14 ms·

After being on both sides of the interview situation for quite a while now, my feeling on this is more nuanced. The thing is, when you look for a job, you will

After being on both sides of the interview situation for quite a while now, my feeling on this is more nuanced. The thing is, when you look for a job, you will often go for 5 to 10 interviews. On the other end, when I'm looking for someone to fill a position in my team, I will interview at the very least 50 candidates. That is to say, all things equal, the interviewer has most likely more incentive than the interviewee to go straight to the point, and thus perform a technical check early in the process. Also, you have to realize than the vast majority of candidates applying for a position are highly unfit for it. Seriously, even for very senior positions, you would be amazed at the sheer amount of people applying with grossly pumped resumes, and overall low skill level once tested. Even after careful picking of resumes, I would estimate that 80% of candidates end up being obviously unfit after the first 10 minutes of a technical interview. That's why, as an interviewer, I'm not very inclined to have a long open discussion about the job until I have at least some degree of confidence that the candidate is worth it. Of course that process is unfair for the "good" candidates. Those who apply to positions fitting their skill set. But when you have more than 50 interviews ahead of you, and an actual job to do, you have to make compromises and tailor your process for efficiency.

cmrdporcupine 6y ago
Honestly, I question most interviewers ability to evaluate someone as low or high skill. I honestly don't think the testing works most of the time.
- AshamedCaptain 6y ago
  If you really believe so, then I think you are failing to grasp how low "low skill" truly happens to be.
  - cmrdporcupine 6y ago
    Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.
    - NationalPark 6y ago
      I felt this way too until I was made to start giving interviews. However low a bar you're imagining, I assure you I've seen "strong on paper" candidates who failed to meet a lower one. I don't know if people are lying, or people cheated through school, or talked other people into doing their work at the jobs they claim to have had, but it's really astonishing how unable to write code they can be. However, the particularly insidious candidates are the ones who have developed a skill for talking about software/programming but can't actually write code no matter how much help or prodding they are given. As soon as you accidentally hire one of those, the case for technical interviews becomes a lot stronger.
      - song 6y ago
        I was going to write a similar comment when I saw yours. We've recently hired someone who was great on paper, was adept at talking about software/programming and was able to present some code he allegedly wrote and explain it. He seemed like a great fit based on the discussions but we hadn't actually given him a whiteboard interview. Once he joined the company he proceeded to actually be completely unable to write a single working piece of code. Everything he wrote needed to be reviewed and had major glaring issues. When confronted about it, he would say that he couldn't figure it out so decided to just commit his unfinished code. That guy was senior, had worked for 20 years and is really good at talking but when it comes to actually developing software, he is completely utterly incompetent.
        ryandrake 6y ago
        I am constantly surprised at how many Brillant Paula Bean [1] developers are out there successfully interviewing, getting hired and BS-ing their way through jobs. I've always wondered if this is as prevalent in other industries outside of software. 1: https://thedailywtf.com/articles/The_Brillant_Paula_Bean https://thedailywtf.com/articles/The_Brillant_Paula_Bean
    - edanm 6y ago
      I don't know how many people saying otherwise would constitute sufficient evidence in your mind, but add me to the list of people that disagree with this sentiment. I've had candidates who couldn't code a loop. Not "did something suboptimal", I mean literally couldn't write a single line of code. I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk at length about them. But when given a task to do on the computer, given 2 hours alone to sit and code, couldn't do even the first part of the exercise - despite it being something you could literally copy and paste from the documentation that we gave them a link to!
  - freeqaz 6y ago
    There is a reason that "FizzBuzz" is a meme! I love the expression, "Job candidates who can't seem to program their way out of a wet paper bag." It's too true. A quick search found the source article that I read years ago here[0]. :) 0: http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest
    - jjav 6y ago
      > http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest From that page: > We can't understand why so many people "fail" the Fizz-Buzz test unless we understand why it is "hard" (for them). But the article doesn't even talk about the environment, which is what it's all about. It's hard "for them" because they're being asked to write the code on a whiteboard, with a job/income on the line, with stress and anxiety dialed up to 11, with someone breathing down their neck watching, while expected to simultaneously provide cheerful ongoing commentary to "show how they think". Under those conditions, I totally believe close to 100% perfectly competent developers will fail at it. But of course it has nothing to do with the programming part. Most of us have heard of FizzBuzz while chillin at home reading articles and immediately thought "that can't be hard" and tried it and indeed it is laughably easy. So we can't understand how "they" could fail at it because we didn't experience it under interview hazing conditions. So the "them" is actually all of us. To me that is the key takeaway of FizzBuzz.
      - ciceryadam 6y ago
        In my case I failed at fizzbuzz because I was interviewing after spending a full day merging 2 versions of dbdumps into one, while getting rid of duplicate entries/foreign keys, etc. I could still do a pseudo code version of it, but I couldn't remember modulo function. At all.
