The software industry's greatest sin: hiring - <AUTHOR> https://www.neilwithdata.com/developer-hiring <comment><USER4> Technical interviews were once seen as a breath of fresh air.

You can be a nobody without connections or degrees and if you can prove you have skills during an interview process you may be hired.

Contrast this with other hiring processes which are more irrational, like med residency match, investment banks favoring "target school graduates", law firms favoring "top 14 graduates", etc.

I think whiteboarding is dumb and I'm increasingly unwilling to go through with it. That's a hurdle.

But in many careers the hiring processes are walls, as in there is 0% chance you'll get hired. Because you don't know someone, because you didn't go to the right school. The barriers have little correlation with ability to do the job, and more importantly after some milestone has been crossed it's impossible for you to improve your chances.

<comment><USER5> It is true that you can succeed well at tech companies without a degree from a top school. Class, race, gender, sexual orientation are not barriers to success. That's the positive thing.

The negative thing is that most tech companies heavily favor "top school" candidates and actively recruit for them. They would rather higher someone provably less qualified from a "top school" than someone else. They track and boast about how many "top school" candidates they hire.

Tech companies are hugely biased in favoring the upper class. And then they misguidedly try to pay a recompense for this unethical bias by discriminating on the basis of race in favor of "unrepresented minorities". Of course, they still really want those "URMs" to come from a "top school".

Their goal is to counter their active classism through active racism. As if they somehow cancel each other out.

<comment><USER6> One of my previous bosses (at a large tech company) moved over to the US and was asked to hire 9-10 people in a quarter.

Everyone said it was impossible.

She went to LinkedIn, found people with the right skills (strong data and ability to communicate), and had a massive fight with HR because none of the candidates came from "top" schools.

She won the argument, and all of the hired candidates did a great job.

People (especially US people for some reason) seem overly obsessed with the university someone attended, when it doesn't seem to be that predictive of workplace success.

<comment><USER7> > especially US people

definitely not. french companies actually have engineering salary tables depending on your age and university

<comment><USER8> That sounds interesting, is there an english source to read about that?

