preparing for a phone interview: best books on algorithms/programming practices?

[urlwolf]

I'm preparing for a phone interview.

What are the best books on algorithms/programming practices? Note: I'm not a CS major (self-taught programmer) so all the basic stuff taught on CS courses is something I didn't have to do. I mean, I may know what a bubble sort is only because I found the need for one in the wild... but not all the classical algorithms are found that way . That means I may be missing a lot, which I plan to to complement in 2-3 days of serious reading.

Recommendations?

[iphigenie]

Depends on the languages you know

I have "algorithms in perl" and its actually more about perl than algorithms so only if you know perl. Not found a decent java one ever.

I had a great book about algorithms in C or C++ which I used to learn even though I barely knew C - but I cannot for the life of me remember which it was - should go through covers at amazon later

a couple refs I have bookmarked

http://www.oberon.ethz.ch/WirthPubl/AD.pdf  (ok, i am from that university - you probably dont know the language but it is clean and procedural...  almost like pseudocode. The quick descriptions are math-ey but clear - he has a very clean thinking)

http://www.softpanorama.org/Algorithms/index.shtml - a bit of a mish mash and you could waste hours which you probably dont have, but if you know what to focus on

http://www.cs.sunysb.edu/~algorith/ - nifty graphics and links to multiple source codes in multiple languages

http://www.nist.gov/dads/ - 3 line definitions, might be good for a last minute cheat while on the phone

[urlwolf]

Thanks iphigenie, great resources.
I was unsing the wolf book (algorithms in perl) right now.

There's a nice list here:
http://www.philosophicalgeek.com/2007/11/21/books/

Somewhat C# oriented (guy is a microsoftie).

[iphigenie]

the oberon pdf is worth skimming through for a nice intro to each of the techniques - and if you ever learned pascal, well, this is in the family

[patthecat]

Steve McConnell has authored several books regarding software development - http://www.stevemcconnell.com

Here are some links I've been keeping regarding sorting algorithms and data structures:
http://www.iti.fh-flensburg.de/lang/algorithmen/sortieren/algoen.htm
http://cg.scs.carleton.ca/~morin/misc/sortalg/

Since it's a phone interview it's probably an initial screening one to decide whether to bring you into the office for the 2nd round.  Most likely it will center on what you've done.  If they do get programming specific and you don't know the specific answer, then it's best to answer you don't know but counter that with "but here's how I would approach the problem..." and relate it to what you do know. 

Sort of like infamous Microsoft / Google type interview questions like "How many marbles can fit in a bus?"  What interviewers are looking for here is not the specific answer but to get a feel of how you would tackle the problem - your thought processes.  Assume marble has a radius of x and get its volume.  Measure the volume of the bus (without seats for simplicity sake). Divide that by the marble's volume... this is just one approach to answering the question.

Good luck.
Patrick

[urlwolf]

These are really excellent sites, thanks patthecat!

[tranglos]

I'm preparing for a phone interview.

If you have any time left in-between digging into all the technical stuff, check out Jeff Atwood's blog: codinghorror.com for some insights into the interview process. Not just the technical aspects, but also psychological angles of interviewing for a dev job. Just last week, for example, there was this post:

Coding Horror: Getting the Interview Phone Screen Right
http://www.codinghorror.com/blog/archives/001042.html

There's plenty of interesting bits about what interviewers look for, stuff to expect and stuff to avoid.

[iphigenie]

Oh, I never checked his site, and I have code complete

A great book on the craft and practice of programming is "the pragmatic programmer" - I have given that one a few times to people who had "migrated" into coding from some other beginnings, as it is very down to earth and introduces a lot of things without the academic weight. It creates a lot of "aha!" moments.

But I wouldnt who does pointed technical over the phone in a first interview is not being fair (unless the position is first line tech support!)... I would tend to ask more circumstancial questions that show to me that the person knows what they are talking about, so make them talk about projects or things like "what is the coolest thing you have done <insert language or technology here>" or "what is your pet peeve" or "why would you pick X / why would you NOT pick X" etc.

Codinghorror is cool, we get a laugh out of it quite regularly in the office 

[tinjaw]

I also suspect the initial phone interview will not be more than "Who are you?" and "What have you done?". However, that is good news because it means you have longer to study for the real technical interview.

My #1 piece of advice about technical interviews is: Be brutally honest.

Somebody who does know something in and out will spot a mark a mile away. I can tell easily when somebody is stumbling along on buzzwords and concepts and actually has never done it and has no clue.

There are two types of technical interviews, because their are two types of technical positions, beginner and advanced. For the advanced, they often need you to hit the ground running and be productive in about two weeks. They positions are usually on an established team that is looking to expand because their workload is growing on a big project and they need help fast. The beginner position is not simply beginner in terms of technical knowledge, but beginner in the sense the new guy on the team. This is a position they hope you enjoy and that you grow technically as you are mentored by the team.

In the former, you need solid technical knowledge. In the latter, you need a track record of taking on tasks, of any nature (like a PhD) and successfully completing it. You need to show a general knack for the logic of programming and a willingness to listen to your mentors.

As for study material, I agree with The Pragmatic Programmer: From Journeyman to Master and Jeff Atwood's blog. Also good are Joel Spolsky's two books. On the latter of the two, don't forget that part of being on a team is communicating about what you are doing, not just writing code.