Although headquartered in San Francisco, Doximity has a thriving remote work culture. While the office is the historical hub of activity, a large portion of our hiring over the last several months has been remote workers. Remote employees might take a back seat to on-site workers in a lot of offices, but, at Doximity, remote workers are first-class citizens.

Meetings and Communication

We strive to stay as lean and agile as possible and to create a culture that isn’t overly focused on meetings. That doesn’t mean we’re opposed to them — in fact it’s quite the opposite. Person-to-person communication is important and fosters a sense of connection and team building. To put that into a real-world perspective, you’re not going to have meetings all day, and the ones you do have are quick, focused, and important. As a company, we’ve invested in the infrastructure to make these more seamless and plan to keep that up as we grow.

A little bit about company structure: there are several different main teams, each working on a different product. For example, on the DocNews team, we begin the day with a standup meeting. Each participant is expected to talk about what was done the day before, what they'll be working on that day, and any blockers they may have encountered. It’s a good way to stay in contact with the team and, in addition to the intrinsic value of the standup, makes remote employees feel connected. Not every team does stand-ups but the infrastructure and options are there.

“Estimation meetings” are used to gauge how many points to assign to different stories. We talk about the feature and all give a thumbs up when we’re ready to estimate. Estimating points is done in a rock-paper-scissors-esque manner where we count to three and then put up fingers corresponding to the number of points we think a story should take. If we have different opinions on point assignments, we take time justify our position.

We recently started using a web app called Stickies for our retrospectives. This lets remotes participate just like they were in the room. We also use live video chat during the meeting and collaborate using the app and Slack. Read more about retrospectives at Doximity to get more insight into how they work for us.

Pair programming is also something we remoters do occasionally. This is generally up to the people who want to pair; we don’t force mandatory pairing time. Schedules permitting, coworkers are almost always up for pairing. We’ve mostly used Skype for this, but we also occasionally use tmux and a shared connection.

Hardware and Software

We use the typical tools to manage communication across our team:


We use Slack for pretty much everything. In-office text communication is done with Slack, which puts remote workers on the same playing field as everyone else. All of our deploys are done via in-house software which is controlled via bot. This lets any engineer have visibility into what's happening at all times. Most teams have their own channels (or several) where pertinent data is accessible, and the same applies to shared roles such as QA.

Everything Else

We make use of Google Hangouts, Skype and appear for video chats and screen sharing. Now that Slack is testing out video and audio chats, we may start using that more actively. Skype is slowly being phased out but we do have employees who prefer it.

Occasionally, we’ll use a remote tmux session for pairing. When that isn’t feasible, we use Screenhero. Our timezone account gives us a nice view of current times for remoters.


Some of our conference rooms have recently been outfitted with Chromeboxes, which have exceptional video and audio quality. These help tremendously and have the least amount of headaches when setting up.

In Person Visits

Even though working remote has tons of benefits, so does face-to-face interaction. Remote workers can visit the office every couple of months between our off-sites. We have two corporate lofts very close to the office where employees can stay.

New employees come to the office for their first week. This time functions as an introduction to the office, team, products, and the process. Developers are expected to make a commit and production deploy on their first day. There is also a series of presentations that teach about the company, culture, and introduce new hires to their coworkers.

Working in the office also means you can hang out at the J-Bar, an office staple. As the name suggests, there is alcohol available should you wish to partake, as well as a gorgeous view of San Francisco. It’s also where we do our lunch and learns, meet-ups, and larger meetings. There is a camera and mic setup where remote participants can see and hear what’s going on as well as ask questions and interact with the presenter.

We also have off-sites every quarter. The off-site locations are different each quarter so we get to experience new places. With a diverse and remote team, off-sites are a chance to get everyone together in person. This helps to maintain the culture and provide an opportunity for everyone to realign and prioritize goals. We also share what we’ve learned and worked on the previous quarter and squash outstanding bugs in our bug bash.

A full development retrospective is done at each off-site. We try and concentrate on larger issues affecting all teams. I’m not trying to imply it’s all smooth sailing — it took a while to have a consensus on whether 80 or 120 characters is the proper line length for a Ruby file. (It’s 80, in case you were wondering.)

We’re Hiring

If you like what you hear about our remote environment, drop us a line and follow us on twitter. We’re hiring, and, obviously, remote workers are welcome :)

