Category Archives: Uncategorized

The Dangers of Book Learnin’

Posted on by
8

Today’s software professional is under constant pressure to maintain a high skill level with an ever-changing palette of languages and tools, and the fear of potentially becoming somewhat irrelevant can be daunting.  Those that do not keep up with industry trends and movements are at some risk of losing marketability, but even those that do closely follow tech news need to make choices on which skills to pursue (time permitting), which to ignore, and what methods to use in the pursuit.

The first instinct to learn something new would naturally be to find some good resources online and perhaps acquire a couple books.  You can find presentation slides and videos, articles and blog posts, and even attend live meetups or conferences in addition to your reading.  Over the years I have seen hundreds of engineers (accomplished and junior) that invest an extraordinary amount of time to reading about different languages and tools, many of which they may never even get to use professionally.  Some even read with the goal of some certification, which they feel will demonstrate mastery of a new skill.

I have also come to know another group of technologists who are inclined to learning in a different manner.  This group starts off with some amount of reading as well, which might be limited to the product documentation and a quick tutorial, and then immediately transition into a more hands-on approach.  Once they have a basic understanding of a language or tool, they actually try to build something.

As a recruiter, I have had candidates do a quick study on a new language (used by the potential employer) and throw together some common interview coding problem or even a simple app in a GitHub repo.  As a Java user group leader, I have had presenters build small apps to help familiarize themselves with a framework they will be describing to others, and then demo the app live.  The offer to present could be “I think X looks pretty cool.  I’ve read about it but haven’t used it yet, but I’ll build something and present on my experience with X.  I can be ready in a month.”

It appears that many technologists are very comfortable with the reading portion of learning, but focus there too long and never get around to creating something.  This seems to be common for some college graduates, who obtain a wealth of classroom experience but very little time spent doing.  Even if what you build is entirely useless to the world, your creation has value.  Learning by doing is not a new concept, so the educational value is obvious.  What other value is there?

Marketability and interview advantage
I was prompted to write this post about book learning when I was reviewing my recruiting placements for the past year.  The developers I’ve helped into new jobs over the past year have (with few exceptions) had one thing in common – a portfolio of products and code.  This was rarely the case ten or even five years go, but today it has become the norm.  The Android and iOS developers I’ve placed had at least one app available for download.  Web developers were able to demonstrate sites with accompanying code samples.  Even the programmers who focused on back end had something to show in interviews.

The biggest example of the value of ‘learning by doing’ and a portfolio is probably exemplified by the mobile app space.  It’s hard to sell yourself as a mobile developer if you don’t have any mobile app to show, and “Do you have an app?” is probably the first question mobile devs will be asked.  Software developers in most other areas are usually not subject to or judged on this direct a question.  Put simply, mobile developers know that in most cases having an available app makes you more marketable.

Programmers who work in more secure environments, such as those who build defense systems or financial software, often find it impossible to produce a work sample when seeking new employment.  Without being able to show your past work and with no personal projects, these candidates are much more liable to be subjected to a language interrogation and the game show style of interviews that many job seekers dread.  Marketability may be more tied to experience and somewhat arbitrary measurements of skill instead of demonstrable accomplishment for these candidates.

Interview advantage
Having a portfolio gives an interviewee a distinct advantage, in that the interviewee has at least some control over the topics that will arise.  Walk into an interview empty-handed and the possibilities for question topics are endless, and chances are you won’t have endless answers.  If a candidate brings a work sample to an interview, it will almost certainly be included in the discussion, and one would hope that the code’s author should fare better on questions regarding that sample than on questions on random topics.  Even average developers should see performance improvement in interviews when the topic is their own code.

tl;dr
Read enough to get going, then build something.  Don’t worry about whether your something is going to change the world.  Save what you build, and occasionally look back and improve upon it.  Bring what you build to interviews, and practice talking about your creations.

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

About these ads

Indicators of Talent (and Heuristics) for Software Engineers

Posted on by
6

