Cohere Articles

A Primer on Setting Up Your Remote Employee

Posted by Jennifer Tu on Feb 14, 2019 1:00:28 PM

Last night, I was talking with a tech lead of a local company. He was struggling with supporting two of his teammates who are newer to their roles (let’s call them Alyssa and Ben). Alyssa, like nearly all her teammates, works in the local office, and is learning quickly. Ben is the sole remote member of the team, and he both chases features that don’t support the team’s business goals, and does everything slowly.

They’re both bright junior developers. The difference is that Alyssa takes advantage of micro-interactions around the office that Ben isn’t able to access. While greeting her office neighbor as she walks into the office, Alyssa mentions what she’s working on that day, and gets warned away from a rabbit hole lurking in that direction. She bumps into her tech lead while they’re waiting for the meeting room to empty just before the team meeting, and the tech lead philosophizes for a moment on the team’s business goals.

Ben doesn’t get that. He’s isolated and only interacts with his team three times the entire week: a 1-1 with his manager, a 1-1 with the tech lead, and the weekly team meeting. Out of every work week, Ben only has three occurrences of team contact. Alyssa gets just as many occurrences before she grabbed her post-lunch coffee every single day. No wonder Alyssa’s learning and growing five times faster than Ben – she gets feedback five times as frequently.

What can you do if you find yourself in this tech lead’s position??

Please don’t use this post to decide whether to start a remote team member, or how to start a remote team member. This post is a triage recommendation for when you realize you have an isolated remote teammate who isn’t working at their full capability because of that isolation.

Frequency over quantity

Much of Alyssa’s success – and of everyone else in the office – is because she gets a few minutes here and there spread out over her week. Both Alyssa and Ben are smart and work hard, but Ben is working with much less guidance, and struggling as a result. Even when the tech lead added a second weekly 1-1 to work with Ben, the effect wasn’t the same. Concentrating those micro-interactions into an hour or two doesn’t have the same effect as having more interactions more frequently.

Start each day with a team interaction

Here’s what you can do instead.

If you’re not doing (and don’t want) daily team standups, you’re going to need to manufacture something for Ben that’s similar to what Alyssa gets when she greets her colleagues as everyone enters the office. This accomplishes two things:

(1) Provides Ben with the same opportunity for beginning-of-work-hours guardrails that Alyssa has, so that if he’s about to embark into dangerous or not-well-aligned territory, he can be redirected to a safer path.

(2) Provides Ben and the team regular reaffirmation of his team membership. Even if Ben is meeting with only one teammate, when the rest of the team sees and hears that in-office teammate talking with Ben, they’re more likely to remember Ben’s existence without prompting – and that makes them more likely to reach out to him to share topics relevant to his work.

When should this happen?

This should ideally be at the start of Ben’s day. If he’s in a different timezone from the local office, hopefully the start of his day overlaps with the start of the local office’s day. If you can’t schedule this to be at the beginning of Ben’s day, schedule it for as early in Ben’s regular workday as possible. (So if Ben is on the east coast and the office is on the west coast, and everyone starts their day at 9am local, schedule this for 9am Pacific / 12pm Eastern.)

Who should be on this call?

Since this is a team that isn’t doing a daily team standup, pull together those who are working on the same or adjacent work as Ben. In the real world example, the tech lead’s Alyssa and Ben are working on similar tasks, so putting the two together for this daily morning call would work out very well (and free up the tech lead from taking on another regular meeting). They’ll be able to compare notes, help each other out, and the rest of the team can wave at Ben over Alyssa’s shoulder as they walk to their desks in the morning.

How should this call happen?

Use videoconference software. At Cohere, we least hate using Zoom. The audio-video experience is good and less “hi can you hear me I can’t hear you” than usual, and there’s both a screenshare and a remote control feature available. Each viewer can adjust for themself whether they see a gallery of participants, or only the speaker.

Encourage Alyssa and Ben to stay on the call and keep working together if they start working on something together, and make sure any meetings or other obligations don’t stomp on their time. You might also ask Alyssa and Ben to set up a few 2-hour pair programming sessions throughout the week (maybe Tuesday and Thursday mornings immediately after their morning call? pick something that complements your team’s meeting cadence.)

Physical setup

Drop $100 on good headsets-with-mics for Alyssa and Ben, or stop complaining when you hear Ben’s voice coming out of Alyssa’s computer.

Make sure both of them are able to set up their physical spaces so that they can point a laptop webcam or external video camera at their face. If Ben is having problems, have him email a selfie of his workspace so you can help him find a physical setup that works. If Alyssa is having problems, you can walk over to her desk and experiment with different configurations with her.

