Selecting Against Experience - Do Employers Know?

IBitOBear asks: "A couple days ago I did 'the interview loop' at that leading online retailer. Over the course of six hours I was repeatedly introduced to a guy in his early twenties, who would then ask me to write out code on a white-board for a problem that you might find in the study guide for a 200-level computer science class. I have 20 years of experience in programming and systems design. And in several cases the interviewers were vague, semantically incorrect, or self-contradictory. Interviewer blunders included not understanding that non-normal forms in databases -can be- more correct or efficient when the domain of a data is extremely limited; or choosing a leader among N candidates -is- a byzantine agreement problem. In short, the loop would have been perfect to weed out some guy getting his first job fresh out of school, but it definitely exerted selection pressure towards excluding experienced candidates. So employers, what are you doing to make sure that you are not culling out candidates with the low-ball? Job seekers, what do you do when you find yourself trapped in a sophomore study group?"

Comments

Walk away.

[Spazmania]

Job seekers, what do you do when you find yourself trapped in a sophomore study group?

Walk away. An interview is a two-way street: they're evaluating your ability to do the job but you're also evaluating their ability to provide a worthwhile work environment. If they fail your test, walk away.

20 years? So what?

[zer0man]

20 years experience doesn't mean much. I have heard/seen candidates bullying interviewers with their credintials (I've got a PhD in Computer Science) or experience (I've been coding since you were in diapers) and yet still fail to reverse a linked list in-place, or fail to explain the basic idea of hashing.

It bothers me, as an engineer with some experience, to be subjected to the humiliation of 'the interview loop', yet having been involved in hiring I absoluately see why it is needed -- people, well, inflate their credentials when it comes to looking for work. So companies essentially ignore past work experience and ask questions relating to specific engineering problems to try to see what kind of developer you are. Sometimes the interviewer is bad, but that's why it's a "loop" there are at least 4 of them, and one of them should be a more 'senior' interviewer who holds more sway (that is if i'm guessing correctly at your 'leading online retailer').

True, the system isn't perfect. You could be a brilliant engineer, but can't reverse a string. But with the amount of money that is invested into an engineer by the company as high as it is, they company doesn't want to be wrong.

Re:20 years? So what?

[tgd]

The problem with the position you described in your reply is that its not really applicable to software development.

An engineer with 20 years experience knows a few things:

1) He hasn't had to reverse a linked list in 23 years.
2) There are framework functions to reverse a linked list. Who cares how they work.

Questions like that are VERY age-biased. Because only someone right out of school, or someone with their head so buried in the code would remember that on the spot. Experienced engineers will tell you how to manage the development process, how to write code that is engineered to be testable, can actually explain software architecture and will do a FAR better job solving real world problems.

Why? Even if you DO need to reverse a linked list in a situation where you can't use framework functions to do it, an experienced engineer can pretty easily punch in a few google keywords.

No amount of googling will give a kid out of school an understanding of how you really engineer software in the real world.

The only time I would consider asking questions like that to an experienced engineer (and I ripped off a similar one I got asked at Microsoft way back when during an interview today) is if I've already decided someone isn't a fit for some totally unrelated reason and I need a quick way to quantify that.

Re:20 years? So what?

[AuMatar]

1) He hasn't had to reverse a linked list in 23 years.

He doesn't need to know it immediately, but he damn sure ought to be able to figure it out quickly.

2) There are framework functions to reverse a linked list. Who cares how they work.

If you don't know how it works, you don't know how a list is used. You don't know when its appropriate to use it versus other data structures. If needed, you wouldn't be able to create a hybrid data structure. So yes, it matters if you can't figure it out with a minute or 2 of thought.

If you can't get simple problems like that, its not worth my time to do the rest of the evaluation.

Re:20 years? So what?

[Aceticon]

I suspect it all depends on what kind of position is someone being interviewed for:

- A programmer should remain familiar with the basic principles of creating code that runs efficiently. A more senior programmer is expected to be efficient at creating such code and to make easier to maintain code.

- A software designer is expected to be aware of the importance of compartimentalization of information and division of responsabilities across the design, and of the tradeoffs between flexibility, maintenability and performance when making a design. A more senior designer should be well versed in communicating the design and the rationale behind it to the developers, and of keeping a record of the accepted and rejected designed decisions and the reasons behind it (such a record can be used latter when changes in requirements might mean that the rationale for choosing a certain design feature instead of another one is now not valid anymore).

- A technical architect is expected to understand the issues of scalability, inter-application connectivity, fallback solutions. He should be capable of defining standards which promote efficiente development, maintenability, robustness and/or lower number of errors, all supported by a well document, internaly consistent rationale. He should be an expert at communicating these solutions to the developers and designers. He should be aware of the development process and ensure that the right tools are chosen/provided for the right job.

