5 ms·

> Testing for simple algorithms knowledge biases for recently graduated people who have these in their active memory. I have never understood this argument. Wi

> Testing for simple algorithms knowledge biases for recently graduated people who have these in their active memory. I have never understood this argument. With 29 years of experience, I am about as far from being a "recently graduated person" as anyone could be - in fact, I never graduated at all! Not only did I drop out after three semesters, I never took so much as one computer science class. I have, according to your assumptions, never had algorithms knowledge in my active memory - and yet, these sorts of questions have never been an obstacle for me. How can this be? I think many people must mistakenly believe that interview questions are the same sort of questions one might find on a university test. They appear to believe that the interviewer expects them to regurgitate a correct answer, on the spot, from memory, and that their suitability for the job is rated based on the speed of recall. That would be absurd, of course. If anyone is actually interviewing people that way, they're doing a terrible job. I have never answered these questions that way - and, when I ask such questions in an interview, I never expect them to be answered that way. Rather, the point of an algorithms problem is that you have to think your way through it. I solve them in the same way I would solve any problem I encountered in my day-to-day programming work: by thinking about it, poking around at different approaches, roughing out a simplest-possible approach, then refining toward a more efficient process. If I am interviewing you, and I pose you an algorithms problem, I'm hoping you will not have memorized an answer. If you already know the answer, your skill at writing it out on the whiteboard tells me nothing. The whole point of asking you to think your way through an algorithms problem is that I want to see how you think. I don't even care whether you find your way through to a correct answer in the time allotted, so long as I can see that you know how to think about a problem, work your way toward a solution, and communicate about your process as you go. The common idea that experienced devs ought to struggle with algorithms questions dismays me. What are people doing that does not require them to maintain basic problem-solving skills? Or... perhaps... is this all a big misunderstanding...

gcheong 5y ago
That’s how it should work but it seems to have largely gravitated toward, not rewarding memorization exactly, but definitely pattern recognition gained from drilling on a wide arrangement of leetcode style problems, and as much as they say they want to understand your thought process your performance is heavily weighted towards whether or not you arrive at the optimal solution in the time given, not how well you might explain how you might get there even if your code is ultimately lacking due to time constraints.
bradlys 5y ago
How often do you interview and how often are you doing LC interviews? There’s no real time to “see how one thinks” when the expectation is to pump out two medium answers in <45 minutes. You’re basically just reading the question, going through a couple hoops, and then implementing/explaining the algorithm. There’s barely any time to “see how one thinks” in these modern interviews. Maybe you can show three problems you were asked recently and how long you had to solve them.
- marssaxman 5y ago
  I have never encountered what I would consider to be a "leetcode interview"; that is the essence of my bafflement when people talk as though it is simply The Way Tech Interviews Are Done. Perhaps I have simply been lucky, but my luck has held for a very long time, and that makes me want a better explanation. When I hear people describe these "leetcode interviews", they often describe a process which sounds very much like being given a normal interview problem, except they assume, for reasons which have never been clear to me, that they must have a memorized answer at hand in order to succeed. From my non-college-trained perspective, this seems like the sort of misunderstanding one might easily make if one attempted to apply years of practice with school exams to a new environment. Perhaps I have encountered "leetcode interviews", and simply didn't experience them the same way? Or perhaps the "leetcode thing" genuinely is a different style of interview, which has grown up in a sector of the industry I don't care for. That might explain why it seems ubiquitous to some and nonexistent to others... How often do I interview - ? Well, whenever I might want a new job, I suppose. I'm not sure what you mean; you seem to be implying that people interview recreationally? Last time would have been three-odd years ago, and I certainly did not bother to write down the problems which would have been involved.
  - Apocryphon 5y ago
    Maybe you just haven’t interviewed for tech companies in Silicon Valley/the Bay Area or in Seattle before?
    - marssaxman 5y ago
