Very well written article despite the fact that I completely disagree with the conclusions logic of the author. I'm on the "reading code" and having a more pers

Very well written article despite the fact that I completely disagree with the conclusions logic of the author. I'm on the "reading code" and having a more personal connection side of the road. Partially on the debugging aspect for some cases. Pretty much the process explained here: https://talktotheduck.dev/debugging-the-technical-interview-methods-and-cheating https://talktotheduck.dev/debugging-the-technical-interview-... The "write code" types of interviews fit for juniors who might not know how to even write code properly. If a person doesn't know how to do that and is a junior they usually have the right energy and can put 100% into the job to adapt/learn. I hired such juniors who had no experience in the languages/platforms and were productive within a month. They had good character and discipline. Distilling a question like that for an advanced coder is impossible. No wonder the article didn't provide any sample of a "good interview". We'd all burn him at the stake because we'd all hate it. There's no such piece of code that would provide a valuable data point about a candidate. So this is a waste of your time when dealing with a junior and with an advanced coder. Coding interviews are difficult. You will make mistakes, this is unavoidable. I think the best mistakes to make are the ones where you hire people who are part of your team and can grow with it. Even if they aren't the best coders around, being part of the team will help them hone those skills and evolve. If I had to pick a 10/10 coder or a team player I'd pick the latter every time.