= 27d567bc2d48d9f40e9ccc20ea370b15)
ShardPhoenix comments on What are you working on? December 2011 - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (117)
Typical programmers don't remember these things because they're rarely relevant for typical enterprise software development*. If they're specifically important to what you're doing it may make sense to ask about them, but I don't think these kind of questions should be used just as some generalized "programming intelligence test".
* DB normalization is more likely to be relevant than algorithms, but often the database already exists.
I'm only interested in hiring good programmers, rather than typical programmers.
Do you also pay far above average wages? If not, you should be careful of what trade-offs you are making. If you demand above-average performance in some areas (eg algorithms), then you'll on average get below-average performance in other areas (for a fixed wage), at least to the extent that hiring markets are reasonably efficient.
We offer above-average benefits, including one that is very difficult to others to compete with: we write almost entirely free and open source software.
I don't know much about the enterprise world. Which of the following sounds more true to you?
a) Enterprise programming requires fewer skills, or a lower level of skills, than other kinds of programming;
b) Enterprise programming has a separate skill ladder, and a good enterprise programmer has important skills that are unknown to most non-enterprise programmers.
I'd say it's a little of both. Enterprise programming below a fairly senior level doesn't demand much knowledge of algorithms, complexity theory, formal language theory, or most of the rest of academic CS; in a lot of jobs you can quite easily grind along for years without writing so much as a binary search. On the other hand, it does often demand knowledge of unusual tools and language features, enough flexibility to fit your head around arcane and poorly documented architecture, and above all the ability to understand and fix other people's crappy code -- something that academic CS does a very bad job of teaching.
That's a fairly shallow skillset, but it is a broad one.
Is enterprise programming special in this regard? From the description it sounds like game developers, embedded developers etc. also have to face similar problems.
I wouldn't say any of those problems are unique to enterprise development, but enterprise might be the only major branch of software development where dealing with them well is the main skill needed for the job.
There's a bit of both. In favour of a), enterprise programmers are typically less enthusiastic than people from smaller companies, and also generally more narrowly specialized - they may deal with some small area of a larger system, where a startup employee has to be able to handle everything that comes their way.
In favour of b), enterprise systems can have higher demands in terms of robustness (your bank going down is worse than twitter going down), scalability (most small companies haven't taken off in user numbers yet and probably never will), the amount of legacy code that needs to be read and dealt with, and the size and complexity of the existing code base and database(s), and the need for integration between a number of disparate systems managed by different teams.
Yes, but at some point, the knowledge becomes so basic that it should be considered part of basic CS literacy. By analogy, if you are a writer, you should know what similes are even if you aren't using them every day (to say nothing of things like commas).
I personally consider binary search to be in this class of knowledge. It's one of the simplest (if not the simplest) divide-and-conquer algorithms, and if a person doesn't know whether it performs better than linear search and why, that tells me that the person lacks all kinds of other pieces of critical knowledge, as well.
I'm not saying that knowing this stuff is completely unimportant, but rather than using knowledge of algorithms as a rough signal of someone's ability to do their (non-algorithms-related) job, it's better to measure it more directly.
Firstly, how can we do that ? There's no way we can grant each candidate an evaluation period that lasts two or three monhts -- which is what it'd take to measure his performance directly. So, we need some heuristics.
Secondly, "is the candidate CS-literate at all" is just the kind of heuristic that we can use for this. And, IMO knowing about binary search (not necessarily by name, especially if the candidate is not a native English speaker) is a great test for this heuristic. It's pretty much the CS equivalent of "can you form words into sentences".
One measure is to get them to do a small project (a few hours worth as most) of a similar (but simpler) nature to what your company does. That may not be perfect but it's a lot closer than whiteboard algorithms. IIRC research suggests that of all forms of job candidate evaluation, "work samples" such as this have the highest correlation with subsequent performance.
It's true, but that is still a significant investment of time, both on our parts and the applicants'. Most companies implement a two-stage filter: the phone screen, where they weed out a large portion (if not the majority) of the applicants, and the in-person interview, where the applicant might be asked to solve a programming problem like the one you mention. The "what is binary search and how does it work" type of questions are designed for the phone screen phase. IMO that is entirely appropriate, for the reasons I stated above.
The use of in-person whiteboard type questions is not what I mean at all - I mean a small but realistic project for the person to solve at home on their own time with their own tools. Maybe there is a necessity for a faster screen but I'm not convinced that that particular question is close to optimal for most hiring unless programming those kind of algorithms is something you actually do on a regular basis.
Indeed - if a programmer didn't remember what 'binary search' means, I'd still expect them to be able to derive it on the spot from a rough description and then tell me exactly how it fares as compared to linear search.
I'm not so certain about that. I've seen a number of cases where people working on classic 'enterprise' systems struggled for a long time trying to solve problems that could have been neatly resolved using something that is considered 'theory' (like a dynamic programming solution, Lamport's vector clocks, or A* search) and after much trial and error ended up coming up with a ad hoc approach that mostly didn't blow up. If it's purely a web frontend to a database, sure, there isn't that much algorithmic complexity (that hasn't been implemented for you already), but usually there is more to it than that, and having the ability to look at a specific problem and say "You know what this is really an instance of (some already solved problem)" can be very valuable in programming (as in any other field of endeavor).