Why the Recruiter Didn’t Call You Back

Technology pros often express their venom for both the overly-aggressive spamming recruiter and the recruiter that doesn’t call back. However, the group getting inundated with inquiries and the group not getting a response are probably mutually exclusive. Recruiters provide both groups with a reason to hate the industry.

Whether it is a lack of response to an application to a job posting or the absence of feedback after an interview, job seekers regularly, publicly, and often rightfully voice their displeasure about being left in the dark. It seems like a fairly minor expectation to assume that a recruiter will have both the decency and the 30 seconds required to at least send a quick email to let an applicant know that the resume doesn’t show the desired skills, or to inform an interviewee that he/she was not selected for hire. Candidates who take the time to interview have a right to know if they were not chosen, and hopefully will be given at least some explanation. Yet, based on the volume of complaints, it seems few recruiters extend this minimal courtesy.

After 15 years in the business, I have come to learn that most candidates are grateful to get some feedback on their approach, résumé content/format, or post-interview performance tips. Delivering the bad news about a potentially life-changing job offer is not an enviable task, and I can understand why junior level recruiters might be less comfortable in those calls. Once a recruiter makes several notifications, he/she should hopefully learn that it is best to try and extract at least one lesson for the candidate to take away for next time. Being a recruiter can require equal parts salesman, psychologist, and career coach on any given day.

Keep in mind that the only true benefit a recruiter receives by making these notifications is goodwill and reputation points with candidates, and there is a slight ‘cost’ with taking the time to make notifications (the opportunity cost of the time spent on a notification vs calling the next potential candidate). I have found that the goodwill earned is well worth the small time investment, and providing honest feedback will differentiate how candidates will rate their recruiter experience.

So why are recruiters not responding to your applications or resume, and why do they not provide feedback after interviews?

No response for an application or resume submission

Your approach made you seem like an arrogant jerk – Most applicants are professional and mention their qualifications or skills with some level of humility and maturity. Confidence is a rare asset in the software business, but recruiters are much less apt to respond to egomaniacs and candidates who are disrespectful. There will be other candidates that are easier to work with, so recruiters won’t waste too much time with candidates that seem immature.

You were grossly unqualified – Sadly, a down overall economy produces an extraordinarily high number of applicants that do not even remotely resemble the required or desired qualifications. Yes, recruiters get pummeled with unwanted email sometimes too. I doubt that a significant percentage of the recruiting industry’s harshest critics fall into this unqualified category, but there must be a few. Although I always try to contact all partially qualified applicants, anyone with no relevant professional or academic background will not get a reply.

You appeared qualified, but some detail makes your hire unlikely – Agency recruiting, and particularly contingency recruiting, is all about playing the odds. If there are a number of candidates for a position, some will stand out as the most likely to be hired while other applications may contain strong indicators of a much lower hiring possibility. Any perceived obstacles to hire or details that would make a hire less likely, such as unreasonable salary expectations, unclear work authorization or employment history, or a candidate’s mention of multiple current job offers could prevent a recruiter from responding. Unfortunately, the most qualified candidate can also be the least likely hire based on these external forces. I suspect many of those that criticize recruiters fall into this category, where the candidate can cite impressive credentials for the position but has some Achilles Heel in their candidacy that they do not see as an issue.

Location – If the recruiter’s client is in the middle of nowhere and an applicant claims to be open to opportunities worldwide, the odds are not very good that he/she will choose middle of nowhere over somewhere a bit more interesting. The recruiter is not only competing with many companies, but many more attractive locations. A candidate’s professed willingness to move does not change this view, as the likelihood of a candidate’s move is typically low if any local employment options are available. Likewise, if the candidate’s address indicates a long commute, recruiters may be less apt to respond. Candidates are usually very willing to relocate for very unique once-in-a-lifetime opportunities, but most jobs don’t fall into that category.

The volume of applicants made notification impossible – Internal corporate recruiters are probably more likely to get an overwhelming response than their agency counterparts, but a large applicant pool may result in some submissions not even being reviewed. If no human even sees the application, it is unlikely you will get a personal response.