<comment><USER7> I can't find anything concrete, each company does it internally. There are some articles where they publish the starting salary based on your university's "rank". Try google translate on this: [https://www.google.com/amp/s/www.lexpress.fr/emploi/les- atou...](https://www.google.com/amp/s/www.lexpress.fr/emploi/les-atouts-pour- bien-negocier-son-premier-salaire_1325184.amp.html)

It discusses how there are 6 ranks for business schools, and your salary for the first N years will be based on that. Same for engineering. It's funny that one of the companies is proud to declare that they can move salaries by "up to 5%!!!" based on the candidate themselves (whereas the school can make a 20-30% difference...)

<comment><USER8> Google translate worked really well on the article, thanks! That's kind of insane that the school you went to can give you a raise from 30k euro to 40k euro despite having to do the same job.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week interview process was a lot of effort for pretty mixed outcomes. We realized an interview can't really answer the most important questions: how a candidate works, and what's it like to work together.

So we added an option to interview by way of a paid trial period (work part- time nights/weekends for a few weeks with the hiring team). Figured maybe some people might prefer that, but probably wouldn't be feasible for most.

Every candidate since has chosen that route, with very good outcomes - so far, everyone who did well in the trial period has been a good hire. Some of our best hires did not interview well (and would not have been hired under our old process), but were outstanding in the trial period. And, a couple candidates interviewed so well we almost skipped the trial period, but they struggled to complete even simple tasks during the trial.

We've now optimized interviews for that process, where the decision is primarily about whether it's worth moving to a trial period. That usually only takes a short screening call and a 1-hour call with the team (we're a remote team, even before quarantines).

BTW, if you'd like to experience this first-hand, we're hiring - [https://news.ycombinator.com/item?id=22753515](https://news.ycombinator.com/item?id=22753515)

<comment><USER10> I'm sure you get good outcomes from this, but I'd be willing to bet you are completely weeding out whole classes of people. For example, most parents or caregivers (single or otherwise) don't necessarily have the time for this. Senior engineers are less likely to want to go through this.

I would guess that most of your hires are single young people. And you are already kind of teaching them to work nights and weekends, which sounds like you are, again, choosing people who would not have a problem with a bad work life balance.

I also wouldn't be surprised if your process isn't teetering on the illegal side. Not on purpose, but it might be accidentally favoring or disfavoring a race/gender. Probably not enough to get you in trouble though, because those things are hard to spot. And unless your company is really big, probably nobody cares.

<comment><USER11> I think I'd like this even if I were married, as long as the trial period isn't too long and interview experience indicates that I should have a good chance of landing the job.

Contrast with the alternative: I'm a senior, considering switching jobs, but I have no real way to evaluate the potential new employer beyond word-of-mouth and interview experience. What if it turns out to be a place I don't like and I just gave up my former position for something worse?

Working a few evenings & weekends (and getting a little extra $$) to evaluate the new company sounds like a superb way to gain the confidence and jump ship without regrets. In best case, I get a new job I like. In best case, I get some extra money and keep my old job which is better than the new one proved to be. Win/win? What's the worst that could happen?

<comment><USER9> When we offer the trial option, this is the #1 reason most people are interested in it. They are just as concerned about evaluating us, as we are about evaluating them.

</comment></comment></comment></comment><comment><USER12> > Developer hiring is broken

This seems to be a pretty popular opinion. It totally might be right, but it's not my own experience, so I have a serious question because maybe I don't know what's happening out there with most hiring today - what are the broad-stroke outcomes that demonstrate that hiring isn't working? Are there statistics that show that hiring has problems? All of the reasons given in the article are claims without evidence, nor objective comparison to hiring for other industries. When looking for jobs, I've never been evaluated on IQ or code alone, it has always come with communication and personality and culture fit evaluations, among many other things. When hiring, my own team does everything this article claims isn't being done. So I might be completely unaware of the major trends out there... how can I see those trends from where I sit? Are people not getting jobs who should, has there been high unemployment? Are companies not able to hire people? If hiring is broken, what are the problems it's causing?

> It's a disguised IQ test

It is amusing to me that many blog posts and comments around here argue for exactly that under the same banner 'hiring is broken'. Lots of developers are frustrated about being evaluated by how well they communicate and not by their code. Lots of people here complain about in-person interviews and tests and argue that take-home coding should be the norm, or that coding tests should not used at all.

<comment><USER13> I'm a software engineer working at a company in the hiring space. I've done over 400 technical interviews in the last year alone, and ... this is a hot take, and not the view of my employer, but I think developer hiring processes are fine (At least, at most mature companies.)

There's a problem at the moment in the market that there's a huge amount of pent up demand for senior developers. The market has responded with bootcamps and the like, and we have a ton of junior devs with very little knowledge and experience pouring into the workforce. The sad truth is that most devs fresh out of collage or a bootcamp aren't valuable enough to be worth hiring at large tech companies like Google. Most people who apply to any hiring role you advertise won't really be able to program effectively. (And if they can, they won't know the conventions of the language they use, they won't know anything about security, they won't be able to read code others write in order to debug it, etc etc.).

Programming is hard. It probably takes about a decade of practice to become good at it, and I don't think schools have figured out a replicable way to take someone off the street and teach them programming yet. (For example, most fresh grads have never had to read the code another programmer wrote. Imagine teaching people how to write without teaching them how to read!)

I think there's lots of angry junior folks out there saying "Hey, I can write a simple for() loop in python, and lots of people are hiring - but I apply to lots of jobs and keep getting knocked back! The hiring process must be broken!". And a few angry senior engineers out there saying "Why do I have to keep writing fizzbuzz? Its like I have to prove over and over again that I can program at all!".

Of course, nobody wants to admit that the reason they failed their 6th whiteboard interview in a row is because they aren't very good at system design. And the reason for that is that their collage didn't teach them any system design skills, and they have no experience, and they never learned how to use words to communicate technical ideas. And ArbitraryProductCo doesn't have the runway to train you up.

Of course there's the occasional person who is really skilled and somehow still manages to fail programming interviews all the time. But if the goal of a technical interview is "make sure we don't hire anyone who wouldn't be effective at the job", I think they're fit for purpose. I think the real sin is that we're afraid to tell people they aren't very good at programming yet, and we use technical interviews as a scape goat.

<comment><USER14> > I think the real sin is that we're afraid to tell people they aren't very > good at programming yet, and we use technical interviews as a scape goat.

So does this mean that programming education is broken? That companies should invest more in training? That bootcamps should revamp what they teach? That there should be industry standards for what programmers at different levels should be expected to know?

The most maddening thing about interviews imo is the opacity. There's always uncertainty about where exactly things went wrong, and how it should be fixed next time. It's almost a meta-engineering problem of its own. And it's a metaphor for the lack of software engineering standards.

<comment><USER15> > So does this mean that programming education is broken? That companies > should invest more in training? That bootcamps should revamp what they > teach? That there should be industry standards for what programmers at > different levels should be expected to know?

Programming education is broken. I did one year of computer science at one of the top universities in the world (switched into mathematics after that), and I'd see that course as useless if not actively negative. The only way of learning that I've seen really work for anyone (myself included) is more like a craft apprenticeship, working closely with someone more experienced. We shouldn't be surprised that that produces widely different approaches.

Frankly the field isn't mature enough to have standards. If you tried to set a professional exam based on today's best practices, in five or ten years the answers would mostly be wrong. We still don't know the right way to write software. Million-dollar systems still come with laughably simple bugs.

What does the interview process look like for a craftsperson? That's probably the best we can expect from a field as unsystematic as ours. The one thing that strikes me is that in creative fields it's normal for people to show a portfolio of past (client) projects, whereas in software past employers usually keep all copies of your code. I have no idea how we'd go about changing that norm though.

<comment><USER13> > What does the interview process look like for a craftsperson?

Welcome to my shop. Here's some wood. Make a chair!

In most of the interviews I conduct, I get the candidate to write follow a spec we've written and some code. And I get the candidate to debug a program with some failing unit tests. About half of the candidates I interview fresh out of school have no idea how to get started debugging a program they didn't write. You need to do that just about every day at work, and its usually not even mentioned at school.

But I've worked as a teacher too. I will move heaven and earth for my students, but in my darkest moments I think taboo thoughts. Maybe IQ is a real thing, and maybe some people just don't have the neural hardware to ever be good at programming. If thats true, we do those people a huge disservice. We steal years of their lives and tens to hundreds of thousands of dollars training them in a skill they can never master. I'd love to see the stats on how many people graduate from a CS program, try but never find reliable work in our industry. I worry the numbers might be damning.

A few months ago a candidate I interviewed asked for feedback at the end of the interview. He wanted to know I recommended that he practice so he could improve. I said he should pick an opensource project on github - <USER2> something thats not too big and look through the issue tracker. Pick a simple looking bug and try and fix the bug and submit a PR. His whole manner changed after I said that - the idea of doing that was so incredibly daunting to him. But that right there? More or less, thats the hiring bar. As an interviewer I'm trying to answer the question "If I hire you, can you do the work?". Read, think, understand, modify, write code, communicate it to your team. Thats the work and thats the bar.

<comment><USER16> Both of your "taboo thoughts" seem blatantly obvious to me, and not especially taboo. Intelligence obviously exists and some people have more of it than others, even if the metric "IQ" doesn't perfectly capture it. And yeah, some people are not cut out to be programmers. Why are we pretending otherwise?

<comment><USER14> I find that there's a borderline self-contradictory aspect of hacker culture. While we romanticize the concept of the 10x programmer, which is an individual of genius, our culture also stresses the concept of autodidacticism. Teach yourself to code. Just use MOOCs. Build it yourself. Hack on an open source project. So there's this tension between valorizing the inborn superhuman and the belief that it's possible to reach greatness- though perhaps not 10x greatness- by pulling yourself up by your bootstraps.

In a way, this is mirrored by the organizations themselves. Startups who make the right moves, and work hard through grit and 60-hour weeks, can become unicorns. Also some startups are led by visionary founders and cannot fail.

So all of this, buttressed by real world labor demands, create incentives for people to try to become programmers. Even those who aren't "cut out to be programmers." Our increasingly cutthroat and unequal society also incentivizes people shifting to programming as a safe career choice. "Learn to code."

I don't know how we can stop "pretending otherwise." Tech companies continue to complain about the engineering talent shortage. Bootcamps and online courses continue to promise people that they can become that talent. There aren't any agreed-upon industry standards by which to exclude people who truly aren't fit for it. FAAMG has infinite money and power in the industry to continue their entrenched practices. Most startups cargo cult the leading megacorps' processes. So instead, candidates are encouraged to continue grinding Leetcode and apply, apply again.

<comment><USER15> > I find that there's a borderline self-contradictory aspect of hacker > culture. While we romanticize the concept of the 10x programmer, which is an > individual of genius, our culture also stresses the concept of > autodidacticism. Teach yourself to code. Just use MOOCs. Build it yourself. > Hack on an open source project. So there's this tension between valorizing > the inborn superhuman and the belief that it's possible to reach greatness- > though perhaps not 10x greatness- by pulling yourself up by your bootstraps.

Those seem like orthogonal aspects. If we stressed the idea that you had to do (say) a 4-year degree at a great university, or something akin to the bar exam, would that be any more compatible with the idea that some people are 10x better than others? If anything I'd say the opposite: we'd expect most of the Harvard graduating class to be on roughly the same level, it seems a lot less wild that some self-taught people could be 10x better than others.

> So all of this, buttressed by real world labor demands, create incentives > for people to try to become programmers. Even those who aren't "cut out to > be programmers." Our increasingly cutthroat and unequal society also > incentivizes people shifting to programming as a safe career choice. "Learn > to code."

This happens in every field though? You get people who are desperate to become a doctor and apply to med school year after year, despite being completely unsuited to it. You get people who insist they're gonna make it as an actor/musician/comedian and spend decades working crappy day jobs so they can live where the action is, when really they'd be better advised to pick a career they're good at.

> I don't know how we can stop "pretending otherwise." Tech companies continue > to complain about the engineering talent shortage. Bootcamps and online > courses continue to promise people that they can become that talent. There > aren't any agreed-upon industry standards by which to exclude people who > truly aren't fit for it. FAAMG has infinite money and power in the industry > to continue their entrenched practices. Most startups cargo cult the leading > megacorps' processes. So instead, candidates are encouraged to continue > grinding Leetcode and apply, apply again.

Well, if we told people outright that programming is a matter of IQ, and gave an actual IQ test rather than an IQ-like test in interviews, that might help some people realise it's not for them. You're right that what catches on in the industry is largely a function of what the most successful companies pick, but ultimately that list of top companies is not static and we'd hope that companies with better hiring practices will (eventually) rise to the top.

<comment><USER14> > If anything I'd say the opposite: we'd expect most of the Harvard graduating > class to be on roughly the same level, it seems a lot less wild that some > self-taught people could be 10x better than others.

That's not the point I was trying to make- I'm saying that in programming we both prize talent born of nature, and skill honed by nurture. (Though admittedly that may exist in many other disciplines.) Because of the latter emphasis on grit, hacker culture encourages self-improvement and going beyond the capacities one started with. That dogma of self-improvement goes against the notion that people are not cut out to be programmers.

Though of course, this could also be a marketing ploy for recruitment on behalf of management: "Anyone can code, you should learn to. But we only hire from the best." By encouraging an increase in talent, they have a larger labor pool to choose from (and potentially undercut wages), while plucking out the few that can pass their interviews.

> This happens in every field though?

To some degree, but the details vary. Medicine or law used to be seen as safe secure careers into the (upper) middle class, but doctors are limited through the AMA, and currently law is a notoriously difficult and costly profession with dwindling prospects. Entertainment and the arts is universally known as a risky proposition. We're talking about software, which has had the reputation of being the current surefire path to a stable, even successful, career, for at least the past two or three decades.

> Well, if we told people outright that programming is a matter of IQ, and > gave an actual IQ test rather than an IQ-like test in interviews, that might > help some people realise it's not for them.

Leaving aside the legality of using IQ tests to exclude candidates, that opens up the questions of _if_ there is a direct correlation between programming good software and IQ, why programming out of all STEM fields should focus so heavily on IQ, and why all of those other technical and engineering professions don't need to resort to IQ tests for hiring.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Given HN's demographics, I'm probably older than most here. I've worked with and personally invented quite a few great products, usually spanning Product, UX, and Engineering work. It's a joke to pretend ageism isn't a thing, and asking questions that only a recent CS grad is going to remember is not a tacit form of filtering for age. There's not many technical questions a fairly smart, non-lazy person with some experience can't either find with a Google search, a conversation with a peer, or a bit of hacking to figure it out. It's been a LONG time since I had to write the code to invert a binary tree, but I've done stuff orders of magnitude more tricky and valuable than that countless times, as have many others. What makes a great engineer? I've lost count of how many times I've had to rewrite the code of many engineers who aced the 'whiteboard shuffle', then wrote hopelessly over-complex and unmaintainable garbage. Most of software engineering is not that hard from a 'learn the things or look them up to get stuff done' perspective. What's hard is working well with others and consistently emitting tight, semantic, legible code that's fun to look at and extend.

<comment><USER18> You say that as if you were born perfect. As someone of elder years myself (and not just by SV standards), what you are saying is quite obvious to anyone with experience. But when you're young and know everything, it's not so obvious. We too, were brave believers of complex == good in our youth. Well, I sure was.

It's also important to learn by failing (aka learn by doing). Like parenting, there are many things in organizational behavior that can't be learned until you experience it for yourself. Few of us can be told "don't do that" and will internalize it to the degree necessary, without experiencing personally what happens when you do "do that". These people graduating from top schools and going straight into FAANG are doing themselves a disservice of the worst kind, by missing out on important organizational learning experiences.

On that note, I recommend everyone either get fired from a job, or work for a company so bad you quit, at least once. I also recommend it at most once. :)

As for inverting a binary tree, with your experience you must realize that the very large majority of applicants are poseurs. You need to filter them with easy things like inverting a binary tree. Most companies need "doers" not "thinkers". Even at the highest levels of pseudo-management (staff and above IC), you really better be able to do this kind of easy stuff.

<comment><USER17> I'm sorry if I made it sound like I was born perfect. That wasn't what I was trying to convey. Yes, we learn by making mistakes, and I've sure made at least my fair share of them. My point is that horking out algorithms on demand is definitely not the same thing as being a competent software engineer, nor is it particularly predictive of the likelihood of developing those skills. Also, I measure my success by the people I've helped and the impact I have on the business. For instance, figuring out how to eliminate 500,000+ lines of code from a codebase strikes me as way more valuable than hopping about at a whiteboard like a trained monkey. Ask better questions, get more impactful employees.

<comment><USER18> Agreed!! Sorry I didn't mean to accuse you of anything.

I share your criticism for poor interview practices. But not that basic knowledge whiteboard questions are asked -- sadly, it's a requirement -- rather that most don't get beyond that. Or dwell on the classic "OMG how could you not know this piece of trivia that we only learned here at our org after 12 years refining the solution".

Anyway I adore that kind of interview. It lets me know I don't want to work there! I call those interviews successful. Most candidates (or at least most discussion of interviews from the candidate POV) seem to think the entire purpose of an interview is to prostrate yourself to the all powerful company, that they may see you as worthy, oh master. It's the wrong perspective.

So while I share your criticism, I am not dismayed by it.

</comment></comment></comment></comment><comment><USER19> To the best of my knowledge, my workplace uses a fairly traditional hiring process that's the same for hiring a programmer or a machinist: Resume screen, phone screen, on-site, offer.

I have to say we do really darn well, especially given we're located in the Midwest and supposedly the brightest programmers have fled to the hot markets. One thing I like is that we get a range of ages, which is heartwarming given that I'm over 50 myself.

The thing to do is look around at your colleagues and ask if the hiring process is really broken. It may be that we've all been driven into a panic about hiring, by the hiring industry.

<comment><USER20> > a fairly traditional hiring process that's the same for hiring a programmer > or a machinist: Resume screen, phone screen, on-site, offer.

Some years ago, I was looking for a job, and an employed friend of mine sent me a problem and said "this is our hiring challenge. Try it out".

I completed it, and she asked for my resume, and turned in both to whoever the relevant person was at her company.

She then reported back to me "he said this is the best response he's ever seen to the challenge, but we're looking for someone with more experience". I was not contacted by anyone else.

And years later, when I ribbed her about this, she told me "he regretted that, later".

I note that by putting the resumé screen first, you're committing yourself to the idea that whatever you're looking for in the resumé screen is more important than anything you might learn in the phone screen or the on-site. Do you believe that? Are the phases looking for the same things? If not, is that intentional?

<comment><USER21> I did resume screening for about fifteen years for different small companies, it's first because if I phone screened everyone who sent an letter or email expressing interest there would be no time for anything else and I would be wasting a lot of candidate time when I could look a resume and know if someone was ballpark decent and just let both of us off the hook early with rejection (a lot of people swing for the fences with applying for jobs) if this was easily ascertainable from the resume. I am assuming candidates are making the best argument for themselves in their resume.

<comment><USER22> My last company put the automated HackerRank test first, because if we filtered by phone call or resume first, there would be no time.

HackerRank was so great at saving everyone's time. One third of candidates never opened the link. Open third opened but didn't do any exercise.

</comment></comment></comment></comment><comment><USER23> This makes so much sense. I've stopped doing in-depth technical interviews for precisely this reason. Instead, I take the developer out for lunch and spend an afternoon discussing our software stack and business with them. It always gives be better results. There is no stress. I don't want to see their code, but I do want to understand how they think and work.

<comment><USER24> Would you hire a sculpter by taking them to lunch and talking about tools but never seeing their sculpture?

<comment><USER25> Would you hire a doctor by insisting they perform surgery in front of you? Would you hire a lawyer by demanding they filling out legal paperwork in front of you?

<comment><USER26> My background is a mix of neuroscience/biology and machine learning, and it's always funny to me how jobs right on that margin interview totally differently, depending on how the organization started.

If they think of themselves as "tech", you're at the whiteboard, reversing strings in C and playing games with trees. When I interviewed for nearly identical job in a "science" department, someone spent 45 minutes chatting with me about the coding behind projects I had mentioned. I even offered to show or write soome code and got told "Nah, we already looked at your github and it's fine."

</comment></comment></comment></comment><comment><USER27> This article was painful for me to read, mostly because of how accurately it reflected my experience with job searching.

I'm not the worlds most experienced dev who's shipped multiple products, but for a relatively inexperienced (2y professional, 5y total), I feel I am overlooked for positions I would excel in because I am just plain bad at technical interviews.

I have a fairly impressive github, a creative cv and recruitment page, and a bunch of nice addons that show how much I care about programming both technically and socially. I have probably the best possible background for remote positions in particular. I get interviewed a lot because of all this, and then facepalm my way out during technical interviews.

I'm the kind of dev that can eventually solve pretty much any leetcode-y type problem, but it takes me a long time of sitting in silence and playfully experimenting with a repl or similar. This translates extremely poorly to interviews.

I have also noticed that my brain will just disconnect midway through interviews and I will fail something that under ordinary circumstances I would never miss.

A combination of my style of thinking mapping poorly to the interview format, and stage fright, means that my odds are poor; even against candidates who would be both technically and personably worse fits.

Not really sure how to tackle this :)

<comment><USER28> Sounds like you know exactly what your problem is. Technical interviewing is just like normal problem solving, just you have to narrate your thoughts as if the interviewer's inside your head with you. Get some sample problems that match what you're seeing in your onsites, roleplay having an interviewer there with you, and practice them while recording yourself. Best is if you can have a real human. If you're passionate enough, it would be a great idea to organize some kind of group for people in similar positions.

Either you will learn the skill enough or you will find a position that fits your current skillset along the way. Being understood by other people is where the rubber meets the road for ideas having any impact and communicating your technical ideas is an important skill in general.

<comment><USER27> Aye, I hear you. I was giving it more thought over the last few days having written the above comment, and I realised that what happens in tech interviews is that I switch my mode of thinking.

Under normal circumstances, I sit and problem solve, thinking only of the issue at hand, branching out and following leads and so on.

Under interview circumstances, I instead try to anticipate what the person scrutinising me wants to see, and try to like, game an ungameable situation, which blocks my natural problem solving thinking.

I have noticed that when I'm in a position of subordination, I do worse creatively. This isn't to say I can't work as employee, but rather in specific situations, such as "person knows x and is just watching me try to do x", I enter this reactive thought mode.

Conversely, when I am in a superordinate position, I find myself much more creative than my baseline, thinking clearly and well.

I don't know how to handle this for interviews.

</comment></comment></comment><comment><USER29> You've got to know if the other person can code. Lots of people can talk a mean game and make nothing and few people can spot them.

That's the thing, though. If you make a reputation as the kind of guy who can near 100% spot the good engineers, you will make boatloads of money. An employer will pay you more than $30k if you only do great hires. You do 10 of them with your conversation out to lunch and you've made $300k. That's the low-end.

But no one can do that and the few with high hit-rates act as executive-search agencies where they make a lot more.

But I think I would never interview anyone I've worked with. That just seems like a waste. I already either know that they can or can't do things.

<comment><USER30> > You've got to know if the other person can code. Lots of people can talk a > mean game and make nothing and few people can spot them.

If only this were true. I've co-authored a (technical) book, edited another, have dozens of OSS contributions, and GitHub projects with hundreds of stars. Everyone still tries to whiteboard interview me. Usually I tell them to screw off, but still. My theory is that (a) people are too lazy to come up with better hiring processes and (b) there's a prevalent "if it ain't broke" mentality so there's little motivation to do anything about it.

<comment><USER31> Man the guy you responded to is right. I've interviewed and mistakenly hired several types of these people.

Here's the thing, you're not too wrong either. I don't doubt that there are tons of great programmers who can't pass a technical whiteboard interview for various reasons.

But without a doubt if you pass a whiteboard interview your success at that interview is highly highly correlated with your success at the job.

You tell me... how do we screen for these master bullshitters and hire people like you? I would love to know because I see no other alternative than to use whiteboard interviews. I want to hire someone like you, but I have no clue how to differentiate you from a person who can really code and a person who is a master bullshitter.

<comment><USER31> I think a novel take home test may work. Anybody have horror stories about candidates who did well on a take home but bombed at the job?

</comment></comment></comment></comment><comment><USER32> My favorite interview was at digg.com. A four hour interview was going great. My dream job. I knew their tech solid. Then the last guy - walked in [ianeure]. He asked: "What is a having statement in sql". I leaped in - rambled on and on how you can filter aggregated sets. His response: "I don't think you know how they work." I sat there confused and concerned. He explained you don't need a group by with a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25]. Welp, he then rolled his eyes and left. Four hours of an interview ruined. Oh well. Yep. That is how tech interviews go. He went on to ruin digg.com (the rewrite everything guy) and I promised myself to never be a dick to people I interview.

<comment><USER33> > He explained you don't need a group by in a having statement and that I > needed to go back and study sql. I sat there awkwardly [I have been writing > sql since I was 14 - I was 25].

He's technically right though. For instance in postgres, you don't need to have a GROUP BY clause when using HAVING [https://www.postgresql.org/docs/current/sql- select.html#SQL-...](https://www.postgresql.org/docs/current/sql- select.html#SQL-HAVING)

<comment><USER34> "Technically correct", the most irritating form of "correct"

<comment><USER35> Also, technically the only form of correct.

</comment></comment></comment></comment><comment><USER36> I decided pretty early in my career that I wasn't going to concentrate on figuring out how to get hired to what folks consider the top tech companies in the world.

I decided to take a different route. Take the decent-paying, but average job at an average-ish company, which will require immersive experience in all aspects of running a web infrastructure.

The reason for this, I didn't see "getting a job at Google" as the pinnacle for me and my achievements. I saw "creating my own successful company" as the end goal.

Sooo many benefits to this I think. You'll get the IMPORTANT experiences and knowledge, which will benefit you regardless of whether you are able to achieve the end goal of creating a successful business. The ceiling in terms of compensation is SOOO much higher. And in this scenario you're ALWAYS doing the most important things. In my experience working for large corporations you will typically be doing things that are far less important and in most cases your job will not push your limits. You will be a cog in a wheel using maybe 20% of your capacity to do amazing things.

Worst case you go back to doing what you love making a decent living. Best case you far exceed anything any of the FAANG companies could ever offer you.

<comment><USER37> The only way you are going to exceed FAANG compensation at an average-ish company is if you go into senior management at that company, which is a completely different career track.

You make it sound like being a web developer at a non-FAANG is somehow different than being a web develiper at a FAANG. Regardless, you are going to be working on some permutation of a CRUD app.

</comment></comment><comment><USER38> You sorta evaluate the soft skills while evaluating the hard skills - how they approach a question, how they solve the problem, etc. Our general rule hiring was hire sharp people, but no assholes - at least nobody more of an asshole than I am ;)

I think the biggest problem is actually whiteboard coding problems - <USER3> does that in real life.

<comment><USER39> I think designing on whiteboard helps if not coding. Designing shows the big picture they have in mind for solving the problem.

<comment><USER40> Coding on a whiteboard is the worst. I've been in google interviews where I mention that the whiteboard format makes the process very difficult because of how much work it is to rework existing code.

The interview replied "well wouldn't you have to do the same on a computer?" _chuckles to himself at how clever he is that he realized that_

No numb-nuts, on a computer I can move lines around by pressing Alt+Down. Here I need to erase the entire thing and re-write it, which wastes precious time, so instead I spend way more time pre-planning the exact layout of the code, which wastes more precious time.

And in the end you take a picture of it to transcribe into the computer to send to the hiring overlords. Just let us use our tooling to begin with.

Ugh.

<comment><USER41> Last time I interviewed with Google (in 2018) they had me code on a Chromebook. Still just dumb algo questions but much better than a whiteboard.

<comment><USER40> Interesting. This was 2019, but it was a SRE position. Don't know if that makes a difference. Probably not, because the interviewers didn't even know it was for an SRE position.

</comment></comment></comment></comment></comment><comment><USER42> I hire people from direct conversation that jumps around many subjects. My goal is to see the wheels turning, find what excites them, get the lights in their eyes shining. If I can't do that in even 15 minutes, then I lose interest fast. If I can, an hour goes by in a flash and I really get to determine if they align with the role they've applied to.

I could care less about data structures and graphs. Do they care about code and can they learn and can they communicate. That's what matters.

<comment><USER43> Many companies get by with mediocre developers, mine is one of them. You're not demonstrating that your interviewing style generates superior results.

<comment><USER42> As a consultant, I'm almost exclusively on high pressure projects that require a higher level of talent.

I have zero problems hiring adequate talent if there are suitable roles.

</comment></comment></comment><comment><USER44> We use a 3 step process:

1\. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with

2\. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems, but come out of the designs we've implemented. We ask for 100 lines of code and not more than 2 hours. They take as much time in days as they need, and let us know when you're done. The candidate then comes back and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not do criticize their style and approach.

3\. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It's a check point to look for concerning weaknesses, as well as get buy in from the broader organization.

This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.

</comment><comment><USER45> I wrote a book on this last year, out of my frustration with dev interviews

[https://www.amazon.com/Whiteboard-better-hire-best- developer...](https://www.amazon.com/Whiteboard-better-hire-best-developers- ebook/dp/B07FJ6N8P1)

I've interviewed and hired a lot of people over the years, and have been interviewed a fair amount. The way a lot of companies do it didn't make sense to me, so 5+ years ago I decided to figure out a better way to do it.

My basic premise in the book is that in an interview when asking someone to show skill, it should be as close as possible to what the job is. Most interviews are just not anything like a whiteboard interview or algorithm question. I get that can show how someone thinks, how they ask questions, etc. - but to be honest I rather have them actually DO something as they would do if I hire them.

I've had a lot of luck with this way of interviewing. The reality is it can still be a crapshoot - you really don't know what someone is going to be like until you work with them for a while - but this at least gets closer to making a more informed decision ('cause you basically work with someone, in a small way!)

</comment><comment><USER46> People still acting like we all live in silicon valley and the dot com bubble hasn't bursted twice, software engineering is over as a high impact career, the meta has shifted from solving problems to finding problems.

There are too many smart people in this industry who won't/can't code but act as gatekeeper to valuable problems. My advice is to search out these problems yourself, its a much more challenging problem then any programming.

Or spend two weeks preparing for your technical interview to learn stuff you won't ever use again and then do the bitch work of someones over-engineered vanity project while the plebs are doing "research", "marketing", "design", and "business development".

</comment><comment><USER47> I did a coding test the other day.

To be fair they said don't put more than 2 to 4 hours in. However I'm not someone who can fail to meet the requirements so I spent 8 hours building it to meet the requirements exactly.

Heard nothing at all back.

Silence.

<comment><USER48> I'm assuming it was for other reasons, but it is possible they did see you put all that extra effort into it and figured that's not the sort of person they want. At least at my job, balancing the time spent on various issues is very important.

<comment><USER47> No matter what they say, handing in a half done coding test because you ran out of time is a fail. IMO anyway.

Probably it was virus related but I'm not very enthused about doing coding tests any more.

<comment><USER49> Totally agreed. More often than not, I have failed the automated graded filter tests. I seem to have better results when I know that the company is also taking the process seriously for e.g., allocating an employee's time to evaluate me over the phone / in-person

</comment></comment></comment></comment><comment><USER50> I interviewed for an agency in my city. The first three interviews went well. Then the interviewer vanished for a week or so. I thought things were done after following up a few times with no response. Then I heard from them again a month later, the position was infilled and they wanted me to come in and meet the team.

So I did, they made fun of my suit, they grilled me and then acted like I was unsure of the job roles... however I'd gone over them many times in the listing, prepared, and had three successful interviews. The person I originally interviewed was there, I have him an odd look, he gave me an "I'm sorry" shrug. And I left, perplexed. I was polite and professional the entire time.

Then they called again, now the CEO wants to meet me face to face. So I did, the other person who was his partner didn't show up until 40 minutes later. I was having a great time with the CEO and asked him a lot about how he built the company, what the future looked like, and what Em he enjoyed most about the culture. I was getting into my work and history when the second individual showed up. He arrived, interrupted the story unintroduced, made fun of my suit, looked at his watch, and gave me an annoying look.

I started from the beginning as requested, I got a sentence in and he nudged the CEO and said "were late". And that was that.

While they were walking away he made fun of my suit again.

<comment><USER51> I used to own a suit like that ;)

No, really. In my case I went with white-green because I liked it. It was quite obvious that it made the bank employees feel unsure if they should mock me or if I was some sort of secret celebrity.

</comment></comment><comment><USER52> The problem I keep running into is that the more room for nuance and fit and holistic evaluation that you inject into a hiring process, the more room there is for interviewers to fill that space with their own biases toward hiring people like themselves. In that sense, the white board problems are pretty fair, even if they're (very) imperfect.

</comment><comment><USER53> Anecdotal evidence:

Several times in my life I've had the strange luck of being told the internal workings of a decision after I was rejected for a job. Usually somebody from the interviewers liked me but couldn't convince the others, and subsequently decides to find me on LinkedIn and send me a direct message.

The messages have been eerily similar and are usually like this:

"Hey Dimi, I want you to know that I think you would be a perfect senior dev for our team. But the other guys said you were awkward part of the time, you didn't feel like you'll fit with the rest of us, and one of them heavily emphasised that you hesitated before answering one question very specific for our work... and when I pressed them to elaborate further they just angrily told me that I don't get it.

I wish you luck in your future searches but you should know that if it were up to me you'd be working with us now."

You can lose your balance for a minute while being evaluated live by several people? You can hesitate before answering a trick question about a niche project? Imagine that.

It's really bittersweet to get these internal insights and can make you want to pull your hair out -- but it did give me the perspective that most of the people charged with hiring go by a gut feeling and personal sympathy.

<comment><USER54> Yeah almost anything is possible so one really has to try not to obsess about it too much. I know it's hard. I can't say I'm able to do it either.

Anyway, my anecdote: we were interviewing for a C developer position. The next candidate was in his 50s. Our project leader took a dislike to him the moment he saw his resume. No idea why but I assumed it was either his age or that this project leader knew him and didn't want to work with him for some personal reason.

The project leader arrived to the interview at least 40m late. In that time this candidate impressed me (as the C guy) very much and I said 'hire' immediately. However, as presaged, the project leader said no.

This candidate had no way of knowing what had happened. He definitely could tell I was impressed so he probably assumed it was his age. Just imagine how he must've felt. I probably should've contacted him to let him know how messed up the our process was.

<comment><USER53> Not sure how legal this is (the giving insights into your internal processes to a stranger part) but since there are no trade secrets involved I'd imagine it's quite safe.

As I said above, it can be really bittersweet knowing the details but I'd advise you to strive to show maximum sympathy -- including contact them privately and let them know what and why happened.

It's a little comfort for somebody who is about to run out of savings to hear "sorry that our process is so effed up, dude, and best of luck in the future!" but I can assure you that it helps them make peace with that past further down the line.

</comment></comment></comment><comment><USER20> > when a developer is hired, it is incredible the extent to which the process > will ignore the human being and focus exclusively on algorithmic/technical > aspects. It's a disguised IQ test, and we all know it.

> What's crazy is most people hiring will even throw away your ability to > learn and adapt!

These conflict. At the very least, the second quote illustrates that the hiring people are not aware that the interview is meant to be a disguised IQ test.

</comment><comment><USER17> Let's also not forget the bias of Indians only hiring other Indians. There's entire product development teams in the Bay area that are close to 100% Indian. Sorry, I don't buy the excuse that's the only people available to hire. How does this relate to competence and the quality of the engineering work product? Race, gender, age, do NOT matter. So, why the pro-Indian bias?

<comment><USER37> I've noticed this trend in companies with Indian middle managers who tend to aggressively pursue hiring outsourcing firms (like Accenture) to bring in offshore Indian resources, and the project inevitably fails.

Every time I've seen this, the decisions to hire the outsourcing firm never really made sense, so the easiest guess to make is the managers were receiving some kind of kickback, but we can only guess.

<comment><USER55> I would hazard to say that it is an Indian cultural thing. But it seems to be a spectrum since I have read accounts that some Indians don't hire Indians who don't belong to the same caste/region/state.

</comment></comment></comment><comment><USER56> As someone currently interviewing, with 10ys exp scaling multiple successful companies, I couldn't agree more. Some of the tech questions I've been asked are so useless in practice it's unnerving.

</comment><comment><USER57> Yes, it's the reason I'm not currently employed in the software industry. After a decade of being a professional developer, I decided to start building physical things and learning other maker skill sets. Whenever I need some extra income I start looking at software jobs, but I'm not able to think clearly during these sort of test situations, and they don't usually go well. I've built so many things from software products and businesses from scratch and could do so again, but it just makes me bitter to even subject myself to this initiation. I would be much happier (and companies would have more diverse candidates) if a resume and past experience did the talking like other professions.

</comment><comment><USER58> The core problem is that many people who apply for software developer jobs are attracted to the money, and just aren't very good at coding. Slogging through these interviews is a drag and a waste of time for capable developers. So, the process is delegated to junior people who don't yet have the judgment or experience to know what's important.

This is a joke, but uncomfortably close to the way junior people interview:

[https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...](https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_carpenters_were_hired_like_programmers/)

</comment><comment><USER59> The thing is, when you start having a lot of candidates at your door, say, because you are a big company with interesting problems and/or good benefits, and the position is sought-after, your recruitment process costs even more. So you look to lower that cost by filtering out applicants based on some criterias. People from renowned schools go first because they are more likely to be skilled on average, if you ever deplete that pool, you look for the rest.

I recruit for my company, and we don't do that, in fact we do quite the opposite. But I'm pretty sure that's how big companies see it.

</comment><comment><USER60> I think it depends on the company. In a small company it's vital that developers understand user needs and want to provide a great user experience. Bigger companies can, but not always will - see Google, have dedicated people to think about the product the user experience and how the product should catter to a particular user base. Those people can translate the requirements for developers.

I am not saying that developers should be autistic and completely ignore anything that is not code related but it can be done. Google failed but others succeeded, see Adobe or Ubisoft.

I certainly like to code and like technical intricacies but I always looked to code from an entrepreneur pov: always trying to work on something which will be useful for someone and ask myself what feature is going to be useful, to how many people and in what way. I did my share of "inverting binary trees" but that was when I was a student and needed to learn. I always tryed though to use such a technique to solve a real issue.

Maybe CS programs at universities should start teaching not only CS and programming courses but also concepts about thinking products, understanding user needs, assessing user needs.

Architects are trained not only on visual and technical aspects of planning buildings but also on understanding user needs and making the building useful for a particular customer. It's useless if a house looks good, uses clever technical solutions but no one is wanting to live in it.

</comment><comment><USER61> Developer hiring is not broken, it is the people who do the hiring that are.

It could not be more clear to me and their conclusion only makes me more sure of it

      We need to throw away this idea that you can get the measure of a person just by subjecting them to a faux-IQ test.

      We need to fully internalize that being a great software developer is holistic and draws on abilities ranging from, yes, technical skill, but also empathy, experience, taste, grit, perseverance, and independence.

      Being a great software developer is multi-disciplinary and we need to actively and vigorously reject the notion that just being good at "cutting code" and inverting a binary tree is the end of the story

      and is therefore the only axis on which to assess people who work in teams and build products for other human beings.

The kind of person who is able to judge someone for such skills, is also probably very high up the company ladder, a busy person who cannot interview every candidate. At the end of the day, 50% of interviews are going to be conducted by people who were until recently new-grads and have only taken exams which are neither technologically holistic nor gauge for non-technical essentials.

This is not a problem in the system. This is a problem of scale.

</comment><comment><USER62> Maybe that's just a software developer thing? When we hire technical but not primarily software-developer roles, we focus on the particular role's requirements, and the skillset and experience the candidate is bringing. If this is a product support role, have you done product support? If this is an ops role, have you fielded random "urgent" requests from development teams and recovered bad production deploys? Do we need someone who can get something done ASAP, and as such do they have all the needed skills _now_ , or can we wait while they familiarize themselves with a bunch of new stuff?

I generally ask few technical questions because I'm mostly interested in everything _other than_ your technical knowledge. I can find 50 people who have taken a coding bootcamp and memorized an entire language's inner workings. And I can usually quickly determine how deep your technical knowledge is by throwing stupidly specific questions at you. But I won't know whether you can apply that knowledge in a way that will gel with the team and the requirements of the role.

Which is why most quality candidates come from personal referrals. If you want to get a good job, develop good working relationships.

</comment><comment><USER63> 1\. Fizzbuzz

2\. If you claim SQL: Explain LEFT JOIN ... IS NULL pattern. Do you know about little bobby tables (injection exploit).

3\. "How does the internet work?"

4\. "Tell me about a hard / interesting / instructive bug you had to handle.

5\. What would you do differently if you were the lord high poobah on your last job?

6\. Tell me about something you helped finish and ship to users.

7\. What do you have to say about OUR product?

Those questions have helped me hire some great people. They apply to anybody from a fresh-out to a self-taught to famous programmers.

You CAN shove into their face some strange line of code that depends on arcana of operator precedence. But the only useful answer there is "I would never write something so obscure."

<comment><USER64> Or you could have gotten lucky in the pool of candidates you are sampling from. If you end up only interviewing good (or bad) programmers, then your interviewing process never really mattered in the first place. So, no formulaic interview process is going to ever be proven effective (and in fact, is very likely never going to be much more effective than a coin toss). People really need to get over themselves with their "clever" questions and answers.

</comment></comment><comment><USER65> I feel like this explains the needless product abandonment and reinventing at Google.

</comment><comment><USER66> No, the greatest sin of the software industry is the sprint meeting. That's literally a lie we perpetrate every day.

</comment><comment><USER67> Is this really a thing outside US/US companies? I've been now 10 years in software industry (as a developer) in Asia and Europe and never had one of these "whiteboarding algorithm"-interviews.

Interviews I have attended might have included something like that, but it's usually 1-5%. Most of the interview is talking about my previous experience, "how would you design a system xyz", homework tasks, "Take a look at this piece of source code for 15mins and tell me what's good and bad about it" etc.

<comment><USER21> I'm in California but applied for a couple of jobs in Europe. One had a 24 hour timed test on hackerrank to complete 4 of 6 problems (unrelated and complete mini games) and another for an Android position had a timed hackerrank test in Java trivia (disguised as a programming test) with a short time limit. These were the screens so the follow up on sites were probably worse.

</comment></comment><comment><USER68> People have been saying that tech hiring is broken over and over for a decade now but nothing was done about it. Hiring processes are still rooted in the "If you can solve this tricky textbook problem, you're smart" ideology which is completely wrong because it commoditizes a very narrow type of intelligence which is not related to value creation.

Unfortunately it's too late to fix that problem now. If a top value-creating developer was hired by one of these companies today, their approach and thinking style would be fundamentally incompatible with most of the other people who work in the company today (due to the legacy of bad hiring). Moreover, their boss would probably be one of those textbook and process- oriented people who is completely detached from actual value creation; working under such people is deeply depressing for value creators who have developed a laser-focus "eye on the prize" and "simplest is best" mentality from years working in harsh startup environments.

I would argue that the "simplest is best" mindset is good at any scale but the corporate hiring process has systematically weeded those people out.

That's why corporate monopolies are harmful for society, some entrepreneurial people just can't fit in at the bottom of large corporate hierarchies but yet they are often left without any alternatives.

</comment><comment><USER69> Is it actually an IQ test? Can you practice for an iq test like you can for an interview? I don't see it being that difficult to just grind on leetcode enough to snag a FAANG job.

<comment><USER70> It's not that difficult for people smart enough to get a FAANG job. Personally, I've heard anecdotes from people who can't understand leetcode problems even when given the solution. Professionally, I've seen multiple people who were clearly _trying_ to recite a memorized solution for an interview problem, but just weren't clever enough to do it properly or talk about how it works.

<comment><USER71> For all the complaints about whiteboarding, it does filter out a lot of people who can't seem to generalize problems or are weak at either problem solving or coding. I don't see how anyone who has given technical interviews could say whiteboarding is a waste of time, unless they are not good enough at whiteboarding to be able to productively give such an interview.

</comment></comment></comment><comment><USER72> I'm in a mid-sized startup with headcount in the mid hundreds, and my mental model is like this: Say you have a batch of 100 ppl applying for the generalist SWE position, among which you can only afford to bring onboard ~10. So you need a filter that approximates this desired selectivity, and it needs to be consistently applied across the board for fairness. Also, you can't afford to spend too much time + effort per candidate. What do you do?

It so turns out that simple technical problems that requires coding, in conjunction with active spotting for deal-breaking red-flags, can be calibrated well to achieve both fairness and desired selectivity. I can't think of anything else that can so conveniently satisfy the rather essential conditions above. Of course the devil is in the details... which lies mostly in the kind of technical problem you ask.

Personally I prefer handing out distilled real problems encountered at work, with a hint of realism, no dependency on know-how other than a solid understanding of CS fundamental, and reduced to be self-contained. Think of the "kinda smart" bits sprinkled across your codebase. This of course requires careful design and calibration, and risks spoilers online, but it's been consistently working well. Personal anecdote though so YMMV.

</comment><comment><USER73> The problem as I see it with focusing on history & people skills too much is a lot of the weak candidates are flat out lying about those kind of things.

I've interviewed more people in the last year than any previous year of my career. We found numerous candidates cheating on online coding tests. Weak candidates that fall flat on their face when asked to do something super simple like a FizzBuzz problem list massive accomplishments on their resumes. Often it seems like they are listing everything the team they worked on accomplished, not what they accomplished.

And the weak candidates frequently list things like "Expert at Spring Framework" or "Expert at J2EE". To be an expert on those things is very rare since they are enormous frameworks. Not many strong candidates will list themselves as experts on giant projects unless they were one of the founders of the project.

He is talking about filtering out developers with good technical skills who have other aspects of their personality/behavior that don't mesh with his business. But the bigger problem seems to be finding people who actually have real technical skills. The things he's worrying about are easier for management to correct/control.

<comment><USER74> Ability to invert a binary tree is not what you actually want to measure, but you can't bluff your way through it, so it's an attractive target to measure, especially at a large company trying to have standardized practices. Professional accomplishments is much closer to what you care about, but you can bluff. But it's still possible to give a good subjective interview. Good interviewers will find a area on someone's resume that they have deep knowledge of and drill deep. It takes longer to sniff out a complete fraud than FizzBuzz, but it can still be an effective approach.

<comment><USER73> Inverting a binary tree is actually something that weak candidates seem to find a way to cheat on though.

Same thing with Fizzbuzz, so it was an artificial example in my post.

The best thing for us seems to be relatively simple coding questions that are domain specific problems.

My go-to the last year or so has been an interview like this:

1) Give a demo of the product

2) Explain a problem the product has/had to solve

3) Go over the entities/objects involved in the problem

