46 ms·

As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of convers

As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them. Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved and all the hard technical challenges were overcome, how can you tell? Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about. Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...

Jensson 5y ago
Yeah, any member of a team that isn't completely clueless will be able to convincingly claim that all of the achievements done by the team was achieved by the person alone.
TrackerFF 5y ago
There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position. Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine. And this is fought with setting up ridiculous 8-part technical interviews where you'll have to whiteboard some leetcode questions ("Given a problem, show us a working O(Log N), or preferably O(1) solution. You have 45 minutes") or design questions ("Show us how you would design slack / discord / zoom / etc.") that drags over 6 months. For someone to be truly incompetent, or even not good enough to meet the company standards, the current system is overkill.
- philwelch 5y ago
  The vast majority of people you actually work with are competent, sure. But the problem with interviewing is that it adversely selects for incompetent people, because competent people are more likely to have jobs and not be currently interviewing.
- Hermitian909 5y ago
  It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company. How empowered are new senior hires, and how expensive is the time of the team? At larger companies senior engineers are often phenomenally expensive and at smaller companies controls over potentially business ending operations are usually minimal. A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires. On the other end of companies, I've heard of seniors corrupting the database and its backup and ending an entire startup. This is not a defense of whiteboard interviews per se, just an observation on why companies desperately want to avoid bad hires.
  - dgb23 5y ago
    In your examples, did they go through a coding challenge / whiteboard process?
    - Hermitian909 5y ago
      Across all examples I can think of - some yes, some no. It's not material to my point either way. I was only arguing that for some company's being very afraid of bad hires may be sensible and dismissing their concerns as hysteria does not seem obviously correct to me.
      - Clubber 5y ago
        >In your examples, did they go through a coding challenge / whiteboard process? I think he was trying to point out that if some of the bad candidates had passed a whiteboard test, it brings in to the questions of the effectiveness of whiteboard tests to filter out bad candidates. I remember a guy we hired years ago who answered all the tech questions we asked with flying colors. He was lazy and unmotivated and ended up dumping all his work on other people (me). I would have much rather had a motivated person who I had to teach some stuff to rather than him.
- jonathankoren 5y ago
  I think about the time my manager dismissed an interviewee as not understanding map-reduce because he couldn’t solve some problem in 2 passes, but rather needed 3. I asked him to explain how to do it in 2. And he was like, “what? It’s easy!” Then another person on the team who over heard it also asked. Eventually the whole team was there, asking him to prove it, and he spent over an half an hour trying to explain it, and none of us were getting it. The consensus from everyone (except the manager) that it was an unfair question that relied on a a very subtle assumption about the data that wasn’t obvious at all, and that 3 passes was the minimum required Without the that assumption. Of course the manager said everyone was stupid and it was a good question. That manager remains my counter example of what a good manager is.
  - popcube 5y ago
    this example display the advantage of leetcode. if your recruiters just can not work, leetcode style still can offer some useful data for decision.
  - swiftcoder 5y ago
    An awful lot of the datastructure-style questions rely on specific knowledge of the optimal approach. I dislike asking questsions because they are more a test of whether you took a particular style of datastructure course than a test of problem solving
