Hacker News Reader

Comment by ricksharp | Hacker News Reader

This sounds like an inspection of whether the person has had a class in basic algorithms rather than if they have ever coded anything in real life.

In school I played with sorting algorithms, in business if I ever found a developer manually writing a sorting algorithm, I would consider them inept (unless there were very specific reasons to do so).

If someone didn’t know how to sort a list using the built in or standard library of whatever language they are using, I would know very quickly that they have almost no experience writing anything useful.

View on HN

If you're given a blank slate and asked to sort a list without using a library without any gotchas, complexity requirements, space requirements, expectations that the code is completely free of small bugs etc.; and you can't do that after some thinking even to a basic degree, then you're just not a good programmer.

As a programmer, your task is to find algorithms to solve problems. Sure, sorting numbers is a solved problem and in real life you should use a library. But you will not find a library for each problem you encounter, and sorting is a very simple problem to solve compared to anything you'll find in real life.

I agree, but how is applying pre-learned algorithms significantly better than using pre-build libraries? Both is about using an existing solution, instead of coming up with it on your own. The real approach would be to ask candidates to solve a problem that doesn't easily fit into any popular category, so that they have to come up with an original approach - but that is first hard to come up with, and 2nd it would require investing extra time on both sides, which usually neither candidates nor interviewer can afford.

Yes, that's a good point, and in our interviews we do try to take a slightly less well-known problem, at least one that doesn't have a dozen well-known named algorithms.

Still, even using a pre-learned algorithm demonstrates some level of confort with algorithms in general, and can be used as a stepping stone during the interview to shift the problem slightly to see how they adapt the algorithm.

For example, if a candidate is clearly taking their time and essentially working out the algorithm themselves, and succeeding, that demonstrates the skill and we can move to other problems. If the candidate just breezes through and finishes in 2 minutes, then we can change the problem ad-hoc to try to get them off the beaten track a bit (say, if they wrote quicksort, maybe ask about making it stable, or sorting even numbers differently from odd numbers, off the top of my head).

My point was that if testing for a skillset, using something that favors those who have toyed with a specific algorithm is the same as asking trivia questions.

Trivia does not provide evidence of skill, it demonstrates prior knowledge.

It would be better to introduce a unique situation that would place everyone at the same starting point.

If the expectation of the interviewer is to see if they know quicksort, then I fully agree with you. If the sorting problem is simply used as a (rather uninspired, granted) stepping stone to checking that the candidate has basic algorithm-finding skills, then I think it can serve this purpose (though less well-known but still relatively simple problems would be better). I gave an example in another thread as well, but in principle I would change the problem up a bit if the candidate is obviously producing a well-known algorithm; whereas, if the candidate is working out the solution themselves, I would be happy with that and move to other topics.

Even so, knowing very widely talked about programming trivia is still a signal for interest in the art. I'm not sure that sorting algorithms are a good example of what I'm thinking, but I always award extra mental points to candidates who seem knowledgeable about the field (e.g. they know the general consensus on manual memory management vs garbage collection). Still, I wouldn't consider these sorts of things dealbreakers by any stretch of the imagination.

In fact now that I think about it, it might be a good test to see if they are passionate enough to be a great problem solver:

When was the last time you wrote a sorting algorithm?

Acceptable answers:

- You mean sorting a list? - In school - Why would I write a sorting algorithm? - Never - (Glazing eyes and other body language that indicates frustration)

Red Flags:

- Anything that indicates they think writing a sorting algorithm is a perfectly logical thing to do during the course of software development.

(Note: The problem is sorting may seem like a well-understood problem, but it’s actually not. Only a person who studied the algorithms in school as an assignment would feel comfortable with that code.)

Acceptable answer: it depends on what I'm sorting. Is it a primitive like char strings, numbers, or a more complex data type? Could it have null values and type mismatches, am I using a strongly typed language? Does it need to be cleaned first?

I think the ability to come up with relevant and important questions to ask about the task given is more crucial than whether they can solve it. You can look up answers to questions from hundreds of good sources, but you need to be able to generate the right questions that need to be answered first.

> you need to be able to generate the right questions

Completely agree with this statement.

I would add that having the proper vocabulary is an important part of generating the right questions.

Reply on news.ycombinator.com