How to Hire Engineers at Every Career Level

Right now, tech teams are growing, the market for engineers is lightning-hot, and hiring managers are having to make recruiting decisions quickly that will affect them for months or years. 

To achieve this growth, as a hiring manager, you must quickly assess the skill level of the engineers you’re hiring. But you can’t really get a valuable assessment of someone’s applicable skills through a contrived, 30-minute coding challenge doesn’t provide a very deep view of their knowledge. So, how do you make this assessment both efficiently and accurately?

At Method, we’re currently experiencing this same growth challenge, hiring double-digit numbers of engineers across multiple projects and clients (and if you’d like to join us in that growth, we’re hiring!). 

For context, we’re a consulting firm that builds custom enterprise software across a wide array of industries. So, by design, we mold our processes and teams to fit whatever tech stack our clients require.  We also have a responsibility to teach our clients along the way, so that when our project is fulfilled, they aren’t left struggling to manage something they don’t understand. This flexibility means we aren’t married to a specific tech stack like many product companies are, and we highly value soft skills. But the hiring guidelines we use can apply to any team.

Here’s how we assess skill levels, culture fit, and teamwork, and what we look out for as a red flag at each level.

Enhance All Your Processes With Paul RoweSpeed Up Onboarding for New Developers With This Guide

Totally Junior

A “totally junior” candidate is someone who hasn’t pushed production code; they’re totally green in the tech world. Usually, this type of person is fresh out of a coding school or college or is making a pivot from a closely related field. Engineering teams often overlook people at this skill level, seeing it as risky — how can you know that this field will “click” with this person and that they’ll stick around and be productive?

What I look for

Skill level is hard to assess in this type of applicant, so I probe for attitude, teachability, and the ability to quickly pick up a concept and apply it.

I’ll ask them to talk me through a certain scenario like explaining a hypothetical model for building a very simple app or feature and handling its data. They’ll probably stumble during this test, and I’ll guide them through it. As they see their missteps during this guiding process, I assess whether they’re actually thinking about and applying what I just explained. I’ll ask them to dig in deeper on why they’d choose to do something. Any answer is acceptable, even if incorrect, because I simply want to understand how they think through problems.

Red Flags

I’m also looking for curiosity here. If the candidate simply takes the guidance and corrections and moves on to the next step without digesting it first, I see that as a strong indicator that they will require a lot of hand-holding and have to be shown the answer to complex scenarios, instead of taking initiative to try to solve it on their own. 

I also assess attitude — is this person getting flustered or frustrated, or are they surprised and excited that this interview is actually teaching them something? Having a growth mindset is 75 percent of what makes a total junior into a viable candidate.

Junior

Junior candidates have some light experience, usually having published a couple of personal projects or held a short first job. They’ve seen their code in production.

What I look for

I want to see that a junior applicant knows where they’ve been and has some idea of where they’re going. Can they explain what they’ve learned up to this point? What do they want to learn next? Where have they struggled? This step is about determining whether things have clicked for them up to this point. This assessment takes a bit of the risk out of junior-level hires because you establish that they’re teachable based on their previous experience.

Red Flags

Watch out for excuses. At this point, junior candidates have likely made a bunch of mistakes in their learning process but aren’t aware yet that mistakes will be prevalent for their entire careers. Do they take these mistakes and learn, or do they avoid responsibility for their mistakes with excuses and finger-pointing? At this level, I’m seeking a collaborative teammate willing to mess up and keep trying.

Mid-Level

Mid-level engineers have been around the field for a bit, usually two to four years. Give them a tech stack they’re familiar with, and they’ll be able to build you something with some light guidance. 

What I look for

I want to see candidates who can explain all the important parts of their favorite tech stack and how they work together. They can explain why one style or pattern might be better than another. They have opinions about libraries and frameworks. They can nerd out in a casual discussion when asked more subjective things like, “What do you think about react moving to hooks?” This person should also feel very comfortable collaborating, giving and receiving critical feedback, and mentoring more junior developers.

At this step, a coding exercise may be useful, but not via take-home tasks. I prefer to inform someone ahead of the interview that they’ll be sharing their screen and writing some code, so they should prepare their environment however is most comfortable for them. Pairing happens frequently on our teams, so performing with someone watching is actually a required skill. Plus, I can assess how they think through problems, how comfortable they are with their editor and tools, and general aptitude with the tech.

Red Flags

Beware a lone wolf. These types of people will typically put their heads down and do their thing alone. This approach doesn’t do well for growing with the team. In this field, we value knowledge sharing, teaching each other and our clients, and helping to build a stronger team.

Senior

Senior engineers can be fully productive as they learn about the product and can reliably guide the team on technical decisions while still getting comfortable with the subject matter. They can anticipate issues during a planning stage and can propose solutions to non-technical stakeholders with ease.

What I look for

Senior engineers should demonstrate mastery in a chosen stack and have no issue with showing it. They are comfortable mentoring junior developers. They have thorough opinions about various choices in technology and can explain why they made certain tech choices in previous roles. They prefer simple solutions to solve categorical problems and can confidently weigh the cost versus the benefit of various solutions.

Red Flags

Taking a page from Jane Austen, I watch out for pride and prejudice here. If senior engineers dismiss others due to their lack of experience, demonstrate cocky attitudes, or speak badly about their peers, they can become a toxic member of the team, even if they’re extremely capable. Senior team members have a responsibility to bring less experienced teammates up to their level, and being open-minded is a key part of that process.

I also am wary of seniors who default to heavy, complex solutions that aren’t easy for others to pick up and implement.

Principal/Architect

A principal engineer, or architect, has seen a large variety of systems and can diagnose categorical problems across the stack. These folks can architect solutions and predict where issues may occur. They can anticipate the implementation plan for entire systems and assist non-technical stakeholders with assessing the viability of a plan.

What I look for

I mainly ask questions about the breadth of their experience and how they came to solutions for the systems they’ve architected in the past. Since this person must form a plan that will be communicated to non-technical stakeholders, I care immensely whether or not they can convey these concepts in a way that doesn’t make my eyes glaze over. This role provides a crucial element to many systems, so they must be able to discuss the ways they interact with other teams and stakeholders to assure that their plan was put in place effectively.

Red Flags

Avoid hard-line, inflexible planners. This person must be amenable to adapting their plan to changing circumstances on the fly. Especially with systems, it’s extremely difficult to predict whether your plan will actually work, and it’s unlikely that it will be the same in a few months. I look for someone who’s ready to admit fault, call an audible, and accept new requirements when they least expect it.

More in Software EngineeringHeadless Versus Integrated Architecture: What’s the Difference?

Step Up Your Hiring

We can teach anyone technology, but we can’t teach team dynamics. Our highest priority is for someone to be enjoyable to spend 40 hours a week with, who’s willing to learn and grow, and who is excited to bring others on that journey with them.

If you’d like to work with us at Method, we’re hiring designers, engineers, product strategists, and more!