The other day an old co-worker from my days at Microsoft on the Oslo/M/Quadrant projects, asked if a college friend could pick my brain on being a content developer in advance of his upcoming interview at Microsoft for that role. I wrote back a lengthy reply (because it's fun for me to think about such things), and in the spirit of Scott Hanselman's Keys Left pricinple, I'm sharing all of that here.

To respond to the young man's question, I asked myself, what would I be looking for if I interviewed someone for the job? I had to admit that I've been through only one content-specific interview myself. It was just a couple of hours because I already had such a strong reputation. The interview was really more about getting to know people I’d be working with.

First, let me explain how I see the role of "content developer" vs. "programming writer." I personally like the idea of “content developer” much more because it opens itself to many kinds of content that aren’t just about writing: code, videos, presentations at conferences, improving answers on StackOverflow, etc.

I’ve seen too many people with the title of “writer” get stuck in the mindset that their job is to put words on a page, and that they measure success by how many words they write. A content developer, on the other hand, measures success in terms of effectiveness of communication—does the content I’ve produced help developers get to the needed information and answers quickly? And does it answer the questions they actually have, including one they’ve not identified yet because they’re still learning a technology?

Thinking this way, content development is an ongoing process just like software development. And just as with software, sometimes the right answer in that development is to cull, prune, and even wholesale delete large amounts of previous work because they’re obsolete, unhelpful, or otherwise don’t have much value.

Side note: It’s worth thinking about what this means in terms of metrics collected for content. Traditionally, people have worried about page views and time spent on page, but for developers, this doesn’t necessarily make sense. For developer documentation, the real question is whether they found their answer quickly, which means time spent on page is actually irrelevant. (That measure is really applicable only to sites that have on-page advertising, because more time means they can charge more for that advertising space!)

Next, I looked through the job listing itself (on the Microsoft Careers site) to see what skills it identifies for the role. Here are my thoughts on those:

  • “Enable the creation of amazing apps, innovative services, and creative experiences through the education of the developer ecosystem.” This tells you that the role is very much about education, not performance as an code-monkey. It’s about the ability to effectively and clearly communicate, so be prepared to demonstrate where you’ve had success in this way.
     
  • “It will be your job to learn about Microsoft platforms and technologies in order to teach devs…” I like to say that this role is all about suffering as much as possible in order to save many other developers from suffering. That is, I like to go through pain and anguish to figure out some difficult task because within Microsoft you have the luxury of then going to the engineering teams that create the stuff itself. Nobody on the outside—that is, the customers your serving—have this luxury. So you’re the bridge to take what they know and present it in a way that external people can most effectively utilize. A specific implication of this is that although engineering teams can afford to think in the silo of their particular domain (such as touch input), a content developer has to meaningfully relate those specifics to a much broader picture, such as “gaming apps” that happen to use touch input…and a whole lot of other stuff! So be prepared to demonstrate any experiences you’ve had in being that kind of a bridge, of taking specific details and putting them in a broader context.
     
  • “This role leverages your passion for teaching, writing, and coding.” And in that order! So be prepared to demonstrate that passion. I will add that one of the most important qualities to demonstrate—something I would certainly look for in a candidate—is empathy. You cannot be an effective teacher or writer if you don’t understand the people you’re trying to educate or communicate with. So how do you go about understanding that audience? Think about that and be ready to talk about it, and if people don’t bring up matters of empathy or knowing your customer, bring it into the conversation yourself. I, for one, like to go to developer conferences for this purpose. I also like to read other blogs, monitor questions on forums (and answer a lot of them!). And when I’m writing, I try to keep part of my awareness separate so it can immediately respond to my work as if I was an outside reader. In that way I’ve been able to anticipate questions that someone might have, and then answer them right away.
     
  • In fact, a short time later the description says, “You’ll walk in the shoes of your customers…” This is what empathy is all about!
     
  • “You’ll start by diving into code and collaborating with people across engineering, design, and marketing to understand the end to end story.” Again, big picture thinking is part of the equation here, so demonstrate that you have the ability to collect a lot of specifics and abstract them into the big picture. And clearly, the ability to collaborate is very important. You need to be able to relate well and work with people who aren’t like you, but just as essential to the shared goals. Be prepared to give examples of anything you’ve done along these lines, e.g. working effectively in teams. As a new college grad you won’t be expected to have done too much of this, but even to understand the need is super-valuable.
     
  • “Deliver code samples and technical assistance”: this is where the rubber meets the road, because in the end it is about delivering content. Be prepared to talk through how you’ve managed your own projects and assignments—how you’ve organized tasks, kept yourself to a schedule, and checked for quality.
     
  • “Engaging deeply with the community”: again, this is super-important for developing empathy.
     
  • “Excellent writing skills”: Do you know what the big secret is about writing? That it’s 80% editing. It’s one thing to put your thoughts down on a page. It’s another skill entirely to go through it several more time to make it better and better. If I were conducting an interview I’d actually quiz people on this, i.e. give them a piece of writing and have them think through how to improve it. I’d spend more time on this than I would on code, although I’d probably do the same thing with code (more on this in a moment).
     
  • “Graphics background a plus”: This isn’t so much about being a graphic designer as it is about the ability to express concepts through diagrams and illustrations. Take a look at the latest MSDN magazine article of mine for some examples. Or for a much bigger piece of work, download my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition. I did all the illustrations and graphics for that one myself—what’s in the book is straight from my files.
     
  • It’s not mentioned in the job description, but if you’ve done any video production and editing, showing those projects would be a big plus. Take a look at the One Dev Minute video series (https://channel9.msdn.com/Blogs/One-Dev-Minute). These are really working to communicate as efficiently as possible—they have lots of studio and graphics support, but if you have anything to show that approaches thoughtful editing in the video space, that would certainly be a plus.

Now for a few other thoughts:

  • Don’t worry about tooling—you'll learn on the job in a matter of days. At best, familiarity with some industry standards like Markdown might help, but really, you’ll get all the specifics in the process of the job.
     
  • The ability to do on-the-spot coding exercises as is traditional with software development interviews is not all that important to content development. In content, your job is much more about using code as a means for explaining concepts, techniques, and so forth. It’s part of documentation. I would want to make sure a candidate could write good, clean, and well-documented code, especially where the commenting explains the bigger picture of how all the code works and how it might relate to code that uses it. In other words, being able to explain why you chose to do something the way you did is often more important than the simple how or what.
     
  • In fact, what I would potentially ask a candidate is to show me an application project they’ve worked on, walk me through what it does, give me an architectural overview, illustrate the relationships between the key pieces, and explain what pieces could be most useful to other developers writing similar applications, and what parts are more specific to the project itself.
     
  • Let me return to the question of editing. There are two main things you to consider, and perhaps also practice instead of trying to solve coding problems.

     

    • I highly recommend spending time with the existing content produced by the team you’re be interviewing with. For example, if someone was interviewing for the team I'm currently in, I'd want them to go through the topics on MSDN under Cross-Platform Development. Reviewing that material would familiarize you with the technical areas that my team's involved with, but more importantly, pick a few topics that you understand pretty well already and ask: how would I improve this content? And overall, could you think of ways to improve the whole table of contents? Does the ordering of Getting Started material make sense to you? If you were just starting out, would you find this content engaging and effective, or are there changes that might improve it. These are things that writers and content developers should have opinions about.
       
    • If I were doing an interview, instead of having you write code from scratch, I’d show you a few pieces of code and ask how you would improve them to make them more useful as samples or as documentation? (Samples are documentation.) I’ve seen plenty of crappy samples in my time, and could explain to you exactly why they are crappy as a sample (even if they are good code from an engineering standpoint). To that end, find some samples that are relevant to the team you're interested in (including ones they've produced), and study them. Do you think these are good samples? What about them works well as educational material? What about them can be improved and how would you make those improvements? It would probably be helpful to spend more time with one of the samples to the point where you can give an on-the-spot tutorial about how it all works, as I suggested above.

 

In the end, I think content development is a pretty cool career path. You get to be deeply involved in technology, but you don't get so buried in the details of creating it that you lose sight of how it relates to everything else. I, for one, thrive on seeing, understanding, and communicating those relationships, and enjoy serving other developers in this way. In fact, I'm more delighted with a clear, well-written explanation or a clear illustration about how a piece of code works than I am about getting that piece of code to work in the first place. That's why I've always gravitated to content and community work.

If you feel the same way, this is definitely a career path to consider, especially as content is increasingly seen today as one of the keys to technology adoption, which is especially important with startups and innovators.


Comments are closed