What If Cars Were Rented Like We Hire Programmers?

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).<p>In this case, the person renting the car would be "interviewing" the car rental company to determine if their service is worth their money.

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

<p><pre><code> 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.</code></pre>

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

This part was golden:<p>Agency : How much did you pay for your last rental car?<p>Applicant : I don't see how that matters. What are you charging?<p>Agency : We like to know what you paid before so you get a fair rate.<p>Applicant : I paid market rates.<p>Agency : Sorry, we must know how much...

I've had a few interviews like this.<p>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.

I became unreasonably angry while reading this. I guess it struck a nerve with me for some reason.<p>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.<p>There was this one time were the guy kept asking me crap I would never EVER need while working for his company.<p>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.<p>---<p>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.

As a hiring manager, the thing I find most interesting on posts like this (ignoring that the analogy is TERRIBLE) are the comments of people used to being on the other side of the desk. I don't think we (as interviewers) do a good job of explaining why we ask the questions we ask. And I don't think we do a good job of communicating what our job is.<p>Our job is to stop you getting hired.<p>If we get 100 people applying for the job, then our job is to not employ at least 99. So we are looking for anything that identifies you as being one of the 99.<p>That you could go away and learn what color the middle wire is is great. But the guy next to you has been fixing wiring in distributor caps for years. And right now, I need people that know what color the middle wire is.

This makes no sense.<p>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.<p>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.<p>Here's what it would be like if we hired programmers like we rent cars:<p>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"

I've given enough interviews to know it's all relative.<p>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."<p>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.<p>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 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).

