In this article, I’ll show you some topics worth reviewing to get prepared well, important from the technical recruiter’s perspective. Here’s what you can expect:
Table of contents:
In this part, I’ll discuss what an advanced JS developer may expect during a job interview for a relevant position at a good IT company: what knowledge, skills and experience are required and what types of questions may be asked.
And, first of all, I’ll show you my perspective on what seniority in software development is, and how it may be addressed during a recruitment meeting.
Who can be called a senior developer?
For me, a senior developer is a person who is completely independent and can bring value to the project without any help or supervision (at least from the technical point of view). Of course, this person should also be a team player and always watch over the quality of code, a tech debt fighter attitude will also be a plus. Moreover, they need to write code that will be easy to maintain.
But how to test those skills during an hour-long technical interview?
It’s never fully possible, so during my interviews, I try to test the hard skills and assess a candidate's proficiency in the softer aspects of engineering too.
What is the main point of a technical interview?
“What is really the point of a technical interview?” – that’s the basic question here, and the common answer like: “to objectively assess the candidate’s skills” that comes to mind is… wrong. Because an assessment like this is simply never quite objective.
Well, one thing is that the recruiters are not robots but people, and people are always subjective. The second thing is that the company always wants an employee who brings added value to it – and bringing added value doesn’t always mean the same, and doesn’t always equal simply having the best overall skills.
During the interview, I always try to verify if the candidate is suited to the role and if they bring value to the project that they are recruited for rather than trying to give them a grade.
What is more important: experience or hard knowledge?
The short answer is both, but as I already mentioned before, testing the experience is really hard during the interview, so I put more emphasis on the hard skills.
Let’s imagine that I only focus on high-level topics that can be learned only through experience, such as finding the folder structure, architecture, testing approaches, etc. The conversation for sure would be interesting, but, as a recruiter, I wouldn’t be sure if the candidate was able to write good code.
I always start from hard knowledge, theoretical questions, code samples. Then we go through a short live coding session. Next, I move to higher-level topics (that is: if we have time, and that always means that the candidate did well in the previous parts :)).
Quite often, I hear from the candidates that “dry” theoretical questions about the language itself are “dumb”, “not practical”, “boring” and “unnecessary to remember”. My answer is simple: if you want to be called a senior developer, you have to know your main language’s basics well, including the things that are going under the hood. You should be able to provide a correct answer to a question about them, even if you are drunk and woken up in the middle of the night. :)
And these are the basics, and a good programmer should be an engineer, too. I wonder how many of the candidates who think that the basics are a bore would let their house be built by an architect without basic knowledge of physics? Or how many of them would like to be treated by a doctor without the basic knowledge of anatomy?
After that, I’ll provide you with some tips on communicating with your tech recruiter.
Topics worth revising before a senior JS developer interview
- The basics – what is the scope, how variables are declared, what is closure, what are primitives and what are objects, how the interpreter reads our code, what is hoisting, and much more. If you can’t answer these questions, I can advise you to read a great book series called “You Don’t Know JS”.
- The asynchronous code – and not only the ability to use timers and fetch. As a senior developer, you should be aware of the steps that are taken in the event loop and of the existence of micro and macro tasks queues. Also, be familiar with the promise constructor.
- `this` – what is the context of execution and what affects it.
- Your framework – this is the last topic, on purpose. If the candidate knows JS well, then the framework will not be of any concern. Personally, I always ask about frameworks at the end, after discussing the basics.
As a bonus, here’s a sample question that I sometimes ask – with an explanation why:
The answer is not that easy. It seems to be tricky. It's obvious that such code shouldn't be found in a well-maintained codebase. The reason why I ask such a question is that I want to hear the candidate's opinion in an ambiguous, unclear situation, and this opinion should not be based on a gut feeling, but on hard knowledge about the topic. In this case, if the candidate remembers that promises can change state only one, and how the promise constructor works, the answer can only be one. So this example is an indirect question about the theory behind promises.
- The recruiter's purpose is never to show you how much you don’t know. Truth be told, I sometimes avoid some questions if I have a hunch that the candidate is not strong in that field. It’s a good idea to mention your strong sides at the beginning of the interview.
- It's better to simply say “I do not know / I don’t remember” than guess. I always ask about the explanation, anyway.
- It’s also better to be honest about your lack of knowledge in a given area rather than think about the answer to a simple question for several minutes. If you admit to not knowing it quickly, then we can move on to the next question – and the more questions are asked, the more opportunities you get to provide good answers!
- Ask about the minimal acceptance criteria when doing live coding. The requirements during the tech interview are usually lower than in a real project – we have very limited time, so providing a working solution even if it’s not perfect is better than not providing any. After that, you can always point out what you would refactor in real life.
- It’s always good to start from writing the tests after you ask about the criteria.