Algo Interviews - Engineering Method

Apr 2 (edited) in Resources

Why should I use the Engineering Method in algorithm interviews?

Our data shows that people perform better along these metrics when applying the Engineering Method.
People complete timed coding tests faster and pass all the test cases in fewer attempts than those who jump into coding and have to rewrite and debug complex code.
People complete interview questions faster and appear more competent to interviewers than those who write code without a clear direction.
There’s a strong correlation between better hiring outcomes and the number of steps they demonstrate to the interviewer.

Behavioral component

The human aspect of an interview introduces a need for clear and effective communication in each step of the problem-solving process to have a successful discussion. It's important to note that a successful interview often involves more than simply having a correct output. The interviewer is also interested in understanding your thought process and being confident that you have good judgement. That is to say, the journey is more important than the destination.

To ensure that your solution and thought process are clearly understood, it's crucial to articulate them in a way that's easy for the interviewer to follow. Demonstrate independence and initiative by taking an active role in driving the conversation and efficiently moving through the problem-solving process. These behaviors are important factors in demonstrating your skills as an engineer.

🏴‍☠️ Explore

Ask the interviewer enough questions to sufficiently clarify the problem before coming up with solutions. These questions can include the expected inputs & outputs of the abstract problem and concrete test cases.

👀 From the interviewer’s perspective

They want to ensure that you fully understand an objective before addressing it. This step allows them to recognize your ability to resolve ambiguity.

💡 Tips

1. Come up with your own “happy case” examples

When your interviewer starts the interview, they’ll typically provide some examples. Come up with at least one of your own examples, starting with the smallest and simplest. Then try to poke holes into your interviewer’s examples! The happy case here refers to a normal input that isn’t trying to test the edge cases of the question.

Example conversation with an interviewer
Interviewer: "Given an array, return the first unique number. For example, given [2, 1, 2, 3] return 1."
You: "So, if I were to remove this 2 so that the input was [2, 1, 3], I’d return 2, correct?"
Interviewer: "Great example! Yes, you’re correct."
...and you’re already in the interviewer’s good graces :)

2. Come up with edge cases

Example conversation with an interviewer
Interviewer: "Given an array, return the first number that is repeated k times.
For example, given the array [1, 2, 1, 2, 2], k = 2, return 1"
You (ask happy case): "So, if this 1 and 2 were swapped like [1, 2, 2, 1, 2], k = 2, that would return 2, correct?"
Interviewer: "Yes, correct."
You (ask about edge case): “What if all numbers are repeated fewer than k times?”
Interviewer: “In that case, return -1. This isn’t great since -1 might be a value in our array, but let’s do that for now.”
You (ask about edge case): “OK, and will k be at least 1?”
Interviewer: “Yes, let’s assume k will be at least 1.”
...this is an A+ conversation. You’re already winning this interview! This example is a bit on the easy side of interview questions, but assuming you were to get this question, you’d be on the right track to earn a pass!
💡 Tips
Clarifying questions that have reasonable assumptions should be asked as a statement instead of a question.

🧠 Brainstorm

Discuss potential ideas with the interviewer. The ideas should include the algorithms, data structures, and space & time complexities to solve the problem. Beginning with a brute-force solution can be a starting point toward an optimal solution. This step allows you to explain viable solutions and arrive at a consensus with the interviewer about which solution to pursue without investing the time to implement them.

👀 From the interviewer’s perspective

They want to ensure you've pursued multiple avenues and analyzed their viability and trade-offs before committing to any particular approach. This step allows them to recognize your collaboration and problem-solving skills independent of coding.

💡 Tips

Showing the interviewer your work toward these unsuccessful ideas shows the interviewer a lot about your problem-solving skills and is useful not only to your eventual correct solution but to the interviewer’s understanding of you as a problem-solver.

1. Identify a simple solution

You always want to aim to have at least a straightforward solution within the first 5 minutes of the interview, no matter how bad the runtime, that can solve the problem. Make sure you’re sharing your thoughts out loud during this section!

💡 Tips

Spend as little time as possible explaining your simple solution. You want to spend as much time as possible analyzing your solutions, not explaining them. You want to explain it in one or two sentences. “Well, I could do it in exponential time by testing all possible subsequences...” is sufficient!If no obvious solution comes to you immediately, you can work through a list of major algorithms and data structure archetypes. Once again, share your thoughts out loud so your interviewer can interact with you and let you know if you’re on the right track! Be careful not to let it seem like you’re asking the interviewer whether something works.Counter-example: Should I use a Set? Stack? Queue? Heap? Trie? Union-Find?Better: If we use a set, we could do X. But that doesn’t help because of Y. If we used a dictionary instead, then...Don’t be afraid to suggest an incomplete idea. Even if you reject a solution that doesn’t work, you should share it out loud to give the interviewer a window into your thought process. Keep it quick and simple: "a dictionary doesn't help here because X" is great.

