in reply to Evil Interview Questions

I think that I, too, would join the “walk out of the room” group. The mere fact that I was being asked such questions would tell me a great deal about the organization, including the fact that I would not want to work there.

I've been programming for ... well, for a very long time now ... and “picking up a new language” is frankly the work of a long weekend, at most. The task of understanding an obscure language-construct is the work of fifteen-minutes on Google.

... but the experience that enables me to know not to write such code in the first place, and to know to be repelled by it and to eliminate it (like kudzu) wherever it may be found, has taken ... well, a very long time.

Therefore, I frankly do not want to work for an organization that prizes its developers' knowledge of arcane language-lore. I don't want to have to deal with their code-base or with the rash of avoidable bugs that I know it will contain. I don't want to plunge into a nest of competing egoes, because in such a nest there will be neither partnership nor communication. This will not be “a healthy place to work.” Instead, it will be a constantly-abrasive one that will grind you down, and life's too short for that. The best thing to do with such places (and they are legion...) is to avoid them at all costs.

The questions that you are asked during even the very first stages of the hiring process will tell you a great deal about what that organization values, what qualities it holds in high esteem, and how it defines its worth within the business organization in which it is situated. A company's interview process is a bright window straight into the personality and temperament of a fairly high-level manager whom you may never get to meet. They will reveal the organization's confidence (or lack thereof) in itself, and may illuminate the nature of the political image-battles which the organization fights.

I say again:   interview questions are a magic mirror. A workgroup that peppers its candidates with obscure questions lacks confidence in itself, and therefore will lack confidence in you even if your name is Larry Wall. A workgroup that asks how you feel about teamwork and long-hours isn't a cohesive and well-managed team and pays for it with long hours. Per contra, a workgroup that talks about company-paid employee training early in the interview process is probably a well-run group that is on top of its game (as it should be), and confident-enough about staying there to pay attention to its members' professional growth and personal well-being.

Your reactions to being asked such questions will likewise tell you a lot about yourself. If you find that you have a visceral negative-reaction to it, do not ignore your ‘gut,’ no matter how badly you (think that you) want the job! It's tough to walk away from an interview, much less a firm offer, especially when you don't have another offer in-the-wings. But sometimes that's what you have to do. You want to “get to the ‘yes,’” but it must be the right “yes,’ and the right one might not be the first one. If you are not satisfied with your job right now ... if it did not turn out to be what you expected it to be ... then unfortunately, you made a poor selection, too.

Replies are listed 'Best First'.
Re^2: Evil Interview Questions
by dpuu (Chaplain) on Feb 11, 2008 at 22:53 UTC
    From the perspective of an interviewer, a big problem is that it's much easier for a candidate to BS you with a hand waving design issue than with raw code. You can hide a lot of ignorance behind an insistence on big-picture design issues. If I have 45 minutes (max 1 hour) with a candidate then it is worthwhile spending one or two minutes checking the fundamentals using this style of questions.

    I sometimes compare this focus on fundamentals to the game of Go: strong players have a very strong sense of "direction of play" (i.e. strategy), but the way to get strong is to study life&death problems, and tesuji: the intricate tactical issues that weaker players ignore in favor of "power" moves (which work only against similarly weak players)

    Of course, it depends on the resume. If you say "Perl expert", then I consider the questions fair: you should at least be able to get the answers wrong. If instead you claim "Ruby expert" then I wouldn't ask the same questions: I'd probe more for the ability to pick up new languages (hopefully such a candidate would know more than one, so I could find some common basis).

    --Dave
    Opinions my own; statements of fact may be in error.
[reply]
Re^2: Evil Interview Questions
by Anonymous Monk on Feb 11, 2008 at 19:22 UTC
    And how exactly does the interviewer know that your years of experience translates into skill? Given your years of experience, I'm sure you've met other developers who, even though they have many years under their belt, could hardly barely write a "hello world" program.

    Simply put, testing helps find out if the candidate is fibbing about their skills or not. And yes, a lot of people lie (or exaggerate if you wanna be nice about it).

[reply]

      I know that a fair number of candidates are fibbing lying about their past experience. They have to, as long as gatekeepers filter-out resumes based on the field-names they put into a “skills” array and the numeric value of that field.

      The best solution that I have found for this phenomenon is to talk about soft skills in the job-requisition, and hope that enough of it makes it through the HR-gauntlet to be useful. Describe what the candidate will be responsible for, not in programming-terms but instead in business-terms.

      A problem that you will very-frequently encounter is that candidates simply don't have “business” skills to begin with. Nothing in their formal education (that they might well have spent tens of thousands of dollars for) has prepared them for this. So they have studied “wrenches” for years, and they've maybe even torn-apart and rebuilt an engine, but if you make the mistake of asking them an abstract question you get a blank stare. But when I'm interviewing, it's those abstract questions that I want to get answers to.

      One of my favorites:   “In your opinion, what makes a Truly Great piece of software, and why?” Notice that there is no right answer. That throws a lot of people... I wish it didn't, and I don't mean for it to. It's another chapter of the story of folks who get out of school with a perfectly-honed ability to take tests, and no practical knowledge whatever. That's a failing of our educational and training system, not of those people.

      Let me put it this way:   “around here, we don't ‘write programs in Perl.’ Well, that's what we Little-D-Do. What we Big-D-Do is to build solutions to business problems for people who, quite frankly, don't want to give a damm about computers except to use them. We intend for them to find that our solutions are technically flawless (“but of course”) ... and to find that our solutions are great.”

      I'll omit all mention of what programming languages we are using, if I can. The folks who don't particularly care what language we're using are the ones I want to talk to. The ones who know how to design-and-build Great Software... in anything.

      It can, of course, be problematic to get these things through “the HR gauntlet,” and yet you have to work with these guys and do things their way, because they're the ones who make it their business to keep you from getting sued. “Hell hath no fury like a lover loser-candidate spurned...”

Re^2: Evil Interview Questions
by kyle (Abbot) on Feb 11, 2008 at 19:29 UTC

    I think the value of knowing arcane language-lore is not in its utility when writing but in its utility when debugging and refactoring (i.e., when reading). Yes, you can look up some obscure construct and figure out what it does fairly quickly. On the other hand, some constructs do not appear to be obscure but can have unexpected features anyway (the map vs. for example, for instance).

    Most (if not all) of the places I've worked have somewhere some old scary code written by someone who wasn't very experienced at the time. I want people who can read it and know what it really does, not just what it looks like it's doing or what the comments say it's doing.

    Knowing the arcane can also reveal a passion for the subject.

    Pretty much every conversation of strange constructions or obfuscated code that I've been in has included someone saying, "but writing that would be a bad idea anyway." If I'm talking to a candidate who doesn't say that, it makes me wonder. If I ever talk to a candidate who says, "I'll have to use that feature," that's almost certainly disqualification.

[reply]
[d/l]
[select]

In Section Meditations