My Adventures in the Interviews Jungle

 

As you know I recently switched jobs and while finding a new one I’ve done quite a lot of interviews in different companies.

I really enjoyed the process! Some days I had 3 interviews in a row! My friends called me insane but hey, I can easily talk about software all day long!

While looking for my next job I took the way a company’s interview process as a major factor for my final decision.

In my opinion the interview process should reflect the values, the culture and the professional level of the company. A company that values my time, tries to make me feel like home and asks question that actually reflect my knowledge is most likely a better company than a one that does the opposite.

In this post I want to share some of the questions and tasks that I had in my interviews. Some of them were great. They actually allowed me to show what I know and the overall process made me feel wanted and special. On the other hand there were some that were a complete waste of time.

Let’s start.

Ridiculous, exhausting and a waste of time

Bizarre questions

“How many hair cut places are there in Tel Aviv? How many golf balls can fit into a bus?” These questions were famous due to Google’s interview process where candidates had to answer super hard and bizarre questions.

Few years ago even Google stopped asking these questions!

“They are a complete waste of time” - Laszlo Bock, Google's senior vice president of people operations. 2014.

I couldn’t agree more – these questions don’t test anything and furthermore don’t have anything to do with the candidate’s future work.

When my interviewer asked me these questions I asked if their company found it useful. He replied ‘yes, Google does it and so do we’.

That was a red sign for me – if you copy from someone at least stop when they do.

 

Endless trivia questions

By “trivia” I mean questions that don’t make the candidate think. Usually they start with what and not with why. Those questions check whether the candidate knows the answer or not. “What is HTTP? What is a transaction?” They don’t focus on the candidate understanding of why something is used or how is it used. Only if he knows the definition.

Honestly - when was the last time that you used a Mutex? Or had trouble with the GC? Either way it’s googlable. So it’s ok not to know all the answers.

I think that some trivia questions can be useful for three reasons:

1. To check if the candidate is serious about the job and that he took his time to prepare for the interview. Serious candidates usually prepare themselves and come ready for interviews.

2. To check that the candidate is not a complete noob/code monkey. It’s a bad sign if he cannot answer any question.

3. To check if the candidate knows how to say that he doesn’t know something. If he tries to lie and make up an answer in the interview then he will probably do it again in a real situation.

In one interview I had an hour and a half of trivia questions! Needless to say that it was one of the most exhausting interviews I’ve ever done.

In the end I asked the interviewer if they actually need all this knowledge to their day to day work. He told me no. They don’t even use multi threading but he questioned me for 40 minutes about mutexes, threadpool and thread synchronization.

 

Writing code for hours

In one company I had a coding test as the second interview phase. I think that it’s essential to check the way the candidate writes code but and this is a big but it shouldn’t take 6 hours@#$!

A small coding task should check if the candidate writes tests (perhaps TDD), uses SOLID principles and that his code is clear and well written. A simple calculator task can check all these. Writing a 6 hours long project is a waste of both the candidate’s time and the interviewer’s.

The worst part is that it’s in the company office (and not a home task) so the candidate will be stuck for 6 hours in a row writing code for some test in some company. Writing some code in the company office is good but only if it doesn’t takes the whole day.

 

Text exams

As I mentioned before, there shouldn’t be more than a few trivia questions in an interview. The only thing that is worse the asking 30+ trivia questions is having them in a written exam while the interviewer is not even present.

Those tests give the candidate the feeling that his time is not valuable enough for an interviewer to be present while he answers.

As a candidate I want to have the feeling that I’m wanted and that my time is valued. Leaving a candidate in a room alone with a text exam does exactly the opposite.

It can be even worse if the text exam is Scott Hanselman’s 25 things that every .NET developer ought to know and the interviewer tells that it is his private collection of questions.

 

The Good Parts

Now let’s go through the interviews that I really enjoyed, the technics and questions which allowed me to truly show my skills and made me feel wanted.

Home project, code review and pair programming

In one company I also got a coding project however it was a home project meaning that I could go home, work on it whenever I wanted and send them back the solution when I’m done.

This is so much better than working on it at the company during the interview. It allows me to put in as much effort as I want while doing it in a familiar and comfortable environment.

After I sent them the code I was invited to a code review. I think that this is the best possible interview since it checks everything! Both my coding skills, my ability to explain my choices and to see how I accept critics.

