Category: Interview tips
Salary Negotiation For Geeks
Advice on salary negotiation is abundant, but material written for the general public may not always be applicable to a technology sector where demand is high and the most sought after talent is scarce. There is quite a bit of misinformation and the glorified mythology of negotiation is often mistaken for the much less interesting reality where little negotiation actually takes place.
Let’s start by going over a few “rules” that are often thrown around in these discussions.
Always negotiate
Using absolutes is never a good idea (see what I did there?), and there are definite situations when you should not negotiate an offer. For example, entry-level candidates who are considered replaceable with other entry-level candidates often do more harm than good by negotiating, particularly when the job being offered is among the most desirable. We will cover when you should and should not negotiate a bit later, but there are clearly some conditions when it’s not a great idea.
There’s no harm in asking for more/Doesn’t hurt to ask
Actually, sometimes it does. When you propose a counteroffer, there are only a few realistic outcomes.
How to Prevent Crying During Your Technical Interview
A recent blog post Technical Interviews Make Me Cry by Pamela Fox tells the personal tale of a technologist and conference speaker who gets a Skype/Stypi interview for her dream job, becomes stumped on a technical question, breaks down in tears, almost abandons the interview, fights through it, and eventually gets the job. Everyone loves a happy ending, and it was courageous for the author to tell her story so publicly as a service to others. However, I think some of her takeaways and the advice she provides can be improved upon.
So how can we prevent crying or freezing up during a technical interview?
Let’s start with the author’s advice. She offers that interviewees should prepare for the format and not just the material, and writes
Continue reading
Why You Didn’t Get The Interview, Part II
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.
How to (Partially) Control Your Technical Interview
ebook now available
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 Amazon. A sample from the iBook in PDF format can be found here.
The Dangers of Book Learnin’
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, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.
A Guide To Lifelong Employability For Tech Pros
There seem to be a rash of “Am I Unemployable?” posts and comments lately on sites that I frequent, and after reading details the answer in my head is usually “Not quite, but sounds like you are getting there“. In other words, someone will hire you for something, but many who assess themselves as unemployable are going to feel both underpaid and undervalued when they finally find work.
How does a technology professional go from being consistently and happily employed for a number of years, only to find himself/herself suddenly unemployable? Better yet, what are the key differences between someone who spends months on a job search and someone who can unexpectedly lose a job Friday and start a new one the following Monday?
How do certain people get job offers without having to even interview?
It isn’t simply about skill, although that is obviously a factor. Even pros that are highly productive and well-regarded in some circles can encounter challenges in today’s hiring environment. It’s about creating relationships and developing your reputation/visibility.
In my experience, pros that are always in demand and rarely (if ever) unemployed seem to share certain sets of habits, and while some of the material below is Career 101 there are some that you probably never considered. As a longtime user group leader and recruiter of software engineers for the past 15 years, I see this first hand on a daily basis. Let’s start with the habits that are the least obvious and progress to some that are more widely practiced.
Interview – How often do you interview when you are not actively looking for a job? For most the answer is never, and I’d encourage you to take at least a couple interviews a year. Going on the occasional interview can serve two purposes. First, they are a way to make new contacts and keep your name in the minds of potential employers, with the added benefit that these same interviewers may be working at new companies in a year or two. One interview could lead to an ‘in’ with four or five companies down the road. Second, it is the only way to keep interview skills sharp. Interview practice is best done live without a net, and failing the audition for a job you truly wanted is often attributed to rusty interview chops. Even a simple informational interview request (made by you) is an effective and creative way to make first contact with a potential employer.
Know when to leave your job – Without question, the group having the toughest time finding work are unemployed with say ten+ years at the same company, and a close second would be employed workers with that same ten year tenure. For anyone about to scream ‘ageism‘ please hold that thought, as older technologists that have made smart moves do not typically have this issue. I would add that older engineers who possess the habits outlined here are the group being hired without interviews. There are always exceptions, but tech pros can stagnate quicker than those in other industries due to the speed of change in technology.
The definition of job hopping has morphed over the past fifteen years, and it is now understood that semi-regular movement is expected and accepted. Where other industries may interpret multiple employers as a symptom of disloyalty, in the software world a pattern of positive (moving to something better) job changes is often more indicative of a highly desirable candidate. Conversely, someone who has remained at a company for many years may be viewed by employers as loyal to a fault and potentially unambitious. If this person has solid skills, why has no company picked him/her up yet? Changing jobs before stagnating is critical to overall employability, and how quickly you stagnate will vary based primarily on your employer’s choices, your own ability to recognize that stagnation is happening, and your desire to not let it happen.
Make ‘future marketability’ a primary criterion when choosing jobs or projects – Carefully consider how a new position will impact your ability to find work later in your career and use that as one of your key incentives when evaluating opportunities. Details about your roles and responsibilities as well as the company’s technology choices and reputation in the industry are all potential factors. Does the company tend to use proprietary languages and frameworks that will not be useful later in your career? How will this look on my résumé? Many candidates today are choosing jobs or projects based on an opportunity to learn a new skill, and for this they are usually willing to sacrifice some other criteria.
Reach out to others in the community (not coworkers) – How many times have you sent an unsolicited email to someone in your field that you don’t know? “Congrats on your new release, product looks great!” or “Saw that you open sourced, look forward to checking it out” as an email or a tweet is an effective way to create a positive impression with a person or organization. Twitter is great as a public acknowledgment tool, and the character limit can actually be advantageous (no babbling). If you stumble on an article about a local company doing something interesting, there is much to be gained by a 140 character pat on the back. This is essentially networking without the investment of time.
Lunch with others (again, not coworkers) – You have to eat lunch anyway, so how about inviting someone you don’t know that well to lunch? Perhaps include a few people that share some common technology interest and turn it into a small roundtable discussion. Meeting with other tech pros outside an interview or meetup environment enables everyone to let their guard down, which leads to honest discussions about the experience of working at a company that you may consider in the future. It’s also an opportunity to learn about what technologies and tools are being used by other local shops.
Public speaking – This is an effective way to get attention as an authority in a subject matter, even on a local level. Preparing a presentation can be time consuming, but generally a wise investment. Even speaking to a somewhat small group once a year can help build your reputation.
Attend a conference or group meeting – This isn’t to be confused with going to every single meeting for every group in your area. Even getting to an event quarterly keeps you on the radar of others. Make an appearance just to show your face and say hi to a few people.
Reading and writing about technology – One could debate whether reading or writing has more value, but some combination of the two is likely the best formula. If you don’t know what to read, follow some peers and a few respected pros from your field on Twitter, LinkedIn or Google+, and make a point to read at least a few hours a week. As for writing, even just making comments and discussing articles has some value, with perhaps more value (for job hunting purposes) in places like Stack Overflow or Hacker News where your comments are scored and can be quantified. Creating your own body of written work should improve your understanding of a topic, demonstrate your ability to articulate that topic, and heighten your standing within the community.
Build a personal code repo – Many in the industry balk at this due to the time required, but having some code portfolio seems to be on the rise as an expectation hiring firms have for many senior level candidates. If the code you wrote at work is not available for demonstration during interviews, working on a personal project is more critical.
Conclusion
At first glance, this list may appear overwhelming, and I’m certain some readers will point to time constraints and the fact that they are working 60 hour weeks already. Some of these recommendations take considerable time, but at least a few require very little commitment. Employ a few of these tactics and hopefully you will never suffer through a prolonged job search again.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.
“I Dunno” – Recovering From a Botched Technical Interview Answer, Postmortem
A recent post on Stack Exchange’s Workplace forum posed a rather unique question and perhaps raised a few more. The post asks if it is appropriate to follow-up with a correct response afterwards if you answered a technical interview question incorrectly (or responded with “I don’t know”). As a recruiter of engineers, I’ve taken my share of calls from candidates upset about fumbling a tech question that they would have slam-dunked 99% of the time but froze in the moment, only to have the correct answer come to them while driving home from the interview. At the time of this writing, there are four answers listed and (in my opinion) at least a bit of poor advice for job seekers.
The posted question brings up a few topics for thought, which will also be detailed in (plug warning) my book. First, we will cover this specific scenario and the best way to ‘recover’, as well as what is wrong with the answers provided. Then we will dig a bit deeper into the “I don’t know” problem and reveal the motivations behind technical interview questions and why a simple “I don’t know” (which was recommended by one respondent) is almost never appropriate.
Recovery From A Botched Interview Question, Postmortem
The answer in the forum accepted as the best suggested that it was not recommended to send a correct response as it may make the candidate appear ‘obsessive’, and added that the answer could have been looked up after the fact. Two distinct points were made, and both were (IMO) not helpful.
If the candidate sends a note resembling “I just HAD to get this off my chest, I’ve been losing SOOO much sleep about that answer I messed up“, then of course the obsessive label may be legitimately applied. However, if the correct answer is provided tactfully using some careful language, the result should be more indicative of tangible interest in the job than an obsession to be correct.
The mention that the candidate could have researched the answer afterwards is probably irrelevant unless the question was a complete softball that any industry professional must know. If the question was difficult or perhaps a complex programming exercise in an environment approximate to what the engineer would encounter in the real world, one would think that the test should be open book in order to simulate the office experience.
How To Make The Recovery
- 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.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Job Tips For Geeks 