Having witnessed literally hundreds of interviews, I can speak with some authority on what works and what doesn't from an interviewer's perspective. There is outstanding advice out there for general interviewing ("Check your resume for spelling mistakes!", "Nobody has ever been refused a job for wearing nice clothes!", "Do not become confrontational!") the advice is scant for the technical portion of your interview. Here my Top 10 mistakes made, and how to avoid them.
1. Saying, "You Can Always Look That Up," Responding to a Basic Question.
If there is an abstruse question that required detail knowledge, you may well say you don't know the details right now. But if someone asks you, "What character terminates a statement in C/C++/Java?" and the word "semi-colon" isn't shooting out of your mouth at the speed of a Lincecum pitch, you are unlikely to impress. That question is the programming language equivalent of, "What's the letter after 'C' in the alphabet?" Surely, you wouldn't answer that you can look that up online!
Is the question you got asked a basic question? It helps if you consider when it was asked. Interviewers typically follow a sequential strategy - one field after another. They either aim low and go high, or they go the other way around. If you are interviewing for a junior position, they'll typically start low, asking you easy questions - which you have to answer easily If you are interviewing for a senior position, they'll typically start high, asking you tough ones. Depending on how you did, they will adjust their perceived level. If you don't answer they way they expected, they will adjust down. If you do, they will aim higher.
How do you react if you are asked a basic question and you don't know the answer? Tell the truth: you don't know the answer. You may say that it slipped your mind, or that you are nervous. As long as there aren't a lot of things you don't know, it's OK. And if there are lots of basic things you don't know, there just isn't a good save at all.
"You can always look that up" doesn't work. Any interviewer will have heard that a few too many times from unprepared candidates, and the arrogance that comes with the statement - essentially accusing the interviewer of asking a frivolous question - reduces good-will.
2. Lying About Padding Your Resume
So you made the cardinal mistake of not sending out a copy of your resume tailored to the job at hand and the interviewer is amused by the list of 50 programming languages you have on there. Obviously, you are not an expert at all of them, and you probably barely more than heard the name on some of them. Unfortunately, the interviewer happens to be an expert on the last language on your list. So (s)he is going to ask you a question about - I don't know - the main distinguishing characteristic of FORTH.
Instead of acting surprised that FORTH is on your resume and explaining you made a mistake, that you had put it on there because you were going to take a mandatory FORTH class that got canceled, and take the results in stride, you guess. Horrible things happen. You see, the interviewer asked a question because (s)he knows something about that language/technology. If you open your mouth, you are likely to say something terribly stupid to someone who cares. Very, very bad.
Instead, be honest. Say that you padded your resume (and think of a good reason ahead of time), and beg to move on to a topic that really matters.
3. Sending Out a Generic Resume
This one angers me when friends do it. If you are applying for a position, make sure that your resume works for it. Remove everything that is unrelated and emphasize the things that match. If you are applying for a job as a Java programmer, all those years of System Administration are not going to do you much good. If you are applying for a SysAdmin job, all those years of Java programming will make you look suspicious and likely to have you head in the clouds and your nose stuck in the air.
Take the time and send out a resume that works. You don't have to write one resume per position - but you are going to apply to a set of job types, and if you are smart, you'll find that you will need only a dozen or so at most resumes.
Why do you have to do that? Because people are prejudiced. They are not prejudiced because they are evil or malicious, but because they have to read through thousands of resumes, and unless you match, you are out of the running. It's really not the interviewer's fault: what would you do if you had a day job and then the need to read hundreds of resumes on top of it? Surely you wouldn't spend a lot of time interviewing the person that doesn't sound like a perfect match when you have dozens of perfect matches available, no?
Additionally, if your resume is obviously tailored, it shows that you really care about this particular job. You can't imagine how many "smart" people write scripts that send their resume to anyone that posts any job on any online board. We started posting on Craigslist and had the same person respond to a job ad for sales, programming, accounting, QA, and admin!
4. Never Giving Up
An interview has only this much time, and the interviewer typically has to gauge not only how much you know (actually, that's usually the least important part), but also how you work and how you interact. The main question (s)he will want answered is, "Will hiring this person make my life more pleasant?"
When you get asked a technical question and you don't know the answer, don't dwell on it unless the interviewer demands it. Make a joke, say that you don't know, and move on. Always have a joke handy, by the way.
I have seen applicants get stuck on a question and leaving my mental presence to dive in a pool of wonder and amazement, trying to find the solution to the problem, while I was twiddling my thumbs, mentally trying to figure out the rest of my work day. I am a patient person, but even I would get a little annoyed after ten minutes of someone scribbling on paper and refusing to move on even after I said it wasn't really important.
There really are very few instances in which the actual answer to a question asked during an interview is really important. "Are you allergic to anti-hystamines?" when you are stung by a hornet comes to mind. In most cases, both you and the interviewer can survive if you don't know the answer, as long as you can find the answer to a lot of other questions.
5. Giving Up Too Easily
The opposite of Never Giving Up comes into play when your interviewer wants to know how you tackle a problem whose answer you don't know. Sometimes the interviewer will wait until there is a question that stumps you, and sometimes the interviewer will ask a question specifically because (s)he thinks you don't know the answer.
I used to ask all interviewees for Java position the same question, to which nobody ever knew the answer: "Why is the String class in Java static, immutable, and final?" Everybody knows that it is, since it is a major headache - whenever you want to perform any string operation, you either have to use a StringBuffer (which is NOT a string and needs to be made into one before passing it to anything else) or you have to copy the String as many times as required. Meanwhile, all major APIs use Strings as arguments. Painful!
I ask the question because it allows me to see how a candidate reacts to something well-know but not understood. The answer I'd like to see is, "You know, I never thought about that. Here are a couple of possibilities that come to my mind." Off we go brainstorming. I know the actual answer, having heard it from the Java inventors, but the correct answer is not half as important as the process you use to get to one, and the creativity and knowledge of the field you display.
If you just tell me, "I don't know and I don't care to know," you display lack of interest in the field of your work. A very troublesome sign.
On the other hand, if you ask the interviewer to explain it to you, you appeal to a very human instinct: parading around one's skills. Typically, interviewers love to tell you what you don't know and they do know.
6. Being Too Reactive
Interviewers, especially in technical fields, are frequently not trained in their function. As a result, they make frequent mistakes in their methodology even if their technical skills are top notch. You can suffer from that or use it to your advantage - it's really your choice.
In the worst case scenario, you find an interviewer that probes superficially and then digs in as soon as (s)he detects you don't know something. The problem with that is that you spend the vast majority of your interview talking about things you don't know. As a result, the impression will come up that you don't know much, since half the time you didn't know what (s)he was talking about- despite the fact you were knowledgeable about the vast majority of topics (but (s)he didn't probe).
In the best case scenario, you succeed in focusing the interview on areas of your expertise that you sense the interviewer doesn't know well. You also manage to avoid the opposite, areas in which the interviewer speaks with authority and you, well, don't.
How do you manage to avoid the worst case scenario and get to the best case scenario? Well, for one you structure your resume to emphasize topic related to the job, but unusual. You get a hook that many interviewer will latch on to, and you can get started there.
Even if your interviewer comes in with a list of topics to be discussed and doesn't guess about what to talk (which is the right way to do a technical job interview, by the way), you can avoid digging deep by simply stating that you feel unprepared in the particular topic at hand, and to please move on.
7. Not Knowing About the Company
Preparing for a job interview includes as one of the essential items that you learn about the company you are going to work for. Sometimes that's easy, as when you are applying for a job with a large corporation; sometimes it's harder. In any case, there is a ton of information you can glean about the questions you are going to get asked simply by the company's work environment.
Focus on a few important items:
- Do a search for the company on the Internet and see if there is any technical documentation listed - contributions to open source projects, forum posts from users with a domain email address, news articles about adoption of particular technologies
- Learn and use (if possible) the products of the company. If you apply for a job at Google, don't use a Yahoo! email address. If you apply for a job at Skype, make sure your phone number is a Skype number.
- Look at the technical staff listed on the web site and perform a search for them. That's most useful with small companies and gives you a general idea of the technical background you can expect.
- Look at the job description again and again. It will not only tell you what technical requirements are necessary, but also how they are valued. Does the description list "source code control" generically, or is a particular SCCS listed? The difference is that between someone who may not care all too much and someone that wants you to hit the ground running.
8. Missing the Interviewers' Skill Level
When your interviewer introduces h(im/er)self, when a question comes over, when a comment or correction is made, you gain valuable information about the interviewer. Some of the clues are human in nature - what mood is the interviewer in, are there time constraints, etc. From a technical perspective, the most important information is the skill level of the interviewer.
You have to try, as far as you can, to match the skill level of the person in front of you. If you detect a guru, try to speak as fluently and technically as possible. Throw in anecdotes of technical nature, pile on relevant and obscure acronyms, try to find something the interviewer doesn't know that you do.
If the interviewer is technically unskilled, you gain no points by being too hard to understand. You can use any gobbledygook and achieve the same results. You do gain points, though, for explaining things plainly and not overly complicated. Don't dumb things down - just make them clear.
At one of my jobs, I was interviewed by Marshall T. Rose, of IETF fame. We were on the phone for about five minutes and I got the job. How? He dragged me into a conversation about arcane details of HTTP and Tcl internals, things I knew extremely well. We conversed at the 100,000 foot level, and he really didn't need a lot of information to know that I could do the job.
At a different job, I was interviewed by the VP of Marketing, who was acting Head of Engineering. He asked me about login processes and we started chatting about best practices in the login/registration process. I explained why things are done a certain way, why things are not done a different way, and what ways are particularly onerous on users. For instance, I told him, any restrictions on characters in a password indicate that the password is stored in a database in cleartext - a huge no-no. The man had an a-ha! moment, I got the job.
9. Ignoring the Basics
I am always shocked when people apply for senior level positions and don't know the most basic things about their field of work. Yet it's something that happens extremely frequently.
I'll give you an example: HTTP is a text-based protocol. Requests and responses are formatted as text, newline delimited, with a "HEADER" colon "VALUE" format. The separator between headers and payload is a double newline. It's all extremely basic, and is both what's good (easy to debug) and bad (easy to forge) about HTTP. You can easily telnet into an HTTP server and send a well-formatted request and get a full response, both as text you could edit in vi.
You will not believe how many people I interviewed that didn't know cookies are headers in HTTP. The question is important, because many people do not understand why it is so easy to forge cookies, and hence why they cannot be relied upon.
Turns out object-orientation is a problem in this case. Many Java developers in particular have never had to concern themselves with Cookie headers. They never see them, as they are processed by the servlet engine/application server. They magically show up as Cookie objects.
It's fine for a junior developer to miss the basics. You will learn them eventually. But there are a series of things you have to expect of yourself after a while - and one of them is that you need to know how things work internally. Not just the encapsulation of them you find in your programming environment.
10. Blimping by the Buzz
I cannot tell you how many times an interviewer asked a question based on the latest discussions on Slashdot. If the topic of the day was The Year of Linux on the Desktop, I would get a question asked about KDE vs. Gnome. If the topic was Firefox, there'd be something about browsers (or HTTP fundamentals).
Of course you cannot expect things to work out that way, and of course you cannot focus your prep work around Slashdot - but you get an easy start on an interview if you are aware of what's going on in the world around you and are informed about the latest buzz. Besides, it shows you care about the technology world, which is something that is always good in a tech person. [The sad corollary is that if your interests revolve around partying and surfing, you probably don't want to mention that.]
Also, try to create accounts on every latest coolest site available. Play a bit with it, until you know what you like and don't like about it. Look for things like speed, response time, technologies used, etc. It takes surprisingly little time to do that, and the benefits are huge. Besides, you cannot imagine what kind of "street cred" you get from a low registration ID number.
Follow the buzz, stay ahead of the curve, and keep current.
No comments:
Post a Comment