Resume Critique #1 (Subject: HJS)

In my previous article, Your Resume, It’s the little things that hurt, I extended an offer to provide feedback on programmer resumes for anyone brave enough to take some criticism in a public forum as a pedagogical tool.  The first victim will be known as HJS for the purpose of this analysis in an admittedly feeble attempt to provide him with a shred of anonymity despite his insistence that it was not necessary.

Disclaimer: My critique will consist of my raw, uncensored opinion and thought process as I read through the resume from the perspective of a technical hiring manager looking for a programmer. In some cases, I may make comments that indicate bias or other things that it is illegal to consider when screening candidates, at least in the US.  I want to clarify that in the execution of my duties as a manager, I make every effort to make hiring decisions based on objective facts, endeavor to treat all candidates equally, and follow affirmative action principles as part of our recruiting methodology. 

As I discussed recently in “Age Discrimination and Programming Jobs,” it is my strong belief, however that acknowledgement of our bias and that of others is critical to combat unfair recruiting practices.  As such, I am going to call out things in my analysis that the candidate could proactively do to minimize the potential for discriminatory practices by unscrupulous managers. None of the material in this article represents the policies or practices of my current or previous employers.


Candidate “HJS”



Phone: <Censored>

email: <Censored>

The multi-line address at the top of the resume in a giant font is taking up hugely valuable real estate. Put it in a single line on the footer to reduce the vertical real-estate.
Re-purpose the top of this resume to succinctly create a branding statement that shows my job is the one he is looking for “Experienced Web Developer” or something like that.

Summary of Qualifications

  • § Experienced Software Team Leader. How experienced? Quantify it with a number of years and maybe a title 
  • § Fourteen years of software engineering experience. Good start. Experience is a key differentiator, I like how you get to this quickly. 
  • § Master of Science in Information Systems. Normally I wouldn’t feature a degree so prominently, but in this case it is a powerful selling point, because it is an advanced degree and relevant to the job.
  • § Languages: C, C++, Java, Python, Javascript, Erlang, HTML, XML, SQL, Unix shell, Perl.
  • § Web applications, Communication Protocols, Linux, Client/Server, Distributed Systems, Parallelism and Concurrency, J2EE, EJB, TCP/IP, RPC, SNMP, Network Management, Element Management, Multi-threaded. Too specific, doubly so for summary section.
  • § Development Tools: Eclipse, make, ant, Apache, Subversion, XML-RPC, RPM, Installshield. These are not enough of a selling point to feature them in this section. Move to separate “Skills” section.
  • § Experience in an organization certified at SEI level 5 and ISO 9001. “Experience in an organization”… emphasises your employer, not you. re-word “organization” out of it.
  • § Software engineering techniques: Requirements, design, OOD, OOP, UML, project planning, Fagan inspections, configuration management, change control.
  • § Native English, good spoken and written Hebrew. If you are applying for a job in the US, they are going to assume English, mentioning makes me want to doubt you speak it well. Unless the job desires/requires Hebrew, dump this fact.
  • § Enthusiastic, innovative, organized, motivated, adaptable and a quick learner equipped with broad technical knowledge and excellent people skills. I skim past statements like this that are subjective and on every single resume.  This just wastes space.


Giant Steps NETWORKS                                                                                     2003-Present

