Loudwhisper

I failed my first interview

"Table of Contents"

Just a few days ago, I failed my first interview. Until then, I had never been rejected by any job I applied since I am employed (I have been ghosted plenty when I was just starting out).

The experience has been a mixed bag of bitterness and anger, even though I was really not sure I would have accepted that job on the first place. This post is my own attempt to rationalize and process the experience, while also at the same time a I want to take the chance to reflect on this dumpster fire which is the tech recruitment galaxy.

Introduction

First of all, let's paint the context. They reached out to me, I am not even actively looking for a job change or anything like that. The position offered was Platform Security Engineer. I won't copy the details for the job, but basically the position - as the name suggests - is strongly tied to the infrastructure security: implementing tools, Linux security, Kubernetes security, etc. Based on my own experience, this position was the best fit among all the positions I have ever applied to, as I specialize in exactly that.

Speaking with the recruiter, I learned that the company so far has one security team called "security tooling", which actually means software engineers working on security-relevant products, such as in-house proxy and bastion solutions. The reason why I am mentioning this is because this is the first thing that did not promise well, but I will come back to this later.

The interview process has a number of stages, starting with a "coding test". This is the stage that apparently was enough for them to reject me. I want to take the chance to discuss the process and express my views on the problems I see with it; however, I want to make a premise: I am relatively happy they rejected me, I have made peace with it and concluded that I was indeed not a good fit for the position, so if I am criticizing something, it's not because I am still bitter, but because I actually think that something is wrong, especially considering that I have myself been on the other side conducting 40/50 interviews for security engineers.

Building a Recruitment Pipeline

I will paint a picture, let's see if it sounds familiar: your company has already 50/100/300/500/etc. engineers, but only 5/10/20 security specialists, who are maybe people with mixed skills, from compliance to application security, from network engineering to DevOps specialists. The "theme" of the initial security department is strongly driven by the first core people: if those people are more "software" people, the team probably focuses exclusively on application security, if they are more "infrastructure" people, the team focuses only on infrastructure and so on. Maybe some of the people in the team have been internally recruited, perhaps some engineer with a particular interest in security, or something like that. Whatever might be the case, the end result is that the company does not have a strong experience in hiring security specialists. They have, however, already recruited tons of engineers. You probably see where I am going, and this is exactly what I think happened in this case (and why I called a red flag the fact that the company only has one team, which is heavily software development oriented).

Building a recruitment pipeline is hard: it's a lot of work that nobody wants to do, recruiters don't have the skills to design questions/home tasks/whatever, engineers and tech people don't have time/desire to invest time in this process. Someone, at some point, comes up with a great idea: let's use the same process that we use for engineers, let's just make some little adjustments, and be done with it.

This is exactly what happened in this case.

The coding test

I consider myself lucky. Before this experience, my interviews only entailed some "home task". These can range from answering open questions, reviewing some code or Pull request, providing a security evaluation of some application or things like that. While everyone would probably silently consider this kind of stuff a waste of your own personal time, I consider myself lucky because I was missing out on something that apparently is very popular for software engineering positions: the coding tests.

For lucky people like me that do not know what these are, you can head to leetcode.com or sites like that and discover it yourself. In short, these are websites in which tasks are provided with a strong focus on algorithms and data structures. Usually people "compete" to provide efficient solutions which are executed in the least amount of time and/or space.

Already the name of these websites (leetcode, hackerrank, ...) can tell you everything you need to know.

Other people have already written about the topic in the context of interviews, so I won't spend many words about it too.

I am looking at this from another perspective, the one of the person doing the interview. Specifically, having been so many times on that side of the (virtual) table, I ask myself: what information this test is providing me, to make a decision whether I want this person in my team?

To answer it, I will reconstruct my own process and try to look at it from the eyes of the examinator.

The coding test consisted of two problems:

Obviously the problems were given one at a time. To add some flare, the examinator did not allow to use any language, but just plaintext, so that the code could not be run and any issue had to be debugged mentally.

Now, if I found myself in the uncomfortable position of having to administer such interview, I would probably think:

Obviously, "this person" has also a public Github profile, so I was any interested I could have just looked at that and skipped this whole thing, but let's pretend, right?

The first problem took approximately 30 minutes, out of the whole hour. Considering the examinator joined the interview 5 minutes late, plus the time to introduce the task, the tool, themselves etc., that left only ~20 minutes for the second problem. The solution is fairly simple, although a couple of times the examinator misunderstood my own algorithm and straight-out "guided" me incorrectly. I did struggle a little bit as I was trying to come up with a solution which was clean and O(n), but ultimately, I did get it.

