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