Please create an account to participate in the Slashdot moderation system


Forgot your password?

Selecting Against Experience - Do Employers Know? 292

IBitOBear asks: "A couple days ago I did 'the interview loop' at that leading online retailer. Over the course of six hours I was repeatedly introduced to a guy in his early twenties, who would then ask me to write out code on a white-board for a problem that you might find in the study guide for a 200-level computer science class. I have 20 years of experience in programming and systems design. And in several cases the interviewers were vague, semantically incorrect, or self-contradictory. Interviewer blunders included not understanding that non-normal forms in databases -can be- more correct or efficient when the domain of a data is extremely limited; or choosing a leader among N candidates -is- a byzantine agreement problem. In short, the loop would have been perfect to weed out some guy getting his first job fresh out of school, but it definitely exerted selection pressure towards excluding experienced candidates. So employers, what are you doing to make sure that you are not culling out candidates with the low-ball? Job seekers, what do you do when you find yourself trapped in a sophomore study group?"
This discussion has been archived. No new comments can be posted.

Selecting Against Experience - Do Employers Know?

Comments Filter:
  • by yagu ( 721525 ) * <> on Thursday August 24, 2006 @09:47PM (#15975058) Journal

    They probably know they are leaning towards fresh blood, and probably will pass on more experienced and stronger candidates. I know quite a few people who work "there", and inside, they are one of the top IT shops, bar none.

    Also, there are a few things to be aware of... part of the interview process intentionally (from talking to insiders there, and at Microsoft) introduces vagueness, incorrectness, and other troubling aspects to problem solving. One of the things they're trying to observe is how a candidate deals with the obstacles.

    A friend at Microsoft told me if a candidate got flustered and angry at an intractable "problem" he (or she) was pretty much disqualified on the spot. At Microsoft, you could tell your job was "no go" if it didn't last the entire day. (Mine did, sigh... and I got the job, sigh again.) Typically they "nice" way was to tell the candidate the next interviewer got caught up in some responsibilities, and that would be that.

    My personal opinion, not that it amounts to a hill of beans for these companies, they sell themselves more short than they might realize. Business is about numbers games and businesses play the curve within one sigma, that's it.

    As for what to do when trapped in a sophomore study group, that sophomore group pretty much holds all of the cards. Candidates would be wise to suck it up, be friendly, and at least pretend not to be bothered by their seeming snobbery. (Also, by the way, the snobbery at Microsoft is real.)

    Some are better than others selecting excellent candidates (that online retailer comes to mind), but I think there's a slew of mediocre companies out there that would be better performers with a bit more appetite for investing in "old timers". Of course, coming from an old timer, I'm probably introducing my own bias.

    (ASIDE, and By The Way... you said over the course of six hours you were repeatedly introduced to a guy in his early twenties... If management had any of their wits about them, they'd consider getting rid of that guy... he should have been recognizing you by the 2nd or 3rd introduction. Sheesh.)

    • Re: (Score:2, Insightful)

      by a_nonamiss ( 743253 )
      and probably will pass on more experienced and stronger candidates.
      You left out "more expensive." Yeah, sure, it's age discrimination, and it's illegal. Doesn't mean it doesn't happen all the time. They just have to be creative as to how they weed out the old guys.
    • Re: (Score:3, Insightful)

      by Guppy06 ( 410832 )
      "Also, there are a few things to be aware of... part of the interview process intentionally (from talking to insiders there, and at Microsoft) introduces vagueness, incorrectness, and other troubling aspects to problem solving. One of the things they're trying to observe is how a candidate deals with the obstacles."

      Never attribute to malice that which is adequately explained by stupidity.
    • by Skreems ( 598317 ) on Thursday August 24, 2006 @10:56PM (#15975345) Homepage
      I agree with most of that. I'm basically one of the 20 year olds the story is complaining about. I ask retardedly easy questions when I interview people, and on occasion I will be a bit vague on purpose, to see if they will ask clarifying questions or just fumble around for a half hour (guess which one gets you hired?). The problem is, I've interviewed people who claim to have been working in industry longer than I've been alive, and you'd be amazed how many of them can't code what basically boils down to a double nested for loop. I've had people go up to the white board and fumble around for 30 minutes only to wind up back where they started. You have to ask those retardedly easy questions because half the candidates can't answer them, even the ones who've been full time workers for decades.

      As for incorrect knowledge of some algorithmic stuff... there's two options. One is, they may know the correct answer, but are waiting to see if you do, and if you'll correct them. In one of my interviews coming out of college, a person said something about the problem I was working that was blatantly incorrect. He'd been working on a similar system for months, so I'm convinced that he was just seeing whether I'd correct him, or defer to him as "the authority". I corrected him, and I got the offer. The second option is that he doesn't, in which case you should stand up to him anyway. Even if he doesn't know you're right, most people will respect someone who isn't afraid to contradict them. If you just blandly defer to everything they say, how do they know what it would be like to try to design a system with you?

      Not all of the impressions of snobbery at Microsoft are real, though. I found them very friendly in my interviews, and very down-to-earth. Probably depends on the group you're interviewing with, but there's a lot of people who are just good at what they do, and want you to show them that you're good at it as well.
      • And yet these guys have probably been writing successful software systems for years, what's going on?

        Perhaps there's really not much of a connection between writing code on a whiteboard under interview pressure and writing applications in the real world.
        • by Skreems ( 598317 ) on Friday August 25, 2006 @12:01AM (#15975671) Homepage
          And yet these guys have probably been writing successful software systems for years, what's going on?
          It could be any of a number of things: for one, we only have their word that they've written all these successful software systems. A resume gets you in the door, but it's useless after that. We don't know the true complexity of the system, we don't know the quality of your peers on the job, and we don't know how well the final product really worked.

          Secondly, I've known some people that could write software that "worked", but it was far from pretty, and it took an inordinate amount of time. We need someone who can code at a reasonable speed, where other companies, particularly non-tech companies who just have some internal tool programmers, may not care as much.

          Finally, it doesn't matter so much whether you actually solve the problem, but the work process that goes into it is key. If you stare at the board and just write some stuff, it tells me nothing. That's why I like simple questions posed in a slightly vague manner. I leave a lot of things undefined about the problem to see what the person will do. They can choose to assume things, which is fine as long as the state that they're assuming it. They can ask me for clarification, which I'll gladly provide. Any of these things is a big plus, because it shows you know how to analyze a vague problem, figure out the things you need to clarify it, and still move forward with an implementation without stalling on questions and definitions. The ones who fail are inevitably the ones who just stare at the board, write a couple lines of code, erase them, stare some more, etc. Specs aren't always clear. Requirements and bug reports aren't always clear. If you can't ask the right questions to clarify a slightly vague 200 level coding quiz, you're not someone many people would want to work with.

          One other comment: some people may suck at this because they rely on the compiler for everything. You can get surprisingly complex systems out of guess-and-check programming, but it's far from ideal. Quite a few new grads have this problem, although I'm not so sure about the more experienced programmers.
          • It'e interesting, but all your questions assume a certain mentality that's probbably similar to you're own mentality. Are you sure you're selecting for quality programmers, and not just people that think like yourself?

            That can be a good thing, and a bad thing. If everyone thinks you like you, you'll probbably all get along quite well and be able to communicate easily. But you're also likely to all make the same mistakes over and over.
            • by Anonymous Brave Guy ( 457657 ) on Friday August 25, 2006 @08:39AM (#15977200)

              The parent makes an excellent point, in that what Skreems and co. really seem to be testing for is people who match their approach. The implicit assumption that their approach is (a) the only one that works, or (b) better than everyone else's, is not going to help improve their business.

              There is also the problem that interview processes are two-way things. You don't know me, so let's assume for the sake of argument that I am a good programmer who knows his stuff. The moment I walk up to the building of a prospective employer I am sizing the company up. The moment someone greets me (or leaves me hanging around in reception for ten minutes) I am gauging how much value the people at the company really place on colleagues. And when we get to the technical questions, I am definitely judging the technical competence of those who would hire me, and the quality of the code produced by the existing staff if I see any.

              So, dear interviewers of the world, let me put this simply. I am interviewing you, too, and I expect you to know your stuff. I would not be here if I wasn't interested in your business, but I am confident of my own abilities, including my ability to find another job quickly if yours isn't up to scratch. And it will cost me a lot less than it will cost you if today is a waste of time.

              What does this mean in practice? Well, everyone's different. Personally, I think vague questions are fine and expected. I'll seek clarification without a second thought, because that's how the game works. But if the interviewer is a smart-ass, or repeatedly makes elementary mistakes, I won't take it upon myself to educate them. I will simply judge them incompetent, and not take a job working with them.

              Now, perhaps a lot of companies wouldn't want to hire someone like me. (They probably wouldn't like my non-negotiable rules on IP and my expectation that I will work the hours in my contract and not give them 50% more for free, either.) That's their decision, and I accept that my principles here will rule out some companies that I might have been happy working for. But just as an employer usually gets enough applications not to worry about missing the odd good one because there will be others, so it goes with good people and finding jobs.

              As they say, first impressions count. This is particularly true of interviews, because you'll never really know whether someone is a good candidate or an employer is a good place to work until a few days into the job, so the recruitment process is really just an attempt to make the guesses more educated. In this context, I'd advise any employer who wants to recruit people who are good rather than merely young and enthusiastic (now) to stick to sensible interview techniques, and avoid the time-wasting and trick questions. You aren't really hurting anyone but yourselves with that kind of stuff.

        • by Haeleth ( 414428 ) on Friday August 25, 2006 @04:47AM (#15976496) Journal
          And yet these guys have probably been writing successful software systems for years, what's going on?

          Here's a clue. []
      • by Travoltus ( 110240 ) on Thursday August 24, 2006 @11:37PM (#15975545) Journal
        I'll present a candidate with a real problem in the danger room (our term for the isolated test center where we diagnose stuff and load test network setups without screwing with the blades&racks that are live) and screw something up, then have them try to fix it. I'm more interested in their methodology than their solution. Our test network works, but it's a mess; if they can innovate before my eyes and tell me how to clean things up while being tactful then they're hired. My predecessor did this and so do I.

        I expect to be corrected if I (intentionally, for the most part) say something wrong, but I expect tact and respect, and I'll tell them those guidelines up front. BS artists have that look when they don't know something, and they get very vague. I don't need to play games with them. Someone who knows their stuff will appreciate the honesty and show their true competent colors.

        I send BS artists out the door with a pretty precise explanation of where they went wrong. Hell, I even suggest where they need to get training so they don't have to BS their way through the next interview. This way they won't bother another employer with their BS attempts, or at least they'll know why they got rejected.

        If you know it, you know it, if not, then you don't, that's my motto. No need to trip people up, the losers will always get culled from the herd as soon as they open their mouths.

        Playing games with applicants sucks, IMHO.
        • by Skreems ( 598317 )
          Yeah... I'm not saying I intentionally fuck with people. I just leave some things undefined, and see whether they immediately ask for clarification or, as you say, get that "BS artist" vagueness and start throwing random lines of code at the board. I leave nothing vague that can't be corrected by 30 seconds of discussion about the problem, and I'll usually accept whatever way they choose to define something if they start filling in the vagueness with their own assumptions.
      • by plopez ( 54068 ) on Thursday August 24, 2006 @11:40PM (#15975573) Journal
        this 'for loop' of which you speak. is it like iterating over a collection or perhaps like usinng a row fetch cursor? I vaugely remember something like that from... fortran... but haven't touched it in a while... :)
    • I work at nVidia (driver development... please don't kill me, herd of vicious /.ers), and I was talking at lunch the other day to one of the guys that does a lot of interviews. He mentioned this one question he loved to ask, and said the reason he loved it is because there was no right answer and not even really any good answer. He asks the interviewees to basically think completely out loud, display their whole problem-solving process while working, and has a list of several approaches that are good ones
      • by boron boy ( 858013 ) on Friday August 25, 2006 @12:53AM (#15975909) Homepage
        We won't kill you, but if you ever want to see your garden gnomes again you'll give us the source code.
    • by uradu ( 10768 )
      > Mine did, sigh... and I got the job, sigh again.
      > [...] Also, by the way, the snobbery at Microsoft is real.

      Shut up, really? 'Cause I was gettin the warm fuzzies at first there.
  • Walk away. (Score:5, Insightful)

    by Spazmania ( 174582 ) on Thursday August 24, 2006 @09:58PM (#15975110) Homepage
    Job seekers, what do you do when you find yourself trapped in a sophomore study group?

    Walk away. An interview is a two-way street: they're evaluating your ability to do the job but you're also evaluating their ability to provide a worthwhile work environment. If they fail your test, walk away.
    • I took a job once where they didn't even bother to send me a techie for the interview. While I could do the work, the work environment was awful. If they can't be bothered, you can't be bothered.
    • They have goals, so do you. Evaluate accordingly.
    • I can not agree more! After a recent interview with a 'darling' tech company I decided that I didn't want to work there. Vague questions and poorly worded rebuttals to answers scared me away. Plus they fell into the cardinal sin of computer science. Never.. Ever.. ask somebody to write answers on a white board. It is not natural. If I prefer to place open/close brackets right when start a function then white boards do not fit that pattern. Little things like this make it more 'English' and less 'code'. As

      • Re: (Score:3, Interesting)

        by AJWM ( 19027 )
        Never.. Ever.. ask somebody to write answers on a white board. It is not natural. If I prefer to place open/close brackets right when start a function then white boards do not fit that pattern. Little things like this make it more 'English' and less 'code'

        You just failed any interview that I'd give. Not that I necessarily ask folks to write code on a white board, but if they can't handle that it shows that they're inflexible and would probably be totally lost in a design discussion or a code walkthrough.
        • "Not that I necessarily ask folks to write code on a white board, but if they can't handle that it shows that they're inflexible and would probably be totally lost in a design discussion or a code walkthrough."

          Inflexible? Programmers? Who has ever heard of such a thing? It's not as if one would be so inflexible that they wouldn't hire someone who couldn't code on a whiteboard.
        • Ahh.. more voodoo interview techniques. They all amount to "If you can't do thing-X I think is super-important, you suck!". Strangely thing-X is different for each interviewer, but yet they act like it's a Universal.

          It probbably shouldn't bother me that people like you have these weird tests that you think can peer into the heart of any programmer, but it does. Programming is kind of weird in that something can outwardly function, but yet be terribly coded. I don't know of many other fields where this
    • Re:Walk away. (Score:4, Insightful)

      by bahwi ( 43111 ) on Thursday August 24, 2006 @10:54PM (#15975335)
      Agreed, I do freelancing contracting, back when I was looking for more contract jobs, I went to a guy at a company after sending him my portfolio and website and everything, he asked for a resume, I simply told him he didn't know what's he looking for and walked out. Really freaked him out, turns out it would be a job job not a freelance job, definately not what I was looking for.
      • Re: (Score:2, Insightful)

        by Sharpner ( 894049 )
        Good thing you figured out the situation was not for you. But if such a simple, standard request (resumes are standard and highly useful even for contractors, and even for those with lots of samples) was able to negate your interest, he was well rid of you as well.
    • It's only a two way street when you are old enough and experienced enough to be able to ask the right questions. A very experienced worker should be able to ask enough questions during the interview to ferret out exactly what the company is looking for, and tailor any answers to reflect experience in the field.

      I once spent two hours in an interview asking questions about the project, never once did the hiring guy manage to get a question in. I so completely led the interview that near the end the interviewe
    • You are right,

      I spent some time at a company like that, it was horrible, especially since the inexperienced guys tend to be seen as the experts in areas where they have absolutely no experience.

      Took me a while to find that out, a little longer to try and show management the value of real business experience (i.e. things in real companies, not universities or opensource projects).

      Finally left, went to a different place, have been happy here for a few years now, actually getting challenges, and having my valu
  • by Surt ( 22457 ) on Thursday August 24, 2006 @10:01PM (#15975124) Homepage Journal
    Probably you want to realize the company doesn't care enough about its hiring practices to have a bright future, and move on.

    If you're an employer, you want to make sure that your interviewers have a strong enough grasp of the interview questions not to be wrong about possible valid answers. Allowing inexperienced developers to interview candidates is a recipe for disaster. You don't build a quality company by delegating this task to the inexperienced. You accept that this is work that is best done by your most experienced people, and that it is one of the most valuable uses of their time that you can make.

  • 20 years? So what? (Score:5, Insightful)

    by zer0man ( 5467 ) on Thursday August 24, 2006 @10:04PM (#15975131) Homepage
    20 years experience doesn't mean much. I have heard/seen candidates bullying interviewers with their credintials (I've got a PhD in Computer Science) or experience (I've been coding since you were in diapers) and yet still fail to reverse a linked list in-place, or fail to explain the basic idea of hashing.

    It bothers me, as an engineer with some experience, to be subjected to the humiliation of 'the interview loop', yet having been involved in hiring I absoluately see why it is needed -- people, well, inflate their credentials when it comes to looking for work. So companies essentially ignore past work experience and ask questions relating to specific engineering problems to try to see what kind of developer you are. Sometimes the interviewer is bad, but that's why it's a "loop" there are at least 4 of them, and one of them should be a more 'senior' interviewer who holds more sway (that is if i'm guessing correctly at your 'leading online retailer').

    True, the system isn't perfect. You could be a brilliant engineer, but can't reverse a string. But with the amount of money that is invested into an engineer by the company as high as it is, they company doesn't want to be wrong.
    • by tgd ( 2822 ) on Thursday August 24, 2006 @10:18PM (#15975200)
      The problem with the position you described in your reply is that its not really applicable to software development.

      An engineer with 20 years experience knows a few things:

      1) He hasn't had to reverse a linked list in 23 years.
      2) There are framework functions to reverse a linked list. Who cares how they work.

      Questions like that are VERY age-biased. Because only someone right out of school, or someone with their head so buried in the code would remember that on the spot. Experienced engineers will tell you how to manage the development process, how to write code that is engineered to be testable, can actually explain software architecture and will do a FAR better job solving real world problems.

      Why? Even if you DO need to reverse a linked list in a situation where you can't use framework functions to do it, an experienced engineer can pretty easily punch in a few google keywords.

      No amount of googling will give a kid out of school an understanding of how you really engineer software in the real world.

      The only time I would consider asking questions like that to an experienced engineer (and I ripped off a similar one I got asked at Microsoft way back when during an interview today) is if I've already decided someone isn't a fit for some totally unrelated reason and I need a quick way to quantify that.
      • by kingkade ( 584184 ) on Thursday August 24, 2006 @10:34PM (#15975258)
        1) He hasn't had to reverse a linked list in 23 years.

        Irrelevant, it's a basic problem.
        2) There are framework functions to reverse a linked list. Who cares how they work.

        See (1), it demonstrates problem-solving skills and it's not an unreasonable problem to solve. It may be insulting if you think they think you're that much of a dolt that it'd be challenging. But otherwise it's not hard at all if they give you enough time.

        And let's say it is in that framework: you need to understand linked lists anyways if your problem uses lists that needs to be searched, you would know that using the list would be unwise.

        And say you do "Google it". How do you verify that the code is correct? "oops this is code to reverse a circular linked list...ummmm."

        I agree that you should probably not insult the guy's intelligence with such a question, or asking hm the question and giving a gameshow time limit.

        And inane questions too. I had some guy ask me "what data structure would you use in designing a database application?" You just have to be gracious, don't act snobby, and "suck it up" like someone said. Joke about it later with his co-workers ;)
        • Frankly, I think the best answer to the question is not a straight answer, but a "I would research it to find the cannonical answer with the best complexity for our expected data, but for a general first-pass solution I would try X". The sophomore study group problem is about asking for programming trivia rather than programming approaches. Programming is easy. Managing the complexity of a software project is hard. A real question would be bring in real situations and ask for an approach:

          We have a C++ c
        • by Aceticon ( 140883 ) on Friday August 25, 2006 @04:05AM (#15976401)
          I suspect it all depends on what kind of position is someone being interviewed for:

          - A programmer should remain familiar with the basic principles of creating code that runs efficiently. A more senior programmer is expected to be efficient at creating such code and to make easier to maintain code.

          - A software designer is expected to be aware of the importance of compartimentalization of information and division of responsabilities across the design, and of the tradeoffs between flexibility, maintenability and performance when making a design. A more senior designer should be well versed in communicating the design and the rationale behind it to the developers, and of keeping a record of the accepted and rejected designed decisions and the reasons behind it (such a record can be used latter when changes in requirements might mean that the rationale for choosing a certain design feature instead of another one is now not valid anymore).

          - A technical architect is expected to understand the issues of scalability, inter-application connectivity, fallback solutions. He should be capable of defining standards which promote efficiente development, maintenability, robustness and/or lower number of errors, all supported by a well document, internaly consistent rationale. He should be an expert at communicating these solutions to the developers and designers. He should be aware of the development process and ensure that the right tools are chosen/provided for the right job.

          [Note: there's a lot more than just this]

          Now, if you're interviewing for a technical architect position, which is more important:
          • Somebody that knows how to reverse a circular linked list out of the top of their heads and can do it in 5 minutes on a whiteboard
          • Somebody that can hammer down an Interface Requirements Specification for connecting two sub-systems being developed by different contractors

          In my experience there's a limited amount of seniority (in knowledge and wisdom) that you can achieve as a programmer before you find out you've turned into a software designer (in all but name) - if you're still selling yourself as a programmer by then (say, because you like programming and can't stand the boring parts of software design like making long documents and doing presentations), expect to have to go through "just out of school" questions in an interview when applying for a programmer position, even if you're insanelly experienced for a programmer.
      • by AuMatar ( 183847 ) on Thursday August 24, 2006 @10:48PM (#15975320)
        1) He hasn't had to reverse a linked list in 23 years.

        He doesn't need to know it immediately, but he damn sure ought to be able to figure it out quickly.

        2) There are framework functions to reverse a linked list. Who cares how they work.

        If you don't know how it works, you don't know how a list is used. You don't know when its appropriate to use it versus other data structures. If needed, you wouldn't be able to create a hybrid data structure. So yes, it matters if you can't figure it out with a minute or 2 of thought.

        If you can't get simple problems like that, its not worth my time to do the rest of the evaluation.
      • An engineer with 20 years experience knows a few things:

        1) He hasn't had to reverse a linked list in 23 years.
        2) There are framework functions to reverse a linked list. Who cares how they work.

        Questions like that are VERY age-biased. Because only someone right out of school, or someone with their head so buried in the code would remember that on the spot.

        Oh come on. Reversing a linked list really isn't hard. I don't think I've ever had to do it and with about 15 seconds of thinking I can easily picture th
        • by dgatwood ( 11270 )

          Reversing a linked list is trivial. Reversing a singly-linked list without ever making any nodes completely unreachable is far trickier.... Now that would be a fun problem to ask somebody in an interview. I think the solution would look something like this:

          Create a variable "newtail". Make it a NULL pointer. Recurse to the end of the list. On your way back out:

          • Change the current (now last) node's next pointer to be your newtail pointer's next pointer (assuming newtail is not NULL).
          • If newtail is
          • by AuMatar ( 183847 )
            Waaay too complicated. Here's the real algorithm, in C (no I didn't look it up- it took about 5 minutes to code from memory).

            struct node {
            node *next;
            int val;

            //Reverse a list
            //input- list head
            //output- list head of reversed list
            node* reverse(node *head){
            node *previous,*next;

            //Avoid null pointers
            return NULL;

            //Handle the old head, special case logic

      • by Rakishi ( 759894 )
        1) He hasn't had to reverse a linked list in 23 years.
        2) There are framework functions to reverse a linked list. Who cares how they work.

        It's an easy problem, being unable to solve it without pre-made functions shows an inability for critical thinking. Heck the question is more valid for experienced programmers as out of college students will have it memorized not have to derive it on the spot.
      • by Animats ( 122034 ) on Friday August 25, 2006 @01:11AM (#15975970) Homepage

        The last time I saw production code that reversed a linked list, it was because someone wanted the last element of the list. So they reversed the list and extracted the head. After reading the code for a while, I realized that I was looking at C code written by a LISP programmer. I finally rewrote the thing to use C++ collection classes. A list wasn't even the right structure; a C++ vector was, because the collection was built once and then used millions of times.

        Be suspicious of code that does elaborate munging on pointers. Stuff like that should be encapsulated in general-purpose routines. If you see it in application-specific code, somebody is probably doing something wrong. And it's very likely that such code will be broken during maintenance.

        Programmers should know how to reverse a list, but shouldn't actually do it.

      • ... but I wouldn't want to hire an engineer who couldn't figure out how to do it with a pencil and paper.

        You're not expected to remember the solution for reversing a linked list. You're supposed to remember the most trivial, basic property of lists: they start with one node which you know about, and each node points to the next node. And you're supposed to use those twenty years of experience to be able to *devise* a solution to the problem. Which if you know that simple property and have a practical und
      • Re: (Score:3, Funny)

        by drsquare ( 530038 )
        Experience is overrated, old people are generally stuck in their ways, you only have to read the posts on here from experienced programmers telling everyone how awkard and difficult they are.

        It makes sense that a company would target younger workers who are more cooperative and pliable, they have more potential than the old beard in a crusty sweater who wants to sit in his cube and grumble about how he's not allowed to write everything in machine code with ed.
      • 1) He hasn't had to reverse a linked list in 23 years.

        I've never reversed a linked list, and it took me all of ten seconds to figure out how to do it. It's a test of logical problem solving capabilities, not the ability to route memorize algorithms.

        2) There are framework functions to reverse a linked list. Who cares how they work.

        Propably no one. How the applicants mind works, however, is quite interesting to anyone who would hire him. And the best way to find out is to observe that mind at work.

    • by Godeke ( 32895 ) * on Friday August 25, 2006 @12:54PM (#15979442)
      What I find amusing here is the request to "reverse a linked list in place". Talk about your WTF worthy request. Is it singly or doubly linked? If it is doubly linked, why the heck would you want to reverse it: just make an iterator that walks from tail to head instead of head to tail. Done and done, minus all that nasty moving data around. If you really want it to be permanent reversed, swap head and tail.

      If it is singly linked, why the heck would you want to do it in place when constructing a new reverse link list (effectively making the list doubly linked) will allow you to avoid moving a single piece of data and yet again walk the data in reverse efficiently. Just add the head link as "tail" and then iterate forward, prepending elements into the new list. Now walk your new reverse link chain.

      If you really really want to reverse in place, then I ask how the heck you managed to load your data in backwards in the first place. Only after you could explain that would I bother with the fact that the previously mentioned reverse link list can just be used to swap pointers by chaining both directions at once. Of course, such an operation requires a locking mechanism for the list as a whole and I'm going to guess that any software that requires swapping a singly linked list in place probably doesn't bother doing that. Bleh, how did your poor program end up in such a muddle.

      You see, such a question in modern development is best answered MU: un-ask the question and examine the root causes. Sadly, some people around here would find the idea of actually unmasking the root problem to be offensive and get angry that their toy problem wasn't considered a serious request. Toy problems don't show you understand anything except how to code toys. Large systems are not toys, and employing people who are good with toys, but not with large systems is a bad idea. The good news: people who ask toy problem questions instead of being concerned that you can understand the real issues are not people you want to work for.

  • Heh (Score:3, Insightful)

    by tgd ( 2822 ) on Thursday August 24, 2006 @10:10PM (#15975163)
    Anyone who has interviewed at that "online retailer" knows exactly what you're talking about. In fact, it leaves no doubt among those who have who you're talking about.

    Its a silly process... they pride themselves on Google-esque hiring practices, but miss the boat. It was the one and only place with a process more rediculous than the Evil Empire(tm).

    My suggestion? Laugh at the guys giving it who imagine themselves big fish in a big pond, leave confident you've got more experience then them, and go work at a company with a better corporate culture. They're a struggling company stuck in the dot-com mentality. Unless you like that (and I'd have to guess with 20 years experience, you've outgrown sardine can working conditions and ego trips), you'll be far happier not working through interviews like that... use them as a sign of how the company works, and look elsewhere.

    There are FAR better places to work.
  • by nizo ( 81281 ) * on Thursday August 24, 2006 @10:12PM (#15975172) Homepage Journal
    ...what do you do when you find yourself trapped in a sophomore study group?

    Make sure to make fun of any bogus information in a way that makes it clear any braindead moron should know better. Follow up with a story about a previous co-worker who got fired for thinking that exact same thing. Lastly make it clear that you are glad you have an interview at a competitor later and look forward to helping to crush their inept company. Adding that you will enjoy buying some of their used furniture at the firesale is a nice touch.

  • TA problems (Score:3, Interesting)

    by rednip ( 186217 ) on Thursday August 24, 2006 @10:15PM (#15975186) Journal
    Over the course of six hours I was repeatedly introduced to a guy in his early twenties, who would then ask me to write out code on a white-board for a problem that you might find in the study guide for a 200-level computer science class.
    I'm quessing that the reason why they are comfortable with those examples is , they were teaching it to undergrads just a few years before. It's likely that the company hired these fools right out of college (or their first job) to be architects, which is likely the job you are looking for. They have little to no project experience, and the only coding they have done is examples rather than real world solutions. We've had a group like this in our company for a couple of years now, besides costing millions every year, all they seem to do is cause headaches for those of us who do the programing.
    • That is part of the problem. CS snobs like to point out its only science! Go to Devry if you want to learn programming?

      However in the real world what is needed is learning how to spec and project manage programming requirements. That is the number one issue for any real IT project involving code. Coding itself should take the least amount of time and effort and if you follow the principles properly you can achieve near 100% completetion filling out requirements and saving or making your employer money.

      Who c
      • Who cares really about mathmatical oriented things unless you write compiliers or something of that nature?

        Having both maintained and written compilers, let me asure you that you don't even use "mathematical oriented things" when writing a compiler. A compiler is simply a text processor, taking a source code and translating it into something else, whether that is a source code in another language (for a translator or cross-compiler) or into a binary file. The so-called "mathematical things" are useful in

  • Summer Experience (Score:3, Interesting)

    by D.A. Zollinger ( 549301 ) on Thursday August 24, 2006 @10:15PM (#15975187) Homepage Journal
    I am returning to graduate school this week, and while I attended summer school, some of my classmates did not. Most of us have had professional experience before returning for a master's degree. One colleague of mine took an internship over the summer, and worked on developing a new internal software package. Previously she had been a project manager at a couple of different companies, and had developed a successful strategy for project management. At her internship, she was a project member, and for the first time got to see things from a different perspective. The project was not well defined, and no specific goals were set until much later in the project causing a lot of people to re-work things they had previously created. As well, the project manager had poor communication skills, and did not communicate the status of the project well with members of the project. As a result, she found herself working 19 hour days, and well over a month late on this project.

    As a former project manager, she had the experience, and asked questions about the nature of the project to help flush out details, as well as provide a much more narrow scope for the project. However, because she was the "intern" many of her questions were dismissed, and she was labeled as being "too detailed."

    She has committed to staying with the company until the project is completed, even though it may interfere with classes for the next couple of weeks, but she feels it is her duty to see the project come to a conclusion. As such, she has the skills, resources, and know-how to make the project a reality, but it is my suspicion that the employers were afraid to give her too much responsibility in the company or with the project because of her temporary status. As well, it is obvious that the company does not have a good project manager, and the company expects mediocrity because it knows nothing different. Those who desire to excel may find themselves working against the corporate current, and may ultimately be defeated by it. I certainly wouldn't want to work in such an organization.
  • My experience (Score:4, Interesting)

    by cperciva ( 102828 ) on Thursday August 24, 2006 @10:16PM (#15975193) Homepage
    A couple of weeks ago I did 'the interview loop' at that leading search engine. I had already told [] my recruiter that there wasn't any point asking me about 200-level material, and aside from one silly question about topological sorting my phone interviewer respected that. When I arrived for my on-site interviews, several interviewers apologized about being required to ask really easy questions. They asked their questions; I provided my answers; they asked why my solution wasn't the same as their solution; I explained that my solution was asymptotically faster; and we moved on to more interesting discussions.

    Having not interviewed at that leading online retailer, I don't know if the situation is the same there; but my impression at that leading search engine was that my interviewers were very quick to recognize that I was more qualified than they were and to adapt their interviewing appropriately.

  • It seems i'm the only person who doesn't know what organization you're coyly hinting at. It's killing me...
  • As an employer ... (Score:4, Insightful)

    by rebill ( 87977 ) on Thursday August 24, 2006 @10:21PM (#15975217) Journal

    I would already be looking to weed you out. Your disdain for the younger employees with junior technical skills is pretty obvious. As a manager, I would immediately wonder how you would treat those junior employees, and I would worry that you would regular belittle their knowledge, deride them for their mistakes and restort to intimidation to squelch a junior employee's idea that you happen to dislike.

    Of course, I worked with someone who acted in the manner I describe. He actually managed to cost the company we both worked for many hours of my time, as he chose to display his extensive knowledge at every opportunity, and I found myself translating what he was saying into something that the junior employees could understand. Oh, and thanks - I had never heard of the Byzantine Generals problem. But your reference to it is something that I would take as a warning sign.

    So, like previous posters, my suggestion is: just walk away. You are not built to work for a company like that.

    • by IBitOBear ( 410965 ) on Thursday August 24, 2006 @10:37PM (#15975268) Homepage Journal
      Actually, I showed no disdain at all. I carefully and cheerfully complied. I even kept the mood up and remained positive through the entire process. It was the odd post-interview feedback that got my goat a little bit. 8-)

      I actually like working with younger people as a general rule as it keeps the mind sharp and provides a continuous influx of fresh eyes to stave off the dogmatic ossification I often encounter in my peers.

      There is nothing wrong with going back to first principles. I just found the failure to transcend first principles (and the fact that a couple of the guys got all grumpy when they didn't understand my solutions to their problems as stated and as revised) to be something of a warning flag.

      The "ask a question of sublime simplicity" approach can only prove effective if the questioner can understand an answer of sublime subtlety.
      • Actually, I showed no disdain at all. I carefully and cheerfully complied. I even kept the mood up and remained positive through the entire process.

        [snippage more disdainful and derogatory material by the OP.]

        Which, of course, is why your Ask Slashdot is written in a tone that is disdainful and deriding of the process and the interviewers.

        Now, while I've never been involved in job interviews of the type you went through - I did sit on submarine and watchstation qual boards (and signed the c

        • Actually, you are assigning motive to me in the absence of evidence.

          Or, more particularly, I wrote the Ask Slashdot article in a way that would make it a good candidate to be posted as an Ask Slashdot lead article. The constraints are rather rigorous. It has to be short (I almost went over-long) it has to inspire interest. It has to be linkable even if it doesn't contain links (the editor added the link to the byzantine agreement page). It has to give sufficient context for both the questioner and the q
          • Actually, you are assigning motive to me in the absence of evidence.

            No, I am reading the words you write - not just the Ask Slashdot question, but your subsequent replies.

            To perfect your analogy, consider what would happen if the senior welder walked through and you demanded he weld a pipe to demonstrate his understanding of the importance of maintaining the static pressure, and having a man watching that pressure, in the main cooling loop. Wait, you say, that doesn't make sense. Exactly.


    • If I take your comments out of context I'd probbably weed you out in an interview as well. You assume a lot from what amounts to candid responses usually reserved to your friends over a beer. It's really not that uncommon to come out of an interview and think "What the hell was all that about?", and then want to ask others if they've had similar experiences and what they did/would do.

      It sounds like you're filling in all the gaps of who the poster is with your own personal biases. That's usually not a goo
  • Just think - in any company the managers are the least technically astute employees, and they have the biggest influence in the technical content of the software. If the development engineers are working at a very low level of technical content, just imagine how bad the managers must be. You will be using javascript encoding of passwords rather than SSL. All of your data will be in one table in name value pairs. Instead of exchanging data between servers using efficient protocols you will be passing around
  • by IBitOBear ( 410965 ) on Thursday August 24, 2006 @11:02PM (#15975363) Homepage Journal
    I didn't get the job. And after I thought about the interview I didn't really want the job. So it was a push. I took a job offer that I had gotten from another company the day before the interview loop.

    Also, I have done hiring. I appreciate the need to ask some simple coding questions because it isn't that uncommon to get people in who _can't_ write a bsearch and who cannot demonstrate a mastery of the simple language syntax. But you only really need to walk that mountaiside once in the interview process.

    Then again, when you write some code on a white-board and the interviewer cannot understand it (q.v. "I don't understand... why are you checking the value of the pointer and then the contents of the pointer") and then that interviewer helps build the group decision that "we should get someone more technical", you are entering the realm of high comedy.

    I actually laughed when the recruiter told me about their rationale.
    • by Surt ( 22457 )
      That reminds me of a phone interview I had with SBC. They passed me around to a few people to answer some technical questions, and it became increasingly clear that they didn't understand enough about what they were doing to understand my solutions to their problems. The further I went in trying to explain the number of easier ways to do things that were available to them, the more entrenched they got in the notion that what I was suggesting was impossible, and couldn't work (ignoring of course the very s

      • In the end they didn't hire me, I laughed when the recruiter told me they thought I couldn't solve their problems. Two years later the project they were going to hire me for was canceled as a failure, a project I could have helped them wrap up in less than a year (faster if I could have taught someone else to help me).

        From what it sounds like you're VERY lucky you weren't hired by SBC. From everything I hear the big telecomms are like working for hulking dinosaurs. Everything you've said seems to confirm
        • by Surt ( 22457 )
          Indeed, though given where I was trying to work, they were one of the better paying options, and I could have lived with the frustration for a couple years in exchange for the money. Since then I've moved to an area with many more opportunities, and I certainly wouldn't consider working for such a project now.

  • (Insert some famous quote along the lines of "When men were studying bats, bats had an unparalleled opportunity to study Man.")

    If they're dunderheads and can't ask good questions, don't go. REALLY don't sign up. I did that once, it sucked true and hard, and I bailed in five months even though the CEO was in tears [yup] during my exit interview with him, begging me to stay. I still tell stories about that place, like the time they brought in a head-shrinker [yup] to interview the whole engineering staff t
  • by Tronster ( 25566 ) on Thursday August 24, 2006 @11:39PM (#15975557) Homepage
    By now I've performed about 80-100 tech interviews for a variety of IT companies. I will ask the brain dead questions, but ramp up accordingly. I essentially want to ask just enough to know whether or not I can say with confidence "HIRE" or "NO HIRE". ( Recommend reading: Joel On Software [] )

    If relevant, I will ask for some white-boarding of UML, or a code fragment to perform a simple task.

    I do all of this because, I have found that age means nothing. I've worked with some seasoned geeks who taught my colleagues and I alot on the latest technologies. I've also worked with a guy I hired who had well over 20 years experiences and was absolutely useless. I can personally say the same to guys just a few years in the field.

    It's a crap shoot...and I don't like to gamble.

    Another way I look at it... I've also been on the receiving end of an interview at least a dozen times. When this happens I try to show my patience when going through the brain-dead questions, because I know acting rushed or anxious is a sure way to send bad mojo to the interviewer, even if I've nailed all the tech questions.

    I know I'm interviewing for a good contract when the interview switches to more challenging questions based on my answers. If the interviewer just runs through the list or makes self-contradictory statements, there is a good chance it's either a manager who doesn't know the subject matter or possibly a technie called in to give the interview and isn't good at it. At which point, it can be a fun challenge to turn up the charm with the interview, because I know the questions coming are no sweat. The degree of confidence shows leadership skills and does stick in their mind when making decisions. (Especially if the interviewer WAS a non-technie.)

    P.S.: Also regarding semantically incorrect or self-contradictory statements... I sometimes deliberately throw out a misstatement to see how the interviewee responds (if at all).

    Help me find 3 kidnapped children! []
  • I'm a 22 year old guy, interviewing candidates for a helpdesk SA position (someone working under me).

    Any good tips for how to *not* come off like a young idiot?

    • Re: (Score:3, Insightful)

      by symbolset ( 646467 )
      Any good tips for how to *not* come off like a young idiot?

      Wait 20 years.

    • FWIW, the following advice seems to come up a lot in these discussions. I haven't interviewed much myself, so this is mostly my way of summarising second-hand information; take it with a pinch of salt.

      1. Be friendly and confident, but don't try to be artificially authoritative. You won't carry it off, and since they're interviewing for a job with you there is enough implied authority on your side anyway.
      2. Make written notes on key points, but don't become too focussed on it. Pay attention to the candidate
  • I admit I've never had the guts to do it, but I thought it would be great to prepare a test for the interviewer that you can whip-out when presented with a test for you to perform.

    I suggest a reverse-trick "what is the code doing" question: i.e. one that appears at first glance to solve a well-known problem but actually doesn't. Make them examine all the trees rather than the forest.

    It probably want get you the job but it might scare the interviewers from testing other candidates in the future.
  • The most interesting part of the responses in this article are all the varied little voodoo that people use to separate the "good" developers from the "bad" developers. Some people seem to focus on the technical questions, i.e. if you can't write an algorithm that reverses a linked-list in 10 minutes, you stink. Ignoring the fact that not all languages even have linked list data structures in them. Also ignoring the fact that a lot of programming values higher level architecture and maintainability over
    • by rfc1394 ( 155777 )

      The most interesting part of the responses in this article are all the varied little voodoo that people use to separate the "good" developers from the "bad" developers. Some people seem to focus on the technical questions, i.e. if you can't write an algorithm that reverses a linked-list in 10 minutes, you stink. Ignoring the fact that not all languages even have linked list data structures in them.

      Like Cobol, which is about 70% of all programming code, according to estimates.

      Fortran doesn't have them eith

      • And come to think of it, since Java doesn't have pointers, it would stand to reason it can't have linked lists either.

        Actually Java has linked lists implemented as part of the standard library. It's a pretty dumb question in Java since all you'd do is call Collections.reverse(yourLinkedList) to reverse the LinkedList.
  • by clambake ( 37702 ) on Friday August 25, 2006 @03:17AM (#15976303) Homepage
    Part of having 20 years experience is being able to control more than just code... It means you should have learned how to wrangle people as well!

    I went to those exact same interviews that you did, the same kinds of introductory questions, the ones looking to weed out the html "programmers" who suddenly decide they can do real programming since it looks so easy.

    So, what happened to me? Basically, I was able to turn the interview on it's head, and before too long *I* was the one having /them/ draw the witeboard diagrams. It wasn't hard, it's just a way of dealing with people, something I have learned over the years:

    Interviewer: "How would you make a singleton in java?"
    Me: "Well, how does this look:"

    public class Foo {

        private static final Foo _foo = null;

        private Foo() {}

        public static Foo getInstance() {
            if (_foo == null) {
                    _foo = new Foo();
            return _foo;

    Interviewer: "Ok, good job next question..."
    Me: "Hold on a sec... Look closer at what I wrote, what did I just do wrong?"
    Interviewer: "Huh? You mean that's wrong somehow?" then I follow with explaination of what would happen if two threads reached the inside of the if statement at the same time ...
    Interviewer: "Ooooh, threading, of course. I have heard of that!"
    Me: "Yeah, so, now how could we fix it? Here's the pen, show me what could be done..." ... next start a discussion about synchronization, maybe get into Java's serious double-check-lock bug/feature (and show them with pseudo-code how the HotSpot compiler can illogically re-order execution without you ever realizing it) and then discuss how one could fix it with the new ReentrantLock class, or some of the other .concurrent.lock.* packages.

    Maybe ask if they can think of a way to implement any kind of locking without using synchronization, have them use the whiteboard and show you what they are thinking in an more abstract form, and then show them how Sun did it with the thread scheduler magic...

    And before you know it, you've stretched a thirty minute interview into a threee hour programming discussion and you get offers to join before you leave the room.

    THAT is what "experience" should have taught you, everything else you can read in a book.

    • by greg1104 ( 461138 ) <> on Friday August 25, 2006 @06:05AM (#15976706) Homepage
      This reminds me of my worst interview ever. It was for a C programming job, ten years ago. The main programmer at the company asks "how you can write a function that [some operation on an arbitrary string requiring memory] without allocating memory at run-time inside the function?". I said "you can't without relaxing some part of the requirements". He disagrees; I ask for his solution. He shows a function using a static buffer, so the memory is allocated at compile time. I point out that a) this puts a limit on the size of strings it can handle, which he accepts and b) you'll be screwed the minute you introduce that code into a multi-threaded environment like the one they deploy their code into, because your static variable will inevitably get clobbered one day by two calls to this utility function. After some argument, he comes to recognize my point, and I ultimately got offered the job.

      Three months later I was fired for arguing with him all the time about how code should be built.
    • by hyfe ( 641811 )
      Interviewer: "Ok, good job next question..." Me: "Hold on a sec... Look closer at what I wrote, what did I just do wrong?"
      So, from there on, I see two possible outcomes:

      First one is he spots the error..

      .. or worse; he doesn't and you get to come off as a condescending wise-ass who enjoy putting down others for perceived incompetence, almost without even trying!

  • I only have a couple of years experience, so I doubt my advice means much to you, but I say just go with it. Explain the simple solution that they will understand first - after all, it may be more maintainable - but mention that there are more complex solutions. It's sad, but I experience does not necessarily equate to programming ability, so they have to ask those kind of questions. I regularly see appalling mistakes in code from experienced engineers (finding the nearest multiple of X to Y using a while l
  • As companies get bigger, the "IQ" of the company begins to regress to the average for the population at large. Decisions become poorer, profits lower. It's normal, wouldn't worry about it.

  • by hal2814 ( 725639 ) on Friday August 25, 2006 @09:24AM (#15977467)
    What job were you applying for? Has it occured to you that you may be overqualified for the position if you're probably interviewing along with kids fresh from school? I've done many an interview and had to turn down plenty of overqualified candidates. Given their interests and abilities, they would've grown bored with the work we required of them very quickly even though they may be better at doing it in the short term. If they're gearing the interviews towards new grads, maybe that's for a reason.

Recent investments will yield a slight profit.