The Startup Resume(justinkan.com)
justinkan.com
The Startup Resume
http://justinkan.com/the-startup-resume
11 comments
Has it worked? Which startup are you with now? I see from your blog you are interviewing with Google (not a startup anymore), but still not bad. Are you still open to finding the right fit with a startup? Are you "startup friendly" (appropriate expectations of work hours, pay, and equity)? I find the latter to be the biggest hangup in folks that we're looking to add to our team. They like the tech challenge, but can't really grok the startup work environment.
I'm not sure why but the phrase "Are you 'startup friendly' (appropriate expectations of work hours, pay, and equity)?" just rubs me the wrong way.
Joining a startup is a two way street. If you are considering joining one, you should do as much diligence (or even more) than they are doing on you. I, personally, love startups -- the energy, the diversity of problems, the ability to learn and grow. But, I've also been bitten by all the glitz (early in my career during bubble one) as well as people that thing "it's a startup" is an excuse to demand above and beyond efforts on a regular basis.
In general, you are going to work more at a startup, you may or may not get paid less, and you will need to weigh the whole work/life balance thing, most likely. You might be asked to make a tradeoff between equity and salary.
The tangibles you have control over (salary, time you are willing to commit, etc) are the ones you need to weigh. But, you also need to understand as much as you can about the expectations of those in management.
Poor planning, for instance, should never be excuse by "this is a startup" -- I don't mean pivoting, I don't mean tweaking as new information comes along, I mean those people that can't make up their mind on what constitutes the expected deliverable by a particular date.
Joining a startup is a two way street. If you are considering joining one, you should do as much diligence (or even more) than they are doing on you. I, personally, love startups -- the energy, the diversity of problems, the ability to learn and grow. But, I've also been bitten by all the glitz (early in my career during bubble one) as well as people that thing "it's a startup" is an excuse to demand above and beyond efforts on a regular basis.
In general, you are going to work more at a startup, you may or may not get paid less, and you will need to weigh the whole work/life balance thing, most likely. You might be asked to make a tradeoff between equity and salary.
The tangibles you have control over (salary, time you are willing to commit, etc) are the ones you need to weigh. But, you also need to understand as much as you can about the expectations of those in management.
Poor planning, for instance, should never be excuse by "this is a startup" -- I don't mean pivoting, I don't mean tweaking as new information comes along, I mean those people that can't make up their mind on what constitutes the expected deliverable by a particular date.
I think you have it reverse -- I'm not in search to join a startup, I'm in search of others to join me. Basically, what I'm finding is that many of the candidates I'm interviewing have entirely the wrong expectations for joining a startup... at least in my geographic region (mid-Atlantic US). I'm sure it's different in your locale. But around these parts, many candidates for the startup positions simply aren't "startup friendly".
I'm currently focusing on graduating by the end of the year. But I do work with startups on a freelancing basis (10-ish hours a week).
Which startup I'm "with" changes every couple of months.
As for the Google situation, they came to me and I decided to go along with it. To see how far I get and have some external benchmark of my programming prowess. If I do end up getting an offer, I'll then decide whether I want to work with them. Before that I ask every engineer I get to talk with about their working environment to gauge whether Google is the type of company that has retained enough of a startup spirit for me to feel productive there.
Which startup I'm "with" changes every couple of months.
As for the Google situation, they came to me and I decided to go along with it. To see how far I get and have some external benchmark of my programming prowess. If I do end up getting an offer, I'll then decide whether I want to work with them. Before that I ask every engineer I get to talk with about their working environment to gauge whether Google is the type of company that has retained enough of a startup spirit for me to feel productive there.
Am I correct in interpreting this post as saying that generalists don't get hired at startups, and that you should optimize your resume to look like a specialist? That seems pretty counter-intuitive, since at an early stage startup, employees end up wearing many hats.
Generalist programmers get hired all the time at startups; as someone else mentioned, requirements are always changing and it often doesn't make sense to specialize immediately. At Justin.tv, we hired a ton of generalists before we ever hired any specialists.
What I meant in the post was that if you are going to be programming then you need to demonstrate that you are a good programmer, hopefully with some specific abilities or experience that demonstrates you'll be able to work on the actual problems of the company. We hire people all the time that don't have massive experience in web development, but they demonstrate skill in some related way (e.g. maybe they talk about how they've used Python for scripting in their phd work). Anyways, the point is that even a generalist has specific projects that demonstrate they are a good programmer, and this goes beyond just listing a ton of languages they've dabbled in. Good programmers are generally very good at specific stuff they have experience in, and aren't necessarily good yet but can become good in other areas.
What I meant in the post was that if you are going to be programming then you need to demonstrate that you are a good programmer, hopefully with some specific abilities or experience that demonstrates you'll be able to work on the actual problems of the company. We hire people all the time that don't have massive experience in web development, but they demonstrate skill in some related way (e.g. maybe they talk about how they've used Python for scripting in their phd work). Anyways, the point is that even a generalist has specific projects that demonstrate they are a good programmer, and this goes beyond just listing a ton of languages they've dabbled in. Good programmers are generally very good at specific stuff they have experience in, and aren't necessarily good yet but can become good in other areas.
I read your post and this comment as arguing for resumes to focus on achievements ("this awesome thing is my fault") rather than tasks ("I did thing X as a means to an end while in role Y"). Is that a fair summary?
If so, I think you're off the mark a bit when you say this applies only to startups; I think this applies when you are applying to specific roles at a company, regardless of the company's size. I don't work at a startup at all, but resumes with lists of papers with no direct relevance where the candidate is one of 10 co-authors, academic honors, TA positions that are irrelevant to the job at hand, lots of description about a former team's job rather than what the candidate did, etc. make my brain glaze over. I have to spend more time looking for the core nuggets of achievement buried within, and that's generally not time I have. It's not necessarily a killer for someone's interview process, but it's certainly not fun and drains my time.
Meanwhile, people I encounter outside of the normal resume-submission process who simply point out something really cool they've done? If it's something really awesome, they get recruited, no real resume required.
If so, I think you're off the mark a bit when you say this applies only to startups; I think this applies when you are applying to specific roles at a company, regardless of the company's size. I don't work at a startup at all, but resumes with lists of papers with no direct relevance where the candidate is one of 10 co-authors, academic honors, TA positions that are irrelevant to the job at hand, lots of description about a former team's job rather than what the candidate did, etc. make my brain glaze over. I have to spend more time looking for the core nuggets of achievement buried within, and that's generally not time I have. It's not necessarily a killer for someone's interview process, but it's certainly not fun and drains my time.
Meanwhile, people I encounter outside of the normal resume-submission process who simply point out something really cool they've done? If it's something really awesome, they get recruited, no real resume required.
[deleted]
I spend quite a bit of time reviewing resumes, interviewing and hiring engineers, and I am not looking for specialists. If a candidate has an in depth knowledge of a particular subject, that is awesome, but completely optional. The requirements are: Strong problem solving ability, a love for writing high quality code, and the ability to learn fast and work independently.
One thing I do agree with in the original post is that the resume is a really bad way for me to learn about candidates, and most candidates resumes are much too long. A blog, open source contributions or stackoverflow answers are much more helpful and really make candidate stand out from the crowd for me.
Within the last couple months we also started requiring all candidates to do a coding challenge before applying (http://thumbtack.com/challenges), and it has been an epiphany for us. My current process is to look at the challenge submission without seeing anything else about the candidate, grade it, at which point I'll then look at the resume to see how many years of experience (I have higher expectations for the solution the more years of experience the candidate has). For borderline submissions I'll dig deeper into the resume, but 90% of the decision comes from the challenge submission and maybe 10% from everything else.
One thing I do agree with in the original post is that the resume is a really bad way for me to learn about candidates, and most candidates resumes are much too long. A blog, open source contributions or stackoverflow answers are much more helpful and really make candidate stand out from the crowd for me.
Within the last couple months we also started requiring all candidates to do a coding challenge before applying (http://thumbtack.com/challenges), and it has been an epiphany for us. My current process is to look at the challenge submission without seeing anything else about the candidate, grade it, at which point I'll then look at the resume to see how many years of experience (I have higher expectations for the solution the more years of experience the candidate has). For borderline submissions I'll dig deeper into the resume, but 90% of the decision comes from the challenge submission and maybe 10% from everything else.
OK. Problem #1 "Your solution should be in Javascript and CSS"
Smart people don't play monkey games. If you want a monkey at the very least be honest about it. If you want a rockstar you better have a damn good reason for them to come to your company rather than just start their own. Playing monkey games to see if your possible new team rockstar is good at reading minds through osmosis is the first reason they won't even look at you. Better stick to brogrammers, however I doubt you even see many of them.
Smart people don't play monkey games. If you want a monkey at the very least be honest about it. If you want a rockstar you better have a damn good reason for them to come to your company rather than just start their own. Playing monkey games to see if your possible new team rockstar is good at reading minds through osmosis is the first reason they won't even look at you. Better stick to brogrammers, however I doubt you even see many of them.
I would say we have a lot of evidence that great candidates enjoyed doing our challenges, but certainly it isn't for everybody. You are free to not do the challenges.
As for your secondary point about the quality of our team, I encourage you to read our engineering blog (http://www.thumbtack.com/engineering/) and look at some of our open source contributions (https://github.com/thumbtack). I think you will find more than enough material there to see what our engineering team is all about.
As for your secondary point about the quality of our team, I encourage you to read our engineering blog (http://www.thumbtack.com/engineering/) and look at some of our open source contributions (https://github.com/thumbtack). I think you will find more than enough material there to see what our engineering team is all about.
In addition to other answers, there's a linguistic element as well. Generalist language is generic, overused, hence relatively meaningless and uninteresting, and won't get you very far. Concrete, specific, original, and niche terms are much better at catching attention, sticking in people's minds, piquing interest.
Aside from knowing this intuitively, witnessing it in everyday life (and on HN), I've seen internal adsense A/B testing demonstrating it.
Another tip I've recently learned from watching a friend make this mistake is, if you have the opportunity to see a writing sample of the people you're applying to, even just email - mirror their writing style. Among the SV crowd that tends to be:
1. Short paragraphs, no walls of text.
2. Direct, Concise. Every sentence should be as simple as possible, but no simpler.
3. Your best skills only. Ref #2.
4. Your best work examples only. Don't elaborate, just a sentence.
5. What the article says.
6. What Swizec says above (http://news.ycombinator.com/item?id=3907717)
Aside from knowing this intuitively, witnessing it in everyday life (and on HN), I've seen internal adsense A/B testing demonstrating it.
Another tip I've recently learned from watching a friend make this mistake is, if you have the opportunity to see a writing sample of the people you're applying to, even just email - mirror their writing style. Among the SV crowd that tends to be:
1. Short paragraphs, no walls of text.
2. Direct, Concise. Every sentence should be as simple as possible, but no simpler.
3. Your best skills only. Ref #2.
4. Your best work examples only. Don't elaborate, just a sentence.
5. What the article says.
6. What Swizec says above (http://news.ycombinator.com/item?id=3907717)
> Overall, startups are looking for employees who are exceptional in the one key thing that they will be doing
Key - in my opinion - being the operative word. In other words, you may be doing many things, but how good you are at those things aren't as relevant as how good you are at this key thing.
Key - in my opinion - being the operative word. In other words, you may be doing many things, but how good you are at those things aren't as relevant as how good you are at this key thing.
Much like the idea of the "T" shaped employee from Valve's employee handbook. Broad set of capabilities with depth in a specialty.
The generalist is the CTO, if they're bothering to hire somebody, they're looking for something in particular you're strong at that they need even if you'll be wearing multiple hats.
Things change very fast in startups. As your problem space emerges, you will be changing technology also to fit that picture. Strict specialists are rarely good in that kind of environment.
If you're doing a standard web app stuff that doesn't push any boundaries of science, you probably won't need a specialist until after you've hired four or five engineers anyways.
I didn't say strict specialists, I said someone who had something they were strong at but still able to adapt.
I'm a CTO hiring this sort of person right now.
I'm a CTO hiring this sort of person right now.
Sounds like an excellent in-comment writing exercise.
Zack's Resume (ala Justin Kan):
If I could, I would spend all day rolling around in data. I have fond memories of spending a weekend graphing the comments of top posters on Hacker News[0]. In the next week or two, I will be opening a pull request for d3.js for an easy way to do fisheye distortions on geographic maps[1]. I got a beating over winter break trying to convert the R project into JavaScript via emscripten[2].
Hire me so I can make your data beautiful[3].
[0]https://github.com/zmaril/HN-Visual-Comments
[1]http://mbostock.github.com/d3/
[2]https://github.com/zmaril/emscripten/tree/herecomesdrtran
[3]https://www.odesk.com/users/~~80bea7ba2750c34b (Shameless misdirecting plug)
Zack's Resume (ala Justin Kan):
If I could, I would spend all day rolling around in data. I have fond memories of spending a weekend graphing the comments of top posters on Hacker News[0]. In the next week or two, I will be opening a pull request for d3.js for an easy way to do fisheye distortions on geographic maps[1]. I got a beating over winter break trying to convert the R project into JavaScript via emscripten[2].
Hire me so I can make your data beautiful[3].
[0]https://github.com/zmaril/HN-Visual-Comments
[1]http://mbostock.github.com/d3/
[2]https://github.com/zmaril/emscripten/tree/herecomesdrtran
[3]https://www.odesk.com/users/~~80bea7ba2750c34b (Shameless misdirecting plug)
That's a cover letter.
You're not helping an overworked/exasperated resume reader by writing prose in your resume, IMO (for what it's worth...). Resume should be bulletized chronological work history with most relevant/interesting stuff getting a sentence or two of explanation.
Leave long-form prose to the cover letter. And that is a pretty good cover letter, zackzackzack.
You're not helping an overworked/exasperated resume reader by writing prose in your resume, IMO (for what it's worth...). Resume should be bulletized chronological work history with most relevant/interesting stuff getting a sentence or two of explanation.
Leave long-form prose to the cover letter. And that is a pretty good cover letter, zackzackzack.
Sometimes I'd much rather have a little bit of detail on an accomplishment or point than a couple sentences of a bullet point. If I end up confused because of someone sticking to this rule, I get annoyed.
Yeah but it's so hard to tell when it's appropriate. It's subjective. I think everyone just has to find what works for them and go with it, hopefully achievements speak for themselves (with the help of a good cover letter).
Your cover letter (i.e. email) is far more important. Four short (1-2 sentences) paragraphs:
1. why you are choosing *them*
2. your basic competence for the job
3. what special talent you bring, that makes you outstanding
4. why you'll get along with them, be a good fit sociallyAs the CTO hiring my first developers, I'm looking for people who will integrate with my company and my tech stack with the least amount of friction possible. This means that (a) you're a full-stack RoR/JS programmer, (b) you're smart as hell, and (c) you're not annoying.
The only thing that's really going to come through on a resume is (a), and I might be able to glean some of (b) and (c) from your cover-letter. It's rare enough to see full-stack RoR programmers on the job hunt though, so (a) alone is enough to get a call from me. Your resume almost doesn't matter, as long as it doesn't violate (c).
For me at least, just put together a generic resume and write a frank, friendly email/cover-letter. Even though I'll probably call you regardless of the cover-letter, a good one may give me enough confidence to skip right to on on-site (or coffee).
The only thing that's really going to come through on a resume is (a), and I might be able to glean some of (b) and (c) from your cover-letter. It's rare enough to see full-stack RoR programmers on the job hunt though, so (a) alone is enough to get a call from me. Your resume almost doesn't matter, as long as it doesn't violate (c).
For me at least, just put together a generic resume and write a frank, friendly email/cover-letter. Even though I'll probably call you regardless of the cover-letter, a good one may give me enough confidence to skip right to on on-site (or coffee).
Programmers: you should be founding not applying. Don't waste your time on other people's ideas. Bag groceries if you have to. As an employee you will probably get nothing or some small token amount if the company is sold.
What happens to the resumes that don't make the cut? I know that I'm always in search of some great additions to our team and while the resumes might not be a fit for you, they might be a great fit for me, and YCombinator is an amazing magnet / funnel that attracts a relatively higher quality of candidate, regardless of whether or not they made the cut. Around these parts, it's hard to convince tech talent to join a startup at all, their skills notwithstanding.
I know that resumes are probably shared with a reasonable expectation of privacy, but perhaps you can let it be known that there are other, non-YC startups that might be interested in these resources if you would be willing to share and float a few other boats with those that weren't a good fit.
Just a thought.
I know that resumes are probably shared with a reasonable expectation of privacy, but perhaps you can let it be known that there are other, non-YC startups that might be interested in these resources if you would be willing to share and float a few other boats with those that weren't a good fit.
Just a thought.
The principle applies elsewhere, too. He's right - tailor your resume.
Also, make sure what you rock at is big and clear and up-front and featured. Because you hope your resume is being read by somebody who doesn't just read resumes all day.
Then put keyword soup at the bottom for recruiters, if you need to.
Also, make sure what you rock at is big and clear and up-front and featured. Because you hope your resume is being read by somebody who doesn't just read resumes all day.
Then put keyword soup at the bottom for recruiters, if you need to.
I've been reading Land the Tech Job You Love [1] recently, and he says the same thing about putting "keyword soup" at the bottom. But he also recommends naming the section something like "Buzzwords" so that human readers know to skip that section. "Oh, this is obviously to satisfy the automated resume screeners." I'm not so keen on the idea, but probably because I usually apply to companies that are too small to use the automated resume screeners.
[1] http://pragprog.com/book/algh/land-the-tech-job-you-love
[1] http://pragprog.com/book/algh/land-the-tech-job-you-love
It's not for the human readers to skip the section so much as to simply acknowledge that you're doing it for the machines.
If I'm a human and I'm reading a skills section that includes PostgreSQL, PL/pgSQL, SQL and RDBMS, I might think "Aw, she's padding her resume, those are all related." But if I slap a "Buzzwords" section on there, now it's clear why it's there.
And I do think that's important. Say you've got an HR drone who is told to look for candidates who know SQL. He might see a resume including Oracle, Postgres and DB/2. We all know those require knowing SQL, but the HR guy doesn't. He won't see the magic word "SQL", so there's a good chance your resume will get ignored.
That example is also why I suggest that no hiring manager ever let HR screen resumes. It's just too important to be left to a filter that doesn't have the proper knowledge set. Sure, your recruiters at Google and Microsoft and other big operations know these tech things. But most tech jobs aren't at tech companies like that.
If I'm a human and I'm reading a skills section that includes PostgreSQL, PL/pgSQL, SQL and RDBMS, I might think "Aw, she's padding her resume, those are all related." But if I slap a "Buzzwords" section on there, now it's clear why it's there.
And I do think that's important. Say you've got an HR drone who is told to look for candidates who know SQL. He might see a resume including Oracle, Postgres and DB/2. We all know those require knowing SQL, but the HR guy doesn't. He won't see the magic word "SQL", so there's a good chance your resume will get ignored.
That example is also why I suggest that no hiring manager ever let HR screen resumes. It's just too important to be left to a filter that doesn't have the proper knowledge set. Sure, your recruiters at Google and Microsoft and other big operations know these tech things. But most tech jobs aren't at tech companies like that.
>It's not for the human readers to skip the section so much as to simply acknowledge that you're doing it for the machines.
Yes, exactly. That's a much better way of wording it.
Yes, exactly. That's a much better way of wording it.
It makes it clear what it's for. Intent is good.
You can improve signal-to-noise by listing in categories ("best", "okay", "seen it before", "academic-only") and then humans can get something out of it too. Or you can call it a loss and treat it like what it is.
You can improve signal-to-noise by listing in categories ("best", "okay", "seen it before", "academic-only") and then humans can get something out of it too. Or you can call it a loss and treat it like what it is.
The idea of listing categories is fine, but don't rely on those descriptions to give enough detail. What you think might be "good" knowledge of X might be strictly amateur to someone else. Better to tell stories and give descriptions of how you've used the technology in question.
Also, if you know something good enough to say that you're good at it, there better be multiple bullets up above explaining how you've used that technology. I've had resumes where someone says they have expert knowledge in a given technology, but nowhere in their work history do they have anything that says that they've used it. You know Oracle? Then you have to have it in a bullet up above.
Another way that you can get those details in the resume about what you know is by quantifying as much as possible. Instead of saying you wrote a Ruby app to do such-and-such, say that you wrote an N,000-line Ruby app to do such-and-such. The numbers give a sense of scale that's missing without it.
More from my blog about the importance of numbers: http://petdance.com/tag/numbers/
Also, if you know something good enough to say that you're good at it, there better be multiple bullets up above explaining how you've used that technology. I've had resumes where someone says they have expert knowledge in a given technology, but nowhere in their work history do they have anything that says that they've used it. You know Oracle? Then you have to have it in a bullet up above.
Another way that you can get those details in the resume about what you know is by quantifying as much as possible. Instead of saying you wrote a Ruby app to do such-and-such, say that you wrote an N,000-line Ruby app to do such-and-such. The numbers give a sense of scale that's missing without it.
More from my blog about the importance of numbers: http://petdance.com/tag/numbers/
One thing to keep in mind is that the resumes looked at were for YC's "Work At A Startup" event. This means that while it is possible to tailor your resume based on the kind of job you want or your strengths, you can't at this stage tailor it to a specific company.
The irony of having three separate points that all say the same thing... and that thing is keep it brief, don't use filler.
Hi,
I'm a coder from Slovenia.
I like writing JavaScript and Python. I'm learning Haskell.
Here is my github: http://github.com/Swizec
I have a blog at http://swizec.com
Most recently I did cool thing X <relevant link, this changes every couple of months>
Cheers, ~Swizec