Jump to content

Programming interview

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by G8moon (talk | contribs) at 07:12, 14 February 2011 (starting the article about programming interview). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

A Programming Interview is a technical job interview in the software industry or in IT departments of major corporations to test candidate's coding ability, problem solving skills, and creativity as well as their technical knowledge about computers. Candidates usually have degrees in Computer Science, Computer Engineering or Electrical Engineering, and are asked to solve programming problems, algorithms, puzzles, and/or computer related technical questions.

Software Development Engineer (SDE), Software Design Engineer in Test (SDET), Technical Consulting

The Interview Process

Screening Interviews

On-Site Interviews

Languages to Use

If the interviewing position has a specific language requirements, it is expected to know those languages and solve the questions with it. If the interview is for general programming or development position, a thorough knowledge of a mainstream language such as C, C++, C#, or Java is enough to get by. Interviewer may also permit to use other popular languages, such as JavaScript, PHP, or Perl. If the choice of the language is given, it is better to select the one that is most familiar with. Interviewers are less likely to permit to use less-mainstream languages such as Lisp, Python, Tcl, Prolog, COBOL, or Fortran, however, if you are particularly expert at one of these, you should definitely talk to your interviewer. [1]

Dress Code

This may require some research since the dress code is usually reflected by how other people wear at the company. These days, most companies in software industry allow business casual at work. Therefore, unless the interviewing position has a significant business or consulting aspect whereby formal dress will be required, a suit might be an overkill for a programming interview.

The standard business casual outfit would be as follow:

  • for men: A combination of collared shirt (such as a dress shirt or polo shirt), cotton trousers (such as khakis or blue, green, brown, or black trousers) with a belt, and modest shoes (such as loafers) with socks is generally acceptable. A blazer or business jacket can optionally be added.
  • for women: A reasonable length skirt (not mini-skirt) or full-length trousers of a non-jeans material combined with a top (such as a dress shirt, polo, or sweater set) is considered acceptable. An informal dress with appropriate skirt length is also acceptable.
  • Unacceptable for either gender: gym clothes, rumpled or ripped clothing, miniskirts, underwear as outerwear, inappropriately revealing attire such as bare midriffs, and flip-flops.[4] Many corporations also frown upon open-toed shoes and shorts.

Interview Tips

  • If you have time you MUST run through your code and do some basic verification/error testing. Try to start with a general case so that you are pretty sure it works at a basic level and then hit some boundary cases. If you are running out of time mention how you would test your code. You won't lose points if you catch small issues quickly after you are done coding, but if the interviewer has to point out a lot of issues you don't find you will lose points.
  • If you start coding immediately you have already lost the battle. In school, you have strict guidelines and you implement based on those guidelines. However, nothing is ever clear cut at work . You need to make sure you understand the guidelines you have been given, but what you have to do can be quite open ended. Even if something doesn't sound open ended, you need to make sure you ask questions. Understand how what you would develop would be used immediately and how it may need to be used later.
  • Try to approach longer and shorter questions the same way. You need to ask questions to make sure you know what you are supposed to do, then spend time coding, and finally spend time testing. If an interview is based around a single coding question you should think about security, performance, extensibility, ease of code maintenance, etc. But try to come up with a standard approach to questions that you are comfortable with. You can adjust how much time you spend in each phase of your process based on the amount of time you have to answer the question and the difficulty of the question. The more comfortable you are the better the interview will go.
  • You need to understand the basic concepts you learned in the introductory computer science classes. This includes Big-O notation, data structures, time and space trade-offs, buffer overflows, string functions, pointers, etc.
  • Be confident not cocky. If you know something, you should be able to express your thoughts clearly. However, if you don't know something, don't try to make stuff up to get your way through it. You'll look much better saying you don't know something than making it up. Trying to make up something that sounds intelligent on the spot will make you uncomfortable and have a detrimental impact on the rest of your interview.
  • Talking - The interviewer needs to understand how you think through problems and get an idea how you come up with your solution. The interview is definitely a conversation. With that said, there are times to talk more and times to just get things done. If you discuss and plan what you are going to code before you start coding you shouldn't need to talk much while coding. They should know where you are going and things should flow rather smoothly. If you get stuck handling a detail you didn't think of before try to summarize the issue you are having and what you are thinking about. If you need a minute to think about it, tell them and spend the minute focused on the problem. If it starts to take more than a minute, it may help to start bouncing ideas off the interviewer or to just skip to something else and come back later.
  • When being asked technical questions, listen for the things that aren’t asked or specified in a problem you’re solving. Try to stave off assumptions you make when working through a problem by asking clarifying questions. Being able to show that you think things through and think critically about problems is good.
  • Review your basic data structures and their related operational algorithms. Knowing how they work and when they should be used will be helpful both for that knowledge in particular but also for applying that same analysis for the problems you will be presented.
  • Be prepared to discuss both technical details and information regarding non-technical aspects of the bigger projects you’ve been involved in.
  • Usually the language you work through isn’t too important, but if you’re going to try and code a problem in a particular language. Make sure that you are fully prepared to do so. It is usually acceptable to not be able to mentally recall the class and function names of the extended class library, but you should be able to recall the basics.
  • Brush up on common memory and CPU time optimization techniques.
  • Practice working through some coding problems that you haven’t seen before, as this is similar to the technical parts of the interview. Don’t worry if you can’t nail every single programming contest problem you find on the internet, the important thing isn’t so much that you come upon the optimal solution right away but rather that you demonstrate that you can think through problems, work through ideas on how to solve them, and can step back and re-evaluate when what you’re trying isn’t working. Take problems you’ve solved and see if you could optimize them for CPU time and memory usage.

Study Resources

  • Programming Interviews Exposed (John Mongan)
  • Code Complete (Steve McConnell)
  • Clean Code: A Handbook of Agile Craftsmanship (Dean Wampler)
  • Cracking the Coding Interview, Fourth Edition: 150 Programming Interview Questions and Solutions (Gayle Laakmann)
  • Programming Pearls (Jon Bentley)
  • Algorithms For Interviews (Adnan Aziz)
  • How to break software (James Whittaker)
  • How to break security software (James Whittaker)
  • Lessons Learned in Software Testing (Cem Kaner & James Bach)

References

  1. ^ Programming Interview exposed, page 16
  • John Mongan, Programming Interviews Exposed: Secrets to Landing Your Next Job (2nd ed.), Wrox, ISBN 978-0470121672
  • TWELVE TIPS FOR SOFTWARE DEVELOPMENT ENGINEER INTERVIEWS (by Microsoft)
  • SDE Interview Top 10 List (by Microsoft)