Category: Interview tips

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.

What If We ______ Like We Hire Programmers – What Questions Are Appropriate?

Programmers often experience a high degree of frustration during the interview process, and one primary source of annoyance is how the programmer perceives the line of questioning or exercises.  In a buyer’s market where supply exceeds demand, hiring managers will often be a bit more selective in evaluating candidates, and talent evaluators may request or require more specific skill-sets than they would if the talent pool were deeper.  These tactics are short-sighted but deemed necessary in a crunch.

I recently stumbled on two articles with an identical theme.  “If Carpenters Were Hired Like Programmers” was written in 2004, and “What If Cars Were Rented Like We Hire Programmers” was posted very recently.  The tl;dr of these posts is essentially that programmers being interviewed are asked incredibly esoteric questions or are grilled about experience with irrelevant topics (wood color for carpenters, car wiring for car renters).  The comments sections on Reddit and Hacker News are a mix of agreement, criticism, and various anecdotes about interviews that reflected the articles’ theme.  No analogy is perfect.

There are surely companies that are ‘doing it wrong’ and asking questions that will reveal little about a candidate’s potential as an employee, but I’m getting the sense that many candidates are starting to claim that even appropriate lines of questioning and requests are now somehow inappropriate.  More importantly, it appears that candidates may not understand or appreciate the true value of certain questions or tasks.

To continue the carpenter analogy, let’s look at the types of questions or tasks that would be both useful and appropriate in evaluating either a carpenter or a programmer (or anyone that builds things) for potential employment.

  • Overall experience and training – No one will should argue these.
  • Experience specifically relevant to the project at hand – This is where we may first see some candidates crying foul, particularly if the relevancy of the experience is judged predominantly by the level of experience with very specific tools.  Learning a new programming language is probably not equivalent to learning how to use a different brand of saw, but engineers can sometimes be overconfident about the amount of time required to become productive with a new technology.  The relevancy of experience factors into a hiring decision most when project delivery is valued over long-term employee development.
  • Answer some questions about your craft – When hiring managers ask questions, candidates should keep in mind that there can be a few reasons why a question is asked.  Obviously, one objective may be to truly find out if you know the answer.  However, sometimes the interviewer asks a difficult question simply to see how you may react to pressure.  Another possibility is that the interviewer wants to reveal if you are the type of person who may confidently give a wrong answer to try and fool the interviewer, if you are more likely to admit what you do not know, and to evaluate your resourcefulness by how you would research a problem with an unknown answer.  A genuinely, laugh-out-loud stupid question may be asked to see how well you may deal with frustration with a co-worker or an unruly customer.  Lastly, the interviewer may simply want to see your method of approaching a tough question and breaking it down.  Candidates that are quick to complain about being asked seemingly minute or irrelevant details often overlook the true purpose behind these exercises.
  • Design something – I’m always amazed when candidates call me in a state of shock after being asked to do a whiteboard exercise in an interview, as if these types of requests were either unfair, insulting, or a ‘gotcha’ technique.  Anyone who builds things should be somewhat comfortable (or at least willing) to either visually depict a past design or attempt to design a quick solution to a problem on the spot.
  • Show us how you work alone – Assigning a short task for someone to complete either in an interview setting or at home before/after an interview is absolutely an appropriate request, which candidates can choose to accept or deny.  It is both only an opportunity to demonstrate skills and to further express your interest in the position by being willing to invest time.  Providing a bit more than the minimum requested solution is a valuable method to differentiate yourself from other candidates.
  • Let’s see how you work with a team – As candidates are often hired to build things collaboratively, a short pairing exercise or a group problem-solving activity could be the best way to efficiently evaluate how well one plays with others.
  • Show us some samples – Professionals who build things have the unique interviewing advantage of actually showing something physical that they have built.  A carpenter bringing a piece of furniture to an interview should be no different than an engineer offering a past code sample.  Companies are increasingly using past code as an evaluation tool.
  • References – At some point in the process of evaluating talent, asking for references is a given.  Being unwilling or unable to provide references can make someone unemployable, even if all other tasks are met.