- Jach 6y ago
  You're right to question it, but this is also why testing is so prevalent apart from the deluge of unqualified/barely qualified applicants. It's possible for a single person to spend an hour (perhaps over lunch) with prospective candidates and better evaluate them, with a corresponding better evaluation of the company by the candidate, without needing to do the multi-stage multi-test multi-people rigamarole big companies are addicted to. Similarly such people can usually detect resume BS better and whittle a list of 50 down to a shortlist of a few to spend that hour on each and come away with more than one good fit. But the skills needed to do that aren't widespread or taught or in many cases even acknowledged as existing. Hence tests, where when followed as a script can be given and scored by even the most disinterested programmer who'd rather be programming instead of doing their manager's job. Now you don't even need someone ok at resume BS detection to narrow the list, you can parallelize that 50 hours. Of course the tests are proxies and often aren't even scored objectively. And most tests aren't very good at proxying anything general (hence companies' tendencies to have several). There's a lot of problems that remain, our industry doesn't take hiring seriously. But testing and trying to test as early as possible have come to dominate for not totally unreasonable reasons, and persist at the large companies despite the well-known negative trade-offs. It's a startup's/small company's advantage to not copy bigco's interview processes.
- hirundo 6y ago
  Sometimes it's easy. We had a candidate who looked good on paper and sounded good in person. When it was time to start the screening test he asked to go to the bathroom. And never came back. We took that as a red flag.
gedy 6y ago
I think a big problem is companies and in house recruiters who reach out to experienced/settled engineers and first thing they want is send you through some hr / tech quiz pipeline. No. I need to hear what this is about and if it's something I'll bother jumping through hoops for. Your recruiter's quick calls are not cutting it and that is not the same as "applying".
C1sc0cat 6y ago
I am reading this correctly a short list of 50 for a single role?
- claudeganon 6y ago
  It’s completely insane if they’re interviewing 50 people per role. The filtering process is entirely broken if they’re doing that many. The most people I’ve ever interviewed for a job is 7.
  - edanm 6y ago
    Do you have some context around that number? E.g. are you in a large company that pre-filters the pool for you? I ask because 50 is not completely unreasonable. I've had positions where we've had to interview dozens of candidates, in our small company. In larger companies, often someone else does some initial interviews though and that filters out candidates who e.g. can't code at all (sometimes - not always!).
    - claudeganon 6y ago
      7 was at a large enterprise software company. I don’t remember exactly how many phone screenings they did, but it was less than 20. I still thought it was too many. Like I said, I think if you have to interview that many, your filtering process is really broken further up the pipeline. You don’t know what you want, what the job really is, the or application process isn’t properly structured. Interviewing large numbers of people is also a huge liability unless you’re extremely consistent and well-documented in your hiring process (something which I’ve found to rarely be the case).
      - johnward 6y ago
        > You don’t know what you want, what the job really is, the or application process isn’t properly structured. I interviewed at Google. The position description versus what I was interviewed on were two worlds apart. Like the position mentioned front end CSS and HTML. I was grilled on SQL in two of the 4 interviews. This wasn't a SWE position, it was more of a client support role, but I was given a coding test. I did poorly on the test, but I still consider it difficult for a role that was not a SWE. It didn't even seem like Google knew what role they were hiring for they just wanted "someone technical" to do something. I left this process feeling pretty confused and turned-off at their hiring process and questioning if I really wanted to work at a place like that.
xtracto 6y ago
>On the other end, when I'm looking for someone to fill a position in my team, I will interview at the very least 50 candidates. I'll give you a pro-tip: Candidate Interview Packs. Cook up some Google Slides with the main info about the position, the company, the team, what you expect from the person, what you are looking for, the interview process, etc; beyond the dry JD that HR shares. Give it the personality of your (Engineering) team and generate a PDF that you can share with the 50+ candidates. It has worked for me in the past.
sumtechguy 6y ago
This is really why I use the 'easy' type questions (some variation of fizbuzz or something simple). A senior guy will crank it out in 5-10 mins. I then ask a question or two on how to improve it and a mini walk through of what they did and why. I also make it clear I sometimes get people who just can not do it but have the resume chops for it. I then usually spend the rest of the time digging on previous techs they have used, problems solved, etc. The annoying ones are dudes who want you to somehow do a big O proof of some NP complete problem, with tests, proper code, and in front of 3 people in 45 mins (with 5 left for you to ask any questions). For something you may have not touched in 20+ years. I do not want a guy who can create the proof. I want a guy who can explain it in plain English to the 3 other guys in the group and maybe take a few days to get it right and make the code easy enough to understand so when we have to change it in 8 months they can pick it back up.
- stronglikedan 6y ago
  +1 for fizzbuzz. It still amazes me how this simple little test can often weed out a largish portion of candidates early on.
  - sumtechguy 6y ago
    I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something everyone can grasp but it is not something everyone knows about. Plus it is easily looked up and gamed. I try to pick something that has a few if conditions and a loop, which is what most people do. Bonus if it can be a 'refactor' style problem for the small walkthrough afterwards. But it is not necessary for that. If I were to make one up right now I would say something like 'given a string reverse the first half and move the second half to the front of the string and return the result'. There are enough little gotchas there to see if they have a feel for what can go wrong and loops and ifs. It also has an advantage that it is not easily looked up on the internet and pre-studied as fizzbuzz has been codegolfed on some discussions. The downside is it would probably burn a lot of time. So you need to budget your time with them accordingly. If I can talk someone into it I try the test out on them beforehand to see how long it would take. I want it to be quick. I just want someone who is competent and can explain what they did and has some relatable experience and can explain what they did there.
grumple 6y ago
If you're interviewing 50 candidates, your process is horrifically broken. As soon as you find an acceptable candidate, hire them. They don't have to be perfect; no hire will be, no matter how much time you spend. You're wasting company time and money.
- DoofusOfDeath 6y ago
  In case you're interested, there's a bit of mathematics related to this. It's called "The secretary problem" [0]. [0] https://en.wikipedia.org/wiki/Secretary_problem https://en.wikipedia.org/wiki/Secretary_problem
  - grumple 6y ago
    Thanks! I've seen this before but forgot what it was called.
renewiltord 6y ago
Here's the funny thing. I've worked with recruiters where the candidates they supplied needed the tech screen upfront and recruiters where the sell call upfront was useful. Honestly, the latter guys are absolutely fire to work with. I think recruiting is like security engineering: 90% of the guys doing it are total rubbish so you just assume that's what it's like. But that last 10% are super good, and the top 1% are really freaking good. I remember when I first encountered a recruiting pipeline put together by a guy who was good at it. Literally every person I spoke to was a good engineer. We did tech-screen them, but only after the initial call where we talked to them about their interests and our company objectives. Literally every one of these engineers knew: * What sorts of problems they wanted to work on * What stage of company they wanted to work at (seed, series-A, ..., big established company) * What risk they were willing to take * What sort of team they wanted to work on This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot. Anyway, I was very impressed. Also, the fact that almost every one of them didn't bat an eye at the tech screen. You read some of the comments on HN/Reddit and you see that these guys are a cut above the standard dudes. Like, just the social nous. Way off the charts. On HN, people talk about an interviewer mis-sizing the problem: "Haha, so I told him I'd do it on a single SGI UV 300 with 3 TB of RAM. The interviewer got stuck. I got him.". These guys are like way better. If you mis-size, they'll just be like "Ah, okay, so you can get this done on a single machine these days, they have a lot of RAM, but that's trivial. AWS has the u24s for 24 TB or something. So let's say the problem is even bigger or that we want the other advantages of clusters" and they'll take it away. No chip on the shoulder. No insecurity. If some constraint doesn't make sense, they'll say "Okay, if we were doing this in prod, I'd push back on that, but let's say it's the case" and just go on. We didn't convert everyone - not everyone wants to work in our domain or wants to deal with the quirks of our team or whatever, but that's life. It was way more enjoyable as an interviewer.
- yowlingcat 6y ago
  > This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot. I think that's probably more the rub than anything. I never had a happier time being an interviewer than my time at hypergrowth startups. The sheer caliber of both candidates AND resource allotment towards landing them was far higher than what I was able to see in the BigCo environment. It made things a lot more pleasant.
TheFiend7 6y ago
I've been a software engineer for over 6 years and I still have to do 20+ interviews.
monadic2 6y ago
> That is to say, all things equal, the interviewer has most likely more incentive than the interviewee to go straight to the point, and thus perform a technical check early in the process. I would think that any "straight to the point" hiring process would be "straight to the point" because it avoided the technical interview process: A) there's not much you can do to entirely avoid problems with work performance and B) technical knowledge can only be sussed out so far in an interview, period, before actual work performance in the context you're hiring the person for can be evaluated.
jjav 6y ago
> I will interview at the very least 50 candidates. Why? IMO this is about an order of magnitude too many. I typically interview about 3-4 people, on rare occasions a few more. I've been interviewing candidates for about 25 years now. If your recruiter is sending you 50+ mismatched resumes for a role, get a better recruiter. But even in that case, you should notice and weed these out while reviewing the resumes yourself, before getting to the interview stage. I literally cannot imagine any scenario where I'd interview over 50 people for a role. Or even ten people. A few startups ago we had to grow the team from 20 people to ~120 in a year. Your approach would result in interviewing well over 5000 people in a year. That would be over 20 people a day, every single day, zero work getting done meanwhile! I suggest a re-think of your hiring strategy. > being obviously unfit after the first 10 minutes of a technical interview Which one is more likely: 1. Senior people who have built many successful products don't actually know how to do what they've done. or 2. Interview techniques that focus on skills unrelated to the job (e.g. whiteboard puzzles, algorithm trivial pursuit) have an inordinately high false negative rate.
Galanwe 6y ago
I see a lot of comments asking for clarifications on the numbers, the process, and what is being tested during the interview. Let me clarify first that 50 interviews include phone screening, where we don't do specific technical questions but rather just poke around what the candidate is looking for and whether they seem able to explain what they have been doing without drowning. As for the process we use, we are a hedge fund of 30 people, we have no HR, so I directly deal with head hunters. That means the numbers I gave are "raw". I see a lot of comments arguing whether it's even possible to assess technical skills during an interview, and overall spitting on whiteboard brain teasers. For the former, really, you need to be in the front row of hiring to understand it. I'm not talking about filtering candidates that can answer library specific trivia or solve red black tree removal on a white board here. I'm talking about senior Python developers that cannot remember the syntax of a for loop, data science specialists that cannot ELI5 the intuition of a linear regression. That's the degree of "low skill level" I'm talking about. I think a lot of people here are biased toward thinking the average programmer on the market should be the same skill level of their average colleague. This is Wrong. You are reading hacker news, you are very likely to be passioned and dedicated about what you are doing, you are most likely working in an above average company, surrounded with above average colleagues. Your perception of the average programmer is biased toward your own surroundings. Now I see that the whiteboard interview seems to be really dreaded. And man, do I feel you. I also used to hate them as an interviewee. But that does not mean they are all the same. When I do a whiteboard interview, I am perfectly aware that the candidate is obviously stressed, uncomfortable, and not at 100% of his potential. That's why the questions I ask are typically not too intellectually challenging. Some variations of the fizzbuzz mainly, along with a small exercice on recursivity in case the fizzbuzz is too easy. "Whiteboard interview" should not become a strawman for "24yo fresh grad throws B-tree inversion at you to feel superior". Really, the only thing that should be tested in these interviews is your programmer muscle memory. And from my experience, it does work.

