As a Stanford CS student (soon to be alumni), I've been through more than my fair share of interviews (Google, Facebook, Dropbox, Palantir, Coursera, Addepar, Quora, Amazon), as well as have heard stories from a number of other friends in the Valley. Software engineering interviews tend to be quite difficult for the unprepared, but actually are not as hard as one might think if one covers their bases. Here's some general tips regarding interviewing for an entry-level software engineering position:
Not every component of the degree is important for interviewing, but each piece you learn gives rise to greater maturity in CS. In particular, pay attention to classes in algorithms and data structure, operating systems, discrete math, and functional programming. Other areas (security, networking, machine learning) are optional.
Most interviewers will let you choose your language to code in, so choose something fairly concise and expressive. Python is a great interview language and has been my language of choice in the past. Know as much as possible about the language (eg. the underlying implementations of the data structures, the ecosystem, 3rd-party libraries, advantages/disadvantages versus other languages, etc.).
Most interesting companies will give you thorny problems to solve, which most likely will not yield to a brute force approach. While it's unlikely that the interviewer will ask you to prove the divergence of a harmonic series, it's good to be able to take a step back from the problem and ask the broad structure of how it should be solved, using the tools of mathematical analysis. Pay particular attention to discrete math, probability and statistics, series summations, etc. Math is especially important for those interviewing for quant-related roles.
Apply to as many interesting companies as you can. Interviews are a notoriously noisy process, and companies and recruiters generally accept failure of good candidates as part of the noise. Don't be afraid to take chances in your interviews as you learn more about the process.
The best interviews are not instantly knowing all the correct responses, but rather a joint exploration of the problem space, hopefully leading at least to the correct conclusion, but possibly also moving past it to deeper waters. Be open-minded and straightforward in exploring the problem space - don't be afraid to ask questions, question the interviewer's posing of the question and question your own assumptions. It should feel more like a conversation with a colleague when working on a research paper rather than an interrogation.
Smile and be polite. Ask for contact information at the end of the interview. Follow up soon afterwards, thanking them for the experience.
These are basically the core components of the software engineering interviewing problem. There's a lot more wrinkles in the process, mostly dealing with networking and navigating HR, however these are not unique to software engineering, so I'll leave them them off here for now.
This was originally published on January 28th, 2014 at https://www.facebook.com/notes/chris-lengerich/software-engineering-interview-tips/10151829882836541?pnref=lhc