Software Team Leader, NMS Division

  • § Currently leading a team of 2 engineers working on Apache module in C++. Don’t be specific about the number of engineers if it isn’t impressive.
  • § Currently developing J2EE distributed application deployed in Amazon Elastic Cloud. Sneak in some keywords/acronyms here to enhance search-ability (EC2, AWS, Cloud computing)
  • § Multiplatform NMS (embedded Linux, Windows 2003 Server). Web-based using C, C++, Python, Openlaszlo (Flash), Java, SQL. Using SNAP protocol over RS232/RS485, HTTP, PPP, Modem control. Move these to skills section and reference them more generally here.
  • § Managed and developed a 3 person project to develop a three-tier management system for Fiber-Channel SCSI switches. Technologies: Java, C, ant, XML-PRC, RPC, rpcgen, make.  Move to skills section, too detailed for this section.
  • § Developed a document processing engine in C# and Managed C++.NET (Microsoft .NET). Analyzed, designed and implemented the software. Planned and managed the project teamincluding activities of other team member.
  • § Developed and deployed a Client-Server Element Management System in Java(J2SE, Swing), XML-RPC and SNMP.
  • § Designed and Implemented CSP-SMS protocol layer, SMS application layer for a Java(J2ME, MIDP) Instant Messaging application. Reduced code size by 25% while improving performance by refactoring the design. Was your original design that bloated and slow? Might not want to claim you invented it and then stress how much room you had for improvement.
  • § Deployed (and continuing to administer) company wiki (Moinmoin). I wasn’t familiar with this Wiki software, you might want to be more specific what Moinmoin is. Also, emphasize your role in implementing a wiki. The wording makes it sound like it was someone else’s idea that you just implemented.


Motorola                                                                                                                     2000-2003

Test Lead, Vancouver PCS System Test Team (2002 – 2003)

  • § Molded the Vancouver PCS System Test team by creating test plans, mentoring and training junior team members and resolving technical and project management issues. Molded?
  • § Increased customer satisfaction by completing test cycles 20% ahead of schedule by estimating work packages, re-planning activities and optimizing test procedures.  I don’t get the connection to customer satisfaction, it stands fine without that prefix.
  • § Reduced escaped defects while reducing cycle time by 50% by establishing and then optimizing an Integration Test Plan. What is an escaped defect? Also, once again you created something (the plan) then had to go back and optimize it. You are creating subtext that you don’t get things right the first time through.
  • § Created a System Test team in Turin, Italy by identifying and training a team lead, developing initial test plans and training team members. Created is probably the wrong word unless you gave birth to them.

Software Engineer, GPRS SGSN (2.5G) Core Platform and Availability Team (2000 – 2002)

  • § Reduced software defects by representing the Platform team on Change Control Board for problem reports and design changes. Analyzed, assigned and tracked problem reports.
  • § Resolved system stability and availability problems with high customer impact. Traveled to Europe on two different occasions to successfully resolve major availability problems.
  • § Supervised and mentored co-op students. Assigned tasks, monitored progress, evaluated performance.
  • § Received three “Bravo” awards for exceptional performance. Tell me more about the circumstances of the award.

Forward Software                                                                                                  1996-2000

Contract Programmer/Analyst                                                                                                        

  • § Developed ERP software using Progress 4GL and RDBMS. May be true, but it feels like an exaggeration. You did this single handedly?
  • § Worked on payroll, accounting, manufacturing and “data mining” software packages. Turn this into an accomplishment. I don’t want people that “work on” stuff, I want people that get stuff done!

Placer Dome                                                                                                               1993-1996

Systems Administrator, Campbell Mine (1995 – 1996)

  • § Administered a mixed UNIX and Novell PC network. Any accomplishments to note other than filling a chair?

Programmer, Vancouver (1993 – 1995)

  • § Implemented database (what platform?) inventory system from design documents. Too specific, remember that the little things hurt when you call too much attention to the obvious.
  • § Tested third-party software. Say what? This seems vague and doesn’t indicate an accomplishment. Anyone can do, you need to show excellence.


2008            M.Sc in Information Systems at Athabasca University. Essay Project titled “Concurrent Programming – A Case Study on Dual Core Computers.”. Completed courses include Distributed Systems, Project Management, Human Computer Interaction, Enterprise-wide Network Architecture, Data Structures, Systems Analysis and Design. (Separate degree onto separate line from details to highlight it)

1991            B.Math in Pure Mathematics from University of Waterloo, after 2 years study in Electrical Engineering.  Graduated on Dean’s Honours List.  Received Engineering Entrance Scholarship, Descartes Fellowship. (Separate degree onto separate line from details to highlight it)


5NINES training – Sounds promising, give more detail!

PowerPC programming – Is this programming on a particular type of computer? Is this relevant to the job you want?

LynxOS device drivers – What about them?

Inspections training Fluff – This is meaningless outside your current firm.

