Many new entrants to today’s technology job market are obsessed with the handful of high-profile companies that set the trends in the industry, and the next generation of software engineers seem to think that the only companies worth working for are Google, Microsoft, Apple, Facebook, Yahoo, Twitter, and Amazon. Software development has become both a celebrity culture (where companies and their CEOs are the stars) and an oligarchy in the eyes of recent graduates and teens, who set their sights on employment with this small number of firms. Young developers in foreign countries appear to be particularly susceptible to this hyperfocus on a tiny segment of the hiring market. If you don’t know how widespread this is, I’d suggest a visit to Reddit’s CS Career Questions section to see what people are asking.
When Yahoo changed their remote work policy the web exploded in debate around the value of remote employees, and the more recent news around Google dismissing GPAs, test scores and answers to Fermi questions made many tech companies reconsider their hiring procedures. Not a day passes where a piece on one of these companies doesn’t hit the front page of most major news sites. A cottage industry has erupted with authors and speakers providing guides for aspiring engineers to create résumés, land interviews and answer technical questions to get jobs specifically at these companies. The focus seems to be less about becoming skilled and more about being attractive to a specific subset of employers.
These companies are glamorized amongst budding engineers much like Ivy League and top-tier schools are with high school students, and the reason you probably won’t work for Google is the same reason you probably didn’t go to MIT. Because they are highly selective, and they simply can’t hire everyone.
Of course some of you can and perhaps will work for Google and the other companies listed here, just as some of you may have attended top universities. But the majority of
you us won’t – and that’s OK. Follow your dreams, but be realistic about the outcome.
So here comes the good news! Beyond Google, Microsoft, Apple, Facebook, Twitter, Yahoo and Amazon, there are hundreds of awesome places to work that are highly regarded by engineers the world over, and most people outside the industry (and many inside) haven’t heard of most of them. Experience with these shops, much like the above list, will get you noticed. Companies like Netflix, LinkedIn, Salesforce, eBay and GitHub are well-known but not typically mentioned in the same breath as the top celebrity firms, though they certainly could be. I’d venture that most college CS majors haven’t even heard of 37signals or Typesafe, where smaller teams are doing work that is regularly recognized by the engineering community.
And again the bad news. You probably won’t work for these companies either. For most of the world, these are still reach schools that employ relatively few. Although they may not be held by the general public in the same esteem as that list up top, they are incredibly selective, and most in the industry will view the difference between this group and the Googles as incredibly slim.
And now for some more good news. Beyond the lists of companies above are thousands of great places to work that I guarantee you have never heard of. These may consist of startups that fly under the radar or smaller specialized technology companies that serve a niche market. They could be the development groups for major banks or 25 year old mom and pop shops that have an established customer base and solid revenues. Game developers, ecommerce sites, consulting firms, robotics – the list goes on.
In almost every city, this group is the one that employs the overwhelming majority of engineers. This is where most of us will likely end up – a company that you will surely need to describe and explain to your parents and significant other.
In the city where I focus my business (Philadelphia) and run our Java Users’ Group, we have some Googlers and I’ve known engineers who have worked for Amazon, Yahoo, and Apple. And I know many many others who either turned down offers or likely could have joined those companies, but chose instead to work somewhere else. Just as some students may reject the offer from the top-rated school to stay closer to home or to accept a more attractive scholarship package, many of the world’s top engineers simply don’t work for Google or Facebook, or anywhere else in the Valley for that matter.
Philadelphia is by no means Silicon Valley, yet there is a fairly robust startup scene and a large number of software shops that are doing valuable work. Over the past 15 years I’ve worked with hundreds of Philly companies to hire engineering talent, and 99% of these places would be unknown to the typical developer. I almost always have to describe my clients to potential candidates, as most of these shops have not built a reputation yet, and these are firms ranging from 20 to perhaps 20,000 employees. And the vast majority of them are great environments for technologists where developers work alongside at least a few top engineers that could (and some that did) pass the entrance requirements for the Googles and Facebooks of the world.
All the great engineers in the world aren’t in the Valley, and they don’t all work for Google. This fact is obvious to most, but fewer than I’d expected and hoped. If that is the goal, go after it. The rest of us will be here if it doesn’t work out.
Job Tips For GEEKS: The Job Search DRM-free ebook is available for
$9.99 (reduced to $6.99 in December 2013) – more info here.
In August 2012 I published a blog post Why You Didn’t Get The Interview, which received a good bit of attention from readers and was republished a few times (most notably by Lifehacker). Of course one article could not list every possible explanation that an employer or recruiter might use to discard a résumé, so I decided to revisit the topic once again. This is not intended to be a comprehensive list, but rather an addendum to the previous post that may help explain a lack of response to your job search.
No submittal content – Online applications often consist of several fields and check boxes that don’t always give job seekers an opportunity to express interest or differentiate themselves. However, when you send a résumé via email or are provided some space within an online application to craft a custom message, you are foolish not to take advantage. Simply sending a résumé without any supporting information about your experience or interest in the job comes across as lazy or aloof, and can give the appearance that a job seeker is simply blasting résumés indiscriminately (perhaps even in an automated fashion). SOLUTION: Tell the employer at least one or two things that drew your attention to the job and company.
Multiple applications to the same employer for vastly different roles – Sometimes I will open my inbox and find an email from a job seeker about one job that could possibly be a fit, and then find another four or five emails from the same applicant for other jobs that are not remotely connected to the candidate’s experience. This applicant may have received some attention if he/she only sent the one semi-targeted application, but the additional blind stabs have too many negative implications. It typically signifies either a lack of self-awareness regarding qualifications, immaturity, or desperation. SOLUTION: Before submitting your résumé, check several of the company’s listings to make sure that you are applying for the one or two jobs that best fit your experience and goals. If you have a strong desire to work for a specific employer, sending a targeted application to one or two listings is much more effective than spamming your résumé to all of their vacant slots.
Many small red flags – My original article last year referenced 14 fairly obvious reasons that job seekers are not interviewed, but often it’s not that simple. Many times a résumé/application package will contain a handful of items that would not be a problem when considered individually, but when combined add up to a rejection. The recruiter or hiring manager will feel that too many special circumstances would have to occur that make the candidate’s hire unlikely. Perhaps a candidate has a slightly elevated salary expectation, requires relocation assistance, is minimally qualified, and lacks any easily identifiable positive indicators of talent or ability that stand out from others. An applicant with only one of those characteristics would likely be considered, but the aggregate picture makes it too much of a longshot. SOLUTION: There is no real fix to this. You could always try to explain what could be perceived as a red flag. For example, if you are relocating to a specific area, make it clear why you are looking in that specific market to avoid being viewed as someone open to jobs worldwide. Displaying some level of interest or passion for the employer could also help overcome objections and get you a shot.
Personal reputation and your employer’s reputation – It shouldn’t surprise anyone that if you apply to firms where people either know you or are connected to those that do, a decision to interview will typically be based on how these contacts feel and talk about you. However, your employer’s reputation may also come into play here as well. If a particular company has interviewed multiple former employees of your firm without much success, chances are they will not waste time interviewing another. As a recruiter, it is fairly common for companies to tell me “Unless they are outstanding I’m not overly interested in candidates from COMPANY, as we see many and have not had any luck.” Your company’s reputation is more likely to work in your favor if you are employed by a firm known for having talent, but it seems the trend to discriminate against employees of certain shops continues. I wrote about this a bit in a past post regarding discrimination by startups against workers from large enterprises. SOLUTION: Keep your personal reputation in mind when dealing with co-workers and particularly when leaving jobs. Minimize stints at employers that have a negative reputation in your market.
Inconsistency - This can be the result of discrepancies between a résumé and cover letter/application, between a résumé and LinkedIn profile, or just something fishy in the résumé itself. If you changed professions more often than Barbie (impressive list) or have travailed up the corporate ladder and come back down multiple times, your application will raise suspicions. Candidates that list titles progressing from CTO to CEO and then down to Junior Developer will be scrutinized. SOLUTION: There isn’t anything you can do to change the past, but explanations could go a long way if you left an industry to pursue a passion. Make sure all of your online profiles match your résumé details before sending applications. Try to use job titles that reflected your actual duties if you worked for a small firm and had an inflated title. Even if you were CEO or CTO of your dorm room software company, it may not be helpful to list the job that way.
“Meh“ – Your qualifications and history are virtually identical to the others in the stack of résumés received. You may have met what was listed on the job spec, but so did everybody else. This is of particular importance for jobs where it is expected that most applicants will have similar qualifications, such as entry-level positions for new graduates or jobs that list highly generic specifications. SOLUTION: There has to be something different about you that you can add to give some positive spin to your candidacy. Review the requirement again and try to find an area where your background exceeds the expectation, or a specific experience you have that others probably don’t.
My ebook Job Tips For GEEKS: The Job Search was recently released and is available for
$9.99 (reduced to $6.99 in December 2013) on iTunes, Amazon, Barnes and Noble, Google Play, and Kobo. I can provide a PDF version for sale by request.
Generally speaking, when you walk into an interview you are at the mercy of the interviewers. Although you may be given some general information regarding the interview format and probably have an idea about the questions or exercises you may encounter, there are endless possibilities on the topics you may be asked about over a two or three hour session.
As was stated before, any item on your résumé is fair game, so one way to potentially avoid queries on unfamiliar topics is to keep those words off your résumé. Regardless of what is or isn’t on your résumé, it is quite likely that you will be asked questions pertaining to subjects that are not within your areas of expertise. Trying to fully eliminate the exposure of certain vulnerabilities is an exercise in futility, but there is one rather effective method to at least attempt to mitigate the risks.
There is an increasing trend in the technical hiring world for employers to request firm evidence of a candidate’s abilities that go beyond what a traditional résumé includes. For programmers, this typically can be achieved through a code sample. Front-end designers and developers may be expected to show off some UI or website that they built, and architects may be asked to share documents. Mobile developers may hear this more than any other group, and are routinely asked “Do you have any apps available?” as part of the vetting process.
One way to partially control the content and direction of your interview is to provide interviewers a work sample that will presumably become a point of discussion. This will turn what could be a technical interrogation into a version of show and tell. Even if the exchange about your sample only takes fifteen minutes, that is fifteen minutes of the interview where you hopefully will shine, and it is fifteen minutes less time for the interviewers to delve into other topics that are probably less familiar.
To employ this tactic, be sure to make it known at some point early in the process that you have samples of your work for review by request. A GitHub link at the top of your résumé, a URL to download your mobile app, or a link to sites that you developed are much more graceful than large file attachments. You can choose to extend an invitation to view these projects as early as your résumé submission, and when scheduling the interview you can express your willingness to discuss the projects in more detail and offer to bring a laptop with samples.
Independently volunteering to show representations of what you have produced will give an employer the impression that you are both willing and able to demonstrate the quality of your work. That act makes the applicant appear more open and trustworthy than someone who hesitates when asked for some samples. Recruiters and hiring managers alike will welcome résumé submissions that are accompanied by additional supporting evidence of a candidate’s abilities.
When you enter the interview, you can mention that you brought samples to show if the team is interested in seeing your work. This will typically be received quite positively and could lead to a deep dive into familiar territory.
This post is an excerpt from the recently released ebook Job Tips For GEEKS: The Job Search, available to purchase from iTunes iBookstore, Amazon, Barnes and Noble, Smashwords, and (soon?) Kobobooks. A sample from the iBook in PDF format can be found here.
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.
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.
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.
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
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.
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.
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.
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.
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
- Email the interviewer and lead with a standard thank you sentiment.
- 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).
- Write out the question as best you remember with a synopsis of the answer you provided.
- 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).
- 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.
- Questions you find difficult, but at least somewhat within the scope of something you could/should know.
- Questions regarding incredibly minute and trivial details that you could possibly know, but that most candidates probably would not answer on-the-spot.
- 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.
- 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.
- 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?
- 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.