Organizational Skills Beat Algorithmic Wizardry

http://prog21.dadgum.com/177.html

by sbierwagen • 13 years ago

193 67 13 years ago

prog21.dadgum.com

piranha• 13 years ago

The biggest problem here is that I don't see a clear way how do you assess organizational skills of a candidate?

seanmcq• 13 years ago

Ask them to write an essay.

RivieraKid5• 13 years ago

From my experience, ability to write good essays doesn't have especially good correlation with programming ability.

sitkack• 13 years ago

Have them refactor a 200 line program and then discuss with them why they did what they did.

Or given the same codebase have them add a feature and some form of testing.

There are many ways to simulate in a highly compressed manner the typical tasks of a programmer without resorting to algorithmic puzzles.

vog• 13 years ago

As a side note, these kinds of tasks are also pretty common in at my university in the practical computer science courses.

Often, you aren't supposed to write a big thing at once, but you are given some partially working code, with some incomplete set of test cases. You then have to finish the implementation, and you are also encouraged to add more test cases.

I found it especially interesting that the test cases were incomplete on purpose - you are supposed to understand and solve the given task, not just to blindly write some code that happens to pass a given set of tests.

shin_lao• 13 years ago

Try to solve with them a problem you currently have. If the candidate is adding value, it's a good sign.

It doesn't mean you shouldn't assess the candidate's technical skills.

mtdewcmu2• 13 years ago

I'd like that kind of interview. When I get asked to solve a problem that's totally artificial, the type of question that's designed for interviews and programming competitions, it throws me off track. I feel like I'm trying to read the interviewer's mind to know what criteria I'm being evaluated on. With real-world problems, there's no mind-reading necessary. It's easy to imagine what type of solution would get the job done. Plus, hearing a real problem would actually be interesting, and perhaps break some of the tension from being scrutinized.

llemiengre• 13 years ago

Talk about the organizational struggles at his previous company.

bsaul5• 13 years ago

that's something i closely relate to verbal expression. the first thing you need to structure are your thoughts. so i simply ask them to describe to me a system they've previously built. if the language is clear, then so are the thoughts and so most likely will the code be.

RivieraKid5• 13 years ago

Are you really sure that this isn't a myth? I often have problem expressing myself, finding the right words, but I am quite a good programmer.

ArekDymalski• 13 years ago

I'm afraid that assessment of programming skills based on verbal expression makes you vulnerable to many errors and biases. Sure, you'll quickly filter out incompetent candidates but along with them you'll most likely flush out some really good ones, because programming and communication are two different competences and they doesn't have to be correlated. At least not positively ;) Plus, it's generally bad idea to assess two competences on one observed behavior. You're "saving time" on the expense of clarity and precision of judgement.

davidcuddeback• 13 years ago

I ask candidates a high-level design problem. So far it appears to be an effective way to identify engineers who can decompose a problem into smaller, digestable subproblems.

carlob• 13 years ago

The company I work for holds a summer school every year. And while I understand this does not apply to most tech jobs applications, I can assure you that after three weeks working together with the students we get a pretty good idea of who can organize their thoughts and divide problems in subproblems. So maybe the key would be to test technical skills for a while longer than a half hour quiz.

louischatriot2• 13 years ago

I agree with the OP but I still think the power of algorithms and datastructures should not be understated, as they power most of the software everyone (including "organizational" coders) use, e.g. databases.

For example, I'm writing a pure JS database (https://github.com/louischatriot/nedb), and using indexing I was able to speed it up hundreds fold. That's clearly not something I could have done without knowing about self-balancing binary search trees.

I also think that knowing algorithms does make you a better programmer, even if you don't use them on a daily basis.

bsaul5• 13 years ago

There really are two classes of programmer : the one that build "tools" for other developers, and the ones that build end-user software.

The first ones needs to be fluent in every types of algorithms and data structure. The other type will have the task of modeling real world processes into a computer (which means "concept organization translation" rather than pure algorithms).

The first ones deal with primitive types, and very rarely more than that. The second ones need to model all the entities of a real life problem and their complex interactions (complex in the sense of combinations and organization).

That's why I think there will always be a gap between those two developers. They are dealing with very different kind of tasks, yet their jobs titles are the same.

contingencies• 13 years ago

This distinction is artificial. I know I do both every day.

louischatriot2• 13 years ago

It's true there is little overlap between these two categories. But I found that the low-level work I do (such as the db mentioned above) helps me understand better and be faster at high-level, "real world" work (such as my startup's website and API tldr.io).

xradionut• 13 years ago

"There really are two classes of programmer : the one that build "tools" for other developers, and the ones that build end-user software."

Actual the second group is occasionally saying, "WTF was the first group thinking?" after spending hours trying to get the tools to work for the real world. (Try spending a few hours/days writing wrappers for PKI software with shitty APIs...)

kyllo• 13 years ago

This Yegge article from 2007 is relevant:

http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...

"If you don't know how compilers work, then you don't know how computers work."