cmrdporcupine 6y ago

Honestly, I question most interviewers ability to evaluate someone as low or high skill. I honestly don't think the testing works most of the time.

AshamedCaptain 6y ago
If you really believe so, then I think you are failing to grasp how low "low skill" truly happens to be.
- cmrdporcupine 6y ago
  Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.
  - NationalPark 6y ago
    I felt this way too until I was made to start giving interviews. However low a bar you're imagining, I assure you I've seen "strong on paper" candidates who failed to meet a lower one. I don't know if people are lying, or people cheated through school, or talked other people into doing their work at the jobs they claim to have had, but it's really astonishing how unable to write code they can be. However, the particularly insidious candidates are the ones who have developed a skill for talking about software/programming but can't actually write code no matter how much help or prodding they are given. As soon as you accidentally hire one of those, the case for technical interviews becomes a lot stronger.
    - song 6y ago
      I was going to write a similar comment when I saw yours. We've recently hired someone who was great on paper, was adept at talking about software/programming and was able to present some code he allegedly wrote and explain it. He seemed like a great fit based on the discussions but we hadn't actually given him a whiteboard interview. Once he joined the company he proceeded to actually be completely unable to write a single working piece of code. Everything he wrote needed to be reviewed and had major glaring issues. When confronted about it, he would say that he couldn't figure it out so decided to just commit his unfinished code. That guy was senior, had worked for 20 years and is really good at talking but when it comes to actually developing software, he is completely utterly incompetent.
      - ryandrake 6y ago
        I am constantly surprised at how many Brillant Paula Bean [1] developers are out there successfully interviewing, getting hired and BS-ing their way through jobs. I've always wondered if this is as prevalent in other industries outside of software. 1: https://thedailywtf.com/articles/The_Brillant_Paula_Bean https://thedailywtf.com/articles/The_Brillant_Paula_Bean
  - edanm 6y ago
    I don't know how many people saying otherwise would constitute sufficient evidence in your mind, but add me to the list of people that disagree with this sentiment. I've had candidates who couldn't code a loop. Not "did something suboptimal", I mean literally couldn't write a single line of code. I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk at length about them. But when given a task to do on the computer, given 2 hours alone to sit and code, couldn't do even the first part of the exercise - despite it being something you could literally copy and paste from the documentation that we gave them a link to!
