I've just interviewed for Google and Meta. In total I went through 8 individual coding interviews.

With an exception of one, which was a bit too much like a puzzle, I think the assignments were completely fair examples of what I might experience on daily basis. Not at all tailored to people doing competition style programming, which was what I expected after being exposed to HN for years.

I have to say I enjoyed both preparing for the interview as well as the interviews themselves. And I believe that overall the interviewers were able to grasp how I would code.

If you have to prepare for the interview, doesn't that suggest the assessment isn't representative of day-to-day programming skills? In fact, it suggests the exact opposite.

With zero preparation, I could go to an interview with you right now and tell you anything you wanted to know about designing a database schema, how to get any kind of data out of that schema, how to make that data available via an API, how to cache the data and perform permissions checks, how to deploy code to a cloud environment, how to set up a build pipeline, or any other question you might want to ask about the day-to-day process of developing and deploying web applications. I can answer those questions because I already work in the industry and I broadly know what I'm doing.

However, I probably couldn't pass a FAANG interview without months of prep work, precisely because whiteboard interviews bear almost no resemblance to the reality of software development.

The items you list may not be as universal in software development as you seem to think they are. There are plenty of highly competent programmers who haven’t thought about designing a database schema in many years, or who have never deployed code to a cloud environment (at least not in the way you have in mind).

Having a set of common knowledge to interview about is in fact very useful.

Interviewing is assessing how a person would perform, not an actual day to day collaboration. There is a gap. You do not talk like you would to a colleague. You have a limited time and it's more one-sided to even the playing field. It's worth preparing for to overcome the gap.

It's like a dance. Your are supposed to lead deriving the solution, interviewer is supposed to follow closely and judge your performance.

If you expect to ace an interview just like that then you also need to be lucky not accidentally getting asked to stuff, which you always need to Google an answer to, basic algorithms and patterns, which you usually kind of know but could slow you down during the precious 40 minutes you have to show off your skills.

And lastly, people do prepare for these. If you do not do that, you might simply make a slightly worse impression than someone who did.

That being said, I mostly did not prepare for the coding interviews. I focused on the design and behavioral interviews.

I would never change the way I speak to someone just because they're interviewing me. If you're interviewing me it's with a view to working with me on your team a few months later. You would surely want to see the real me, not some constrained version. Maybe it's an age thing, but I'm comfortable enough with my skills and my knowledge that I don't feel the need to put on an act. And remember that you're interviewing the interviewers as much as they're interviewing you.

Also, I would also be quite surprised if Google didn't allow candidates to Google information during the interview...

> Also, I would also be quite surprised if Google didn't allow candidates to Google information during the interview

I did a Google onsite several years ago (probably 7 or 8 years ago at this point). Each interview was just me in a room with a whiteboard and a person sitting at a table across from me with a notepad. No computer present.

I suppose I could have dug out my phone and Googled, but that feels unprofessional to me, moreso than if I had access to a computer.

Also the part I got stuck on was coming up with the trick needed to solve the problems. Most I was fine, but one in particular would have taken some decent searching to find something equivalent if I just Googled, and would have taken some time to grok the answer. Also that guy was not very forthcoming with hints or information when I asked him, so I doubt he'd have appreciated a Google search.

I don't remember the exact question, but it had to do with converting a 3D city model into a 2D skyline by drawing a single line. I got stuck on trying to visualize how to deal with partial overlapping models and irregular building shapes and ran out of time.

Did you pass the interview?

I did not, no.

Their loss. Better luck next time!

I might not have been clear. It's not an act. You are not usually guiding your peer trough your thought process our loud step by step. That's inefficient. Yet that is what you should do to maximize the amount of information passed onto the interviewer. It's just a different setup to which most people need to adjust to.

You just described a CRUD app.

At FAANG, most people are not doing any of these things. Think of people working on EC2, Ads or Maps.

I only worked at multiple FAANG and I never had to design a database schema or make data available via API.

Google publishes many APIs. I know, because we consume them. My company in turn publishes APIs that are consumed by other companies. You're probably right that most people working at FAANG are not allowed to touch a database or set up deployments, however.

As a sibling commenter pointed out, you just described a CRUD app. Web/mobile applications.

It's not hard to do those.

And I suppose for most business cases out there, writing data to the DB and reading it back later is all it takes.

However, there's plenty of other problems where the skillset you mentioned falls short.

For instance, you talked about designing a database schema. Do you know how to design and build a database itself from the ground up? What if that DB has to be distributed, with thousands of writers? How do you ensure consistency and consensus? (These are all solved problems).

Think about Linux kernel developers. Do you think DB schema design is an especially relevant skill for them to have?

Can you come up with a compiler, or your own programming language?

Try building your own text editor, with features like syntax highlighting, undo/redo etc (it takes clever algorithms).

I'm not claiming I can do all of that; just mentioning that the whole scene is much more interesting beyond the horizon.

I once worked on a system that included a SQL-ish interpreter (starting from an ANTLR-based parser and all the way to distributed plan execution). I don't remember discussing it in interviews in the last five years. Even at places such as Dremio or Imply. In all fairness, I _once_ got an offer when one interview in the process included sketching an ANTLR grammar for a calculator in a plain text editor.

As someone who has done the interview rounds at FAANG and many dozens of other companies in SV - you either work in algorithmic work or got lucky with your questions.

The questions that are asked have little to no basis in my daily work as an engineer. Same is true for the hundreds of other engineers I’ve worked with who have gone through the same hoops that I have.

Interesting. Might have been just lucky.

> I think the assignments were completely fair examples of what I might experience on daily basis.

In my experience, you have a lot more than an hour to do it in the real job. And while perhaps 1% of SW folks will deal with in on a daily basis, most will not. I certainly have gone years without needing to use graph algorithms (including even DFS/BFS). And I've needed a BST only once in a decade - and I didn't need to code it, just needed to understand the data structure and complexity to know that "binary_search" in C++ was a superior option than using a map for my use case (even though the complexity is the same).

Some context: At work I recently solved a problem where I had to build a graph (DAG), and do some queries on it mildly efficiently[1]. I did it quickly thanks to wasting time on Leetcode, but no one knew how quick, and people were impressed that I "got it done in less than a day". The reality in most SW work is that whether it takes you a day or an hour to solve this problem, the overall rate of progress will not be impacted.

[1] Mildly efficiently because for the first POC pass, I didn't memoize, and then I got lazy and decided I'd optimize it only after getting a real world data set and seeing if it was slow. It wasn't, even for a decently large data set. The reason? Business logic dictated that the max distance between two nodes did not exceed 8, so from a complexity stand point, you're not increasing the work N-fold by not memoizing, but it's just changing the constant factor.

Somehow, I suspect that in half of the FAANG interviews, had I coded this and argued that the complexity didn't change, I would not get a pass.[2]

[2] Not trying to be cynical: I did argue this for a different problem in a Google phone screen - I had been asked to write some code + data structures to handle an Manager/Report relationship, and the interviewer pointed out my data structure was less than optimal. I countered with "In most companies, the number of employees a manager has under him/her is usually bounded by a small number." Surprisingly, the interviewer gave in.

This comment reminds me of a comic with two vultures who question Mr. Mouse’s claims about the Owl being a predator. It’s not like he ever bothered them. See here: https://twitter.com/nathanwpyle/status/999294987195035649

I appreciate the reference.

But, I don't think those are vultures. They are bald eagles. I'm not sure if owls scavenge, but I do know they primarily hunt. Eagles both hunt and scavenge. Vultures primarily scavenge.

The comic could definitely use some annotations :)

