As a person who leads technical interviews, I’d like to share a few thoughts to help you prepare and perform well to make a great impression on tech staff.
We are the same as you
The first thing you need to know and remember — we are also tech people, doing the same job as you. We are not examiners, teachers, judges, parents, or bosses. There’s really nothing to fear. Of course, some of us may have more experience than you, but it doesn’t mean we will feel better after dragging you down. We really just want to know more about our potential future colleague and, most likely, teammate.
It’s not an exam
Although the technical interview may seem a bit like an oral exam at university, it really isn’t. For technical recruiters, the best would be to have a regular talk with candidates. A bit directed, but still a discussion. Because our work is often closely related to our hobby, we like talking about technical stuff. We’d like to learn about interesting things you’ve already done and what you have to say on some intriguing technical topics.
Even those most basic questions can lead to a fascinating exchange of views. For example, such boring university topics as the optimal use of data structures can lead to some fascinating remarks. For instance, it’s sometimes worth using something that’s theoretically worse but in practice works better. Of course, depending on your experience, you will get a bit of a different set of questions. We won’t ask junior too much about architectural issues and seniors about typical university stuff. But don’t treat it as a sure thing; we do sometimes like to hear if newcomers can even consider how they would solve complicated issues, to assess future potential; and it’s interesting to ask seniors about simple theory in order to assess if they have the ability to explain things to others.
Theoretical and practical parts
While doing technical interviews, I like to divide them into two parts — theoretical and practical. The first will be the talk, as described before, mostly on topics from programming theory and technologies you’ll work with. Here, what impresses me the most is not being a walking encyclopedia, but having your own (proper) definitions, and your own opinions. No one likes to hear the same definition from Wikipedia (especially in the time of remote interviews!) over and over again.
Next is the practical part. That’s where we like to see your coding in action. But don’t worry. It’s not writing anything from scratch or implementing some strange functionalities. These are often straightforward tasks where we only want to see your way of thinking and how you take on challenges. For example, in my interviews, these tasks are often “one-liners” with multiple possible solutions. I like to see how the candidate is looking for an answer and why he/she thinks it is the best one.
What should you learn before the interview?
Don’t learn anything just for the interview. Like I said before, it’s not an exam. We want to see the real level of your knowledge. However, if you’re going to prepare for an interview, you can just refresh your knowledge from things you have written down in your CV and are required by the job you are applying for. For example, if you are applying for a front-end developer role with React, you can do a quick refresher on some basic things. Just remind yourself how you use React, why you use it, and what alternatives there are out there.
Be yourself
The last thing I’d like to recommend you is just to be yourself. Don’t pretend to be someone you’re not. We want to know the person with whom we will most likely work in the future, not a fake version for interview purposes. Remember, if you are cool but don’t have a high skill level, we will be more eager to hire you than someone who knows everything but is rude or annoying. Personality goes a long way.
So now, if you haven’t done it already, check out our job offers and find a position that you think fits your skills and your personality.
Can’t find an offer that fits your area? Feel free and sand your CV.
