4 ms·

Just don't ask brain teasers when you conduct an interview; I believe they give no valid signal at all, and I also believe Microsoft does not ask them anymore.

by ventana 2mo ago

Just don't ask brain teasers when you conduct an interview; I believe they give no valid signal at all, and I also believe Microsoft does not ask them anymore. The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided. When I conducted interviews for FAANG, I asked somewhat simpler coding questions, something around DFS and/or topological sorting (without calling it by name, of course), because those are thing which you might actually need to implement at work: people sometimes traverse JSONs, and people sometimes resolve dependencies. No one has ever told me "oh, I know this problem, it's DFS", because surely I know they know it. Just show me that you can write the code.

viccis 2mo ago
>The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided. The problem with these is that their solutions always seem trivial when you are shown them (or spend time solving yourself) and then mull over them for a while.
- ventana 2mo ago
  I've been doing "daily leetcode" for fun, just to remember how to write code manually without agents, and a few days ago they gave a brain teaser kind of task [1], for which the solution was just [2] (spoiler alert). It took me quite some time to come to that solution, and I'm not really sure I would've found it with all the stress of being on a real interview. [1]: https://leetcode.com/problems/stone-game/ https://leetcode.com/problems/stone-game/ [2]: return True
  - viccis 2mo ago
    Yeah one of the worst offenders of this are the leetcode problems that have a clever but extremely elegantly simple greedy algorithm (such as "return True" lol). Great example is Majority Element [1] The answer seems pretty clear when you think about it enough, even the proof seems like it makes sense. The problem is marked Easy on Leetcode. But coming up with the algorithm and proving its correctness is a two-name algorithm with its own Wikipedia article. In your example, the challenge isn't even really to "design" that algorithm, it's to prove that it's true. 1: https://leetcode.com/problems/majority-element https://leetcode.com/problems/majority-element 2: https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_majority_vote_algorithm https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_majority_v...
Aachen 2mo ago
> something around DFS and/or topological sorting (without calling it by name, of course), because those are thing which you might actually need to implement at work: people sometimes traverse JSONs, and people sometimes resolve dependencies. No one has ever told me "oh, I know this problem, it's DFS", because surely I know they know it. Well, I've been coding for 15 years (of course walking through data structures, JSON being one of the simplest), hung around HN and did interview puzzles a bunch, and yet have no idea what you mean by DFS nor ever needed to write a topological sorting implementation. No need to explain, I'll look it up for the fomo, but just to show that there's always experienced people who just didn't happen to come across something you say you've needed only on rare occasions ('something you might need') Edit: oh ok, DFS is just depth-first search. Walking a tree. Okay yeah sure I can do that but it seems (from my security PoV) about as common to write tree parsers and sorting algorithms as designing a new cryptographic protocol, that is: hard avoid, rarely necessary
- afpx 2mo ago
  I understand where you're coming from and can empathize because I've been asked some absurd computer science questions in interviews. However, in my experience, if an interviewer can't confirm basic knowledge of data structures and algorithms, then some lead ends up having to teach computer science to explain to a developer why their code with 5 nested loops is probably not a good idea. Having been that lead who has had to stay up all night trying to debug some difficult to reproduce deadlock or race condition ... I would prefer that companies spend resources on training rather than spending $5k to interview a candidate
  - forlorn_mammoth 2mo ago
    > an interviewer can't confirm basic knowledge of data structures and algorithms agreed. However, as I read the parent's post, they did not immediately see that DFS was an acronym for a basic algorithm. Given their implied background in computer security, a field littered with thousands of abbreviations (very few of which are basic algorithms) it is understandable that they needed a minute to see what DFS meant. I could alternately ask a number of python developers if they were familiar with Javascript object notation, and cause a panic because they aren't familiar with javascript. Interviews are stressful. If your field always call it 'json' or 'a dict', you might not immediately make the connection.
paulluuk 2mo ago
I had an interview with Google about 10 years ago. Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more". The interview was literally nothing but back-to-back brainteasers and leetcode-challenges for 3 hours straight. I didn't get the job even though I only failed to solve one problem, and looking back I think that the problem was in fact unsolvable and they wanted me to come to that conclusion rather than admit that I couldn't solve it in my head.
- beng-nl 2mo ago
  The Kobayashi Maru (Though personally I don’t think giving a truly unsolvable problem in an interview without warning that this may be unsolvable is a reasonable test of anything, but a cruel experiment)
