Onboarding Script

This is an example of a script that we have found success with. However, you should feel free to create one that you feel comfortable with.

Each section should be copy and pasted one at a time, with headings formatted as Bold and Italic and giving the engineer ample amount of time to read through and think about the sentences they're reading. Be careful not to overwhelm them by posting too much at once.

Before you begin, be sure to prepare a dogfooding challenge and quiz for the engineer. They will be used later in this script:

  1. Quiz
  2. Dogfooding

Manager's Note:

During the example script below, we have the engineer complete a quiz and a dogfooding challenge. We consider both to be important to the onboarding process and recommend creating them before starting.

Welcome Notes

Welcome to the team! This is @David Guttman, our VP of Engineering and @Dan Gorman, our Engineering Manager. Let’s get you started with the on-boarding process.

Before we begin, please note: all time related to Outlier, even if it isn’t direct coding, should be logged. This includes these two certification courses below.

Using your new @engineering.outlier.org email address, please complete these two certification courses (~30 min each)

  1. https://studentprivacy.ed.gov/training/ferpa-101-colleges-universities
  2. https://studentprivacy.ed.gov/training/ferpa-201-data-sharing-under-ferpa

Once you have obtained both certificates please provide verification by posting either the link to the certificate or a picture of the certificate to this thread.

We will continue with the onboarding process after this is completed.

Manager's Note:

Once you receive the pictures of certification, it is imperative that you store them for future reference if the need arises.

Congratulations on completing the above courses! Also, it should be noted that student names or emails should never be used in github tickets. Use student ids instead 👍

Please take this moment to ensure that you have verified your @engineering.outlier.org email address.

Also be sure to track when Daylight savings occurs in the United States. Set a reminder a few days before the working hours shift forward or backward an hour.

Moving on!

Check-Ins

Great! Now what we’ll do is have you set up a time with me for your Weekly Check-in. This is a 45 minute meeting between you and I that takes place every week. Let me go through what they're all about:

Our Check-in’s:

I use the Check-in meetings to see how engaged our engineers are.

If an engineer comes to a Check-in every week without much to discuss, I become concerned that they are not as engaged as we would like. The Check-in functions as your opportunity to speak with us about anything that is important to you. This can be about your work or questions pertaining to personal development.

I will also use Check-in’s as an opportunity to provide you with feedback. I am here to help guide you with your work at Outlier, and I am also interested in your overall progress as an engineer.

Every day when you sit down and do work here at Outlier, think about the challenges you face. Think about what you would like to see change, or what you could be doing to make things change.

In the end, the Weekly Check-in’s are only going to be as good as you can make it. You have to bring your own contributions because ultimately, they are all about you.

With that all said, does $yourPreferredTime work for you?

Weekly Team Meetings

These meetings take place every Tuesday at 9am PT and take place in the #engineering channel via text.

Please note that these meetings are mandatory.

These are 1 hour meetings that take place in the #engineering channel. These meetings are strictly text-based and do not require you join any platform. Just be present in the #engineering channel at the allotted time. These meetings function as a method to get everyone on the team on the same page for the week. This can be used to pinpoint or address the previous week's pain points or successes, as well as address any areas of communication that need improvement.

Manager's Note:

The time that these meetings take place is entirely up to you. We do recommend that they take place at the beginning of the week to maximize their effectiveness.

Standuply

Manager's Note:

We have had great success with Standuply as it has allowed us to form a way for engineers to structure their day, but more importantly plan. It forces them to think in terms of input and output as a daily routine.

This functions in a different way for the manager. With Standuply we can see what they have worked on, plan to work on, if their daily plan succeeded, or if it failed and why.

The uses this tool provides is truly invaluable.

I added you to Standuply, so you’ll now get reminders to fill out the reports below at different times of the week or day.

There are three different reports, please note that completion of all reports is mandatory.

  1. Daily Standup Report
  2. Weekly Dev Report
  3. Weekly Hour Log Report

The Daily Standup Report takes place at 9am PT every weekday, you will have 15 minutes to respond, so you can choose when you submit your updates.

This report is what you use to set your goals for the day.

Here is an example of the Daily Report:

How many PRs have you approved since the last standup?

3

How many PRs have you rejected since the last standup?

1

Keeping the above in mind, what do you plan to accomplish before the next Standup? Do not include reviewing PRs as part of your answer.

I will be adding tests for saving assignment HTML, then I will create the GET endpoint for getting the assignments’ files

