Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Re: Pairing during interviews?

Expand Messages
  • Eric Crampton
    ... I guess I m one of those strange people who would say, Ohama? Great! Personally, I would be really happy to be interviewed in the manner that Ken
    Message 1 of 8 , Jul 1, 2004
      On Thu, 2004-07-01 at 02:57, Ken Boucher wrote:
      > The majority of the people who decide not to interview are the ones
      > who say "Omaha? You want me to relocate to Omaha? Bwahahaha."

      I guess I'm one of those strange people who would say, "Ohama? Great!"

      Personally, I would be really happy to be interviewed in the manner that
      Ken describes. When I'm in the interviewee position, it's really hard to
      know how their development process works, the general "code
      cleanliness", how their test coverage looks, and what kinds of hurdles
      they have in their daily development (managerial? build times too long?
      undocumented code? stale code? untestable code? source code control?
      requirements problems? etc.). Anything I can do as an interviewee to
      learn these things is great.

      I think I've often asked *too many* questions as the interviewee trying
      to glean this information from a potential employer. If I can't get that
      information I want about how they do their jobs, then I won't accept the
      job.

      Having the opportunity to actually *code* with the people I'd be working
      with on a daily basis would be perfect, grueling or not!

      --Eric
    • Ken Boucher
      ... Great! If you smalltalk and you re interested, send a resume my way.
      Message 2 of 8 , Jul 1, 2004
        > I guess I'm one of those strange people who would say, "Ohama?
        Great!"

        If you smalltalk and you're interested, send a resume my way.
      • Tony Nassar
        ... Wouldn t it be a relief to find out how they code? What their code looks like? What practices they actually follow? What they re *like*? This is the *only*
        Message 3 of 8 , Jul 5, 2004
          > > Do any candidates ever reject the offer after such a grueling
          > > experience?

          Wouldn't it be a relief to find out how they code? What their code looks like? What practices they actually follow? What they're *like*? This is the *only* kind of interview I'd like to go through. Sure, I'd have to skip work for a day, but do I really want a better job or don't I?

          After struggling for a year to find a job near San Francisco, and having to suffer through quizzes, puzzles ("A king had three sons..."), technical "Gotcha!" questions, etc., I know whereof I speak. In the future I will walk out on a prospective employer if all the interviewers resort to these tactics, because <EM>there is no way to tell if I'd actually want to work there</EM>, no way to tell if they write good code (not individually, which doesn't count, but collectively), and no way to tell if I'd write good code if I went to work there.
        • Ken Boucher
          ... Even though it s off topic, I feel I need to talk a bit about these tactics, since I ve now been on the other side of the hiring table a few too many
          Message 4 of 8 , Jul 5, 2004
            --- In extremeprogramming@yahoogroups.com, Tony Nassar
            <tony.nassar@o...> wrote:
            > having to suffer through quizzes, puzzles ("A king had three
            > sons..."), technical "Gotcha!" questions, etc., I know whereof I
            > speak. In the future I will walk out on a prospective employer if
            > all the interviewers resort to these tactics, because <EM>there is
            > no way to tell if I'd actually want to work there</EM>, no way to
            > tell if they write good code (not individually, which doesn't
            > count, but collectively), and no way to tell if I'd write good code
            > if I went to work there.

            Even though it's off topic, I feel I need to talk a bit about these
            tactics, since I've now been on the other side of the hiring table a
            few too many times.

            For the most part, the programmers our organization interviews are
            not in competition with anyone else. This may change, as all things
            may, but really each person is running pretty much on their own
            merits. We've occasionally matched canidates with jobs other than the
            ones they knew about when they were a fit for one thing but not a fit
            for the job they applied for.

            But here's a quick run down of some of the things that happen and
            what this means to someone looking for a job.

            1) The resume slush pile:
            Do not make a mistake on your resume. A resume very rarely convinces
            any one to hire you. What a resume really does is give someone a
            reason to end the interview process right then and there. We need
            X,Y, and Z. Does the resume clearly indicate they have X,Y,and Z?
            Good. Are there any mistakes or anything we don't like about the
            resume? The resume is an indicator of the best work we can expect out
            of a canidate. If the best work someone can do includes a bunch of
            mistakes, well, we have other resumes and a limited amount of time.
            So really the resume isn't a "who do we include?" process. It's
            really a "who do we throw out?" process. Write and have your resume
            reviewed accordingly.

            2) The phone interview.
            The phone interview serves one purpose only. We don't want to waste
            their time and our time and everyone else's money to fly someone in
            unless we think they're a good fit. So we want to make sure the
            person knows what we're about, we know they know their stuff, we know
            that they can communicate, and we all have a happy feeling about
            this.
            The trick questions above can come into play here. We've done samurai
            java and smalltalk interviews complete with trick questions, obscure
            details, and everything else. Why? Because there aren't a lot of
            things you can find out from a phone conversation. You can get a good
            feel for someone's knowledge, someone's ability to relax, and
            someone's ability to say the words "I don't know". You can also get a
            feel for how strong someone's personality is. People who bend too far
            or can't bend at all may not be a good fit for the organization. So
            you do what you can because phone interviews are cheap and the next
            step isn't. Once again, it's a weed-out process.

            3) Onsite.
            A lot of things happen when you're onsite for the day. Everyone has
            different experiences in hiring practices and in a day you're going
            to see a lot of them. You may find yourself pairing with the shop's
            most abrasive programmer. You may find yourself discussing obscure
            forms of music. You may wonder why everyone is wearing a wig. You may
            ask yourself what the heck these people are even saying because the
            language is peppered with terms and acronyms that you've never heard
            before. You might wonder why someone just banged the gong
            (literally). Some of this is simply business as normal and other
            times it's done just to see how you react.

            Does that last bit sound strange? Read
            http://militera.lib.ru/research/suvorov6/04.html and learn the lesson
            of the towel. Think about it. And then think about all the stange
            customs a group of people who work as closely together as a agile
            shop has to might create.

            I honestly belive we now hire people as much for the person they are
            as much as for the skills they have. After all, the right person can
            learn the skills as they need to. Changing a personality on the other
            hand is much more difficult.
          • Ron Jeffries
            ... Fascinating story! Thanks! Ron Jeffries www.XProgramming.com I m not bad, I m just drawn that way. -- Jessica Rabbit
            Message 5 of 8 , Jul 5, 2004
              On Monday, July 5, 2004, at 11:33:27 AM, Ken Boucher wrote:

              > Does that last bit sound strange? Read
              > http://militera.lib.ru/research/suvorov6/04.html and learn the lesson
              > of the towel. Think about it. And then think about all the stange
              > customs a group of people who work as closely together as a agile
              > shop has to might create.

              Fascinating story! Thanks!

              Ron Jeffries
              www.XProgramming.com
              I'm not bad, I'm just drawn that way. -- Jessica Rabbit
            • Ilja Preuss
              BTW, I just read a very interesting paper on Extreme Interviewing , which included a lot of PP:
              Message 6 of 8 , Jul 7, 2004
                BTW, I just read a very interesting paper on "Extreme Interviewing",
                which included a lot of PP:

                http://menloinstitute.com/freestuff/whitepapers/extremeinterviewing.htm

                or

                http://tinyurl.com/3c583

                Cheers, Ilja
              Your message has been successfully submitted and would be delivered to recipients shortly.