Our Doximity application has gone through many stages of evolution since the first commit in June of 2010. It began as a small Gemfile consisted of Rails 2.3.5, authlogic, paperclip and will_paginate. No micro-services, no Dockerfiles, no message queues, not even much JavaScript.

As we built richer user interfaces, we started writing more JavaScript using Backbone as the front-end framework. One thing became apparent over the years; JavaScript kept coming up in our retrospectives because it slowed down development. Writing features in Ruby on Rails was considerably faster than Backbone but we didn't want to compromise the flexibility we had with Backbone. It was time for us to reevaluate our front-end options.

Luckily for us, the JavaScript ecosystem has progressed rapidly over these 7 years. But porting 105,000 lines of JavaScript wasn't an easy pill to swallow. Without jumping to rash decisions, we decided to take a week to experiment with the popular frameworks that existed. Our initial choices for this experiment were Ember and React.

The Showdown

A group of four engineers took two weeks to build the initial front-end application in Ember and React. This included boilerplate tools we needed such as authentication and assets, and some commonly accessed pages. Thereafter, we sent an email to all of our engineers to take a week implementing specific features within the Ember and React applications. It took a bit of coordination due to engineers being on separate teams but we managed to make it work by staggering it across 4 weeks. Below is the email that kicked it off:

As per an earlier email I've sent out, we are going to spend a week learning and implementing features in Ember & React. Here are the schedules for when you will be working on it and who you will be pairing with. Due to an uneven number of people, there is one team of 3.

I haven't had a chance to check vacations, if you are on vacation that week please let me know ASAP.

[ Group Assignments ]

What To Do:
1. Join #javascript to ask any questions.
2. Spend 1-2 days reading up on Ember and React. Use the resources provided for
   Ember and React. Pair with your group for any questions or discussions that come
   up around the material. You will be assigned two small stories to implement a
   feature in Ember and React. Do both by pairing with your group and submit it as
   a pull request to the channel. Expect it to be reviewed by other members of the
   team.
3. Make any updates to the README as necessary to help the next group of people
   working on it.
4. Take notes on what you found useful, hard, complicated so when we review it
   weeks from now, you have notes.

If you have questions, reach out to me directly.

The Review

Once everyone finished their implementations, we started sharing the feedback within the team and did a retrospective on this experiment. During the experiment we had two new frameworks that made it into the mix unexpectedly. Angular 2 and Vue were introduced as people had extra time and believed they can also help solve our problems. Needless to say, there were plenty of opinions in the form of 32 lengthy emails, 12 pages of notes and too many Slack messages to count. The decision on our front-end framework boiled down to these five considerations:

  1. The community around the frameworks and how active they were.
  2. Our feature development process at Doximity. We work in two week iterations and allocate resources often towards spiking new prototypes and split testing new ideas. This was easy for us in Ruby on Rails, and we didn't want to lose velocity in this regard.
  3. Ease of implementing features following good design practices without fighting the framework. Ruby on Rails, once again, made this easy.
  4. Coordinating work with our design team and leveraging our Vital CSS framework.
  5. Writing end-to-end tests, which we never found ideal within a Ruby on Rails application.

For the majority of these decisions, React and Vue met most of our needs. We are all big fans of Ruby on Rails, especially for the convention over configuration aspect of it. React often led us into bikeshedding discussions. But with Vue - it just worked. Therefore, we chose to move forward with Vue slowly.

The Vue Forward

So, how were we planning to migrate our front-end features to a Vue SPA? The plan was going to take the better part of a year but we wanted to approach this cautiously. There was no rush. Here’s how we did it:

  1. We knew we had a lot of front-end components that we needed to build or port over from Backbone. Therefore we catalogued the components we had and the ones we would need and began work on these. We weren't implementing any user facing features but simply building the backbone so engineers can focus on building features. We eventually open sourced the project called Genome.
  2. We identified all the required features we needed within the SPA to build our pages - from server side rendering, to deployment strategies, to state hydration and created stories to track them.
  3. Following this, we had two dedicated engineers working on the SPA implementation to ensure the required feature sets were brought into the mix.
  4. Meanwhile, we provided material for other engineers to brush up on ES6 and Vue through online courses and books.

