Portfolios Shanti Braford asked:

While Google, Microsoft, Facebook, etc have an ongoing War for Talent, I wonder if another company could develop a system for developers who most Get Stuff Done, ship code, etc. (as in Joel’s “Smart & Gets Stuff Done” goal of hiring)

Looking at resumes only measures this trait so much. 2-minute academic coding problems usually measure IQ as opposed to brute coding that is more likely to be done in the wild.

Any ideas?

Well yes, as a matter of fact, I do have an idea:

Portfolios.

For example, this is my teaser portfolio. I also carry a physical portfolio to meetings with employers (the photos aren’t that impressive, but this is something I show in a face to face meeting, not something I use to justify meeting with me).

Quite simply, hire people who can show you evidence of their Smarts and ability to Get Stuff Done™. Of course, the big companies will seize everyone with IQs off the charts, GPAs through the roof, and all the other obvious traits. So you’re looking for people who are “false negatives” by the standard tests, people who don’t get an offer from Google, maybe they don’t even get an interview, but they’re great anyway.

Of course, a portfolio is not the only thing. Readers, please don’t write and say, “but you also need to ask them to write FizzBuzz,” or “what about Monopoly,” or “a degree from a good school shows they can handle doing the stuff they hate as well as the stuff they love.” I believe you! Test those things as well!!

I’m just saying, look for portfolios. Ask for them. Right in jour job ad, if you like.

p.s. I regularly receive requests for my résumé. I expect more requests now that I’ve officially announced that I am no longer working on my start up and am ready for the next chapter in my career. But it’s amazing how few people ask me to send a portfolio, or links to recent work, or source code samples.

Labels: jobs

  ¶ 9:12 AM 17 comments

  Icebreakers One of the problems with all interviews is that the formality and importance of the meeting forces people into rote, scripted behaviour. This makes it very difficult to determine whether someone is a good fit.

If someone tells you they are seeking “an opportunity to apply their dynamic skills and team-orientation to furthering the company’s mission in an upwardly mobile career position,” are they a snot-nosed corporate drone? Or are they saying what they think interviewers want to hear because they have invested far more time improving their development skills than time improving their interviewing skills?

Your job as an interviewer is to talk to the person, to get them talking about who they really are, not trying to guess what you might want to hear. “Icebreakers” are interview questions designed to put you both at ease and break out of the scripted, stilted talk that results in bad hires and missing good hires.

(That being said, I do not suggest that they be used to determine whether someone is a good candidate or not: with all of these questions, there really is no “right” answer, and if you try to read too much into the answers, you run the risk of evaluating the interviewee on the basis of whether they are your clone.^{1, 2})

So don’t go overboard: an interview should not be dominated by questions like these, any more than it should be dominated by computational complexity questions, algorithm discussions, design explorations, review of past achievements, or any other single factor.

I suggest you use one or two of these in an interview as a way of loosening things up. There’s anecdotal evidence that even very good candidates may react poorly to the pressure of a job interview, generating “false negatives.” Anything that lowers the pressure raises the chance of identifying great people for your team.

Bootstrapping

• What was the first computer you used? What was the first computer you programmed?


• What was your first programming language? What did you like about programming at the time?


• How did you get into this industry? Why? Do you still think that reason is/those reasons are important to you?

Programs

• What’s the most incredible program you’ve ever seen? Why?


• What’s the best software you’ve ever written? Why? Can I see it/try it?


• If you had a million dollars (cliché, but still) and you already did everything else you wanted to do, and now you could write any program you wanted, what would it be?

People

• Who’s the best programmer you’ve ever worked with? What made them great? What did you learn from them?


• What’s the best team you’ve ever seen? Why were they the best: Quality? Speed? Awesome Software? What’s the most important reason for their greatness?


• What’s the best company in the world? Why?

Languages

• What’s your favourite programming language (it doesn’t have to be work-related)? Why?


• Of all the languages you’ve used seriously, what is your least favourite? Why?


• I see from your résumé that you have experience with both Scala and SNOBOL (Pick any two, obviously). If you could pick any one feature from Scala and add it to SNOBOL, what would it be? if you could pick any one feature from SNOBOL and add it to Scala, what would it be?

Sharpening the Saw

• What’s the most recent serious thing you’ve learned? Why is it important?


• What’s the best way for you to learn something new? Formal education? Books? Hands on experimentation? Mentoring? A combination?


• Who’s the best teacher/mentor you’ve ever had? What made them great?

Final words

One final tip about icebreakers: Try sharing your own answers to the questions. You might not want to answer them first: some candidates will feel pressured to echo your responses, but there’s a lot of value in turning a question into a conversation. Don’t turn the conversation into a monologue: this isn’t your interview, and these are icebreakers, not some sort of secret mechanism for identifying talent.

Did you ever take that test yourself? Deckard?

As soon as you feel the conversation relaxing, move on to something important, be it asking the candidate to solve a problem or working through their experience in a more structured manner. Return to an icebreaker if thing stiffen up too much. Learn a little. Share a little. Laugh.

Remember, you are looking for someone who can make or break your team. You might want to talk with them first :-)

---

1. In my own case, I have spent a lot of time thinking about tools and languages. So I am always tempted to like programmers who have also spent a lot of time thinking about tools and languages. However, someone who is not particularly reflective about tools and languages might be a great contributor in certain roles that don’t have a heavy “sharpen the saw” emphasis. Or, they may be delighted to learn some new tricks if placed in a supportive environment.
   
   So the lesson for me is that if someone says the kind of thing I like to hear, great. If they don’t, I need to try another icebreaker, not evaluate them based on their response.


2. Here’s a dissenting view

Labels: jobs

  ¶ 10:20 AM 10 comments

  A caveat about job interviewing

Never hire an engineer on the basis of questions any idiot could answer.

If you ignore the above maxim, the result of your negligence may one day wind up becoming your boss.

(Follows: A caveat about job interviews)

Labels: jobs

  ¶ 5:13 PM 0 comments

  A caveat about job interviews

If you take a job with a company that asks you questions any idiot could answer, sooner or later they’re going to put you on a project with some idiot who answered them.

(Follow up: A caveat about job interviewing)

Labels: jobs

  ¶ 9:36 PM 0 comments

  Thank you for writing such a heartfelt critique of the Fizzbuzz screening question Dear Shelley Powers:

Thank you for writing such a heartfelt critique of the Fizzbuzz screening question. I’m not writing to argue with your observations: I think we both agree with your points.

First, I think we agree that is not true that 199 out of 200 programmers cannot actually program. Anyone who draws this conclusion from observing that 199 out of 200 (or any lesser ratio down to 1 out of 2) applicants for a programming job cannot program has omitted a very simple analysis.

Second, I think we agree that it is not necessary to ask screening questions, and that interviewers who fail to take advantage of alternatives when they are easily available is unprepared.

Third, I think we agree that some people place far too much emphasis on a screening question like Fizzbuzz, trying to extract all sorts of inferences about someone’s professional software development capabilities form what is—in every respect—a toy problem with almost no relationship to the work we do on a daily basis.

Fourth, I think we agree that some excellent candidates will feel anxiety in an interview situation, and that their “performance” on a test in front of a panel of interviewers will fall short of their performance under workplace conditions. And I certainly agree with your premise that workplace pressure is often not the same thing as performance anxiety.

All of my comments below are based on the premise that we are talking about “blind” applicants, people who have responded to a posting or people with CVs up on a job board.

Can 199 out of 200 programmers actually write programs?