Yeah. I might be generalizing a bit, even though I made sure to emphasize that it is my isolated experience.

On the other hand I felt like a sample of 8 different interviewers from different offices and backgrounds felt representative. If it is true that the interviews are overwhelmingly negatively received, what is the probability that I would get more than half of reasonable interviews? Let alone 7/8.

You're overlooking the fact that you're just one person. Each one of us reacts differently under such conditions and only a minority (which is likely small) happen to excel at this.

The interactions and power dynamics between people differ wildly from person to person. While an interviewer might be the kindest person in the world for candidate A, they might be a total bully for candidate B. I was bullied constantly throughout school snd, whatever cues prompted those kids to pick on me are probably still there, but adults are a bit more subtle, because they can hurt you in other ways. And this is on top of the day-to-day variations, because they might be hungry and the current interview is sitting between them and lunch or maybe they just got slapped down by their boss and want to punch someone or whatever. Based on my own experience, out of the typical 5 rounds of in-person interviews that I went through many times for FAANG companies, one or two ended up being a total shitshow each time, where the interviewer was condescending at best and I don't think they realised it or cared. I was told several times "how easy / trivial" the problem is and that "they're sure I'll have an easy time solving it based on my CV". Maybe the worst ones are when the interviewer smirks at me when they spot dome issue and I can't cope with that.

Now add to this a long streak of never ever getting an offer after dozens of such interviews in spite of putting myself through training sessions and mock interviews over and over. I'm sure I'd get in eventually, if I just kept trying, but do I want a job where I'll be asked to interview people in a similar manner? Even if I refuse to interview people as part of my job, will I really thrive in there? I'm certain this process permeates in one form or another throughout the company culture in various internal management, decisionmaking and promotion processes, but that's a separate discussion.

> Even if I refuse to interview people as part of my job, will I really thrive in there? I'm certain this process permeates in one form or another throughout the company culture in various internal management, decisionmaking and promotion processes, but that's a separate discussion.

Are you sure you want to work at a FAANG company? You sure you would be happy? What motivates you to try so hard?

Bingo! I now know I don't, but it took me years to come to this conclusion. When I started this career, everyone around was telling me that getting into one of these companies will lead to meaningful and challenging work which is complete nonsense. I now know that a large number of people who join these companies are unable to find any meaningful work there.

Anyhow, several years ago, I added a disclaimer to my public profile on LinkedIn which states that I refuse any form of live / timed coding assessments during interviews and I'm not going to make any exceptions on it.

> preparing for the interview

Not sure what is wrong with preparing for a challenging interview. What is the point you are making?

To add some thought to this.

The interview results need to be reasonably repeatable and comparable to assess interviewer skew and bias.

The result is that the interviews themselves inevitably end up being somewhat predicable. And what is predicable you can prepare for, giving you predictably better results.

If you are top 0.1%, sure you will nail them without much prep, but most of the candidates would spend some time preparing.

You mentioned that it is not about Competitive Programming/leetcode stuff but a daily real world work. So how do you prepare? Just continue doing your daily work?

You prepare by making sure all your bases are covered. In my daily work discussions, for example, I tend to be very hand-wavy about concurrency, calling everything “locks” and hoping people understand that I can dig down into the details when needed. When I’m interviewing I don’t want to just hope, so I review my concurrency primitives to try and make sure I won’t put my foot in my mouth.

The fact that people prepare for an interview doesn't say per se it's a failed model.

What type of questions were there?

> I've just interviewed for Google and Meta. In total I went through 8 individual coding interviews.

Curious, were there any questions about what you think of their company ethics, and if you have a problem with it?

Congratulations, there is no chance in hell I would put myself through that.

Well. I definitely underperformed at Meta. Google went great IMO with a few stumbles here and there. No feedback yet. Wish me luck.

One thing to realize is that interviews are a two-way street. Do you think you want to work with the interviewers? Do you like the interview process? If the interview process is poor, what other kind of hiring decisions is the company making? Are you going to want to work with the people they end up hiring?

You learn a bit about the company during the interview, and if that bit is bad, then move on. If they ask shitty leetcode questions and the interviewers are hostile or hung up on unimportant details - move on to another company.

The problem is when a significant number of companies all cargo cult the same process- that way you can’t even write them off as a one-off bad place.

Do they cargo cult the same process? I do see similarities in the interview process, so maybe that's somewhat true, but in my experience there's a ton of variety. Different companies have different formats, different questions, focus on different aspects of my responses, and I'm sure make hiring decisions wildly differently.

Some places have phone screens, and some don't. One company gave an easy leetcode problem as part of the phone screen, while in another case, one person actually spoke characters over the phone to me ("LinkedList", "left angle bracket", "String", "right angle bracket"). Some give take home questions. Some do a code review interview. Some dig into my resume during an interview, and some don't. Some companies had multiple interview sessions where I was asked the same question about my resume in each session by different people (wasting time). And so on.

So in general, I can and have passed over companies based on their hiring process.

I’ve interviewed at hundreds of places all within SV - I can say quite confidently that they’re almost all the same. There are some minor variations but they’re almost all completely forgettable by the end of the day. If they have something truly novel - it’s usually very off putting and requires intense amounts of unpaid labor… which you can’t take with you to other interviews.

The variations you’re talking about are quite minute. Whether someone asks you about your resume or asks you about your most technically challenging project is all relatively mundane stuff.

You can still write off cargo-culting companies who cargo-cult bad processes off. I give you permission.

Every company cargo-cults or should we say - follows best practices or industry wide processes - in something.

No company has thought through every little bit of their system and processes because no company has the time to be completely original, just like no human idea only has ideas that they thought up themselves instead of borrowing a bunch of ideas from school, books, and overheard conversation because they sound right.

It is better to not know and explore than adopt a bad process because you overheard it in a coffee shop.

It's ok to not have an answer.

You have personally used at least one tool, language, or framework without reading its code or understanding it beyond a surface level. You've done this because some text on some website claims it gets the job done. And you probably do this every day (e.g. your OS, your phone, your microwave).

People cargo cult because there isn't enough time to exhaustively research every topic from scratch. Civilization exists because we blindly trust whatever methods seem to work, and then iterate on them.

I'm going to put the definition of cargo culting here since we seem to have lost it:

> Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Some examples are adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a programming paradigm, or adding deletion code for objects that garbage collection automatically collects.

Installing an app from the store is not cargo culting. Playing with a new framework is not cargo culting. Trying a new order at the donut shop is not cargo culting.

several points, I agree installing an app is not cargo culting, however following the same interview process as many other companies do is not 'cargo cult programming' while I would agree it is cargo culting of a sort.

the problem really is that results for interview process does not seem to reliably add up to anything, there are no reasons behind any interview methodology in the traditional cargo culting sense because there is no interview methodology really founded on reason, it's mumbo jumbo all the way down.

But back to my original point some posts up, everybody has at some point taken something on faith as a best practice that works without understanding why.

Some examples where cargo cult programming are concerned are adding unnecessary comments to self-explanatory code - but how about also one I've had requesting the removal of explanatory comments from code because the code should explain itself (comment was something like, have done it this way instead of what might seem like the more reasonable way ..example code.. because of a bug in Safari that means X happens, etc. etc, if you want to removal or change to better method please check that Safari works now and this place actually wanted it removed because they preferred not to have comments in code!)

