I'm going through the interview process this week at two different companies. One of the companies I found through an ad on Stack Overflow whereby they publish two programming "exercises/puzzles" with the opportunity to earn $100 for a correct answer to each puzzle ($200 total for two correct answers). While I spent more than eight hours on both puzzles, I found them to be thought provoking and I learned stuff in the process so I don't feel like I wasted any time and I got a check in the mail for $200. My code was reviewed by their dev staff so they had immediate feedback on my programming ability and high confidence to bring me in for an on-site interview. I like this process and consider it worthwhile.
On asking job candidates to code
41–50 of 524 posts
Re: On asking job candidates to code
#42> As brain-dead as I was after eight hours at my project, [..] Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice? If you apply to five jobs, you're expected to spend an entire unpaid work week writing code that doesn't benefit anyone? If a company receives 20 applicants, their ideal candidate selection wastes a collective work month? I don't really…
I'm helping hire developers here at HelloFresh and I thought of this a lot. A surprising amount of people don't maintain a very impressive public profile (me included, tbh). These people need the opportunity to showcase their skills and the only way to do so is by spending some time coding a nice solution. We try to minimize the candidate's overhead by providing general guidance in the challenges we issue (like "plea…
Why not just ask them?
You're on the phone with them, you can ask them if they'd prefer a little challenge to showcase their skills, or whether they'd like to provide a portfolio example instead.
Maybe a bright self-taught college student switching tracks into software would pick #1, a parent switching jobs would pick #2.
Re: On asking job candidates to code
#43Like the author, having run a hiring program for several years based on coding challenges designed to mimic the work the team does (ie, work sample tests), I do not understand why any tech company does developer hiring in any other way. I particularly like how this team iterated on their uploader problem, abstracting it out to a socket server and providing a test suite for it. Reacting to ambiguity by abstracting the…
> (ie, work sample tests), I do not understand why any tech company does developer hiring in any other way. Because every method of hiring has its own biases and tradeoffs. Requiring work samples biases against programmers who aren't interested in doing a "homework assignment". For example, I don't enjoy whiteboard interviews but I'd rather write some fragments in front of the interviewer and "think out loud" instead…
It's easy to be selective. I can ask all comers with a degree to roll three dice, and if they don't roll three sixes, I consider them unworthy. Only about 0.5% of candidates will pass. That's a pretty selective first screening, isn't it?
Selectivity is only good if it selects for traits you want, and, in practice, what you want is not a uniform skillset. So being selective for one trait, any trait, is already a bad idea.
Even the basics of the interview format make a difference. At other companies, all coding interviews are timed at 45 minutes or so, including the problem statement. It's a bit like going to an episode of Chopped. It's certainly selecting for 'can you think under pressure' along with 'are you friendly enough that your interviewer will help you when you are getting something wrong without docking your score'. But that's not good for a careful candidate that is trying to build sturdy, reliable code. So guess what: The company's codebase has few tests, things fail often when deployed to production, and reliability is a problem. It's not that they are willingly selecting against careful programmers, but it's a consequence of the interview process.
The moment you are hiring a lot of people, and you think you have a single model that works, you are hiring from a cookie cutter, and you'll get gingerbread men.
Re: On asking job candidates to code
#44Earlier quoted context omitted.
The problem is: Writing good resumes and having a lot of experience with programming is a good heuristic for "experience" and "knows how to play the game" but not meaningfully useful for "excellent at programming". Work-sample tests measure the latter. A worker's experience is a heuristic for programming skill, but a heuristic of a heuristic is like an average of a set of averages: Useless.
That's what probation periods are for. Use them.
What do you mean by probation periods? Something like...
"Hi, I'd like to ask you to work for a very temporary contract with us so, if it doesn't work out, you have to scramble to find more work and maybe risk homelessness."
Re: On asking job candidates to code
#45Earlier quoted context omitted.
> (ie, work sample tests), I do not understand why any tech company does developer hiring in any other way. Because every method of hiring has its own biases and tradeoffs. Requiring work samples biases against programmers who aren't interested in doing a "homework assignment". For example, I don't enjoy whiteboard interviews but I'd rather write some fragments in front of the interviewer and "think out loud" instead…
> For a company like Google Inc who is more selecitve than Harvard University Nitpick, but I'd love to see a citation on that. Google, like every technology company on the planet (modulo a small error value) goes to great lengths to recruit and hires lots and lots of people.
Part of the reason why is that it's super-easy to apply to jobs online. With just a couple of clicks (especially via LinkedIn) you can apply for whatever you find listed. This is an area where Taleo & similar provide enough friction to make it somewhat painful comparatively. So, you end up with thousands of people submitted applications for each of the positions Google lists. Most are not serious candidates (or at least worth seriously considering).
Re: On asking job candidates to code
#46Earlier quoted context omitted.
Just to play devil's advocate, being excellent at programming is also only a heuristic for working as a professional programmer.
Sure, but it's O(n) rather than O(n^2). Hiring decisions are hard to generalize, because different companies have different needs at different times.
Which makes it extra frustrating that hiring practices are the most often cargo-culted practices in this industry. I feel like the root of hiring problems is that most companies know neither what they need or how to identify those features in a candidate.
Re: On asking job candidates to code
#47Earlier quoted context omitted.
I'm helping hire developers here at HelloFresh and I thought of this a lot. A surprising amount of people don't maintain a very impressive public profile (me included, tbh). These people need the opportunity to showcase their skills and the only way to do so is by spending some time coding a nice solution. We try to minimize the candidate's overhead by providing general guidance in the challenges we issue (like "plea…
Why not just ask them? You're on the phone with them, you can ask them if they'd prefer a little challenge to showcase their skills, or whether they'd like to provide a portfolio example instead. Maybe a bright self-taught college student switching tracks into software would pick #1, a parent switching jobs would pick #2.
This sounds reasonable.
"We ask that you provide:
1) an implementation of this sample project (estimated 8 hours time).
2) a work sample that meets the following criteria (same criteria we are looking for in the sample project)"
Re: On asking job candidates to code
#48I think a coding test is the wrong approach. Typically a coding test is too simple to be meaningful, or too difficult to be practical.
Instead I would have a Mock PR in a github style discussion forum. Have it be a contrived example of some things that could be improved or some things that could spark really good discussion. Give the mock PR link to the candidate and ask them to Peer review the code. Make the discussion and comments of the the candidate the basis for which you determine their aptitude. If they have a lot of depth in their critique then you can be relatively confident how they would interact with the team in a real work scenario.
Re: On asking job candidates to code
#49Earlier quoted context omitted.
Sure, but it's O(n) rather than O(n^2). Hiring decisions are hard to generalize, because different companies have different needs at different times.
Which makes it extra frustrating that hiring practices are the most often cargo-culted practices in this industry. I feel like the root of hiring problems is that most companies know neither what they need or how to identify those features in a candidate.
Sounds like a lucrative itch to scratch.
Re: On asking job candidates to code
#50> As brain-dead as I was after eight hours at my project, [..] Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice? If you apply to five jobs, you're expected to spend an entire unpaid work week writing code that doesn't benefit anyone? If a company receives 20 applicants, their ideal candidate selection wastes a collective work month? I don't really…
I interpreted that as "after 8 hours of work at my regular job", not "8 hours of working on the project". Otherwise, why is he thinking about it on the train, and talking about how fun working on it that night was?
I could be wrong, though.