That brings us to where we are now - implementing user facing features with a single MOFO team. Keeping the implementation to a single team will help us continue to polish the SPA while we get our feet wet with Vue.

We could have moved much faster if we wanted to, but there is value in carefully evaluating technologies as they pertain to our business and teams. In this case, we chose to move slower with purpose and not break things.


I started working at Doximity as a Software Engineering intern in May of this year. The internship was my first experience working in the Bay Area, and more importantly, my first time working somewhere other than my home country: Canada.

Working in the United States for the first time was an enormous leap for me, with a lot of uncertainty. However, now that the internship is nearing its end, I can confidently say I couldn't be happier to have had this opportunity at Doximity.

How To Measure the Quality of An Internship

1. Mentorship, Growth, and Learning Opportunities

The most important aspect of an internship to me is mentorship and growth. As a third year Software Engineering student, I want to gain as much practical knowledge as I can from my work experiences. I want an internship to teach me industry standards, best practices, and to offer the practicality I find school sometimes lacks with its theoretical focus.

Full-time Mentorship

Starting out at Doximity, I was paired with a full-time mentor from day one. This was awesome because it introduced me to a friendly face right from the get-go, and gave me a resource to ask any questions I had about company values, technologies used, and best practices for said technologies.

Having a mentor in the company helped me to grow as a developer through pair-programming, code review, and discussing technical topics such as database design, object-oriented design patterns, the tradeoffs between these patterns, and agile methodology best practices.

Library Card Not Needed

One of my favorite things about Doximity is the company library. The company has dozens of books (both physical and electronic copies) on various technical and non-technical topics, ranging from web technologies and object oriented design patterns to data science and engineering management.

Eager to take advantage of the wealth of knowledge at my disposal, I asked my mentor for recommendations, and he suggested I read Practical Object-Oriented Design in Ruby: An Agile Primer. This book helped me to become a better object-oriented designer by making me more conscious of the patterns I was using, as well as the trade-offs between various object-oriented design techniques. Furthermore, it taught me practical ways to use the SOLID design principles I learned in a theoretical way during school. After reading through the book, I noticed an immediate difference in the code I wrote and felt it greatly improved my engineering judgment when tackling software design related problems.

nice

Backtracking to my point about mentorship, the biggest plus for me as an intern was discussing the contents of the book with my mentor. This was helpful in solidifying the design techniques and best practices suggested by the book, as well as discerning which aspects of the book to focus on in my daily software development.

2. Work Culture & Work Life Balance

Move fast, ship often

The engineering team at Doximity has a culture of moving fast and shipping often. On average, the engineering team deploys to production around 30 times per day, for dozens of apps and microservices - including this blog!

:shipit:

Me shipping the engineering blog you're currently viewing to production via our #deployments slack channel.

A testament to the speed of how the company progresses is the onboarding process. As a new hire, an engineer is able to ship code to production on their first day.

Working in an agile environment taught me techniques of how to break down larger tasks into smaller, more manageable chunks to make the sum of the parts less daunting and easier to digest - such as breaking complex tasks into smaller stories.

Work From Home Wednesdays

Work From Home Wednesdays are a great way to recharge halfway through the week and focus on work from the comfort of home. It's great because I don't have to commute to work on Wednesdays, which means I can sleep in!

I've taken this opportunity to work from various cafés in San Francisco, Oakland, and Berkeley - which was a nice way to explore the Bay Area during work.

3. Social Culture

The social culture is what I believe separates Doximity from other companies. It's allowed me to form meaningful connections with full-time employees and other interns at the company.

Shack Lunch

Every two weeks, you have the option to opt-in to a 'shack lunch', which randomly assigns teams of six people from various departments for a group lunch.

Shack Lunch

Myself (left), and another intern Jitin (right) at a lunch event