Let’s perform this simple thought experiment (if you know anyone who is single and actively seeking a partner, they can carry out the experiment for real and report their results to us).

We register with a dating or personals site. We use the search facility to perform a fairly simple screen for “qualifications” like age, gender and gender orientation (presuming you care). Now, we contact every single person matching our search. How many are worth a second date? How many are, let’s be honest, completely unready to date?

After a few months of “dating,” people can become very cynical. “Where are all the good men/women/womyn?” They plaintively ask. The answer, we all know, is that good people are rarely looking. They are already in relationships. If they become single, after a reasonable period to recover from their experience, they date very briefly and then get into another relationship. They have a good network of friends and family that introduce them to eligible mates, so they have very little need for dating web sites.

People with “issues,” on the other hand, spend a lot of time dating and searching for mates but relatively less time in relationships. Their friends and family are reluctant to introduce them to potential partners because, deep down, their friends and family know they are not ready.

The net result is that on a dating site, the majority of the people looking for mates are not the people you want to meet. And if you try to judge people as a whole from dating sites, you will get a poorly skewed distribution. It is not a representative sample.

The fact is, the vast majority of people are wonderful partners. You cannot judge people as a whole from the people you find looking for blind dates.

And the vast majority of programmers can program.

It’s understandable that someone interviewing programmers from the available pool (like résumé boards or blind submissions to the company’s jobs@bigco.com email address) will become cynical and wonder “where are all the good programmers?” But it’s wrong to conclude that the vast majority of programmers are incompetent based on observations of people looking for programming jobs.

Is a screening question mandatory?

If there is no reason to worry that someone may not be an outstanding, qualified programmer, it is appropriate to screen them before investing time and energy in a full interview. Just as an applicant ought to be carefully screening the companies where she submits her CV. Are there alternatives to a screening question like Fizzbuzz? Of course there are.

Before I touch on a few, let me describe one that is not. Years of experience indicated on the CV, even if not falsified, is not evidence that an applicant can actually perform the work in a competent fashion. They must still be screened and interviewed.

It’s a paradox related to the dating analogy: if someone has five or more years of experience, why are they looking for a job? Why haven’t they compiled a network of friends and contacts? For five straight years recruiters have been calling them every week offering them a job. Why haven’t the recruiters found them a new position?

This person may be an incredible find who is looking due to unusual circumstances. Or they may be a wonderful developer with poor networking skills. But they may also be incompetent, and that’s the reason their friends, contacts, and recruiters haven’t placed them in a job.

So what alternatives do we have to asking a screening question? The best alternatives are entirely within the candidate’s control.

First, a candidate can belong to the “Insider’s Club.” Very simply, candidates who do not wish to be asked screening questions should only go on interviews where there has been a warm, personal referral from a trusted friend. I don’t mean Joe told you that Bob’s company is hiring and Bob sends your CV to HR. I mean you know Greta well and she takes you to lunch with Gwen, who is the hiring manager.

Not everyone is a great people person. That’s why it helps to have nature or nurture on your side. But everyone can become a better networker through practice. And nearly everyone should. Not just to avoid screening questions, but because a regular lunch with Greta is fun, and playing Ultimate with Joe’s team on Tuesday nights is a good workout.

If an interviewer still insists on screening such warm referrals… I don’t know what to say about that.

Second, I like your proposal that candidates bring samples of their work to interviews:

Having candidates bring in samples of code and having the interviewer and interview team review such, and question why decisions were or weren’t made is an excellent way of getting insight into the person’s problem solving skills.

For the last decade I have carried a portfolio to interviews with code samples, product brochures and awards, references, and other opportunities for the type of interaction you suggest. I would love it if every candidate brings such a portfolio to me when I’m interviewing them.

Even though I suggest it in nearly every invitation to an interview, most candidates show up with nothing except an eager expression on their face. I wish they would listen to you on this subject. No matter, by the time they have arrived I have already Googled them to see what they have on their home page, what they’ve written on their blog, and what they’ve contributed to OSS. Just as you suggest.

Alas, I often come up empty. (Not always: one candidate arrived with a book… that he had written! Another brought an actual shrink-wrapped Adobe product he had a part in developing). But note that you have a blog… I would never need to ask you about Fizzbuzz, I would much rather ask you about what you have written.¹

So candidates can avoid a lot of screening questions by blogging, contributing to open source, participating intelligently in on line professional forums, and bringing samples to interviews.

If an interviewer wants to ask me to write Fizzbuzz after reviewing my code that implements tail call optimization in Scheme… let’s just say that I will be amused.

Root of minus one, what I actually do in many cases, especially with new graduates, is mail people a problem. They can work on it in their own time without any pressure and get back to me when they have a solution. I have posted one such problem on my blog: designing a deck of cards.

I’m still waiting for the candidate who has Googled me before an interview and comes prepared with code for a deck of cards. That person I would hire: even if they copied the code off the internet, they have initiative and will make a contribution somewhere!

The work at home problem is still used to screen people out, so it’s kind of unfair to lump it under “ways to avoid a screening question.” But it isn’t a screening question in the sense that I plan on drill down and ask candidates questions about their code in a face to face meeting.

In some ways it’s worse than a screening question in the sense that it requires a larger investment on the part of the candidate and there’s more pressure to do well. It’s not just enough that it work, it must somehow please the interviewer.

I personally find that tough, more on that a few headings below.

Is the screening question a significant predictor of talent?

If someone doesn’t have a warm referral, and they don’t have the type of material you suggest, I need to know if they’re the person on their CV. Something dead simple like Fizzbuzz is impossible to screw up in an interview. I actually don’t believe you would fail this in an actual interview, even with your disclaimer.

But let’s pretend that I was too busy to Google you and you forgot to bring some samples and I ask you to write some code or diagram something. Let me be very clear: I’m not judging you on how well you write it, or whether you are nervous. Or even a trivial “nit” like whether you start at zero or forget that numbers divisible by fifteen should print “fizzbuzz.”

And I’m not going to put you on a pedestal if you write it in Haskell, or use recursion, or somehow torture Perl’s regular expression engine into doing the work. Although some interviewers insist that you write such tests in the lingua franca of their office, I always ask a candidate to write programming tests in whatever language they find easiest. PHP is acceptable.

All I’m trying to do is separate you from the people who don’t know that you want a loop (or recursion, or a range initializer, or whatever) and can’t even get started. This is a very Boolean gate.

When it’s done we’re not going to have along chat about your approach. I may even stop you before you’re finished if it looks like you know what you’re doing. I don’t want to waste time on it: once I know you aren’t impersonating the person on your CV, I want to forget about Fizzbuzz as fast as humanly possible and get to the real interview.

So really, the important thing about a screening question is to remember that it’s only a screening question. It’s not a be-all and end-all opportunity to judge a candidate’s coding style, or ability to elicit requirements, or cultural compatibility.

I’m not going to narrow my eyes into slits and demand that you “find the bug.” I’ll glance over your one page of code and then turn it face down. Or I’ll erase the whiteboard. And move on.

Do good people really get anxious enough to fail screening questions?

I agree that good people can fail a screening test from time to time. Do you want to hear a story about the time I was given a lukewarm referral into a company and somehow I was unable to write a program to print out the first one hundred prime numbers? My contact cursed me for choosing that day to have a brain cramp and devaluing his credibility as a judge of talent. We all have our days… this kind of thing keeps my feet firmly on the ground.

Every single technique has some kind of false negative. Interviewing is a statistical model: you employ a number of techniques in the aim of making sure you don’t accidentally toss out a great person or hire a duffer by mistake.

