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

  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

  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

  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

  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

  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

  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

  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

  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

  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

  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

  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

  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

  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 reliability. Whatever.

I’m not saying that’s bad. Or good. But I will say that given a problem too large to solve in the time allotted, there’s fantastic value in evaluating what’s important. And that cuts both ways. If you think that some of the OO design choices are critical but the interviewers hand wave it and want to see how you plan to handle 10,000 requests per minute, that’s revealing.

Summary

I like asking (and being asked) about Monopoly because it provides fertile ground for discussing issues that are critical to judging both competence and cultural fit, like:

• Communication style and skills;
• Deep OO design philosophy;
• Prioritization and time management, and;
• Handling ambiguity.

And now, if you have a moment, I’d like to ask for your feedback. Is there a better design question to ask? What is your perspective as an interviewee? What other issues about a design should be discussed during an interview?

I’m looking forward to hearing from you. Thanks in advance!

Update: A cautionary note

Some people have objected to this question because it may be a trivia challenge: how well does the candidate know the game of Monopoly? In the comments I mentioned that the question really only applies to candidates that already know the game.

Others have suggested it may be a form of “guess the design I’m thinking of” where there is exactly one right answer, the design the interviewer has already come up with. I think this is a legitimate concern.

It really applies to any interview question. For example: “name your three strengths” or “tell me about a challenge you faced in your last position and how you overcame the obstacles.” If an interviewer is looking for something specific, they can and will twist any interview question into a variation of “guess the answer I’m thinking of.”

I won’t say that Monopoly is somehow better than other questions in this regard, nor is it worse. If you have an interview based on reviewing a candidate’s past accomplishments, don’t you think there are some interviewers that will discount those that don’t fit their personal criteria for merit?

I once had an interview where the interviewer spent forty minutes talking to me about my education, and something like fifteen talking about my fifteen years (at that time) of actual career experience. Bias in an interviewer is orthogonal to the choice of interviewing technique.

What do these two cautions have in common? Only that the most important thing for a successful interview is that the interviewer be genuinely seeking out a view of the candidate’s strengths and weaknesses. All I can really say about this question is that if (and it’s a big if) the interviewer is sincerely attempting to evaluate a candidate’s technical ability, and if the candidate has some familiarity with the game, then the session can be very productive.

Update: Some relevant links

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.

The bottom line in my interviewing technique is that smart people can generally tell if they’re talking to other smart people by having a conversation with them on a difficult or highly technical subject, and the interview question is really just a pretext to have a conversation on a difficult subject so that the interviewer’s judgement can form an opinion on whether this is a smart person or not.

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.

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 back end 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.

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.

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?

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.

Labels: jobs, popular

  ¶ 10:45 AM

  An Encounter with a Programming Interview Problem From the NexTag Java Development Jobs Page:

Given a deck of nCards unique cards, cut the deck iCut cards from top and perform a perfect shuffle. A perfect shuffle begins by putting down the bottom card from the top portion of the deck followed by the bottom card from the bottom portion of the deck followed by the next card from the top portion, etc., alternating cards until one portion is used up. The remaining cards go on top. The problem is to find the number of perfect shuffles required to return the deck to its original order. Your function should be declared as:

static long shuffles(int nCards,int iCut);

Please send the result of shuffles(1002,101) along with your program and your resume to 'resume' at nextag.com.

I saw mention of this over on reddit.com. It couldn't have come at a better time. I'd just read a provocative essay on programming's mediocracy: Beating the Average makes the point that programmers are terrible at judging their own skills. We all think we're good enough, and our environment does not promote the kind of objective competition and ranking that would shake us out of our complacency.

There's a name for this: The Lake Wobegon Effect. (This is related to the Blub Paradox, of course). How do we break out of this comfort zone? One way is by solving puzzles and problems where our solution is ranked against others. With that in mind, I decided to try this puzzle over lunch today.

My code runs in sixteen milliseconds or so on JDK 1.5/Eclipse in a garden-variety PC. After googling around, I discovered that the first version of my code could have been tighter and faster. That's terrific: I actually learned something by not being the best and the brightest today.

But worries me is this: how do I know whether my code could be even better? The Blub paradox dooms me to thinking I've got the answer, when perhaps I could be even better than I am. (If my code could be better, please comment or email. I want to hear from you!)

My tip is to seek out problems like this from time to time. Don't settle for thinking up the approach in your head and considering the actual coding to be an insignificant exercise in typing. Go ahead and write clean, debugged code, preferably with a time limit to put some pressure on yourself.

(By the way, some people argue that this type of problem has little to do with Enterprise stacks and all the other cruft of a daytime gig. This is a thinly veiled excuse for not trying, and roughly equivalent to an NFL linebacker refusing to do the bench press because an actual football game is more complicated than simply pushing an iron weight over his head while lying flat on his back.)

Labels: jobs

  ¶ 2:35 PM

  I heard you twice the first time Dear programmer:

Most people have at least one manager. They may not have eight managers, but they have at least one. The way the software business is usually structured, most programmers have two managers.

The first manager is often called a team leader. Programmers report directly to the team leader and work with her on a daily basis. Team leaders direct the work of programmers, mentor them, and evaluate their contribution.

