2 ms·

> It’s not perfect, but I won’t hire anyone that can’t pass a live coding round I'd like to add two points to this: First, I like that you said "live coding"

> It’s not perfect, but I won’t hire anyone that can’t pass a live coding round I'd like to add two points to this: First, I like that you said "live coding" rather than leet code. The floor for live coding should be super low, with a high ceiling and lots of flexibility. That allows you to say, nope, they didn't pass the floor level, easy binary decision, no hire. Pick a fun toy to build in 90 minutes and the high ceiling + flexibility will yield tons of signal from applicants. Second, I see live coding sessions like this as a positive sign from potential employers. It lets me know that my future colleagues will have some baseline level of competence. If you've worked on a team that didn't do live coding, and you've had to carry water for someone who can't actually do the day-to-day technical "hard skill" work of software engineering, you probably feel the same way. Never again.

Esophagus4 1y ago
Absolutely agreed. I start with a simple problem with several answers of varying difficulty and literally instruct the candidates to code the first correct solution they can think of. Nested for loops, brute force, it’s absolutely fine. I just want to see you translate what’s in your head to code. I want to see you structure code, use data structures, etc. Then we will talk through optimizations, refactoring, testing, edge cases, etc later. You want even the under qualified candidates to feel like they got some pieces right and had a fair shot. As you start probing deeper, the top candidates stand out. They answer your questions about the differences between data structures, how you would test this piece, how you would monitor that piece in production, how you could parallelize it, etc.