A recent Hacker News post by a man named Andrew was voted to the front page and received over 50 comments (as of my post).  The post was called Ask HN:  Would you hire me?, and Andrew specified that he was talking about a junior level position.

He provided the following details about himself:

  • 28 years old with a Finance Degree from a non-Ivy league school
  • Spent the last two years living overseas teaching English and learning to code
  • Fairly well versed in html, css, javascript, and PHP

He also included links to his:

  • GitHub – handful of repos, 7 months as a member, pretty active over the last quarter
  • Stack Overflow profile – 521 reputation, top 37% this quarter, 16 badges
  • Blog – Attractive UI, 7 overall posts (a few with some code), with the highlight being details of a Chrome extension he built and demonstrates in a video

Andrew received a fair amount of positive feedback, and not one single poster gave a ‘you are not hirable‘ response.  No CS degree, no professional experience, yet a highly technical audience were either mostly positive and at worst neutral on hiring (considering is more accurate) this potential applicant.  Only a couple responders mentioned looking at the one project he listed, and none referenced the quality of his code samples on his blog or GitHub, so we might assume that no one even bothered to look at his code.  Interesting.

Part of the explanation for the positive response is undoubtedly the makeup of the Hacker News crowd, which does not include a large contingent of HR reps from large companies who control a great deal of the hiring decisions.  Place this resume and story on Monster or Dice, and I expect that Andrew would receive responses from less than a quarter of his viewers.  Possibly less than a tenth.

I admit, if I were to see this candidate’s resume (assuming it reflected the details he put on HN), I would absolutely want to speak to him.  The clients I represent, which are mostly startup and early stage software companies, are more representative of the HN crowd (at least in terms of evaluating engineers) than most larger companies.  And even if I did not have a great opportunity for him today, I would think that a few years down the road he will be someone that I’d want to represent.

What is it about this candidate with no experience and no highly relevant education that gets our attention?  Of the details we have about Andrew, how many could have impacted my decision to speak to him?

When evaluating talent and the decision whether or not to interview a candidate for a software job, I must rely on several attributes that have historically been attached to quality talent that were successful in receiving job offers from my clients.

Let’s break it down.

28 years old with a Finance Degree from a non-Ivy league school - Most readers, including myself, probably didn’t give this any thought.  His degree in finance should indicate some math background, and if he had listed his specific school that would have had an impact.  Although most might be reluctant to mention it, the age demographic is probably a positive based on the industry, as he obviously has some life experience and maturity but will not fall prey to any old dog/new tricks bias.

Spent the last two years living overseas teaching English and learning to code – Teaching any subject to any students is valuable experience for almost any profession, and should indicate some level of communication skills.  The international aspect adds a bit more interesting background than if he were teaching domestically.  Some who chose to speak to Andrew may have been strongly influenced by the oversas aspect, as this could also show some willingness to face risk and change.

Fairly well versed in html, css, javascript, and PHP.  Just getting started with Ruby - His claim of being ‘well versed’ is only a self-assessment, but that could be at least somewhat validated (or invalidated) by anyone taking a look at his blog’s source or GitHub account.  This at least indicates that he is learning technologies that will give him some marketability based on demand for these skills.  We may question Andrew’s choices if he were learning a less popular skill.

GitHub, Stack Overflow, and Blog - For those that make decisions about technical talent, the fact that Andrew has both a GitHub and Stack Overflow account is probably more of an indicator of possible talent than what is actually in the accounts.  Most candidates in my experience don’t have a GitHub/Bitbucket or SO account, but those who do have accounts are historically more successful with my clients than those who don’t.  The attractive blog and few technical posts are yet another indicator, showing some passion as well as the ability to articulate his ideas in writing.

What other details may have led to the decision of HN readers or people like me who would at least want to speak to Andrew?

He reads Hacker News – Even if he isn’t a senior developer, he at least appears to have spent some time in one community where they frequent.

