Play the game

___

INTRODUCTION

As part of this and some upcoming blogs, I intend to help the fresh college grads or new joiners from any industry, gain some perspective of how the real world works.

This is part 3 of resume building ( how to write ). Having gathered content for our resume, we will edit it for brevity and punch. Let’s edit …

Disclaimer

Neither do I claim to be an expert in the field of resume building ( if there is indeed such a field ), nor have I consulted many HRs or recruiters.

I have appeared in and have conducted multiple interviews. The following information is based on my own experiences, knowledge gained from the experiences of my juniors, peers and mentors, and some brainstorming sessions with friends.

Mindset

Now that we have all the data … we have to structure it, polish it in a logical, easy to understand, and eye-catching manner.

This requires taking a different mindset … think of the difference between keeping bricks and designing a building. We need to take a step back from the core details and see how all the pieces fit in together.

This is also the reason I recommend NOT mixing this process with the first process of just gathering details.

–The first step would just require a word vomit ( without being gross ) any and everything that comes to one’s mind … and

–The second step would be creating content out of the raw information.

With this mindset, we will focus on a few things:

–Brevity – meaning we want to keep our statements short.

–Quantification – assigning a number to most details.

–Vocabulary – using technology/ industry-specific terms.

Brevity

Please understand that a resume is a short space that needs a lot of information to be filled in. Unless we are careful our sentences can be framed in unwantedly long ways.

Let’s take some examples:

Long : In the process of testing the code, we ran into issues.

Short : While testing we ran into issues.

Long : I am a Software engineer and I have 5 years of work experience.

Short : Software engineer with 5 years of work ex..

Long : 73% from St. Marks Senior Secondary School, Jhansi.

Short : 73%.

Keep it short dear

Notice the highlighted words.

–How does ‘the code’ add value ? These usual fillers do NOT add to the quality of content and are usually either a bad-habit OR leftovers from the literal conversions, from our native languages to English.

–‘I am a’ and ‘I have’ in two subsequent sentences does not add value. The recruiter knows that he has YOUR resume and therefore YOUR experience is what is mentioned. Repetition does not add value.

–How is the recruiter enlightened by the fact that St. Marks is a ‘Senior Secondary’ institution?

Unless the college is IIT, IIM, Harward, Stanford, or in the league … I would personally not care !

Please treat resume real estate of high value. A high-value real estate ought to be used with value !

Also, if you aren’t too good with the English language, please o’, please … do NOT do this by yourself. Please take help from someone who has a good handle of the language. Ask a friend for help.

Quantification

This was a big big one for me. Thanks to the book ‘The Google Resume’, I was able to understand this mistake and correct it, much to my benefit.

Before we even begin, how do these sound for an MBA?

–Invested 2.5 million $, to a ROI of 750% in 1 year.

–With 90% improved efficiency, procured a 1 million $ worth project for the client.

I hope you said Good ! because these have been paraphrased from the LinkedIn profile of someone doing very well in his field.

Even if you are not from his field, do not understand his work … do these statements help show that he is competent ? To me they do !

But the real question is WHY ?

In my understanding, quantification helps give perspective to the receiver of the information.

–A Return Of Investment of 750% easily and clearly demonstrates the results and thus, clearly establishes the person’s abilities.

–90% improved efficiency again easily and clearly establishes the changes done.

Same thing in our case – Quantification makes our work, and accomplishments easy to understand, and put into perspective.

Let’s again take some examples:

Unquantified : Several years of experience in multiple domains

Quantified : 7 years of experience.

Unquantified : Worked to improve the application.

Quantified : Improved the application performance by 5000%, with just 100 hours of effort.

Unquantified : Handled many big projects

Quantified : Worked on a dozen projects with an average budget of 1 million $.

You see the quantification helps show the width, depth, and experience levels quite clearly. This clarity as we already know helps recruiters and therefore increases our chances to get an interview call.

If you are a software engineer, you have an added advantage. You already get to see the results in numbers … 30% performance improvement, 50% build time reduction, 20 hours of effort etc. We just have to use the same terminology in our resume.

In case some of you feel puzzled by these numbers, please know that you have company … I had a hard time understanding how to derive numbers from a project. These questions might help you …

1.What is the cost of your project ?

2.What is the profit ( or expected profit ) to your company, from the work you do ?

3.What is the size of the data you handle ? millions or billions or records, Gigabytes or Tera bytes of data ?

4.What is the full user base size ?

5.How many concurrent users can access your system at the same time.

6.How long would someone have taken to do a work in your place ( to show that you did the work 50% faster )

7.How long does the system take to complete its work? How much was the improvement ?

8.Cost of a server, number of servers, the scale of deployment etc ( how much does the server environment cost to the company? )

9.Degree of automation ? ( number of hours saved to the company )

10.The number of UAT bugs caught, Critical issues avoided. The same numbers presented as a % might give a better perspective etc.

And just in case you haven’t been paying attention, let’s start doing that now by asking your manager on the size of a project, the $$ value, work hour size, complexity numbers etc.

My friends – doing the work is one thing; presenting it is completely another. This is Very Important. Please help the recruiter understand your skills clearly and easily !

Vocabulary

I’d like to clarify something !

In the previous blogs, I have indeed recommended using simple language to explain your work experience and projects. So how does one simplify a ‘thread race condition’ ? or ‘thread deadlock’ ?

If I were to try and simplify these problems, I would fill paragraphs after paragraphs of my valuable resume space before anyone at all understands what I did. So, we need to understand when to simplify and when to use the technology vocab !

Be judicious, but between ‘cost of being complex’ and ‘using industry vocabulary’ … my recommendation would be to choose the latter.

These would be terms like :

●Race conditions

●Deadlocking

●Performance

●Network payload

●Throughput

●Latency

●Terabytes/ petabytes

●Server cores

●Thread starvation

●Lazy loading

●Distributed locking

Simplification should NOT be done at the cost of diluting the technical details.

( Diverting from the current topic, here is an example of how we make mistakes: During the first draft, I wrote the above sentence as :

The desire to simplify a resume should NOT be ….

the highlighted part was unnecessary text and was replaced with Simplification, during editing, for reasons of ‘Brevity’. I hope this helps you see how easily mistakes are made )

Back to vocabulary now, what does the above mean:

–‘Resolving race conditions’ should NOT be replaced with ‘made application better’.

–The phrase ‘Data movement’ CANNOT describe a ‘Terabyte data migration’

–‘Made application better’ CANNOT describe ‘reducing network payload’ or ‘using threading’

Truth be told, two things can happen:

1.A non-technical person will read the resume and NOT understand the details. or

In my opinion, the person NOT understanding the details will be impressed with your vocabulary, and work.

2.A technical person will read the resume and WILL understand the details.

This is of-course good for you !

Moving on …

We have looked at the three mindsets of editing a resume. Having understood some key points of how to put the details together, we will now go over editing all the data we collected in our previous blog.

We will cut short the long sentences, we will add numbers and value to most, if not all details and finally, we will add more technical vocabulary.

Till then .. c ya !

Write back, in case you have an opinion. Like what you read – do like, comment and share.