3 ms·

As an interviewer, I would not expect most candidates, including qualified ones, to be able to whiteboard the concurrent case without issues, but I would expect

• taywrobel 6y ago
  Yeah, of course, I'm not looking for perfect code. Concurrency is hard, and as I mentioned, it's probably the most common problem spot I see in interviews, so if I were a hard-ass about it I'd never hire anyone. My expectations are that a candidate can identify that there is a concurrency consideration to be made in the first place, and have some knowledge around how to handle concurrency issues in their language of choice, since different languages take very different approaches. For JS/node that could mean identifying that the main execution is single threaded, so you need to use async/await or callbacks for asynchronous tasks to prevent blocking all other execution. In go that could mean understanding that passing messages is generally safer than sharing memory. In java that could be an awareness of the concurrency primitives that the language has like atomics and concurrent data structures (I could never expect a candidate to fully grasp the concurrency nightmare that is java). I also usually give candidates a laptop and free use of the internet. I try to ask questions that are more grounded in the actual work we do and not just toy algorithms, which means letting people look up documentation, data structures, and whatever else they want. If we're being honest with ourselves, the ability to effectively search the internet is just as important to software engineering as the coding itself, if not more so.