I feel this interviewing process mostly mirrors a typical interview day for most startups (or did some years ago).<p>I’m glad you took the time to iterate and document the work involved to accomplish a welcoming and safe space — did this evolve into company guidelines? Do get domain experts to help with the interview. I also wouldn’t ditch the white board so easily, let know the candidate before hand, and make it collaborative, even initially drive. Brainstorming ideas can be an engaging activity, discussing architectures can introduce a small part of the systems the candidate will interact with.<p>Well done and thanks for sharing.
I’ve been ruminating on what’s a good tech interview methodology since mine is good at finding junior programmers but not senior ones.<p>But what if we did a 2-3 hour pair programming session where we fix bugs in an open source project?<p>I think it would cover hard skills (actual coding), soft skills (git, reading and writing PRs) and address the “I don’t want to do free work for a company under the guise of an interview”<p>And so what if we use AI? Realistically, that’s how coding will be done anyway.<p>Thoughts? Has anyone tried this?
TL/DR:<p>"a 40-minute technical pair programming assessment providing a dummy codebase mirroring a section of your production code, complete with incomplete functions, faulty implementation, and failing tests.<p>The candidate is sent read-only access to the repository one hour before the interview, to allow them to look over it and get a feel for the code, how it’s structured, etc. However they should not actively implement anything in that hour."