I’m an Engineer, Not a Compiler

Recently I had a phone interview where I got asked a variety of Java questions. This kind of thing is standard, and most of the questions were somewhat standard:

  • What is polymorphism?
  • What’s the difference between a List and a Set? When would you use one over the other?
  • When might you see deadlock?
  • What is the difference between strong typing and weak typing?

These are mostly fair game. I dislike the polymorphism one, simply because it is so closely tied to most OO languages and inheritance that most people–when overriding or overloading a method, for instance–use it without ever thinking “oh! this is polymorphism in action!” Instead I might ask “what is inheritance and where do you use it,” which generally has a keyword or pattern in OO languages. But this is a personal preference and I can see the argument.

The strong and weak typing one was a bit unusual, because he was actually referring to type checking rather than type strength and got a little confused when I described C as weak-static, Java as strong-static, and Python as strong-dynamic (I think JavaScript is weak-dynamic, but I didn’t mention it).

What came next, however, were nano-questions:

  • What package is List in?
  • What package is File in?
  • What keyword do you use to inherit with?

(We also got the “standard interview questions” such as “where do you see yourself in 5 years,” etc.)

Russ Olsen mentions two consequences of asking nano-questions:

Aside from telling you not much at all, the tiny question has two real costs: first it takes up the time that you could be spending getting to know this person, finding out if they are smart enough, if they have the right background, if they will fit into your group. The second cost of this kind of question is that it tends to tick off those smart, well rounded people that you really do want to hire.

I got the nano questions listed here right, but let me throw on a third consequence: Asking nano-questions can lead to false negatives by weeding out otherwise great fits.

A good engineer thinks abstractly in terms of designing and building systems, they think in terms of algorithms, components, and engineering design. They do not necessarily know all of the details of syntax of a given language, especially if they are used to a good IDE which does it for them (I use Eclipse: I type List and then control-space to load java.util.List). It is more important that I recognize which package I want than that I be able to name it off the top of my head.

Similarly, it is more important that I be able to tell you when and where I should use inheritance, and when and where I should use polymorphism, than to be able to spit off the definition.

Basically: Any question that takes 5 seconds to answer with Google is not a good question. My favorite phone interview question? “What’s your favorite language?” followed by “What are it’s weaknesses?”

Yet a lot of interviews and a lot of exams basically test you to see how well you would substitute for a compiler. Even the Java Certification Exams tend to focus on questions of syntax and compilation as opposed to either how well you can actually program or how well you can design a system.

I am a good engineer, I am not a good compiler. I cannot look at a block of code and necessarily tell you that the problem with it is that it won’t catch the ClassNotFoundException, and a modern compiler will tell me that this is a problem. If not immediately, than at least when I attempt to compile. IDE dependency? Perhaps, but that isn’t necessarily a bad thing since that is representative of the tools they will be using in the office.

In Short: Finding a good fit for your team is far too important to risk it with a game of Trivial Pursuit: Geek Edition.

This entry was posted in Uncategorized. Bookmark the permalink.

Error: The ad management script is not properly configured for this user