Special thanks to Bruno Miranda, Ben Fischer, Jaymes Waters, Greg Lombardo, and Daniel Zajic, and all Dox remoters for their feedback with this article.

Over the years, we've had several different flavors of Wikis. All of them failed to suit our needs at one point or another. When looking for a new solution we wanted a wiki that was easy to customize, non-bloated and had a good looking UI out of the box.

We found just that with Orientation. It's a small Rails app, highly customizable by anyone on our team. It comes with an interface that's easy to use and easy on the eyes. It also provides just enough features to be functional. We forked the Orientation's repository so that we can make changes as necessary. So far we've added image uploads and made a few other small adjustments.

Pages Contributions

Everyone should feel welcome and be able to contribute easily. For access right now we only require an authenticated Google apps email account from our organization domain. Once logged in you can browse and create new pages. The organizational system is fairly simple. We use tags to group related pages together and guides to provide a bit more structure to the documentation.


Guides are tables of contents for a subset of documents. A guide contains any number of links to wiki pages. We have a "New Employee" guide for newcomers and a product guide for each one of our applications.

Wiki Page on Writing Wiki Pages

This seems meta, but it helps people keep the wiki pages consistent and clean. A concise page provides guidance on naming conventions, tag usage and image upload info. We also provide a Markdown style guide on the sidebar of the edit page as a reminder of how to properly format pages.

With around 200 pages and growing, we couldn't do without search. Though Orientation does ship with basic search, we'd like to improve it. Ideally the search results would pick out the portion of the page that matches the search query for easier results parsing.

Endorsements and Subscriptions

Both really neat features of Orientation, endorsements and subscriptions allow users to let the page author know they've found the page useful, as well as subscribe for page updates. Page authors receive an email when their pages are endorsed. Subscribers receive an email when the page is updated.

Rotten and Fresh

Users can mark a page as "Rotten" if it needs to be updated. This notifies the author that the page needs attention. Marking a page as "Fresh" essentially reverts the status. This feature also ships out of the box. Though it may not be earth shattering, it makes keeping docs up to date a tiny bit easier.

Orientation is one of the nicest, non-bloated wiki engines I've found. The ability to modify it as we see fit was one of the biggest sellers for us.

Hope you enjoyed this peek into how our wiki works. I expect to write a few more posts about our engineering culture and processes in the near future. Follow us @dox_engineering if you'd like to be notified about updates to this blog.

Thanks to Natasha Singh for reading drafts of this.

It's no secret most software engineering interviews leave a lot to be desired. As an interviewer, do you ask candidates about their past experiences? Do you have them solve a problem on the board? Or even more awkwardly, do you have them work on a computer other than their own? It's understandable that lots of people get nervous and bomb these interviews. I've been there, on both sides of the table. It's not a fun day. So how do you make sure you get the most out of a couple hours of interviewing without making the prospective employee a nervous wreck? At Doximity we start with a coding assignment.

Why a Coding Assignment?

We believe the candidate should be allowed to showcase their skills on a practical and relevant assignment. A few days before the interview, we add candidates to a GitHub repository and provide instructions on how to complete the assignment. This allows them to work with familiar tools on their own computer, without the unnecessary pressure of someone looking over their shoulder. We want to make sure someone is capable of solving the problem at hand with clean code. Memorizing an implementation for an interview doesn't prove anything.

The Evolution of Coding Assignments

Our first stab at creating a coding assignment wasn't great. At first, we asked candidates to write an air conditioner controller simulator in Ruby. The unit would be responsible for ensuring the temperature stayed within 3 degrees of the desired temperature while being as cost efficient as possible. This assignment allowed candidates to showcase their OO design skills and Ruby knowledge. However, it lacked opportunities to showcase the use of JavaScript and required very little knowledge of Rails DSL -- both skills needed to perform the actual job.

We scrapped the original assignment for something more practical. We asked the candidate to create a simple blogging engine with authentication, seed data, specs, caching and a few performance optimizations. This assignment was much better at allowing engineers to showcase their Rails DSL knowledge, but it was too open-ended. We got submissions that vaguely fit the requirements and neglected implementation details. A lot of the details we found valuable for gauging knowledge and experience level were missing. This was totally our fault, so we decided to change it one more time.

Current Assignment