From my experience, the most important thing is not to fall prey to the mistake of making up your mind in the opening sixty seconds of an interview and using the remaining time to justify your prejudices. There are people with my experience—perhaps even me—who are duds. There are people with a funny accent or perhaps with experience in a programming language you despise who are brilliant thinkers and excellent communicators.

A good interview requires an open mind.

This is why the title of my own post on the subject of Fizzbuzz was Don’t overthink Fizzbuzz. It’s just one extremely brief part of a process that takes multiple meetings and many hours when I am looking for a great team mate. But that being said, I still look for people who can finish the problem, no matter how elegant or haphazardly they do it.

I can tell you what frightens me more than another “print the first one hundred primes” problem:

What frightens me is an interviewer cross-examining me with no apparent system or objective. Perhaps someone who has already pre-judged me as superficial because I brought code samples on a Macintosh instead of a Dell. Or who ignores my Java experience to spend the entire interview grilling me about how I could use an allegedly “unsafe” language like Ruby.

I personally find testing of any kind—whether a formal test like a programming problem or an informal test like an interview—produces anxiety. What increases the anxiety for me is not knowing how the test is graded. It’s like being asked to write a program without requirements from the client. That’s very stressful.

Quite honestly, this is a major flaw with the way some people administer screening questions. They ask you to write a program that does such-and-such. But they don’t say anything else. Are they looking for unit tests? Build scripts? Do they want golf-like brevity of code? Or do they want you to baby. talk. the. code. so. that. any. body. can. mouth. the. symbols. one. by. irritating. one.? Do they want comments from top to bottom? Or just comments to explain why not what?

Faced with this anxiety, a lot of candidates feel like they are playing “Guess the program I’m thinking of.” They worry that the interviewer is thinking of the one perfect answer (I wonder if it’s by strange coïncidence exactly what the interviewer would write themselves?). The candidate can think of a few things to write, but the main problem is choosing the right thing to write.

I personally think that the anxiety can be reduced by being very specific about the problem and what is being tested. I think it’s not just anxiety-provoking but outright harmful (to the interviewee and to the interviewer) to say little or nothing beyond the desired output (fizz… buzz… primes…) but attempt to draw conclusions about a candidate based on the code they wrote on the spur of the moment with no further guidance.

I agree it’s ridiculous to expect that the code for Fizzbuzz would resemble production code for a mission-critical web application, and one of the sources of anxiety for some candidates might be trying to “complexify” such a toy program to make it look like it belongs on BigCo’s heavy iron.

Thank you

Once again, thank you for taking the time to remind everyone not to glorify screener questions like Fizzbuzz. Although I have written this partly in support for your points and partly in defence of my own interviewing practices, your post has reminded me to be extra observant the next time I am interviewing. I do not want to let a good person become nervous: even if they “pass,” the extra pressure will put the meeting off stride.

I also want to thank you for your implied criticism of the tone of many blog posts. Yes, I have been frustrated with the quality of applicants the last few times I have been interviewing. But nevertheless, I need to be more clear about the difference between saying that 199 out of 200 applicants cannot code and 199 out of 200 working programmers cannot code.

Cordially,

Reginald Braithwaite

p.s. I am going on my very first diving holiday later this month. Your links to the ocean’s wonders are a timely discovery. Thanks! I am going with my partner, whom I happened to meet on a dating site! So I know that good people are looking and that they deserve the benefit of the doubt until proven otherwise, no matter what the previous 199 dates were like.

---

1. For example (and I say this gently, I am very pleased with your post), I might probe into whether you are the type who “does not suffer fools gladly,” based on the use of phrases like “arrogant twats” and “idiocy travels up the food chain” in your own post. Just as, I am sure, you would have plenty of questions to ask me if you took a few minutes to peruse my own blog.

Labels: jobs

  ¶ 12:02 PM 19 comments

  Make Money Fast! Kevin Barnes explaining the consequences of “great” coders¹ getting paid far too little:

In the end, this means that really great coders will keep getting paid less than they are worth and average ones will keep getting paid more, so the economic benefits of great skill will go primarily to the companies with the best employees and not to the employees themselves.

I have news for anyone outraged or disappointed by this true statement: all great employees are paid far less than the value they generate, even employees like salespeople that are paid proportionally.

Let me put it in this painfully direct manner: who lives better, the slave in the field, the slave in the house, or the master who owns the plantation?

Purely and simply, the money is in owning your own business. Every time. Without exception.² The point is that if you are any good at what you do, and if you want to earn more money, then you need to found a business. It can be a start up, a consulting business, or even a night club.³ That’s how you’ll get paid what you’re worth.

I’m not even close to being the first to point this out. ‘Props’ to Paul Graham⁴ for suggesting that starting companies is the best way for twenty-somethings to get paid something close to what they’re worth.

Update: A few people have pointed out that running a business is a skill that is orthogonal to coding. True. And a few people have pointed out that running a business is risky. Also true, and related: running a business without a modicum of business talent is akin to programming without being able to code fizzbuzz.⁵ That does not change the basic fact that if you wish to be paid more money, you must successfully run your own business.

Look, I’m not saying anything in life has a guarantee. If I said “A Porsche is faster than a Chevrolet,” you can point out that most people either cannot afford a Porsche or reasonably choose not to purchase one. But that doesn’t change the fact that the Porsche is still faster.

So if you have good reasons for not starting a business, fine. But that does not change the fact that the people who run businesses make more money than the people who work for the people who run businesses.

---

1. Let’s not argue about whether the bike shed ought to be green. If you think that coding is not a valuable skill, that the value is in communication, or architecture, or eliciting requirements, or some other characteristic of great software developers, feel free to apply some white out to your display and write the appropriate word in. Great developers, however you measure great, are underpaid. By the way, I have no evidence that great coders cannot communicate, do not design great architectures, or are unskilled at divining good requirements. So there.


2. The one exception I can think of raising would be Michael Milken, who earned more than half a billion dollars as an employee of Drexel Burnham Lambert. But a cursory examination of his circumstances reveals that he was running his own business under the Drexel banner.


3. Or possibly not a night club. See the comments.


4. Paul’s book, Hackers and Painters: Big Ideas from the Computer Age is another must-read.


5. Actually, getting and keeping a programming job without being able to program is significantly easier than running a business without any talent for it.

Labels: jobs

  ¶ 11:32 AM 9 comments

  Please design a deck of cards in Java Dear Future Colleague:

I’ve been asked to perform a quick technical evaluation of your résumé before we ask you in for an interview. You obviously have the right kind of experience and I’m looking forward to meeting you soon.

We are asking all candidates to perform a little exercise before coming in for the first meeting. I realize you have a great deal of relevant experience, so this will not take very much of your time at all.

And I’m sure you appreciate the fact that we value ability and merit above certifications and other pieces of paper.

Please design a deck of cards in Java

Imagine that we are writing a casino program. We are not going to write the whole program right now, just the part of the program that has to handle the decks of cards to be used by the rest of the program.

If you are not familiar with the kind of cards used in European card games (like Poker, Bridge, Blackjack, Crazy Eights, Rummy, and so on), please write back and I will give you a different problem. You should be comfortable with concepts like the ranks of the cards, the suits, shuffling, and dealing.

Your task is to design the interfaces and/or classes we would need for the deck(s) of cards. At a bare minimum, your classes should handle everything we need to know about decks of cards, the cards themselves, and operations on decks of cards like shuffling, dealing, removing cards from a deck (some games have one or two jokers, some don’t, some only use the cards from 9 and up, some from 7 and up, some use them all), and combining decks (Canasta uses two, four, six, or more decks of cards with jokers!)

