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:
- Do you have the skills to do the job?
- Will you be an overall positive contributor to the team?
- Can you learn quickly enough to get the skills you’ll need later?
Two important things to know about the three things:
- Many hiring teams can’t quite articulate that this is what they’re looking for.
- 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.
13 Comments
So basically all we need is empathy? 🙂
If only!
Interviewer: Describe a time when you were primarily responsible for managing a major project and how you dealt with an issue that arose.
You, looking for your 1st job with no experience: I have never done that but I can empathise that you’re seeing what positive contribution I will have to the organisation! Here’s a smaller scale answer that is still truthful and relevant.
…aaand you’re dead to them already 🙁
Great, I spent all this time with the computer cause I can’t stand people
Sure, sure, sure.
hmm, I think those questions are in the mind of a recruiter only after you pass technical questions..
I don’t think “empathy” means what you think it means.
I want to design software and always did especially going into Indeed websites and seeing the jobs for people with college educations who know their craft. Nothing was said about a certificate. I ant to earn that certificate with deferred tuition and pay it back in installments making 120$. I design greeting cards and write the verses and I am a published writer with an online portfolio under the name annelle. I up to the decision by you. Please know i am a serious student with deep convictions and a unique sense of humor/
It’s worth asking *why* there are so many applicants for every job.
A socio-economic asymmetry such as this – persistent for a decade and exhibiting ever-increasing asymmetry – suggests something might be going wrong, somewhere.
Either getting a suit-and-commute job is as important for society as we’re all told it is and the economy is broken / unfit for purpose because it shows itself incapable of generating suit-and-commute jobs in sufficient number. (And will fail harder as more processes are automated).
Or getting a suit-and-commute job is much less important for society than we’re all told it is, which explains why the supply of jobs falls so far short – our socio-economy really doesn’t need more jobs. But then we should question the dominant narrative that getting a suit-and-commute job is a significant marker of success and it’s what we should all be focusing on. (That’s not to suggest it’s a deliberate mis-narration. It might be unintentional oversight by those who grew up in a different technological era and have failed to realise how rapidly we are approaching The End of Work).
Which is it? Is the socio-economy broken? Or is the narrative we’re being told by boomers an anachronism?
I feel that this article is missing the point. How do these tips help people trying to find their *first* dev job?
Finding the first one is the hardest, esp. if you come from a non-tech background. It’s often about the experience paradox: companies searching mostly for the experienced developer which makes it hard to get a foot into the door. (Coupled with the fact that the interview processes hardly reflect your actual workload, it’s more similar to a lottery.)
This becomes even more misleading as you claim that one of the biggest questions is: “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?”
Any wanna-be new developer reading this will now die of anxiety and imposter syndrome even though the the answer to that questions is (with some exceptions) a resounding NO.
No, I won’t deliver valuable output tomorrow. Tomorrow, I might finish the setup of my computer / laptop. I might start adding value after two weeks, while still reducing the overall output of the team due to the added friction of the on-boarding process. My full potential may only be reached within 6 months.
Adding a new member should be seen as an investment and be treated as such. And that changes the framing of an interview: Can I convince people that I am worth the investment? Am I a good enough fit that I can start there? Can I demonstrate that I am able to learn, reflect, and communicate honestly?
And it works in the other way too: Do I have the feeling that I can learn and grow?
Your tips read like you as a candidate have to try to convince people that you have certain hard skills (even if you don’t).
I always prefered candiate that would flat out say: “I don’t know that” instead of trying to bullshit their way through an interview. As often, these question are not: “If you don’t know that you fail” but: “How much do you know and not know so I can get a feeling how much I need to invest in you and if you’d be a fit for the team”.
I also object notions of having to “put in the extra work” for a job interview. Of course, I have to show effort, yet this tip reads like a recipe to burn-out in my mind. If you have to go out of your way to land the job, how much do you have to go out of your way to keep it while remaining your sanity?
“Tomorrow, I might finish the setup of my computer / laptop. I might start adding value after two weeks, while still reducing the overall output of the team due to the added friction of the on-boarding process. My full potential may only be reached within 6 months. Adding a new member should be seen as an investment and be treated as such. ”
Given that a standard dev seems to hold a job for only 9-18 months now, is this realistic? I’m not sure that someone who requires that level of support is employable.
I think six months is actually pretty reasonable. Ran it by a fellow programmer, they thought so too. I think you’ll definitely get net positive value out of any decent hire after a month or so, but “full potential” really requires a lot of integration — knowing the codebase, understanding the product, gelling with the team, etc, etc. Sure, if it’s a small codebase or brand-new project, ramp up time should be less, but any mature project has some serious onboarding cost. No longer needing to ask questions of devs who have been around longer on the project can take quite awhile.
The 9-18 month turnover thing plus this idea sure is chilling, yup! But don’t make either wrong! 😀
If your company has such a high turnover rate, it has a different set of problems. If a developer can find a better job after 9 to 18 months, all the power to them. An employee doesn’t mind going through the onboarding process. The company does (better: should).
Which is why I said: Hiring a new employee should be seen as an investment. I have my current job for 5 years, and only starting feeling comfortable in the project after 4 months. I also learned two new languages, and of course I was less productive while learning the technology. I was aware of this, my dev manager was aware of this, so it was fine. It’s about managing expectation in both ways.
That being said: There are cases where a new employee can start within the first week to be productive, though that really depends on their prior experiences and knowledge and the scope of the project(s). And even experienced people sometimes change technology stack when starting a new job, which means that even those very experienced people may need over a year to really get going. (It still can pay off for the company, if it keeps them after they learned the ropes.)
Which is why I find that this article sets the wrong expectations for *new developers* trying to land their *first job*. As an absolute newbie, you won’t perform at 100% right away and that is fine. If your company (and you yourself) expect to be able to do everything from day 0, you will maneuver yourself into burnout territory at ludicrous speed.
These stories also might give you perspective:
https://dev.to/xngwng/after-you-start-a-new-job-as-a-software-developerengineer-how-long-it-took-before-you-feel-you-are-very-productive–fb
To me “empathy” means: to put yourself into other person’s shoes to see things from his/her perspective so that to be able to speak her “language”, be on the same page to find common grounds.
Food for thoughts:
If you are a young, skilled, but less-experienced job seeker, think of yourself as a fledgling start-up, a growth stock. Why should investors be interesting in you? (growth potential, ROI, long term investment, etc.). How do I attract/convince them?
If you are a more-experienced, therefore more-skilled job seeker, think of yourself as one of the well-known stocks such as Apple, Amazon, Netflix, Facebook, etc. When are these stocks attractive to shrewd investors to scoop them up? (value at a discount, well established, on trajectory, etc.) How do I attract/convince them?
If you are a highly-skilled, most-experienced job seeker, you choose your own battle on your own terms.