Ugh, so many bad practices being defended in the comments here. I've been on both sides of the table: - As an interviewee, my experience is that companies tha

Ugh, so many bad practices being defended in the comments here. I've been on both sides of the table: - As an interviewee, my experience is that companies that use coding exams are not places I would want to work - companies that use these exams have a poor hiring process or any technical interviewers themselves either are not proficient with the technologies they are interviewing for or cannot discuss the technologies effectively. Any of those cases is a big red flag for me. - As an interviewer, there are two problems with coding exams: either they are so short that they can only test CS knowledge instead of the actual required skill (which is translating the business problem domain into code) or they are so long they impose too great a burden on the interviewee. ("Oh, don't spend more than 4-8 hours on this project" is not an acceptable burden in my book.) Further, the hiring manager is not the one that should be evaluating the technical ability of candidates. (Well, unless the hiring manager is hiring Employee #2 for a start-up, but that should be more about trust and hiring someone with a track-record of success.) The technical staff should be evaluating the technical capability of the candidates, and the technical staff doing the interviewing should have both the technical knowledge and communication ability to easily screen any candidate in 30-45 minutes of casual conversation, tops. The hiring manager should be looking for team fit, communication ability, and other soft skill abilities the candidates have. Anecdotally the businesses I've encountered in the Upper Midwest that do actual interviews instead of coding exams all have solid developers as employees. The businesses that use coding exams have the second-rate (and lower) developers writing code. No other field in engineering, barring positions requiring the professional engineer's exam, requires candidates to go through an engineering-specific exam. The employment contracts that are drawn up usually include a 90-day probationary period in which the hire can be fired again for non-performance. I don't see why software positions should be treated any differently, since that hiring process has worked (and worked well) for other engineering fields.