If you go back and reread the articles about the carpenter and rental car interviews, you may have a new perspective on the reasons some questions may be asked.  Think back on some interviews that you have had, and consider whether it’s possible that the interviewer had ulterior motives.  It’s not always about simply knowing an answer.

If you found this article useful, you might find my ebook Job Tips For GEEKS: The Job Search very helpful.  You can also follow Job Tips For Geeks on Google+, Facebook, and Twitter.

Interview Prep For Geeks

Failing an interview due to a lack of qualifications is forgivable, but it is tragic when highly qualified candidates do not get an offer due to being unprepared. With the amount of information freely available today, the time and effort required to prepare for an interview is extremely low and a relatively small investment to make in your career.

Typically a candidate will have at least two or three days advance notice to do some research and prepare for any interview. Here is a checklist of things for technologists to investigate to be sure you are ready for what will come your way.

  • Company intel – Learn as much as you can about the company, and try to have at least one minute of material memorized to answer the “What do you know about us?” question. Be prepared to present on the company history, the products or services the company provides, details on the business model, and the industry itself (competitors, health of the market, etc.). For technologists, the ability to give an eloquent response to the “Describe what the company does” question is a huge asset that should not be overlooked and could be a significant factor in your success. Gathering substantial information on a young company’s funding status or finances might be difficult, but there will generally be at least some info in press releases from venture partners.
  • Tech environment – Get specific details about the technical environment by doing some basic web research, reviewing any available job descriptions or LinkedIn employee profiles, and talking to your recruiter or any appropriate company contacts you may have. What frameworks, languages, databases, operating systems, and hardware are they using? Even if the details aren’t all entirely relevant to your interview, it will show that you are taking this process seriously. Look up any buzzwords or acronyms you don’t recognize so you can at least discover if you may have experience with a related item (“I haven’t worked with ______, but I’m familiar with ________ which appears to be a similar tool/language”).
  • Tech moves – Knowing the company’s current tech details is valuable, but knowing about some of the company’s technical history will show great initiative while also providing potential insight into how the company views technology and makes tech decisions. Has the company made significant changes to their stack, and if so, why? Are they heavily invested in open source? Do they seem closely linked to a specific vendor? Does the company have an engineering blog or a company GitHub account for you to explore that might contain this information?
  • Interviewer intel – Insight into the technical background and past employers of the individual(s) you will meet is a great advantage, as you may have some similar history. Personal GitHub or Twitter accounts? Technical blog posts? A LinkedIn or web search of the interviewer(s) might turn up some helpful details to use during the interview, as long as you use the info wisely. Showing that you did some research displays initiative, as long as you respect personal space.
  • Confirm the basics – Where are you going and who should you ask for when you get there? Who are you meeting with and what is his/her/their role in the company? What is the preferred dress code? (NOTE: Some companies actually ask that candidates dress more casual, so be sure to ask)
  • Prepare questions and anecdotes – Most interviews will provide you with at least a brief opportunity to ask questions. Although you ideally want to have these memorized, it is generally a good idea to have some questions listed so you don’t forget them under possible duress. There are also some fairly standard questions in the “tell me about a time when…” family which are commonly answered with anecdotes. Give some thought to past challenges, failures, and successes, and especially what lessons you learned from each project.
  • Documents – Some companies may ask you to fill out an application and other relevant documents before the interview. Find out if this is the case and if so get those completed before interview day. Make sure to print out at least three copies of your resume and one copy of your list of questions. Think about who you will list as references if asked on the application, and have their info (name, email) available.

Keep in mind that making a solid impression in an interview is something that can make a huge impact down the road, whether or not you get the job. Interviewers remember candidates who impressed, and they absolutely will remember those who crashed and burned as well. Do your homework and take interviews seriously, not just for the sake of getting this job but for opportunities later in your career.

TALK! It’s An Interview, Not An Interrogation

