« Added Remove Paste Capability to Nopaste | Home | Ruby on Rails, Cygwin, and Git part 1 »
Interviewing, Part 1
By Jacob Cohen | May 3, 2008
This is the first installment in what may become a series of posts on how to do better in technical interviews.
Most technical interviews have a few key areas in which you need to demonstrate some skill or experience, such as problem solving, algorithms, data structures, programming language concepts, dealing with ambiguity, writing code, and communications skills.
Let’s take an example problem that might come up in a technical interview situation: printing a binary tree in depth level order. This type of problem tests several areas at once. First, do you know what a binary tree is, and how to perform various operations on them? Next, do you recognize that this requires a breadth-first search algorithm instead of the usual depth-first searches you would use to, for example, print the tree in value order? Then, can you pick relevant and useful data structures to help attack the problem, and can you write code that had a reasonable chance of compiling and solving the problem correctly?
If you’re weak in any of the above areas, you will have difficulty with a problem like this, even though it seems like a basic coding problem on the surface. Other problems will cover different combinations of various technical skills and aptitudes, so you need to be pretty well versed in everything to pass a technical interview.
So to prepare for a technical interview, take some time to make sure you are adept in all of these areas. Tackle unfamiliar problems and make sure you write code to solve them. Be familiar with standard data structures and how they are found in the programming languages you expect to use to solve the problem. (e.g. it’s difficult to solve a graph problem in Java if you don’t know how to represent or manipulate a graph in Java).
And make sure you are solid in your programming language of choice. Nothing makes an interview go bad faster than forgetting how to do simple things like string/integer conversion, sorting, basic arithmetic operations, memory allocation/deallocation (if applicable), and so on. A candidate for a programming position is expected to already be solid at programming. You need to give the impression that the time the company will invest in getting you up to speed is going to be spent familiarizing you with the company’s code base and particular way of doing things, *not* teaching you how to write basic code.
Topics: General |