4) Present this as a simplified whiteboard problem

5) Candidate needs to write some code on the board to solve the issue (Typical solutions < 20 lines of code)

6) Discuss scalability of the solution

7) Discuss alternate ways to refactor the larger code base to avoid having to write the algorithm that was written on the whiteboard at all

The process of having to take a problem that comes from a specific product & translate that into code seems to catch the weak candidates that cheated on the online coding tests and bluffed the recruiter nearly every time.

This is as opposed to places like Google that just constantly try to ramp up the difficulty of the non real-world coding questions they're asking the interviewee.

</comment></comment></comment><comment><USER75> The software industry's greatest blog post sin: "Hiring in tech is broken"

This topic is trite. Furthermore no one seems to be able to offer up actual tangible suggestions as to how to fix this, or some objective 'better way'.

Disclaimer I work at a FAANG etc company: Also this has been distinctly "not" my experience at many FAANG type companies. Usually these interviews, even the one's I haven't done well in, have been highly conversational, and all contain a fairly in depth 'soft skills' interview as well.

Yes, your technical knowledge has to be good, but a good interview will keep pressing at the edge of your knowledge (not to make you 'fail'), but to see how you handle the unknown.

In fact for one of the companies I ended up working at I was called in for a second soft skills interview just to dig even deeper on the dimension the author claims is 'never tested for'.