[Note: there's a lot more than just this]

Now, if you're interviewing for a technical architect position, which is more important:

• Somebody that knows how to reverse a circular linked list out of the top of their heads and can do it in 5 minutes on a whiteboard
• Somebody that can hammer down an Interface Requirements Specification for connecting two sub-systems being developed by different contractors

In my experience there's a limited amount of seniority (in knowledge and wisdom) that you can achieve as a programmer before you find out you've turned into a software designer (in all but name) - if you're still selling yourself as a programmer by then (say, because you like programming and can't stand the boring parts of software design like making long documents and doing presentations), expect to have to go through "just out of school" questions in an interview when applying for a programmer position, even if you're insanelly experienced for a programmer.

Re:As an employer ...

[IBitOBear]

Actually, I showed no disdain at all. I carefully and cheerfully complied. I even kept the mood up and remained positive through the entire process. It was the odd post-interview feedback that got my goat a little bit. 8-)

I actually like working with younger people as a general rule as it keeps the mind sharp and provides a continuous influx of fresh eyes to stave off the dogmatic ossification I often encounter in my peers.

There is nothing wrong with going back to first principles. I just found the failure to transcend first principles (and the fact that a couple of the guys got all grumpy when they didn't understand my solutions to their problems as stated and as revised) to be something of a warning flag.

The "ask a question of sublime simplicity" approach can only prove effective if the questioner can understand an answer of sublime subtlety.

Your expierience didn't pay off

[clambake]

Part of having 20 years experience is being able to control more than just code... It means you should have learned how to wrangle people as well!

I went to those exact same interviews that you did, the same kinds of introductory questions, the ones looking to weed out the html "programmers" who suddenly decide they can do real programming since it looks so easy.

So, what happened to me? Basically, I was able to turn the interview on it's head, and before too long *I* was the one having /them/ draw the witeboard diagrams. It wasn't hard, it's just a way of dealing with people, something I have learned over the years:

Interviewer: "How would you make a singleton in java?"
Me: "Well, how does this look:"

public class Foo {

    private static final Foo _foo = null;

    private Foo() {}

    public static Foo getInstance() {
        if (_foo == null) {
                _foo = new Foo();
        }
        return _foo;
    }
}

Interviewer: "Ok, good job next question..."
Me: "Hold on a sec... Look closer at what I wrote, what did I just do wrong?"
Interviewer: "Huh? You mean that's wrong somehow?" ...so then I follow with explaination of what would happen if two threads reached the inside of the if statement at the same time ...
Interviewer: "Ooooh, threading, of course. I have heard of that!"
Me: "Yeah, so, now how could we fix it? Here's the pen, show me what could be done..." ... next start a discussion about synchronization, maybe get into Java's serious double-check-lock bug/feature (and show them with pseudo-code how the HotSpot compiler can illogically re-order execution without you ever realizing it) and then discuss how one could fix it with the new ReentrantLock class, or some of the other .concurrent.lock.* packages.

Maybe ask if they can think of a way to implement any kind of locking without using synchronization, have them use the whiteboard and show you what they are thinking in an more abstract form, and then show them how Sun did it with the thread scheduler magic...

And before you know it, you've stretched a thirty minute interview into a threee hour programming discussion and you get offers to join before you leave the room.

THAT is what "experience" should have taught you, everything else you can read in a book.

Re:at "that" online retailer, they probably know

[dangermouse]

Wrong. Want to know why you're wrong?

Because I don't have the time in my day to cross every 't' and dot every 'i' for you. You are a valuable developer if I can throw the problem and maybe the broad strokes of the solution to you, and trust you to fill in the details in both in a way that makes sense, and trust you to communicate with me when (and only when) you really need information or decisions that only I can give you.

If I have to write a massive spec for everything I want you to do, I might as well replace you with some cheap team in India. They're great at giving you exactly what you ask for.

When I get people who are contemptuous in an interview, for any reason, the interview is over. I'm looking to see whether I can work with you, not whether you're the perfect little programmer monkey. The world is awash with programmer monkeys, and with assholes.

Re:at "that" online retailer, they probably know

[dangermouse]

You've misread my post.

I can write a good spec. But if I take the time to do so, there's no particular reason I should hand that spec to you for implementation rather than to a cheap offshore team. Coding to spec is their specialty, and they're not bad at it.

I don't want or need programmer monkeys. Junior developers we can train into senior developers, sure. There are a lot of very good reasons to go that route, and it's healthy and economical to have some junior devs on staff. But spending the big money on whizbang coders who need everything spelled out for them is a double waste.

My interview is designed to find people who can and will think about a problem and its solution, and who have the knowledge and experience to get the details right. Those are the best developers, and they're relatively rare. You can bet that when I find and hire them they're highly valued and treated as such.

Finally, an interview is a meeting of equals, and I approach it as such. The goal is to figure out together whether you and I want to enter into the employer-employee relationship, not for me alone to decide whether you're "good enough" for my team. If my expectations and your expectations differ, that's fine, we can shake hands and go our separate ways and the best of luck to you. Like you said, there are plenty of other employers. If you at any point display contempt for my expectations, though, you're just some prima donna asshat with a superiority complex-- don't let the door hit you on the ass, jack.