Possible Duplicate:
How to prepare yourself for programming interview questions?

Could someone give me pointers on how go to about preparing for a technical interview? As a CS graduate, I guess one must be thorough with the following topics:

Data Structures: Array, Linked List, Stack, Queues, Heap, Hash Table, Binary Tree, Binary Search Tree, Self Balancing Binary Tree (AVL, Red Black Tree), B-Tree, Tries/Suffix Tree

Algorithms: Sorting (Bubble Sort, Insertion Sort, Selection Sort, Shell Sort, Quick Sort, Merge Sort, External Sorting), Searching (linear and logarithmic time searching), Graph Theory (Adjacency List, Adjacent Matrix, DFS, BFS, Topological Sort), Dynamic Programming, Greedy Algorithms, Divide and Conquer.

Adhoc Algorithms: Select Algorithm, Fisher Yates Card Shuffle, Reservoir Sampling and list is endless.

Databases: SQL Queries

Programming and Design: C,C++, Java, scripting languages (Perl, Python), (OOPS basics, virtual functions, deep and shallow copy, copy constructor, assignment operator, STL, memory management, pointers/reference, interface, abstract classes

Operating Systems: Thread Synchronization (Mutex, Conditional Variables, Semaphores, Deadlocks), Memory Management (Segmentation, Paging, TLB, Caching Mechanisms)

Also it would be great if we all could compile the resources available on internet to brush up these topics. I will add some of these:

Linked List and trees: http://cslibrary.stanford.edu/103/

Please help me out to find useful resource to prepare for these topics, also I would appreciate if you could add in to these topics.


4 Answers 4


It really depends on the type of job you are applying for. I've been through a few interviews, and conducted even more. Here are some tips.

  • Everything you listed falls into the "technical trivia" category. It is important to know - it helps to establish that you have good depth and breadth of technical knowledge. The reality is it is often really hard to study for - either you know it or you don't. Not so say brushing up on things is a bad idea.
  • Problem solving and critical thinking is also really important. Questions like "how many manholes in Manhattan" are common - they are not looking for an right answer, they want to see how you solve problems. Explain your process - if you discover you made a mistake then explain why and how you can improve it. Don't toss your hands in the air and give up. Be tenacious and be willing to be creative - for the manhole question you could suggest interviewing cabbies.
  • Be willing to defend your points. I am not saying to be argumentative, but if you are asked what technology or methodology you would use in a particular situation be ready to defend that point. If they ask you if you would build a web application or a client application to solve a specific problem (everyone always says they would ask the client, but usually that isn't enough) be willing to say why you choose that technology. Usually "it is all I know" is not the right answer. The reasons for the choice are more interesting then the choice. We were interviewing a guy once (who we hired) and asked him if he would choose web or client solutions to different problems, he said web, and explained why, but then said unless it was for Africa (he immigrated from there) because their Internet infrastructure was terrible!
  • Don't BS - if you don't know the answer, be up front - but then explain how you would try to find the answer, or what you would do based on what you know. I've asked questions that I know there is no actual answer for before just to prove someone was BS'ing me.
  • Study the company you are interviewing with. You can learn a lot about them from the job listing and other listings they have. Make sure you do research every technology in your job posting, and be aware of other technologies used at the company (based on other listings). This has gotten me the job before.
  • Have some thoughtful questions planned. Especially inspired by your research into the company and their technologies.
  • Create a portfolio of code samples, user interface designs, blog posts, papers, patents, open source projects, Stack Overflow answers, interesting problems you have solved (even if just explained on paper) etc. Anything you can point to show some of your skills, experiences, etc. Be sure you have rights to anything you share. I once had a candidate mail me login credentials to a application he designed for a previous employeer. Stuff you have done on your own time (or in school) is key - plus it shows your passion.

Hope that helps. Good luck!


This book has been very helpful to me in the past. Specially when I was just coming out of school.

EDIT: It's called "Programming Interviews Exposed: Secrets to Landing Your Next Job, 2nd Edition (Programmer to Programmer) "


It's good to know as many items on your list as you can, but when I help interview, we quickly go past whether you know the items. We are interested, and the more you know the better, but it's even better if you know enough to answer why you would choose one data structure over another in a given problem, or what times you would use semaphores rather than mutexes, etc.

In addition to that, people who bring in samples of previous work are much appreciated. If you do this, be sure you know it well; that is, don't bring something you did as a "team", where the majority of the code was written by someone else, unless you really understand it. Be prepared to explain why you chose the algorithms you did, what constraints you were working under, and things like that.


Most of what you listed won't come up in an interview directly; it will be assumed that you know most of it based on your background. What you will need to show is the skills, rather than the knowledge, do do the job. Things like:

  • Strong communication skills, both written and verbal. The entire application and interview process, including your resume and cover letter, are your opportunities to show this off.
  • Fast learning and good research skills: the ability to admit what you don't know, and not let it stop you. Be ready to say "I don't know", and confident enough to add "yet". You may be given a question or two that no one knows off the top of their head; this is to prove that you don't get flustered or make things up, that you can calmly and quickly go and find out what you need to know.
  • Analytical thinking: you may be presented with various sorts of riddles to prove you can work your way through a problem and arrive at a solution; what will matter most is your process, not your final answer. Oftentimes, the person asking doesn't know (or care) if your final answer is write or wrong. They want to see how you come up with it.
  • Technical demonstration: that's right, the fun part. A good company will present you with a programming task to complete, and they will review your solution. There is no preparation for this other than experience, though the problems are typically relatively straightforward. They just want proof that your background adds up to genuine implementation ability.

None of these things can really be "studied", only practiced. The more practice the better, but always remember, it's not "practice makes perfect", but "perfect practice makes perfect". Always practice doing it right, not just doing it at all.

Good luck!!