Or how about this one which I am old enough to have done: putting your script tags in the head of the document because this was a best practice (before async and defer attributes, I'm talking 1999-2000 here)

Hell many of the best practices around CSS usage have depending on the year been the exact opposite of some other earlier best practice. And many frontend developers do it because they don't have the time or evidently the inclination to really learn CSS.

Hey, many best practices regarding CSS at various times are based around the fact that frontend developers don't want to learn to use it.

Now you might say those are not really examples of cargo culting, but I think they are somewhat close - if you are using a naming convention to avoid learning how something works then you don't really know why you are using the naming convention because the purpose of that convention is to keep you from that knowledge.

anyway getting off track here, I just think that saying you are not going to work at a place that has cargo culted its interview process does not tell you anything about the overall quality of the place, because everyone has cargo culted something, just like many fine developers when setting up their React projects have said oh, everyone uses Webpack we'll do that as our build process - they know they need a build, but why Webpack? They don't really know (me neither, every time I've ever encountered Webpack I've always ended up wondering why!? Generally the answer is because that's what the tutorials had, everyone used it, they didn't give any thought, but now we're stuck with it)

A simple test: Do they hire like Google but manage their programmers like a sweatshop (ie Scrum)? Then they are just cargo culting. Companies like Google at least gives its engineers a lot of responsibility and freedom you'd never get in an Agile shop.

a) plenty of agile shops give you more freedom than Google does. Following Agile methodology really doesn't mean what you think it means; and b) please don't casually "ie sweatshops" when talking about something that is clearly not that.

Do your developers have to work in 2 week sprints and forced to work on tasks split into sub 1-day part so they never have any real autonomy? Then you aren't giving your developers more freedom than Google. And if you aren't working like that then you aren't doing Scrum.

Google gives even junior developers multi month projects to own, manage and complete. No Scrum shop gives developers that level of autonomy, not even to senior developers.

So to me the time I've spent working on Scrum projects feels like a sweatshop compared to how I could plan and structure development at Google. At Google I am free to collaborate with stakeholders, build prototypes and get feedback etc, as I see fit to complete the project. Or not do it when I don't feel it is needed, the important part isn't how I run the project but that I run it well. If you don't give your developers that level of autonomy then I'm not sure why you'd care much about developer competence at all. (I quit Google a few years ago though due to how the company was changing, but I'll never join a Scrum development team again)

"And if you aren't working like that then you aren't doing Scrum"

I kindly disagree. You seem to have worked at a very stressfull place. In my experience that has nothing to do with it being "true scrum TM" or not. In any case, happy for you that you got out.

Always this "if you have any complaints about Scrum then you aren't doing it correctly" with no explanation how you'd fix the problems I talked about.

Also the leetcode interview is cargo-culted from big tech companies like Google and Scrum is cargo-culted from big tech consultants. They don't fit well together, having both means your company just picked the most popular/simple way to do each part without considering why Google uses that interview or tech consultants uses Scrum. If you want your engineers to work on problems similar to at Google then you wouldn't use Scrum, and if you want your engineers to work on similar problems as big tech consultants then you wouldn't use the leetcode interview.

Scrum does not mean "no freedom" or "no autonomy" it just says lets think about what we're going to do and try to follow a plan for the next week or two. Of course the individual software developer should be the one responsible to forming, adapting, and updating this plan (and it definitely should contain " collaborate with stakeholders, build prototypes and get feedback etc,") (of course, there is some level of 'commitment'. As in other project management systems, you should try and do what you said you'll do).

If as you say, you had no autonomy/freedom, this has nothing to with scrum, that's just regular bad management.

Sanity check: Would your manager complain if you stopped doing Scrum? If yes then you don't got that much freedom. If no, then I can see it being fine. It can work fine if nobody outside of it depends or uses the Scrum process, but then the company isn't doing Scrum, just the team doing it internally. This lets the team adapt and stop doing Scrum when it no longer fits their problem etc, that is the agile way. My point was just that if a company uses both the leetcode interview and the tightly integrated Scrum process mandated on teams then that doesn't make sense.

Edit: And a job ad where they say you should be well versed in Scrum I take it as they will force Scrum on me regardless if it makes sense or not, because I doubt a team just doing Scrum for themselves would put that in a job ad. Companies loves putting this in their job ads though so it is very easy to spot which companies works like this.

"You can't stop using scrum without your manager complaining" is not the same as "zero autonomy".

In every Scrum team I’ve personally worked on (admittedly not a huge sample size), it was OK for a senior engineer to say that their work for the next two weeks isn’t scrum-able so they’re going to mark themselves as having no capacity this sprint.

Yes, and my point was that juniors at Google have more freedom to go and work on different things than seniors have in a typical Scrum team. The description for the junior role (level 3) at Google says that they go off and work on individual projects lasting no longer than 3 months. Having a project for a month or two isn't an exception, it is expected from juniors. Then as you advance levels you get more and more freedom, and as a senior IC you are basically a free agent expected to be able to find things to improve, write a design for that, sell it to the higher ups on the product, and then go and build it, possibly get a junior to build it instead as a few months project, possibly get headcount and set up a team to maintain it etc, on your own.

I'm not saying that this way is strictly superior, but you undeniably have way more freedom under it than Scrum.

You're in the scrum cult dude, get over it.

Scrum is like communism, it doesn't work, stop obsessing over it.

If a company is really following scrum, then the developers are creating and managing their own tickets

Yes, nobody else could write tickets that reliably takes less than a day other than the team. The problem is that your day to day structure gets decided by a brainstorming session held every other week, that might make sense in some contexts but mandating that every developer has to work that way is exactly what I mean that you aren't allowed to have any responsibility.

To me it seems like Scrum was designed to make developers have as little individual ownership/responsibility as possible while still being able to produce relevant code. I see the merit in that, you don't have to tell me why minimizing individual ownership/responsibility could be a good thing. But I strongly believe that individual ownership is necessary to properly capitalize on the creativity of individual talent, otherwise its mostly wasted.

The false negative is the obvious downside of the coding interview, but I wouldn't say that it means there's no merit to the excercise.

Take for example the "can't define an array" crowd. Are there people virtually sitting in front of me who just forget the basic syntax? Absolutly, but given we a) tell them that correct syntax isn't dreafully important, and b) let them pick the language, a [] would probably suffice, I don't think it's a completely unreasonble ask.

Moreso, when we added a prestep of basic questions that one can google, the "can't define an array" crowd mostly disappeared. Sure, there may be some other causation there, but it's hard to hire a coder that you know, can't demonstrate coding.

Finally, anecdata, since we started coding interviews, the quality of developer is simply better. We have had internal debates about this, but the truth is, everyone is overall happier with what we're doing, and I'm a lot happier that false positives are way down.

I'm sure there's other ways of course. :)

The style you propose probably has a high correlation with intelligence and adaptability without requiring too much upfront knowledge / experience. It's open enough to allow for mistakes or answers which show intelligence without requiring perfection. Comparatively, LC-style interviews and "do you know the compiler of this language"-style questions are looking more for knowledge than figuring things out on the spot.

Knowledge generally isn't a great indicator of future job performance, intelligence is. There might be some correlation between the two (you probably need a level of intelligence to acquire the knowledge for LC-style questions), but most jobs are layering proxy upon proxy to test something that has little to do with job performance. Being able to fuddle syntax or search basic solutions and mutate, is leagues different from what LC in an isolated environment is.

Then you add onto that the alternatives tend to be even worse. Personality testing works when done right, but the vast majority of interviewers play pretend-psychiatrist and make the entire thing way too subjective to be effective beyond filtering obvious red flags. Take-homes work, but most companies won't compensate for time and there's no framework to show which take-homes individuals have succeeded (kind of like a certification process), making them an incredible time sink.

And then there are always the cases who have little experience yet manage to pick everything up in 2-3 months and become anywhere from average to top performers.

> The false negative is the obvious downside of the coding interview, but I wouldn't say that it means there's no merit to the excercise.

Tell that to the people who are always the false negative.

I notice there seems to be a "No true Scottman" issue here where the critics is stating one problem and the proponent is like "yeah but what if we change it to this". I'm guessing the process at your place is much more tolerable than what people have been complaining.

I wonder at what point does it stop being "whiteboard interview" and just a "few sprinkle of algorithmic questions to test logical skill".

Also when the talents pool is large enough, obviously you can do as many brutal questions as you can and still fill the headcounts with good developers. So I think saying "but it still works" is not very productive.

It seems to me that a false negative is worse than a false positive if the goal is to hire talent. Have never understood the mentality that it is better to mistakenly turn away a high skill individual than to mistakenly hire a low skill one, you're effectively guaranteeing the former to avoid the latter. Would you write a search algorithm that behaved this way?

> Do coding interviews work in the actual world in which we live in?" No, fundamentally not.

I look forward to seeing you disrupt every major tech company in the world via your superior hiring strategy.

> EVEN IF THE CANDIDATE CAN IN FACT PROGRAM JUST FINE.

You don’t seem to have thought very hard about what employers are optimising for. Everyone realises that programming interviews produce lots of false negatives. Even the strongest programmers have bad days. From the employer’s point of view, that’s okay - minimizing false negatives is not the goal. The goal is minimizing false positives. Failing to hire a strong candidate carries a much lower cost than hiring someone who can’t do the job.

The question is whether they are actually decreasing the number of false positives. So far I've not really seen evidence of this beyond some mere anecdotes. For such a bold claim, one would expect evidence to be readily available.

Which becomes even worse when realizing "false positive/true positive" is too binary of a definition for a spectrum such as job performance.

And I say this as someone who's in favor of giving people a quick check on whether they can actually do FizzBuzz.

> For such a bold claim, one would expect evidence to be readily available.

The only way to provide this evidence would be to to conduct an RCT in which you hire some percentage of people who fail the test as a control group. The nascent psychologist in me loves this idea, but it seems unethical, and presumably this is why nobody does it.

But I disagree that we need ”evidence.” It’s flat out obvious. If you give your job candidates a discrete math problem orders more difficult than the usual ticket, you minimize the risk of hiring someone who can’t do the job.

>If you give your job candidates a discrete math problem orders more difficult than the usual ticket, you minimize the risk of hiring someone who can’t do the job.

You're also maximizing the odds they will get bored and feel baited. With all due respect, you could have picked a better example to illustrate your point.

This is exactly why you can't make such bold claims. You're looking at this from one perspective without considering all the variables which go into the workplace equation. So far, the best correlator to job performance is giving people work corresponding to what they will be doing at the work place. For various reasons, this isn't really happening in software development, making people all to eager to grasp at proxies which they swear will do the same thing. Maybe whiteboarding is in line with the day-to-day at FAANGs, but tons of companies ask questions which are not in line with the day-to-day at all. Both vertically and horizontally. It creates dissatisfaction, burnout, bad cultures, sometimes even animosity, as if hiring managers are playing pranks on candidates.

If you're only looking at this from the perspective of "get someone who can do the job", you're going to miss the forest for the trees. As others say, the company is also being interviewed.

> You're also maximizing the odds they will get bored and feel baited.

I like this point. This is an especially big problem in my area (data science), in which people think they are being hired to do deep representation learning, and are subsequently mortified to learn that the job is principally about transpiling ”product manager” to ”SQL”. The cure is to be up front with job candidates. Tell them the job involves no deep learning. Explain that you give hard interview problems because you need to know that they can reason about eg asymptotic complexity on the rare times where it arises.

> So far, the best correlator to job performance is giving people work corresponding to what they will be doing at the work place.

I don’t necessarily disagree, but I believe you want to optimize for the hardest day rather than the average day. If your team is optimized for who can best solve an average problem, you will eventually have a problem that nobody can solve, and the business will suffer greatly as a result. Hence the discrete math problems.

> I believe you want to optimize for the hardest day rather than the average day.

I think this is a huge mistake. I work in data science, and nearly universally my colleagues are motivated by opportunities to learn. If you're testing for the very rare day, so that your employee has the right answer in their front pocket when that happens they are never going to feel challenged, feel like they're growing, and they're going to jump ship.

I think you're doing snobby filtering, and it's not to your benefit.

> If you're testing for the very rare day, so that your employee has the right answer in their front pocket

On the hard days, the answer has never been seen before, and therefore can’t be in anyone’s pocket. You need to know that you have employees who are smart enough to discover it. Technical interviews are how you find them.

The observation that your employees are motivated by learning opportunities is useful for how you manage them, but this doesn’t tell us how to hire people who can do the job.

>but I believe you want to optimize for the hardest day rather than the average day

There are a few problems with this. If your "hardest day" deviates far from your "average day", while being very infrequent, you're still not doing a good job enticing the candidate. Worse, by looking for people who have already acquired the skills to combat the worst you can throw at them, you're severely stagnating their growth.

Then comes the cherry on top, if your company is doing it while not providing absolutely stellar benefits to function as external motivation, you're further incentivizing people to work on ditching your place. Many companies do not give total comps in line with the skill level tested for, setting themselves up for failure in this regard. Altogether, you're still looking at this primarily from the job interviewer's perspective, not the perspective of the candidate which translates into the company's long term (lack of) health.

>you will eventually have a problem that nobody can solve

No. Someone has to be the first person to solve a question. This strategy doesn't take into account the capacity of individuals to learn and overcome challenges. What's more, most individuals will not be on the highest level, allowing mentors to train them to higher levels.

>I don’t necessarily disagree

It's not about disagreement. Schmidt and Hunter did a meta-analysis on this way back in 1998, and psychology has yet to find the silver bullet. Look at table 1[1]. Most studies checking the market find similar things. It is ridiculously difficult to find correlations between job performance and selection criteria. All corporates, including FAANG, are not exempt from making the very human mistake of doing something which seems great, but ends up being part of survivorship bias. In something as multi-faceted as the job market, combined with the young and everchanging nature of software development, making statements on correlations shouldn't be taken for granted.

Notice how the study above points out years of experience as one of the worst predictors. Most of the job market still uses YoE as if it is gospel. The market is nowhere near as rational as people like to believe it is.

[1]: https://www.researchgate.net/publication/232564809_The_Valid...

> conduct an RCT in which you hire some percentage of people who fail the test as a control group

You might enjoy Work Rules by Laszlo Bock. They actually did do this at Google to validate their interview approach.

Lo and behold, they still do coding interviews. Who would have guessed that people who answer difficult questions correctly would outperform people who don’t.

In all seriousness, thank you for bringing this up - it’s an interesting story and I will probably look into it. But I also think it’s pretty obvious that coding interviews work extremely well, and any discussion of ”how can we create a procedure that is better for everyone” that doesn’t acknowledge this is hopeless.

> You don’t seem to have thought very hard about what employers are optimising for.

Have you ever seen a hiring process that's simply not effective?

The undercurrent of this irks me a bit. It assumes a kind of omniscience on part of the employer, and enough time for them to develop a good interview process. I think this is really hard to do.

I think you're generally right. And a lot of the time, employers are empathetic, pragmatic, self-aware and really are doing us a favor when they deny us. Some take into account I-O psychology stuff, too.

I (and others probably) are eager to hear what companies you feel do a good job at hiring.

> Everyone realises that programming interviews produce lots of false negatives.