Your application contained a sloppy introduction or résumé – When an applicant cuts and pastes their introduction (today’s cover letter) and neglects to include the proper company name, it lets the recruiter know that this candidate is probably very active and at least slightly careless. Multiple spelling and grammatical errors will make recruiters question why they should invest time with a candidate who invested so little time and effort in their application. Getting a second set of eyes (such as a friend or a résumé review service) may help find the issue.

The job has been filled – One would hope a recruiter could quickly inform a job seeker that a position is no longer available, but if there are many applicants the process could become time consuming.

No response after an interview

The recruiter has no news to give you – Just as recruiters may feel they have little to gain by further contact with rejected candidates, hiring managers may decide their time is better spent on tasks other than explaining to recruiters why a candidate was not chosen. It is also not uncommon for recruiters to get radio silence from the companies they represent in specific situations. Managers and execs may be stumped on how (or if) to inform a recruiter about a potential hiring freeze, a funding issue, or management shakeups that could negatively impact their ability to get new hires on board. If the post-interview decision is a definite ‘no’, recruiters should find out quickly and be willing to share that news with candidates, but based on anecdotes it seems many recruiters completely ignore requests for feedback from rejected candidates.

The recruiter is waiting for the right moment (that may never come) – If an agency recruiter has multiple candidates interviewing for one position, it is in the recruiter’s best interest to keep the client’s top choices ‘warm’ for as long as possible, or at least until an offer is accepted. A recruiter will not want to tell you “Hey, you are actually my client’s third choice for the role, but our first choice is dragging her feet on accepting the offer, so just hang tight.” Hopefully your recruiter will provide at least some degree of transparency and insight, but don’t expect that from most.

Your poor interview performance damaged the recruiter’s relationship with the client company – This is thankfully quite rare, but unprofessional behavior in an interview will hurt the recruiter’s reputation and make a call from the recruiter unlikely (and probably unnecessary).

You didn’t follow-up or ask for feedback – Do not expect that a recruiter will contact you independently and unsolicited with interview feedback. Recruiters with a booming business may be relying on either your request for feedback or the incoming call/email from the client as a  workflow prompt to notify you (I rely on this prompt often), so be sure to contact the recruiter after the interview to assess how you did and to express interest in learning results. It looks professional and shows both initiative and interest when candidates contact recruiters after an interview to debrief, so make that a habit anyway.

If you are not hearing back from recruiters, take a look at your submissions to see if you may fall into one or more of these categories.  Continue to ask for feedback after interviews, as you are entitled to a timely answer.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. Follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Why You Scared Off the Ninja

The saying goes you never get a second chance to make a first impression, and it is well-documented that this is never more true than in the effort to hire great technical talent.   Complaints about the interview practices of some companies and anecdotes about how recruiters make foolish approaches are quite popular reads lately.  As someone in the hiring business, the criticism can be painful to hear, but when justified with evidence of ineptitude it is certainly understandable.

Demand for elite developers is so competitive (and talent is so hyperaware of this fact) that both recruiters and company representatives rarely get a second chance if their first contact or the ensuing hiring process is received negatively.  The best case scenario for the headhunter approach gone awry is to have the attempt ignored, and the worst case is public shaming by a tech celebrity.  It is particularly painful when a recruiter or company turns off an attractive candidate (whether through an email or hiring process) that possesses a very rare skill or experience, or worse yet a high degree of both skill and community influence.

Accomplished technologists can be brutally unforgiving to even the slightest perceived breaches by recruiters, and the level of outrage is often congruent to the programmer’s self-perceived industry status.  This is most likely a function of the sheer volume of noise received by high-end talent with status, and the frustration that noise can cause.  Junior level candidates tend to appreciate any type of attention, while the more senior or recognizable professionals seem to rarely find any recruiter contact worthy of a positive response.  Beyond just the recruiter problem, the interview process and practices used by companies cause very strong negative reactions by many in the industry.  When offended, those that feel they’ve earned ninja status (used ironically, please stop saying ninja) seem most likely to wield the sword.

