Hacker News Reader

Comment by piranha | Hacker News Reader

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

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.

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.

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.

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.

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.

Ask them to write an essay.

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

I agree with you to an extent but I guess it comes down to how you judge a good essay. I wouldn't expect a literary masterpiece but if the candidate can convey their intended message in a clear, unambiguous and concise manner, I'd take that as a fairly good indicator of decent organisational skills.

Talk about the organizational struggles at his previous company.

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.

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.

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.

Well, it's probably not equivalent, but it's a good hint (aka : you can't express clearly something that isn't well structured in your mind). Plus, it also let me test verbal skills themselves, which is extremely important as soon as you're working in a team.

Another way of looking at it is that "finding the right word" often means find the good "fit" between abstract concepts shapes or feelings, and a construct of known language items. That's precisely what you're doing as a developer.

Ok, so it's based on reasoning full of assumptions that may be wrong, not on empirical evidence. For me, it's quite hard to think aloud when solving some problem, because it forces me to translate what goes in my mind into words, which is quite distracting, I cannot fully immerse into the problem.

I suppose you're more a "tool" developper than a "business process automation" one. In the latter, you very often have to talk through the problem with your customer.

But it is an assumption indeed... Only it is based on my personnal experience.

As for the comment mentionning google developpers, the ones i see are good enough verbally to talk about their jobs at google i/o.

That you're "quite a good programmer" might be a myth too :P

I don't think so, because I've developed some quite popular software and done well in programming contests.

Programming contests show nothing about your organizational skills, which is what companies should be looking for.

See https://news.ycombinator.com/item?id=5911235

Mathematicians perform very well on programming contests, but they are usually terrible software engineers.

Anyways, I was just kidding :)

Google is full of engineers that did well on programming contests, they even have their own contest, and i don't think they are all terrible software engineers.

http://qz.com/96206/google-admits-those-infamous-brainteaser...

I don't think the problems in algorithmics contests are in the category of brainteasers. As far as i know Google still relies heavily on knowledge of algorithms and problem solving capability to hire their engineers.

Fair point. I still think there are two types of programmers: problem solvers and system architects.

The former (e.g. a data scientist) will be good solving a problem but bad building a big architecture. The latter, the other way around.

I guess the question is which kind of programmer you are and which skills to look for.

I think there are probably more than just two types of programmers.

I think that mathematicians don't do well in software development because they simply have much less experience than other devs :) I think that what's most important in software engneering is experience, motivation, intelligence, common sense and good taste (aesthetics).

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.

Don't worry, my recruitment interview also include algorithm and data structure quizz.

But when i do, it's in front of computer, and i'm sitting right next to the candidate while he taps, to see his line of reasoning. Then, if he's in trouble, we talk about it, i give him hints, and see if he understand what i'm saying and fix the code.

Reply on news.ycombinator.com