Much like these authors I don't have a perfect solution to this, however I will say one of the most rewarding interviews I've ever done (at a well funded startup where I did NOT get the offer was comprised of):

\- 1 Algo question (standard fare)

\- 1 Architecture question (standard fare)

\- 1 'find a bug in this mock part of the codebase / pair program with me' question. Implementation didn't necessarily have to be perfect, mostly was interested in diagnosing the actual problem and talking about 'how' we might solve it (very fun)

\- 1 Product Sense (!) question with actual PMs (very fun)

\- 1 General culture fit / experience interview

<comment><USER76> >Furthermore no one seems to be able to offer up actual tangible suggestions as to how to fix this, or some objective 'better way'.

There are other professions with models of credentials that could be adopted to software given some time and adjustment and faith. Then we could shed our current technical interviews in favor of shorter interviews overall. You naturally need more people to handle interview bandwidth as your company grows.

People want to show some credential and not have to deal with technical interviews at every potential opportunity. We've learned enough about technical interviews that we should be able to make this kind of widely- recognized credential. We just don't want to do it. We'd rather keep recruiters employed and force developers to budget large blocks of interviewing time.

</comment></comment><comment><USER77> There are two camps here that strongly correlate to their opinions: those who have been through a job hunt in the last 5 years, and those who haven't.

