Break open interviews: on algorithms, on architecture, behavioral, etc.

I have just completed seven interviews at Silicon Valley companies. I ended up accepting a software development offer on Facebook.

This is how I prepared for this interview and what I learned along the way.
')

My long journey to Silicon Valley

When I studied computer science at my university in Australia, I always represented my future as a software engineer in Silicon Valley.

I liked the idea of being at the center of all the innovations in the technical industry, as well as its blunders. This goal motivated me. It helped me focus.

I left my place as lead iOS engineer in a wonderful company in Melbourne and I went back to my hometown of Perth to study. Here I will prepare for the negotiation process that is waiting for me in Silicon Valley. I knew it would be incredibly difficult and hard.

If you mentioned a technical interview in a room with software engineers, many will oppose the usual interviewing techniques. Most of the arguments are based on the fact that solving algorithms on a board does not actually represent the everyday tasks of a software engineer.

For the sake of this article, I will not enter into this discussion. Instead, I will look at the different types of interview methods from a candidate’s point of view. I will also focus on what I learned from this process.

The translation was made with the support of the company EDISON Software , which is professionally engaged in the development of software for large customers (for example, an urban lighting control system or an electronic medical examination system ).

Interview is a skill

During my training, I understood all the time that the interview would be difficult. But I honestly had no idea how hard it was, until I was at my first interview.

In the run-up to the interview, I used both paid and free services that imitated telephone interviews with people who had real experience interviewing candidates. These practical interviews were important in order to overcome the pressure. But, as I understood later, they constituted only a part of what the real interview consists of.

I would advise you not to have an interview for the job of your dream, not having a few fictitious or real interviews in the background. Nervousness can be incredibly overwhelming, and can only be blunt through practice.

As in many other situations in life, the practice will increase your confidence.

Different types of interviews that I have encountered

If you prepare and perform well enough prior to the interview by phone, you will be given the opportunity to get to the site and have an interview all day. These interviews usually last from four to six hours depending on the company in which you are interviewing.

During my trip to Silicon Valley, I managed to pass seven interviews on the spot. This gave me a unique experience in interviews in its current sense.

As a rule, there will be three main topics on the spot; algorithms, design and topics of behavior that I studied and prepared. However, there are some companies that seem to break this trend and expand their interviews so that they can cover more practical skills.

I will briefly review each of the topics I have encountered.

Interview on algorithms

The most common type of interview you will come across. The interviewer will ask you to solve a problem on the board, which will evaluate your knowledge of data structures, sorting, recursion algorithms, algorithm complexity analysis (time / space complexity), as well as risk recognition. In this interview, you will most likely come up with a bad decision, and then try to improve that decision and discuss the trade-offs, if any, with the various solutions that you propose.

It was the bread and butter of my preparation, every day for six weeks, I solved the algorithms on a cheap hanging board, evaluated their complexity (time / space complexity), and also really tried to understand what was going on in each line of code.

Personally, I really like to solve algorithms on the board, because I don’t have to worry about writing a syntax to compile (most of the time), which allows me to focus exclusively on the task. Other people may not like the board, but I would advise them to try it, and they may change their mind.

Architecture Design Interview

This is an interesting interview, which I greatly underestimated. The interviewer will ask you to develop a system (on the blackboard, of course), such as a parking ticket system, a chat messenger, a twitter channel, or some other similar system.

What you are evaluating is how you understand the basic concept and develop a system that meets all the requirements and limitations. Also, the candidate must ask the right questions that define the requirements and restrictions. This interview is more of a conversation, mixed with charting and perhaps even class structuring. Everything is pretty high level, so you won’t write any actual implementation code.

Naturally, you must manage the conversation to show your knowledge of how the systems work. If you are a backend engineer, you wouldn’t go deep into how the client application works if you had no experience in this area. I'm an iOS engineer, so I talked about architecture, modularization of functionality, design patterns, and not about scaling API endpoints, adding employees, AWS, and so on.

Behavioral interview

The interviewer will ask you questions about you and how you deal with certain types of situations. Preparing for this is not as difficult as for other interviews, but it will require your own self-analysis.

The questions are usually the following:

How do you cope with failure?
What is your greatest weakness?
How do you resolve conflicts?
What would you do differently?

I feel that it would be quite difficult to fail him, but I heard that a lot of people were failing. They try to hide their strengths as weaknesses, project their reactions to what they think the interviewer will want to hear or even simply blame the failed projects on other people.

“My weakness is that I am too focused.”
“It was all Jerry's fault, he was responsible for much of the project.”