This was a fantastic way to meet and interact with people at the company who I don't normally interact with on a day-to-day basis. Talking to other employees in various roles around the company gave me a better understanding and appreciation for the many different aspects which make a business function.

Events and Games

Doximity had an abundance of games, events, and tournaments during my time here in the summer - including a company-wide shuffleboard tournament and an 'arcade hoops' tournament.

Unfortunately, I bowed out early in both tournaments (I was never a good baller and I consider myself a shuffleboard novice), but I still had a lot of fun. Both tournaments had very inclusive environments, which made me feel very welcome at the company.

Doximity also has an annual summer internship competition where two teams of interns compete against one another. This entailed each team hosting a company-wide event, which was critiqued by a panel of full-time employees. Our team was responsible for organizing the 'Doximity Shuffleboard Tournament Finals,’ where we decorated the 'JBar' (the company bar), served food/drinks, and provided commentary for the evening festivities.

Final Words

Key Takeaways

Good written communication is 🔑 for software engineers

Working on a team with large remote presence helped to make me a better-written communicator.

Most of our communication is done via email, Slack, Pivotal Tracker, and GitHub, so having strong written communication skills is essential to being a successful member of the team.

Agile Principles: Communicate frequently, and deliver often

Agile Manifesto Principles

The principles of agile methodologies, such as early and continuous delivery of software and frequent communication with your stakeholders, helped me realize the importance of having business people and developers working together through the development process.

It's okay to make mistakes: we learn from them

No one’s perfect. Everyone makes mistakes - and that’s okay.

I made a bad assumption for an edge-case when writing a Redis-based locking mechanism for concurrent jobs in our internal deployment tool.

The tests I wrote accounted for the poor assumption in my code and led to some failing sidekiq jobs in the deployment software.

I was concerned this assumption would be a big issue, but we simply reverted my changes so I could fix them, and re-ran the failing deployment jobs.

This experience taught me a valuable lesson: everyone makes mistakes, and it’s part of the learning process. The important thing is to stay calm, keep a level head, and not lose your cool when debugging or devising a solution; it’s a natural part of the software development life cycle.

Conclusion

Working at Doximity has been a phenomenal experience - abundant with numerous opportunities for personal growth as an engineer, and as an individual.

Working at my desk in Doximity HQ

I couldn't be happier to have had my first work experience in the United States at Doximity and will be sad to return to school and say goodbye to all the friends I've made in my four months here.

Andrew Robert McBurney

...

Special thanks goes out to Jey Balachandran, Bruno Miranda, Chris Woodrich, and Priya Gangolly for reading drafts of this blog post, and for giving me their feedback!

Be sure to follow Doximity Engineering @dox_engineering if you'd like to be notified about updates to this blog post.

I’m a third year Software Engineering student at the University of Waterloo, currently finishing up my internship as a Software Engineering Intern at Doximity. I can’t believe there are only three weeks left; time really does fly when you’re having fun. My goal with this post is to cover as much internship-related information as possible. To do that, I’m going to organize my experiences into a Q&A where I answer the questions I generally have when going into an internship.

Q: What’s the interview process like for an intern?

A: I really enjoyed the Doximity interview process, it was quick, efficient, and made sense. There were a total of three interviews over the course of a couple days. Each interview was with a different senior engineer, and they were each about 45 minutes long. The interviews tested applicable technical knowledge, which is something I’ve rarely seen in internship interviews. By “applicable technical knowledge” I mean knowledge that will contribute to success on the job. In the four months I’ve worked at Doximity, I’ve been able to apply answers to these interview questions directly to my work. The interviewers also left a good chunk of time to pitch Doximity to me and for any questions that I had. The whole process is very prompt. Within a day of finishing each interview, someone will reach out to you with next steps, whether that be a follow-up interview or an offer. I really appreciated this transparency because a lot of other companies I was interviewing with at the time took weeks to get back to me. There’s nothing a student appreciates more than quick turnaround on decisions (thanks to Doximity’s awesome Technical Analyst, Jackie!)

