Fog Creek Software
Discussion Board




"Whack a mole" decision making

I think Joel just coined a term - I heartily encourage people use "Whack a mole" decision making to describe dealing with a large volume of input by making instant rejections based on perceived surface flaws instead of taking the time to find a quality option.

This is the root of:
-Get a degree to help get a job
-Get certified to help get a job
[in the legal field] - Print your resume on cotton bond paper, either typed or laser printed, not inkjet
- Wear a suit to the interview
- Make sure your cover page is perfect, well-researched, mentions the name of the company and addresses the job you're applying for [grin]

It also created extravagant sales pitches, the trade show boom, etc, etc...

A great, concise term that exactly describes the problem...

Philo

Philo
Wednesday, June 04, 2003

This is common in the field of publishing, too -- editors will reject a manuscript that's not in a specific format.

One important point:  This filter criteria isn't necessarily absolutely pointless.  If a person were to interview wearing a faded "F*** YOU" t-shirt and torn-up jeans, and hadn't bathed recently, that would convey a specific impression to me.

A lot of these criteria are there to filter out the people who obviously aren't putting much effort into the process.  If I'm hiring somebody, I'd expect them to know something about my company when interviewing, to dress nicely (as appropriate for the job; programmers don't dress the same as executives), to have a cover letter tailored to this particular job, etc.

Brent P. Newhall
Wednesday, June 04, 2003

I wrote a diatribe here a little over a year ago on resume selection. The question I was responding to was "how do I sort through several thousand resumes to find the best candidate."

I advocated something similar to whack-a-mole decision making. Basically semi-arbitrarily choosing resume's based on the information you have about the given job. So only resume's that have certain keywords (which is how many people do online searches anyway).

Basically, loosely defining some criteria you use to judge resume's. If you're an HR manager with a lot of time on his hands, then you can do an analysis of people you've hired and see what's common on the resume's of the highest performers, and then use that as a filter.

Of course, being out of work, this kind of advice will probably bite me in the ass when my resume reaches an HR manager who reads this thread!

www.MarkTAW.com
Wednesday, June 04, 2003

Using superficial criteria to deal with an (over?)abundance of data isn't what "whack-a-mole" means to me.  It's more evocative of an endeavor in which fixing one problem causes another to appear.  You hit one mole over the head, and another pops up.

Hardware Guy
Wednesday, June 04, 2003

But if you whack enough moles you get a ticket, and you can trade your tickets in for prizes that are worth about 2% of the money you spent getting the tickets.

See, it all works out in the end.

www.MarkTAW.com
Wednesday, June 04, 2003

Huh?

Hardware Guy
Wednesday, June 04, 2003

Obviously some people don't have young children who like going to Chuck E Cheese.

heh

Jason Watts
Wednesday, June 04, 2003

If he got the "you hit one mole over the head and another pops up" he must know what whack a mole is.

He just doesn't get the carnival part where if you win at enough games you collect tickets and get a prize.

www.MarkTAW.com
Wednesday, June 04, 2003

I'm thinking this through right now, so bear with me...

I think part of the problem is the feeling that when faced with 10,000 resumes, you *must* go through all 10,000 and dig down to the specific ten that meet your needs, then interview them - like the resumes are in an inverted pyramid and you have to remove every level completely before going to the next, to find The One True Candidate who is perfect for the job, at the very bottom (Needle in a Haystack searching)

Instead, I suggest that resumes should be approached like searching for lost coins with a metal detector - it's better to go slowly and methodically, reviewing until you find candidates. You don't need The One True Applicant - you're just looking for the right guy to do the job, of which you probably have dozens or even hundreds applying.

Some resumes you can dismiss out of hand - they're in the wrong area and unwilling to relocate; they don't have the skills you need; they don't have the experience you need; they're currently working for a competitor or a partner and you just don't want that headache right now; etc, etc, etc.

Some you can dump after a more thorough reading, realizing they're not the right person.

Then you have the resumes that are worth interviewing.

Now, instead of looking at a pile of a thousand, saying "I have to find ten people to interview in here" and dumping 990 (which is what I think creates the "whack a mole" mentality), take the attitude of "I have 1,000 resumes - I'm going to go through them until I have ten candidates I want to talk to, then shelve the rest".  (Or maybe skim the rest to look for superstars).

I'm not sure if this makes sense, but I think it might be the right direction...

Philo

Philo
Wednesday, June 04, 2003

Philo - that's exactly what I'm suggesting.

On one extreme you can approach it using bayesian networks weighing different qualifications and such and grading each resume accodingly.

On the other you can choose just one criteria that they must match (five years javascript and eight years HTML) and stopping at the first one that matches.

Somewhere in between is coming up with a matching scheme that has a few criteria, and once a large enough percentage are met - a few musts categories and a few brownie points - you select it and send it on to the next round for more detailed analysis.

