Lessons From A Silicon Valley Job Search
07 Mar 2014
This post is a fairly exhaustive summary of the things I learned during my recent Silicon Valley job search. It is really quite long, but has been edited aggressively, and I’ve tried to make sure that nearly every point is either actionable, interesting, or both. If you’re currently or may one day be looking for a job as a programmer, either in San Francisco or elsewhere in the world, then there should hopefully be a bunch of useful stuff for you. I’ve tried to give numbers and stats where possible - your mileage will of course vary, but my hope is that they are still helpful for working out which ballpark to start in.
After 4 months of funemployment, 25 job applications and 6 weeks of constant interviewing, I’ve finally got a job at >Stripe.
The job search experience wasn’t some epic, arduous, life-affirming quest in which I realised that the nerdy girl with glasses was actually both inwardly beautiful and outwardly smoking hot when she brushed her hair. But it was certainly non-trivial and did take a lot more work and time than I had expected. As with anything, there were some things I did that accidentally turned out to be pretty smart, many things that turned out to be boneheaded, and lots of basics and finesses about making applications, doing interviews and negotiating deals that I feel I understand far more now than I did when I started. There’s plenty more on these below, but there are 2 lessons I would particularly like to emphasise from the start:
Firstly, find the right level of confidence. I’ve spent a good deal of the last 6 months oscillating between (often multiple times in one day) the twin but completely contradictory beliefs that:
- There are trillions of people who know hundreds of times more stuff about everything than me, and anything I can do could and should be done infinitely quicker and more effectively by these savvy supermen
- I AM PROGRAMMER, KNEEL BEFORE ME AND BEG ME TO WORK WITH YOU
When written out in front of you, it’s pretty clear that both these statements are somewhere between false and insane. It’s equally clear that the true and healthy mindset lies somewhere between them. Unfortunately, it can be hard to remember this.
Secondly, everything becomes much easier when you accept that some people and some companies are better or worse at interviewing candidates than others, and that at this point in time it’s your job to play the ball as it lies. Almost all companies do have processes that are at least better than requiring interviewees to wrestle with a chimp and hiring the survivors, and do give you a broadly sensible framework in which to demonstrate your skills. I know that there are many people who are amazing programmers but for whom current-day standard interview practises just do not and cannot work for whatever reason. This sucks a lot, and if this truly is you then perhaps there is something to be said for getting more creative or selecting primarily and aggressively for companies who you feel already understand you.
But it’s just a fact that in any extensive job search you will be asked to jump through some bizarrely shaped hoops that are leaking a strange liquid onto the carpet. You can read many posts about how most technical hiring processes are broken, and I don’t disagree with them. Some places like Matasano, Stripe, Github and I’m sure many others are aware of this and are equally aware that it has the potential to harm their company a great deal. But until this realisation propagates throughout the entire industry, just answer any approximately reasonable questions or challenges as they come, and save your constructive bile for a blog post once you’ve finished. Tune in next week for mine. For now, here’s some more thoughts and stories about finding and choosing a job as a software engineer that I hope you find useful.
0. Some quick background for reference
0.1 Me
I’m a 25 year old Ruby/Rails guy with a smattering of experience in other stacks. I did physics and then computer science at university, and have been programming for 4 years total, 2 years professionally. I did have a cheat code in the form of the noble Peter Nixey opening his brain to me for the year we worked together, but overall I’m adequately good at some things and completely inexperienced in others.
0.2 My situation
I’m moving to San Francisco very shortly, but right now I live in London and have an H1B US work visa from the April 2013 ballot burning a hole in my pocket (complicated story). US visas are hard and I got very lucky with mine. If you’re looking then the main options are H1B, O1, J1 and L1 (here’s a great summary of these as well as some more exotic options). Even if you’ve never even thought about getting a US visa before, many companies are happy to use their flock of lawyers to help try and drag you through the process. However, some aren’t, especially smaller companies, so make sure you find out early in the conversation.
I wanted to move to San Francisco and seek my fame and fortune, so I finished a contract in Oct 2013, spent Nov/Dev funemployed, and hit the interview trail in mid-Jan 2014.
0.3 Timeframe and logistics
The process took 6 weeks from start to finish; 3 weeks of phone screens and 3 weeks of on-sites in San Francisco. Not already living in SF made everything a lot more intense than it would otherwise have been. I had to make sure that I blitzed all my on-site interviews in a single trip and that I actually had an offer that I wanted to take by the end of it. Having to come back to SF for another round would have been time-consuming, demoralising and not a good signal.
Flying out to interview with a single company is easy - they pay for the flights and hotel and you use them. Interviewing with 7 companies made for a surprisingly stressful round of negotiation before I’d even arrived, as I tried to spread the cost according to who could most afford it and who was getting the most time with me. I booked everything myself once I had 3-4 invitations for on-sites, guessed at how many interviews I expected to have in total and split the cost up accordingly. Fortunately all the companies were very understanding and I got reimbursed for all but around $100 of the cost of the trip.
I could probably have compressed the process to 5 weeks if necessary, and to 4 weeks if I already lived in the Valley. Don’t underestimate how time-consuming a substantial job search will be; I would never have been able to be as thorough as I was if I had been working at the same time.
1. Deciding where to apply
1.1 My stats
- I applied to 25 companies
- 17 asked me to do phone interviews, 8 either never replied or said no thanks straightaway
- 7 asked me to go to San Francisco for an on site interview
- 5 made me an offer
Since I was funemployed for the entirety of my job search, I had the time to talk to as many companies as seemed sensible. 25 applications feels like a lot, but many of these were relatively speculative, and given my geographical complications I wouldn’t have felt comfortable making many fewer than this. If I had applied to half as many companies and had a couple of extra off-days then I could easily have ended up with only 1 or even 0 offers.
1.2 Be quietly confident
The internet does not do a good job of reminding you that very few people are programmatic celebrities and that you don’t have to be a polyglot or a prodigy in order to be an incredibly good hire. Even if you are “just” good at building stable, maintainable and vanilla Rails apps, you are still a very rare breed.
For almost all positions, open source contributions and active StackOverflow and Github profiles are just one of many nice-to-haves. Even if you do have a bunch of projects and other content on display, they’ll be used to evaluate your code quality, not your all-consuming passion for programming. Companies are aware that not everyone wants or is able to work on OSS, and if you don’t have any public code then they’ll just look at other indications of your skills instead.
Equally, a popular or populated blog is just another nice-to-have. I personally felt that having ~20 essays I could point to was a great way of demonstrating to someone that I’m at least a somewhat thoughtful person before even having met them. I pushed my blog hard in my CV and cover letter, and 15-20 interviewers made a comment along the lines of “I liked your blog.” I’m sure that some substantial percentage of these were just being polite (c.f. “I like your haircut”) but I’m equally sure that another substantial percentage actually had read it and enjoyed it. Regardless, no matter how much writing or code or anything else you have on the internet, you will still need to show a company in person that you can write good code and will be reasonable to work with.
If you’re applying for a generalist or entry-level position, assume that every list of criteria includes the point “experience with any of our technologies is just a plus”. If a position and company look fun, then apply, even if you don’t meet any of their requirements. The worst they can say is no, and the best they can say is “sure, let’s talk”, whereupon you can show them why you are awesome in 10 ways they hadn’t even thought of.
1.3 Yes, there is an "Engineer Crunch"
Sam Altman recently wrote a great post on the “Engineer Crunch”, and you are probably already aware that there are lots of jobs for engineers but not enough people with the skills to do them all. This means you will probably be able to get your feet in a lot of interesting doors.
1.4 But it's not that Crunchy
That said, you will still get rejected from companies you feel should be snapping you up, and you won’t necessarily get an offer for any and every job remotely related to programming. Companies still have to hire people that fit their needs, and making no hire is always better than making the wrong hire. An 8-person team with only 1 senior engineer probably can’t afford to hire another person with talent but not experience. If you are a Django-only programmer then you may find it challenging to find work as a Machine Learning specialist, although I’m sure it wouldn’t be impossible.
Thomas Ptacek from Matasano has written some interesting thoughts in the “Engineer Crunch” HN thread. Matasano is a security consultancy that happily hires people with zero prior experience in app sec, and has built an incredible team doing so. So perhaps other companies are doing it wrong, but you can still expect a lot of surprising and unsurprising rejections.
2. Making applications
2.1 Cover letter/CV
Whilst first impressions do matter, your cover letter/CV will quickly get forgotten when you start talking code, so all they really have to do is get you in the door and maybe be a bit memorable. I liked leading with repeated references to my blog and a list of impressive yet quirky facts about me, but this might just be because I think that at the moment they are more impressive than my programming accomplishments. There are already enough pixels on the internet about how to write CVs, but I thought my cover letter in particular was pretty good and somewhat amusing, so if you’re interested then here is it.
2.2 Intros
Intros are fine, but far from essential. In a company of any size with a defined process you’ll probably get thrown into the top of their standard interview funnel anyway, so it doesn’t seem to make much difference. I was so pleased with my skeleton cover letter that I actually preferred not to go through an intro unless it was to someone particularly senior and guaranteed to be burning hot.
2.3 Spreadsheet
Keep a spreadsheet with:
- The company name
- The date you applied
- How much you like the company (scale of 1-4, use conditional formatting to colour-code)
- The stage you are at (Applied/Phone Hello/Phone Tech/On Site/Offered)
If a company rejects you, move them to a separate list. You need to be able to see at a glance how many live applications you have and how many of them are actually interesting to you. Anything not on the above list is unnecessary and won’t get updated, so will just make your spreadsheet stale and less communicative.
2.4 Where to look
- Hacker News Who’s Hiring thread - created on the 1st of every month, this thread provides a place for companies that read Hacker News to post job adverts. There are a lot of posts, and the companies are generally pretty interesting. I made 7 applications after seeing them on January 2014’s HNWH.
- AngelList - setting your profile to “I’m looking” gives you an idea of what it must be like to be an attractive girl on an online dating site, except with about half as much aggressive sexual abuse. It seems particularly fruitful if you are looking for seed-stage companies. I received 46 “X is interested in you”s and 4 developed into conversations.
- LinkedIn - mostly spammy recruiters, some thoughtful recruiters, a small number of in-house recruiters. I received 16 messages. 1 developed into a conversation. Pro-tip: set your location to San Francisco (or wherever you are looking), even before you get there.
- Hired.com - this seems like a very interesting model, particularly for engineers. I was on auction for a week and received 8 credible-looking offers with actual proposed dollar amounts. None of the products felt like a fit for me, but the process was very easy and potentially disproportionately rewarding. In the worst case you still get some idea of your market value, although I would suggest only using your shot on it once you are in a position to actually follow up with any interesting offers.
- Intros/direct applications - these will still likely make up the bulk of the top of your funnel. I made 10 applications this way.
2.5 Inbound interest
Inbound interest is a wonderful thing that can make you feel very warm and very fuzzy, but you shouldn’t be flattered into pointless conversations. Both you and the company will quickly forget who approached who, and in the end the only thing that matters is whether an opportunity is interesting to you. Would you have applied for this job if you saw it on Hacker News? Why hadn’t you already applied for it?
I had a “Hire Me” banner on my blog for about 4 months. I received 7 messages because of it, almost all from ultra-early-stage companies looking for a CTO-type character. This is a perfectly valid thing to be doing, but not what I was looking for. This was from 5k visitors, so the conversion rate from blog hit to (generally low value) enquiry was around 0.1%.
I would therefore suggest not relying on or expecting much such freestyle inbound interest, unless you are a either a rockstar or more highly trafficked than I. That said, I was mostly writing technical and other labour-of-love posts, and it would be interesting to see what would happen if you made a 30k hit score on Hacker News.
My “Hire Me” page turned out to be most useful as a way to get people from my cover letter/CV onto my blog (“Here’s some further detail on what I’m all about”), and to cram a load of impressive but only tangentially relevant info into any application. With this in mind, a “Hire Me” page and banner are very worthwhile things to do, but should not be relied on to generate inbound interest. I’ve left my page up for posterity.
3. General Interviews
3.1 You can't waste anyone's time
If you don’t have several interviews where you get completely annihilated (I had 3), then you probably didn’t make enough speculative applications. It’s up to a company to decide whether they want to talk to you. If they make a mistake and it takes them an hour to work out that you are actually completely unsuited for the job then that’s not a big deal. Once you hear how much recruiters’ fees are then you won’t feel bad or embarrassed when talking to a company ever again.
3.2 Standard general questions
You will inevitably gradually evolve your answers to the standard questions:
- Tell me about yourself.
- What are you looking for in your next:
- Product?
- Team? (size, culture etc)
- Technical challenge?
- Have you had experience scaling applications?
- Tell me about a cool project you worked on recently (very important).
It couldn’t hurt to answer them once or twice to a friend before your first interview too.
3.3 You might think that some companies suck at interviews
But it’s not worth getting upset about. At pretty much every company you will be answering a series of 45-60 min code-oriented challenges, with a few curveballs thrown in for variety. Some of these will be purely algorithmic (although very rarely a standard, rote algorithm like merge sort), and some will be more focussed on architecture. But regardless, you will spend much of your interview time writing code. If this doesn’t appeal to you then, unfortunately, you will just have to get practicing.
Many companies include a 2-3 hour take-home technical challenge as part of their phone screen process. Most of them are at least somewhat interesting, and some of them are actively really fun. None of the challenges I went through took too long or seemed stupid. Even if you think they are silly and a waste of your precious and expensive time, your time has to be really valuable before it becomes sensible to refuse to give a company you are even slightly interested in some idea of how good you are at ACTUALLY writing code. So just do it.
3.4 Systems design questions
Most companies will ask a question about designing a high-level (often distributed) system - what machines would you use, how would you arrange them, how would you deal with failures, how would you set up your database etc. If, like me, you have little practical experience with this stuff, then don’t lose any sleep over it. It’s all surprisingly logical and non-magical, and you can stumble through the problem, learn a few things, and reach a broadly sensible answer.
3.5 The one question I will give away
It’s obviously extremely unhelpful to give away interview questions, but since I was asked this clearly already non-secret systems design question an honest-to-Dog total of 6 times I will make an exception:
“Design the infrastructure for a link-shortener.”
The first time I was awful, the second time I was better, and from then on I think I sounded like the CEO of bit.ly himself.
3.6 The other question I will give away
This question also gets asked a lot, but is so open ended and useful to know about that I don’t think that any company that asks it would even mind if they knew you had pre-prepared it:
“If I type https://google.com into my browser and press enter, what happens?”
You can talk about so many things on so many levels - DNS lookup, IP lookup, client/server-side caching, SSL/TLS and many more. A fun question to answer.
3.7 Do your own write-ups
In the current market, the engineering interview process is arguably more about you choosing a company than a company choosing you. Every interviewer you speak to will be writing detailed notes on you after you finish with them, and you should do exactly the same. All you need is a document in Evernote - “FooCorp Phone Interview 1/1/14” - with details of what they asked, what you replied, whether you liked the person, whether you liked the sound of the company, the answers to any questions you asked them and what the next steps are. You will forget all of this information within a couple of hours, so do it immediately after you finish.
3.8 Find out next steps
At the end of every phone and on-site interview, make sure you know exactly what the next steps are and when they will contact you by. This will make your planning far easier and will stop you from going crazy when you haven’t heard from them for a few days. It will also make it easier and less awkward for you to follow-up after any prolonged radio silence - “Steve said you’d be in touch by Thursday, just checking everything’s OK your end?” feels much better than “Haven’t heard from you, just wondering if you liked me, hope you did HAHAHAHA!!”
4 Phone interviews
4.1 Scheduling
Phone interviews are surprisingly tiring. Don’t arrange too many in a row and make sure to give yourself breaks.
Even scheduling them is hard and time-consuming. You’ll almost always be doing at least 2, maybe even 3 or 4 per company, especially if you are an international candidate and the company will need to spring a few $k just to get you on-site. Block out a few hours each day and try and fit them in there. Give people multiple time options. I’m sure you know how to schedule things effectively, so just do that.
4.2 Things to learn
Don’t be thrown by Fizzbuzz:
“Write a program that prints the numbers from 1 to 100. For multiples of three print “Fizz” instead of the number and for multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.”
It’s not a trick question, it really is as easy as it sounds, so just do it. Small gotcha: remember that for(var i=0; i<=100; i++) is technically wrong - you should be starting at 1, not 0.
Other common screening-type questions include the properties of common data structures (hashes, arrays, sets, trees, binary-search trees) and Big O complexities. It’s worth learning that sorting a array of N elements takes O(Nlog(N)) time, finding an element in a sorted array takes O(log(N)) time, and that the sum of the numbers from 1 to N (the actual sum, not the time taken to calculate this sum) is O(N^2). Pro-tip: the fact that Hashes have O(1) lookup time is often a great way to speed up an algorithm.
I subscribed to the semi-regular Coding For Interviews emails. They were interesting and of no harm, but I wouldn’t worry about practicing puzzlers unless you haven’t programmed for a while or really freeze up in interviews. It still can’t hurt to briefly review depth-/breadth-first search, bit-shifting, programming language properties, and all the other things you haven’t thought about since CS 101 though. Again, it may upset you that these things aren’t directly related to what you’ll be doing on a day-to-day basis, but it’s what you’re mostly going to be asked about.
5. On-site interviews
5.1 Length and energy
On-site interviews are LONG (6-9 hours). Interviewers tend to forget that whilst they are just about to start their segment, you may have not had a break for several hours. Even if you’re running behind schedule, it’s a waste of everyone’s time if you have pillow-head (lit. - your head feels like there is a pillow inside it) so make sure you ask if it’s OK if you go and grab a Mars Bar and a cool glass of milk if you need one.
5.2 Other people
At the majority of software engineering interviews, especially in larger companies, you aren’t competing against other interviewees. If a company likes you, they’ll make you an offer, regardless of whether they dis/like someone else. So you don’t need to focus on accidentally nudging other interviewees down an elevator shaft to their doom.
5.3 Misc
The first on-site interview of your job search won’t necessarily be terrible, but it will be much worse than your last.
Hopefully the day includes at least 1 meal; they’re the best time to get a sense of how the team interacts and whether you’d enjoy being a part of it.
6. Post-interview
6.1 References
A surprisingly large number of companies want references. Line up 2 or 3 people you have worked with (at least 1 of whom managed you) and brief them beforehand. Share a Google Spreadsheet that tells them who wants a reference, by when, and any special instructions. It can be incredibly easy to lose track of these things and waste valuable time at the crucial offer stage.
6.2 Don't worry
It’s easier said than done, but don’t worry about what did or didn’t go well. You don’t know what they were looking for, and even if you did there’s no point worrying about whether they found it.
7. Negotiation
7.1 Patrick McKenzie
Patrick McKenzie (patio11) has written up pretty much all the advice you’ll ever need. Everything that follows is stolen directly from there.
7.2 Don't start negotiating until yes-if
Yes-if means “yes you are hired, if we can reach a deal.” This is a strong position for you to be in.
No-but means “no we aren’t going to hire you, but I guess maybe we could if you lowered your salary requirements.” This is a crappy position for you to be in.
If you give a company a number before they’ve said yes-if, then you leave the door open for a no-but. You want to start negotiating at your strongest point - when they have said “we love you, let’s make a deal.” You also want to be able to use your other offers to either increase your number or prevent it from decreasing, which means delaying talking about it until you have or are close to several yes-ifs. If you are asked for a number before you’re told yes-if, politely say you’d prefer to work out if there’s a fit first, and only start talking details then. Stonewall ad infinitum if necessary.
7.3 Negotiation is not scary
Engineers are not good at negotiation. It seems like a scary, alien thing where you feel very exposed and open to ridicule and failure. However, only 1% of negotiation needs to be thinking of a big number and Jedi-mind-tricking your way towards it. The other 99% is having several viable options and making reasonable statements about their relative attractiveness to you. With strong BATNAs (Best Alternative To a Negotiated Agreement), everything becomes much simpler. You also feel less stupid saying an aggressively big number, because it’s probably only incrementally bigger than what someone else is already offering you.
At any point after you get the yes-if, the worst they can say to your counter-offer is no.
7.4 Negotiation is not vulgar
People in startups (as well as many other professions) generally like to think that they are doing some version of “changing the world for the better.” And whilst this is a good and noble-ish thing, it can make you feel like a tool when you start talking about and debating salary and equity. After all, you should be doing this job for love, not money. Right?
There’s a great Dilbert cartoon where Catbert tries to sell a prospective employee on the many intangible benefits of working for his company. The prospective employee politely suggests that Catbert’s stockholders might prefer to have his intangible benefits, and he’ll take his compensation in cash if that’s OK. It’s not at all vulgar or unreasonable or disloyal to want to feel fairly materially compensated, and any suggestion that there is anything wrong with negotiating in good faith with a profit-seeking enterprise is entirely disingenuous. Equally, it is completely reasonable for a hiring manager to be protecting the company’s interests whilst trying to reach an agreement that works in context for both you and the company. If everyone is communicative and pleasant then it can and should be a mostly painless process.
7.5 Market rate is market rate and options are worth what they are valued at
Early-stage companies tend to claim poverty and offer salaries at anything down to 60% of market rate. I’m sure you could find even lower examples without much trouble, and these are theoretically offset with “generous equity grants”. However, you should keep in mind that the value of options for 0.1% of a company is 0.1% of the company’s current value, and in fact somewhat less due to their strike price and other complications. If a company is currently worth $10m, options for 0.1% are worth $10k. Vesting over 4 years this is $2.5k/year. It doesn’t matter what magic you can weave in Microsoft Excel by dragging a 3x growth multiplier 5 years into the future; these options make up for less than a $2.5k delta in salary, and even-even less if you factor in a risk discount.
If you’re thinking about working for a fairly early-stage venture, you probably like them quite a lot and are probably comfortable taking some degree of a hit to your compensation. But options aren’t some magical, mystical salary equaliser. They have a very easily calculable value, and it’s probably not actually very much. If a company wants to give you equity instead of cash then that’s fine and great, but if you’re going to be missing out on a lot of cash then you should be getting a lot of equity in return.
7.6 Understand your offer
Far too many offers come through as:
$Xk/year
10,000 options
This is literally equivalent to:
$Xk/year
$100bn in monopoly money and bingly bongly bangly boo
You have to find out the last round valuation of the company, the total number of shares issued, and the strike price of your options, otherwise an option grant is completely meaningless. It’s not rude to be persistent in trying to find this information, and it’s not distasteful to ask to be walked through the details of the offer until you understand it. Don’t comment on whether you are happy with an offer until you are clear what it actually is.
7.6 Calm down
This is all incredibly unintuitive and unfamiliar for most engineers (myself included), but is incredibly important. That said, it’s easy to be too quick to fly into slightly-hostile-negotiation mode once a first offer comes through, without making it clear that you really appreciate the company’s interest and offer and really like them and what they’re doing, but don’t feel that the deal as it stands fairly reflects your value or matches up to your competing offers. It’s good to negotiate, but you should still be polite, understanding and open-minded about it.
Conclusion
It’s a great market to be an engineer, but finding the right job still requires a lot of time and effort. Spray applications anywhere and everywhere you like the look of, and see what sticks. A little organisation will go a long way, but a little over-thinking will quickly make you go insane. How best to conduct a technical interview process is a hot and very worthwhile topic of discussion at the moment, but just go with whatever is thrown at you, regardless of what you think is and isn’t a good hiring strategy. Unless you think a company is being unreasonable or exploitative, your own interview is vanishingly unlikely to be the time or the place to try and change a company’s interview practises. You can always make yourself an instant hero on your first day by explaining to your interviewers in exacting detail all the ways in which they are idiots.
During your job search you’ll solve some delectable puzzles, meet some heavyweight people and see inside some very zany office spaces. You’ll say some face-meltingly intelligent stuff and commit some rusty-scissor-apendectomy-esque blunders. And hopefully, with the right combination of luck, skill and more luck, you’ll even come out the other side with a job. Good luck!
This post is a fairly exhaustive summary of the things I learned during my recent Silicon Valley job search. It is really quite long, but has been edited aggressively, and I’ve tried to make sure that nearly every point is either actionable, interesting, or both. If you’re currently or may one day be looking for a job as a programmer, either in San Francisco or elsewhere in the world, then there should hopefully be a bunch of useful stuff for you. I’ve tried to give numbers and stats where possible - your mileage will of course vary, but my hope is that they are still helpful for working out which ballpark to start in.
After 4 months of funemployment, 25 job applications and 6 weeks of constant interviewing, I’ve finally got a job at >Stripe.
The job search experience wasn’t some epic, arduous, life-affirming quest in which I realised that the nerdy girl with glasses was actually both inwardly beautiful and outwardly smoking hot when she brushed her hair. But it was certainly non-trivial and did take a lot more work and time than I had expected. As with anything, there were some things I did that accidentally turned out to be pretty smart, many things that turned out to be boneheaded, and lots of basics and finesses about making applications, doing interviews and negotiating deals that I feel I understand far more now than I did when I started. There’s plenty more on these below, but there are 2 lessons I would particularly like to emphasise from the start:
Firstly, find the right level of confidence. I’ve spent a good deal of the last 6 months oscillating between (often multiple times in one day) the twin but completely contradictory beliefs that:
- There are trillions of people who know hundreds of times more stuff about everything than me, and anything I can do could and should be done infinitely quicker and more effectively by these savvy supermen
- I AM PROGRAMMER, KNEEL BEFORE ME AND BEG ME TO WORK WITH YOU
When written out in front of you, it’s pretty clear that both these statements are somewhere between false and insane. It’s equally clear that the true and healthy mindset lies somewhere between them. Unfortunately, it can be hard to remember this.
Secondly, everything becomes much easier when you accept that some people and some companies are better or worse at interviewing candidates than others, and that at this point in time it’s your job to play the ball as it lies. Almost all companies do have processes that are at least better than requiring interviewees to wrestle with a chimp and hiring the survivors, and do give you a broadly sensible framework in which to demonstrate your skills. I know that there are many people who are amazing programmers but for whom current-day standard interview practises just do not and cannot work for whatever reason. This sucks a lot, and if this truly is you then perhaps there is something to be said for getting more creative or selecting primarily and aggressively for companies who you feel already understand you.
But it’s just a fact that in any extensive job search you will be asked to jump through some bizarrely shaped hoops that are leaking a strange liquid onto the carpet. You can read many posts about how most technical hiring processes are broken, and I don’t disagree with them. Some places like Matasano, Stripe, Github and I’m sure many others are aware of this and are equally aware that it has the potential to harm their company a great deal. But until this realisation propagates throughout the entire industry, just answer any approximately reasonable questions or challenges as they come, and save your constructive bile for a blog post once you’ve finished. Tune in next week for mine. For now, here’s some more thoughts and stories about finding and choosing a job as a software engineer that I hope you find useful.
0. Some quick background for reference
0.1 Me
I’m a 25 year old Ruby/Rails guy with a smattering of experience in other stacks. I did physics and then computer science at university, and have been programming for 4 years total, 2 years professionally. I did have a cheat code in the form of the noble Peter Nixey opening his brain to me for the year we worked together, but overall I’m adequately good at some things and completely inexperienced in others.
0.2 My situation
I’m moving to San Francisco very shortly, but right now I live in London and have an H1B US work visa from the April 2013 ballot burning a hole in my pocket (complicated story). US visas are hard and I got very lucky with mine. If you’re looking then the main options are H1B, O1, J1 and L1 (here’s a great summary of these as well as some more exotic options). Even if you’ve never even thought about getting a US visa before, many companies are happy to use their flock of lawyers to help try and drag you through the process. However, some aren’t, especially smaller companies, so make sure you find out early in the conversation.
I wanted to move to San Francisco and seek my fame and fortune, so I finished a contract in Oct 2013, spent Nov/Dev funemployed, and hit the interview trail in mid-Jan 2014.
0.3 Timeframe and logistics
The process took 6 weeks from start to finish; 3 weeks of phone screens and 3 weeks of on-sites in San Francisco. Not already living in SF made everything a lot more intense than it would otherwise have been. I had to make sure that I blitzed all my on-site interviews in a single trip and that I actually had an offer that I wanted to take by the end of it. Having to come back to SF for another round would have been time-consuming, demoralising and not a good signal.
Flying out to interview with a single company is easy - they pay for the flights and hotel and you use them. Interviewing with 7 companies made for a surprisingly stressful round of negotiation before I’d even arrived, as I tried to spread the cost according to who could most afford it and who was getting the most time with me. I booked everything myself once I had 3-4 invitations for on-sites, guessed at how many interviews I expected to have in total and split the cost up accordingly. Fortunately all the companies were very understanding and I got reimbursed for all but around $100 of the cost of the trip.
I could probably have compressed the process to 5 weeks if necessary, and to 4 weeks if I already lived in the Valley. Don’t underestimate how time-consuming a substantial job search will be; I would never have been able to be as thorough as I was if I had been working at the same time.
1. Deciding where to apply
1.1 My stats
- I applied to 25 companies
- 17 asked me to do phone interviews, 8 either never replied or said no thanks straightaway
- 7 asked me to go to San Francisco for an on site interview
- 5 made me an offer
Since I was funemployed for the entirety of my job search, I had the time to talk to as many companies as seemed sensible. 25 applications feels like a lot, but many of these were relatively speculative, and given my geographical complications I wouldn’t have felt comfortable making many fewer than this. If I had applied to half as many companies and had a couple of extra off-days then I could easily have ended up with only 1 or even 0 offers.
1.2 Be quietly confident
The internet does not do a good job of reminding you that very few people are programmatic celebrities and that you don’t have to be a polyglot or a prodigy in order to be an incredibly good hire. Even if you are “just” good at building stable, maintainable and vanilla Rails apps, you are still a very rare breed.
For almost all positions, open source contributions and active StackOverflow and Github profiles are just one of many nice-to-haves. Even if you do have a bunch of projects and other content on display, they’ll be used to evaluate your code quality, not your all-consuming passion for programming. Companies are aware that not everyone wants or is able to work on OSS, and if you don’t have any public code then they’ll just look at other indications of your skills instead.
Equally, a popular or populated blog is just another nice-to-have. I personally felt that having ~20 essays I could point to was a great way of demonstrating to someone that I’m at least a somewhat thoughtful person before even having met them. I pushed my blog hard in my CV and cover letter, and 15-20 interviewers made a comment along the lines of “I liked your blog.” I’m sure that some substantial percentage of these were just being polite (c.f. “I like your haircut”) but I’m equally sure that another substantial percentage actually had read it and enjoyed it. Regardless, no matter how much writing or code or anything else you have on the internet, you will still need to show a company in person that you can write good code and will be reasonable to work with.
If you’re applying for a generalist or entry-level position, assume that every list of criteria includes the point “experience with any of our technologies is just a plus”. If a position and company look fun, then apply, even if you don’t meet any of their requirements. The worst they can say is no, and the best they can say is “sure, let’s talk”, whereupon you can show them why you are awesome in 10 ways they hadn’t even thought of.
1.3 Yes, there is an "Engineer Crunch"
Sam Altman recently wrote a great post on the “Engineer Crunch”, and you are probably already aware that there are lots of jobs for engineers but not enough people with the skills to do them all. This means you will probably be able to get your feet in a lot of interesting doors.
1.4 But it's not that Crunchy
That said, you will still get rejected from companies you feel should be snapping you up, and you won’t necessarily get an offer for any and every job remotely related to programming. Companies still have to hire people that fit their needs, and making no hire is always better than making the wrong hire. An 8-person team with only 1 senior engineer probably can’t afford to hire another person with talent but not experience. If you are a Django-only programmer then you may find it challenging to find work as a Machine Learning specialist, although I’m sure it wouldn’t be impossible.
Thomas Ptacek from Matasano has written some interesting thoughts in the “Engineer Crunch” HN thread. Matasano is a security consultancy that happily hires people with zero prior experience in app sec, and has built an incredible team doing so. So perhaps other companies are doing it wrong, but you can still expect a lot of surprising and unsurprising rejections.
2. Making applications
2.1 Cover letter/CV
Whilst first impressions do matter, your cover letter/CV will quickly get forgotten when you start talking code, so all they really have to do is get you in the door and maybe be a bit memorable. I liked leading with repeated references to my blog and a list of impressive yet quirky facts about me, but this might just be because I think that at the moment they are more impressive than my programming accomplishments. There are already enough pixels on the internet about how to write CVs, but I thought my cover letter in particular was pretty good and somewhat amusing, so if you’re interested then here is it.
2.2 Intros
Intros are fine, but far from essential. In a company of any size with a defined process you’ll probably get thrown into the top of their standard interview funnel anyway, so it doesn’t seem to make much difference. I was so pleased with my skeleton cover letter that I actually preferred not to go through an intro unless it was to someone particularly senior and guaranteed to be burning hot.
2.3 Spreadsheet
Keep a spreadsheet with:
- The company name
- The date you applied
- How much you like the company (scale of 1-4, use conditional formatting to colour-code)
- The stage you are at (Applied/Phone Hello/Phone Tech/On Site/Offered)
If a company rejects you, move them to a separate list. You need to be able to see at a glance how many live applications you have and how many of them are actually interesting to you. Anything not on the above list is unnecessary and won’t get updated, so will just make your spreadsheet stale and less communicative.
2.4 Where to look
- Hacker News Who’s Hiring thread - created on the 1st of every month, this thread provides a place for companies that read Hacker News to post job adverts. There are a lot of posts, and the companies are generally pretty interesting. I made 7 applications after seeing them on January 2014’s HNWH.
- AngelList - setting your profile to “I’m looking” gives you an idea of what it must be like to be an attractive girl on an online dating site, except with about half as much aggressive sexual abuse. It seems particularly fruitful if you are looking for seed-stage companies. I received 46 “X is interested in you”s and 4 developed into conversations.
- LinkedIn - mostly spammy recruiters, some thoughtful recruiters, a small number of in-house recruiters. I received 16 messages. 1 developed into a conversation. Pro-tip: set your location to San Francisco (or wherever you are looking), even before you get there.
- Hired.com - this seems like a very interesting model, particularly for engineers. I was on auction for a week and received 8 credible-looking offers with actual proposed dollar amounts. None of the products felt like a fit for me, but the process was very easy and potentially disproportionately rewarding. In the worst case you still get some idea of your market value, although I would suggest only using your shot on it once you are in a position to actually follow up with any interesting offers.
- Intros/direct applications - these will still likely make up the bulk of the top of your funnel. I made 10 applications this way.
2.5 Inbound interest
Inbound interest is a wonderful thing that can make you feel very warm and very fuzzy, but you shouldn’t be flattered into pointless conversations. Both you and the company will quickly forget who approached who, and in the end the only thing that matters is whether an opportunity is interesting to you. Would you have applied for this job if you saw it on Hacker News? Why hadn’t you already applied for it?
I had a “Hire Me” banner on my blog for about 4 months. I received 7 messages because of it, almost all from ultra-early-stage companies looking for a CTO-type character. This is a perfectly valid thing to be doing, but not what I was looking for. This was from 5k visitors, so the conversion rate from blog hit to (generally low value) enquiry was around 0.1%.
I would therefore suggest not relying on or expecting much such freestyle inbound interest, unless you are a either a rockstar or more highly trafficked than I. That said, I was mostly writing technical and other labour-of-love posts, and it would be interesting to see what would happen if you made a 30k hit score on Hacker News.
My “Hire Me” page turned out to be most useful as a way to get people from my cover letter/CV onto my blog (“Here’s some further detail on what I’m all about”), and to cram a load of impressive but only tangentially relevant info into any application. With this in mind, a “Hire Me” page and banner are very worthwhile things to do, but should not be relied on to generate inbound interest. I’ve left my page up for posterity.
3. General Interviews
3.1 You can't waste anyone's time
If you don’t have several interviews where you get completely annihilated (I had 3), then you probably didn’t make enough speculative applications. It’s up to a company to decide whether they want to talk to you. If they make a mistake and it takes them an hour to work out that you are actually completely unsuited for the job then that’s not a big deal. Once you hear how much recruiters’ fees are then you won’t feel bad or embarrassed when talking to a company ever again.
3.2 Standard general questions
You will inevitably gradually evolve your answers to the standard questions:
- Tell me about yourself.
- What are you looking for in your next:
- Product?
- Team? (size, culture etc)
- Technical challenge?
- Have you had experience scaling applications?
- Tell me about a cool project you worked on recently (very important).
It couldn’t hurt to answer them once or twice to a friend before your first interview too.
3.3 You might think that some companies suck at interviews
But it’s not worth getting upset about. At pretty much every company you will be answering a series of 45-60 min code-oriented challenges, with a few curveballs thrown in for variety. Some of these will be purely algorithmic (although very rarely a standard, rote algorithm like merge sort), and some will be more focussed on architecture. But regardless, you will spend much of your interview time writing code. If this doesn’t appeal to you then, unfortunately, you will just have to get practicing.
Many companies include a 2-3 hour take-home technical challenge as part of their phone screen process. Most of them are at least somewhat interesting, and some of them are actively really fun. None of the challenges I went through took too long or seemed stupid. Even if you think they are silly and a waste of your precious and expensive time, your time has to be really valuable before it becomes sensible to refuse to give a company you are even slightly interested in some idea of how good you are at ACTUALLY writing code. So just do it.
3.4 Systems design questions
Most companies will ask a question about designing a high-level (often distributed) system - what machines would you use, how would you arrange them, how would you deal with failures, how would you set up your database etc. If, like me, you have little practical experience with this stuff, then don’t lose any sleep over it. It’s all surprisingly logical and non-magical, and you can stumble through the problem, learn a few things, and reach a broadly sensible answer.
3.5 The one question I will give away
It’s obviously extremely unhelpful to give away interview questions, but since I was asked this clearly already non-secret systems design question an honest-to-Dog total of 6 times I will make an exception:
“Design the infrastructure for a link-shortener.”
The first time I was awful, the second time I was better, and from then on I think I sounded like the CEO of bit.ly himself.
3.6 The other question I will give away
This question also gets asked a lot, but is so open ended and useful to know about that I don’t think that any company that asks it would even mind if they knew you had pre-prepared it:
“If I type https://google.com into my browser and press enter, what happens?”
You can talk about so many things on so many levels - DNS lookup, IP lookup, client/server-side caching, SSL/TLS and many more. A fun question to answer.
3.7 Do your own write-ups
In the current market, the engineering interview process is arguably more about you choosing a company than a company choosing you. Every interviewer you speak to will be writing detailed notes on you after you finish with them, and you should do exactly the same. All you need is a document in Evernote - “FooCorp Phone Interview 1/1/14” - with details of what they asked, what you replied, whether you liked the person, whether you liked the sound of the company, the answers to any questions you asked them and what the next steps are. You will forget all of this information within a couple of hours, so do it immediately after you finish.
3.8 Find out next steps
At the end of every phone and on-site interview, make sure you know exactly what the next steps are and when they will contact you by. This will make your planning far easier and will stop you from going crazy when you haven’t heard from them for a few days. It will also make it easier and less awkward for you to follow-up after any prolonged radio silence - “Steve said you’d be in touch by Thursday, just checking everything’s OK your end?” feels much better than “Haven’t heard from you, just wondering if you liked me, hope you did HAHAHAHA!!”
4 Phone interviews
4.1 Scheduling
Phone interviews are surprisingly tiring. Don’t arrange too many in a row and make sure to give yourself breaks.
Even scheduling them is hard and time-consuming. You’ll almost always be doing at least 2, maybe even 3 or 4 per company, especially if you are an international candidate and the company will need to spring a few $k just to get you on-site. Block out a few hours each day and try and fit them in there. Give people multiple time options. I’m sure you know how to schedule things effectively, so just do that.
4.2 Things to learn
Don’t be thrown by Fizzbuzz:
“Write a program that prints the numbers from 1 to 100. For multiples of three print “Fizz” instead of the number and for multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.”
It’s not a trick question, it really is as easy as it sounds, so just do it. Small gotcha: remember that for(var i=0; i<=100; i++) is technically wrong - you should be starting at 1, not 0.
Other common screening-type questions include the properties of common data structures (hashes, arrays, sets, trees, binary-search trees) and Big O complexities. It’s worth learning that sorting a array of N elements takes O(Nlog(N)) time, finding an element in a sorted array takes O(log(N)) time, and that the sum of the numbers from 1 to N (the actual sum, not the time taken to calculate this sum) is O(N^2). Pro-tip: the fact that Hashes have O(1) lookup time is often a great way to speed up an algorithm.
I subscribed to the semi-regular Coding For Interviews emails. They were interesting and of no harm, but I wouldn’t worry about practicing puzzlers unless you haven’t programmed for a while or really freeze up in interviews. It still can’t hurt to briefly review depth-/breadth-first search, bit-shifting, programming language properties, and all the other things you haven’t thought about since CS 101 though. Again, it may upset you that these things aren’t directly related to what you’ll be doing on a day-to-day basis, but it’s what you’re mostly going to be asked about.
5. On-site interviews
5.1 Length and energy
On-site interviews are LONG (6-9 hours). Interviewers tend to forget that whilst they are just about to start their segment, you may have not had a break for several hours. Even if you’re running behind schedule, it’s a waste of everyone’s time if you have pillow-head (lit. - your head feels like there is a pillow inside it) so make sure you ask if it’s OK if you go and grab a Mars Bar and a cool glass of milk if you need one.
5.2 Other people
At the majority of software engineering interviews, especially in larger companies, you aren’t competing against other interviewees. If a company likes you, they’ll make you an offer, regardless of whether they dis/like someone else. So you don’t need to focus on accidentally nudging other interviewees down an elevator shaft to their doom.
5.3 Misc
The first on-site interview of your job search won’t necessarily be terrible, but it will be much worse than your last.
Hopefully the day includes at least 1 meal; they’re the best time to get a sense of how the team interacts and whether you’d enjoy being a part of it.
6. Post-interview
6.1 References
A surprisingly large number of companies want references. Line up 2 or 3 people you have worked with (at least 1 of whom managed you) and brief them beforehand. Share a Google Spreadsheet that tells them who wants a reference, by when, and any special instructions. It can be incredibly easy to lose track of these things and waste valuable time at the crucial offer stage.
6.2 Don't worry
It’s easier said than done, but don’t worry about what did or didn’t go well. You don’t know what they were looking for, and even if you did there’s no point worrying about whether they found it.
7. Negotiation
7.1 Patrick McKenzie
Patrick McKenzie (patio11) has written up pretty much all the advice you’ll ever need. Everything that follows is stolen directly from there.
7.2 Don't start negotiating until yes-if
Yes-if means “yes you are hired, if we can reach a deal.” This is a strong position for you to be in.
No-but means “no we aren’t going to hire you, but I guess maybe we could if you lowered your salary requirements.” This is a crappy position for you to be in.
If you give a company a number before they’ve said yes-if, then you leave the door open for a no-but. You want to start negotiating at your strongest point - when they have said “we love you, let’s make a deal.” You also want to be able to use your other offers to either increase your number or prevent it from decreasing, which means delaying talking about it until you have or are close to several yes-ifs. If you are asked for a number before you’re told yes-if, politely say you’d prefer to work out if there’s a fit first, and only start talking details then. Stonewall ad infinitum if necessary.
7.3 Negotiation is not scary
Engineers are not good at negotiation. It seems like a scary, alien thing where you feel very exposed and open to ridicule and failure. However, only 1% of negotiation needs to be thinking of a big number and Jedi-mind-tricking your way towards it. The other 99% is having several viable options and making reasonable statements about their relative attractiveness to you. With strong BATNAs (Best Alternative To a Negotiated Agreement), everything becomes much simpler. You also feel less stupid saying an aggressively big number, because it’s probably only incrementally bigger than what someone else is already offering you.
At any point after you get the yes-if, the worst they can say to your counter-offer is no.
7.4 Negotiation is not vulgar
People in startups (as well as many other professions) generally like to think that they are doing some version of “changing the world for the better.” And whilst this is a good and noble-ish thing, it can make you feel like a tool when you start talking about and debating salary and equity. After all, you should be doing this job for love, not money. Right?
There’s a great Dilbert cartoon where Catbert tries to sell a prospective employee on the many intangible benefits of working for his company. The prospective employee politely suggests that Catbert’s stockholders might prefer to have his intangible benefits, and he’ll take his compensation in cash if that’s OK. It’s not at all vulgar or unreasonable or disloyal to want to feel fairly materially compensated, and any suggestion that there is anything wrong with negotiating in good faith with a profit-seeking enterprise is entirely disingenuous. Equally, it is completely reasonable for a hiring manager to be protecting the company’s interests whilst trying to reach an agreement that works in context for both you and the company. If everyone is communicative and pleasant then it can and should be a mostly painless process.
7.5 Market rate is market rate and options are worth what they are valued at
Early-stage companies tend to claim poverty and offer salaries at anything down to 60% of market rate. I’m sure you could find even lower examples without much trouble, and these are theoretically offset with “generous equity grants”. However, you should keep in mind that the value of options for 0.1% of a company is 0.1% of the company’s current value, and in fact somewhat less due to their strike price and other complications. If a company is currently worth $10m, options for 0.1% are worth $10k. Vesting over 4 years this is $2.5k/year. It doesn’t matter what magic you can weave in Microsoft Excel by dragging a 3x growth multiplier 5 years into the future; these options make up for less than a $2.5k delta in salary, and even-even less if you factor in a risk discount.
If you’re thinking about working for a fairly early-stage venture, you probably like them quite a lot and are probably comfortable taking some degree of a hit to your compensation. But options aren’t some magical, mystical salary equaliser. They have a very easily calculable value, and it’s probably not actually very much. If a company wants to give you equity instead of cash then that’s fine and great, but if you’re going to be missing out on a lot of cash then you should be getting a lot of equity in return.
7.6 Understand your offer
Far too many offers come through as:
$Xk/year
10,000 options
This is literally equivalent to:
$Xk/year
$100bn in monopoly money and bingly bongly bangly boo
You have to find out the last round valuation of the company, the total number of shares issued, and the strike price of your options, otherwise an option grant is completely meaningless. It’s not rude to be persistent in trying to find this information, and it’s not distasteful to ask to be walked through the details of the offer until you understand it. Don’t comment on whether you are happy with an offer until you are clear what it actually is.
7.6 Calm down
This is all incredibly unintuitive and unfamiliar for most engineers (myself included), but is incredibly important. That said, it’s easy to be too quick to fly into slightly-hostile-negotiation mode once a first offer comes through, without making it clear that you really appreciate the company’s interest and offer and really like them and what they’re doing, but don’t feel that the deal as it stands fairly reflects your value or matches up to your competing offers. It’s good to negotiate, but you should still be polite, understanding and open-minded about it.
Conclusion
It’s a great market to be an engineer, but finding the right job still requires a lot of time and effort. Spray applications anywhere and everywhere you like the look of, and see what sticks. A little organisation will go a long way, but a little over-thinking will quickly make you go insane. How best to conduct a technical interview process is a hot and very worthwhile topic of discussion at the moment, but just go with whatever is thrown at you, regardless of what you think is and isn’t a good hiring strategy. Unless you think a company is being unreasonable or exploitative, your own interview is vanishingly unlikely to be the time or the place to try and change a company’s interview practises. You can always make yourself an instant hero on your first day by explaining to your interviewers in exacting detail all the ways in which they are idiots.
During your job search you’ll solve some delectable puzzles, meet some heavyweight people and see inside some very zany office spaces. You’ll say some face-meltingly intelligent stuff and commit some rusty-scissor-apendectomy-esque blunders. And hopefully, with the right combination of luck, skill and more luck, you’ll even come out the other side with a job. Good luck!