Fast-growing startups tend to hire more experienced engineers since there is a belief that supporting early-career engineers slows teams down too much. This belief leads to teams being “top-heavy” from an IC perspective and contributes to all sorts of sustainability problems for teams later on.
To combat the perception that the only viable solution for a fast-growing startup is to hire experienced engineers, we aim to equip hiring managers and their teams with the knowledge to source, interview, and integrate early-career engineers successfully.
An early-career engineer is anyone who has no prior or limited (loosely defined as less than 12–24 months) professional work experience in an engineering-focused role. An early-career engineer could be someone who recently entered or reentered the job market, just finished their studies, or is transitioning into a new career.
You may want to consider an early-career engineer if some of the following statements apply to your team:
- Your team composition consists of mostly more experienced engineers.
- We loosely recommend a ratio of 2:1 experienced to early-career teammates.
- This ensures there are sufficient teammates to support and mentor the early-career teammate.
- It also allows other teammates to take PTO as needed without the concern of the early-career teammate not having the appropriate support.
- You have a backlog of well-defined work that is ready to be executed.
- Early-career engineers are focused on learning, growth, and establishing themselves as contributing teammates. It is therefore vital, especially in an async all-remote environment, that work is well-defined.
- You have teammates who want to advance in their careers by providing mentorship to others.
- Early-career engineers may need additional levels of support in various forms like work definition, pair programming, PR review, coaching, and mentoring.
- You are looking for ways to enhance the diversity of your team
- Hiring early career engineers increases the pool of candidates you can consider and gives you more opportunities to hire someone who would add to the diversity of your team.
The above statements are guidelines only. It is up to the team’s manager to make a correct determination on whether their team is ready to support an early-career teammate.
Before preparing to post your job description, it’s vital to set up the right environment and expectations within your team:
- Commit to hiring an early-career engineer from a timezone the team can also commit to making themselves available.
- Talk with the whole team in advance to prepare a plan to support the new engineer; consider having another engineer on the team “sponsor” this new teammate beyond the initial onboarding period.
- Create, emphasize, and re-emphasize a culture of blamelessness amongst your whole team.
- Treat learning (for the early-career engineer) and mentorship/pairing/teaching (for other engineers on the team) as 1st class responsibilities of each member of your team for at least their first six months.
- Avoid making restrictions around what domains, responsibilities, initiatives, etc., the early-career engineer can participate in.
This framework intends to complement the standard processes defined by the Talent team to ensure a higher success rate.
Your first step is to meet up with your department’s recruiter and work on a strategy to find the right talent for your team’s needs. You will follow the standard process to kick off a search and identify candidates.
The sections below will help you to understand what to consider.
Follow these tips to ensure your job description is appealing to early-career candidates:
- Specifically, call out that you are open to/looking for early-career candidates.
- Focus on skills and characteristics rather than experience.
- Indicate the mentoring the teammate will receive on the team.
- Emphasize that candidates would be joining a team where it is safe to fail and treat mistakes as opportunities for continuous growth, regardless of the engineer’s level.
Your primary objectives with inbound sourcing are to:
- Make the job description appealing and encouraging.
- Convince candidates that you will provide a nurturing environment for them to grow.
Things that might scare away early-career talent:
- Lack of mentorship/growth opportunities.
- Specifying the years of experience in a job description.
- Too many/too few responsibilities.
Things that might encourage early-career talent to apply:
- Equal parts potential to learn and potential for impact.
- Encouragement to act with agency.
- Mentorship opportunities from engineers at all levels and across different teams.
- Ability to hone in on their career opportunities and find what drives them.
Consider the following communities when reaching out to early-career candidates:
Some recruitment agencies/platforms have a specific focus on early-career talent and can be helpful in not only sourcing candidates but also evaluating them. This could save you a lot of time in the screening process.
Below you will find a list of possible agencies/platforms you could use. Always consult the Talent team before approaching an external partner.
Faced with many candidates to screen applications for, how do you identify which candidates are suitable?
A possible challenge with early-career candidates is that there is often not much work/project history to consider to give you insight into their performance and ability. So what can you focus on instead?
Here are some aspects that you might want to consider when identifying suitable candidates:
- Passion - do they show a keen interest in their chosen career, the company, and technology.
- Learnability - are they constantly looking to expand their knowledge and capability.
- Grit - do they have the ability to persevere in the face of adversity and push through to achieve success.
- Problem Solving and Critical Thinking - are they able to break down problems and think analytically about them.
- Initiative - have they made the extra effort to further their career development? This comes in the form of classes, bootcamps, or taking on a project outside of work.
What you are looking for is a candidate with the right attributes so that with the proper guidance and experience, they are likely to be a high-performing teammate.
To help set you, the hiring team, and your candidates up for success, we offer the following guidelines for navigating the interviewing process.
What follows is a collection of tips for each stage of the interview process for you and your team to use once you are ready to start the hiring process.
However, the most important resource available to you is our amazing recruiting team! The #hiring slack channel is your direct line of communication with this team to ask questions, practice giving an interview with someone, or get any other support you need. Hiring managers and folks who have participated in early-career interviewing are also always encouraged to help out!
- Weight the candidate’s demonstration of core company values on the same level as relevant work experience.
- Be upfront that [the team, the company] does not have so many early-career engineers yet, and be ready to answer questions about what the company is doing to support these members of our teams.
- Note in the interview prep that it’s helpful to take a few extra minutes to put the candidate at ease to calm their nerves and show up as their best selves.
- Note in the interview prep that it’s helpful to ask follow-up questions and reframe questions to help the candidate share their thoughts more easily (this doesn’t need to reflect poorly on the candidate automatically).
- Assess the candidate’s ability to learn in addition to their skills; often, early-career candidates more than make up for lack of experience with grit and will.
- Design a project to showcase the candidate’s skills to complete independently, with less pressure than demonstrating it live.
- For candidates shifting their career focus, consider how experience in other industries could translate to value for this role (for example, how a previous background in marketing becomes a value-add due to expertise in communication).
- Resist overvaluing where they went to school, which bootcamp they attended, or which company they interned at.
- Avoid asking about gaps in the candidate’s resume or why their path took the directions it did.
- Keep in mind that what could look like “job hopping” (when a candidate has a few jobs on their resume where they only stayed a year or so) doesn’t automatically indicate poor performance; there are lots of reasons candidates switch jobs frequently (self-discovery to try to figure out what they want to do; self-respect to get out of an unhealthy situation, etc.).
- When preparing a question, consider if the question might inadvertently be too specific; in other words, does your question become harder to answer if a candidate lacks a certain educational, professional, technical, or cultural background? For example:
- Instead of asking what a candidate’s favorite class was, ask the candidate to share something interesting that they learned recently
- Instead of asking the candidate how they’ve debugged an issue in production before, ask the candidate to describe a gnarly debugging experience they’ve had
- Take a moment to consider how different factors may impact your evaluation of the candidate that may not directly bear on their ability to perform in the role. For example, how might your perspective have differed if they:
- were older/younger
- spoke more/less familiarly
- had spent more/less time in school
- had started in the same/a different industry
- were more/less tech-savvy
- were more/less “nerdy”
Many of these practices are not specific to early-career hiring, either! After an interview, it can be helpful to reflect on whether the interview may have felt easier or more challenging than other interviews; often, this doesn’t have to do with the candidate’s skills or abilities, but simply that it can take more time and effort to build a relationship between people who have less common ground at first glance.
To further train your bias-catching muscle, check out Pamela Fuller’s The Leader’s Guide to Unconscious Bias.
- Avoid asking technical questions that require familiarity with specific languages, patterns, or paradigms to answer; the vast majority of concepts that an early-career engineer will need to understand to be productive are language-agnostic, and those that aren’t can and should be the focus of their learning opportunities.
- Provide an overview of what candidates can expect in a technical interview so that you start on the same page together; it’s common for early-career candidates not to be familiar with how our technical interviews are conducted, and it’s okay to help them understand.
- Make it clear when you think the candidate is doing well to continue showing you their best selves.
- Encourage the candidate to pull from personal or academic experiences as much as professional ones.
- Read any technical prompts aloud before asking the candidate to dive in.
- Be as explicit and straightforward as possible.
- Remind the candidate to take their time if they need to.
- Err on the side of providing too many hints or too much positive encouragement over not delivering enough.
- Focus on the candidate’s thought process as much as their answers; often, understanding their thought process tells you more about their ability to learn and onboard than their direct answers.
- Practice giving an interview in advance, and seek feedback from #hiring on any questions or topics you’re not sure about covering!
It is essential to prepare when someone new is joining the team regardless of their experience, even more so for an early-career engineer. The following are guidelines to help hiring managers and their teams think about what a new hire’s development should look like and what the goal is.
The hiring manager should define:
- Expectations: what do you expect this new teammate to achieve, learn and do.
- E.g., values and communication skills or independence in certain activities
- Goal: what is the outcome the teammate should achieve and by when.
- E.g., complete specific tasks or own certain projects
- Roadmap: what are the milestones you want the new hire to achieve on their way to the goal
These definitions can and should change over time to best reflect the new hire’s interests. However, it helps to be clear and upfront in order to keep a healthy and productive dialog open with your new teammate.
There are several primary things to think about when coming up with good first tasks for your new teammate:
- Technical skills
- What technical skills or knowledge is most important for the new teammate needs to be successful?
- What areas are they most interested in?
- What does your team need?
- Context of the codebase (learn about how our code works)
- The reality is: docs will always be incomplete/imperfect (in life in general, not just here at Sourcegraph), so it’s a special skill to be able to learn a codebase quickly.
- Opportunity: use this reality to get good at self-directed learning of the codebase and improve the codebase docs.
- Soft skills
- How can the new teammate level up their communication skills?
- Are there basic working processes that they don’t know about and should work on? (eg: cross-team collaboration)
- Balance the needs of the team against the needs of the new teammate.
- Strike a balance between tasks that are too easy and too hard.
- Early feedback to the new teammate is valuable, so consider tasks that are not too large and have clear opportunities to engage other members of the team.
- Merging their first PR is an excellent early win and makes sure they don’t feel their contribution is insignificant.
- Make sure each new task clearly relates to the goals you’ve set. Recurring activities are welcome, as long as they mean something (like practicing a specific skill or making sure the new teammate understands how to do it), but be mindful of work that may feel too repetitive or mindless.
- Provide resources that support the practical task.
- It can be a document, a video, a skill (e.g., google this string, and you’ll find the different types of answers; how do I know which solution fits?; etc.) or even a session with someone in the team that provides context.
- Include them in the conversation and let them own their learning process.
- Teammates will bring their own experiences, knowledge, and expectations to the table. It is essential to include them in this process. They will feel involved and included.
- One of the easiest ways to help an early-career teammate feel proud of their work is to empower them to choose what they will work on.
Once you’ve identified some good options for the early-career engineer to start out with, it can help to write out on a document a couple of sentences of an overview of what each chosen task is and why it was chosen. This can help new teammates understand their work, keep track of their progress, and frame their work around what the rest of the team is doing (context is vital!).
Remember that an early-career engineer is someone who has the potential to be a senior engineer. They just need practice, guidance, and feedback. The goal for you and your team is to guide them rather than tell them what to do.
Take time to listen to them and make it a safe space for them to ask questions! Is there anything they don’t understand or struggle with?
- Differentiate between the types of questions you are getting. Is it that they don’t have enough code context, or is it that they don’t have the technical knowledge.
- Listen to questions without guessing/assuming.
- Be empathetic and understanding, remembering what it felt like not to understand.
Try not to give a fast answer to get them unstuck because our objective is for the new teammate to understand what is going on. We sometimes want people to find the answer themselves, but be mindful of how they are processing this and make sure it isn’t more harmful than beneficial.
Sometimes, knowing what question to ask can be the hardest part. It can be helpful to “temperature-check” if you pick up on areas that your new teammate has limited opportunity to explore or is less vocal about. This can be accomplished through naming how they might be feeling (e.g., “I have to imagine it might feel like …”) or asking how understandable or accessible something feels (e.g., “How well do you feel you followed when A was talking about …?” or “How comfortable do you feel responding to the feedback B left you on your PR?”). These conversations are generally more comfortable for new teammates to have in a 1:1 format, where it’s more apparent that the intent is to support rather than assess.
Share with them things that you are struggling with at the moment. Talking about what you don’t know or don’t understand makes everyone on the team seem more approachable and can help mitigate feelings of Impostor Syndrome.
Create a team environment where team members feel comfortable sharing
- When they learn something new that they didn’t know
- When they don’t know something and want to learn it
- When they are stuck on something for a long time
- When they put a lot of time into something that ultimately doesn’t work out
- When they realize something late
- When they get tripped up by a silly mistake
Let them know that they’ve been helping the team and talk about their achievements. It’s a great idea to record moments that signify their growth by:
- Writing down compliments that they receive
- Keeping an accomplishments journal and writing entries even for the tiny ones
- Brag document (this is an example of what an accomplishments journal could look like, but remember this is done by and for the teammate, so it can take any format they feel the most comfortable with).
Focus on creating an environment where everyone feels comfortable sharing their compliments and accomplishments.
Provide constant constructive feedback. Use the Onboarding Feedback Milestones as part of the process, but open a two-way communication channel. You need to share what’s on track and what needs attention on their part, and they need to feel safe asking for help and letting you know what you can do 10% better.
Keep in mind that feedback is very powerful, and we should think twice before giving it. Sometimes you need to ask yourself if the feedback you are offering is about your preference or a mentorship moment. (e.g., you might love the Oxford comma. Technically, it’s not required, so giving that feedback would be more about your personal preference).
Finally, make them part of the conversation and their learning process.