</comment><comment><USER78> Being a manager and hirer is very different from being the interviewee. It's great to believe that you could have some innate ability to judge one's empathy and character in a set of interviews but so much of that runs to favor people who can talk well, which is a wholly different skill from being to code well. Saying technical interviews are disguised IQ tests is quite the horse- shit metaphor. I won't dig into all the problems with IQ tests. Certainly some people have innate ability to do well in quantitative tests, but I know so many people who have put in so much work to get so good at what they do against difficulty and belittling their success at interviewing as something inherent like IQ is awful. Getting to that level takes experience. It takes grit. Programming is a highly technical skill, I have worked with people I don't get along with and people I can't talk to comfortably who have written amazing code and when I am reviewing code that is going to be depended upon by millions of people each day I will always merge good code over someone I like personally. Lots of developers also have responsibilities that use empathy and character and leadership and those people you should always hire along that rubric as well, but if what you need is strong technical skill and ability to solve hard problems with code. You have to find someone who can program well; after that you can have a lot of flexibility in how you work with them and what other responsibilities you give them. I think you are off in comparing programmers to white collar professions. Compare them to skilled professions ala crane operators, machinists, or surgeons. If you don't have hard technical problems then you have the luxury of not needing people who are very good technically, so you can have the luxury of rounding out your interview, but if you have programs for which code quality is very important, you should trust someone who can build good software.