Team leaders do not have true 'hire/fire' authority. They also usually don't have final say over things like deadlines and requirements (although this may not be the most effective way to do things, that's how it usually works). In other industries, team leaders often have titles like 'supervisor,' reflecting the fact that they direct the work but have little tangible authority.

Programmers also usually have a true manager, often the team leader's direct manager. This manager has some real authority, usually including the authority to hire, fire, set pay or bonus, and negotiate what can be done by when.

Most programmers have no trouble with this setup. They work well with their team leader, have a reasonable (but not awestruck) respect for their team leader's manager, and in the fullness of time their contributions are recognized in the form of a promotion to team leader or something more technical like 'architect' (whatever that means).

However... From time to time a programmer chafes. He smarts at the setup. He agitates.

In my experience, there are several reasons for this. Many programmers don't respect their team leader's technical competence. Some programmers combine an adversarial personality with a short term horizon, and they have trouble reporting to someone who can't impose immediate consequences or rewards. Some feel unfairly treated because they are not the anointed team leader and feel the need to express this feeling at every opportunity.

Obviously, the programmer, the team leader, and the team as a whole suffers when one of the members of the team begins to express their frustration with the situation. I'd like to share the manager's perspective. What do you think is running through my mind when the feces begin to flow uphill and land in my in box?

The first thing is, obviously the programmer is sending me a message that he feels the setup is wrong. He ought to be the team leader, or we shouldn't have a team leader, or maybe we should have a team and a team leader but he's an exception and ought to report to me, or we should have a separate technical structure and he should report to the Exalted Grand Visionary Poobah of Architecture Astronautics, or some other scheme.

Well, my door is open and I want to listen, and it's ok to tell me that. But do me a favour, okay? Tell me directly and tell me once.

Quite often people walk around with this dysfunctional idea that there's a black and white, right and wrong for everything. When things aren't exactly so, they say things "ought to" be another way. By strange coincidence, the way things "ought to be" happens to be something that favours them. Go figure.

Anyways, I have found that this "ought to" mentality invariably walks in tandem with a belief that everyone should know how things ought to be. This means, in practice, that the "ought to" believer shouldn't have to explain how things ought to be, the rest of us should just get it.

Please, please, please don't let this pathology take over your career. If you have an issue, the very best thing to do is pretend that I'm a smart guy, that I get it, that I understand and support you, and that perhaps I've been a little busy with a ton of other things that need my attention. So just walk up to me and tell me flat out what you want and why you want it.

Don't drop hints. Don't undermine the team leader. I may not act like I get why you shouldn't have a team leader, but I totally get that something's wrong when you constantly come to me for decisions and information that you should be getting from the team leader. Sure, I'm pissed off at the team leader for not keeping you happy.

And if that's the reaction you wanted, congratulations. But don't think that somehow you're smelling like a rose. After all, everyone else seems to be getting along ok. Am I supposed to believe that you are the sole voice of reason in the building?

I also get that something's wrong when you undermine the team leader by somehow forgetting to do or being to busy to do a zillion things she asks you to do, like the administrivia of project management. But you know I don't get? I don't get the reports and statistics and numbers I need to do my job, which is convincing the people that write the cheques to keep the money flowing.

You know, I'm somewhat aware of the team leader's strengths and weaknesses. And thanks for double underlining the weaknesses in red pencil. And maybe she won't have my job one day, or my boss' job. Maybe I ought to find someone else to lead your team.

But you know what? I may be busy. I may have other plans for her and for you. I may have other priorities. That doesn't mean I will or won't act on your initiative. But it does mean that dropping hint after hint after hint very quickly goes from irritating to full blown obstruction to success.

Right now, I need software. Are your actions helping us ship higher quality software, with less risk, in less time? So...

Do yourself a favour. Come to see me. Talk to me. Make sure I understand by speaking plainly. And then listen to what I have to say. Be sure you understand. And then stop dropping hints. One way or the other, let's ship software.

Yours very truly,

Reginald Braithwaite

post scriptum

I've run into this several times in my career. From my experience, once it reaches the point of sabotaging the man in the middle, both parties become very tarnished, very quickly.

I'll share one story where I was the hapless man in the middle. I was managing the development activities for one company, where I had several team leaders reporting to me. The company founder also had an R&D team cooking up some revolutionary software.

This team had been whiling away the years on this project, and to all appearances they had an unlimited budget and schedule. The project required a very deep domain knowledge, and the team tended to hire people with high domain knowledge and little or even no experience writing software, much less developing products.

The founder was exceptionally interested in this project and loved to brainstorm with the team. One day I got the news: he wanted me to manage this team, to teach them how to ship software. He saw their brains and my experience as a match made in heaven. The team's leader was told to stop reporting to the founder and start reporting to me.

Well, managing software development isn't that hard, is it? I asked the team leader for a list of what he thought the team could accomplish, by when. I simultaneously asked the company's business development folks for a list of what we needed to have in order to close deals. I proposed that we put the two lists together and create a development schedule.

Apparently this was not to the R&D team leader's liking. He questioned whether someone lacking a doctoral degree in his field could understand the software, much less participate in its creation.

He flat out refused to participate in any management exercise I cared to propose, letting me know that the software would be ready when his team shipped it, and that it would contain whatever features his team deemed necessary to include, and that the team was not going to commit to those features in advance, as research was still underway.

And all the while, he continued to deal directly with the company founder, who remained involved as a 'product manager' while we pretended that I was the actual manager.