Inspection Moderator training  Fluff – This training helps someone at another company, how?


Disposition: Promote candidate to phone interview stage.
Initial Impression of Candidate: B+

Age Discrimination and Programming Jobs

As my personal odometer clicks over to 38 today, I’m thinking about the very real concern of age discrimination in the technology field where many would consider a person wizened at 40. The legal and political considerations associated with this issue make it a very touchy subject that encourages many to tread lightly or avoid discussing it entirely. This is unfortunate, because for both the job-seeker and hiring manager, passive acknowledgement that age-bias is a factor does little to remedy the situation. This Tauran is going to stampede through that china shop and confront the issue head on with in a frank discussion about older programmers and the recruiting process. Along the way I’ll provide advice to both managers and job hunters for overcoming bias that can result in unfair and illegal discrimination.

Let’s start with what I admit is an unabashedly controversial opinion. It is my belief that, for programmers, age discrimination is more pervasive than either racial or gender discrimination during the hiring process. The basis of this sentiment is rooted in the demographics of the software development community which is predominantly comprised of male employees that are on average younger than the labor force in general (McConnell).

I suspect that hiring decisions made and influenced by younger managers who were raised during a period of increased emphasis on achieving racial equality in the wake of the civil rights movement are less likely to reflect race based bias than those of their elders. Further, it is likely not uncommon for the typical young, socially awkward, male software engineer to sometimes give an edge to qualified female candidates if only for some respite from the homogeny of his peers. That said, I also think that older female candidates are victims of more discrimination than older male candidates.

Do you feel me on this? If so, we are both guilty of exposing a personal bias that younger workers are less likely to discriminate in their hiring practices and men as a group are generally prone to using their status as a hiring manager as a personal dating service. While it is certain that both of these preconceptions must be true for some element of the workforce, it is equally true that they are not universal, and it is ambiguous about whether these characterizations are even widespread. The important consideration here is that each of us harbors at least a few innate personal prejudices, and there is a good chance that some of them are going to be inaccurate.

The Two Question Technology Bias Test

Even if you didn’t take the bait on that first point, consider the assumptions at play in the following two question quiz.

(1) What Operating system does the man in this photo prefer?
Guess my favorite OS!

(2) What makes the following image humorous?
Unix Girls on the Beach

Despite what the guilt mongers would have you believe, prejudice, discrimination, and bias are not fundamental human failings that are uniquely modern and need to be worked out of the system. Instead, instead they are shortcuts wired into our primitive brains that allow us to apply a probabilistic model based on our own experience.

In a survival sense, it provided competitive advantage for our ancestors to assume that a particular lion is prone to violence based on their experience with a completely different lion eating a cousin’s face. The types who argued that maybe this new lion seems nice and deserves a fair shake probably didn’t fare as well as the lion-ist jerk who didn’t trust anything with six inch incisors. Given the eons it took to condition this into us, I don’t think it is feasible to eliminate it from our nature.

Although you can argue that the lion-prejudice pattern is outdated and no longer applicable. Consider the more modern practical applications of bias for programmers in the refactoring movement. Code Smells are little more than prescribed bias against certain coding elements that may or may not indicate real problems. I am not going to go all Gordon Gekko on you and declare that “Bias is Good.” I am just trying to say that in the appropriate context bias can be beneficial.

Conscious acknowledgement of preconceived notions and being vigilantly objective despite experience is critical, however, for managers making recruiting decisions. For the candidate, who is unlikely to suspend the well-shorn biases of society for the duration of an interview, mitigation strategies are in order.

Continue reading

Your resume. It’s the little things that hurt. (The Programmer’s Guide to Getting Hired)

A skill that emerges naturally for managers after conducting a relatively small number of recruiting efforts is the ability to recognize common anti-patterns in resumes that are contra-indicators of good developers. I’m not talking about the major faux pas that have been repeatedly covered in generic articles about job hunting, but rather the nuanced messages that are communicated to a technical hiring manager who has learned to  read between the lines. This article is intended as cautionary advice to help prospective developers avoid the most common and damaging mistakes beyond simple typos and grammar considerations.

