Lawrence immediately saw that it was a trick question. You would have to be some kind of idiot to make the facile assumption that the current would add or subtract 5 miles per hour to or from the speed of the boat. Clearly, 5 miles per hour was nothing more than the average speed. The current would be faster in the middle of the river and slower at the banks. More complicated variations could be expected at bends in the river. Basically it was a question of hydrodynamics, which could be tackled using certain well-known systems of differential equations. Lawrence dove into the problem, rapidly (or so he thought) covering both sides of ten sheets of paper with calculations. Along the way, he realized that one of his assumptions, in combination with the simplified Navier-Stokes equations, had led him into an exploration of a particularly interesting family of partial differential equations. Before he knew it, he had proved a new theorem. If that didn't prove his intelligence, what would?
Then the time bell rang and the papers were collected. Lawrence managed to hang onto his scratch paper. He took it back to his dorm, typed it up, and mailed it to one of the more approachable math professors at Princeton, who promptly arranged for it to be published in a Parisian mathematics journal.
Lawrence received two free, freshly printed copies of the journal a few months later, in San Diego, California, during mail call on board a large ship called the U.S.S. Nevada. The ship had a band, and the Navy had given Lawrence the job of playing the glockenspiel in it, because their testing procedures had proven that he was not intelligent enough to do anything else."
A much more common example is that (particularly young) candidates tend to make job interviews into big, stressful things in their head. Then they don't sleep properly the night before, and during the interview they can't think creatively or access deep memories (which are both well known symptoms of stress). They can't answer your questions. You think its because they don't know, but actually the problem is that they're too stressed to think at all.
Long programming questions work great for my anxiety because I can zen out while I'm programming and forget the interviewer is there. But everyone is very different with this sort of thing.
The more general way to work around this problem is to listen and pay attention to the candidate. If you asked "Lawrence" in this story what he was thinking about during this interview, he'd tell you about fluid dynamics and partial differential equations. That tells a story. Another candidate will tell you that they felt really awkward programming through an SSH connection because they're used to Visual Studio. Or how they really do (or don't) like some aspect of the programming style on display. Or how (to crib from another commenter) the programming was easy enough, but they're worried that doing so introduces a race condition between atomic multiply and add instructions if they're interleaved. And they hate doing the work because they feel like they're introducing a bug.
None of that really helps with stress bunnies, but you learn so much about what sort of employee they'll be by asking.
This idea keeps me up at night, but do you have any evidence for it?
I've interviewed plenty of people with 15+ years of experience who really struggled to do basic programming tasks. And who didn't show any obvious signs of stress.
To this day I have no idea how many of them were not performing because they were stressed out of their minds but hiding it. Vs how many were simply not very good at programming. I have no idea how to tell the difference when they don't make it obvious to me.
Ergo, I strongly suspect the current tech hiring culture filters out anyone who has above average sensitivity.
Note that aside from some minor body language cues, there aren't a lot of outward signs of panic. How it looks and how it feels are very different.
Because weak candidates need to submit a lot of applications to get a job, most job applications are from weak candidates. Its easy to feel compassion for people who have panic attacks. Its much harder to make a filter for weak candidates which doesn't also filter out people with performance anxiety.
Seems like we don't even know how big a this problem is. Is it 1% of the candidates? 10%? 50%? I have no idea. And it sounds like nobody here has any real idea either.
This is a solved problem already. Do we use whiteboard interviews for standardized tests or certifications? No.
>Seems like we don't even know how big a this problem is.
Seems like you don't know.
>Is it 1% of the candidates? 10%? 50%? I have no idea. And it sounds like nobody here has any real idea either.
How much time did you spend trying to find out before giving up?
> Do we use whiteboard interviews for standardized tests or certifications? No.
Your position is not clear here. Are you claiming a written exam would be a better assessment for programming ability? That sounds bad?
For what its worth, I don't think whiteboards are the best way to assess programming skill either. My preference is for supervised programming assessments - like this article suggests. Whats your preference and why?
>> Seems like we don't even know how big a this problem is.
> Seems like you don't know.
Correct; I don't know. That is why I asked.
If the answer is obvious to you, maybe instead of insults you could link to a study?
> their testing procedures had proven that he was not intelligent enough to do anything else
I see the final sentence as entirely detached from the rest of the story.
My take: Their testing procedures had detected he had lacked basic awareness of the situation. When he received a (written!) communication, he wasn't able to imagine that the author was not the smarter version of himself despite a multitude of clues. The idea didn't occur to him.
Man, and that is a LONG book, but I clearly remember that section for some reason.
"Can you understand a complex code base, figure out how to zoom in on the section of interest, and add a function?"
Far, far too many people interviewing for coding positions can't do that. Though I question how many could whip out FizzBuzz in 5 minutes and would then fail the more complex version. At some level, either you can code, or you can't. And, importantly, at some point in your career (if you go down the standard management track), you will typically lose the ability to code. If you've not done it in 5 years, you probably can't do it, in a practical sense. Not that you can't re-learn, but you can't just jump into a coding interview and ace it, either.
If you find yourself at a point in your career where coding interviews are a thing, "having a side hobby project that requires coding" is a very useful way to be really quite good at coding interviews. Plus, if it's your hobby project, there's no "Hrm... can I talk about that?" sort of problems when you're asked about a time you X'd with Y. You can talk about your personal hobby project absolutely as much, and in depth, as you want.
I don’t know a thing about memcached internals but, as presented here, with the potential encoding and concurrency issues means that there’s likely levels to the complexity here that will likely take someone quite a bit of time to resolve if they’re not familiar with memcached internals.
But again memcached and even C++ isn’t my thing. ¯\_(ツ)_/¯
Years ago, I got tired of some owners of a company I worked for hiring bench techs (small business IT support and such) who'd clearly never opened a computer before (I don't know why, but as the closest person I couldn't focus on any of the work I was supposed to do when constantly being interrupted by bench techs), so I "broke" a scrap computer as an interview problem, rather extensively. RAM wasn't seated, a PCI card wasn't fully seated, I think the power switch was halfway pulled off (enough that it didn't work but was visibly wrong), and I did some terrible things to the partition tables as well. The goal, which it succeeded quite well at from my point of view, was to see where a possible bench tech's skills ended, then help them through. If you'd worked on computers a bunch, and one wasn't powering on, "reseating stuff" was a useful enough response, which would either clear the corrosion on some pins or ensure everything was actually planted in place, which would render this machine booting (after you pushed the power button connector back in), and let me observe what you did with some weird boot errors. There were Windows and Linux environment boot DVDs laying around, so, pick what you know.
The result of this was that our next bench tech hire had the skills to do stuff himself, and generally left me alone to do the stuff I was trying to get done.
In my experience with these questions, it is painfully obvious very quickly those who will and those who won't.
There already exists a function that does the exact thing the question asks for, handling all the atomicity complexity.
What this comes down to is can the candidate: figure out how to build the project, grep to existing implementation and copy, paste, change a plus to an asterisk. And also, can they articulate the work-to-be-done this simply.
I've never seen the first item in that list tested in an interview and .. I don't hate the idea.
While that’s the gist of it, it hardly seems that’s quite enough from the author’s solution, nor should it be enough for an interviewer. The question isn’t how to write, or copy paste a function but how to add the command interface as well which, if one doesn’t know memcached, can be more complex then the function itself and isn’t covered by this trite an answer.
https://quuxplusone.github.io/blog/2022/01/07/memcached-inte...
(I realize this might sound sarcastic, but I'm serious. I think the way interview questions are presented is very important, and often overlooked.)
You would not believe how many times I have to tell some people that it's not a trick, I really don't mind if they google something or use `man`. That I'm not trying to trick them into having to know what the arguments of pthread_create are by heart, or that yes they can compile the program in coderpad as many times as they want.
Really unfortunate that so much of the industry thinks interview questions should be like Shyamalan movies.
(also sadly I'm changing jobs soon and I'll have to abandon this question and I don't think it'd fly in the new job's interview policies anyways)
Definitely. That would make it more clear it's about SE and not stupid brain tricks.
Your first clue is it's an interview for a software engineering job.
1. The code would not build at all on a standard linux distro unless you knew exactly what packages to install. (I had an interview like this once)
2. Locking the key was going to be inexplicably linked to the operation (got very worried when I saw `add_delta` and `do_add_delta`). Turns out add_delta just calls do_add_delta wrapping it in a lock. The lock API is very simple.
3. There would be a massive amount of code duplication that would make it difficult to add this feature without doing serious refactoring. Turns out you basically just change `bool incr` for `math_op_t` or something and provide a way to map from binary/string input to math_op_t.
This would be very easy. Depending on how comfortable I was with the editing environment they talk about elsewhere in the hn comments it wouldn't be too bad.
For example, for adding it should be enough to use an atomic Fetch-And-Add instruction:
https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.h...
Multiply doesn't have an equivalent. You can work around that by reading, multiplying and then using CMPXCHG to atomically update the variable if nothing has changed while you were processing. But you need to think about the ABA problem[1]. (I think in this case its safe, but I haven't thought about it enough. Lock free algorithms have subtle bugs.)
Like do the commands have to be registered somewhere? Is it a string mapping the operation name to a function pointer? A cascading if-then statement? Etc. etc.
It's just a test of diving in and understanding existing code in a relatively short amount of time.
What's the obvious approach? You do have to dig into the source of memcached and understand some internals. With good use of grep and vim it can be done quite quickly, but I wouldn't call it obvious.