Category: Interview tips
How to Get an Interview at (Almost) Any Company
In my line of work (recruiting, job search coaching, and resume writing) and through my comments on Reddit, I’m often asked by job seekers how they can get noticed by a favored employer (which we’ll call COMPANY). A good resume, cover letter, and online profile are the standards if you don’t already have a friend on the inside, but when competing with candidates who might look better on paper, your results might not always be positive.
When you have narrowed a job search down to a few top places where you really want to interview and perhaps your qualifications fall a bit short of the company’s ideal candidate, a bit of extra customized effort can make a major difference in your results. Most people tend to use elaborate cover letters or resume delivery methods, which may work sometimes but aren’t entirely original. Sending a box of cookies with a hidden resume inside might get some attention, but methods like this don’t elevate you as a candidate so much as they make you appear willing to bribe.
Your mileage may vary (read: good luck!) when it comes to the biggest names that get hundreds of thousands of resumes per year, but startups and smaller firms will find one tactic difficult to dismiss or ignore.
What’s the most effective way in?
Use COMPANY’s Stuff!
If you want COMPANY to say yes to the interview, create a project using COMPANY stuff. This could be APIs and data sets, open-source code, or anything resembling the development work you might be doing while working for COMPANY.
Does COMPANY have some publicly available APIs? Create a project that makes some novel use of the API or extends the functionality of an existing related project. Find some public data sets that pertain to COMPANY’s business and create something with them using the tech stack COMPANY lists on their job specs.
Is COMPANY involved in open source? Jump into a couple of their repos and see if you can address a few of their issues.
Read up on COMPANY’s tech blog, find out what the developers are working on and any unique challenges they faced, and make a comment linking to relevant information.
It’s a pretty simple concept. If you are applying for a job with COMPANY, anything you provide that reflects the kind of work you’d be doing for COMPANY serves two purposes. First, this is perhaps the best possible evidence of your work quality using their tools, and second, it demonstrates your interest in and potential commitment to their work.
Interview Prep: Ready for Storytime?
Interview preparation often means different things to technologists depending on their level of experience. It seems that more and more material written about interview prep seems focused on junior level developer interviews at the most visible employers (“the Big 4”), causing worried job seekers to spend hours memorizing algorithms and data structures or the code to the most commonly asked problems to solve.
After someone gains a few years of programming experience, their interviews tend to focus less on technical memorization and more on professional accomplishments and to some degree on self-awareness. Being prepared for a potentially deep technical conversation still is important, but studying for an interview should also include a healthy dose of reflection and the preparation for anecdotal questions.
Here are some questions you might expect to see:
- What professional accomplishment are you most proud of, and why? Some may take this opportunity to brag while others might stress the value of their team during the efforts.
- What are the biggest challenges you face in your current position? Be careful to sidestep being perceived as overtly negative about your employer.
- How does your work (or $PROJECT) impact the business? Several hiring managers have privately expressed to me that their biggest pet peeve was when developers had little understanding of their relationship to the big picture.
- Tell us about a professional disagreement you had with a difficult boss/co-worker and how the situation was resolved. This one is also tricky, and some humility goes a long way.
- Tell us about a mistake that you made that had an effect on your team or product, what caused the problem, and how it was fixed. Everybody messes up, and the ability to both accept fault and learn from mistakes is a valuable trait.
There can be many examples of questions that require reflection. One useful exercise is to review your resume before an interview to refresh your memory of various projects, and consider both the positive and negative experiences for each. Having to improvise stories can be a difficult task in front of an audience, so practicing answers may be helpful.
Using the “Do You Have Any Questions?” Question
During most interviews, an interviewer provides the candidate the opportunity to ask questions. In most cases the highly-anticipated “Do you have any questions?” question falls towards the end of the session, though some companies today throw candidates a curveball and start the interview this way (consider yourself warned).
Many candidates use this invitation to gather information that will be helpful in making a decision on any offer that may be extended. This reaction is instinctual. The interviewer used the allotted time to ask the candidate questions to determine whether or not an offer should be made, so when the tables are turned the candidate asks questions to determine whether or not an offer should be accepted. At best it’s a chance to “interview the company”, and at worst learn if they have direct deposit.
Others may go into a reflective mode and ask about their own performance. This puts an interviewer on the spot and isn’t likely to produce a positive outcome. A candidate that performed well might now be considered insecure.
What if interviewees viewed the opportunity to ask questions in an entirely different way?
The interview is a finite amount of time where the candidate’s ultimate goal should be to make a positive impression on the interviewer and ideally gain an employment offer.¹ Any minute of interview time not used towards those ends is wasted.
The minutes provided to ask questions are the only time during an interview where interviewees have total control of the conversation. This window provides candidates a one-time opportunity to steer dialogue to areas advantageous to their candidacy.
This is not to suggest that candidates should never ask about perks, benefits, responsibilities, and all the things that will help with evaluating an offer. Candidates should fully utilize interview time to convince employers of their positive qualities. There will be ample time post-interview for candidates to get the information needed about the company’s offerings.
How can interviewees maximize the opportunity?
The key is to anticipate the question and not to blow it. Unprepared candidates may react with “How did I do?”, but most will gravitate towards asking questions best described as “What’s in it for me?”. Any questions about salary, benefits, perks, vacation, and training fall into this category in most situations, which are best to ask at the offer stage. Interviewees who lead with questions about the company’s tuition reimbursement policy give the appearance that they are looking for a scholarship more than a job.
What strategies can prepared candidates use to utilize the time wisely?
Create positive thoughts – Creating any positive thoughts in the interviewer’s mind gives the best chance for offer. Most interviewers (even engineers, with some exceptions) will enjoy talking about themselves for a bit. “What is your background?” and “What was it about this company that interested you?” are ways to make that happen, while the latter also should generate a positive answer. Too many questions like this will start to resemble an interrogation.
Redirect to a highlight – If an interviewer failed to address a particular strength or highlight of the candidate’s career, that can be corrected. “Do you feel my experience in PROJECT/SKILL would be valuable to me when working for COMPANY?” may bring the interviewer’s attention to an accomplishment or skill that the interviewer overlooked.
Demonstrate interest and insight – A question that required research, such as one relating to a company current event, can demonstrate that an interviewee keeps tabs on the company and industry. “How do you believe COMPANY’S recent acquisition of COMPANY2 will impact future projects?” and “Do you feel COMPANY’S recent new product is indicative of the direction the company is headed?” will show that the interviewee did homework.
Show long-term thinking – Questions about long-term topics could show the interviewer that the candidate isn’t a mercenary just thinking about the next paycheck. Most questions about future projects, career path, and the goals of internal departments and groups can serve to differentiate an interviewee from the herd.
Conclusion
Interview time is limited, so use every bit wisely. Almost all questions that candidates use in their decision to accept/reject offers can be asked after an interview, and those candidates that fear they may waste time interviewing for jobs they won’t accept should be asking ‘deal breaker’ questions before interviews. Prepare questions in advance.
¹ For anyone thinking “But I’m interviewing the company as much as they are interviewing me”, I don’t disagree with that overall philosophy. However, I’d suggest that most candidates will probably gather most of the required information without needing to ask a multitude of questions, and those questions can be answered after interviews are complete. Let them interview first.
“…but I’m negotiable”
I review many emailed job applications each week that include a salary expectation, usually in the form of “seeking $X,000 per year“. Some continue with a phrase that has become trite, not to mention quite costly to job seekers everywhere.
“but I’m negotiable”
What these candidates are telling us is “I have a target number, but I want you to know in advance that I’m willing to accept less.”
This phrase is also a common response during live conversation with candidates, whether in speaking to me or in interviews with my clients.
INTERVIEWER: What are your salary expectations?
CANDIDATE: I’m seeking 80K, but I’m negotiable.
But usually it goes more like this
INTERVIEWER: What are your salary expectations?
CANDIDATE: I’m seeking 80K…
INTERVIEWER: [Silently takes a note for five seconds]
CANDIDATE: …but I’m negotiable.
Don’t do that.
The mistake here is that the candidate willingly dropped their request before hearing any objection to the number provided. In the first instance, they have altered their negotiating position before even giving the interviewer so much as an opportunity to say no.
The Fix
IN APPLICATIONS – When providing a salary requirement in writing, there is the option of using a single number or a range. Supplying a range could be potentially useful, as a range may account for variation between what companies offer in time off, benefits, bonus, or perks. When providing a range, expect employers to start negotiations at the bottom.
Providing some brief context along with the number (“assuming competitive benefits and working conditions”) will provide an opening to negotiate above the provided number/range when necessary. Usually there will be some part of the package that can be cited as below market to justify raising an offer.
If the recipient of the application feels the candidate is qualified and at least in the ballpark for the budget, contact will be made and the flexibility topic may come up early.
IN INTERVIEWS – Prepare a number to ask for along with any context before the interview. It’s quite a common question, and having an answer available should provide the best results. Improvisation on this question is usually where things go wrong.
When the question about compensation expectations comes up, reply with the number along with any brief and necessary clarifying context. Then, stop talking. Don’t say a word until the interviewer responds. Even if the stare down lasts a minute, say nothing.
Interviewers realize you are probably a bit on edge and slightly uncomfortable during an interview. Any silence, even for just a few seconds, is commonly interpreted by candidates as a negative sign (“Uh oh, why did she stop asking questions???”). Some hiring managers or HR professionals actually have a pause built into the script in order to determine possible flexibility without having to even ask.
Conclusion
Never start negotiating downward until some objection is provided, and don’t mistake the silence of an interviewer as an objection.
Boot Camps, MOOC’s, and Jobs: A How To For Fresh Devs
Every year, thousands of professionals in various lines of work look to the programming world as a promising new employment option. Just in the past few months, I have spoken to attorneys, accountants, salespeople, and even a former professional athlete trying to land their first paying gigs in the industry. This isn’t the first time we’ve seen this.
A brief history lesson and cautionary tale
During the initial dot com boom of the late 90’s, millions scrambled to enter the technology industry. Naturally, some entrepreneurs looking to cash in on the movement developed accelerated training programs and boot camps designed to quickly convert blue collar workers into earning members of the IT industry. These classes and certifications were not cheap, but they usually cited high placement rates (and in some cases guarantees) and salary data for graduates.
Early on, the training programs typically had barriers to entry. Entrance exams and interviews left the least qualified applicants on the outside looking in. Time commitments made juggling a full-time job and a training program challenging for many, while cost made these programs inaccessible for others.
As you might expect, training programs with lowered admission standards and reduced prices arrived on the scene. Financial aid was made available, lecture times were adjusted to accommodate almost any schedule, and marketers flooded TV/radio/newspapers with anecdotes of auto mechanics and dental hygienists now earning double in the IT field. When qualified instructors were not available, classes were led by recent graduates who did not find employment.
Much of this training was geared towards obtaining a certification known as the MCSE (Microsoft Certified Systems Engineer), which was primarily a qualification towards Windows admin roles or desktop support. Even today, Microsoft has marketing material live on their site touting the value of these certifications.
The early graduates of the first programs probably did have high employment rates. However, the rise of the MCSE factories created a new class of applicant dubbed the Paper MCSE, defined as someone with no experience that was just able to pass the test. The MCSE certification quickly became associated with a type of get rich quick mentality, and having the letters next to your name was less indicative of knowledge and more likely someone trying to game the system.
Flash forward
If this story doesn’t sound at least a bit familiar, it should. Back then the message was ‘learn computers’, but now everyone from the President to Shakira (not to mention Ashton Kutcher and NFL legend Warren Sapp?) is telling us we now need to learn how to code. Today’s career changer isn’t trying to simply fill what are generally considered less glamorous jobs like help desk, but rather they want to be like those (pardon the silliness) rock stars and ninjas that they read about who are higher up the food chain.
Programming boot camps and the availability of MOOC’s has again taken learning of in-demand skills to the masses, and (regardless of your opinion on their value) the emergence of these programs impacts the hiring landscape for everyone. For now, most of these programs have some admissions criteria and may be affiliated as feeders to recruiting or consulting firms. Unlike their predecessors, the programs often boast that graduates will network with industry veterans and leave with real-world contacts to leverage in their job search.
Although it’s far too early to see how these graduates will do over time, history and basic economics indicate that new programs of reduced quality will emerge.
The difference between then and now
The major difference between the MCSE gold rush and the recent development-focused trend is that today’s career changer is often expected (and hopefully able) to demonstrate proof of their credentials. Graduates of boot camps are often very quick to point out that the classes were rigorous, had low program acceptance levels, required hours beyond typical full-time jobs, and that they built professional-grade applications before graduation. In almost every case where I’ve encountered a boot camp grad, these topics were brought up immediately by the job seeker. If the reputations of these programs become overwhelmingly positive (I’d now say they are no worse than lukewarm now), grads should become much less defensive as to the value of their education.
Being accepted into a help desk job today without experience or a relevant degree is one thing, but how willing will the programming community be to view these graduates as one of their own? This is more daunting when you consider that the community is considered to be protective of their craft’s reputation, and are sometimes known for being less-than-welcoming to their own. Will employers value the more hands-on approach of a three month boot camp over traditional lecture-based four year CS degree programs?
Keys to success
Whether you graduated from a boot camp or a four year program, I think the expectations for most new hires are similar. Employers probably won’t be expecting boot camp grads to be committing code any sooner or later than a BS in CS, and it is expected that there is inherent risk for any hire (particularly any hire without experience). There is some leap of faith for managers trying to evaluate someone for their first industry position.
For boot camp grads specifically,
You’re not being hired because of your boot camp app. Although your code portfolio may help you some, in a few years you’ll realize your app looks like it was coded by someone who learned Ruby in three months. Don’t overstate the importance or relevance of whatever app you built – it’s incredibly impressive to you because you don’t know better (yet). You are being hired almost exclusively on your perceived potential, not weeks of work.
You’re being groomed to work at startups and smaller firms. At this point HR representatives at most large firms will be less open-minded to you than to CS grads. Don’t take that personally because it’s really not about you, and big shops probably aren’t who you are trying to attract anyway. Your instructors likely came from startups, are teaching development as is done in typical startup environments, and the technologies taught are of a common startup stack. Your job search time is best spent focusing first on the firms that have a relationship with your program, and then other startups.
Your non-programming intangibles are just as relevant as the boot camp. Employers know that you can’t become highly productive in programming with a few hundred hours of learning. Conveying the smart and gets things done attribute is still the most important factor. You are still considered a risky hire, and if you are perceived as potentially damaging to the team dynamic you will be passed over for someone less risky.
Use caution if comparing boot camps to CS degrees. The two are vastly different, both with advantages and disadvantages. The quality and quantity of time for each are difficult to compare, and those that invested four years are more likely to be swayed by your knowledge than by diminishing the value of their degree.
To both CS and boot camp grads,
You’re not an expert. In my experience, the word expert gets bandied about more often among the inexperienced with something to prove than it does by industry vets with project history. Expertise takes time. Once you’ve been in the business a few years, you will meet people who know twice as much as you do yet still consider themselves novices. Whether in interviews or on résumés, choose your words very carefully to prevent the appearance of overconfidence (and to prevent what seems an open invitation for technical grilling).
You’ll do best if you show respect to the industry veterans. The people you are interviewing with have likely paid their dues during times when learning and information wasn’t as readily available. It’s probably difficult to envision being a programmer in 2001, where those in the field had far fewer tools or resources. They probably think you’ve had it easier in a lot of ways (and harder in others), so temper confidence with some humility.
Job Tips For Geeks: The Job Search DRM-free ebook reduced to $6.99 for the holidays. A great gift for the tech pro in your life, or for the annoying co-worker that you wish would find a new job.
How and Why to Backdoor Into Jobs
When I read anecdotes from frustrated job seekers in the tech industry, they usually start out the same way.
“I applied to dozens of jobs
but I am not getting any response.”
Sometimes the low response is warranted due to lack of qualifications or less obvious factors, but often the problem is simply that the job seeker never got access to the person/people who matter most in the hiring of technical professionals. Hiring bottlenecks start with the traditional application process (submit résumé blindly) and can be further complicated by HR reps that are hiring for disparate skills and business units. At a smaller company with no recruiters, the task of screening résumés may go to junior employees and administrative personnel with no background or training in hiring.
When you like a company and want to get an interview, the ideal entrance is very rarely the front door. The front door is the advertised entrance that HR wants you to take, crowded with active job seekers with varying qualifications that will be culled or herded through the process by the people manning the door.
After many years in the business I’ve learned that if you ask privately (meaning not within earshot of HR), most technical managers don’t want candidates to come through the front door either. They would rather you came through a back door, and if necessary to hiring protocol they will later introduce you to the front door guardians to ensure passage. HR mans the front door, but the geeks own the back doors. This is how it works at many employers.
What are the more common back doors?
Hiring Indicators, OSS, and the Value of GitHub
As someone who writes about tech hiring and who has also encouraged many to participate in open source and establish a GitHub presence, a recent article caught my eye. Why GitHub is Not Your CV ¹ by James Coglan was partly inspired by another article, The Ethics of Unpaid Labor and the OSS Community by Ashe Dryden. Both articles are well-written and if you evaluate programmers for hire please read them.
Dryden’s tl;dr for me was meritocracy in OSS, an explanation regarding the lack of diversity, and ways to hire that are ‘less biased‘ than relying on OSS contribution or public code availability. Coglan references her piece and adds his own thoughts around similar topics, but his readers might disregard the value a GitHub presence provides. Neither article tried to discourage a presence, but the Coglan piece dismissed the value quite a bit.
Continue reading
Job Tips For Geeks 