3 ms·

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 medi

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
    That would be a convenient explanation! - but I began my career in CA and moved to Seattle in '99. I've worked for a handful of startups, a few mid-size companies, and three of the megas.
- gcheong 5y ago
  If they’re asking you to explain the time and/or space complexity of your solution in terms of “Big O”, which is something you’d learn in an algorithms class, that’s a good clue. The most recent interview I had asked me to determine the depth of a given binary tree which is about as textbook algorithms class as you can get. Others were a bit more nebulous in terms of solutions but they all span various algorithmic topics you learn in school.
  - jklm 5y ago
    Big O is a useful vocabulary for comparing efficiency between different approaches. Binary trees are abstract, yes, but I prefer them to spending an extra 5-10 minutes listening to an interviewer describe a scenario that ultimately still boils down to a binary tree. From the other side of the table, when I’ve interviewed candidates without a solid understanding of runtimes I’ve seen some very unique code. One candidate wrote a triple-nested for loop and couldn’t understand why it wasn’t an answer we were hoping for. i.e. O(n^3) instead of O(nlgn). Running that code in production honestly would have been a disaster for our oncall. Interviews being such a hot button topic always struck me as odd. On HN we love evaluating new frameworks of the month, or discussing the intricacies of Elixir fundamentals - all of which also require time investment to learn. Why draw the line at learning Big O? Try looking at it through the lens of a useful skill rather than something to memorize for interviews. Even if you never learned it in school, you can still learn it now and it has real life practical value.
  - therealdrag0 5y ago
    Isn’t binary tree depth just simple recursion? Pretty straight forward from programming first principles without memorizing algorithms.

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
  That would be a convenient explanation! - but I began my career in CA and moved to Seattle in '99. I've worked for a handful of startups, a few mid-size companies, and three of the megas.
gcheong 5y ago
If they’re asking you to explain the time and/or space complexity of your solution in terms of “Big O”, which is something you’d learn in an algorithms class, that’s a good clue. The most recent interview I had asked me to determine the depth of a given binary tree which is about as textbook algorithms class as you can get. Others were a bit more nebulous in terms of solutions but they all span various algorithmic topics you learn in school.
- jklm 5y ago
  Big O is a useful vocabulary for comparing efficiency between different approaches. Binary trees are abstract, yes, but I prefer them to spending an extra 5-10 minutes listening to an interviewer describe a scenario that ultimately still boils down to a binary tree. From the other side of the table, when I’ve interviewed candidates without a solid understanding of runtimes I’ve seen some very unique code. One candidate wrote a triple-nested for loop and couldn’t understand why it wasn’t an answer we were hoping for. i.e. O(n^3) instead of O(nlgn). Running that code in production honestly would have been a disaster for our oncall. Interviews being such a hot button topic always struck me as odd. On HN we love evaluating new frameworks of the month, or discussing the intricacies of Elixir fundamentals - all of which also require time investment to learn. Why draw the line at learning Big O? Try looking at it through the lens of a useful skill rather than something to memorize for interviews. Even if you never learned it in school, you can still learn it now and it has real life practical value.
- therealdrag0 5y ago
  Isn’t binary tree depth just simple recursion? Pretty straight forward from programming first principles without memorizing algorithms.