Let's assume a bad scenario. A company can disregard evidence of competency, like having a portfolio, to basically have a rolling, year round tech Olympiad. To them, it's about fronting as a strong candidate in events, even at the expense of being good at the role.

You can be a pro at pole vault or discus throwing, but a poor carpenter. But there's a mentality out there - with some - that a strong, fit candidate can handle any technical challenge.

Can a chemist be a great chef? I bet, I also bet some could overthink and/or overengineer preparing a simple meal. Does the interview process do anything to check for soft skills, like curiosity, simplicity, etc? Hopefully.

> The goal is minimizing false positives. Failing to hire a strong candidate carries a much lower cost than hiring someone who can’t do the job.

I think some companies - not all - can create a "squid game" contest out of candidates. Worse, I feel candidates can unduly suffer and be humiliated in these cases.

The company gets a superb interviewer, who is no doubt a very intelligent person, but not necessarily one that can adapt to technical reality, contingencies, ambiguities, etc. Some interview processes end up focusing on theoretical and rote knowledge, not integration and synthesis, when they deeply need that. Turnover happens.

But we're back to the beginning, did the company: 1. really know what they needed for that position, 2. interview process check for that? My guess is when you wrote that you were assuming situations where both were true?

But the adversarial puzzles and whiteboard programming are not "the job".

Hire for strengths, not to avoid weaknesses.

> But the adversarial puzzles and whiteboard programming are not "the job".

This is true. They are closer to ”the rare, most intellectually difficult parts of the job.” A hockey player typically spends 70% of each game sitting on the bench; yet this isn’t what is emphasized in tryouts.

> Hire for strengths, not to avoid weaknesses.

I guess you didn’t read the part of my comment where I wrote:

1. ”Failing to hire a strong candidate carries a much lower cost than hiring someone who can’t do the job.”

This is the default position of large tech companies who do coding interviews, and especially those like Google and Microsoft who interview with very difficult discrete math problems.

If we assume 1, the hiring practices of Google/Microsoft make perfect sense. They are not trying to hire all the extremely talented candidates. They are trying to ensure that all the hires are extremely talented. Put differently, they are optimising for precision rather than recall.

It seems like you disagree with 1. And if you’re right, then you have a huge opportunity, because this suggests you can disrupt any vertical where the incumbent does the LeetCode thing.

But my default position is scepticism, because if it was possible it would probably already be happening.

> And if you’re right, then you have a huge opportunity, because this suggests you can disrupt any vertical where the incumbent does the LeetCode thing.

Only if you view hiring as the competitive advantage of Google/Microsoft/Apple. But everyone cargo cults the hiring practices of Google/Microsoft/Apple without becoming Google/Microsoft/Apple, which shows that it's not actually some magical unique competitive advantage.

We can get into a discussion/argument about what is the competitive advantage of Google/Microsoft/Apple (which collectively own near 100% of the market for mobile OS, desktop OS, web browser, search, etc.), but that's kind of a tangent IMO.

I will say that Google/Microsoft/Apple have a competitive advantage specifically in hiring (that is, getting many of the top candidates to apply) because of their prestige (a product of the aforementioned market dominance) and vast wealth. The latter in particular allows them to offer more compensation, especially stock compensation, than other companies.

It's important to mention though that the formalized hiring practices of these companies are largely ex post facto and could only be put in place after they were already successful. It's unlikely they hired exactly in the same way during the early years. Steve Jobs was introduced to Steve Wozniack by a friend in high school! Nobody can plausibly claim that the success of the Apple II was due to "coding interviews". Larry Page and Sergey Brin met in college, where they were already working on the ideas that led to Google. Hiring doesn't just turn into success, that's not a reliable formula.

You can set the bar as high as you like, but you won't be able to hire anyone if candidates just walk away from your obstacle course. Talented people put themselves through a lot of crap to work at BigCos because there's a big payoff working for a BigCo. That's what tends to make the BigCo hiring pool better than for other companies, not the hiring bar itself. You can afford to be extremely picky if you have a wealth of options to pick from.

> Only if you view hiring as the competitive advantage of Google/Microsoft/Apple. But everyone cargo cults the hiring practices of Google/Microsoft/Apple without becoming Google/Microsoft/Apple, which shows that it's not actually some magical unique competitive advantage.

You're conflating some things here. Without unpicking it all, the main thing I'd say is that you've only demonstrated that amazing hiring is not sufficient for competitive advantage. You have not demonstrated that it's not necessary.

I wouldn't describe it as "amazing" hiring. I'd describe it as assembly line hiring. The results are amazing: Google/Microsoft/Apple are 3 out of the 4 largest companies in the world by market cap. And there's a hiring process — though I doubt the process has remained exactly the same from company founding to present. The question is how much if any the specific hiring process contributes to the results.

I'd say there's a big difference between a company finding engineers and engineers throwing themselves at a company. The latter is what often occurs with BigCos. They have a big pool of candidates throwing themselves at the company, and the company gets to pick whomever they like from the pool. How much credit to due to the company for picking? Whereas I think you'd give a company more credit for going out and specifically recruiting/poaching one person they want, even if that person wasn't applying for a job with them.

> How much credit to due to the company for picking?

Lots. Firstly for becoming a place people want to work. Secondly for sifting through all of those people.

So how do I effectively test for the strengths I want with a low likelihood of false positives?

Ideally without an increase of time/cost requirements.

Maybe you're the enlightened one here or maybe you're just rationalizing an awful and lazy part of the hiring process for many companies.

If anyone actually believed this they wouldn’t complain about it on HackerNews. If it were true that Google, Microsoft, Apple, etc don’t know how to hire programmers effectively, this would be an incredibly powerful observation which you would want to keep top secret while silently beating the hiring market and building the most successful tech company of all time. We’re all waiting.

The reason people are upset by this issue is that it highlights a misalignment in the incentives of employers and job seekers. And with this I fully empathize: job hunting is hell in any industry, ours included.

But we can’t begin to have a conversation about improving the situation until we have a rudimentary understanding of what is happening today. And all these ”Google doesn’t know how to hire smart people” takes are brutally handicapping the discourse.

> If it were true that Google, Microsoft, Apple, etc don’t know how to hire programmers effectively, this would be an incredibly powerful observation which you would want to keep top secret while silently beating the hiring market and building the most successful tech company of all time.

Well, I'd like to have a word with the Apple Mac Mail app team. And the Disk Utility team. And some others...

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?")

you should be able to explain why you wrote something the way you did; that's not an absurd ask.

perf characteristics of different iteration styles are often significant to the task at hand.

Your problem has gone off the rails if that level of performance difference is important.

For me it wouldn't be about performance but about readability.

try rendering a dynamic React dashboard with 30 line, scatter, and heatmap charts, each containing 3 series of 10k points each, several times per second. welcome to what Grafana can do :)

If someone suggested that I ought to be able to solve a problem like that in an interview, rather than solving it over the course of several years with a team of developers (like Grafana did) then I'd stop the interview and remove myself from the hiring process.

No doubt there are situations where hugely optimized code is necessary. An interview isn't one of them unless you're hiring someone to write exactly that code. Most companies aren't.

> No doubt there are situations where hugely optimized code is necessary. An interview isn't one of them unless you're hiring someone to write exactly that code. Most companies aren't.

knowing the difference, and consciously deciding that it doesn't matter for a given task is often a strong positive signal. hopefully a good interviewer will not actually ask you this question if it doesnt matter for the given task.

I don't agree. If someone brought that up in an interview I'd just think "oh, they know a bit of JS trivia that won't impact any of the code they'd write here." and ignore it. It's not a signal at all, let alone a strong one.

