5 ms·

There’s plenty of issues around algorithmic questions, and it’s even possible he would fail them, but there’s still important value in asking them. Senior engi

There’s plenty of issues around algorithmic questions, and it’s even possible he would fail them, but there’s still important value in asking them. Senior engineers in such companies need to work and cooperate with hundreds of people. If they find solving such problems beneath them, or expect to be treated as a higher class of person, or not willing to get hands dirty, they will not be as valuable as employees. (Occasionally, the lone genius is great, but the lone genius is a worse employee than the genius that can cooperate well) My company would keep doing such interviews, but the expectations change of course. A new grad needs to do these well. More senior people can do worse, and make up for it using other skills showcased in other interviews, or based on their record. But if you find a senior person that finds solving algorithmic questions is beneath them, you might want to be careful about them and how they will interact with your company’s culture.

rndgermandude 6y ago
I never remember the nitty-gritty details of the more complex algorithms and data structures, I only remember they exist and their important properties. If I then have to implement one, I consult google or books. Googling often has the neat side effect that you'll sometimes find refinements/improvements or other (new) potentially better algorithms to solve a particular problem. Or somebody might have done the heavy lifting already and packaged it up under a compatible license (if it isn't something simple like leftPad). I mean, it's OK to ask for basic algorithms in interviews, to see if the interviewee has at least some understanding of basic stuff and/or can think on their feet and/or can reason about problems appropriately... But I would still welcome it if instead of giving an interviewee a boring, memorizable problem like "invert a binary tree", the interviewer would find a more general problem and would see how the employee would tackle it, and if the interviewee refers to binary trees as part of the solution without writing out a full implementation from memory that's OK (as long as binary trees would be a valid approach to solve the problem, of course).
- fernandotakai 6y ago
  > the interviewer would find a more general problem and would see how the employee would tackle it those are the best interviews imho. specially when both the candidate and the interviewer engage into a productive discussion about the solution the candidate gave. at the same time, those take time and a lot of companies want a "fast" hiring pipeline, which leads to "invert a binary tree on this whiteboard!".
- strulovich 6y ago
  Just for reference, my company does not ask anyone to implement a binary tree or any well known algorithms in coding interviews. I see a bunch of comments that look to me as strawman, or really bad interview experience. A good coding interview should: - not be known by the interviewee if they spent even a few weeks on leetcode - avoid requiring anything that isn’t covered in an average CS101 class - draw its challenges from the need to process a new problem, and gradually uncover the edge cases in it and how to handle them gracefully. I don’t do leetcode. But went now and tried the first hard question I found. It was “find the median of two sorted arrays”. I find this question to be a good example of very little background knowledge needed. (You’d need to know how to deal with arrays, and what’s a median - not everyone will know these, but it’s a pretty low bar) This question already has plenty of room for mistakes, edge cases and problem solving. I’m going to take a wild guess from knowing talented veteran engineers I’ve seen that they can surely handle it in the interview structures I’ve experienced.
throwaway894345 6y ago
It’s not a question of status, but rather the utility of memorizing algorithms as an indicator of success. Notably, it’s probably not because Google exists and anyway the majority of one’s time isn’t finding the optimal algorithm.
pc86 6y ago
I don't think the problem is senior folks believing answering questions about bubble sort beneath them (I'm sure some do but I doubt it's the norm), I think the problem is that 99.99% of developers at all levels don't need to know how bubble sort works to do their jobs well.
peteradio 6y ago
Guido is not a senior engineer.. he's a "special projects" person. Fewer than 50 such persons would exist in the microsoft stable. Why would you have someone who functions at such a high level bother with low level implementation? There's thousands of shit munching nerds who can implement flawlessly but who need the overarching guidance to deliver product.
- anfeldman 6y ago
  Because most really good designers also did low level implementation? Thompson, Ritchie, Leroy, Torvalds. Heck, while I don't know for sure, probably Dave Cutler did, too. I don't know any product that's pleasant to use that was developed in the way you describe. Python certainly wasn't.
wing-_-nuts 6y ago
One thing I have always hated about HN, is that they grey out downvoted comments. That has to be the absolute worst UI decision possible. At least at other sites, when you manually expand a downvoted comment, it's actually readable. Here the contrast is purposely so low, I'll never know what you wrote.
- three_legs 6y ago
  I don't think it's so much of a UI decision vs. a product decision, i.e. they want downvoted comments to be less attractive to read, I suppose. That said, I do agree - it'd be nicer if they weren't. I tend to highlight downvoted comments so I can read them better