What else can we do?

Getting into a new work pattern can take some time. Plan to run this for at least 4-6 weeks before deciding if it’s a good long-term arrangement for your team.

Check in with Alyssa and Ben separately and regularly (preferably weekly, but at least every other week) to see how things are going, if there’s anything you can do to support them (a $300 headset for better mic isolation? YES that is totally worth making two developers more productive!).

Especially early on, hop into a videoconference with Alyssa while you’re both in the office, so you can get a feel for what kind of experience Ben is having in these calls. Grab a conference room and see and hear what Ben is experiencing. Is the background noise distracting? can you hear Alyssa’s voice clearly? how does screensharing feel?

Ask each of your other teammates to meet virtually with Ben once a month. They can join the morning session, or grab a virtual coffee with Ben. At 30min once a month, it’s not a big request for any one individual, and you’ll see it start to pay off with more information exchange happening after a few short months.

A few parting thoughts

Supporting a remote teammate is a skill that must be learned, but it can be incredibly rewarding once you’ve got the hang of it. The skills Alyssa learns by working more closely with Ben will help her grow as a leader on your team. She’ll be exposed to more work and ideas than she would working only on her own tasks. She’ll learn to do for Ben what her teammates do for her, of identifying and calling out warnings of possible dead ends and rabbit holes.

And Ben? His productivity will go up, he’ll pick up more context around what your team is trying to accomplish as a group, and you’ll find he’s aligning his efforts more with the team’s goals. You’ll also start to see his growth as a developer more start to resemble Alyssa’s and the other newer devs on your team.

Read More

Topics: cohere, interviewer, interview tips

How to Interview your Future Manager

Posted by Jennifer Tu on Feb 14, 2019 12:58:38 PM

We often get the chance to interview our future manager, but usually it’s while being evaluated for a new job. What do you do when you find yourself getting to interview your current manager’s replacement?

Read More

Topics: cohere, interviewer, interview tips

Return from RailsConf + Interviewer Skills Part 0/??: Intro

Posted by Jennifer Tu on Feb 14, 2019 12:54:17 PM

We’re back from speaking at RailsConf, and what an incredible experience! The conference organizers did a fantastic job at running a smooth event despite never-relenting weather challenges. We were constantly learning from our fellow speakers, and I may forever be in awe of Sarah Mei’s ability to deliver a keynote with 15 minutes’ warning. We’re so glad we got to meet and reconnect with everyone.

Read More

Topics: cohere, interviewer, interview tips

Interviewer Skills Part 1/3: Why Set Specific Goals

Posted by Jennifer Tu on Feb 14, 2019 12:53:04 PM

This is Part 1 of a multi-part series covering some of the topics introduced in our RailsConf 2018Interviewer Skills workshop.

Read More

Topics: cohere, interviewer, interview tips

Interviewer Skills Part 2/3: How to Create Interview Questions

Posted by Jennifer Tu on Feb 14, 2019 12:51:24 PM

This is Part 2 of a multi-part series covering some of the topics introduced in our RailsConf 2018Interviewer Skills workshop.

Part 1 covered how to know what would make a candidate the right addition to your team, and why single-word descriptions like “independent” or “smart” can imply different behaviors to different people.


You’re hiring - yay!

You have a list of 4-6 descriptive attributes that describe the ideal candidate - double yay!!

Now how do you learn whether a candidate possesses these attributes?

You can’t ask your candidate directly if they exhibit that attribute:

You: <checks list of attributes>

You: Hello $candidate, are you someone who will independently seek out the business reason for development tasks?

Them: Uhhh… yes, $interviewer, of course I do that.

“Yes or no” questions won’t tell you how your candidate behaves. You’re going to need questions that prompt your candidate to tell you about their experience exhibiting the qualities you’re looking for. You’re going to need to do some behavioral interviewing.

How do you do that? How do you go from an attribute, to making it easy for the candidate to tell you about an experience that shows off that attribute (or makes it clear that they possess the opposite of that attribute)? If you’re at a loss for how to make this jump, here is a loose outline that can help you go from an attribute description to an interview question.

  1. Re-read your attribute descriptions
  2. What might success look like?
  3. How might someone summarize a story of a successful situation that shows off this attribute?
  4. How would you ask a question that would draw out this story, or a story similar to it?

This isn’t the only way to create your interview question, but it’s the first of many strategies you might employ when creating your interview questions.

1. Re-read your attribute descriptions

You know how when you’re breaking ground on a brand new feature, the first bit of code you write is going to be creating a new file – which means you need to know the class name, the file name, the file path? You need to have all that context in your head of what you’re trying to accomplish as you create a single empty file.