The good thing about this is if your company is sizable enough to get 1,000 resumes, once you codify this process, you can give it to an internet to do.

www.MarkTAW.com
Wednesday, June 04, 2003

[On one extreme you can approach it using bayesian networks weighing different qualifications and such and grading each resume accodingly.]

Or you could do what I do: throw them all down the stairs. The ones that go the farthest get the interviews!

Bruce
Wednesday, June 04, 2003

I like Marktaw's thinking.  What about something like an "appraisal" system.  You define your important requirements VB, ASP.Net, etc.  Each applicant gets 1 point for each requirement.  Applicants without get -1 point.  Then you will have a subset of potentially qualified applicants.  From there you could wack a mole based on things like "unwilling to relocate".  If you figure wack a mole requires skimming a document looking for keywords, then it shouldn't take much long to assign points.  I think that would give you a better subset then just eliminating people for ONE reason.

You could even weight your points based on what's essential and what's nice to have.  For example, VB=2 points while ASP.Net = 1 point.  Or whatever.

shiggins
Wednesday, June 04, 2003

Replace wack a mole in the above post with whack a mole.

shiggins
Wednesday, June 04, 2003

Shiggins - that's good, and I think it directly attacks the "Whack a Mole" system. WAM stresses negative - looking for reasons *not* to interview the person. Your system stresses the positive - looking for reasons *to* interview the person, which I think is going to give a better yield of qualified candidates and is less likely to skip qualified people.

Set up your points system, then go through resumes until you have ten candidates who score higher than [x]. Adjust as necessary, but time and experience should give you a fairly good system.

I'm thinking the rebuttal to this is "you have 1000 resumes and you find ten good candidates after going through 400. You're just going to blow off 600 resumes completely?"

And I think the answer is "yes." The upside is that the 600 unreviewed resumes are "selected out" by chance, and I'm thinking that's healthier for the system than silly criteria like "they used the wrong font" or "you didn't staple in the top left corner"

Philo

Philo
Wednesday, June 04, 2003

Your ten jobs for one thousand resumes is about right.

I do personnel selection for an entirely different job but in the last three years we have had about 2,400 job applicants (I keep a reoord of every one because the refusals keep reapplying) and in total have hired about 25 people., which is the same proportion you're talking about.

Now two things to bear in mind here. Firstly recruitment is an expensive business and no agent will do it for less than 12% of annual salary before you even think of expenses, so if you want to hire ten new staff members think about having about a third of somebody's job for a year just for that. And if that sounds impossible then try and farm out the initial stuff to somebody you can trust.

Secondly you are not looking to find ten resumes but 40 or 50 resumes. To hire one person, in general you need to interview four or five, since one or two will prove unsuitable for some reason, and another couple will decide you are unsuitable.

The next thing you need to do is the three piles system. You have three piles; "straight-off refusals", "maybe look at laters", and "let's start with these".  Because of the present unemployment situation and the nil cost of firing off a resume by email, you will find that 600-700 of the resumes are clearly unsatisfactory. For the interview pile you simply choose the CV's that look outstanding. If you get to 50 before you get through them all, you can either stop there and interview those first, or keep on until you reach the end of the pile, and then go on selecting a second time from within that pile.

If you don't get the fifty you want then you go through the second pile again until you more or less have made up the numbers.

Stephen Jones
Wednesday, June 04, 2003

Shiggins - again, weighted network = too much effort. It has to be simple matching. You should be able to glance at a resume and say "yes... no... yes... no" like trading baseball cards "got it, got it, want it, need it, got it, got it..."

Otherwise you'd burn out pretty quickly.

A number of these companies that refuse any applications that aren't submitted via their website must use this methodology behind the scenes.

Stephen - 3 piles that's exactly what I'm talking about. I was even going to mention piles, but thought nobody keeps actual piles... I guess I was wrong.

www.MarkTAW.com
Thursday, June 05, 2003

I had to fill a position. I'm one person and have two hours per week to read resumes. What did I do? what COULD I do... I used the method Bruce mentioned.

You think I'm kidding. I not. I'm really not.


Thursday, June 05, 2003


Here is an opinion that programming tools are not
productive -> programming work not productive ->
outsourcing inevitable.

Maybe with better tools more emphasis would be placed on understanding processes/business requirements? These things are harder to outsource.

http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=000tec&topic_id=Ask%20Philip&topic=

......................................................................................
"Web programming has reached new heights of absurdity with Java and C#. A whole page of type declarations at the front of every file to tell their compilers that the variable "foobar", for example, is going to be a string. The variable in question is being filled with a column read from an Oracle database in which its datatype is very tightly specified and yet the compiler is too feeble to go into the Oracle data dictionary and come back to infer the proper type for a local variable that does nothing except shadow this database field.
"With programming tools being as lazy and stupid as they are, it is no wonder that employers want to find people to work for $1/day."

