The Only Time I Failed a Tech Interview

Recently, I came across my notes from a technical interview I did back in 2017 with a funded tech startup. The interview consisted of a 30-minute video call, followed by a coding assignment that took about 2 hours, and a 30-minute feedback session the following day.

Despite doing well on the call and having a stimulating discussion with their CTO, I did a pretty mediocre job of the coding task. It was a full-stack to-do list project that required building a bunch of interactive features in a short timespan and I found it challenging to complete in time. Still, I was fairly optimistic about getting the job because I knew other candidates were in the same boat.

When I received my feedback tomorrow, I was told that they chose someone else for the position and they were kind enough to provide a detailed list of reasons.

Here is what went wrong and what I learned from the experience. The test project was in Laravel and Vue.js, but the concepts apply to all tech stacks. All italics below are from the client’s feedback.

The good

Having completed about a dozen of projects in Laravel, I was right at home with setting up the environment and project infrastructure. I built my model relationships, controllers, requests, and policies very efficiently.

Given the limited amount of time, I thought I did reasonably well on the testing front as well. The feedback reflected as much.

Good overall performance in Laravel

Wrote a good number of HTTP/feature tests

An attempt was made at all requirements

Good use of route-model binding, request validation, middleware

Notice something about those four items? They all refer to the back-end. The “attempt was made” made me a little wary of what was to come.

The bad

No README included with a basic description of the work that was done or how to get it running

This was a bit of a “huh” moment for me considering the timeframe and the simplicity of starting the app. After some thought, I realized that I could have easily taken a minute to write a README. This was more a matter of principle than of practical need in this case, but making the effort is nonetheless desirable.

Mixes templating between Vue and Blade even though Laravel scaffolding provides a pre-setup Vue SFC

In other words, taking the easy route doesn’t pay. In Laravel, you can build login/register functionality with one line. The trouble is, this line builds it all in Blade, Laravel’s standard templating engine. While this works, it is objectively better to build it in Vue for a Vue-based project because it makes it easier to maintain, and easier for the authentication to interact with other components as required.

No frontend/Vue tests

I (rightfully) left this as the final item on my list and I didn’t have time to do it. It is unlikely that this was the sticking point that cost me the position.

The ugly

Poor choice of data structures in Vue part, makes it necessary to loop over the whole list of tasks to find the task with the right ID

This one hurt. The handling of data structures is such an essential part of software engineering that I was extremely annoyed at myself for getting it wrong. The reason I got it wrong is that I rushed through it without thinking in order to move on to other tasks. All too often, programmers make the same mistake for the same reasons in production-level apps.

My solution had no discernable performance disadvantage while testing with 10 tasks, but if I had tested with 10000 it would have failed miserably. It is important to think about data structures before you build your solution, and then to test it with a realistic amount of data.

Two tests do not pass

I mishandled some edge cases and ended up with tests that don’t pass. This is a pretty big error if you are to work in a team environment. If you can’t be trusted to get all your tests right, then somebody else has to do it for you, and you become a drag on team productivity.

Aftermath

Many software developers hate coding tests, but if done right, they are an excellent way to hone your skills and test yourself under pressure. The crucial thing is that you get real feedback from a real expert, rather than just a generic “sorry, we chose another candidate” email.

This learning experience made me wish that I had failed 100 tech interviews. I thanked the interviewers for the provided feedback and got to work on improving my weak areas.

In the ensuing days, I got better at testing, front-end structures, and, perhaps most importantly, I understood that patience had more value than speed when it comes to software. Even if your time is strictly limited, it is better to do 75% of the work with 100% precision than 100% of the work with 75% precision.

Guiding principles

Be patient.

Do the important things first.

Take the easy wins.

These three concepts refer to, respectively, data structures, tests, and the README in my example. However, you can apply them to all tech interviews and they are guaranteed to boost your chances of being hired.