But, I Really Do Know This Stuff…

Whether it’s in verbal Q&A or in whiteboard exercises, people often bump up against the limits of their technical knowledge. It’s to be expected, after all; we can’t know everything, and it’s the interviewer’s’ job to probe the extent of our knowledge.

I’m reminded of a quote from a former Secretary of Defense. To paraphrase: we know what we know; we know what we don’t know; but we don’t know what we don’t know. And when people go into an interview, they often don’t know what it is they don’t know until it’s pointed out to them.

So how do people handle it when they realize they can’t answer a question? Some people deal with it better than others. Some simply say, “I don’t know”, which is usually the best answer. However, others may guess or try to be more creative.

However, saying that you can simply “Google” the answer to a question is not being clever. Neither is saying that you rely on IntelliSense. I roll my eyes and groan (silently) whenever I hear those responses from candidates.

Don’t ever say, “I can’t answer that, but I really do know this stuff.” You’re not fooling anyone, and you’re just making yourself look bad. The reality is that you may think you know the subject matter, but you may be rusty. Just because you knew something five years ago doesn’t mean you still know it now.

Perhaps the worst kind of response is where the candidate rattles out a bunch of different answers hoping that one of them will stick. It’s kind of like one of those games on “The Price is Right”, where contestants have a few seconds to guess the price of an item. Whenever they get close they’ll start blurting out prices in succession, hoping they’ll hit the right number before time is up. But an interview is not “The Price is Right”, and offering up a dozen different answers hoping that one of them is correct will not win you any prizes.

Finally, keep in mind that if at the start of the interview an interviewer asks you to gauge your skill level in a technology, don’t say you’re an expert; they’re just setting you up to shoot you down! That’s why when asked, I never rate myself as higher than 7/10 in any technology. It’s better to set expectations low and impress than to build up and then disappoint your audience.

Whiteboard Exercises

If you are interviewing for any kind of hands-on development position you may be asked to go up to the whiteboard and write some code or markup. I have seen many candidates who were remarkably polished and articulate during the verbal Q&A fail miserably when they went up to the board. As the saying goes, these candidates talked the talk but they couldn’t walk the walk.

Why did this happen? I suspect it’s because many people have only a superficial knowledge of the technologies they list on their resume. They know enough to talk about it competently in an interview, but not to apply it in practice, especially under pressure. Or they may call themselves ‘Architects’ and may not have written any code in the past year or two. Or perhaps having to perform in front of several strangers just puts them outside their comfort zone.

To prepare yourself for these exercises you should practice writing code and markup yourself on a whiteboard. You’ll find that it’s a bit different from writing code in a Visual Studio style IDE with IntelliSense helping you out. You’ll have to think on the fly, and you’ll have to remember the important keywords and syntax. Once you’ve got that routine down pat you’ll be ready for the in-person grilling.

What Kind of Work Are You Interested in Doing?

I often encounter candidates whose experience spans front end development, business logic or middleware, and databases. If you interview with a number of people in the organization, and especially if you do so in a group interview, you might be asked which of these areas you want to focus on.

Is this a trick question? A trap? Well, yes and no. Ideally your interviewers will first explain what their own responsibilities are, so that you can tailor your response appropriately if you wish. Or you will be told up front what specific position you are interviewing for. But if you do not have this information, you will have to take a guess.

For some companies the wrong answer is to say that you are interested in all the areas. Unfortunately, that might be the right answer for other companies. You see, some companies (typically larger ones) segment their teams in front end / biz logic / data access teams, and people only work in one of those areas. However, at smaller companies it’s not unusual for people’s responsibilities to span multiple architectural tiers.

So how do you present a response to this question that does not rule you out for a specific position? Well, you’re going to have to finesse it. Something like, “My most recent experience has been in front end development, but I would be equally comfortable in the business and data layers.”

Modesty in Interviews

Candidates learn quickly that modesty doesn’t pay off in interviews. The “Aw shucks, my colleagues actually did all the work” approach doesn’t do much to sell your skills to the interviewer.

Still, vanity doesn’t look good either. One example is when candidates use “I” more than “we”. As in “I did x, y, and z” vs. “We completed this project.” It’s important to point out your accomplishments, but it’s also important to show that you are a team player.

So just how do you strike a balance between the two? Well, point out your contributions to each project you worked on. Explain what your efforts entailed in terms of technologies used, obstacles overcome, knowledge gained, and lessons learned. Give credit to others where credit is due, but also point out the value you added to the project.

As an example, contrast these two hypothetical paragraphs and see if your BS meter goes off.

“I led the team in requirements gathering, negotiating features with the product manager, and creating technical specifications. I created the architecture and high level design, identified risks and developed mitigation strategies, and performed the bulk of the implementation. I made sure the schedule was followed and resolved any team obstacles. The result was that I delivered the product on time with all key features and outstanding quality metrics.”

“As a part of the implementation team, I worked with the team lead, the product manager, and project manager on technical requirements and design. I advocated the refactoring of legacy components to improve quality and enable easier unit testing using NUnit. In this way I helped contribute to the overall quality and on time delivery of the product, while also learning more about Unit Testing and Test-Driven development.”

