Where should I apply?

This a chapter of the book Get a Better Developer Job. It’s best to start at the beginning.

This chapter covers how to evaluate employers when deciding where to apply. You may feel that beggars can’t be choosers but keeping an eye out for your next employer helps you plot a straight path to it.

I’ve written about specialization and prestige. Both factor into choosing where to apply for your next job.

Aim High
Prestigious employers guarantee an easier time finding a job in the future. Partly because they do cool work, but mostly because if they hired you, you proved you can pass a difficult interview. Recruiters know this and will feel more confident about recommending you. This is not all the recruiter’s fault. They may want to take a chance on unorthodox candidates, but most don’t have the technical chops to accurately evaluate them, so they risk looking foolish (which leads to getting fired).

The list of famously hard interviews includes:

• FAANG
• Microsoft
• Palantir
• Airbnb
• Uber

In addition, good local recruiters will know of other companies in your area they consider prestigious, so don’t hesitate to ask. Often times these are startups created by people who left the above companies. If you think you’ve got a shot, the earlier in your career, the better, especially if you studied computer science in college. You want to get in before that algorithms and data structures knowledge evaporates.¹ In fact, if you got an offer from one of these companies and declined it, that would be a good thing to mention to your recruiter (along with why). Heck, put that in your LinkedIn summary if you want a flood of attention.

Of course, not many can get into those companies – that’s why they’re prestigious. Unfortunately, that line of thinking is self-defeating and prevents you from trying. Legendary coach Vince Lombardi has some words for you:

“Gentlemen, we will chase perfection, and we will chase it relentlessly, knowing all the while we can never attain it. But along the way, we shall catch excellence.”

So it’s OK if you don’t land a job at Google, because simply trying will make you qualified for tons of great jobs.

On Startups
If you are interested in startups, the general advice is to “learn before you earn,” meaning go work at a startup and learn how it’s done before starting your own. Elad Gil has a great article on choosing one (endorsed by the previously linked VC Mark Suster). The key factors, starting with the most important:

• Awesome people. Smart and connected. What would be your net worth be if you had hooked up with the PayPal mafia?
• Market, AKA industry. What’s hot and rising? If this job doesn’t work out, you want to be able to find another quickly while leveraging what you’ve learned.
• Personal marketability. What skills and resume flair will you accumulate that will help you get the next gig?
• Engineering brand or name recognition. Same benefit as selective employers above.

Read the whole article, it’s short but goes into greater detail, including what not to bother with:

http://blog.eladgil.com/2015/03/career-decisions.html

If you’re thinking that’s solid criteria for even established companies, I would agree. You may notice that the first and last deal with prestige (working with top people and at a place people associate with good engineering or quality products) and the middle two cover specialization of both domain (industry) and technology.

Evaluate the Team
Above we said to find awesome people, but don’t just go by the interview. Check out the LinkedIn profiles of the engineers and managers you’ll be working with, or even those who have recently left. See what they’ve accomplished. If you’ve got the offer in hand, consider talking to them further.

A big part of the team is its practices. For that, we have the famous Joel Test, which is still darn relevant. I might simplify it to five questions, slightly modernized:

• Do you do continuous integration? Continuous deployment? These answer all the source control and build questions. The latter is becoming a lot more common than it was.
• How do you deal with technical debt? All projects accrue technical debt when they have to code to a deadline (real or imagined). “There isn’t time to do it right.” OK, not right now, but when? Do they have quarterly cleanups? Or do they wait until everyone hates maintaining it, then rewrite the whole thing (risking second system syndrome)?
• Do you have testers? This says a ton about their view of software quality. If there are no testers, then coders test their own dog food. And you know how much the average coder loves to test.
• Do you do have code and design reviews? This tells you if there’s knowledge transfer within the group. Without that, there’s total code ownership, where you’re screwed if someone leaves or goes on vacation.
• Do you have quiet working conditions? Maybe telecommuting? This tells you how much you can get done in a day. There was a time when I’d say you should have your own office, but these days you’re blessed if there’s full height cubicles vs. an open floor plan. With the latter, you can put in 50 hours and 30 will be productive.

Evaluate the Leadership

I would advise that you consider how well the company publicly values engineers. Not all industries equal in this regard, and you can find out by looking at the company’s leadership page. Does the CEO have an engineering background? Do they list a CTO or VP Engineering, and how prominently? I’m frequently surprised that companies we think of as “tech” (it’s their competitive advantage or revenue driver) with large engineering departments don’t list one. I see this with media companies a lot, and most companies run by salespeople. Healthcare companies are known to value MDs most highly, and you’ll rarely find a CEO in that industry without one. This all affects low leadership perceives your role and how high you can climb if you’re interested in management.

Along those lines, look at the college degrees of top management. Some don’t mention them. Some all come from a few Ivy League schools. In others, it’s littered with PhDs, or MBAs, or even MDs. Again, how well you fit in with top management affects your ceiling. And that may be perfectly fine if you want a long career as a developer.

Help somebody's career:

Next chapter: Where to next?