4 ms·

> I'm honestly not sure what I'd replace it with if I were. Just to theorize: how about having the interviewee write a narrowly scoped toy project that's relev

> I'm honestly not sure what I'd replace it with if I were. Just to theorize: how about having the interviewee write a narrowly scoped toy project that's relevant to the position? (Edit: On site, as a replacement for white boarding.) A JS to-do app for a front-end engineer, for instance. Just a short thing you and the candidate can attack together in a couple hours. The candidate can write "normal" code, google things, clarify requirements, use their own architecture/patterns/style to reach the solution, etc. You could even add/change a requirement midway through the session, too. That would be realistic, and test for brittleness (and maybe be mean). I don't interview people, so this might be hopelessly naive, or maybe untenable for some types of positions. But that interview process strikes me as a far more representative microcosm of an actual job than regurgitating LeetCode solutions or hardcore algo arcana.

908B64B197 6y ago
> Just a short thing you and the candidate can attack together in a couple hours Unless your hiring pipeline is absolutely perfect (you pretty much get great candidates all the time and almost no bad ones) this doesn't scale at all.
- a_wild_dandan 6y ago
  Could you explain why it scales worse than current typical interview sessions?
  - hnrodey 6y ago
    On one hand, it would currently double the time commitment from me (and my interviewing peers) per candidate. That would be a tough pill to swallow. Interview processes are designed mostly for the employer, not the candidate. That's just the reality.
  - decafninja 6y ago
    Because a candidate can grind leetcode and prepare for a huge number of companies. On the other hand, something like a homework assignment is typically good for a single company, and if you fail, it's time and effort and emotional energy down the toilet.
    - 908B64B197 6y ago
      Homework are great if you: Are extremely prestigious or have compensation clearly above market rates. Candidates only have so much time to dedicate to homework so they will sort companies and work on homework assignments from top to bottom. Homework are easy to grade (some of that can be automated!) and low commitment from the employer side. But that low commitment sends a signal that the candidate isn't really valued. Having an on-site with engineers sends a much better signal as it tells the candidate he's worthy of discussing with a real engineer on company time rather than some gradings software. Of course, if your recruiting pipeline is very poor (low signal to noise ratio, majority of applicants can't code) then sure, weed out with a homework assignment.
      - decafninja 6y ago
        Agree 100%. I've decided to just reject any company that requires a homework assignment unless it's a FAANG or nearly FAANG level of prestige and/or comp. Otherwise, it really is a waste of time when there are many, many, companies that do not require homework.
    - a_wild_dandan 6y ago
      I think I misled you. I meant for the toy project idea to be an on-site, swap out replacement for a typical white board session. The time commitment should remain unchanged. Maybe I should edit the original comment. Sorry!
    - ek750 6y ago
      I've done tons of interviews over the past 10 years. It was surprising to me the number of times the experience on a resume didn't line up with what the interviewee showed through conversation and small whiteboard exercises. I get that it's not very real-world representative, and that's why homework is used instead by some companies. Maybe the answer is to give the applicant a choice? Either be prepared to convince me you know what you claim, or demonstrate it with a take-home problem. Personally, I'd prefer a day of in-person-pair programming as part of the interview. I'd get a better feel for the team and their workflows. If it's a total horror show, it's good to know up front :)
  - 908B64B197 6y ago
    Couple of hours vs 30-40 minutes. I prefer to have multiple short interviews with different engineers rather than a single multi-hour long one with only one engineer. You get better feedback and it helps against bias. Not only that but a "toy JS app" implies the candidate knows JS at all. If it's college recruiting, you are better sticking with algorithms since you know that they know it.
    - a_wild_dandan 6y ago
      To be clear, the goal is to watch the candidate build something using the prerequisite skills expected for the position. I'm not prescribing 3 hour sessions, or JavaScript. Target a 45 minute session. Target whatever tools, languages, etc are expected for the role. Maybe that means being language agnostic. Whatever is appropriate. Watching folks make something -- for any significant duration -- is perhaps a better estimator of a candidate's genuine job ability than testing how well they approximate an algorithm textbook. Well...that's the assumption, anyway.
      - 908B64B197 6y ago
        Now I get it. Thanks
