Hacker News Reader

> In an hour-long interview, I have to be able to state the problem in a way the candidate can understand, within 10 minutes or so. We don't have time for a lecture on the intricacies of voucher calculation and global sales tax law.

If you send me a rubric I can pre-load whatever you want to talk about. If you tell me what you're trying to build and what you need help with, I can show up with a game plan.

You need to make time for a conversation on the intricacies of voucher calculation and global sales tax law if you want to find people jazzed about the problem space.

> In an hour-long interview, I have to be able to state the problem in a way the candidate can understand, within 10 minutes or so. We don't have time for a lecture on the intricacies of voucher calculation and global sales tax law.

Proving if they are technically capable of a job seems rather silly. Look at their resume, look at their online works, ask them questions about it. Use probing questions to understand the depths of their knowledge. I don't get why we are over-engineering interviews. If I have 10+ years of experience with some proof through chatting that I am, in fact, a professional software engineer, isn't that enough?

Have you ever hired?

No, it's not enough. There are people out there who can talk great talk, and have great resume, but cannot do their actual job for some reason. Maybe they cannot read the code, maybe they cannot write the code, maybe they can write the code but not in the manner that keeps the rest of codebase working... I've had people like that on my team, it was miserable for all of us.

It is essential to see candidate actually write and debug code. It would be even better if we could see how the candidate deals with existing huge codebase, but sadly this kind of thing can't be easily done in a quick interview, and good candidates don't want trial periods.

I have seen people passing leetcodes and other types of intensive interviews with high ranks but then failed miserably at their jobs. I have seen hard working/learning people, having zero idea on specific programming language but know some basic fundamentals become the best engineers. I know lots of people who are great engineers and have become VPs of engineering, staff engineers, architects, etc. who didn't complete the technical assessment successfully. This means that they weren't perfect at the time of the interview but had other skills to succeed in their jobs in various companies. They were hard workers, great learners, versatile, innovative, etc. But that was a past era of interviews when people were not searching for perfection but mostly evaluating soft skills. Nowadays people just search for the perfect candidate. Any error in the technical assessment or leetcode means rejection, any imperfect/doesn't meet my own solution response also means rejection. Nobody checks for or evaluates soft skills, nobody checks whether I have solved similar problems in some past experience. I guess that's the issue with bad fits, not just the lack of technical skills (which I agree that needs to be evaluated as well but not in an extremely hard and strict yes/no format unless you are google and co).

>Interview coding questions aren't like the day-to-day job, because of the nature of an interview.

You have missed his point. If the interview questions are such that AI can solve them, they are the wrong questions being asked, by definition. Unless that company is trying to hire a robot, of course.

That’s silly. It’s like saying that a car can do a 100m dash faster than a human so it’s not a useful test for selecting players for an NFL team.