When the interview ends the candidates are given a simple assignment: the business needs to convert a csv file from one format to another. The candidates are given 24 hours to complete the task.
The first developer goes home and designs an amazing yet simple site where multiple files can be uploaded simultaneously and users can choose to be notified via SMS or email when the task is completed. It's great software.
The second developer receives the assignment and spends the next 30 minutes talking to the business to see how the software will be used and what value it provides. After he's gotten the information he needs he says thanks, but instead of letting him leave, the CTO offers him the job on the spot.
The first developer gets the "thanks, but no thanks" call the following day.
What the first developer didn't understand was that the assignment was designed to evaluate collaboration, not coding ability. Both candidates had previously submitted code samples and discussed their samples as part of the interview. Both developers could code equally well, but only candidate 2 had collaboration skills. Candidate 2 was clearly a better hire.
Developers love to talk about how software is about people. I know it's about people, you know it's about people, yet when I look around I rarely see developers interacting with people. It doesn't seem to make sense, and yet it happens the majority of the time. We're stuck in the ways of software development past.
Hackers put out code, often good code. That's great. Without hackers I wouldn't have messaging systems, proxies, web servers, etc. At least I wouldn't have such a good selection. But, being a good hacker doesn't make you valuable to a business.
Time after time I see requirements gathered and presented in a way that is totally disconnected from the business problem that's being addressed. There are two ways to handle the situation.
- Write the best code you can.
- Talk to the business.
But, a developer can deliver what the business is looking for the first time. A(n often) quick conversation with the business ensures that the developer knows what to work on and how it will benefit the business. This dialog often leads to a superior solution implementation where the business gets what it wants and the developer is able to do it in the most efficient way (e.g. I don't need a beautiful website, I need a command line application).
A hacker can deliver the same value to the business (on the 2nd or 3rd try), but the time difference between when the developer delivers and when the hacker delivers is the cost of employing hackers. Hackers create waste (lost time), which the business must pay for. Good developers avoid waste by ensuring that the business gets what they are looking for as quickly as possible.
This idea isn't mine, I just see the application of the idea constantly so I felt the need to write about it. Kent Beck has been talking about it for years, most recently at QCon in London earlier this year. Look for the video when it becomes available at InfoQ -- it's relevant for anyone developing software for a business, and Kent puts it much better than I do. When Kent talks about it you think "well, yes, obviously", but look around work and see if Kent's ideas are being applied. If they are, consider yourself lucky to be working with good colleagues.
I think this is a weakness of the open source culture. So often when people want to contribute suggestions, they are met with "It's open source, so change it yourself". If you can't contribute code, the experience or expertise you do have is of "no value". At the same time, we know programmers don't like maintaining code. But they expect newcomers to work on someone else's code to get their change in. That's maintenance programming. I know why this happens, I know "barking mad" suggestions are 5 a penny, I know it's all voluntary work, but it still seems a bit pathological. I don't have a good solution to it, but I think it is time the matter was given serious thought. [Unless we don't want free software to progress further... One Laptop Per Child to get Windows XP now, apparently, etc]
ReplyDeleteI disagree w/ this, but perhaps it was the way the example was worded. the requirement seems pretty straight forward to me; there is no reason why a good developer couldn't churn it out. the key would be whether enough things were missing(or added, like there are a lot of legacy systems that will need integration / EAI / SOA) in the future etc.
ReplyDeleteIf you hire the 2nd guy on the spot, how do you know they are a good developer? b/c if they are a bad one, then you just bought yourself a business analyst....
If it were that simple...
ReplyDeleteIf you hire the 2nd candidate they may or may not be a good developer, but the first one has already proven he isn't.
But it wasn't that simple...
You (just like the hacker) missed the point. The assignment wasn't designed to assess programming skills. It was designed to assess communication and collaboration.
There would presumably be other tests that would ensure the candidate could code. In fact, I'd have to wonder about a company that completed the interviews before getting a code assessment.
Actually though, I'll give you that I might not have been detailed enough with the example. Though, if I had, it kind of gives away the point. =)
Cheers, Jay
In most of the service companies developers will not get a chance to talk to the business. Its not because developers don't want to talk, but they don't get a chance to talk. To talk to the business they have some business analysts who creates some documents and pass it to the developers.
ReplyDelete@albin - This is dramatically changing in web application development. Frameworks and scripting langauges are driving down the barrier to development, the development:analysis ratio is much lower than say 5 years, so developers need to be much more in tune with the business, as they are likely to be closer to clients. Agile development has changed up the field.
ReplyDeleteAlbin,
ReplyDeleteThat might be true on occasion, but I've found it to be an excuse far more often.
In the past 4 years I've worked for 8 different companies (mostly as a consultant) and it was much more often the case that the developers didn't want to talk to the business and the analysts didn't want the developers talking to the business (for fear of their job).
Regardless of the company, I found the business to always be happy when a developer showed interest in the domain.
Of course, my experience is anecdotal. If your business truly doesn't want to talk to you, so be it. But, don't use it as an excuse to lessen collaboration.
Cheers, Jay
A good Developer needs to possess very good coding capability and JUST the right amount of business querying skills... not too much, not too little.
ReplyDeleteJay, you're spot on.
ReplyDelete"A hacker can deliver the same value to the business (on the 2nd or 3rd try)..."
Witnessing even the big guys like Microsoft stumble a few times before getting a product right shows the hacker mentality.
When I'm doing business analysis, one of the first things I ask is "why?" Why have the feature in the first place? What is the business trying to achieve?
We hear stories all the time in this industry that users don't tell you what they really need. That's true to an extent, but instead of putting the blame entirely on someone who has maybe never developed software before, why not look at ourselves and make the choice to ask the right questions.
Keep asking Jay. Asking the right questions in the right way is often more important than the answers you'll get. I miss having you on my team.
Programming and analysis are very different skills. I think many people who have one, miss the fact that they don't actually have the other. Given a problem, most people will turn towards the tools that they know best.
ReplyDeleteA bit more on analysis (too big for a comment box): The Essence of Analysis
Paul.
The interview is flawed. I can't believe this is how you hire SOFTWARE DEVELOPERS. The second guy would have been great if he came back with a working program also.
ReplyDeleteYou guys just hired a business analyst for now. If he knows to code, you're lucky.
I'm just guessing there were more rounds to this. And letting go of the "hacker" was a bad choice too. Good companies have training on soft skills and all. You could have invested in him if possible.
Anyway, lots to comment. But this interview is flawed. That's for sure.
George, Like I said in a previous comment (and as you guessed) there would be other tests for coding. This was just a test for collaboration.
ReplyDeleteThe hacker might have done better with some training, but we can assume this was a 0 sum interview and only one person could be hired.
I think getting to the level of detail we're at completely takes away from the fact that finding a good coder isn't the hard part, it's finding one that talks to the business that's almost impossible.
Cheers, Jay
Hi, Jay. What you say put in one sentence is: "Developers should be evaluated according to their communication skills only." I think your evaluation idea is too scanty. You cannot evaluate two developers just for their communication skills. Not considering the difference between their coding skills is deficient and in my opinion an insult to hacker society.
ReplyDeleteHowever, what you wanted to say is maybe: "Communication skills of a developer are more important than her coding skills." Which is an interesting idea, in my opinion wrong - but I admit I have no data to prove it :)
I think the whole thing is that people pretend software is hard. Software isn't hard, requirements are. It's the scourge of software.
ReplyDeletePeople like to say they are hackers but in reality, most people can do hacking. Implementing clustering algorithms, p2p, search, custom databases, file based data structures, indexing etc, its just not that hard.
You are so correct when you talk about this, and some of the comments show why. Hackers are much more likely to go and make something that isn't the solution simply because they think the real world is easy and hacking is hard.
Sorry pal, its the other way around, and is the reason there are a handful of applications in this world people like to use. Software is easy, people are hard.
Oh, and if you think software is hard, you definitely AREN'T a hacker :)
Holy shit, it takes 30 minutes to figure out what converting a CSV file is for? 30 minutes for what could be a one-liner in Perl?
ReplyDeleteHow do you ever get any work done?
Do you interview entirely in trick questions that ask for something completely different than what they appear to ask for, Jay?
This is fine for hiring one person. The hiring process might have been zero sum but often so is the skills that someone brings to the job.
ReplyDeleteFor example, you can hire a jack of all trades to build a website but you still might need to bring in coders and designers for something more complex because the general developer cannot develop these specific skills to a high degree.
You have to figure out what is most important for your needs and go with someone who leans more heavily in that direction (but lacks strength in other areas.) For example, the more time I spend working on my design skills is less time I spend on my programming skills.
Perhaps a good way around this problem is to allow the hire to contract out certain parts of the development or design.
@maros: I'm not saying that collaboration is more important than coding skills. In the post I say that the interview is over. Responding to other comments I say that I expect coding to be judged at another point in the interview.
ReplyDeleteThe specific test was for collaboration, and the hacker failed, as most programmers do.
Being a hacker isn't good if you're delivering software for a business. That's the point, not how you should interview or anything else.
@anonymous who asks about trick questions.
Not all questions are tricky, some are what they are. And, some questions are tricks. Do you really think that none of the questions asked in interviews are trick questions?
@glexa - I love the pragmatic approach. I agree that different people have different skills. But, communication isn't really one I think you can skip. Some of the best programmers I know are also very social.
Honestly, guys - this is the most "tongue-in-the-cheek" approach I've ever seen.
ReplyDeleteIf I'd be in the first guy shoes - I'd be happy that I am not working for this company. And it's not about whatever business which you serve - it's about employer-employee relationship we are bout to be engaged in. How could I know that you honest and this "selection" is just an interview trick? Why wouldn't I perceive it as there is nothing as it seems in the company and I have to solve little puzzles every day just in order to survive?
And you can't say that I am missing the point - you are obviously do not care what impression you making on me.
"The first developer ... designs ... great software". In 24 hours. Another messages here - company doesn't care if developer would die over-timing and it's either requirements were slightly exaggerated or ... something else.
It's all from the tone of the article, nothing more. I know that ThoughtWorks is not that kind of company. Or do I?...
"Witnessing even the big guys like Microsoft stumble a few times before getting a product right shows the hacker mentality."
ReplyDeleteTrue in her earlier days
but now, she's getting the product 'beyond right' ... showing the developers mentality ... along with increasing opportunity of conversation with business people (especially since Ballmer's leadership)
the result? look at MSFT stock and Vista rejections
that's the fate for the company who chooses second developer
Like said above, you just hired yourself a business analyst. That's what you needed long term. You had this short little project that no one else could do, so you assigned it as an interview project -- and that got work done for free for you.
ReplyDeleteGood job... Exploitation at its finest.
I liked this parable. I liked the assignment of meaning to each label "hacker" vs "developer", though different ppl might use different words for the two people in the story.
ReplyDeleteYes, us programmers have issues talking with people. I find computers an awful lot easier to understand. Computers don't lie to others, or even to themselves.
ReplyDeleteYes, I can see that hiring a developer who is willing to talk with people would be a good thing in the first instance. The business gets warm fuzzies from being listened to. And if the problem they are seeking to solve is reasonably within the capabilities of current tech, they'll even get the right result first time.
If however you actually need something that requires some serious r&d chops, then I'm reasonably willing to bet that the people focused developer isn't going to have the skills to deliver.
It's a bit of a case of hiring for the job. And yes, web sites for an advertising agency isn't exactly rocket science - the business made the right choice in this instance. Maybe.
If they need a lot of similar sites with minor variations on a theme, then a hacker with the ability to visualise and implement a domain specific language capable of describing all the sites will actually deliver greater value over the longer term, if the business is willing to learn how to communicate with said hacker.
Short term thinking leads to short term results.
i agree with this article. it is all about communication. the guy that was hired showed good signs - requirements gathering...
ReplyDeleteIsn't it hilarious how all the 'hackers' are saying that it's a bad thing?
ReplyDeleteHonestly, listen to yourselves. If you think you can ever truly understand what the client needs without communication, (even direct-to-consumer communication) you are delusional. Software is easy. People are hard.
This is why processes like XP implemented well are performed: your developers talk to a representative user as part of the team. But that's lost on most people.
The reason he hired the right person is because one person understands that requirements given by the user are usually wrong, and wanted to be sure he wasn't WASTING HIS TIME, and the other just went away and coded something up. Thats typical of an average developer, the type that thinks they know more than even the people who they develop for.
Enough already, let's say it again: software is easy, people are hard.
Kent Beck does a great job explaining his point of view in his books. What is the additional "value" added to Kent's thoughts in this post?
ReplyDeleteIt reminds me of some Eric Evans' talk, and his notion of 'core business value'. If I remember correctly, he was saying that you should take the time to investigate on what has value for the business in all the codebase/system (i.e. what parts of the code really is specific to your business and is necessary for making profits), and then put the effort on it.
ReplyDeleteAnd this is harder than it looks like.
sure, software is easy. except when the entire industry treats it as an engineering discipline rather than a craft and stumbles over its incompetent need of closure (actually, most technical subjects are crafts, but that's something that non-technical people will never see)
ReplyDeletemaybe someday, for some reason a Great Hacker will apply to your company and be hired, and you will see that they treat programming as a craft
you will see that to them, the final product is the program. and all the code is just what has to be done to make the program
you will see that they are a deeply empathic person, who can predict that a user will have trouble with feature X, and that feature Y has to be one click away because it will combine with feature Z in a certain form, and that the mockups they were given would lead to a program that looks and behaves like shit and need to be ignored, instead replaced by actually crafting the UI as the program is being created
and you will see that it is because of this focus on the final product that their code is inimitable
in other words, Great Hackers are both of those people, on crack. you probably haven't met any Great Hackers. and unfortunately you're fairly right about hackers in general, but probably not to the degree that you think you are
World of warcraft: A great hacker can spend months working on their version of an ultimate system that ends up pleasing no one, simply because the hacker really didn't understand the problem in the first place?
ReplyDeleteYour legendary great hacker has an amazing ability to jump in and program before requirements are spelt out, purely because they think they are so great!
Regardless, yes I do know great hackers. They rarely work on mundane, public facing applications. In fact, I do not know any who enjoy this. They enjoy working on problems that enhance the world, rather than their pocket.
When faced with writing facebook or working in a research lab on the latest artificial intelligence, I know what ALL great hackers would choose. And its not option a. In reality, the "hacker" mentality promoted by an organisation that will remain nameless is hilarious: these people aren't hackers, and probably never will be.
If you are programming websites you aren't a hacker. You are a "business apps developer". Real hackers pwn you.
Real hackers produce papers in many fields. Simply because their interest is not in how to structure a login screen or make a table more usable. Sorry to disappoint!
> "World of warcraft: A great hacker can spend months working on their version of an ultimate system that ends up pleasing no one, simply because the hacker really didn't understand the problem in the first place?"
ReplyDelete> "Your legendary great hacker has an amazing ability to jump in and program before requirements are spelt out, purely because they think they are so great!"
no... because they are deeply empathic. these aren't socially inept people. in fact their problem is they are both too aware of social aspects, and are oversensitive in general. again, the strong empathy
it can be confusing because hackers come in two distinct flavors, and one of those flavors is socially inept
the Great Hackers of the empathic flavor are very unlikely to deliver something useless, because, again, they design completely towards the end program
and let me make it clear what i mean by the end program. i don't mean the source code that you get at the end. i don't mean the abstract architecture that the source code represents. i mean the actual interface that end users will experience. that is what they craft
all the abstraction, while entertaining and nerdgasmic, is only a means to an end for them. if they had to stack earthworms in forms of 3D pyramids to make that vision they have of the software into a reality, that's what they'd do
in other words, it's much more likely they'll realize that what the company wants to do is retarded, rather than the other way around ;)
let me give you an example of a famous Great Hacker -- Shigeru Miyamoto
this is someone that, while programming Super Mario Bros in assembly or C, always kept their sight toward the end interactive experience
funnily, i don't know of any other Great Hackers that are developing games... maybe because the managers don't expect soft-spoken, seemingly anti-social people to have such intense creativity and design sense. and that's too bad, because we could use a lot less noobs "designing" things
> "Regardless, yes I do know great hackers. They rarely work on mundane, public facing applications. In fact, I do not know any who enjoy this. They enjoy working on problems that enhance the world, rather than their pocket."
indeed:
"maybe someday, for some reason a Great Hacker will apply to your company..."
note the bolded part. i was trying to imply that it's unlikely
actually, i retract my statements somewhat. i don't know if i'm describing Great Hackers. maybe i'm describing an entirely different and much rarer beast
ReplyDeleteWorld of Warcraft: You aren't describing a hacker here. Have you read his bio, I am not sure he even programs at all. He is what I would call an interaction designer of johnathon ives ilk.
ReplyDelete"Hackers" spend more time thinking about how to implement a better algorithm than it takes a monkey to build a website in rails. Choose wisely.
Disclaimer: I haven't read all the comments above, so I may be repeating.
ReplyDeleteI thought we agreed that there are two kinds of customers, liars and damned liars. From personal experience, I don't think a great BA (let alone a good Developer) could get the right requirements from one round of conversations with the client. I figured the whole point of iterative development was so that developers/hackers didn't have to go to the users and say, "Here's what you asked for... right?" But instead say, "Here's what I think you asked for, am I right?"
Like the poster above me, I felt that this article seems to be opposite of the entire agile development approach. I was pretty sure we all agreed that no matter how much conversing or designing based on said conversations we do up front, we simply aren't going to get it right the first time.
ReplyDelete@Saager & @Justin,
ReplyDeleteAgile is a fantastic way to deliver software, but relying on it to make up for a lack of collaboration is inexcusable.
Agile encourages early delivery and iterations, which is great. But, remember, story cards are nothing more than placeholders for conversations. In fact, Agile is almost totally about collaboration, so it's interesting to me that you would see it as a replacement for a discussion. Perhaps we have vastly different definitions of Agile.
You probably won't get it correct the first time, but you doing your best to ensure that happens if you aren't collaborating.
Go talk to the business. You work for them. Don't take their requirements blindly because you know you can fix it next iteration, discuss their needs and deliver value as soon as possible.
If you're not collaborating, you're not doing your job.
"In fact, Agile is almost totally about collaboration, so it's interesting to me that you would see it as a replacement for a discussion."
ReplyDeleteI think you have twisted what both the poster above me and myself have said. Neither of us said, or implied, that the KEY aspect of agile development, collaboration, can be removed from the process. What we both did say, explicitly, was that trying to get ALL the requirements up front and then going off and coding the ENTIRE project is futile and NOT agile. Collaboration over nothing (as opposed to something as simple a paper napkin) is generally ineffective which is why its important to iterate in small steps and THEN collaborate (test-first for the business?). This is why we have things like prototypes and wireframes.
I meant exactly what I said, nothing more nothing less. I think your misunderstanding might stem from the fact that this example seems incredibly contrived and leaves lots of room for interpretation.
@Justin,
ReplyDeleteMy response is based on the fact that the entire blog entry is about collaboration, so if you are disagreeing with the post, I'm left to assume that you don't value collaboration.
I agree that this example, and most others don't give enough context. Such is life. If I wrote full context blog entries no one would ever read them due to their length.
It sounds like from your follow up that you do value collaboration, but don't believe that all requirements can be gathered up front.
I also believe that all requirements cannot be gathered up front. The entry wasn't designed to describe gathering requirements up front, it was designed to show that coding skills aren't enough, developers also need collaboration skills.
I don't agree with anyone that feels that they don't need to have a conversation with the business because iterative development will catch the issue quickly. I'm not saying that you (Justin) believe that, but I know other commenters do, and they're wrong.
Cheers, Jay
I've got mixed feelings about this, overall :(
ReplyDeleteOn the plus side:
- Yay ! A great idea that one could borrow on to separate the "code-only" people from the "what does the customer need all said and done" people.
On the minus side:
- With experience, such requirements would indeed seem straightforward and if a customer
- The dev who asks all those nice questions has not yet been evaluated on his tech approach. Will he actually be able to translate the answers from the customers into something architecturally useful, or will he just "do the simplest thing possible" that his capabilities limit him to (and thereby actually put the project at risk!?)
This article forgets that people can actually change and learn.
ReplyDeleteUnless the hacker has some kind of autism or something, (s)he can adapt and quickly learn how to ask the right questions.
What's better? To have a great hacker learn how to ask for requirements, or to have a good communicator learn how to implement things?