- wavemode 2mo ago
  Haven't encountered "marbles in an airplane"-style brainteasers, but leetcode challenges are definitely still the norm at Google and other big tech. Not sure who was claiming otherwise.
- ventana 2mo ago
  > Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more" Google, just like all other FAANG companies, uses a lot of Leetcode-style questions and there's no tendency for this to change so far. The thing that Google does is that they ban interview questions which were exposed on Leetcode, so they could've meant that you won't be given a question that is known to Leetcode crowds. > looking back I think that the problem was in fact unsolvable As for the unsolvable problem, this is weird, but when the company has tens of thousands of active interviewers, chances are that one of them will surely ask some bullshit question, and there is a very low chance that someone will ever let that interviewer know that they're not doing a good job. The lottery aspect always exists here.
calchedonic 2mo ago
> The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided. I remember an MS interview I failed in 2015 or thereabouts: As part of the interview, they asked "how would you find the kth element from the end of a singly-linked list in the shortest time", and they strongly implied that size() followed by counting forward was not what they were looking for, and that they were expecting constant space. I didn't know the answer, and failed. I don't know if I failed because of it, but anyway. So I went home and looked up the intended solution, which is the dual iterator, advance one k times then repeatedly advance both one step. After a bit of thought I realized that the time complexity is the exact same as the naive size() + count. With size(), you do n traversals to get the number of elements, then you do n-k to get your iterator to the desired position. With dual iterators, you advance one n times and the other n-k times. Same deal, total number of steps is 2n-k no matter what, and linked lists usually aren't sequential in memory, so there are no cache benefits favoring one over the other. There are other advantages to dual iterator-like algorithms (e.g. if it's a stream, you cache the k last seen values and pass only once at the cost of O(k) space; or if it's paging from very slow storage, it pages less due to locality). But they didn't say anything to indicate they were doing a stream. They were, essentially, just reading a puzzle from a book and expecting a particular solution.
- ventana 2mo ago
  The interviewer probably learned the trick with two pointers and wanted to see you implement it, for no real reason. This question, just like it's well-known sibling question "check if the linked list has a loop", has absolutely no practical applicability; no one will ever want to find k-th element from the end of the linked list, it's just not the right data structure for this kind of task: it's better to use an array or a double linked list if you need to do this operation often.
mrwh 2mo ago
In my corner of the Faang world it's been 20 years since that sort of brain teaser was asked. We switched to coding problems that require dynamic programming!
gwbas1c 2mo ago
> The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided. Those are usually the first hints I give; mostly because I'm concerned about "everything else" in the coding question.

by ventana 2mo ago

viccis 2mo ago

>The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided. The problem with these is that their solutions always seem trivial when you are shown them (or spend time solving yourself) and then mull over them for a while.

ventana 2mo ago
I've been doing "daily leetcode" for fun, just to remember how to write code manually without agents, and a few days ago they gave a brain teaser kind of task [1], for which the solution was just [2] (spoiler alert). It took me quite some time to come to that solution, and I'm not really sure I would've found it with all the stress of being on a real interview. [1]: https://leetcode.com/problems/stone-game/ https://leetcode.com/problems/stone-game/ [2]: return True
- viccis 2mo ago
  Yeah one of the worst offenders of this are the leetcode problems that have a clever but extremely elegantly simple greedy algorithm (such as "return True" lol). Great example is Majority Element [1] The answer seems pretty clear when you think about it enough, even the proof seems like it makes sense. The problem is marked Easy on Leetcode. But coming up with the algorithm and proving its correctness is a two-name algorithm with its own Wikipedia article. In your example, the challenge isn't even really to "design" that algorithm, it's to prove that it's true. 1: https://leetcode.com/problems/majority-element https://leetcode.com/problems/majority-element 2: https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_majority_vote_algorithm https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_majority_v...

Aachen 2mo ago

> something around DFS and/or topological sorting (without calling it by name, of course), because those are thing which you might actually need to implement at work: people sometimes traverse JSONs, and people sometimes resolve dependencies. No one has ever told me "oh, I know this problem, it's DFS", because surely I know they know it. Well, I've been coding for 15 years (of course walking through data structures, JSON being one of the simplest), hung around HN and did interview puzzles a bunch, and yet have no idea what you mean by DFS nor ever needed to write a topological sorting implementation. No need to explain, I'll look it up for the fomo, but just to show that there's always experienced people who just didn't happen to come across something you say you've needed only on rare occasions ('something you might need') Edit: oh ok, DFS is just depth-first search. Walking a tree. Okay yeah sure I can do that but it seems (from my security PoV) about as common to write tree parsers and sorting algorithms as designing a new cryptographic protocol, that is: hard avoid, rarely necessary