It's very easy to decry company hiring procedures. That happens all the time here on HN, and for a very good reason--most company hiring procedures are not based on research and are demonstrably suboptimal for hiring the best people. We discuss this a lot on Hacker News because many of us have been looking for jobs or looking for people to hire some time in our adult lives. From participants in earlier discussions I have learned about many useful references on the subject, which I have gathered here in a FAQ file. The review article by Frank L. Schmidt and John E. Hunter, "The Validity and Utility of Selection Models in Personnel Psychology: Practical and Theoretical Implications of 85 Years of Research Findings," Psychological Bulletin, Vol. 124, No. 2, 262-274<p><a href="http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf" rel="nofollow">http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...</a><p>sums up, current to 1998, a meta-analysis of much of the HUGE peer-reviewed professional literature on the industrial and organizational psychology devoted to business hiring procedures. There are many kinds of hiring criteria, such as in-person interviews, telephone interviews, resume reviews for job experience, checks for academic credentials, personality tests, and so on. There is much published study research on how job applicants perform after they are hired in a wide variety of occupations.<p><a href="http://www.siop.org/workplace/employment%20testing/testtypes.aspx" rel="nofollow">http://www.siop.org/workplace/employment%20testing/testtypes...</a><p>EXECUTIVE SUMMARY: If you are hiring for any kind of job in the United States, prefer a work-sample test as your hiring procedure. If you are hiring in most other parts of the world, use a work-sample test in combination with a general mental ability test.<p>The overall summary of the industrial psychology research in reliable secondary sources is that two kinds of job screening procedures work reasonably well. One is a general mental ability (GMA) test (an IQ-like test, such as the Wonderlic personnel screening test). Another is a work-sample test, where the applicant does an actual task or group of tasks like what the applicant will do on the job if hired. (But the calculated validity of each of the two best kinds of procedures, standing alone, is only 0.54 for work sample tests and 0.51 for general mental ability tests.) Each of these kinds of tests has about the same validity in screening applicants for jobs, with the general mental ability test better predicting success for applicants who will be trained into a new job. Neither is perfect (both miss some good performers on the job, and select some bad performers on the job), but both are better than any other single-factor hiring procedure that has been tested in rigorous research, across a wide variety of occupations. So if you are hiring for your company, it's a good idea to think about how to build a work-sample test into all of your hiring processes.<p>Because of a Supreme Court decision in the United States (the decision does not apply in other countries, which have different statutes about employment), it is legally risky to give job applicants general mental ability tests such as a straight-up IQ test (as was commonplace in my parents' generation) as a routine part of hiring procedures. The Griggs v. Duke Power, 401 U.S. 424 (1971) case<p><a href="http://scholar.google.com/scholar_case?case=8655598674229196978&#38;q=Griggs+Duke+Power&#38;hl=en&#38;as_sdt=2,24" rel="nofollow">http://scholar.google.com/scholar_case?case=8655598674229196...</a><p>interpreted a federal statute about employment discrimination and held that a general intelligence test used in hiring that could have a "disparate impact" on applicants of some protected classes must "bear a demonstrable relationship to successful performance of the jobs for which it was used." In other words, a company that wants to use a test like the Wonderlic, or like the SAT, or like the current WAIS or Stanford-Binet IQ tests, in a hiring procedure had best conduct a specific validation study of the test related to performance on the job in question. Some companies do the validation study, and use IQ-like tests in hiring. Other companies use IQ-like tests in hiring and hope that no one sues (which is not what I would advise any company). Note that a brain-teaser-type test used in a hiring procedure could be challenged as illegal if it can be shown to have disparate impact on some job applicants. A company defending a brain-teaser test for hiring would have to defend it by showing it is supported by a validation study demonstrating that the test is related to successful performance on the job. Such validation studies can be quite expensive. (Companies outside the United States are regulated by different laws. One other big difference between the United States and other countries is the relative ease with which workers may be fired in the United States, allowing companies to correct hiring mistakes by terminating the employment of the workers they hired mistakenly. The more legal protections a worker has from being fired, the more reluctant companies will be about hiring in the first place.)<p>The social background to the legal environment in the United States is explained in many books about hiring procedures<p><a href="http://books.google.com/books?hl=en&#38;lr=&#38;id=SRv-GZkw6TEC&#38;oi=fnd&#38;pg=PA271&#38;dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology&#38;ots=iCXkgXrlOV&#38;sig=ctblj9SW2Dth7TceaFSNIdVMoEw#v=onepage&#38;q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology&#38;f=false" rel="nofollow">http://books.google.com/books?hl=en&#38;lr=&#38;id=SRv-GZkw6...</a><p><a href="http://books.google.com/books?hl=en&#38;lr=&#38;id=SRv-GZkw6TEC&#38;oi=fnd&#38;pg=PA95&#38;dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology&#38;ots=iCXkgXrnMW&#38;sig=LKLi-deKtnP20VYZo9x0jfvqzLI#v=onepage&#38;q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology&#38;f=false" rel="nofollow">http://books.google.com/books?hl=en&#38;lr=&#38;id=SRv-GZkw6...</a><p>Some of the social background appears to be changing in the most recent few decades, with the prospect for further changes.<p><a href="http://intl-pss.sagepub.com/content/17/10/913.full" rel="nofollow">http://intl-pss.sagepub.com/content/17/10/913.full</a><p><a href="http://www.economics.harvard.edu/faculty/fryer/files/Fryer_Racial_Inequality.pdf" rel="nofollow">http://www.economics.harvard.edu/faculty/fryer/files/Fryer_R...</a><p><a href="http://books.google.com/books?hl=en&#38;lr=&#38;id=frfUB3GWlMYC&#38;oi=fnd&#38;pg=PA9&#38;dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology+%22predictive+validity%22+Duke+Power&#38;ots=5O9Hx_E1vY&#38;sig=g-zERWztBWq3h4guEuv9VVkTh8I#v=onepage&#38;q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology%20%22predictive%20validity%22%20Duke%20Power&#38;f=false" rel="nofollow">http://books.google.com/books?hl=en&#38;lr=&#38;id=frfUB3GWl...</a><p>Previous discussion on HN pointed out that the Schmidt &#38; Hunter (1998) article showed that multi-factor procedures work better than single-factor procedures, a summary of that article we can find in the current professional literature, for example "Reasons for being selective when choosing personnel selection procedures" (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias Berchtold, and Martin Kleinmann:<p>"Choosing personnel selection procedures could be so simple: Grab your copy of Schmidt and Hunter (1998) and read their Table 1 (again). This should remind you to use a general mental ability (GMA) test in combination with an integrity test, a structured interview, a work sample test, and/or a conscientiousness measure."<p><a href="http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/preprint_j.1468_2389.2010.00485.x.pdf" rel="nofollow">http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/prepri...</a><p>But the 2010 article notes, looking at actual practice of companies around the world, "However, this idea does not seem to capture what is actually happening in organizations, as practitioners worldwide often use procedures with low predictive validity and regularly ignore procedures that are more valid (e.g., Di Milia, 2004; Lievens &#38; De Paepe, 2004; Ryan, McFarland, Baron, &#38; Page, 1999; Scholarios &#38; Lockyer, 1999; Schuler, Hell, Trapmann, Schaar, &#38; Boramir, 2007; Taylor, Keelty, &#38; McDonnell, 2002). For example, the highly valid work sample tests are hardly used in the US, and the potentially rather useless procedure of graphology (Dean, 1992; Neter &#38; Ben-Shakhar, 1989) is applied somewhere between occasionally and often in France (Ryan et al., 1999). In Germany, the use of GMA tests is reported to be low and to be decreasing (i.e., only 30% of the companies surveyed by Schuler et al., 2007, now use them)."<p>Integrity tests have limited validity standing alone, but appear to have significant incremental validity when added to a general mental ability test or work-sample test.<p><a href="http://en.wikipedia.org/wiki/Employment_integrity_testing" rel="nofollow">http://en.wikipedia.org/wiki/Employment_integrity_testing</a><p><a href="http://apps.opm.gov/ADT/Content.aspx?page=3-06&#38;JScript=1" rel="nofollow">http://apps.opm.gov/ADT/Content.aspx?page=3-06&#38;JScript=1</a><p><a href="http://www.princeton.edu/~ota/disk2/1990/9042/9042.PDF" rel="nofollow">http://www.princeton.edu/~ota/disk2/1990/9042/9042.PDF</a><p><a href="http://www.hotelschool.cornell.edu/research/chr/pubs/reports/abstract-14602.html" rel="nofollow">http://www.hotelschool.cornell.edu/research/chr/pubs/reports...</a>

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.

Evidently other people must have been through the same types of interviews as I have.

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.

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?

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.

Ah yes, another person describing their Google interview experience. They do leave a lot of solid candidates out but in their defense, when I was there, being able to survive the non-intuitive interview process was a good indicator you could survive the non-intuitive business dynamics.<p>If didn't really crush people when they didn't get called back it would make it funny. Sort of like the Monty Python sketch <a href="http://www.youtube.com/watch?v=zP0sqRMzkwo" rel="nofollow">http://www.youtube.com/watch?v=zP0sqRMzkwo</a>

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

I have had this interview. I didn't get the job.

hehe, yeah, I've been through this several times.<p>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.

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.<p>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.<p>Design questions are (at a high level) maybe even closer to "how would you do your job?" than coding questions.<p>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.

The problem with this article (and nearly every attempt at analogous argumentation by anybody, ever) is that the writer cannot construct a homologous argument, which ultimately relegates the entire attempt to, at best, being mildly entertaining, but otherwise unhelpful. I've attempted many times to draw analogies in argument, but when your audience by and large shares the experience, they're useless. When attempting to dispute a point, or bring notice to something that you'd like to see changed, it's better to stick with homologous arguments and eschew analogies. Otherwise, you're just going to get mired down in quibbling over how the analogy doesn't hold, and completely sidetrack any attempts to discuss what you're really wanting to discuss.

What I think candidates tend to miss is some of the potential ulterior motives that employers have when asking esoteric questions or certain task requests. The list of what candidates label as 'inappropriate' for interviews has become longer, or perhaps candidates have simply become more vocal about it. I wrote another article in response to this, in order to outline why certain lines of questioning (esoteric, riddle, impossible, inane) may be used to try and learn something deeper about the candidate. Candidates need to understand that it isn't always just about your ability to answer a question. <a href="http://news.ycombinator.com/item?id=5073791" rel="nofollow">http://news.ycombinator.com/item?id=5073791</a>

This is absolutely spot on.

The only times I have been asked language specific questions are when I was selling myself as a language expert to fix some particular problem in some particular language.<p>I will however say that 90% of the interview questions I have been asked are heavily biased towards C type answers, although I did manage to use Scheme once!<p>Sure a linked list problems don't technically have to be written with pointers, but we all know what the interviewer is asking for.<p>Actually that brings up a good idea, I am going to come up with a bunch of contrived answers to the "find a loop in a linked list" problem, memorize them all, and next time someone asks me that question I'm going to give 5 weird answers in the course of 30 minutes.

I've been through a lot of hiring processes, on both sides of the desk, and I don't know what the article is trying to satirize. The worst, most bizarre hiring process I've ever been involved with bore no resemblance to anything in this little drama, and the analogy is bad. (My immediate reaction to the title was that car rental is based on what's available and how spiffy the car is (fairly rational) whereas programmer hiring is abased on jumping through hoops (e.g. Dumb C trick questions or programming challenges or certifications), who's available, and some weird perception of value almost guaranteed to be out of whack with reality.

It's funny in an absurd way. It is absurd because software technology grow significantly faster than car technology. Asking someone to write something with 1998 technology versus 2012 technology is different than asking someone to drive a 1998 model car and a 2012 model car.<p>It's true, if you have a solid foundation software, you <i>can</i> catch up to the 2012 platform. It will take some time.<p>So I think it is less that software changed so fast that solid programmers are unable to catch up so much that software changed so fast that recruiters have been unable to keep up.

I just had to interview people for a (non-tech) job who didn't even want it, and who we had no intention of hiring, because of our company's rules about how many people you have to interview before hiring. At least the hiring process described in the post has some sort of point, however badly executed.

What's with this "only Subaru" analogy? What I've found is more along these lines:<p>"Are you sure I'm qualified? I don't feel like I'd be very useful. I've never done Java, only C++ and JS and lisp" "No, you'll be perfect. We don't hire people for specific languages"

Question since I'm in the middle of interview sright now (I haven't experienced anything like this other than the last part of negotiations): how and what do you look for in terms of team and company for? for some reason in not sure myself.

