Hacker News Reader

Comment by ventana | Hacker News Reader

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.

View on HN

> 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

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

> 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.

> [...] to explain to a developer why their code with 5 nested loops is probably not a good idea.

Funny anecdote about that:

I had written code with (in a nutshell) more than five nested loops because that's how password cracking works: try all the options. Someone in the presentation audience came from compsci education and asked if that isn't bad for performance. I really struggled to explain this basic logic of... like, yeah, it takes a while but what magic do you think exists to not do the password cracking algorithm (that indeed takes an indeterminate amount of time) yet get the password back from the hash (which was the objective of our research project)!

We got a good grade but I'm not sure if I was able to clear up this compsci student's confusion :p. They learned a theory but didn't know where to apply it

> 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 [...]

Instead of making interviews a repeat of the exams that their diploma certifies, I'd suggest asking after the knowledge that you need/prefer them to have. E.g. we had a vacancy related to large-volume log data processing, so we gave people a challenge to answer simple questions about a large dataset which doesn't fit in RAM (e.g. "which city in the dataset had the most events"). The candidates, all in the last year or having finished compsci university, solved it in O(n) memory at best (some solutions were worse) instead of the O(1) solution¹ that seems obvious to me. They would, instead, split the dataset in a biased way and provide answers for the first slice only, often (not always) acknowledging it's a partial or biased solution and needs to be repeated for each slice, but not making the logical connection that if one can add up the results for the parts then maybe they could also just structure the code that way and process in a streaming manner for each record that comes in

I found it very insightful about candidates' ability to work with real-world data; that their algorithms class' theoretical knowledge doesn't translate if they haven't taught themselves that

Programming is commonly self-taught. I basically dropped out of high school to do a vocational school instead since I had already learned the basics, and there I'm not sure we covered algorithms for dealing with tree structures, I just know about that from the internet. In projects I've done for fun or for other jobs, it quickly becomes obvious which solutions perform and which ones don't. Looking up an existing algorithm to use is a lot quicker than knowing math theories and needing to learn programming from scratch still, so long as you know that performance in hot loops or UI threads is a thing to be aware of

¹ for(event in events){cities[event.city]++;} asort(cities);, excluding some wrapper code to e.g. associate event coordinates with a list of cities that we provided

Several times I have implemented topological sorts and parsers as part of routine work in very ordinary tech jobs. I think it is absolutely incorrect to say that these tasks are tantamount to implementing your own crypto. They are not things you do every day, but they are basic informatics and to be honest if a developer told me that they could never conceive of implementing them in their job I would be inclined to regard them as someone who was working without a full toolbox, so to speak.

That might just be my world in which the acronym DFS has a single well defined meaning; but of course the interview question never says "implement DFS", it will be a kind-of-real-life coding exercise that can be solved by a graph traversal, like checking if some nested structure has a loop.

Dunno, there are very few universal knowledge checks that would work across the entire industry, but my two absolute baseline standards for anyone who would be coding are 1) knows how to version control, and 2) can comfortably traverse a graph.

To be fair, knowing the acronym "DFS" itself is not necessary - it reflects badly on the industry itself (not necessarily the candidate) that we're so bad at even agreeing what our shared jargon is.

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.

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)

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.

> 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.

> 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.

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.

>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.

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/

[2]: return True

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

2: https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_majority_v...

> 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.

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!

Reply on news.ycombinator.com