This article was published in the Nov 98 issue of Microsoft Certified Professional Magazine:
MICROSOFT CERTIFIED PROFESSIONAL MAGAZINE&127; www.mcpmag.com &127; NOVEMBER 1998 75
By Randy Cook, MCSE, SCSA
don’t have to feel like interrogations. Follow these tips and you’ll be
a success in no time—no matter what side of the desk you’re sitting on.
a consultant for a large network consulting company, I often must go
through a technical interview before being accepted by a client. Not
long after I joined this company, I was also asked to conduct interviews
for prospective consultants as part of our hiring process. My
experience on both sides of the desk has given me a unique insight into
the technical interview process , which I’d like to share with you now.
I recently had lunch with a friend from another firm who was interviewing for a very big project management position. Knowing that he’d just gone through a technical interview, I asked him how it went. He sighed with relief, knocked on the wood table, and said, "I made it! I’m so glad they didn’t ask me anything about my experience with Y2K issues!" He was celebrating the fact that the interviewers hadn’t discovered his lack of experience, despite the fact thatY2K issues were to be a major portion of the job’s responsibilities. This is a common reaction to the interview process. (Many people feel that " interrogation " is a more appropriate term.) The common fear is that, with one slip of the tongue, our skillful interrogators will proclaim us total frauds, undeserving of even the most menial positions. In reality, nothing could be further from the truth. You must rid yourself of this mindset if you want your interview to be a success.
First, be absolutely, brutally honest with yourself as to your current level of skill, experience, and training. Make sure your resume is up to date and reflects this honest appraisal. Have nothing to hide and you’ll have nothing to fear.
Second, think of the interview as your chance to discuss a subject you may rarely get to talk about at length but that you’re an expert on: yourself. How often do you get the chance to talk about yourself for nearly an hour and not be considered an egomaniac?
Third, interview the interviewer. This is your opportunity to discover if this position is right for you. Think of it this way: You’re the expert on your skills and background . Your interviewer is the expert on what the position requires. Don’t let this be a one-sided conversation. Ask questions. Many technical interviews are more assessments of your skills than traditional job interviews; but don’t let this intimidate you. Be curious. Be confident.
I always remind myself that the person conducting the interview has more reason to be nervous than I. (Of course, this isn’t helpful when I’mthe one conducting the interview, but I have another tip for that.) Think about it. If you make a mistake and accept a job that isn’t right for you, you can always move on to another job. The interviewer who recommended you , however, is left with the reputation of having done a lousy job.
Finally, do your homework. Find out as much about the company and the project as possible before the interview.
One of the weirdest technical interviews I ever experienced turned into the best use of all of the advice I just gave. It’s also the best example of how not to conduct an interview.
I arrived early because I was told I needed to fill out a form. The form turned out to be a questionnaire that had me rate my skills from 1 to 5 on over 200 applications and operating systems. (I was tempted to write "MCSE!!" across the middle in huge block letters, but I resisted.) I finished the questionnaire prior to my appointment time. Then I waited and waited. After 30 minutes passed, I asked the receptionist if we needed to reschedule. She made a quick call and assured me that it would only be a few more minutes.
Each of the participants had a copy of my resume and the lengthy questionnaire, but I didn’t see anyone refer to them. Instead, they each asked me a question from a typewritten sheet, which looked to be a series of questions and answers that someone with a technical background had given them. If my answer didn’t fit the answer on their sheet, they’d ask the resident techno-type if "that was right?"
I’d love to tell you that I walked out, throwing them a cutting yet witty barb from over my shoulder. Reality is always slightly less colorful, however. I answered their questions to the best of my ability, asked a few of my own, and didn’t let the situation anger or intimidate me. During my questions, I discovered they recently had several network administration jobs open up—they wouldn’t tell me why, which answered the question. I also discovered that they were looking for some-one who could do whatever it took to fix their network problems. Now, after more questioning, it became apparent to me that "whatever it took" meant long hours with no overtime compensation and no additional budget, and the network still had to be up during extended business hours. After an hour, they had run out of their prepared questions and said they’d let me know of their decision. Needless to say, I didn’t waste time getting back to my car.
I found out later the next day that I had "passed" and was invited back for the next level interview. I had seen all I needed to see and heard all I needed to hear to make my decision: I declined the offer. I’ve found that the best results come from a less formal approach, the complete opposite of the interview I just described. Many of the interviews I conduct have been over the phone. This is primarily because of my schedule — it ’s much easier for me to set up a time to talk with someone in the evenings. Also, and I’m sure opinions vary on this point, I find people much more at ease under these circumstances. Think about it:
They’re at home; I’m at home. No office stress, no rushed lunch meetings; just two people chatting on the phone.
Is It a Fit?
Here are a few tips for determining how well someone will fit the needs of the available position. First, as I’ve just recommended to interviewees , do your homework before the interview. Read the person’s resume. Check into the company where the person is currently working. Prepare some notes for the interview. There’s nothing more nerve-racking and unproductive than to have to resort to the standard, "So, tell me about yourself " or "Where do you see yourself in five years?" It’s often just a lazy way of covering up for the fact that the interviewer isn’t pre-pared. (Unfortunately, all interviewees should still have answers prepared for these questions.)
Second, keep it casual. This isn’t a homicide investigation. I usually start out by asking about the person’s current job. What does he or she like about it? What doesn’t he or she like? One red flag I look for is the amount of enthusiasm displayed when it comes to the IT field. I’m always wary of people who, when discussing a network problem, are more concerned about placing blame than about finding a solution.
I remember one young man who particularly impressed me during an inter-view. He told a story about how exciting his first day on the job was. The UPS failed during a power outage, and when the power was restored, the network was a complete mess. He said it was the best thing that could have happened to him. He’d found out more about their network in a few hours that he would have found out in weeks of on-the-job training. Talk about looking for a silver lining! I couldn’t help but be impressed by his willing-ness to learn and his dedication to his craft.
Third, find out about the person’s certification, training, or education. Being an MCSE, I know what it takes to earn the title. However, I also know that, without the day - t o - d ay experience of working with the products and regular refresher training, the knowledge will fade away. Rarely will I ask a "test" question; instead I try to trade war stories. I’ll relate an experience where I was able to solve a problem because of something I read or learned while studying for an exam. My goal is to get the other person to tell me a similar story. Usually, this gives some insight into the person’s depth of knowledge and experience.
Fourth, try discussing some new IT-related item in the news. Our business is constantly evolving, and I’m always looking for people who like to keep their skills sharp. Ask if the person is studying for more exams or learning any new soft-ware. Ask what trade magazines the per-son reads. During Windows 98’s early beta testing period, I referred to it by its beta name by asking an interviewee if he’d had a chance to work with Memphis yet. There was a slight pause before he replied that he didn’t get to travel much. If you look away from this business for two seconds, you can get left behind. Some of the best recommendations I’ve given have been to people I know stay in touch with current IT trends and developments. Finally, be brutally analytical. Look at the facts and make a value judgment based on what you know about the position and the person. You won’t be doing anyone any favors by approving someone for a position for which he or she isn’t ready. It doesn’t do your own professional career any good, either. I always ask myself if I want my name stamped on this person’s resume. This mindset helped me when I had to give a thumbs-down review of a prospective hire. The young man had obviously misrepresented himself to our recruiter. He had several fabricated items on his resume regarding his training and experience. In this interview, I did ask many test questions to prove to myself (and to the interviewee) that he wasn’t what we were looking for in a consultant.
This is obviously a very rare occurrence, but the point is that you must remember that your name will be linked to this person’s performance.
Behind the Desk
If you don’t do technical interviews for your company, think about trying it. It has helped me better understand the process, and I know it has improved my skills when I’m the one being interviewed. Make sure you have reasonable expectations for each candidate. Ask you r recruiter about the position for which the person is being considered. A candidate being considered for a first-level user sup-port position wouldn’t need the level of knowledge an NT WAN administrator would need. Adjust your questions to match the needs of the position.
Consider the phrasing of your questions. Try to ask questions that’ll start a dialog rather than test your interviewee. For example, "What’s the biggest problem you’ve faced when configuring DNS?" is better than "Explain DNS to me."
In Front of the Desk
Wear clothes that make you feel comfortable. If you feel that wearing a suit is needed, then wear one that fits. If you aren’t comfortable in a suit, then go business casual. The important thing is to give a positive visual impression. If you feel confident and comfortable, you’ll surely do well in any interview.
Use mental imagery. I know this creeps into the "who needs it" category for many, but it has certainly worked for me. My favorite trick is to imagine the person sneezing without a handkerchief. Whenever I feel myself getting nervous or intimidated by someone, aaaaaahhhh-chooo! It never fails.
The best way to get good at something is to do it. The worst time to interview for a job is when you need one. Go out on interviews any time you get the chance. Ask friends to role-play with you for practice.
During a tech interview, if you don’t know the answer to a question, just say so! There’s nothing more obvious than someone faking his or her way through an answer. Albert Einstein said, "If you can’t explain something simply, then you don’t know enough about it." Make sure you’re giving the interviewer the benefit of an accurate assessment of your skills. Most important, remember that this is an opportunity for both parties to see how best to match the needs of the position with the skills of the individual.
When compared to all of life’s pleasures, I can’t say I’ve ever really enjoyed being interviewed or interviewing someone else. But I can say that I’ve enjoyed the benefits that have come from doing it right. Good luck and gesundheit !Randy Cook, MCSE , MCP + Internet, SCSA lives in Richmond, Virginia. A Senior UNIX System Engineer, he specializes in Windows NT/UNIX WANs, Sun Microsystem's Solaris and Exchange Server. He can be reached at firstname.lastname@example.org or via his Web site at http://www.rcook.com
Work History - Published Articles - Resume in Word 6.0 - Resume in ASCII Text - Home