Several times a year I will get a call or email from a hiring manager telling me that an interview never really ‘went anywhere’ because the candidate seemed either unwilling or unable to dive very deep into technical topics.  It can be impossible for an interviewer to accurately gauge whether the cause was a lack of tech skills or just an inability to communicate those skills, but it really makes no difference as the end result is a rejection.  This observation is probably a bit more prevalent during phone screens, where the parties do not have the advantage of proximity and body language to assist.

Whenever I hear feedback like this from clients, I imagine what the interview may have sounded like:

INTERVIEWER:  Have you worked with Ruby on Rails before?
CANDIDATE:  Yes, I have.
INTERVIEWER:  Could you elaborate on that a little bit?
CANDIDATE:  Yes, I could.
INTERVIEWER:  (VISIBLY ANNOYED)

It brings to mind the old joke (which of course reinforces gender and programmer stereotypes):

A wife asks her computer programmer husband, “Go to the store and get a gallon of milk, and if they have eggs get a dozen.”  A short time later the programmer returns with twelve gallons of milk.  She asks, “Why did you get twelve gallons of milk?” and he responds, “They had eggs.”

In the short two question interview scenario above, the candidate is answering the questions being asked, and the candidate is providing all the information that was being requested.  If you look at the questions in a literal manner (as many engineers tend to do), this candidate may not feel he/she is being dodgy at all.  Just as the programmer in the joke did what his wife asked (by his literal interpretation).

Let’s now look at a brief example of a police interrogation:

INTERROGATOR:  Where were you on the night of the 8th?
SUSPECT:  At home.
INTERROGATOR:  Were you by yourself?
SUSPECT:  No
INTERROGATOR:  Who was with you?
SUSPECT:  My husband.
INTERROGATOR:  WHO WAS WITH YOU??!!
SUSPECT:  My lover!  (CUE SCARY MUSIC)

These answers provide the minimum amount of information the interrogator requested, and a lawyer will probably advise you to keep your answers short and precise during questioning.  The interrogator’s job is to get a suspect to say something that he/she does not want to reveal.

A job interview is not an interrogation, and it is important for candidates to be sure they are not treating it as such.

Keep in mind that interviews, particularly in technology settings, can be awkward situations for participants on both sides of the table.  Most interviewers are at least slightly uncomfortable being placed in a room with a complete stranger for the sole purpose of judging him/her in order to reach some conclusion about whether he/she should be hired, a decision which could greatly impact the life of at least one party (the candidate) or even both parties (if the hire is made).  If an interviewer gives even a small consideration that this stranger may have a family that depends on the income that the job would provide, the potential for an awkward exchange is even more likely.

Most interviewers want to get a dialogue flowing, where the discussion will allow them to evaluate your technical and interpersonal skills.  They want to control and moderate the conversation, but they would like to listen more than they speak.  The candidate’s ability to communicate his/her thoughts will be apparent after a few questions.  At some point most interviewers have to ask themselves, “Would I want to work next to this person every day for several years?”  If the candidate answered their questions in a fashion resembling the Candidate or the Suspect in the samples above, the answer is always “No”.

Some candidates may argue that they have answered the questions as asked, and that if the interviewer wanted more details he/she should have inquired for them specifically (“Tell me about Ruby on Rails experience.”).  This is a valid observation, but it doesn’t solve the problem.  It’s purely a function of conversational English, and it is one reason that chatbots with artificial intelligence may give answers like our Candidate did in the example.

So, I’ll just keep talking and talking to solve the problem?  NOPE.  There is also the possibility that if a candidate answers every question with a long-winded response, he/she may be rejected for not being able to provide succinct answers.  Managers are often unwilling to hire someone who they feel is unable to express themselves efficiently, and in the case of software engineers you may hear, “Being that chatty, I can’t imagine what his/her code (comments) looks like!‘