Q: How’s the learning experience?

A: This is the most important thing I look for in an internship, and is the biggest factor in how I rank my internships. If you’re looking for a TLDR, here it is: Doximity ranks first out of my 4 internships in terms of learning experience.

As far as technology goes, I learned a lot. I primarily worked with Rails applications which was great for me as I’ve never used Rails in a professional setting before. My last two internships were full stack roles in the Javascript ecosystem, and I can safely say I feel a lot more at home with Rails than I ever did with Javascript. Furthermore, coding in Rails is, by far, the most fun I’ve ever had coding.

Working

Coding in Rails at the Doximity office, told you it's fun.

Let’s talk mentorship. When I was hired, I was assigned a personal mentor who has been there to answer any questions I’ve ever had (thanks Krish, really appreciate it!). Having a personal mentor is great; it makes learning easy and it gives me great comfort knowing that there’s someone there who’s always willing to help even if he’s busy.

The biggest learning from my time at Doximity isn’t regarding any specific technology. It’s the development of a trait that many good engineers seem to have: the ability to switch between code bases often and make contributions right away. In the last few months, I’ve worked on 7 different applications -- and I’ve been able to make valuable contributions in each. These applications include the main Doximity app, Email Delivery, Heaven (our deployments app), Orientation (our internal wiki), and a bunch more. I attribute this success to the support I got from my mentors and the trust they had in me delivering the required features.

Q: What’s a day in the life of an engineering intern?

A: A regular work day for me starts at 9:30am. I usually begin with reading some emails and checking for any slack messages. I’ll take a look a quick look at Pivotal Tracker to remind myself what tasks I’m currently working on and peek at what’s in the backlog. At around 10:00am, I’ll send a message to a slack channel consisting of my mentors, letting them know what I worked on yesterday, what I plan on working on today, and anything that’s blocking me (a “text scrum”). After that, I’ll “officially” start working on the tasks I’m currently assigned. This means coding, testing, asking questions, etc. At noon, I’ll join some co-workers to have lunch and crack a couple jokes; then I’ll get back to work till about 5:30pm.

Doximity has Work From Home Wednesdays (WFHW). At first, I thought I wouldn’t enjoy this concept because I’ve always believed work stays at work, but after the second WFHW, my opinion changed. Working from home in the middle of the week splits the week up beautifully, boosting my productivity the second half of the week. On Monday and Tuesday, you come into the office and be productive. On Wednesday, you can catch your breath, work in your PJs, run day-time errands, and not have to commute (meaning you can wake up at 9:00am, though, I’m not saying I have...). Then, back to the office on Thursday and Friday, and it’s already time for the weekend! Work weeks have never felt so manageable. WFH Wednesdays gave me the energy to work hard for the entire week.

Where does the fun come in? After work at 5:30pm, a bunch of folks head up to the JBar (our private rooftop lounge) to grab drinks, play shuffleboard, or chill. I recommend going on a Tuesday or Friday, when most people are there. Doximity really values work-life balance. I’ve never been asked to work overtime, in fact, I’ve been discouraged from doing so. This is huge because, before coming down to the Valley, I had always heard that everyone works really late (sometimes because they don’t want to be the first to leave). Sounds terrible. During my time here, I’ve been able to maintain a solid weekday schedule of work, gym, dinner, and home by 8pm. You know what they say - a healthy body and a healthy mind equals a happy life (I don’t really know if they say that).

Q: Why Doximity?

A: First and foremost, Doximity is a company with a real purpose and meaningful goal. For a lot of people, even myself, working with friendly and caring people is the most important part of a job. In my opinion, the next biggest factor in enjoying work is how much you resonate with and support what the company is doing at a product level. A company can always say they have a good culture, which Doximity does (see Q: What’s the culture like?), but one thing everyone should know before joining a company is what the company is trying to achieve. Before joining Doximity, I could clearly see that it could save lives by solving a fundamental problem in the medical industry: lack of communication.