- native_samples 5y ago
  Sadly this isn't some sort of mass hysteria but based on practical experience. Yes, it's hard to believe. New interviewers are routinely shocked the first few times they are asked to take a candidate through a coding test. That's why everyone should just ignore the advice in the article - it's wrong. If you want to hire competent programmers, you need to test them rigorously by watching them code, in front of you. Every time I have been tempted to stray from this path the results have been bad. The world is full of people who are very good at seeming affable, friendly and competent but who then fall to pieces the moment you ask them to write a program. Any program. That does anything at all.
  - stackbutterflow 5y ago
    Then why ask candidates to solve a leetcode hard or two mediums in 45 mins? If you're afraid of people who can't code any program then ask for leetcode easy.
    - native_samples 5y ago
      Sure but the article isn't about difficulty of coding challenges, or where you get them from, but about doing them at all.
      - chakkepolja 5y ago
        It's a vicious cycle. As companies ask 'Leetcode easy' questions, there came to be thousands of online blogs, youtube channels etc.. which trained even the n00bs who can't write good code otherwise. If they train very well they can solve 2sum or write binary tree level order traversal without understanding much. Of course not all interviews can use novel exclusive questions, and these have a non-negligible chance of passing. Now if you are hiring, you would think, "If these n00bs can solve Leetcode easy with practice, the good ones are solving Leetcode medium with same level of practice. So let's raise the level of questions so that we don't end up hiring these rote-learning noobs". And it continues. I don't think there's an obvious solution to this, if you don't want to lose the statistically good heuristic of problem solving skills, in order to weed out candidates.
mattkrause 5y ago
Other fields seem to do just fine with this approach. If you interview for an R&D position at (e.g.,) a biotech company, in academia, or one of the National Labs, you're usually asked to prepare a 30-45 minute presentation about your past work. New grads usually use their MS/PhD thesis defense slides; other folks often have a conference talk they can expand. Some places also do "chalk talks" where you describe how you'd approach a new problem of your or their choosing. This presentation is the jumping-off point for the rest of your interviews. If you talked about building a compiler, someone is going to ask for details about the lexer, maybe have you do implement a very simple tokenizer on a white board. Another person will ask how you measured its correctness/performance. Yet another may dig into how you organized the team doing the work, etc. Maybe, as you propose, someone else helped with parts of the work. This wouldn't necessarily weed that out. Nevertheless, I'd argue that being able to justify the decisions that were made--and cogently explain when/why they might be different--isn't actually BS; it's understanding.
swman 5y ago
What happened to references? That’s an easy way to verify if someone is bullshitting. It is possible to bullshit your way through interviews (there’s a whole industry to help you do just that) and not know good software engineering patterns.
- twiddling 5y ago
  Most companies won't do references beyond verifying employment. Then you relying on professional references, and are they lying?

Jensson 5y ago

Yeah, any member of a team that isn't completely clueless will be able to convincingly claim that all of the achievements done by the team was achieved by the person alone.

TrackerFF 5y ago

There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position. Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine. And this is fought with setting up ridiculous 8-part technical interviews where you'll have to whiteboard some leetcode questions ("Given a problem, show us a working O(Log N), or preferably O(1) solution. You have 45 minutes") or design questions ("Show us how you would design slack / discord / zoom / etc.") that drags over 6 months. For someone to be truly incompetent, or even not good enough to meet the company standards, the current system is overkill.

philwelch 5y ago
The vast majority of people you actually work with are competent, sure. But the problem with interviewing is that it adversely selects for incompetent people, because competent people are more likely to have jobs and not be currently interviewing.
Hermitian909 5y ago
It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company. How empowered are new senior hires, and how expensive is the time of the team? At larger companies senior engineers are often phenomenally expensive and at smaller companies controls over potentially business ending operations are usually minimal. A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires. On the other end of companies, I've heard of seniors corrupting the database and its backup and ending an entire startup. This is not a defense of whiteboard interviews per se, just an observation on why companies desperately want to avoid bad hires.
- dgb23 5y ago
  In your examples, did they go through a coding challenge / whiteboard process?
  - Hermitian909 5y ago
    Across all examples I can think of - some yes, some no. It's not material to my point either way. I was only arguing that for some company's being very afraid of bad hires may be sensible and dismissing their concerns as hysteria does not seem obviously correct to me.
    - Clubber 5y ago
      >In your examples, did they go through a coding challenge / whiteboard process? I think he was trying to point out that if some of the bad candidates had passed a whiteboard test, it brings in to the questions of the effectiveness of whiteboard tests to filter out bad candidates. I remember a guy we hired years ago who answered all the tech questions we asked with flying colors. He was lazy and unmotivated and ended up dumping all his work on other people (me). I would have much rather had a motivated person who I had to teach some stuff to rather than him.
