Read on Twitter
Leetcode-style interviews are orthogonal to the work. It requires interviewing skills not day-to-day skills. According to Google's research, there is no link between a candidate's interview score their actual job performance. https://twitter.com/ianfoo/status/1276057928382820352
I know a few people who likes to interview a LOT. They don't it for the sake of hiring the best but to keep their interviewing skills up-to-date. It's a lose-lose game. We can't even incentivize people to interview for the right reasons.
"But the system is to avoid the false positives."
It takes 5-10 minutes to see a person is a no-hire. It takes a very long time to be able to tell if they are a "hire". Leetcode or anxiety-driven programming are not giving enough signals about a candidate's skills.
It takes 5-10 minutes to see a person is a no-hire. It takes a very long time to be able to tell if they are a "hire". Leetcode or anxiety-driven programming are not giving enough signals about a candidate's skills.
I love flexible formats, e.g.:
- Ask about fundamentals (don't expect textbook answers)
- Code an every day problem
- Ask about pros/cons about an open ended topic
- Ask about past experiences
- Ask questions about organizational awareness
- Ask about fundamentals (don't expect textbook answers)
- Code an every day problem
- Ask about pros/cons about an open ended topic
- Ask about past experiences
- Ask questions about organizational awareness
If the candidate is more experienced ask more system design and API design questions. Ask them to review an every day patch. Ask them to review the goals/non-goals of a design doc. Ask them about their leadership experience.