He comes across as modest and doesn’t appear to feel entitled - You don’t see anywhere in Andrew’s post a reference to how awesome he is or how he is ‘kicking CSS’s ass on a daily basis’.  His responses to feedback are very positive, grateful, and polite.  The choice of ‘well versed’ over some other terms that may be linked to overconfidence was wise.  Andrew also will not be accused of sounding entitled to a great dev job, and on the contrary he comes across as someone who knows he has to earn it.  Perhaps that is a function of his lack of a CS degree, but either way he appears to be taking the right approach.

He’s already creating product – Although he is only early on in his tech studies, Andrew has a product on the market that you can find in the Chrome Web Store that you can download.  There are developers with 20 years of experience that haven’t built any of their own tools or products yet, but this guy is two years in and has that mindset.  Some may question how great (or even good) a product someone at this level of experience could build, but the desire to produce and distribute a tool is something that perhaps can’t be taught.

Note:  Other indicators I use regularly include:

  • Past employers – Some companies frankly have a higher standard of hiring
  • Technical hobbies – Arduino, build robots, or create things at home
  • Speaking or writing – Presentations and publications are usually strong indicators
  • Tool choice – What blogging platform or operating system you run at home
  • User group and meetup – Shows interest and passion

Conclusion:  Hiring managers and recruiters are making quick decisions to interview and consider candidates, and as demonstrated by this HN post it seems that there are several recognized indicators of possible talent.  For job seekers, you may want to display links to your accounts prominently, and highlight details such as independent product development.

Of course, these indicators are not perfect.  I, too, have a GitHub and Stack Overflow account and a blog that covers technology (and I even run one of the best Java Users’ Groups in the world) – but I don’t write code.  Readers of HN should not hire me.

Discuss here or on Hacker News.

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

Why You Scared Off the Ninja

Posted on by
1

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

 

Enterprisey Developers, Acronyms, and Discrimination

Posted on by
6

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

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

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

A Quick Thanks to DZone

Posted on by
Reply
Image

Bodhi the dog and his owner show off DZone swag

I just wanted to say a quick thanks here to DZone for being so generous in sending a swag package to me and many of their other authors for contributions over the past year.  The bag included a DZone mug, a flash drive courtesy of Tizen, a data nerd drink cozy from New Relic, two of DZone’s famous Refcardz, fancy black t-shirt, sticky notepad, sticker, a set of “Inter-Cubicle Ballistic Missiles” (think mini foam darts for shooting at friends, enemies, QA testers and project managers) and a substantial Manning Early Access Program discount code!

It feels good to be appreciated.

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

Posted on by
2

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.

 

How to Hire Geeks, Brand Your Shop, and Beat the “Talent Shortage”

Posted on by
1

As a recruiter of software engineers, I hear every day how difficult it is for software companies to find technical talent.  If hiring engineers was easy, I wouldn’t be in business.  Using a recruiter is one way to have qualified potential employees neatly packaged and delivered, but there are several other strategies that forward-thinking firms can implement to differentiate themselves from their competitors who are just posting ads to the same old places and hitting up the friends and family networks.  Your company probably spends significant amounts of money to advertise your product and brand, but very little attention is paid to promoting the company’s identity as a good employer for engineers.  These strategies can take a bit of time and effort, but the rewards are stronger talent at a lesser expense.

Here are a handful of ways to make your company more attractive to new engineering hires.

Creative ads, inviting job descriptions, unique process

I have both reviewed and written more job descriptions for software engineering jobs than I care to mention, and it seems that well over 90% of the ads out there consist of the same trite words and phrases mashed up in different ways.  More importantly, it is incredibly rare to see ads that ask the reader to apply.  You will see ads that specify who should not apply (“must have x years of experience with ______“), but how often do you see an ad actually encouraging an applicant to “check us out”?  Request your reader to act and apply, particularly if your ad is placed in a location where qualified candidates are more likely to be.

Making the application process itself more interesting is another way to set yourself apart.  I don’t know anything about Parse, but I know they allow engineers to apply via API.  Asking an engineer to fill out an online application that takes ten minutes is an annoying barrier to applying, while adding a small element to the hiring process that engineers view as a minor challenge is a potential draw.  If you are going to argue that the application process is a test of an applicant’s commitment and interest, I will counter that a better measure of interest is to have engineers solve a small technical problem to apply (see API example above).

