Category: Resume tips
Why Your Résumé is 10 Pages
Even though there are hundreds of articles professing the beauty and efficiency of the one page résumé, not a day passes where I don’t see a five pager. The issue of length has even surfaced amongst college undergrads applying for internships, who seem to have increasing difficulty trimming their list of accomplishments and experiences into a single page (really). This is a troubling sign for future HR and recruiting professionals tasked with selecting applicants, as job seekers who are unable to shorten their credentials will continue to have difficulty in their search.
The amount of time a recruiter or hiring manager spends reviewing any single résumé varies by the individual. When offered a single page résumé, the reader is much more inclined to give that page a proper scan to make a fair assessment. A two page offering should get a proper review as well.
Continue reading
Enterprisey Developers, Acronyms, and Discrimination
Over the past few years my clientele shifted from a mix of mostly mid-market companies and a few startups to almost entirely startups, and that shift has resulted in a wider palette of languages requested by clients. Where my business was about 95% Java for the first 10+ years of my career, today it is closer to 25%. As I’ve written before, my business veered naturally from a pure Java focus when a considerable amount of the Java talent I have represented in years past started to migrate and show interest in diverse languages and ecosystems.
Unlike the boom periods for startups in the past, it appears that today’s startup is much less likely to choose Java as the primary development platform. Many developers who did Java work for startups in the mid 2000’s sought higher ground in the late part of the decade when small shops took a hit, and found themselves working for large companies and more corporate environments.
Flash forward to the past few years and the resurgence of startups. Many of those engineers who took shelter in the larger firms are now interested in establishing themselves once again as a major contributor on a small team in a startup, and when I have represented some of these highly qualified developers to startups now, I’ve been met with the feedback ‘The candidate’s résumé appears too enterprisey‘. As an aside, I don’t get that response nearly as often for Java engineers that stayed with small companies.
The enterprisey label, in my experience, seems to be used in two situations that can often (but not always) go hand-in-hand. First, enterprisey is often used to describe candidates that come from large development shops regardless of the languages used (although Java and .Net platforms are the norm), where the bias is that the development culture and the broader company culture make that candidate less likely to succeed in the startup. This is the result of preconceptions surrounding development methodology, possible unnecessary complexity in applications, a slower release schedule, or the impression that developers in these larger environments are sheltered from tasks related to data, devops, sysadmin, and QA that are frequently handled by developers at startups. The label may be applied liberally to virtually any candidate coming from a company larger than the hiring firm.
The second common enterprisey tag is used on any developer using Java or .Net regardless of the employer size, due to the predominant viewpoint that other language communities have developed regarding Java/.Net being wrought with and plagued by dozens of frameworks and bloated stacks. As someone who sees thousands of résumés a year, it is clear that résumés of Java and .Net developers are often significantly longer than those of developers in other languages, but there could be several factors at play there beyond just the number of potential bloat items (insert Java = verbose joke here). At a distance, the résumés of Java developers can resemble an eye chart, with acronyms outnumbering actual words. One hiring manager of a Scala shop provided this gem:
“The laundry list of legacy enterprise technologies (JMS, JMX, etc.) doesn’t do anything for me.”
The word ‘legacy’ seems particularly cruel there.
Sadly, many of those making hiring decisions in these startups are quick to dismiss a highly-skilled talent simply because of their experience working for a larger company or their primary language being in the Java or .Net worlds. Whereas an interest in, say, functional languages is now often used by startups as an indicator of ability, the prolonged use of Java or .Net at a large firm can be a detriment when applying for work in any other language or polyglot environments.
So how can engineers labeled ‘enterprisey’ escape that bias and be accepted by smaller shops with different languages?
Résumé and bio de-enterprisification – That’s not a word (yet), but the concept would be to go back and make sure your résumé/bio/LinkedIn profile/etc. doesn’t read like a corporate Buzzword Bingo card. Eliminate or modify anything that may appear steeped in bureaucratic process and procedure, and be wary of any items that can be perceived as indicative of a glacial development pace. References to project length and time between releases should typically be avoided. Emphasize new development over maintenance tasks, and accomplishments over process. Listing too many tools, frameworks, and specifications will often work against you and may be considered an indicator of your dependence upon them. Shortening the résumé is almost always the way to go here, and three + page résumés generally smell of enterpriseyness.
Develop other language credibility – Any code that you can point to that does not run the risk of being labeled enterprisey is better than nothing. As stated before, some startups perceive functional programming interest as a marker for ability, so even an implementation of a typical interview exercise in a functional language (or one different from your primary) has value. Provide links to this code on your résumé and reference any personal projects that are applicable.
Stop calling yourself ‘LANGUAGE Developer’ – I do it too (all the time), but you should not. Use whatever you feel is appropriate – Software Engineer, Programmer, Developer, Geek – but stop inserting a language when describing yourself on paper or verbally. And perhaps more importantly, stop thinking of yourself as a LANGUAGE Developer. Sometimes you may need to dumb it down so the clueless recruiter will find you, but try to minimize those instances the best you can (and do you really want that recruiter to find you anyway?).
Express your outside interests – Just because you get paid by some insurance company to write Java/.Net apps all day doesn’t mean that is who you are. If you are exploring other languages through books, conferences, and self-study, make that known in whatever way may be discovered during your job search (résumé, blog, social media, etc.). Hobbies like robotics, Raspberry Pi, and Arduino are probably unrelated to your job but not necessarily unrelated to your career. Any technical interests beyond the primary function of your job demonstrate at least some level of versatility and the ability to adapt outside of your enterprisey 9 to 5.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
The Stigma of Tech Certifications (and their real value)
Every so often I will receive a résumé from a software engineer that includes a list of technical certifications. These days most candidates tend to have none listed, but over the years I’ve seen some include anywhere from one or two certs up to ten or more certs, and it seems the number of companies willing to certify tech professionals has continued to grow. Vendors like IBM and Oracle each offer over 100 certifications, while Brainbench lists almost 30 tests on Java topics alone. At prices ranging from the $50 neighborhood up to $200 and more, the technology certification industry seems quite lucrative for the testing companies. But what is it all about for engineers? What (if any) value do certifications have for your marketability, and could having a certification potentially result in the opposite of the intended effect and actually hurt your chances of being hired?
When do certifications help?
There are some situations when certifications are absolutely helpful, as is the case for job seekers in certain industries that generally require a specific cert. A certification that was achieved through some relatively intense training (and not just a single online test) will also usually have value, much like a four year degree tends to be valued above most training programs. If a technology is very new and having skill with it is incredibly rare, a certification is one way to demonstrate at least some level of qualification that others probably will not have.
When and why can certifications actually hurt?
Professionals that have very little industry experience but possess multiple certifications usually will get a double take from hiring managers and recruiters. These junior candidates are perceived as trying to substitute certifications for an intimate knowledge that is gained through using the technology regularly, and more senior level talent will note that the ability to pass a test does not always indicate the ability to code. Many of these job seekers would be much better off spending their time developing a portfolio of code to show prospective employers.
Experienced candidates with multiple certifications may have some stigma attached to them due to their decision to both pursue them and then to subsequently list them. Some recruiters or managers may feel that these professionals are trying to compensate for having little depth in a technology or a lack of real-world accomplishments, and that the candidate wrongly assumes that a cert shows otherwise. Some that evaluate talent might get the impression that the candidate obtains certs in order to feel validated by (or even superior to) their peers, and that the cert is more driven by ego than a desire to learn. Lastly, there will be some who feel that over-certified technologists are ‘suckers’ that should have spent their (or the company’s) money and time more wisely.
The greatest value of certifications
Having spoken to hundreds of programmers certified in any number of technologies, I found that the majority claimed to find more value in the process of studying and test preparation than with the accomplishment of passing the test and getting certified. Pursuing a certification is one way to learn a new skill or to get back to the basics of a skill you already have. Certification tests are a great form of motivation to those that take them, due to the fact that there is:
- a time deadline – If you decide you want to learn a technology in your spare time, you probably don’t associate any particular date in mind for learning milestones. Certs are often scheduled for a specific date, which motivates the test taker to study right away.
- a time cost – Preparing for a test like this comes at the expense of other things in your life, so most that pursue certs understand the time investment required.
- a monetary cost – Shelling out $50 to $200 of your own money is an additional motivator. It’s not that much for most in the industry, but it is a lot to pay to fail a test.
- a risk of failure – If you are studying with others for a test, pride will also be motivating.
As the pursuit of certification seems to be the greatest value, keep this simple fact in mind.
Just because you get a certification doesn’t mean you have to list it on your résumé.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Tips To Overcome Ageism In Hiring As a Software Professional
As a recruiter who is about to celebrate (as if recruiters celebrate such a thing) mark fifteen years in the technology industry, I am starting to see that many of the contacts I made back in the late 90’s are now having some concerns about ageism during a job search. Any failed interview for older software professionals may cause a raised gray eyebrow and a thought that age and not their skill was a factor in the decision. Companies that freely apply catchall terms such as “overqualified“ or “not a cultural fit” in a rejection only serve to cloud the engineer’s mind and cause him/her to wonder if these are just the politically correct or legal code words to signify “You’re too old for us”.
Much has been written about older professionals being dogged by myths surrounding work effort, production, energy, and whether employees with families are more likely to work less. Start-ups are often portrayed as testosterone-and/or-alcohol-fueled code marathons only welcome to young males, which hurts the many start-ups that are not. But even hiring managers who have read studies and evidence that debunks these myths may still be guilty of judging candidates based on perception, so another blog post about why all companies (start-up or mature) should consider hiring older workers may not be helpful. The goal of this post is to help these more experienced candidates maximize their chances of being considered for jobs, and to make sure they are evaluated based on their skills alone during interviews.
Just as you would find at a nightclub, ageism starts with the person at the door. During a job search, the doorman is the person screening resumes. Therefore, the resume is the first item of consideration when trying to combat the problem. Let’s look at some common resume mistakes that expose candidates to ageism.
Resume Tips
Mistake #1 – Your resume does not need to include every position you have had in your life, and it doesn’t even need to list every position you have held in your field. This is by far the most common way that candidates expose themselves to possible ageism. If you have been in the industry for over twenty years, the work you did at the beginning of your career is hopefully quite different than what you are doing now. Trim down your resume to a manageable size by eliminating jobs that are the most dated and least relevant. Although there is nothing wrong with removing outdated experience, add the phrase ‘Additional experience provided upon request‘ if you feel it necessary.
Mistake #2 – The ‘Education’ section of a resume does not need to include graduation dates. The graduation date is arguably the easiest and most accurate way to put an age number on a candidate, using the formula
Age = (current year - graduation year) + 22
By including the date of graduation you are simply making it easier for them to discriminate. When hiring managers or recruiters see dates that seem like the distant past, they will do the math in their head subconsciously and label you with a number. “This guy graduated in ’81? That makes him, what…54?” Don’t put the date on the resume if you feel that your age could be used against you. This isn’t dishonesty (putting an incorrect year would be dishonest). There are several details about you that are not listed on your resume, and graduation date should not be required.
Without a graduation date, the formula for quickly approximating age generally becomes
Age = (current year - year of hire at earliest job listed) + 22
If you consider the point listed in Mistake #1 and you decide not to list early and irrelevant job(s) right out of school, and you also do not list your graduation date, you can potentially take years off of your perceived age.
Mistake #3 – Your resume does not need to include every technology that you have ever used. A resume of a very senior engineer could potentially contain an impressive and lengthy list of technologies in the skills section if he/she were to offer a comprehensive inventory of the various hardware, tools, languages, operating systems, databases, protocols, etc. that have been used during the span of their career.
Keep in mind that certain technologies or buzzwords are likely to trigger a visceral reaction based either on the age of the technology itself or how that technology is generally viewed by the industry. Languages that are out of favor in today’s programming culture are probably the most common issue. To have experience over a long period of time and with several tools is undoubtedly valuable, but unless a technology has significant relevance to the jobs being sought the risk of including these details may outweigh the benefits.
Interviews
If you followed the advice above regarding your resume, the next step will be interviews. In interviews, you want to make sure not to play into any of the myths or the fears that are commonly associated with the hiring of older workers. Below is a list containing many of the most stereotypical generalizations or assumptions common to ageism and how to best avoid them.
Older hires will not be able to put in hours. The availability issue is more closely associated with start-ups that may require more office time, and this perception is amplified when a start-up is staffed primarily with young, childless, and single employees. Being honest about your desire for work/life balance is best for all parties involved, but don’t let the interviewers assume that because of your age or family situation that you are only able to work 40 hours if you are indeed open to more. Clarify the amount of time you are willing to commit to working in or out of the office to prevent false assumptions.
Older hires will retire soon. Answering the “Where do you see yourself in five years?” with “Retired in Florida” is probably not the best answer, but honesty about your expectations is always best. Don’t let the employer assume that you are planning to retire soon if that is not the case. If you can not afford to retire in the near future, it may be helpful to let a hiring manager know that fact in order to allay this potential fear. The amount of time technology professionals of any age spend at any one company is lower than it used to be, so having an older employee on board for three to five years could have value to the company that is not much different than the average tenure of a young hire.
Older hires have low energy or are less productive. Older candidates should be more aware of their perceived energy level and body language during interviews. It’s good advice to job seekers of all ages to try to schedule interviews during the hours of the day that you feel you perform best and are most alert. Be sure you are well rested, fed, and look alive.
Older hires have dated or irrelevant experience. Eliminating some of the older experience on the resume helps showcase current skills while avoiding the appearance of stagnation. When giving anecdotal answers, try to focus your material first on what is most relevant and most recent. Referring to projects that ended thirty years ago is not advised unless the lesson learned was incredibly valuable.
Older engineers only want to manage. If you have been in leadership roles but are looking for something more hands-on, you must make that very clear during interviews and in initial correspondence when applying for a job. The assumption will always be that employees expect more responsibility as their career progresses, but many software engineers simply want to stay in the code and are not interested in managing. Don’t let your interviewer assume that you want to manage if you do not. A willingness to mentor employees while also being hands-on will add to your potential value.
Older engineers are less teachable and may have strongly reinforced bad habits. This line of thinking is amplified if the candidate has been in the same professional environment for many years, and the suspicion is that engineers become overly accustomed to a single way of working and won’t easily adapt to new ways. If you have had the same employer for a long time, try to emphasize any major changes that took place during your tenure and how you were forced to learn new things or leave your comfort zone. If you were an agent for change, be sure to bring that fact up during conversation.
Older hires will not be a culture fit. Culture fit is something older engineers probably didn’t hear much about in the beginning of their career, and ‘not a fit’ can be used as a blanket term for rejecting candidates without having to give a specific reason (which potentially exposes a company to discrimination lawsuits). Try to learn about company culture before the interview so you can at least be aware of their values and the image they want to convey, even if that image is not really who they are.
Career advice
Stay relevant. Keep up to speed on what technologies are popular with the cool kids, even if you do not use them on the job. If you have time to spend a few hours and tinker, that experience may pay off in your next job search. Knowing what others in the industry are doing is as simple as reading articles every few weeks.
Never stagnate. Older engineers that overstay their welcome at a company will have an incredibly difficult time finding work if a job search becomes necessary. When senior engineers are the victim of layoffs after being employed for 15 or more years, a long and difficult job search is often the result. Being stuck in the same role with the same technologies at the same company for a long stretch could become comfortable, but it will not be an asset when changing employers. Your first loyalty should be to yourself and your career, and not to your company. In my experience, older professionals that have not stayed at any job for a long stretch (>10 years) have the most prospects.
Keep a positive attitude. Many engineers are quick to actually dismiss themselves as candidates due to age, and they don’t even bother applying to companies they feel will reject them based on ageism. Other candidates have self-defeating attitudes about their plight or their perceived inability to improve their situation. Do not fear rejection, and learn from mistakes made during job searches.
Share your knowledge. Engineers that have a reputation as teachers, advisers, and mentors will always have an easier time finding work. Whether you write technical blog posts, present to user groups, or do informal talks during lunch, you will develop a reputation as someone who uses your experience to make your teammates better. Think of your experience as a positive asset for a new employer, and be known as someone who is always willing to guide younger technologists.
Be open to non-traditional employment options. Job trends and careers have changed drastically over the past 30 years, and the traditional ‘graduate college → get job → retire with pension‘ progression isn’t realistic today. If you haven’t already, give consideration to contract/consulting work, contract-to-hire or alternative employment options. Older professionals may find that ageism is less common in temporary hire situations.
Why You Didn’t Get the Interview
After reading the tremendous response to Why You Didn’t Get the Job (a sincere thanks to those that read and shared the post) I realized that many of the reasons referenced were specific to mistakes candidates make during interviews. At least a handful of readers told me that they didn’t get the job because they didn’t even get the interview.
With a down economy, most of us have heard accounts of a job seeker sending out 100, 200, perhaps 300 résumés without getting even one response. These anecdotes are often received by sympathetic ears who commiserate and then share their personal stories of a failed job search. To anyone who has sent out large quantities of résumés without any response or interviews, I offer this advice:
The complete lack of response is not due to the economy. The lack of response is based on your résumé, your experience, or your résumé submission itself.
My intent here is to help and certainly not to offend, so if you are one of these people that has had a hard time finding new work, please view this as free advice mixed with a touch of tough love. I have read far too many comments lately from struggling job seekers casting blame for their lack of success in the search (“it wasn’t a real job posting”, “the manager wasn’t a good judge of talent“, etc.), but now it’s time to take a look inward on how you can maximize your success. I spoke to a person recently who had sent out over 100 résumés without getting more than two interviews, and I quickly discovered that the reasons for the failure were quite obvious to the trained eye (mine). The economy isn’t great, but there are candidates being interviewed for the jobs you are applying for (most of them anyway), and it’s time to figure out why that interview isn’t being given to you.
If you apply for a job and don’t receive a response, there are only a few possibilities as to why that are within our control (please note the emphasis before commenting). Generally the problem is
- a mistake made during the résumé submission itself,
- problems with the résumé, or
- your experience
Qualified candidates that pay attention to these tips will see better results from their search efforts.
Your Résumé Submission
Résumés to jobs@blackholeofdeath – The problem here isn’t that your résumé or application was flawed, it’s just that nobody has read it. Sending to hr@ or jobs@ addresses is never ideal, and your résumé may be funneled to a scoring system that scans it for certain buzzwords and rates it based on the absence, presence and frequency of these words. HRbot apocalypse…
Solution – Do some research to see if you know anyone who works/worked at the company, even a friend of a friend, to submit the résumé. Protip: Chances are the internal employee may even get a referral bonus. LinkedIn is a valuable tool for this. Working with an agency recruiter will also help here, as recruiters are typically sending your information directly to internal HR or hiring managers.
Follow instructions – If the job posting asks that you send a cover letter, résumé, and salary requirements, this request serves two purposes. First and most obviously, they actually want to see how well you write (cover letter), your experience (résumé), and the price tag (salary requirements). Second, they want to see if you are able and willing to follow instructions. Perhaps that is why the ad requested the documents in a specific format? Some companies are now consciously making the application process even a bit more complicated, which serves as both a test of your attention to detail and to gauge whether applicants are interested enough to take an extra step. Making it more difficult for candidates to apply should yield a qualified and engaged candidate pool, which is the desired result.
Solution – Carefully read what the manager/recruiter is seeking and be sure to follow the directions exactly. Have a friend review your application before hitting send.
Spelling and grammar – Spelling errors are inexcusable on a résumé today. Grammar is given much more leeway, but frequent grammatical errors are a killer.
Solution – Have a friend or colleague read it for you, as it is much more difficult to edit your own material (trust me).
Price tag – As you would expect, if you provide a salary requirement that is well above the listed (or unlisted) range, you will not get a response. Conversely and counterintuitively, if you provide a salary requirement that is well below the range, you will also not get a response. Huh?
Suppose you want to hire someone to put in a new kitchen, and you get three estimates. The first is 25K, the second is 20K, and the third is 2K. Which one are you going to choose? It’s hard to tell, but I’m pretty sure you aren’t going to use the one that quoted you 2K. Companies want to hire candidates that are aware of market value and priced accordingly, and anyone asking for amounts well above market will not get any attention.
Solution – Research the going rate for the job and be sure to manage your expectations based on market conditions. Another strategy is trying to delay providing salary information until mutual interest is established. If the company falls in love, the compensation expectation might hurt less. There is some risk of wasting time in interviews if you do not provide information early in the process, and most companies today will require the information before agreeing to an interview.
Canned application – By ‘canned’ I am referring to job seekers that are obviously cutting and pasting content from previous cover letters instead of taking the time to try and personalize the content.
Solution – Go to the hiring firm’s website and find something specific and unique that makes you want to work for that company. Include that information in your submission. If you are using a template and just filling in the blanks (“I read your job posting on _____ and I am really excited to learn that your company _____ is hiring a ______”), delete the template now. If you aren’t willing to invest even a few minutes into the application process, why should the company invest any time learning about you?
Too eager – If I receive a résumé submission for a job posting and then get a second email from that candidate within 24 hours asking about the submission, I can be fairly sure that this is an omen. If I get a call on my mobile immediately after receiving the application ‘just to make sure it came through‘, you might as well just have the Psycho music playing in the background. Even if this candidate is qualified, there will probably be lots of hand-holding and coaching required to get this person hired. Reasonably qualified candidates with realistic expectations and an understanding of business acumen don’t make this mistake.
Solution – Have patience while waiting for a response to your résumé, and be sure to give someone at least a couple/few days to respond. If you are clearly qualified for a position, you will get a reply when your résumé hits the right desk. Pestering or questioning the ability of those that are processing your application is a guarantee that you will not be called in.
Your Résumé
Your objective – If your objective states “Seeking a position as a Python developer in a stable corporate environment“, don’t expect a callback from the start-up company looking for a Ruby developer. This applies even if you are qualified for the job! Why doesn’t the company want to talk to you if you are qualified? Because you clearly stated that you wanted to do something else. If you put in writing that you are seeking a specific job, that information must closely resemble the job to which you are applying.
Solution – You may choose to have multiple copies of your résumé with multiple objectives, so you can customize the résumé to the job (just be sure to remember which one you used so you bring the correct résumé to the interview). As there may be a range of positions you are both qualified and willing to take, using a ‘Profile’ section that summarizes your skills instead of an ‘Objective’ is a safer alternative.
Spelling and grammar (again) – see above
tl;dr – To any non-geek readers, this means ‘too long; didn’t read‘. To my geek readers, many of you are guilty of this. I’ve written about this over and over again, but I still get seven page résumés from candidates. I have witnessed hiring managers respond to long-winded résumés with such gems as ‘if her résumé is this long, imagine how verbose her code will be‘. (Even for non-Java candidates! #rimshot) Hiring managers for jobs that require writing skills or even verbal communication can be extremely critical of tl;dr résumés.
Solution – Keep it to two or three pages maximum. If you can’t handle that, get professional help.
Buzzword bingo – This is a term that industry insiders use to refer to résumés that include a laundry list of acronyms and buzzwords. The goal is to either catch the eye of an automated search robot (or human) designed to rate résumés based on certain words, or to insinuate that the candidate actually has all the listed skills. Software engineers are probably more guilty of this than other professionals, as the inclusion of one particular skill can sometimes make the difference between your document being viewed by an actual human or not. When candidates list far too many skills buzzwords than would be reasonably possible for one person to actually know, you can be sure the recruiter or manager will pass based on credibility concerns.
Solution – I advise candidates to limit the buzzwords on your résumé to technologies, tools, or concepts that you could discuss in an intelligent conversation. If you would not be comfortable answering questions about it in an interview, leave it off.
Your Experience
Gaping holes – If you have had one or more extended period of unemployment, hiring managers and recruiters may simply decide to pass on you instead of asking about the reasons why. Perhaps you took a sabbatical, went back to school full-time, or left on maternity leave. Don’t assume that managers are going to play detective and figure out that the years associated with your Master’s degree correspond to the two year gap in employment.
Solution – Explain and justify any periods of unemployment on your résumé with as much clarity as possible without going into too many personal details. Mentioning family leave is appropriate, but providing the medical diagnosis of your sick relative is not.
Job hopping – Some managers are very wary of candidates that have multiple employers over short periods of time. In the software world it tends to be common to make moves a bit more frequently than in some other professions, but there comes a point where it’s one move too many and you may be viewed as a job hopper. The fear of hiring a job hopper has several roots. A manager may feel you are a low performer, a mercenary that always goes to the highest bidder, or that you may get bored after a short time and seek a new challenge. Companies are unwilling to invest in hires that appear to be temporary.
Solution – If the moves were the result of mergers, acquisitions, layoffs, or a change in company direction, be sure to note these conditions somewhere in the résumé. Never use what could be viewed as potential derogatory information in the explanation. Clearly list if certain jobs were project/contract.
Listed experience is irrelevant/unrelated – This could be a symptom of simply being unqualified for the position, or it could be tied to an inability to detail what you actually do that is relevant to the listed job requirements. I would suspect that most of the aforementioned people (that received no responses to 100 submission) probably fall into the unqualified category, as job seekers tend to feel overconfident about being a fit for a wider range of positions than is realistic. Companies expect a very close fit during a buyer’s market, and are willing to open up their hiring standards a bit when the playing field starts to level.
Solution – Be sure to elaborate on all elements of your job that closely resemble the responsibilities listed in the posting. Instead of wasting time filling out applications for jobs that are clearly well out of reach, spend that time researching jobs that are a better match for you.
You are overqualified – The term ‘overqualified’ seems to be overused by rejected applicants today, as there is no real stigma to the term. It’s entirely comfortable for a candidate to say/think “I didn’t get the job because I possess more skills at a higher level than the employer was seeking“. When a company is seeking an intermediate level engineer, it isn’t always because they want someone earlier in their career than a senior level engineer (although in some cases this could be true). Rather, they want the intermediate level engineer because that is what their budget dictates or they expect that senior engineers would not be challenged by the role (and therefore would leave). There are also situations where companies will not want to hire you because your experience is indicative that you will only be taking this job until something better comes along. A CEO applying for a job as a toll collector will not be taken seriously.
Solution – Be sure that your résumé accurately represents your level of skill and experience. Inflating your credentials or job titles will always work against you.
Conclusion
The time you spend on your job search is valuable, so be sure to use it wisely. Invest additional effort on applications for jobs that you feel are a great fit, and go above and beyond to be sure your submission gets attention. As a general rule of thumb, you want to be sure that whoever receives your résumé will get it into the hands of someone who has a similar job to the one you want, not just someone trained to look for buzzwords. Employees that have similar experience will be the best judges of your fit. If you aren’t getting the response you want, do not keep using the same methods and expecting a different result.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
How Employers Measure Passion in Software Engineering Candidates (and how to express your passion in resumes and interviews)
Over the past few months I have had some exchanges with small company executives and hiring managers which have opened my eyes to what I consider a relatively new wrinkle in the software development hiring world. I have been recruiting software engineers for 14 years, and I don’t recall another time where I’ve observed this at the same level. Here are two examples.
The first incident was related to a candidate (‘A’) resume that I submitted to a local start-up. A was well-qualified for the position based on the technical specifications the client gave me, and I anticipated that at worst a phone screen for A would be automatic. I even went as far as to share A’s interview availability. A day after hitting ‘send’, I received feedback that the hiring manager was not interested in an interview. A large part of the manager’s reasoning was related to the fact that A had taken a two year sabbatical to pursue a degree in a non-technical discipline and subsequently took a job in that field for a brief stint, before returning to the software world a few years ago. I clarified information about A to be sure that the manager had full understanding of the situation, and the verdict was upheld – no interview.
My second anecdote involves another candidate (‘B’) that I presented for a position with a different client company. B was someone I would classify as a junior level candidate overall and probably ‘borderline qualified’ for the role. B had roughly the minimum amount of required experience with a few gaps, and I was not 100% confident that B would be invited in. B was brought in for an interview, performed about average on the technical portions, and shined interpersonally.
As this company does not make a habit of hiring average engineers, I was at least a bit surprised when an offer was made. I was told that a contributing factor for making the offer was that B’s ‘extracurricular activities’ were, according to my client, indicative of someone that was going to be a great engineer (though B’s current skills were average). B’s potential wasn’t being assessed as if B were an entry level engineer with a solid academic background, but rather the potential was assessed based on B’s interest in software.
There are obviously many other stories like these, and the link between them seems obvious. Software firms that are hiring engineers (smaller shops in particular) appear to be qualifying and quantifying a candidate’s passion with the same level of scrutiny that they use in trying to measure technical skills and culture fit. Historically, companies have reviewed resumes and conducted interviews to answer the question, ‘Can this candidate perform the task at hand?‘. For my purposes as a recruiter of engineers, the question can be oversimplified as ‘Can he/she code?’. It seems the trend is to follow that question with ‘Does he/she CARE about the job, the company, and the craft?’.
If you lack passion for the industry, be advised that in future job interviews you may be judged on this quality. Whether you love coding or not, reading further will give you some insight. Engineer A is a cautionary tale, while B is someone the passionate will want to emulate. Let’s start with A.
Candidate A never had a chance, and I’ll shoulder partial responsibility for that. A was rejected based solely on a resume and my accompanying notes, so theoretically A could be extremely passionate about software engineering without appearing to be so on paper. Applicants do take some potential risks by choosing to include irrelevant experience, education, or even hobbies on a resume, and I will often warn my candidates of items that could cause alarm. In this case, A’s inclusion of both job details and advanced degrees in another discipline were judged as a red flag that A might decide to again leave the software industry. A similar conclusion could have been reached if A had listed hobbies that evidenced a deep-rooted drive toward something other than engineering (say, studying for a certification in a trade).
Another related mistake on resumes is an Objective section that does not reflect the job for which you are applying. I have witnessed candidates being rejected for interviews based on an objective, and the most common example is when a candidate seeking a dev job lists ‘technical lead’ or ‘manager’ in the objective. Typical feedback might sound like this: ‘Our job is a basic development position, and if she only wants to be in a leadership slot she would not be happy with the role’. Listing the type of job that you are passionate about is essential if you are going to include an objective. I prefer that candidates avoid an objective section to avoid this specific danger, as most job seekers are open to more than one possible hiring scenario.
Since the search starts out with the resume, be sure to list all of the details about you that demonstrate your enthusiasm. This should include relevant education, professional experience, and hobbies or activities that pertain to engineering. When listing your professional experience, emphasize the elements of your job that were the most relevant to what you want to do. If you want to strictly do development, downplay the details of your sys admin or QA tasks (a mention could be helpful, just don’t dwell). When listing your academic credentials, recent grads should be sure to provide specifics on classes relevant to your job goals, and it may be in your best interest to remove degrees or advanced courses unrelated to engineering.
In my experience, the most commonly overlooked resume details that would indicate passion are:
- participation in open source projects
- membership in user groups or meetups
- conference attendance
- public-speaking appearances
- engineering-related hobbies (e.g. Arduino, personal/organizational websites you built or maintain, tech blogging)
- technical volunteer/non-profit experience
If any of the above are not on your resume, be sure to include them before your next job search.
Assuming that you get the opportunity to interview, try to gracefully and tactfully include some details from the bulleted list above. Your reading habits and technologies you self-study are best mentioned in interviews, as they may seem less appropriate as resume material.
Conclusion: Most candidates should feel free to at least mention interests that are not engineering related if the opportunity presents itself, as companies tend to like hiring employees that are not strictly one-dimensional. Just be sure not to overemphasize interests or activities that could be misinterpreted as future career goals. Passion alone won’t get you a job, but it can certainly make a difference in a manager’s decision on who to hire (candidate B) and who not to even interview (candidate A). Make sure you use your resume and interview time to show your passion.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, and Google +.
Job Tips For Geeks 