Engineering Blog

We’re the ZocDoc engineering team, and we love sweet code, dogs, jetpacks, TF2, robots, and lasers... all at once. Read about our adventures here, or apply for a career at ZocDoc!

Hello, ZocDoc – Training New Developers

As ZocDoc has grown we’ve scaled our systems massively. But it’s not just our technology that has had to scale – our technology organization has as well.

While we pride ourselves on only hiring the best developers that we can find, they all have one fatal flaw: they weren’t born with an innate knowledge of the various technologies we use to build ZocDoc. Unfortunately, modern science has yet to develop the ability to upload new knowledge directly into people’s brains. So while we wait for that to happen, our only choice is to train them.

The Before Times

Back in the day, “training” consisted of giving a new developer a computer, showing them how to open Visual Studio, and then throwing them off the proverbial deep end. Okay, perhaps it wasn’t so dire, but there really was not a formal or well defined training process. The typical experience for new developers on day one was basically: get a cursory overview of our codebase from another developer and then be assigned an introductory project which would allow them to dip their toes into the source code. As developers worked their way through the project, a natural form of training would occur as they sought answers to the questions that inevitably arise.

Sure, it was informal and ad hoc, but it worked. And so long as we remained small, it would continue to work. Unfortunately, our own insistence on growth rendered this approach untenable.

The Now Times

Eventually, we hired a big enough wave of new devs that we were faced with a problem. Training them all in the manner we were accustomed to would have been a nightmare; we would waste resources repeating the same information, and when questions arose only one person would benefit from the answer.

The solution was clear: we needed to train them simultaneously. If that solution seems eye-rollingly obvious, it’s because it should be. Nothing about how we train our developers is particularly revelatory, nor should it be. Teaching always works the same way at a fundamental level: have an expert talk about it, answer questions people have, and then let them practice it. Rinse, repeat. However, we consciously made two philosophical decisions that guided how we would approached the topics we would cover: breadth over depth and no magic.

Breadth over Depth

Breadth over depth means we cover many topics a little rather than a few topics a lot. This sounds like the adage, “jack of all trades, master of none,” but it is ideal given the circumstances. First, training is “only” 2-3 weeks, so as a practical consideration we just can’t cover topics to the level of detail that you would in a semester-long college course. And second, we don’t need to: our new hires are self-learners, and will naturally seek out that depth themselves. Therefore, the goal of training isn’t really to educate per se, but to simply show our trainees all the various things they may not know so that in the future when they encounter the topic again they’re not completely ignorant. Of course they’re not completely alone; they have their peers and experienced developers to guide them.

No Magic

If you’ve done software development you’ve probably heard the term “magic.” “Magic” is pejorative jargon meaning any software functionality whose implementation may not be readily understood by a competent developer. Magic is bad because when something goes wrong (and it inevitably does) it’s hard to diagnose the problem. You have to painstakingly deconstruct it while things are breaking (possibly in production!).

However, if you’re an inexperienced developer learning a new technology stack, a lot of things seem like magic to you. Good training demystifies complex systems so that they don’t appear magical.

The Process

Besides those philosophical points, there shouldn’t be anything too surprising about training itself. Long before our first official “class” of trainees arrived, a small group of developers broke down the various topics we felt it was important to cover. The final list in no particular order was:

  • ZocDoc Business
  • ZocDoc Architecture
  • .NET/C#
  • SQL
  • The Internet/Web
  • HTML/CSS
  • JavaScript
  • ASP.NET MVC
  • UX
  • Git
  • Developer Tools
  • Software Engineering
  • Team Fortress 2
  • Testing
  • Release Engineering
  • Interviewing

Those are a lot of topics to cover in two weeks, especially considering that certain topics (.NET, SQL, JavaScript) have both basic and advanced sections. But again, breadth over depth. Some of the topics, like HTML, may seem really basic, but if you’ve never actually made a web page before, we’re not going to hold that against you. It is better that some trainees be bored than others miss crucial information. A few of these topics are noteworthy. For example, ZocDoc Business and ZocDoc Architecture function as bookends to our training. On the very first day we’ll teach ZocDoc Business, a course which covers all the things about ZocDoc that you probably can’t glean from the outside: our processes, our structure, and cool new things that we’re working on that aren’t ready to be shared with the public just yet. ZocDoc Architecture happens at the very end of our training, and is really the only course that’s specifically about development at ZocDoc. Again, we do this for breadth over depth. Our developers will be learning ZocDoc-specific stuff anyway, so we give them as much general knowledge as possible. After we broke down the topics, courses were assigned to volunteer developers and designers who put together materials. Once materials were completed, they were reviewed and presented to existing developers. Feedback was given and materials were revised. Finally, when our first wave of new hires arrived, they were all seated together in ZocDoc University, our largest conference room. They were then sequestered there with no food, no water, and only a single monitor for the full duration of training (okay, they had food and water – free lunch, in fact). As each course was presented it was recorded and its materials committed to source control for posterity. The end goal of training was to have all the new hires build a simple feedback web application we call “ZocTweets”:

All trainees worked towards the same goal so they could help and learn from each other. When training was done, all the trainees underwent code reviews. Experienced developers came in, critiqued the trainees’ code, made suggestions, and asked questions. The trainees were rewarded with a desk with four monitors and maybe a little bit of extra knowledge on top of the experience.

The After Times

At the end of training, new developers aren’t going to be as productive as an experienced developer, and we don’t expect them to be. They still have a lot to learn, especially around the more intricate parts of our architecture. The training simply prepares them to solve the problems they’ll face.

Most of the lessons learned since rolling out this process have to do with gauging the difficulty of a given topic (which is tricky when you live and breathe this stuff). Our recommendation for anyone designing similar training is to go even more basic than your gut feeling when it comes to your material.

And that’s the nature of the beast: We’re continually refining our training, and we hope it gets even better in the future. It’s a learning experience. You might say even say we’re in training…