12 ms·

"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 id

"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 is sufficiently capable to actually analyze code, and writing code with an audience is absolutely a stupid anxiety inducing high stress situation that makes candidates into babbling children who can't define an array - EVEN IF THE CANDIDATE CAN IN FACT PROGRAM JUST FINE. Add in one idiot on the interview panel who can't stop "tsk"-ing or asking obnoxious questions ("Why did you use a foreach and not a for loop?") and you have an hour long anxiety sandwich where the only thing you are getting from the candidate is whether or not they can dance in front of a sufficiently hostile crowd on demand.

leeoniya 4y ago
> 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.
- light_hue_1 4y ago
  > 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?
  - leeoniya 4y ago
    > 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.
    - vorpalhex 4y ago
      It's probably time to move into a faster language if you're getting caught up in language specifics on loop execution.
      - leeoniya 4y ago
        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
    - light_hue_1 4y ago
      > 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!
      - leeoniya 4y ago
  - pkolaczk 4y ago
    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.
    - Dayshine 4y ago
      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
- tshaddox 4y ago
  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.
  - leeoniya 4y ago
    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)
- vorpalhex 4y ago
  Your problem has gone off the rails if that level of performance difference is important.
  - leeoniya 4y ago
    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 :)
    - thaneross 4y ago
      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.
      - leeoniya 4y ago
        > 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/ https://jsfiddle.net/3ho6f5k1/
        drewrv 4y ago
        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.
quacker 4y ago
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.
- Apocryphon 4y ago
  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.
  - vorpalhex 4y ago
    You can still write off cargo-culting companies who cargo-cult bad processes off. I give you permission.
    - bryanrasmussen 4y ago
      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.
      - vorpalhex 4y ago
        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.
        4y ago
peterhunt 4y ago
What’s the alternative?
- vorpalhex 4y ago
  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.
  - peterhunt 4y ago
    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)
    - vorpalhex 4y ago
      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?
      - peterhunt 4y ago
        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.
koonsolo 4y ago
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.
- implmentor 4y ago
  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 https://duckduckgo.com/assets/hiring/how_we_hire.pdf
  - koonsolo 4y ago
    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 :(.
vletal 4y ago
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.
- weatherlite 4y ago
  What type of questions were there?
- slifin 4y ago
  > preparing for the interview
  - vletal 4y ago
    Not sure what is wrong with preparing for a challenging interview. What is the point you are making?
    - extropy 4y ago
      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.
    - zerr 4y ago
      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?
ozim 4y ago
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.
- maccard 4y ago
  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.
ownagefool 4y ago
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. :)
- BlargMcLarg 4y ago
  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.
dlkf 4y ago
> 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.
- chrisweekly 4y ago
  But the adversarial puzzles and whiteboard programming are not "the job". Hire for strengths, not to avoid weaknesses.
  - Ntrails 4y ago
    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.
  - dlkf 4y ago
    > 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.
ajross 4y ago
> "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.
- ubik_ 4y ago
  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.
  - ajross 4y ago
    > 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.
robertlagrant 4y ago
I can't tell if you think companies should hire everyone or hire no-one.
mihaitodor 4y ago
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.
bodge5000 4y ago
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"

leeoniya 4y ago

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

light_hue_1 4y ago
> 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?
- leeoniya 4y ago
  > 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.
  - vorpalhex 4y ago
    It's probably time to move into a faster language if you're getting caught up in language specifics on loop execution.
    - leeoniya 4y ago
      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
  - light_hue_1 4y ago
    > 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!
    - leeoniya 4y ago
- pkolaczk 4y ago
  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.
  - Dayshine 4y ago
    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
tshaddox 4y ago
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.
- leeoniya 4y ago
  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)
vorpalhex 4y ago
Your problem has gone off the rails if that level of performance difference is important.
- leeoniya 4y ago
  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 :)
  - thaneross 4y ago
    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.
    - leeoniya 4y ago
      > 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/ https://jsfiddle.net/3ho6f5k1/
      - drewrv 4y ago
        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.

quacker 4y ago

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.

Apocryphon 4y ago
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.
- vorpalhex 4y ago
  You can still write off cargo-culting companies who cargo-cult bad processes off. I give you permission.
  - bryanrasmussen 4y ago
    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.
    - vorpalhex 4y ago
      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.
      - 4y ago

peterhunt 4y ago

What’s the alternative?

vorpalhex 4y ago
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.
- peterhunt 4y ago
  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)
  - vorpalhex 4y ago
    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?
    - peterhunt 4y ago
      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.

koonsolo 4y ago

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.

implmentor 4y ago
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 https://duckduckgo.com/assets/hiring/how_we_hire.pdf
- koonsolo 4y ago
  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 :(.

vletal 4y ago

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.

weatherlite 4y ago
What type of questions were there?
slifin 4y ago
> preparing for the interview
- vletal 4y ago
  Not sure what is wrong with preparing for a challenging interview. What is the point you are making?
  - extropy 4y ago
    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.
  - zerr 4y ago
    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?

ozim 4y ago

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.

maccard 4y ago
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.

ownagefool 4y ago

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

BlargMcLarg 4y ago
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.

dlkf 4y ago

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

chrisweekly 4y ago
But the adversarial puzzles and whiteboard programming are not "the job". Hire for strengths, not to avoid weaknesses.
- Ntrails 4y ago
  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.
- dlkf 4y ago
  > 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.

ajross 4y ago

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

ubik_ 4y ago
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.
- ajross 4y ago
  > 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.

robertlagrant 4y ago

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

mihaitodor 4y ago

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.

bodge5000 4y ago

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"