bcbrown 5y ago
> That, of course, would be absurd. If anyone is actually interviewing people that way, they're doing a terrible job. Perhaps you have never experienced that sort of interview, but it doesn't mean it doesn't exist. I was once asked a question where the solution involved implementing a trie. The naive design involves a 26-element array to hold all the possible next-letter entries, which obviously takes a huge amount of memory. The interviewer expected me to know the trivia answer on how to avoid allocating all that memory, and was clearly disappointed that I didn't know (using a linked list instead of a fixed-size array: https://en.wikipedia.org/wiki/Trie#Implementation_strategies https://en.wikipedia.org/wiki/Trie#Implementation_strategies). This was a principal engineer interviewing another principal engineer, FWIW. The company was Qualtrics, a survey/customer satisfaction company, not a bare-metal algorithms-heavy company. Obviously you've managed to have a successful career without encountering interview questions that hinge on algorithmic trivia, and I'm not doubting your experience. But saying "it's never happened to me so therefore it can't exist" isn't an especially strong argument.
- jklm 5y ago
  I’ve had this happen to me too. When I had only 2 years of experience, I was asked to code parallel dijkstra's in an interview. That startup shut its doors only 2 years later - guessing a hiring issue. But at the same time, saying “it happened to me once therefore it’s generally the case” isn’t a strong argument. I agree with the GP. I’m also a dropout, but am generally pretty good at navigating FANG-style questions, which are leetcode medium at worst. Often it feels like they’re ultimately testing for depth of understanding, flexibility, and creativity when coming up with an answer. It’s possible to brute-force your way through questions by rote memorization, but that’s going about it in the wrong spirit. And it feels like that's the gap when this topic comes up. Interviewing is a skill to a certain extent, with maybe a few days/interviews of warmups. But if you believe that your ability to land jobs is directly correlated to regurgitating leetcode hard questions, the outcome is almost predestined. If I had to sum up from personal experience: - Not every good leetcoder I know is a top engineer. - Every top engineer I know is a good (but not necessarily great!) leetcoder.

gcheong 5y ago

That’s how it should work but it seems to have largely gravitated toward, not rewarding memorization exactly, but definitely pattern recognition gained from drilling on a wide arrangement of leetcode style problems, and as much as they say they want to understand your thought process your performance is heavily weighted towards whether or not you arrive at the optimal solution in the time given, not how well you might explain how you might get there even if your code is ultimately lacking due to time constraints.

bradlys 5y ago

How often do you interview and how often are you doing LC interviews? There’s no real time to “see how one thinks” when the expectation is to pump out two medium answers in <45 minutes. You’re basically just reading the question, going through a couple hoops, and then implementing/explaining the algorithm. There’s barely any time to “see how one thinks” in these modern interviews. Maybe you can show three problems you were asked recently and how long you had to solve them.

marssaxman 5y ago
I have never encountered what I would consider to be a "leetcode interview"; that is the essence of my bafflement when people talk as though it is simply The Way Tech Interviews Are Done. Perhaps I have simply been lucky, but my luck has held for a very long time, and that makes me want a better explanation. When I hear people describe these "leetcode interviews", they often describe a process which sounds very much like being given a normal interview problem, except they assume, for reasons which have never been clear to me, that they must have a memorized answer at hand in order to succeed. From my non-college-trained perspective, this seems like the sort of misunderstanding one might easily make if one attempted to apply years of practice with school exams to a new environment. Perhaps I have encountered "leetcode interviews", and simply didn't experience them the same way? Or perhaps the "leetcode thing" genuinely is a different style of interview, which has grown up in a sector of the industry I don't care for. That might explain why it seems ubiquitous to some and nonexistent to others... How often do I interview - ? Well, whenever I might want a new job, I suppose. I'm not sure what you mean; you seem to be implying that people interview recreationally? Last time would have been three-odd years ago, and I certainly did not bother to write down the problems which would have been involved.
- Apocryphon 5y ago
  Maybe you just haven’t interviewed for tech companies in Silicon Valley/the Bay Area or in Seattle before?
  - marssaxman 5y ago

bcbrown 5y ago

> That, of course, would be absurd. If anyone is actually interviewing people that way, they're doing a terrible job. Perhaps you have never experienced that sort of interview, but it doesn't mean it doesn't exist. I was once asked a question where the solution involved implementing a trie. The naive design involves a 26-element array to hold all the possible next-letter entries, which obviously takes a huge amount of memory. The interviewer expected me to know the trivia answer on how to avoid allocating all that memory, and was clearly disappointed that I didn't know (using a linked list instead of a fixed-size array: https://en.wikipedia.org/wiki/Trie#Implementation_strategies https://en.wikipedia.org/wiki/Trie#Implementation_strategies). This was a principal engineer interviewing another principal engineer, FWIW. The company was Qualtrics, a survey/customer satisfaction company, not a bare-metal algorithms-heavy company. Obviously you've managed to have a successful career without encountering interview questions that hinge on algorithmic trivia, and I'm not doubting your experience. But saying "it's never happened to me so therefore it can't exist" isn't an especially strong argument.

jklm 5y ago
I’ve had this happen to me too. When I had only 2 years of experience, I was asked to code parallel dijkstra's in an interview. That startup shut its doors only 2 years later - guessing a hiring issue. But at the same time, saying “it happened to me once therefore it’s generally the case” isn’t a strong argument. I agree with the GP. I’m also a dropout, but am generally pretty good at navigating FANG-style questions, which are leetcode medium at worst. Often it feels like they’re ultimately testing for depth of understanding, flexibility, and creativity when coming up with an answer. It’s possible to brute-force your way through questions by rote memorization, but that’s going about it in the wrong spirit. And it feels like that's the gap when this topic comes up. Interviewing is a skill to a certain extent, with maybe a few days/interviews of warmups. But if you believe that your ability to land jobs is directly correlated to regurgitating leetcode hard questions, the outcome is almost predestined. If I had to sum up from personal experience: - Not every good leetcoder I know is a top engineer. - Every top engineer I know is a good (but not necessarily great!) leetcoder.