At Doximity, we have the ability to see firsthand the difference we’re making. Aparajita Singh, a San Francisco Gastroenterologist wrote in, “I was struggling with a complex patient with a very rare condition -- sclerosing mesenteritis. I easily found an article on Doximity authored on that topic by an expert and was able to contact the author. He told me about a medicine that he was trying out on his patient and it just all worked out. Thanks Doximity!"

Doximity alleviates doctors from the headaches of their jobs and is bringing the communication technology in the medical industry up to present standards. Unfortunately, prior to Doximity, it had been stuck in 90s. It is safe to say that Doximity’s impactful line of products and services played a big part in my decision to work here.

Q: What’s the culture like?

A: The way I would describe Dox culture is with the old saying, “work hard, party harder!” Actually, that downplays how hard people here work, so let’s go with “work harder, party harder!”

Right off the bat, Doximity has quarterly offsites! Let’s crunch some numbers here - that’s 4 offsites in a year! Offsites are when teams get to meet up at an awesome destination, reflect over the last quarter, and celebrate their accomplishments. I was lucky enough to go to Seattle for the engineering offsite, all expenses paid by Doximity! Big shout out to Rachel and Amy for organizing everything beautifully! My favorite part was meeting co-workers who I don’t get to talk to on a day-to-day basis. It also didn’t hurt that I got to see a new city for free. For the offsite, we all select an activity that we’d like to do while we’re there; in Seattle, the list included kayaking, paddle boarding, a Boeing facility tour, visiting the Space Needle, and more. I tandem kayaked with my coworker-friend Chris and we had a great conversation while taking in the beautiful views of Lake Union.

Seattle Doximity

The Doximity team at the Seattle offsite.

At this quarter’s offsite, all the engineering teams proudly presented the features they implemented. It was mind-boggling to see how much stuff got done in only 3 months. Numbers speak for themselves and, during these presentations, I saw a lot of graphs that went up and to the right. You don’t have to know much about stats to know that’s a great sign.

Everyone’s extremely smart here, but also extremely down to earth. One night, I was on LinkedIn and decided to stalk some of my co-workers; I must have gone on a 7 profile streak of PhDs! These are coworkers who I would have never imagined being PhDs, not because they don’t seem smart, but because of how humble they are. I’ve never felt even the smallest bit of arrogance or superiority radiate from anyone. I like to compare Doximity to their hometown basketball team, the Golden State Warriors. There is no LeBron James or Kyrie Irving; rather, there’s a collection of very talented teammates who play their role and do so very well.

Q: What are the benefits of interning at Doximity?

A: There are many perks to working at Doximity. Starting off with the basics: I’m paid well, I get my flights to-and-from home reimbursed, and I get free lunches and snacks. Lunch is delivered to the office by Eat Club, which allows you to pick lunches from a wide variety of local restaurants. If you’re looking for filling, protein-packed meals, I suggest going with the Butter Chicken or the Chicken Tostada Salad (who would have thought you can get 40g of protein in a salad?).

Another big benefit to working here is you get to live in San Francisco! Full disclosure: at first, I probably wouldn’t have listed this as a pro. Mostly because I’m a huge homebody, but also because SF is just a lot different than my hometown of Toronto. But every day I’ve lived here, I’ve grown to love the city more and more. If there’s ever a day I’m feeling down, all I have to do is walk out my door and go for a little walk. A big part of this is I really love the neighborhood I live in (Russian Hill). Some advice for future interns: I advise you spend a good amount of time looking for the neighborhood that’s right for you.

Russian Hill

The view from my house, right at the top of Russian Hill.

Another awesome part of being an intern is you get to participate in the Annual Doximity Intern competition. All the interns get placed on a team and each team is asked to organize a party after work centered around events happening at the company. For example, my team’s party took place on the night of Doximity’s shuffleboard tournament finals, and the opposing team’s took place during karaoke night. The winning team gets to choose a costume they’d like the losing team to wear to the end-of-summer bash. I found both parties to be a blast, but at the end of the day, there’s always one winner (thankfully, it was my team!). We’re still deciding on what we want the other team to wear -- trying to keep it work-appropriate but also want to have a good laugh!

