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 :)
I build developer tools and services at Microsoft (currently Codespaces, Live Share, IntelliCode) and maintain some OSS projects (CodeTour, GistPad, CodeSwing, WikiLens)
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.