You do not need to worry about the mechanics of games like hands of cards, ranking Poker hands, knowing about Trumps or Bowers (as in Euchre and Bridge), discard piles (as in most games), or melds (as in Gin, Rummy, and Canasta). Imagine that other people will write all of that stuff using your classes for decks and cards.

Please be specific about the interfaces, abstract classes, and concrete classes you will need. There is no need to actually write the bodies of methods, but please be specific about what the methods are called, what parameters they take, and what they return (if anything).

I am especially interested in the relationships between the classes. Although you don’t have to write out each method, if you expect that a method would call other methods in your design, please say so.

For example:

class Deck {

// calls Card.arrangeRelativeTo(Card othercard)
public void shuffle () { ... }

}

You can see that in this hypothetical design cards have some ability to arrange themselves relatively to each other and I am documenting that Decks can be shuffled and they use the Cards’ arrangeRelativeTo method to do so. Obviously, you don’t need to follow that design. It’s just an example.

This extends to constructors. Does creating a Deck create Cards? Or does it use Cards that already exist? Or are Cards not even objects but are represented by primitive types?

About UML

You can just write out the skeleton of the classes and interfaces. If you prefer to use UML, be my guest. As long as your design answers all of the questions I have, use whatever notation you prefer. Just don’t fall into the trap of letting the notation drive the design: just because a certain type of UML diagram doesn’t indicate the CREATES-A relationship, that doesn’t mean you shouldn’t add it: what’s important is the design, not the document.

Requirements?

Feel free to email or call with any questions you might have about requirements. This is not meant as a test of your ability to read my mind about what I want or to ask insightful questions. So, it’s ok to ask me questions. If you have a choice to make, it’s also ok to just decide.

For example, you might wonder how to represent which cards are left in a deck after dealings some out. Should you use a standard OO pattern like a List or Set? That might be fine if our Casino program is a single-user game. But if we are running a web-based virtual casino with many thousands of users, performance might be important enough that we consider using something like a bitfield for each deck.

If you want, you can ask what’s more important. Or you could just decide for yourself. Using a bitfield for performance is a fine decision. So is having a standard OO design. Each works well for a particular set of requirements.

So don’t be too concerned about asking a million questions. I just want to get a basic idea of your comfort level designing OO software.

Thanks,




Reg Braithwaite

p.s. This isn’t a trick question. There’s no right answer, and as I said above I don’t even expect full implementations, so you don’t even have to write code that compiles.

There is absolutely no need for a bunch of stuff I didn’t ask about, like requirements in three-ring binders or JUnit test cases. I know that you are probably tempted to show off your depth of experience and SDLC knowledge, however I really only want to know how you would approach the design in this question.

Please save the other stuff for the interview. Just because I don’t need to know about it right now doesn’t mean I don’t agree that it’s important!

Labels: java, jobs

  ¶ 10:00 AM 10 comments

  Don't Overthink FizzBuzz I noticed some traffic coming to my post on juggling from Using FizzBuzz to Find Developers who Grok Coding. Like me, the author is having trouble with the fact that 199 out of 200 applicants for every programming job can’t write code at all. I repeat: they can’t write any code whatsoever.

UPDATE: If you think that I just claimed that 199 out of 200 working programmers cannot code, stop immediately and either read my follow-up explaining the math, or read Joel’s article on why companies aren’t as picky as they think they are. Thank you.

So the author has decided to set the bar ridiculously low. As the post says:

I’ve come to discover that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.

He gives an example of a “tiny” problem that is quite suitable for a phone interview:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

One of the nice things about using a tiny problem is that anyone who has written actual code in the last six months will solve it in less than ten minutes. This is good because (a) it leaves more time for talking about important things, and (b) if the candidate can’t solve the problem you will find out right away and save yourself a lot of grief.

As you can imagine from a post like this, quite a few people have stepped forward with creative solutions. Here’s mine:

# fizzbuzz.rb
# see http://weblog.raganwald.com/2007/01/closures-and-higher-order-functions.html

def compose *lambdas
  if lambdas.empty?
    lambda { nil }
  elsif lambdas.size == 1
    lambdas.first
  else
    lambda do |n|
      lambdas.first.call(compose(*lambdas[1..-1]).call(n))
    end
  end
end

def carbonation(modulus, printable_form)
  i = 0
  lambda do |n|
    (i = (i + 1) % modulus) == 0 && printable_form || n
  end
end

print(((1..100).map
   &compose(
     carbonation(15, 'FizzBuzz'), 
     carbonation(5, 'Buzz'), 
     carbonation(3, 'Fizz'))).join(' '))

Right away I think you want to be careful if you ever trot a solution like this out in an actual interview. Here are some of the things that could go wrong:

• The interviewer merely wanted to go through the motions of demonstrating you could program. Now she’s going to have to get into a discussion with you about how your solution works, which is irritating and wastes time that could have been invested more profitably on a design question;


• The interviewer might presume that you will always find the most indirect route to the destination and decide you belong in an ivory tower;


• The interviewer might not understand your solution at first glance but will make up for this by “bikeshedding” and grilling you about some minor nit like the failure modes of using && and || instead of the if statement or the ternary operator;


• The interviewer might have just finished The Seasoned Schemer and grill you over why your solution doesn’t use the Y Combinator to implement compose (snap!).

Of course, some interviewers are just looking for an excuse to talk about technical issues and will not prejudge you in any way. Speaking for myself, I would laugh if you wrote something like this out. But then again, I once worked for someone who had won the second International Obfuscated C Contest.

Update: Don’t Overthink the Interview Either

If you are conducting an interview and you receive a cryptic answer, or an impossibly concise one-liner, or perhaps something like the above that is redolent of Higher Order Functions, do you embrace the candidate as a genius? Or perhaps avoid them as someone who cannot write clear, maintainable code?

I suggest the best answer is neither. Stay on track: you asked the question for the purpose of eliminating the 199 out of 200 that have absolutely no hope of ever producing working software. You have just identified that this person is the one in two hundred applicants who can actually code. Mission accomplished. You aren’t trying to get to HIRE or NO HIRE over the phone.

Invite them in for an interview: that’s the place where you can drill down and obtain their views on professional programming. Remember, this is a toy problem. Unless you load the question down with requirements that their answer resemble production code, why should you have any expectation that the candidate only knows one way to write software?

This is like trying to hire programmers who know both languages, FORTRAN and COBOL.

If you do ask them for production code, don’t be surprised if the best candidates decide not to work for you: they will rightly point out that FizzBuzz is not a realistic example of a production problem.

Overall I think the best approach as an interviewer is the simplest: pose the simple question. Indicate it is a screener designed to confirm that they are the person described on the resume.

If anything, tell them that there is no need for production artifacts like documentation and unit tests, you just want working code in as little time as they are able. The no-hopers won’t get it no matter how simple the question, and the good people won’t waste a lot of time with JavaDoc and xUnit.

And then make your decision based on one objective fact: does the code run and produce the desired output. Everything else is superfluous to the question of whether the candidate should be asked into your office for a face-to-face meeting.

Update: a response to some of the criticism.

Labels: jobs, lispy, ruby

  ¶ 9:49 PM 60 comments

  Trick or Bleep? I like to post fun stuff on Fridays. I also repost old stuff from time to time when my brain is page faulting or when something I’m reading reminds me of an old post. Today both were true: I spotted this post about interviews going wrong and I remembered an interview where I was the hapless victim.

