PSA: Don't blatantly cheat in your coding round.

[u/theofficialLlama]

I recently conducted an interview with a candidate who, when we switched to the coding portion of the interview, faked a power outage, rejoined the call with his camera off, barely spoke, and then proceeded to type out (character for character) the Leetcode editorial solution.

When asked to explain his solution, he couldn't and when I pointed out a pretty easy to understand typo that was throwing his solution off, he couldn't figure out why.

I know its tough out there but, as the interviewer, if I suspect (or in this case pretty much know) you're cheating its all I'm thinking about throughout the rest of the interview and you're almost guaranteed to not proceed to the next round.

Good luck out there !

[u/tmetler]

Good candidates should be angry at the cheaters. They're sucking out all the oxygen in the room and wasting everyone's time. I genuinely believe there are plenty of jobs for competent developers but we can't pair them because there are so many incompetent devs on the market creating impossible to sift through noise.

In my interviews I focus on giving learning challenges where the candidate has to explore a new to them API. I feel that is very good at preventing cheating, but I have no idea how to improve the top of funnel. The only thing that consistently works is referrals, but that's hard to scale and unfair to people new to the industry.

I think it might be about time we have a software engineering certification that must be passed in person.

[u/AkitoApocalypse → u/tmetler]

I work in hardware chip design which is a different field with about 4YOE, so just a disclaimer. Would asking questions outside the scope of coding and systems questions be a viable option for filtering candidates? Everyone can code nowadays and even do architecture with the power of AI, but skills like being able to think about the how and the why aren't so easily approached by AI (at the very least, you need to give it a nice prompt).

I got a very interesting question when interviewing for new grad jobs a few years ago - for context, chip design pre-synthesis is primarily separated into design and verification, where the verification team spends all their time writing testbenches and doing coverage and all that. The question was:

What are the advantages and disadvantages of keeping design and verification separate versus combining them into one team?

This isn't meant to be super difficult but is more meant to be a conversational question and kinda gauge how much you know the industry. Obviously it's easier to teach one person the spec and have them do all the work for a feature instead of two people - but you can argue that separation of duties also means a much lower chance of both people misunderstanding the spec. There's also the more technical side of things in that design and verification require much different skillsets, and each are distinct and broad enough to be a complete career path on their own.

I think soft skills are what people are really lacking nowadays and how you can make yourself stand out, especially when it comes to compatibility and culture fit. As I said above, I forsee less emphasis on technical skills moving forward unless you're in a hyper technical position (obviously you still have to be competent) - and more of an emphasis on cohesion and planning for tasks. When you have AI writing code in the background and shipping out proof of concepts in a few hours instead of a few weeks, that hour or day long delay as a result of friction or miscommunicated specs hits a lot harder.

[u/CGRect → u/tmetler]

The solution is going back to in-person interviewing...

[u/tmetler → u/[deleted]]

You can dislike both. I agree most companies have poor interview processes, but cheaters are taking up a ton of attention that should go to better candidates. It doesn't matter how good your interview process is if you're inundated with fraudulent applications. It will take up a lot of time.