5 ms·
Insulted? Never. Annoyed? Many times, yes. It really depends on the type of test. If they give me the "this should take 4 hours" project, I usually tell them to
by y-c-o-m-b 5y ago
Insulted? Never. Annoyed? Many times, yes. It really depends on the type of test. If they give me the "this should take 4 hours" project, I usually tell them to take a hike because that's very disrespectful of my time and the 4 hours is complete bullshit if one is trying to deliver a perfect result. Coding puzzles are extremely annoying, but I can usually get through them.
The best coding tests are those that demonstrate you know how to code applications relevant to the job; e.g. a UI component or an API endpoint that takes a parameter and body and returns a filtered result. Then the test is followed up with discussions around what else could be done with it in the real world (auth, performance enhancements, etc.). Seemingly this would be the easiest and most rational path for both interviewer and interviewee, so I'm not sure why the industry is still stuck on those stupid puzzle exams.
"We can't find any good devs". No, your hiring method sucks and you're eliminating good devs because of it.
- justin_oaks 5y ago> The best coding tests are those that demonstrate you know how to code applications relevant to the job Exactly. I am extremely confused as to why puzzle exams are common. Why can't the exams cover things that normal developers work through all the time? Things like reading existing code, improving error handling, debugging, basic performance optimization (e.g. don't do unnecessary work inside the for-loop), refactoring, etc. When I was an interviewer I gave some code samples to a candidate. The code would have all sorts of problems in it and I asked how the code could be improved. If the candidate couldn't identify basic problems then it was a red flag. For example, I made the code catch all exception types and ignore them. If you're a developer and can't tell me "You probably shouldn't do that" then you're not ready for production work. When I ask, "What can be done to improve it?" the minimum I expect is "Log the error" or "Don't ignore the error. Propagate it to the caller" or "catch only specific exceptions". Funny enough, I once had a boss who wouldn't make the cut based on my example above. We begged him to stop committing code.
- sergiotapia 5y agoI agree, code puzzles suck. Our take-home assignment takes about five hours and we provide you with the skeleton project with a few schemas already there for you to play with. https://github.com/play-oxygen/takehome-fullstack-engineer https://github.com/play-oxygen/takehome-fullstack-engineer What you do in this take home assignment directly applies to what you're going to be doing full-time while working with us. However these kinds of take-home assignments only work if you have technical people on your team. If your founding team is non-technical and you are using an outsource shop YMMV. https://sergiotapia.com/your-interview-process-sucks-you-arent-faangm https://sergiotapia.com/your-interview-process-sucks-you-are...
- y-c-o-m-b 5y agoNo offense, but that still seems excessive. I'm guessing you still have another 1-2 hours minimum of interview time talking to the candidate afterwards too right? I would turn it down. My FAANG interview was a total of 5 hours and it included mostly behavioral questions and two 45-minute coding exercises, both relevant to the job. I think that was a decent compromise, but even that felt heavy. There are some exceptions. A 5 hour take-home project might be acceptable if you pay the candidate. For example DuckDuckGo paid me for their take home project, although it took far less than 5 hours to do. I appreciated that. Still, with the developer shortage, I'm far less inclined to deal with these silly experiments when there's a handful of other companies that have more efficient hiring processes I can apply to.