The Startup Resume
justinkan.com
justinkan.com
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
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.
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.
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.
I'm a CTO hiring this sort of person right now.
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.
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.
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.
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.
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.
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)
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)
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.
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 sociallyThe 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).
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.
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.
[1] http://pragprog.com/book/algh/land-the-tech-job-you-love
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.
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/
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.
Yes, exactly. That's a much better way of wording it.