How do I appear to be open, honest, and transparent without sounding chatty?  How do you avoid being labeled as unable or unwilling to answer interview questions?

  • Don’t take every question literally – Remember that a good interviewer is trying to engage you in a dialogue and an exchange of ideas.
  • Pause before answering – Some candidates seem programmed to immediately start talking after a question is asked, and then find that they haven’t really answered the question.  Taking a moment to reflect on the question and to organize your thoughts gives the appearance that you are making an effort to supply a strong answer and that you are not impulsive.  A little white space does not have to be an uncomfortable silence.
  • Pause after answering –  If the interviewer does not respond with a follow-up after a few seconds, he/she may be waiting for you to go deeper.  Ask if he/she is satisfied with your answer and offer to continue with more information if necessary.  “Would you like some more details on that?“
  • Ask questions to clarify what type of answer is expected – If you are asked a question where there could be both an acceptable short answer (yes/no) or a longer answer (details), give the short response and offer the interviewer more.  “Yes, I have used Ruby on Rails.  Would you like me to discuss my experience further?“
  • At the end of the interview, ask the interviewer if they have any other questions that will help them make their decision. Invite them to contact you in the coming days if any additional information is required or if they would like any clarification on the answers you provided.

Go into the interview with the goal of having a conversation which should put the interviewer at ease.  Be willing to follow the interviewer into any direction the discussion may take, and ask questions so you know that you are on the same page.

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+.

Overqualified is Overdiagnosed

I’ve been inspired by comments on prior articles to discuss the sensitive topics of ‘overqualification’ and ageism. My Why You Didn’t Get The Job and Why You Didn’t Get The Interview posts were republished on a few sites, resulting in some active debates where at some point a participant states that the real reason that they weren’t hired was that they are overqualified for all the jobs out there, or they were victims of ageism. In my opinion and experience recruiting in the software engineering world, the term overqualified is used too widely by companies (and then inaccurately cited by rejected candidates), and  claims of alleged ageism are often something else entirely.

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?

  1. 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?
  2. 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.
  3. 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.
  4. 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.

Blind Dating for Geeks: Questions Candidates Should Ask (and when to ask them) During Interviews

After a few ‘Questions Candidates Ask In Interviews’ themed articles appeared in my Twitter stream, I was reminded of an article I wrote two years ago called ‘Best Questions To Ask The Interviewer, And When To Ask Them‘.  I think one key element missing in the new articles is the ‘when to ask them’ detail that I feel is incredibly important.  Also, being that JobTipsForGeeks is aimed at technology professionals, there are some nuances that do not apply to other industries.

Why is the timing of when the questions are asked important?  An interview is nothing more than a blind date, with the goal on both sides being to find out if you want to start seeing each other in a somewhat committed fashion.  You want to discover as much as you can about the other party, but first you have to set a positive tone and build trust. We surely would want to find out if our blind date is, say, a serial killer – but leading off with the ‘Are you a serial killer?’ question would seem rude, and we probably wouldn’t get an honest answer anyway.

Below is a list of the best questions to ask in chronological order.  Please keep in mind that you would need to restart from the beginning for every new person that you meet in situations where you meet with multiple participants individually.  You may not be afforded the opportunity to ask all the questions based on time constraints, so use at least one question from the first section for each person and try to use all the questions at least once at some point in the process.

Setting a positive interview tone
OR
Cocktails and light conversation

Question: “What is your background and how did you come to work for COMPANY?”
Reason to ask it:  Most people genuinely like to talk about themselves (those that do not share this trait will probably not be in the interview), so give them a chance to do so. Don’t be afraid to toss in some remarks and perhaps a follow-up question regarding their background if appropriate.  You may learn that you have some shared history with this person that could give you a potential ‘in’.

Question: “What do you like best about your job and about working for COMPANY?”
Reason to ask it: This question serves two purposes. First, it gives the employee the opportunity to speak well of the company, which again will give an initial positive vibe to your dialogue. Secondly, what the employee chooses to say they like best can be quite telling. If their answer is ‘environment’, ‘work/life balance’ or ‘the people’, that is a universal positive. If the response is ‘the money’ or ‘vacation time’, you may want to dig deeper to find out why.

BONUS Question:  (If possible, find a fairly recent newsworthy item about the company that is both appropriate and positive, and ask an insightful question about it)
Reason to ask it:  This shows that you have done your homework before the interview and that you want to be taken seriously as a candidate.  This is something that you want to fully research to prevent making a huge mistake that would make recovery impossible.