If they mentioned the fact that React 18 batches updates in concurrent mode which would greatly improve the responsiveness of a dashboard app that's updating lots of small components frequently, or if they suggested the graphs might be better written using GLSL shaders to move the rendering to the GPU so JS only needs to update a uniform array, then I'd pay attention. Potential new ways to approach a problem or changes to architecture to avoid the problem entirely rather than micro-optimizations are much more interesting signals about someone's deeper knowledge of building things.

Yes, a regular for loop is a bit faster at iterating over a large list of elements than foreach in Javascript, but why on earth would you care about that kind of optimization minutia in a coding interview?

The question you're asking involves 10k * 3 * 30 = 900,000 data points. If a candidate wants to simply loop over all of them multiple times a second, I'd say that's a much bigger problem.

> If a candidate want to simply loop over all of them multiple times a second, I'd say that's a much bigger problem.

unless the task is to animate them in a rAF loop (which runs at ~60Hz), right? the task matters. in some cases the question is stupid & irrelevant, and in the other case it means getting the job done, or not.

the difference between the brain-dead way and the fast way is literally 30x (53ms vs 1.8ms on my machine): https://jsfiddle.net/3ho6f5k1/

It’s unrealistic to expect this level of optimization in a generalist whiteboard session. For a specialist, maybe. I’m not specialized in this area.

For an array of 5-10 items the performance hit of foreach is worth it for readability. Maybe an interesting discussion could occur about when to sacrifice readability for performance but you won’t get that by grilling people about minutiae.

> For an array of 5-10 items the performance hit of foreach is worth it for readability

As always it depends, maybe that component is being called 500 times on the page making it actually 5,000 invocations.

I'd FULLY expect a candidate to understand the difference and would ask in a whiteboard session. There is a lot of bloated slow javascript libraries out there and they almost always stem from the fact that most devs don't realize how much overhead function calls introduce.

For the interview, there is no discussion necessary, the correct answer is simply:

"I used a foreach for readability, because performance doesn't matter in this case because X."

or

"I used a for because performance matters in this case because Y"

End of story.

one could argue that it's a job for the compiler to make sure two equivalent language constructs (map and for loop) perform similarly...

Foreach with functions being passed being slower is an implementation detail. You don't see it in Rust, where the block body is inlined like a generic, and it's perfectly feasible for a dynamic runtime to specialize the pattern and inline based on it being a common practice, never mind polymorphic inline caches which in principle permit inlining in this case.

> For an array of 5-10 items the performance hit of foreach is worth it for readability

100% agree. my point is more about OP's example being used to prove that dumb questions get asked. if it's being asked by a good interviewer, it's usually relevant.

Not sure it proves anything in interview context though. It's a language specific trivia you'll quickly learn either from experience or from a good mentor. Proves nothing about your ability to code or to be a successful member in the team. Unless you're actively looking for a candidate that knows all those JS optimization tricks.

Take Rust. For each and map generally are faster because they often allow bound checks to be elided.

100% trivia.

Constant factors don't normally matter in an interview algorithm context. Focus on them often results in ugly code and can be a distraction against bigger improvements.

I would care about the reading optimization. So if someone tells me "I chose a forEach instead of a for because it provides almost the same performance, but is more readable, and my code does not need the index", that's a very good sign of someone making conscious choices.

If you can't give me the o(n) performance of the algorithm that you just wrote, this is a pretty serious red flag about your ability to understand what you are writing.

I'm going to blow your mind but a ton of important software was written by people who have a hard time explaining these things.

Also a ton of important software was written as a giant mess of spaghetti code, or with horrible security vulnerabilities.

I've never been tested on my ability to not write spaghetti code or write security vulnerabilities in my 15 years doing many many interviews.

Unless you're suggesting that knowing the performance of a loop helps with that?

What I'm suggesting is that "Important software has been written by people who couldn't/didn't do X" is not a very strong indication that X is not a valuable quality that employers should want in their engineers.

Except for the fact that using foreach instead of for has no impact on your O(n) performance.

What would you do if a candidate said with a smile "I'm pretty sure it is O(n!)"?

Parent commenter asked for little o, not for big O. So to be safe, better say n^o(n^2).

Hah this is the best comment.

“So you want to put code into production without having a better estimation of its time complexity than O(n!)?”

If the choice is relevant to the task, then sure. If it’s an arbitrary choice then the question is meaningless. It’s like asking “why are you wearing a blue shirt?” when you would have asked “why are you wearing a black shirt?” had they been wearing a black shirt.

i'm not claiming that this is a good question for every case. but there are many times where the choice of loop makes a significant difference. asking this question for a task that only requires iterating 3 elements every 1000ms would indeed be quite stupid on the interviewer's part.

it always amuses me when people use these seemingly stupid questions (out of context) to prove how broken tech interviews are. but of course, if your job will be write high perf code, then suddenly they question is incredibly relevant.

to be clear, i agree that there are a lot of stupid questions that get asked which are not relevant to the actual job you'll be doing (exceedingly few SWEs will need to implement a merge sort as part of their job)

> perf characteristics of different iteration styles are often significant to the task at hand.

This ridiculously untrue.

It's also a great example of how dumb current interviews are. Someone like this poster could easily interview you, and now what? Do you just play along or begin to explain how incredibly wrong they are?

This is untrue in languages with proper optimizing compilers, designed for performance, e.g. C++, Rust, Zig. A functional iterator transformation chain is often just the same performance as a "traditional" for loop.

But try that in Java and you'll often see a 3x-10x difference, especially if you run into problems with boxing. Streams are known to be notoriously slower than for loops with index. I once have even doubled the speed of a for loop by unrolling it manually (Java 8). Not all compilers are equally strong at optimization.

Anyway, asking such questions in an interview for a junior/regular developer is just a distraction.

Even in java/c#: what kind of application has its performance dominated by a control structure? If you're doing so little work inside the loop then you should probably look at using fancy cpu instructions like SIMD

> This ridiculously untrue.

at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes.

i profile and optimize a lot of JS/TS code that handles datasets with millions of datapoints at my day job. but you don't need to take my word for it; this claim is not exactly difficult to verify.

> Do you just play along or begin to explain how incredibly wrong they are?

in this case, i'd prefer to be proven wrong with code, rather than prose.

It's probably time to move into a faster language if you're getting caught up in language specifics on loop execution.

quite impossible to move into a faster language when it would

1. require a complete rewrite of an existing, massive codebase

2. where the primary task is rendering interactive charts for a React web app

> at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes.

Total nonsense. It is not true of JS today, not has it ever been true.

No modern web app's or website's performance is dominated by the performance of what loops you choose. It isn't even remotely meaningfully impacted by that; by this I mean, any differences are totally unmeasurable beyond some 3 line micro-benchmark.

You have never benchmarked or profiled your code.

Of course, tight inner loops for image processing or ML, etc. yes, this can make a difference. But we're only talking about a handful of loops that matter out of many tens of thousands an application may have, you are almost certainly never writing those loops, and that's a specialized field that basically has nothing to do with the web. And it isn't what you're talking about.

> in this case, i'd prefer to be proven wrong with code, rather than prose.

What absurdity. And this is exactly when interviews suck. Because people have strongly held beliefs that are ungrounded in reality, and since there are no objective measures by which to rate interviews you need to pretend that they're real, because a lot of interviewers are basically just testing "cultural fit".

But hey! I have to say. That if you brought this up in an interview. I would at least know to never take the job!

> "Do coding interviews work in the actual world in which we live in?" No, fundamentally not.

