Article candidate

**Muqtar SGT_Clintok** · 01-21-09, 07:46 PM

Title: Interview Tips for IT folks

Intro:
Real-world observations from the hiring side of things

Body:
I manage nine network engineers directly, and work within a team of 40 engineers who provide Tier IV IT support for the military. Over the past year I have taken on the role of technical screener/interviewer for people being hired. Below are some things that sink people time after time when interviewing.

* If you cannot discuss or answer questions on the subject, take it off your resume.
When I interview people, I am usually pulled away from my job. I don't have a long time to digest and pore through resumes. I read through experience listed and look for what people advertise on their resume. When I see specific skills mentioned, it draws attention to the subject and I focus on that during questioning. If you cannot go into details on a skill, it is going to show. The analogy I frequently use is that when people claim they know how to swim, the first place we are going to visit is the pool.

* If you do not know the answer to a question, admit it. Do not try to improvise on technical subjects. When people are asked questions that they do not know and try to answer anyway with something other than knowledge, it is a huge mark against them. The interviewer may not make a huge issue out of it, but you just struck out. I would rather see someone tell me flat out, I do not know the answer to that because I haven't worked with it up to this point. In most cases, a serious interview is going to consist of someone who knows the answers to the questions they are going to ask and won't be fooled.

* Try to focus on what you have been doing within the past year or two.
I rarely pay any attention to the information about the jobs you held beyond the past 6 years. Technology moves quickly, and (at least in my case) people understand that skills go stale after you have been busy doing other things. If you can find a way to steer the interview in the direction of what you are freshly familiar with, you will be better off. One of the most successful people I have interviewed to date stopped me and flatly said "I may not be able to answer all the questions on technologies you are interested in, because I don't work here yet. Could I give you a chance to see what I know about where I currently work?" He then white-boarded the overview of his current network, and it showed that he knew his job in a different environment.

* Try to avoid power phrases and jargon, and be real. Some phrases that make me laugh when I hear them:
“I am a team player” (sorry TTP)
“I think outside the box”
“My biggest weakness is that I work too hard.”

A couple of questions to break the ice and probe familiarity:

-Binary - What does a 32 bit IP address mean in your own words?
-CIDR - Explain to me what 192.168.101.128/25 means. How many networks, and how many hosts.
-DHCP - Describe the service path of a DHCP request. What is a DHCP relay agent, or helper address and why is it necessary.
-DNS - Name a few of the different types of DNS records and describe their function. Name a few of the different zone types and describe their differences.
-TCP/IP - Describe the difference between TCP and UDP. What purpose does the TCP "Three way handshake" have?
-NAT - Describe Network Address Translation and how it works.
-What is the difference between layer 2 and layer 3 of the OSI model?
-What protocol does "ping" use?
-Explain the difference between Forests, domains, and OUs in Active Directory.
-Can you publish software using Group Policy?
-What are the three scopes and two types of groups in an Exchange enabled Active directory environment? What are the differences?

These questions are designed to test your core skills when working on an Enterprise Microsoft network. The questions often branch off into more advanced lines of questioning.

Whatever your discipline is, ensure that you are able to discuss some of the core skills with ease. Try directing the conversation into an area where you are able to demonstrate familiarity. Spending a lot of time reviewing proprietary business processes (such as your mastery of that 16-bit legacy timesheet application at your last company) probably wont carry you far in the interview. Instead, read into the job description or call ahead and see what the company's interest is in, and brush up on your skills if you have them. If you don't have any of the skills that the person is looking for, thats a red flag.

Hopefully this article has provided you with some insight from the other side of the table, and has helped you benefit from the mistakes of others.

**Adsartha** · 01-21-09, 07:50 PM

I doubt I'll beat Walker to the first reply, but the main thing I see is that this needs, both visually and textually, a conclusion. Visually, because ending it with the set of questions you often ask trails the article off and doesn't end it with any punch, and textually it's the same thing.

The rest of it looks good, though.

**Walkerxes** · 01-21-09, 07:52 PM

Looks good! I'd advise to try to make it more visually stimulating. For example, as you have a kind of bullet style working, try bolding the first sentence after each asterisk.  If you can find or think of images that might go along with this, that would also help. Don't need 100 images, even one or two would help break it up and make it more appealing to the eye.

Little tweaks like that will keep the reader interested enough to get through the whole thing.. even for a relatively short er article like you have.

Even if you only ind some generic openshare type pics of people taking interviews or something.

One very minor typo that I noticed.. and I'm actually gonna take the liberty of just fixing it quick

Adsy, you beat me only because I typed more

[edit]
yeah, I agree with Adsy.. a conclusion would help close it. It does end kinda open-ended.

**Potemkine** · 01-22-09, 12:26 AM

what they said

**Muqtar SGT_Clintok** · 02-09-09, 04:07 PM

This is not a dead initiative. I will put forth some more content on it this week.

Sorry to drag my feet, I am a bit stumped on where to go with it from here.