3 ms·
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 Wa
by 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 agoMaybe you just haven’t interviewed for tech companies in Silicon Valley/the Bay Area or in Seattle before?
- marssaxman 5y agoThat 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 agoIf 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 agoBig 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 agoIsn’t binary tree depth just simple recursion? Pretty straight forward from programming first principles without memorizing algorithms.