List of Open Source Projects with Documentation Opportunities

After last week’s post about Docs FixIt Day at Cockroach Labs, I received several requests asking me to suggest open source projects that people can contribute docs to. As far as I know, almost all open source projects accept docs contributions. The following list includes some open source projects I find interesting:

If you have any favorite docs-friendly open source projects, tell me about them in the comments. And don’t forget to subscribe!

Update 1: Suggestions from the community:

Update 2: Came across this article: Open Source Maintainers Owe You Nothing, which I thought was a mandatory read for anyone who wants to contribute to open source projects. It is important to remember that developers and maintainers of open source projects usually work on these projects on their own time and dime, and it is not their responsibility to help us understand how the project works. We need to put in our own efforts, read all available documentation, learn about the project on our own, before we ask for their help.

Docs FixIt Day at Cockroach Labs

This week, I interrupt your regularly scheduled programming of technical writing techniques to brag about the incredible people I work with, who exemplify a company-wide culture of good documentation.

Let me give you some context: As most of you know, I work as a Senior Technical Writer at Cockroach Labs. For a major product release coming up in April, we had around 163 open issues to be documented for the release. Some of the issues were big-ticket items while a considerable number of issues were small but time-consuming fixes. It wasn’t humanly possible for our team of 4 technical writers to document all the issues before April. While brainstorming possible strategies to complete the documentation tasks, we thought of enlisting the help of our fellow Roachers* to contribute to our docs. The Engineering team had previously organized a successful Bugs FixIt Day, so we decided to replicate their model and announced a Docs FixIt Day.

We planned and prepped for days – announcing the Docs FixIt Day at the weekly team meeting, sorting through the issues and marking the ones we thought the engineers can take up, and of course arranging for snacks. Our fearless leader, Jesse Seldess, brought delicious Babka, and my fellow tech writer, Lauren, baked out-of-the-world, drool-worthy cookies.

We started the day with Jesse’s “Getting Started with Docs” presentation. He discussed the purpose of the FixIt Day, walked the engineers through the Docs toolset (GitHub and Jekyll), and announced the prizes – a Docs-team authored poem** and an Amazon gift card. The prizes would be given to the person who resolved the most Docs issues, and also to the person who resolved the Docs issue with the biggest impact.

We had 24 people in attendance for the kickoff session – in office as well as remotely. At the start of the day, we had 83 open issues marked as FixItDay. The participants included interns, engineers, engineering managers, and our CEO as well! They self-assigned the issues they wanted to work on and wrote docs all through the day till 6 PM. The last I checked on the day, we had 52 open PRs ! And people were contributing PRs even after that, so the final count might have been higher. (IMO, Jesse deserves an award for reviewing all the PRs).

To say the day was a success is an understatement. Not only did we get a big chunk of our documentation done, but the event also fostered cross-functional team collaboration. The engineers’ enthusiasm was infectious – they were totally invested and involved in the whole Docs process. We had given them the option of either working on the Docs end-to-end (as in they write, edit, revise the content), or just provide the raw content and the Docs team takes over the PR for them. But almost all engineers opted to complete the docs themselves, asking us for assistance with our GitHub process and SQL diagram generators and so on. This gave them a chance to understand the Docs toolset and they voluntarily helped us figure out how we can optimize the toolchain.

I have never been prouder to be a part of a company as I am now. As a technical writer, I am intensely aware of how big of an anomaly our company culture is. In most companies, docs are added as an afterthought and technical writers are considered a pesky annoyance. At Cockroach Labs, however, the importance of good, sound documentation is deeply ingrained in our DNA. And that is evident in all forms of documentation we produce – RFCs, user docs, training materials, or even meeting notes.  That is also evident from the fact that we already have a team of 4 technical writers for a team of around 35-40 engineers, when it is not unheard of at other companies to have one technical writer for 120 engineers. It is a privilege to work at a company where people genuinely care about good documentation and are willing to do everything they can to ensure we maintain the quality documentation we have. And I am thankful to be a part of an immensely talented team that is rooted in our core values: “Aim High and Build to Last”.

You can check out the awesome work our team did for Docs FixIt Day here.

*Roachers n. People who work at Cockroach Labs

**Poems written to express our appreciation for our peers is a time-honored tradition at Cockroach Labs.

My Writing Process

