[stegosaurus]

I don't know what BFS is.

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.

[bad_user]

Trees and graphs are fundamental to computer science and there are only two ways to traverse them. I don't know what kids are doing these days, but I learned this because of my high-school curricula.

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.

[stegosaurus]

I think this makes sense if you consider an interview as extending a hand to a poor, down-trodden vagrant, rather than an exchange amongst equals.

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.

[bad_user]

Are you sure you replied to the right comment? :-)

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.

[stegosaurus]

Yes, I am.

>> From my point of view, an interview really isn't an exchange between equals

If you design it that way, sure. It doesn't have to be like that.

The whole principle here is that there exists a growing portion of developers who can't be bothered with interview ping pong.

If you don't want them, great! Everyone wins. You don't need to convince us, we won't be working at your company anyway.

[bad_user]

So first of all, I'm not hiring :-P I see your point though and I don't agree.

First of all, the point of the interview isn't to determine whether somebody is bad, or improperly couched. Surely interviewers would love being able to do that, but it's not possible to do it in a couple of hours.

During the interview all you get to do is to apply a noise filter to get rid of the incredibly bad ones. Because without that filter you can get people that are a very bad fit and that can cost you the project and the morale of your existing employees. It's incredibly taxing to fire somebody. Every time it happened to see a colleague being fired, internal discussions, personal attacks and bad feelings happened internally, every single time and not just at one company. And then in big corporations, because of the risks involved in firing people, you get an even worse effect - you see them "promoted".

And with a noise filter you can naturally have many, many false negatives, as in people that are in fact good, but won't pass the test and interviewers are willing to have that risk, instead of risking false positives.

Of course, from what you're saying, I think you believe everybody can be great. Well, yeah, I think everybody can be great at something useful, but not everybody can be great at something specific. We software developers are too idealistic at times. I don't see surgeons going around telling other people that everybody can be a surgeon. That would be a preposterous thing to say.

On the other hand I do think that if companies want good people, they should invest in education.

> The whole principle here is that there exists a growing portion of developers who can't be bothered with interview ping pong.

I can agree with that. I'm not into interviewing myself. I'm not into switching jobs that often either. I can't be bothered with that because I've got satisfying things to work on already. Capitalism and the free market cuts both ways, right?

[ts330]

You're right about learning. Everyone should be doing this ALL THE TIME. Problem solving and learning ability are what you should be measuring and then deciding if their past experience justifies the position/starting rate. This is far more likely to serve you well than testing the finer points of some algo/tech that is simply a building block of a solution to a far bigger set of business/technical challenges.

[bad_user]

But you cannot measure problem solving and learning ability without relying on a set of common knowledge to use in your tests.

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.

[dimino]

I'v;e been programming for 8 years and have never ran into a BFS problem. Why do I need to know this to be an effective programmer again?

[Morgawr]

I've been programming for ~8 years as well and have implemented BFS multiple times, especially in occasions where I have to travel nested data structures and want to print them in a specific order.

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

[dimino]

I guess I should rephrase. I've been programming for ~8 years and I've never been presented with a problem that insisted I know what BFS was explicitly.

It is intuitive, which even further pushes the question "Why do I need to know this to be an effective programmer"?

[Morgawr]

You don't need to know BFS, you need to show that you can come up with a BFS implementation if you need to do so. You can always say "wait, remind me again, which one was BFS?" and the interviewer can certainly tell you at least what the conditions are. Maybe he might think a bit less of you (although I personally wouldn't) because BFS is a really really common name in the jargon of a programmer, but still it's better than simply blanking out and then angrily claiming that it's unfair to ask BFS.

A similar question could be "Can you print in order all the elements of a given tree/graph?", would you find that more fair compared to straight out using the word "BFS/Breadth First Search"?

[dimino]

Yeah, I think presenting the actual problem rather than a jargon test is a better way of determining a programmer's competency, but even then I'd prefer to ask questions specific to the problem domain, like if you're a streaming company ask about compression algorithms.

My favorite questions are when companies ask actual problems they're having and try to get the interviewee to suggest solutions and/or implementations.

[taneq]

Because it's not intuitive to some people. Some people just don't 'get' it. The assumption is that such people are probably also not good software developers.

[jpatokal]

No, it's not a test of whether you know it, it's a test of whether you can implement it. If the candidate doesn't know/recall what BFS is, it's trivial to demonstrate the basic idea on a whiteboard, and it's the candidate's job to convert the idea into code. (Which, at the end of day, is pretty much what the vast majority of coding is about.)

[ams6110]

It's still not realistic. People don't code on whiteboards. You code (today) with all the resources of the internet at your fingertips, and if you need to invert a binary tree you will use a well-tested implementation from a standard library.

[TheCoelacanth]

It's not supposed to realistic. It's supposed to be a test of programming ability that fits into an hour interview with time left over for talking about other things. Real world projects last months or years. You can't fit that into an hour, so you have to make do with something that can.

