Trying to find your first dev job? Here’s what employers are actually looking for.

Finding a job—any job—is hard. Tiring. Confusing. Time-consuming. 

Finding a job in a field that you’re new to is all that on steroids.

For the past seven years, I’ve been lucky to help build Flatiron School and help our students find their first jobs as developers. 

Our team has seen over 10,000 interview processes, usually from both sides: We work closely with grads, as career coaches help them navigate their first steps into the market with one-on-one guidance, and with companies, who work directly with our team to hire technical talent. And our grads do impressively well on the job market. 

That’s all to say, we learned what it takes to land a job as a brand-new dev. (And if it turns out you’re not looking for a dev job, this still works—the methodology we use applies to almost any job.) 

Interview processes run the gamut from a few conversations, to hours of writing code on a whiteboard, to evaluative social events with the team. It can all seem very mysterious and nerve-wracking from the outside. 

But here’s the big secret: No matter what kind of process you step into, the hiring team, really, is only trying to figure out three things.

That’s it. 

You might get asked hundreds of different questions, but all of those questions are, in one way or another, trying to get at one of those three important things. If you can focus all your interactions with the company on proving you’re a “yes” to these three questions, you’ve got a very good chance of getting the job. 

Those three things are:

1. Do you have the skills to do the job? 
2. Will you be an overall positive contributor to the team?
3. Can you learn quickly enough to get the skills you’ll need later? 

Two important things to know about the three things: 

1. Many hiring teams can’t quite articulate that this is what they’re looking for. 
2. Even if they can, most will tell you they don’t know how to test for these three things with 100% accuracy—that is, no false positives and no false negatives. 

This is a challenge for hiring teams, to be sure. But it’s a giant opportunity for you. 

I had a chance to chat with Sara Chipps, Paul Ford, and Ben Popper about this on the Stack Overflow Podcast recently, so head over there if you want to hear how this process plays out over a few interview questions (where Paul played hiring manager, and Ben was a very good sport). 

We’ll spend the rest of this post on why these three things are so important, and how you can showcase them. 

Do you have the skills to do the job? 

What: This is the simplest one, and this is what most people think they’re trying to show when they interview: If we dropped you at a desk right now, could you do the work required to perform the role? Could you deliver valuable output for our company tomorrow?

This is the ostensible primary purpose of the whole interview process, and in most interview processes I’ve seen—especially for technical positions—this is the part of the process that gets the most thought and attention from the employer. 

All this part of the process wants to know is: Can you accomplish the work that we need to get done here?

How: Just because you’re put through the technical ringer during a live-coding challenge, doesn’t mean that’s the only way to demonstrate you have the skills. If you flub a part of the process, double back and revisit it. Re-tackle the challenge in a blog post and send the interview team your corrected answer. Build a small app with the technology that tripped you up in the interview room. Build a webpage with some cheeky pseudo code that animates your path to your previous error and re-codes the example on the right path. 

One of the biggest fallacies of the interview process is that it’s linear and binary: I give you a challenge, you pass or you fail. If you pass, you receive another challenge, and if you pass enough times, you get a job. That’s not true. It’s up to you to demonstrate that you have the skills to do the job, and it’s up to you to figure out how best to do that.

There are endless ways to showcase your skills. Get creative, pick one, and put in the extra work to let your competency shine.

It’s important to note that there’s one kind of organization where this is unlikely to work: At companies like Google, Facebook, and Twitter, or “cool companies,” as Bill Burnett and Dave Evans call them in their excellent book. These companies, in short, don’t care much about false negatives. They’re flooded with qualified talent, so if you don’t pass their process, they’ll move onto the next person—while false positives can be quite expensive, a false negative doesn’t cost much when you’ve always got dozens more high-quality candidates in the wings.

Will you be an overall positive contributor to the team?

What: In addition to the ability to do the blocking and tackling of the job, companies want to know if you’ll be a good team member. Can you contribute beyond your role? Can you behave in a way that’s in keeping with the company’s standards? Outside of your work product, will you deliver something valuable to the organization?

Some places call this culture fit—at Flatiron School, we evaluate candidates for values fit—but this ultimately boils down to contributions and operating behavior. General ability to contribute is nebulous and hard to define, but every company I’ve ever talked to strongly emphasizes that they want to hire people who will contribute positively to the organization.

How: Here you have even more latitude than in the skills requirement, because you’re less likely to get asked specific questions about your ability to be a great contributor to the team. Companies often evaluate this as a function of how you answer other questions, or with behavioral questions, like “tell me about a time when you solved a hard problem” (that’s the one Sara gave Ben on the Podcast). This, again, is a big opportunity for you. 

Imagine all options are open: How might you prove that you’re great to work with and great to have on a team? 

You might prepare stories about how you went above and beyond in your previous job to help colleagues solve problems not in your job description. You might write a cover letter that’s all about ways you’ve demonstrated the company’s values in your life and career. You might simply demonstrate empathy and curiosity during the interview, making sure to use your Q&A time with the hiring team to ask about their biggest challenges and most burning priorities. Bonus points if you can figure out a way to make productive suggestions or contributions to these in a follow-up or discussion later on. 

Can you learn quickly enough to get the skills you’ll need later? 

What: If you’re a technologist, you know that tools and technologies change at head-spinning speed. It’s unlikely you’ve used all the tools the person in this role uses now, and it’s almost a certainty that you don’t know the tools this role will use two years from now (the company probably doesn’t, either). In such a fast-moving industry, this might be the most important feature of a candidate’s profile and the one most valuable to a company. It’s also the most difficult to evaluate. 

How: Good news: If you’re a new developer, you’ve just demonstrated how fast you can learn. You picked up the skills to do the job over a few months at a coding school, during your major at college, or over many hours of self-study. That’s a great story to tell and, assuming you do in fact have the skills to do the job, one that should inspire lots of confidence that you can pick up new technologies. Have a crisp narrative around this experience that earns that confidence. 

Companies often want you to be able to learn fast and independently, so in addition to however you learned how to code, you can demonstrate you’re a fast learner by picking up a new technology or concept in real-time and sharing your progress with the employer. That might mean building something small on the company’s API, expanding on a technical concept you find on their blog, or building a dynamic version of your resume in their preferred front-end technology. 

Empathy wins jobs.

When you’re in a job-search setting—and that includes everything from trying to get in the door for a first conversation all the way to accepting an offer—companies want reassurance that you can do these three things. Any communication you send, any question you’re asked, pause and ask yourself: Which of the three things is this trying to get at? 

This comes down, as Paul eloquently put it during our conversation, to empathy. Put yourself in the employer’s shoes: If you didn’t know you, what would it take to convince you that you have the skills, ability to contribute, and learning horsepower to succeed in that job?

If you can thoughtfully demonstrate you’re a “yes” to these three questions all the way through the process, you’ll be heads and shoulders above almost every other applicant. Get really good at helping companies see a “yes” to these three questions about you, and your first dev job offer won’t be far away.