Applicants that appear average will probably be treated that way.  But when a recruiter or a company hiring manager discover what could be that once-in-a-lifetime potential hire, or even a candidate that would seem to fall into the top 10%,  they must be flexible enough to change their standard hiring protocol while exercising an abundance of both caution and tact at every contact.  Many companies homogenize the process for all candidates to their own detriment, and when dealing with in-demand talent that typically comes with a bit of ego thrown in for good measure, treating the ninja like a common commodity is a critical error.

What are the most obvious ways that recruiters and companies turn off the most qualified candidates during first contact and the subsequent hiring process?

First, mistakes in the approach:

  • Impersonal contact and lack of research – The link earlier in the article referencing a recruiter approaching DHH for a Rails role happened more than once, and notably a recruiter for Groupon made the same mistake.  These examples are well beyond a typical recruiter infraction, as most Rails engineers are not DHH and most recruiters are not this lazy and clueless.  The ‘Let’s connect on LinkedIn‘ invite without any point of reference also applies to this category.  Recruiters are given little leeway and must conduct at least minimal research before contact, and then must choose their words wisely.  Once you know a bit about the candidate, tell him/her why you felt it was appropriate to reach out.  Be specific.
  • Referral requests – Recruiters are trained from birth to end every communication with ‘Do you know anyone else who might be qualified?‘, and they are often asking complete strangers.  Technologists at the lower levels look at this as an opportunity to help a colleague find work (and maybe even get a referral bonus), while ninjas who make plenty of money have no interest in helping most recruiters and view the request itself as a breach.  Don’t ask top people for referrals until you have at least developed some form of relationship, and even then only with caution.
  • Technical ignorance or irrelevance – Recruiters who confuse Java for JavaScript get crucified, and will be forever remembered as being ‘that guy/gal‘.  Whether you are a non-technical CEO or a recruiter, be sure that your communication is technically sound.
  • Approached by the wrong person – When courting high-end talent (particularly for a small company), it is wise to get an internal talent or leader involved as early as possible.  Your junior recruiter that started last week should be kept in check until he/she knows how to market the company, and that marketing skill should be honed in conversations with junior candidates that generally require a lower degree of difficulty and thus reduced potential risk.  Startup CEO, CTO or Development Managers should be willing to send a quick note from their own email in order to get a ninja’s attention early in the process.  Recruiters need to know when it may be appropriate to step aside for first contact.
  • Lack of details – Vague, boilerplate company descriptions rarely get the attention of top talent, and may turn off the candidate completely without ever getting the chance to show them more.  Provide as much detail as reasonably possible to demonstrate that you have no intention of wasting their time.

And in the hiring process:

  • The HR phone screen – I cringe when a client responds to my submittal of a top talent with ‘This one looks great!  We’ll have Joe from HR do a quick phone screen‘.  NO!  Some recruiters vet engineers better than others, but if a candidate looks stronger on paper than most you see, forgo the pleasantries and get down to business.  
  • Standardized tests – These are fairly rare with startups and small companies and for midsize and large companies these tests serve as just another way to scare off top talent.  Tests for IQ, personality types, and even third-party technical tests tend to give the wrong impression to talent.  Development managers at companies that employ standardized tests could be frustrated with the skill level of their applicants, and should want to promote policy change or at least allow for exceptions.
  • Disorganized interview process and inflexibility – Missed phone calls and making candidates languish in a lobby while waiting for an interviewer is inexcusable when wooing a strong candidate, and tech talent may feel these indiscretions could reflect on your work environment.  Even if you traditionally like to keep interviews very loose and informal, use at least a small amount of choreography when entertaining the ninja to keep their engagement level high.  Accommodating a request for a call either before or after hours could also be the difference when interviewing candidates that are unable to use business hours for meetings.
  • Lowball offers and negotiation games – After investing a fair amount of time building mutual trust and admiration during the interview process, the last thing you should do is play games when it comes to sealing the deal.  The long term value of the hire should not be risked for a few thousand dollars saved through negotiations.

Conclusion:  Companies and recruiters need to do a better job of customizing their approach and treatment of top technical talent.  While technical recruiting is generally considered a numbers game focused on high-volume, the courting of the most elite developers requires a completely different and more time consuming campaign to be implemented by your most competent resources.

Discuss on Hacker News.

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

 

Why You Make Less Money