deleted 6y ago
[deleted]
hajile 6y ago
Many threads, SIMD, cache hierarchies, and calculations often being "free" due to general memory pressure means the classic version of any algorithm is pretty much guaranteed to be bad at it's job while a seemingly worse algorithm might actually perform better. You likely won't learn any of that from your algorithms book. If you tried to implement those algorithms on my team without a very good reason, there would definitely be some serious conversations that followed. In any case, vomiting algorithms on command doesn't seem to correlate strongly to programming ability. Almost all programming problems have a lot more to do with handling much higher-level complexity issues. The knowledge and art of knowing how to poke some undocumented third-party API to implement our system is much more practical. Knowing how to think at a high level is much more practical. Leave algorithm questions for research positions in that area.

rndgermandude 6y ago

I never remember the nitty-gritty details of the more complex algorithms and data structures, I only remember they exist and their important properties. If I then have to implement one, I consult google or books. Googling often has the neat side effect that you'll sometimes find refinements/improvements or other (new) potentially better algorithms to solve a particular problem. Or somebody might have done the heavy lifting already and packaged it up under a compatible license (if it isn't something simple like leftPad). I mean, it's OK to ask for basic algorithms in interviews, to see if the interviewee has at least some understanding of basic stuff and/or can think on their feet and/or can reason about problems appropriately... But I would still welcome it if instead of giving an interviewee a boring, memorizable problem like "invert a binary tree", the interviewer would find a more general problem and would see how the employee would tackle it, and if the interviewee refers to binary trees as part of the solution without writing out a full implementation from memory that's OK (as long as binary trees would be a valid approach to solve the problem, of course).

fernandotakai 6y ago
> the interviewer would find a more general problem and would see how the employee would tackle it those are the best interviews imho. specially when both the candidate and the interviewer engage into a productive discussion about the solution the candidate gave. at the same time, those take time and a lot of companies want a "fast" hiring pipeline, which leads to "invert a binary tree on this whiteboard!".
strulovich 6y ago
Just for reference, my company does not ask anyone to implement a binary tree or any well known algorithms in coding interviews. I see a bunch of comments that look to me as strawman, or really bad interview experience. A good coding interview should: - not be known by the interviewee if they spent even a few weeks on leetcode - avoid requiring anything that isn’t covered in an average CS101 class - draw its challenges from the need to process a new problem, and gradually uncover the edge cases in it and how to handle them gracefully. I don’t do leetcode. But went now and tried the first hard question I found. It was “find the median of two sorted arrays”. I find this question to be a good example of very little background knowledge needed. (You’d need to know how to deal with arrays, and what’s a median - not everyone will know these, but it’s a pretty low bar) This question already has plenty of room for mistakes, edge cases and problem solving. I’m going to take a wild guess from knowing talented veteran engineers I’ve seen that they can surely handle it in the interview structures I’ve experienced.

throwaway894345 6y ago

It’s not a question of status, but rather the utility of memorizing algorithms as an indicator of success. Notably, it’s probably not because Google exists and anyway the majority of one’s time isn’t finding the optimal algorithm.

pc86 6y ago

I don't think the problem is senior folks believing answering questions about bubble sort beneath them (I'm sure some do but I doubt it's the norm), I think the problem is that 99.99% of developers at all levels don't need to know how bubble sort works to do their jobs well.

peteradio 6y ago

Guido is not a senior engineer.. he's a "special projects" person. Fewer than 50 such persons would exist in the microsoft stable. Why would you have someone who functions at such a high level bother with low level implementation? There's thousands of shit munching nerds who can implement flawlessly but who need the overarching guidance to deliver product.

anfeldman 6y ago
Because most really good designers also did low level implementation? Thompson, Ritchie, Leroy, Torvalds. Heck, while I don't know for sure, probably Dave Cutler did, too. I don't know any product that's pleasant to use that was developed in the way you describe. Python certainly wasn't.

wing-_-nuts 6y ago

One thing I have always hated about HN, is that they grey out downvoted comments. That has to be the absolute worst UI decision possible. At least at other sites, when you manually expand a downvoted comment, it's actually readable. Here the contrast is purposely so low, I'll never know what you wrote.

three_legs 6y ago
I don't think it's so much of a UI decision vs. a product decision, i.e. they want downvoted comments to be less attractive to read, I suppose. That said, I do agree - it'd be nicer if they weren't. I tend to highlight downvoted comments so I can read them better

deleted 6y ago

[deleted]

hajile 6y ago

Many threads, SIMD, cache hierarchies, and calculations often being "free" due to general memory pressure means the classic version of any algorithm is pretty much guaranteed to be bad at it's job while a seemingly worse algorithm might actually perform better. You likely won't learn any of that from your algorithms book. If you tried to implement those algorithms on my team without a very good reason, there would definitely be some serious conversations that followed. In any case, vomiting algorithms on command doesn't seem to correlate strongly to programming ability. Almost all programming problems have a lot more to do with handling much higher-level complexity issues. The knowledge and art of knowing how to poke some undocumented third-party API to implement our system is much more practical. Knowing how to think at a high level is much more practical. Leave algorithm questions for research positions in that area.