See, that's just not right. I mean, we all agree there's a hard problem to solve here, right? The world is populated by engineers of widely varying skill levels. It just is.

So how do you detect them? Well, the ability to bang out a correct solution on a whiteboard is a verifiably correct way to do that. It may not be optimal (passing candidates with other issues that make them bad fits), and it may have undesired failure modes (rejecting people who have trouble performing in the high pressure environment). And those are problems worth discussing.

But... it works. It clearly works. We've all seen it work. Companies that use these techniques aggressively tend strongly to be organizations with a long track record of producing working software. The FAANG employers are desirable because FAANGs ship code and make money!

So I just don't get the absolutism here. If there's a clearly better way that produces a more effective workforce, where's the darwinian example? Who's winning by hiring better people than Apple or Meta? I just don't see it.

And yet correlation is not causation. And a survivor bias is probably in play here. There are so many more factors contributing to the quality of FAANG work and their performance as businesses. Hell, most of them due to their monopoly-like status could easily use any hiring technique and still rake in tons of $$$. To me the streamlined / cargo cult hiring process seems much more a symptoms of the bureaucratization of these large companies than an actual key to their success.

> And yet correlation is not causation

Well... yeah. To pedantically elaborate that, clearly the hypothesis is that the measured traits (doing well on a coding interview and doing well at coding) are co-causal, and that measuring one (which is comparatively cheap to do) is a useful proxy for measuring the other (extremely expensive!).

That's a really compelling hypothesis. The counter point requires, to my eyes, a clear working example: a company with a uniform hiring process involving some other technique which has a track record of product development as robust as all the existing leaders. And I don't see one. Calling them monopolies or cargo cults seems to be filling in for evidence, and I don't see that as persuasive.

What do you mean by "robust"? There are only a handful of monopolists in the world (by definition), so in that respect no other comparable companies exist.

But there are plenty of smaller companies who do well for themselves, relatively speaking, without cargo culting on BigCo hiring. And there are plenty of companies who cargo cult on BigCo hiring but who have not become a market leader. In fact there are graveyards full of failed startups who cargo culted BigCo hiring. So the hiring process doesn't clearly explain the financial results of the BigCos.

There are plenty of large companies with established hiring practices and standardized interview schemes out there that don't do FAANG-style coding interviews, though. And on the whole they don't do well at delivering software, and have a reputation as terrible places to do software work.

And on the other side: are there major employers who implement rigorous coding interviews who... don't have a history of producing good software? I really can't think of any.

That's my point: the evidence is really stacked in favor of the FAANG scheme. So pointing to a handful of small outfits doesn't really sway my impression; those are just expected outliers. I've worked at smaller companies with terrible hiring success, FWIW; they ended up successful because of a few lucky hires.

It's difficult to agree or disagree with this comment, because it's so vague. For example, "on the whole they don't do well at delivering software, and have a reputation as terrible places to do software work." Are we supposed to just accept this claim without question? I have no idea which companies you're talking about. And I'm not sure that Apple and Amazon for example don't have reputations as terrible places to do software work, but again I'm not entirely clear on what you mean by that.

Moreover, "good software" is also highly subjective and subject to dispute. I feel that the software coming from Apple and Google has gone downhill in the past decade. Are we to explain that by hiring?

The financial numbers are indisputable for Apple, Microsoft, Google, Amazon, and Facebook. (Not sure the term FAANG even makes sense anymore.) But something like "reputation" is another matter entirely.

> There are only a handful of monopolists in the world (by definition)

I don't think that's right. If a small town only has one gas station, and the next closest is 100 miles away, isn't that gas station owner a monopolist?

Fun part is that it can work like ideal world when you have 1-2 devs per year to hire and as a small company you get 20-30 CVs a month.

Once you get into scale where you need to hire 20 devs a year and get 100s of CVs per week it all breaks down.

I've been at companies where we receive hundreds of applications per role posted, and one where we receive 10s. I've posted about this before but in both cases the pipeline was the same - initial pass eliminates about 70-80% of the candidates because they're just not worth following up on - think things like IT staff applying for mid level development jobs with no experience, education or anything to indicate they could write any code. Of the remaining we end up filtering out based on comparing applications - this bit sucks, but pretty much stack ranking the resumes and picking out the top 20 or so[0]. At that point, everyone gets a phone screen with a set of questions picked from a list and we proceed through that. The same process works mostly because the size of your interviewing group scales with the number of engineers you hire.

[0] side note - I work in games where we're often filtering resumes for specific roles, e.g. a gameplay programmer or an online programmer. The filtering here is most of the time bucketing candidates based on their experience and sorting that way.

I do a lot of interviews with potential candidates, and worked with plenty of those we hired (and unfortunately some we fired afterwards).

If you have a better way on how to assess a software developer, I would love to hear it.

Not OP, but I would love to share some: I relate strongly to the anxiety induced descriptions in OPs text and thus try to avoid these when I interview devs as an engineering manager. Of all the candidates I have interviewed over the years I have never done a live coding interview because it is essentially worthless for me as an interviewer and only serves to discards potentially very clever people whose thought process does not work this way.

Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time, so I can review what kind of solution they will actually deliver once hired. We then go through the solution with them and do a code review as they would go through if they got hired. You then see both the problem-solving skills as well as how they take feedback.

I would recommend checking out DuckDuckGo's excellent "How we hire" guide[0] which describes some of the best hiring process I have come across (albeit it may be too extensive to do in full for some companies).

[0] https://duckduckgo.com/assets/hiring/how_we_hire.pdf

So how do you know they did it on their own? Spouse is a developer, helps them out, explains everything. Then on the job there is no spouse, and it all goes to shit. Not saying this would be every time, but you might come across one of these.

We have an initial Hacker Rank 'filter', that if you don't pass that, we don't even do an interview. A few weeks ago we interviewed someone who passed that filter very well. But in the interview, it was really below par. Not even the basics were understood. So I'm very skeptical about these kinds of homework where they could get help.

What I currently do is go through a very simple coding example that I wrote (very generic). Then we go through the code and I ask questions like "can you explain what this line is doing", or "If I move this line over here, is the behavior still the same", etc. Some bugs are in there and I ask what is going wrong and how to solve them.

Not ideal, but the problem is that nothing really is :(.

I think this person has a better idea because your spouse scenario, while realistic, can easily be detected while you discuss the code being presented.

You may have good intentions but what do you equates to "I don't trust you, bro/sis". Not a great way to start a relationship imho

> can easily be detected while you discuss the code being presented.

That is possible of course. But if they wrote the code together, and know they will question later, you could teach the other person all the trade-offs etc. I could see myself doing that with a bad developer and get them through such an interview.

> Not a great way to start a relationship imho

Well, you could take the benefit of the doubt, and then when it seems they did cheat, just fire them. But firing is always such a big decision.

It's a difficult problem.

> But firing is always such a big decision.

Isn't that why managers get paid the big dollars, to make the big decisions?

The whole rhetoric of the tech industry — taking risks, creative destruction, etc. — seems to completely fall apart when it comes to hiring, where everyone turns fearful and ultraconservative.

Have you ever worked with a really bad hire? Someone totally incompetent at doing the job? In my personal experience, that person completely tanks the productivity and moral of the entire team. I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that). Bad hires are disastrous.

> In my personal experience, that person completely tanks the productivity and moral of the entire team.

A bad manager completely tanks the productivity and morale of the entire team too. And you can't fire your boss, you can only quit your job.

> I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that).

Not sure how it's relevant whether you're doing the incompetent person a favor or not? Hiring isn't about favors, it's an exchange of money for work. If there's no useful work, then the money has to stop.