Needless to say, that didn't last very long. The company founder realized that the team leader was forcing his hand and reluctantly took action.

Labels: jobs

  ¶ 9:10 AM

  A quick word about prima donna hackers Is every prima donna really one hundred times as productive as the middle of the Gaussian distribution who have a degree? Maybe, maybe not. But this post is about those prima donnas who really are from another planet, and the people who hire and manage them.

This is not a team. It's not a boat, not a machine that has a lot of parts of it that have to work together. The metaphors are all crap. This is a business - that's all it is.

Vogler in "House," Season One Episode Fifteen, "Mob Rules"

Read the sports section of the newspaper. Or do a Google News search for Terrell Owens. He's a superstar, one of the truly gifted who can change a football team dramatically. He's also incredibly high maintenance. And he's just been fired.

The bottom line? His team is losing. Here's the way it really works. Let's make things simple and say that Terrell is worth four wins to the team. If the team can make the playoffs without him, four extra wins makes the difference between making the playoffs and making it to the Superbowl.

When a team is losing, the same four wins are only the difference between just missing the playoffs and being out of it a month before the season ends. Although the difference in number of games won might be the same, the "utility" is far lower.

Now consider the cost. When the team is doing well, most of the players, fans, and management are basically happy. The distraction of a loose cannon is just that. A distraction. But when the team is losing and everyone is unhappy, a loose cannon is more like a bouncing hand grenade. Everyone is sore.

And even if a coach or manager is detached enough not to take a difference of opinion conveyed through the media personally, it's hard to turn a team's culture around and make changes when your authority is so visibly undermined. Basically, a prima donna provides less value to a losing team and costs more.

And yes, I'm going to say that the same thing applies to software development. If you're rocking and rolling in a growth environment where you're shooting the lights out, prima donnas provide value. They can make the difference between "just shipping" and hitting a liquidity event. They provide more value and cost less.

But if things aren't going well... a prima donna is going to be a distraction at a time when others have very little tolerance for a contrarian viewpoint.

And that's why you often see prima donnas flourishing in start ups but exiting when the company goes enterprise and development is no longer the value add.

Labels: jobs, passion

  ¶ 4:26 PM

  Spot the Bug and Interviews Gone Wrong Spot the (Java) Bug:

private final static long THIRTY_DAYS_IN_MILLISECONDS = 30 * 24 * 60 * 60 * 1000;

...

final Date today = new Date();
final Date thirtyDaysHence = new Date(today.getTime() + THIRTY_DAYS_IN_MILLISECONDS);

Sheesh.

I promise that if I ever ask someone to spot this bug in an interview, they can gather their resume, code samples, and references up and walk out without another word.

More about interviews gone wrong: Nah'mean? and Other Interview Stories

Where does one begin with those stories? Obviously, interviewing and recruiting is a two-way process. If the interviewers are superficial, you can bet the company will be superficial. Is that what you want?

On the other hand, some people have an idea of propriety that does not strongly correlate with their fitness as employers. In other words, they might expect you to dress conservatively and be polite for an interview, but that doesn't mean they won't be great people to work with/for.

The whole dress code and manners thing boils down to something quite simple: when meeting new people in a business context, your dress and mannerisms should not call attention to themselves. This works both ways: I own custom tailored suits and a full set of 'tails', but few of my software development colleagues have ever seen them :-)

I'm not advocating some sort of herd mentality. I'm suggesting that you want your accomplishments and potential to stand out. I'm all for making a huge personal impression, but let it be about your talent, not your gear.

Think of your clothes and manners as a windowpane. Sure, you can present some interesting stained glass. But won't that obscure all the interesting things about you?

p.s. Reg blows an interview

Labels: jobs

  ¶ 11:40 AM

  Why You Need a Degree to Work For BigCo Hello applicant:

I’m very sorry, but I don’t have good news about the job opening here at BigCo. We really liked meeting you, but the bottom line is that you don’t have a degree from the right kind of University.

——What’s that you say? You have learned an awful lot about writing software during the four years that you weren’t carting textbooks around the campus? My dear applicant, thanks for pointing out the obvious.

I can read, you know. I was impressed by the list of projects you have completed. I even took an extra thirty seconds to Google your name and enjoyed the screen shots and links on your home page.

But nevertheless, University teaches you things above and beyond how to write code. And that’s what we need here at BigCo.

——I beg your pardon? You think that you have learned just as much about communication, teamwork, and project management from shipping software in small teams as you would have learned completing coursework?

Please don’t take this personally, but I need a moment to chuckle. Ok, I’m done. University isn’t about communication, teamwork, or project management. If you happen to learn those things, that’s a bonus. I was thinking of something else.

——Look, I admire your enthusiasm, but if you’d let me do a little of the talking I could tell you what we need. But since you bring it up, no I wasn’t thinking of any of that Computer Science stuff.

Just in case you’re thinking of referring any of your friends to BigCo, please let them know that if they learned why S, K, I, and Y are the most important letters in the alphabet, they need not apply. Ever.

To paraphrase Eric Beck, “At either end of the educational spectrum there lies a hacker class.” And we are not interested in hackers, even great hackers. We need those middle of the spectrum folks who are going to live in the suburbs, commute to our offices, and do a decent job for a fair wage week after week, year after year.



