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?"

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.)

TA problems

[rednip]

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'm quessing that the reason why they are comfortable with those examples is , they were teaching it to undergrads just a few years before. It's likely that the company hired these fools right out of college (or their first job) to be architects, which is likely the job you are looking for. They have little to no project experience, and the only coding they have done is examples rather than real world solutions. We've had a group like this in our company for a couple of years now, besides costing millions every year, all they seem to do is cause headaches for those of us who do the programing.

Summer Experience

[D.A. Zollinger]

I am returning to graduate school this week, and while I attended summer school, some of my classmates did not. Most of us have had professional experience before returning for a master's degree. One colleague of mine took an internship over the summer, and worked on developing a new internal software package. Previously she had been a project manager at a couple of different companies, and had developed a successful strategy for project management. At her internship, she was a project member, and for the first time got to see things from a different perspective. The project was not well defined, and no specific goals were set until much later in the project causing a lot of people to re-work things they had previously created. As well, the project manager had poor communication skills, and did not communicate the status of the project well with members of the project. As a result, she found herself working 19 hour days, and well over a month late on this project.

As a former project manager, she had the experience, and asked questions about the nature of the project to help flush out details, as well as provide a much more narrow scope for the project. However, because she was the "intern" many of her questions were dismissed, and she was labeled as being "too detailed."

She has committed to staying with the company until the project is completed, even though it may interfere with classes for the next couple of weeks, but she feels it is her duty to see the project come to a conclusion. As such, she has the skills, resources, and know-how to make the project a reality, but it is my suspicion that the employers were afraid to give her too much responsibility in the company or with the project because of her temporary status. As well, it is obvious that the company does not have a good project manager, and the company expects mediocrity because it knows nothing different. Those who desire to excel may find themselves working against the corporate current, and may ultimately be defeated by it. I certainly wouldn't want to work in such an organization.

My experience

[cperciva]

A couple of weeks ago I did 'the interview loop' at that leading search engine. I had already told [daemonology.net] my recruiter that there wasn't any point asking me about 200-level material, and aside from one silly question about topological sorting my phone interviewer respected that. When I arrived for my on-site interviews, several interviewers apologized about being required to ask really easy questions. They asked their questions; I provided my answers; they asked why my solution wasn't the same as their solution; I explained that my solution was asymptotically faster; and we moved on to more interesting discussions.

Having not interviewed at that leading online retailer, I don't know if the situation is the same there; but my impression at that leading search engine was that my interviewers were very quick to recognize that I was more qualified than they were and to adapt their interviewing appropriately.

Um... duh?

[IBitOBear]

I call "editorial license". Whenever you try to cram a lot of observation into the (typically one paragraph) slashdot style article you have to do some word smithing. That makes things terse, and that comes off as pompous to some people.

So what...

Go ahead and try to rephrase me. I'll give you twoce the word length. Hit all the points and ask both sides of the question. And get it into a shape that would be accepted as an article...

Then go take some classes in journalisim and/or rethoric.

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.

Speaking from experience...

[Anonymous Coward]

99 out of 100 people that claim to be able to program simply can't. Even simple questions in an interview can weed-out most of them. The last three Comp Sci grads I hired couldn't write a simple for loop in C despite claiming to have had several C or Java classes. The last two guys I hired that claimed over 20 years programming experience with C couldn't do much better. I now ask plenty of 100-level programming questions in an interview. I've hired around 225 programmers in my life and only two of them could program acceptably. All of the others were hired because usually I'm told to hire the best person by a deadline or the best person out of a group of three (or whatever) interviewees. This has left me 99% of the time out of the past 35 years I've been here as the only programmer that can produce so I've been stuck doing 80 hour weeks most of the past 30 years. It is really hard to find a non-idiot programmer.

Don't be insulted by it. You probably insulted them with your attitude. I'm sure they're asking easyish questions for a reason since all of their last hires couldn't even do what they asked you to do.

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:Walk away.

[AJWM]

Never.. Ever.. ask somebody to write answers on a white board. It is not natural. If I prefer to place open/close brackets right when start a function then white boards do not fit that pattern. Little things like this make it more 'English' and less 'code'

You just failed any interview that I'd give. Not that I necessarily ask folks to write code on a white board, but if they can't handle that it shows that they're inflexible and would probably be totally lost in a design discussion or a code walkthrough. I don't care about matched brackets on a whiteboard -- compilers are real good at catching stuff like that -- but if you can't explain what you're doing in English (or whatever natural language you speak) then you don't understand it.

I'm _glad_ they didn't hire me.

[IBitOBear]

I threw no "fit". Then or now. I did answer the questions intellegently. I harbor no anger though I feel disapointed that the entire interview never got to "design".

