Why Buzzwords are Bogus, Keyword Searches are Lame, and Talk is Cheap When it Comes to Resumes, Interviews, and Negotiating Your Salary

Author: Quinn Heiner
Without seeing the subtitle to this article, you might try to decipher what “Synergizing the Strategic Alignment of our Initiatives“ really means, only to find that in reality, it means almost nothing.  It’s just a bunch of buzzwords thrown together.  The old adage that words mean something is only sometimes true.  When it comes to buzzwords, they usually have a very vague, shallow definition that doesn’t actually solve problems.
We’ve heard all the talking points and buzzwords in interviews and seen all the keywords we’re looking for in a resume.  But too often we become disappointed when someone looks great on paper and talks a good talk in an interview, only to see them give a mediocre job performance at best when push comes to shove.  In this article, we will discuss what companies really want to see on a tech resume, how to really vet a candidate in both technical/non-technical interview situations, and some practical advice on salary negotiation from both the employee/employer perspective.  Although this article is written with software engineers in mind, many of the topics discussed can apply to other disciplines alike.
The Resume
The purpose of a resume is to list relevant accomplishments that you feel make you a good fit for a company.  It’s also used to land you an interview.  Some general tips:

    • avoid listing unnecessary or irrelevant details
    • keep your resume concise (1-2 pages max)
  • make sure your resume is readable and formatted well (assume it will be screened by software, or if you’re lucky, quickly scanned by someone who won’t be reading every word)

Concerning the actual content of your resume, it’s extremely important to remember one simple fact: actions speak louder than words.  This is especially true for software engineers, where practical experience almost always trumps other credentials, such as education.  Most applicants will already have some form of a college degree and will claim to be proficient with a particular programming language or framework.  So by knowing this upfront, what exactly will separate you from the other candidates?  The answer is specific accomplishments that are rich with action words, not merely buzzwords to satisfy a keyword search.  The following comparison chart below can help drive home this point:

Good Better Best
Significant experience in C# C# development on a large-scale web application for various Department of Defense agencies Senior architect on a $1.2 million dollar, 2-year, enterprise-level C# web application for the Department of Defense. Actively managed 10 developers and regularly coordinated with stakeholders, including extensive end-user trainings and demos. Completed project on time and under-budget.
Senior-level experience in Angular 3 years of front-end development on a C# web application using Angular Active participant in various Angular forums, including several presentations at user conferences and weekly blog posts on a developer blog with over 5,000 weekly views. Received guru badge status on Stack Overflow by answering over 100 Angular-related questions.
Microsoft certified Currently MCSD Certified (Microsoft Certified Solution Developer) Successful completion of the MCSD (Microsoft Certified Solution Developer) Certification, including over 200 hours of studying outside of work for 3 separate exams covering all aspects of the Microsoft .NET framework.

In terms of a general structure for tech resumes, it’s often best to have four distinct sections that offer both a high-level and low-level insight into your accomplishments:

    1. a brief summary of qualifications (no more than a few sentences) that describes your expertise at a high level (i.e. the elevator pitch)
    1. a short list of technical skillsets
    1. professional experience (this is the only place where you will list out extensive details as suggested in the table above)
  1. education and training (including applicable certifications, honors and awards)

In general, having a resume that clearly and concisely communicates exactly why you are a good fit for the job can not only help you land an interview, but will also help to create a better first impression going into the interview.
The Interview
Unfortunately, the people performing an interview sometimes like to make the interview all about them by asking tough questions to make them feel smart.  Or worse, they’ll stick to vague, irrelevant “fluff” questions that don’t really establish whether you’re the right fit for the job (questions such as “what’s your greatest weakness?”, “if you could be any animal, what would it be?”).
The real purpose of an interview is to have a two-way conversation to establish whether you’re right for the company, and whether the company is right for you.  It usually boils down to three questions:

    1. Do you deliver good results?
    1. Do you deliver on time?
  1. Are you easy to get along with?  In other words, are you a team player that will fit in with the company and its culture?

In interviews for a technical position such as a software engineer, you are not only trying to establish whether the candidate has good soft skills, but also whether they meet a certain level of technical skills.  Below are some examples of both types of questions to get a productive dialogue going.
For soft skills:

Good Better Best
What is the time-scope-quality triangle? Why is the time-scope-quality triangle so important in software development? What are some strategies or tactics you’ve employed to keep the time-scope-quality triangle balanced?
What qualities make a great leader? What kind of leadership roles have you taken on in your career? As a senior developer, you’ll likely be helping out some of the juniors on occasion. How do you best deal with other developers that are constantly asking for your help?
How do you resolve conflict? What kinds of conflicts or battles occur during development on a project that you’ve observed, and how do you best deal with them? You and another developer heavily disagree on how to best implement a solution for a given architecture problem. How would you resolve such an implementation battle?
What kinds of technology changes have you seen in the industry in the past few years? How do you adapt to changing technologies? You’ve been assigned to a project using a technology that you’re unfamiliar with. How do you best adapt?
What does the term “rough consensus and working code” mean to you? What are some industry best practices you’ve grown to appreciate in your career as a software developer? How do you best balance principle vs. practice when it comes to writing code?
What is Agile development? How do you think software requirements are best established? So many customers only want to evaluate things in a production-like environment. How can we help to ensure early feedback in a more agile way?
What are your greatest strengths and weaknesses? If I were to call your supervisor from your last job, what would he say about you? What’s your claim to fame from each of your previous jobs?
Why do you want to work for us? What makes you more qualified than the other candidates? How do you think you can transcend your current role?

For technical skills:

Good Better Best
On a scale of 1-10, how would you rate your SQL skills? Our customer needs to set up a very simple order tracking system. Draw for me a basic ER diagram for the backend database that could be used. Here’s an ER diagram of a basic product sales database. Write me a SQL query that shows me the best-selling product by month.
What does SOLID stand for? How have you incorporated SOLID principles in your code? I need to calculate the area of various shapes. Write me some pseudo code of how to best implement calculating each shape’s area, adhering to SOLID principles as much as possible.
What’s the difference between a for loop, a foreach loop, a while loop, and a do-while loop? Write for me a for loop that prints out only odd numbers. Here’s an example of a for loop that is producing incorrect results. Can you identify the bug and fix it?
What technologies are you currently using in your application stack? What would be the ideal technology stack for your application? For each of the technologies in your application stack, describe for me the strengths and weaknesses of each.
What is an abstraction? What is the difference between an abstract base class and an interface? When would you use an abstract base class vs. an interface?
What is dependency injection? Why is dependency injection important? How have you been using dependency injection in your current project, and how has this benefitted you?
What is an N-tier application? Why is important for an application to have many layers? Describe for me the overall architecture of your current application, including what each of the levels are for.
What are design patterns in software? Why are design patterns in software important? Describe for me a few of the software design patterns you use on a day-to-day basis and how this has made your application better.
What is TDD? Why is TDD important? I have a set of requirements here for a screen on adding a new employee to an HR employee management application. Using TDD, walk me through how you would architect some unit tests for this.
What is inheritance? What is prototypal inheritance in Javascript, and how does this differ from classical inheritance in C#? Here are some examples of inheritance in both Javascript and C#. What values will be printed to the screen on line ___ of the code?
What is encapsulation? How is encapsulation implemented in C#? Here is a code example of some classes with poor encapsulation. How would you fix this?

The takeaway from all of this is that rather than merely quizzing an interviewee on concepts or questions that will invoke a very generalized response, it’s best to ask more specific, thought provoking questions that will force candidates to give specific, real-life examples, or (in the case of technical questions), actually demonstrate they understand the concepts in practice.
The Salary
So you want a raise?  Who doesn’t?  How much money a person makes is certainly a sensitive topic, and one that most people would be uncomfortable discussing openly.  However, when it comes to salary negotiation, you must be willing to not only be specific, but also feel justified in your request.
First, it’s important to understand salary from the employer perspective.  Employers have fixed costs well beyond just the salary figure you see on your paycheck, including (but certainly not limited to): benefits, unemployment insurance, taxes, administrative costs, building utilities and maintenance, training resources, reinvestment expenses, etc. It would be a shock to most workers if they were privy to the full sticker price of their employment in an organization.  In addition, companies must remain financially solvent (and, depending on the industry, profitable), in order to stay in business.  These factors certainly place limits on how much a company can actually afford to pay you.
Second, it’s important to understand the true market value for a particular job.  Market value is simply defined as the “going rate” at which most employers in your area are paying their workers given a level of expertise.  Since the tech industry is very much a talent-based industry, software engineers with a high level of expertise (and skillsets that are in high demand) can expect their market value to be significantly higher than an entry-level engineer fresh out of college with limited experience.  The truth of the matter is that offers are all over the map.  It’s hard to pin-point a specific dollar amount for an engineer with x years of experience, because offers vary widely depending on the job location, type of business, needs of the business, and background of the engineer.  In addition, since software engineers are in high demand, job hopping in order to increase salary is a common behavior, with each employee often offering to match or beat what they’re current at salary-wise.  It is for these reasons that market value is always changing, and that only through careful research and knowing where you fit into the overall market scheme can you at least get an idea of what is considered fair compensation.
Third, and probably most important, is the need to understand that a salary is always (or should always, at least) be merit-based.  In other words, what have you accomplished in particular that warrants a salary increase?  How have you added value to the company?  The more valuable the company perceives you, the more they are willing to pay you to keep you around.  Check your ego at the door on this by trying to look at salary from an objective point of view when it comes to what is merited.
Unfortunately, many workers think that circumstance alone justifies a salary increase.  For example, your medical expenses doubled last year.  You just moved into a new house and your mortgage payment is higher.  You just had a new kid, so your cost of living has increased in order to provide for your family.  These are all valid circumstances that one can certainly sympathize with, and for which a raise would definitely help.  Often times there are even more unique circumstances beyond one’s control that can certainly put a financial strain on any family.  Certainly, there are companies out there who are willing to work with their employees to make sure their basic needs are met, and, at times, can increase salary according to those needs.  Often times, however, one must first merit a raise by adding value to the company in a measurable way.
When it comes to software engineering, what kinds of things can you do to merit a raise?  The best place to start is to have an open dialogue with your manager about specific performance expectations or actions that one can do to merit such an increase.  Sometimes that means getting certified in a particular technology. Other times that can mean taking on extra projects that will save the company money or increase revenue.  The specifics vary widely depending on the needs of the employer.  Having an agreement in place with objective, measurable benchmarks can help to ensure that both the employer and employee’s expectations are being met.  The bottom line is to practice clear, concise, and constant communication with your employer about where you feel you’re at and where you’d like to be.  Before you try and job hop to gain a few bucks, talk about it with your employer first.  You may be surprised at how much they are willing to work with you, especially as you become a strong asset for the organization.
In conclusion, resumes, interviews, and salary negotiation can be tough nuts to crack, but one theme certainly prevails among all three, and that is that actions speak louder than words.  So drop the buzzwords and start listing real accomplishments on your resume.  Anticipate more thought-provoking questions in interviews that will demonstrate a practical understanding of a concept or principle, rather than just sticking to talking points that sound rehearsed and overly general.  And when it comes to salary negotiation, understand the employer’s perspective, your market value, and what merits you personally bring to the table in order to start a successful dialogue.
Author: Quinn Heiner