Have you ever had a conversation with a fellow technologist that you felt wasn’t quite at your skill level, and at some point you discovered that she/he makes $20,000 more than you do? $50,000? As someone who has had a great deal of access to the salary and compensation details for thousands of software engineers over many years, I can report that there can be significant variation in salary between technologists with almost indistinguishable skills and qualifications. This may not be news to some, but the reasons might not be obvious to professionals in the field, particularly if someone has only been exposed to a small subset of industries or companies. Many of the explanations are somewhat unique to this industry or just more prevalent in the software world. Regardless of whether or not money is a primary motivator in your career, it is still useful to understand why others may be earning more (and what you can do to join them).

money

What are some possible explanations as to why someone equally or less-qualified makes more money?

  • Public image and intangibles – An average technologist may be compensated above more productive co-workers if there is some advantage that the company sees in that person’s employment. Community influencers such as open source project leads, conference organizers, meetup/user group leaders, speakers, and authors may all fall into this category. In business this is the concept of goodwill, where an asset has a higher value due to an intangible. Google’s high profile hires of James Gosling and Ray Kurzweil and Dropbox’s hiring of Guido van Rossum came with a certain level of goodwill bundled. On a local level, a company may believe that hiring the local Python group leader could make hiring Python pros easier and less expensive, which may justify a higher salary independent of the developer’s quality or production. Regulars on the conference speaker circuit can ask for a premium simply based on the PR provided every time their bio is published on an event website.
  • Negotiations and raises – Software professionals are often stereotyped as unskilled negotiators or uncomfortable in situations where they are seeking additional salary or perks. This first requires the courage to ask for more (in the form of a raise, or a higher starting salary for a new hire), and then the knowledge and skill to ask effectively. As a recruiter I typically handle salary discussions for my candidates, and I know that for most engineers that particular service is highly valued. A difference of even a few thousand dollars as a starting salary has the potential to dramatically alter your lifelong earnings. Remember that this number is regularly used as the basis for bonuses and raises, and most importantly it usually has some bearing on salary at your next job. Think of starting salary as the principal level for compound interest.
  • Market knowledge – Remember that conversation alluded to in the first line of this article? If you had three or four similar interactions within a year you may have noticed a pattern and it seems your friends might know something that you don’t. Many engineers aren’t even aware that they are paid below market rate because they just trust that they are fairly compensated and have no reason to investigate further. I have had conversations with experienced and well-qualified developers who are floored when they learn that they have been paid 20-30% below market rate for many years. Know what you are worth.
  • Self-promotion – Even if the high skill level is there, many technologists are either unable to properly express their own expertise and accomplishments or feel awkward tooting their own horn. The ability to market yourself often starts with a powerful résumé and a confident interview presence when trying to maximize salary at a new job. When staying with your employer, self-promotion requires the savvy to make your accomplishments known without looking like a braggart.
  • Consulting differential (both independent and staff) – Developers that are independent consultants charge clients a premium to account for expected frictional unemployment and to address the fact that a temporary employer typically will not make any real investment in the career of a temporary employee. It is rare to see independent consultants sent to conferences or trainings by their clients, and independents do not always get the most desired projects. Independents are also on the hook for their own benefits, retirement savings, etc. Salaried employees of consulting firms are also often paid above other similarly qualified professionals, as it is easy to measure a consultant’s contribution to the firm’s net revenues based on bill rates, billable hours, and their compensation package. There may also be regular travel or variable commute that tends to inflate salaries. Salaried consultants who know their bill rate, utilization, and total compensation package have a distinct advantage when trying to justify their value (and salary) to an organization.
  • Profit vs Cost Centers – Similar to consulting, companies that use technology as their main source of revenue tend to pay higher than firms where it is considered a cost center. Building software products that will be sold usually results in higher salaries than building systems for internal use. There are some major exceptions, but those tend to be specialized to industries where technology utilization is a key differentiator in the performance of the firm’s primary business interests (trading systems come to mind).
  • Rare skill – The premium paid for even one single rare skill among many common skills can be substantial. When a new language, framework, product, or platform is hyped as the ‘next big thing’ and adoption begins, even junior level talent with that skill can earn above more generally qualified individuals. This is simple supply and demand for a scarce resource. In years past the premium was greater for rare skills, as companies today seem more confident in their ability to train an existing resource than to hire someone new and much more expensive.
  • Time expectations – Some employers pay a premium because of the high expectations they place on hires. Unless you have some vested interest in the success of the company (stock, profit sharing), a 70 hour work week is probably unacceptable unless you are being compensated accordingly for that level of commitment. Positions that require employees to be on-call are also commonly paid above market. Work/life balance has a price, and some are willing to sell.
  • Long tenures at big companies – Many large organizations have systems of pre-determined fixed raises and regular bonus or vacation increases for certain milestones. The hire’s value to the company increases over time as they become highly specialized in a certain environment, and the concept of golden handcuffs is born. The downside of this for the employee is that it often leads to compensation well above true market rates, which makes it nearly impossible to find new employment at a lateral compensation rate.  When these types are victims of a layoff, the result is brutal.
  • Location – No explanation needed, I hope.