Look at your plan from the previous standup. Did you successfully complete it?

Yes

This report is a critical representation of the work that you will put in on that day, as well as the work that you have done the day before.

Notice the first two questions:

  1. How many PRs have you approved since the last standup?
  2. How many PRs have you rejected since the last standup?

It is required that all engineers review at least on PR per day. There should be no reason that you enter 0 for both questions unless there are no PRs to review. If there are no PRs to review, be sure to note that in your Daily Report 👍

PR Reviewal process:

We have a set of rules that we have our engineers follow. Along with a Developer Checklist that needs to be followed, we have a repository on our GitHub called Onboarding. This contains a markdown file that details how one should review a PR

Let’s talk about the 3rd question:

Keeping the above in mind, what do you plan to accomplish before the next Standup? Do not include reviewing PRs as part of your answer.

^ The purpose for this question is to allow you to set an attainable goal for you to complete during the given workday.

notice that I highlighted “complete”

Answers to this question need to be tangible results that you will do by the end of the day.

The definition of tangible is “substantially real : material”

That means you should be setting goals such as “create a PR”, “Deploy XYZ”, “research and create document with findings”, etc

Answers that you should never give us are intangible goals.

These can range from “work on XYZ”, “Look up ticket”, “Think about plan XYZ”, etc

For example, if you were to disappear for a week, all that I would have would be “I will work on XYZ” and I wouldn’t have anything like a PR or document to see as a representation of your work.

Does this make sense?

The last question for our Daily Standup:

Look at your plan from the previous standup. Did you successfully complete it?

^ This is a place for you to gauge your effectiveness for each previous day.

Did you complete your previous day’s goals? Great!

Did you not? Ok, what happened and how can you plan to improve in the future?

For example:

Look at your plan from the previous standup. Did you successfully complete it?

No, I realized that I did not take $function into consideration. After this realization I went back into my work and found other areas that I had mistakenly overlooked. I have written down a list of things that I will be sure to do each time before I submit a new PR to prevent this happening in the future.

There’s nothing wrong with being wrong. There is everything wrong with being wrong and not accepting accountability.

That’s one thing I want you to know about working here.

You’re going to mess up.

That’s ok.

What matters is how you grow from it.

And that’s where I get to see who our best performing engineers are.

Let’s move onto the Weekly Dev Update:

You will have 4 hours to complete this report and it starts at 9am on Monday. In this Standuply Report are 3 questions. I will list them and go into detail on each of them below.

In your own words, what did you complete last week?

^ This is exactly what it sounds like. I want you to tell me what you completed last week. This means instead of giving me links to PRs, you give me your thoughts on what you completed last week.

How has your work impacted Outlier as a whole?

^ This is also inline with your thoughts on the system of Outlier. Show me that you understand what your work has impacted.

What was the biggest obstacle you faced last week?

^ Was there an obstacle that you didn’t plan for? New information that slowed down progress? Let me know here.

Do you have any questions about the above?

Alright, the last one is our Weekly Hour Log Report:

The Weekly Hour Log Report begins on Friday at 4pm PT and ends 24 hours after. Please use this to report the hours you spent on specific projects as well as the total hours you’ve logged to upwork.

Here is a good example of a response:

Please enter your project hours from last week.

Format:

[zenhubProjectName](link): INT

Bugs / Misc: INT

Philosophy Grading Criteria Update: 4

Content Gating for cohorts and students: 10

Bugs / Misc: 21

How many hours were logged to Upwork?

Format: INT

38

When reporting the project you’ve worked on in the first question the name of the project you use should be the one that is used in #engineering-projects

Any questions?

ZenHub Swimlanes

In zenhub, we have a number of stages in which the tickets are placed.

The new tickets, which are not yet ready for development, are placed on New Issues column.

The tickets, which are ready for development to start, will be placed on Backlog

The developers will pick the tickets from Backlog and move them to the In Progress column.

Once a developer finishes with the development of the ticket, that ticket is placed in Needs Review column. Here, a different developer will review the PR.

Once the PR is reviewed and approved by the reviewer, that ticket is moved to Needs QA column.

Here, the QA will pick the ticket and test if the issue has been fixed as per specifications.

If QA doesn't find any issue with the PR, they move it to Ready to Deploy column.

If QA finds that there's some issue with the PR, or it doesn't fulfill the specifications described in the ticket, they move it to In Progress column and notify the PR's owner.

Slack Communication