Risk Level: For senior candidates, most of the mistakes described below are fatal to your candidacy. For more entry level technical positions I am more likely to let these types of issues slide, but do use them to differentiate candidates that are otherwise equally qualified, so it still makes sense to be mindful of them.


Tip #1: Don’t be hyper-specific

One of the most effective ways to portray yourself as a novice or one-trick-pony is to pile on the trivial details when describing past jobs or projects. I understand that you are proud of your accomplishments, and know how easy it is to get wordy when drafting the Book of Moi, but remember that a resume is a brochure, not a biography. The prime objective of a resume is to get you booked for an interview, not to close the sale. The interview is a much better forum to brag about the implementation specifics of the “Monolith 3.0 Infrastructure Upgrade Project” because it allows you to adjust the message as you deliver it to hone in on whatever aspects resonate with the interviewer.

The key problem with being too specific arises from the undesirable subtext it creates. I think this is demonstrated well in the following excerpt from a real resume submitted for a Web developer job that I was trying to fill.

“Created stored procedures to fetch query results from the database for higher performance. Involved in writing complex SQL queries that required data from multiple tables using inner and outer joins.”

Gems of this type are hardly rare. I see variants of this exact statement so often in developer resumes that I can now spot them as quickly as if they were marked with a yellow highlighter pen. My mind automatically drifts to the same questions every time I see something like this…

Question 1:  Why is this person making such a big deal about menial tasks like writing a stored procedure and using specific join types?
Option A: They find writing SQL/Stored Procs very difficult and consider it a major accomplishment to have done so.
Option B: They didn’t have much to talk about in the resume and are padding it with trivialities to seem more qualified.
Option C: They just learned about joins and are proud of that accomplishment.

Question 2:  Why call out that they wrote the procedure specifically to query data?
Option A: Maybe they have never written a query that modifies data, are they that inexperienced?
Option B: Are they trying to educate me about what a stored procedure is? Do they think this isn’t common knowledge? Perhaps it isn’t to them.

Another example from the same resume:

“Designed online store by using ASP.Net. This system allowed user to order the products from the store and user can accept the order or cancel the order. “

Question 3: Did this person do substantial work on the project or just write the code for the “Accept” and “Cancel” buttons?

My advice to the author of this resume would be to take Vince Lombardi’s advice and “Act like you’ve been there before.” By assuming the details, it conveys a tone that the candidate considers the specifics of optimizing queries as routine and not worth bragging about. The discussion about the specifics of the clever optimization technique are best saved for the interview. Here is a reworked version that generalizes the same sentiment without dwelling on the trivia.

“Substantially improved performance of company’s core accounting package by profiling and optimizing database access code.”

Another major problem with getting too far into the weeds on a resume is that it implies that the resume is a comprehensive. By being asymmetrically specific about experience with various technologies, it has the effect of implying that the applicant is less competent in skills that are described more generally and not skilled in those that are not explicitly mentioned. In the above example, by specifically calling out experience with SELECT queries, it leads the reader to the conclude that the candidate might not be able to form other types of queries.Be mindful that what you do say often speaks volumes about what you don’t.

Tip #2: Don’t egregiously add keywords in the narrative sections

It could be argued that being specific in a resume gives you an opportunity to get all the buzzwords in, and this is true. The gatekeepers to most jobs are recruiters and HR people who use keywords from the job requisition to locate candiates on sites like and internal recruiting databases often without understanding their meaning. For this reason, I like the idea of separating out the keywords in to a separate “skills” section on the resume. This makes it easy for recruiters to scan your list of competencies by grouping them together, and makes the narrative parts easier to read for the hiring manager who doesn’t need to be prejudiced by that level of detail.

Here are a couple of examples from resumes that work a little too hard to jam keywords into the job history.

“Debugged and fixed the bugs which reported in TestTrack Pro by Seapine Software, Inc. according to SDLC.”

“Designed the database in SQL Server using database normal forms to prevent data redundancy and ER (Entity Relationship) diagrams.”

Although it is amusing, I’ll forgo a discussion on whether using normal forms actually “prevent ER diagrams.” If only…