ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

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

<< < (2/2)

urlwolf:

These are really excellent sites, thanks patthecat!

tranglos:
I'm preparing for a phone interview.
-urlwolf (January 28, 2008, 08:57 PM)
--- End quote ---

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  :P

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.

Navigation

[0] Message Index

[*] Previous page

Go to full version