Types of Technical Interviews
The different flavors of technical-oriented assessments
Interviewing at a tech company will often require an assessment focused on evaluating the technical skills of a candidate. The exact interview format often varies from simple, abstract problems to full-blown applications. I’ll try to enumerate some of the different interview types and discuss their strengths and weaknesses, both from interviewer’s and candidate’s perspective.
Coding Challenge
In a coding challenge, the candidate will be given a relatively simple problem, that needs to be translated to working code to be solved. Someone may now ask, isn’t that called an algorithmic challenge? As you’ll see next, I reserve this term for challenges where designing and understanding the algorithm itself is a substantial part of the interview.
Some problems that fall into this category:
Count the occurrences of each string in an array of strings.
Find the common elements between two arrays of integers.
These problems sound simple but they can provide significant insights into someone’s capacity to effectively communicate their thoughts and display their methodology to problem-solving in general. In addition, there is often an expectation to write unit tests to verify the solution, along with identifying and covering edge cases in the code.
Although not usually crafted for performance-related discussions, there’s still room for such questions in the everyday engineering context. Are we applying micro-optimizations versus favoring readability and maintainability for non-performance-critical code? Are we using a sub-optimal custom implementation that could be replaced by a standard library function?
Another interesting aspect is testing the knowledge depth and experience of a programming language. Are they knowledgeable about the standard library and language constructs? Do they write non-idiomatic or even error-prone expressions? Are they familiar with the error handling and unit testing fundamentals? Note that language selection is often open to a large set of popular languages, but certain companies will narrow the choices down to a smaller subset or even a single language, if they consider these fundamental to the organization and a prerequisite for any position.
You may wonder what happens when the interviewer doesn’t have experience with the language chosen by the candidate. Although a not-so-ideal scenario, an interviewer can still assess the ability of the candidate to explain technical matters to someone experienced in software engineering in general, but having a specific knowledge gap. Being able to narrow down the scope of shared information in this case is also a sign of experience. If you have mentored or collaborated with other engineers closely, you likely had the chance to explain your approach on multiple occasions.
🟡 Scalability/Performance
🟡 Testing
🟡 Problem-Solving
🟢 Language Proficiency/Ecosystem
🟢 Practicality
🔴 Systems Thinking
Algorithmic Challenge
In this case, the candidate is requested to provide an algorithm for solving a difficult problem, such as Tree traversals or other operations, Graph searches, sorting. The solution usually requires a deep understanding of data structures, graph theory, set theory and mathematics. Apart from the inherent difficulty, these problems most likely have performance-related components, which must be discussed during the interview in the form of analysis on space and time complexity.
Although pseudo-code may be applicable, or even requested as an initial step, most interviews will also require writing working code as well, and even reach the stage of delivering unit tests along with the solution. You may now wonder if that’s a more difficult Coding Challenge. There is indeed an overlap, but due to time restrictions, the interviewers will likely not have enough time to dive deeper into all the focus areas that were mentioned in the previous section.
A significant drawback of algorithmic challenges is that they may require prior knowledge or exposure to a specific Computer Science problem (e.g. detecting loops in linked lists). Although working with the interviewer to see how you approach problem-solving still plays an important role, there is a chance that some candidates will not go very far in the discussion unless they have a breakthrough moment.
Interviewers may also face a problem with becoming biased when knowing the solution beforehand. Inevitably the solution seems obvious over time. This effect can be mitigated, by alternating interview questions after a fixed period of time, e.g. every quarter.
There is a major debate on the value of difficult algorithmic problems within an interview scope. They are frequently regarded as not being in touch with everyday engineering practices and possibly dismissing valuable experience of other important aspects of software engineering. A counter-argument may be that they reveal the candidate’s exposure to highly-scalable, performance-critical applications where space and time complexity matters to the extent of rendering a solution non-functional. In addition, a strong CS background is actually required in some positions. For example, if you are interviewing for a position in a team developing a NoSQL database system, you’ll have to display some understanding of how Trees work.
🟢 Scalability/Performance
🟡 Testing
🟢 Problem-Solving
🟡 Language Proficiency/Ecosystem
🟡 Practicality
🔴 Systems Thinking
Project Assignment
While the two previous types are almost exclusively performed synchronously in collaboration with the interviewers, a project is usually given in the form of an assignment. It is often criticised as requiring a significant time investment on behalf of the candidate, though this varies on the scope of the project: some assignments can be fully completed in 1 or 2 hours, others will imply an expectation of spending 14-20 hours within a calendar week for a high-quality deliverable.
The goal is to simulate a real-world feature and evaluate the candidate’s experience on several important aspects of software engineering, such as language ecosystem knowledge, framework experience (e.g. React, Rails), Continuous Integration and testing, documentation. The usual requirement is to create (or modify) a service with an HTTP interface or write a CLI tool.
Usually, the deliverable is the complete application code either as a private repository or as a compressed archive. Candidates are expected to write clear and concise documentation on how their app is deployed or used in the command-line. For Git repositories, interviewers may also want to take notice of version control specifics, such as commit messages, sequence and content.
The project specifications may also require that a specific third-party API is utilized. Interactions with several services are commonplace in today’s architectures that depend heavily on Infrastructure-as-a-Service providers for core operations (e.g. object storage with AWS S3/Google Cloud Storage) and integrate with other service vendors for their actual business logic, for example, transactional email or payment gateways.
Upon successful completion of the assignment, there is usually another technical interview round where the candidate presents the solution to the interviewers with some follow-up questions. The candidate may also be asked to implement additional functionality during the interview, which tests both their understanding of the delivered solution and their ability to adapt to new requirements along with their communication and collaboration skills.
An interesting variant of the technical assignment is to be granted access to a draft of the project solution and apply enhancements or new features there. The Code Review workflow may also be followed: the candidate notes some comments in a change request and is able to communicate with the interviewers asynchronously in writing. During the interview each comment is discussed and any agreed suggestions are then implemented by the candidate. An example of this variant is GitLab’s technical assignment.
🟡 Scalability/Performance
🟢 Testing
🟢 Problem-Solving
🟢 Language Proficiency/Ecosystem
🟢 Practicality
🟡 Systems Thinking
Conclusion
The approaches mentioned here display several differences, but what they do have in common is that communication always plays a key part. As a candidate, you’ll need to explain your ideas, ask for clarifications and work together with the interviewer to reach the optimal solution. As an interviewer, you should also focus on evaluating how a candidate deals with unknowns, adapts to new information, communicates and approaches problem-solving in general.