Becoming better at the first class of programming that you describe, will also make you better at the second class.

And a lot of times, "modeling the world" is a pitfall of object-oriented programming, and something that you don't really want to do. But it's very tempting if you've only ever programmed in Java.

tbrownaw• 13 years ago

There really are two classes of programmer : the one that build "tools" for other developers, and the ones that build end-user software.

Where exactly is the distinction? How would you classify Monodevelop, or git/svn, or the C++ STL, or SQLite, or Emacs, or the Unix shell utilities, or Photoshop?

hkmurakami• 13 years ago

I also think that knowing algorithms does make you a better programmer, even if you don't use them on a daily basis.

IMO this helps at the most very basic level because it lets us consider "hey, I wonder if there's an algorithm out there that'd help me with this" and gives you the impetus you need to go looking.

Kind of a "you know what you don't know" situation of sorts.

fatman• 13 years ago

I just had my ego smacked in another algorithmic interview with a large, fancy software company a few days ago (took too long to get too rough an answer). I like to think I'm not stupid - my current day to day developing gig is heavy on thinking & mathematics and I do OK with it - it's more than just "organization". It just seems like if I spent a few hours a week entering TopCoder competitions, in 6 months I could ace these things - but what end result skill is the interviewer really selecting for?

victorhn3• 13 years ago

It just seems like if I spent a few hours a week entering TopCoder competitions, in 6 months I could ace these things

Then why don't you just do it? And you forget once for all about these algorithmic interviews and show your other more job-relevant skills.

arbuge• 13 years ago

Precisely so. I consider myself to be a pretty good coder because I'm good at keeping track of many things going on at once (I used to be a chip designer in a prior life), but I'm 100% sure I'd flunk the puzzles that companies interviewing for coders throw out in their interviews.

Good to see a realization by Google that those puzzles aren't all that useful: http://qz.com/96206/google-admits-those-infamous-brainteaser...

Google might be one company where algorithmic wizardry might be expected to be more important than most, so that's saying something...

goyalpulkit• 13 years ago

I think that the only reason the algorithmic interviews are still so common is because of the difficulty in analyzing the real skills of the candidate. I have worked with guys really good at algorithms, but it is no way related to how good they are at building complex projects.

joshuaellinger2• 13 years ago

When I interview, I use this question is a reverse fashion.

I asks how would you implement a b-tree index (for example). The right answer is -- "I wouldn't. DB vendors put years into getting this right.".

If you want this sort of gimmick to stop, when you are in an interview, you should just have the balls to ask how it is relevant to your potential job. Their response will give you a good idea if you really want to work there.

As an interviewer, you litmus-tests on questions like this is that they should be (a) answerable by all your existing employees and (b) reveal the thought process of the applicant. If they don't do that, find some better questions.

drewcoo• 13 years ago

That may work for you and I don't mean this as personal criticism, but hostile interview techniques like that are enough for me to not accept a position if it's offered. Likewise, if I were interviewing someone and the candidate asked hostile questions to see if I "had balls" that would be a no hire. Just my opinion, of course. YMMV.

joshuaellinger2• 13 years ago

I think you misread my post slightly.

I consider the trick questions from Google interviewers to be hostile. The only reason not to call them on it in the interview is that you want the job and think that you can get it by being nice rather than honest.

"having balls" != "hostile". "having balls" == "telling the truth"

The point I was trying to make in an interviewer is that you really want to find out what someone is going to do when you ask them to do something that they think is stupid. Because you will eventually.

As an interviewee, you really want to find out what happens if you have to challenge the management.

You can be both honest and nice. It is just harder than trying to answer the question directly.

xntrk• 13 years ago

I think the best interview I ever had I was sat down in front of a computer and asked to complete two different classes and make the tests pass. This tests ability to write code under a deadline and shows that the candidate knows how to use some programming tools editor, testing framework etc.

mathattack• 13 years ago

Very true. So much of the day to day job is everything except solving the very hard algorithms. But it does help to have that person around.