In the second problem, I struggled, a lot. Why? No idea. Actually, I did not, my initial solution was the following: "I merge the digits in the array, multiply by X, and unpack the result back to an array of digits". Probably this would have been 3 lines of fake-Python? But no! You can't do that, the interviewer added one more constraint on-the-fly, which is that the number in the array may be too big to be multiplied this way (they actually noted this time to specify in the next interviews!). So not only I wasted few minutes of my precious time, but I also had to do this problem in another way because mine was not "leet" enough. Doing this, I struggled. Why? Maybe time pressure. Maybe my mind was really tired. Mostly, I do not think just looking at code. The problem is obviously a way to implement in code the process of making multiplications like we do on paper. However, my mind just doesn't work in that way, and what happens in my brain does not involve for loops and iterations, it just doesn't. My mind actually works so that 234x3 = 600 + 90 + 12, which (surprise, surprise) is the approach I initially tried to implement in code, but obviously it's not a good idea, because an array (the result), unlike my mind, needs to have the elements pre-allocated (e.g., I need to know that 234 x 3 has 3 digits result, somehow, or that 234 x 9 needs 4), which is fairly complex to do. In this case, I believe I would have been much better off if it was a problem I had never seen before so that my own instinctive process would not have biased and confused me. I am also a visual person, and in a real environment, I would have just sketched the problem on a whiteboard and modelled the algorithm there, but I couldn't, I had to do just in text, in front of me, without being able to run the code.

During the whole process, the interviewer was either the best note-taker in history or was also chatting in Slack, several times he asked me to recap what I was thinking. No judgement, such interviews must be extremely boring, especially because you have seen the problem a million times and you are just waiting for someone to go close (enough) to the solution you expect, nudging them on the way, there is very little of interesting that your mind is willing to listen to in such discussion. The thing that probably annoyed me the most was the patronizing attitude of the interviewer who was repeating "do you remember how to do multiplications, like they taught you in school?". I mean, you can assume I am completely unable to code, but I find a little bit offensive to imply I am not able to fucking do multiplications, considering I have a computer engineering degree and a relatively good career in Math Olympic games, and also the fact I am older than 10. Granted, I might have forgotten lots of theory about complex numbers and integrals, but you should give for granted that I am able to multiple two numbers together, and maybe you should be able to understand better what the problem is that I am facing, which is clearly in translating such simple algorithm into a loop iteration (which again, it's not the way my mind works).

Ultimately, I did not finish the algorithm in time, and the interviewer concluded the interview telling me that they will let me know, maybe, sometimes, they are not sure of what the process is (great!).

My Objections

I did lie about the fact that I won't spend many words about this, looking at what I have just written. It is my blog after all, so I write what I want.

So let's spend a few words on why I believe this process was completely batshit crazy and a huge waste of time, both for me and for the engineer who had to waste 1h of their time:

  1. The skills measured are completely irrelevant for a platform security engineer. This test would be stupid even for a software engineer, but for a security specialist who doesn't generally have to write code, doesn't make any sense.
  2. The second interview would have been a scenario-based security design. Wouldn't that have made much more sense as a filtering step? Why the fuck would you care whether your infra security engineer is able to come up on the spot with an algorithm for a problem that they will never have to solve in real life with the same constraints?
  3. These tests seem 100% expressive of that idiotic "leet" culture of the hacker/genius. I have a news for you leet geniuses: tech workers are just workers, and security work is mostly method and boring analysis. Moreover, most companies would benefit in 80% of the cases from the inefficient (but readable) brute force solution compared to the clever O(logN) solution which involves xor and shifts which nobody else can read and maintain after a week.
  4. With the above, I am not saying that careful design of algorithms and clever use of data structure is useless, it has its place. And the place is to solve and address specific problems, which can be done with all the tooling, including books and references for known algorithms, visual tools, live debugging and tests and everything that we can use in our day job. Not in 20 minutes, just looking at code on (virtual) paper.
  5. It is completely reasonable to want to know whether your candidates know how to write code. This is just a dumb way to do this.
  6. From a good coding challenge, you will know that someone is very good at designing algorithms, or that maybe that they spent tons of time on the 'leetcode grind', which apparently is a thing for people who are preparing for tech interviews (look it up!). This tells you very little about what you want to know, though. You will know even less if someone fails such interview.

The Rejection

As a cherry on top, a couple of days later, I have received the (expected) rejection letter. I will quote it because I think it really gives closure:

Dear [Candidate's Name],

I hope this message finds you well. I want to thank you for your interest in the [Position Name] role at REDACTED and for taking the time to go through our technical interview process.

After careful evaluation, we regret to inform you that we have decided not to move forward with your application at this time. We had a highly competitive pool of candidates, and while your qualifications and experience are impressive, we have chosen to proceed with another candidate whose skills and experience more closely align with our current needs.

We appreciate your interest in joining our team and were genuinely impressed with your technical knowledge and abilities. We encourage you to continue your job search and keep an eye on future opportunities at REDACTED.

Thank you once again for your interest, and we wish you the very best in your job search and career endeavors.

Note the templates. We all know that most of the communication in this context is bullshit formality, but didn't we agree all to at least try to maintain the appearances?

Conclusion

It felt good to rant about all of this, so that now the curtains of my shower are not the only ones who could argue against coding tests. I want to conclude with a few personal takeaways:

Tags: #interview #tech Categories: #tech #personal