Conversely, here are a couple explanations as to why someone might make less.

  • Startups – Startups often exchange equity for cash compensation. These employees are often earning less for the opportunity to receive a big payout. Candidates negotiating with startups must place their own figures on the value of the equity, which is a difficult task. Startup compensation today is much more competitive with large companies than it once was, at least in my experience.
  • Benefits, work/life balance – Since most professionals refer to compensation in terms of cash paid, employees that receive significant value in their benefits and perks may be mistakenly considered underpaid. Generous paid time-off, tuition reimbursement, and childcare can be major expenses that are covered by some employers and often not included in discussions. 
  • Experience value – The opportunity to work for certain companies, to learn a valuable skill, or to be on a highly-regarded team is a reason that many engineers may sacrifice some salary, and shops that provide that ability may leverage that during negotiations. Many developers are entirely comfortable with accepting compensation below market as a trade-off for the positive effect on their career and marketability.

Conclusion:

If the topic of compensation comes up with other technologists, consider that there may be several explanations and hidden factors for the disparity between numbers. When exploring new opportunities, keep in mind that the amount of your offer is not solely based on your skill level relative to others or the value the company feels you will provide. In situations where several of these explanations apply simultaneously, the numbers become even more skewed.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.   You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Enterprisey Developers, Acronyms, and Discrimination

Java eyechart

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

A Guide To Lifelong Employability For Tech Pros

There seem to be a rash of “Am I Unemployable?” posts and comments lately on sites that I frequent, and after reading details the answer in my head is usually “Not quite, but sounds like you are getting there“.  In other words, someone will hire you for something, but many who assess themselves as unemployable are going to feel both underpaid and undervalued when they finally find work.

How does a technology professional go from being consistently and happily employed for a number of years, only to find himself/herself suddenly unemployable?  Better yet, what are the key differences between someone who spends months on a job search and someone who can unexpectedly lose a job Friday and start a new one the following Monday?

How do certain people get job offers without having to even interview?

It isn’t simply about skill, although that is obviously a factor.  Even pros that are highly productive and well-regarded in some circles can encounter challenges in today’s hiring environment.  It’s about creating relationships and developing your reputation/visibility.

In my experience, pros that are always in demand and rarely (if ever) unemployed seem to share certain sets of habits, and while some of the material below is Career 101 there are some that you probably never considered.  As a longtime user group leader and recruiter of software engineers for the past 15 years, I see this first hand on a daily basis.  Let’s start with the habits that are the least obvious and progress to some that are more widely practiced.

Interview – How often do you interview when you are not actively looking for a job?  For most the answer is never, and I’d encourage you to take at least a couple interviews a year.  Going on the occasional interview can serve two purposes.  First, they are a way to make new contacts and keep your name in the minds of potential employers, with the added benefit that these same interviewers may be working at new companies in a year or two.  One interview could lead to an ‘in’ with four or five companies down the road.  Second, it is the only way to keep interview skills sharp.  Interview practice is best done live without a net, and failing the audition for a job you truly wanted is often attributed to rusty interview chops.  Even a simple informational interview request (made by you) is an effective and creative way to make first contact with a potential employer.

