By using such automated tests, companies want to identify top talent by taking a shortcut and not investing any time on their side.
People who can't code, compile, and run a fizzbuzz in an hour are probably not fit to be hired.
Asking someone to implement a proper Diffie-Hellman over Hackerrank is ludicrous, on the other hand. Interviewers should err on the side of stupidly simple problems. A surprising number of people can't code a loop in the languages on their resumes.
I guess you can reach two conclusions from that:
1) A surprising number of applicants are totally misrepresenting their abilities – either through deceit or wild ignorance.
2) Something about your interview process makes a surprising number of people unable to perform at their normal level – from nervousness, unrealistic and artificial constraints, etc.
Certainly many of those applicants fall into the first bucket, but I'm betting a large portion fall into the second. So, you might reconsider whether the false negatives and highly unpleasant experience for many interviewees are worth the perceived value. Maybe there's a better way to get the same insights.
But then at the end of the interview I was given a coding challenge to do at home over the next few days. PHP and MySQL have good online documentation so I was able to knock it out quickly and I got the job. So, yes I misrepresented my skills, but I also knew I could live up to what I was claiming I could do.
Employer: First job out of school pay, requires four years of experience in our exact tech stack.
Candidate: Sure I'm willing to take first job out of school pay (BTW, just graduated in May). Yeah, totally have 4 years of experience, and what do you know, it covers exactly your tech stack!
Edit: exactly the point shawn-furyan is making.
https://news.ycombinator.com/reply?id=11224427&goto=item%3Fi...
I've worked with people who crashed and burned during the interview during nervousness and then went on to do okay afterwards.
I'm a believer in trying to make the interview process as close an analog of day to day work as possible and as low key as possible.
That means real, actually encountered problems (no fizzbuzz), and a progressive ramping up of the difficulty so that candidates with confidence problems can have a few easy problems to get over their anxiety with before getting into something meaty.
People that suspect they're in category (2) could come to an interview with some code samples. Personally, I'd even be OK if a (2) contacted me after the phone screen with some code samples and an explanation about what happened. Maybe we could set up another phone call and find another way to assess technical abilities.
Good development requires good communication and someone with the maturity to overcome that sort of problem will fit in well somewhere, maybe even on my team.
(That being said, I'm horrible at doing interviews so take my advice with an even bigger grain of salt.)
I often use CSV parsing, where I specify a function that involves a simple string and I want some natural parsing of that in your favorite language. A bonus point for starting with the observation we should use a library, then do it yourself. From there I can pivot into discussing what the correct output data structure is (especially if the rows do not all have the same size or the same data types), converting text into better types, whether or not you understand unambiguously encoding text ("how can you include a comma in your field?", and I'm not worried about whether it's a "standard" answer), UTF8 and other text encoding issues, computational complexity a bit (and while small, it's a very practical, day-to-day bit) and questions of memory efficiency, the question of streaming if the dataset is too big. I can also easily pivot into outputting this CSV file into an HTML table in your favorite language, getting into HTML template issues, security issues that can arise from that, dumping the CSV into a database, and I'm probably even forgetting some of the pivots I've done. (And the point here is that I can choose, not that I ever cover all of these in one interview.) This question template scales from intern level ("can you get this string into an array of array of strings?") to senior engineer ("alas, the text encoding is varying from field to field, now what?") quite easily.
I've phone screened with this in a shared doc, too, since I can copy & paste in the problem pretty easily.
You're clearly getting a better caliber of candidate than those people are. That's great! And clearly, if that's the case, you should adjust accordingly. I think the lesson there is to tailor your process to the people you get.
I took one of these recently, and botched one of the tests. Within 10 minutes after the timer was up, I had restarted my solution with a successful answer and was iterating on it.
The idea that the pressure is the same doesn't seem to apply to all applicants. Doing work under pressure within set times has been a strength of mine(ex. playing chess against higher rated players or when timer is low). I've noticed, however, that my skills fall apart during interviews. Once again, totally different contexts where you're being tested.
I am so tired of hearing the refrain that "we want to see how you work under pressure". Anybody who thinks that all pressure or stress is the same and that you can translate performance in one stressful situation into any and every other one has no business being near a hiring decision.
Nope, we aren't even going to ask you anything about that, or let you open up your iPad and show us, here's a whiteboard, start writing up a recursive permutation algorithm (only ever had to do this in programming interviews) because we want to prove you know how to do recursive stuff (and then tell us why you should almost never use recursive solutions in our apps), oh, and how about a red-black tree (algorithms class ran out of time to cover, unneeded since), or how about coding this specific sort (heap, merge, whatever) that you'd almost never use in actuality because there are tried and true libraries that are already more efficient than you'd ever be doing it from scratch?
Ugh. Fine, you can do your test, but please don't ignore my prior experience or act like you haven't even given a cursory glance at my resume, or even worse, make a dismissive comment when I talk about it during the interview. It really is insulting. And yet half the interviews I've been in have been like this.
I know to get away from those companies and never come back. If our values differ so much at the interview stage, it won't get any better a few months from now.
However, what I cannot condone is wasting the time of 100 applicants. It takes the employer ten minutes to "sort by best" and start calling down the list.
You are 100% right about their time investment. They are saying their time is more important than yours. It is another layer that muddies the process.