Hacker News Reader

Comment by jamesaguilar | Hacker News Reader

One thing I have seen repeatedly in interviews for engineering positions of all levels is people who have not gone back and reviewed the basic algorithms they learned in second year. I know coding questions as posed in interviews are not the best measure of job performance, but they are also one of the few we have that is guaranteed to be sourced from the candidate in question. To perform well at these sorts of questions, you should be familiar with basic algorithms and techniques. It's a common language that you and the interviewer can speak. Not knowing that language is gimping yourself unnecessarily. Don't know what a graph or a queue is? You're gonna have a bad time.

Take a few hours to study up before interviewing at the big engineering-focused companies.

View on HN

Basic data structures and algorithms are worth noting, but most of these formulaic interviews seem too focus on an academic base rather than an experience base -- probably good for someone who is only a few years experience.

I've turned down a couple of companies that take the formulaic approach. In most cases, I've not been looking. So, if you reach out to me, there is something in my background that is interesting, and I expect contact to be based around that.

As a counter, when I interview a candidate, I mostly avoid typical questions and try and ask questions intersecting the candidate background and what we are up to. If that is a stretch, I prefer focusing in on a passion or project and talking about the design/implementation challenges there.

Google and Facebook seem to have similar approaches, and because of the number of resumes they get have set up a formulaic system. It probably gets a certain level of quality, but probably also puts artificial caps at the high end.

If you agree that these types of questions are not a good measure of job performance, why encourage this line of questioning? Wouldn't it be better for the industry as a whole to discover better ways to determine future job performance?

I don't set interviewing policy at my company, and anyway I'm unfamiliar with any technique that provides better results. I suppose finding it is a direction of research that would be interesting, but I have a full time job just being an engineer.

My comment is only meant as practical advice to candidates. It is not normative.

knowing these are not going to guarantee good performance. But not knowing them is a clear indication of incompetence. A programmer who doesn't know basic algorithms and data structure is a bad programmer.

Obviously more knowledge is good knowledge. And perhaps the bar for being a good programmer involves being able to

1) Implement a red black tree on a white board

I would argue, though, if that's the bar, there are probably other bars that are a bit lower that at least some of the algorithm triumphalists would fail, such as to

2) Throw up a basic and secure Wordpress site on an Amazon EC2 instance

3) You're running into an issue where you're getting an error message about running out of file descriptors. Tell me what's the issue here and what you'd do about it

4) write a basic, safe script that makes backups of each file in a given directory and its subdirectories

5) tell me what the fuck is the clearfix?

Now, if intermediate algorithms is something that people should be able to do, surely you'd agree 2-5 are even lower bars to meet (since they're things that virtually all of those "bad programmers" are able to do). By the same token, though, it's absolutely the case that many hires at the BigCos actually wouldn't be able to respond to 2-5.

I wouldn't say that those people shouldn't have been hired; after all, people learn! But if algorithms are actually part of the everyday job, someone could also learn them, no?

To the extent that you're testing for raw intelligence--which is the most important aspect of any of these types of jobs--algorithms are a good ruler. But to equate the measurer with the measure is somewhat foolish, because it's a means to an end, not the end itself. If you can use other probes of raw intelligence, those function just as well as being able to vomit up algorithms and data structures that, as people point out, any person who spends a month or so studying can get a solid grasp on and then never need again.

If someone doesn't know how to approach an algorithms problem why not get them to show you how they would google around and puts the pieces together.

If they have no idea, they are likely going to google and follow the wrong advice. If they have an idea but have forgotten the specifics they will know where to go and which advice to take.

The utility of google rises exponentially with your pre-exsisting knowledge (at the low end of existing knowledge). If you know nothing about algorithms, then you can still look up and implement, say, a red-black tree. However, if you run into a problem that is simmilar, but not identical to, the problem that a red-black tree solves, you will have a difficult time adapting the red-black tree to your problem.

If, however, you have a strong basis in algorithms, but still no pre-existing knowledge on the red-black tree specifically, then you will be in a better posistion to adapt or optimise it for your particular use case. Not to mention have a better intuition in what to search for in the first place, or who to structure the rest of you code to play nice with an algorithm that is a good fit.

Agreed. Even though some interview coding questions are a bit absurd, having a good grasp of basic algorithms and data structures shows that you at least care a little bit about _how_ things work.

Reply on news.ycombinator.com