I’ve noticed a trend amongst development teams to adopt an technical interview format that looks more like a pair programming/code review session between the interviewer and candidate. Among other things, this has the potential benefit of providing a more collaborative, real-world, “day-in-the-life” discussion, as compared to a "traditional" whiteboard/logic puzzle style interviews.
I’d love to learn more from folks that are doing this already (or are planning/aspiring to soon!), and in particular:
What software do you use to collaborate/code along with candidates during the interview? (e.g. Zoom/Teams/Slack for screen sharing?, online IDEs such as Codesandbox?) Do you rely on a separate service/tool for audio and/or video for communication?
What is the scope of the task the candidate typically performs? (e.g. are they writing tests, doing a code review, fixing a bug?).
Are candidates working against a real codebase, a test/evaluation project, or building a new app from scratch?
If you’ve already written about this before, feel free to just share the link. In general, I’m very keen to learn more about collaborative tech interviews in-the-wild, so I appreciate any and all details. I suspect others in the community will be interested as well, since this an area that deserves continuous improvement and knowledge sharing 🙌
Top comments (8)
After a year or so of interviewing candidates, I found my interviewing style morphed into a pairing style interview. Pairing/swarming as a team appeared to empower the candidates where as the traditional interview did the opposite.
We would use a white board and pseudo code only. Candidates are given a systems type problem that would require at least several components to work. After some designing, we would write some pseudo code for some of the components. I'd let them pick witch component they'd want to tackle and what they'ed like me to work on.
Giving candidates a team and agency has had a noticeably positive impact on our companies interviewing results.
Hi! I have some years here interviewing tech candidates. In Germany basically the only option we have is to hire devs abroad, so most of the interviews are done remotely.
After CV triage, the candidate is given an URL for a four/five (very easy) code challenges exercise. They can use any programming language they want and have about two hours to do it. Every keystroke is recorded, so we can replay and check how the candidate produced the code (and potential plagiarism). The exercise is guided by unit tests, of course.
If passed, then comes the technical interview with me and the lead developer of the position the candidate is applying to.
The technical interview is basically composed of three parts: an open technical discussion about a practical subject (for example, how to implement a RESTful API), a sequence of Q&A (boring, but veeery useful) and finally the pair programming session (the most important part).
We launch an AWS instance in advance and share a terminal session through tmux and code using vim. The candidate doesn't have to know vim, we guide them. Usually the task is to implement a trivial class or module depending on the language, using TDD and coder/breaker pattern. It doesn't have to be complicated as the most important aspects are the adherence to TDD rules, team work, algorithm thinking, refactoring and readability.
Most of the cases the candidade really enjoys this part, even if most of them fail hard :)
Thanks for sharing! Out of curiosity: is the use of tmux/vim based on the fact that that's what many folks on the team use? And therefore, that provides a realistic impression of what collaboration on the team would actually look like?
I'm a vim user myself, but most of the team doesn't use it on a daily basis (but they all passed through the same interview process). The choice of using tmux/vim/AWS is based on several factors. The remote pairing environment is terribly simple to setup like this in virtually any programming language (we have a polyglot ecosystem here). Familiarity with the Linux command line is imperative for us, so that's another strong reason. Also, I want to hire real developers, people who can think software, not superusers of an specific IDE. Taking the candidate out of the comfort zone helps to reveal that.
Our interviews are two part. 1) 40 minute test-driven paired programming exercise. In this round the assessor does all the typing asking the candidate questions along the way. It can be in-person or via Webex.
2) on-site paired programming exercise doing a “real” user story. During this exercise we use the same tools and follow the same xp practices we use on the job.
Zero whiteboard if exercises
Zero trick questions
So the candidate would end up getting a feel for both the projects they’d be working on, as well as the actual team practices/tools? I love that! Also, since you have a mix of coding from both the interviewer and candidate, you’d need a tool that supported bi-directional control?
Out of curiosity: does you team practice TDD and/or pair programming full-time?
BTW, I’d also be interested to hear from folks that have been on the other end of a “collaborative coding” style interview. Since tech interviews are a form of developer collaboration, feedback from all parties is equally meaningful!
tbh, it's a touchy subject for me. I even wrote this dev shit post 2 years ago about ridiculous tech interviews :( linkedin.com/pulse/can-i-code-tara...