So you want to work here…

Abstract

Hiring is one of the cornerstones of making a company successful and hiring the best people around is an essential, but very difficult, task. In this write up we will go through the anatomy of an interview in the technical field and we will also see the different types of technical, and not so technical, interviews.

I interviewed a lot of people and I have been an "hiring manager" too (the guy with the open positions under him). I sifted through many hundreds CVs in my life and I hired a bunch of people too. Just to make things clear, if there is one thing that I hate above them all is people lying on their CV, not only because I end up doing questions that are replied with a "mmm… not really" but also because I cannot make sure I would trust the person once in. If you think about inflating your CV, please do that within reason.

Recently (well, not all that recently), I came to the conclusion that interviewing is a two way process: it is not only the company interviewing the candidate but also the candidate trying to make sure that the place fits his/her skills and way of working.

This document is not about any specific question I asked, or that I still ask, this is about what you will face, why and what is generally expected from you as a candidate. I hope that this document could be useful also for young interviewers that want to start interviewing.

If you are looking for references and deep dives about interview questions, there are some good books that you can start from. Moreover, I will not discuss about interviews performed by HR people or interviews that at not R&D focused as I have little experience in those. As well, I will not touch the "making an offer" part as it is terribly different in all the place where I have been working.

Stages of the Technical Interview

Let's start now analysing the structure of a technical interview and we will analyse the "testing" and "soft-skills" interviews in the next section.

As general summary, the interview can be seen as composed by roughly 5 parts, from the introductions to the part in which the candidate can ask some questions too. Parts ② and ③ are not said to happen in all the interviews but parts ①, ④ and ⑤ for certain are. Moreover, interview sessions are usually one hour long but they can be as short as 45 minutes or as long as one and half hours.

Let's proceed now.