[LamaOfRuin]

Which is why they're not asking you to do it in an actual job. It's a proxy problem that is easy to communicate so you're not spending the entire interview explaining the problem. Arguably, fleshing out a spec would also be a valuable test, but not the same one.

[kuschku]

People often do code on Whiteboards – but not actual code, but diagrams, plans, etc.

[catnaroek]

Sometimes actual code too. For instance, if I'm designing an optimization pass for a compiler, I'll write toy IR programs and show how the optimization pass will rewrite them. And I'll do it on a whiteboard.

[kuschku]

Yup. But the thing I meant is that you illustrate things, not actually code your application code.

[catnaroek]

I know for damn sure that, if I'm implementing something algorithmically tricky (not BFS, though), I first sketch the details on a whiteboard or a piece of paper.

[stegosaurus]

I edited my post. Yes, this makes sense, if the interviewer describes what they're actually after.

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

[LamaOfRuin]

To a degree this is true, but there is also significant value in having (and retaining) that broad base of knowledge that a good CS program or some systematic personal studies will get you. Most of the time you're not going to get a "implement this algorithm" you're going to get a "solve this problem we have" and you need to know the standard tools that are available to get you to a first approximation solution.

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.

[robbiemitchell]

Why would an interviewer assume a front-end dev has a CS degree or has invested personal time in studying algorithms rather than other (probably more) relevant topics, such as various frameworks?

[LamaOfRuin]

That depends. Mostly because front end job listings still often list a CS degree as a requirement. Also, I think it's great when people enjoy working on the front end since I don't particularly, but I still want to work with people that aren't hyper specialized.

[robbiemitchell]

I think you might be underestimating the breadth of front-end skills required to properly develop, test, deploy, deliver, monitor, analyze, and optimize front-end applications. Including the myriad third-party integrations that other teams need, from CS to marketing.

[LamaOfRuin]

Well, I wouldn't have considered half of those things as part of "front end development" work, but it pretty much drives my point. I'm a firm believer in the idea that you'll be more effective at all of those things if you have a general baseline knowledge of CS, so that if you need to you can (relatively quickly) understand how and why all of your tools work the way they do.

[drakenot]

Most specialized fields have jargon. It is the common language between the practitioners of that field. At what point should a person be expected to know some basic ideas and the words associated with them for the field they work in?

[stegosaurus]

Well, if the knowledge of a particular thing is useful for that job, then yes, that's reasonable.

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.

[drakenot]

I think memorization tests of the sort that ask what FunctionX you should use from LibraryY for a particular situation are terrible.

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.

[stegosaurus]

Sure. I know what a list, a hash table, a tree are because I looked it up whenever I saw someone mention it, and eventually internalized it.

But before that, I'd used them for 10-15 years without knowing the name because it doesn't matter. Take a hash table. Python calls it a dict. C++ calls it an (unordered) map. Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.

Actually in usage I type {} in Python and it is what it is.

I'm not arguing that these things aren't useful at all.

I'm arguing that the distinction between the CS-ified person that has spent the effort to learn what the words mean to pass interviews is not substantially more knowledgeable or useful than the version of that person that will have to find it out in the future. It's marginal.

Basically it feels like a sort of 'table manners' test. You've put the fork on the wrong side of the plate, so you can't eat dinner with us today, you scoundrel.

Don't take this to mean that I think that computer science is useless. Far, far from it. It is simply that I think that relying on jargon is testing whether someone genuinely has a CS degree (or equivalent without certification). It's not testing whether someone is a good programmer.

If that's what you want, just ask for it. Let's not waste each other's time and money.

The anger here exists because people want good faith interviewing, and instead they get "bloody hell the last 20 people were crap I can't be bothered any more" interviewing.

[stuxnet79]

>> Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words.

Actually, they are more than just words. Try not to conflate the abstract data structure itself with the language-specific implementations which can vary quite significantly. Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far. It's better to frame your argument like this ... "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for" which is quite reasonable as most devs CS-minted or otherwise will agree with you. & also while it might not be useful to rote memorize every single CS concept, it's sensible to at least have a passing familiarity. Why? Well, not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.

[stegosaurus]

>> Also your flippant, dismissive attitude on quite important CS concepts wouldn't take you far.

Please try to avoid this. We can discuss without resorting to attacks.

>> "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for"

That's what most people are arguing for I think, so I agree with you there.

>> not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.

By doing this you are throwing away developers that have made their respective companies millions in revenue. It's not hypothetical. One day, a non-CS trained developer will come across a tree and use it. And then they'll learn.

[GFK_of_xmaspast]

> C++ calls it an (unordered) map.

Hey, whoa, stop right here. std::map and std::unordered_map are not at all the same thing, and if you're going to be using them in a manner beyond "trivial" it's important to know the difference between them.

[dunkelheit]

That's not what happened to the OP. He was asked to code up a solution to maze searching problem. The statement of this problem is understandable by a 5-year old kid.