First time technical interview advice

February 20, 2008 2:01 PM

I'm a college freshman about to experience technical (CS) interviews for the first time. What can I do to prepare?

I'm a freshman studying CS at a large public university in the US with a top 10 CS program, and I've been offered some interviews by some large software companies (large as in, unless you're running *nix, you're using their software) for internship positions. However, I've never actually interviewed for a technical position before, and would like to be as prepared as possible for this first round.

What can I do to prepare for these interviews and what advice can you offer?

posted by comwiz to work & money (15 comments total)

Investigate the companies you'll be interviewing with. Learn about their products and the tools they use to make them. Do it the day or two before the interview so it's still fresh in your mind.
posted by kindall at 2:12 PM on February 20

Michael Pryor's "technical interview questions, brain teasers, puzzles, quizzles (whatever the heck those are) and other things that make you think".
If you list software competencies on your resume, be prepared for very detailed questions (as in, "Ah, I see you list Linux - what does ps -ef do?")
posted by djb at 2:13 PM on February 20

You could also try finding out about the people who will be interviewing you. If you won't be told who that is until just before the interviews, why not bring along a phone with Internet capabilities and google them before going in. I've tried it - it works.
posted by Claypole at 2:17 PM on February 20

The technical interview consists of a series of questions chosen by the interviewers to test your knowledge, problem solving skills, and personality fit. But anyone who's interviewing a college freshman knows that you won't know anything, so I wouldn't expect hardball algorithmic monster questions.

Depending on what you've been taught, know either your OOP or functional programming concepts. For example, if you've been studying Java, be able to explain how and why to use polymorphism, inheritance, and encapsulation. Some basic knowledge of algorithms and data structures wouldn't hurt, but don't go buying textbooks just to acquire a superficial knowledge - you only need to know what you've learned from school and from your own projects.

Speaking of which, any projects you've been doing as homework or for fun are great topics for you to bring up when you're asked about your skills and interests. Emphasize your creativity and your ability to recognize and solve problems.

All this notwithstanding, your interview is likely to be mostly about attitude. Everyone wants an optimistic, hard-working intern who's passionate about the craft of coding. At this point in your career, hard knowledge is mostly a bonus.

Good luck!
posted by svolix at 2:20 PM on February 20

Great advise above, but also know how to demonstrate a Bubble sort.
posted by Slenny at 2:32 PM on February 20

If your school offers it, set up some practice interview sessions. When I was interviewing after graduation I found it enormously helpful to set up and go to interviews for positions/companies I had no desire to work for, I just wanted to experience a variety of interviews so I would remain relaxed during the ones I cared about.

As others say, I wouldn't sweat the the technical details. I interviewed for a very technical position developing HPLC machines, I was really worried since I had very little experience with them but the session turned into a general discussion of the instruments and what the company wanted to do with them (with a lot of off topic breaks into other areas of science). They were much more interested in me, how I handled myself, and how I got along with the people already in the department, instead of whether I knew all the details of the position. I got a second interview with the big boss and a pretty quick job offer. For entry level jobs the company probably has methods and procedures they want to instill in you, they're not looking for someone to breath new life into a developed program.
posted by Science! at 2:44 PM on February 20

I was in the same position - CS freshman interviewing at some the large software company. I got the internship and now work there (and have taken their interviewing training). Some of the advice here is probably specific to that company.

svolix's advice is solid; the key for attitude is to remain confident when you know you're right and admit when you don't know what's being talked about. Assuming you know your stuff, enthusiasm and confidence can cover for a lot of slight deficits, but if you sternly insist that a Java class can only implement at most one interface, you won't get very far*.

To practice, you should be able to talk coherently for at least 5 minutes each about the projects you list on your resume (you have projects listed on your resume*, right?), and be able to answer questions like "Tell me about a difficult experience you had with X while doing Y" *. The great part about these questions is that they don't require any expertise on the part of the interviewer, so you can just have your friends ask you random questions about what's on your resume. If you have multiple technologies listed on your resume (you have multiple technologies listed on your resume, right?), be able to talk about them in a constructive, comparative fashion* ("When would you use C# instead of C++?"). Don't put anything on your resume that you don't actually know about* as it's an easy way to make the interviewer doubt the veracity of the whole thing.

