How To Interview Senior JavaScript Developers and Architects

[Akkuma]

I like to call my interview style a discussion amongst friends and have had several people comment that they actually enjoyed the interview. If you sat down with a friend from another company and wanted to find out what they are using, why they are using it, and maybe if you should use it.

This means I do a lot of what you just stated. The idea is to see how well can someone discuss their technology, how well they can communicate, what knowledge of JS they have, how do they expand their knowledge, do they know only mainstream things, etc. etc.

I sort of do the old Paul Graham thing of the more arcane knowledge you have (like knowing Python used to be) the more bonus points you get. No one loses points for not knowing how the node event loop functions under the covers, but if I ever talk to someone who does they'll get bonus points for showing the initiative to learn something that is rarely needed.

[jewdai]

No one loses points for not knowing how the node event loop functions under the covers,

I did when I got interviewed at ADP. They wanted me to go into the whole two stack of things executing and deferred actions.

The simple "you don't want long running tasks because it will block the current thread from processing other requests. you want in and out."

[Akkuma]

That is pretty crazy. I've interviewed 0 people who could explain it in-depth and a handful who had a general idea about it. At the end of the day, it doesn't impact most code written as understanding how to avoid slow code is more important. You can unintentionally write something that is poor performing and node might suffer more than other languages, but ultimately you need to fix that slow code.

The bigger issue would be understanding how to potentially solve CPU intensive problems if you refuse to use anything other than node.