Job Posting 2.0 — Recruit More Effectively By Describing A Typical Day at Work
It’s hard to hire amazing colleagues. It’s especially difficult to find great engineers and designers. As we wrote before, you can either steal great developers, or you can farm them.
The combination of technical experience, quality communication skills, empathy, problem-solving, interest in mentoring/teaching, offbeat perspective, and professionalism is tough to locate already. It’s even worse trying to find the right mix of those skills (and others) which augment your team best.
As an experiment, we have rewritten an engineering job description in the format of “A Day in the Life”. I’m curious to hear what you think of the result.
Hypothesis
Tech job descriptions can be really bad at describing the true nature of the work they expect a new hire to do. Instead of a laundry list of technologies, management buzzwords, and the professional attributes of the world’s greatest employee, a job description could explain the meetings and rituals you’ll attend and just how they expect your 40 hours a week to be spent.
We can do a better job attracting great candidates by more clearly describing what the day-to-day is like at the job.
In a tight labor market, candidates are shopping for employers as much as the reverse. Describing the actual job in more detail can help attract the right people to your team.
(Note: For this experiment, I rewrote an engineering job description for our partners, Code for America. You can read more about our work with them here.)
(Another note: This description is long and detailed intentionally. It’s designed to give a clear picture of what it’s like to work at this job. Please comment and let us know which parts are most valuable to you.)
A Day in the Life of an Engineer on Our Team
Hello!
I’m [NAME], one of the engineers working on the GetCalFresh team. I’m going to tell you a little bit about what my day is like and hopefully you’ll find it so exciting, you’ll run out and apply for an engineering job with us!
(Note: You can apply at this link. I’ll also put the link at the end.)
What am I working on?
I am an engineer on the GetCalFresh team. We use the startup-style tactics to optimize user signups and get more Californians enrolled in the food stamp program, CalFresh. You can read more about it here on our project webpage or in this impressive New York Times article.
Start the Day
I take the train/bus/walk to Code for America headquarters in downtown San Francisco. It’s a lively workplace filled with amazing people working hard every day to make a positive difference in the lives of real Americans.
I get into the office at about 9:30am and make some coffee. Mornings usually start for me by catching up on emails and having a quick look at any outstanding pull requests (PRs) in GitHub in preparation for…
Morning Rituals
Every morning at 10am the whole team spends an hour together doing something we call “Morning Rituals”. It’s a time to get together and plan our days using two structured discussions.
1. Standup
Like many modern software engineering teams, we have a round-robin standup discussion to start the day. We take turns sharing what we worked on yesterday and plan for today.
This is a great time to ask for help or to coordinate with another engineer to pair-program. It’s also helpful for hearing about teammates doing not-coding things like “I’m shadowing a partner meeting today to understand how the California Counties work with one another” or “I’m listening in on a client customer success call to learn how to better move users through our signup flow.”
2. The Daily Diff
This is a ritual unique to our team (as far as I know!). After Standup, we review the code which was merged into the master branch over the last day. We value knowing a lot of context information around our work and this really helps us maintain that. Doing a code review doesn’t always suffice for more involved conversations, so this is a great time to chat.
In this discussion, we also cover changes to the product, debate coding conventions, and occasionally some minor process improvement. If any bugs or emergencies pop up, we’ll discuss how to handle them here as well.
Morning Coding
From 11am to lunch, I usually review my teammate’s pull requests, merge my own, deal with any ops issues, and set up my afternoon’s work.
Lunch
Some of us will grab some food from the nearby Ethiopian restaurant, bring it back to the office and eat in the kitchen. Yum!
Sometimes on Wednesdays, we have lunch speakers who are usually badasses from the world of technology or government. These talks are super interesting and provide a good opportunity for us to learn from leaders in the two worlds we straddle.
A Typical Feature
Design Discussion
After lunch, we have a meeting with my amazing designer teammate. We do an hour-long sit-down with her where they present the new feature and we engineers ask questions. The next day they refine the flow in mockups (usually in Sketch app) and post screenshots into GitHub Issues for us. For the most part, static mockups are great for us although sometimes we use InVision when demo-ing for people outside the team.
The Idea
To take one specific feature as an example, we built something we called “Desktop-to-Mobile Handoff”. When someone is filling out a SNAP application on their desktop computer, they need to upload pictures of documents. This is tough to do on a desktop because most photos are taken on mobile devices.
We hypothesized it would be easier if clients could put a phone number into our app while using a desktop computer, get a text message with a link which would transfer the state of the SNAP application onto the mobile browser in order to upload document photos from your phone.
We tested this idea with some of our customers and they loved it, so we wanted to build the quickest version of this feature to see how much it helped our clients.
Because we are engineers, we talk through all of the edge cases where this feature could break: What if the text message fails to send? How do we resend? Is it the same link or a new one? What if the link is expired (we do this for security purposes)? What is the error message we show them? Our designer patiently works through these scenarios with us and then we have a more complete picture of how to build the feature.
Our fearless Project Manager then turns this feature picture into more detailed user stories and she queues them up for us in Waffle, an Kanban-type interface for GitHub Issues.
Afternoon Coding
After this meeting, I’ll write code on my own or with one of my colleagues until about 4pm.
Development Flow
We pick off the top card on the prioritized list in Waffle and get to work! Typically, two people pair on the feature, writing tests first and then making them pass. For example, I might guide my pair by saying something out loud like “Okay, now I am going to write the controller create action so that when it posts some stuff it gets saved to the model.” I write the test in RSpec and then pass control off to my pair so they can make the new failing test pass. Yay! Green test!
Once we’ve completed our work, we make a git commit for the feature, open a Pull Request so our teammates can help us with Code Review. Often when we pair, we consider that a review so we will merge without a third person’s input. While the PR is open, we demo the results with the designer, or ask her to pull the code down and run it. We talk through it with her and see if it’s close to what she had in mind.
Because the stories were so well developed, we can merge with minor revisions into master and get ready to deploy our changes to the production server. We typically deploy 4–5 times a week.
Tech Stack
It’s probably worth taking a minute to describe some of the tools we use:
- Ruby on Rails (version 5.0)
- PostgreSQL (version 9.4)
- RSpec (test coverage 91%)
- Selenium
- Bourbon / Neat (SCSS grid framework and style libraries)
- No Javascript! (as of now)
- We deploy the app onto GovCloud, which is a separate part of AWS which is more secure and better designed for government work.
You may notice the conspicuous absence of The New Hottness, technology-wise. This is very intentionally a boring list of well-worn technologies which help reduce uncertainty, risk, and reducing learning curves for new colleagues. Also, Rails is already really powerful for our purposes and sticking to the conventions allows us to cast a wide hiring net (I’m talking about you, reader!). Finally, by reducing the amount of JavaScript we use, we make the web application better for a broader population of customers who have a wide variety of mobile devices.
The Daily Drive
This is my favorite part of the day — submitting SNAP applications to the various California counties.
We must submit SNAP applications to the county by 5pm for them to be valid for the day, so we all typically pause development at 4pm to start automated submission using Selenium. We call this process “The Daily Drive”.
As a design principle, we want to be very permissive regarding the information submitted to us. We do this in order to learn how clients view their situation as opposed to imposing a strict expectation from our side on what information should look like. This principle manifests itself in the form of loose validations in models and forms.
Of course, all decisions have tradeoffs and in this case, being more permissive means we have issues around address parsing and integrating with different counties’ sites, who may vary slightly. The Daily Drive is the dedicated time for us to run background jobs to submit the SNAP applications and then dig into issues when they fail for some reason. This is super useful because you learn so much about how your Rails application really works for your users. It’s also nice to have dedicated time for investigating operational issues.
This is a time for us to note failure patterns and figure out what needs fixing, then create tickets to address them. Most of these things have to do with validation of mailing addresses. For example, military base addresses don’t have street names, which can be confusing if you’ve not served in the military.
By the way, this is the most gratifying part of the day and the whole reason everyone comes to work each day. From 5pm onward, I spend some time doing cleanup, code review, email, wrap up, and get set up for the next day. I head home at 6pm on the train to watch British comedies and engage in Civil War cosplay with my 6 corgi dogs (Editors note: adapt quirks for your specific situation.)
The Longer View
Of course, some things don’t happen every day so it’s probably good to describe what one of our iterations looks like:
We refer to our 2-week-long development phases as “iterations”. We don’t call them “sprints” because we feel the term has negative implications about how fast we should be going when developing software. We focus on continuous improvement and creating a sustainable development pace in order to keep our team happy and healthy.
Planning Meeting
On the Monday at the beginning of the Iteration, we have a planning meeting to track our progress against our goals and plan work for the rest of the iteration.
Each quarter, we develop a set of goals and ways to measure progress in the form of OKRs (Objectives and Key Results). Typically, they’re 3–4 big themes we are working toward.
With this context, we ask ourselves: What are the big project priorities for the next 2 weeks? This is not just an engineering question — it’s about the product and all parts of our team (including partnerships and client success) are included to create the most complete context.
Once we have a picture of our priorities, we then work to describe what accomplishing those priorities will look like during the iteration.
Iteration Review
At the end of the iteration on a Friday, we take a moment to look back and see how we’ve done as well as what we could do to improve.
We gather the whole team and allocate 1.5 hours for the meeting. We remind ourselves of what we set out to do for this iteration and ask if we accomplished our goals. We might ask quickly “why” but we then get deeper into that in the next activity.
Retrospective
We use a live online tool to create three lists, each with an emoji as a title: Happy Face, Meh Face, and Poop Emoji. We all shout out ideas and thoughts as they come up, and we categorize them based on the emojis. Some items get greater emphasis from the group and we “star” them to discuss in greater depth once the “popcorn” period is over.
This meeting is very important to the healthy functioning of our group, and as such, is the only non-optional meeting.
Wrapping Up
Again, if this sounds like a day you might enjoy, you can apply to work with us or get in touch with us by email. Thanks!
