Technical Interview and Steve Yegge's "Get That Job At Google" Post

 Having been on both sides of the table as a former software developer (not with Google), I can confirm that the interview described is pretty standard. In my experience, interviews for development roles are broken into technical and non-technical sections.  The blog post is somewhat biased toward the technical side but the intent of the post seems to be to highlight what is different about Google, ie beyond the basic behavioral interview your should expect almost everywhere. Some of the things I noticed that are inline with MT guidance are:

1. Preparation in both knowledge of the basic material and in its' effective communication (practice by having a friend interview you).
2. Get rest the night before and to psych yourself up beforehand.
3. Directly answer the questioned that you are asked.
4. Avoid answers that paint you as an arrogant producer (you will be working as part of a team).
5. Be prepared to demonstrate your skill at something they are hiring you to do.
6. It's about the process you use to get to the answer, not just about getting answer correct .

As for the technical questions, the same set of algorithmic solutions apply to the majority of problems.  The better your understanding of the tools in the toolbox, the better you will be able to customize a technical solution to the problem at hand.  Also, the technical stuff cited is more fundamental (A BS in computer science should cover the majority of it) than knowing the hot topic of the day.
 
Thanks for posting the link. - Sam

(Background: I'm a hiring manager for sysadmins, tech support people, and the occasional front-line manager thereof, and have worked in and interviewed for those positions most of my career, except for a brief stint driving trains -- of which the interview phase was surprisingly valuable in giving me an alternate view of how interviewing can be done)

Whilst I have restructured my company's hiring practices (for the roles I'm involved in) to include MT-inspired behavioural questions, I firmly believe that they are not enough, on their own, to be able to sufficiently determine a candidate's suitability for the role.  Historically, my company's interview process was centered around a written technical quiz, and I haven't removed it from the interview process (and I have no intention of ever doing so).

The problem is that the candidate gets to pick the stories they tell, and while you can (and must!) interject to get more information about the candidate's thought processes, if I'm getting a bunch of stories about tracking down performance problems, and I need my candidate to be able to fix performance problems *and* write some scripts, I can't tell if I'm getting a certain set of stories because they're the most appropriate ones or because they're the *only* ones.

My guess as to why you perhaps don't do a big "technical" interview (where I define that as "assessing the candidate's ability to recall and apply the industry-specific body-of-knowledge", rather than firm-specific "fit", or other "soft" skills) in the legal profession is that you've got to pass an (as I understand it) strong technical assessment (a bar exam or equivalent) before you can even hope to get a job *anywhere* in the industry.  As such, you can be fairly sure that any candidate who comes to you having passed the bar exam will know the basics of the law.

No such qualifying exam exists in IT, and so we've essentially got to do the equivalent of a bar exam to every candidate who comes through the door, just to make sure they've got the slightest hope of being able to do the job.  (Before you ask: no, a degree is *not* sufficient -- I taught some classes at a University, I know what goes on, and there are no shortage of graduates of "reputable" CS programs who I wouldn't trust to plug in my toaster, let alone administer systems).  I suspect that the lack of a baseline industry-wide certification, and a very different focus on what makes a "good" employee, pretty much explains the difference in interview structure between the two professions.

As an aside, I've actually been through (and passed) the Google interview process -- in many ways, it has elements of behavioural and roleplay interviewing as part of the lengthy technical interview you go through.  The pre-qualifying phone screens were in effect "tech quizzes", or "bar exams", and the in-person interviews were, for all intents and purposes, role-plays of various aspects of the day-to-day work in the job I was interviewing for.  There wasn't a formal "behavioural questioning" part, and no interviews with "the hiring manager" (I think you get assigned to a team after you join the company -- in my case, the team I was interviewing for hadn't been formed yet, and they didn't have a manager at all yet), and that might be hurting them a little bit, but it's not a million miles away from the spirit of what MT recommends, in my opinion.

I'm interviewing at Google on Monday (wish me luck!). In my case, I'm interviewing for a management job, and it is for a particular role on a particular team. The recruiter has made it clear that I'll be questioned both on technical stuff (all managers are expected to keep their chops up and for this particular role I will initially be an individual contributor and then grow a team) and on management problems - how to deal with various personnel situations, how to attract talent, how to motivate folks, etc. I've never had formal training as a manager and most of my success has been from the gut, but I think my last few months on ManagerTools will help me a great deal with some of these questions. 

My wife is a lawyer, so  the shoe is on the other foot from SAMBEROZ. She works for the Court of Appeals and I know that they do have new candidates do a writing sample where they're presented a particular problem and have a certain amount of time to analyze the problem and write a brief of a sort. These weigh heavily in their hiring process. Of course, on the court the main job is doing exactly that - analysis and writing - so it might not be appropriate for a litigation position, etc. 

One MT/CT difference is I've been told by MANY people to NOT wear a suit. Goes against my instincts, and certainly when I interview at financial software companies (my most recent job) I'm always in a suit and tie. But the recruiter says a sweater instead of a jacket is much better - that they're very casual at Google. If I had an interview with an executive, I'd wear the suit, but I don't think that will happen. 

OK - back to Yegge's and my recruiters' lists of things to prepare for!

Cheers,

      Jim