Joel Spolsky's resume tip for startup applicants(joelonsoftware.com)
joelonsoftware.com
Joel Spolsky's resume tip for startup applicants
http://www.joelonsoftware.com/items/2009/01/02b.html
35 comments
When I left the military--I interviewed, outside my network, looking for a tech lead position. During the interviews I emphasized my leadership skills and experiences. I had come from a research background: won funding on my own, executed my own projects (i.e. wrote code), led development teams, and contributed in many places. I got things done.
Every interview led to an offer+. Yet I was frustrated during the whole process. I asserted tech lead and they pushed back with straight coder.
+ [Note--there was one company where I declined before they could make an offer.]
After reading this post, I can see there was a difference of values causing a misunderstanding. In the military, my technical skills were completely ignored (except at the research lab--I found my way there despite my career field). Leadership ability is what matters (esp for officers). In the civilian world, it seems leadership skills are perceived as fluff.
I won't say one is better than the other. A lot of time what people pass off as leadership accomplishments are just fluff. Its harder to fake a solid technical background.
Eventually I declined every offer and am continuing to work on my startup idea. At the time, the process gave me a bad taste of private sector "jobs". This led to a second wind and more determination to make it.
My failure tolerance moved from "almost out of money--get a job" to "sell everything I own, move in with my parents, try startup again--get a job if accumulating debt".
I haven't hit these extremes yet but find myself willing to go there if necessary.
Every interview led to an offer+. Yet I was frustrated during the whole process. I asserted tech lead and they pushed back with straight coder.
+ [Note--there was one company where I declined before they could make an offer.]
After reading this post, I can see there was a difference of values causing a misunderstanding. In the military, my technical skills were completely ignored (except at the research lab--I found my way there despite my career field). Leadership ability is what matters (esp for officers). In the civilian world, it seems leadership skills are perceived as fluff.
I won't say one is better than the other. A lot of time what people pass off as leadership accomplishments are just fluff. Its harder to fake a solid technical background.
Eventually I declined every offer and am continuing to work on my startup idea. At the time, the process gave me a bad taste of private sector "jobs". This led to a second wind and more determination to make it.
My failure tolerance moved from "almost out of money--get a job" to "sell everything I own, move in with my parents, try startup again--get a job if accumulating debt".
I haven't hit these extremes yet but find myself willing to go there if necessary.
I'm curious - why the bad taste of private sector jobs? Because of the emphasis on technical skills, or something else?
I can sympathize with the "declined all offers and continued to work on startup idea". I did that once and was very tempted to do it a second time. Eventually I figured that since I had a good offer in hand and my ideas didn't seem all that hot, I was better off taking it before I got into dire straits.
I can sympathize with the "declined all offers and continued to work on startup idea". I did that once and was very tempted to do it a second time. Eventually I figured that since I had a good offer in hand and my ideas didn't seem all that hot, I was better off taking it before I got into dire straits.
This didn't really have anything to do with idea and opportunity cost vs. job. It was about cultural differences. I interviewed outside my network (to avoid burning bridges for saying no). At the time--I found the process distasteful as they ignored what I had been conditioned to value most about myself.
I'm thankful I did get offers and was welcomed into these organizations. But I did feel devalued and this is no way to walk into an organization. This further motivated me to keep rocking it on my own.
I'm thankful I did get offers and was welcomed into these organizations. But I did feel devalued and this is no way to walk into an organization. This further motivated me to keep rocking it on my own.
I think this depends on if you're hiring someone new primarily to take the coding pressure of the current team / founders or if you're hiring someone that will grow into leading a group later on and have to wear a lot of hats along the way.
But I don't think Joel is really talking about startups, he's talking about Fog Creek. Fog Creek isn't a startup, it's an established, profitable, small business, and for small businesses, he's right.
But I don't think Joel is really talking about startups, he's talking about Fog Creek. Fog Creek isn't a startup, it's an established, profitable, small business, and for small businesses, he's right.
Back in the last century, I was the CTO at small company and I had to hire marketing and sales vice presidents. I learned pretty quickly to avoid people from large companies like IBM. They never got their hands dirty and wanted a large support staff. I never really interview programmers from large companies, but I suspect the same may be true for them, e.g. they have never configured a server.
"Those VP jobs just don’t exist at startups, and the few VPs they have are the founders and a key early hire or two. Not you."
That's probably not fair. Successful startups are looking for talent, not pedigree - it's a question of whether the candidate can add significant value as a VP.
I think this blog post get's distracted from it's original point - if you're a software developer looking for a software developer position then emphasize software development skills. This applies to small companies and even big companies (like Google). The skill set to be a good developer is consistent no matter what the size of your company.
This doesn't mean that startups don't need business, product, or technical leadership because all the best ones have shown they attracted all these very early.
That's probably not fair. Successful startups are looking for talent, not pedigree - it's a question of whether the candidate can add significant value as a VP.
I think this blog post get's distracted from it's original point - if you're a software developer looking for a software developer position then emphasize software development skills. This applies to small companies and even big companies (like Google). The skill set to be a good developer is consistent no matter what the size of your company.
This doesn't mean that startups don't need business, product, or technical leadership because all the best ones have shown they attracted all these very early.
So, even though I think Spolsky's posts have gone further and further off the rails, this is one that resonated with me:
* first, management jobs in startups do go to the founders and "key hires" (definition: if you have to ask if you are one, you aren't) --- and
* the key predictor for whether someone does well in a startup has, in my experience, been how willing they are to write lots of code, as opposed to just talking about code.
Every bad hiring decision I have ever contributed to has involved allowing myself to be impressed with someone's design/architecture/methodology/"engineering". Conversely, everyone I've ever neg'd because they didn't seem grounded or professional enough has gone on to depants me in the commit logs.
* first, management jobs in startups do go to the founders and "key hires" (definition: if you have to ask if you are one, you aren't) --- and
* the key predictor for whether someone does well in a startup has, in my experience, been how willing they are to write lots of code, as opposed to just talking about code.
Every bad hiring decision I have ever contributed to has involved allowing myself to be impressed with someone's design/architecture/methodology/"engineering". Conversely, everyone I've ever neg'd because they didn't seem grounded or professional enough has gone on to depants me in the commit logs.
Even though I recognize you meant this, I'd edit your key predictor to read,
'the key predictor for whether someone does well in a startup has, in my experience, been how willing they are to write lots of _good_ code"
I've been at several startups where the developers who made the most difference where those who wrote concise, correct, and elegant code that did the job, and nothing more. They didn't get distracted into writing "architectures" when all that was needed was a "tool." Their code was a pleasure to build upon, and people instantly respected their ability to bang it out.
Sometimes less is more.
I've been at several startups where the developers who made the most difference where those who wrote concise, correct, and elegant code that did the job, and nothing more. They didn't get distracted into writing "architectures" when all that was needed was a "tool." Their code was a pleasure to build upon, and people instantly respected their ability to bang it out.
Sometimes less is more.
I actually didn't mean that. I meant: write lots of code.
The bad decisions I made?
(a) thinking that people who could talk and talk and talk about code (shut up I'm not interviewing with you) would write good code
(b) thinking that people who couldn't explain why they'd ever use a red-black tree instead of a hash table would write bad code.
I'm making a case for more-is-more. People who write code (really write, sure, not cut-paste) have work ethics, are really into actually writing code, can easily be trained to bring them up to a median "engineery" standard of code, and get stuff done.
The bad decisions I made?
(a) thinking that people who could talk and talk and talk about code (shut up I'm not interviewing with you) would write good code
(b) thinking that people who couldn't explain why they'd ever use a red-black tree instead of a hash table would write bad code.
I'm making a case for more-is-more. People who write code (really write, sure, not cut-paste) have work ethics, are really into actually writing code, can easily be trained to bring them up to a median "engineery" standard of code, and get stuff done.
I'm not sure where in the tree to place this, so I'll put it at the bottom.
The absolute best indicator I've found for separating quality developers from the 9 to 5 set is finding out what they read.
80% read nothing and admit to it.
15% will make up something like "I read lots of things" or "I read blogs". This is the dangerous group, they're the astronauts.
The last 5% will tell you books they're reading, and more often than not will recommend books to you because they are passionate about what they read.
This simple test has yet to fail me. I'm sure there are great programmers in the 9 to 5 crew, but they aren't the people I want to trust in a pinch. I'll always prefer the guy who is doing this because he loves it over the guy who does it because it's a paycheck.
The absolute best indicator I've found for separating quality developers from the 9 to 5 set is finding out what they read.
80% read nothing and admit to it.
15% will make up something like "I read lots of things" or "I read blogs". This is the dangerous group, they're the astronauts.
The last 5% will tell you books they're reading, and more often than not will recommend books to you because they are passionate about what they read.
This simple test has yet to fail me. I'm sure there are great programmers in the 9 to 5 crew, but they aren't the people I want to trust in a pinch. I'll always prefer the guy who is doing this because he loves it over the guy who does it because it's a paycheck.
I've met a lot of people who can talk very intelligently about code and design, and who have read the canon, and can't put a function in a text editor to save their lives. Obviously, I'm not the only person to notice this: it's the reason for the "fizzbuzz" test.
Well, there are two parts to this. First of all, here (Phoenix) the market is very full of the "I program because it pays the bills" sort, and when we do a posting we review hundreds of candidates (either who directly contact us or are sent to us). Of those hundreds, I'll talk to probably 30 to 50. Of that 30 to 50, maybe 5 or 6 will come in for a face to face. The conversation around software is a great start and it saves me a TON of time when screening candidates by phone. Once there here we can talk code samples or details.
The second part is that it is inevitable that someone will eventually talk a good talk but be unable to actually walk the walk. That's when it's nice that we're in a right to work state. There's no point keeping someone on if they can't do the job you've hired them to do.
Of course, all that being said, this only works because we are a small shop, and the person doing the hiring is the same person who will work with "the new guy" from day one. This makes it loads easier than having to deal with hiring for someone else's department or even company.
The second part is that it is inevitable that someone will eventually talk a good talk but be unable to actually walk the walk. That's when it's nice that we're in a right to work state. There's no point keeping someone on if they can't do the job you've hired them to do.
Of course, all that being said, this only works because we are a small shop, and the person doing the hiring is the same person who will work with "the new guy" from day one. This makes it loads easier than having to deal with hiring for someone else's department or even company.
Conversely, I generally don't read books on software design. I buy books on business, math, graduate level CS, occasionally programming languages (but then usually just to get something I can go through once and quickly) - but not software engineering. It just seems so ... well, put bluntly, the concepts covered in most of those books are pretty boring and part of the conventional wisdom of engineering culture.
The crowd that reads all of the software engineering books seems to be evenly split between good engineers and wankers.
I want to see a portfolio with real code behind it. I want to read your code. If I can't do that, you've probably not convinced me you're a good programmer, no matter how much you can talk the talk.
The crowd that reads all of the software engineering books seems to be evenly split between good engineers and wankers.
I want to see a portfolio with real code behind it. I want to read your code. If I can't do that, you've probably not convinced me you're a good programmer, no matter how much you can talk the talk.
Are we all disqualified because we waste too much time on HN?
Reading looks like a good wheat from chaff question because someone who reads is continually educating him/herself. What gets points for a candidate? Language/framework books, algorithms, professional practices, essays, science fiction?
Reading looks like a good wheat from chaff question because someone who reads is continually educating him/herself. What gets points for a candidate? Language/framework books, algorithms, professional practices, essays, science fiction?
Well, keep in mind that I'm just one guy. I'm not some sort of high powered executive; I'm a hacker that just happens to do hiring.
There is a world of difference between the people of the world who are interested in making themselves better developers and computer scientists and the people who just want to do the minimum necessary for a job.
Other than the obvious requirement of some modicum of honesty on a resume (like... if you're going to say you know Haskell on your resume, you'd better be prepared to tell me what a monad is), reading has been the best indicator of a hire for me than anything else. Of course, just because someone says they read a ton of books doesn't mean they're going to get a job, but I'll only do face to face interviews with people who give a shit about what they do.
We don't do the caliber of stuff that requires deep discussion about sorting a million integers with only 2MB of memory, but we do like to keep our shop as small as is humanly possible in order to keep the quality level as high as we can.
There is a world of difference between the people of the world who are interested in making themselves better developers and computer scientists and the people who just want to do the minimum necessary for a job.
Other than the obvious requirement of some modicum of honesty on a resume (like... if you're going to say you know Haskell on your resume, you'd better be prepared to tell me what a monad is), reading has been the best indicator of a hire for me than anything else. Of course, just because someone says they read a ton of books doesn't mean they're going to get a job, but I'll only do face to face interviews with people who give a shit about what they do.
We don't do the caliber of stuff that requires deep discussion about sorting a million integers with only 2MB of memory, but we do like to keep our shop as small as is humanly possible in order to keep the quality level as high as we can.
(a) It's not really the fact that they talk about code, imho, it's what they say about code. Anyone who's clearly a passionate geek and writes weird and wonderful programs in their spare time is likely to be good.
(b) I don't know how to answer that question, but I could easily look it up if I was doing some work that required this sort of optimisation. Despite that lack of knowledge, I've built two start-ups now.
(b) I don't know how to answer that question, but I could easily look it up if I was doing some work that required this sort of optimisation. Despite that lack of knowledge, I've built two start-ups now.
You use a hash table when you just need lookup. You use a tree when you need sorted order. The only tree worth using is a red-black tree. There, now you don't need to look it up. ;)
If I asked that question in an interview, and that's the answer you gave, I'd probably not hire you (assuming the position was CS-intensive).
There are a number of special-purpose trees which are important in some domains (tries, B-tree, splay tree, ...)
Simple hash implementations also tend to assume that it's cheap to compute a hash on the given key type (not always true) and that you have a rough idea on the bound of items in storage. Hashes far below that level are often also less memory efficient since the hash-table is pre-allocated.
There are a number of special-purpose trees which are important in some domains (tries, B-tree, splay tree, ...)
Simple hash implementations also tend to assume that it's cheap to compute a hash on the given key type (not always true) and that you have a rough idea on the bound of items in storage. Hashes far below that level are often also less memory efficient since the hash-table is pre-allocated.
Oh, bring it on, wheels.
First, take tries and B-trees out of consideration: they aren't generic search trees. Tries have a higher overhead than binary search trees. You use a trie when you need prefix search. You're wanking if you break out a trie otherwise. B-trees are for building external indices. Most people here have never written one.
If you don't agree with either of those, I'll still just say you're cheating by taking what I clearly meant as "binary search tree" and overgeneralizing. But I'll stand by my take on tries and b-trees. Tries are neat; I even wrote a pretty popular blog post about them:
Second, if you need to cache search results, you should cache search results explicitly, with a cache structure. Splay trees suck. They aren't balanced. They have worst case O(n). And they change on read; lookup can invalidate iterators. Lots of people write splay tree code. My theory as to why: splay trees are easy to write.
Finally, and most importantly: nobody in the history of the universe has written and put into production a tree ADT library (at least, not in C/C++) that didn't have catastrophic bugs. A balanced binary tree is something you want to have written once and tested and debugged, and then never touch again. If you're going to get balanced trees right once, what's it going to be? AVL? Actual 2-3 trees? The industry already sorted this out, which is why all the STLs use red-black.
(For the record: I agree with you on hashing being overrated and binary trees being underused, but I'm still more likely to use a generic hash table than a tree for simple lookup).
First, take tries and B-trees out of consideration: they aren't generic search trees. Tries have a higher overhead than binary search trees. You use a trie when you need prefix search. You're wanking if you break out a trie otherwise. B-trees are for building external indices. Most people here have never written one.
If you don't agree with either of those, I'll still just say you're cheating by taking what I clearly meant as "binary search tree" and overgeneralizing. But I'll stand by my take on tries and b-trees. Tries are neat; I even wrote a pretty popular blog post about them:
http://www.matasano.com/log/1009/aguri-coolest-data-structure-youve-never-heard-of/
Second, if you need to cache search results, you should cache search results explicitly, with a cache structure. Splay trees suck. They aren't balanced. They have worst case O(n). And they change on read; lookup can invalidate iterators. Lots of people write splay tree code. My theory as to why: splay trees are easy to write.
Finally, and most importantly: nobody in the history of the universe has written and put into production a tree ADT library (at least, not in C/C++) that didn't have catastrophic bugs. A balanced binary tree is something you want to have written once and tested and debugged, and then never touch again. If you're going to get balanced trees right once, what's it going to be? AVL? Actual 2-3 trees? The industry already sorted this out, which is why all the STLs use red-black.
(For the record: I agree with you on hashing being overrated and binary trees being underused, but I'm still more likely to use a generic hash table than a tree for simple lookup).
Sure, now there's a real answer. :-)
What I was mostly taking offense to was: "The only tree worth using is a red-black tree." There are a number of special trees that are useful in specific domains. Especially in a comment addressed at folks that weren't familiar with tree structures, this seemed important to note.
Other than that there's nothing in there I'd disagree with. On splay trees -- they're not just simple to implement, they're also lightweight. Often useful for the cases where you only half-way care. Tries and B-trees obviously aren't general purpose.
What I was mostly taking offense to was: "The only tree worth using is a red-black tree." There are a number of special trees that are useful in specific domains. Especially in a comment addressed at folks that weren't familiar with tree structures, this seemed important to note.
Other than that there's nothing in there I'd disagree with. On splay trees -- they're not just simple to implement, they're also lightweight. Often useful for the cases where you only half-way care. Tries and B-trees obviously aren't general purpose.
I wouldn't dare show my face in a CS-intensive interview and not know this. Fortunately, that's not my bread and butter at the moment. :-)
Cheers :-)
That's an interesting and intuitive-after-the-fact observation. Thanks.
"They didn't get distracted into writing "architectures" when all that was needed was a "tool.""
I'm fighting this fight right now :( Someone I work with feels the need to add 3 layers of leaky abstractions and a few anti-patterns (visitor patterns without double-dispatch for example) to solve every little problem.
I'm fighting this fight right now :( Someone I work with feels the need to add 3 layers of leaky abstractions and a few anti-patterns (visitor patterns without double-dispatch for example) to solve every little problem.
I'd agree with pretty much all except the below quote.
"... So, even though I think Spolsky's posts have gone further and further off the rails ..."
From the article ...
"... But for startups, everything about your resume has to scream getting your own hands dirty... the only thing we REALLY need is code to be written, and customers to be called on the telephone ..."
reads to me, on-track. One thing I have noticed is JOS has always been skewed towards JOS type businesses (privately owned, bootstrapped software development companies) rather than Startups (fast revenue based technology companies that in the end are either sold or IPO'd). So the stories seem misaligned.
"... So, even though I think Spolsky's posts have gone further and further off the rails ..."
From the article ...
"... But for startups, everything about your resume has to scream getting your own hands dirty... the only thing we REALLY need is code to be written, and customers to be called on the telephone ..."
reads to me, on-track. One thing I have noticed is JOS has always been skewed towards JOS type businesses (privately owned, bootstrapped software development companies) rather than Startups (fast revenue based technology companies that in the end are either sold or IPO'd). So the stories seem misaligned.
The off-the-rails comment is due to the blog's trend away from things like critiquing the Win32 API and talking about software scheduling, and towards Spolsky's theories of company management. It's the Inc. effect.
His writing is also less engaging now than it was 3 years ago; fewer stories about crazy bread machines, more bland prescriptions.
His writing is also less engaging now than it was 3 years ago; fewer stories about crazy bread machines, more bland prescriptions.
This applies to small companies and even big companies (like Google). The skill set to be a good developer is consistent no matter what the size of your company.
I agree only partially. It definitely applies to all sizes of companies, but larger companies seem to care less about it during interviews. This is a large part of why startups work more efficiently on average.
I agree only partially. It definitely applies to all sizes of companies, but larger companies seem to care less about it during interviews. This is a large part of why startups work more efficiently on average.
I dunno about other big companies, but Google seems to care about it a lot.
Agreed, they are an anomaly there in my mind.
"Contributes to OpenBSD file system in spare time"
i'm curious about a windows shop using openbsd as an example for startup cto recruiting
i'm curious about a windows shop using openbsd as an example for startup cto recruiting
I'm not sure if they're a 100% Windows shop.
In any case, if you think of it as a sort of modified version of the "Python paradox" for sysadmin, then it makes sense. You can probably get better Windows admins if you look for people who can do both Windows and OpenBSD (though I suspect not many OpenBSD gurus would be eager to work with Windows).
In any case, if you think of it as a sort of modified version of the "Python paradox" for sysadmin, then it makes sense. You can probably get better Windows admins if you look for people who can do both Windows and OpenBSD (though I suspect not many OpenBSD gurus would be eager to work with Windows).
Single-handedly developed robust 100,000 LOC threadsafe C++ service
I don't know if I love this or hate it.
Does "Single-handedly" mean "jack of all trades" or "doesn't work well with others"?
"Robust" according to whom? Save the commercials for your webpage. Just the facts, ma'am.
"threadsafe C++ service" that did what? for whom? Did anyone even want it? Does anyone even use it? The outcome is as important as the process.
"100,000 LOC" My favorite. I still don't know how I feel about this. Does this mean lots and lots of valuable experience or a newbie who can't write a function but is a whiz at cut and paste? Hell, my javascript generator just cranked out 100,000 LOC while I slept. Onto the resume it goes!
I don't know if I love this or hate it.
Does "Single-handedly" mean "jack of all trades" or "doesn't work well with others"?
"Robust" according to whom? Save the commercials for your webpage. Just the facts, ma'am.
"threadsafe C++ service" that did what? for whom? Did anyone even want it? Does anyone even use it? The outcome is as important as the process.
"100,000 LOC" My favorite. I still don't know how I feel about this. Does this mean lots and lots of valuable experience or a newbie who can't write a function but is a whiz at cut and paste? Hell, my javascript generator just cranked out 100,000 LOC while I slept. Onto the resume it goes!
> "Robust" according to whom? Save the commercials for your webpage. Just the facts, ma'am.
I would argue that a resume is a personal, (hopefully) factual commercial. The interview is there to put any claims you've made into perspective.
I would argue that a resume is a personal, (hopefully) factual commercial. The interview is there to put any claims you've made into perspective.
Well, since it's a resume, it sounds like you know exactly how to interview her. That's an hour's worth of questions right there.
Your comment reminds me of Steve McConnell's "beware a guy in a room" chapter in "Code Complete", though.
Your comment reminds me of Steve McConnell's "beware a guy in a room" chapter in "Code Complete", though.
http://steve-yegge.blogspot.com/2007/09/ten-tips-for-slightl...
'Resume screeners keep an eye out for non-weasel words, aka Productivity Words. These are words that you can't weasel out of when someone asks you about them. The best are synonyms of "got real stuff done", including "coded", "implemented", "developed", "delivered", and "launched".
It's perfectly OK to use "designed", as long as you follow it up with a Productivity Word. If you design something without implementing it, then it's just a synonym for "Proposed". If you prefer to design things that other people ultimately implement, then you're quite possibly outstanding material for a company full of kneebiters. But a real tech company like Amazon or eBay or Microsoft or whoever isn't going to hire you, because they can find plenty of people who can both design things and implement them.'