Your remote company can hire junior developers, too | Romina Suarez | #LeadDevAustin


Right, thank you, Meri. So I know for most
companies, some things that we belong to, we understand and value the need to have junior
engineers in our team. I know for me working with juniors, told me that I don’t really
get a concept until I can explain it to someone who is maybe early in their career very well.
And that supporting each other and supporting each other in remote environments, is possible.
And I learned these by working with some extremely talented junior engineers in remote environments.
For a while, years ago, I thought, to really support juniors, you had to be in the same
office. How will you — hm. How will you — (audio
cutting out) That you are there for them and support them
if you you meet maybe a couple of times once a week.
Now, I know when we think about hiring juniors, we are all, you know, a little terrified,
because — … my mic, oh, is this unabled? Sorry about that.
So I know thinking about hiring juniors in remote environments is a little terrifying.
We all fear that we won’t be able to support them correctly, we all fear that it may end
up ruining the beginning of their careers, because we are not quite as ready as we want
as remote companies to support them. We all worry that the team dynamics we work
so hard to create in a remote environment may be compromised by bringing someone in
who may not be ready. Not many of these concerns are directly linked
to remote, though. I think we all worry about those things in offices, as well.
We worry, most of all, that we won’t know how to help them. But the reality is, as much
as helping juniors is complicated, helping juniors — sorry, helping seniors build the
networks and the communication skills and the interdisciplinary skills that they need
to level up and go forward in their careers is also quite complicated in remote environments.
I’m Romina, I work in a remote-first, nonprofit organization, building technology to raise
the voices of marginalized people, and I want to tell you a little story about why these
matter so much to me. So about 11 years ago, I was starting my career in technology.
And as for many — at the time, I was working in an office. Now, it didn’t take any long
to realize that it was going to be really hard for me to cope with life in offices.
Based on I was feeling overwhelmed by the noise and chatter of the group, I was having
trouble getting things done that I knew I could do.
I just couldn’t focus. And in this situation, I did not succeed,
and did not last very long. So less than a year later, I was freelancing,
alone, to be able to work from home. Now, freelancing as a junior was kind of a
nightmare. Not only I had to learn the basics of being an engineer and do it kind of alone,
but I also had to learn how to market myself, you know, how to get clients, and I was always
terrified that the next gig would not come. But freelancing did give me work, my ability
to focus. I went back to being able to solve problems
that I was trying to solve in an office. I tell you this story because it would have
meant a lot as a junior engineer to have access to a kind of supportive remote teams that
I’m lucky enough to be a part of today, but whenever we speak about bringing juniors into
remote, the general agreement seems to be, we just can’t do it.
Well, this may sound reasonable, because remote is kind of new. If we believe remote is the
future, if we believe remote enables people to control their environment and perform better,
it’s time we find ways to bring more people into it.
When we expect seniority to enable people to work remotely, we are kind of preventing
people who may not be able to thrive in an office from working, but what’s more is you
really can’t learn how to be remote by working in an office. The skills that you need to
communicate effectively and collaborate effectively with a remote team are different from those
that you gain by doing the progressive remote setup that I see many teams do, where, you
know, you are in the office maybe four times a week and you go to your home one day a week.
And that day at home is blissful, isn’t it? Nobody bothers you, you’re just coding and
writing and getting things done. But that’s not quite what happens in a remote environment
when you are doing it every single day. When you’re doing it every single day, you actually
do need to develop the ability to collaborate and create and ship products remotely, because
you really can’t depend on a team iterate to plan your work.
I know as I say this, I also know, you know, it’s a new thing, remote. It hasn’t been around
for so long. And we are kind of learning as we go, and
there is not a lot of literature. But teams in offices should have a level of skill levels
and skillsets, we should be push are our management to bring new voices into our remote teams.
Now, with this I don’t mean you should go ahead and hire juniors if you have not figured
out the basics of remote work. If you are still struggling to get a product done remotely,
you’re not there as a team. If your team is not able to support each other,
even with only senior people, it’s unlikely that you’re ready to take on very junior folks,
but for many remote companies, established companies, wherein companies with senior folks
are who are not just able, but willing and looking forward to the possibility of mentoring
new people. Now, as we think about these, we also have
to think, what does it mean to be ready, right? And of course the very first check in that
list could be ensuring that you have team dynamics that enable seniors to support each
other. What does it mean that they can support each
other? It means that when one of your senior engineers is learning a new skill, they can
pull from the knowledge of their coworkers and exchange ideas. It means that people are
able to help each other already. You should also make sure, before you go and
get a new junior engineer, that you have an onboarding process that has been tested. You
don’t want to be testing your onboarding for someone in the very first time with someone
who is in their very first year in tech. It’s going to give you a lot of insights, but it’s
going to be a painful process. The key thing that I’ve seen make or break my own ability
to support email has been timezones. For those of you who work remotely, we all really don’t
love timezones and for every engineer in the room, I’m very sorry. Timezones are terrible.
But before you go ahead and hire a junior engineer, you do want to make sure that you
have enough timezone coverage to support them. And that, together with having enough people
in your team entirely to support them, is the one key thing that’s going to make or
break your ability to support junior folks. Because what you don’t want is to hire a junior
engineer who has eight hours of time difference with a senior person who’s going to be mainly
in charge of supporting them. That is very hard to do, and I can tell you,
because I have tried. You want to ensure that — if you’re a three-person company, don’t
even try. It’s already really tough. But you want to ensure that you have at least
two senior folks who are really looking forward to this, and can commit to take a bit of their
time for a few months at least, to support this person.
Now, the junior engineer is going to need your support for many, many months, but you
want to have this commitment for three to six months from your senior engineers, because
those are going to be the most intense months. And you can also always reevaluate and have
one of them switch with someone else if they start to burn out.
I mention the two engineers, because what I’ve found is it’s so easy to feel like you’re
starting to burn out when you’re supporting a junior teammate and especially if you’re
remote and have been remote for a while and are super used to not having many interruptions,
it’s going to feel that you lost a little bit of what you loved about remote, but I
promise you, it doesn’t last forever. It gets better, because juniors will surprise you
in their ability to grow and learn very, very fast.
You don’t need a perfect team. You don’t need to have 10 seniors for each junior. You don’t
need a 200-page onboarding doc. It doesn’t have to be perfect. It needs to be functional,
and you have to have people who actually want to do it.
So OK, so we know it doesn’t have to be perfect. But what do we do now? You know? We have to
go find a junior engineer and is this the same as when we were in an office? Do we just
hire some super-brilliant fresh grad what maybe doesn’t have the best communication
skills? It’s going to be more complicated. So for remote work, one of the key things
we’re always testing for is communication skills.
And especially — sorry, and especially the ability to communicate your thoughts in writing,
your ability to ask questions asynchronously, to understand a problem and get feedback on
it. And junior engineers actually have this ability.
It’s not about seniority, just as much as many seniors doesn’t have this ability. So
you want to make sure that you are testing for this as the main skill that you’re going
to value to hire them. When you’re interviewing, your testing should
really try to reflect the kind of work dynamics that you have. You don’t want to be doing
interviews if your team is mainly working asynchronously. It’s likely that a com test
that I see more often is going to give you more insight when you work asynchronously,
and also to get clarification of what they need and finally send back a documented project
that really explains what they did, how they did it, and why.
Just as much as you’re going to test for these skills, you’re going to want to make sure
that you highlight that there will be a support network, that they will have access to more
experienced people, and that you have a plan for their onboarding.
This is going to really make sure that the people who are looking what they’re showing
you feel like they will be there for them and feel like they want you in your company.
One more thing about preparing for interviewing junior engineers that I’ve found very surprising
was recently I was speaking with someone about hiring juniors, and their main concern was,
well, all the junior engineers I know get all their social life from work, so if I hire
a junior engineers I’m going to take away from their ability to to go out for drinks
with their team. At first I was like, wait, how is that a concern? But it’s a totally
reasonable concern to have, because of course we care about doing right by the people who
join our teams. But what you have to do is make sure they
actually realize that, because it’s one of those non-obvious — obvious, but kind of
not so much — facts about remote life. You’re no longer able to pull your social life from
work. That’s just how it is, which is not to say we don’t have fun, because honestly
I’ve had more coffee chats over Slack than I can count.
So OK, so we’re ready to find a junior engineer. And we found one. We interviewed, we went
through a tech screening, we did all the hard work, we made some hard decisions to select
someone. And they signed. Congratulations! But now starts the hard, hard work of helping
them succeed. Been there on the first day. What’s on obvious
thing to say, right? Of course you have to be there on their first day and yet, I’ve
heard at least three times this year from friends working in remote companies, that
they woke up, started their day, and waited for three hours for their managers to appear.
And in these three hours, in their minds, all that they had was, was my contract canceled?
Do I still actually have a job? And how do I justify these three hours? And it all happened
because nobody on the other side thought, hey, we should actually tell this person to
start on a specific time, and it’s not really that they didn’t think of it. Because as remote
workers, how often do you, you know, actually set someone’s hours? For many of us it’s an
afterthought. But still, it’s important in the transition,
so please be here. and also want you to be there, because that will be the first of many,
many, many one-on-ones that you will be having with this person.
Whoops, I keep pushing the wrong button. You will do a progressive 1 to 1 schedule. So
on that first day you will outline everything that will happen on the first week, on the
first month, on the first quarter. Of course, you know, the first week will be
very hard, the next one a little less, and the first quarter. It’s normal for to feel
anxious because nobody is watching us, and so you want to ensure that you have that set
up. For the first week, you will be meeting with
this person every day. If it sounds like a lot, it’s not. It doesn’t have to be an hour,
but you want to be checking in very often on how that onboarding is going. And as a
manager, your side of this onboarding will be logistical, will be about career support,
it won’t be about helping them get set up. And it won’t be about helping them get set
up, because of the senior engineers who have volunteered to be fantastic peers and help
this person grow. So in that first day, you will outline a few
critical things. First, one thing that I’d really recommend is ensure that they know
that they have these meetings with our senior engineers who will get them set up, but also
that you expect them to reach out to some people outside of their own team. And this
is going to be terrifying for a new person. But reaching out to someone outside of your
team no matter how difficult it is, sets the tone that you are expected to be in touch
with your coworkers and you have the power to do so. And it’s going to be critical later
on when these same junior engineers start growing into a role and start needing help
from people who are not just in their immediate team.
As you go, you will be asking questions to validate learning. And this is going to be
much of what you will be doing that first week.
You will give them space to read documentation. You know they will be working with their senior
peers and getting set up, and you will be validating learning. And by this, what I mean
is to ask simple questions that tell you whether or not progress on onboarding is going as
expected. Things like how does this go into production are basic onboarding questions
that you ask to validate that your documents are as well as you think they are. They are
not going to be, and when you discover holes in your documentation, it would be really
great if you encourage the new junior engineer to go help fix that documentation for the
next person. That will put them in a position of helping others, which is something that
you really want to give them when you can. Because it can be so frustrating when you’re
still junior, and everyone is helping you and you feel like you don’t have much to give,
and this first week, being able to fix something for someone else is going to be powerful.
I mentioned the senior engineers a lot. Their job for that first week is not going to be
shipping product. Their job for that first week is going to be making sure that this
junior engineer is shipping something for production. They’re going to be setting them
up. They’re going to be explaining internal processes, and in the end, something should
be in production. Nothing helps engineers quite as much as getting
something done. Pair programming can be a powerful way to break down walls at different
levels of seniority. I found this to be extremely effective. Especially
in remote environments, where we’re kind of just a face in a screen, and it feels so intimidating
for someone new. I remember my relationship with an intern
going from from you know, you are here and you are here, change when she started programming
more, because she saw me making silly mistake, you know, get hung up over some typo. Just
doing the things that happened to her every day, I showed that it happens to everyone.
You’re going to be the delivering feedback, and I know you know this, but once a month
is too little. And you want to be giving feedback hopefully weekly, and in that first week,
something is going to go wrong and you should be there to tell them. Something is going
to go right, and you should be there to tell them, as well. You don’t want to just deliver,
“you are doing great” feedback. You want to be specific, and you want to also note things
to improve, because what I’ve found happens when you only say the positive is that people
don’t quite believe you. And I’m looking that way and laughing, because
this actually happened with a fellow there who is in the audience who for months, probably
thought I was not giving the right feedback, just because I was saying so many good things.
You’re going to want to make sure — and this is a logistics nightmare, it but you want
to make sure that you want to make sure you hire a junior person close to the a retreat.
I know it’s hard to plan. But try to not let more than 6 months pass before they have some
facetime interaction with their team. I found the team retreats to be so powerful. My first
team retreat was amazing and it made a lot of people I respected into full humans instead
of faces in the screen and gave us space to break down walls, as well.
We already talked about this, because I went far, but yeah, working to achieve a common
goal is always a powerful part of team building. And one more thing about that is ensuring
that this junior person also has the ability to give feedback so when you’re doing code
reviews, if you can, try to find something that they will review, and they can actually
critique, because it will help break the gap of seniority a little bit more, and it will
help them feel like a full part of this team. Now, I was so worried about running over,
that I have a few minutes left, actually. So wrapping up, what I want you to take from
this is juniors belong in remote. They belong in remote because not everyone can thrive
in an office. Just as much as not everyone will be able to thrive in a remote environment,
but when you prevent junior engineers from showing in a remote team at all, you are excluding
a huge part of the population of engineers and you are making it hard for people like
me to actually upscale without having to find weird hacks in how we structure our work on
our days. So this is a little bit selfish, because I
actually would have loved to have had this opportunity as a junior. I want you to think
as you feel all the reasons why you should never hire a junior engineer into remote.
I want you to actually think, is this about remote, or would this still happen in an office?
90% of the time, the blockers actually exist in offices, as well, it’s just that we’re
more used to T I also want you to think, as you prepare for a junior engineer, or as you’re
saying, no, that can never happen, I want you to think, if I fix this blocker, will
it make life much better for seniors, as well? And you’re going to find that for many things,
it could. If you fix your documentation to be a little more friendly, your seniors will
benefit, as well. If you fix the way you collaborate with each
other, your seniors will thrive and work better, as well.
And finally, I just want you to go find some juniors, hire them into your companies, and
support them. Because eventually, they will grow into senior engineers that you very much
want to hire right now. Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *