:tags:  career-growth, applying-for-jobs, storytelling

Interview with Ravind Kumar
===========================

Ravind is a senior technical writer working for `MongoDB`_ in New York. He has been writing technical documentation for 8 
years, writing mostly within the software industry but also has experience in writing for finance.

Key takeaways
-------------
* Know the domain that you want to write for.
* When writing documentation, don't make the user work for the information.


**What formal education do you have?**

    My background was in journalism. That's where I did 2.5 years out of my four year degree, switching from computer science to 
    journalism. My first job was a technical writing job because of that. I had the writing chops, but I also had just enough
    computer science knowledge to be able to read code.

**Did you know that you wanted to become a technical writer out of college?**

    I wanted to write and talk about software in some capacity, but at the time I didn't even know technical writing was a field. 
    I knew that documentation existed in general, but I was looking at potentially writing for a magazine, maybe having a technology 
    column. Once, one of my friends, my college roommate, he introduced me to this idea of a technical writer. It immediately made a 
    lot of sense to me. This was everything I was kind of hoping to do, being able to stay in sync with software design but at a
    level where I can do what I'm strongest at, which is writing, and not worry so much about the programming side, which I like, but
    I don't like enough to do as a living.

**What do you think you'd be doing had you not found technical writing?**

    If I had not found technical writing, I probably would have continued to do various levels of technical writing but from more of      a journalistic perspective. I don't know  what would have happened down that line. Because the year that I graduated is the year
    that a lot of newspapers started shutting down. Yeah, so I'm pretty thankful

**Ravind's first job out of school was as the sole technical writer at a mobile software development company called** `Phunware`_. **After some time, Ravind moved to New York and transitioned to writing in the finance industry for EOXLive, writing regulatory documents and user-facing documentation and market data /newsletter content. He now works as a senior technical writer for MongoDB in New York contributing to their server documentation.**

**When you were starting out with your first job, were those skills learned mostly in the workplace, or did you have some experience beforehand?**

    That was on the job. One of the projects managers walked me through the existing documentation. He gave me a quick tutorial on 
    InDesign, and I just took that and ran with it. And that's all we had at the time. The finance firm was a little different. I
    knew a little bit more about designing documentation. Most of my focus was on learning the financial regulatory side of things,
    so spending time on learning docs tools was a low priority. Mostly Microsoft Word and InDesign, and using various FOSS video
    capture/editing tools to create marketing-focused tutorials. MongoDB was my first experience using docs as code, using something 
    like a plaintext markup language and producing HTML from that.

**How collaborative was your work?**

    The finance job was the least collaborative, mostly because of the way finance works and the regulations we were up against. 
    I wasn't technically allowed to use the code or view the source code. I was mostly downstream of the application changes. 
    I should state that at EOXLive, the developers and my other business co-workers were happy to provide information, but compared 
    to other jobs it was more of a downstream operation - I typically did not contribute much back upstream beyond basic QA work. I 
    was also the only technical writer, so there wasn't a lot of co-writing to do. MongoDB has been the most collaborative, in the 
    sense that I'm not writing as much code. I don't contribute code to the core server product, but I have the highest level of 
    interactivity with the developers, product managers, VPs, from top to bottom. I have the ability to have conversations and
    figure out what's going to happen next, I have levels of ownership that are far higher than they were before.

**How has that ownership and responsibility changed with the progression of your career?**

    I think it's the scope that has changed more than anything, because at Phunware I was the only technical writer. So I had  
    complete ownership of all of our documentation that was produced. I owned all of that. At EOXLive, I was the only technical
    writer/business analyst. What I had ownership of had reduced in scope. I was mostly writing the documentation that was user
    facing and some marketing stuff. At MongoDB, I am on a team of two inside of a team of I think 20, inside of department of 40 or 
    50. My ownership, in terms of what I own out of the pie is actually quite small, but the product that I contribute to is very
    large. I don't document everything at MongoDB. At Phunware I documented all of their stuff. At EOXLive I documented all of their 
    software. At MongoDB, I only document the server, but that project is so large that it's still pretty significant. I do 
    definitely still feel like I have ownership but it's a little bit more of a shared responsibility.

**What advice do you have for the aspiring documentarians in the community?**

    If I were to go back to myself fresh out of college, I think the biggest thing would have been just reminding myself that you 
    have to put your diligence into learning these technologies. It's really not enough to do a surface read. That doesn't get you 
    far enough. That doesn't teach you enough to be able to write about topics in a way that other people will benefit from them. To
    me, that's the differentiating factor between a technical writer and a good technical writer. A good technical writer produces 
    documentation that is useful. A technical writer just produces documentation.

    Another piece of advice I'd give is that users really just want everything up front. They're not looking to have to bounce around
    a lot. That was like an older style where you would link to different pages and expect the user to put that information together. 
    You can still do that, but the expectation now is that it should all just be there.


Ravind goes by ``ravind-mongodb`` on the Write the Docs Slack group. You can find him in the ``#watercooler`` and ``#career-advice`` channels.

.. _mongodb: https://www.mongodb.com/careers
.. _phunware: https://www.phunware.com/company/careers/