Our interview, laid bare

We wrote about our recruitment process before and offered some insights into what kind of colleagues we’re looking for as well as dropped a few hints on the kind of things we ask during the technical interview.

Today we’re taking that one step further and publishing the complete (*) set of our interview questions. The (*) deserves a clarification, which will most likely become obvious as you go through the questions, but let’s address it anyway because it’s an important indicator of, once again, what we’re looking for: most of the questions are open-ended!

That’s right, we barely have any “API questions” or “directly googlable” questions. While one can (and should) learn everything (or well, as much as possible), some things take longer to learn (and even longer to master) than others. As such, we try to avoid questions to which you can find the answer using a quick web search and rather focus on open ended questions that are about (engineering) principles, how things work behind the scenes, why the tools you use were designed the way they were, what are the pros and cons of a specific thing etc.

We don’t ask this kind of questions out of smugness or elitism, we’re agilists at heart and try to approach problems in a structured, yet pragmatic way and these kind of things do come up frequently in our work. What’s more, we, at InfiniSwiss, have a completely 100% flat organizational structure: we’re all engineers, no managers, seniors, team leads etc., which means each and every one of us should be able to come up with at least an initial proposal for a feature, functionality slice or application architecture (after which we’ll discuss and iterate). Without having sound engineering and computer science knowledge as well as specific technology insight into how stuff works, it’s hard to come up with a half-decent proposal as you’re not aware of the tradeoffs involved.

An example I often use in discussions is “you have to implement a feature to download N files, M at a time, how do you do that? Do you use multithreading? Async/await? Queues? Schedulers? Etc.”. If the candidate chooses “async/await” I’ll be interested to find out how “async/await” actually works behind the scenes, e.g. how does the execution flow “pause” when “await”-ing and how does it resume after, what IS the “awaitable” thing and what particular issues one has to be aware of.

This is one example, maybe seemingly complex to some, but even simpler topics can be expanded on and can become more complex at scale. For example, our “non-repeating character in infinite sequence” question (see below) is easily solved in a local, in-process environment, but becomes trickier if the sequence of characters is maybe a sequence of IOT inputs in a scaled out environment of 100 service instances.

What I’m driving at is:

  1. Our interview questions are open-ended, we will therefore delve into each as deeply as we can and expand as much as we can
  2. They are based on real-life situations that come up in our daily work.

An interesting side effect of the above is that (in our opinion at least) you can’t “game” the interview. Even now, having all the questions available, does not mean you can memorize the answers and pass. Rather, if you want to go through it, the focus should be on thinking about each question in depth and how to possibly expand on it in various scenarios. Also, we’re not always looking for the “right” answer and it’s especially delightful when a candidate doesn’t know the answer but will think about it out loud and explain his or her thought process throughout. In the end, we think about it as a discussion, not necessarily an interview, where both sides collaborate on finding solutions to problems (though granted, one side has a bit more beforehand knowledge 😊). This also means you’re welcome to ask questions, ask for hints etc.

Ok, but why?

Now that you understand how our interview is designed, you might wonder why we’re opening it up. The answer to that is, again, pragmatism.

Through the years (we’ve been doing this for many, both in InfiniSwiss and our previous companies) most, if not all, interviews we participated in followed the same template:

  • Candidate shows up
  • Questions
  • Decision

Most of the time, unfortunately and despite our best screening efforts, the interview doesn’t go well. We’ve gotten various feedbacks about it:

  • “It’s too hard”
  • “I don’t use this stuff”
  • “I don’t need to know how stuff works behind the scenes, I use it and it’s enough”
  • (didn’t even get to the interview, people heard it’s tough and never went ahead)

Over time, we sought to improve our screening process in various ways:

  • Describing what we’re looking for better*
  • Giving the candidates a small questionnaire to self-assess
  • Having a short screening call with some basic questions (10-15min) instead of going directly for the full blown interview (1-2h)

Unfortunately, while it improved things somewhat, the feedbacks above still largely applied. So thinking about it, opening up our interview completely is the next logical step. It also nicely complements the “template” mentioned above, in the sense that it actually gives candidates the very concrete knowledge of the skills we’re looking for and time to prepare if they so wish. This way, it’s actually more akin to a regular exam:

  • You get the subject matter to learn, then…
  • You learn it, then…
  • You take the exam

Imagine an exam starting directly with the last point: it’s what we (and everyone else?) have been doing so far…so it’s maybe time to change it up.

In addition to the reasons above, which are entirely selfish 😊, there’s also a selfless reason behind this: we want people in this field to get better. We are lucky and blessed to be working in a field that’s never boring, always fun and surrounded by smart people. And while we can do much alone, we’ll do much more together: that’s why, even if you never come interview with us, these questions might at least raise some questions about areas you feel you can improve and compel you to act in that direction. And while there are specific “interview books” out there (and they’re good), we hope our little set of questions here provides a more pragmatic look into how a smaller (but in our opinion highly technical) company interviews.

Finally, dear reader, I’d like to ask you also for something: any feedback, improvement suggestions or additions/corrections you might have are more than welcome. Just ping me at [email protected] and I’m happy to talk about it.

So do I need to know everything here to join InfiniSwiss?

That would be ideal, but we don’t live in an ideal world.

Having a solid handle on the answers to the engineering/computer science questions is a prerequisite for moving forward. Due the nature of the projects we are involved in, we use the specific engineering knowledge they highlight on a daily basis. We are a flat organization, so we expect from our colleagues to be able to come up with architecture/design proposals on features, vertical slices or end-to-end applications. Hence our deep focus on software engineering. 

For the technology-specific questions you should be confident that you can have an in-depth discussion around them. You only need to handle the technologies known to you currently, we will not ask you about technologies you are not familiar with. Doing well in this part of the interview is a bonus (and will reflect in the offer we make you), but not a prerequisite for moving forward, because we believe a person with sound software engineering knowledge will learn any technology relatively quickly. 

If you are confident about your knowledge, let’s move on to the next step: the technical interview.Should you need more time to think about the answers, let’s keep in touch and talk when you feel comfortable. Our door is always open. Check out the graph above for a better understanding of our needs from you.

Without further ado…

…here come the questions. Notice they are divided in two main categories:

  • Engineering / computer science (not technology specific)
  • Technology specific (based on the technologies the candidate knows and our two tech stacks at the time of this writing, Javascript and .NET)

There is also a prequel, which stems from our previous screening call: the 3-4 basic questions which we deem a prerequisite for going further. Again, please don’t let their simplicity dissuade you from thinking about them, they can (and likely will be) expanded upon when we actually discuss.

Thank you for reading, thank you in advance for your feedback and of course thank you for considering joining our team (contact us at [email protected] or on LinkedIn).

Links:

Written by:
Adi.jpg
Adrian Hara

Managing partner and geek wannabe