The third and current installment does a much better job of allowing the candidate to focus on well-defined tasks. Still using this blog engine, we ask candidates to add search and a simple scoring algorithm class. Though this assignment usually takes less time to complete than the previous one, it gives us more insight. We're generally able to gauge OO Design, JavaScript knowledge, Rails DSL and Ruby experience. The main difference with the current code is that the candidate starts with a much more feature-complete base application. Therefore we remove distractions such as: "Which gems should I use?" or "Should I install Bootstrap?" Instead, the majority of the time is spent on the things that help us determine if we want to invite the engineer for in-person interviews. And because it takes less time to complete, the current assignment is more respectful of the applicant’s time.

To keep things fresh, we tend to change the assignment requirements every few months.

There's some controversy regarding unpaid assignments. I've talked to other companies and interviewing departments who swear by a temporary contracting period prior to full-time hire. We've done this in the past, and I am not totally against this. The problem arises when the candidate is already employed and either has no free time or can't legally take on paid work for another company. Our opinion is that as long as the assignment can be completed in a reasonable amount of time, say 2-4 hours, it's an investment the applicant should be willing to make in their career.

The In-Person Interviews

During the in-person interviews, we use code from the assignment as talking points. We can then dive into the thought process behind some of the decisions made by the engineer. There are no absolute right answers; it's an exploratory discussion between the interviewer and interviewee. We may choose to ask questions regarding possible optimizations, current limitations, and alternative solutions. Having real code as a starting point allows us to limit interviews to two one-hour sessions. At the end of that time, we make our decision.

We continuously try to fine-tune this hiring process by using feedback from candidates. If you have any interview tips, we'd love to hear them. Likewise, if you're interested in working for Doximity, we're hiring.

Hope you enjoyed a peek into our recruiting process. I expect to write a few more posts about our engineering culture and processes in the near future. Follow us @dox_engineering if you'd like to be notified about updates to this blog.

Thanks to Jason Seifer, Jey Balachandran for reading drafts of this.

An Agile Retrospective is a meeting held at the end of an iteration or at a scheduled interval. In a retrospective, team members get a chance to voice their opinions on things that worked well and items that need improvement. Participants write their concerns and praises on post-it notes that are stuck to opposite ends of a wall. We read and review each topic one by one, take notes, and create action items on things that deserve more attention. Action items are assigned as stories and chores, and sent out to all participants.

We haven't been doing retrospectives since day one. At first they seemed unnecessary as we were a very small team. Whether that's ideal or not is water under the bridge. The fact is, they work. I want to write about the positive effects of Agile Retrospectives and how we've used the feedback and process to continuously improve.

I like to think we follow Agile practices in a non-cultish way. We've been doing this long enough to do away with some of the principles we deemed unnecessary. We only adopt the practices that fit our team and needs. This may not work for everyone, and I would certainly recommend you follow all Agile principles when first adopting the methodology. This will help you learn what works best for you.

We began with a team wide retrospective that included the entire engineering team, QA team, and a few of the product managers. The first few meetings were painful, not so much due to the process but mostly because we'd neglected things that needed attention. I guess I shouldn't have been surprised when the "Needs Improvement" side took over 80% of the whiteboard. Thankfully, we've seen a drastic shift for the better over the years. The "Needs Improvement" side has shrunk and given way to the "Good" side. As we focus on improving based on the constructive feedback, negative items are soon replaced by positive feedback and praise.

The graph above shows the trend based on our retrospective data starting on 2013

We now have team wide retrospectives every two months rather than every six. Sub teams within the engineering department also have smaller retrospectives slightly more often. They use these to discuss items pertaining more closely to their specific work and focus. This has worked really well.

If you're considering hosting retrospectives with your team, I'd advise the following:

  • Make sure all team members understand the purpose of the retrospective
  • Review previous retrospectives action items quickly before you begin, if you have any
  • Keep participants focused and any one individual from hogging the mic or going on lengthy tangents
  • Keep the meeting to one hour max
  • Have a moderator and a separate note-taker. We rotate these responsibilities at Doximity amongst team members
  • Include remote participants and make sure they have local representation for posting post-its on the whiteboard
  • Walk away with clear action items and assign them as stories and chores
  • Send out retrospective notes to all participants as soon as possible

The list above isn't comprehensive, but it's a good place to start. It has led us to a place where everyone is happy with the process, and the outcome has been nothing but positive. If you try this out with your team, let us know how it goes.

Hope you enjoyed a peek into our retrospective process. I expect to write a few more posts about our engineering culture and processes in the near future. Follow us @dox_engineering if you'd like to be notified about updates to this blog.

