Our (Software Engineer) Interview ProcessTL;DR Google style technical interviews (google for it)
In this post I try to explain the process you should expect if you are applying to work as a software engineer at ZenRobotics and why we are doing it that way. The process is different for HW engineers and interns (but those processes have similar goals).
Process structure and schedule
This process holds if we have official open positions. If we don't, the time scales may vary a lot - but do send us an application: we'll always consider people and normally new positions open up after a few months.
- You send us an application (for details, see zenrobotics.com/jobs)
- 2--4 weeks later we will contact you to either schedule an A-round interview or to let you down gently
- The A-round is one 1-hour interview in which we try to ascertain you can code and that there is a reasonable cultural fit (and you can ask questions about us)
- 1--2 weeks after the A-round we'll contact you to schedule B-round interviews or to let you down gently
- The B-round is 3--4 technical interviews, 1 hour each. Each interview is given by a different member of staff and consists of 1--2 technical problems you will get to solve on the whiteboard. Each interviewer gives an independent -2 .. +2 judgement which are combined into a hire/no-hire decision.
- 1--4 weeks after the B-round we'll contact you to schedule salary negotiations and signing of a contract or to let you down gently.
Our technical questionsWe work with intelligent robots. They are made intelligent by software, but to make the software intelligent you need some other technical skills (than software skills) too. In our interviews we try out the following kinds of problems (not necessarily all of them for everybody, and we may add some probes into skills you claim on your CV):
- Actual nuts-and-bolts programming (think FizzBuzz) in one language you get to choose, most typically in the A-round.
- Algorithms and data structures (think graphs, trees, hashes rather than bloom filters)
- Software design (think a simple API for a simple component)
- Math and physics (think high-school, rather than 3-body)
- Statistics and probability theory (think Monty Hall and Bayes' rule, rather than convergence of estimators)
- Ability to explain some basic technology (how does binary work, how do two processes communicate over a network)
Why do we do it this way?We want to get several independent reasonably reliable datapoints. Several so that you don't fail because of a single mismatch with an interviewer. The reliability is supposed to come from actually getting you to solve problems rather than to make claims of your ability.
(Do note that for us the cost of hiring the wrong person is pretty high and the cost of not hiring a good candidate is pretty low; for you it's the other way round. Also: we have to be able to make judgements with a reasonable amount of effort).
We want very good people (but not necessarily (just) rock stars). The hire/no-hire doesn't depend on what team you'll start in - we want the bar to be high enough that you are a good fit to any team. However, different teams have different balances between the different technical skills named above and how well you do in the different questions will have an effect in where we try to start you out in.
We try to start easy but have ways of turning up the difficulty if you are doing well. This is so that we can gauge not only whether you are 'good enough' but we can distinguish between good and better.