Land that first programming job

This was one of the questions discussed last night at the Cascadia JS Scholar Success Mixer.

A special event bringing together CascadiaJS scholarship recipients with senior members of the JS community here in Seattle for an evening of networking and fun.

Now that I’ve left GitHub, I have more time to get involved in such events and ponder these questions with others.

What the hell do I know about this?

I’ll be honest, it’s been a long time since I had to do a job search. My first job as a programmer came right out of college when dinosaurs still roamed the earth crapping out startups like there was no tomorrow.

And to lean into this crappy metaphor, this was just before the big Dot Com comet came and burned them all to the ground. Really, how was Kozmo supposed to survive having bike messengers deliver me a Frappucino and a CD at below cost?!

Here’s a photo of me hard at work back then.

I found that first job through applying to a series of job ads when I was a senior in college. But after that, every other job I had came through a contact.

So I felt a bit unprepared to help answer the question about how to land your first job. I even asked if dice.com was still a thing, clearly identifying myself as a dinosaur.

It occurred to me that I might have something to offer. It wasn’t long ago that I was a hiring manager and that experience might be useful.

Hiring practices

Before I get into some tips, it’s important to understand that hiring practices differ widely. And most interviews are no better than random chance at predicting future success.

For example, when I was at GitHub, we adopted structured interviews because studies showed they had a better than random predictive validity. How much? 51%.

So slightly better than flipping a coin! However,

You might think 51% is really bad, but compare that to, say, basing hiring decisions solely on someone’s reference checks (26%). And it doesn’t mean that 49% of your hires are going to do inherently bad – it just means that, with that practice adopted, you’re essentially giving up ~49% of your hires to chance.

Combinations of practices can net up to 60% predictive validity.

A big part of GitHub’s hiring practices is to remove bias from the process. For example, GitHub doesn’t use your GitHub profile as a signal because whether you have time to contribute to projects on GitHub depends on a lot of other factors that may not correlate to being a solid performer.

Getting Noticed

The tips I will provide are not comprehensive. There’s probably much better resources a Google search away. These are just a few tips I want to highlight based on my own experience.

The first step is to get noticed. This is bidirectional. You need to notice a good place to work. And the good place to work needs to notice you.

Networking comes in real handy here. The more people you network with, the more opportunities you learn about. If you don’t have the benefit of a deep network, reach out to folks you know. Try and attend events like the Cascadia Scholars mixer. Attend user groups. Connect with folks on LinkedIn and note that you’re looking.

When you find a job you’re interested in, see if you know someone who works there. Or ask for an informational interview. The goal is to find out as much as possible what the company is looking for and what they value in an employee.

This last bit is important because you want their values to align with yours, or it’s not going to go well.

Applying for that job

A company like GitHub can get hundreds of applications for a given position. Reviewing that many applications can put a reviewer in a zombified state.

This is one reason that networking is important. It can uncover a smaller company that is a diamond in the rough and isn’t getting overloaded by applications.

In either case, it’s important to make sure your application stands out. For example, many applications have a short set of screener questions. This is not your opportunity to write a long manifesto. This is your chance to demonstrate competence and communication skills by answering the question succinctly.

I also don’t recommend spamming your resume to a bunch of jobs. As one who reviewed a ton of resumes, the ones that caught my attention seemed tailored to the applied position. It was clear to me they emphasized their experience that related to the position. Walls of text cause my eyes to glaze over.

Even with these tips, there’s a lot of luck involved.

Interviewing

If you make it passed the screeners, it’s now time to interview. Hopefully, you’re applying to a company that is committed to removing bias from its interviews.

If someone asks you why manhole covers are round, flip the table and leave. Those questions are useless and reflect an outdated approach to interviewing. You don’t want to work there. Unless, of course, you’re applying to a job making manholes. Only then is that question relevant.

Research the position and look online for the types of questions that might be asked. It goes without saying that you should be prepared to answer technical questions relevant to the position.

But be prepared that many questions will be situational. It’s good to think through situations from your own past relevant to the position and how you’d answer such questions. For example,

Tell me about a time you had to deal with a difficult peer. What did you do?

Many of the scholars I talked to at the mixer were folks making a career change. They had recently completed a developer bootcamp and were looking to land a developer position.

In my mind, these folks have a leg up on folks right out of college. They already have work experience and a work history to draw upon to answer such questions with.

But if you don’t have much work experience, when faced with such a question, note that you haven’t been in such a situation, but answer with what you would do if faced with such a situation.

For those hiring

Many of the readers of my blog are experienced software engineers managers, and leaders. I encourage you to get involved with mentoring the next generation of developers. Reflect on the anxiety you felt when you looked for your first job.

Also, I think many companies still have a bias against developer bootcamp in favor of recent grads with a four year computer science degree.

From my experience, a degree in computer science is great, but isn’t as relevant to day to day web development. If you’re hiring a React developer, a recent bootcamp grad who spent the last 13 weeks learning React can hit the ground running.

Also, bootcamp grads often are mid-career and exhibit the level of professional maturity that will benefit your team. I’ve had a lot of success with hiring bootcamp grads and completely changed my own outlook towards these programs.

There’s a lot of software jobs out there and a lot of people looking to fill those positions. I hope we can work together to match people up with a great opportunity.