Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    154
  • comments
    121
  • views
    115074

Interview tips

Sign in to follow this  
khawk

210 views

Here are some tips if you're interviewing for an entry-level or internship position. These tips are based on my experiences of interviewing people for entry-level positions, including what I looked for in candidates and what would be automatic NO's for a candidate. I'm generally a hard ass when it comes to interviewing (I've been labeled very difficult by those who I have hired), so while these may not apply to every interview situation, you may find some of it useful:

1. Eye contact. Give it and give it consistently. However, do not stare at your interviewer's eyes. That freaks me out. At the same time, do not glance around the room (shifty eyes) and do not stare at the floor. I read both as a lack of confidence, with staring at the floor marked as automatic NO. Glancing around the room reminds me of a trapped animal in a situation it really doesn't want to be in that is looking for any possible means of escape. That's not exactly the best way to handle an interview.

2. The handshake. You better give one when you say hello and when you say goodbye, and you better give it firm (both male and female), but not squeezing. Eye contact is essential. Bonus points for candidates who say my name during the goodbye.

3. When asked technical or problem solving questions, then give me what I asked for. For instance, if I ask for code, then give me code. It can be pseudo-code, but it needs to be algorithmic in some form. DO NOT give me a diagram or flowchart describing how you would solve the problem. I want words, algorithms, code, if that's what I ask for. If no end-result is given, ask for one (see #4 - attention to detail). If still no end-result is given, make it CODE.

4. Attention to detail. Do you notice what I have on my wall? Do you notice what I have on my desk? Do you notice my books? Do you catch the hints I give you with my hands when I describe a particular problem? (yes, I give away the answer with my hands to one of my interviewing questions) What words do you use to describe yourself? What words do you use to describe your impression at the company? What have you noticed about our environment? Have you visited the company website? Do you ask questions that are require detail for answers? Detail-oriented engineers catch issues others don't, notice patterns faster than others, and write higher quality code. Details are often what separates the best from the very good.

5. Think outside the box. Show your creativity. Don't be a whacko, but show some ability to think beyond what you learned in school.

6. Show interest and initiative. Ask questions about me. Ask questions about the workplace environment. Ask questions about your role should you be hired. Show interest in the company and show intiative in wanting to be a part of the team.

7. Immediate NO: people who want to work on "fun" stuff. If you say the word "fun" in the context of what you want to do at the workplace, then consider yourself as having failed the interview. You can say "enjoy", but we're not at work to have "fun". We're at work to help the business make money, and luckily most of us enjoy our role in doing that.

8. Don't give up on problems. Not only does that show a lack of confidence, but it shows a lack of ability, a lack of desire, a lack of thought process, and a lack of passion. Immediate NO if you give up on something, because if you're going to give up on something for an interview, it's almost guaranteed that at some point, likely at a critical point, you will give up and/or not perform at the level expected of you.

9. Know what's on your resume. In fact, bring a couple copies with you and hand them out, especially if they've been updated. DO NOT stretch the truth on your resume. When I comb through it in the interview, I will likely figure out if you stretched or lied. Sell yourself, but be honest about it. I like ethical people. Most businesses like ethical people.

10. Enjoy yourself. Typically during interviews my goal is to make the person crack. No joke. My goal is to see one of several things: sweat on the forehead, shaky hands, sweaty palms, verbiage promoting extreme worry and anxiousness, nervous tendencies like shaking a leg, tapping a foot, or tapping a hand, shaky voice, or simply the person says they can't solve my problems because they can't think straight. I've had each of those happen in interviews over the last year. While none of those are a definite NO for me, I look to see how well you handle the pressure. Can you take an authority figure hammering away at you when you don't really know the answer? Are you decisive? Can you make the quick decisions on the spot with no referencing or research?

That's 10 tips. I have lots more, so maybe I'll post them soon. Again, those are all based on my own experiences interviewing entry-level and internship positions for software engineers, so take what you will out of it.
Sign in to follow this  


3 Comments


Recommended Comments

Thanks. I have an interview on Friday so this will become helpful. It's not in the industry, but it's something. Wish me luck!

Share this comment


Link to comment
Some other things that can help when interviewing:

Bring stuff you made.

When I interviewed for my current job, I brought:

A copy of Isometric Game Programming with DirectX 7.0
A copy of Game Developer's Guide to Cybiko
A copy of Focus on 2D in Direct3D
A copy of Focus on SDL
A copy of Game Programming Tricks of the Trade.
A cybiko with a game I had written for it loaded onto it.
A CD with JetLag 2003 and source code.

What I should have ALSO brought:

A copy of Hatfields and McCoys
A copy of Emergency Rescue Fire Fighters
A copy of the PC World Magazine with the (admittedly really bad) review of ERFF.


Ultimately, none of these things mattered for my interview, as I was essentially hired before I walked in (people who have DirectX experience are in short supply in my area).

Bringing stuff you made, especially if it is available to the public like books or published games, *CAN* be a double edged sword. For example, Kevin would not be very impressed with book authorship since he is himself an author, but he would recognize that yes, you can actually finish things, so not all of the value is lost.

When I interviewed at my company, at one point I noticed a copy of "Special Effects Game Programming" sitting on a shelf. I think they /MAY/ have been impressed when I picked it up and said "Hey! Mason's book!"

Or maybe I'm not helping anybody... looking back at this post, *I* am impressed by the things I've done, and I'd hire me in a second if I didn't know already how much of a slacker I am.

Share this comment


Link to comment
Another good technique is to relate questions back to your experience. For example, when asked "how would handle situation x?", try to relate to something concrete you've done, but don't stretch what you've done. Only relate to a real and relevant experience (unless it's pretty damn impressive/funny)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!