- freeqaz 6y ago
  There is a reason that "FizzBuzz" is a meme! I love the expression, "Job candidates who can't seem to program their way out of a wet paper bag." It's too true. A quick search found the source article that I read years ago here[0]. :) 0: http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest
  - jjav 6y ago
    > http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest From that page: > We can't understand why so many people "fail" the Fizz-Buzz test unless we understand why it is "hard" (for them). But the article doesn't even talk about the environment, which is what it's all about. It's hard "for them" because they're being asked to write the code on a whiteboard, with a job/income on the line, with stress and anxiety dialed up to 11, with someone breathing down their neck watching, while expected to simultaneously provide cheerful ongoing commentary to "show how they think". Under those conditions, I totally believe close to 100% perfectly competent developers will fail at it. But of course it has nothing to do with the programming part. Most of us have heard of FizzBuzz while chillin at home reading articles and immediately thought "that can't be hard" and tried it and indeed it is laughably easy. So we can't understand how "they" could fail at it because we didn't experience it under interview hazing conditions. So the "them" is actually all of us. To me that is the key takeaway of FizzBuzz.
    - ciceryadam 6y ago
      In my case I failed at fizzbuzz because I was interviewing after spending a full day merging 2 versions of dbdumps into one, while getting rid of duplicate entries/foreign keys, etc. I could still do a pseudo code version of it, but I couldn't remember modulo function. At all.