Quite honestly, the very fact that you passed on University tells us something disturbing about you. Quite obviously you aren’t stupid. And you knew that people like us would have a problem with your lack of education. But you believed in your heart of hearts that you could make up for this with excellence.

But you know what? That same attitude might have you think “It’ll look bad if I quit this job in less than five years, but I’ll make up for it.” That kind of attitude makes you a little fearless. And while we try our best to build a decent working environment, we like our people to be just a little afraid of leaving the nice security blanket we give them.

This may come as a surprise to you, but we’re looking for people who are looking for us. Of course we know that the educational component of University is a waste. We wouldn’t have it any other way.

Like hazing rituals and wearing dark suits to work in August, attending a certain kind of University is a statement that you want to belong, that you know there is no practical purpose to the exercise but that you are prepared to make the sacrifice just to fit in. And you, dear applicant, would not fit in.

Let me stress this point about what kind of University. We aren’t talking about some aerie faerie place where you build robots or spend your free time writing business plans. Those places exist to skim the cream off the top so we can hire a plain glass of 1% milk.

As a matter of fact, the kind of University we like discourages you from dreaming about the future and keeps your feet firmly planted in the ground. For example, our favourite institutes of higher learning send you to work for companies like ours on work terms. This provides us with cheap labour and has the pleasant side-effect of discouraging the more creative undergraduates from wasting everybody’s time by coming to work for us.

——Look, I really have to go, and I don’t want this call to end on a down note. There are lots of happy people in this world, and most have never even heard of BigCo, much less come to work here. So please consider this a redirection instead of a rejection. I know that’s trite, but it’s no less true just because it has a memorable rhyming form.

It’s not you, it’s us. The plain fact is, you wouldn’t be happy here. So buck up, look around, and see if you can get yourself into something a little more early stage. Consider starting your own company.

Because quite honestly? I’d read your business plan any day. Your résumé would look better on top of a funding proposal than under a cover letter.

Good luck out there.

Labels: jobs, popular

  ¶ 4:30 PM

  You and Your Research Richard Hamming on solving important problems:

In order to get at you individually, I must talk in the first person. I have to get you to drop modesty and say to yourself, ``Yes, I would like to do first-class work.'' Our society frowns on people who set out to do really good work. You're not supposed to; luck is supposed to descend on you and you do great things by chance. Well, that's a kind of dumb thing to say. I say, why shouldn't you set out to do something significant. You don't have to tell other people, but shouldn't you say to yourself, ``Yes, I would like to do something significant.''

This, in my experience, is the whole story. Everything else falls out of this personal commitment. It's a commitment to try. To strive. To sweat. To make the effort. To care.

Without this commitment, you have made a de facto decision to be on the receiving end of life. To float down the river like a leaf, now hither, now thither, carried by currents and wind.

Drop the modesty. There's nothing wrong with wanting to do something great, even insanely great.

But I'm forty-two going on forty-three...

Age is another factor which the physicists particularly worry about. They always are saying that you have got to do it when you are young or you will never do it. Einstein did things very early, and all the quantum mechanic fellows were disgustingly young when they did their best work. Most mathematicians, theoretical physicists, and astrophysicists do what we consider their best work when they are young. It is not that they don't do good work in their old age but what we value most is often what they did early. On the other hand, in music, politics and literature, often what we consider their best work was done late. I don't know how whatever field you are in fits this scale, but age has some effect.

But let me say why age seems to have the effect it does. In the first place if you do some good work you will find yourself on all kinds of committees and unable to do any more work... When you are famous it is hard to work on small problems. This is what did Shannon in. After information theory, what do you do for an encore? The great scientists often make this error. They fail to continue to plant the little acorns from which the mighty oak trees grow. They try to get the big thing right off. And that isn't the way things go. So that is another reason why you find that when you get early recognition it seems to sterilize you.

In my own experience, having some modest success early opens doors. But do they lead in the right direction? Sometimes not. I am constantly getting offers to manage teams of programmers working on uninteresting applications. I have taken such jobs, and I can say with certainty that while I have been successful most of the time and unsuccessful some of the time, uninteresting projects have never magically transformed themselves into important work.