jonathankoren 5y ago
I think about the time my manager dismissed an interviewee as not understanding map-reduce because he couldn’t solve some problem in 2 passes, but rather needed 3. I asked him to explain how to do it in 2. And he was like, “what? It’s easy!” Then another person on the team who over heard it also asked. Eventually the whole team was there, asking him to prove it, and he spent over an half an hour trying to explain it, and none of us were getting it. The consensus from everyone (except the manager) that it was an unfair question that relied on a a very subtle assumption about the data that wasn’t obvious at all, and that 3 passes was the minimum required Without the that assumption. Of course the manager said everyone was stupid and it was a good question. That manager remains my counter example of what a good manager is.
- popcube 5y ago
  this example display the advantage of leetcode. if your recruiters just can not work, leetcode style still can offer some useful data for decision.
- swiftcoder 5y ago
  An awful lot of the datastructure-style questions rely on specific knowledge of the optimal approach. I dislike asking questsions because they are more a test of whether you took a particular style of datastructure course than a test of problem solving
native_samples 5y ago
Sadly this isn't some sort of mass hysteria but based on practical experience. Yes, it's hard to believe. New interviewers are routinely shocked the first few times they are asked to take a candidate through a coding test. That's why everyone should just ignore the advice in the article - it's wrong. If you want to hire competent programmers, you need to test them rigorously by watching them code, in front of you. Every time I have been tempted to stray from this path the results have been bad. The world is full of people who are very good at seeming affable, friendly and competent but who then fall to pieces the moment you ask them to write a program. Any program. That does anything at all.
- stackbutterflow 5y ago
  Then why ask candidates to solve a leetcode hard or two mediums in 45 mins? If you're afraid of people who can't code any program then ask for leetcode easy.
  - native_samples 5y ago
    Sure but the article isn't about difficulty of coding challenges, or where you get them from, but about doing them at all.
    - chakkepolja 5y ago
      It's a vicious cycle. As companies ask 'Leetcode easy' questions, there came to be thousands of online blogs, youtube channels etc.. which trained even the n00bs who can't write good code otherwise. If they train very well they can solve 2sum or write binary tree level order traversal without understanding much. Of course not all interviews can use novel exclusive questions, and these have a non-negligible chance of passing. Now if you are hiring, you would think, "If these n00bs can solve Leetcode easy with practice, the good ones are solving Leetcode medium with same level of practice. So let's raise the level of questions so that we don't end up hiring these rote-learning noobs". And it continues. I don't think there's an obvious solution to this, if you don't want to lose the statistically good heuristic of problem solving skills, in order to weed out candidates.

mattkrause 5y ago

Other fields seem to do just fine with this approach. If you interview for an R&D position at (e.g.,) a biotech company, in academia, or one of the National Labs, you're usually asked to prepare a 30-45 minute presentation about your past work. New grads usually use their MS/PhD thesis defense slides; other folks often have a conference talk they can expand. Some places also do "chalk talks" where you describe how you'd approach a new problem of your or their choosing. This presentation is the jumping-off point for the rest of your interviews. If you talked about building a compiler, someone is going to ask for details about the lexer, maybe have you do implement a very simple tokenizer on a white board. Another person will ask how you measured its correctness/performance. Yet another may dig into how you organized the team doing the work, etc. Maybe, as you propose, someone else helped with parts of the work. This wouldn't necessarily weed that out. Nevertheless, I'd argue that being able to justify the decisions that were made--and cogently explain when/why they might be different--isn't actually BS; it's understanding.

swman 5y ago

What happened to references? That’s an easy way to verify if someone is bullshitting. It is possible to bullshit your way through interviews (there’s a whole industry to help you do just that) and not know good software engineering patterns.

twiddling 5y ago
Most companies won't do references beyond verifying employment. Then you relying on professional references, and are they lying?