Monthly Archives: February 2013

The Stigma of Tech Certifications (and their real value)

Posted on by
7

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, keep an eye out for my book Job Tips For Geeks: The Job Search (mailing list for the release announcement and free chapter can be found here) and follow Job Tips For Geeks on Facebook, Twitter, or Google+.

About these ads

“I Dunno” – Recovering From a Botched Technical Interview Answer, Postmortem

Posted on by
1

A recent post on Stack Exchange’s Workplace forum posed a rather unique question and perhaps raised a few more.  The post asks if it is appropriate to follow-up with a correct response afterwards if you answered a technical interview question incorrectly (or responded with “I don’t know”).  As a recruiter of engineers, I’ve taken my share of calls from candidates upset about fumbling a tech question that they would have slam-dunked 99% of the time but froze in the moment,  only to have the correct answer come to them while driving home from the interview.  At the time of this writing, there are four answers listed and (in my opinion) at least a bit of poor advice for job seekers.

The posted question brings up a few topics for thought, which will also be detailed in (plug warning) my book.  First, we will cover this specific scenario and the best way to ‘recover’, as well as what is wrong with the answers provided.  Then we will dig a bit deeper into the “I don’t know” problem and reveal the motivations behind technical interview questions and why a simple “I don’t know” (which was recommended by one respondent) is almost never appropriate.

Recovery From A Botched Interview Question, Postmortem

The answer in the forum accepted as the best suggested that it was not recommended to send a correct response as it may make the candidate appear ‘obsessive’, and added that the answer could have been looked up after the fact.  Two distinct points were made, and both were (IMO) not helpful.

If the candidate sends a note resembling “I just HAD to get this off my chest, I’ve been losing SOOO much sleep about that answer I messed up“, then of course the obsessive label may be legitimately applied.  However, if the correct answer is provided tactfully using some careful language, the result should be more indicative of tangible interest in the job than an obsession to be correct.

The mention that the candidate could have researched the answer afterwards is probably irrelevant unless the question was a complete softball that any industry professional must know.  If the question was difficult or perhaps a complex programming exercise in an environment approximate to what the engineer would encounter in the real world, one would think that the test should be open book in order to simulate the office experience.

How To Make The Recovery

  1. Email the interviewer and lead with a standard thank you sentiment.
  2. If there were any legitimate mitigating circumstances that negatively affected your performance, it is relatively safe to mention them (with a slight risk that you are regarded as fragile or that life will impact your work).
  3. Write out the question as best you remember with a synopsis of the answer you provided.
  4. Provide the correct answer and dive a little deeper into your knowledge of the subject.  Be careful not to go too deep (which could risk the obsessive tag mentioned earlier).
  5. Close by reiterating your interest in the position and your willingness to be tested again with either another interview or some exercise (programming task, white board exercise, etc.) that will allow you to demonstrate your ability.

If code is appropriate as part of the answer, write it and send it.  Go slightly above and beyond in your answer if possible by pointing out some other relevant points during your explanation, such as any experiences during your career related to the question.  Results will vary.

Plain “I Dunno” Answers

One of the participants in the thread added

“…’I don’t know’ is a safe answer as many places use negative marking for wrong answers.”

Partial credit for that, but incomplete.  A simple “I don’t know” could possibly be indicated for a specific set of questions, but in general it is better to give a longer response to questions that you can’t solve.  What?  Questions that will typically get the dunno answer usually fall into three categories.

  1. Questions you find difficult, but at least somewhat within the scope of something you could/should know.
  2. Questions regarding incredibly minute and trivial details that you could possibly know, but that most candidates probably would not answer on-the-spot.
  3. Questions about a subject that you have absolutely no exposure to and couldn’t possibly be expected to know outright.

Motivations Behind The Three Types of Questions

Category 1 questions are fair and the only motivation is to discover what you know and what you don’t.  Nothing to see here, move along.

Category 2 questions are probably a mix of items that could conceivably fall into Category 1 or Category 3, depending on the level of the candidate being interviewed.

Category 3 questions along with some Category 2 crossovers are the ones that almost always have a hidden agenda, and it surprises me when I hear a candidate react surprised when being asked “How many gas stations are there in the US?“.

Category 2 and 3 questions typically are asked for one or more of three reasons.

  1. To measure your brainpower and memory (mostly Category 2) – Some employers do expect their staff to have an abundance of knowledge readily available without using outside materials.  With the vast amount of resources used by technologists today, most managers value this ability much less than in years past.  In certain cases, the interviewer really does want to know if you can answer the question asked.
  2. To observe you under duress (both Category 2 and 3) – It can be difficult to simulate various scenarios that happen on a day-to-day basis inside of any particular company.  By asking a difficult or even an impossible question, the employer can get some sense as to how you may function when required to quickly improvise a solution.  Will the candidate admit a lack of knowledge about a subject area or will he/she attempt to feign expertise to potentially appease the interviewer?
  3. To understand your resourcefulness and how you diagnose problems (mostly Category 3) – Questions with no widely known answer are a somewhat effective way to see how a candidate might approach and break down a future real-world problem, or where the candidate would go to find out.  An example would be Fermi problems, where it is expected that respondents will not have an answer in memory but should be able to provide some estimate by using other information that is more widely available.  “How many gas stations are there in the US?” is a fairly common example of a Fermi problem where an immediate numerical answer would be unexpected and defeat the purpose of the exercise.
Aside:  A fourth motivation increasingly cited by interviewees is to measure your subservience or your tolerance for and willingness to even try to answer such questions.  There is a large population that feel Fermi problems are useless in evaluating talent, but their value is not the point of this post. 

Better Alternatives to “I dunno”

A simple “I don’t know” is rarely appropriate.  Try one of these instead.

“I don’t know x, but I do know y” - This answer is appropriate for questions related to specific technology experience.  If you are asked if you have used MySQL, you might mention that you have not but you have used another RDBMS.  This lessens the impact of a straight ‘no’ answer, implying that any learning curve will be less severe.

“I don’t know x, but if you would like I can tell you how I would find out” – This answer allows you to demonstrate your resourcefulness and creativity in solving problems on the spot.  Managers should also value your modesty and the fact that you are not the type of professional that would rather claim expertise than admit not knowing.

If you found this post useful, keep an eye out for my book (mailing list for the release announcement can be found here) and follow Job Tips For Geeks on Facebook, Twitter, or Google+.