Whoever your "we" are I pitty them your presence. You think this is "a fit", I thought it was an interesting discussion starter.

Programming without design is the quintessential case of going off half cocked.

I would be doubly disapointed if this were a deliberate selection "technique" on their part. Running rats through a maze isn't clever if all you are looking for is fast rats.

Besides, I don't "try to be cerebral", I am, for better or worse, that (over?) precise and careful. Yep, if you find that annoying, then I am _naturally_ that annoying. No effort, no wierd "attempt to seem". (Gee, a computer geek that isn't a social darling... Who could have possibly imagined _that_? 8-)

Besides, while "[I] am the one wanting the job" in your mind, shouldn't "[YOU] want the quality employee"?

If that was a deliberate test, then the hiering practice has established a damn low ceiling (IMHO of course) and the company must be constantly struggling against its tendencies towards brute-force solutions. It's not that such an approach _can't_ succede, its that such an approach will tend to hemmorage money, time, and tallent. There are so many metaphores that the mind boggles.

So why am I glad? Glad they didn't hire me _and_ glad I asked the question in this forum? The various respondents have informed us all that I am not the only person to have encountered this broken process. And if it's broken up front, its probably broken out back.

The scenery was nice though... 8-)

Maybe they don't want the most experience.

[hal2814]

What job were you applying for? Has it occured to you that you may be overqualified for the position if you're probably interviewing along with kids fresh from school? I've done many an interview and had to turn down plenty of overqualified candidates. Given their interests and abilities, they would've grown bored with the work we required of them very quickly even though they may be better at doing it in the short term. If they're gearing the interviews towards new grads, maybe that's for a reason.

Just go ahead and correct them.

[Malkin]

I have corrected interviewers in the past, and still received a job offer. Take it to a higher authority, if necessary, to convince them of their error. I once put the K&R smackdown on one guy who was trying to ask a trick question, and didn't have his facts straight. As long as you make an effort not to bruise their egos too much about it, they will usually come away with a positive impression. If they don't, then you don't want to work with them, anyway.

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

[ratboy666]

Rearrange in one pass:

What they were trying to determine was your ability to "think outside the box". The box is the definition of string.

Does that give you a clue?

Try something like this:

for character in string do
. . . if uppercase(character) add character to uppercasestring
. . . else if space(character) increment spacecount
. . . else add character to otherstring
print uppcasestring otherstring space x spacecount

Single pass. Sort of redefines "string".

That would be my first solution. And I can think of more...
I would ask a question like that of a potential programmer (at a senior level) that is going to be doing design. Just to see how the brain juices work.

YMMV
Ratboy

Just my 2 cents

[MadCat]

I've been on both sides of the hiring fence a few times, and most "vague" questions from interviewers are usually meant to see what your reaction will be to it, whether you blithely accept it and start mucking about or whether you will ask more questions to figure out what exactly the issue is.

Ofcourse there are also interviewers that shouldn't be allowed near a computer.

When doing the hiring (haven't in a while to be honest) I like to ask a few "easy" questions first, mostly centered on "how would you do X" just to see whether someone has the basic knowledge needed. If they can't answer them, it's not an immediate "no hire" but it does tend to weed out the bullshit artists. I also like to drill down. One of the last interviews I did was for a perl programmer position, so I put together some questions, some code, tossed that on a laptop, gave the interviewee the laptop and asked him to go ahead and solve my questions (implementation of a logfile parser that'd auto-update an iptables firewall for people dictionary-bombing ssh), and to fix my broken code, or suggest ways in which it could be done better.

That usually gets you a clear picture of whether someone is actually capable of performing, and doing some thinking on the spot. They are allowed to Google to their hearts content, and they can grab the big bad Perl book as well. I'm satisfied if people can't necessarily tell me things from memory, but they know where (and how) to find the information they need.

After that I try to see how they'd fit into the team as far as personality goes. How that's done depends on the applicant, and the team itself. Usually I'll take them on a little tour past the team first, show some things they're working on, then ask the applicant what he thinks and see whether he's either going to be the diplomatic type, or be honest and maybe suggest other ways to do things. I'll leave them with the team for a while and see how the discussion ends up going. This also gives the team an idea of what the applicant does or doesn't know.

Afterwards I'll usually ask the team what they thought, and take that into account as well.

I figure it's a fair way to do an interview, because people do get the chance to "show off" what they know, and I get to see whether they could work with the team.

Being the applicant myself, the absolute worst experience is when you're asked a question, you don't know the answer, but your answer of "I don't know how to do this, but I know where to find the information that will teach me how to do it" is classified as being totally wrong. I've forgotten a lot of things in the past 10 years, and often don't memorize the obscure details of certain function calls, but I know where to find all the information that I'd need to make it work.

Just my 2 cents.