4 ms·

Interviewing is really tough. The OP replaced some coding questions with other questions and if he were to interview a bunch of people with them, we'd get anoth

Interviewing is really tough. The OP replaced some coding questions with other questions and if he were to interview a bunch of people with them, we'd get another set of blog posts complaining how ridiculous his interview questions were. "Why is it bad to write a file to the disk one byte at a time?" What are they interviewing for, low level disk experts? "Here's a stack trace from an open source project, can you tell me what went wrong?" Oh sure, print-based debugging is awful, you just have to read stack traces from unfamiliar projects in the blink of an eye. "Here's a CRUD app, copy existing code patterns to implement a new CRUD endpoint" 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!!!!

EdwardDiego 5y ago
> What are they interviewing for, low level disk experts? Why would only low level disk experts be able to answer that?
- eklavya 5y ago
  That’s not their point. Point is, it’s really subjective and there is no standard answer. As much hate as leetcode style interviews get, you at least have a standard interview process as that point but yeah don’t overdo it and make sure the loop is varied in the areas it covers.
  - kevinventullo 5y ago
    I believe “Writing to disk one byte at a time will be slow” is the standard answer, with varying levels of detail depending on the role.
    - eklavya 5y ago
      I am being misunderstood, let me elaborate, point is, there is no standard answer to the question “what to ask in an interview”. They are just giving an example of how somebody will always have problem with the questions being asked and they could be right in their perspective which is just different.
dimmke 5y ago
Seriously. I feel like complaining about hiring for programmers is the #1 topic discussed on HN. 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.
- l8rpeace 5y ago
  Like interviews for program managers? There are all sorts of anecdotal topics that aren't revolving around impact.
tharkun__ 5y ago
What are they interviewing for, low level disk experts? While I agree that "disk" stuff is "low level" compared to a web developer, it's definitely a very relevant question. You might ask it and if the candidate is interviewing for a web developer position rephrase it after getting a blank stare: Why is it bad retrieving 50 users from a REST endpoint like `/api/users/{id}`, one at a time? Oh sure, print-based debugging is awful, you just have to read stack traces from unfamiliar projects in the blink of an eye. That's actually pretty relevant. If you want to be nice, make it something that uses the same stack as you're hiring for but even if not, it can tell you something about the candidate. Some candidates might react like you did in this reply. Not hired. Some candidates might go "oh well, that looks like python, which I'm not familiar with but let's see, ..." and then they try to figure something out from the function call naming and error messages shown. In any large enough company you will definitely be looking at unfamiliar stack traces, potentially from a service you are unfamiliar with and potentially a different stack than you're used to. Happens all the time at my place for example. I can't just throw up my arms and ignore it. Gotta dig in and use generic problem solving skills. 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!!!! Or maybe it's a simple test of "OK, so all of the other questions the candidate sort of failed on. Can he at least do 'stackoverflow copy and paste programming'?" Whether it's a CRUD endpoint or something else entirely doesn't matter. The point is: can this candidate work w/ something potentially unfamiliar and still get something done? Happens all the time in any large enough code base. Happened to me just this week where I had to implement something I needed in a old python service we have. I don't like python and I don't know any of the python frameworks used there. I copy and pasted, adjusted and google some basic python syntax and got it done in like half an hour. That's what they're testing for there. Sounds perfectly reasonable to me.
- wiseowise 5y ago
  > Sounds perfectly reasonable to me. Sounds like a mental gymnastics to me.
  - nitrogen 5y ago
    It's perfectly reasonable to expect a developer to be able to recognize patterns and repeat them.
dehrmann 5y ago
To quote the author, > 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.
- wiseowise 5y ago
  Definitely much more subjective than algorithm interview.
  - disgruntledphd2 5y ago
    It feels like the other way round to me, can you clarify why you think that a multiple choice questionnaire is more subjective than an algorithmic interview?
    - wiseowise 5y ago
      > I could absolutely see people complaining about multiple choice questions and how you're more likely to get tripped up by minor mistakes.
      - disgruntledphd2 5y ago
        But this is also common in algorithmic interviews, correct? Like if I have a sheet that says bubble sort is the answer, and you provide merge sort then you are marked wrong. 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.
  - dehrmann 5y ago
    Sure, but performance reviews are inevitably subjective.
dehrmann 5y ago
> What are they interviewing for, low level disk experts? Writing one byte at a time is a pretty quick way to ruin flash on a mobile device (or really, any flash).
ngc248 5y ago
True .... However maligned l33tcode questions are you can at least prepare for them and there can only be one correct answer. The questions you enumerate are more subjective and depends on the interviewer's experience/maturity on how well they can gauge someone's answers.
wruza 5y ago
What are they interviewing for, low level disk experts? 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.
arthur6667 5y ago
I'm not sure if you are being sarcastic or not, but I think those are some pretty excellent interview questions. 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.
- gilbetron 5y ago
  I was being sarcastic with the question responses - the point being, for any question you ask in an interview, there is a significant population of candidates that will think it is a terrible question.

