Interview programming test
Author
Hi so next week I have an interview for a programming position and I was told that were would be a code test. Now this is my first interview ever coming out of school and I wonder if anyone that has experienced this sort of a test would share what questions they were asked.
[Edited by - Ravuya on March 26, 2009 1:40:07 PM]
It varies based on the company and what they are looking for. I head up the process for my company and these are the kinds of questions I might ask:
1. Write a string reversal algorithm
2. Write a function to determine if a number is a power of 2
3. Calculate the nth Fibonacci number
4. Write a function to reverse a doubly linked list
5. Determine if a linked list is circular.
Sometimes they can get much more complicated. Finding the correct answer is not always the only thing they want. They want you to understand the problem or understand how to work it out/break it up. They want to see how you approach solving the problem.
It's also not unheard of to sit someone down for 3 hours while they develop a mock system(A car where you must define individual components(motor, seats) using inheritance etc.) to see how they design and approach larger scale problems.
Sometimes they will give you an incredibly hard problem you may not be able to finish. In this case, try your best, explain how you would try to solve it, in the end its good to understand your limitations. If you can not do it, just tell them. "This is an interesting problem, however I am not familiar enough with X to solve it. Would you mind explaining what this does?"
Have fun with it most of all. It's always a learning experience.
1. Write a string reversal algorithm
2. Write a function to determine if a number is a power of 2
3. Calculate the nth Fibonacci number
4. Write a function to reverse a doubly linked list
5. Determine if a linked list is circular.
Sometimes they can get much more complicated. Finding the correct answer is not always the only thing they want. They want you to understand the problem or understand how to work it out/break it up. They want to see how you approach solving the problem.
It's also not unheard of to sit someone down for 3 hours while they develop a mock system(A car where you must define individual components(motor, seats) using inheritance etc.) to see how they design and approach larger scale problems.
Sometimes they will give you an incredibly hard problem you may not be able to finish. In this case, try your best, explain how you would try to solve it, in the end its good to understand your limitations. If you can not do it, just tell them. "This is an interesting problem, however I am not familiar enough with X to solve it. Would you mind explaining what this does?"
Have fun with it most of all. It's always a learning experience.
Quote:Original post by Tang of the Mountain
1. Write a string reversal algorithm
2. Write a function to determine if a number is a power of 2
3. Calculate the nth Fibonacci number
4. Write a function to reverse a doubly linked list
5. Determine if a linked list is circular.
If you asked these, I would be tempted to ask when you're going to get to the interesting stuff. ;) OTOH, it is very useful for the company to start out with this stuff, to filter out the incompetents (who are disturbingly high in number).
(The more interesting version of 5: Determine if the linked list falls into a cycle at any point, in O(N) time and O(1) space. :) )
Quote:It's also not unheard of to sit someone down for 3 hours while they develop a mock system(A car where you must define individual components(motor, seats) using inheritance etc.) to see how they design and approach larger scale problems.
Sometimes they will give you an incredibly hard problem you may not be able to finish. In this case, try your best, explain how you would try to solve it, in the end its good to understand your limitations.
I've actually heard of at least one case in which the company asks the question... that the company is basically dedicated to solving. ;)
Just some I can remember:
Write a function to retrieve the offset of a data member from a class.
Write a function to test a ray vs triangle for intersect
Write a heap (priority queue)
Write a function to reverse a string
Write a function to swap two integers
Write a function to mulitply two numbers with out using the multiply operator
Write a function to count the number of unique words in a paragraph
Write a vector (math) class
Write a basic inheritance example (this will varey greatly on the employer)
Write functions to manipulate the case of a character/string (tolower, toupper)
Keep in mind, the circular linked list problem.. the circular reference could be anywhere along the list. Like a regular linked list, but the last nodes node is pointing to itself, so you can never escape the list during iteration. Write a function to test for that (or an arbitrary loop backage).
These tests are impossible to prepare for. You may get in there and they'll ask you a question that none of us have mentioned :P
Also none of these problems are all that hard, they are looking more closely at HOW you do it rather than if it works.
Write a function to retrieve the offset of a data member from a class.
Write a function to test a ray vs triangle for intersect
Write a heap (priority queue)
Write a function to reverse a string
Write a function to swap two integers
Write a function to mulitply two numbers with out using the multiply operator
Write a function to count the number of unique words in a paragraph
Write a vector (math) class
Write a basic inheritance example (this will varey greatly on the employer)
Write functions to manipulate the case of a character/string (tolower, toupper)
Keep in mind, the circular linked list problem.. the circular reference could be anywhere along the list. Like a regular linked list, but the last nodes node is pointing to itself, so you can never escape the list during iteration. Write a function to test for that (or an arbitrary loop backage).
These tests are impossible to prepare for. You may get in there and they'll ask you a question that none of us have mentioned :P
Also none of these problems are all that hard, they are looking more closely at HOW you do it rather than if it works.
Take a look at:
http://www.gamecareerguide.com/features/489/game_programming_.php
The best advice is just to take it easy, be careful with your answers, show all working and treat it as a learning process. The first test I ever took out of uni I got 30%. It's pretty crushing, but just collect all the tests as you go and always keep learning.
Some tests are really badly written, aiming more to prove how clever the test writer is than really examining the applicant's ability. These are usually the ones that have questions related to specific, obscure language behaviour. Don't take these sorts of tests too personally.
Other than that, the rest of the suggestions in this thread are pretty good, and they match up well with the tests I've experienced.
Unfortunately many companies put you under some sort of non-disclosure agreement before you get given a test, so even though a lot of people on the board will have example tests you're unlikely to be given one.
http://www.gamecareerguide.com/features/489/game_programming_.php
The best advice is just to take it easy, be careful with your answers, show all working and treat it as a learning process. The first test I ever took out of uni I got 30%. It's pretty crushing, but just collect all the tests as you go and always keep learning.
Some tests are really badly written, aiming more to prove how clever the test writer is than really examining the applicant's ability. These are usually the ones that have questions related to specific, obscure language behaviour. Don't take these sorts of tests too personally.
Other than that, the rest of the suggestions in this thread are pretty good, and they match up well with the tests I've experienced.
Unfortunately many companies put you under some sort of non-disclosure agreement before you get given a test, so even though a lot of people on the board will have example tests you're unlikely to be given one.
Its hard to say what questions will be given to you, so you should prepare more generally. Instead of trying to study specific examples for their solution, study specific examples with the purpose of developing your methodology and "getting into the groove".
Find some example problems online, in a book, wherever... Work through each problem by first asking if you understand the problem clearly -- write down some potential questions you might ask if not, its not bad to ask questions during an interview, in fact it can be a good thing, because they don't want to hire someone who's going to run off half-cocked and then come back a week later with a great solution to the wrong problem. After that, write at least a paragraph explaining your approach to solving the problem, interviewers want you to talk through your solution, you're not going to look like a genius because you do the work silently. If you deviate from the original plan, or discover "implementation details" along the way, jot down a sentence or two about why/how. When you're finished, run through at least once mentally, if not twice -- if possible, pick example cases that simplify the math without trivializing the execution, try to test all the possible execution paths, try to test edge-cases that might be cause for concern (off-by-one errors, boundary conditions, etc.) During the whole thing, interact with the interviewer, try not to be stiff, humor is good if its appropriate -- the interview process is designed to test whether or not they can work with you, both professionally and inter-personally.
Some general topics that come up (presuming this is a game studio):
- String manipulation
- Linked Lists
- Recursion
- Trees
- Logic
- Math (typically Matrices and Vectors, particularly transformation, cross and dot products, projection, reflection).
Some advice from my own experience:
- Make sure you understand what is wanted before you begin.
- If they hand you a piece of code from a AAA game or engine, don't assume it's correct, or does something logical. I was once handed a 15 line function from the Unreal 3 engine, and made the mistake of assuming that it couldn't possibly be returning untracked pointers from a pool of memory in round-robin fashion (in other words, there was no mechanism in place to prevent two callee's from getting the same pointer, aside from an assumption that the first will have simply forgotten about it by the time the second comes calling,) and spent my time looking for red-herrings (minor errors, off-by-ones) when that was indeed the real issue.
Finally, there's a really good book that is now in its second or third edition called "Programming Interviews Exposed" which is absolutely invaluable, if you can get your hands on it, its a great investment. About half to two-thirds of the book covers the basic technical information you should know, with plenty of problems to work through, including the "brain teaser" type questions that a popular at some companies. The rest of the book covers everything from how to graciously admit defeat when you are truly stumped, to how to dress, to how to negotiate your salary. It's truly a book that every computer scientist should read though, if not own, before they go out into the workforce.
Find some example problems online, in a book, wherever... Work through each problem by first asking if you understand the problem clearly -- write down some potential questions you might ask if not, its not bad to ask questions during an interview, in fact it can be a good thing, because they don't want to hire someone who's going to run off half-cocked and then come back a week later with a great solution to the wrong problem. After that, write at least a paragraph explaining your approach to solving the problem, interviewers want you to talk through your solution, you're not going to look like a genius because you do the work silently. If you deviate from the original plan, or discover "implementation details" along the way, jot down a sentence or two about why/how. When you're finished, run through at least once mentally, if not twice -- if possible, pick example cases that simplify the math without trivializing the execution, try to test all the possible execution paths, try to test edge-cases that might be cause for concern (off-by-one errors, boundary conditions, etc.) During the whole thing, interact with the interviewer, try not to be stiff, humor is good if its appropriate -- the interview process is designed to test whether or not they can work with you, both professionally and inter-personally.
Some general topics that come up (presuming this is a game studio):
- String manipulation
- Linked Lists
- Recursion
- Trees
- Logic
- Math (typically Matrices and Vectors, particularly transformation, cross and dot products, projection, reflection).
Some advice from my own experience:
- Make sure you understand what is wanted before you begin.
- If they hand you a piece of code from a AAA game or engine, don't assume it's correct, or does something logical. I was once handed a 15 line function from the Unreal 3 engine, and made the mistake of assuming that it couldn't possibly be returning untracked pointers from a pool of memory in round-robin fashion (in other words, there was no mechanism in place to prevent two callee's from getting the same pointer, aside from an assumption that the first will have simply forgotten about it by the time the second comes calling,) and spent my time looking for red-herrings (minor errors, off-by-ones) when that was indeed the real issue.
Finally, there's a really good book that is now in its second or third edition called "Programming Interviews Exposed" which is absolutely invaluable, if you can get your hands on it, its a great investment. About half to two-thirds of the book covers the basic technical information you should know, with plenty of problems to work through, including the "brain teaser" type questions that a popular at some companies. The rest of the book covers everything from how to graciously admit defeat when you are truly stumped, to how to dress, to how to negotiate your salary. It's truly a book that every computer scientist should read though, if not own, before they go out into the workforce.
Quote:Original post by Tang of the Mountain
1. Write a string reversal algorithm
reverse :: [a] -> [a]reverse = foldl' (flip (:)) []Quote:Original post by Tang of the Mountain
2. Write a function to determine if a number is a power of 2
isPowerOfTwo :: Int -> BoolisPowerOfTwo x = x .&. (x - 1) == 0 && x /= 0Quote:Original post by Tang of the Mountain
3. Calculate the nth Fibonacci number
fib :: Int -> Integerfib = (fibs !!) where fibs = 0 : 1 : (zipWith (+) fibs (tail fibs))Quote:Original post by Tang of the Mountain
4. Write a function to reverse a doubly linked list
5. Determine if a linked list is circular.
Circular data structures do not exist in Haskell as far as I can tell.
So, do I have the job? :)
Quote:Original post by DevFredNatively. But surely you can represent a directed non-acyclical graph in Haskell [smile]
Circular data structures do not exist in Haskell as far as I can tell.
Quote:So, do I have the job? :)You solved all questions, but failed to understand why I was asking them (or willingly chose to ignore it). So, no [smile]
I've got an interview comming up. I'm about to get pounded on :) It's just another day though right? just gotta stay calm and not over work the problems.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