There has been some refreshing commentary on the post and also on reddit. I want to give my thoughts on one issue. Was the interviewer posing a “trick question,” trying to find out how I negotiate conflict? This subject has attracted a lot of attention since Joel Spolsky recently raised the issue, and while it didn’t cross my mind at the time, it’s worth considering.

The question posed to me was, list all of the ways to call instance and class methods in Java. I listed a bunch of things, and at the end, I included:

    someInstanceVariable.staticMethod();
    // calls the staticMethod of someInstancevariable's declared class

The interviewer told me I was wrong, and I shrugged, explaining that I thought I was right, but no big deal if I was wrong, since I never use that style of call, so it wasn’t an issue. The interviewer later told me that he did not like my answer, and indeed I did not get an offer.

If this was a trick question, ok, you had me! I am not afraid to argue points where I believe there is a direct connection between the issue and the outcome of software development projects. If I really believe it is irrelevant, I don’t argue even if I have a personal preference. So I’ll happily go along with any particular coding style you advocate (including none), and if you insist that I use Eclipse for Java instead of TextMate, fine.

The problem with that question (let’s be clear, it’s my problem, not the interviewer’s problem), is that I don’t really care whether Java lets you call a static method via an instance of a class. The reason I don’t care, as I explained to the interviewer, is that I will never allow that code to get into the repository.

For those who are too busy with Lisp to know all of Java’s warts, the problem is that static or class methods are never polymorphic. So if you write:

    // (yes, I know about public vs. private. These are obviously in 'package scope')

class House {
    static String doorAction () { return "closes and locks"; }
}
class S___House extends House {
    static String doorAction () { return "bangs"; }
}

and you do this:

    final House structure = new S___House();
System.out.println(structure.doorAction());

You get closes and locks instead of bangs. Always. This is not what happens with instance methods, and that’s because so-called ‘static methods’ in Java are really global functions that live in class namespaces. The compiler resolves the function doorAction by looking up the declared type of structure at compile time. Its actual type at runtime is irrelevant. C++ programmers recognize this as the difference between virtual and non-virtual functions.

Back to the “trick question.” My problem is that since I never have and never will use this, I’m not going to argue whether it’s legal or not. It will never have the slightest impact on any project I’m on. If you want an argument, let’s discuss why you think we should use this idiom in production code.

I honestly don’t think it was a trick question. If the interviewer knew it was legal and wanted an argument, he could have (and I suggest should have) chosen a different thing to argue, something a little more obvious, such as telling me it is legal and polymorphic, and then seeing whether I (a) know that it is not polymorphic, and (b) argue with him.

I don’t use questions like this, but I can see the value of this second question: a really experienced person knows exactly why it isn’t polymorphic and can discuss the kinds of bugs you will get if you try to write code depending on it.

What do you think? Was this really a trick question? If so, should I have been more aggressive in arguing the subtle points of Java law?

p.s. The interviewer later told me that he did not like my answer, and indeed I did not get an offer: one benefit of much water having passed under the bridge is a more balanced perspective. I no longer assume that this one question is the only reason the interviewer decided I was not appropriate.

I may have been overqualified, too talkative, too reflective, or even too meticulous (when given the programming challenge of permuting a string, I was apparently the only candidate to ask what the output should be when the string contained duplicate letters). Perhaps the interviewer had already decided the interview outcome before this question was discussed.

And do you know what? I’m not so sure I wouldn’t have reacted the same way as the interviewer. One of the big “No Hire” flags for me is a candidate who doesn’t fundamentally “get” a programming language. Anyone can “Learn Blub in 21 Days,” memorizing code snippets and patterns by rote. But such candidates often have no clue how a language works, how its features interact with each other to make those memorized code snippets work.

Let’s say that I’m interviewing and I don’t know that Java (which isn’t particularly OO in theory or in practice) allows this bug of calling a static ‘method’ via an instance of a class. Is that so bad? Of course not, it’s a wart on the language. It’s not like knowing that it is allowed reveals a deep understanding of how Java works. So not knowing this isn’t a fundamental flaw in a Java developer or interviewer.

Now a candidate tells me that this thing works. Well, I might jump to the conclusion that the candidate really doesn’t get the difference between static and instance methods, that the candidate will have trouble understanding the various scoping issues involved with instance members and static members. I could easily believe that this candidate will draw a complete blank when working with inner classes.

An interviewer who didn’t happen to know this bit of Java trivia might reasonably infer that thinking it works betrays a superficial knowledge of Java.

Labels: java, jobs

  ¶ 8:14 PM 10 comments

  Take control of your interview I’m helping some colleagues interview programmers, and for once I’d like to offer some suggestions to the interviewees and not the interviewers. This post is about using the interview to maximize your chance of landing the right job.

have an objective

First, you need to walk in with an objective. No, not “to secure a strategically progressive position leveraging your forward-going architectural vision and hands-on experience to advance the division’s mission,” but a simple, tactical objective for the interview.

Here’s what I suggest. Think of three things you want the interviewer to know about you that you think they are unlikely to find out if they ask all the questions.

The important ideas are that (a) you want the interviewer to know about each of the three things, and that (b) the interviewer is unlikely to ask about all three if you don’t exercise some control over the interview.

Let’s start by ruling a few things out. First, don’t bother with how many years of technical experience you have with the company’s tools and platforms. If they are using in-house Common Lisp macros compiled to C and then distributed on a grid with MapReduce, I guarantee that they will ask whether you have any Lisp or distributed programming experience all by themselves. (You can still take advantage of your experience, I’ll show you how below.)

Second, rule out anything that doesn’t really help sell them on you. Yeah, yeah, hockey is competitive and it takes a special kind of focus to be a goalie. I get that, but it really only sells when the interviewer is also a hockey player. My suggestion is put that kind of thing at the bottom of your resumé and let them ask about it if they care.

the three things

The three things you want to take into the interview should be stuff that matters to them but is hard for them to ask about. Stuff that doesn’t pop out of your resumé. I don’t have a pat formula for generating these items that I can share, but here are a couple of ideas to get you started.

Remember the technology buzz-phrases we rejected (“five years of JEE” “Common Lisp”)? Think about the difference between yourself, presumably an expert in these areas, and someone who has only worked on one project with the same technology. You both touched all the same tools and code, but there’s something special about you, your extra experience means something. What is it?

Joel Spolsky and Peter Norvig both suggest that you cannot pick up a new programming language or platform and become proficient overnight. That being said, if you tell me that you have five years of experience, I have no idea whether you have five years of experience or whether you simply did the same thing over and over again. What is it that you learned that makes you special? What secrets to you possess that can’t be listed on your resumé?

For each person, there will be different answers. One person might say that their “secret sauce” is that they have learned the ins and outs of the platform, they know what works and what doesn’t, they know how to work around the shortcomings. Another might emphasize the non-technical skills. I would personally be impressed with anyone who said that what makes them special is that they are very, very accurate when they estimate tasks and projects.

This leads naturally to another area I would mine for nuggets: Soft or non-technical skills.

99% of the dreck you read about interviewing programmers is about finding out whether they can actually write programs. Rightly or wrongly, most interviewers focus on the hard skills. But if they never get around to discovering your ability to juggle priorities, or write effective technical documentation, or analyze requirements, how will they know that you are far and away superior to the other five people they will interview this week?

You have to tell them, that’s how they’ll find out.

tell them about it