As an engineer-turned-tech writer, I have repeatedly heard “Writing is so hard; how do you do it?” and “Anyone can write”. Both statements are fallacious. Yes, anyone can write, but not everyone can write well. And yes, writing is hard, and it is made harder by the romanticized notions of inspiration striking, wooden cabins in the middle of nowhere, and solitude.

In reality, writing is a methodical, multi-step process. In this blog post, I attempt to break down my technical writing process so as to demystify it and hopefully make you think about your own process. The following image depicts my writing workflow for any technical document:

project workflow

As the image shows, my writing workflow consists of four phases:

Phase One: Research

My research phase consists of the following steps.

  1. Use the Cornell Note-taking System to briefly record the key points gathered from sources (reading materials, talking to engineers, attending meetings, and so on).
  2. Use the Feynman technique to ensure that you understand the information.
  3. Setup CockroachDB.
  4. Try out the feature being written about.

Phase Two: Draft

I use the 5-draft method while writing documents.

Phase Three: Editing and Reviews

Once I am satisfied with the rough draft, I edit my document using several techniques. Each technique helps uncover and correct different facets of the document:

  • Grammarly: Check spelling, grammar, adherence to technical writing conventions
  • Text-to-speech: I use the text-to-speech feature on my Macbook Pro to listen to the document. It helps me catch awkward sentence constructions, missing words, and so on.
  • Elements of Style: This little book sits on my desk and reminds me of my personal pitfalls/repeated mistakes. I have earmarked the style guidelines that I know I forget. Going through the book helps me ensure I am not repeating my mistakes.
  • Style guide: I go through the company style guide to ensure I adhered to it.

Once I am done self-editing, I open a Pull Request in GitHub which enables others to review my document. My review process is iterative, wherein my draft goes through technical and editorial reviews multiple times before it can be published. At Cockroach Labs, our engineers and other stakeholders (Product Managers, Sales, etc.) review the document for technical accuracy and completeness, and my manager and fellow technical writers review the document for editorial as well as technical completeness and correctness. The perks of working at a company that is deeply interested in good documentation 🙂

Phase Four: Publish

Once the reviews are done and everyone gives the LGTM (Looks Good To Me), it’s time to merge the document on GitHub and celebrate! Check out my Git profile here.

Try out the process, form your own, and share it with me at And don’t forget to subscribe!

Bonus: I track the various phases of each document in my bullet journal:

project dashboard


Deep Work for Tech Writers

One of the life-changing books I have read in my professional life is Deep Work (affiliate link) by Dr. Cal Newport. As I discussed in the Day-In-The-Life blog post, I start my day with one-hour (2 Pomodoros) of Deep Work. And that has been the secret to my productivity and success as a technical writer.

Following are a couple of resources that summarize the book far better than I could have. Go through the resources, try out the technique, and drop me a line at to let me know what you think of it. And don’t forget to subscribe!

Book summary:

YouTube video:


Pomodoro for Tech Writers

Thе Pоmоdоrо Tесhniԛuе iѕ a time mаnаgеmеnt mеthоd developed bу Frаnсеѕсо Cirillо in thе late 1980s.Thе tесhniԛuе uѕеѕ a timеr to break dоwn wоrk into 25-minute intеrvаlѕ, ѕераrаtеd bу 5-minute breaks. These intеrvаlѕ are nаmеd Pоmоdоrоѕ, thе plural in Engliѕh оf the Itаliаn word Pomodoro (tоmаtо), after the tоmаtо-ѕhареd kitchen timеr thаt Cirillо uѕеd аѕ a university ѕtudеnt.

The Pomodoro tесhniԛuе helps you асhiеvе the following:

  • Imрrоvе efficiency
  • Kеер away from diѕtrасtiоns and fосuѕ оn thе task аt hand
  • Imрrоvе timе-ѕеnѕе
  • Eliminаtе ѕtrеѕѕ burnоutѕ
  • Assist in аnаlуzing timе taken fоr tаѕkѕ

Hоw thе Pоmоdоrо Tесhniԛuе wоrkѕ

Thе Pоmоdоrо Technique rеgulаtеѕ when to diligеntlу fосuѕ оn a tаѕk аnd whеn you ѕhоuld take a brеаthеr.

This tесhniԛuе iѕ centered аrоund brеаking your timе down into роmоdоri (one Pomodoro iѕ еԛuаl tо 25 minutеѕ). You lоg a ѕресifiс tаѕk уоu are going tо work on and thеn ѕрrint уоur wау thrоugh thаt роmоdоrо. Aftеr 25 minutes of dеdiсаtеd wоrk, the timеr gоеѕ off аnd уоu tаkе a nice 5-minute brеаk frоm your wоrk.

Once your brеаk is over, уоu ѕtаrt аnоthеr 25 minutе long Pomodoro. This new роmоdоrо саn be dedicated tо thе ѕаmе tаѕk аѕ bеfоrе (if уоu did not complete it during thе previous роmоdоrо) оr a new оnе. Aftеr every 4 роmоdоri (рlurаl fоr роmоdоrо), уоu саn tаkе a lоngеr break, if уоu would like (ѕuсh аѕ fоr 15 minutеѕ).

While уоu’rе wоrking уоur way thrоugh a роmоdоrо, уоu can temporally interrupt it for uр to 45 seconds, if need bе. If thе interruption lаѕt fоr longer thаn thаt, уоur dеdiсаtеd fосuѕ оn thе mаin tаѕk iѕ viewed to bе lоѕt, аnd thuѕ thе Pomodoro iѕ rеѕеt (having tо ѕtаrt over at 25 minutеѕ) again.

Thе dеfаultѕ of 25 minutеѕ реr роmоdоrо, 5 minutеѕ реr rеgulаr breaks, 15 minutеѕ реr lоngеr break, and 45 ѕесоndѕ реr intеrruрtiоn seem to wоrk wеll for me аnd most people I knоw whо’vе triеd thiѕ hаndу tесhniԛuе оut. Hоwеvеr, that said, thоѕе arbitrary аllоtmеntѕ оf timе саn bе сhаngеd dереnding оn уоu реrѕоnаl hаbitѕ and ѕсhеdulе, ѕо аѕ lоng as уоu consistently ѕtiсk with thе аllоtmеntѕ thаt уоu’vе lаid оut. Fоr example, ѕоmе реорlе may prefer to wоrk “in the zоnе” for 50 minutеѕ, аnd then tаkе a 10 minutе break.

Why the Pomodoro Technique works

It is common experience that we can focus on a given task only for a short period of time before we get distracted (or seek out distractions). The Pomodoro technique helps to quantify and manage those focus periods. If you know you have to work for just 25-minutes, and then you can surf the web or check Facebook guilt-free, you will be more inclined to put in those 25 minutes of focused work. And you can get a lot done with 25 minutes of focus!

This technique has been a game-changer for me in terms of my productivity. As I discussed in the Day-In-The-Life blog post, I start my workday with at least 2 Pomodoros of focused work (which is almost one hour), and then I am free for the rest of the day to attend meetings, do some mundane tasks, socialize, or just goof off, because I have done the most important tasks for the day already.

The Pоmоdоrо Tесhniԛuе fоrсеѕ me to think in tеrmѕ of асtiоnѕ that nееdѕ tо bе tаkеn in order tо еffесtivеlу gеt things dоnе. It also imроѕеѕ thаt I рriоritizе аnd dесidе whiсh асtiоn I’m gоing to work оn. By hеlрing tо limit my аttеntiоn ѕраn tо a ѕinglе activity, thiѕ tесhniԛuе аidеѕ me in ѕtауing focused (instead of hopping between a handful оf diffеrеnt tаѕkѕ аnd/оr diѕtrасtiоnѕ).

Rеviѕiting my dаilу Pomodoro lоgѕ highlights whеrе I spend my timе аnd hоw рrоduсtivе I was thrоughоut a given timе period.

I now think of my tasks in terms of thе number оf роmоdоri thаt a givеn tаѕk might rеԛuirе. I diѕсоvеred that еvеn сhаllеnging tаѕkѕ саn оftеn bе tаkеn care оf in a handful of pomodori ѕеѕѕiоnѕ.

Try out the technique and let me know if it works for you. Drop me an email at And don’t forget to subscribe!

P.S: Here’s my favorite Pomodoro playlist:


Getting Things Done as a Knowledge Worker

I often imagine myself greeting my tech writing students as they graduate and enter the technical communication workplace. I imagine myself saying to them, “Welcome to the professional world. You have now graduated from being a tech writing student to a knowledge worker. And the key to succeeding in this role is not writing well, or being a good team player, but knowing what work to do.”

You see, in your days as a student, you knew what work was to be done that had pre-determined success metrics. You had set courses, with defined assignments and grading rubrics. You knew if your work was finished or not, and if you met the success criteria or not.

However, in the professional world, you will not be given a well-defined assignment. Instead, you will be given a “project” – a fluid, ever-changing best-guess scenarios developed by others in the organization. The success metrics are not defined either. As David Allen puts it, “There is usually no right answers; there are choices instead”.

As a technical writer, this is the part of the job I struggled with the most. With a never-ending stream of emails and Slack messages, changing roadmaps and company priorities, I was drowning in an information overload. I couldn’t get a handle on all the things that need to be done, let alone actually doing the tasks. At a time, I was juggling three highly technical projects that each required a considerable amount of brainpower and writes and rewrites. On the brink of a breakdown, I found David Allen’s Getting Things Done: The Art of Stress-Free Productivity (affiliate link). The book has been my savior. It has led to massive increase in my productivity and helped me maintain my sanity.

The Concept of Stress-Free Productivity

Anxiety quickly builds up when we begin to think about all the tasks we have to complete each day. It’s impossible to rely on our brains to remember it all!  The Getting Things Done (GTD) strategy works on the premise of relieving our brains of the stress of remembering all that needs to be done by appropriately capturing everything in writing.

Capturing this information in what is dubbed our “external brain” allows us to be fully focused on what we’re doing in the present moment. This increases efficiency and creativity.

My GTD workflow

GTD Workflow
My GTD Workflow

Develop the 4 Vital Habits for GTD Success

Applying GTD effectively requires more than just recording your to-do list. Making the GTD system truly work for you means embracing the following essential habits: capturing/collecting, daily processing, organizing, and weekly reviewing.

Capturing: Record ideas immediately. Keep notepads in places you frequent, make use of your smartphone’s virtual assistant (such as Siri or Cortona), or create a bullet journal. This helps your brain release the pressure of having to hold on to something to try to remember it. This ultimately releases your mental space so that you can focus on the present.

Daily Processing: Schedule time at the end of each day where you review each captured item and determine if you want to carry out the idea. If you do, you then need to determine the subsequent actions that must be taken.  Actions that require extensive attention should be added to a project list.

Organizing: Actions that can be completed in 2 minutes or less should be further categorized into calendar lists, next actions lists, and follow-up lists. Calendar lists are for time-specific items. Next actions are important, but don’t need to be done within a specified time-frame. Follow-up list items are those that are dependent on additional information or actions from another individual.

Weekly Reviewing: Schedule about an hour at the end of each week to check the progress of your task completion. Reflect on where you see yourself in the next 3 to 5 years. Think about the projects and tasks that will help you accomplish that vision. Prioritize the action items that must be accomplished in the following week to make this vision real.

Reward Yourself

The GTD productivity strategy may seem like more work than you’re prepared to do. Hard work deserves a reward. Treat yourself to something you like at the end of your weekly review. The trick is that you can only effectively complete that weekly review to get the treat. Approaching your weekly review this way increases your motivation to get it done.

Bonus resource: An excellent YouTube video that discusses the GTD method:



So there you have it: the secret to my productivity and success as a technical writer. Next week, we will discuss another of my favorite productivity tools – the Pomodoro technique. Subscribe to stay tuned!


Day-in-the-life of a Technical Writer

In January, we discussed how to get a job in technical writing: how to search for a job, craft your resume, write a cover letter, and build your portfolio. Graduates of professional technical communicator programs tend to have a sense of ambivalence about what to expect in their new careers. Several questions flood their minds. Is the work world really like the picture my lecturers have painted it out to be? What can I expect? What should I really be looking for? This article chronicles a day in my life as a technical communicator. I hope that sharing my experiences will help you better understand what to expect when you enter the real world.

Starting the day right

Preparation for my workday begins the night before. I follow the Getting Things Done (affiliate link) method by David Allen for planning out my week and workdays (detailed blog post here). By the end of my planning session, I know the meetings I have the next day, which deliverables are due (if any), and what documentation project I need to focus on that day. I juggle several projects, so it’s important to have a focus project for each day to reduce context-switching.

I then break down the focus project into tasks I need to get done that day. Some of these tasks include: meeting people to get information, drafting, editing, reviewing and publishing.

This night-before preparation helps me start my day right. My morning routine begins with a nice, relaxing cup of coffee, cereal with oats, nuts, and apples, getting ready for work, and a half-hour commute.

Deep Work