</comment><comment><USER43> Would companies make more money if they hired in this "wholistic" way? Every time this comes up, I struggle to see how these top tier companies with these algo-intensive interview practices are compromised by not being "wholistic." They're raking in cash. By all quantitative measures their hiring is working extremely well for them.

</comment><comment><USER79> In my experience the UK is slightly less focused on credentials than the backwards boneheads in the US.

That's the good news.

The bad news is that tech interviews in the UK tend toward the same faux-IQ test mentality.

When are recruiters going to realise that just because you can reduce a person to a HackerRank score, that doesn't inform a good hiring decision?

I've often said the _only_ way to see how someone is going to work out in an office is to hire them and let them work for a month on probation. After a month, if they've demonstrated an ability to talk, to collaborate, and to learn, then keep 'em. If not, cut 'em loose.

 _everything_ else in tech hiring is B.S. I have yet to see an alternative that can't be gamed, that takes in the holistic person.

And _none_ of my jobs have really brought out the best in me. In jobs I've done well, I drove that myself. In jobs I didn't, it usually came down to bad communication (in both directions). Nothing to do with the recruitment _at all_.

<comment><USER54> > When are recruiters going to realise that just because you can reduce a > person to a HackerRank score, that doesn't inform a good hiring decision?

Never. If tech people can't find a way to do it there is no way a non- technical person will be able to. Pretty sure this is why Google has its own recruiters. Your average recruiter has no clue how to grade candidates. For other companies it's probably best to find a way to apply directly.

I recently went through the process and got a job from a direct application. I dealt directly with the tech lead. The process was entirely devoid of BS. We understood each other right from the beginning---perfect clarity. After the little bit of time I spent looking through job ads and dealing with recruiters I am endlessly thankful that I got this job before having had to deal with all that for longer than a couple of weeks. The difference was stark.

</comment></comment><comment><USER80> Whiteboarding sucks. I was asked to do this once or twice, I can't think while others watch because I am focusing on what they are seeing, and my penmanship sucks. It's not for anyone that gets nervous easy. I just don't get it, why not put up a text editor on a wall screen and ask people to write the same code there?

</comment><comment><USER81> Oddly, the more real experience you have diminishes your chance of being hired. You might recall how to 'invert a binary tree' had you recently graduated from college. But since inverting binary trees is an extremely rare need in the real world, you are doomed if you have significant experience.

</comment><comment><USER82> I liked most interviews, but the one that irks me are when the interviewer asks very specific questions that are specific to the particular domain the company is in.

But one of the biggest reason to apply somewhere as a developer is precisely to get to know a problem domain. Money is not the only incentive, by far.

</comment><comment><USER83> I posted this comment yesterday buried in some thread and even though it was buried it still got 37 up votes.

