FAQ

Technical Interview Types

Source: https://www.freecodecamp.org/news/software-engineering-interviews-744380f4f2af/

Algorithm Interviews

The most common type of interview you will encounter. The interviewer will ask you to solve a problem on a whiteboard which will assess your knowledge of data structures, sorting algorithms, recursion, time/space complexity analysis as well as pattern and edge-case recognition. In this interview, you will most typically come up with a brute-force solution, and then try to improve upon that solution and discuss the tradeoffs, if there are any, with the different solutions you propose.

Architecture Design Interviews

The interviewer will ask you to design a system (on a whiteboard of course) such as a car park ticketing system, chat messenger, twitter feed, amongst other common systems.

What you’re being assessed on is how you take a broad concept and design a system which meets all the requirements and constraints. But it’s up to the candidate to ask the right questions, which define the requirements and constraints. This interview is more of a conversation mixed in with some drawing diagrams and perhaps even class structuring. Everything is quite high-level, so you won’t be writing any actual implementation code.

Naturally, you should steer the conversation to cover your knowledge of how systems work. If you’re a backend engineer, you wouldn’t really go into the mechanics of the client application details unless you had some previous expertise in that area. I’m an iOS engineer, so I talked about architecture patterns, modularisation of functionality, design patterns instead of how to scale the API endpoints, adding workers, AWS, and such.

Behavioral Interviews

The interviewer will ask you questions about yourself and how you deal with certain types of situations. The preparation for this one isn’t as difficult as the others but does require a lot of introspection on your own behalf.

The questions are typically along the lines of:

  • How do you deal with failure?

  • What is your biggest weakness?

  • How do you resolve conflicts?

  • What would you do differently?

Just be genuine, show passion for your work, own your flaws, show initiative for improvement and you’ll do fine.

Pair Programming

An interesting category for which you will be paired with another engineer in front of a computer which has been set up with a development environment, much like what you would be using in the real world. You’re given a basic task with a list of requirements which you must complete, as you finish each task the interviewer will ask you to implement more functionality until the time limit is reached. You’re free to use whichever resources you want, such as Stack Overflow or online documentation.

I feel like a lot of a candidate’s success in this interview would be determined by exposure to real-world experiences. Unlike whiteboarding, writing syntactically correct code is required, so you should know your language and environment inside and out because you don’t want to be spending too much time on the internet or documentation searching for answers.

Testing Domain Knowledge

Programming is fundamentally the same across most of the common languages we see today. Chances are if you know object-oriented programming in one language, those skills will mostly transfer to another.

However, this interview focuses on the aspects that cannot be transferred between languages or frameworks. You will be interviewed on environment specificities relating to API, memory management, capabilities, constraints, history, and so forth.

Culture Fit

This is usually paired with the Behavioural interview and is focused on finding whether you are aligned with the company’s values. For example, Facebook follows the hacker-like culture of being bold and shipping new ideas, trial by experimentation, not being afraid to break things. Whereas Airbnb wants to create a world where people feel like they belong anywhere they go, so they look for people with great hospitality skills.

A lot of the big tech companies put a lot of emphasis on the culture and hire people based on that person’s alignment with their values. If you’re interviewing at one of these companies, it’s important that you look up their values and find past experiences in which you’re able to relate and communicate to your interviewer.

Minimum knowledge

If anyone were to ask me what I felt would be areas to focus on, I’d suggest the following:

  • Learn to write code by hand on paper and a whiteboard first and then throw it into an IDE for syntax highlighting, this should become second nature to you.

  • Develop deep knowledge of data structures, their strengths, and weaknesses in comparison to each other. I discovered that implementing data structures and their behaviors from scratch taught me so much more than what I knew from their abstract concepts.

  • Completely understand Big O notation for both time and space complexities, this will pair perfectly with your algorithm and sorting questions.

  • Grasp all major sorting algorithms because the difference in time/space complexities have the potential to derail your optimum solution for an algorithm you’re trying to solve.

When to start

Depending on your timeline, you may want to start sooner than later. A lot of the companies I interviewed with had a 12 month cooling period before a failed candidate could reapply. On the flip side, if you know you won’t be ready within a year, you may as well start the process now and get a small taste of what it’s like to go through the interview process so when you are ready, it won’t be nearly as scary.

Resources

Mock Interviews

Algorithms

Operating Systems

Architecture Design

Behavioral

PreviousStudy Game PlanNextSalary Negotiation for Internships

Last updated