People who ask for more complicated code than "reverse a string" or "fizzbuzz" in a remote code screen is doing it wrong.
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.
>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.
Misrepresenting abilities ... yes, I did that in my first job interview. The job posting said PHP, HTML, MySQL skills. Well, I knew HTML well enough but my PHP and MySQL skills were from a few side projects doing copy-paste-modify with PHP BB's code base to make my own web app, which I never did finish. So I only kinda/sorta knew those languages.
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.
Yes, it seems that most companies misrepresent their requirements in job postings. It also seems that most candidates misrepresent their skills in responding to those job postings. There's a certain symmetry there.
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!
I actually really like the take-home coding challenge, ideally something a qualified candidate could do in 1-2 hours and inspired by a real on-the-job problem (perhaps distilled a bit). It gives me much more insight into your coding style and is a much more low key, realistic test – especially since my team is fully remote anyway.
OTOH, for example, at a certain (non-IT) company, they overblow requirements for the most junior IT posts in such a way that the ONLY people they're able to hire are people that lie about their experience/abilities on their interviews (and there's no technical interview, so they can do so at will). They're optimizing their recruiting process in a very, well, weird way.
>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.
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.
I think it's mostly (1). The question is mostly "prove to me you've written code before". I typically let them pick their own language. I'm guessing some are fake-it-until-they-make-it and some are genuine Dunning-Krugers. The phone screen is to filter out category (1).
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.
The one time I tried a fizzbuzz in a series of interviews, one candidate was surprised and almost insulted. At the end of the day, I learned almost nothing about any of the candidates from this question. Only one candidate (in fact, the one female candidate) implemented it substantially different than any other. All the candidates could do it. They were all CS students at a university, so what was the chance they were not going to be able to compile a program anyway? So I think you have to take fizzbuzz with a grain of salt and know when to try a more complex programming exercise.
(That being said, I'm horrible at doing interviews so take my advice with an even bigger grain of salt.)
When I've seen people advocate Fizzbuzz, it's always in a context of how 90% of their candidates can't even do it. It's intended as a quick screener that immediately eliminates a ton of obviously bad candidates.
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 like gradated questions where if someone knocks my first iteration out of the park, I have several avenues to keep probing. That usually involves bringing in more concepts, not merely making the questions more complicated per se. Fizzbuzz doesn't seem to me to have an obvious avenue for bring in more concepts. It's obvious how to make it "more complicated" but not how to expand it.
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.
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.