Walk into the interview with your three things. Now, the interview is a game. Presuming you don’t get thrown out or you don’t walk out before it ends, you win the game if the interviewer discovered all three of your things. If you like games as a metaphor, call them goals.

If the interviewer asks you about one of your things, that’s an easy goal. Take it.

If the interviewer asks you if there’s anything you’d like to mention about yourself, that’s an easy goal. Talk about one of your things.

If the interviewer asks you about something related to one of your things, answer the interviewer’s question and then ‘coat tail’ your thing onto the end. For example:

Interviewer: It says here you worked on JProbe, that’s a Java tool, right?

Interviewee: Absolutely. JProbe is a suite of tools for JEE Server-Side development (answers the interviewer’s question). Under my management, we released three consecutive versions on schedule. I’m really hoping that there’s an opportunity to apply my focus on hitting plan to this team (adds on).

Watch politicians “staying on message.” Now matter what question they are asked, they spit out their own pat statements. You don’t want to be that plastic, but you have to take responsibility for a a successful interview. And you know what? If the interview ends with your best features undisclosed, the company loses as well.

One more time with the coat tail:

Interviewer: What’s your experience with Ruby?

Interviewee: Well, I was the lead developer on the Certitude project. We built that with Rails and we included a fairly heavy dose of Ruby idioms, including a domain-specific language for pattern-matching and lots of dynamic meta-programming (answers the interviewer’s question). One of the things I discovered on that project was the importance of a bomb-proof quality control process when you have such a powerful language. I customized our continuous integration server to track changed files, tests, bugs in a unified report interface so we could monitor the most troublesome modules. It really saved our bacon late in the project when we had to really tighten up our risk management to ship on time (the add on, emphasizing the process).

if all else fails

Perhaps you didn’t get a good opportunity to mention your three things and the interview is winding down to a close. Don’t try a desperation coat tail where you try to stick two completely unrelated things together. Instead, try using a question to introduce one of your things indirectly.

Some examples:

• “Could you describe the product management process for me?” leads to an oportunity to talk about your product management experience or your experience working with product managers.
  
• “What tools do you use for source code management, builds, and bug tracking?” is a great opportunity to talk about your experience with the full software development life cycle, not just the coding.
  
• “How do you plan and track ship dates?” turns the conversation towards how well you estimate dates, manage priorities, and your track record of shipping code on time.
  

Opportunities to ask questions should not be wasted on trivia like the company’s dental plan or whether they prefer cubicles to private offices (actually, neither are trivial, but they are not important until you have given the interviewer every reason to hire you).

My suggestion is to only ask questions about areas where you have something positive to contribute if the question leads to a spirited discussion. And the best way to make that happen is to plan in advance.

You have three things you want to say, and you should walk into the interview with three questions you can ask that will turn the conversation towards your agenda.

back to square one

So here’s how to get started.

1. List your three things you want the interviewer to know about you that you think they are unlikely to find out if they ask all the questions;
2. Write a one-paragraph description of for each thing that you could use to ‘coat tail’ onto another question;
3. Think of a question you could ask for each thing that would naturally lead to a discussion.

Good luck.

Labels: jobs, popular

  ¶ 5:11 PM 3 comments

  Three tips for getting a job through a recruiter In response to a question on the Joel on Software discussion forum:

I have obtained just one job in my career through a recruiter. It worked out well for me. If my experience can help you, great.

This is about what works for me, not the great be-all and end-all of how you can live your life. Especially for this subject: we're talking about making money. I once took a year off work because I didn't think there was a good fit with the companies hiring at the time. I've been told that most people consider this a poor career choice.

I happen to hire through recruiters from time to time, so I can also give you some perspective from the client end.

Update: Just to clarify, these points are about my personal experience working with recruiters on full-time employment.

Double submission

...one staffing company tried to tell me that a second submission would "cancel out" the first and the hiring company would simply reject me as a candidate.

This is 100% true. It's absolutely bad to have two recruiters submit your resume to the same client. Speaking as a client, I round-file any resume received through two recruiters. This is because I do not want to end up fighting with them over who should get paid. And they will fight.

The trouble is, the recruiter thinks that they only have upside to submitting your resume, even if the client already has the resume, or you've worked there in the past, or another recruiter has already submitted it. They will tell you all kinds of stories, such as "if you haven't submitted it in the last ninety days I can resubmit it for you." The recruiter would rather have a slim chance of a fee than no chance, and if your resume gets tossed, well, better luck with the next company.

Never mind what the recruiter wants to do, follow these guidelines:

Always ask for the client name. Recruiters will often stall, claiming the client demands confidentiality. Simply say that you may already have contacts into the company and you wish to save them time and trouble. If they still refuse, ask them what else thay have for you. Never submit your resume blindly. Sadly, some recruiters will screw things up and submit you without permission. It's your loss when this happens. The best you can do is refuse to do any further business with them.

If you have had any contact with that company about getting a job, especially if the company has seen your resume, do not allow the recruiter to submit your resume. Period. You can only lose, you can never gain. For example, I have your resume. Now I see it from a recruiter. I could have hired you without paying a fee. Now your resume has a big fat "+20% in cash" sign on it. It goes to the bottom of the pile. I don't want to argue with the recruiter if there's someone else who is "clean."

Of course, if you're the right person you get the job and I'll tough it out with the recruiter. But it's a lot of bother forwarding emails and stuff to prove I had you before the recruiter sent you in. I'm not going to bother unless you're exceptional. And if you're exceptional, you were already at the top of the pile and you didn't need the recruiter to help you get an interview. Capiche?

The corollary is that you must never go around the recruiter if you first heard of the opportunity through them. If your friend Steve works there and he never mentioned they were hiring, let the recruiter run with the ball and earn their fee. If your friend Steve mentioned that they are always looking for good people but you never gave Steve your resume, let the recruiter run with the ball and earn their fee.

If you gave Steve your resume and for whatever reason you didn't get an interview, but the recruiter tells you they're hiring, politely say that you are already working with the client and ask them what else they have. Then bug Steve to get things rolling.

Keywords

Recruiters are simple keyword-oriented pattern matching machines. J2EE? Check. Eclipse? Check. WebSphere? No? No submit.

Pad your resume with every keyword that might possibly fit. I used to put a keywords section at the bottom for their software programs. If you have a tenuous claim to knowing about something, put it down. For example, I claim J2EE and EJB. But quite honestly, my experience with non-EJB J2EE systems is way bigger than my experience with EJB J2EE systems. But EJB is one of my keywords.

They whole exercise is a waste if the client thinks you've lied, so here's what to do:

First, get a written job description from the recruiter. Don't settle for a verbal description. The recruiter can and will email you something, often exactly what the client emailed them. I've seen forwarded emails with sensitive information such as the client's secret budget objectives. Recruiters are in a hurry, and they love the 'forward' button.

Next, screen yourself out. If you have a scant claim to something and the client doesn't mention it, don't worry. But if it seems central to what they do, you'd better be honest: "Yeah, I put Ruby down because I used it on a student project, but I'm thinking that 37Signals might have high expectations... Let's pass on this one..." The recruiter will understand.

Don't play fast and loose, or you'll wind up coding a Monopoly game in a language and architecture you don't understand. Keywords are fine to get the recruiter to call you, but not fine to get you into an interview where you don't have what the client needs.

Disclosing your compensation

Now about disclosure. Google around. You will find that it is always a bad move to discuss your current or past compensation details with an employer. Guess what? That goes 2^n for recruiters. Do not discuss past or present compensation details with a recruiter. Ever.