These interviewers are trained and honed to identify trashy people and pay special attention to this. Just be sincere, show passion for your work, be aware of your shortcomings, take the initiative to improve, and everything will be fine.

Compliance with corporate culture

This is usually included in the behavioral interview and is focused on determining whether you meet the criteria of the company.

For example, Facebook should be a hacker-like culture, welcome bold and new ideas, and apparently are not afraid to spoil something. And Airbnb wants to create a world where people feel at home, wherever they are, and therefore they are looking for people with hospitality skills.

Many large technology companies pay great attention to their culture and hiring people based on the compliance of this person with their values. If you are interviewing one of these companies, it is important that you pursue their values and, based on the experience gained, can communicate them to your interviewer.

Pair programming

An interesting category in which you will be paired with another engineer in front of a computer, to which a development environment will be specially installed, very similar to the one used in practice. You will be given a task with a list of requirements that you must fulfill as soon as you finish the task, the interviewer will ask you to demonstrate more functionality until the deadline for the task is completed. You can use absolutely any resources like Stack Overflow or documentation.

It seems to me that the success of a candidate in this interview will largely be determined by his readiness for practical tests. Unlike the blackboard, writing syntactically correct code is simply necessary, so you need to know your language and development environment in which you work, both from the outside and inside, because you do not want to spend too much time searching for answers on the Internet or documentation.

During my previous work, I tried to write clean code while working on the task. This kind of workflow was not effective in the case of this type of interview. I managed to push myself to a standstill with my clean code, optimizing the program too early, it was hard to get back to where I started. I realized that writing incomprehensible code and reminding the interviewer that I would have done everything differently in actual development is considered sufficient, unlike writing clean and optimized code.

Search and correction of errors

Much of what we do as engineers focuses on finding and fixing bugs that are reported to us from various sources. In this interview, you will be given a list of errors for finding and fixing them, as well as identifying other potentially problematic code.

I saw only one case of this type of interview, and I feel that it will be really difficult for someone to prepare, especially if he is a junior. Each programming environment has its own small quirks and nuances, many of which emerged due to my previous experience with the integrated development environment (IDE) and similar frameworks that I have used over the years.

Testing knowledge in your field

Programming is fundamentally the same in most languages that we see today. Most likely, if you know object-oriented programming in one language, these skills are suitable for another.

However, this interview focuses on aspects that cannot be linked between languages or frameworks. You will be interviewed about the features of the environment associated with the API, about memory management, about the possibilities, limitations, history, etc.
Preparing for this particular topic is probably more difficult. As in the case of interviews related to search and correction of errors, I feel that many of the answers will be based on the experience already gained. Depending on the level of the role you are applying for, the answers you give may be weighed differently. For example, if someone applying for a junior does not know the history of why the API is structured in a certain way, they may be given a concession. However, if a candidate applying for a senior role does not know the answer, he will be assessed more strictly.

Understanding operating systems

Depending on the role or team you are interviewing, you may have an interview that focuses exclusively on operating systems. In this interview, you will be asked questions that will evaluate your understanding of the lower level of the computer's operating system.

To be honest, this interview took me by surprise. Operating systems were what I learned in my early years at the university, but since then my knowledge has become vague on this issue, which is reflected in my characterization.

How should you prepare

As I wrote earlier, the interview is your skill. Even if you are already a great programmer in your daily work, or get excellent grades in your studies, you will not be able to pass on 1 to 1 your skills when you find yourself in a tiny room for interviews. Perseverance, repetition and consistency with the preparation and practice of interviews will be key determinants of your outcome.

Minimum knowledge

If someone asked me what areas I need to focus on, I would suggest the following:

Learn to write the code by hand on the leaflet and the board first, and then transfer it to the IDE to highlight the syntax, this should be your usual business.
Develop deep knowledge of data structures , their advantages and disadvantages in comparison with each other. I found that implementing data structures from scratch and their behavior taught me much more than what I knew from their abstract concepts.
Fully understand the concept of Big O to understand the complexity of algorithms (time / capacitive). This is great when you come up with questions about algorithms and sorting.
Master all the sorting algorithms , because there is a great chance that the difference in the complexity of the algorithms (time / capacitive) may fail your optimal solution for the algorithm that you are trying to solve.

When to start

Depending on the time frame, you may want to start as early as possible. Many companies I interviewed followed a 12-month pause before a failed candidate could re-apply. On the other hand, if you know that you will not be ready in a year, you can just as well begin the process now and feel what it is like to go through the interview process so that when you are ready you are not so scared