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.
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.
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é.
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.
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
willshould 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.
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.
Over the course of my career I have scheduled thousands of software engineering interviews with hundreds of hiring managers at a wide array of companies and organizations. I have learned that although no two managers look for the exact same set of technical skills or behaviors, there are recognizable patterns in the feedback I receive when a candidate is not presented with a job offer.
Obviously, if you are unable to demonstrate the basic fundamental skills for a position (for our purposes, software engineering expertise), anything else that happens during an interview is irrelevant. For that technical skills assessment, you are generally on your own, as recruiters should not provide candidates with specific technical questions that they will be asked in an interview.
It should be helpful for job seekers to know where others have stumbled in interviews where technical skill was not the sole or even primary reason provided for the candidate’s rejection. The examples of feedback below are things I have heard repeatedly over the years, and tend to be the leading non-technical causes of failed interviews in the software industry (IMO).
Candidate has wide technical breadth but little depth – The ‘jack of all trades’ response is not uncommon, particularly for folks that have perhaps bounced from job to job a little too much. Having experience working in diverse technical environments is almost always a positive, but only if you are there long enough to take some deeper skills and experience away with you. Companies will seek depth in at least some subset of your overall skill set.
Candidate displayed a superiority complex or sense of entitlement – This seems most common when a candidate will subtly (or perhaps not so subtly) express that they may be unwilling to do any tasks aside from new development, such as code maintenance, or when a candidate confesses an interest in exclusively working with a certain subset of technologies. Candidates that are perceived as team players may mention preferences, but will also be careful to acknowledge their willingness to perform any relevant tasks that need to be done.
Candidate showed a lack of passion – The lack of passion comment has various applications. Sometimes the candidate is perceived as apathetic about an opportunity or uninterested in the hiring company, or often it is described as what seems to be an overall apathy for the engineering profession (that software is not what they want to be doing). Regardless of the source of apathy, this perception is hard to overcome. If a candidate has no passion for the business, the technology, or the people, chances are the interview is a waste of time.
Candidate talked more about the accomplishments of co-workers – This piece of feedback seems to be going viral lately. Candidates apparently ramble on about other groups that built pieces of their software product, QA, the devops team’s role, and everyone else in the company, yet they fail to dig deep into what their own contribution was. This signifies to interviewers that perhaps this candidate is either the least productive member of the team or is simply unable to describe their own duties. Give credit where it is due to your peers, but be sure to focus on your own accomplishments first.
Candidate seems completely unaware of anything that happens beyond his/her desk – Repeatedly using answers such as “I don’t know who built that” or “I’m not sure how that worked” can be an indicator that the candidate is insulated in his/her role, or doesn’t have the curiosity to learn what others are doing in their company. As most engineering groups tend towards heavy collaboration these days, this lack of information will be a red flag for potential new employers.
Candidate more focused on the tools/technology than on the profession – Although rare, this often troubles managers a great deal, and it’s often a symptom of the ‘fanboy’ complex. I first experienced this phenomenon when EJB first arrived on the scene in the Java world, and many candidates only wanted to work for companies that were using EJB. When a technologist is more focused on becoming great at a specific tool than becoming a great overall engineer, companies may show some reluctance. This is a trend that I expect could grow as the number of language/platform choices expands, and as fanatical response and the overall level of polarization of the tech community around certain technologies increases.
Candidate’s claimed/résumé experience ≠ candidate’s actual experience – Embellishing the résumé is nothing new. A blatant lie on a résumé is obviously a serious no-no, but even some minor exaggerations or vague inaccuracies can come back and bite you. The most common example is when a candidate includes technologies or buzzwords on a résumé that they know nothing about. Including items in a skills matrix that are not representative of your current skill set is seen as dishonest by hiring managers.
Candidate’s experience is not ‘transferable’ – If your company is only using homegrown frameworks and proprietary software, or if you have worked in the same company for many years without any fundamental changes in the development environment, this could be you. The interviewer in this case feels that you may be productive in your current environment, but when given a different set of tools, methodologies, and team members, the candidate may encounter too steep a learning curve. This is often a response on candidates that have worked within development groups at very large companies for many years.
Give some thought to these before your next interview.