3 ms·

This seems like a better way to evaluate real-world coding skills. Did you use it in a standard 45-60 min interview or as a take home problem? It seems like it'

This seems like a better way to evaluate real-world coding skills. Did you use it in a standard 45-60 min interview or as a take home problem? It seems like it'd take a decent amount of time to read the requirements and just introduce the task.

PaulRobinson 3y ago
Take home and “please time box it to maybe an hour maximum, you’re probably doing a load of interviews and tech tests at the moment, so you don’t need to finish: I just want to see your approach”. In-person time I used to like to ask a question I got from here: “Tell me about your favourite coding work or side project”. We’d then dig into choices, trade offs, obstacles and how they got around them. My favourite answer to this was “an OpenGL implementation for the X Window protocol which I wrote in Common Lisp”. Just getting through the first layer of “Why [x]?”, took 15 minutes and we spent an hour talking about all the facets. Hired him, was a superb colleague.
- kaashif 3y ago
  "Please timebox to an hour" is a bit dodgy though. If one candidate really does that, but the rest give it an extra 2 or 3 hours, that 1 hour candidate will probably be at a disadvantage.
  - neon_electro 3y ago
    Thank you for mentioning this. I always find myself going further back and forth with employers who allow a take-home exercise but ask that it be time-boxed nonetheless; it's difficult to try to unpack how they're trying to communicate what kind of time pressure a role experiences, and that if I took longer than their expected time box, does that look bad just because I needed some more time to understand the problem?
    - remich 3y ago
      I don't think most employers are out there looking at the timestamps on your commits to see if you really completed it within the timebox or not -- I certainly wouldn't. I don't think that candidates who spend less time or turn in incomplete take homes are necessarily at a disadvantage. Sooo much can be discerned from a take home even if it's not finished. I can evaluate a candidate's familiarity with modern syntax, how they organize functions, how readable their code is, whether or not they used ChatGPT/CoPilot or copy/pasted from an online tutorial (surprisingly easy to discern when you're evaluating many submissions), and so on. All of that tells me a lot about how well someone functions as an engineer, as well as what level they're operating at, and it doesn't require the completion of the take home problem.
      - neon_electro 3y ago
        Thanks for sharing your take. I wish I came across interviewers like yourself in the last 18 months of job searching.
  - PaulRobinson 3y ago
    I often ask for them to version control and send me a zip of the git repo, so I can look at commit histories. Yes, they can fake that, sure, but I can normally tell a lot about a dev from that, and actually if I see 4-5 commits over an hour perhaps with some wrong turns, that pushes the candidate up in my estimation than somebody with 1-2 commits that don't tell a story, but does show a complete solution - which is most likely what would happen if you edited history a bit.
    - kaashif 3y ago
      When I'm actually writing code and hashing out a solution over the course of a single hour in my job, I'm not going to commit the wrong turns. What you're really asking for is a candidate to spend extra time inventing a convincing git history. I really think the only way this actually works is if the problem is on a page which you can only view after you start a timer or something. Or do it on site and watch them. This is all high pressure but if you really want to time box, there can't be a way around it.
remich 3y ago
In a current hiring loop my company is doing for a senior, we have a take home divided into a series of steps, with explicit instructions that say that completion of the entire exercise is not necessary to advance (and we mean it). The take home serves two purposes: (1) should the candidate progress to the in person interviews? (2) if the candidate stumbles in the in person coding, can I deduce from the take home that they do actually know what they're doing, and the stumbling was a side effect of interview anxiety? I can tell a lot even from an incomplete take home, about whether someone is likely to do well on the in person interviews, but I mostly find it extremely valuable for (2), as a tiebreaker. It hasn't happened yet in this cycle, but I can imagine a situation where someone turned in a fantastic take home and then brain farted during the in person coding, and, thanks to the take home, got hired.

PaulRobinson 3y ago

Take home and “please time box it to maybe an hour maximum, you’re probably doing a load of interviews and tech tests at the moment, so you don’t need to finish: I just want to see your approach”. In-person time I used to like to ask a question I got from here: “Tell me about your favourite coding work or side project”. We’d then dig into choices, trade offs, obstacles and how they got around them. My favourite answer to this was “an OpenGL implementation for the X Window protocol which I wrote in Common Lisp”. Just getting through the first layer of “Why [x]?”, took 15 minutes and we spent an hour talking about all the facets. Hired him, was a superb colleague.

kaashif 3y ago
"Please timebox to an hour" is a bit dodgy though. If one candidate really does that, but the rest give it an extra 2 or 3 hours, that 1 hour candidate will probably be at a disadvantage.
- neon_electro 3y ago
  Thank you for mentioning this. I always find myself going further back and forth with employers who allow a take-home exercise but ask that it be time-boxed nonetheless; it's difficult to try to unpack how they're trying to communicate what kind of time pressure a role experiences, and that if I took longer than their expected time box, does that look bad just because I needed some more time to understand the problem?
  - remich 3y ago
    I don't think most employers are out there looking at the timestamps on your commits to see if you really completed it within the timebox or not -- I certainly wouldn't. I don't think that candidates who spend less time or turn in incomplete take homes are necessarily at a disadvantage. Sooo much can be discerned from a take home even if it's not finished. I can evaluate a candidate's familiarity with modern syntax, how they organize functions, how readable their code is, whether or not they used ChatGPT/CoPilot or copy/pasted from an online tutorial (surprisingly easy to discern when you're evaluating many submissions), and so on. All of that tells me a lot about how well someone functions as an engineer, as well as what level they're operating at, and it doesn't require the completion of the take home problem.
    - neon_electro 3y ago
      Thanks for sharing your take. I wish I came across interviewers like yourself in the last 18 months of job searching.
- PaulRobinson 3y ago
  I often ask for them to version control and send me a zip of the git repo, so I can look at commit histories. Yes, they can fake that, sure, but I can normally tell a lot about a dev from that, and actually if I see 4-5 commits over an hour perhaps with some wrong turns, that pushes the candidate up in my estimation than somebody with 1-2 commits that don't tell a story, but does show a complete solution - which is most likely what would happen if you edited history a bit.
  - kaashif 3y ago
    When I'm actually writing code and hashing out a solution over the course of a single hour in my job, I'm not going to commit the wrong turns. What you're really asking for is a candidate to spend extra time inventing a convincing git history. I really think the only way this actually works is if the problem is on a page which you can only view after you start a timer or something. Or do it on site and watch them. This is all high pressure but if you really want to time box, there can't be a way around it.

remich 3y ago

In a current hiring loop my company is doing for a senior, we have a take home divided into a series of steps, with explicit instructions that say that completion of the entire exercise is not necessary to advance (and we mean it). The take home serves two purposes: (1) should the candidate progress to the in person interviews? (2) if the candidate stumbles in the in person coding, can I deduce from the take home that they do actually know what they're doing, and the stumbling was a side effect of interview anxiety? I can tell a lot even from an incomplete take home, about whether someone is likely to do well on the in person interviews, but I mostly find it extremely valuable for (2), as a tiebreaker. It hasn't happened yet in this cycle, but I can imagine a situation where someone turned in a fantastic take home and then brain farted during the in person coding, and, thanks to the take home, got hired.