afpx 2mo ago
I understand where you're coming from and can empathize because I've been asked some absurd computer science questions in interviews. However, in my experience, if an interviewer can't confirm basic knowledge of data structures and algorithms, then some lead ends up having to teach computer science to explain to a developer why their code with 5 nested loops is probably not a good idea. Having been that lead who has had to stay up all night trying to debug some difficult to reproduce deadlock or race condition ... I would prefer that companies spend resources on training rather than spending $5k to interview a candidate
- forlorn_mammoth 2mo ago
  > an interviewer can't confirm basic knowledge of data structures and algorithms agreed. However, as I read the parent's post, they did not immediately see that DFS was an acronym for a basic algorithm. Given their implied background in computer security, a field littered with thousands of abbreviations (very few of which are basic algorithms) it is understandable that they needed a minute to see what DFS meant. I could alternately ask a number of python developers if they were familiar with Javascript object notation, and cause a panic because they aren't familiar with javascript. Interviews are stressful. If your field always call it 'json' or 'a dict', you might not immediately make the connection.

paulluuk 2mo ago

I had an interview with Google about 10 years ago. Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more". The interview was literally nothing but back-to-back brainteasers and leetcode-challenges for 3 hours straight. I didn't get the job even though I only failed to solve one problem, and looking back I think that the problem was in fact unsolvable and they wanted me to come to that conclusion rather than admit that I couldn't solve it in my head.

beng-nl 2mo ago
The Kobayashi Maru (Though personally I don’t think giving a truly unsolvable problem in an interview without warning that this may be unsolvable is a reasonable test of anything, but a cruel experiment)
wavemode 2mo ago
Haven't encountered "marbles in an airplane"-style brainteasers, but leetcode challenges are definitely still the norm at Google and other big tech. Not sure who was claiming otherwise.
ventana 2mo ago
> Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more" Google, just like all other FAANG companies, uses a lot of Leetcode-style questions and there's no tendency for this to change so far. The thing that Google does is that they ban interview questions which were exposed on Leetcode, so they could've meant that you won't be given a question that is known to Leetcode crowds. > looking back I think that the problem was in fact unsolvable As for the unsolvable problem, this is weird, but when the company has tens of thousands of active interviewers, chances are that one of them will surely ask some bullshit question, and there is a very low chance that someone will ever let that interviewer know that they're not doing a good job. The lottery aspect always exists here.

calchedonic 2mo ago

> The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided. I remember an MS interview I failed in 2015 or thereabouts: As part of the interview, they asked "how would you find the kth element from the end of a singly-linked list in the shortest time", and they strongly implied that size() followed by counting forward was not what they were looking for, and that they were expecting constant space. I didn't know the answer, and failed. I don't know if I failed because of it, but anyway. So I went home and looked up the intended solution, which is the dual iterator, advance one k times then repeatedly advance both one step. After a bit of thought I realized that the time complexity is the exact same as the naive size() + count. With size(), you do n traversals to get the number of elements, then you do n-k to get your iterator to the desired position. With dual iterators, you advance one n times and the other n-k times. Same deal, total number of steps is 2n-k no matter what, and linked lists usually aren't sequential in memory, so there are no cache benefits favoring one over the other. There are other advantages to dual iterator-like algorithms (e.g. if it's a stream, you cache the k last seen values and pass only once at the cost of O(k) space; or if it's paging from very slow storage, it pages less due to locality). But they didn't say anything to indicate they were doing a stream. They were, essentially, just reading a puzzle from a book and expecting a particular solution.

ventana 2mo ago
The interviewer probably learned the trick with two pointers and wanted to see you implement it, for no real reason. This question, just like it's well-known sibling question "check if the linked list has a loop", has absolutely no practical applicability; no one will ever want to find k-th element from the end of the linked list, it's just not the right data structure for this kind of task: it's better to use an array or a double linked list if you need to do this operation often.

mrwh 2mo ago

In my corner of the Faang world it's been 20 years since that sort of brain teaser was asked. We switched to coding problems that require dynamic programming!

gwbas1c 2mo ago

> The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided. Those are usually the first hints I give; mostly because I'm concerned about "everything else" in the coding question.