It’s a good question, and something I used to wonder myself, earlier in my career. In response to an honest question on this topic from someone I know, I was motivated to write an honest answer. This is what I do all day.
Some details about the team I lead at Course Hero, for context:
- We have 10 full-stack web developers
- Total company size is ~50 people
- Developers are divided among three (Scrum-like) product teams, each of which has its own product manager and designer in addition
- We have two new developers coming on board this summer, and are looking for more
Overall, most of my activities fall into one of two categories:
- Recruiting and hiring
- Looking for ways for our team to perform better, now and in the future
And even those are similar in that they’re really about helping other people with their own work. My day is more interrupt-driven than a typical engineer’s—I know, I used to be one, for many years. Several things can happen, at any time, that will make me stop what I’m doing and shift my focus. For example:
- A new candidate shows interest through our recruiting channels
- I get new information about an in-process candidate
- A site performance issue occurs
- A new bug is reported
- Someone comes to me with a personal problem
- Someone comes to me with a problem about our team or company
- I detect a problem with our team
Responsiveness is critical for handling these types of issues, so I’m constantly scanning for new ones.
With that background, here’s a fairly typical day for me. This one was Tuesday, May 20 2014:
7:45-7:50am: Quick email check. Nothing urgent.
8:45-9:30am: Email (and chat) time. Today’s topics:
- Check in with our new hires who start next month — what do they need?
- Review all new incoming recruiting opportunities (including 16 new resumes)
- Chat briefly with a team member about some details of our web framework
- Provide feedback to our recruiters about next steps for two candidates from the day before
9:30-9:40am: Set up a meeting for the afternoon about a current project that has turned out much longer and more difficult than expected. Determine who needs to be there, meeting format (Five Whys), and schedule it.
9:40-10am: Skim a large code review and comments for this project, which is nearing completion. More than looking for bugs, I’m looking to see if we’re consistent in our conventions and patterns, if I agree with our choices, and if other team members are doing the same analysis.
10-10:30am: Phone screen a new candidate.
10:30-11am: Eavesdrop on product team standup meetings while continuing to review code.
11-11:30am: Continue code review, asking questions of team members along the way.
11:30am-12pm: Regular (bi-weekly) 1-1 meeting with a team member.
12-12:20pm: Go for a walk around the campus. Enjoy the sunshine and weather.
12:20-12:50pm: Lunch (casual, not a meeting) with a team member.
12:55-1pm: Meeting prep. Prepare the notes template, get the room set up, have all material ready to go at 1pm sharp.
1pm: Lead the full team discussion about our troubled project.
2-2:20pm: Synthesize meeting notes to generate specific recommendations for improvement in future projects and circulate with the team.
2:20-2:30pm: Look at a new code review, on a project to start a migration to a new web framework. Try to understand the differences (and improvements) over our current system.
2:30-3:30pm: Do a final review of all peer feedback and notes for an upcoming team member performance review. Write up the review (overall assessment, strengths, opportunities for improvement, and goals), review our budget and finalize a decision on a raise for this person, and share with our CEO and Director of People Ops for review.
3:30-3:45pm: Phone call with recruiting staff at U of Waterloo to clarify some details of their co-op program.
3:45-4pm: Hacker News.
4-5pm: Review new internal (such as marketing and support) projects with our COO and CTO to assess priority and discuss which teams could take them on. Discuss some of the challenges faced by these new teams, and what we can do to improve. Also discuss the best way to bring our new hires onto the teams and generally learn how things are done.
5-5:10pm: Check in on the status of the code review and bug list for the large project.
5:10-5:20pm: Final review of email and new recruiting candidates, mostly intern or co-op possibilities.
8:30-9pm: Review the latest version of our new company recruiting videos and provide feedback.
9-9:10pm: Review details of a new candidate forwarded by one of our recruiters.
10-10:20pm: Chat with a former colleague in an effort to determine if he’s interested in a position.
Not every day is the same, but in reading it over, this one seems pretty typical. It’s a great job and I love it, mostly because of all the ways I get to work with and help other people build great software.