After the code review I was asked to change something in the code – it took just 10 minutes but the interviewer sat with me the whole time and was part of my design choices. It was more like a pair programming than a test. It allowed me to show how I think before I code, my TDD skills and it also allowed me to see how it feels to actually work with someone from that company. This was the best interview process!

 

Team Leader/Group leader who is in charge of the interviews process

As a candidate you usually talk to the HR in order to schedule your interviews, to get more info about the company and simply talk between the interviews. The HR are usually really nice girls (never met a HR guy) but it’s way more welcoming and respectful when your point of contact is a team or a group leader of that company.

It makes you feel important and that you are taken seriously since a manager is investing time from his busy schedule to walk you through the interview process in his company. A company that shows this kind of respect to a candidate must show even bigger respect to it’s employees and that is a company that I want to be part of.

 

CEO that talks to the candidates

I really valued the companies that their CEO invested ~30 minutes to get to know me and tried to make me feel like home even before I decided to sign with his or her company. When the CEOs shared their visions for their companies and told me their missions and values I felt an immediate connection. These talks were the last step of the interview process and companies who’s CEO actually called me or invited me to come and talk to him made me appreciate that company more than others and that is a major decision factor.

One CEO even called me from San Francisco just “to get to know me”. He is the CEO of ~100 people. If he could find the time then most of the high level managers in not huge corporate can.

 

Architectural and design questions

I was surprised to see that most of the companies didn’t ask me architectural questions. Only 2 companies wanted to know if I understood the architecture of the projects that I’ve worked on.

“Why do you have a load balancer? Why don’t you use micro services? Did you have a DRP? How does it work? What is the most fragile place of your architecture? What should you change? How? Why?”

If the trivia questions have usually the “What” prefix then the deep design questions will have the “Why” and “How” prefixes. This way the candidate must understand the pros and the cons of the architecture and more importantly to understand why the architecture is the way it is.

I think that these sort of questions show whether the candidate was just a code monkey or if he truly cared and understood his project.

 

White board role playing

Almost every company asks the candidates to approach the white board to solve a problem or design an algorithm. Remember that the solutions doesn’t matter! It’s how you thinks what’s important. This is why it’s important to think loudly and share your thoughts with the interviewers.

This is a great test however I think that it can be even better.

In one company after I solved the problem at the white board the interviewer stood up and told “now it’s my turn”. He asked another question (something about modeling and design) and then approached to the white board and started to sketch a solution.

Then he asked me if that works and if his solution was good. It wasn’t and I had to spot the problem and then explain him why his solution wasn’t good enough. It was great!

We switched roles and I felt like the interviewer. It was a simulation of a technical argument and he wanted to see if I can spot the design problem and most important part to see if I can hold on to my position and be able to convince him that he was wrong in a good and calm way. This is also one of the best interviews I had.

 

“How do you keep learning?”

There are plenty of developers out there. Only a small part of them are truly great developers. Many things distinguish them from the mediocre ones. One of them is what I call “Continuous Learning”.

The truly great developers always keep learning. They code, they read they write about it, they go to meetups and they are always up to date. Every company want these developers since they will always bring you progress.

If someone asks you to share this then they probably also care about learning and that place will probably have great developers who work there.

 

“Tell me about something that you are proud of?”

Enthusiasm and ownership are extremely important qualities. Every company wants their developers to be enthusiastic about their work, to have ownership for their features and to feel accountable for the application that they are building.

In order to be proud of something you must be involved in all aspects of the product development. You must feel that you own that something to the bones. If someone is truly proud of a feature or a product then he will talk enthusiastically while describing it.

I really liked when in one interview I was asked to tell about a feature that I was proud of. I could explain why did I think that this feature is important, it’s complexities and how did I actually developed it. It allowed me to show my understanding of that feature and my enthusiasm of software development. This is impossible to reproduce with only trivia questions.

 

That’s it.

This was a summary of most of my interviews. It was really interesting to see other companies and developers and to be tested for my skills. My personal advice is that when you go to an interview don’t be in the state of mind of a candidate that needs “to pass” the company’s tests. Go there and be the interviewer. Sure answer their questions, but don’t forget to ask yours. Remember that you are special and not every company deserves you. So be smart when choosing one. I think that the interview process can really help in deciding whether the company is worth going to. I hope that this post helped you know what to look for.

Good luck and feel free to share your experience!

 

* I want to thank Netanel Lev for review this post.