Body Language in the Interview

Body language consists of non-verbal cues. Your posture, eye movements, facial expressions – they all contribute to the ‘vibe’ that you give off. Unfortunately, many people are painfully oblivious to what their body is saying, even when it’s sending entirely the wrong message. This is partly why some people do well on phone interviews and yet do poorly in person, or vice versa. It’s the presence (or absence) of body language.

Some people might complain that taking such subjective matters into account opens the door to loads of other subjective factors. I could deny that, but then I’d be lying. Fact it, for better or for worse it’s impossible not to consider subjective factors.

So just how do body language and other subjective factors affect an interview? Speaking strictly for myself, here are things I look for in a candidate.

• Firm handshake – no “limp fish”.
• Sharp, alert, and focused – basically “on your game”.
• Enthusiastic about the job and the work.
• Confident without being arrogant.
• Smiles without faking it.

Conversely, here are things that turn me off:

• Arrogance.
• Slouching in the chair and behaving casually.
• Gestures that indicate dishonesty. I won’t give these away, but you can do your own research.

Once again this is just my own viewpoint, and other hiring managers may brush off some of these things as trivial and inconsequential. Horses for courses, as they say. But if it’s your choice to engage in the positive behaviors, why not give yourself the advantage?

More on Communication Skills

“Communication Skills” is a bit of a nebulous term. What does it mean? Well, the good ones include:

• Enunciation and clarity of speech


• Vocabulary, diction, and grammar


• Ability to listen


• Lucid, clearly articulated thoughts

Some of the bad ones include:

• Being argumentative (If the interviewer is blatantly wrong about something, don’t dwell on it).


• Trying to BS or guess the answers to things they do not know.


• Peppering the conversation with buzzwords to hide lack of in-depth knowledge.


• Rambling on about unimportant things, not knowing when to stop.

Regarding enunciation, clarity of speech, vocabulary, diction, and grammar – although people for whom English is a second language might seem to be at a disadvantage, that’s not always the case. Sometimes immigrants know English better than native speakers, at least at a formal level, since they are more likely to have recently studied English grammar and syntax. Most English speakers by comparison haven’t studied grammar since grade school.

The disadvantage that immigrants often do have is in the area of accents. Eradicating an accent is a difficult endeavor, and perhaps not even one you should bother with. Still, you can mitigate the effects of a strong accent by speaking slowly and enunciating clearly. Nearly everyone gets nervous at interviews, and nervousness often makes people speak faster. Resist that urge and speak out every syllable deliberately and clearly.

Note that “vocabulary and diction” does not mean you need to talk like William F. Buckley. However, you should avoid the use of slang and other informal speech. Also, you should speak in complete sentences whenever possible.

The ability to listen should be obvious, but you’d be surprised how many candidates I meet who don’t actually answer the questions I ask. I might ask “How would you use XYZ to do this?”, and they’ll proceed to rattle off everything they know about XYZ, while not bothering to actually answer the question about applying XYZ to the problem. Perhaps they don’t know the answer, or perhaps they’re just trying to impress me with their wealth of knowledge about XYZ. Or perhaps they’re preparing for a career in politics.

Finally, lucidity and articulation of thought should be obvious, but I see too many candidates who stumble over their own words. Again, this happens because they get nervous or excited and try to talk too fast, and their brains have difficulty catching up. If you find yourself in this situation, remember – take a deep breath and sloooow down. There’s nothing wrong with pausing for a few moments before you deliver your answer. It might even make you seem more thoughtful.

Mad Skillz, or What Does the Hiring Manager Look for?

Speaking strictly for myself, I look for the following in an in-person interview:

• Communication skills
• Technical knowledge
• Problem-Solving skills

I judge communication skills not just by how well you talk, but also by seeing how you handle ‘soft’ questions. Your vocabulary, inflection, enunciation, and tone of voice also factor in, as does your posture and body language. This is not to say that you should obsess over your every little movement, but you should remember that most and everything you say and do is being judged or at least noticed.

As for technical knowledge, that is evaluated by asking --well, technical questions. I try not to make it too much of a trivia contest, but I will of necessity ask both straightforward as well as obscure questions.

In terms of technologies I typically cover all the ones that a web developer at our company would use. This may also include databases, although admittedly a front end developer is unlikely to work heavily with the database except maybe for testing purposes. Certainly they will never touch a production database; team boundaries and Sarbanes-Oxley regulations will see to that.

Problem solving skills are difficult to evaluate in an interview, but that doesn’t stop me from trying. I ask the candidates some hypothetical design problems and also get them to write some code or markup on the whiteboard.

These exercises require a combination of technical knowledge as well as problem solving skills, and I find them more useful than purely abstract ‘Microsoft’ style questions. And as it turns out, some people who can answer the most obscure technical questions cannot write the simplest of code or solve the most straightforward of problems, and it becomes evident at this stage.

Finally, some people wonder whether the interviewer makes up their mind about the candidate within the first 10 minutes of the interview. I try not to let this happen; even people who sputter coming out of the gate they may redeem themselves in the latter part of the interview. Only rarely do I ever cut an interview short, and that only happens when it’s painfully obvious the person truly has no clue.