2. Work out the expected time and space complexity of each idea

Runtime and space complexity are important elements of comparing solutions.

Example conversation with an interviewer
An example conversation with an interviewer might look like this:
You: "Since we double nested loop iterating through this array, we're looking at O(n^2)"
Interviewer: "Could we do any better than that?"
You: "Hmmmm. Maybe we could use a heap to optimize the inner loop?"
Interviewer: "Cool, show me how you might do that."
That is your clue to optimize your solution or look for another approach.

3. Proactively point out the flaws in your solution(s)

Example conversation with an interviewer
The problem is to sort an array of 0s, 1s, or 2s.
You: “Hmm, so I guess to be lazy, I could call the built-in sort function, but that would run in O(N log N). How long will the input be? We might want to develop something more clever if it's very long. The built-in function is the way to go if we expect the input to be on the shorter side normally.”
Interviewer: “Yeah, the input could be very long. Let’s see if we can do better than O(N log N).”
This small interaction is a great example of identifying a simple solution, followed by an analysis of when it would apply and probably be the best solution vs. situations where something else may be required. Suppose you go straight to optimizing beyond calling the super-simple, super-fast-to-code sort function. In that case, it’s a slightly negative sign, so again – name sub-optimal solutions so you can critique them! Sometimes sub-optimal computer science solutions are great software engineering solutions.

📆 Plan

Translate an idea into an algorithmic outline using verbal or written documentation.

Effective time management is valuable throughout the problem-solving process, but it’s especially crucial to balance the time you invest between the planning and implementation stages to maximize the overall benefit of both steps. The amount of effort to dedicate to each step varies depending on the individual and the specific problem at hand. More challenging problems may require more planning, while longer solutions may require more implementation time. It’s necessary to find the right balance for each problem. One size doesn’t fit all in this regard.

👀 From the interviewer’s perspective

They want to be confident that you clearly understand how to bring a solution to fruition. This step allows them to recognize your algorithmic skills independent of coding.

💡 Tips

Keep an eye on the time! You probably want to choose a solution and start coding by no more than the halfway mark of the interview. It would be best if you still had a theoretical solution in mind before beginning to code. But as long as you have a solution, even if it’s inefficient, you should still start coding by the halfway mark.
Be confident. Say, "I'm going to implement solution B instead of A or C for these reasons. Is that ok?" This might lead to a back-and-forth conversation with the interviewer, but that’s a good thing! The best engineers should be able to lead a conversation and the process of driving toward a solution.

🛠️ Implement

Translate your plan into code.

It’s strongly recommended that you’re proficient in your chosen programming language to maximize your implementation time by keeping up with your pace of thought. If you’ve clearly communicated your approach, you shouldn’t feel obligated to communicate proactively during this step. Instead, focus on writing code with the best practices.

👀 From the interviewer’s perspective

They want to ensure that you can write code fluently. This step allows them to recognize your mastery of programming and deep technical skills.

💡 Tips

The transition to coding can happen in one of two ways:

You can initiate the transition to coding.
You can make this graceful by asking: "I'm pretty confident in this approach now. Do you have any questions?" Don’t ask if you may start coding. Instead, make a recommendation as the engineer on the problem. Asking if the interviewer would like anything clarified further accomplishes the same thing without deferring to the interviewer.
Your interviewer may suggest to start coding.
In some cases, the interviewer will hint that you should start coding. The hint will be very obvious, like "we can probably start coding now." This generally means they’re satisfied with the problem-solving and algorithm design steps. In some cases, this might also indicate that the interview is short on time. This might affect the solution you choose.

🧪 Verify

Test the code.

Run your code against the test suite you created during the problem exploration if there’s a runtime environment. Otherwise, manually walk through your code with a concrete example while tracking variables and other information to methodically verify your code is behaving as intended.

👀 From the interviewer’s perspective

They want to ensure that validation is part of your engineering process. This step allows them to recognize that your methodical problem-solving approach includes ensuring that a solution works as expected.

💡 Tips

Interviewers don’t expect you to be perfect but they expect you to be diligent and methodical. You can still do well in an interview with bugs in your code if you demonstrate problem-solving behaviors in uncovering them.

3 comments