As a client, I bug the recruiter to get that info so that I am armed with the power to underpay you when we negotiate. The recruiter gets to play the hard ass while I pretend to be Uncle Reg fighting to get you every dollar.

Ok, I'm not really that bad. But you know what? I'm human, I have a budget, and within a certain range of 'reasonable' for what you can do, it's my job to pay you closer to the bottom of the range and let you earn a raise. It's your job to get me to pay the top of the range and earn a raise anyways.

There're books written on the subject of negotiating salary. They all say the same damn thing. If you want the Coles Notes, when the recruiter says "no details, no submit," you say "You win, no submit." If the recruiter wants to take themselves out of the picture, that's their business. Don't believe them when they say the client insists. I prefer to have the details, but if Peter Norvig wants to meet me and won't tell me what Google is paying him, I'm not arguing.

Now I said you don't disclose details. I think you want to mention a range. Here's exactly what I say when people ask me:

Over the past five years, my compensation has ranged from X to Y dollars.

And when they press for more details, I ask them whether this is in the client's budget. If the answer is yes, let's submit the resume. And they will ask for more details. How much is base? How much bonus? How much last year? Does that include stock options? I blow off all additional details. If they can't submit my resume without additional details, that's their problem.

What the client needs is to know that you are neither too cheap (you must suck, or be ignorant, or both), nor too dear (motivated by money, or ignorant, or both). The range answers the question while giving very little away for the negotiation.

Here's how to calculate X and Y. Over the last five years, take the smallest base salary you've earned in any one year or at any one job. Include only the cash portion. This is X.

Now take the most you've earned in any one of the five years. Include the cash equivalent of perquisites like travel to trade shows or conferences, meals, drinks, everything (I drink two free cups of coffee a day. If I'm calculating Y for this year, I'm adding $2.20 a working day to Y).

That's your range. Notice how it works even if you've been at the same job for five years? Nice. And don't discuss this calculation with a recruiter, ever. Their job is to get you an interview. X and Y are all they need to get you the interview.

Speaking as a client, this is enough. I may want more before I make an offer, but this is enough to know whether I'm wasting your time bringing you in for an interview.

Okay, three tips. That's enough for now. Good luck with your search.

p.s. Why is it so much worse to tell a recruiter your compensation details? Because recruiters will tell everyone. If you tell one prospective employer exactly what you made last year, they do not tell every other employer. They probably consider it advantageous to keep that information to themselves. You've damaged your ability to negotiate with them, but if things don't work out, you can start again with a fresh slate at the next interview.

But if you tell a recruiter, they put it on your file and every time they send your resume out they will send that information with it. Really nasty recruiters will use you to sell other candidates (Ok, you like Kate but you want to see a few more people? Well, I can send you Reg, but he's asking 20% more. If I were you, I'd make an offer to Kate before someone else gets her). If the recruiter has no idea about your compensation history, or only has a broad range, the recruiter will probably send your resume in.

But if they know your exact details, the shortest line between this situation and their fee is pushing Kate instead of you. Not only are you screwed with clients that want to make you an offer, you're screwed with clients that haven't even interviewed you yet! Speaking as a client, I might have liked you so much more that I would happily pay more. But it's hard to know that if I haven't met you, and it's hard for me to have the optimism that somehow you're going to be worth the extra 20% when I haven't seen you juggle.

Don't tell recruiters anything more than X and Y. And even then, skip X and Y if you can.

p.p.s. An interesting link, via lifehack.org: How to Answer the Toughest Interview Questions.

Update: Welcome, Recruiters. Seriously.

Please continue to post whatever you like in the comments on my blog. I'm not going to debate you here, but I won't delete your posts either.

Please keep a few things in mind. First, I'm almost always the client when working with people like you, so I'm only seeing half of the story, the half where you work very hard to convince me that everything you do is in the interest of me, the paying client and not in the interest of the candidate. It gives me a warped perspective, you know?

Second, this is my experience, what I think works for me, right or wrong. You're right that there are other ways. There are thousands of people who have worked with recruiters, broke all of my so-called rules, and nevertheless they seem very happy with the results. Am I calling them on the phone and telling them they were wrong? Of course not.

Third, you really ought to have your own blog where you run the voodoo down for us. Tell us who you are, how you work, and what you think candidates ought to do. Be specific: tell us why it's in the candidate's best interests to allow you to submit their resume to companies without you disclosing the company to them. Tell us why it's in the candidate's best interests to disclose their compensation details to you.

I look forward to reading what you have to say. I'm not young enough to know everything, and I may pick up a tip that will be useful to me. Speaking as a client, I look forward to hearing how your advice for candidates also happens to be in my best interests as an employer. Whether on contingency or retainer, you almost always work for me, the client. Isn't your obligation to act in the employer's best interests? Or am I wrong about that?

Your blog is sure to be an interesting read. C'mon back when you've got something to say and put a link in the comments here. I look forward to hearing from you.

Labels: jobs

  ¶ 2:33 PM 28 comments

  The worst interview question I've never been asked What does this code do?

perl -e '$i=$ARGV[0];$i++while("."x$i)=~/^(..+?)\1+$/;print"$i\n";' 90



(code snarfed from GuyWithLag on reddit.)

Labels: jobs

  ¶ 1:06 PM 7 comments

  Hiring a Juggler Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.

Manager: Do you work with flaming objects?
Candidate: Sure.

Manager: …knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.

Manager: Do you have a line in funny patter that goes with your juggling?
Candidate: It’s hilarious.

Manager: Well that sounds fine. I guess you’re hired.
Candidate: Umm… Don’t you want to see me juggle?

Manager: Gee, I never thought of that.

“It would be ludicrous to think of hiring a juggler without first seeing him perform. That’s just common sense. Yet when you set out to hire an engineer or a designer or a programmer or a group manager, the rules of common sense are often suspended. You don’t ask to see a design or a program or anything. In fact, the interview is just talk.”

(HIRING A JUGGLER, Chapter 15 of Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister.)

Update: Some relevant links

Of course, some interviewers are just looking for an excuse to talk about technical issues and will not prejudge you in any way. Speaking for myself, I would laugh if you wrote something like this out. But then again, I once worked for someone who had won the second International Obfuscated C Contest.

Don’t Overthink Fizzbuzz

What I’m about to say will be blindingly obvious to the Enterprise crowd (sorry, not you over there with the Greasemonkey script that translates your web email to Klingon). The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications.

My favourite interview question

<

In case you didn’t know this, about 1/3 of all technical interview questions worldwide are variants of “How do you fit 10 pounds of crap in a five-pound bag?” Examples: how do you reverse a string in place, how do you sort a billion numbers, how do you write a decent compiler backend for an architecture with only four frigging registers, how do you handle fair scheduling when someone just forked off 1000 copies of some Towers of Hanoi simulation, etc.

Interviewing Ruby programmers

I’m exaggerating a lot, but the point is, when you select 1 out of 200 applicants, the other 199 don’t give up and go into plumbing (although I wish they would… plumbers are impossible to find). They apply again somewhere else, and contribute to some other employer’s self-delusions about how selective they are.

Joel on Hiring

And then there is the issue of why would someone care if I knew how to write a file copy function, ahead of what the difference between an interface and an abstract class was. Or when would I use encapsulation? Or in my design, how would I choose between polymorphism or inheritance? Or what pattern would I recommend for dealing with a general or specific problem?

What’s with the programming test!?

