Blog

Hiring process: Here we go again…

May 29, 2023 | 10 minutes read
Share this:

Tags: hiring, technical-interview

I would like to start this first post by sharing one of the reasons why I decided to build this blog since it’s also the reason why I chose this topic as the first one: Recently I was fired from the job. Not due to personal performance reasons but motivated by the company’s roadmap change. Nothing to reproach and only gratitude for the opportunity as well as for the fun.

Having said that, the fact is that I’m currently open to new job opportunities and this means that it’s time to go through all the LinkedIn messages that I had been skipping for months, join new Slack channels as well as new platforms where I was told to find “much better offers than in any other known platform” (I was expecting to discover a sort of engineers Valhalla with tones of incredible offers suiting me but finally the only feedback I’ve got is the mail that they sent after completing the registering form) and last but not least: be ready for being enrolled in tens of calls, screenings, 7-steps hiring pipelines and the most diversity kinds of questions that you can imagine.

Summarizing: Be ready for your new role as Senior cracking interviews specialist. Sample image

Joking apart, I would like to say firstly that I’m aware that we’re privileged workers, with the best shape salaries and job conditions, so this post is not going to be a kid complaint because would be ridiculous given the average conditions in most of the jobs nowadays, but just a list down of my thoughts about why this is probably the only piece of the cake where every engineer would agree: these kind of hiring process are painful, time-consuming and leave a feeling of randomness and trendy-based questions that are not showing out which are going to be the duties of the role.

As I said before, we are privileged workers that, in between all the privileges that we have, receive a lot of offers daily. This means that even in active job research as it’s my case, you can get rid of knocking on the doors asking for opportunities and just open the 2/3 most important platforms to check what’s going on around your profile. Despite this is something good as I said, is a double-edge weapon too, because if the amount of messages is too big and almost there’s no difference between them (I think that out there are more leader companies than companies themselves), choosing which one reply and which one skip is extremely hard, and no way to answer all because would drive me crazy.

Conclusion: I’m 100% sure that I skipped the work of my life due to this unmanageable message broadcast. Dead by success.

But wait, this wasn’t all, because the most time-consuming part comes now, when you are attracted by a description that fits most of your wishes: Screenings, Technical question meetings, Live codings, architecture design sessions as well as offline code challenges which shouldn’t take more than 5 hours but finally you invest 3 days and a half because you need to dust off your trigonometry skills to solve them.

I would like to reflect on this with some numbers because I’m keeping track of the amount of time that I devoted these past 4 weeks overall. These are the outcomes without taking into consideration offline previous preparation, setups, and so on:

  • Number of companies: 9
  • Overall amount of steps/interviews: 23
  • Average of steps/interviews: 2.6
  • Max number of steps/interviews: 5 (4 technical interviews)
  • Min number of steps/interviews: 2 (1 technical interview)
  • Max number of minutes required by a process: 315 (5.25 hours)
  • Min number of minutes required by a process: 45
  • Overall amount of minutes: 1195 (∼20 hours)

As a current status summary:

  1. Discarded from one (after 4 interviews they suddenly realized that were actually searching for a Terraform expert. No questions nor mentioned it before. Crazy AF)
  2. One offer achieved
  3. I declined to move forward just in one process

This means that after that amount of interviews, 6 companies have in mind or already have arranged more interviews. And yes, the one with the max interviews so far is one of them.

Too much in my opinion.

We reached THE TOPIC. I frequently speak about it with other IT mates and I can say that there’s a full quorum: no one agrees with the questions and code challenges that they’ve faced during their previous hiring interviews.

I’m not going to be the exception, and I agree with the feeling that some kinds of interviews are not helping to raise the knowledge or background that the candidate has to have for the offered role but are a sort of ego trip for the interviewer: “take a look, huh, do you see how much I know? Are you a senior I’M A SENIOR!”. I have to say that this time I had good luck (so far) and 95% of the interviews were what I consider a good interview (later I will write down which are the things I like) but is a shared feeling in the industry. The question would be: Why if all of us agree on the problem it cannot be fixed?

Well, from my point of view, this is produced by a very competitive sector where Imposter Syndrome is appearing constantly, and somehow each of us needs to feel important, showing ourselves that our value and knowledge are higher than the others to keep on track. One of the ways we have found is asking technical things that all of us know that no one has in memory and the most important thing, are not mandatory to succeed in the new role. Questions like O() notation, “list me all the collection types” or complex sorting algorithms may make really sense in some cases to achieve the performance difference, so it’s perfectly fine to ask them in these cases but let’s be honest, in most of the cases are not even close being required and we keep asking them just because they make us look clever (moreover if there’s a manager during the interview).

