So I'd say anyone looking for engineering work should aim to have at least one (and just one is fine) of the following:

1. A good (and well-known) school. MIT, Stanford, CMU, UW, Waterloo, you get the picture.

2. A good (and well-known) employer. FAANGs in particular. Ideally as an FTE but internships are good signals here too.

3. To be known for something you've done. Well-used open source project, well-known blog, that sort of thing.

(1) and (2) fall into the category of "social proof" [1] and whether you like it or not, social proof can take you pretty far in life. Like in my case, it didn't take that long from working at Google to getting cold-called almost constantly (and I guarantee you there's nothing special about my situation).

My own job seeking experience (pre-Google) tends to be pretty similar to the numbers in this post (applications to interviews to offers). For those of you sending out hundreds of applications let me offer you some advice because I see a lot of people making easy-to-fix mistakes.

Hiring is a popular topic on HN and you see the same comments. There are always people who call a hiring pipeline a failure because a good candidate got rejected. This is the wrong way to approach this. The process is asymmetric.

A candidate is trying to get through each stage of the pipeline and get hired by somebody. Ideally they want multiple offers to boost the offer they end up accepting. "Success" is accepting an offer.

Below a certain size, a company wants to fill a role. It'll have N applications and the pipeline is designed to have filters along the way to winnow down that number to fill the role. "Success" is filling that role with someone sufficiently good. They don't have to be the best. Technical skills matter but usually only to a point. You have to bear in mind that you are a cog that needs to fit into an existing machine. Each step of the process gets increasingly time-consuming so the more you can weed out at the earlier stages while still filling the role, the better.

Large companies are similar except you don't tend to be interviewing for a particular role. There is a constant hiring pipeline. Recruiting may well be a separate org. You can use this to your advantage.

So, let's make up some numbers for our waterfall:

- Recruiting receives 100 applications

- The 20 best get sent to a hiring manager

- They may well eliminate half for various reasons passing on 10 to one of their engineers

- That engineer may well filter out half too meaning 5 will get called

- 3 of those will get interviews

- 1 will get an offer, another will be the backup

Like I said, completely made up but still instructive. And I'd say it wouldn't be too far off the mark for a mid-sized company.

The first thing is you need to get through a company's recruiting/HR filter. Well they look at the requisition ("req") they have and try and see if the application seems to fit the criteria and I really do mean seems to. This is what I call the buzzword filter. Anecdote: I once had a conversation with a recruiter who said--and I'm not making this up--"I can see you have 6 years of Java experience but do you have any J2SE experience?"

Some of it isn't buzzword related. Like if the req calls for leading a team, they'll look to see if you've led a team in the past. Depending on the company, the seniority of the position and so forth, factors like your school and previous jobs may come into play. Length of employment is a factor here.

So how do we approach this to pass this filter? Well we need to cater our resume to the job posting and see how it fills the criteria. We need to have sufficient buzzwords but not too many and not any we can't back up. This may hurt us later. Then again, it's completely valid to try and pass through early stages and deal with that problem later.

One point to consider is that the half the applications the hiring manager may never see. To be fair, a lot of job applications are garbage. My numbers are actually pretty generous. I've had people tell me that 90% of applications can be immediately rejected.

The hiring manager will have their own criteria and biases. They're trying to judge if you're someone who will fit on the team. Here lots of short jobs can hurt. There are cultural factors too eg in the UK I found having contracting on your CV would really hurt you for full-time roles (this was years ago; I can't speak for the current conditions).

Basically the hiring manager is looking for red flags.

The engineer will typically be looking for technical suitability. It's from this point onwards that various (ideally cheap) negative filters are used to try and reduce the numbers further.

And this is what a whiteboard coding test should be: a relatively easy problem just to see if you're not an idiot. FizzBuzz is easy for a reason. Engineers fall into the trap of thinking the problem needs to be hard. This actually reduces the effectiveness of the signal as you've turned a useful negative filter into a crap shoot of whether or not you know the "trick". For example, I had whiteboard coding problem once to reverse bits. Turns out (I found out later) this can be done in O(log n). I had never had need for such a trick so didn't know it. So what did that test accomplish exactly? Bit-fiddling is applicable to certain classes of programming, just not any I had and (more importantly) not the one I was interviewing for.

An early stage startup may simply be the hiring manager responding to emailed applications and they'll hire the first suitably qualified candidate they find because they really don't want to be doing this. A larger company may filter everyone through and then pick the "best" to extend an offer to.

So when you apply for a position, I would encourage you to think about what process that company has for hiring and treating it as a waterfall that you need to get through. Find out what you can about their hiring process. If you can't find out, make up something that seems reasonable given the type of company they are and their size.

The most important step for your application is to make it through the first 1-2 filters as those tend to be pretty dumb. Your CV needs to stand out from a hundred others in some way. A known school or employer is a good one. Absent that, allowing them to see some evidence that you can communicate in written form and/or actually code is a big plus.

[1]: https://en.wikipedia.org/wiki/Social_proof