Car analogies are usually bad. This one is worse.<p>The underling problem is very true though.

The author is confused.<p>1) While renting a car you are paying. 2) Interviews are for getting PAID.<p>It is buying versus selling.<p>The buyer will be cautious, try to get the best deal. The seller will be sweet, nice and somehow sell it.<p>So, we should ignore this post.

A similar analogy but from a different angle: <a href="http://blog.212labs.com/?p=53" rel="nofollow">http://blog.212labs.com/?p=53</a><p>I argue recruiters should act MORE like car salesmen =)

Related <a href="http://blog.jitbit.com/2011/05/what-if-drivers-were-hired-like.html" rel="nofollow">http://blog.jitbit.com/2011/05/what-if-drivers-were-hired-li...</a>

Hiring feels broken in many businesses, typically because it is executed by people who do not understand the target position, especially with technology. And, like the author tried to focus on, it doesn't help when the focus is far too heavily on a specific piece of the tech puzzle, and not on the overall talent and aptitude of the candidate her/himself.<p>I've both participated in and executed hiring processes in a mid-size (~500 emps) corporation where just about everyone wears ties or biz-casual (gross).<p>I sat in on one department's hiring rounds with about six candidates. What the dept was <i>looking for</i> was a programmer who had MS/.NET experience to develop on the MediaRoom platform (I managed the internal development team, hence my sitting in; responsibility for operating MediaRoom was under the other dept, however, so this candidate was not going to be able to be part of my team (stupid corporate organizational bullshit where dept mgrs squabble and scramble for stupid feelings of control and shit)). The questions the dept came up with and spent 1-2 hrs torturing the candidates with included <i>zero</i> questions about programming experience and aptitude-gauging type of inquiries. No questions about past projects, current interests, or anything remotely helpful. All the questions that were technical revolved around sysadmin tasks or how many damn acronyms the candidate was familiar with from MS's alphabet soup of platforms &#38; products--literally asking if the candidate knew what they meant, not if they understood purpose or anything else like that. For a fucking programming job. The position stayed open for a <i>year-and-a-half</i> without being filled.<p>Biggest problem I saw? The interview was designed by a guy with zero programming experience trying to hire a programmer. Why the questions he chose? Best I can tell, servers and sysadmin tasks were something his dept had long done, and something he semi-understood (but didn't do himself).<p>In contrast, when I ran hiring for my dept, I requested explicit permission to direct the interviews myself, instead of having them led by HR (though an HR rep was still there). Before setting up an interview, my team and I would meet the candidate for lunch just to get to know them a bit. It was sort of our version of testing- or phone-based screening processes. We could figure out more in an hour lunch that we could <i>trust</i> than automated tests or other devices.<p>After the first candidate's official interview, I heard HR was talking about it. By the second candidate's interview two days later, the SVP of HR sat in on the process with the other HR person who was always there. What was most interesting to HR, apparently, was that candidates didn't display any of the typical nervous behaviors that are so common. About 10 minutes in, we had them relaxed, talking and smiling and laughing like normal, discussing things they did in their free time to take a break from programming, talking about the projects they'd loved and hated the most--even talking about times they'd fucked up. That last bit was really fun to watch HR react to, as they hadn't ever experienced anyone talking about times they'd done something <i>wrong</i> in an interview.<p>There were no bullshit how-would-you-resolve-a-stupid-conflict-with-a-coworker questions. We asked some general tech and programming questions, shot the shit about open source projects that impressed the candidate. The focus, though, was on collaborative tasks where the entire dev team went through a couple exercises with the candidate as if s/he was part of the team already, letting the candidate lead, but basically serving as a normal team would--asking questions, raising objections, saying what a good idea or novel approach something was. It was a great way to get a feel for what it'd be like to work through a problem together.<p>By the time we'd interviewed 4 people, we'd already hired 2 of them and I had to push pretty hard to get a very competitive offer out immediately before finishing all the rounds. I nagged the hell out of them till they were willing to break their own rules of waiting till all interviews were done. Our positions did not stay open even one month before we hired three new people. But making them successful required a lot of effort on my part to plead and nag and bargain to get processes bent so we could pull it off.<p>Hiring feels broken in many businesses. But it doesn't have to be.<p><i>Disclaimer:</i> This was a mid-size company. I'm not saying that companies who receive hundreds or thousands of applicants can afford to take the time to do things this way. I can say that every interview that has ever meant a damn to me were the ones where the people interviewing actually took the time to be relaxed, get to know me a bit, and just make interviewing more like having a conversation. It's not coincidence that each one of those happened to be over coffee or lunch or somewhere away from a conference room and table as the first meeting.

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

This article rocked! Yes!! Todd should write movie scripts. I loved that.

Wow. Sure sounds like the author had some bad hiring experiences.

Terrible analogy...

Why no one asks questions that show deep understanding of the work and not technical details that can be googled in a second.<p>Like - can you land Curiosity with off the shelf java and JVM? Why or why not?

I kind of agrees with the above.

Why not type your problems flat out. Trying to "abstract" the problem by transferring it to a completely different and reverse analogy just makes the whole post artificial.<p>I was actually wondering if this was written by a programmer or a man that hires programmers at first...