I am lucky to work at a company that understands that every individual has different work environment and timing preferences, and encourages us to figure out a schedule that works best for us. For me, I love getting my writing tasks done in the morning even before I reach the office. Most workdays, I go to my favorite cafe at Union Square, get myself a Chai Latte, and put in an hour of Deep Work (affiliate link) (detailed blog post here). In this hour, I work on tasks that require a fresh mind and focus: drafting a technical document or studying how a piece of technology works. I time myself in Pomodoros (detailed blog post here). Once I get at least 2 Pomodoros of the most important task of the day done, I walk to my office at around 11 AM.

View from my favorite writing place in NYC (Peet’s Coffee – Cap One at Union Square)

At the Office

The first thing I do when I arrive in the office is pour myself a large glass of water and sift through emails and Slack messages. I adjust my task list based on these emails and messages, if required.

I then do some “shallow work” for an hour at noon. Shallow work includes editing something I had written before, publishing material on GitHub, reviewing other people’s documents, and parsing GitHub issues.

At around 1 PM, I have lunch and check my emails and forums such as Reddit and Hackernews. All my meetings are usually post-lunch. This is the time to socialize, meet my colleagues, discuss work projects with them, get information, and so on. The 1 PM to 4 PM time slot is when my energy is the lowest in the day. So, I don’t do any writing tasks then. I leave work around 5 PM and head home for another Deep Work sprint.

Free Fridays

At Cockroach Labs, we have a thing called Free Fridays, which basically means you can do whatever you choose to do. You can continue working on your work projects, or put work is placed on the back burner and work on any personal projects, or just take the day off. I usually do my most difficult writing tasks at home on Fridays, and also get in an hour at the gym.

This is just a basic outline of my work day. Each technical writer may have a different experience. Following are some day-in-the-life blogs of other technical writers that I found interesting. I hope that sharing my routine and the routine of other technical writers gives you a clearer picture of what it is like to work in the industry:

Now that we have discussed what a technical writing job looks like on a daily basis, let’s move on to how to succeed at a technical writing job. In my opinion, the most important skill for a technical writer is figuring out the scope of work and planning it well. And that’s what we will discuss in detail in next Wednesday’s blog post. Subscribe to stay tuned!

Building your technical writing portfolio

A portfolio of relevant and professional technical writing samples can be the deal-sealer while applying for technical writing jobs. Check out the following posts from Tom Johnson’s for ideas to build your tech writing portfolio:

Bonus tip:

For every sample document you create, add a cover letter that describes what the document is about, who’s the audience for the document, which tools you used, and which of you skills does the document demonstrate.

If you have questions, suggestions, or blog post requests, drop me a line at

Subscribe to follow this blog via email

Writing a cover letter for a technical writing job

Note: Although this post is intended for technical writing students who are about to begin the job search process, but the techniques here might be useful for other students as well.

A cover letter is an essential component of your job application that helps you discuss why you should be considered for the position and demonstrates your communication skills.

The keys to a good letter are selectivity and results.

  • Select two or three points of greatest interest to the potential employer and develop them into paragraphs.
  • Emphasize results.

Elements of a cover letter:

  • Introductory paragraph:
    • Identify your source of information: State about how you heard about the position.
    • Identify the position you are interested in.
    • State that you wish to apply for the position.
    • Choose a few phrases that forecast the body of the letter so that the rest of the letter flows smoothly.
  • Education paragraph:
    • Focus on the courses, projects, and extra-curricular activities that are relevant to the job you are applying for.
    • Discuss the skills and knowledge gained from advanced coursework in your major field.
    • If you haven’t already specified your major and your college or university in the introductory paragraph, be sure to include that here.
  • Employment paragraph:
    • Like the education paragraph, the employment paragraph should begin with a topic sentence and develop into a single idea.
    • Choose only the relevant employment experience.
  • Concluding paragraph:
    • A reference to your resume
    • A polite but confident request for an interview
    • Your phone number and email address

Examples of good cover letters:

Update: As Larry Kunz (technical writer extraordinaire) advised in the comment below, the first sample is of the appropriate length, but the second one is longer than optimal.

Good resource:

If you have questions, suggestions, or blog post requests, drop me a line at

Subscribe to follow this blog via email

Crafting your technical writing resume

Note: Although this post is intended for technical writing students who are about to begin the job search process, but the techniques here might be useful for other students as well.

In this blog post, let’s discuss how to craft your technical writing resume.