Another day I will try to tackle the kind of interviews “Close all the windows, no IDE is allowed, uninstall the browser. We have to do things, and for that, you can use whatever you consider to achieve it. 60 minutes. Has to compile. Happy Hunger Games, and may the odds be ever in your favor”.

How it looks/How it is

⚠ Disclaimer: I’m not an authoritative voice for this, so these are my personal preferences and are not written in stone. I’m glad to hear disagree.

I have faced overlapped questions/topics within the same process, locking me in a Groundhog Day cycle.
My experience is that 3 interviews should be more than enough to determine whether the applicant’s skills suit the requirements or not. Going further probably will just lead to wear and tear on both sides (and probably any other company will be faster)

Fortunately, I saw a drastic reduction in this kind of challenge, but still out there. I fully understand the reasons why some people support this approach: lets you get rid of this uncomfortable feeling that appears when someone is seeing you typing, as well as makes all the available resources usable (as a normal productive day indeed).
But to be fair enough, this offline code challenge takes much more time than a simple live coding, and this would discard most of the possible candidates: the ones who are currently in a job and doesn’t have too much free time. And, with this approach, there’s usually a linked extra step: a subsequent interview to discuss the taken decisions and, being honest, check that you were the developer who did the implementation.

If something is mandatory, much better to know it on the first call. Occurs that sometimes the company doesn’t have a clear must-haves list that raises after the last interview.
This applies to the applicants as well: if this company is searching for a Python expert, be aware of your skills and highlight them during the first interview.

I use Google, StackOverflow, ChatGPT. Even sometimes I ask my teammates because, surprisingly, team player also means filling in some missing knowledge just asking.
Yes, sir, I’m aware that IDEs currently are extremely helpful and do a lot of stuff for me, but please, now release my arm and let me use my IntelliJ as I do daily, and let me get rid of this VI-based online editor.

Yes, you can see that I switched to irony with that but these kinds of dumb rules that were trendy to evaluate god knows what (fortunately another practice that was reduced drastically) make me extremely nervous. Technology to help the business, not the business to show fancy coding/memory skills.

I showed my best version during the interviews where the interviewer had a good mood and made some jokes to reduce the stress. Which is the aim of being as an in a poker game?

As an anecdote, one of the interviews I passed through was about creating a very simple Rest API based on SpringBoot from scratch, and when I say from scratch is that was mandatory to download a new project from the Spring Initializr even though I’ve shown a dummy Maven archetype ready to use. Ooook, let’s check that my Internet connection works 🙏.

Well, the things that start badly probably will continue badly, and this is what occurred:

I missed to place the project within the correct path and this led to some Maven dependencies not being added to the classpath. I realized about that after finishing the call, so no autocomplete for the imports during the interview and I had to search every package on Google. Very fluent.
One thing I learned is that the most interesting part of this live coding is thinking out loud because it’s assumed that somehow you can make it work but the keys are your decision reasons. This was not the case. The interviewer was obsessed to see it working within the scheduled 50 minutes as if the company financing relies on my challenge outcomes.
I was speaking about pushing out the first unclean implementation logic from the controller into a use case layer (service), then using the DI mechanism provided by SP to inject it into the controller using a constructor-based injection to blah blah blah…

“Man, I would like to see it running, and we don’t have too much time”. He saw it running, of course, I’m a committed person, but he will never see me again. Fair enough.

The diversity of questions that can appear in an interview can be huge: from generic algorithms performance to deep framework details, CI/CD, or testing approach.
Taking a quick look at these topics is not cheating, is just refreshing whatever details that your garbage collector decided to drop. The applicant is not going to have a chance to learn in deep about these topics or put them into practice before the interview, but possibly the opposite case.

I can promise you that I was hired in my previous company after getting stuck on a simple dummy “reverse a list in Java” because simply I didn’t expect it (of course at the next hiring steps I’ve shown better skills 😅)



Thank you for keep reading till the end of the post, sorry for this extended soliloquy and please, if you have any comments or ideas about the content of the post reach me via LinkedIn or mail and I will be pleased to hear about them.
The aim of sharing my thoughts is to improve whatever I’m wrong about.