What I look for when hiring Junior Software Engineers

/7 min read

advice

Recently I shared some advice on BlueSky:

Dear New Developers,

Do not—ever—generate code faster than you can explain it. To explain code you MUST understand 1) what it does, and 2) why it is implemented the way it is, and 3) the second-order effects of its its implementation.

You SHOULD have strong opinions about implementation details of what you are building. You MUST be competently familiar with a domain’s dimensionality; how familiar you are should govern what tools & references you employ, and how competent you are MUST steer your internal expectations of velocity.

You are not a manager of code generators. That is a marketing lie. You are a programmer; you compose fine computer instructions. You MUST develop velocity discipline—generating code faster than you can explain coherently leads to structural issues in your mental models that leak into your comments.

When I am interviewing young developers, I am not looking at how fast you can ship nor how much code you have in your portfolio. I am specifically hiring how you respond to not knowing something. Velocity discipline—slowing down and developing reasoning alongside your code right now—helps you grow.

Automation tooling, including code generation tools, are part and parcel of the work we do. But the tools are not the work; the tools help us DO the work. The tools don’t develop coherent mental models that we can explain—WE do. YOU do. And then you USE those tools to effectuate YOUR implementation.

Since this is coming from a place of having hired and mentored junior engineers over the past decade, I would like to expand on this a bit and share the kinds of things that I have personally looked for when interviewing people for entry-level/junior roles.

Not every company is going to look at you through this lens, but I can confidently tell you that the good companies to work for–the ones that aren’t out to tolerate your newness but rather cultivate your potential–will absolutely be thinking about these kinds of things.

# Social intelligence

The first thing I look for is how you work with other people:

  • Are you the kind of person who asks for help after 30 minutes of being stuck, or do you wait three hours (or three days?)
  • Have you received code feedback without getting defensive?
  • Can you explain what you’re working on to an engineering colleague who isn’t looking at your screen?
  • Can you explain what you’re working on to a non-engineering colleague who isn’t looking at your screen?
  • Do you read documentation before asking a question that documentation answers?

I generally consider most people in the world at the interview stage to be sufficiently teachable so long as there is some semblance of intrinsic motivation, so the rest of this, while centering on the work of software engineering, is more about setting expectations for your manager/mentors than it is about assessing your competence.

Remember: good organizations hire you based on your ability to learn, not your ability to perform.

# Broad technical familiarity

Once I get a good sense of a person’s social intelligence, I’ll start to ask about fundamentals–topics that every programmer should feel some sense of curiosity about. Depending on the role, these would be things like:

  • In what ways would a nested loop over 20,000 items be a problem?
  • How would you describe what a function does?
  • When a database query is slow, what are some possible culprits?
  • How does a web request go from browser to server and then back to browser?

This will generally lead us to fluency and familiarity with languages:

  • Can you write a working program in at least one language without looking up basic syntax?
  • What’s the difference between passing by value and passing by reference?
  • In what cases might we reach for a hash map instead of an array?
  • Can you read someone else’s code and predict what it does before running it?

That last point usually involves screen-sharing. I like seeing how people think and talk about code as we’re both looking at it.

Usually at this point we are well on our way into the weeds of stories, questions, etc. People who don’t have a storied work history will generally convey information about what they did in school, projects they’ve completed, things like that. If you don’t have a portfolio, that’s probably okay–but expect that most of the other people interviewing for your position will be providing some kind of showcase of what they have done before.

At the very least, you should be prepared to talk about your specific technical experiences.

# Specific technical experience

I want to know how you work and have completed things in the past:

  • What is your familiarity with git?
  • Are you comfortable in the terminal? If not, why?
  • When something breaks, do you form a hypothesis before changing code?
  • Have you used a debugger or logging deliberately?
  • Have you ever fixed a bug that wasn’t where the error message pointed?
  • Have you ever had to make your code handle input that you didn’t expect?
  • Have you ever integrated with someone else’s API or library and dealt with it not working?

Notice the pattern here: “have you ever…” It’s hard to convey aptitude for engineering without having something to show for what your aptitude can do. Notice I didn’t say “produce”; being able to communicate about your experiences with writing code can often be a more useful signal than just pointing at your past projects (if any) alone. After all, much of what you will be doing in software engineering roles will center around communication and collaboration.

# Parting thoughts

Expect more hiring managers to want to talk to you more often. With so much coherent generated code at one’s fingertips, it is more important than ever to screen for authentic attitudes and ambition. When everyone has access to tools that can produce artifacts that appear to communicate competency, expect people to look for things like:

  • Can you build something small end-to-end without a tutorial holding your hand?
  • What did you do the last time you were completely stuck?
  • Is there a link you can send someone?

I don’t think anyone should have to work for free to prove they can do a job. It’s often the case that the most enthusiastic hiring recommendations I’ve made are for people who happen to really enjoy writing computer instructions, and as such, have projects and repositories they can share. These don’t really tell the whole story–and they are definitely something people can lie about–but it does help to shape the overall story that someone is trying to sell of themselves.

All this to say that, no matter what, persistence and authentic curiosity will help you no matter where you end up heading or what you end up doing.

Be kind to yourself, kind to others, and commit to solving hard problems without outsourcing cognition, otherwise you will not develop the neural connections necessary to grow professionally and tackle problems of greater scope and impact.

And ultimately, your growth–as a person, as a programmer, as a human being–is something that you should care the most about. Tt affects the way you show up for those around you, and in doing so, influences your sense of connection with your fellow human.