Engineering blogs

Geeks like reading about cool stuff that other geeks are doing.  How often do you see links publicized from the Twitter engineering blog, Facebook’s engineering page, or Netflix’s blog.  Are you sick of seeing the phrase “____ is a GitHubber!“?  Maybe your company isn’t solving the types of problems that these firms are, but that doesn’t mean the problems you are solving won’t be interesting to a specific audience.  Smaller shops that post even once or twice a month about a technical challenge, decisions being made, or new additions will draw some readers and potential hires.  Comments on your engineering blog are a signal of potential employment interest.

Open source projects and GitHub/Bitbucket public repos

If your company has developed something internally that could have some utility to other developers, making it open source can score your firm some credibility and visibility with the community.  Exposing well-written code shows off your team’s expertise and making it freely available to others builds goodwill.  Those interactions with developers that contribute to your project or use the code are a good way to start a recruiting dialogue.

Community involvement/outreach

Sponsoring and/or presenting at meetups, conferences, and users’ groups is probably the most targeted advertising you can do to promote your company as an attractive employer of engineers.  In theory, money spent on sponsorships could be much more effective than job ads on general employment sites.   Unfortunately, many companies spend the money but end up making a negative impression by trying to turn a meeting into their own career fair.  As someone who has run a users’ group for almost 13 years, it appears that the most effective way to attract potential hires in these forums is to have a couple of your best engineers present and demonstrate how they solved a challenging technical problem.  If you can get the audience to leave the session thinking “I’d love to work with them“, you will get some new applicants.

“Courting” during the hiring process

What is your typical hiring process?  If you are like most of the companies I’ve worked with over the past 15 years, the process consists of a phone screen and one or two face-to-face interviews (and sometimes a test).  When your process is exactly the same as that of your competitors, what does it say about your company?  Nothing.  Mix it up a little by initiating contact with an offsite coffee or lunch, especially if the candidate appears to be very strong and in demand.

Always be interviewing

If your company’s five best engineers resigned tomorrow, who would you try to hire?  I expect that most simply don’t know.  They say timing is everything in hiring (and everything else).  However, the main reason timing is such a factor is that most companies are only willing to interview candidates when they have a well-defined open position.  Timing is indeed everything when the hiring window is only fully open during short instances and cycles.

I am constantly trying to encourage my clients to always keep an open ear to new hires, and to be willing to interview candidates even when there is not a budgeted position currently open.  It is probably important to tell candidates when there is not a current opening, but many will still want to take an informational or informal interview.  This gives a firm the opportunity to develop a wish list of hires for when a vacancy arises.  During times where an open job is not immediately available a company may raise the bar as to who is invited in, but interviewing exceptional candidates as they appear is one way to defeat much of what is attributed to ‘bad timing’.

Focus more on overall talent, less on buzzwords

If your company has explicit and rigid rules on only considering candidates that have a certain number of years of experience, whether overall or in a certain technology, you are doing it wrong.  In a buyer’s market it is common for firms to create very specific requirements for experience, but in times like now when demand is high and supply is low we see the requirements open up significantly.  Companies that hire the best available engineering talent instead of an engineer with a specific skill should end up with better teams in the long run.  Turning away a savvy engineer because his/her experience is with a different language is a tough choice.  Of course some hires are made with short term goals, particularly in the start-up world, but focusing too much on a narrow skill set contributes greatly to the perceived skills shortage.

Conclusion
In my own experience, the companies that are using some of these strategies are much easier clients to ‘sell’ to candidates.  Being stealthy is intriguing but by design it won’t get you noticed.  Making your engineering organization visible to your target audience (great engineers) and promoting the company’s image as “engineer-friendly” should result in a larger and more qualified candidate pool.

Interview Prep For Geeks

Posted on by
2

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.