Conclusion

I hope that I’ve covered all the information anyone interested in a Software Engineering Intern position at Doximity is curious about. I feel very lucky, privileged, and blessed to have had this experience. Big shout outs to everyone at Doximity. Keep it up -- you have something very special here!

alt text

If you enjoyed this post and want to be notified about updates to this blog, follow us @dox_engineering. Also, if Doximity sounds like the place for you, check out the job board and keep an eye out for Doximity on your school job listings. Special thanks to Priya Gangolly, Bruno Miranda, and Jey Balachandran for readings drafts of this.

I’ve been working at Doximity as a Junior Web Developer since February 2017. It has been an amazing and rewarding journey. I feel like I have finally found a company that trusts in my ability to learn and grow. Here is the story of my experience as a Junior Developer, and a woman, at Doximity.

One of the things I’m most proud of is our culture of ‘Straight Talk.’ If you speak, you will be heard. If you have a great idea, actions will follow and your idea will become a reality. When I first joined the company, my mentor was great at guiding me through every step, but I felt a lack of female mentorship. After discussing this with my manager, I now have a female mentor in addition to a technical mentor. It has given me the confidence to communicate my needs and provide feedback through the right channels.

Another noteworthy fact: Women hold many leadership positions at Doximity. Our Head of Product, People, Marketing, Client Success, Mobile, are all women, just to name a few! We also have several programs to empower women at the company:

1. Engineering Mentorship

You’ll be assigned a mentor, regardless of your experience level, location, gender when you joined the engineering team. Your mentor helps set up your development environment and introduces you to the team. Mentors also walk you through your first-day assignment and assist you in pushing it to production. Yes, you heard it right. As a first-day assignment, you will push code to production! Your mentor will be your best friend, biggest supporter and frequent code reviewer. The mentorship usually lasts 3 months, but if you’re joining as a Junior Developer, like me, this can be extended longer.

2. Junior Developer Curriculum

When you start as a Junior Developer at Doximity, we provide you with structured self-study materials so you can become a competent developer. The program consists of video lectures, books, slides and in-house tutorials. The program is also flexible enough to be molded depending on your interest, experience level and pace. Speaking from personal experience, additional advice from our experienced engineers was really valuable in the process.

3. Code Review


Every team can benefit from code reviews, regardless of development methodology. It's a great chance to demonstrate your ability to solve a problem and expose areas where you can improve. In my experience, code review at Doximity is not about experienced engineers telling me how to code. It's more about helping me learn how to think and grow. Our code review stimulates conversations around code style, architecture, and overall workflow. A reviewer will often ask "why" more than "how." All reviews I received were with a positive attitude of constructive criticism and warm encouragement. This helps keep everyone engaged and distributes best practices across the team. I have personally learned so much from each conversation during code reviews and am grateful for the opportunity to interact with and learn from other awesome engineers.

4. Buddy Program

As a new employee at Doximity, you will be offered a "buddy" or "female mentor." This is especially helpful for newbies who want to make friends at the company and enjoy all the perks we offer. It also builds a supportive network from the beginning that is the hallmark of our company.

5. Women@Dox Monthly Breakfast

Doximity has an active "Women@Dox" group, a monthly breakfast series meant to initiate discussions that support women in tech. The meetings are lead by senior managers who empower us to speak up and have our voices heard. We discuss everything from personal development to company hiring policies and management practices. At the last breakfast, we talked about inviting influential women in tech for lunch-and-learns and reviewed company benefits like maternity leave. The breakfast is a great opportunity to meet female leaders at the company and "straight talk" over avocado toast.

6. Women-in-Tech Support

