How to pass the first round of my interviews

If you are reading this, then congratulations, you’ve just checked one of the things that I am looking for in a candidate; the ability to do some basic research. In this case, by simply reading information about the company you are applying to.

I am astounded by the number of candidates that come for an interview and have no clue what the company does exactly. Except of what the – clueless recruiter – might have told them, they haven’t even bothered to check the company site in detail. There is occasionally someone that has read the first paragraph of the home page, but that’s usually it. If you don’t give a damn or don’t even have the curiosity to check out the place you will be spending a large part of your day, then I do not want to work with you.

If on the other hand you do give a damn, then keep reading.

Don’t be late. I hate when people are being late. I do not care about any excuses, and unless there was a real emergency, you should be on time. It’s a sign of respect, professionalism and that you understand that your time is not more important than the other person’s time.

I will be polite upon your arrival. I will offer you something to drink, probably give you a few options but please choose the water. It’s not a cafeteria and I am not your barista. I am your interviewer so do not abuse my hospitality. That means you should not ask me for a latte like someone did once. Yes, that has really happened. He wanted to look "cool" as they advised him in the computer science school he went to during his "how to prepare for an interview" course. Nope, I did not find it cool.

We will be moving to the meeting room where the interview will take place. I am an easy person to talk to so try to relax. We will start with some casual conversation about your past experience, things that interest you, what happened to your last job, what you expect from your new job, how you try to improve yourself every day, what was the last book you read, what hobbies you have and basically anything else that might give me the slightest clue about the person you are.

I want to be absolutely clear about this. What type of person you are and how well you will fit in the team is the most important thing for me. Of course, your technical skills are important as well, but let me put it this way; if it comes down to two candidates, and the first one has an open personality and qualities that I am looking for, but the second one does not, although their technical skills are better, I will ALWAYS choose the first one. You can teach a skill but you cannot teach someone how to be a human being.

What qualities am I looking for? Honesty, patience, someone who is observant, reliable, and respectful of those around them. I want to see a passionate, trustworthy person. A person that is not always looking for excuses or whines about everything but rises up to the occasion. And of course, to have some sense of humor, because, what is life without humor?

Try to be as sincere as possible about yourself. Even if you pretend to be someone you are not during the interview, or if you manage to give the answers I want to hear, you won’t be able to hide your real self after a couple of months of working closely together. Under pressure, all characters are truly revealed. And you will be pressed. So please, if you plan to bamboozle me, do both of us a favor and walk away because I will be reluctant to work with you.

At some point, after I feel I have heard enough about you – or too little – we will move to the technical part of the interview. Please do not suck. No seriously, please do not suck. By sucking I mean that when I ask you to write a for loop (for a simple “FizzBuzz” test) on the whiteboard just to check that you are actually able to write ANY code at all before we proceed, please do write it without hesitation. Unfortunately, it has happened more than once people tell me “I haven’t written code for the last couple of months and I do not remember how to write a loop at the moment” or “I did not expect to write any code. Nobody asked me in the other interviews”. SERIOUSLY? This is an interview for a software development position. I definitely want to see SOME code.

Yes, I know that phone screens exist, yes I know that you can give to the recruiter a cut-off test, yes I know all about the awesome ways to avoid wasting your time, but sometimes, these people just slip through and my answer to these people is, find a different work field. I know that someone told you that computer science “is the future” and that all the cool kids are doing it, but obviously, you do not like it. If you did, you would know how to write a simple for loop. Find something you like instead, be great at it, stop wasting your time, and even worst, others’ time!

Depending on the level of the position you are applying the questions will vary, but there will be something in common. Through the questions, I want to understand what kind of knowledge you were able to acquire from your experiences. I need details. It is not the amount of knowledge you have acquired that interests me, it is the ability of actively trying to recognize and acquire that knowledge through the challenges/opportunities that were presented to you.

I want to hear about your personal preferences and opinions about software. Do you have a piece of code that you like to show me and take me through it? Why did you do it with X way instead of Y way? Do you have a favorite editor? Which tools do you use? Do you have a favorite programming language? Why do you like it? Do you have a least-favored programming language? Why do you hate it? Have you done a project that you are proud of? How was the code organized? What challenges did you face? What do you think you could have done better? Are you familiar with functional programming? If yes, do you prefer it over OOP and why?

If your answer to most of the questions above – or similar ones that I will ask – is “I haven’t really thought of it” or some other passive answer, then I do not want to work with you.

In most interviews, there are theoretical questions like, what is OOP? What is a class? What is polymorphism? What is a linked list? What is the difference between stack and heap? What is a binary tree? What is inheritance? What is encapsulation? What is a singleton? What is the difference between merge sort and quick sort? I will not linger a lot on this kind of questions but I will definitely ask a few. To be honest, I do not expect an exact definition from Wikipedia, but I do expect you to be able to give some kind of answer in your own words or through an example. These questions should be easier for a person that just got out of University and has all this theory fresher, but seniors, please, do brush it up a bit as well.

The one thing that I will not be very kind with bad answers is recursion, especially from senior developers. In fact, I will ask you to implement recursion. The most common exercises with recursion are to find the factorial of a positive number n or calculating a Fibonacci sequence or walking a directory tree. Do not worry about the math in the first two, I will give exact instructions. In fact, you will not need any math knowledge at all. As long as you understand recursion, you will have no problem implementing any of the exercises. If you are a junior candidate and you are not very comfortable with it, please do try without whining that “I am not a mathematician” like someone told me once. There will be no math. I will give you all the definitions and clarifications you need. It’s just another programming problem you need to solve and you will have all the time in the world. JUST TRY.

Although theoretical questions are some kind of indicator, at the same time it does not really show a person’s real experience. You could have just memorized all the theory, read all the “How to pass a coding interview” books and manage to succeed with a little bit of luck and by manipulating the interviewer on a weak day. I really don’t understand why a person would do that but it can happen. In fact, some people have the nerve to see how far they can go by trying to fool everybody even after they get hired. That can mostly work in companies with a lot of employees. In small teams the value of their work has a more direct effect and it’s harder to hide.

Therefore, the following part of the interview will be the most important one. Through real-world use cases, to show me your experience. To show me that you have tried to solve actual problems and you have bled while doing it. These can be from “What fields would a database table need for a user authentication system?”, “What is the difference between authentication and authorization?“, “Why would you use a finally clause in a try-catch-finally statement?”, “What are some common logger levels?” to very specific ones like “How do you enter and exit the Node.js REPL?”, “How do you run the debugger with a keyboard shortcut in your favorite IDE?”.

Do you have some specific examples on your own? Even better, please share them with me! I always enjoy empathizing with the pain and joys that come with software development. I understand that you are worried that you might not have experience with any of the questions I might ask. I assure you that if you have actually worked on ANY real problem with ANY programming language, framework or technology, we will find some common ground.

I wish you good luck!

PS: I have humor.