As you no doubt have seen, we have many different channels that exist here in the Slack workspace. I'll give you a rundown of what each channel is for:

#engineering

General purpose channel for team wide collaboration, communication, and meetings

#engineering-group-$Number

This is a channel where your group teammates discuss relevant tickets and projects that are assigened to the group.

#engineering-backend / frontend

Group discussion of back-end / frontend work

#engineering-ooo

If you are going to be out of town, it is your responsibility to post the exact dates that you expect to be out here in this channel.

examples:

  • I will be out of office 7/20, 7/21, and 7/22 (vacation)
  • I will be out of office today (sick)

#engineering-bugs

Manual reporting of urgent bugs to the engineering team that should be handled immediately

#engineering-errors

Automatic error reporting

#engineering-notice

App integrations around the status of tickets and deployments

#engineering-prs

A channel to post pull requests, and quickly communicate about those PRs in a thread

#engineering-qa

General purpose channel for communicating about anything QA related

#engineering-random

Discuss anything, with a focus on engineering related topics

Error reporting

Do not create a post to discuss an error, or comment in the error's thread in the #engineering-errors channel. Instead, link the error in another post inside another relevant channel such as #engineering or your groups channel to discuss the error there.

Using Private Messages (DMs) to talk about work

When another engineer asks for assistance, the thought “someone else will help them out, I’m too busy right now” can be prevalent. This can lead to no one answering the question, making the engineer think they need to privately message someone for assistance.

This should be avoided at all costs.

If you and another engineer are discussing a topic and are unable to come to a solution, a public conversation allows both of you to quickly include someone else. That engineer can read the previous conversation and get up to speed quickly. Public conversations can also serve as documentation. Someone searching for a term related to that conversation may find that it helps them to understand the problem they are currently facing.

Effective Communication

We are social creatures, so it makes sense that we want to make sure that there is someone to talk to before we send a post out into the void of a channel.

ex. "Hey, has anyone encountered problem X?"

This may seem like a rather miscellaneous question, and you'd be right. What exactly is wrong with miscellaneous questions?

They waste time and space.

With miscellaneous questions, you can expect the conversation to flow like this:

[12:01] Dev 1: "Hey, has anyone encountered problem X?"

[12:03] Dev 2: "Oh yeah, that's a doozy."

[12:03] Dev 1: "How did you figure it out?"

[12:06] Dev 2: "I did fix=XYZ."

[12:08] Dev 1: "I've already tried that, didn't work."

[12:12] Dev 2: "Link me your PR"

[12:17] Dev 1: "Done"

[12:24] Dev 2: "Oh wait, your PR is for repo ABC! That's why my solution didn't work. Try fix = ABC"

[12:30] Dev 1: "You're right! That did the trick, thanks!"

That's 9 posts in a channel if they don't use threads, and over 30 minutes to solve an issue that had a quick fix.

Let's see what the conversation might look like if we cut out miscellaneous questions and instead used concise, well-thought out communication:

[12:01] Dev 1: "Hey @dev2, @dev3: I'm working on LinkToPR in Repo ABC, I've tried fix=XYZ,FIX=X. Am I approaching this the wrong way?

[12:02] Dev 3: "Did that last night, use fix=ABC"

[12:03] Dev 2: "Agree with @Dev 3. Fix=ABC is the solution."

[12:05] Dev 1: "Fix=ABC worked! Thanks!"

That took up 4 lines of code and lasted 5 minutes. Effective communication builds the team and helps the engineer learn how to communicate better.

Engineering Duties

Status & Notifications

Since we require you to be active from , please be sure to keep your status on Slack active. As any @mentions you may receive have the chance to nullified by an "Away" status.

I would also like for you to set the notifications for this Weekly-Check-In channel to "every new message".

Always Have a Plan

When faced with a problem, most engineers will launch right into a solution. Rare is the engineer who will set down and weigh out the pros & cons of a particular solution. In doing so, they might happen a better solution than the one they initial came up with.

Not every task requires a plan. Fixing the margin on a button or creating a simple CRUD API endpoint do not warrant the need for a plan. Implementing a new reusable component? Plan it out. Building a major new feature for the site? Plan it out.

Self-sufficient

Even the most well-intentioned engineer has a bad day, resulting in a choice that accumulates debt at a higher interest rate than others.

You should be self-sufficient and adept at navigating existing code that you did not author. Turning to others for help is actively encouraged, but only after first trying your best to comprehend on your own first.

Incremental Development

By delivering small, incremental changes, we allow for quicker feedback.

