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

at "that" online retailer, they probably know

[yagu]

They probably know they are leaning towards fresh blood, and probably will pass on more experienced and stronger candidates. I know quite a few people who work "there", and inside, they are one of the top IT shops, bar none.

Also, there are a few things to be aware of... part of the interview process intentionally (from talking to insiders there, and at Microsoft) introduces vagueness, incorrectness, and other troubling aspects to problem solving. One of the things they're trying to observe is how a candidate deals with the obstacles.

A friend at Microsoft told me if a candidate got flustered and angry at an intractable "problem" he (or she) was pretty much disqualified on the spot. At Microsoft, you could tell your job was "no go" if it didn't last the entire day. (Mine did, sigh... and I got the job, sigh again.) Typically they "nice" way was to tell the candidate the next interviewer got caught up in some responsibilities, and that would be that.

My personal opinion, not that it amounts to a hill of beans for these companies, they sell themselves more short than they might realize. Business is about numbers games and businesses play the curve within one sigma, that's it.

As for what to do when trapped in a sophomore study group, that sophomore group pretty much holds all of the cards. Candidates would be wise to suck it up, be friendly, and at least pretend not to be bothered by their seeming snobbery. (Also, by the way, the snobbery at Microsoft is real.)

Some are better than others selecting excellent candidates (that online retailer comes to mind), but I think there's a slew of mediocre companies out there that would be better performers with a bit more appetite for investing in "old timers". Of course, coming from an old timer, I'm probably introducing my own bias.

(ASIDE, and By The Way... you said over the course of six hours you were repeatedly introduced to a guy in his early twenties... If management had any of their wits about them, they'd consider getting rid of that guy... he should have been recognizing you by the 2nd or 3rd introduction. Sheesh.)

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

[Skreems]

I agree with most of that. I'm basically one of the 20 year olds the story is complaining about. I ask retardedly easy questions when I interview people, and on occasion I will be a bit vague on purpose, to see if they will ask clarifying questions or just fumble around for a half hour (guess which one gets you hired?). The problem is, I've interviewed people who claim to have been working in industry longer than I've been alive, and you'd be amazed how many of them can't code what basically boils down to a double nested for loop. I've had people go up to the white board and fumble around for 30 minutes only to wind up back where they started. You have to ask those retardedly easy questions because half the candidates can't answer them, even the ones who've been full time workers for decades.

As for incorrect knowledge of some algorithmic stuff... there's two options. One is, they may know the correct answer, but are waiting to see if you do, and if you'll correct them. In one of my interviews coming out of college, a person said something about the problem I was working that was blatantly incorrect. He'd been working on a similar system for months, so I'm convinced that he was just seeing whether I'd correct him, or defer to him as "the authority". I corrected him, and I got the offer. The second option is that he doesn't, in which case you should stand up to him anyway. Even if he doesn't know you're right, most people will respect someone who isn't afraid to contradict them. If you just blandly defer to everything they say, how do they know what it would be like to try to design a system with you?

Not all of the impressions of snobbery at Microsoft are real, though. I found them very friendly in my interviews, and very down-to-earth. Probably depends on the group you're interviewing with, but there's a lot of people who are just good at what they do, and want you to show them that you're good at it as well.

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

[plopez]

this 'for loop' of which you speak. is it like iterating over a collection or perhaps like usinng a row fetch cursor? I vaugely remember something like that from... fortran... but haven't touched it in a while... :)

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

[boron boy]

We won't kill you, but if you ever want to see your garden gnomes again you'll give us the source code.

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.

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?

[kingkade]

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

Irrelevant, it's a basic problem.
2) There are framework functions to reverse a linked list. Who cares how they work.

See (1), it demonstrates problem-solving skills and it's not an unreasonable problem to solve. It may be insulting if you think they think you're that much of a dolt that it'd be challenging. But otherwise it's not hard at all if they give you enough time.

And let's say it is in that framework: you need to understand linked lists anyways if your problem uses lists that needs to be searched, you would know that using the list would be unwise.

And say you do "Google it". How do you verify that the code is correct? "oops this is code to reverse a circular linked list...ummmm."

I agree that you should probably not insult the guy's intelligence with such a question, or asking hm the question and giving a gameshow time limit.

And inane questions too. I had some guy ask me "what data structure would you use in designing a database application?" You just have to be gracious, don't act snobby, and "suck it up" like someone said. Joke about it later with his co-workers ;)

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.

Say it with a sneer

[nizo]

...what do you do when you find yourself trapped in a sophomore study group?

Make sure to make fun of any bogus information in a way that makes it clear any braindead moron should know better. Follow up with a story about a previous co-worker who got fired for thinking that exact same thing. Lastly make it clear that you are glad you have an interview at a competitor later and look forward to helping to crush their inept company. Adding that you will enjoy buying some of their used furniture at the firesale is a nice touch.

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.

Since you might care... A clarification.

[IBitOBear]

I didn't get the job. And after I thought about the interview I didn't really want the job. So it was a push. I took a job offer that I had gotten from another company the day before the interview loop.

Also, I have done hiring. I appreciate the need to ask some simple coding questions because it isn't that uncommon to get people in who _can't_ write a bsearch and who cannot demonstrate a mastery of the simple language syntax. But you only really need to walk that mountaiside once in the interview process.

Then again, when you write some code on a white-board and the interviewer cannot understand it (q.v. "I don't understand... why are you checking the value of the pointer and then the contents of the pointer") and then that interviewer helps build the group decision that "we should get someone more technical", you are entering the realm of high comedy.

I actually laughed when the recruiter told me about their rationale.

Re:Umm.. maybe you need to look

[IBitOBear]

You read to much into my question. I wasn't "outraged" I was bored to tears and disapointed. I didn't say "I have 20 years of experience" to them. I said that to you, the reader of the article, to give you some basis for my position. In a slashdot lead article you only get so much space and editorial attention to make the interesting points and spur on the discussion.

I did answer the questions posed. No hissy fit, no condecension. I liked the people and we got along OK.

The mire comes, however. One of the responses, for instance, was "I've never seen it done that way before" followed by a thats-impossible shake of the head and an "why are you comparing the pointers and then the contents of the pointers like that" when I explained how this second tier (e.g. more complex) question was still soluable in O(log(n)) time using the method presented.

Several interviewers said in the interviews that they didn't understand the code as written etc, then the group consensus was that they needed someone "more technical".

ASIDE: I will fully credit that a good percentage of the lack of understanding may well have been introduced by my crappy white-board penmenship. 8-)

Re:My experience

[Achromatic1978]

Now now, that's not right. After all, working at "that leading search engine", they'd have all rushed out the room to consult "define: asymptotically".

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:Your expierience didn't pay off

[greg1104]

This reminds me of my worst interview ever. It was for a C programming job, ten years ago. The main programmer at the company asks "how you can write a function that [some operation on an arbitrary string requiring memory] without allocating memory at run-time inside the function?". I said "you can't without relaxing some part of the requirements". He disagrees; I ask for his solution. He shows a function using a static buffer, so the memory is allocated at compile time. I point out that a) this puts a limit on the size of strings it can handle, which he accepts and b) you'll be screwed the minute you introduce that code into a multi-threaded environment like the one they deploy their code into, because your static variable will inevitably get clobbered one day by two calls to this utility function. After some argument, he comes to recognize my point, and I ultimately got offered the job.

Three months later I was fired for arguing with him all the time about how code should be built.