I guess the more polite way to say that would be "Gee it would be nice if people who built commercial tools would bring in the best features of Lisp and ML." But the reality is that it doesn't make sense to pay First World wages to code monkeys working with Stone Age tools.

Michael Moser
Thursday, June 05, 2003

I believe you.

If you have 2,000 resumes, one random selection of 50 is as likely to have one or two qualified applicants than any other random selection of 50.

If you were e-mailed these resumes, you could do a boolean search on the contents of the files (JSP and Interwoven) and randomly select one of them.

www.MarkTAW.com
Thursday, June 05, 2003

The piles are of course virtual piles - checkboxes in an Access database application I wrote for the purpose.

My boss still keeps piles however. His desk is surrounded by them. If the Yanks decide to invade Saudi instead of Iran or France they will provide excellent protection against incoming missiles.

Stephen Jones
Thursday, June 05, 2003

But how do you get the resumes into the access database? Even if it's one click, 2,000 one click operations is a lot. Do you bulk import them? Force them to fill out an application online?

www.MarkTAW.com
Thursday, June 05, 2003

Michael Moser,
this is where metadata and code generators come in. You should be able to link the DB table generation and the Java business objects together in this way.

The Pragmatic Programmer (Hunt & Thomas) has a lot of good stuff on this.

regards,

treefrog
Thursday, June 05, 2003

These 2500 + applications have come in over 3 years. All data is hand entered; if they are refusals I still open a record because I find that even though I reply to every email people will still send in the same application again when our advert goes to the top of the list every month. It's quicker to type in first name, last name email, country and tick the refused box, then it is to rescan the CV's every month.

All emails are kept in a shared mailbox on the Exchange Server and a click on contacts/activites will bring up the whole conversation, and attachments are kept in a sub-folder inside a folder on the same location as the database so I can use a relative path. An evaluation form for candidates we are interested in is kept in the database and exported to mail merge.

The things a kludge so I'm going to rewrite it in a couple of weeks but it does enable me to keep track and has worked for the last two and a half years.

A software firm will be in a very different situation, and is unlikely to be hiring regularly as we are; it's more likely to go in bursts which is more problematic, but I still thing the three piles method works best. If there is just you hiring ten people then what you do is hire one guy first to work with you, and then get the other nine while he's doing two-thirds of your job!

Stephen Jones
Thursday, June 05, 2003

Note to self: if applying for position at Bruce's company, send resume in form of paper airplane...

Chris Winters
Thursday, June 05, 2003

Marktaw-

I don't think an appraisal system would take much more effort.  Actually, it could take less considering you don't need intimate knowledge of the position to grade the resumes.  You could have a receptionist do the grading and then you only have to wade through qualified candidates.  It's not far off your system.  Instead of saying "got it", "need it", etc., you're saying "1", "2", "-1". 

In additional, this type of system could be easily automated.  For resumes emailed in, you expose the Word .olb and do a "Find" on your requirements and increment/decrement your grade.  Of course this is assuming an MS world.

Just a thought:)

shiggins
Thursday, June 05, 2003

shiggins:
I'm told that agencies routinely use matching software, some less good than others. They will do things like, e.g. scan for the number of occurrences of particular keywords.

Some matching s/w will have synonyms, so someone with e.g. "5 years VB6" will not get passed over in a search of "Visual Basic".

Remember, the aim is to reduce the numbers; they don't care *who* is selected.

[this is hearsay - recruiters, please correct me if I'm wrong]

Stephen, I did something similar a few years ago, although my system was completely paper based. I printed and filed each CV (resume). This had 3 added advantages:
1) I could scrawl notes onto the paper
2) I often forgot the names, but I would remember layouts. In any event, they were filed in name order.
3) At the time, paper was not subject to UK data protection requirements

Justin
Thursday, June 05, 2003

Shiggins - perhaps, but if I'm sitting at a desk staring at 2,000 resume's, even simple math seems too much to repeat over and over again.

+1 +2 -1 -1 +2 +1 -1 = ?

www.MarkTAW.com
Thursday, June 05, 2003

We've got enough problems in Saudi without adding data protection requirements.

I aactually print out each CV before I do an assessment for the candidates I want to follow up on. I then pass it on to the boss who likes keeping paper. But if I didn't have to do that I would throw it away. There was a great article somebody linked to here aobut the uses of paper.

Basically paper is great for working with, and the fact that air traffiic controllers still  work with 3 x 5 cards shows this. However for storage and retrievaly the computer is King, so I often will print out something on paper and then junk it, even though I may decide to print it out again the next day.

Stephen Jones
Thursday, June 05, 2003

Mark, buy an abacus!

You are unlikely to find anything as efficient for the purpose.

Stephen Jones
Thursday, June 05, 2003

*  Recent Topics

*  Fog Creek Home