A sad, sad, sad, sad story from the trenches: http://whereisbob.wordpress.com/
This falls right in line with the one of my all-time favorites: http://dir.salon.com/story/tech/feature/2004/02/23/no_support/index.html
The sad reality is that a lot of classic vices of white-collar office environment is seeping into the industry that was rather immune to them in the past.
The good news is that there are still plenty of places where this does not happen. Finding them are not that hard - pick any top couple of products in any software area, and the companies building them are probably very, very good. After all, it's hard to build a great product without attracting - and keeping - great people. And great people do not keep very well in terrible environments.
But how do you get a job in a good environment? The easiest way is to be really good at the aspects of the job that are usually tested on the interview.
Most good companies look for essentially the same qualifications in an employee. Joel Spolsky summarises these as "Smart and gets things done" (http://www.amazon.com/Smart-Gets-Things-Done-Technical/dp/1590598385).
In reality, it is impossible to test these qualifications during the interview, so most interviewers look for indirect evidence, thus equating "smarts" with "great computer science skills", and "gets things done" with "demonstrable passion for technology".
The way computer science skills are tested in the interview are by having an interviewee solve an algorithmic problem, with possible segues into computer architecture (is your solution memory or CPU bound?).
Unlike the true intelligence, the skill of solving algorithmic problem can be developed. First, having a genuine interest in these matters helps a lot (if you don't normally care, a short refresher right before the interview produces only very limited results, but it is still better than nothing). There is a couple of really good books, of course, as well.
First is the venerable "Introduction to Algorithms" by Cormen, Leiserson, Rivest, and Stein (AKA "The CLR book"): http://www.amazon.com/Introduction-Algorithms-Thomas-H-Cormen/dp/0262032937.
Second is "Computer Architecture: A Quantitative Approach" by Hennessy and Patterson http://www.amazon.com/Computer-Architecture-Fourth-Quantitative-Approach/dp/0123704901.
It is important to point out that buying these books just to put them on the shelf 'till you have more time will not help - I guarantee it! You have to actually read them, and even do a few exercises :-).
A quick test - if you can implement quick- and merge- sorts, BFS and DFS walks, a basic hash table, delete an element from the binary tree, and analyze respective memory performance of heap- vs. quick- sort - all without consulting a book - you cover both Google and Microsoft's definition of developers' "intelligence" - and this means that you will be selecting the place where you will work next, and not the other way around.
Of course, most modern workplaces do not naturally maintain the algorithmic skills - people rely on Java/STL to do the right thing and do not go into details on how exactly they do it. Whatever is learned at school gets eventually forgotten, and as a result the probability to get a hire vote at most places where I worked before actually diminishes with "experience".
What about the "passion for technology" part of the puzzle? A couple of things help here.
Of course, being really passionate about something technology-related - tracking the progress in this area closely, reading about new developments, and ability to coherently discuss it in depth. When a developer tells me that (s)he thinks that XML is important, I ask "Why?" and then sit back and listen. If the answer does not elevate beyond the standard marketing blabber, it's not a good sign.
Having home projects beyond work and school is also important. This is the true sign of passion for the technology. I often ask people when was they last time they did something software developmentish outside work or school.
The unfortunate part of this "advice" is that it's essentially the same as "lose weight by eating less food" - it requires fundamental life changes. You get beneficial effects but at great cost, which only gets greater as the time goes and you settle - deeper and deeper - in your comfort zone. But no comfort zone is forever - the manager changes and... see the link at the beginning of the article.
But on the positive note, if you have already made the life changes, or have always led the healthy life :-) I have a job for you! Check out what we're doing here: http://1-800-magic.blogspot.com/2008/07/looking-for-great-devs.html and send me your resume!
Monday, August 11, 2008
Subscribe to:
Post Comments (Atom)
4 comments:
Hello Sergey,
First of all, thank you for your blog . It's really very intresting. I'm a Java developer and I have noticed that you don't like the Java language. I have a lot of respect for your professional success and I would like to ask you: "Do you think, that making a great software is preferable with C/C++?" Maybe, I'll change Java on C++... Best regards, Genya.
Actually, I LOVE Java. I used it at Google (and I even had a readability in Java there), and in my personal projects. I wrote the Gutenberg proxy in Java, for example. There are certain projects for which it is absolutely invaluable. And it is certainly possible to write great software in it.
But I think it is very hard to become a great developer (including Java developer) if one ONLY knows Java (or C#, or Python - other languages I like, - or VB. Or STL). To be a great developer one must understand computer architecture and algorithms, and Java hides both too well.
For this reason I hate the fact that most universities adopted Java as THE language of their curriculum, and I always suggest that new grads find a job they can learn and use C/C++.
I also have a policy in my own teams that new graduates don't get to use STL until they've thoroughly learned everything about pointers, and nobody gets to use STL unless they know well how STL primitives are implemented inside.
Thank you, Sergey, for your explanation. I think I will start learning C and C++. And may be one day we will work together :)
The way computer science skills are tested in the interview are by having an interviewee solve an algorithmic problem, with possible segues into computer architecture (is your solution memory or CPU bound?).
The way this is done will either turn folks off, or not. It has to be done right. I do too choose my companies. The ones where the interviewers trot out a half dozen "puzzle problems" from their neat little books of artificial puzzle problems are the ones I choose not to work at. I'm too busy solving real problems to worry about the best solution to some artificial problem that will never been seen in real life. You ask me to solve a real problem, I'll whip you out a solution ASAP off the top of my head and it'll be a workable solution. You give me BS at the interview stage, I go elsewhere, because experience shows that it'll be BS after that too.
Yeah, I'm a bit ornery these days. Worked too often for pointy-haired bosses with no clue or, worse yet, Google-style "non-management". Luckily I don't have to put up with that nonsense to make a good living doing what I do (architecting and designing cool software, whipping out proof-of-concept prototypes ASAP, and managing the implementation teams that turn the prototypes into real products).
Does this disqualify me from working at, say, Google or Microsoft? Hard to say. Google and Microsoft keep calling me, and I keep telling them that I'm not interested. Engineers choose too. And I choose not to put up with BS beyond the normal day-to-day stuff that comes with being part of a team of developers. Works for me. Doesn't work for a fresh newbie right out of college, but that's a different tale.
Post a Comment