Lazy Evaluation in Java

Thanks for your call. I can pull your interview evaluation right up on my screen. Let me see now, home…, candidates…, search candidates…, click the last name field…, clickity clickety…, search. Sorry, wrong, I put your full name in the last name field, let me try again…, search candidates…, click the last name field…, clickity clickety…, search. Sorry about the wait, it’s too bad finding someone in our application is so clunky. Ok, here’s your evaluation, I’m looking at it right now.

I’m sorry, I don’t have good news abut the job opening here at BigCo. We have elected to pass on bringing you in for another interview.

Yes, I can appreciate that you are disappointed. You’re right, you have the right kind of degree from the right kind of University, and you have excellent grades. But still, we are going to bring some of the other candidates in for another round of talks.

We know that you will never need to understand recursion to do things here. In fact, we will probably fire anyone who writes higher-order functional code in our Java applications.

Why? Well, you seem like a nice person, so I will break our policy and tell you the actual reason. It was because you blew the recursion and data structures code tests. That’s it, really. You passed the database stuff and the loop stuff and the web architecture stuff just fine. As well as anybody might. But the recursion and data structures tests are kind of important. If we didn’t think so, we wouldn’t ask those questions.

Yes, we know that recursion doesn’t come up often in business applications. It’s been a while since I needed it for anything, these days we use XPath and SQL and let libraries do all of the dirty work for us. That’s true. And you’re right, we always use libraries and never write our own data structures. This is BigCo, not some sushi-gobbling start up. But we still ask you these questions, and we still expect you to get them right if you want to work here.

Are you asking why again? I feel like I’m talking to my three year-old here. But you obviously put a lot of work into researching our company before coming in for the interviews, you really stood out from the crowd of new graduates, and nobody else had the gumption to follow up with a phone call, I feel I owe you one.

The reason we expect you to know these things is that they were subjects you claim to have studied when you got your Computer Science degree. Don’t argue with me, I know that Universities are getting a lot more “practical” these days, we like that. I know that you learned your stuff in Java instead of in Scheme or—and this would make you instantly unemployable here at BigCo—in Haskell. But they still teach you about recursion. They still teach you about data structures. You are supposed to graduate knowing how to reverse a linked list, how to find the shortest distance between two nodes in a graph, how to search a tree, and what’s involved in finding cycles in a graph.

I know, if it were up to us they wouldn’t waste time teaching you stuff we don’t want you to use every day. But until we finish making programming a level playing field with the Third World, they are going to keep teaching some of that stuff and you are supposed to learn it. We didn’t ask you anything really tricky, we just asked you to regurgitate stuff you ought to have learned.

Laziness

Harumph. really? You really knew it but forgot it because you didn’t think you’d need it here? Well, let me be blunt: you were lazy. You tried to optimize your time to spend as little as possible on the things that you thought we wouldn’t ask you to know. You tried to maximize your grades by taking the easiest courses possible, so you didn’t get much of that stuff.

You were lazy. Now, laziness is said to be a virtue in a programmer. And if you want to be one of those super-smart programmers who can tell me why the only birds you need are Starlings and Kestrels, you might start a company that we buy for big bucks. But quite honestly, we don’t appreciate laziness in someone we are hiring to toil away in the bowels of our enterprise application code.

Quite honestly, we don’t appreciate laziness in someone we are hiring to toil away in the bowels of our enterprise application code.

Ok, stop, stop, I am not finished. Of course we know that you will almost never need to deeply understand recursion to do things here. And if you need it, you can Google around for some code to cut and paste. In fact, we will probably fire anyone who writes a lot of that higher-order functional code in our Java applications. We know that. But you know what else we know? We know you took shortcuts in school, you did just enough to get through without actually learning anything about the stuff you figured you didn’t need to get a job here.

Which makes us worried about what else you skipped to get here. We can’t test everything, we have to assume that if you skipped that stuff, you might have skipped something else. We have to assume that if you took short cuts to get here, you’ll take short cuts after we hire you. Maybe you’ll decide to push code into production without testing it thoroughly. Maybe you’ll decide to pretend to review someone else’s code but you won’t find an obvious error because you were too lazy to read it carefully.

There you go interrupting me again.

Yes of course we sometimes push code into production without as much testing as we like. But you know what? We want to make those decisions. We don’t want our newly hired, wet-behind-the-ears juniors being lazy and making those decisions for us. We want to hire people that are thorough and meticulous and always do everything they are told by us, and by their professors in University.

The bottom line is this: we appreciate your interest, but there is no room for laziness in our evaluation. We’re looking for people who put their heads down and do what they’re told without trying to game the system. We play the game. You are supposed to be the pawn, and if we let you survive to reach the eighth rank, you might get a chance to play along. But nobody needs a lazy pawn, sorry.

Best of luck with your job search, better luck next time.

---

Update: Finally, someone sided with the hapless and much-maligned candidate

To expect someone to know a skill which is not going to be needed on the job is unfair.

First, remember that an employer is talking to dozens or even hundreds of candidates. This one knows everything they anticipate is needed for the job, that one knows all of those things and more: which one should the employer hire?

Second, forget a Computer Science degree for a moment. You are interviewing a programmer who has just graduated with a degree in something unrelated, say English. You ask him whether he studied Shakespeare. He did. Does he remember any of it? Why no, he was just taking the course to get a degree, he didn’t pay attention beyond passing his examination. Is it unfair to pass over this person because they didn’t actually do any learning in College, just doing whatever they needed to do to pass courses and accumulate credits? I think this is a behaviour that—if repeated on the job— is deleterious.

As an employer, I do not select a candidate’s University. I do not select their courses. I do not choose the coursework and study material. The candidate does all of that. Am I unfair to say to the candidate that whatever they choose to study, they ought to actually learn it?

Putting it in harsher terms, when a candidate puts a degree on their résumé, they are making a claim. Are they claiming that they did just enough to obtain the required marks and no more, or are they claiming to know the material that was taught to them? If it is the latter, then as an employer I am being perfectly fair in testing their claims, whether or not the material has direct relevance to their initial job assignment.  ¶ 6:52 PM