Slashdot Mirror
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?"
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Probably you want to realize the company doesn't care enough about its hiring practices to have a bright future, and move on.
If you're an employer, you want to make sure that your interviewers have a strong enough grasp of the interview questions not to be wrong about possible valid answers. Allowing inexperienced developers to interview candidates is a recipe for disaster. You don't build a quality company by delegating this task to the inexperienced. You accept that this is work that is best done by your most experienced people, and that it is one of the most valuable uses of their time that you can make.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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.
Anyone who has interviewed at that "online retailer" knows exactly what you're talking about. In fact, it leaves no doubt among those who have who you're talking about.
Its a silly process... they pride themselves on Google-esque hiring practices, but miss the boat. It was the one and only place with a process more rediculous than the Evil Empire(tm).
My suggestion? Laugh at the guys giving it who imagine themselves big fish in a big pond, leave confident you've got more experience then them, and go work at a company with a better corporate culture. They're a struggling company stuck in the dot-com mentality. Unless you like that (and I'd have to guess with 20 years experience, you've outgrown sardine can working conditions and ego trips), you'll be far happier not working through interviews like that... use them as a sign of how the company works, and look elsewhere.
There are FAR better places to work.
I would already be looking to weed you out. Your disdain for the younger employees with junior technical skills is pretty obvious. As a manager, I would immediately wonder how you would treat those junior employees, and I would worry that you would regular belittle their knowledge, deride them for their mistakes and restort to intimidation to squelch a junior employee's idea that you happen to dislike.
Of course, I worked with someone who acted in the manner I describe. He actually managed to cost the company we both worked for many hours of my time, as he chose to display his extensive knowledge at every opportunity, and I found myself translating what he was saying into something that the junior employees could understand. Oh, and thanks - I had never heard of the Byzantine Generals problem. But your reference to it is something that I would take as a warning sign.
So, like previous posters, my suggestion is: just walk away. You are not built to work for a company like that.
Chivalry is not dead, it's just frequently misspelt. - M. Langley
"I have 20 years of experience in programming and systems design."
Um.. Good for you. Are we suppose to be impressed? It just means that you had a job title for 20 years.
Do you have anything to show for the 20 years? Thats what these silly little interview questions, and your answers, are suppose to show.
"And in several cases the interviewers were vague, semantically incorrect, or self-contradictory."
In all of your 20 years, haven't you ever had requirements like this? I have 10 years and I encounter them so much, I get suprised when they don't show at least one of the above qualities.
How do you handle this sort of situation in the workplace? Curl up in a corner and start crying? Run over to slashdot and complain about your horrific job?
Answer the question as you would do as an employee. Again, the questions are there to allow you to show you how much you know.
I'm sorry if I sound a little rough, but its just arrogant to be outraged by interview questions that are below you just because you believe that you have 20 years you are entitled to not answer questions.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
-Arthur
Cave ne ante ullas catapultas ambules
"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."
Never attribute to malice that which is adequately explained by stupidity.
By now I've performed about 80-100 tech interviews for a variety of IT companies. I will ask the brain dead questions, but ramp up accordingly. I essentially want to ask just enough to know whether or not I can say with confidence "HIRE" or "NO HIRE". ( Recommend reading: Joel On Software )
If relevant, I will ask for some white-boarding of UML, or a code fragment to perform a simple task.
I do all of this because, I have found that age means nothing. I've worked with some seasoned geeks who taught my colleagues and I alot on the latest technologies. I've also worked with a guy I hired who had well over 20 years experiences and was absolutely useless. I can personally say the same to guys just a few years in the field.
It's a crap shoot...and I don't like to gamble.
Another way I look at it... I've also been on the receiving end of an interview at least a dozen times. When this happens I try to show my patience when going through the brain-dead questions, because I know acting rushed or anxious is a sure way to send bad mojo to the interviewer, even if I've nailed all the tech questions.
I know I'm interviewing for a good contract when the interview switches to more challenging questions based on my answers. If the interviewer just runs through the list or makes self-contradictory statements, there is a good chance it's either a manager who doesn't know the subject matter or possibly a technie called in to give the interview and isn't good at it. At which point, it can be a fun challenge to turn up the charm with the interview, because I know the questions coming are no sweat. The degree of confidence shows leadership skills and does stick in their mind when making decisions. (Especially if the interviewer WAS a non-technie.)
P.S.: Also regarding semantically incorrect or self-contradictory statements... I sometimes deliberately throw out a misstatement to see how the interviewee responds (if at all).
--
Help me find 3 kidnapped children!
Cheers.
Secondly, I've known some people that could write software that "worked", but it was far from pretty, and it took an inordinate amount of time. We need someone who can code at a reasonable speed, where other companies, particularly non-tech companies who just have some internal tool programmers, may not care as much.
Finally, it doesn't matter so much whether you actually solve the problem, but the work process that goes into it is key. If you stare at the board and just write some stuff, it tells me nothing. That's why I like simple questions posed in a slightly vague manner. I leave a lot of things undefined about the problem to see what the person will do. They can choose to assume things, which is fine as long as the state that they're assuming it. They can ask me for clarification, which I'll gladly provide. Any of these things is a big plus, because it shows you know how to analyze a vague problem, figure out the things you need to clarify it, and still move forward with an implementation without stalling on questions and definitions. The ones who fail are inevitably the ones who just stare at the board, write a couple lines of code, erase them, stare some more, etc. Specs aren't always clear. Requirements and bug reports aren't always clear. If you can't ask the right questions to clarify a slightly vague 200 level coding quiz, you're not someone many people would want to work with.
One other comment: some people may suck at this because they rely on the compiler for everything. You can get surprisingly complex systems out of guess-and-check programming, but it's far from ideal. Quite a few new grads have this problem, although I'm not so sure about the more experienced programmers.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
The last time I saw production code that reversed a linked list, it was because someone wanted the last element of the list. So they reversed the list and extracted the head. After reading the code for a while, I realized that I was looking at C code written by a LISP programmer. I finally rewrote the thing to use C++ collection classes. A list wasn't even the right structure; a C++ vector was, because the collection was built once and then used millions of times.
Be suspicious of code that does elaborate munging on pointers. Stuff like that should be encapsulated in general-purpose routines. If you see it in application-specific code, somebody is probably doing something wrong. And it's very likely that such code will be broken during maintenance.
Programmers should know how to reverse a list, but shouldn't actually do it.
Wait 20 years.
Help stamp out iliturcy.
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!
/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:
...so then I follow with explaination of what would happen if two threads reached the inside of the if statement at the same time ... ... 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.
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
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?"
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..."
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.
It'e interesting, but all your questions assume a certain mentality that's probbably similar to you're own mentality. Are you sure you're selecting for quality programmers, and not just people that think like yourself?
That can be a good thing, and a bad thing. If everyone thinks you like you, you'll probbably all get along quite well and be able to communicate easily. But you're also likely to all make the same mistakes over and over.
AccountKiller
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.
FWIW, the following advice seems to come up a lot in these discussions. I haven't interviewed much myself, so this is mostly my way of summarising second-hand information; take it with a pinch of salt.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
A request for a resume resume, doesn't necessarily mean that the position is W-2. Just so you know for the next time you feel the need to alienate a potential client.
Even if the position was W-2, who do you think that manager will call with an open contract need? I'll give you a hint: it ain't you.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
I have a job I enjoy, that is well paying, and I don't anticipate looking in the near future, but the next time I do interview for a job I am going to ask to see *their* code and see if they can solve a problem *I* give them on a whiteboard. I want to make sure they can write code that is understandable and is commented. I want to learn new things and be challenged, not dig someone out of a mess they made because *they* don't know how to develop - or worse, expect me to maintain/extend that mess and never dig out of it.
As for that particular retailer - I've had the opportunity to interview with them, I declined, ditto for MS. I have decided that life is too short to work for such companies. I would rather work for a small company nobody has heard of that is doing something interesting.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Fuck tact. If you need tact to deal with a broken design, that's an early warning sign in and of itself.
No, fuck you. Being tactful when talking to colleagues--and especially POTENTIAL colleagues--is just basic business courtesy. You are not exempt from it just because you have to deal with a "broken" design, or for any other reason.