This is the same thing. Take a moment and load up that context around your candidate attribute.

Re-read your attribute descriptions. Maybe you wrote it just a minute ago, maybe they’re ingrained in your heart. Take a moment and read those words again, feel how they tug and resonate, gather up the ideas and feelings you have around this attribute and hold them close.

Example: What do I think of when I say we need someone who “gives kind feedback”?

I need a candidate who will bring more than raw code ability.\ > The team is strong because they trust each other, and we need to hire someone who will add to that environment.\ > We need someone who will others will *enjoy* learning from.

2. What might success look like?

Let’s go back to that new class you added to your codebase. How does it behave? How will you know if it’s doing its job?

In the same way that it’s critical to think about a class’s behavior before you start writing code, it’s critical to think about a candidate’s behavior before you hire them. Like in testing software, you’re going to be looking for a specific instance of behavior that implies the behavior will continue.

Think about the difference between these test cases:

expect(response).to eq 314
expect(response).to be_an Integer
expect(response.class).to be_in [Integer, Float]

What might your candidate’s response look like? You don’t want to expect it to be specific – you can’t require it to be a very specific story. But maybe it can be a class of stories, or one of several classes of stories. Take some time to think about what some acceptable answers might look like. Is 3.14 an acceptable answer? how about -3.14 or "three"?

What might be a story that shows a candidate successfully exhibiting your desired attribute?

What kind of behaviors do you hope to see?

Sometimes it can be hard to come up with the first example story of success. When that happens, here are a few questions you can ask yourself that can help you get started:

  • What does your favorite teammate do that makes you say “they exhibit this attribute we seek”?
  • If you were the candidate, what stories would you tell from your career?
  • What are a few reasons why this attribute is helpful? What might success look like for one of those reasons?

Example: What might be a story of successfully “giving kind feedback”?

  • An example of giving critical feedback when encountering poor code
  • Learning the candidate’s formula when responding in PRs is designed to make the author feel respected
  • Maybe a story about working under pressure (maybe an incident?) and keeping everyone able to creatively contribute because no one was mocked for having a bad idea?
  • Or maybe a story of how someone else on the team asked for their feedback?

3. How might someone summarize a story of a successful situation that shows off this attribute?

If you were to document the behavior of a method, you wouldn’t describe it line by line.

def comp
  puts "Enter your first number: "        # Print a prompt for a
  a = gets.to_i                           # Get a and cast it
  puts "Enter your second number: "       # Print a prompt for b
  b = gets.to_i                           # Get and cast b
  return a if a > b                       # Returns true if a > b
end

You’d summarize the whole thing, right?

### Compares two numeric values and returns the greater
def comp
  ...
end

Take a look at one of your stories of success.
If you had to summarize that story, what would that summary look like?
What are the most relevant parts of the story you want to highlight in a single sentence?
How do those highlights relate to the attribute you want to learn about?
What’s the action you’re trying to convey?

Example: Gives kind feedback

The candidate told me about this great experience they had - they told me about a time when I gave feedback on not-very-good code.

4. How would you ask a question that would draw out this story, or a story similar to it?

Ready to see your interview question??

Take the summaries you made in the previous step.

Add either “Can you tell me about a time when…“ or “When was the last time you…“ to the beginning.

Example: Gives kind feedback

Summary from Step 3:

The candidate told me about this great experience they had - they told me about a time when I gave feedback on not-very-good code.

Add a question to the beginning!

Can you tell me about a time when ____

Can you tell me about a time when The candidate told me about this great experience they had - they told me about a time when I gave feedback on not-very-good code.

Can you tell me about a time when The candidate told me about this great experience they had - they told me about a time when I you gave feedback on not-very-good code?

Can you tell me about a time when you gave feedback on not-very-good code?

Tada! you have an interview question!

What’s next?

Yay, you have some interview questions you think will draw out candidate experiences that show off how they exhibit the attributes you are looking for!

At this point, get some feedback. Share your questions with people around you, and ask what they think you’re looking for in a candidate. Share your attributes, and ask whether the questions will make it easy for candidates to give you good answers.

Make more questions that rephrase what you’re looking for, so if a candidate isn’t giving you a good answer, you’re able to fall back on other questions that might help them give you better answers.

Keep learning more about behavioral interviewing (maybe read what we wrote on how to ask a behavioral question or on how to interview your future manager), keep getting feedback on what you’re doing, and keep practicing. You’ll come up with lots of dud questions that don’t work out, but the more you practice, the easier creating questions will get.

Read More

Topics: cohere, interviewer, interview tips

More Articles