Thanks to Jason Seifer and Jey Balachandran for reading drafts of this.

In 2015 we've added about one engineer per month to our team, and hiring is likely to speed up a bit in 2016. Having a smooth on-boarding process has been, and will continue to be, key to our success.

We want to set people up for success. If you're lost on day-one, confused by a convoluted setup, chances are you'll struggle to keep up. Having been here for five years and having grown the engineering team to over 30 people, we've learned what’s worked and what hasn’t. Here are our best practices for setting up your engineers for success.

On-boarding Kickoff

Once an engineer signs the offer letter, the on-boarding process kicks off. We generate a new company email account, and invite the new teammate to all the services they'll need access to. Pivotal, Trello, Github, are a few. At this time we also add the email account to appropriate mailing lists. The employee doesn't get access to this new account until 8 a.m. on their first day. Boomerang (for GMail) is a useful tool capable of scheduling the delivery of the corporate email account's credentials.

During this stage we assign an engineer on the team to help the new employee during the on-boarding process which leads me to…

The "On-boarder"

This person is responsible for welcoming the new hire into the team on day-one. He hands over their laptop and shows them to their desk. We do hire quite a few remote engineers; I can't emphasize how important it is fly them in during the first week. Another important task is to introduce the new team member to the rest of the crew. Once intros are done, the on-boarding documentation guides the rest of the day.

On-boarding Documentation

We keep a Google Docs master document that we duplicate and adjust for every hire. It outlines basic details and expectations for "Day One," "Week 1," "Week 2," and so forth until "Week 6." This document is no doubt the MVP of the on-boarding process. By giving ourselves simple items to follow, we greatly reduce stress while making sure things happen when we need them to. Here are some example tasks contained in the document:

  • Ship code by EOD, add your photo to the team page
  • Schedule discussion with the PM of the project you'll be working on
  • Spend two consecutive days working on your assigned stories, expect about 50% of the time pairing with your mentor
  • Familiarize yourself with our wiki - particularly the "New Employee Guide"

Application Setup

We believe there's lots to be gained from setting things up by hand rather than trying to automate and package our applications into an image. Having said that, we've automated and polished the readme enough; getting it done is a fairly smooth deal. With the help from the "on-boarder", a new engineer can get a couple of our main applications set up in their local machine in a few hours. The on-boarder gives guidance and context and answers any questions while things build. The remainder of our applications and services can be set up fairly easily later.

First Few Weeks

I touched briefly on our motto of setting people up for success. Doximity runs a goals driven environment (our engineering teams work towards quarterly goals). Throwing a brand new person onto a team mid-quarter would be risky and unfair, so new engineers don't join a product team right away. Instead, they're assigned more general stories. These stories will help them gain an understanding of various systems within our ecosystem without having the weight of the deadlines on their shoulders, which could force them to take shortcuts.

We have fun and introduce people to our culture right away.

The Mentorship

Oftentimes, the "on-boarder" will also be the mentor. The mentor's role is to be the go-to person for any questions the newcomer may have. Having an assigned mentor relieves the possible stress or guilt of interrupting others while they work. The mentor also checks in a couple of times a week to answer any questions and remove blockers. Mentorship programs usually runs 1-3 months. They're also great learning experiences for the mentors themselves.

Code Reviews

Every pull-request intended to be merged into master requires at least one code-review and sign-off from a colleague. During the mentorship period, the pull-requests submitted by the new engineer will also be reviewed by a couple team leads. Not only do code reviews improve code quality, they also ensure work is going in the right direction.

Our Wiki

Over the years we've created and maintained a large collection of articles broken up by sections and guides. The "New Employee Guide" answers a lot of the basic questions someone would have on their first week. At close to 200 pages and growing, it's substantial, and we certainly don't expect someone to be able read the whole thing. The "Guides" point out the most important pages. I'll be writing more about our Wiki in the near future.

Another important aspect of this process is to collect feedback from new employees and use the feedback to fine-tune the process. There's always room for improvement, but I can say the process has drastically improved from what it was five years ago.

Hope you've enjoyed a peek into how we on-board. I expect to write a few more articles about our engineering culture and processes in the near future. Follow us @dox_engineering if you'd like to be notified about updates to this blog.

Thanks to Jason Seifer, Jey Balachandran, and Natasha Singh for reading drafts of this.