I actually feel like algorithm questions are somewhat of an improvement in the programmer hiring process over the alternatives. When interviewing at places that don't have them, the surface area of questions you can be asked is so much bigger.

Like one of the anecdotes in this thread about getting drilled on a testing framework (that the candidate probably added to their resume because they have to have all these keywords to make it through their automated resume scanner and maybe they only played with it for a couple hours one afternoon because they don't use it in their day job.)

With algorithmic questions: - You're doing one type of preparation for a large amount of potential roles - There's tons and tons and tons of great material out there to help you prepare - Probably most controversial but I really believe it: It really does make you a stronger programmer.

For me, doing those kind of questions forced me to learn data structures more thoroughly and dramatically improved my understanding of how to write algorithms and think about performance. This stuff really does matter in terms of code quality and it really bothers me that it's always portrayed as these completely silly puzzles.

The other thing that I see pushed a lot in these discussions is this idea that every company (or most companies) that hires programmers does these exercises. That's just not true. If you're getting coderpad links for every phone screen, you're going after a certain type of company.

    What are they interviewing for, low level disk experts?

    Oh sure, print-based debugging is awful, you just have to read stack traces from unfamiliar projects in the blink of an eye.

    Ah yes, the reductive "everything is a CRUD app" - this interviewer doesn't understand that most applications don't fall under the simplistic "CRUD" moniker!!!! 

Sounds like a mental gymnastics to me.

Writing one byte at a time may be “bad” at many levels. First, on a hardware level it is inefficient because the unit is a sector/block and the access latency kicks in hard, together with a wear leveling on ssds. Embedded low level indeed. On an os/syscall level it is inefficient because of a syscall time itself. It is a system level touching C and unbuffered writes in “middle-level” languages/libs. On an application level it may be inefficient if a stream has a processing pipeline with some expensive setup/try/teardown (e.g. a jsonl parser which “tries” the buffer at every new chunk). Is this still low level?

This is a question about streaming, buffering and latency avoidance, which you may not know in hw detail, but have to have at least a vague grasp of. If a candidate seems confused, one may ask them about other situations where one-at-a-time may become “bad”: sql select one row at a time, fetch NNN items one by one, use heavy_expr().x, heavy_expr().y repeatedly or in a loop. If nothing comes to their mind, chances are you are interviewing a completely inexperienced person, because there is no way they didn’t meet that or think of that before.

I totally agree that it shouldn’t be the reason to skip a candidate, but hiring is an analyzing process, and how do you find their limit if not asking deep open questions? I think that the issue is pushing hard on these areas as if it was laughable for a professional to not know it.

The first one, it's exactly about the thing I find a lot of developers lack in: a fundamental understanding about computers and processing. I've had 'experienced' developers write algorithms where every intermediate value was written to a cache/disk only to pull it out on the next line. I feel asking some more fundamental questions can help weed ppl out.

Same with being able to look at a stack trace and see where it went wrong, how quickly are you able to hone in on a specific target. Crucial skill imo, and I've had sooooo many people at my desk -- 'it's not working' -- that did not even read the f'ing error message.

Why would only low level disk experts be able to answer that?

> Triplebyte has a quiz that actually does a pretty good job of this; you get asked thirty or so questions about databases, networking, and simple coding questions ("what is the value of 'a' when you get to line 17?").

I could absolutely see people complaining about multiple choice questions and how you're more likely to get tripped up by minor mistakes.

The interesting thing about mcq is that their administration is completely standardised so it's more objective in pretty much every sense.

Maybe you prefer algorithmic interviews, that's fine. But I really don't understand how you can believe that they are less subjective than algorithmic interviews.

They avoid the bias of using different interviewers which is massive, even if the questions are standard.

The questions you enumerate are more subjective and depends on the interviewer's experience/maturity on how well they can gauge someone's answers.

Writing one byte at a time is a pretty quick way to ruin flash on a mobile device (or really, any flash).