You'll be expected to write code on a whiteboard*. Practice this. If you think you have a reasonable shot at this job, you should be able to write at least three sorting algorithms down in the language of choice on a whiteboard without making yourself look like an idiot. No matter the problem, you will have a bug in your code, the interviewer will probably find it, and [s]he'll ask you to find it. A key skill here is to be able to act like the runtime - execute a program, in your head, based on what is written, not what you think it's supposed to do*. Write ten methods for common tasks (sort, min/max, traverse a binary tree, etc), then find the bugs in all of them without running the code. Also, if the interviewer can't find a bug in your code, they'll complicate the problem until you do, so don't count on memorizing anything, and plan for adding new lines of code in the middle. For a CS freshman they might start with a very simple problem (reverse a list in place?); this should be easy for you*, knock it out of the park.

If you find yourself in a seemingly non-technical interview while in a product group (often after 3+ technical interviews), this is a good sign. Talk about your passion for software* and why writing word processors (or whatever the group you're interviewing with does) would probably be the greatest thing in the world.

Something you probably haven't encountered yet is that a full day of interviewing is extremely draining. I got a solid 9 hours of sleep before my interview, but still crashed promptly at 6 PM for a nap when it was over, something I never do. Don't turn down a beverage just to be polite - interviewers know how hard it is and that you'll probably be dehydrated regardless of how much you drink.

* I've seen people dramatically fail at all of these
posted by 0xFCAF at 2:50 PM on February 20 [4 favorites]

You think they're going to give a freshman a real technical interview?
posted by smackfu at 3:02 PM on February 20

Maybe things have changed in the last 7 years, but when I was doing internship interviews, I was asked technical questions in all of them. So yes, I do.
posted by 0xFCAF at 3:06 PM on February 20

I don't work for a large company, but when I interviewed college grads last year, I gave them technical questions and asked them to write code. If they can't do something simple on the board during an interview, I doubt how they'll do something complicated without supervision in a cubicle.
posted by meowzilla at 3:21 PM on February 20

You're going to likely get asked a bunch of brain teasers. Go take a look at the standard ones (e.g. there is a soda machine that gives out 10 oz or 12 oz sodas on tuesday, how can you tell it's wednesday?) Got take a look at a couple of those.

You'll get asked some thing like string sorting, or string reversing questions. Take a quick look at thoses. There are lists of these common brain teasers and questions, your interviewer is probably looking their to find them too.

I always like it when a candidate first says "I don't know, but here's what I think may be the answer" instead of 15 minutes of BS when they pretend to know what they are talking about.

Have a recent copy of your resume with you just in case they don't have one.
No need to spend tons of money on 'nice' resume paper.

You'll likely get asked some standard OOP questions, threading questions, etc...

Good luck!
posted by bottlebrushtree at 5:47 PM on February 20

Some may disagree with me, but in my 33 years of professional programming, I think a paraphrase of Shakespeare sums it up: "The fault, dear Dilbert, lies not in our coding knowledge, but in ourselves." I have seen so many extremely intelligent people who just did not have much of a work ethic, or obsessively hard working individuals who had no concept of teamwork, or hard working intelligent people who routinely lied about their project status to managers, I couldn't give you a total. I think the most valuable person in a software organization is a reasonably intelligent person who is eager both to learn from others and to circulate back to the team what they have learned, and to commit to the best of their ability to meet the goals set for them.

In addition to following standard interview do's and don'ts, and following the advice given above, I would try to present myself as the latter kind of person. Now, in the real world some hiring managers just care about salary or won't like you because you look like their good for nothing nephew, but to a results oriented manager who has been burned too many times by the former kinds of people, you would probably be very well received.
posted by forthright at 6:59 PM on February 20

If I ask you a brainteaser, say, "how many gas stations are there in the US? Show me how you would arrive at the result," don't answer by telling me you'd look it up on Google.
posted by feloniousmonk at 7:40 PM on February 20

In addition to looking at that technical interviews website mentioned above, you should have a ton of enthusiasm about technology and be able to articulate that enthusiasm. But if we're talking about first round on-campus interviews, you've got one 30 minute shot to show them you're not an idiot. The impression clock starts ticking from the first handshake. Have good answers to questions like details about projects you have done, bugs you have faced, etc. And then be prepared to answer one moderately difficult but short coding question. Reverse a string, that sort of thing. And have good questions for the interviewers! Something better than "when will I hear more?"
Being a freshman, though, don't get your hopes up. MS will hire freshman interns, but you have to be quite exceptional. Internship programs are mostly for the company to sell themselves to potential full-time hires, and even sophomores are at a disadvantage because they don't pay off as well as juniors in terms of conversion rate.
posted by ch1x0r at 8:31 PM on February 20

This thread might be useful. Also, 0xFCAF's advice is spot-on.
posted by harmfulray at 8:51 PM on February 20