[https://news.ycombinator.com/item?id=22821318](https://news.ycombinator.com/item?id=22821318)

I post a similar comment in this thread and it gets downvoted to user flagged:

[https://news.ycombinator.com/item?id=22831474](https://news.ycombinator.com/item?id=22831474)

Perhaps the largest handicap in developer hiring is bias as evident by the stark contrast in response to these two comments that convey identical sentiments about the same subject with slightly different language and yet receive opposite response.

A company is a absolutely not objective in their candidate selection if developers are the deciding factor in the hiring of other developers.

</comment><comment><USER84> It's weird, I've programmed Everything from Random Forest in VBA to full stack apps to embedded, but I can't get an interview. "Just do projects" they told me.

Maybe I'm asking for too much money? 90k/yr.

I want to switch from Engineering(120k/yr) to programming, but I've been unable.

SE Michigan.

<comment><USER85> 90k a year is totally doable for medium-experience software in principle, but in southeast Michigan I'm much less sure. The salaries are laid out differently.

For those coming into the industry from outside, the real questions may be less about what you're capable of programming, and more about your wisdom in producing code that works well with other code and with the realities of failure. It's hard enough to get a good sense of how much of that wisdom you have even when you _are_ a software engineer...

</comment></comment><comment><USER86> It's often very unclear what you really want out of a candidate, much less how to select for that.

Maybe a workplace wants someone who will conform to corporate culture and cheerlead for the company. Maybe a workplace wants someone who will learn a big stack of internal tools quickly. Maybe a workplace wants someone who will grind out intense hours without complaint. Maybe a workplace wants someone who isn't going to "waste time" paying technical debt and instead just ship an MVP as soon as possible. Maybe a workplace wants someone who learns new skills on their free time tries to incorporate them at work.

Workplaces don't identify or admit what they really want out of a candidate. And they certainly don't have a way for testing against it in interview.

Top tier (read: cash-flush) companies have settled for hiring strategies that effectively select for "yuppies" (I dont mean this in a derogatory way) who are willing to bust their ass and do whatever it takes to overcome any obstacle they are given. This mentality is common among top schools that are already intensely selective and competitive. People with this mentality are much more likely to spend hundreds of hours prepping for tests, such as the leetcode meta today.

Ultimately, while it's very annoying during a job search, I'm thankful for the fucked state of hiring because it means software engineers _aren 't commoditized_.

If we were indistinguishable cogs, and any engineer with N years experience can be replaced by any other engineer with N years experience, that kind of dynamic ultimately results in a strong downward pressure on employee's power and wage. We are closer to a talent dynamic where every engineer is unique and some are much better hires than others. You wouldn't hire an actor just based on their resume. Knowing how many years they've acted or in how many roles isn't enough, you need an audition.

Software engineering is halfway between these extremes, and we should be thankful that we aren't (yet) indistinguishable cogs in the corporate machine.

</comment><comment><USER87> Here is the text from one of the interviewer who clear the fb interview "The second interview was very hard they asked me a leetcode hard question and I was only able to solve it because I did the exact question before. Complete luck there. Personally I think it was unreasonable to expect someone to solve that difficult of a question in 30 minutes. The overall acceptance rate on the question on Leetcode is around 20%." [https://leetcode.com/discuss/interview- question/563659/faceb...](https://leetcode.com/discuss/interview- question/563659/facebook-ml-engineer-santa-monica-pending)

</comment><comment><USER88> >> It's a disguised IQ test

Funny, an IQ test has one of the best correlations with job performance among all hiring methods; one of the few to do better than random chance.

>> Does this person have incredible grit and perseverance? Who cares! Does this person communicate and write well? Who cares! How friendly and amicable is this person? Who cares!

I specifically evaluate all of those things and write them up in the report after a technical interview. I don't know where this person is interviewing, but all of these do matter.

But it doesn't matter how friendly you are if you can't also demonstrate problem solving and coding ability.

Also, what a disaster these threads always are. Depressing.

</comment><comment><USER89> I never understood why companies don't take a slower, ramp up approach for interviewing.

ROUND 1 THE INTERVIEW

Step 1: Interview candidates for 'culture fit'. Chat on the phone, get to know the person a bit, ask questions about what they did before. See if they have a sense of humor, get them to relax. Don't try to trick them, just have a chat.

Step 2: Ask a few 'how do you think questions'. Why are manhole covers round? How many school busses are in New York City, etc. These are questions with no clear answer and missing input data (like real life). Listen to how they work out problems in their head. Then ask fuzzy questions with no clear answer, and relatively high consequences for rightness or wrongness. See how they deal with that. Ask workplace conflict questions and irate coworker questions, see how they respond. Give them all the time they need.

Step 3: At the end of the interview, send them some take home code projects without a time limit. Give them some toy software program and ask them to fix a few reported bugs in it. Then give them a small greenfield project and see how they structure and document their code.

ROUND 2: THE DATING PERIOD

If all of the above goes well; hire them on a 1 month trial basis and see how everyone works together. Maybe they don't like your company? Maybe they smell funny? Maybe you force everyone to do yoga? Maybe they MUST travel with their service chimpanzee? Who knows? Spend a month working together and find out. If either of you see a red flag; shake hands and go your separate ways.

\- - -

My point is this; putting someone through a gauntlet of stressful, random interview questions and whiteboard coding issues makes people stressed and nervous so they do not act like themselves. If the job is a high stress job and it's important to handle a lot of stress; you'll see that during the dating period.

Imagine having to decide if you were going to marry someone based on a few hours of conversation and 'whiteboard coding problems'. It's too much of a commitment with too little information.

Hire people, not machines.

<comment><USER89> One last point on this. The general idea is to see HOW someone thinks. One way to do that is to have them map out and work through a problem on a whiteboard without code. I'm talking boxes and arrows. Ask a question like 'How does (for example) bittorrent work IN GENERAL?'

Have them map out the answer on a whiteboard for _one_ person who knows how bittorrent works and can nudge them along if needed. The idea is to see how well they communicate complex ideas, not how well they have memorized the bittorrent protocol.

</comment></comment><comment><USER90> I think a very important point from this article got lost in this discussion; many engineers aren't aligned with the business and the end users, but instead often needlessly chase new stacks, over engineer the code base, migrate to micro services (prematurely), rewrite an existing codebase in a new hot language instead of just refactoring, needless throwing React/Redux at the problem etc etc. So many times these efforts give zero value to the code base or the product. This type of behaviour seems to go unnoticed since business doesn't understand engineering and has to trust the engineering managers.

</comment><comment><USER91> > neil with data .com

> no data in the article to back up claims

Yet another person who claims that hiring is broken. If this is the case, then show me the company that is not using technical interviews, and demonstrate to me that all these other companies are failing to hiring the best people for the job.

The closest they get to evidence of their claim is that Google didn't hire 1 random guy 4 years ago. Oh, and that Google built Stadia (??? huh ???).

Did I just read an anti-Google blogpost disguised as an anti-interview blogpost? What does Stadia have to do with interviews?

</comment><comment><USER92> I did on a onsite at Google and learned the most during the lunch portion, my interviewers didn't know basic ES6. At lunch, I talked with an engineer who was a teacher before his first industry job at Google which he has worked for 5 years, in contrast with me that had work at 4 different places in 5 years. I didn't get the job even though my github and industry skills were more vast. They would rather hire "theory over practice" developers because they are easier to retain, which is fair.

</comment><comment><USER93> The worst part about hiring is once you're into the "elite circles" it becomes less work. Work for a FAANG? Getting a much becomes far easier and sometimes with less difficult questions.

Whether you agree with the IQ test or not, it's not even a level playing field or merit based. It's about an elite club keeping things elite.

Half the engineers working for FB, Google etc would not get hired today. Yet they still ask questions that they would not be able to answer as a form of gate keeping.

<comment><USER94> >Half the engineers working for FB, Google etc would not get hired today.

I thought people jump around a lot these days.

<comment><USER95> That doesn't invalidate the idea that half, or some other portion, don't.

<comment><USER94> don't =/= can't.

</comment></comment></comment></comment><comment><USER96> Nice insight. Recently posted my take after jumping into the industry head first after going it independently for decades....

[https://www.linkedin.com/pulse/let-me-open-you- adam-m](https://www.linkedin.com/pulse/let-me-open-you-adam-m)

[https://news.ycombinator.com/item?id=22820905](https://news.ycombinator.com/item?id=22820905)

</comment><comment><USER97> "Your interviews are hurting my ego." "How did they hire that guy? He can't code his way out of a paper bag!"

We (me included) protect our egos like our lives depend on it. Very few people have the balls to just admit the interview went terrible because of themselves, it's always the person on the other sides (interviewer OR interviewee) fault.

</comment><comment><USER98> I did love the way eBay did hiring with 360 interviews. I interviewed my future boss and recommended that she should be hired.

</comment><comment><USER99> I wrote about a better way to hire people: [https://jonpauluritis.com/a-better-way-to-hire- people](https://jonpauluritis.com/a-better-way-to-hire-people)

It works remarkably well if you're flexible enough to follow it.

</comment><comment><USER100> Nothing will ever beat a trial. It's more expensive, but it's clear shortcuts just don't work that well. Give people a chance to work with you and then you both can make a well informed decision about how the situation is likely to play out.

</comment><comment><USER101> some frustrating parts for me:

1\. if i got an offer from your company a year ago, why do i need to redo the phone screen and entire process?

2\. if someone has 10 years of experience at google and is L6, why do they need to do the standard process to work at some rinky startup?

<comment><USER102> The reason for (2) may be the following: can the company verify that the candidate did in fact work at Google for 10 years and reached L6? I don't know about Google, but if someone claims they worked at Microsoft as an L65, and they call Microsoft to fact-check, Microsoft will only tell them when that person started and ended their employment there. They will not disclose any other information.

</comment></comment><comment><USER103> The best way I see it, is to have this guy to work for a while, say a few weeks or a few months as a contractor, then either ends it or converts to a permanent job. This is the best interview approach.

<comment><USER104> Honestly that would filter out basically anyone senior, and anyone who could get an actual job elsewhere. Given the choice of going through a normal tech interview process before leaving my current job, or leaving my job for this, why on earth would I pick this?

</comment></comment><comment> loup-vaillant > _Almost no other "white collar" profession I'm aware of will so completely > and thoroughly ignore your actual proven ability, historical > accomplishments, and holistic qualities, as part of the hiring process._

Perhaps that's because programmer is _not_ a white collar profession? Those who don't manage other programmers are naturally at the bottom of the hierarchy, just like a machinist (clearly a blue collar profession, though I would certainly show proper deference to them before I even dare approach a machine).

Never mind how useful, or how skilled, people at the bottom are. They're at the bottom, and that alone probably affects how they are treated. The hiring process is just an effect of this.

<comment><USER104> "White collar" doesn't normally exclusively mean managerial, it means 'professional' in a kind of poorly-defined, rather obsolete, classist way. A "you know it when you see it" thing. For instance, a doctor is white collar (but probably not a manager). So's an accountant, or an engineer; again, they're mostly not managers.

<comment> loup-vaillant How about a cordwainer? Many are highly qualified professionals, and I bet they're "blue collar" all the same. They're working with their hands making shoes after all. I think this "white/blue" distinction blinds us somewhat. What really matters is how others (in particular those who have power over us) perceive us.

As for being a profession, relatively few programmers are independent. Most work under a boss, with the same hierarchical constraints as a factory worker. We're not organised as a profession. I dare say we _aren 't_ a profession just yet. Our trade is too young for us to have achieved good average competence (doubling our numbers doesn't help, and is an indication that there's no selection pressure yet).

The only thing that makes us "white collar" is that we work in clean environment, without physical exertion.

<comment><USER104> > How about a cordwainer? Many are highly qualified professionals, and I bet > they're "blue collar" all the same.

Yup. That's largely where we get into the classism thing. "White collar" doesn't say anything in particular about skill or earnings (or even education, necessarily; you don't need a degree to be white collar); it's a class signifier.

> As for being a profession, relatively few programmers are independent. Most > work under a boss, with the same hierarchical constraints as a factory > worker.

Same goes for doctors (in most countries), accountants, etc. And of course, a middle-manager is white collar. While collar doesn't necessarily mean self- employed/company owner/bourgeois. It's more complicated than that.

</comment></comment></comment></comment><comment> globular-toast > It's a disguised IQ test.

No. It also tests knowledge and familiarity with whatever technology is required. But yes, of course it tests IQ. What else is important? The way you look? The way you speak? Your background? I don't care about any of that. If you can express yourself in a technical context then you automatically satisfy all other requirements.

I like technical interviews. They remove bias. It means someone isn't going to get the job just because I "like" them or, worse, I want to fornicate with them. I've hired people of all ages, races, and other "identities" thanks to the technical interview.

</comment><comment><USER105> Tossing my 2c in the ring, this is how I usually hire new dudes[1]:

\- Ask the existing team for a set of dude recommendations, and the reasons.

\- Track down a set of dudes myself. Usually from publications, open source, or previous products.

\- Discuss with the dudes regarding the greater project target, team, goals, initial tasks, scheduling. Ask the dudes for other dudes they can recommend, and why.

\- From here on I pay the dudes for their time and effort during recruitment, always:

\- Have the dudes look at previous problems and solutions, if available, and ask for feedback.

\- Have the dudes spend time with existing team on current work and ideas. When populating entire teams I have dudes work with each other. I especially look for people who are freely sharing even with people they are (technically) in competition with.

\- I always followup on my initial predictions over time, to see where I'm right or wrong, and what to look for in the future.

I often hire scientists or other people who do a lot of work out in the open. It's just so much easier to quickly get a feel for peoples' output by looking at, and discussing, previous work. And most of my projects require bleeding edge specialists.

I advertise <25% of my positions (guesstimate). This is a failing on my part. I have no magic lens to read CVs, so they carry no additional information value for me.

Hiring is expensive and often takes a long time, but hiring the wrong people is much worse.

Throughout my projects I have only had one person leave, and that was for a once in a lifetime offer. I very rarely need to fire anyone.

I would rather hire two excellent dudes than five good dudes. So I tend to have the budget to pay good rates. Then I call up temporary manpower to solve the more mundane tasks so I can keep my excellent people on the more difficult and interesting items.

Red flags I look for when I'm on the other side of the table:

\- Who is doing the hiring? Some checkbox HR drone, the owners/investors, or the actual team?

\- Hiring evaluation tools. Have they actually bothered to read up on the latest few decades of research, or are they just following dogmatic trends? Do they even track their own prediction skills when hiring?

\- What is their understanding of the project, tasks, etc?

\- Do they respect my time investment?

1) a "dude" is gender and ageless, of no persuasion, has neither skin nor eye colour, and so on.

<comment><USER106> > 1) a "dude" is gender and ageless, of no persuasion, has neither skin nor > eye colour, and so on.

In that case, s/dude/person/g

Language affects thought, right?

<comment><USER105> Very true, my deviance. But words change meaning and connotations over time. For me "dude" is a blank placeholder. I should of course take more care to see my text from the eyes and mind of the target reader.

IIRC the 2004 bsg called everyone "sir" regardless of gender. I remember that nudged me the first and second time I heard it, but then it was just second nature. It had lost it's (for me) implied gender.

</comment></comment></comment><comment><USER107> Leonardo da Vinci means Leonardo from Vinci. Trivia is not always useful but is an indicator of curiosity.

</comment><comment><USER108> A week on HN wouldn't be complete without the traditional "hiring is broken" blog post.

</comment><comment><USER109> I'm not a technical interviewer specialist, I'm a developer who has in the past given interviews.

Other than filtering out chancers with a lack of required basic skills, one thing that's always bothered me is how my own personal Dunning-Kruger effect alters the interview process.

I obviously only ask questions I think I know the answers to otherwise how would I know if they were correctly answered?. So that may mean I miss out on candidates with a range of skills I lack and can't detect in interviews.

Interviewing successfully, I suspect, is a "difficult" problem if you take it really seriously.

Like those pointless "skills matrixes" that inexperienced managers like to set up for their teams. I mean you can ask me my skill level for a particular subject matter but how can I answer you with any accuracy if I don't know what I don't know?

</comment><comment><USER110> "disguised IQ test"

If only. It's more like a Wonderlic Test.

</comment><comment><USER111> I feel similarly as the author but I'm starting to take a more balanced approach to all of this and it's helping me put things into perspective. I'll play the game because I'm not sure what other choice I have. I don't enjoy my current job and in order to get the jobs I want with the people I want to work with this is the price. That being said, it's absurd we have to do this EVERY DAMN TIME. Even moving between FAANG requires you to do this. That in and of itself is a clear indication of how bad of a signal this interview process is. Reviewing reddit and team blind and HN (as this is the best data that I have), it seems many folks working at a big tech company still need to leetcode to move to another big tech company despite already passing the bar at one! If that isn't a clear indication of the type of information these interviews provide I don't know what other evidence we need.

And here is the real crux of the whole thing. Considering how standard it is, we might as well just make it a part of a software developer certification/license that you have to do once to break into the industry. The funny thing is, despite our best efforts to not become a real standard profession we are behaving a lot like one, except we don't realize it and keep making candidates jump through the same hoops repeatedly.

Now many of you will balk at the prospect of standardizing but hear me out. Are we really that different from any other profession? At the end of the day most CS curriculums are very much the same. Why can't we do standardized tests to "pass the bar" so to speak? And additional certifications can be taken for specialties (e.g. ML, Cyber Security, Finance etc.) like in many other engineering professions or like specializing in medicine.

Yes, knowing algorithms and data structures IS imporant to being a good software developer, even if you are building CRUD or mobile apps. But, how many times to do I need to prove I know them? Yes, showing leadership skills IS important to being a good software developer. But isn't being a leader mostly about conflict management, moral obligation and being ethical?

Maybe we can stop fearing becoming a real profession that is beholden to standards and public scrutiny and embrace it. It will end up being better for everyone.

For juniors (not in age, but in experience), it offers a consistent predictable way to learn and grow, and a set of criteria they can focus on learning to land junior positions. From there we can treat them like apprentices, and to get certification you need to spend x number of years being supervised. This allows companies to also retain their junior talent for longer and their investment in their training can pay off in the long run because even if they lose a junior who's now certified, they can hire a recently certified intermediate from another company!

For seniors, it means we can focus on demonstrating why we are seniors (i.e. I've built these systems, led these projects, etc.), and offers a real honest predictable path to becoming a staff or principal (i.e. a master).

For companies, it means they can focus on hiring PEOPLE, not leetcoding machines. They shouldn't have to worry about assessing the technical skills of individuals. The only reason they do so is because they feel they have to. If they had confidence that the people they are interviewing are likely qualified as it is, then they can actually focus their time and effort on more important things to assess such as if a person is a good fit for the mission. People assume companies do this because they want to haze candidates. The reality is, companies just don't have any better way of de-risking their hires at this time.

We can revisit the criteria regularly to make sure the tests we need to pass represent what it means to be do our jobs and do them well. We can have industry input, academic input and so on. We can even have the professional body accredit programs so as not to have candidates waste their time and to ensure academic programs keep up with the advances industry makes. Further, we can make this a global thing.

Rather than shunning becoming a true profession, let's learn from the mistakes of other professions and build a process that helps everyone.

</comment><comment><USER112> Just adding on the post. I used to work for big tech companies, I interviewed for some and also I had the pleasure of interviewing candidates. I mostly interviewed for security related roles but at some stage, I had constantly positive feedback from the candidate so I was thrown in to interview candidates for other roles as well.

I agree with the article, and had my fair share of bad apples so my thoughts here. Unless the role was something that required dealing with incidents, there was no point on doing a technical interview onsite and seeing how the candidate reacts under stress. Generally, noone cares how well a candidate performs under stress. Instead, I'd let them deal with technical problems on their own time, if they wanted and tell them to spend no more than 2 days (I'd actually kill the instance to ensure that). For security positions, I ended up building a CTF platform and told them to solve as many challenges as they wish and send back a report.

For the onsite interviews, we did mostly cultural interviews. There was a bit of technical questions involved, mostly open-ended questions to see how they approached a problem. This usually was to design some system or, given a tiny codebase, how they'd go implementing a feature. Also, I did what we ended up naming "spirals". Successive questions, increasing in difficulty to see how much in depth they went during their research. E.g. Traceroute -> Ping -> ICMP -> Differences in Linux vs Windows. This had two benefits. It was clear how much in depth they would go and two, it was almost guaranteed that at some point they wouldn't know the answer, which is fine, but forces them to explain how they would go to find the answer. Almost always, I'd tell them whether they were on the right path and if they were stuck kinda help them. I'd give about 5-10 minutes for the candidate to ask me anything. Literally, anything. For me, this was important because I would get a sense for how candidates evaluated the company and what they were interested in.

Beyond that, at some stage, we added some questions called internally the "I read it on the internet". The questions were pretty straightforward, e.g. given a terminal, tell me how would you ssh in this box as XYZ user or how would you rm a directory. Fun fact. I initially made fun of the operations guys asking those questions until I interviewed a series of people where noone knew how to do simple stuff with their terminals. Btw, I didn't focus at all on technologies. Given the size of the company, asking "How much you know about $LANGUAGE" would be futile. I wanted to hire people who could pick up new technologies and, given the size of the company most of the tools were custom-built or heavily modified. It was pointless asking "$LANGUAGE" and then telling them "Well, great, just keep in mind we don't actually use exactly $LANGUAGE but rather our own version of it". Last, and probably the most important. I asked myself how I wanted to be treated during an interview. I kept in mind that I generally wanted to be treated with dignity and respect, I kept in mind that the resume is basically a snapshot of someone's life and the candidate is a human being and acted accordingly. Also, I valued for candidates who asked for feedback and actually I'd give them some and tell them stuff to read reg. things I felt they could do better. Btw, I also assumed that each candidate would get an offer and I didn't want them coming in and thinking "That's the idiot that was acting cocky during the interview".

</comment><comment><USER31> I had a candidate totally fail the algorithm interview. Is a binary tree balanced? I thumbs downed him.

I was overruled and he was hired based off of his credentials, resume and what he talked about in the interview with another person who just had a talk about "architecture."

Turns out the guy can't even code. He constantly just talks about architecture and tries to tell everyone to completely change the architecture to be event driven. But when given an assignment to work on the actual product he totally fails. It's crazy, the man is a complete clown.

Here's what I think. You can't hire a candidate based off of just a technical interview alone. But you can't just hire a candidate off of his credentials either. There's too much room for lies and deception in this area. You need both metrics in order to get the most information out of a candidate. It goes both ways.

The Technical Interview was invented because of too much of the above problem. People who are charismatic and exaggerate their resume and turn out not being able to code. Of course nowadays with canned memorization going rampant and technical interviews becoming IQ tests there's really no accurate way measuring a candidate.

I'll just say that as bad as an IQ test is in identifying good programmers who are bad at IQ tests, a person with high IQ is likely going to be a good programmer.

</comment><comment> non-entity That "bad hires" section describes a lot of people I've know and worked with and tbh, I kind of feel sorry for them. They're often incredibly intelligent people that want to apply themselves. We hired this one guy who constantly attempts to re-architect and rewrite various systems on his own, just to have his works rejected.

At the same time, some of these guys are seniors. How on earth have you been in the industry for this long and not grasped what your job is?

<comment><USER113> I think in this field, it's not at all guaranteed that years worked means better. For some people, they grow a mountain in a year. For others, barely at all.

Honestly I agree with your pain because the above situation is also not completely tied to how much you care. Luckily though, most of the time it is.

</comment></comment><comment><USER114> The interview question that best exemplifies what Neil wrote is, "Did you write it yourself, or as part of a team?"

Both answers are wrong, depending on the interviewer.

If you say "yourself", you're admitting you're a lone wolf. If you say "team", then you were along for the ride, even if only two people were on the team.

<comment><USER115> I mean a candidate should be able to distinguish their contribution to a project in some more fine grained way than this. If they come from freelance and say "I wrote the code on my own" that's fine but maybe you could mention how you communicated with the client to establish requirements and milestones and get to a successful delivery.

If you worked in a team you should be even more able to explain your individual contribution & the context in which you worked.

This is not a trick question. A good answer is "I did x, y, and z tasks, which required a, b, and c interactions with the world around me to make sure I was doing the right work and meeting expectations".

<comment><USER116> I once failed this question at a FAANG company. We were talking about a recent project that my company did with Pivotal. So like every project Pivotal does, we spent about one day a week dividing up the upcoming work into tiny pieces, then we spent the other four days pair programming by doing whatever the top task on the backlog was. Predictibly, on a team that had 3 pairs, this means I or my pair did about 1/3 of all things, distributed somewhat uniformly throughout the project.

"What parts are you solely responsible for?" 0 things, the same as everyone else who worked on this project! Wrong answer though.

</comment></comment></comment><comment><USER117> If you were to go in to an interview for a welding gig you would likely be asked to produce something simple like a cube or other basic shape. Nothing extravagant, but it demonstrates competency with the tools, materials, and techniques. I have tried very hard to replicate this in our hiring process. But the sad reality is that many applicants cannot code to the level suggested by their resume.

</comment><comment><USER118> Literally any single person can aspire to be a Software Engineer at a major tech company by studying online, on their own, with resources that are either free or modestly expensive.

I disagree that it is a broken process. I do not want the software world to also start selecting for non-hard-work metrics like who your parents were.

<comment><USER119> You can work hard at things other than leetcode though, like actual jobs, personal projects, or learning tech in your field (web frameworks, programming languages, whatever).

</comment></comment><comment><USER120> "I failed my technical interview, so here's a blog post".

Software is one of the very few industries where lying on your resume and lying through your teeth about your prior accomplishments can be very easily tested.

</comment><comment><USER121> Agree with all points made. Especially with the first point (engineer hiring tends to be one dimensional) as well as the "your company is who you hire" point - and even the google example given for that point. Google is great at software. No one writes better software than google hands down, but what you/they learn is that it's not always about how good you code (else GCP would be the #1 cloud platform). Great write up

<comment><USER122> "No one writes better software than google hands down"

When was the last time you worked within Google?

</comment></comment><comment><USER123> People who hire developers wouldn't be as focused on the candidates' experience with the technology in the job ad if developers were typically more open for new tech that would be learnt at the job. Try to teach a 40+ Perl developer a new language if you want to see what I mean...

When you compare IT with other industries like the author did, this is what makes hiring so different. Other industries are fine with hiring graduates with no specific experience and the candidates are eager to learn on the job. Whereas in IT, half the people will tell you "can't do this", "don't like that", "won't learn Java" ...

<comment><USER124> I'm almost 40. I can learn new programming languages just fine, thank you. And new languages/tech generally aren't too hard to pick up once you've learned a few, for the most part.

They do a lot of the same things, just the incantations are different.

I do have more non-coding hobbies now and other responsibilities sucking up more time than when I was young, so I don't have as much time to learn them on my own, but I still can and do learn them, especially if needed at work.

<comment><USER125> Thanks for that. Necessity is is me chopping wood for 8 hours. Everything else is enjoying the fire.</comment></comment></comment>