The most important thing to remember is that your resume is NOT your autobiography. The recruiter does not need to know all that you have done or achieved in your life so far. They have a limited amount of time to go through hundreds of resumes. Your job is to make it easy for them to select your resume from the massive pile in front of them. Use your resume as a rhetorical tool to present concise, clear, to-the-point facts about why you are a good candidate for the position. Remember, it’s not about you, it’s about what the company’s looking for.

Know Thyself

Before you start writing your resume, take a pen and paper, and do a self-inventory:

  • What courses do you like?
  • What type of organization would you like to work for?
  • What are your geographical preferences?
  • What is your employment history?
  • What professional organizations/associations do you belong to?
  • What social/extracurricular organizations/activities do you associate with?
  • What are your accomplishments/honors/awards?
  • What software/hardware/technical skills do you have?
  • What are your strengths and weaknesses?

Know your audience

In the previous post, we discussed why it’s important to customize your job application materials for each job you apply for. I am aware of the fact that this is an inefficient method of job application. But I have a workaround: Create a base resume based on the self-inventory, and then tweak it for every job you apply for.

Build your base resume

In his textbook, “Technical Communication”, Mike Markel discusses the  essential components of a resume:

Identifying information

  • Full name
  • Address
  • Phone number
  • Email address
  • Link to LinkedIn profile



Include the following elements in the education section:

  • The degree
  • The institution
  • The location of the institution
  • The date of graduation
  • Information about other schools you attended
  • Your grade-point average
  • List of relevant courses

Employment history

Present at least basic information about every job you held:

  • Dates of employment
  • Organization’s name and location
  • Your position or title

Add carefully selected details of your job and experience. Provide at least a one-line description for each position. For particularly important or relevant jobs, present the following details:

  • Skills: What technical skills did you use on the job?
  • Equipment: What equipment did you operate or oversee?
  • Money: How much money were you responsible for?
  • Documents: What important documents did you write or assist in writing?
  • Personnel: How many people did you supervise or work with?
  • Clients: What kinds of, and how many, clients did you do business with in representing your organization?


  • Be specific when you write your experiences on a resume.
  • Whenever possible, emphasize results.
  • When you describe positions, functions, or responsibilities, use the active voice. The active voice highlights action.
  • Practice your bulleted lists.
  • Use the form .
  • If you have not held a professional position, list the jobs you have held, even if they are unrelated to your career plans. If the job title is self-explanatory, like waitperson or service-station attendant, don’t elaborate. If you can write that you contributed to your tuition or expenses, such as by earning 50 percent of your annual expenses through your job, include that.
  • If you have held a number of nonprofessional positions, group them together. Example: Other employment: Cashier (summer 2007), salesperson (part-time, 2008), clerk (summer 2009)

Interests and activities

Include information about your interests and activities:

  • Participation in community-service organizations
  • hobbies related to your career
  • Sports, especially those that might be socially useful in your professional career
  • University-sanctioned activities

Additional Information

You can also include:

  • Computer skills
  • Military experience
    • Dates
    • Locations
    • Positions
    • Ranks
    • Tasks
  • Language ability
  • Willingness to relocate

Customizing your base resume for every job application

Once you have your base resume, it’s easy to customize it for every job you apply for. For every job advertisement, identify the keywords in the advertisement. Understand the core requirements for the job. Then customize the following sections of your resume:


State only the goals or duties explicitly mentioned, or clearly implied, in the job advertisement.

For example, if your base resume’s objective is “To obtain a position as a software engineer”, then while applying for a Full-Stack Developer position at say, Google, reword your objective to “To obtain the position of a Full-Stack Developer at Google”. Just insert the position title and name of the company in your objective statement.

Focus on the reader’s needs, not on your goals.


The education section is the easiest part of the resume to adapt in applying for different positions.

Emphasize those aspects of your education that meet the requirements for the particular job.

Your base resume would probably list your courses in a random order. To customize your resume for a particular job, reorder the courses so that the most relevant courses are at the top of the list.


Your base resume would include details of all positions/projects you held in equal weightage. To customize your resume for a particular job, rearrange the experience section so that the most relevant projects/positions are highlighted, and others are mentioned briefly.

There you have it. Easy steps to customize your resume for every job you apply to. In the next post, we will discuss how to write a cover letter for each position. Stay tuned!

If you have questions, suggestions, or blog post requests, drop me a line at:

Subscribe to follow this blog via email