Below is an article originally written by Adam Stewart at PowerToFly Partner Rover, and published on May 9, 2018. Go to Rover's page on PowerToFly to see their open positions and learn more.
One of the many problems facing the tech world is a lack of diversity. At a previous position in my career, I was in a diversity training program with 32 people. Thirty of them were white males. Now that I'm at Rover, I'm proud to say that diversity is something we spend a lot of time and resources addressing and it's reflected in the diversity of our team. We feel that implicit biases and subjectivity in the hiring process should be actively addressed and, to the extent possible while still evaluating a candidate as a whole person, removed from the picture.
Borne from one of these conversations was the need to make our hiring process as anonymous as possible to remove bias, and we started by looking at the take-home coding challenge. As part of our normal engineering interview process, we give candidates a challenge to work on independently and return to us. Our goal with the take home coding challenge is to solely review a candidate's coding and design abilities, independent of the candidate's past work and years of experience. In theory, this is the place in our hiring funnel that can be completely scored based on technical skills.
To accomplish this, we realized we needed to revise the take-home project to be anonymous in order to mitigate any implicit biases a reviewer may have. With the full support of management, I added tickets for this to my sprint schedule. This had an impact on the velocity of my normal work, but it was the right thing to do. I worked with the hiring managers and other interested people across several teams to design and review the new process to get a system that would work for everyone.
Our old process
Before the anonymization project, when a candidate started the take-home challenge, we would create a new Github repository based on their Github username to maintain unique naming patterns. This project would be shared with the candidate for them to finish. Once the candidate was finished and had committed the last bit of code and documentation, they would notify the hiring manager.
The hiring manager would then get two engineers to review the code, and would add them to the Github repository. They would also add them to our hiring software as reviewers so they could input the results. This software sends out an email with deadlines and information. It also allowed the reviewer to see the resume, phone screen results, and some other information about the candidate in order to make a more informed decision. Once our internal review was complete, the results were submitted to the hiring manager who would make a decision on the candidate and if they should make it to the next step in the process.
Our new process
We decided there wasn't enough value in seeing the candidate's whole set of information (resume, name, years of experience, etc.) to justify letting any internal biases affect our decisions.
Therefore, we first removed the candidates Github username from the repository name. Now the projects only have a date and two initials as an identifier. This keeps the repositories unique without exposing the candidates choice of username.
Since some candidates leave identifiable information such as adding files based on their name, or signing their readme file, we needed to do something to prevent that. We now have instructions emailed to the candidate that inform them that they should not include any personal information in the project.
After the candidate is finished with the project, the hiring manager runs a short script against the candidates repository that replaces the candidate's username with the hiring manager's username. This preserves the log messages, which can be valuable, but obscures who actually did the commits.
The next difference in the process is that the hiring manager no longer adds the reviewers to the hiring software until after the review. The Github access is granted, and that is the only link the reviewer has into the candidate. The reviewer can now review the code as a standalone set of data without any bias.
The final change is that once the code review is complete, the reviewer submits the review in a new document that is sent to the hiring manager. The hiring manager can then copy and paste the review contents in the hiring software at this point, and complete this part of the interview.
This whole change in the process puts a little more workload on the hiring managers, but we felt it was important to implement. They now manually run an extra script to anonymize the Github repository, and they copy/paste the review into our hiring software. This only adds a couple of minutes to each candidate.
As a company, Rover is committed to hiring a diverse team. Diversity attracts more people and is a sign of a healthy and inclusive culture. It creates a more welcoming workplace. It can spark creativity and empathy, and allows the team to better help the people we serve. We are constantly trying to reduce biases in all aspects of our company culture, and an anonymized coding challenge is one small but necessary step towards that.
Below is an article originally written by Brianne Killinger at PowerToFly Partner Rover, and published on October 5, 2018. Go to Rover's page on PowerToFly to see their open positions and learn more.
This is the fourth post in a series of interviews with our team of engineers at Rover. We'll introduce you to one of our Rover engineers, share their daily work and give you a peek into what it's like to work for Rover. If you're interested in an engineering career at Rover, check out our PowerToFly page.
As a full-stack engineer on the Rover engineering team, Allison Northrop creates operations efficiencies by working with internal groups at Rover that often work directly with customers.
What do you do as a Rover engineer?
Northrop: I work with internal teams at Rover such as customer experience and our booking assurance team. Our goal is to create tools to fix things on the site so that they can do their job faster and for Rover to scale efficiently. For example, if our customer experience team receives a flurry of calls about one particular problem or there's a lack of functionality, we work to find them a solution to ensure they're not getting bombarded. We work closely with our product manager to prioritize their needs and analyze what's the most plausible to address now versus later.
How long have you been at Rover?
Northrop: I've been with Rover for a little over a year. I started as an intern through Ada Developers Academy, a program funded by technology companies with a goal to encourage women and non-binary people to start careers in software development. Rover has been a sponsor of Ada and we have quite a few Ada grads working here currently.
What's an example of how you help these teams?
Northrop: Previously, once a stay was booked, you couldn't personally edit the stay. If your flight was delayed or you had to come back early, you would have to call customer experience to get it changed. It wasn't addressed for a while because it was very complicated to fix on the backend. Addressing this issue required five engineers, including me, over the course of three to four months.
What's your favorite thing about working at Rover?
Northrop: There's so many things that I love! Apart from loving to work with dogs, I love the product. I love that my role as a software engineer here actually makes a difference in people's (and pet's) lives. A friend of mine recently posted on social media that she started sitting with Rover and I know she's a parent and she wanted a more flexible schedule. It's great that I work on a product that helps people and helps dogs. I love the people who I work with and the mentorship I've received in my career.
How do you feel you make an impact in your role? What excites you?
Northrop: Even though everyone on my team has more years of experience in software development, my tenure at Rover is the longest. It's been rewarding to be able to answer questions and contribute a lot. I did a lot of ZenDesk integration work early on in my time at Rover and now I can help people with code related to that. I've also done a lot of customization and performance work in our admin tool, which is Django's built-in admin, so I help bring people up to speed on tickets related to that.
In terms of what excites me, I really love working for teams within Rover, while also impacting our customer base. I think it's satisfying to make people's jobs less of a hassle through the things that we roll out.
What's it like working across teams at Rover?
Northrop: Our product managers are incredible because they make working across teams really seamless. I think that it's important to have engineers interface with people that they're making solutions for and Rover's done a great job ensuring that happens. For example, when I was an intern, I had the opportunity to work with the quality assurance team who vet and approve our sitter profiles. I was able to sit with them, learn about the tasks they handle on a daily basis and listen to their suggestions on how their tools could be better. I was partnering with a product manager and she worked closely with me to prioritize solutions for them.
Tell me about a recent project you worked on that impacted Rover's customers or your team?
Northrop: When we were about to start the project to enable sitters to edit a booked stay, my mom called me and told me one of her friends needed a cat sitter and they did it through Rover. They booked it and plans changed. Her friend was really frustrated that she couldn't change the booked stay on her own and I thought 'if one of my mom's friends is having this issue, it's clearly widespread.' Working on that project goes back to the commitment that Rover has to make it easier to own a pet. Now that we've enabled the option to edit a booked stay, we've seen a dramatic 30% decrease in tickets related to that issue.
What's a technology you are especially excited about and why?
Northrop: Not sure if this counts, but since I use it every day I'm going to give a shout out to my IDE. I love PyCharm because it makes it so much easier to navigate through a large code base and helps me keep up good code quality. Some people use Atom, Visual Studio, or something else. There are so many options and here you don't have to use one in particular. Rover is really flexible in what IDE you choose.
What's your favorite meeting at Rover?
Northrop: I really love Tech & Treats! It's a meeting we have once a week where people across the tech org present on things they've worked on, how to fix performance issues, how to use tools we have, etc. You get to see so many things that people are working on or little tricks that people have learned. It's expensive to have all engineers in a meeting for an hour and it's nice that Rover is willing to invest that time. It's a great place for knowledge sharing.
Favorite spot in the office?
Northrop: Wherever Fondue or Freya can be found! I'm a big Bernese fan. I also am a big fan of my office space buddy Willie, a Nova Scotia Duck Tolling Retriever.
Are you a mentor or mentee?
Northrop: I just love how much mentorship happens on the tech team. I have been mentored by tons of people not just on my team but across the organization. One example that comes to mind is a ticket that was much more search-related, but it touched one thing on my team and we ended up getting the ticket. Search is not what I've worked on so I messaged someone on the team asking them questions. They came over and paired with me for 15 minutes and explained how it works and reviewed my code once I submitted. It probably would have been faster if someone on the search team took that ticket but they were willing to invest time to teach me about it. And now I can talk a little bit about our search filters!
Something also unique at Rover is that we also have "office hours" that different platform teams hold on a regular basis. I also took advantage of a weekly introductory React class that Rover hosted over four weeks. It was great that they created this curriculum – not every company will do that.
What are some of your passions outside of the office?
Northrop: I love to climb. There's actually a Rover climbing community on Slack. I'm not nearly as intense as most people and I just go to Vertical World. Whenever I go there, I always run into someone from Rover! I also like going to tech meet-ups like PyLadies and PuPPY and I'm still fairly involved with Ada through tutoring folks currently going through the program. I also have a orange tabby cat named Vincent. I'm happy that Rover is giving cats their rightful space in the codebase and that "cat" soon will not be listed as a type of dog breed.
Below is an article originally written by Brianne Killinger at PowerToFly Partner Rover, and published on June 26, 2018. Go to Rover's page on PowerToFly to see their open positions and learn more.
Editor's Note: This is the first post in a series of interviews with our team of engineers at Rover. We'll introduce you to one of our Rover engineers, share their daily work and give you a sense of what it's like to work for Rover. If you're interested in an engineering career at Rover, check out our PowerToFly page.
Rachel's role as tech lead for developer tooling on the Rover engineering team includes long-term planning, prioritization, code reviews, and working with teams on new tools. With Rover's explosive growth, her new role was developed in late 2017 to devote more energy to dev tooling for quality assurance and productivity.
What do you do as a Rover engineer?
Tobin: Dev tooling covers anything a developer needs to get their job done and make their lives easier. This can be anything from updating code on the website, ensuring the code that is shipped is of a certain quality, and looking at what kind of automation we can introduce to make sure things like "oops, I forgot a semi-colon here" doesn't get out into production.
What's your favorite thing about working at Rover?
Tobin: I love the energy! We're achieving cool things and everyone is growing so the environment is very motivating. Being able to affect decisions and be a part of that is exciting. What we're doing now is so different than when I started two years ago because of the increased scale and volume.
The culture here is to move fast. Why wait? We can get the code out and start collecting data on it right now instead of waiting a week and get hamstrung.
What's it really like working with dogs in the office?
Tobin: The dogs in the office make it cool. I grew up with dogs. I'm now more of a cat person, since I'm at a point in my life where I prefer lower maintenance pets. If I was to get a dog, I'd want a herding breed who have a huge amount of energy. In the meantime, I can come into the office and pet all the coworker dogs.
Tell me about your your typical day at Rover.
Rachel: Coffee. First thing in the morning, coffee. While I'm commuting, I'm catching up on Slack to see what happened overnight. Our infrastructure team gets here very early, so then my next priority is to check in with them. Then my team has a daily stand-up at 9:45am. There's about seven of us who cover dev productivity and performance and our team name is the "Ibizans," which is an uncommon breed of a hound dog. In fact, each of the nearly 10 engineering teams here has an uncommon dog name like Jindos, Ridgebacks, and Salukis.
After stand-up, I will start looking at code reviews on GitHub, which is a decent chunk of what I do. Other people have submitted code changes and I review them to make sure it's accomplishing what we want it to accomplish and the style is accurate. That will lead to conversations to clarify could we do this in a different way, what did you mean here, etc.
Who is typically submitting changes to code?
Tobin: Anyone at any level on the engineering team can suggest a change to code. The process is democratized. And there are no strict rules on who can review code. You want to find someone with the most knowledge and context because we view code reviews as a knowledge share as well. The review process can be really useful for less senior engineers to see what thought process is involved so they can understand the code better in the future.
What's the processing of updating code?
Tobin: We also deploy code 20 or more times a day. A lot of times companies will do staged releases and they'll build up a version and ship it once a week or once a day. For me to get code out in the wild, I make a PR, someone reviews it and it can immediately ship. You can push a button and it will go through automated processes and then it's out in the wild.
We trust our developers to be able to push that button to deploy. We've also had a pretty heavy reliance on automated systems. Our testing suite is very large and robust. The culture here is to move fast. Why wait? We can get the code out and start collecting data on it right now instead of waiting a week and get hamstrung.
Tell me about a recent project and how it's impacted your day-to-day?
Tobin: We recently made a big switch with how we deploy our code. We switched from a long-time tool in the tech industry to a different service, Buildkite, that will run our tests and eventually deploy the code. It's been a game changer for us. We pride ourselves on our deploy times—we can get something out in 20 minutes. With the previous tool we could only get something out in an hour. With this new tool, we're able to see much faster build times, and ship things faster to benefit the customer more quickly.
What do you do for fun at Rover?
Tobin: I'm part of a video game and board gaming group here. We have a Switch in our "Poodle" conference room and we have a board game library. We play a lot of Dominion since it is easy to pick up and play it relatively quickly.
The Rover team is made up of fanatical dog lovers, and that enthusiasm drives everything they do. From building progressive new tools to supporting the sitter community or writing for their awesome dog blog, employees thrive in this self-directed environment where accountability is key and everyone sees the immediate impact their work makes on the Rover community.
The team, comprised of creative problem solvers and eclectic overachievers, is deeply committed to Rover's mission. They bring the company's core values to life, celebrating each other's successes with a culture of humor, fun, and a little irreverence, too.
At Rover, named one of the world's most dog-friendly offices by Inc.com, every day is "bring your dog to work day." Employees who don't have a dog of their own can even get funds to help adopt or foster a dog. Whenever team members want to get away, Rover helps cover their dog's staycation with the perfect sitter, and employees who moonlight as sitters on Rover accrue additional days off—just for watching dogs on the platform.
Are you a fellow dog lover who is interested in joining the team at Rover?
Then click here to see all of their available opportunities, and don't forget to press 'Follow' to receive custom job matches, event invitations and more!