> Bad hires are disastrous.

Seems a bit overstated to me. Do you have any examples of companies put out of business by a bad programmer hire?

Coders come and go. Is it a "disaster" if your best coder leaves for another job? We're treating hiring as if it were like marriage and divorce, but it's not. When you hire someone, it's not "til death do us part". Breakups are expected.

Too many companies make hiring much more difficult than it needs to be. They overthink it, and also waste way too much time on it. Find someone who seems right for the job, and hire them. If they don't work out, get rid of them and hire someone else. You might get unlucky at times with a bad hire, but you might also get lucky with an unexpectedly great hire. If you can't correct your mistakes quickly, that's a problem with your company's culture, not a problem with job candidates. I would argue that it's not a bad hire that demoralizes a team but rather a bad company culture that's incapable of correcting mistakes.

You're answering in a vacuum. The previous poster is saying that just hiring easily with a view to firing if they're bad is destructive. Talking about managers is irrelevant to this. It's not one or the other.

This, probation time + take home assignment + discussion = I can filter out almost all the false negatives of the take at home. Give the people a choice between take home assignment and more classic code interview so you can dodge problems like shitty home-offices, strange contracts clauses but the real deal remains the probation time.

> Not saying this would be every time

How often would you say it ever happens? This feels like a rather extreme level of paranoia.

> Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time,

And in this case you're eliminating people who aren't willing and/or able to spend time preparing for your interview process. One of my previous jobs had a clause in the contract that all my programming work belonged to my employer; is your company going to sign a waiver that says they take responsibility if a previous employer sues? Doesn't matter whether or not it's enforceable or not.

What if you use that solution in production, do you compensate for their time in helping solve the problem like you would if the task was assigned to you?

Also, you're not really setting a level playing field here. How do you gauge a candidates experience/seniority versus the other 10 candidates you hired if you're not asking them the same questions or looking for the same things. Maybe I've solved that bug in my current job.

All this is to say that this doesn't "just fix" hiring - I don't know if it's any better or worse than giving people on-site tests, but you're at the very least trading one set of problems for another.

It might not "just fix" hiring, but at least it doesn't blinding accept the status quo and attempt to engineer an alternative that can then be evaluated. We are supposed to be scientists, are we not?

This is really not rocket science. We have implemented in our company.

Step 1: An initial phone interview with the candidate regarding technologies of choice, war stories, etc

Step 2: A small coding exercise that is similar to what we work on. The candidate can solve this on their own time and email us the solution.

Step 3: Review the solution together and ask questions about their methods.

Step 4: Meet the boss & offer.

The coding exercise is only sent _after_ the initial phone call, so we don't waste their time or ours.

The only problem here is that we can't virtue signal that we follow FANG whiteboard interviews and pretend that everyone working at the company can invert a Trie Tree in a 30 minute coding session..

I would like to see the hiring process like this.

1st interview - Go over the role etc, both parties ask question to see if they are a good fit. If both parties are happy to move to the next stage then there is a take home exercise to do.

Tech Exercise - Something simple which touches the core competencies that the role requires.

2 Second interview - Go through the exercise discussing the design choices etc. If everyone is happy offer the job.

I think the probation period should be used to determine if the candidate is the right fit for the role. That way the business gets a much better idea of who it is they are hiring and the same goes for the candidate.

My favourite is "I'll be your google, I'll be your Stack Overflow, when you would usually search something, ask me instead". So you eventually ask them, and they give you a cryptic answer back.

I'm sure Google wouldnt be as successful as they are if their answer to "how do you define an array" was "well think about what you're trying to do here"

This! Thank you for writing it. And let’s not forget about the wasted nights ruminating about the poor performance and putting up with people who get their dopamine when they are given authority over a peer. Most developers don’t study psychology and don’t have the ability or interest of creating a safe space for conducting the kind of interviews that their employer demands.

I can't tell if you think companies should hire everyone or hire no-one.

What’s the alternative?

If we have to give Leetcode questions I'd at least like there to be an option to do it by myself, no one watching me type or asking questions if I'm thinking more than a minute. This interview style is so unrealistic and stressful, and turning a normally stressful event to a real horror show. Yes you'll have to somehow see to it that I don't cheat if you leave me alone - which makes it harder, but it will be much more humane.

You can just ask them to talk about code. You can ask them to compare and contrast some frameworks or languages of their choosing. You can ask them to do design tasks, or just talk about the work the company does and let them ask questions.

One of the things I like to do, especially when a candidate is super anxious, is just ask them to talk about a recent project they've done that they like and why they like it.

Isn’t that going to result in a highly biased interview process? I suspect extroverts will do disproportionately better than introverts, and those who are comfortable in technologies the interviewer is not will do worse than those who share a similar technical background.

I also think the skill cap on this sort of question is super low.

(I’d put design questions in a different category though)

What process do you think introverts are going to have an equal footing at that isn't take home homework?

And yes, people who know technology will do better.. in a technology interview. I suppose I could ask about gardening but that doesn't help much does it?

Algorithmic interviews are huge equalizers. Anyone regardless of their social skills or technical background can show their talent.

I’m not talking about people who know technology generally. I’m talking about people who know different technology. The process you’ve proposed, if implemented at, say, PHP shop, will rule out plenty of great .NET developers since the interviewer won’t have the context.

Algorithmic interviews optimise for algorithmic knowledge, not on the job capability. It checks for rote learning and time spent preparing for the interview.

Knowing how to implement prefix tree or a hash table shows that you've learned solutions, but not that you can write good code in a team environment. Frankly I'd take a worse engineer that worked better in a team over a 10x that ends up silo'ed in 95% of cases.

That’s not a fair characterization of how most companies (well, at least FAANG) do algorithmic interviews.

A good algorithmic interview does not test algorithm trivia. The question should be solvable with only strong structured thinking and fundamentals.

For example, the much-derided “reverse a binary tree” question (I don’t ask it but I think it’s reasonable) doesn’t really require a ton of algorithm trivia. The data structure can be explained in a few minutes and the problem definition can be made super clear and crisp.

Algorithmic interviews, at least the way they are formatted now (with interviewers silently watching over the candidate at all times, typing notes) also test for anxiety:

https://news.ycombinator.com/item?id=23848039

Maybe the content, despite it being able to be gamed and drilled via Leetcode et al, is sound, but the format in which it is tested may not be.

I've interviewed for Facebook and Google in the past, and at both, my algorithm questions were textbook leetcode/competitive programming questions. You either know the algorithm and/or data structure and know the answer,or you don't and you fail the interview.

Sorry, but introverts can do oral exams just fine.

So instead of selecting people who can do algorithmic problem solving well (under pressure), you’re selecting people who can bullshit well (under pressure).

I’m not convinced it’s really an improvement. I’ve worked with too many people who are great bullshitters but terrible engineers, who sailed through on their charisma.

But that’s why most companies have a mix of technical and behavioral interviews.

Lots of people can bullshit their way out of this. They just repeat stuff they heard their teammates say.

Talking about higher level stuff doesn't mean you can comprehend certain development problems.

> Lots of people can bullshit their way out of this. They just repeat stuff they heard their teammates say.

Indeed. The only way such questions are useful, is as a starting point, maybe they make the candidate more comfortable (less nervous), and they also ensure that you're not asking something the candidate is completely unfamiliar with.

But in any case, any such "experience" or generally "subjective" question must be accompanied by further detail-oriented questions - why did you do this and not that, tradeoffs of different solutions, "how does this framework/library work underneath", questions about understanding performance/security etc characteristics and why, etc.

Lots of people can talk about code but not write it. Way more in fact!