It's hard to plant acorns when you've grown an oak. But it's necessary, very necessary. You can't get buried in management meetings and UML diagrams and presentations to resellers (you especially can't even get buried in writing about software development).

Todd Proebsting

A few years ago I went to a conference at MIT called "Lightweight Languages 2." All sorts of very bright people were there. Joe Armstrong gave a talk on Erlang. Matz gave a talk on Ruby. And a charismatic speaker from Microsoft named Todd Proebsting gave a talk about Disruptive Language Technologies.

In his talk, he gave a story about Richard Hamming. And here's the same story, in Richard's own words:

Over on the other side of the dining hall was a chemistry table. I had worked with one of the fellows, Dave McCall; furthermore he was courting our secretary at the time. I went over and said, ``Do you mind if I join you?'' They can't say no, so I started eating with them for a while. And I started asking, ``What are the important problems of your field?'' And after a week or so, ``What important problems are you working on?'' And after some more time I came in one day and said, ``If what you are doing is not important, and if you don't think it is going to lead to something important, why are you at Bell Labs working on it?'' I wasn't welcomed after that; I had to find somebody else to eat with! That was in the spring.

So...

• What is the most important problem in your area of interest?
• What are you working on?
• Why aren't they the same?
  

Labels: jobs, passion

  ¶ 12:33 PM

  Are you thinking of working for a start up? Let’s say you want to work for a start up. You aren’t one of the founders: you’re coming in after the company has raised some money: it looks like it’s serious about success.

You know that the start up route is a work hard, work harder environment. You’re going to push yourself to the end of your rope and then push yourself harder. You know the deal: work 60, 70, 80, or even 100+ hours a week in exchange for working with great people on something you believe in.

If the personal rewards matter more than any monetary consideration, you can stop reading right here. I wish you well, and nothing would please me more than to hear that the years you spent in a start up were the most thrilling years of your life to date. Go for it!

But what if you want a little more than the vibe? Everyone’s heard about the riches available to employees with stock options when their company goes public or gets bought for big money. Should you consider the working for a venture backed company to make money? Is it worth it?

I’m going to give you my perspective, based on widely disseminated anecdotes about working for start up companies in the technology sector. After you’ve read this post, you should be able to come up with a basic figure of how much money you need to make on your options to justify the long hours, hard work, and lower pay of a start up company.

Let’s say you’re a senior kind of person and you’re offered options worth 1% of the company. Not so fast! As the company grows, it takes in more investment. With every round of investment, the existing stock holders get diluted. You need to figure out how much of the company you’ll have when the company is worth M$100.

First, a disclaimer: I absolutely positively cannot value your stock options. Even if your employer is wildly successful, your ability to cash in depends entirely on the whims of your Board of Directors. If they want to screw you out of your option money, they can and will do so. If you’re an employee, the only reasons to let you cash in are to keep you from quitting and to hold you up as an example so they can motivate other people to work for them.

(Some of the time, those two reasons are good enough. This is especially true if the company has been backed by a reputable VC firm. The VC business depends on “deal flow”: a steady stream of entrepreneurs walking into the offices and offering the VCs new businesses to own. It hurts their deal flow when word gets around that they don’t share the wealth.)

So how much will you get? And is it worth the work? As I said, I don’t know how much you’ll get. I can give you a few tools for making a Wild Assed Guess.

Raganwald’s Scientific Wild-Assed Guesstimation Methodology

First, you have to convert options into your interest in the company. Don’t waste your time figuring out “if the company goes public at $100 a share, and each option has a strike price of $1, I get $99 per option, times 10,000 options is…” That doesn’t work. The thing to do is to figure out how much of the company you have a right to buy.

Let’s say you’re a senior kind of person and you’re offered options worth 1% of the company. That sounds like a lot. If your company is purchased for M$100, your options are worth a million dollars give or take. (Just so you know, lots of software companies are sold for between one and four times revenues. So unless your company is really, really hot, your company isn’t going to be worth M$100 unless you get revenues up to M$25 at the very, very least.)

Okay, 1% is worth a million dollars. Not so fast! As the company grows, it takes in more investment. With every round of investment, the existing stock holders get diluted. That means the 1% you have now (I’m being generous: you typically have the right to buy 1% provided you don’t quit or get fired over the next four years) will actually be worth less than 1% of the company when you cash in.

So you ask the President about the dilution, and she laughs and says “yes, but that means we’ll be on track and on our way to riches, so it’s worth it.” Okay, but you can’t have it both ways: you can’t say 1% of M$100 is worth a million dollars: you need to figure out how much of the company you’ll have when the company is worth M$100.

Here’s an easy way to figure out what your 1% is worth: pretend you’re a VC. They just invested in the company, right? So… what was the post-money valuation? If the company shares this with you, they’re telling you how much the VCs thought the company was worth when they made their investment.

Let’s say you get a rough estimate of the post-money valuation. I’m going to take a really early stage company, a company that just raised M$4 on a post-money valuation of M$12. In other words, the investors just paid M$4 in exchange for 33% of the company.

Guess what? Some people with a reasonable idea of what start up companies are worth just said that 100% of the company is worth exactly M$12. So what do you think 1% of the company is worth? That’s right, 1% of M$12 is worth $120,000. No more, no less.

Another SWAG

Is that worth it to you? Maybe you want a second opinion. Or maybe you aren’t told the post money valuation. Okay, here’s the other way to calculate what your options are worth. For this, you need to figure out your share after all the dilution. Basically, you need to estimate how many times the company will raise more money and how much stock they’ll give investors to do it.

You’re going to have to do some research on comparables to get a good estimate. I’ll take the example I’ve used above and hypothesize a company that’s just raised M$4 on a post money of M$12. This is their second round: the founders started with credit cards and sweat, then management and an “angel” investor put another M$1 to really get things going.

I would expect a company like this to raise at least two more rounds of capital if they’re going to do something big. They’ll probably give away another 50% of the company to do so. So the 1% you have today is going to be worth .5% when the company scores a big win. What’s that worth?

A VC is having a good year when one in five investments hits a home run. If you honestly can do a better job of picking winners, drop your day job and go into venture capital. You’ll make way more money investing in start ups than working for them!

Well, you can always say “.5% of M$100 is half a million dollars.” And that sounds great, much better than $120,000. Where did the $380,000 come from? Well, the first calculation measured what investors think of the company. That takes risk into account. The second calculation doesn’t take risk into account. What’s the chance that the company will be a big success?

Making book

I know, I know. It’s a sure thing. If you didn’t think so, you wouldn’t go to work there. And the President is awfully confident. She ought to be, she’s put her career and possibly her retirement savings on the line. But don’t forget, everyone is that confident, and most VC investments tank. By most, I don’t mean 51%. I mean 80% or more go right down the toilet.

The bottom line is, you ought to ignore your gut and the pedigree of the management team. The VCs take that into account when they invest, and the best they can do is about 20%. Yup, a VC is having a good year when one in five investments hits a home run.

If you honestly can do a better job of picking winners, drop your day job and go into venture capital. You’ll make way more money investing in start ups than working for them!

So back to 20%. That’s the number I’d pick when figuring out the odds of a spectacular success. Oh, I don’t mean that there’s an 80% chance of mass layoffs and/or bankruptcy. Many VC backed start ups eke out a living and make a little money. But the option are worthless unless the company does really, really well and can go public or get bought for major money. And that only seems to happen about 20% of the time.

So… What does that do to the $500,000 we get if the company is sold for M$100? You guessed it, that means that the value of those options is really only about $100,000. Not $120,000 by this calculation, but close enough. And it should be: the investors use pretty much the same reasoning when they decide on the post money valuation.

So is that a lot of money or not?

Okay, final calculation: what’s $120,000 worth to you? I mean, is $120,000 a good return on your investment?

To figure that out, you need to know how much you’re investing by working for this company. You need to calculate your opportunity cost, the money you could have made elsewhere. Let’s start with your salary: if you could make more money somewhere else, calculate how much salary you forgo.

For example, let’s say you can get another $5,000 a year working somewhere else with little or no risk. Over the four years your options need to vest, that’s $20,000 you’ve just invested to get $120,000 when everything works out. Okay, not bad.

But wait: how hard will you work? If the other job is only 45 hours a week and the start up is 60 hours a week, you’re investing 15 hours a week. What’s that worth? You can take the other job and work out the hourly rate, but I prefer to calculate what I could make by the hour consulting. If you can work 60 or more hours in a start up, you can work a night job programming for other people.

Let’s say it’s $30 an hour. $30 by 15 hours is obviously $450 a week. You’re probably going to work 200 weeks over four years, so you’re investing another $90,000 over four years. Add that to the $20,000 and you’ve just put $110,000 into the company to get $120,000 out.

For me, that’s breaking even. It’s not terrible, but it’s no short cut to riches. If you can get a substantially better stake in the company, you’re on track to do much better. But if you’re such a hot shot, you can probably do very well seeking out a job or contract that pays well. So you probably end up in the same place.

Coda

Of course, there are other ways to get rich in a start up. The best is to be one of the founders rather than an employee. In this capitalistic world of ours, entrepreneurs are higher on the food chain than employees. Below investors, but higher than employees.

p.s. Here's Paul Graham's take on starting a company. Jerry Colonna has some reasons why you should be self-funding. And the Anti-Venture Capital web site gives an excellent example of why you'll make less money using venture capital to grow than you would staying small and profitable.

Labels: jobs, popular

  ¶ 12:11 PM

  Are you waiting for someone else to validate your worth?

"Can't sing. Can't act. Slightly balding. Also dances."

Paramount Pictures' screen test report on Fred Astaire.

Labels: jobs, passion

  ¶ 4:36 PM

  Hiring a Senior Programmer / Software Developer in Toronto Here's my standard response to recruiters offering me senior programmers and software developers:

I'm currently looking for aggressive, smart programmers. The very first questions I always ask are, "what's the best work you've ever done? And why are you proud of it?" There's no secret to the correct answer. Candidates who love what they do are always ready to share their passion with me.

Candidates who show up for the first meeting carrying portfolios of previous work (screen shots, source code, &tc.) receive major preferential treatment. I'm amazed at the number of candidates who are carrying a résumé and expect me to conjure up in my head visions of how wonderful their work is.

Our interviewing style is thorough. Candidates will be asked to write code and solve Microsoft-style puzzles right up front. Those who show an aptitude for problem solving and excellent communication skills will be invited to meet with four to six future colleagues.

Did I mention excellent communication skills? This is a team environment where we turn ideas into software products. Being able to brainstorm with colleagues, discuss ideas, and contribute to code/design reviews is part of the job. And that means fluent use of the English language in a technical setting.

Although this can be gruelling, I can promise you that candidates who are smart and capable will get an opportunity to shine. Unlike many other firms, I'm prepared to look at candidates with a variety of backgrounds. Do you have "hacker" types that contribute to open source in your database? I'm interested! Do you have creative types who have developed software for Macintosh? I'm interested!

I know this isn't the standard "5 years of C++" type job requisition: If you absolutely must have some keywords for your database, please try:

• "Python," "Smalltalk," "Lisp," "Squeak," "Scheme," "Haskell," "J," or "Ruby;"
• "Scrum," "Extreme Programming (XP)," "Agile," "Spiral," "Continuous Integration," "Daily Build;"
• "Spring," "Hibernate," "Aspect#," "WebObjects," or "JBoss-AOP;"
• "NextStep", "AUX," "MacOS X," or "Linux."

Please call or email to discuss. I'd love to work with you on staffing my team with the best and the brightest.

Warm regards,


Reginald Braithwaite-Lee

During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavour the job descriptions had, the less dangerous the company was. —Paul Graham

p.s. For your web surfing pleasure:

http://www.paulgraham.com/gh.html
http://www.joelonsoftware.com/articles/fog0000000073.html
http://www.stickyminds.com/s.asp?F=S7875_COL_2
http://www.paulgraham.com/pypar.html

Labels: jobs

  ¶ 2:12 PM

  Taking Work Personally I take software development personally. Developing great software is part of my identity. Doing a fecal, semi-hemispherical (make that "shitty, half-assed") job is, in effect, living my life in a shitty, half-assed way.

Lots of people in our industry jump all over this and talk about how you have to compromise on principles in order to make money, or succeed in company politics. Well, no you don't. Let's get this straight:

Shipping great software is the art of making compromises, of satisfying constraints. However, what makes one project great and another mediocre is the quality of the compromises. Deciding to ship the first Macintosh with 128k of RAM is an example of a high quality compromise. Deciding that it's too time-consuming to fix regressions before the end of the project is an example of a low quality compromise.

The same idea holds for making money, being effective in a team environment, or balancing work and home life. Compromise is the art of the possible, and being passionate is about putting yourself in a position to make high quality compromises.

So when people sigh and tell you that their projects are late because of compromises, they're copping out. The truth is, the people whining about being "reasonable" and "pragmatic"* are actually trying to make themselves feel good about being unprincipled, about having no particular interest in whether their work is great, fair, or poor.

They never had the passion, or they had it but sold out, or it was beaten out of them early. So they tell you how they'd like some principles, but they can't afford any. They're lying to themselves! The worst part of these whimperers is that a few of them secretly want you to fail! It would crumple their world view if you decided to work nights and weekends on some unpaid passionate work and you ended up creating the next friendster, oddpost, or groovy.

On the other hand, I don't mind if they all make tons of money. I'd rather they be happy where they are than sit at their desk all day drinking coffee from a TGIF mug and wishing they were rocking and rolling in a start-up. I've found that the passionate people I know feel the same way: they have an abundance mentality. The only thing I resent about passion-less programmers is their desire to pull us down to their level. It's a herd mentality, and I don't feel particularly bovine.

I'm thinking about this a lot right now. My partner and I are expecting a son this October. A few people who don't know me very well have suggested that now that I'm going to be a father (going to be? as my partner points out, the baby is already here!), I'm going to have to settle down and stop all this passion stuff.

Update:

As if! My feeling is that when you're twenty-one, with no kids and no long-term relationship, you can afford to take a job for the cash. Your life is work, very little sleep, and partying**. Who cares if the nine to five gig is rewarding? But when you're a parent, you're a role model. Now is the very worst time in the world to be working a job that doesn't reflect your values in a deep and meaningful way.

Kids learn from what you are, not what you say or even what you do. No matter what you tell them, they'll grow up to be like you in a fundamental way. Do you think for one moment I plan to have my children learn that work is something you do to pay the bills, but you really don't take any pride in it?

Next I'd have to tell them that you go to school because you need a degree to get a job, instead of an incredible opportunity to learn and meet brilliant, motivated people. Bah!

Okay, time to wrap this up, I've got to get to O----, where my friend Ethan Henry starts today. We're raising the bar another notch! This week I'm interviewing more candidates for a development position, and I'm looking really, really hard for people who feel the same way.

So, thank you for 'listening'. I feel better now, and I hope you do too: I really, truly hope you're going to spend today as passionately as possible. Not throwing a temper tantrum because you have to write your app in Java instead of Lisp, but striving to make those good compromises, the ones that push you closer to shipping a great piece of software.

* I do not mean the pragmatic programmers: those guys have so much passion they practically sweat passion onto every page of their book!

** I know this is old fashioned, but you can get a lot of software written if you avoid anyone who uses the word "party" as a verb :-)

