I just went through a three week gauntlet of interviews (~10 companies who each do at least 3 1-hour interviews). This slide set is pretty accurate in terms of what to expect but I'd weight the API's/language/philosophy sections down a bit. I only got a few language questions and absolutely none about development philosophies (except for maybe "emacs or vim?"). Algorithms & data structures are what you should be studying. Puzzles too but that's more about doing a lot -- you can't really study per se.
I am wondering what it takes to be a qualified web start-up programmer.
I have less formal computer science training than most candidates for Silicon Valley jobs. However, I gamble I have more programming experience than many CS graduates. So, I am hopeful that I don’t need to go back to school for chemistry straightaway.
I am familiar with algorithms and data structures, but I am certain that many properly educated developers would put me to shame. What is the best way to accumulate this core theoretical knowledge? Are there preferred books on the subjects or will any do? Or do you recommend simply taking few courses before I graduate?
Most engineers never implement any of those classic CS algorithms or data structures manually since everything is in the libraries these days. Therefore they're in the same boat as you: general knowledge and a couple of books under a hand to look things up. All they (and you) have to do is to refresh their knowledge since college years.
I've never implemented a linked list since graduation, nor I sorted anything manually using quick sort. Moreover, I never had to generate permutations of anything, nevertheless those are the same damn questions they keep asking on interviews. I wonder why: it only makes sense for fresh graduates, because it's the only reliable way to compare then against each other.
I have used the Aho-Corasick and Boyer-Moore algorithms the Google presenter guy mentioned many times, at least a dozen, in 10 months of employment.
I have also implemented a fulltext indexing system because we have total NIH syndrome, which involved working with suffix trees, inverted indexes, and other classic undergrad information retrieval material.
You don't have to know everything; you need to know enough to know what you don't know, and where to look to get what you need to get the job done. Like, I just start with Wikipedia, usually.
What you need when you actually get the job is a separate concern from what you need to get the job in the first place, though.
I'll second the Algorithm Design book recommendation. An even better theory book is Introduction to the Theory of Computation by Sipser, however it covers slightly different topics. It is one of the most readable theory books I've seen, highly recommended, and a great resource for information on regular languages, context-free grammars and turing machines.
A less theoretical book, that is useful for a gentle intro is Masting Algorithms with C.
A bit off the theory track, but useful for a software engineer: Modern Operating Systems by Tanenbaum and Computer Organization and Design for info on hardware.
The Sipser computation theory book is absolutely fantastic, I agree. Definitely the most readable and clear book on the subject that I know of. However, I don't think it would be particularly useful to prepare for an interview -- the number of people likely to quiz you on the details of computability theory or complexity theory is pretty small.
Hmmm....formal training is important, but if you had a website with some kick-ass demos, you'd probably have a better chance of scoring a face-to-face interview.
Algorithms and data structures? If you like proofs, I've heard that the Cormen and Rivest book is great. Personally, I find that the Sedgewick volumes have great explanations of the most common algorithms.
But you haven't graduated yet, so the most effective approach may be to sign up for an algorithms course. Then you'll have the benefit of a prof and students to help out.
I usually review my data structures and algorithms book before interviews. In particular, you need to be familiar with recusion and tree traversal. Interviewers love these questions.
For me, the only time I write tree traversals is during interviews, so I am a little surprised that it's such a big point for interviewers. I suppose it is a pretty good sign that someone knows how to program, but I do think that it would lead to many "false negatives" (ie., someone who can program well but doesn't have it front and center).
My advice: don't become a false negative. Just make sure you bust out the old textbook and get it fresh in your mind.
If you've never taken data structures and algorithms, then you'll probably get a lot out of this exercise. I use container classes for most of this, but it is valuable to study and learn it well once.
Yeah, I've just been through the interview cycle as well, and I'd definitely focus on knowing as much as you can about: 1) data structures 2) algorithms 3) big picture: how would you build X? 4) math - be a good puzzle solver. the more puzzles you do, the better you get at them.
as much as people rave about rails, python or any other language, the web actually runs mostly on java (and some .net). Most financial sites, brokerage houses, banks and many more websites run with java.
Just b.c you hear about rails or django all the damn time, doesn't mean they are widely used. They are just trendy frameworks.
(Php is the other language that run the rest of the web.).