| I dislike cheating. I've taken ~50 interviews and in 90% of them cheated: a) I could hear their keyboard clacking when they googled the answer b) they'd stall with "umm" and "ooo" while their friend googles the answer and shows it to them c) (the best one) they'd memorize everything from leetcode style solutions and definitions to mathematics MCQs. In my country, you're the odd one out if you have an exam or an interview and you don't prepare for cheating. It's a cultural expectation among peers to cheat to get ahead. To work around this, I follow the advice I've read here on HN: 1) Ask them about their programming experience. Bugs they ran into, solutions they thought of, implementation of those solutions etc. 2) take a problem I faced in my work and present it to them and observe how they navigate the problem to reach a solution. They don't have to solve it, I just see their approach 3) just talk to them while asking basic language syntax and definitions. Again, the goal here is to check if they've memorized the answers or are they speaking from experience. If the answer is a regurgitation of some interview prep website, probe deeper to see if they know what they're saying. The downside of this approach is, of course, time. It takes 40 minutes to an hour for each of these interviews. Time that sometimes I don't have and I have to move some stuff around to accommodate, work late to cover up or delegate. This approach has worked for me so far. I've hired 5 people in my team and all of them have been good hires. EDIT: formatting and grammar |
Couldn't it be argued that memorizing leetcode solutions IS NOT cheating? Seems like it would be better to understand things at a fundamental level, but its still proof of ability to master the problem in and takes a lot of effort.
Especially if the person was upfront about the fact they could solve the problem but still didn't understand everything about it.