Comment by taywrobel | Hacker News Reader

Comment by taywrobel | Hacker News Reader

Disclaimer that I work server-side. This is not applicable to all of software engineering by any means, but if you want a more technical answer than those the article provides: concurrency.

It's 2020: computers have multiple cores, and it's great to know how to use them, but time and time again I see candidates get tripped up with basic concurrency concepts. Deadlocks in go, event loop blocking in node.js, unsafe memory access in Java or C, they come up all the time in interviews I've done.

"Track the median value in a stream of integers"? No problem. Clean code, no errors.

"Track the median value of two streams of integers which are coming in concurrently"? Data loss, deadlocks, concurrent modification exceptions... Sad times.

I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion. Every language has libraries of data structures already written, but concurrency solutions are often context specific and need handwritten solutions.

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 them to be able to talk about those issues when pointed out. I'm curious if that matches your expectations as well?

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.

> concurrency solutions are often context specific and need handwritten solutions.

Wanted to second this as it sounds like a great design problem. I personally love reasoning about concurrency models.

I recently delivered a big project which was parallelizing a huge computation. I entered the project all gung ho thinking I'm using a high level language (MATLAB) how hard can it be? Turns out very hard, specially if you want to maintain state and operate the parallel computing toolbox even slightly different from the examples.

Please recommend the book I wish I had read before jumping in?

> I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion.

You are right, that is hard. Especially in an interview setting. But I 100% agree that it's better than questions about algorithms.

Reply on news.ycombinator.com