Discovery
OR
Gentle interrogation of your date during dinner

Question: What are the biggest challenges you face?
Reason to ask it: The reason for using the word ‘challenges’ is that it does not have a negative connotation, whereas asking someone for the ‘worst’ element of their job will not give a positive impression.  The answer here will start to create an image of what this company is going through today and what the landscape is for tomorrow.  At a start-up, you may hear answers about financial challenges, limited resources and a fast pace.  Some industries are known for heavy regulation getting in the way of progress.  This is all valuable information.

Question: What would the typical day be like for me at COMPANY?
Reason to ask it: You may get an answer that gives you tangible insight into work/life balance (‘I usually get home in time to watch Jimmy Fallon’), how much of your day may be spent coding or doing other duties, how many meetings you may be pulled into, etc.

Question: What was your career path here and what is a typical career path for my role at COMPANY?
Reason to ask it: Find out if they promote from within and if there are separate technical and non-technical/pure management tracks.  Will you be forced into a management role?

Question: How would you describe the environment?
Reason to ask it:  Asking an open-ended question like this could lead in several directions.  You should be able to ascertain if it is cut-throat or cooperative, how much support is given to technologists, and whether you will be expected to work with teams or as a solo entity.

Question: Management styles? Development processes and methodologies in place?
Reason to ask it:  Engineers preferences for structure vary greatly.  Be sure to drill down to get the best understanding of whether their practices are aligned with your views.

Question: Tech stack?
Reason to ask it: If their answer is a list of products and technologies that are severely dated, it could mean the company doesn’t invest in or even investigate the latest and greatest.  Conversely, if they seem overly concerned with bleeding-edge, perhaps they are making tech decisions based on cool factor more than quality.  Be sure to listen for what can be telling patterns, such as an abundance of tools from a particular vendor or a wide variety of open source tools.  This question also gives you an opening to discuss your experience (and preferences) relevant to their stack.

Question: Why is this position open?
Reason to ask it: Growth or promotion are the two most desirable answers. Perhaps this position is a launching board into higher level positions, or maybe it is a dead-end that will burn you out.

Closing the deal
OR
Last call and the drive home…

Question: What qualities/background do you think would be key to making someone successful in this position?
Reason to ask it: During that last set of questions, some negative topics could have surfaced.  This gets things back on the positive side before the end, as well as giving you more info on whether you would be hitting the ground running or may require some learning curve. (NOTE: This question could also be used as an ice breaker early on)

Question: What projects are just getting ramped up or are on the horizon?
Reason to ask it: Interviewers will enjoy discussing new endeavors that they think you will find most interesting. If they talk about fixing bugs and maintenance, chances are that is what you will be doing in this job for the foreseeable future.  Ideally, the interviewer’s excitement should be palpable.

Question: Where do you see yourself in five years here at COMPANY?
Reason to ask it: This question is generally asked of candidates, so turning that around should provide insight into how he/she really feels about the firm and their prospects. Again, it lets the interviewer talk about himself/herself again in a positive fashion, and if the interviewer has a sense of humor expect an attempt to use it on this question.

The Conclusion
OR
Goodnight

Question:  Is there anything else I can answer for you or any more information I can provide to help you in your decision?
Reason to ask it:  It shows you are forthcoming and trying to be helpful.

Question:  I am very interested in this opportunity (or similar sentiment).  When do you expect COMPANY might be making a decision?
Reason to ask it:  Showing interest is vital, and asking about their timing could lead to information on other candidates.  It also may prompt them to ask about your availability to start, which is an obvious buying sign.  You want to do this is with as little pressure as possible.

Close by thanking the interviewer for taking the time to speak with you and tell him/her that you look forward to the next steps.  Good luck.

Why You Didn’t Get the Job

Over the course of my career I have scheduled thousands of software engineering interviews with hundreds of hiring managers at a wide array of companies and organizations.  I have learned that although no two managers look for the exact same set of technical skills or behaviors, there are recognizable patterns in the feedback I receive when a candidate is not presented with a job offer.

