5 ms·

I interviewed hundreds of C++ developers as a freelance assessment interviewer. The most candidates I interviewed wanted to work in the automotive industry in E

I interviewed hundreds of C++ developers as a freelance assessment interviewer. The most candidates I interviewed wanted to work in the automotive industry in Europe. Many candidates (like: maybe the half) are fancy talkers without any skill in writing code. I really don't know why they are applying for dev jobs. It is easy to filter out these persons with a very simple coding test. I agree with the article that 'leetcode' tests (find that complicated algorithm in 30 minutes while I am staring at you) are bad. But I think coding tests are good! Give the candidate just a really simple coding task with stuff they normally do every day. Create and delete object, fill arrays, iterate over arrays, and so on. 50% of the candidates will fail! The rest are OK engineers.

gspr 4y ago
Exactly. Give a simple coding task that the candidate does on their own time (but not one that's too complicated, it's rude to waste the time of people who aren't even working for you), and then, crucially, have them briefly explain their solution during the interview. The task can be so easy that reasonable solutions are just 10-50 lines of code – my experience has been that people's explanation of their own work very clearly tells you whether or not they're a decent coder.
- quickthrower2 4y ago
  What if that test was done once by an external company, and then the stamp of approval is good for a year of job interviews. That would save the candidate and interviewer a lot of hassle!
  - koonsolo 4y ago
    I agree. You would expect that from a bachelor or master degree. But nowadays you have a lot of people coming out of coding bootcamps, and their level can vary a lot. A hole in the market!
    - quickthrower2 4y ago
      Or a hole in national / international standardization. Just create a further education (like 16-18 typical age) course and exam for it.
scottlamb 4y ago
> I agree with the article that 'leetcode' tests (find that complicated algorithm in 30 minutes while I am staring at you) are bad. But I think coding tests are good! Give the candidate just a really simple coding task with stuff they normally do every day. Create and delete object, fill arrays, iterate over arrays, and so on. 50% of the candidates will fail! The rest are OK engineers. Do the candidates know that ahead of time? Your approach seems similar to what I've done as a coding interviewer and to what my interviewers did when I last interviewed (at Google back in 2007). Assess people's coding with something relatively simple. Make sure they can gather requirements, describe why they chose this approach instead of a couple alternatives, and (if they make a mistake) that they can diagnose it if you describe the symptoms. If you have extra time, have them review some bad code. See if they spot the problems and how they gently help the author understand/fix them. (They also should be tested on system design, but that's a whole other interview slot.) I'm studying to be a coding interviewee for the first time in 15 years. This process is stressful in part because they just tell you coding on hackerrank/leetcode/coderpad, which is so broad. If the problem they pick is as you describe, I should be fine. If it's for example some advanced dynamic programming problem...well, those haven't come up for me in the last 17 years, so I'm probably in trouble. It's a perfectly valid area of computer science, but it's not one that matches my experience or what I'd likely be doing if accepted. I'm not excited about taking the time to prepare for that, but I also don't want to make a fool of myself if they do. They probably won't pick this area...and if they do, it's probably a bad sign about the company or my understanding of the role...but the possibility is stressful nonetheless.

gspr 4y ago

Exactly. Give a simple coding task that the candidate does on their own time (but not one that's too complicated, it's rude to waste the time of people who aren't even working for you), and then, crucially, have them briefly explain their solution during the interview. The task can be so easy that reasonable solutions are just 10-50 lines of code – my experience has been that people's explanation of their own work very clearly tells you whether or not they're a decent coder.

quickthrower2 4y ago
What if that test was done once by an external company, and then the stamp of approval is good for a year of job interviews. That would save the candidate and interviewer a lot of hassle!
- koonsolo 4y ago
  I agree. You would expect that from a bachelor or master degree. But nowadays you have a lot of people coming out of coding bootcamps, and their level can vary a lot. A hole in the market!
  - quickthrower2 4y ago
    Or a hole in national / international standardization. Just create a further education (like 16-18 typical age) course and exam for it.

scottlamb 4y ago

> I agree with the article that 'leetcode' tests (find that complicated algorithm in 30 minutes while I am staring at you) are bad. But I think coding tests are good! Give the candidate just a really simple coding task with stuff they normally do every day. Create and delete object, fill arrays, iterate over arrays, and so on. 50% of the candidates will fail! The rest are OK engineers. Do the candidates know that ahead of time? Your approach seems similar to what I've done as a coding interviewer and to what my interviewers did when I last interviewed (at Google back in 2007). Assess people's coding with something relatively simple. Make sure they can gather requirements, describe why they chose this approach instead of a couple alternatives, and (if they make a mistake) that they can diagnose it if you describe the symptoms. If you have extra time, have them review some bad code. See if they spot the problems and how they gently help the author understand/fix them. (They also should be tested on system design, but that's a whole other interview slot.) I'm studying to be a coding interviewee for the first time in 15 years. This process is stressful in part because they just tell you coding on hackerrank/leetcode/coderpad, which is so broad. If the problem they pick is as you describe, I should be fine. If it's for example some advanced dynamic programming problem...well, those haven't come up for me in the last 17 years, so I'm probably in trouble. It's a perfectly valid area of computer science, but it's not one that matches my experience or what I'd likely be doing if accepted. I'm not excited about taking the time to prepare for that, but I also don't want to make a fool of myself if they do. They probably won't pick this area...and if they do, it's probably a bad sign about the company or my understanding of the role...but the possibility is stressful nonetheless.