IndiaFilings Technical Writer Interview: Rounds, Questions and Preparation

What the job involves

A Technical Writer in Indian SaaS and B2B products creates user guides, API references, help articles, and release notes for software used by businesses. You work closely with product managers, engineers, and support teams to turn complex features into clear, step-by-step documentation. The role also involves maintaining a documentation portal, updating content with each release, and sometimes writing in-app copy or onboarding emails.

Role and technical knowledge

1. 1

   What is the difference between a user guide, an API reference, and a release note? Give an example of when you would write each for a B2B SaaS product.

   A strong answer defines each type by audience and purpose. For example, a user guide for an accountant using an invoicing feature, an API reference for a developer integrating payments, and a release note for all users about a new bulk upload option.

2. 2

   How would you document a REST API endpoint that creates a new customer in a billing system? Walk me through the sections you would include.

   Cover endpoint URL, HTTP method, authentication, request headers, path or query parameters, request body with field descriptions, sample request, sample response, status codes, and common errors. Mention that you would test the endpoint using Postman or curl before writing.

3. 3

   What is docs-as-code, and why do many Indian SaaS companies prefer it over traditional help authoring tools?

   Explain that docs live in a Git repository, are written in Markdown or reStructuredText, reviewed via pull requests, and published automatically. Benefits include version control, collaboration with engineers, and faster updates with each release.

4. 4

   How do you decide what to include in a help article for a B2B product where users may have different roles, such as admin, manager, and end user?

   Talk about audience analysis, role-based content, and using conditional text or separate articles per role. Mention that you would avoid exposing admin-only steps to end users and would use clear headings like For admins and For team members.

Practical scenarios

1. 5

   A product manager asks you to document a new GST filing feature in two days, but the feature is still in beta and the UI may change. How do you handle this?

   A strong answer suggests writing a draft based on the current build, marking it as beta or subject to change, scheduling a review after the final release, and using a content reuse approach so only the changed sections need updating.

2. 6

   You receive a support ticket saying a help article is confusing because it mixes steps for two different subscription plans. How do you fix it?

   Explain that you would split the article into plan-specific sections or separate articles, add a clear note at the top about which plan the steps apply to, and update the search keywords so users land on the right page.

3. 7

   An engineer gives you a rough internal design document full of acronyms and database table names. How do you turn it into a customer-facing help article?

   Describe your process: identify the user goal, remove internal jargon, replace table names with UI labels, add screenshots or short videos, and ask the engineer to review only for technical accuracy after you rewrite for clarity.

4. 8

   Your company is launching a mobile app for an existing B2B web product. What new documentation would you create, and how would you avoid duplicating content?

   Mention a mobile-specific getting started guide, a feature comparison table between web and mobile, and single-sourcing shared concepts like account setup. Use conditional tags or separate tabs for platform-specific steps.

Editing and tooling

1. 9

   Edit this sentence for a help article: 'In order to be able to generate the invoice, the user must first make sure that they have clicked on the save button.'

   A strong edit is direct and action-oriented: 'To generate the invoice, click Save.' Explain that you removed unnecessary words, changed passive to active voice, and used the imperative mood.

2. 10

   What is the difference between a style guide and a template? How would you use both when writing for a fast-growing SaaS company?

   A style guide sets rules for tone, terminology, and formatting. A template provides a reusable structure for a specific content type, such as a how-to article or release note. Use both to keep documentation consistent across writers and releases.

3. 11

   How comfortable are you with Git, Markdown, and a static site generator like MkDocs or Docusaurus? Describe a small project where you used them.

   Be honest about your level. If you have used Git for college projects or a personal blog, describe branching, committing, and opening a pull request. Mention any Markdown editor or static site you have tried.

4. 12

   You need to include a screenshot that shows a customer's real name and invoice amount. What do you do before adding it to the documentation?

   Explain that you would blur, crop, or replace sensitive data with dummy values. Mention that you would use a test account or demo data whenever possible and follow your company's data privacy policy.

Behavioural and HR

1. 13

   Tell me about a time you had to explain something complex to someone who was not technical. How did you make sure they understood?

   Use a specific example from college, an internship, or a project. Focus on how you broke the topic into steps, used analogies, checked for understanding, and adjusted based on their questions.

2. 14

   Why do you want to be a technical writer in a SaaS company instead of a developer, tester, or support role?

   Show that you enjoy simplifying complex ideas, writing, and working with product teams. Mention that you like the variety of learning new features and the direct impact on customer experience.

3. 15

   Describe a time you received critical feedback on your writing. What did you do with it?

   Pick a real example, such as a professor or peer marking your report as unclear. Explain that you asked for specific examples, revised the structure, and now apply that lesson to your writing process.

4. 16

   How would you handle a situation where an engineer says your documentation is wrong, but you followed the product spec exactly?

   A strong answer says you would thank them, ask for the specific difference, verify against the live product or a test environment, and update the doc if needed. Emphasise that the goal is accuracy for the user, not being right.