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

[bad_user]

How can anybody have knowledge about compression algorithms without knowing what BFS is? This is like claiming to be a mathematician and not knowing what rational and irrational numbers are.

You speak about the problem domain, but the primary problem domain we are facing first is programming. And without a shared vocabulary, you can talk with other software developers, but you aren't going to be very efficient in that communication. So going back to the problem domain, as software developers we are supposed to master whatever problem domain we are facing, in order to efficiently communicate with the business side in their own domain-specific language. How are we supposed to do that if we haven't even bothered to learn our own domain-specific language?

But it goes deeper than that. Many software developers these days rely too much on libraries, without knowing how they work. And this hurts them a lot.

This is all about standing on the shoulders of giants. And it all starts from the most basic data-structures and algorithms. BFS is right up there with the characteristics of a List or a Map. It's common knowledge that everybody should know. And this common knowledge is half of "Introduction to Algorithms" by Cormen et al. So instead of reading another fluffy piece on Agile methodologies or on soft skills like the "Pragmatic Programmer", or other such bullshit, maybe people should read this one instead.

One recent problem we had was one of scaling out our micro-service-based infrastructure. And I've heard from colleagues wild ideas like "oh, lets introduce an external queue, like Kafka". DevOps for some reason think external queues are the solution to all problems. Yeah, great, but this isn't a freaking webpage reading from a database, we've got singletons, as in producers of truth that need strong consistency in their decision-making because we aren't that smart and you're just moving the problem around, because locks don't freaking scale, no matter how smart your queue is. Or "we'll just add Akka Cluster or Finagle or whathaveyou, should take care of it". Dude, yeah, we've got singletons, which means we need to do sharding and have a protocol for failure detection, so maybe we should talk about that first.

This is just a recent example. Developers are so eager to jump to the latest fads and the latest cool things, without thinking for a second if those solutions would work, only because they can't imagine how these tools are even implemented. And this isn't something that a superficial Google search can fix, because the unknown keeps piling up, the more complex the system is, until the shit hits the fan and you throw your hands in the air and bring in external consultants to fix it. And if you think the UI is spared from all of these problems, think again. I've seen dozens of Javascript-enabled interfaces with performance issues, only because of the "thundering herd" problem happening due to sloppy event handling. How many UI folks understand how Facebook's React works? Not that many.

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