city41 6y ago
I worked at a company that did this. This company always pair programmed. So the interview took place at a pairing station. We gave the candidate a choice of about 10 toy problems to solve, and then we coded for 2 hours. They could use Google, their preferred IDE, whatever they wanted. Of all the companies I have worked at, this was by far my favorite interviewing technique. But, I think it works best when you pair with the candidate. So if pairing at your company is not done, it might not be a good fit.

908B64B197 6y ago

> Just a short thing you and the candidate can attack together in a couple hours Unless your hiring pipeline is absolutely perfect (you pretty much get great candidates all the time and almost no bad ones) this doesn't scale at all.

a_wild_dandan 6y ago
Could you explain why it scales worse than current typical interview sessions?
- hnrodey 6y ago
  On one hand, it would currently double the time commitment from me (and my interviewing peers) per candidate. That would be a tough pill to swallow. Interview processes are designed mostly for the employer, not the candidate. That's just the reality.
- decafninja 6y ago
  Because a candidate can grind leetcode and prepare for a huge number of companies. On the other hand, something like a homework assignment is typically good for a single company, and if you fail, it's time and effort and emotional energy down the toilet.
  - 908B64B197 6y ago
    Homework are great if you: Are extremely prestigious or have compensation clearly above market rates. Candidates only have so much time to dedicate to homework so they will sort companies and work on homework assignments from top to bottom. Homework are easy to grade (some of that can be automated!) and low commitment from the employer side. But that low commitment sends a signal that the candidate isn't really valued. Having an on-site with engineers sends a much better signal as it tells the candidate he's worthy of discussing with a real engineer on company time rather than some gradings software. Of course, if your recruiting pipeline is very poor (low signal to noise ratio, majority of applicants can't code) then sure, weed out with a homework assignment.
    - decafninja 6y ago
      Agree 100%. I've decided to just reject any company that requires a homework assignment unless it's a FAANG or nearly FAANG level of prestige and/or comp. Otherwise, it really is a waste of time when there are many, many, companies that do not require homework.
  - a_wild_dandan 6y ago
    I think I misled you. I meant for the toy project idea to be an on-site, swap out replacement for a typical white board session. The time commitment should remain unchanged. Maybe I should edit the original comment. Sorry!
  - ek750 6y ago
    I've done tons of interviews over the past 10 years. It was surprising to me the number of times the experience on a resume didn't line up with what the interviewee showed through conversation and small whiteboard exercises. I get that it's not very real-world representative, and that's why homework is used instead by some companies. Maybe the answer is to give the applicant a choice? Either be prepared to convince me you know what you claim, or demonstrate it with a take-home problem. Personally, I'd prefer a day of in-person-pair programming as part of the interview. I'd get a better feel for the team and their workflows. If it's a total horror show, it's good to know up front :)
- 908B64B197 6y ago
  Couple of hours vs 30-40 minutes. I prefer to have multiple short interviews with different engineers rather than a single multi-hour long one with only one engineer. You get better feedback and it helps against bias. Not only that but a "toy JS app" implies the candidate knows JS at all. If it's college recruiting, you are better sticking with algorithms since you know that they know it.
  - a_wild_dandan 6y ago
    To be clear, the goal is to watch the candidate build something using the prerequisite skills expected for the position. I'm not prescribing 3 hour sessions, or JavaScript. Target a 45 minute session. Target whatever tools, languages, etc are expected for the role. Maybe that means being language agnostic. Whatever is appropriate. Watching folks make something -- for any significant duration -- is perhaps a better estimator of a candidate's genuine job ability than testing how well they approximate an algorithm textbook. Well...that's the assumption, anyway.
    - 908B64B197 6y ago
      Now I get it. Thanks

city41 6y ago

I worked at a company that did this. This company always pair programmed. So the interview took place at a pairing station. We gave the candidate a choice of about 10 toy problems to solve, and then we coded for 2 hours. They could use Google, their preferred IDE, whatever they wanted. Of all the companies I have worked at, this was by far my favorite interviewing technique. But, I think it works best when you pair with the candidate. So if pairing at your company is not done, it might not be a good fit.