Know when to leave your job – Without question, the group having the toughest time finding work are unemployed with say ten+ years at the same company, and a close second would be employed workers with that same ten year tenure.  For anyone about to scream ‘ageism‘ please hold that thought, as older technologists that have made smart moves do not typically have this issue.  I would add that older engineers who possess the habits outlined here are the group being hired without interviews.  There are always exceptions, but tech pros can stagnate quicker than those in other industries due to the speed of change in technology.

The definition of job hopping has morphed over the past fifteen years, and it is now understood that semi-regular movement is expected and accepted.  Where other industries may interpret multiple employers as a symptom of disloyalty, in the software world a pattern of positive (moving to something better) job changes is often more indicative of a highly desirable candidate.  Conversely, someone who has remained at a company for many years may be viewed by employers as loyal to a fault and potentially unambitious.  If this person has solid skills, why has no company picked him/her up yet?  Changing jobs before stagnating is critical to overall employability, and how quickly you stagnate will vary based primarily on your employer’s choices, your own ability to recognize that stagnation is happening, and your desire to not let it happen.

Make ‘future marketability’ a primary criterion when choosing jobs or projects – Carefully consider how a new position will impact your ability to find work later in your career and use that as one of your key incentives when evaluating opportunities.  Details about your roles and responsibilities as well as the company’s technology choices and reputation in the industry are all potential factors.  Does the company tend to use proprietary languages and frameworks that will not be useful later in your career?  How will this look on my résumé?  Many candidates today are choosing jobs or projects based on an opportunity to learn a new skill, and for this they are usually willing to sacrifice some other criteria.

Reach out to others in the community (not coworkers) – How many times have you sent an unsolicited email to someone in your field that you don’t know?  “Congrats on your new release, product looks great!” or “Saw that you open sourced, look forward to checking it out” as an email or a tweet is an effective way to create a positive impression with a person or organization.  Twitter is great as a public acknowledgment tool, and the character limit can actually be advantageous (no babbling).  If you stumble on an article about a local company doing something interesting, there is much to be gained by a 140 character pat on the back. This is essentially networking without the investment of time.

Lunch with others (again, not coworkers) – You have to eat lunch anyway, so how about inviting someone you don’t know that well to lunch?  Perhaps include a few people that share some common technology interest and turn it into a small roundtable discussion.  Meeting with other tech pros outside an interview or meetup environment enables everyone to let their guard down, which leads to honest discussions about the experience of working at a company that you may consider in the future.  It’s also an opportunity to learn about what technologies and tools are being used by other local shops.

Public speaking – This is an effective way to get attention as an authority in a subject matter, even on a local level.  Preparing a presentation can be time consuming, but generally a wise investment.  Even speaking to a somewhat small group once a year can help build your reputation.

Attend a conference or group meeting – This isn’t to be confused with going to every single meeting for every group in your area.  Even getting to an event quarterly keeps you on the radar of others.  Make an appearance just to show your face and say hi to a few people.

Reading and writing about technology – One could debate whether reading or writing has more value, but some combination of the two is likely the best formula.  If you don’t know what to read, follow some peers and a few respected pros from your field on Twitter, LinkedIn or Google+, and make a point to read at least a few hours a week.  As for writing, even just making comments and discussing articles has some value, with perhaps more value (for job hunting purposes) in places like Stack Overflow or Hacker News where your comments are scored and can be quantified.  Creating your own body of written work should improve your understanding of a topic, demonstrate your ability to articulate that topic, and heighten your standing within the community.

Build a personal code repo – Many in the industry balk at this due to the time required, but having some code portfolio seems to be on the rise as an expectation hiring firms have for many senior level candidates.  If the code you wrote at work is not available for demonstration during interviews, working on a personal project is more critical.

Conclusion
At first glance, this list may appear overwhelming, and I’m certain some readers will point to time constraints and the fact that they are working 60 hour weeks already.  Some of these recommendations take considerable time, but at least a few require very little commitment.  Employ a few of these tactics and hopefully you will never suffer through a prolonged job search again.

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

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

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

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, you may find my ebook Job Tips For GEEKS: The Job Search helpful.  You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.