Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

301–310 of 391 posts

Re: In defense of coding interviews

#301
post #276

Earlier quoted context omitted.

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 st…

> 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.

Re: In defense of coding interviews

#302
post #195
post #160

Earlier quoted context omitted.

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

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

Re: In defense of coding interviews

#303
post #295

Earlier quoted context omitted.

>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 wit…

> 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 n…

>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...

Re: In defense of coding interviews

#304

Earlier quoted context omitted.

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 dat…

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.

Re: In defense of coding interviews

#305

Earlier quoted context omitted.

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 sou…

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.

Re: In defense of coding interviews

#306
post #164

Earlier quoted context omitted.

Yet they are able to do the job. Something doesn't lineup with your testing methods vs outcome. If these people are finding work elsewhere and doing productive work for years what does it say about your process?

Do you think they are looking for a job because they were fired somewhere else? Or do you think companies never fire people? We already fired plenty of people that we hired. So yes, our hiring process is not perfect. But if you're a JavaScript developer and can't explain the difference between var, let and const, I'm not going to hire you. If you claim these people are great developers, you are free to hire them. Let…

Those are different skill sets. Someone may know and know how to properly use var, let and const according to standards and current trends. They may understand it deeply. But that doesn't mean that they can explain it to you.

The question changes to: is what you are testing the actual skill you need? Are you hiring a teacher who is going to explain var,let,const as part of their job or are you hiring someone who needs to know how properly to use var,let,const?

Send me over any developer who fails your teaching requirements for var,let,const but has code samples with proper usage.

I've never seen a senior developer fired for poor coding. I've seen them get fired for being part of a department cut or because they got into a fight with the owner/boss. I've seen them fired because they make too much compared to outsourced resources.

Re: In defense of coding interviews

#307

Earlier quoted context omitted.

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 ca…

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.

Re: In defense of coding interviews

#308
post #282

Earlier quoted context omitted.

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 givi…

> 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…

> 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.

Re: In defense of coding interviews

#309
post #160

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

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…

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.

Re: In defense of coding interviews

#310

Earlier quoted context omitted.

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…

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.

Post reply on HN