Type for search...
codete Java Script Advanced Interview Questions Worth Revising 1 main 5bb1267d31
Codete Blog

Advanced JavaScript Interview Questions Worth Revising

Mateusz Choma 2de59636de

22/12/2021 |

7 min read

Mateusz Choma

Have you ever wondered what you should expect from a senior JavaScript developer technical interview? What kind of advanced JavaScript interview questions might you be asked? 

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:

First, I’ll emphasize what the main point of conducting a technical interview is. Next, I’ll discuss what are the features that distinguish a senior software developer from other programmers, and if huge experience really outweighs hard knowledge. And in the main part, I’ll talk about a few areas of expertise (as well as JavaScript advanced interview questions) that are worth revising. I’ll also give some additional advice for candidates who want to grow as software developers in any industry or company.

 

Table of contents:

  1. JavaScript advanced questions – what can you expect?
  2. List of 5 advanced JavaScript questions worth repeating
  3. Some additional advice for an advanced JavaScript job interview
     

JavaScript advanced questions – what can you expect?

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. 

Why?

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? 

List of 5 advanced JavaScript questions worth repeating

In this paragraph, I will go through some of the topics that advanced software developers might hear during a JavaScript job interview. 

After that, I’ll provide you with some tips on communicating with your tech recruiter. 

 

Topics worth revising before a senior JS developer interview

  1. 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”.
     
  2. 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.
     
  3. `this` – what is the context of execution and what affects it.
     
  4. CSS – it’s not about JavaScript itself, but if we speak about front-end topics, it is important. You would be surprised how many “seniors” can’t explain selectors’ specificity. Do you know which selector is more specific: one with one id provided or one with a hundred classes? If you don't, you do not know the specificity well enough. ;) Also, the rendering pipeline is a topic it’s good to be familiar with during a front-end interview.
     
  5. 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:

JS example 9135eeb447

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.

Some additional advice

  1. 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.
     
  2. It's better to simply say “I do not know / I don’t remember” than guess. I always ask about the explanation, anyway.
     
  3. 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!
     
  4. 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.
     
  5. It’s always good to start from writing the tests after you ask about the criteria.

 

Rated: 4.8 / 4 opinions
Mateusz Choma 2de59636de

Mateusz Choma

I am a scientific mind, passionate about technology, an engineer^2 — a graduate of two universities. ;) In my spare time I teach new code adepts through my online course at coderoad.pl. But mostly, I’m a JS developer who loves sailing!

Our mission is to accelerate your growth through technology

Contact us

Codete Przystalski Olechowski Śmiałek
Spółka Komandytowa

Na Zjeździe 11
30-527 Kraków

NIP (VAT-ID): PL6762460401
REGON: 122745429
KRS: 0000696869

Offices
  • Kraków

    Na Zjeździe 11
    30-527 Kraków

  • Lublin

    Wojciechowska 7E
    20-704 Lublin

  • Berlin

    Wattstraße 11
    13355 Berlin

Copyright 2022 Codete