I've been most excited about how passionate Doximity advocates for women engineers. We host various events to help us grow, including an algorithm night with Hackbright Academy, a women-only bootcamp. It was awesome to see talented women developers pairing with our engineers to solve algorithm and data structure problems. All the women wowed us with amazing problem solving skills and impressive backgrounds. So much so that we ended up hiring a talented engineer from the bootcamp! I’m really happy to see Doximity put in the extra effort to hire and support women engineers like myself.

7. Quarterly Offsite, Explained

The offsite is a core part of the culture at Doximity. I was bit nervous before the first offsite, but it was actually much better than I had imagined!

First, we have Hack Day, typically done on the day of code freeze before offsite. Hack Day is fun and you will have a chance to work with people that you normally don’t get a chance to work with.

The main activity during the offset is a retrospective of how we did last quarter. We speak freely about the good and the bad. Our offsite isn’t a huge brainstorm where we try to come up with the best solution to the biggest problem we have. Rather, it’s a humble discussion on what we’ve done and how we can do better. We also take the time to plan for the following quarter based on lessons learned across the teams.

Another thing I appreciate about the offsite is flexibility. We have core activities but you can opt in/out of additional activities. There is no pressure and no judgement. If your thing is visiting science museums or famous jazz bars, you can do that after core hours. For me, the offsites have been a great chance to meet remote team members. I truly enjoy every minute of the three days with my teammates.

I feel very lucky to be at Doximity. Obviously, no company is perfect but I appreciate all that Doximity does to be better. I am not afraid of straight talk and happy to give my feedback if something doesn’t feel right. I also appreciate the company’s interest in valuing and supporting women, minorities and people from all types of backgrounds.

If what I’ve said sounds like it would be a good fit for you, take a look at our job page to see what teams are hiring! And I can say from firsthand experience that one thing I liked about Doximity from the start was its well-structured hiring process. To find out more about how we hire engineers, check out this article from our engineering blog.

Even the best interview process can be stressful and drawn-out. That's why Doximity aims to reduce stress and friction while making sure everyone still gets the most out of the interview.

tl;dr

We take a close look at all resumes as they come in. If a resume is a good match for the role, the first step is to schedule a 30-minute intro call. Take a look at our open positions for more info.

This call has a few important purposes. The first is to understand why you'd want to work at Doximity. We also want to make sure our expectations match up, so we’ll chat about salary, start date, and other important details. We’ll give you an overview of our company, discuss things like who we are, what we do, and tech stack. You'll learn more about our clients, products, and our team process. And last but not least, you'll have time to ask questions.

We typically decide on the same day of the screening call if we'd like to move forward. If there's a mutual fit, we’ll add you to our take-home assignment on Github. The assignment is a practical example of what you’d be working on at the job, rather than an abstract puzzle that might not tell us as much. It should take about two to four hours to complete, but there’s no hard limit. We want to see your best work, so we’ll give you time and space to shine.

When you’ve completed the assignment, a few engineers on the team will review it. We qualify the solution based on the following criteria:

  • ability to follow instructions
  • ability to solve the problem with clean and easy to maintain code
  • attention to detail and ability to make good decisions
  • completeness
  • performance considerations
  • test quality and coverage

After the assignment, we’ll decide if we want to move forward within a day. The next step is to schedule two 45-minute technical interviews. These take place onsite or over video conferencing, depending on your location. Nobody likes to answer the same questions over and over, so our interviewers will make sure to cover different topics. In these interviews, we’ll go over things like:

  • work experience
  • accomplishments you’re proud of
  • the take-home assignment
  • how you would solve real-world problems in software

It’s easy to get nervous during an interview and struggle with even a simple live coding session, so we won’t put you through one. You will be asked how you'd tackle technical solutions, and you may choose to use pseudo-code either verbally or on a whiteboard if it facilitates your problem-solving effort. There is no hard requirement to write any code, on the board or otherwise.

The Closer

If the technical interviews go well, we'll schedule a final 30-minute discussion for the following day with the engineering team lead. If you’ve reached this step, we'll likely extend you an offer. So, this is the time we discuss final logistics and answer any more questions you might have.

The last step is to check references and make a verbal offer. If you accept the terms, we’ll present a written offer within 48 hours.

