When preparing for a technical interview, most people forget to think about how they answer questions.
Even though you’re focusing on technical topics, make sure you avoid some simple statements that could spoil your chances to land that job.
#3: My Coworker Was an Idiot
Whether or not it’s true, don’t let this statement come out of your mouth.
You will often be asked questions in a technical interview about mistakes you’ve made or witnessed in your career. Your job is to describe the cause of the problem, your response, and what you learned.
Whatever the incident, be cautious pointing the finger of blame. Calling out your colleagues for incompetence or stupidity will bring you down as well. After all, why didn’t you stop them? (Tip: you don’t want to answer that.)
Instead: Focus on the problem with the technology and the process. Talk about your own role– take responsibility for both your mistakes and your achievements. Talk about changes which would prevent the problem from happening again. (Bonus points if you can tell a story about helping make that happen!)
#2: That Wasn’t My Job
Technical interviews will often touch on topics outside your experience. This is no accident: screeners want to see how you react to questions either above your level or in a different area.
When the conversation goes into these areas, never make excuses. Many people try to provide explanations which boil down to “I don’t know that because it wasn’t my responsibility.” This is a huge mistake: you immediately sound like you have no passion, no intellectual curiosity, and only do what you are tasked with.
Instead: It may seem counter-intuitive, but admitting when you don’t know something can work hugely in your advantage in a technical screening. The key is to do so calmly and with confidence. If you have a theory as to how you could figure the question out, or strategies you might take to solve the problem, offer them!
#1: I’m Sorry
Unless you spill coffee on someone, apologies have no place in a technical screening.
You may apologize without even realizing it. When in a high pressure situation, it’s natural for many people to apologize if they feel it isn’t going well. The more nervous you are, the greater chance that you’ll start apologizing.
Apologizing when you don’t know things doesn’t show your strengths. Instead, it gives an impression that you’ve given up on the question.
Instead: Even if you’re on the tenth question you don’t know the answer to, keep your chin up and keep going strong. If many of the questions are on the same topic, ask if the technical screener has a good references where you could learn about that topic. You can try to save the situation by doing some research and sending a great follow up email after the screening. Whatever you do, proceed through the interview with confidence— it’s never too late to succeed.
What to Remember For Your Technical Screening
Your greatest mission in your technical screening is not to get all the questions right: it’s to best represent how you solve problems. Even if you don’t know answers to half of the questions, you can make the screening a success if you show your strengths along the way.
I have seen quite a few situations where a technical screen shows that a candidate absolutely can’t handle the job in question, but the screener is still incredibly impressed by their performance. In many of these cases, the candidate lands a job at the company— it’s just not the job they initially applied for.
6 Comments. Leave new
Hi Kendra,
Well said and it is really worthful for exp…Guys!!
Thanks,
Rama Udaya.K
Excellent post. Thank you very much.
As usual another great post from Kendra! Excellent points to remember. I have a possible interview coming up next week and will use all of these. Especially #1!
I used to conduct technical interviews. One of the oddest things to me was the number of people who actually seem proud of their ignorance. Like their disdain for knowledge implied hipness or toughness. A related problem is the candidate who takes the attitude of “why should I have learned that, it’s too easy, I’ll pick it up on the fly.”
What I wanted to hear was an honest self assesment coupled with a desire to learn more and improve. Even if someone was needed for an immediate role, ideally that person’s tenure at the company will exceed that role. To do this effectively requires a positive, but realistic, attitude and a desire for learning.
Don’t sweat the small stuff. Devil’s advocate time.
#3 – Agreed. Don’t focus on the negatives and don’t single people out, especially in group interviews.
But that doesn’t mean you have to be a kiss-ass about your ex-coworkers. The good thing about working with idiots is that it’s a shared human experience we’re all intimately familiar with. In public anything but false professional face-saving is a no-no, but in private one-on-one interviews with other developers letting the word slip might kindle the flames of a friendship bonfire of mutual understanding.
#2 – Interviews will start off with the prospective employer grilling you on what you cannot do. Your task is to flip the script and take on the role of teaching them about the benefits of generalisation/specialisation and how that fits in with what you can do.
They want clustering but you don’t know clustering? Sure, it’s okay to say you don’t know it, that your last workplace was highly specialised and didn’t encourage knowledge sharing despite your best efforts at setting documentation stardards (wiki, document templates you created and took with you, your knowledge of best practices and cross training). Hey, what edition of SQL Server are they using anyway? Standard? Did they know it’s going to cost them double to upgrade to Enterprise edition so they can even use clustering? What problem are they trying to solve? Well… jeez… that sounds like it could be handled with replication or log shipping, which WAS your speciality.
#1 – Absolutely true. Unless you don’t want the job, then say “Thank you for your time, but I’m sorry, I don’t think this is going to work out,” possibly along with a small synopsis of why.
I’m afraid you’ve rather proven my point.
First, if you ever say something like “my last workplace was highly specialized and didn’t encourage knowledge sharing despite my best efforts,” what the interviewer hears is “I’m not good at making friends at work, and I make excuses about it.” You’ve just told them you don’t play well with others– but you see that as management’s fault.
Blaming your employer is just like blaming your coworkers: it makes you look bad. That doesn’t mean you need to “kiss ass” as you say. It just means avoiding these traps.
The clustering example you give is somewhat perfect. In your example you rule clustering out because it can’t be done on Standard Edition. That’s not correct, you can have two node clusters in SQL Server Standard Edition since SQL Server 2005. You go through the example saying everything is obvious, but what you’re really telling the interviewer is that you have huge blind spots. Your example says “I know a few things, and I insist on implementing things the way I know them.”
It’s great to talk about what you know, but you need to show that you are aware of your blind spots and will actually investigate if there may be viable solutions that you don’t know about yet. Sure, talk about your experience, but be very careful making claims about what things can and can’t do if they aren’t your specialty. Saying that you don’t know much about them and then talking about what you’d investigate (licensing, interoperability, etc) is a much stronger approach.