Jach 6y ago
You're right to question it, but this is also why testing is so prevalent apart from the deluge of unqualified/barely qualified applicants. It's possible for a single person to spend an hour (perhaps over lunch) with prospective candidates and better evaluate them, with a corresponding better evaluation of the company by the candidate, without needing to do the multi-stage multi-test multi-people rigamarole big companies are addicted to. Similarly such people can usually detect resume BS better and whittle a list of 50 down to a shortlist of a few to spend that hour on each and come away with more than one good fit. But the skills needed to do that aren't widespread or taught or in many cases even acknowledged as existing. Hence tests, where when followed as a script can be given and scored by even the most disinterested programmer who'd rather be programming instead of doing their manager's job. Now you don't even need someone ok at resume BS detection to narrow the list, you can parallelize that 50 hours. Of course the tests are proxies and often aren't even scored objectively. And most tests aren't very good at proxying anything general (hence companies' tendencies to have several). There's a lot of problems that remain, our industry doesn't take hiring seriously. But testing and trying to test as early as possible have come to dominate for not totally unreasonable reasons, and persist at the large companies despite the well-known negative trade-offs. It's a startup's/small company's advantage to not copy bigco's interview processes.
hirundo 6y ago
Sometimes it's easy. We had a candidate who looked good on paper and sounded good in person. When it was time to start the screening test he asked to go to the bathroom. And never came back. We took that as a red flag.

gedy 6y ago

I think a big problem is companies and in house recruiters who reach out to experienced/settled engineers and first thing they want is send you through some hr / tech quiz pipeline. No. I need to hear what this is about and if it's something I'll bother jumping through hoops for. Your recruiter's quick calls are not cutting it and that is not the same as "applying".

C1sc0cat 6y ago

I am reading this correctly a short list of 50 for a single role?

claudeganon 6y ago
It’s completely insane if they’re interviewing 50 people per role. The filtering process is entirely broken if they’re doing that many. The most people I’ve ever interviewed for a job is 7.
- edanm 6y ago
  Do you have some context around that number? E.g. are you in a large company that pre-filters the pool for you? I ask because 50 is not completely unreasonable. I've had positions where we've had to interview dozens of candidates, in our small company. In larger companies, often someone else does some initial interviews though and that filters out candidates who e.g. can't code at all (sometimes - not always!).
  - claudeganon 6y ago
    7 was at a large enterprise software company. I don’t remember exactly how many phone screenings they did, but it was less than 20. I still thought it was too many. Like I said, I think if you have to interview that many, your filtering process is really broken further up the pipeline. You don’t know what you want, what the job really is, the or application process isn’t properly structured. Interviewing large numbers of people is also a huge liability unless you’re extremely consistent and well-documented in your hiring process (something which I’ve found to rarely be the case).
    - johnward 6y ago
      > You don’t know what you want, what the job really is, the or application process isn’t properly structured. I interviewed at Google. The position description versus what I was interviewed on were two worlds apart. Like the position mentioned front end CSS and HTML. I was grilled on SQL in two of the 4 interviews. This wasn't a SWE position, it was more of a client support role, but I was given a coding test. I did poorly on the test, but I still consider it difficult for a role that was not a SWE. It didn't even seem like Google knew what role they were hiring for they just wanted "someone technical" to do something. I left this process feeling pretty confused and turned-off at their hiring process and questioning if I really wanted to work at a place like that.

xtracto 6y ago

>On the other end, when I'm looking for someone to fill a position in my team, I will interview at the very least 50 candidates. I'll give you a pro-tip: Candidate Interview Packs. Cook up some Google Slides with the main info about the position, the company, the team, what you expect from the person, what you are looking for, the interview process, etc; beyond the dry JD that HR shares. Give it the personality of your (Engineering) team and generate a PDF that you can share with the 50+ candidates. It has worked for me in the past.

sumtechguy 6y ago

This is really why I use the 'easy' type questions (some variation of fizbuzz or something simple). A senior guy will crank it out in 5-10 mins. I then ask a question or two on how to improve it and a mini walk through of what they did and why. I also make it clear I sometimes get people who just can not do it but have the resume chops for it. I then usually spend the rest of the time digging on previous techs they have used, problems solved, etc. The annoying ones are dudes who want you to somehow do a big O proof of some NP complete problem, with tests, proper code, and in front of 3 people in 45 mins (with 5 left for you to ask any questions). For something you may have not touched in 20+ years. I do not want a guy who can create the proof. I want a guy who can explain it in plain English to the 3 other guys in the group and maybe take a few days to get it right and make the code easy enough to understand so when we have to change it in 8 months they can pick it back up.

stronglikedan 6y ago
+1 for fizzbuzz. It still amazes me how this simple little test can often weed out a largish portion of candidates early on.
- sumtechguy 6y ago
  I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something everyone can grasp but it is not something everyone knows about. Plus it is easily looked up and gamed. I try to pick something that has a few if conditions and a loop, which is what most people do. Bonus if it can be a 'refactor' style problem for the small walkthrough afterwards. But it is not necessary for that. If I were to make one up right now I would say something like 'given a string reverse the first half and move the second half to the front of the string and return the result'. There are enough little gotchas there to see if they have a feel for what can go wrong and loops and ifs. It also has an advantage that it is not easily looked up on the internet and pre-studied as fizzbuzz has been codegolfed on some discussions. The downside is it would probably burn a lot of time. So you need to budget your time with them accordingly. If I can talk someone into it I try the test out on them beforehand to see how long it would take. I want it to be quick. I just want someone who is competent and can explain what they did and has some relatable experience and can explain what they did there.

grumple 6y ago

If you're interviewing 50 candidates, your process is horrifically broken. As soon as you find an acceptable candidate, hire them. They don't have to be perfect; no hire will be, no matter how much time you spend. You're wasting company time and money.

DoofusOfDeath 6y ago
In case you're interested, there's a bit of mathematics related to this. It's called "The secretary problem" [0]. [0] https://en.wikipedia.org/wiki/Secretary_problem https://en.wikipedia.org/wiki/Secretary_problem
- grumple 6y ago
  Thanks! I've seen this before but forgot what it was called.

renewiltord 6y ago

Here's the funny thing. I've worked with recruiters where the candidates they supplied needed the tech screen upfront and recruiters where the sell call upfront was useful. Honestly, the latter guys are absolutely fire to work with. I think recruiting is like security engineering: 90% of the guys doing it are total rubbish so you just assume that's what it's like. But that last 10% are super good, and the top 1% are really freaking good. I remember when I first encountered a recruiting pipeline put together by a guy who was good at it. Literally every person I spoke to was a good engineer. We did tech-screen them, but only after the initial call where we talked to them about their interests and our company objectives. Literally every one of these engineers knew: * What sorts of problems they wanted to work on * What stage of company they wanted to work at (seed, series-A, ..., big established company) * What risk they were willing to take * What sort of team they wanted to work on This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot. Anyway, I was very impressed. Also, the fact that almost every one of them didn't bat an eye at the tech screen. You read some of the comments on HN/Reddit and you see that these guys are a cut above the standard dudes. Like, just the social nous. Way off the charts. On HN, people talk about an interviewer mis-sizing the problem: "Haha, so I told him I'd do it on a single SGI UV 300 with 3 TB of RAM. The interviewer got stuck. I got him.". These guys are like way better. If you mis-size, they'll just be like "Ah, okay, so you can get this done on a single machine these days, they have a lot of RAM, but that's trivial. AWS has the u24s for 24 TB or something. So let's say the problem is even bigger or that we want the other advantages of clusters" and they'll take it away. No chip on the shoulder. No insecurity. If some constraint doesn't make sense, they'll say "Okay, if we were doing this in prod, I'd push back on that, but let's say it's the case" and just go on. We didn't convert everyone - not everyone wants to work in our domain or wants to deal with the quirks of our team or whatever, but that's life. It was way more enjoyable as an interviewer.

yowlingcat 6y ago
> This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot. I think that's probably more the rub than anything. I never had a happier time being an interviewer than my time at hypergrowth startups. The sheer caliber of both candidates AND resource allotment towards landing them was far higher than what I was able to see in the BigCo environment. It made things a lot more pleasant.

TheFiend7 6y ago

I've been a software engineer for over 6 years and I still have to do 20+ interviews.

monadic2 6y ago

> That is to say, all things equal, the interviewer has most likely more incentive than the interviewee to go straight to the point, and thus perform a technical check early in the process. I would think that any "straight to the point" hiring process would be "straight to the point" because it avoided the technical interview process: A) there's not much you can do to entirely avoid problems with work performance and B) technical knowledge can only be sussed out so far in an interview, period, before actual work performance in the context you're hiring the person for can be evaluated.

