[FoRK] Developer interviews and interviewing

Stephen D. Williams sdw at lig.net
Mon Feb 11 01:51:35 PST 2013

When considering the capabilities and qualifications of a developer, not only are we looking for specific and general knowledge and 
experience, personality, and fit, but also problem solving and coding ability.  Developers progress through different levels of 
understanding and mastery of different areas in their own way and may or may not have a good estimation of their own abilities.  
While being able to describe experience and successes in detail is important, and self-assessment can be helpful, there is no 
substitute for observing someone solve a new problem.  Fundamentally, we want to hire only great developers.  Once that is 
established, we have to determine if someone is up to speed or can get up to speed quickly on the specifics we need.

While computer science, IT, and related topics are too large to pick up much overnight, and problem solving is a life-long 
meta-skill, you can make what you can do more accessible by exercising your creative and technical capabilities on representative 
technical problems.  I suggest that prospective developers look into the following problem solving exercises so that they are more 
comfortable solving problems and coding comfortably in an interview setting:

Perhaps interesting: http://www.algorithmsforinterviews.com/

Good to be familiar with at least:

Using LinkedIn well:

In addition to the links above, the following may be helpful for interviewers:
- hide quoted text -
> Technical Interviews as Socratic Teaching
> Over the last three years at Google, I have conducted 140+ interviews for Software Engineering. My style of interviewing is to 
> start with a simple problem and develop it in various dimensions. Let us say we wish to find the intersection of two multi-sets. 
> There are myriad variations of this simple problem: what if the two sets are equi-sized, what if one is really tiny, how relevant 
> is the big-O notation, what if one set is gigantic and on-disk, what if the sets are on two different machines, and so on.
> The first twenty interviewees taught me a lot! There are many ways to "see" the solutions. It was a learning experience. 
> Thereafter, I started leading candidates to explore the inter-connections between various sub-problems, as skillfully as I could. 
> The extent of exploration possible in a limited amount of time helped me rank the candidates relative to each other. A major 
> personal challenge that I faced was to make sure no candidate feels bad at any point of time, and to keep the interview going 
> without any pauses especially when a candidate was fumbling with lack of insight or information.
> By the thirtieth interview, I realized the connection between my style of interviewing and Socratic teaching 
> <http://en.wikipedia.org/wiki/Socratic_method>! Some of the candidates had actually thanked me, saying that they had "learnt" 
> something new during the interview. Also, I had finished reading The Art of Teaching by Gilbert Highet 
> <http://www.amazon.com/Art-Teaching-Gilbert-Highet/dp/0679723145>, a wonderful book that I highly recommend to teachers of any kind.
> So in late December 2007, I wrote the following short article:
>     A technical interview is a meeting of two minds. The interviewer helps an aspirant explore a series of inter-related problems:
>     Socratic teaching in action. The extent of exploration depends upon the acumen of the aspirant and the level of preparation of
>     the teacher. Over time, interviews with aspirants from varied backgrounds imbue the teacher with a deep understanding of the
>     problem space. A bright aspirant sweeps through the problems quickly and sometimes gives new insights to the interviewer. Such
>     an aspirant is joy to talk to. A compassionate interviewer never makes an aspirant feel bad when communication breaks down or
>     when little progress is made in some problem.
> Around the same time, I was given the opportunity to interview Jim Roskind <http://www.roskind.com/>, whose humble homepage hides 
> his illustrious career: Ph.D. from MIT in 1983, co-founder of InfoSeek, VP at Netscape and VP/CTO at AOL. After the interview, I 
> received a warm e-mail from Jim:
>     Your interview in particular was a lot of fun. It was one of the first I've had in many many years where I had to think hard
>     about detailed problems that were not merely "trick questions" (where a person typically either knows the trick, or is
>     dumbfounded). In addition, I've never interviewed at a place where such a question (actually, series of related questions)
>     could be asked of an interviewee. I was hoping to have fun challenging discussions with folks at Google today, and you're
>     interview was clearly the most interesting and educational of the day. Thanks!!!!
> Approval of my technique by somebody as experienced as Jim Roskind assured me that my approach was sound. Thanks, Jim!

  The Most Important Interview Question of All Time - Part 1

Lou Adler 

Lou Adler 
January 17, 2013
inShare <javascript:void(0);>24K

      o Like
      o Comment(1,397)

/(/NOTE - this is not the ONLY question, just the most important./Make sure you check outTHE ANSWER 
<http://budurl.com/LIbloganswer>(Part 2) post. Part 3 is for job-seekers onhow to prepare for the interview <http://budurl.com/MIQ3>.)/

Over the past 30+ years as a recruiter, I can confirm that at least two-thirds of my hiring manager clients weren't very good at 
interviewing. Yet, over 90% thought they were. To overcome this situation, it was critical that I became a better interviewer than 
them, to prove with evidence that the candidate was competent and motivated to do the work required. This led me on a quest for the 
single best interview question that would allow me to overcome any incorrect assessment with actual evidence.

It took about 10 years of trial and error. Then I finally hit upon one question that did it all.

Here's it is:

/What single project or task would you consider the most significant accomplishment in your career so far?/

To see why this simple question is so powerful, imagine you're the candidate and I've just asked you this question. What 
accomplishment would you select? Then imagine over the course of the next 15-20 minutes I dug deeper and asked you about the 
following. How would you respond?

  * Can you give me a detailed overview of the accomplishment?
  * Tell me about the company, your title, your position, your role, and the team involved.
  * What were the actual results achieved?
  * When did it take place and how long did the project take.
  * Why you were chosen?
  * What were the 3-4 biggest challenges you faced and how did you deal with them?
  * Where did you go the extra mile or take the initiative?
  * Walk me through the plan, how you managed to it, and if it was successful.
  * Describe the environment and resources.
  * Describe your manager's style and whether you liked it or not.
  * Describe the technical skills needed to accomplish the objective and how they were used.
  * Some of the biggest mistakes you made.
  * Aspects of the project you truly enjoyed.
  * Aspects you didn't especially care about and how you handled them.
  * How you managed and influenced others, with lots of examples.
  * How you were managed, coached, and influenced by others, with lots of examples.
  * How you changed and grew as a person.
  * What you would do differently if you could do it again.
  * What type of formal recognition did you receive?

If the accomplishment was comparable to a real job requirement, and if the answer was detailed enough to take 15-20 minutes to 
complete, consider how much an interviewer would know about your ability to handle the job. The insight gained from this type of 
question would be remarkable. But the real issue is not the question, this is just a setup. The details underlying the 
accomplishment are what's most important. This is what real interviewing is about -- getting into the details and comparing what the 
candidate has accomplished in comparison to what needs to be accomplished. Don't waste time asking a lot of clever questions during 
the interview, or box checking their skills and experiences: spend time learning to get the answer to just this one question.

As you'll discover you'll then have all of the information to prove to other interviewers that their assessments were biased, 
superficial, emotional, too technical, intuitive or based on whether they liked the candidate or not. Getting the answer to this one 
question is all it takes.


Lou Adler is the Amazon best-selling author of/Hire With Your Head <http://budurl.com/hwyh712>/(Wiley, 2007) and the award-winning 
Nightingale-Conant audio program,/Talent Rules!/His latest book,/The Essential Guide for Hiring & Getting Hired 
<http://budurl.com/EGFH1>/, was published on February 1, 2013.


Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer

More information about the FoRK mailing list