My two cents on technical challenges
Tags: career, webdev
Published: 2022-01-17 03:38:12

Being a programmer, it’s very common for companies to request a technical challenge to assess our skills during the interview process for a job position.

There are several approaches to testing a candidate's technical knowledge: some tests consist of multiple choice questions or writing small functions on automated platforms, others are "live" theoretical tests and there's even some tests where the candidate has to develop an application or solve an exercise and deliver the result to the company.

In this post I'm going to talk about my view on the last type of tests and how two of these tests, requested by different companies, changed my life.

### Attempt #1

Around mid-2021 I was contacted by a recruiter who loved my Linkedin profile, after a nice conversation she sent me a PDF with specifications of a super abstract exercise: I would have to land a probe on Mars and receive a series of commands to move this probe in a cartesian plane. I had 5 days to deliver this exercise.

This challenge was a let-down: 1. I wasn't super excited about the opportunity, 2. The test was abstract and unrealistic for use cases I saw daily, 3. I had to do it in a language I know but I'm not super proficient (JavaScript).

Of course, with all that, my deliverable was well below what I could do: I developed almost everything at the last minute, I didn't add tests, I did as little as possible requested, in short, the refusal I took in the vacancy didn't even surprise me when it inevitably arrived in my email with a negative feedback.

Despite that I was annoyed, not by the feedback, but by having done something so mediocre.

### Attempt #2

A few months later I received a contact from a new company, I had a chat with the recruiter and I received the technical challenge, only this time my eyes lit up: the test was well described, it spoke of a real business situation that the company faced and that makes perfect sense with the company's business, I could do it in any language and I even had very specific instructions on what was expected.

In addition to being super excited about the opportunity, I saw this test as a chance to redeem myself for the previous failed attempt.

This time I did everything as it was supposed to: I used the best programming practices, researched design patterns that fit the problem, added unit and integration tests, documented everything possible, _dockerized_ the application and prepared myself for any questions that the company had.

When I submitted the answer I felt like I had done the best I could and that if there was a refusal it would be because I really wasn't at the desired level for the position and I was ok with that possibility.

### Everything went well

After the submission, I participated in a few more steps such as an architecture interview with a very cool and contextualized challenge and a pair programming where I extended an application that I had previously delivered along with two engineers from the company who helped me in addition to evaluating my skills.

A few days later I received the proposal and I am very happy to be part of Nubank's engineering team.

Today, making an analysis of these two occasions, I think that the first attempt and subsequent ball drop provoked me in a way that I forced myself to deliver something that really demonstrated my knowledge. After that negative feedback it was as if I couldn't let a company evaluate me negatively when internally I knew that I have the necessary competence to do something much better.

### Okay, so what?

I don't know if I'm in a position to give advices for anyone but here are some lessons I learned:
- It is always valid to participate in interviews or tests as a way to test your knowledge/value in the market, but do not take advantage of this and only apply if you are really interested in the position;
- Companies will always need to measure a candidate's skills, technical tests are one way to do this so hold yourself to a high quality level on these occasions;
- Companies: please contextualize your tests with the business domain in which you are inserted. It's much more enjoyable to code something that we know could arise in the company's day-to-day;
- Try to work in a company that makes you excited, it's not always possible, but when it happens your quality of life improves significantly.

That’s it folks, thanks for reading all the way and I hope sharing my experience helps you on your journey somehow. Feel free to hit me up if you need to talk.