Obviously, if you are unable to demonstrate the basic fundamental skills for a position (for our purposes, software engineering expertise), anything else that happens during an interview is irrelevant.  For that technical skills assessment, you are generally on your own, as recruiters should not provide candidates with specific technical questions that they will be asked in an interview.

It should be helpful for job seekers to know where others have stumbled in interviews where technical skill was not the sole or even primary reason provided for the candidate’s rejection.  The examples of feedback below are things I have heard repeatedly over the years, and tend to be the leading non-technical causes of failed interviews in the software industry (IMO).

Candidate has wide technical breadth but little depth – The ‘jack of all trades’ response is not uncommon, particularly for folks that have perhaps bounced from job to job a little too much.  Having experience working in diverse technical environments is almost always a positive, but only if you are there long enough to take some deeper skills and experience away with you.  Companies will seek depth in at least some subset of your overall skill set.

Candidate displayed a superiority complex or sense of entitlement – This seems most common when a candidate will subtly (or perhaps not so subtly) express that they may be unwilling to do any tasks aside from new development, such as code maintenance, or when a candidate confesses an interest in exclusively working with a certain subset of technologies.  Candidates that are perceived as team players may mention preferences, but will also be careful to acknowledge their willingness to perform any relevant tasks that need to be done.

Candidate showed a lack of passion – The lack of passion comment has various applications.  Sometimes the candidate is perceived as apathetic about an opportunity or uninterested in the hiring company, or often it is described as what seems to be an overall apathy for the engineering profession (that software is not what they want to be doing).  Regardless of the source of apathy, this perception is hard to overcome.  If a candidate has no passion for the business, the technology, or the people, chances are the interview is a waste of time.

Candidate talked more about the accomplishments of co-workers – This piece of feedback seems to be going viral lately.  Candidates apparently ramble on about other groups that built pieces of their software product, QA, the devops team’s role, and everyone else in the company, yet they fail to dig deep into what their own contribution was.  This signifies to interviewers that perhaps this candidate is either the least productive member of the team or is simply unable to describe their own duties.  Give credit where it is due to your peers, but be sure to focus on your own accomplishments first.

Candidate seems completely unaware of anything that happens beyond his/her desk – Repeatedly using answers such as “I don’t know who built that” or “I’m not sure how that worked” can be an indicator that the candidate is insulated in his/her role, or doesn’t have the curiosity to learn what others are doing in their company.  As most engineering groups tend towards heavy collaboration these days, this lack of information will be a red flag for potential new employers.

Candidate more focused on the tools/technology than on the profession – Although rare, this often troubles managers a great deal, and it’s often a symptom of the ‘fanboy’ complex.  I first experienced this phenomenon when EJB first arrived on the scene in the Java world, and many candidates only wanted to work for companies that were using EJB. When a technologist is more focused on becoming great at a specific tool than becoming a great overall engineer, companies may show some reluctance.  This is a trend that I expect could grow as the number of language/platform choices expands, and as fanatical response and the overall level of polarization of the tech community around certain technologies increases.

Candidate’s claimed/résumé experience ≠ candidate’s actual experience – Embellishing the résumé is nothing new.  A blatant lie on a résumé is obviously a serious no-no, but even some minor exaggerations or vague inaccuracies can come back and bite you.  The most common example is when a candidate includes technologies or buzzwords on a résumé that they know nothing about.  Including items in a skills matrix that are not representative of your current skill set is seen as dishonest by hiring managers.

Candidate’s experience is not ‘transferable’ – If your company is only using homegrown frameworks and proprietary software, or if you have worked in the same company for many years without any fundamental changes in the development environment, this could be you.  The interviewer in this case feels that you may be productive in your current environment, but when given a different set of tools, methodologies, and team members, the candidate may encounter too steep a learning curve.  This is often a response on candidates that have worked within development groups at very large companies for many years.

Give some thought to these before your next interview.

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+.