EdwardDiego 5y ago

> What are they interviewing for, low level disk experts? Why would only low level disk experts be able to answer that?

eklavya 5y ago
That’s not their point. Point is, it’s really subjective and there is no standard answer. As much hate as leetcode style interviews get, you at least have a standard interview process as that point but yeah don’t overdo it and make sure the loop is varied in the areas it covers.
- kevinventullo 5y ago
  I believe “Writing to disk one byte at a time will be slow” is the standard answer, with varying levels of detail depending on the role.
  - eklavya 5y ago
    I am being misunderstood, let me elaborate, point is, there is no standard answer to the question “what to ask in an interview”. They are just giving an example of how somebody will always have problem with the questions being asked and they could be right in their perspective which is just different.

dimmke 5y ago

Seriously. I feel like complaining about hiring for programmers is the #1 topic discussed on HN. 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.

l8rpeace 5y ago
Like interviews for program managers? There are all sorts of anecdotal topics that aren't revolving around impact.

tharkun__ 5y ago

What are they interviewing for, low level disk experts? While I agree that "disk" stuff is "low level" compared to a web developer, it's definitely a very relevant question. You might ask it and if the candidate is interviewing for a web developer position rephrase it after getting a blank stare: Why is it bad retrieving 50 users from a REST endpoint like `/api/users/{id}`, one at a time? Oh sure, print-based debugging is awful, you just have to read stack traces from unfamiliar projects in the blink of an eye. That's actually pretty relevant. If you want to be nice, make it something that uses the same stack as you're hiring for but even if not, it can tell you something about the candidate. Some candidates might react like you did in this reply. Not hired. Some candidates might go "oh well, that looks like python, which I'm not familiar with but let's see, ..." and then they try to figure something out from the function call naming and error messages shown. In any large enough company you will definitely be looking at unfamiliar stack traces, potentially from a service you are unfamiliar with and potentially a different stack than you're used to. Happens all the time at my place for example. I can't just throw up my arms and ignore it. Gotta dig in and use generic problem solving skills. 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!!!! Or maybe it's a simple test of "OK, so all of the other questions the candidate sort of failed on. Can he at least do 'stackoverflow copy and paste programming'?" Whether it's a CRUD endpoint or something else entirely doesn't matter. The point is: can this candidate work w/ something potentially unfamiliar and still get something done? Happens all the time in any large enough code base. Happened to me just this week where I had to implement something I needed in a old python service we have. I don't like python and I don't know any of the python frameworks used there. I copy and pasted, adjusted and google some basic python syntax and got it done in like half an hour. That's what they're testing for there. Sounds perfectly reasonable to me.

wiseowise 5y ago
> Sounds perfectly reasonable to me. Sounds like a mental gymnastics to me.
- nitrogen 5y ago
  It's perfectly reasonable to expect a developer to be able to recognize patterns and repeat them.

dehrmann 5y ago

To quote the author, > 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.

wiseowise 5y ago
Definitely much more subjective than algorithm interview.
- disgruntledphd2 5y ago
  It feels like the other way round to me, can you clarify why you think that a multiple choice questionnaire is more subjective than an algorithmic interview?
  - wiseowise 5y ago
    > I could absolutely see people complaining about multiple choice questions and how you're more likely to get tripped up by minor mistakes.
    - disgruntledphd2 5y ago
      But this is also common in algorithmic interviews, correct? Like if I have a sheet that says bubble sort is the answer, and you provide merge sort then you are marked wrong. 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.
- dehrmann 5y ago
  Sure, but performance reviews are inevitably subjective.

dehrmann 5y ago

> What are they interviewing for, low level disk experts? Writing one byte at a time is a pretty quick way to ruin flash on a mobile device (or really, any flash).

ngc248 5y ago

True .... However maligned l33tcode questions are you can at least prepare for them and there can only be one correct answer. The questions you enumerate are more subjective and depends on the interviewer's experience/maturity on how well they can gauge someone's answers.

wruza 5y ago

What are they interviewing for, low level disk experts? 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.

arthur6667 5y ago

I'm not sure if you are being sarcastic or not, but I think those are some pretty excellent interview questions. 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.

gilbetron 5y ago
I was being sarcastic with the question responses - the point being, for any question you ask in an interview, there is a significant population of candidates that will think it is a terrible question.