Improving the Process for Everyone

Happily, our engineer hiring process has worked really well. Over the years, the take-home assignment has become fairly fine-tuned. In fact, we extend offers to about 40% of people we interview based on how they completed the assignment. We’ve found it to be a great way to put candidates on the right track and make the process more efficient.

Our method isn’t perfect, but we strive to appreciate and respect everyone’s time. And we’re always trying to make the process even better. We request anonymous feedback from those who have gone through the initial phone call, and we’ve gotten some great responses that help to make the interview process better for everyone.

Hope you enjoyed a peek into our recruiting process. Follow us @dox_engineering if you'd like to be notified about updates to this blog.

Thank you Hannah Frank for the illustrations.

Building software products starts with an idea.

A product idea can go a couple of ways depending on your company’s development culture. The idea could show up in a list of requests sent to someone higher on the food chain who will decide whether it’s a good idea. Or it could be an email to a specific engineer, pleading her to “PLEASE BUILD THIS IDEA”.

At Doximity, we develop ideas differently. We work towards what we call "MOFO" goals.

MOFO? Seriously?

Yes. MOFO is short for My Objectives For Offsite. What did you think it stood for?! A MOFO goal is:

  • Strategic: It should roll up into larger company goals
  • Achievable: A needle that can be moved in 12 weeks time
  • A stretch: No sand bagging here. We shoot for the stars

For example, a MOFO goal could be to launch and sign up 100 people on a new product. Or it could be to increase conversion on our registration funnel. Or it could be the less sexy, yet still important, task of reducing our page load time by 25%.

All MOFO teams set three MOFO goals per quarter to guide development priorities. We’ve found MOFO teams operate best in small, 5-10 person teams responsible for different products. Each team contains a group of engineers, a product manager, a data scientist, a designer and a QA engineer.

So how do we decide which three goals to focus on?

  1. As a team, we collect data, projections and ideas to discuss how these might fit into potential MOFO goals.
  2. Once the team has reviewed and discussed options, the product manager establishes baseline and goal numbers for each finalized MOFO.
  3. The leadership team reviews how the proposed MOFO goals align with company goals. Some ideas die here, and that can be a good thing.

Iterate / Implement / Iterate

MOFO teams work throughout the quarter in two-week iteration cycles. Our goals shape and prioritize the features in each iteration. While some traditional scrum roles emerge, the size of our teams encourages us to look beyond our functional specialties. That means the whole team has ownership and visibility into all aspects of development. For example:

  • Designers present on the potential variations they’re considering and get team feedback on which to use.
  • Data scientists share insights into the different models they’re testing and take suggestions on future model tweaks.
  • Engineers review and suggest product flow alternatives to help speed up user interactions or improve experiences.

As the team ships features, we showcase them on the all-hands weekly call with a summary of how the features impact the business or user experience. We also show how these features move us closer to reaching each MOFO goal, providing full transparency on development status.

The MOFO goals keep us focused but provide room for minor strategic shifts and creative solutions. Our 2 week roadmap can change based upon learnings from earlier tests.

The results are in...

At the end of the quarter, we meet at a company-wide offsite to discuss results. Did we meet our goals? How? We typically present on things like:

  • Split tests and variants. What did we test and how can we generalize those results?
  • New features that distinguish our products. How are we staying ahead of the competition?
  • Ways we reached or missed a goal. What if we had done things differently?

Presenting our results to other MOFO teams helps us to cross-pollinate ideas to improve upon the following quarter.

MOFOs allow us to try new ideas, to evaluate them and to decide whether that idea-turned-product is worth pursuing. This keeps us honest; if a product isn’t really working out after 3 months, should we keep trying? If something works, could we refactor our code to make it work with fewer errors? If it’s working well, how could we invest more to make it really shine?

Software development cultures come in different shapes and forms. Building product starts with an idea, but ideas can often falter without a process and cadence to guide them into production. For us, MOFO goals help empower teams to prioritize ideas and shape them into great products.