I know lots and lots of interviewers, at many companies, who’ve decided that they can fully evaluate you based on whether you can solve some particular convex optimization problem (or graph-search problem, or logic problem, or whatever their pet Elephant Question is), and they ask every candidate this question regardless of their background or experience. In fact, I’d estimate that some 10% of all technical interviewers ask the same questions, year after year, and they could care less about your experience.

The Truth About Interviewing

Labels: jobs, popular

  ¶ 2:09 PM 12 comments

  My favourite interview question Some years back, I was interviewed by an interesting start-up in Palo Alto. I was really tempted to take their offer, mostly because:

1. One of the interviewers was an avid Ultimate player;
2. Stanford. In walking distance. (And the regular Stanford Friz-ball variant game);
3. They asked me a question which has become my favourite interview question to ask and to answer.

The question they asked was:



Of course there’s a lot to be learned on both sides when an interviewee is asked to design something and explain their design. Both parties learn a lot about each other’s communication styles and approach.

It works both ways: for example, if I were sketching out a design and the interviewers repeatedly interrupted me to discuss my UML notation, I could infer certain things about their culture.

Those kinds of issues apply to any reasonably sized design problem. Anything larger than, say, “write a procedure that reverses a string in place.” But let’s look at three of the characteristics of the game of Monopoly that I find attractive for this exercise:

• Monopoly is poorly defined;
• Monopoly requires more than simplistic object design, and;
• Monopoly is too big to be designed in one session.
  

First, Monopoly is poorly defined. Chess, for example, is rigorous. The official rules of Monopoly are silent on some critical questions and vague on others. A tournament-playing aficionado will realize this immediately, but it’s easy to guide a candidate to this realization by asking some of the well-known FAQ questions.

This ‘problem’ makes it a great interview question. It drives a lot of valuable interaction between the candidate and the interviewers. You have to ask questions, make assumptions, and know when to stop gathering requirements and start driving the design.

There have been some blog posts pointing out that even trivial requirements can have many hidden implications. A determined and finicky developer can drive questions for the length of the interview. I think Monopoly’s missing requirements actually improve its suitability as an interview question.

If the candidate uses up all of the interview time trying to obtain perfect requirements, we have a problem. In the software development I do, the requirements are never perfect. I don’t demand that a candidate try to create an agile, iterative process on the spot, but I look for someone who knows when to say “close enough, let’s move forward.”

Another good way to move forward for both interviewer and candidate is to say, “ok, we’ve covered the most important requirements. Let’s make a bunch of assumptions and document them. In a real-world situation we could obtain feedback on the assumptions after presenting an initial approach.”

After all, who’s to say that a programmer, designer, or architect is always 100% beholden to others for requirements?

The second reason I like this problem is that Monopoly requires more than just a simplistic object design. What I’m about to say will be blindingly obvious to the Enterprise crowd (sorry, not you over there with the Greasemonkey script that translates your web email to Klingon). The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications.

Now let’s talk about ‘object-oriented programming’ for a second. 99% of the stuff you read discusses modeling real-world physical objects. Things. Nouns. It is a Kingdom of Nouns. Most candidates start every design by dutifully listing all of the nouns they can think of and then they spend the rest of the time available thinking about piling them into phyla, hierarchies of “IS-A” and “A-KIND-OF.”

This approach, which I will call “noun and verb,” is so limited I’ll dare to call it brain damaged. In fun. But seriously, competent software developers spend much more time on relationships, responsibilities, and constraints than they do on trying to prematurely optimize reuse through inheritance.

Now let’s ask a question about Monopoly (and Enterprise software). Where do the rules live? In a noun-oriented design, the rules are smooshed and smeared across the design, because every single object is responsible for knowing everything about everything that it can ‘do’. All the verbs are glued to the nouns as methods.

Let’s take a look at a simple rules question. If a player owns Baltic Avenue, can she add a house to it?

Well, there’s a bunch of stuff about whether she can afford it and whether there is a house available in the bank. Where does that live? In the bank object? And there is a bunch of stuff about whether it is either the player’s turn or between turns. Where does that live?

And there is a bunch of stuff about whether the property already has four houses. Where does that live? Somewhere in the property hierarchy? Sounds reasonable. Now what about mortgaged property? If Baltic is mortgaged, the answer is no. That’s easy. But what if Mediterranean Avenue is mortgaged? And what if, for example, Baltic has one house but Mediterranean has none? Where does that logic live? Both of these last two questions involve knowing something about the other properties of a colour group.

Now you can debate which verbs belong to which nouns, but here is an opportunity to step back a bit and consider the larger implications of maintaining such a ‘classical’ OO design.

Consider a ‘noun and verb’ design. First, an easy question. How well does the design document the actual game of Monopoly? If someone were to read the source code, do you think they could learn how to play the actual game?

Is this a stupid question? I think it strikes at the root of sustainable software development. In real world applications, software lives for a long time and teams change over that time. Programmers are often asked to maintain software with insufficient training in its intended use.

OO programs can be brilliant communicators in some designs (“here’s everything I need to know about a Money Transfer”) and terrible in others. I think this is part of the appeal and effectiveness) of the Domain Specific Language approach. It does a better job of communicating its intentions than a simple OO design.

I’m not saying that a DSL is right for Monopoly. Or wrong. Just that it’s valuable to consider this issue when discussing an approach. There is a lot of opportunity for a candidate and the interviewers to learn about each other’s thinking that goes way beyond coding if you spend a few moments discussing the importance (or irrelevance) of a design that communicates its intentions. And I think that makes Monopoly a good design subject.

Another issue about the rules. In software development, requirements often change. What kinds of requirements changes are easy with the design? What kinds are difficult?

I suspect it’s easy to change the prices and names of properties, but very difficult to change the fundamental rules. Well, it’s probably easy to introduce the popular ‘lottery’ variation where fines are paid into a pool and anyone landing on Free Parking’ scoops it up. But some of the more esoteric variations would require making lots of changes to many different classes.

The ‘noun and verb’ design is tightly coupled, and distributes the rules across the design. If you really want a mess, consider that popular computer versions of Monopoly allow you to pick and choose rules variations for each game.

The key to making this easy is to find another way to represent the rules. I generally provide hints along these lines by asking the candidate how they plan to implement the Chance and Community Chest cards. What is the relationship between the cards, special squares like “Luxury Tax,” and introducing variant rules?

(You can probably save yourself a lot of interview time. Instead of all this hoopla, ask the candidate to describe when they have actually used the Strategy, Visitor, and Command patterns outside of a framework.)

The bottom line is that designing a Monopoly game requires giving a lot of thought to representing the rules. There are a lot of ways to do that. I’ve hinted at two, and you I’ve heard of a lot of other interesting approaches. It’s a great chance to really go beyond OOP 101.

Now to close as rapidly as possible with what I consider an essential characteristic of a good design problem, and one that applies here. Monopoly is too large to solve in one interview. This is related to the vague requirements characteristic I mentioned above.

The reason this is important is that it forces the designer to pick and choose what elements of the design to solve in limited time. Some candidates will fail outright because their problem solving style is to consider all of the implications before starting. It’s easy to spend hours on a problem like Monopoly. But will you get up and apply the marker to the white board?

>Does a candidate start with the trivia? Who cares how to represent the colour of a property? CSS? A getter in each object? Yawn. I’ll prod him to move along.

Perhaps a candidate spends all of her time working in an area of the problem she knows well. Some candidates can spend forever engineering a Monopoly Online site up to Web 1.0 scale. Or building FTD.com-like