Large parent branches that are separated from the day-to-day work of the rest of the organization can feel like a necessity when developing features that can take weeks to implement. That is, until some bug fix has been made upstream on the existing feature that is being actively worked on in a silo. It takes a diligent engineer to spot that upstream bug fix and make sure it is properly incorporated into the parent branch so that bug is not reintroduced when the new feature work is launched. When it comes time to merge that parent branch into the main branch, a nasty bug can result in reverting week's worth of work. The resulting haystack can be quite frustrating to wade through, demoralizing a team upon what was supposed to be a big launch day.

To avoid silos and maintenance nightmares, small, incremental changes are required.

Test-Driven Development

Test-Driven Development (or TDD) is essential to ensuring the quality of our code, allowing for bugs to be potentially caught during development. Both front-end and back-end code should be covered by tests. Any pull requests that do not include sufficient test coverage should be sent back to "In Progress" so that they can be corrected.

Bugs

Whenever a bug is discovered, the engineers responsible or the relevant team need to address it immediately. If you view the bug but are unable to address it yourself you should @ other devs in the #engineering-bugs to get their attention.

Permissive > Prescriptive

It is not uncommon for an engineer to ask for permission to make a small change. Not used to the empowerment that comes with working at a start-up, contract workers tend to ask their managers if it's okay to use tool X. It is important for them understand that they are empowered to make changes, and should be encouraged to discuss those changes with their team if needed.

There are exceptions of course. Can we use this plugin? You probably don't need to ask. Can we update our whole build process, causing countless man hours to be wasted on upgrading something that doesn't really need an upgrade? It's a possibility but it needs to be discussed first.

Another important lesson to learn is deciding when to discuss a small change vs simply implementing that change and submitting a pull request.

30-60 minutes on a PR might be a better use of time the same 30-60 minutes spent discussing it on Slack.

Worst case, the pull request gets denied and a small amount of time was spent on something that ultimately was not worthwhile. That is okay. It’s a fine line between being proactive and knowing when to ask for permission.

Being consistent about your goals and communication will help in this area.

Dogfooding

This is where we would recommend introducing the engineer to your company's approach to dogfooding.

Get to know our product

As an Outlier engineer, the most important thing you need to do is experience our product from the point of view of a customer. Use your outlier email to create an account at calculus.beta.outlier.org I’d like you to complete sections:

  • 1.1 Representing Functions
  • 1.2 Modeling with Functions

For both you should complete guesswork, lectures, active learning, two practice exercises, and one quiz.

The key here is to view this application from the eyes of a student. Look at each feature, how the UI functions, what you click on, etc. Don’t worry too much about getting the answers correct.

Be sure to give the onboarding guide another careful read and when you have a minute, check out this blog

Like before, we’ll continue when you have completed the above :thumbsup:

Manager's Note:

Consider this your chance to show the engineer what the app should look like from a customer’s perspective.

Show them what the app should look and function like. Give them an idea of how customers will navigate, message doctors, create meetings, and more.

Often times this means creating a dummy account and having the engineer complete certain steps to gain an idea of the app they are working on.

This is a common onboarding tactic when bringing on new people that gets them “on the same page” as everyone else. Thus making them work towards the same goals your team has.

Required Reading

Here's a list of the articles we have our new engineers read. Please take your time to read them all and let me know when you have completed all of the below:

If the dev is BE:

  • Fullstack Node
    • Give them Epub

Quiz

You’re almost done! Taking all of the information you’ve learned above, please answer these questions on our form: https://forms.gle/5d5QTqNWeU7gFVwA6

Manager's Note:

This is where you have them fill out a form that you believe best showcases their understanding about their workspace and what is expected of them.

It can be a Google Form, Typeform, or any other form of polling that you choose to use. The length and amount of detail in this quiz is entirely up to you as well.

It is important for you to pick necessary aspects of the job that you want to be 100% clear with the employee on. This can be used as a reference later on as well.

Introduction to Team

We would like to introduce you to the team and have you give them some information about yourself. Write a few sentences about yourself and post in our #engineering!

Get Them Started

You’re all set! Welcome to Outlier!

Manager's Note:

Once all of this is done, the engineer will be setup to start their first PR with you.

It is recommended that their first PR consist of a simple problem that brings them through the engineering lifecycle and gets them further acquainted with their surroundings.

After this, you will have a fully integrated engineer working on your team. Congratulations!

results matching ""

    No results matching ""