I just googled it. Oh, I know what it is now.
If you haven't been exposed to it, it's just jargon. That's the point. You are testing for jargon rather than ability.
It is the distinction between saying 'implement FizzBuzz' and going silent, and actually explaining what it is. As an interviewer it is easy to forget that whilst you may have asked a question 20 times, this may be the candidate's first encounter with your terminology.
Steelmanning as applied to interviews, basically.
In other words, it's OK if you don't have a formal education in computer science, but when you don't have it, you need to make up for it by learning on your own, because this is basic stuff that high-school kids are learning. And it's even worse when people do have that education on their resume and don't know BFS, because it means they cheated on those courses.
And what would you prefer for a hiring test? Straight IQ tests? A requirement for public, open-source contributions? Or are you speaking of querying databases and fading out divs? I think we can all agree that neither is entirely fair.
And keep in mind that for all the pain involved in the interview process, the only alternative is optimistic hiring for a test period, except that doesn't work because it causes distress to everybody involved if it doesn't work out. This is why many companies now prefer internships, because thus they are dealing with young people that don't have big expectations.
The article might go over the top a bit with self-pity, but personally I just see it as suboptimal behaviour.
http://danluu.com/programmer-moneyball/ - Dan Luu explains better than I can.
I think fundamentally the idea of paying developer X 40K and developer Y 80K (because developer Y has been twice as effective in the past) is broken, because it negates the impact of environment.
If you pay someone 150K GBP in London they can live next door to the office, have TaskRabbit like services perform all household tasks for them, and spend their time exercising and reading 24/7. They will kill it.
Pay them 30K, and regardless of pedigree, they're going to struggle.
Somewhere in there is a balance and I argue it's far less to do with certification and more the circumstances of life which as an employer you have huge discretion to influence.
Basically, it's about steelmanning. Why is someone bad? Is it that they're inherently genetically dysfunctional? Or is it that they haven't been coached well or have a difficult environment?
Given good faith, most of the developers I know have the ability to be amazing. I include myself in that (am I that good? dunno, impostor syndrome innit). But they are stifled by needless nonsense. Management, open office, low pay, commute, stress, basically. Kill the stress and you get your '10x engineer'. Keep the stress and your '10x engineer' turns into a chocolate mousse.
From my point of view, an interview really isn't an exchange between equals, but a meetup where two parties meet, state their demands and evaluate each other. It works in both directions of course.
Again, are we speaking of giving out straight IQ tests? I think there's plenty of people that would be against that, plenty of people that consider IQ tests to be fundamentally flawed. And if not IQ tests, how do you measure problem solving and learning ability?
Maybe you give the interviewee something to do, like an algorithm or a piece of code to develop on the spot, right? But maybe your personal expertise doesn't match with what the interviewer wants or needs. And the interviewer has to give you some problem to solve in some way.
I remember that at a coding interview I was given the problem of programming a Lego Mindstorms device to detect obstacles and do stuff. But then the problem was really about reading a document on the C subset used to program the device, along with the several couple of functions needed to control the motion and read the sensors. Was that measuring learning ability in any way? Of course, if you think that the skill of reading a technical document with precise instructions is so rare. But that wasn't real world problem solving.
So how can you test real world problem solving? Do you give candidates a homework? Ah, but then you run into another problem: the good candidates, the ones that might actually solve your homework, are rarely interested in spending their time on such things, because most good people already have jobs and a life and things to do and you can consider yourself lucky if you get their attention for a couple of hours.
In that light, I don't think it's that unfair to give problems to solve that rely on basic algorithms and data structures, especially for companies where the problems solved are much harder than that.
BFS and DFS are the bread and butter of tree/graph problems and every software engineer is expected to encounter them at least once in their life. What if you want to debug a complex data structure or just a tree and want to print out its contents in order? Is it really such a weird thing? It's akin to asking to do a for loop through a list to print the elements, except slightly more complex (but certainly something that should be achievable by intuition rather than by memory).
I have experienced (on both sides of the table) situations in which it just hasn't happened. 'Can you do X?' 'What is X?' 'Never mind, let's move on'.
Depending on what their listed requirements were, I think it's reasonable to expect you to know standard terminology, though I wouldn't count it against you if you asked to be reminded of the details for one or two things.
But we know that most of the time this isn't true. <1% of software developers write sorting algorithms on the job, and even fewer of those actually need to know which one is Bubble and which Quick and which Heap without reference.
If I'm a multinational company, I want my accountant to know what transfer pricing is. If I'm a self employed joiner, I don't.
Problem solving tests are good. Memorization tests are terrible. We have search engines for that.
I don't consider asking a developer about basic data structures and their properties as terrible. This is foundational knowledge that is useful for nearly every programming job. Knowing about lists, hash tables, trees, etc and their operations or tradeoffs is extremely important.
Similarly, having a developer that can reason about the runtime and memory complexity of the code they write is important as well.
These are the "lingua franca" things that I was speaking about in my previous post. Even if particular developers think that the above things aren't useful to them, I would argue that they are probably wrong and just don't know how or why they are.