A separate thread (https://news.ycombinator.com/item?id=5911017) discusses Google giving up on some of the insanity. In the original NY Times (http://mobile.nytimes.com/2013/06/20/business/in-head-huntin...) article, Question 3 covers doing away with brainteasers.

lifeisstillgood• 13 years ago

Absolutely.

There are times when a new algorithm (or actually a new data structure) will revolutionise the system. But taking advantage of that is an effort of reorganisaing the code.

bjhoops12• 13 years ago

In my experience, some of the smartest, best guys at algorithms and puzzles make some of the worst coders. No one can understand their code, it's brittle and their work eventually gets replaced by code written by somehow with half their IQ but a decent sense of organization.

thewarrior• 13 years ago

This seems very unlikely.

sp332• 13 years ago

It's true, if you're lucky enough to have someone who can write organized code that replaces the original clever junk. https://news.ycombinator.com/item?id=1221756 (ignore the top comment)

scott_s• 13 years ago

The absolute best people I know at "algorithms" are either CS theoreticians or straight-up mathematicians. They can program, perhaps even better than average coder, but they don't have quite the same whole-system view as a systems person or professional software engineer.

If you're solving problems that require algorithmic ingenuity, you absolutely want these people. And if you can pair them with a good engineer who can integrate their algorithm into a non-trivial system, that's when the magic happens.

nahname2• 13 years ago

We are all mortals at the end of the day. You can choose to study algorithms or you can choose to study clean code. Few have the time to do both. I've noticed that it isn't just algorithms though. People that are really good at reasoning in code (maybe from studying algorithms so much) have a much higher tolerance to code complexity and produce much worse code as a result.

That said, I've worked with a few people who got both sides very well and they were a treasure to work with.

makmanalp• 13 years ago

You don't have to "study" clean code. You just have to overcome the tendency to write code in an overly smartypants way. Coincidentally, in my experience, there seems to be a correlation between people who love to study algorithms and people who love doing this. :)

I can reduce that 20 line function into one line of maps / filters / reduces too, but I know I shouldn't if it's going to take 20 minutes for someone else (or me 6 months later) to get through it.

Basically, don't aim to reduce Kolmogorov complexity, aim to increase readability. These two aren't completely mutually exclusive anyway.

pacala• 13 years ago

"organizational skills". aka politics :/

benjamincburns2• 13 years ago

I think my company does it right.

After a phone screen we ask candidates to complete two problems at home at their leisure. One is a simple filesystem traversal problem where we ask you to build in some runtime extensibility, and the other is a binary space partitioning problem (2D bounding box query) with a very difficult performance requirement (low 10's of ms max for 1M records).

All of our interviews are conducted by more senior software developers. Before we ever interview you we read through your code. These aren't huge tasks, but they're enough to show whether or not you use good organization. Then comes the interview...

We do use the first problem as sort of a litmus test. We figure that runtime instantiation of an arbitrary class which implements a known interface is a little on the edge of the realm of what you'll be doing day-to-day, but it's close enough that if given the problem to take home you should know how to Google the right runtime API calls to make it happen. And we're pretty flexible. If you misunderstood the extensibility requirement and when asked how you'd make it "runtime extensible" you can spit out something marginally close to "MyInterface blarg = (MyInterface)Class.forName(pluginFQDN).newInstance()," or even "I'd Google 'instantiate class by name in Java'" you're still doing more or less fine. You're doing very well if you can tell me how to add the plugin to your tool in such a way that it doesn't leak implementation details to the user either through its use or its installation procedure.

We absolutely do not use the second problem in anything close to a pass/fail manner. If you get the optimal solution, awesome. If not, no problem. Either way, let's talk about it. Let's work together. Let's have an in depth technical discussion about the various pros and cons of different techniques to solving this problem. If I say something which in the context of our discussion is by common-sense reasoning obviously wrong, will you call me out on it (preferably politely)? If I say something that you don't understand will you just nod and smile, or will you say "wait, what?" Or the single biggest problem I see surprisingly often - are you capable of in some way communicating a semi-complex idea to another person who is "skilled in the art," either verbally, on the whiteboard, or otherwise? These are the things we're evaluating on the second problem, not if you can pull a kd/quad/r/other-tree out of your ass.

raghava• 13 years ago

Asking candidates to complete problems at their leisure is a very good idea. But recruiters can bungle up on this too.

For something that's purely procedural in nature, asking for a complete and proper object oriented solution would not be such a good idea. Likewise, forcing the candidate to use pure procedural method for something that definitely needs OOP.

benjamincburns2• 13 years ago

Fortunately we have good recruiters. Once they've identified a candidate they play purely a support role in the technical side of the evaluation process.

I'm not sure I follow that last statement 100%, but if you "go against the grain" all we'd care about is that you're able to reasonably articulate the "why" behind your decisions.

avoutthere• 13 years ago

I've always thought that companies like Google miss out on many talented, hard-working, passionate developers simply because those developers can't tackle the ridiculous programming questions in interviews. Then these same companies turn around and complain that there aren't enough qualified candidates.

mech4bg• 13 years ago

There's a difference between asking an interviewee to implement an obscure data structure and knowing your basic algorithms and knowing how much complexity is added by using certain data structures. i.e. I'd expect any coder to understand what the performance trade offs are between a hash table and a binary search tree, and why you'd use one over the other. This stuff matters in day to day backend code whenever you're dealing with a non-trivial dataset.

However writing off in-depth knowledge of algorithms as esoteric or a waste of time is disingenuous in my opinion. I've seen lots of coders write over-engineered, far too complex code, but they were usually not great at algorithms.

Studying up for a Google interview was a transforming experience for me as a programmer - I realized how much I was missing and how little I'd let myself forget the basics since college. It made me a much better coder and made it much easier for me to learn new languages and systems. Understanding CS fundamentals gives you a great platform to work off, and understanding the complex issues makes you a better coder for the day to day stuff.

Organizational Skills Beat Algorithmic Wizardry

Related Stories