Meet and greet. Usually, an educated interview starts with the presentations and definition of who is who. Sometimes, interviews can become a little crowded with more than one interviewer, especially if one of them is learning how to interview and is now just "shadowing" the main interviewer. The shadowing interviewer (sometimes just referred as "the shadow") rarely asks questions but this can happen. Without anyone shadowing, usually the interviewer (let's pretend that we just have one) introduces him/her self, tells what his/her job is, and tells how the interview will proceed from that point on.

The toughest question of them all. This is a really important question and it is crucial to respond well. The question is usually just as simple as "why our company?". The question is meant to discover why you want to work for that employer and to check if those reasons are "good" and if they "fit" the company values and culture. Let me take a diversion: would you work with someone who does not care about what he/she is doing and does not care about the company he/she works for? Probably not, and neither your interviewers do. As a general suggestion: at least inform yourself about the company you are interviewing at, ask in forums, chats, etc. and try to have a rock solid response on that question. I have seen technically good people that did not know what the company they interviewed with was actually doing and being discarded. Who assures the interviewers that you will stay if you do not even know why you want to be hired? Hiring and forming someone takes money and time. Hiring someone is an investment for the company. Notice as well that this does not need to be an epic story of how you think the world would be a better place if only everyone worked in the company, etc. Just a couple of sentences like "you work on X, Y and Z technologies and I am really passionate about them", "I really like the fact that the company has high standards in…", etc. Essentially, what is the reason why, if we hire you, you will not leave tomorrow just for a better offer. Just a funny note: I once interviewed one guy that was referring to the company always with the wrong name, the one of the main competitor… on the justification side for the candidate, it was late and I was the last interviewer of a long list 😊

I see you went to Mars…. Usually, one or two questions are made with respect to past jobs, competencies and projects. These questions are straight out of what you wrote on the CV, usually to understand better the contribution on those project, i.e., what was the specific piece that you did, the major challenges, etc. Sometimes, this can be THE truth test on the CV itself: do you really know 10 different databases? One good thing that you can do to help yourself is to always say the truth on the CV and put there only the things that you are really able to defend in front of an interviewer. Back at the university, I learned Pascal and I programmed with that for two terms but it never made to my CV.

Let's write some code. Many interviews (see below for the exceptions) have an exercise part. The candidate is asked to write down some code to solve a problem or two. Now, the very purposes of those exercises are to ① continue to make sure that what you wrote on the CV was true, ② check how you write code and ③ understand how you think in front of a problem. More in details, the first one should be easy to understand: if you claim to know Java, you need to be able to code in such a language and to respond to questions like "what is that static you put in front of the method?", etc. The second one is about the quality level of the code you write as checking for null arguments, bounds, non-valid values, etc. Conciseness and clarity are evaluated as well. The third one is the most interesting one. The interviewer is more interested in knowing how you think than on the solution itself: you are under stress so something could go wrong but the way you think must be clear and the options that you consider must be sensible. Please, think loudly all the way through the exercises. If you do and you take the wrong way, the interviewer can steer you in the right direction. If you do not think loudly, you are 100% on your own and if you get the wrong path, well, that's it. Another aspect of this is that the exercises are usually increasing in difficulty. The interviewer usually starts with something easy and then more complex questions are asked. Sometimes, an easy question is just the starting point to talk about other things such as data structures, etc. If you are in doubt about the question, ask for clarification: sometimes, questions are left ambiguous on purpose to see if you spot such ambiguities (the real world™ is full of ambiguities). Unless you are applying for a position in which you will use a very specific programming language (e.g., you applied for a JavaScript front-end developer or a Ruby-on-rails developer), you will be asked to choose the programming language to use: chose either ① the one you know best or ② the one that permits you to write more "condensed" code. The first one will make sure that you will probably use it right and the second one that you will not take forever in writing code that is not central to the exercises. Two final remarks: testing and complexity. For the testing, think about how you would test your code, you will not probably be asked to write the tests down but do a mental map of the things you would test such as $null$ parameters, empty arrays, negative indexes, etc. Doing this mental exercise will also help you correcting mistakes while solving the exercise. For the complexity, think about the big-O complexity of the code you wrote (is that quadratic or linear?) and this will help you also understanding if it would be possible to do better when asked about it (and that will be asked).

Making sure the place fits you. Usually, in the last 5 to 10 minutes, the interviewer asks if the candidate has any questions. Do prepare some for two reasons: ① you will look interested in the place or position, and ② you can get more information on the future life in the company helping yourself to make the choice of accepting or not the offer that will be proposed if everything is fine with the interviews. There is a full range of different questions you can make, from the simplest "what do you like most here?" to "what do you use for testing?". The questions are important but the responses even more: after hearing them would you like to work here?

Other Kinds of Interviews

There are other kind of interviews but they more or less have the same shape and only the «exercise part» changes, meaning that some interviews probe something else. Among the things that can be probed there are "thinking out of the box" and "soft-skills".

Testing soda cans. Thinking out of the box questions are meant to see how flexible in thinking the candidate is. The most common form in which they are presented in the one of "testing" exercises. These exercises have the only purposes of checking how you think. You are usually given a very simple thing to test with almost no context (when I did that, I had to test a can of soda and the guy entered the room with an empty can of Pepsi Max and put that on the table, by the way, hi Eric, how are you?). What the interviewer expects is not you to really test cans of soda but if you are comfortable enough to work out of your normal environment. What is expected from you if to come out with questions about what we need to make sure of, if there are any constraints, etc. Moreover, it is important to come out with something sensible and realistic about the task (no, you probably do not need to test cans in outer space).

Thou shall not kill colleagues. Soft-skills are a strange beast, usually undervalued or misunderstood. Soft-skills include a full range of behaviours that make you a good team player and someone "nice" to work with. Usually, the soft-skills interview is conducted over lunch (as no pen nor whiteboard is required) and involves questions to probe the ability of working in some sort of team or collaborative environment. The questions usually make people call out examples of difficult situations, from the people interaction point of view, and how you contributed solving them. Notice that not being able to solve them but saying that now you understand how the situation could have been addressed is a good response. This could be a little difficult to probe on junior hires who come straight out of college as they are likely not to have faced big problems, but still not impossible as difficult home mates can be a good thing to interview on. Usually the interviewer is a manager of some kind who has seen more than one difficult situation. Unless you are a psychopath or someone with a larger than life ego you should not fear this kind of interview. This kind of interview can be particularly tough in the case in which you apply for a managerial position and, in that case, the interviewer will be a senior manager, sometimes paired with someone from HR.

Questions I do not (Personally) Like

There are interviewers that have pretty "bad" questions in their arsenal. I consider these questions bad because they can either provide no useful information about the candidate or they are prone to misinterpretations.

What do you know about us?. First of all, what is a good response for this question? Just what you could find in the "about" section of the website of the company or some kind of mythical description of the company such as "you incarnate the American dream! You started from nothing and you become an empire!"? Honestly, the only place where this question would make sense is you are interviewing for 007's SPECTRE and any response different from "nothing" would mean your death.

Tell me about a situation in which you failed. Do you mean when I failed and I recovered or I just survived? Is this a technical failure, like a massive crash in production? Is this about the time I put salt instead of sugar in my coffee? Probably this question is a very bad formulation of the more common "challenges" question: as an interviewer I am interested in knowing how you solve things because, well, «shit happens» and every one of us at a certain point did something bad, but did you learn from it?

Why do you want to leave your current place?. Unless you have some evidence that the candidate is some kind of psychopath on the run, the best you can get is a lie or some bland approximation of reality. Let's suppose that I am leaving because my company is moving all the operations in another place but the thing is not public yet, I couldn't tell you for the confidentiality agreement with the company. I could leave because my ex got hired and I cannot see her without crying blood. Are these good reasons? What do you know more of me as a future colleague now? Just ask "why our company?" and you will probably get a better idea. Confession, I have to admit that I used to ask this question but then I realized how stupid it was and I stopped. If it happens that I asked that to one of the readers, please forgive me.

Pretend you are in a control room and everything is going goofy, what do you do?. Or more in general all the questions that require too much imagination. Let me do a step back: usually these questions are born from real life cases in which something went horribly wrong but, as an interviewer you cannot say that so you start stripping off details that, probably, were essential at the time. The candidate has probably no clue on what would be available to him/her, thing that is not true for the people in the control room and probably the best thing that the user could say is something on the lines of "are the machines on?". This would be probably superfluous in a real case where monitoring systems can probably give you, if not the response, a very good approximation of what is going on. The interviewer, with this question, usually assumes many things that the candidate cannot know. Do you want a better version of this question? Transform it into a design, or testing, question on what would be good to have in a monitoring system. Too broad? Make another question.

What if…. If I would know what could have happened if some condition that never happened would have happened, I would probably be a millionaire and not being interviewing here. Full stop. Moreover, how could you ever know that I replied the right thing?

On the shape of manholes and other silly questions. Google and many other companies were known for asking these questions. They stopped because the only fact that you are able to check with this question is if the candidate already knew the question (and the response). A candidate is usually already under stress and he/she does not need a question that does not make any sense to go totally tits up. Leave those questions for the lunch break with your colleagues, if you hate them.

Questions with only one correct response. Unless the question is a knowledge question such as "what does static do in Java?" which has only one correct response, design or coding questions that have only one way to be responded correctly or, worst of all, that the interviewer think can be responded in only one way, are usually just a source of stress for both the involved parties in the interview.

Interviewing for Managerial Roles

Sometimes, the candidate is some kind of manager and he is applying to a managerial position (or you believe that he/she will become in a short time after been hired). What can you actually ask in such situations?

Let's think in another way, if you are not a manager and you are interviewing this candidate, what do you expect from this person if he/she would be your manager? Or, if you are another manager interviewing the candidate, what do you expect from this person if he/she would be a manager under you or the manager of a sister team of yours?

First of all, you should not look for miniature versions of yourself (as some "fresh air" can be good in the company) but there are things that a manager is supposed to know how to do: ① growing people in the company, ② know how to manage both up and down and ③ know the area and how to develop that further. More in detail, the first one should help making sure that this person cares about people reporting to him/her and knows how to move in making them progress in their career. The second one is to test what managers should be really paid for: saying "no" and "asking why" to higher management in order to keep things on the side of "possible" and how to make sure that everyone is "good busy" in the team that will report to him/her. The third one is to make sure that the person knows enough of the product he will drive and assess if he/she will be able to create a vision for the product and its evolution, i.e., being able to respond to the question "what's next?".

Still on the third part, sometimes these interviews are performed with the "kimono open", stating what problems the company is facing and asking what the candidate would do to address those problems: things to invest on, suggesting ideas on how to proceed, things to investigate, etc. These interviews are expected to be a continuous back and forth of questions between the interviewer and the candidate trying to define well the problems, the expectations and evaluate how realistic the solutions could be.

Conclusion

Hiring is the mission zero for many companies. If it is not, it should be. Interviewing is the line of defence to prevent "bad" candidates to be part of the company. Hiring good people is the mean of success for companies. Like cooking: you cannot make something good starting from bad ingredients. Performing technical interviews right is the way to make that line of defence effective. There aren't only technical interviews, the "soft-skills" part is important as well to make sure that you are not only hiring a good programmer but also that you are hiring a good colleague. Interviewing is also the way a company sells itself to candidates: if you treat them wrong, even if they are good, they are probably not going to accept your offer and join. Treating people with fairness and respect is the way to go to hire the good people making them accept your offer.

If you want to summarize everything to just on question, for both the interviewer with respect to the candidate and for the candidate with respect to the interviewer(s), that would be: "would I be happy to work with this person?". Because at the end, no matter how complex this thing can be, interviewing is the way you make new colleagues.

Post Scriptum

There are a couple of points that I left out of the above discussion just because I didn't know where to place them.

How do I recognize the "best people"?. I would start saying that this is probably the toughest question of them. Likely, I do not think that there is a general rule for this. Anyway, I will share my rule of thumb: I always try hiring people that can teach me something. This usually summarizes into finding people that either ① can bring in pieces of knowledge that neither my team nor I have, or ② people that are able to bring in the team new points of view on the same topics and things. These people are meant to contribute to the growth of the company, meaning that they must be able to change the direction the company is going if necessary.

Is it easy to find the "best people"?. Let me start from a joke that once a colleague of mine cracked (hi Giuseppe, how are you?): «all the best people already have a job». Which is 99% true. It is unlikely to find one best player without a job unless ① this person decided to take some time off from any job and is now looking again, or ② this person has not a job yet. The first case in the one of people who left a job to relax a bit and that are now looking for new adventures. The second one is really looking for junior candidates with high potential to become top players. So, what's the way to find them? Probably the best solution — and this is no joke — is to actively try getting them from other companies approaching them in conferences, through LinkedIn, etc. At this point, selling the position is a crucial job from the interviewer's point of view.

What's the CV to hire ratio?. From my (very) personal experience in large companies, the process that goes from sifting through the CVs to the hiring discards something in the order of 95% of candidates. If you prefer to see that from the other way around, only 5% of the candidates receive an offer. Roughly speaking, the CVs sifting process discards a good 50%, the phone screening process halves the number left (we now discarded the 75%), and the on site interviews do the rest. Just going with an example: one summer I went through, roughly, 120~150 CVs (that was not a nice summer), we ended up making 4 offers and only 3 got accepted and joined the team (for the most curious ones, the one who did not accept decided to go for a PhD instead). Which is between 2% and 3%. Now, before you hang yourself (or, if you are in Silicon Valley, any other suitable way to kill yourself as ceilings tend to be pretty low), there are cases in which the ratio is higher. The most common one is represented by people already working in the company who introduce former, good, colleagues as potential candidates to fill positions, and this should make even more important to hire the "best people" as they are likely to bring in other "best people".

Post Post Scriptum

I actually wrote this document 6, or more, months before its publication and the reason why I did't publish that on the spot — aside from the various small adjustments and language fixes — was essentially because I asked myself the question «who am I writing this for? Am I writing this for the interiewers or for the the interviewees?». Well, to be 100% honest with you, I still don't know but I sincerly hope that this could help both in either being more prepared to face an interview or to be better interviewers and focus on what I ganuinely believe should matter in an interview. With this last thought, I think I am done and ready for the press, I hope you enjoyed it.

Addendum to "Other Kinds of Interviews"

While talking with my friend — and former manager — Antonio, he made me notice that I forgot one kind of question in the "Other Kinds of Interviews": the design question. Design questions are the most classical example of open ended questions and they are useful for a couple of things, ① make you discover the ability of the candidate to think large and ② as a trampoline for other questions. Before going back to the targets of this kind of interview, let me clarify properly what I mean by design question. In a design question, the interviewer asks the candidate to design the architecture of some large enough system. Usually this system will need to span different logical subsystems (nothing too fancy, if you are scarce in imagination, think about a multi-tier system or a micro-services network of small services). Exactly as in the case of «testing soda cans», things are left ambiguous and questions are expected from the interviewee: how many requests do we expect? Do we need to consider case X? Etc. Now, as for the two points above, for the first one, you want to check the ability of the candidate to think about things that are well beyond a single component, e.g., scalability, load, work distribution, etc. For the second one, these questions represent a good way to test for other pieces of knowledge, e.g. data-structures, specific algorithms or techniques. Jumping from the design to these questions will need to be logical and a natural thing, e.g. "you mentioned that the module would need to keep data in X way, what would be the best data-structure for that?", and from there moving on asking more questions on the subject. Still on this second aspect, sometimes — and especially when interviewing a senior candidate — the follow up questions can stay in the same domain, e.g., "let's suppose that the system now needs to do X and Y as well, what do we need to change?", "how can we distribute that logical-unit/data-store over there on multiple machines?", etc.