I worked at MemSQL, and I got this question when I interviewed. I also gave this question interviewing candidates many times. Interacting with someone while they poke around unfamiliar code really tells you a lot about them. Most of their time is spent reading code, the actual implementation of this feature is only a handful of lines. That tested extremely well for working on the database engine: you had to get up to speed on a huge C++ codebase to accomplish much of anything.
The question has a ton of flexibility when candidates are having trouble getting started. I rarely faulted people for not knowing things you had to know purely by having seen them before. For example, most people didn’t recognize the DTRACE_PROBE macros, so I steered them away from those if they started digging too deep into them. By the time I was there we had a decent playbook of irrelevant things to steer candidates away from, so candidates were only given 1 hour, not 3.
I also held the record completion time for this question of 11 minutes, although I may have been beaten since I left in 2018.
I’m not too fond of coding challenges. People can look at my github and see I can code at a glance. This will needlessly filter out people who are not privvy to the project, are nervous because of the interview situation, or worst of all are bad at live coding (which is unusual to do on the job).
I usually have one question when I interview people for coding positions. I give that question out beforehand and am happy to let applicants prepare for it. The question is: What piece of code are you most proud of (Feel free to brag)?
A toy bcrypt hash cli tool I wrote in Java 7 years ago. I haven’t programmed professionally in Java for… 7 years.
A Ruby gem for pretty printing tables that I literally don’t remember writing, definitely didn’t publish, and surprisingly has a README and basic tests. I have never programmed professionally in Ruby.
A private repo for a private guild administration mod for an MMO I used to play. Written in some truly abhorrent Lua, containing numerous bug fixes of the form “if this specific case happens, twiddle some state so wrong things don’t happen.” Almost all of these bugs could be fixed by refactoring the code into something sensible. I have only briefly programmed professionally in Lua, before rewriting the application in Go because no one else wanted to maintain a Lua/C++ project. The repo is private anyway, thankfully.
None of these things are remotely representative of my abilities. I have significantly more skill and experience writing C++ (most of my career). I’m currently working as an SRE writing lots of bash and Terraform.
Maybe coding challenges are bad. But GitHub is absolute garbage for gauging anything about many developers.
I’m also not fond of coding challanges, but if it there has to be one, I’d much rather take one as described in these article than the contrived, shuffle-things-around-in-arrays-in-two-hours-and-hope-you-don’t-get-stuck-on-some-edge-case or make-some-service-from-scratch-and-hope-it-matches-the-tradeoffs-and-style-preferences-the-reviewer-silently-expects kind.
I think your question will also have a few people who won’t like it. For example: fresh graduates who aren’t enthusiasts (proud of code?), people with wildly different experience (I’ve got 10 really lines shitty of AutoIT that keep bringing me money, probably not what you want to hear), people in jobs they can’t talk about in details (obvious). It’s a cool question for many people, but I wouldn’t want to miss out on the rest.
When I interviewed at a UK gamedev studio as a fresh graduate back in… oof, 2006, way to make me feel old… they had a coding part of the interview process that was similar to this in spirit at least. It was a simple, purpose-created clone of the game Breakout, and there were a bunch of deliberate problems with the code in increasing difficulty from trivial typos, more complex compile errors, runtime crashes all the way to logic bugs. Finally, it asked you to finish off some partially implemented feature. (scoring maybe?)
Not having the giant codebase to trawl through meant this could be accomplished somewhat quicker (I think the soft limit was 1 hour, but they were happy to let you finish if you were in the middle of something), and although it wasn’t live on-site, there was nobody watching me, which probably helps with some people’s interview anxiety/nerves. I don’t remember, but I assume you could ask for help if you got really stuck, and I think I walked through my changes with the interviewer afterwards, although IIRC that was pretty short and straightforward. (Probably mainly because I actually finished the challenge.)
This coding challenge always seemed so much more sensible to me than either whiteboard coding or larger from-scratch take-home projects, for all the frequently-cited downsides. Seems to me that candidates should be offered the option between this or walking the interviewer through one of their own projects if they happen to have an appropriate one handy. (Insisting upon the latter, or worse, judging their GitHub profile, filters out way too many good people.) You can easily get through the whole process with a candidate in half a day with one of these, which seems a reasonable amount of time to demand.
(FWIW, I passed the interview. Too well, however: they were looking for someone more junior; they did pass me along to a sister studio though, which had a separate, IMO not as good, interview process, which I also passed, and where I did land a job.)
While this question is on the better side of interview questions I think it’s important to understand why, it helps drive productive conversation between the interviewer and interviewee.
Personally I’m not a fan of coding-challenge style or taking the interviewee any further outside of their daily comfort zone than an interview already does. I personally like to talk about past projects / personal projects until get the sense of greater interest about some topic. I then ask questions to gain some minimal level of understanding, and ask for some change of that system. My hopes are that this shows the candidate in their best light, puts them in a comfort zone (they know more about the problem than I do), and helps to find often idea’s the held while they worked at a previous company or personal project. Something about this always felt right and the response seems to be very positive from those on both side of it.
When I was starting my career, I’ve failed a few interviews because of random coding challenges that involved either some serious knowledge on a niche field, or depended on having an Eureka moment. I was feeling quite demoralised… The solution was to solve a lot of exercises on spoj (not sure it’s still up, but it was the hackerrank of those days) and manage to pass for the next interviews. For a job I was considered to be some superstar hire for getting the all time highest rating in the coding challenges interview (solving 5 problems in 2 hours). Was I superstar? No. I just knew how to solve all 5 because I knew the ideas by solving similar things in the previous weeks.
When I became an interviewer myself I’ve tried to end this strategy for new hires, but the resistance was so big I couldn’t change a thing. At least I’ve picked easier problems for the candidates and put more emphasis on other things.
I really like it. It actually tests what you expect on the job. If you need someone to hit the ground running, it seems like a really good option. I’ve done something similar in the past, but also quite liked a “do it on your own time” alternative: read rows from CSV, insert into SQL, make it production quality, whatever language. It’s a trivial task, but you could see who cared about encoding, checked for errors, did streaming instead of reading while file, wrote documentation, read config file, etc.
I can’t judge if it’s a good one, but it absolutely prefers a certain type of coder. Bugs notwithstanding I guess I would’ve done great, as that’s about how 90% of my non-bug open source contributions work. The thing is that I’m also not sure if it maps well to software inside corporate structures. The main point being “you can explain the problem in 5 minutes because it doesn’t depend on 5 other things and there are tests AND you can just interactively test it with telnet? Ridiculous.”
I worked at MemSQL, and I got this question when I interviewed. I also gave this question interviewing candidates many times. Interacting with someone while they poke around unfamiliar code really tells you a lot about them. Most of their time is spent reading code, the actual implementation of this feature is only a handful of lines. That tested extremely well for working on the database engine: you had to get up to speed on a huge C++ codebase to accomplish much of anything.
The question has a ton of flexibility when candidates are having trouble getting started. I rarely faulted people for not knowing things you had to know purely by having seen them before. For example, most people didn’t recognize the
DTRACE_PROBEmacros, so I steered them away from those if they started digging too deep into them. By the time I was there we had a decent playbook of irrelevant things to steer candidates away from, so candidates were only given 1 hour, not 3.I also held the record completion time for this question of 11 minutes, although I may have been beaten since I left in 2018.
I’m not too fond of coding challenges. People can look at my github and see I can code at a glance. This will needlessly filter out people who are not privvy to the project, are nervous because of the interview situation, or worst of all are bad at live coding (which is unusual to do on the job).
I usually have one question when I interview people for coding positions. I give that question out beforehand and am happy to let applicants prepare for it. The question is: What piece of code are you most proud of (Feel free to brag)?
My GitHub has virtually nothing on it:
None of these things are remotely representative of my abilities. I have significantly more skill and experience writing C++ (most of my career). I’m currently working as an SRE writing lots of bash and Terraform.
Maybe coding challenges are bad. But GitHub is absolute garbage for gauging anything about many developers.
I’m also not fond of coding challanges, but if it there has to be one, I’d much rather take one as described in these article than the contrived, shuffle-things-around-in-arrays-in-two-hours-and-hope-you-don’t-get-stuck-on-some-edge-case or make-some-service-from-scratch-and-hope-it-matches-the-tradeoffs-and-style-preferences-the-reviewer-silently-expects kind.
I think your question will also have a few people who won’t like it. For example: fresh graduates who aren’t enthusiasts (proud of code?), people with wildly different experience (I’ve got 10 really lines shitty of AutoIT that keep bringing me money, probably not what you want to hear), people in jobs they can’t talk about in details (obvious). It’s a cool question for many people, but I wouldn’t want to miss out on the rest.
When I interviewed at a UK gamedev studio as a fresh graduate back in… oof, 2006, way to make me feel old… they had a coding part of the interview process that was similar to this in spirit at least. It was a simple, purpose-created clone of the game Breakout, and there were a bunch of deliberate problems with the code in increasing difficulty from trivial typos, more complex compile errors, runtime crashes all the way to logic bugs. Finally, it asked you to finish off some partially implemented feature. (scoring maybe?)
Not having the giant codebase to trawl through meant this could be accomplished somewhat quicker (I think the soft limit was 1 hour, but they were happy to let you finish if you were in the middle of something), and although it wasn’t live on-site, there was nobody watching me, which probably helps with some people’s interview anxiety/nerves. I don’t remember, but I assume you could ask for help if you got really stuck, and I think I walked through my changes with the interviewer afterwards, although IIRC that was pretty short and straightforward. (Probably mainly because I actually finished the challenge.)
This coding challenge always seemed so much more sensible to me than either whiteboard coding or larger from-scratch take-home projects, for all the frequently-cited downsides. Seems to me that candidates should be offered the option between this or walking the interviewer through one of their own projects if they happen to have an appropriate one handy. (Insisting upon the latter, or worse, judging their GitHub profile, filters out way too many good people.) You can easily get through the whole process with a candidate in half a day with one of these, which seems a reasonable amount of time to demand.
(FWIW, I passed the interview. Too well, however: they were looking for someone more junior; they did pass me along to a sister studio though, which had a separate, IMO not as good, interview process, which I also passed, and where I did land a job.)
Birds are singing outside my window. I just spent a couple of hours doing quiet, peaceful programming for the sake of it. Thank you for sharing this!
While this question is on the better side of interview questions I think it’s important to understand why, it helps drive productive conversation between the interviewer and interviewee.
Personally I’m not a fan of coding-challenge style or taking the interviewee any further outside of their daily comfort zone than an interview already does. I personally like to talk about past projects / personal projects until get the sense of greater interest about some topic. I then ask questions to gain some minimal level of understanding, and ask for some change of that system. My hopes are that this shows the candidate in their best light, puts them in a comfort zone (they know more about the problem than I do), and helps to find often idea’s the held while they worked at a previous company or personal project. Something about this always felt right and the response seems to be very positive from those on both side of it.
When I was starting my career, I’ve failed a few interviews because of random coding challenges that involved either some serious knowledge on a niche field, or depended on having an Eureka moment. I was feeling quite demoralised… The solution was to solve a lot of exercises on spoj (not sure it’s still up, but it was the hackerrank of those days) and manage to pass for the next interviews. For a job I was considered to be some superstar hire for getting the all time highest rating in the coding challenges interview (solving 5 problems in 2 hours). Was I superstar? No. I just knew how to solve all 5 because I knew the ideas by solving similar things in the previous weeks.
When I became an interviewer myself I’ve tried to end this strategy for new hires, but the resistance was so big I couldn’t change a thing. At least I’ve picked easier problems for the candidates and put more emphasis on other things.
I really like it. It actually tests what you expect on the job. If you need someone to hit the ground running, it seems like a really good option. I’ve done something similar in the past, but also quite liked a “do it on your own time” alternative: read rows from CSV, insert into SQL, make it production quality, whatever language. It’s a trivial task, but you could see who cared about encoding, checked for errors, did streaming instead of reading while file, wrote documentation, read config file, etc.
I used a similar test using Redis instead of memcached at a previous startup, and I can confirm it worked really well.
I can’t judge if it’s a good one, but it absolutely prefers a certain type of coder. Bugs notwithstanding I guess I would’ve done great, as that’s about how 90% of my non-bug open source contributions work. The thing is that I’m also not sure if it maps well to software inside corporate structures. The main point being “you can explain the problem in 5 minutes because it doesn’t depend on 5 other things and there are tests AND you can just interactively test it with telnet? Ridiculous.”