Interview Programming Questions - In house Exam

Question

I have a company that would like to bring me in to serve me an hour long exam. No resources other than a pencil and paper. I really couldn't get any sort of feedback on the type of exam (implementation or generic) beside that it would test a few specific areas.

Have you done anything like this? What sort of questions did they ask? What's a good way to prepare? I'll probably go in a couple weeks before school starts back up.

A time sensitive exam structure is a weak point for me, so what should I absolutely focus down on?

If they like the exam, that's when I'll get a face-to-face meeting.

An advance thanks goes to everybody who provide their time.

Answer 1

I would focus on the things that you would be using if you were employed:

1. What data structures will you probably use time and time again?
2. What libraries will you commonly use?
3. What functions will you often call?

In addition I'd suggest trying to write common/simple programs in pen so that you can get the hang of writing by hand and try to look stuff up on the computer as little as possible while writing by hand.

Answer 2

I've had my fair share of such interviews. Some key points I find helpful are:

• Think before you write. Even if it seems obvious.
• Even if the answer doesn't come to you right away, explain what you're considering. Let the interviewer see how you think.
• Unless specified, I prefer pseudo-code as it saves the hassle of having to use a specific syntax
• Don't panic.

There are many examples on the net. Tech interviews is a fine one. I'd also take a look at Steve Yegge's post about this.

HTH

Answer 3

Try to answer everything even if the questions seem impossible. e.g. How many gas stations are there in L.A.? Write down how you could go about figuring this out, and try it. If you don't know an answer, write down how you would go about finding it.

They may ask you to write some code. It might be helpful to know what languages they work with, and refresh on that.

Read Joel's article on interviewing: http://www.joelonsoftware.com/articles/fog0000000073.html

You may get some idea of what they'll ask.

Good luck.

Answer 4

I've had 2 very different cases of such an interview. One company when I was just out of school gave me a small assembly language and I had to solve some problems with it as efficiently and concisely as possible.

My current company gave me a small application to write, detailing what I needed to solve in the problem.

So, in general, expect to have to prove that you know how to program. As a side note, I think this is a good sign that the company hires, or at least tries to hire competent people, which means you will likely be working with enthusiastic developers rather than 9-5 vocational developers. As an enthusiastic developer, it's more fun to work with the former.

Answer 5

Read the test thoroughly, try to figure out how much time they actually spent putting the test together. If the test is shoddy or poorly worded consider going with another employer. As an example I've included actual word-for-word questions from an interview exam I took 6 months ago:

B09 Which is the command to delete a not empty directory ?

...

W01 How many different information I can have with 6 bits ?

    1. 28
    2. 128
    3. 64
    4. 2^6 – 1

Needless to say, I decided to reject the offer.

Answer 6

If you've been out of school for a while, I would practice answering programming questions you "know" in pencil and paper as fast as you can. I personally found out during an interview that specific syntax really helps me focus my thoughts, while others might prefer the relaxed nature of pseudocode.

Answer 7

My limited experience taught me that the companies a passionate programmer might want to work for also have the more interesting interviews and exam questions.

Obviously I'd advise on preparing for the obvious (linked lists, sorting, complexity, n(n+1)/2 and so on). But I'd also suggest visiting a nearby library and searching for brain-teasers books and even some math games books. For example, I borrowed a couple of years ago an old book (circa 1950) of math puzzles from the Russian Mathematics Olympiad. You'll be surprised how many similarities I found comparing with CS problems, and it gave me new angles to tackle interview problems in interesting ways.

These might give you an advantage if you're introduced a "weird" question, something that requires a creative approach. Cool places of work like doing that, and they look for creative thinking.

Answer 8

I once had two exams at an interview: a personality test, and a technical test.

I passed the technical test with flying colors. I failed the personality test (I actually had a personality, I think they were looking for someone who didn't)

The personality test questions were mapped to a graph, and it turns out they had already drawn a graph of the person they were looking for. My graph was the exact opposite.

At least we could both agree that it wasn't the right place for me!

Answer 9

I recently had an interview where I was tested for quite a long time by team members.

1 - Learn what the position will be doing. Try to imagine what your job will entail and what knowledge will be important. If you're doing embedded programming then a knowledge of .NET won't be relevant...

2 - All of my interviews for a C++ job had a ton of questions on inheritance and polymorphism. Learn the ins and outs of those.

Answer 10

If you haven't, I would suggest you to find out what type of question are they going to ask on the exam. Also, it will help to talk to people who have interviewed for the same position at the same company before.

From my experience, I got asked questions like:

• Reverse a link list
• Insert a node to a SORTED link list
• Using any data structures you wish in addition, how do you always get the minimum integer in a integer stack in constant time
• you have 100000000 32bit integer, but you only have 1MB memory, how do you sort the integers? Improve the efficiency.
• Write a function that outputs the permutation of any string
• Write a function to compute quadratic formula
• Write a function to determine if an integer is a prime number
• What is a wrapper
• Explain difference between tread and processes
• Give you an problem Draw the domain model
• Explain critical section, explain dead lock
• Best and worse case run time of quicksort in big O notation

That's all I can remember for now.

Answer 11

There has only been one time (thus far) that I've been given a written test prior to getting a job. It's been many years now, so it's more than a little fuzzy what the questions were. This was for a C job, and my recollection is that the questions were similar to what you might find on a comprehensive final for an intro to C college level course (or maybe a BrainBench test, but this predated the web), multiple guess, true & false, fill in the blank, tell what a code snippet does, etc. I'd been doing C for a couple years, so it really wasn't too difficult for me at the time (might be now, since I've not seriously written C in over a decade). It seems they were burned by a previous employee who claimed to be a C expert and then turned out to not even know how to open a file. I passed and got the job.

YMMV, of course.

Answer 12

I generally hate onsite tests. I always feel like anything that doesn't require interviewer interaction should be done as a prescreening phase before a candidate is brought in. I also believe that there are sufficient ways to ensure that a candidate is actually solving the problem themselves (such as doing it on the fly via screen sharing while speaking, etc.).

Nevertheless, these are quite common, and generally tend to favour folks who are recent college graduates who are used to pen-and-paper tests. My experience is that a longer a developer is out of college, the harder it is for them to write code without API references and an IDE. Handwriting long lines of code (without an ability to erase) is also a problem.

As for what you could be asked: Anything really, ranging from math problems to abstract design questions to writing actual code, though usually under a page. There's really no way to prepare for these differently than for a regular interview since you could be asked to solve the same questions in realtime on a board. In general, after finishing your test, you will be reviewing your solutions with someone.

I would highly recommend bringing a pen you are comfortable using with you. It sounds like nitpicking, but it can make all the difference. You are going to be writing several long pages, anything that can be a distraction (like a pen that forces you to push harder). Also bring a stopwatch that is not your cellphone, and make sure to put your cellphone far away. Many places observe the interviewee to make sure they are not cheating. It's easier to have your iphone far away than to expalin that you were only using it for a watch.