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?"
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.
So maybe that's a problem. Eh?
An interview should be more about interviewing the company than them interviewing you. This sounds like a place I would not like to work at because they do not value design. That being said, Byzantine Generals have no value in today's workforce. It's all about machine guns now.
Your post is one way of looking at it. Here's another. It could be a simulation of the requirements process. Testing how well you can handle them.
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
I took a job once where they didn't even bother to send me a techie for the interview. While I could do the work, the work environment was awful. If they can't be bothered, you can't be bothered.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
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
It seems i'm the only person who doesn't know what organization you're coyly hinting at. It's killing me...
why run from Vincenzo?
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
They have goals, so do you. Evaluate accordingly.
"Time flies like an arrow; fruit flies like a banana." --Groucho Marx
From the article...
I'd say that puts it around $0. You don't buy a business that isn't making money. It's stupid. Also, don't even talk to me about Murdoch and MySpace. We are talking about the guy that created the problem of placing arbitrary value on the balance sheet as Goodwill to justify his acquisitions. It's a shell game that Murdoch and a few others like Mark Cuban might find a way to time and win - but that a lot of other companies trying to follow in their footsteps that are going to lose big on. I'd even wager that Murdoch is going to get bitten playing this game.
"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.
Just think - in any company the managers are the least technically astute employees, and they have the biggest influence in the technical content of the software. If the development engineers are working at a very low level of technical content, just imagine how bad the managers must be. You will be using javascript encoding of passwords rather than SSL. All of your data will be in one table in name value pairs. Instead of exchanging data between servers using efficient protocols you will be passing around flat files containing fixed length records because these are the techincal approaches understood by your managers.
Just run away, fast. You can bet your prospective employer won't be around very long anyway.
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
Nobody, no matter how bright they are knows everything. When you can influence a person to learn something new they will latch on to you because you empower them to become better at what they want to do well in, other wise you are just wasting your time. I had one interview that started at 5:00 pm after work, and lasted until the 1:30 am in the morning and we never got halfway through his list of questions. The problem was that I had multiple answers, none of what he had considered and all of which demonstrated that there was much for him to know and learn. He realized during that interview that I was the one that could do the best job for the company, not to mention his own career path. The next morning I turned down the job flat despite the money, because they were using SCO Unix (Pre Caldera, Pre-SCOg).
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
Let's face it, there were "cultural differences" to be seen in your interview story.
;-) apparently didn't suit the intense ways of our ISP's staff.
:-)
:-/
;-)
Maybe the younger (20-something) person doesn't know how to deal with folks with "20 years experience"
That can create a bit of fear of being embarrassed (if you were to be hired) by your comments,
eg, at future design meetings, etc.
From his perspective, with a long list of other applicants in-hand, why take the risk?
---
PS If it's any consolation, I think I've had a similar experience with a South Australian ISP
(one that I've heard called a "backyarder" even though he/they seem to be expanding into NSW)
Apparenlty run by a "young-whipper-snapper" (as the expression goes) our calm, collected ways
(from our 50+ years of enjoyable living, across least 5 great countries, not counting ones we
loved while on holiday away...
They once called for User feedback on how their broadband plans could be priced; after giving
my 2 cents on the topic (eg describing any plans that charged over Au$ 100/GB of excess d'load
as "Putting a block before the Blind"), I was given notice that our broadband account would be
TERMINATED at the end of the month (after about 4 months of normal usage).
It seems that some folks are just overly sensitive about what other folks say/write.
This ISP also went so far as to claim we had not been paying our monthly (flat-rate) ISP fees,
ie, long after we gave them our credit card details & they'd agreed to debit out fees as they
became due. We always have more than enough funds in our credit-card-linked account, and the
card was never suspended nor was its number changed. No problems with any other vendors' pay-
ments (by similar debitting). They had succesfully debitted our setup & initial month's fees,
without any problem, so we knew we'd given them the right credit card details.
After we pointed out (with a letter of verification from our Bank's credit card investigator)
that the ISP hadn't attempted to debit our credit card since taking its first payment, months
ago, they suddenly stopped claiming we didn't pay... and turned around & informed us they'd
be PAYING US all the money that would have become payable - over the 6 months of our contract
- as COMPENSATION for them TERMINATING our account, ie, refusing to provide service from 1 Sep.
For locals: the ISP is called "PowerBand Networks"
(A friend called it "PowerTrip Networks" - ie, after hearing the story
On paper, they have a few great plans (for the Aussie market), but don't let your opinion(s)
of their problems get back to their staaff, or you may have to find a new ISP in a hurry
(with all the hassle of informing your correspondents of your new eMail address & shifting
your web sites, etc.)!
If we raise a complaint on this matter to Australia's Telecommunications Industry Ombudsman
(TIO), we'll post the documents from the case, as they become available... ie, if the TIO
doesn't preclude their publication, as other courts do, all too often.
[We're also taking legal advice on our option in the courts.]
Can you imagine an ISP who has to watch what their users post about their service?!? Odd
A colleague considers them "emotionally needy" but they just didn't seem to be on the same
wavelength as me when in the few time we had to report a fault or ask for HowTo details (eg,
on accessing their peering partner's content... I don't think even -they- know to access it,
but I could be wrong...)
Tip:
Odd people, these South Australians... Lotsa work for Mental Health Professionals here.
If you're in that industry, and might like to migrate to Australia, here's your chance!
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.
(Insert some famous quote along the lines of "When men were studying bats, bats had an unparalleled opportunity to study Man.")
If they're dunderheads and can't ask good questions, don't go. REALLY don't sign up. I did that once, it sucked true and hard, and I bailed in five months even though the CEO was in tears [yup] during my exit interview with him, begging me to stay. I still tell stories about that place, like the time they brought in a head-shrinker [yup] to interview the whole engineering staff to find out what was wrong with their development practices. ("My mother? Let me tell you about my mother...") No real mystery to me: With a couple of exceptions the engineers they had hired were god-awful.
My fault for going there. I let a salary distract me from what made me happy: Working with good people and shipping.
On the bright side of things, an experience like that can be good for building a network. The good people stand out. "Man, we're all in this together, right? You, me, and the oxygen-waster undead out there who are probably still (shudder) putting more syntax errors into tonight's release..." I still keep in touch with the three people I respected from that dunderhead company.
One good touchstone for interviewing those aged, hoary old engineers with 20+ years of experience: See how they are keeping up with stuff in the industry. What have they read recently? What technical resources do they use? Are they an ACM or IEEE member, do they read papers or newsgroups with decent technical content? [At 27 years since my first paying job -- hacking C on V6 Unix -- I know that if you're not continually upgrading your skills and knowledge that you're basically toast within a few years. It's really easy to get behind the curve].
Any sufficiently advanced technology is insufficiently documented.
We use tests like that to weed out people like you who try so hard to be cerebral that they are impractical and can't work well with others. Take the damned test and don't complain about it. YOU are the one wanting the job and if you answer the questions intelligently, no one is going to weed you out. If you throw a fit about it in public, like this, you obviously aren't the kind of person a company would want anyway.
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.
Personality and social awareness probably makes the most difference, once a candidate has passed a resume screen and a phone screen and has technical skills that are in the ballpark of the job requirements. I've been an interviewer and interviewee many times and I've come away wondering at the dynamics of the situation. In particular, what are the personal interests of the interviewers? In a pre-IPO startup, there might be intense interest to hire the sharpest, most capable staff so that everyone will get rich from stock options. But in a big, prosperous company like Amazon or Microsoft (or IBM, HP, Cisco etc), "individual contributor" hires rarely make much of a difference, and even if they did, they don't necessarily benefit those individuals doing the hiring, except for the hiring manager.
That's why it basically comes down to people hiring the candidate who makes them feel most comfortable, and that is largely a matter of personality and social awareness. Because when interviewers huddle together to discuss their evaluations of the candidate, these evaluations are quite subjective and may contain gross errors of technical judgement, as the original poster suggests. What does an interviewer have to gain by making the most technically accurate appraisal possible? Instead, s/he votes for people s/he wouldn't mind working with on a daily basis, even if their skills are somewhat deficient.
If you can't talk through a problem on the whiteboard, in [pick your favorite language], then I humbly submit that you cannot code. In fact, your first language of choice should be english (or spanish/mandarin/tagalog, or whatever non-code language you speak at your company).
If you can't describe the problem, your approach to solving it, and the actual solution in english...then you have no business writing code.
Vague guidelines? Did you ask questions? Probe the problem domain? Figure out that problem that they really wanted you to solve?
At our shop we hire people that get stuff done. We don't look for code monkeys that can only operate by following a precise script. Looking for concrete guidelines? Go work at a fast food joint, where your entire operating procedure is in a 3 ring binder, and you dare not deviate.
The working nights sucks, though.
Would you ask an interview candidate to program a "Hello World" program?
simple, fast homepage with your links: http://www.ngumbi.com/
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
At another leading internet company, I got into an argument with a young 20-something hotshot about the complexity of building a heap. I said that the average time complexity to insert a single item into a heap is constant. He said it was log(n) -- which is actually the worst case. I started to explain to him why it was constant, and he interrupted me after a few seconds and just insisted it was log(n). The sad thing was I was just thinking out loud when I mentioned building a heap and it didn't really have an application to the original problem he asked.
I'm a 22 year old guy, interviewing candidates for a helpdesk SA position (someone working under me).
Any good tips for how to *not* come off like a young idiot?
Jay | http://oldos.org
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.
... but I wouldn't want to hire an engineer who couldn't figure out how to do it with a pencil and paper.
You're not expected to remember the solution for reversing a linked list. You're supposed to remember the most trivial, basic property of lists: they start with one node which you know about, and each node points to the next node. And you're supposed to use those twenty years of experience to be able to *devise* a solution to the problem. Which if you know that simple property and have a practical understanding of how to actually work with lists you should be able to do in about five minutes. Then you say "Oh wait, my twenty years of experience is tingling, that solution is O(n^2) and it shouldn't be nearly that hard because the framework I use every day does it a heck of a lot faster".
Help poke pirates in the eyepatch, arr.
If I take your comments out of context I'd probbably weed you out in an interview as well. You assume a lot from what amounts to candid responses usually reserved to your friends over a beer. It's really not that uncommon to come out of an interview and think "What the hell was all that about?", and then want to ask others if they've had similar experiences and what they did/would do.
It sounds like you're filling in all the gaps of who the poster is with your own personal biases. That's usually not a good idea, especially when you've never even met the person and are relying on a one paragraph writeup of an experience.
AccountKiller
I admit I've never had the guts to do it, but I thought it would be great to prepare a test for the interviewer that you can whip-out when presented with a test for you to perform.
I suggest a reverse-trick "what is the code doing" question: i.e. one that appears at first glance to solve a well-known problem but actually doesn't. Make them examine all the trees rather than the forest.
It probably want get you the job but it might scare the interviewers from testing other candidates in the future.
The most interesting part of the responses in this article are all the varied little voodoo that people use to separate the "good" developers from the "bad" developers. Some people seem to focus on the technical questions, i.e. if you can't write an algorithm that reverses a linked-list in 10 minutes, you stink. Ignoring the fact that not all languages even have linked list data structures in them. Also ignoring the fact that a lot of programming values higher level architecture and maintainability over what often amounts to minor details like re-inventing the linked list. Lots of people modded this highly though, so it's a continuing belief.
Others seem to focus in on the "n years experience doesn't matter one bit!!!" Well, yes and no. Obviously there's people that've been around 20 years and learned nothing. But everything else being equal the person with 20 years experience is probbably going to better than the kid straight out of college.
Then there's the "I can smell how good/bad you are from your attitude!" camp. Even in an interview where you're standing right in front of someone this isn't exactly easy. If you think you can do this from a short "Ask Slashdot" post, you've got some real learning to do. I suggest you read up on taking things out of context, writing for an audience, and limiting article length.
In general there's a lot of judgemental replies to this article. Personally I see this as reflecting a lot of insecurity. So many people jump all over the place to try to find the lower quality programmers, as if that makes you a better programmer. There's a lot of good replies offering real advice too, but I find the variety of "interview voodoo" techniques a lot more interesting. Essentially there seems to be no agreement at all on how to seperate the wheat from the chaff.
Frankly I don't know what the magic bullet is to seperate the good from the bad. I guess I'd want to look at stuff the developer has actually done. Often that's impossible since most code is closed-source, and not available to future employers.
AccountKiller
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
I only have a couple of years experience, so I doubt my advice means much to you, but I say just go with it. Explain the simple solution that they will understand first - after all, it may be more maintainable - but mention that there are more complex solutions. It's sad, but I experience does not necessarily equate to programming ability, so they have to ask those kind of questions. I regularly see appalling mistakes in code from experienced engineers (finding the nearest multiple of X to Y using a while loop for example). But then I also wince when I see the code I wrote when I first started here.
As companies get bigger, the "IQ" of the company begins to regress to the average for the population at large. Decisions become poorer, profits lower. It's normal, wouldn't worry about it.
Deleted
Being someone people can work with is often be more important than technical merit no matter how good you are (unless you're a prima donna, in which case they know that and they take that into account, and that's a whole other issue).
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
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 lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
.... but who remembers all this stuff? If you're actually working on real-world software, do people really remember all these algorithms and stuff no one uses anymore because class libraries do all the pointers and memory management for you? Given enough time and books, I could remember how to reverse a linked list, but with C++ templates, Java class libraries, and dynamic languages like Perl, who does that kind of stuff on a daily basis? I might remember something about B-Tree algorithms, but who hand-codes their own database anymore? In the hiring process, doesn't the track record of a person count for something?
...Job seekers, what do you do when you find yourself trapped in a sophomore study group?
Find a new place to work, who'd want to work for those kinda idiots?
Shadus
There are too many companies and managers that don't really know how to interview. They look for very narrow and specific skills matches and resumes experience. They think that these "test" will tell you how someone thinks about problems. They sort of do, but they don't tell you about the person's ability to learn, grow and consistly deliver. Too many people think that things like language knowledge are key when anyone with the right experience cna pick up a language they don't know quickly. It isn't knowing syntax it is work ethic, problem solving, and adaptability. What they really want is the best and brightest candidate that they can find with skills that are close and a proven track record of being able to learn new things.
I had someone who worked for me that went on an interview a couple of years ago who had superior skills in C++, knew MS GUI stuff, had learned Java in 4 weeks and built a very fancy applet, etc. He interviewed at a company that said "Well, you don't have 2 years of C#". C# was only 2 years old! The person toook another job, picked up C# in a few weeks and created some incredibly complex and innovative new applications.
Things move fast and change in out business. Just because you are a Java shop today doesn't mean folks won't need to do Rails next week. You want bright and adaptable people. You want a track record of learning and adaptability. Yes, you might pay a few week learning curve, but after that the better person will more than make up for the learning time by producing more and better results.
When you interview have someone with relatively similar level of experience do the interview. An interviewee might present a solution that is beyond the knowledge and skill of some junior person to get. That happened to someone else I know. The junior guy didn't know enough about Java and J2EE to understand the solution and why it was the best way to address a problem. This was in 2003. The interviewer had 2+ years of Java and the person being interviewed starting working in Java, full time in 1995!
Everyone has both strengths and weaknesses. You have to look at many factors when hiring. You could try to hire somebody to bring strengths to a team to cover for some weaknesses in existing members. You wouldn't want to hire just folks who work well when writing code on a white board. For one thing, why are we writing code on a white board in the first place? I usually use white boards to express ideas; quasi-pseudo code at the most.
I don't ask folks to write code in an interview. It's not natural and I think it's a waste of time. I ask them to bring in some code they wrote. Hopefully they'll bring in some of their best code that they took the time to properly research, written in an environment they find conducive to development.
Discussing an algorithm or doing some design work is better for an interview. It's the kind of thing you'll do together on the job after all.
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.
I used to work with a guy named John. He told me this story.
A few years ago John was interviewing candidates for a position. He received a few resumes, but one really stood out. The guy looked sharp...on paper. The odd thing was that during the intereviewed, he kept talking about all of the Ctt experience he had - Johns had never heard of Ctt and wondered what the guy was talking about. When quized about it the candidate was rather vague, only describing it as an object oriented version of c. That's when John experienced what some refer to as a moment of clarity. The candidate was saying Ctt, but he was talking about C++. Further investigation revealed that the guy was completely full of shit and had fabricated the entire resume.
and that's they story of why they give programming quizes to candidates...even those that look good on paper.
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.
...you can put a stop to all this. Just walk away, and we will spare your lives."
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.
As I found out when I was seeking work a few years ago, and as my youngest brother found out quite recently, getting to the interview stage is a challenge in itself these days. There are so many filtering mechanisms in place before the actual person-to-person interview process that it's a wonder that companies are able to find *anyone* who fits their overexacting requirements.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
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 some nutty interviews where I got asked the craziest questions by utter nincompoops. Its best to stay out of the rat race. Maintain a rolodex of old freinds and acquantainces who know you, your reputation. If you ned to find a job, just start calling. Typically, if there's an opening, you'll get hired on the spot, no interview, nothing, simply because they already know who you are. Better yet, you might get wind of two or three openings, and then you get to choose the one you want. Much, much better deal than the anonymous walked-in-off-the-street hiring process.
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...
I'm not a programmer, but I built and sold a sturdy mailing list manager on Paradox for DOS. I took great pride in its technical aspects that was apparent to anyone who sat down and used it.
Your contempt for excellence explains why so many great programs have been versioned into junk. I am thinking of Paradigm, it was a wonderfully productive fund raiser, best of breed. It was bought out by Best Software and improved by team leaders to the point where it's a bug ridden mess.
You are threatened by competence. You undoubtedly cut your teeth in the dot bomb era where a mans' intellect was defined by the number of his PowerPoint slides. Now I know what happened to Borland Software.
At my last company the following people interviewed candidates:
- The hiring manager
- someone with particular expertise in the domain we needed and the candidate claimed to have (even if not in the team that person would be hired into)
- all the team mates for that person (or many of them)
The idea is that we'd have a good feel for the person's abilities and how they fit in and they'd get a better idea of whom they'd be working with.Whoever went first was supposed to ask a simple programming question which required answering it on the board. The asker was always someone senior so you didn't have a newby try to show off. We always told the candidate what we were doing, something along the lines of "Just solve this little problem on the board. It's OK if you miss a semicolon or something; the idea is just to get an idea of how you think." It's amazing how many people failed these trivial examples. If you flopped, we cut things short so as not to waste the candidate's time or (especially) ours. Examples:
- "Here's an array of numbers. Please return another array with them sorted". (or sometimes "sort them in place"). One candidate allocated two temporary arrays and still managed to permute, but not sort the array. Oh and he returned a pointer to a locally-allocated array on the stack. Another just copied the array, and took a lot of prompting to figure out why. That guy actually sent me an alternate solution the next day -- and it was wrong too.
- Another one (a systems programmer with "years of kernel experience") I asked how strace worked. After I explained what it did, he said it recompiled the code. I suggested that it could be run for a static binary to which I didn't have the source or symbols. He became abusive and started flaming me for "these stupid questions that don't relate to the job" (too bad for him system performance was the job area).
A couple of people ended up copying the array but when asked "are you sure?" would go "damn" and fix it. That was fine -- we assured them that it was OK and clearly just the stress of an interview. Then we'd tell them that they would be amazed at how many people couldn't pass and apologize for the elementary nature of the problem and say that that they shouldn't worry about the silly mistake which of course we all make from time to time even when not under pressure.It's just as bad when a company rejects a candidate just for making a stupid mistake. In fact people who see the mistake and deal with it (even if they're embarassed) are people with integrity. Those are the people I would hope we all want to work with. Frankly it sucks to put them under pressure but I don't know a better way to squeeze out the impostors.
It's also important that the candidates get as much opportunity to see their future coworkers as possible. If they hate us, well, better they flush us up front than we all waste time.
At my current company we have a slightly different approach (unfortunate but unavoidable due to certain atypical circumstances) and can't do this. And a couple of ringers have snuck through.
I recently went on an interview for a PHP/MySQL position. The company was very small, and I have lots of experience (15 years) in a variety of areas, that I thought I might be perfect for the position. Unfortunately, I don't have any real world PHP/MySQL experience - most of this area has been done at home using a Mandrake box I set up for the purpose of recoding my website (I wish I had it done and up - I could have shown them what I have been working on). My most current experience has been using ASP and MSSQL - I also have experience with a variety of other languages (Perl, VB, Python, various assembler, etc) and DB platforms (MSSQL, Access, PostgreSQL, MySQL, etc).
As part of the interview process they asked me a variety of questions relating to both PHP and MySQL. All of the questions I had past experiences with, but unfortunately for me since I didn't have much past experiences with the problems they described, I know I flubbed on them badly. When I didn't know the answer, I told them "I don't know". When I knew the answer, or had an idea, I tried to articulate it as best as possible. I know that some of the answers I got were 100% correct, but others I honestly had no clue, and I told them that.
I then tried to tell them what I would do in such a situation - ie, not knowing the answer, or not knowing the answer fully. I told them I would likely use Google to find the solution. I don't know if they liked this answer or not (it seems likely they didn't) - but it is the truth. When I don't know the answer to something, I consult books (if I have them) or Google around until I find a solution. I don't just cut and paste code, either - I try to understand the solution and the why for it, and then keep it in my mind for future use. Unfortunately, if I only run into something once from six months ago, I am likely to forget it. However, rare has been a problem that somebody else has had and it isn't answered on Google or any other of the methods I know to research. My personal library is pretty large, and the public library is much larger still. If I couldn't find something in PHP, I would search for the general problem area in all languages - if all I could find was something in ALGOL from 30 years ago, then so be it - I will convert the code and understand it.
Like I said, I don't think they liked my answer, as I have yet to hear anything from them, and it has been a few weeks since that interview. I sent a follow-up thank-you email. I also called to ask if the selection process was still occurring, and they said "yes, can we call you back tommorow?" - but tommorow never came...
To me, this is what irks me the most, and makes me question if I really want to work there: if the company can't even take the small amount of time to tell you on the phone "Sorry, we have selected another candidate", even after repeated requests - if they don't have the courage to say "no" to an interviewee who has failed the selection process - then will they have the fortitude to question other decisions made by their vendors or clients? In the end, I think I might have just failed because of lack of significant exposure to PHP and MySQL. Maybe I will have better luck in the future. I do think, however, that I deserve at least a "Thank you, but no thanks"...
Reason is the Path to God - Anon
My, how German. If one cannot accept a question on its own premises, including context, one isn't much of a problem solver. In a hypothetical interview: By going through your whole Spiel on how great you are by showing how little the interviewer is, you've wasted not only his time, but also your own. The question as posed is obviously unuseful in a production system, but it is there simply to gauge some criteria the interviewer is looking for.
"If you really want it to be permanent reversed, swap head and tail."
Ok... what happens to the next pointer of the head and the previous pointer of the tail during this maneuver?
"If you really really want to reverse in place, then I ask how the heck you managed to load your data in backwards in the first place."
I'd answer that's outside the problem scope. If you kept insisting, I'd tell you customer constraints involved using a third party library that had a key function returning a pointer to a singly linked list - which needs to be processed in reverse.
"Only after you could explain that would I bother with the fact that the previously mentioned reverse link list can just be used to swap pointers by chaining both directions at once. Of course, such an operation requires a locking mechanism for the list as a whole and I'm going to guess that any software that requires swapping a singly linked list in place probably doesn't bother doing that."
At which point, I'd say the list was in non-shared memory and ask why you had to go copy all that data when you could have used a couple of temp variables to iterate through the list and reverse it in one sweep. To give you a second chance, I'd have asked how one could minimize the amount of variables needed by swapping without an intermediate variable.
Then I would have asked you where you took up your Zen and which brand of Zen one is supposed to flaunt.
Oh well, guess you wouldn't have wanted to work for me anyways.
H.S.
Actually, I think that they don't know what they are doing.
I am a experienced software and quality engineering manager with 20 plus years of post-college experience. I also put myself through school writing systems for UC Santa Cruz's Administrative Information Systems group in the earlier to mid-80s.
I recently went through a round of 18 interviews at a large web software company. Early on I had an interview with a young, smart, and energetic guy. In the interview he told me that he had worked at Microsoft and then had come to this company. Based on his comments I pegged him as having 4-6 years of experience.
We were discussing N-Tier web applications (point of information, I worked on my first N-Tier web application in 1994). In the course of discussing load balancing for this mythical application, I made a reference to "round robin DNS". At this point our interviewer stopped the interview dead and said, "Do you even know what DNS does?". I then patiently explained what DNS does and how it works, but it was clear that he didn't come back to a strong level of comfort with me. What disturbed me, is he didn't ask me, "What is round robin DNS? Why would you use it?"
A couple of weeks later - in the same loop of interviews - I was speaking to an engineering lead with a decade and a half to two decades of experience. We were going through the same questsion and I this time I spoke about load balancing and perhaps using an F5 (which we had used at my previous employer), but made a comment, "I had to catch myself there, and make sure I didn't refer to "round robin DNS", that got me in trouble with someone earlier..."
My experienced lead jumped on that comment and said, "Round robin DNS! Wow, haven't heard that one mentioned in quite a while!" He then drilled down on how we used round robin DNS and situations in which I would use it in contrast to a more intelligent load balancer like an F5.
I honestly believe that a number of companies have created an environment and hiring process that is perfect for getting the best of "new blood". These processes can be and are driven by high qualitative inputs, but don't attempt to bring in qualitative factors. They are able to hire for skills, knowledge, and to a degree talent. They can't hire for experience. The systems breakdown when attempting to hire experienced people and technical leaders (managers, directors, etc.).
Going into the hiring process at this company, I spoke to several of my friends who work there. They said upfront in unison, "Jordan we don't know how to hire managers and experienced people here. I have seen fantastic technical leaders get rejected for no reason I can grok. Be warned. It might now be fun."
Simply put, these folks are lacking in wisdom. They don't know what they don't know. Because they think they know everything of value (which is everything they learned in University and their early work experience) and are running their BS detectors at maximum output, they trigger on anything thing that doesn't fit what they know and assume you are BSing them.
Yours,
Jordan
Posting anonymously, for the purpose of sharing my personal views, and not speaking officially on behalf of the company in any way:
.com and check out the software I've posted, I think it's pretty cool". Personally, this alone probably made the difference in my getting hired. As an interviewer, I will always 100% of the time follow up on such invitations -- not just as a courtesy to the candidate for his/her initiative, but also because it is likely to better provide the data I'm seeking than any 15 minute canned problem ever will.
So, I was part of your interview loop.
I have tried to read through your postings here with an open mind, taking in everything you have said. I realize I have probably failed at this goal, as there is much emotion and wounded ego at play here, on both sides. That said, I'm not posting this to flame, or to hurt, but with the hope that I (and the both of us) may genuinely learn. And I must preface my comments with the unfortunate disclaimer that, should your reply be along such unconstructive lines, I will not be inclined to reply further.
I am curious to know (non-rhetorically asked) what you would have preferred to have been asked instead? What could have been asked or discussed? In other words: you've clearly denounced our interviewing as "wrong". So what would have been "right"? I don't ask this with any snarl or malice; I would genuinely like to know how I could do things better.
My inquiry pertains to something you wrote in your rebuke to us:
> In some ways its like asking an accomplished chef "how do you cook an egg?"
> The chef will tend to balk when he talks about the egg being "done"
> and the questioner asks "how do you know it's 'done'?".
Interviewing is a [fascinatingly] difficult challenge from the point of view of the business. One has a mere x minutes to go from virtually zero information to a hiring decision. That is an incredibly hard problem. The process will always be imperfect; hence, the goal (in aggregate) is to have fewer false positives than false negatives.
In the spirit of joelonsoftware.com's writings on interviewing, I generally seek confirmation of two areas: aptitude and productivity. I also give high marks to positive attitude and desire for learning (what I call "runway"). I don't really care how those areas are confirmed. But I need the confirmation.
Some of my best interview candidates have been ones that, through no intentional malice or "sneaky plan" on their part, have 'hijacked' a good part of the interview (I say 'hijacked' in quotes because I intentionally allowed, even encouraged, the digression). They realize upfront that more than anything, an interview is a **data-finding** exercise on the part of the interviewer. And for that reason, they bring a lot of data to share: sample code printouts from their hand-selected "best work ever"; they might have a big print-out of some cool architectural diagram; or they talk about some cool side project they've done, or say (even plead), "please go to
Getting to my inquiry:
In your "accomplished chef" analogy, you overlook the employer's fundamental need to collect data. I really am at a loss and do not understand how you can argue this: is the employer simply supposed to take your word that you are an accomplished chef, a veteran architect?
It's an interview. We don't know you, but we genuinely want to know you. In a cynical sense, yes, you have to sell us about yourself. In a more tempered sense, you have to make sure we get accurate data ("the full picture") about yourself -- this is especially true if you think our questions are overlooking key areas of strength on your part.
Personally, I would expect a truly accomplished chef (senior engineer) to have the awareness and, well, the humility to know that he should never "balk" at a question because it is somehow beneath him / a waste of time / aside from the point, etc. Instead, he would (1) give consideration to the ba
We've got a user base of 6k and the most important thing seems to be...Who you know. Hiring prefs to friends and family members are more the rule than exception.