71 Responses to I’m an Engineer, Not a Compiler

  1. imMCSE says:

    agree to the thought, shared on twitter @immcse


  2. Ben says:

    The second cost of this kind of question is that it tends to tick off those smart, well rounded people that you really do want to hire.

    I got the nano questions listed here right, but let me throw on a third consequence: Asking nano-questions can lead to false negatives by weeding out otherwise great fits.

    Aren’t they the same?

    • Minh says:

      The first point suggests that the candidate knows the answer.

      The second point suggests that the candidate may not know the answer.

    • michael says:

      It was only after re-reading that I realised that nachtrabe meant “tick off” as in “irritate”, rather than ticking off on a list, or something like that.

  3. daGrevis says:

    I can’t agree with you any more.

    • Tim says:

      “I can’t agree with you any more.”, meaning that you no longer agree with him!?!?

      *I can’t agree with you more.

      • Ratking says:

        I’m an engineer, not a compiler, a grammar checker, a spell checker, a thesaurus, a dictionary, an almanac, or an encyclopedia. (Did I cover them all?) :-)

  4. It’s pathetic to complain about tests just because you didn’t do well. You would probably complain about square man hole covers or “how many gas stations in the US?”, too. I don’t think Dilbert attitudes about management are good. I don’t like labor union people, either.

    • Eric Garvis says:

      what? you’ve revealed yourself to be a deeply troubled person.

      • fre3k says:

        If I recall correctly, the LoseThos author is definitely off-kilter, and quite possibly schizophrenic. There have been a number of threads with him on reddit and other places where he posts very bizzare comments.

    • Brandon says:

      The “square man hole covers” question allows the interviewee to display abstract, creative, critical thinking skills. I’ve purposely stopped trying to memorize the exact syntax for 10 or so languages I might want to use and rather keep a database of notes so I can quickly access them.

      I build software, I’m not a syntax cheatsheet.

  5. Zdenek F says:


  6. rrgg says:

    Is it possible they asked you which package something is in to see if you’d answer by stating the question is irrelevant for reason X?

  7. Marcus says:

    So… You are an engineer, but obviously not a programmer. Maybe you applied for the wrong job.

    • Pete Townsman says:

      Programmer != memorising

      Editor’s Note: Removed personal attack

    • Steve Meebs says:

      Yes. I as well wondered the same thing while reading this… “hey wait a sec, this is a programmer, not an engineer.”

      • Drew says:

        Software engineers are engineers…

        • Rudolf Olah says:

          No, no they aren’t. Not certified and not professionals *at all*. Rarely learning from history, no formal training is required, except *maybe* a computer science degree (which typically doesn’t prepare you to be a software engineer either).

          The title of engineer is earned -_-’

          • Steven says:

            This is going in circles. There are engineers who work in software development. Not all people who work in software development are engineers. Nachtrabe is claiming to be an engineer, which doesn’t contradict him being a programmer. I don’t see the problem (as long as he’s actually an engineer).

  8. Andrew McGregor says:

    Always sucks when you get rejected because “you aren’t smart enough” when actually the fault is with the interviewer for not giving you the opportunity.

    Of course, I’m just bitter.

  9. Mithos says:

    I use a file server.

  10. Good post. I totally agree with you.

    Although, some interviewers don’t care if you get these nano-questions correct, they just want to see how readily you will admit: “I don’t know”.

    • Quasar Jarosz says:

      I was thinking this same thing. I tend to say “I don’t know” a lot. Mostly when I don’t know.

      If an interviewer finds that to be a problem, that’s okay! I didn’t want to work for them anyway. My greatest strength is my willingness to admit I have no clue (and then go find out).

      • Knowing is half of losing the battle says:

        I wish my employer had known enough to ask me a question to which I did not know the answer. I found out long after being hired that at my company, not knowing is viewed as a sign of incompetence, and reading and learning is viewed as a waste of time.

        That should never be true at any engineering company.

        Admission of not knowing should happen every day, and should be followed by the opportunity to spend time learning.

        That’s how individuals, and companies, get stronger.

  11. Andy Till says:

    I think this is to weed out those engineers who type List and attempt to use java.awt.List for several hours.

  12. Jon Davis says:

    I think such “nano-questions” are more about getting an idea of the color hue of how acquainted you might be with the tooling. Getting such questions wrong won’t necessarily weed a person out so much as make a person stand out if he answers correctly and very quickly.

    One must consider that what makes a good developer varies from organization to organization; in some organizations, productivity is paramount over code design. Someone who spends an hour architecting the most beautiful code might be far less useful in some places than the person who got something working in less than five minutes because he knew where all the dependencies were and wasted no time trying to gather all the references, etc.

    Just some food for thought. I don’t disagree with you but I think there are multiple additional angles for the topic.

    • Drew says:

      You have to understand that none of us who would consider ourselves seasoned software engineering or technology professionals would give the latter type of person nearly as much professional respect as the former. The latter is a code monkey, and that is all he will ever be. His job can be outsourced to India or Pakistan. The former is a systems architect.

      • Knowing is half of losing the battle says:

        Agreed.. but it should be said that in *some* cases, a company truly needs a code monkey.

        I am a very competent architect, who works best with two particular people on my team..

        1) A code monkey who submits sub-par code in bulk, which I can filer, adjust, or give direction for improvements.

        2) A disciplined programmer, who can submit reasonable facsimiles of architecture I describe, which I can correct and adjust after initial commits.

        I strive for perfection, but I work best with people who strive for *any functioning product* after considering the limitations I place to prevent them from producing crap.

  13. Well said. “Nano-question” is a great description. This drives me crazy too, since I’ve been coding for decades and so much of this stuff has become automatic, I don’t have to explicitly think about it anymore. I believe that the questions should match the candidates level of experience, and that it’s insulting for potential employers to essentially not believe anything on my resume (and that nano-questions on things I haven’t done for a decade don’t prove that I’m not going to be able to re-learn them in a very short period of time. I may be rusty in some areas, but I’ve done the hard part already).


  14. Tony S. says:

    After 53 years of hard life and real engineering, here are the rules:

    1.)bad money drives out good. Stupidity in the organization tends to spread.
    2.)the most important job is Human Resources and Talent.

    3.)IBM took Ross Perot. They rewarded his SUPERIOR TALENT with
    ‘insults.’ They practically forced him to start EDS as a MAJOR COMPETITOR
    to IBM. IBM told him – you finished your sales quota for the year in three
    days. Just go back to your desk and don’t bother anyone.

    4.)The ESSENCE of programming is writing complex books that can
    be understood by a FIFTH GRADER. The ECLIPSE IDE – compiler I use
    is the 8th grade reviewer. The book level is MS computer algorithms.

    5.)Hey WOMEN, is this sexist?
    A Lady Should Be A Chef In The Kitchen, A Maid In The Living Room And A Whore In The Bed Room.”
    5a.)be flexible – sometimes you must use shell and awk as a flexible chef.
    5b.)be a good maid. Write clean docs and literate programs so that even
    those who are NOT native English readers can understand clearly.
    5c.)Bed room – Know the rules; overload the rules and know how to bend them.

    6.)intelligence is not the same as memory. In a storm, a dog will get lost.
    Humans get lost easily in the woods. A horse rarely or NEVER gets lost.
    So, the horse is smarter than you are!

    7.)Questions as farce? No demonstrated or even statistical relevance to
    the position tasks.

    8.)the ideal is government of the people, by the people and FOR the people.
    8a.)programming dept is run by managers who can’t program and ‘outsourcers’
    8b.)hiring is by HR (look only at test scores). We, the corporation do NOT
    trust the programmers to hire or even to recognize their fellow team-mates.
    8c.)the more churn and hire/fire – the stronger the HR department gets.
    real simple question: How many PERFORMANCE APPRAISALS actually
    show BAD CODE?

    Plenty of these HR tools are subjective. They use ‘AMBIGUOUS WORDS.’
    Even their test STINKS or smells.

    PS. Just like code smells or ‘taints.’

    PPS. After 30 years, my expertise is in programming AND engineering.
    No math tests because maybe most of the HR dept. is math ILLITERATE?
    No Euler Programming Tests.
    No math/logic reasoning puzzles/ or even basic map reading skills or
    OPEN SOURCE code reading skills.

    Question: Where are the critical code sections and vulnerabilities of
    FIREFOX BROWSER? (read the source.)

    PS.All Medical Doctors or M.D.s should be treated with the same attitude
    that they are ‘technicians’? Please question your BRAIN SURGEON on
    the obscure anatomy of the hand and the Latin terms.
    (by the way Latin is a ‘dead language.’ and this sarcastic remark is
    that the traditional interview is a DEAD interview).

    PPS.Controversial. I studied elec. engineering. Worked in elec. engineering.
    Much better to be an ENGINEER and then code than the opposite.
    The opposite is: take ‘high school dropout hackers.’ Let them loose on
    FACEBOOK and your privacy/security is assured!
    make sure to train the ‘code slingers’ in engineering and make them
    cut their long hair!

    PPS. Classifcation of the questions on the interview
    1.)Computer Science – design of languages – useful for C.T.O. or V.P.
    But most jobs – THE LANGUAGE IS already there and fixed.
    2.)Engineering and algorithms – no questions – we just ignore this.
    3.)Technician – borrowed from junior year college exam written by a
    part-time lecturer. – e.g. What package is File in?
    4.)Sanity questions: where are you going to be in 5 years. The CEO’s
    average tenure is 2.5 years. Even the CEO of HP – HewLett Packward does
    not know when he will be fired!
    5.)general common sense. sometimes helpful.
    6.)creativity and INGENEURING questions – from the ingenieus engineeer.
    How would you improve Google Maps? By making ONLY RIGHT TURNS for car directions for the route. Just like the travel strategy of Fedex,UPS.

  15. Developer Dude says:

    Excellent points.

    One of the best interview questions I was asked after I illustrated how I would solve a problem, was “now how would you test that?”. I think I have been asked something like that twice in all the interviews I have had in over 18 years working as a s/w engineer.

    One side effect of the “nano” questions and other useless questions like them, is that I learn that I probably don’t want to work for that org – I might have, but just like it is a false negative for them, such questions leave a bad taste in my mouth as to the employer’s level of competence – at least with regards to conducting interviews. Now granted, just like they may be getting a false impression of me I may be getting the same false impression of them; they may be quite competent engineers and just lousy interviewers (not unusual at all).

    I get the impression sometimes that some of these questions are a rite of passage – not useful except to cut down the number of people to consider.

    If someone asks me where I see myself in five years I tell them “on a beach in Tahiti”. What? It’s the truth.

    My philosophy at this point in my career is that if they ask dumb questions and don’t like the answers I give, then I don’t want to work for that org.

    • nachtrabe says:

      One of the best interview questions I was asked after I illustrated how I would solve a problem, was “now how would you test that?”.

      Nowadays I ask exactly that question, actually. It’s a fantastic question.

  16. Bjørn says:

    The polymorphism question would obviously be warranted in your case because you immediately started to talk about inheritance — which is a worrying red flag because it may indicate you write “onion code” with overuse of inheritance.

    As for the detail questions yes, they are pointless and I wouldn’t think of asking them — but if a candidate doesn’t know what package List is in, yet claims to know Java I know the candidate is either a liar or an idiot.

    • Developer Dude says:

      Well call me an idiot because I would not be able to recall which package List is in off the top of my head. If you call me a liar though I would likely walk out of the room right then and there because I have been professionally developing Java apps for over 12 years now, and I keep getting hired and kept for multi-year gigs so I must be doing something right.

      The truth is I have a terrible memory for silly mundane details like this, and it isn’t necessary to know what package List is in in order to be a good Java developer. Having a memory for rote details is not pre-requisite for software development, and those that think it is are either liars or idiots.

  17. david says:

    I agree with on the interview quedtions but to an extent and the key point your missing is that you have to be well rounded. See I think part of being a good engineer is having the programming knowledge but most importsnt its communication. You have to be able to articulate what you see and what you’re doing in in order to make a project successful. Yeah you always need a good programmer but if the person who created that project just so happens to not posses the deep technical knowledge as you then there is a barrier. This also depends what type of company you work for if its pure technologies then great if not the you have the business side to deal. Don’t get me wrong I hear you frustration as I feel the same way. I think what changed my perspective was the vp’s above me, when you on top looking down things just look different and unfortunately that’s where the money is.

  18. duggi says:

    5 years, best answer candidates:

    * celebrating the 5 year anniversary of you asking me this question
    * checking your performance review, deciding on whether to fire or promote you
    ... and if you want to go full insanity wolf ...
    * kicking back on your sofa, **ing your wife, wearing your face as a mask

    seriously though … i like the questions where you get into the philosophical aspects of knowledge that can only be answered by someone with a lot of experience and repeated analysis. to wit: do you have a position on namespacing as a code management technique? discuss the relative merits of vector vs. raster art in a production lifecycle. do you prefer thin object factory layers or thick component frameworks?

  19. Carolyn Ann says:

    Years, a decade or so, ago, as part of an endless day of job interviews for a network management position (it was not a “technical” job, btw), I was asked about the details of some network and application protocols. Stuff I’d not looked at in a long time. Bits and bytes, that sort of thing. I didn’t impress the chap interviewing me when I told him “I have books to remember that!” It was really irritating; if they needed me to know that level of detail for that job, they were wasting my time and theirs.

    They still offered me the job. (Which I turned down because it was at the height of the dot-com boom, that particular interviewer had irritated me and someone else offered me more money, etc.)

    My favorite interview question is “Tell me about a mistake you’ve made”. :-)
    I *love* that question. It’s quite a tripwire.

  20. bAris says:

    Hope you never have to code ADA on UNIX :)

  21. simoncpu says:

    Hahaha, these questions sound like a Google interview! Yeah, they weed out lots of false negatives.

  22. Dan says:

    Not only about this stuff but stupid question about limitations…

    for instance I had an Android interview where the written test, must have been written in 2009 because most of the information about memory, size limitations, etc… was simply outdated.

  23. quess says:

    Dude C its really Strong Type, or maybe you meant this fact:
    Java, C#, Pascal, Ada and C require all variables to have a defined type and support the use of explicit casts of arithmetic values to other arithmetic types. Java, C#, Ada and Pascal are often said to be more strongly typed than C, a claim that is probably based on the fact that C supports more kinds of implicit conversions, and C also allows pointer values to be explicitly cast while Java and Pascal do not. Java itself may be considered more strongly typed than Pascal as manners of evading the static type system in Java are controlled by the Java Virtual Machine’s dynamic type system. C# is similar to Java in that respect, though it allows disabling dynamic type checking by explicitly putting code segments in an “unsafe context”.

    And by the way, stop complaining a be a man.

    • duder says:

      Weakly typed languages allow casting, strongly typed don’t. C and Java are weakly typed. Python is strongly typed. Java is weakly typed at the syntax level, but it won’t let you incorrectly access memory like a C cast, so maybe Java is really strongly typed?

      It doesn’t matter what you call it, just that you understand how it works. The OP’s weak-static description shows that he understands how the languages work, and that’s all that really matters.

      • quess says:

        It all depends in the context of the conversation they were having i guess!

        You can tell by the conversation that the person doesnt have technological background. Fallowing the conversation he could just answer with a question like: What do you mean with Strongly Type? Variables doesn’t have to be declare with a type like Int, Char, Etc. ex: Php, JavaScript? or the fact that the programming lenguage allows casting, ex: C, blah blah? Etc.

  24. itoctopus says:

    I think this is a large company and you were being interviewed by someone who knows nothing about programming.

    A couple of months ago a friend of mine got interviewed by Amazon (someone with a very heavy accent did the interview) – my friend mentioned the word “E-com” – the person on the other line said “By E-com do you mean Electronic Commerce?”

  25. James Head says:

    I’m not sure I agree 100%. I think it’s almost good to ask some annoying questions, or questions that you feel are bad, or unfair, purely as a psychometric test, to see how you handle such questions. (Do you handle them with grace, – are you ok with failure, or do you throw your toys out of the pram?).

    • Developer Dude says:

      If you want to play mind games then play them with someone else. In my experience, when the interviewer asks dumb questions, or a question that is guaranteed to irritate anybody, then either they are wasting my time or they are ignorant or both.

      I am not impressed either way. Which brings me back to something I alluded to earlier, if the employer wants quality experienced people, then they had better worry as much about the impression they make on the candidate as the candidate makes on them. After all, I have a decent job that pays a six figure salary, and I get offered gigs all the time, so the employer/position will have to persuade me that they are worth my time and effort, and you won’t do that by asking stupid annoying questions. At that point I might just respond with stupid annoying answers just to end the interview and get on with my life and we are both better off.

      If you don’t have a better way to determine whether I am a good match for your position then I don’t want to work for you, and at this point in my life I can afford to be very picky, even in this economy.

  26. Eric says:

    If I give you a test and you make 100% on it, I haven’t ascertained the limits of your knowledge. It’s only when I go beyond your limits that I know the extent of your expertise.

    Before I delve into a subject I ask the candidate to rate his knowledge of the subject on a scale of 1 to 10. That tells me several things: how good he thinks he is, where to start my questions, where the questioning should end.

    Your “nano-questions” show a depth of knowledge and familiarity with the subject. Yes, I could google “how do I find my ip address on a unix system” and get “ifconfig”, but if I’m interviewing someone that says they’re an expert unix sysadmin and they don’t know “ifconfig” (or iostat, vmstat, grep, netstat, awk) of the top of their head, they are full of shit. I know Java, but I couldn’t answer the “what package” questions. I live Python and I can probably tell you where to find most functions in the standard library.

    I agree with most of the people here that think you sound a little bitter because you may have been under qualified for the programming aspect of the job.

  27. Dean says:

    I hate it when they ask these kind of questions to Front-end Engineer. Its not like you ever fucking use those things in your daily work. I almost didn’t get a job because I didn’t know complex sql queries. I was there for 2 years, and never wrote a single database query or saw it in our codebase.

  28. Tom says:

    I totally agree with you. It’s about your ability to do good design and build a stable and robust system. Knowing package names is trivial, it’s not really a skill where as engineering is.

  29. Toby Pinder says:

    Totally agree. I see too many people who see reliance on tools like IDEs as a bad thing. Could you do it yourself? Yes. Is it convenient and useful for you to commit it to memory? Hell no. We have tools, and while it’s important to know what’s happening underneath (just as you might read about Bytecode and the garbage collector) it’s not important to hold it all up top.

    People should consider their brains as an L1 cache, with simple google queries as main memory.

  30. Guillaume says:

    What is IDE dependency when it’s basically the standard tool you learn programming with and use your whole life (unless of course you stop coding) ?
    I’m tired of people who are only willing to agree with you if you’ve coded a thousand classes with nano.

  31. I wouldn’t go quite as far as asking what package List is in, but it belongs to an interesting class of questions that I mentally refer to as “résumé checks”.
    If someone puts down on their résumé that they’ve spent the last five years writing Java code, there are certain things that you’d expect them to know just on the strength of inevitably encountering them every working day. If they don’t know them, this is a big flashing red light that their résumé might be padded.

    The fact is, there are a lot of people in the industry who can talk a good program but not write one. There are also a lot of jobs in this industry where those people can go and ineffectually tell other people what code they should be writing without ever putting keyboard to editor themselves. The only way to spot them is to ask depressingly practical questions, or ask them to demonstrate practical tasks.

    Obviously, failing to answer one such question isn’t a deal-breaker. If you live in an environment for long enough, you can stop noticing obvious things because they’ve formed part of the scenery. But a pattern of not knowing the answer to these sorts of “nano-questions” is a big warning sign.

    The thing about interviewing is that the tools at your disposal to evaluate a candidate are never particularly good, and if you’re anywhere worth working at, the pressure not to hire the wrong person is just as great as the pressure to hire the right person. False negatives are an unfortunate side-effect of having to be really careful to avoid false positives. As such, it’s up to the interviewee to do their homework and avoid becoming a casualty of the process.

    • Developer Dude says:

      And good employees are hard to find, so it is up to the employer to not waste their time and the time of the interviewee by asking silly trivial questions that are not really an indicator of proficiency or skill. If such questions are the best you can come up with to weed out false positives then your workplace probably isn’t as good as you think it is.

      I’ve never given an employer a false idea of my experience or skills, but they have often fooled me as to their competence – again, as you said, by talking a good game but not walking the walk. I now try harder to learn more about them, but they have the advantage; it is pretty hard to find out the truth about a workplace and the people you are going to work with – they don’t provide references like I often do.

      Sometimes there are red flags in what they say in an interview, sometimes I catch them right away, sometimes it takes some thought, sometimes I miss them altogether (like the employer I went to work for that had not installed a VCS yet despite having a s/w dev group for over a year).

  32. noise says:

    Nano-questions are there to determine your experience level.

    For instance if you use List a lot, you will know where it’s imported from of the top of your head. Anyone can memorize definitions of basic OOP principles, but knowing random facts by heart come with years of experience.

    And frankly you aren’t supposed to be able to answer all those nano questions anyways. Sometimes saying “I don’t know” is the right answer. Because admitting that you don’t know something when you don’t know it, is often the exact quality an employer may be looking for.

  33. Guillaume says:

    If I might, an interview tells as much about the candidate as it tells about the company.
    If the interview’s shitty, the hiring team/department/company might as well be so there’s nothing wrong in moving on to the next interview.

  34. Some Guy says:

    Some idiot at LinkedIn insisted on giving me the kinds of interview questions you describe here, and he wouldn’t drop the script when I suggested we talk about my experience, and how it relates to what he needed to get done.

    He was looking for an engineer to take over their iPhone app, and I’m a guy who’s been developing code in Objective-C since the NeXT days. He managed to offend me enough that I deleted my LinkedIn account.

    These days, I’m at Apple, where I’ve never been asked a stupid question in an interview.

  35. Petr Jiricka says:

    Based on my experience as an interviewer, asking nano-questions is not necessarily bad, the important thing is how the answers are interpreted. E.g. if someone tells me that he’s been programming in Java 8 hours a day for the last 5 years, and then does not know that List is in java.util, then this tells me that he/she is a liar, as someone with that much experience would surely know it. On the other hand, if he/she tells me that during the last 5 years they’ve done some Java programming, but also a lot of JavaScript, .NET, Scala, Erlang and Ruby, and then does not know that List is in java.util, then I won’t hold it against them and make it clear that I am not making the decision based on this answer. And also, this person should be in a great position to answer the “favorite language” question, which I agree is a very good question.

    • Developer Dude says:

      Yet another person who thinks knowing where a tool is equates to knowing how to use it. *sigh*

      Then you compound it by calling people with poor rote memory for inconsequential details, liars. Nice. So you’re judgmental about silly things too. Thank you for not hiring me based on your silly test – I am glad I don’t work with or for you, life is just too short to deal with people like you on a daily basis.

      As for my “favorite” language, I don’t have one, but I can suggest appropriate languages for different problems if you tell me what kind of problem you want to solve.

      • Hugo Estrada says:

        Good point on the favorite language. Depending on the problem, there are some languages that are better than others, either because of language features or due to its library ecosystem.

  36. jaydelatorred says:

    Absolutly true, I have had many interviews and test like this, instead of focus in real engineer. Skills … Pretty goood…..

  37. fangbianmian says:

    cannot agree more. for years I’ve been frustrated by so many nano-questions. I’ve been programming for years, and using dozens of languages. But I have a loose memory for syntax. The syntax is up to the compiler. The architecture is up to people. Don’t ask people to behave like a machine!

  38. Michael Dorf says:

    It’s time someone finally get this crap out from under the rug. These interview questions have become ridiculous in recent years as more and more “stock” interview question articles hit the space. Before you know, you forget the whole purpose this guy is here for and just want to GRILL, GRILL, GRILL! Thanks for a thoughtful post!

Leave a Reply to Ben Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>