Labels: jobs, passion

  ¶ 7:28 AM

  How to get your first job developing software HumbleCoder asked:

I've seen a number of people recommend doing programming work for free in order to gain experience. This can involve either volunteer work for a local charity or school, or working as an intern for a for-profit corporation. I'm not sure if this actually works or not, so I am wondering if anyone out there can comment on this strategy for getting experience. Email me if you have used this technique to help you land a first job.

I have been hiring developers for almost a decade, and one of the things I look for is a habit of writing free or nearly free software.

In my experience, good developers love to write code. In fact, the very best developers don't know how to "not write code". When they were in high school, they wrote MUDs in Basic (well, that's what they did in the 80s). When they were in college, they developed Perl and Tcl scripts that scanned Usenet for updates to threads of interest. Even if they hold a "lowly" summer job working in a computer store, they have a Linux system at home running Apache and mod_perl or PHP.

Even after they get paying jobs working 70 hours a week, good developers can't stop coding. For example, Phil Greenspun started Ars Digita, yet he wrote lots of free tools on his home server (I use two of them on my own weblog). Paul Graham ran Franz and Viaweb (now Yahoo! Stores), yet he is busy developing a new language, Arc. In my own case, I was busy as a consultant in the early nineties but couldn't help writing a PDA application and a dynamic web service "on the side".

