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

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.

We all have our favorite tools, yet I find myself finding useful apps and services in the most unexpected places. These tools help us get our jobs done. Seeing as it's the end of the year, I asked a few of our software engineers to highlight a tool they found especially useful in 2015.

Aquamacs

by: Sayem Khan

2015 was the year I first switched to Aquamacs from regular Emacs, along with using a Mac instead of Fedora as my normal development setup. I thought I would hate it at first, but I couldn't be happier. My normal Emacs config has no menu items, no scrollbar, and is just a black screen with green text. I don't use the mouse one bit when I'm on my editor, like many Emacs users. Aquamacs, on the other hand, has a very OS X-like UI; it has a navigation bar at the top, along with a scrollbar, and it lets you organize your work in tabs, which is pretty cool. All three of those things were pretty new to me, but they've speeded up my productivity.

Bugsnag

Also by: Sayem Khan

Bugsnag has been an indispensable tool in our team's day-to-day development, and I was first introduced to it earlier this year. It's been a real pleasure to work with, and support from their team has been great. Bugsnag automatically notifies you of exceptions caught in production, and it presents it all in a nice dashboard for your team to tackle them one by one. It also has a handy API which you can use to gather more details on the root cause of any exception, filter specific exceptions by their class type, and also customize it for your QA and staging environments. I highly recommend Bugsnag for your team's workflow.

tmux

by: Ben Fischer

If you plan on running a process on a remote box that will take a long time, tmux is a great tool. It allows you to run a process without keeping your ssh connection open. If you just run a process in the background, the system will kill it if your connection dies. But with tmux, you can disconnect from a box and reconnect to it later to check up on your process without worrying about it being interrupted.

httpie

by: Rodrigo Kochenburger

HTTPie (pronounced aych-tee-tee-pie) is a command line HTTP client. Its goal is to make CLI interaction with web services as user-friendly as possible. It provides a simple http command that allows for sending arbitrary HTTP requests using a simple and natural syntax, and it displays colorized output. HTTPie can be used for testing, debugging, and generally interacting with HTTP servers.

Vim

by: Daniel Nill

2015 was the year I learned how to vim. Everyone's heard of it and it has many proselytizers, but if you've never taken the week or two to force yourself to use it as your primary editor, the learning curve can seem very intimidating. If you want to sincerely try out vim, be prepared to sacrifice some productivity for the first week. I suggest you learn to move around using the vim quick keys and then start exploring some popular packages to make your development experience even faster and easier. After that, continue trying to learn a new shortcut or tool in vim every week. After using vim for a little under a year, sublime text, my editor of choice for the previous 3-4 years, seems tediously slow.

ngrok

by: Jason Seifer

Securely tunnel to localhost with ngrok. This is practically a necessity when testing external API callbacks locally - just run “ngrok [port]” and you get an external address that can be used to view local changes on the web.

htop

by: Mujtaba Badat

Having to track down why your process is unexpectedly dying and a server becoming unresponsive isn't a frequent occurrence, and that can make it hard to know where to start. When it happened to me, it was challenging to figure out what was going on without the right tools. A coworker suggested htop and was nice enough to show me how to use it (hint: it's dead easy). With a simple command I was able to watch the total memory usage grow until the box ran out of resources. After isolating a few things, it was obvious that a gem we were using for concurrency was leaking memory like an umbrella made of tissue paper. Once the gem was swapped out, the htop dashboard made it simple to verify an improvement in memory usage immediately.

Dash

by: Alejandro Ramirez

Dash downloads documentation for various languages and frameworks, which allows you to access them, even if you're offline. You can easily google search for them, but Dash really comes in handy when your internet is laggy or unreliable. I use Dash when I run into a method I haven't used before. I quickly just filter out by framework and search for the method. The search functionality is very fast.

ECMAScript 6 (ES 2015)

by: Matthew Witek

ECMAScript 6 is the newest version of the ECMAScript standard. This standard was ratified in June 2015. ES2015 is a significant update to the language and the first major update since ES5 was standardized in 2009. Implementation of these features in major JavaScript engines is underway now.

ES2015 has taken note of many of the things we love in coffeeScript. These include arrows acting as shorthand for declaring functions, lexical ‘this’, classes, string interpolation, iterators (for..of, for..in), and language-level support for modules for component definition. Also included is fixed hoisting, the use const for declaring constants, maps, sets, weak maps, weaksets, which provide efficient data structures for common algorithms...the list goes on. Javascript is somewhat more predictable, and that in itself is a big win.

Paw

by: Bruno Miranda

I've been on the hunt for a good looking and fully functional REST client for the Mac for a while. cUrl is great for small requests, but composing larger bodies with form params and bearer tokens in the command line isn't a very pleasant experience. Paw allows me to compose HTTP requests and save them as templates. Support for JSON requests and well-formatted responses makes it a pleasure to use. Paw supports OAuth 1 and 2, Basic Auth, and S3 auth. It also let's you export the request in a variety of formats.

What tools did you adopt in 2015 that helped you get work done? Follow us @dox_engineering if you'd like to be notified about updates to this blog.