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?"
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.)
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.
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.
I Am My Own Worst Enemy
The force that blew the Big Bang continues to accelerate.
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.
I haven't lost my mind!
It is backed up on disk...somewhere...
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.
Tarsnap: Online backups for the truly paranoid
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 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.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
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.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
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-)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
I'll present a candidate with a real problem in the danger room (our term for the isolated test center where we diagnose stuff and load test network setups without screwing with the blades&racks that are live) and screw something up, then have them try to fix it. I'm more interested in their methodology than their solution. Our test network works, but it's a mess; if they can innovate before my eyes and tell me how to clean things up while being tactful then they're hired. My predecessor did this and so do I.
I expect to be corrected if I (intentionally, for the most part) say something wrong, but I expect tact and respect, and I'll tell them those guidelines up front. BS artists have that look when they don't know something, and they get very vague. I don't need to play games with them. Someone who knows their stuff will appreciate the honesty and show their true competent colors.
I send BS artists out the door with a pretty precise explanation of where they went wrong. Hell, I even suggest where they need to get training so they don't have to BS their way through the next interview. This way they won't bother another employer with their BS attempts, or at least they'll know why they got rejected.
If you know it, you know it, if not, then you don't, that's my motto. No need to trip people up, the losers will always get culled from the herd as soon as they open their mouths.
Playing games with applicants sucks, IMHO.
--- Grow a pair, liberals... stop letting the Republicans bully you!
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.
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-)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
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
Never, ever use your provider's address for your website and (especially) NEVER use your provider's domain name for your e-mail if it's of any importance. Look at my e-mail address for a moment, and you get the idea. When you have your own domain name, if your provider terminates you, or you leave, or you want to leave (better service, more features and/or lower price), you simply change the termination point for your service to someone else. In fact, it's not a bad idea to have your DNS service with someone other than your hosting in case you have problems or your hosting becomes overloaded (like being Slashdotted, for example) and you get locked for excessive bandwidth, you can change to someone else fairly quickly if you need to, but you might not be able to do that in a hurry if your DNS provider and your hosting provider are the same. (Especially if you can't get into your provider's control panel because they're overloaded.)
With domain names around $9 a year, there's no excuse using your provider's domain name unless you're so broke you can't afford it. Which I have been, on occasion.
Now, for that, you can often get a geographic-based domain for free (at least, in the .US you can). I established the domain "paul.washington.dc.us" which cost nothing, and ran it under a provider that allowed free hosting if you carried a banner ad, so for more than five years I had my own domain name and e-mail under that domain for free. I still have it, too, going on eight years now.
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
The parent makes an excellent point, in that what Skreems and co. really seem to be testing for is people who match their approach. The implicit assumption that their approach is (a) the only one that works, or (b) better than everyone else's, is not going to help improve their business.
There is also the problem that interview processes are two-way things. You don't know me, so let's assume for the sake of argument that I am a good programmer who knows his stuff. The moment I walk up to the building of a prospective employer I am sizing the company up. The moment someone greets me (or leaves me hanging around in reception for ten minutes) I am gauging how much value the people at the company really place on colleagues. And when we get to the technical questions, I am definitely judging the technical competence of those who would hire me, and the quality of the code produced by the existing staff if I see any.
So, dear interviewers of the world, let me put this simply. I am interviewing you, too, and I expect you to know your stuff. I would not be here if I wasn't interested in your business, but I am confident of my own abilities, including my ability to find another job quickly if yours isn't up to scratch. And it will cost me a lot less than it will cost you if today is a waste of time.
What does this mean in practice? Well, everyone's different. Personally, I think vague questions are fine and expected. I'll seek clarification without a second thought, because that's how the game works. But if the interviewer is a smart-ass, or repeatedly makes elementary mistakes, I won't take it upon myself to educate them. I will simply judge them incompetent, and not take a job working with them.
Now, perhaps a lot of companies wouldn't want to hire someone like me. (They probably wouldn't like my non-negotiable rules on IP and my expectation that I will work the hours in my contract and not give them 50% more for free, either.) That's their decision, and I accept that my principles here will rule out some companies that I might have been happy working for. But just as an employer usually gets enough applications not to worry about missing the odd good one because there will be others, so it goes with good people and finding jobs.
As they say, first impressions count. This is particularly true of interviews, because you'll never really know whether someone is a good candidate or an employer is a good place to work until a few days into the job, so the recruitment process is really just an attempt to make the guesses more educated. In this context, I'd advise any employer who wants to recruit people who are good rather than merely young and enthusiastic (now) to stick to sensible interview techniques, and avoid the time-wasting and trick questions. You aren't really hurting anyone but yourselves with that kind of stuff.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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.
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 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.
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.
There is no sig...