I'm actually interested to know what kind of developer gets the job. And also, what was he/she thinking when accepting the job, was it out of necessity? because he/she liked the interview process? (I'm asking seriously)
Just like having a drivers license is no guarantee you are a good driver, having many years of job experience programming is no guarantee you are a programmer.
On the other hand, you are liable for any damage you do to a car you rent, plus the company is fully insured in the case you do any damage and can't pay. Hiring and firing someone (which is the only real way to know if someone is a good developer) is very expensive.
Here's what it would be like if we hired programmers like we rent cars:
You walk in to a software company and are immediately hired under these conditions: "We'll take you on for 6 months, but if it doesn't work out you need to pay us back all of your salary, plus benefits and payroll tax"
He's not saying "don't find a good programmer." He's saying that the questions they ask get them no closer to finding out whether he is a good programmer.
He's saying that the questions they ask get them no closer to finding out whether he is a good programmer.
A lot of the time they're not meant to. They're meant to figure out whether he's a bad programmer (or bad cultural fit, or something else bad).
The cost of hiring someone bad is way higher than most people would guess. I've come to believe that in many cases the questions asked in an interview almost don't matter - they're just there to give you an opportunity to fail, or to say something incredibly dumb or ignorant or obnoxious so that the interviewer can quickly reject you and avoid an expensive mistake.
As long as the interviewer treats it like that I'd be fine with it. If they are playing things the way you describe then answering a question with "why does it matter?" would be a viable response and you'd be open to discussion about it.
The real world problem is that too many interviews follow the model because that's what they know from past experience themselves. They may not know why they ask such baseless questions, all they know is the answer they want and damn you if you don't give it to them.
If you hire someone who is boring and has no obvious problem but isn't very productive, you have your ass covered. His lack of productivity is his fault. If you hire someone exceptionally useful with some notable problem, or even just some notable flavor someone doesn't like, it is something you should have noticed and you are liable. A lot of companies want an unblemished calf more than they want a Zed Shaw.
While this seems "spot on" at first glance, I can tell you that when I interviewed at Google and Amazon (two years ago), it wasn't anywhere near this bad. Both places asked what might seem like contrived technical questions, but the thing is, you have to pick something that can be tested in an hour (or less). That, and it's not the answer that matters, but more your process of working a problem. They didn't seem to care too much about experience with specific tools. I guess it depends on the organization, and I can see how many places would be much worse. My question is, if they care so much about experience with specific tools, why do they even get to an in-person interview with someone who doesn't have it on their resume?
My experience with Amazon was similar but at the end I was led to ask: "if the 1hr filter process isn't efficient at finding the best candidates, why do they do it?"
I think in the end its a balance of basic filtering vs. HR requirements. The process has to be objective and quantifiable so they're covered in the event of anyone calling foul play. Everyone gets the same treatment and there is a paper trail of reasons for why they turned you down.
The process only has to look objective and quantifiable. Everyone doesn't get the same treatment, but it's not actionable if the differences are all deniable and have rationalizations like 'culture fit'. People can and do still hire who they want for whatever reason, they just claim some objective reason for it.
Ah yes, I completely agree. I really should have clarified by the HR part in that it is meant for HR's use and not the actual hiring manager/interviewer. If they want to sabotage the interview or otherwise they still can; its just harder to prove-if at all
Hiring practices of Google and Amazon are very unrepresentative of smaller companies and more heavily emphasize general intelligence, prestigious background and background in computer science. As you say, it's about the process of working a problem more than experience with specific tools.
However, most companies are smaller than Google and Amazon and have different practices. Sometimes, stupid practices, because the interviewers don't really know how to do it, just want to get it over with, or really care about things which aren't important.
But since they are in the hiring position and assume they and their company are awesome, they are not so likely to question their own technical or interviewing abilities and certainly don't want to hear what interviewees have to say about it.
You need additional insights beyond just doing the job to understand what makes someone else useful in that job. And if you don't even have that much, you are guaranteed to ask stupid questions and end up with people selected for how good they are at selling and how much you think they're cool.
For future interviews, I've collected similar questions to ask of them (questions that I have conveniently worked out or looked up the answer to beforehand), my rationale being, "I want to make sure I would be working with competent peers." And I don't give a fuck if it rubs them the wrong way.
If your rationale is to find out if you're going to work with competent peers, why not asK a question that leads into a proper, deeper technical discussion?
He meant his stated rationale. I'm sure his actual rationale is to try and help the interviewer achieve enlightenment by turning his own pointless methods back on him.
Right so to ace the interview all one needs is some white racing overalls and a white simpson Daimondback helemt accessorized with a vintage HP calculator and a set of steam tables.
Some say that his not only the man-in-the-middle, he's at both ends and has wiretaps on Alice, Bob, Carol and Dave. and that he once crashed a 10 way IBM sysplex by staring at at it all we know is hes the stigs nerdy cousin.
I agree with parts of it, but I disagree with the basic premise that hiring programmers is like renting cars. When you hire a programmer, it is like hiring a car mechanic, not a car driver. Some of the questions do seem appropriate to ask to a car mechanic.
Car Mechanics dont build the car parts or research into how to build the most efficient engine, but do need to know how to apply the knowledge of those parts. The best car mechanics can apply the science but may not be the best car researchers. Thats why in my opinion, some questions do make sense for a car mechanic.
If you were using the photoshop analogy, then I think to interview someone, you need to ask them how different features of Photoshop work, not how Photoshop was built but also not how they draw in general, IMO. You may be a great artist, but if you can't understand Photoshop features and what they mean you will fail to create a great digital painting.
The car mechanic analogy is an interesting one that I came across while touring universities to find one that I liked. A parent at one of the Q&A sessions asked what the difference was between Computing and IT (in a UK education context). The degree director replied that an IT course is like learning to drive a car, whereas Computing is like learning to be a mechanic.
(Context: IT classes pre-university used to consist of learning to use Word, Excel and Powerpoint.)
So I suppose whether the analogy works depends whether you want your programmer to find and plug a hole in your exhaust pipe, or to work out how to make a more efficient catalytic converter.
Maybe it's because I just made the egregious mistake of getting drawn into a gun-control debate with a friend and his friends on Facebook, but hyperbolic arguments by analogy feel really silly, cheap, and disingenuous to me right now...
I find that analogies are a poor argumentation technique overall, even if they are not hyperbolic. It's always possible to find similarities between wildly different and even opposing ideas. The details matter.
I find analogies very good for explaining concepts (to make the details easier to understand), but absolutely horrible for debates. Analogies generally over simplify issues, and hackers are particularly bad at arguing the analogy to an absurd extent instead of arguing the main premise behind it. It happens here all the time.
It seems like this example helps highlight the absurdity of requiring experience in $Language for $Years (or other similar too-constrained metrics) when an Able Programmer can just learn that stuff. The general populace views what we do as magic, but understands being able to drive very well. This effectively says that programming is a general skill, and that a good programmer should be able to learn it if they already know something similar. So, your Visual Studio 2012-only shop can hire people w/ 15 years of embedded C experience, and probably get a pretty solid programmer.
We all seem to consider this as true about being a Good Programmer ("Sure, I can learn $language_that_you_use"), but are frustrated by HR departments who don't realize it.
For hiring Excellent Programmer, it is true. For hiring Average Programmer, experience matters a lot - average programmers become proficient slower than excellent ones, so it is better to hire somebody that has already passed most of the learning curve. OTOH, hiring by tool usually doesn't make any sense unless this tool has really steep learning curve (in which case why use it anyway? yes, I know there are exceptions, but generally it's true).
Analogies, if constructed carefully, have a limited use in explaining concepts. The more closely the analogized items resemble each-other, the longer you can hold onto the analogy. To really understand something, you can't be using analogies.
This analogy can hold together for half a sentence at most. The concerns involved in hiring a programmer and selecting a customer to rent cars to have almost nothing in common.
And if you want to use an analogy in an argument, you first have to argue that the analogy is valid.
Articles like this contribute nothing to my understanding of hiring.
Analogies aren't an argumentation technique at all. Analogies are only useful for explaining stuff. They are utterly useless for forming an argument, despite what many people would like to think.
Absolutely correct. I was thinking of things along the lines of "use JDK 1.2, which still lets you turn off the garbage collector, and then spend 100% of your time after startup in a JNI module." That's the least scary version.
From an interviewer's perspective, that answer wouldn't really help me gauge your familiarity and depth of understanding with regards to the JVM (which is, presumably, something I'd be very interested in knowing).
This analogy is backwards... Hiring a programmer is an exchange of company money (or equity, benefits, etc) for a service (programming skills). Renting a car is an exchange of one's own money for a service (use of the car).
In this case, the person renting the car would be "interviewing" the car rental company to determine if their service is worth their money.
That, and cars are interchangeable standardized goods. Programmers vary widely in ability. The process's closest analogy is buying a home. You want to take a walk through, compare multiple properties, get an inspection report, have everything tidy legal-wise, etc.
true but i would hope we all know what hes getting at. And by the way its hilarious because anyone who has been a contractor and gone through a staffing firm knows EXACTLY that same situation
Maybe this is me having spent too much time thinking about econ, but I don't get why the analogy is backwards here. What is special about the person spending money? A car rental company is filling a large number of slots, and the renter would like to fill one. Why is that not as natural an analogy point for you?
Instead of "whoever is giving up money should do the due diligence," I would suggest you consider "both sides should do increasing due diligence as the importance of a decision increases."
From this perspective, the article is pointing out the dumbness of some due diligence methods currently being used at software companies.
Because car rental companies exist to provide a service to the people who walk into them, so we walk in expecting to be served, providing we can pay. It's a simple transaction; they get money, you get use of a car. Everyone is happy. If they start giving you the third degree, you'll be inclined to respond, "Geez, do they want my money or not?".
To walk into a job interview with the same expectation of being "served" is ridiculous. It's true that if they're smart, they will try to entice you and provide a nice experience, but primarily they are trying to decide whether to spend large amounts of time and money on you versus someone else. Most companies are not in the business of quickly and efficiently hiring as many people off the street as possible. You can be flustered by an interviewer's poor technique, but don't be impatient to receive the job offer you feel entitled to.
>> In this case, the person renting the car would be "interviewing" the car rental company to determine if their service is worth their money.
It goes both ways... the rental car agency interviews the person to make sure she is trustworthy of driving the car. The author is asking you to think about the relationship a little more abstractly than simply who is giving money to whom.
Having said, that, I think this is a poor analogy because I don't find it particularly illuminating and the situations just don't seem very... analogous.
Something like "if interviewing carpenters was like interviewing programmers" would work, with various questions regarding trivia about the Mightyman Bansaw 3000, specific experience using square-faced carbon tipped reverse-threaded screws and comparisons between building red versus white cabinets.
The analogy is backwards if it is a direct hire by the company. The article used an agency, which gets money from the hiring company for placing the candidate. If you look it at like that then the programmer is the car and the hiring company is the driver.
Maybe applicants need insurance. If they don't work out, their insurance company refunds the employer their salary and the opportunity cost of their bad commits. This way, applicants get muscled out of the job market gradually by high insurance rates, rather than with a brick wall filter.
That's not a bad idea at all. But it's unlikely to be very useful for specialized work, unless the insurance is highly specialized, and in that case it is likely to be as expensive as malpractice insurance.
I think it's funny when the recruiters try and lie at the beginning by saying a later interviewer may or may not be out sick and there is the possibility for some interviews to be cancelled and the day cut short. We all know they want to send you home if you screw up in the beginning. It's not a secret.
My own personal, small sample size experience has shown that if I start questioning things early on in the interview, I can predict fairly well whether or not the company will be a good fit or not. I try not to jump to conclusions but even initial emails and phone calls can make for pretty strong clues.
If I sense during an interview that things aren't going to be a good fit, I still try and finish the interview graciously. There is no use burning any bridge, even if it's one you're 100% certain you'll never use. One trick I do to keep myself from seeming aloof or displeased is to start asking questions about the industry. At this point, I know I don't want the job and probably don't care about the culture, but learning something about an industry you may not know much about could be useful down the line.
The poor interview process is one thing, but what irks me most is that almost nobody offers you a chance to meet the team, even when they make you an offer. That's been my general experience so far anyway. It sucks, because your only exposure to anyone was the hiring manager, and maybe a lead, and all they did was ask questions about what you memorized about whatever language(s).
Friendly advice ... don't settle for an offer, make a request. The team is too important in helping determine if you'll be happy working at a given company.
When I'm interviewed, I take it as a bad sign if I'm not allowed to meet other members of the team. Typically they're included in interviews, in which case it's a non-issue. In other cases, I make a friendly request to meet 2-3 members of the team for a short conversation. I've only had to do that once though.
That's definitely what I should be doing. Usually though, I've gone through 2 or 3 interviews already for this position, one of many I am interviewing for, and I'm tired and want to be done with it all. The last round, one 1 company sat me down in front of their team, and that's the job I took, because the team seemed cool and I enjoyed that part of the process a lot.
It's just surprising that this is consistently a problem. I shouldn't have to make the extra effort, it should be part of the process.
My pet peeve is that you are interviewed as though you should be God, and you would be so lucky and privileged to work on this pristine, perfect codebase...only to find out that the codebase is not all that perfect, and the development processes are not scrum or agile or XP, but instead "run around like chicken with your head cut off, just get it done!"
Perhaps this is the queue for someone to suggest "that's why we try so hard to prevent bad people from getting hired". :-)
I hate those interviews and interviewees that have that attitude too. Especially since the opposite is actually the case. It's so incredibly easy to find work as a developer right now, you need to tell me why I should come work for you. Remind me why I'm sitting here talking to you instead of somewhere else that could be more exciting.
That's odd; at every tech company where I've interviewed, the majority of the interviewers were potential peers on the team (or from another team, to have an "outside voice"). The hiring manager is usually mainly there to judge culture fit and, if they like you, to help sell the company.
At the companies where I've worked and have interviewed people, the hiring manager would of course have veto power, but would never hire someone without the agreement of the team.
At my current company (Twilio), even the first phone screen (after a possible initial recruiter call) is done by a team lead or member of the team. But often the candidate doesn't end up on the same team as the phone screener, since we don't always know what team would be the best fit until after the screen.
I think of hiring as everyone's job, as it's right up at the top of the list of things that will determine the course of company culture over time.
(Shameless plug: having said all that, if you're an Android developer who enjoys building frameworks and APIs, email me at my HN username at twilio.com.)
> I think of hiring as everyone's job, as it's right up at the top of the list of things that will determine the course of company culture over time.
That's what bothers me so much about it. The team and the culture is hugely important. I appreciate that the interviewer has determined culture fit, and that's fine I guess, but I want to know that I'll like the team I'll be working with too.
Sure. It goes both ways. As the interviewee, it's your job to ask your interviewer questions that will help you learn whether or not you'll like the team.
Well, if you buy instead of rent, especially used car, that's what 99.99% of salesmen would do. "How much is that car?" - "well, how much can you pay?" They have sometimes prices posted but everybody knows these have little meaning except generic signal of "we consider it an expensive car" or "this one is cheap".
Interviewer#3: How long you been driving your 2010 Escort?
Applicant: About 3 years.
Interviewer#3: Sorry, but we are looking for someone with
experience of driving 2010 Escort for at
least 10 years.
Interviewer#3: We are looking for someone who knows how
operate the navigation screen on the 2010 Escort.
Applicant: My car does not have the navigation option
installed.
Interviewer: Then you do not qualify. Knowing how to
work the navigation system is a priority.
Applicant: I know how to work navigation systems in
general. My car before this one had a navigation system
and I learned it pretty quickly.
Interviewer#3: No. We need people with 10 years of
experience with the actual navigation system on the 2010
Escort.
Note: Ford no longer sells the Escort in the USA. They sell the Focus and the Fiesta. Both terrific little cars.
Interviewer#3: We are willing to accept 8 years of education with a Master's or equivalent on the subject of 2010 Escort navigation systems in lieu of 10 years driving experience, for otherwise qualified candidates
Completely off-topic response to your note, but I loved my 2000 Focus and I was almost sad to sell it. It went through air intake hoses on the transmission about as fast as it did gasoline (hyperbole, but the Arizona heat was hell on that little rubber elbow. Fixing it took 5 minutes and cost $3 once a year, though, so as far as chronic car problems went it was pretty mild). It was still running strong after 12 years, and got my wife from Tucson to Seattle as safe as could be :3
> got my wife from Tucson to Seattle as safe as could be
It's a lot safer, I would have thought, per mile to do long highway drives than lots of short urban journeys, particularly on the separated highways in the USA.
I was witness to the sending of a request for candidates with 3 years of Android experience to HR at 2011 at Intel. They just insisted that two or one isn't enough.
First Android phones were release at 2008.
In other news - I thank god I never were in as bad as interviews as some of you. My worst experience was the interviewer giving up and starting to ask me personal and professional stuff about another candidate to the same position. I guess I did a good job because the other candidate got it, company shutdown withing a year.
"E se me nona gavesse e rode sarìa na carioea", as they say here in the Veneto, which, literally translated, means "if my grandmother had wheels, she'd be be a wheelbarrow".
The literal translation is pretty clear, actually. If [something ridiculous/impossible] then [something else ridiculous/impossible]. In other words the comparison is a bit of a stretch.
Better analogy would be shipping company hiring a truck driver and asking him those questions. And also requiring experience piloting Formula One cars for at least three years, knowledge of how to operate large construction equipment and ability to replace the tire on a truck with bare hands.
I became unreasonably angry while reading this. I guess it struck a nerve with me for some reason.
During my interviews, I was very charismatic, confident in my skills, was asked technical question that were things I would need day in day out. I landed the job on 100% of those interviews.
There was this one time were the guy kept asking me crap I would never EVER need while working for his company.
Binary tree's, linked lists, pointer arithmatic. "What the fuck?", I thought to myself. This was for a C# developer position for a small 20 person company. Anyways, I thanked him for his time and left. He called me with an offer two weeks later, and I declined. Not going to waste my time with that crap.
---
99% of us will never work for Google, or Amazon, or Twitter - but for your run of the mill software shops. And that's ok.
I'm actually insanely jealous of you if a "What the fuck" interview was about binary trees and linked lists. All my interviews have /started/ at that point and gotten way worse. I still get anxiety thinking about some of my job interviews.
Don't want to throw anyone under the bus, many of them are actually YC funded! I respect the companies a lot, but their interviews are incredibly stressful.
I don't disagree with your decision to leave, but it is possible that your interviewer was just a crappy interviewer and might not be a crappy colleague.
Out of curiosity, why do you consider binary trees, linked lists, and pointer arithmetic to be so out of the bounds of possibility for work at a job? Those strike me as skills I might find invaluable in one of my software engineers depending on the job.
While I can't speak for the OP, in that situation, I would take this to mean that they aren't sure of the skills they actually need so they're asking general questions that may or may not reveal whether or not we (the company and myself) are a good match.
Granted, if they ask a few of those and then jump right in with more specific questions I would just count that as the qualifier/anti-BS filter.
If I was only given general softball 100 series CS course questions I'd probably end up trying to wrestle more info about the position out of the interviewer unless I was really hard up for a job and was willing to put up with potentially unfulfilling work for a while.
Let me offer an explanation: maybe the job he was applying for asked for knowledge and experience in Java, Spring, Hibernate, Grails, Javascript, SQL, CSS, writing stored procs with PL/SQL, performance tuning, node.js, and Git...and the binary trees/linked lists portion only pertains to Java (and maybe Javascript?). More specifically, maybe the guy just hasn't had the need, for whatever reason, to use a binary tree or a linked list recently. I doubt he runs around saying "it's April, I haven't used a TreeMap in a while, let me use one now so it's fresh in my mind for next year's interview".
The point I'm trying to make is that some requirements are very, very wide/broad. And then they'll take one piece of that broad pie and decide to go very, very deep.
And then there's the death knell...you spent time developing deep expertise in something no longer actively used. This applies more to frameworks than languages (i.e. Struts, Prototype, Dojo, etc.)
You probably won't be doing pointer arithmetic in C#. It's been about 5 years since I wrote any C#, but I don't remember any... mostly I remember it as a Java clone, which would preclude pointer arithmetic.
The only time I've ever used them is to speed up drawing. Bitmap.SetPixel is super slow compared to taking a pointer to the raw image data and writing there directly.
I'd be inclined to side with the interviewer on this one. Data structures such as binary trees and linked lists may be abstracted away by many modern frameworks, but every abstraction is leaky and if you aren't aware of what's going on behind the scenes, you can absolutely crucify your application's performance. Binary trees, linked lists, hashtables and so on have very different performance characteristics, and if you choose the wrong one for the wrong situation, you can end up with code that gets unbearably slow surprisingly quickly. The difference between O(n^2), O(n) and O(log n) can be massive on datasets of only a few thousand, and even small 20 person companies can end up having to deal with datasets much larger than that.
This is all fairly basic stuff that should be a core competency for every software developer, and the fact that it isn't is the reason why so many Flash- and JavaScript-intensive websites are such resource hogs. The kind of things that Google, Amazon and Twitter are into that you'll never EVER need in a small 20 person run of the mill software shop are things such as machine learning, compiler theory, Bayesian statistics, image recognition, and so on.
Now, maybe I've gotten lucky, and I've only interviewed at a few companies (well-known ones include: Google, Amazon, Facebook), but I've never had an experience as bad as that painted by this analogy.
In general, the interview questions I've gotten are designed to test general CS knowledge and the ability to translate an algorithm into code. This is important, and as an interviewer myself, a lot of candidates fail at the translating to code step.
Design questions are (at a high level) maybe even closer to "how would you do your job?" than coding questions.
I have yet to see a company ask for specific experience with VB.net 2012 edition and exclude candidates like myself who are only familiar with C/Python/Java. If they do, I'd recommend straight out lying (for languages). You can pick languages up really quickly. For platforms, maybe you really should know it and it is actually relevant to your potential job.
If the job you are applying for is to work on a rails site or develop a mobile app, I would argue that it is pretty important that you are already familiar with those technologies (and their pitfalls)…
I wouldn't exclude someone unfamiliar with a specific framework, but as an employer you understand that ramping them up to speed is going to take a significant amount of time.
I have yet to see a company ask for specific experience with VB.net 2012 edition and exclude candidates like myself who are only familiar with C/Python/Java
I've absolutely seen it, but I've stopped looking at it as an injustice that must be mocked, but rather a useful indicator of an organization that isn't a good fit for what I have to bring. If the economy were worse, I may have a different perspective.
I've given enough interviews to know it's all relative.
To cherry pick one example: "What color has the middle wire feeding into the distributer cap?" implies interviewers ask ridiculously specific questions that you could "look up if and when you needed to know."
The problem is for some applicants that question could be "how would you implement Google's PageRank" and for other applicants it can be something as simple as "what's the difference between an interface and an abstract class." Think what you want but if you don't think you need to be able to answer the latter, it's probably not going to work out between us.
To be honest, of the few interviews where I've been the applicant, the questions have always been fair and I've never been treated with the level of disrespect that was demonstrated in this scenario. That said, I'm completely willing to believe I've just been lucky so far.
The problem I perceive is that that question gets asked to people who will never need to know it. I too often see people interviewing for front end web or javascript positions asked questions about binary search trees or something that totally doesn't relate to front end development, instead of asking about closures or what they think about coffeescript. Honestly, I think at this point if you're asking about various search algorithm big o timings to find out if a programmer can build an iOS app or do Rails dev, you're doing it wrong.
176 comments
[ 3.5 ms ] story [ 188 ms ] threadJust like having a drivers license is no guarantee you are a good driver, having many years of job experience programming is no guarantee you are a programmer.
On the other hand, you are liable for any damage you do to a car you rent, plus the company is fully insured in the case you do any damage and can't pay. Hiring and firing someone (which is the only real way to know if someone is a good developer) is very expensive.
Here's what it would be like if we hired programmers like we rent cars:
You walk in to a software company and are immediately hired under these conditions: "We'll take you on for 6 months, but if it doesn't work out you need to pay us back all of your salary, plus benefits and payroll tax"
He's not saying "don't find a good programmer." He's saying that the questions they ask get them no closer to finding out whether he is a good programmer.
A lot of the time they're not meant to. They're meant to figure out whether he's a bad programmer (or bad cultural fit, or something else bad).
The cost of hiring someone bad is way higher than most people would guess. I've come to believe that in many cases the questions asked in an interview almost don't matter - they're just there to give you an opportunity to fail, or to say something incredibly dumb or ignorant or obnoxious so that the interviewer can quickly reject you and avoid an expensive mistake.
The real world problem is that too many interviews follow the model because that's what they know from past experience themselves. They may not know why they ask such baseless questions, all they know is the answer they want and damn you if you don't give it to them.
I think in the end its a balance of basic filtering vs. HR requirements. The process has to be objective and quantifiable so they're covered in the event of anyone calling foul play. Everyone gets the same treatment and there is a paper trail of reasons for why they turned you down.
However, most companies are smaller than Google and Amazon and have different practices. Sometimes, stupid practices, because the interviewers don't really know how to do it, just want to get it over with, or really care about things which aren't important.
But since they are in the hiring position and assume they and their company are awesome, they are not so likely to question their own technical or interviewing abilities and certainly don't want to hear what interviewees have to say about it.
You need additional insights beyond just doing the job to understand what makes someone else useful in that job. And if you don't even have that much, you are guaranteed to ask stupid questions and end up with people selected for how good they are at selling and how much you think they're cool.
For future interviews, I've collected similar questions to ask of them (questions that I have conveniently worked out or looked up the answer to beforehand), my rationale being, "I want to make sure I would be working with competent peers." And I don't give a fuck if it rubs them the wrong way.
Some say that his not only the man-in-the-middle, he's at both ends and has wiretaps on Alice, Bob, Carol and Dave. and that he once crashed a 10 way IBM sysplex by staring at at it all we know is hes the stigs nerdy cousin.
I don't think every Java Coder would be able to tell how the internal mechanics of Java work. They aren't Java mechanics, they're just driving Java.
If you were using the photoshop analogy, then I think to interview someone, you need to ask them how different features of Photoshop work, not how Photoshop was built but also not how they draw in general, IMO. You may be a great artist, but if you can't understand Photoshop features and what they mean you will fail to create a great digital painting.
We all seem to consider this as true about being a Good Programmer ("Sure, I can learn $language_that_you_use"), but are frustrated by HR departments who don't realize it.
(This being an example of course)
This analogy can hold together for half a sentence at most. The concerns involved in hiring a programmer and selecting a customer to rent cars to have almost nothing in common.
And if you want to use an analogy in an argument, you first have to argue that the analogy is valid.
Articles like this contribute nothing to my understanding of hiring.
Like - can you land Curiosity with off the shelf java and JVM? Why or why not?
In this case, the person renting the car would be "interviewing" the car rental company to determine if their service is worth their money.
Instead of "whoever is giving up money should do the due diligence," I would suggest you consider "both sides should do increasing due diligence as the importance of a decision increases."
From this perspective, the article is pointing out the dumbness of some due diligence methods currently being used at software companies.
To walk into a job interview with the same expectation of being "served" is ridiculous. It's true that if they're smart, they will try to entice you and provide a nice experience, but primarily they are trying to decide whether to spend large amounts of time and money on you versus someone else. Most companies are not in the business of quickly and efficiently hiring as many people off the street as possible. You can be flustered by an interviewer's poor technique, but don't be impatient to receive the job offer you feel entitled to.
It goes both ways... the rental car agency interviews the person to make sure she is trustworthy of driving the car. The author is asking you to think about the relationship a little more abstractly than simply who is giving money to whom.
Having said, that, I think this is a poor analogy because I don't find it particularly illuminating and the situations just don't seem very... analogous.
If Carpenters Were Hired Like Programmers
I think it's funny when the recruiters try and lie at the beginning by saying a later interviewer may or may not be out sick and there is the possibility for some interviews to be cancelled and the day cut short. We all know they want to send you home if you screw up in the beginning. It's not a secret.
If I sense during an interview that things aren't going to be a good fit, I still try and finish the interview graciously. There is no use burning any bridge, even if it's one you're 100% certain you'll never use. One trick I do to keep myself from seeming aloof or displeased is to start asking questions about the industry. At this point, I know I don't want the job and probably don't care about the culture, but learning something about an industry you may not know much about could be useful down the line.
When I'm interviewed, I take it as a bad sign if I'm not allowed to meet other members of the team. Typically they're included in interviews, in which case it's a non-issue. In other cases, I make a friendly request to meet 2-3 members of the team for a short conversation. I've only had to do that once though.
It's just surprising that this is consistently a problem. I shouldn't have to make the extra effort, it should be part of the process.
Perhaps this is the queue for someone to suggest "that's why we try so hard to prevent bad people from getting hired". :-)
I hate those interviews and interviewees that have that attitude too. Especially since the opposite is actually the case. It's so incredibly easy to find work as a developer right now, you need to tell me why I should come work for you. Remind me why I'm sitting here talking to you instead of somewhere else that could be more exciting.
At the companies where I've worked and have interviewed people, the hiring manager would of course have veto power, but would never hire someone without the agreement of the team.
At my current company (Twilio), even the first phone screen (after a possible initial recruiter call) is done by a team lead or member of the team. But often the candidate doesn't end up on the same team as the phone screener, since we don't always know what team would be the best fit until after the screen.
I think of hiring as everyone's job, as it's right up at the top of the list of things that will determine the course of company culture over time.
(Shameless plug: having said all that, if you're an Android developer who enjoys building frameworks and APIs, email me at my HN username at twilio.com.)
That's what bothers me so much about it. The team and the culture is hugely important. I appreciate that the interviewer has determined culture fit, and that's fine I guess, but I want to know that I'll like the team I'll be working with too.
The underling problem is very true though.
Agency : How much did you pay for your last rental car?
Applicant : I don't see how that matters. What are you charging?
Agency : We like to know what you paid before so you get a fair rate.
Applicant : I paid market rates.
Agency : Sorry, we must know how much...
To add:
Note: Ford no longer sells the Escort in the USA. They sell the Focus and the Fiesta. Both terrific little cars.Completely off-topic response to your note, but I loved my 2000 Focus and I was almost sad to sell it. It went through air intake hoses on the transmission about as fast as it did gasoline (hyperbole, but the Arizona heat was hell on that little rubber elbow. Fixing it took 5 minutes and cost $3 once a year, though, so as far as chronic car problems went it was pretty mild). It was still running strong after 12 years, and got my wife from Tucson to Seattle as safe as could be :3
(Also you might want to edit your comment, it's ended up all on one line)
First Android phones were release at 2008.
In other news - I thank god I never were in as bad as interviews as some of you. My worst experience was the interviewer giving up and starting to ask me personal and professional stuff about another candidate to the same position. I guess I did a good job because the other candidate got it, company shutdown withing a year.
During my interviews, I was very charismatic, confident in my skills, was asked technical question that were things I would need day in day out. I landed the job on 100% of those interviews.
There was this one time were the guy kept asking me crap I would never EVER need while working for his company.
Binary tree's, linked lists, pointer arithmatic. "What the fuck?", I thought to myself. This was for a C# developer position for a small 20 person company. Anyways, I thanked him for his time and left. He called me with an offer two weeks later, and I declined. Not going to waste my time with that crap.
---
99% of us will never work for Google, or Amazon, or Twitter - but for your run of the mill software shops. And that's ok.
Granted, if they ask a few of those and then jump right in with more specific questions I would just count that as the qualifier/anti-BS filter.
If I was only given general softball 100 series CS course questions I'd probably end up trying to wrestle more info about the position out of the interviewer unless I was really hard up for a job and was willing to put up with potentially unfulfilling work for a while.
Edit: Grammar
I think you kind of answered the question yourself. ;)
The point I'm trying to make is that some requirements are very, very wide/broad. And then they'll take one piece of that broad pie and decide to go very, very deep.
And then there's the death knell...you spent time developing deep expertise in something no longer actively used. This applies more to frameworks than languages (i.e. Struts, Prototype, Dojo, etc.)
It's a no-win situation all around.
This analogy is proving more accurate as I read thru the comments.
This is all fairly basic stuff that should be a core competency for every software developer, and the fact that it isn't is the reason why so many Flash- and JavaScript-intensive websites are such resource hogs. The kind of things that Google, Amazon and Twitter are into that you'll never EVER need in a small 20 person run of the mill software shop are things such as machine learning, compiler theory, Bayesian statistics, image recognition, and so on.
In general, the interview questions I've gotten are designed to test general CS knowledge and the ability to translate an algorithm into code. This is important, and as an interviewer myself, a lot of candidates fail at the translating to code step.
Design questions are (at a high level) maybe even closer to "how would you do your job?" than coding questions.
I have yet to see a company ask for specific experience with VB.net 2012 edition and exclude candidates like myself who are only familiar with C/Python/Java. If they do, I'd recommend straight out lying (for languages). You can pick languages up really quickly. For platforms, maybe you really should know it and it is actually relevant to your potential job.
I wouldn't exclude someone unfamiliar with a specific framework, but as an employer you understand that ramping them up to speed is going to take a significant amount of time.
I've absolutely seen it, but I've stopped looking at it as an injustice that must be mocked, but rather a useful indicator of an organization that isn't a good fit for what I have to bring. If the economy were worse, I may have a different perspective.
To cherry pick one example: "What color has the middle wire feeding into the distributer cap?" implies interviewers ask ridiculously specific questions that you could "look up if and when you needed to know."
The problem is for some applicants that question could be "how would you implement Google's PageRank" and for other applicants it can be something as simple as "what's the difference between an interface and an abstract class." Think what you want but if you don't think you need to be able to answer the latter, it's probably not going to work out between us.
To be honest, of the few interviews where I've been the applicant, the questions have always been fair and I've never been treated with the level of disrespect that was demonstrated in this scenario. That said, I'm completely willing to believe I've just been lucky so far.