The recruiter beats me - about the MockIT team's technical interviews

Intro

Technical interviews... sooner or later everyone who plans to start working in IT will come across them. What do these interviews look like? What can be done to ensure that the first interview is not a clash with the wall? How to prepare for it? What can be the reasons for failure? Can choosing the right time or day of the week for an interview affect the outcome? These and other questions are answered in this blog post in the form of an interview with one of our founders, who share his experiences, insights and advice.

You have substantial experience as a Software Developer, but do you still remember how it all began? Let's start with your first job applications. Where did you look for them?

Yes, I remember this stage well. When it came to internships, it was never easy to find the right opportunity, so just finding the appropriate job offer required a lot of effort. I must mention the great job done by Wrocław University of Science and Technology, which organizes job fairs several times a year where such opportunities actually appear. It was at these job fairs that I sent my rather humble CV to companies. I then participated in two recruitment processes.

What about the internship recruitment processes themselves? Was it just a formality because it was only an internship, or quite the opposite?

It somewhat depends. Well, not just somewhat. The internship recruitment process at one company was the longest ordeal of all the recruitment processes I've had in my entire career. It consisted of 5 stages and lasted over a month. At the beginning, I had to tackle an extensive online test that assessed knowledge of SQL, frontend, algorithms, and general JavaScript proficiency. The test consisted of tasks similar to those found on platforms like Codewars or LeetCode. Although all tasks except SQL were relatively easy, the SQL part was quite challenging, especially for an intern-level position. It was at a difficulty level akin to 5 kyu on Codewars. Then came the soft skills interview and an interview conducted in English. Interestingly, from this stage onwards, all subsequent stages were conducted entirely in English. Finally, there was a technical interview, which was long and detailed. It included both knowledge-based and situational questions like 'what would you do in a specific situation'. I also had the dubious pleasure of facing a 'live coding' challenge, where I had to solve a coding task during the interview. It was a relatively simple algorithm problem that involved string and array manipulation. The last stage was a soft skills interview with the CEO. No deep history questions here. It was more about getting to know my personality, discussing financial expectations, and so on. I successfully completed the entire process and got the job.

The process was quite different at the second company. There was only one stage—a soft skills interview with two technical questions, and that was it! The compensation was the same (in fact, slightly better)! Why didn't I take that offer? Well, I felt that the effort I put into the first recruitment process was significant, and I had to honor that commitment. Today, I know that it's essential to carefully weigh all the pros and cons.

Technical interviews can take various forms. They can include knowledge-based questions, live coding, a combination of both, or something else entirely. What type of interview was the most challenging for you, and why?

For me, interviews involving live coding of algorithms were always particularly demanding. First, it's very stressful. Often, it involves coming up with the right idea and applying several predefined methods from a given programming language. Stress certainly doesn't help in coming up with the right idea, so you often resort to less-than-optimal solutions just to complete the task. Second, personally, I don't see the point of this type of live coding in technical interviews. It doesn't really assess anything useful. Unless it's measuring stress resistance, but I don't think that's the purpose of such tasks.

There's a much better way to assess a candidate's problem-solving and coding skills, such as live coding on the development of a project or solving a real-world problem. Once, I received a task that involved implementing several functionalities in a project provided by the recruiter during the interview. He briefly explained what needed to be done, and we started pair programming. The task was much closer to what I would actually do in the company, and the stress level was lower because the recruiter actively participated in the problem-solving process. Of course, live coding of algorithms might be okay if you're applying for a position directly related to algorithm development, but in 99% of cases, it just isn't.

Concluding this topic, I will only add that as MockIT we have to adapt to the requirements of the market in terms of technical interviews so such tasks as live coding of algorithms will naturally come up with us during MockIT interviews.

Did you successfully pass all the interviews you participated in? If not, what were the reasons, and at which stages did you fail?

Unfortunately, it wasn't always smooth sailing. Failures happened too. Most often, it was during the technical interview, as I mentioned earlier. Like I mentioned earlier, live coding can be stressful and unpredictable. Once, during such a task, I didn't immediately come up with the right solution and solved the problem 'by bypassin' the main issue. My solution worked, but it wasn't computationally efficient, which was a requirement set by the recruiter. The recruiter didn't provide much assistance and was rather uncommunicative. Additionally, for JavaScript knowledge questions, all my answers received a generic 'Correct, great' response during the interview, but the feedback afterward was completely different :) After that interview, I learned that it's better to respond to questions as descriptively and elaborately as possible to leave no doubts about your knowledge.

Do you have any unconventional advice for others, perhaps less experienced individuals, on how to prepare for job interviews?

What I'm about to say is just my opinion, but I believe even something as simple as choosing the right day of the week and time of day is significant. Think about when you are most productive during the day and try to schedule the interview at that time. Just remember that very early hours and those closer to the end of the standard workday are not the best choices. Recruiters are still groggy at the early hours and not entirely focused, or they are tired at the end of the workday and just want to shut down their work computer. The same applies to choosing the day of the week. It's best not to schedule interviews on Mondays when everyone is still unhappy that the weekend is over and not entirely focused on their duties, or on Fridays when the weekend is just around the corner. I always aim for Tuesdays and Thursdays.

Of course, proper preparation involves revisiting all the theory related to the specific technology stack. There are plenty of websites that present the most common interview questions for a given technology. I recommend going through them. However, that's not enough for live coding. Here, I recommend platforms like Codewars, which offer thousands of algorithmic tasks. Solving several of them should help you warm up before live coding.

As for other unconventional advice, I'll share my protip that you probably won't find anywhere else except in this blog post. Specifically, I recommend reading comments from people who have gone through interviews at a specific company on Glassdoor. They often mention the types of questions they were asked, and sometimes even specific questions. I assume more resourceful individuals will come up with this idea on their own. So, here's one more bonus: before the interview, you always receive an email with information about who will conduct your technical interview. I recommend checking the social media profiles of that person, primarily LinkedIn... and of course, GitHub! Why? Look for easter eggs—they're there. I guarantee it.