How I Used Technical Assessment Feedback to Ace my Developer Interviews

Rejection when job searching is never easy, but this can be seen as a learning opportunity if you are able to receive and implement feedback. Here’s how I leveraged the feedback from unsuccessful interviews to improve my technical assessments and find a great job!

two cats with cans and a feedback loop attached to the cans

I went through seven interviews in three months and got to the technical interview stage for most of them, but seemed to get stuck there. When reflecting on this, I realised that there were patterns during my technical interviews:

I had difficulty explaining the technologies I used in the problems I was given
I didn’t always use libraries the companies expected me to
I had difficulty adapting an algorithm to a real problem

I decided to ask companies for feedback and used it to improve my performance in my next interviews.

Asking for feedback

Every time an interview didn’t go well, I thought about the errors I made or questions I couldn’t answer. At the end of each interview, I made detailed notes on this.

When I wasn't sure why I didn’t succeed in my interviews, I sent an email asking:

What did I do right?
What do I need to improve?
Are there any recommended resources for the improvement areas?
What did they expect from me during the process that I didn’t know or didn’t mention

Some of the companies went straight to the areas of improvement, and some gave me complete feedback that included answers to all the questions above. With concrete suggestions on where to improve, I started to understand the expectations for the positions I interviewed for. As I was applying to similar roles, this was useful for companies I would apply to in the future.

Using the feedback I received, I went back to the problems and reworked the parts that I failed previously.

Here are some examples of feedback that I received and how I used them to learn and improve for future interviews.

Ask clarifying questions

“I think you didn't really manage to get into the problem, which really got us a bit stuck and didn't let us go far enough with the problem.”

I received this feedback when I reached the last technical interview: pair programming with a technical leader. I was given a problem description and needed to write an algorithm to solve it.

I didn’t understand the problem completely and was afraid to ask too many questions instead of writing code. I implemented code that didn’t solve the problem, and the interviewer mentioned the missing cases that my code didn’t cover. All my time had passed, and I realised I had no way to adjust my code.

I learned that it’s always better to understand the problem completely from the beginning than try to pretend that everything is clear. Asking about the details that you need to start the implementation doesn’t make you a bad programmer but is a way to show how you think about the problem and can save time during coding.

Pair-programming interviews are an opportunity for you to show the company how you see and think about the problem they’ve given you. Your approach and thinking illustrate what experience level you’re at. You need to communicate your thinking with your partner while you’re working through it and when you’re implementing it.

Let the job description guide your technical approach

“In this case, using threads did help, but keep in mind that the usage of lines is not always the best choice… There are edge cases that can be discovered by implementing tests.“

I got this feedback after I delivered a technical assignment. The assignment was to build a command-line interface (CLI) that filters data from an external API. The project description defined all the functional requirements well, and I was free to choose the technical approach to solve the problem.

I looked at the requirements to understand more about the external API I needed to use. When I found out that I need to deal with a lot of data, I decided to use threads. With threads, I’m able to create multiple processes in parallel and get the data faster than in a sequential way. I then implemented some tests.

During the interview, I couldn’t clearly explain the cons of using threads in the programming language. My tests did not cover some edge cases, and they expected me to use specific libraries to improve the code.

If I had checked the job description thoroughly before starting the technical assessment, I would have noticed the details around the libraries the company expected me to use. Always check the job description in great depth before your technical assessment and interview, as it can give you an idea of what the company expects of you.

It’s also important to prepare thoroughly when explaining your solution: Know the pros and cons of your chosen approach and be aware of other possible solutions. In my case, I only knew the general motivations for and against using threads, but not for the specific language used.

Practice a variety of problems

“We encourage you to continue to improve your proficiencies in applying data structures and algorithms to solve complex problems.”

This was the feedback that I received from a big tech company after a pair programming phase to solve two algorithms. The interviewer remotely shared a text editor with me that contained the problems’ descriptions.

I solved the first problem easily. However, I couldn’t figure out which algorithm I needed to implement for the second problem. After the interview, I searched for similar problems and realised they expected me to use the Dijkstra algorithm. I knew this algorithm, but it wasn’t clear to me when reading the problem description that I needed to implement it.

Even if you have a good knowledge of algorithms, you can’t do anything if you don’t know how to interpret the problems companies give you.

If you practise problems at different difficulty levels, you can more clearly understand how to interpret problems. I found using the same algorithm with different problem descriptions very helpful in improving my understanding.

I used LeetCode and Hackerank to practise solving at least one problem per day to improve.

Use failure to grow

Searching for a new job is not easy; it can feel more difficult after a few failures, but we can use failure to learn. When you can take something good from your failure, like knowing the areas you can improve, you become better in the next opportunities you have.

I spent some time applying the things that I learned from feedback. After a lot of practice, I defended my approach in technical interviews and received two offer letters. It's a process that requires patience and dedication, but it's worth it!

Resources:

Books

Training

If you're looking to ace your developer interview, these posts might be helpful too:

Ana França is a full stack developer at Equippo. She is a coding enthusiast interested in good practices, optimisation and code reuse. She is fascinated by projects that use technology to simplify complex processes or add value to society.