jjav 6y ago

> I will interview at the very least 50 candidates. Why? IMO this is about an order of magnitude too many. I typically interview about 3-4 people, on rare occasions a few more. I've been interviewing candidates for about 25 years now. If your recruiter is sending you 50+ mismatched resumes for a role, get a better recruiter. But even in that case, you should notice and weed these out while reviewing the resumes yourself, before getting to the interview stage. I literally cannot imagine any scenario where I'd interview over 50 people for a role. Or even ten people. A few startups ago we had to grow the team from 20 people to ~120 in a year. Your approach would result in interviewing well over 5000 people in a year. That would be over 20 people a day, every single day, zero work getting done meanwhile! I suggest a re-think of your hiring strategy. > being obviously unfit after the first 10 minutes of a technical interview Which one is more likely: 1. Senior people who have built many successful products don't actually know how to do what they've done. or 2. Interview techniques that focus on skills unrelated to the job (e.g. whiteboard puzzles, algorithm trivial pursuit) have an inordinately high false negative rate.

Galanwe 6y ago

I see a lot of comments asking for clarifications on the numbers, the process, and what is being tested during the interview. Let me clarify first that 50 interviews include phone screening, where we don't do specific technical questions but rather just poke around what the candidate is looking for and whether they seem able to explain what they have been doing without drowning. As for the process we use, we are a hedge fund of 30 people, we have no HR, so I directly deal with head hunters. That means the numbers I gave are "raw". I see a lot of comments arguing whether it's even possible to assess technical skills during an interview, and overall spitting on whiteboard brain teasers. For the former, really, you need to be in the front row of hiring to understand it. I'm not talking about filtering candidates that can answer library specific trivia or solve red black tree removal on a white board here. I'm talking about senior Python developers that cannot remember the syntax of a for loop, data science specialists that cannot ELI5 the intuition of a linear regression. That's the degree of "low skill level" I'm talking about. I think a lot of people here are biased toward thinking the average programmer on the market should be the same skill level of their average colleague. This is Wrong. You are reading hacker news, you are very likely to be passioned and dedicated about what you are doing, you are most likely working in an above average company, surrounded with above average colleagues. Your perception of the average programmer is biased toward your own surroundings. Now I see that the whiteboard interview seems to be really dreaded. And man, do I feel you. I also used to hate them as an interviewee. But that does not mean they are all the same. When I do a whiteboard interview, I am perfectly aware that the candidate is obviously stressed, uncomfortable, and not at 100% of his potential. That's why the questions I ask are typically not too intellectually challenging. Some variations of the fizzbuzz mainly, along with a small exercice on recursivity in case the fizzbuzz is too easy. "Whiteboard interview" should not become a strawman for "24yo fresh grad throws B-tree inversion at you to feel superior". Really, the only thing that should be tested in these interviews is your programmer muscle memory. And from my experience, it does work.