When I am asked how an inexperienced person can get their foot in the door, I give two pieces of advice:

First, I tell them to just start writing code. If they don't know what to write, I don't suggest anything specific, I just tell them that they should pick stuff they enjoy, using tools they like. It isn't important to use the latest "industry standard" tools or work on something "commercial".

Second, I tell them to think in terms of a "portfolio" instead of a "résumé". Even if they don't take a physical portfolio to job interviews, their résumé or cover letter should include an appendix with samples of their work. If an inexperienced person wants to stand out from the crowd, screen shots, links, and code snippets will appeal to a technical hiring manager.

Is any of this guaranteed? No. Some companies hire HR people that are not qualified to tell the difference between a talented candidate who compiles and builds their own development environment at home and a mediocre college graduate that didn't expand their own horizons.

I personally wouldn't want to work for a company that gives significant authority over its intellectual property to such an HR person, but not everyone is as picky as I am :-)

Labels: jobs, passion

  ¶ 7:57 AM

  The Interviewee's Perspective So I find myself sitting still for a technical interview with a faceless corporation that’s hiring contract programmers. Right away the answer to all my problems is “don’t do that!” But anyways, I did it, and here’s how it goes…

I meet four junior-ish programmers that pepper me with Java and SQL questions. I get it all just about right, although I was unsure about one of the SQL questions. They seemed satisfied, but maybe they don’t bother to shake their fingers at hapless interviewees when they blow a question…

