Before we begin, I acknowledge that companies want to hire cheaper labor when possible, and some shops care less about quality products than others. And for the record, I’m over 40.
By saying you are overqualified for jobs, what are you really saying? “I am more skilled or more experienced than the job requires.“ That feels kind of good, doesn’t it?
SPOUSE: How did the interview go?
JOB SEEKER: I didn’t get the job.
SPOUSE 1: Oh, I’m sorry. What happened?
JOB SEEKER: Unfortunately, it turns out my skills are simply too strong.
Of course rejection hurts, but to tell your spouse (and yourself) that you were turned down because you were too skilled or too experienced is much less bruising on the ego than the alternative. For companies looking to eliminate candidates, using the word overqualified may take some of the sting and fear of retribution out of the rejection. But is it true?
Think about this scenario for a second. You are trying to hire a software developer and you estimate that someone with say five years of experience should be able to handle the duties effectively. A candidate is presented with fifteen years of experience that has all the attributes you are seeking. This person should theoretically perform the tasks quicker and even take on some additional workload. Do you really think a company would not hire this person simply because he/she has those additional years of experience? I would argue that is rarely the case.
Question: Is ‘overqualified’ a code word used by managers/HR to mean other things?
Answer: ALMOST ALWAYS
What can overqualified actually mean?
listed in order from most likely to least likely, IMO
- Overpaid/over budget – If your experience > what is required, it generally becomes a problem when your salary requirements are above what is budgeted. It’s not that you are classified as overpaid in your current role, but that you would be overpaid for the level of responsibility at the new job. I list this as the most likely culprit because I often see companies initially reject a candidate as overqualified, then hire that same person because of a lack of less experienced quality talent.
- Stagnant – Candidates who have worked for many years as a developer in a technically stagnant and regulated environment will often not thrive in less regulated, more technically diverse firms. The conventional wisdom, right or wrong, is that you can’t release the zoo lions back into the jungle once they’ve been tamed.
- ‘Overskilled’ – If your skills > what is necessary for the job, an employer may fear that the lack of challenges provided will bore you into looking for more interesting work in the future. Hiring a tech lead to do bug fixes could lead to a short stint. There is emerging evidence that shows skilled workers do not exit less challenging jobs quickly or in high numbers, but hiring managers are not quite ready to abandon the traditional line of thinking.
- Threatening – If your experience > those conducting the interviews, there could be some fear that you could be a competitor for future opportunities for promotion. If a start-up is yet to hire a CTO, the highest geek on that firm’s food chain may be jockeying for the role. This may sound a bit like a paranoid conspiracy theory, but I genuinely believe it is prevalent enough to mention.
- Too old – Ageism is a real problem, but in my experience in the software world, ageism is also widely overdiagnosed by candidates who think the problem is their age when in actuality it is their work history. Most of the self-diagnosed claims of ageism that I hear are from candidates who spent perhaps 20+ years working for the same company and have not focused on keeping their skills up to date (see stagnant above). I can’t say that I’ve ever heard a claim of ageism from a candidate that has moved around in their career and stayed current with technology. The problem often isn’t age, it is relevance.
Some of the best and most accomplished/successful software engineering professionals that I know are over 50, which is older than some of the candidates I hear claiming possible ageism. One trait that the overwhelming majority of these engineers have in common is that they didn’t stay in any one place for too long to stagnate. I don’t think that is a coincidence.
If you are an active job seeker that is continuously hearing that you are overqualified, what can you do to improve your standing?
- Rethink – Try to investigate which of the meanings of overqualified you are hearing most often. Is your compensation in line with what companies are paying for your set of qualifications? Do you present yourself in interviews as someone who may become easily bored when your work is less challenging? Are you making it clear in interviews that you want the job, and you explain why you want the job?
- Retool – Make sure your skills are relevant and being sought by companies. Invest time to learn an emerging technology or developing some niche specialty that isn’t already flooded.
- Remarket – Write down the top reasons you think a company should hire you, and then check to see if those reasons are represented in your job search materials (resume, email application, cover letters). Find out what was effective for your peers in their job search and try to implement new self-promotion tactics.
- Reboot and refresh – Take a new look at your options beyond the traditional career paths. Have you considered consulting or contracting roles where your guidance and mentoring skills could be justified and valued for temporary periods? Are there emerging markets that interest you?
Terms like ‘overqualified’ and ‘not a fit’ are unfortunately the laziest, easiest, and safest ways that companies can reject you for a position, and they almost always mean something else. Discovering the real reason you were passed up is necessary to make the proper adjustments so you can get less rejections and more offers.
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.