When I get home I try it on my laptop and discover I’d left something out of my SQL answer. I get it right and like a good brown noser I send them an email thanking them and correcting my answer, being careful to explain that I’d tried it like a hands-on person rather than googling the answer like a student.

This wins me a second interview, and once again I get technical questions, these ones a little better. The first set were all right and wrong answers, these ones include an opportunity to share your thinking, such as:

“What’s the difference between an Abstract Class and an Interface? Explain when you would use one versus the other.”

All goes well until I’m asked to explain the difference between static and instance methods, and give examples of how to call them. I do so, and write out a series of calls including this one:

    someInstance.staticMethod();

I explain that it’s allowed by the compiler but I never do that. The lead tech guy shakes his head, saying no, it’s not allowed. Okay, I’m not perfect, I explain that I thought it was allowed but not a good idea, but I could be wrong. Either way, I’m not writing that code.

They finish by asking me to write code for permuting strings. I include command line flags, help, JUnit tests, I go all out and take thirty minutes. He seems impatient for me to finish, even though inside sources told me they’ve hired people who took forty-five minutes to complete the code.

When it’s all over, he’s escorting me to the elevator. I ask him how it went. “Some good, some not so good.” He says. You can guess where this is going… He explained that I got the method code wrong, and that really was not so good.

What can I do? Of course, when I get home, I check the answer. I’m deflated to discover that I was right. This doesn’t help, I’m not going to get a job by telling him he got it wrong. I’d rather be wrong and admit it.

Of course, some people would shrug and say it’s a minor detail, they don’t mind getting it wrong. I’m one of those people. But if I’m interviewing, I don’t hold those details against people. This guy seems to think that knowing the details of the language are important. So I’m not going to tell him he would fail his own test.

So all I can do is blow off a little steam on the web and look forward to interviewing elsewhere.

Thanks for listening, I feel better now.

(This originally appeared in the Joel on Software discussion group shortly after the interview: time has mellowed my perspective since then.)

Follow up: In hindsight, this is good for a laugh. What are your thoughts about interviews like this? Should I have respectfully disagreed with the interviewer? Should I have deliberately left any anti-patterns out of my answer? Perhaps I missed an opportunity to turn the discussion towards one of my strengths?

Labels: jobs

  ¶ 12:12 PM

  Hazards of Hiring Hazards of Hiring

An excellent article with a balanced look at the hiring process. The author runs a small ISV, so you get a highly pragmatic perspective.

Labels: agile, jobs

  ¶ 10:00 AM

  Wanted: Agile C++ Wizard O---- is looking for a self-directed C++ wizard with a strong agile mindset. O---- is a *product* company. This isn't another J2EE/WebSphere/Oracle yada yada yada project. This is hard core, shrink-wrapped software, for a company that has substantial revenues and has been in business for more than five years.

I'm going to be candid with you: this company is investing in Agile, is giving agile a try, but needs to see results. We've already hired two strong agile development leads, and we're gaining traction with the CEO and VP of Product Management.

We've got the support and we're already doing a lot of new development using agile practices. Now we need to deliver. And that means we're looking for two things: (1) people who deliver (Joel calls this skill "Gets Things Done"), and (2) people who are strongly committed to agile development.

I'm stressing this point for a reason. There are a lot of people who "like" agile, who "think its cool." We aren't looking for them. If you believe that agile's nice, but not essential, PLEASE pass this email to someone who's a little more passionate about delivering software.

We're looking for the few, the proud, the fanatics. People who know that the old ways deliver half as much software in twice the time, if they deliver at all. And specifically, people who care enough that they're uncomfortable delivering less than their best.

It's really simple. We're delivering great software, ahead of the curve, using agile practices. Our success is going to drive the company to the next level. We have an ambitious plan. And now we need to bring in the talent to deliver the products while evangelizing the entire company.

SO: if you're a "God amongst insects" when it comes to C++ development, if you have incredibly strong communication and leadership skills, if you want to be a part of the agile revolution, email your resume to me RIGHT NOW. I'm ready to arrange interviews.

Labels: jobs

  ¶ 7:38 AM