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

Natural Selection of programmers

Expand Messages
  • Adam Sroka
    I ve had an opportunity to go on a number of programmer interviews in recent years. I m starting to notice some trends in the way we interview programmers that
    Message 1 of 19 , Aug 20, 2009
    • 0 Attachment
      I've had an opportunity to go on a number of programmer interviews in
      recent years. I'm starting to notice some trends in the way we
      interview programmers that disturb me. A couple of observations:

      1) Most interviewers seem to assess object-orientation skills with
      canned questions like: "What is polymorphism?" I would prefer to see
      them ask things like, "Given this description of the domain, can you
      build a model?" Using CRC, or UML, or a simple block diagram. Very few
      do.

      2) Most interviewers ask about testing in very canned way as well,
      e.g. "What perl modules do you use for testing?" They don't ask you to
      write tests, or even to explain how/why you would write them.

      3) Nearly every technical interviewer expects candidates to implement
      some data structure and/or algorithm from memory on a whiteboard. This
      is a fairly good way to determine that a person a) has memorized what
      the structures and algorithms are and how they work, b) can write
      basic procedural code, and c) can write code without tools.

      4) Nearly every technical interviewer expects candidates to write SQL
      queries involving complex joins on the whiteboard from memory. This is
      a reasonable way to determine that a person a) has memorized the
      majority of the SQL language, and b) can write queries with complex
      joins (And therefore probably will.)

      It seems to me that if we interview this way we are "naturally
      selecting" our teams for good procedural programmers who can write
      complex queries and know very little about testing or object-oriented
      programming. Further, it seems to me that many of the programmers I
      encounter when I consult somewhere as a programmer or coach, or that I
      encounter here on these Yahoo! groups asking lots of questions about
      TDD, refactoring, basic OOP stuff, etc, share these qualities.

      Are we, as an industry, expecting the wrong things from programmers?
      Are we exacerbating a gap in knowledge that starts very early in a
      programmer's career?

      If so, what should we, as an industry, do to fix this?
    • Jeff Morgan
      When a candidate arrives at our office for an interview we have him spend two hours solving a small coding problem (we give him a few choices). We then review
      Message 2 of 19 , Aug 20, 2009
      • 0 Attachment
        When a candidate arrives at our office for an interview we have him spend
        two hours solving a small coding problem (we give him a few choices). We
        then review looking for signs of TDD/BDD and good design. If he passes
        we then ask him to pair with somebody on one of the teams. This process
        has worked well for us.

        -Cheezy


        On Thu, Aug 20, 2009 at 3:34 PM, Adam Sroka<adam.sroka@...> wrote:
        >
        >
        > I've had an opportunity to go on a number of programmer interviews in
        > recent years. I'm starting to notice some trends in the way we
        > interview programmers that disturb me. A couple of observations:
        >
        > 1) Most interviewers seem to assess object-orientation skills with
        > canned questions like: "What is polymorphism?" I would prefer to see
        > them ask things like, "Given this description of the domain, can you
        > build a model?" Using CRC, or UML, or a simple block diagram. Very few
        > do.
        >
        > 2) Most interviewers ask about testing in very canned way as well,
        > e.g. "What perl modules do you use for testing?" They don't ask you to
        > write tests, or even to explain how/why you would write them.
        >
        > 3) Nearly every technical interviewer expects candidates to implement
        > some data structure and/or algorithm from memory on a whiteboard. This
        > is a fairly good way to determine that a person a) has memorized what
        > the structures and algorithms are and how they work, b) can write
        > basic procedural code, and c) can write code without tools.
        >
        > 4) Nearly every technical interviewer expects candidates to write SQL
        > queries involving complex joins on the whiteboard from memory. This is
        > a reasonable way to determine that a person a) has memorized the
        > majority of the SQL language, and b) can write queries with complex
        > joins (And therefore probably will.)
        >
        > It seems to me that if we interview this way we are "naturally
        > selecting" our teams for good procedural programmers who can write
        > complex queries and know very little about testing or object-oriented
        > programming. Further, it seems to me that many of the programmers I
        > encounter when I consult somewhere as a programmer or coach, or that I
        > encounter here on these Yahoo! groups asking lots of questions about
        > TDD, refactoring, basic OOP stuff, etc, share these qualities.
        >
        > Are we, as an industry, expecting the wrong things from programmers?
        > Are we exacerbating a gap in knowledge that starts very early in a
        > programmer's career?
        >
        > If so, what should we, as an industry, do to fix this?
        >
        >
      • Carlo Bottiglieri
        Hello, I ve noticed the same. But not everywhere, just in the majority. I think this is due to 1) the largest share of current programming culture is rooted in
        Message 3 of 19 , Aug 20, 2009
        • 0 Attachment
          Hello,
          I've noticed the same. But not everywhere, just in the majority.

          I think this is due to
          1) the largest share of current programming culture is rooted in
          procedural-centered university classes, this results in most of the
          people emulating little programming exams when devising an interview.
          2) interviewers tend to be "older" programmers who switched to
          technical management at some point in their past. This makes the
          average interviewer knowledge-base even more obsolete.

          I think that the inertia accumulated by our industry will take years
          to dissipate, but I trust it will dissipate eventually (and then there
          will likely be another kind of inertia to strive to get rid of).

          I think so because those who are recruiting with skill and sense,
          using, for instance, direct interaction with their teams to screen
          candidates, will easily outmatch their ineffective competition
          securing the best candidates and thus surviving better, on average.
          Recruiting a big-stored-procedures-programmer is probably one of the
          best company-sinking manouvers management can perform, probably it's
          on par with shotgunning the productions servers, but it's more
          expensive.

          In short, I trust that such companies (at least the small-medium ones)
          will get naturally selected just as ruthlessly as they select the
          wrong people.

          On Thu, Aug 20, 2009 at 9:34 PM, Adam Sroka<adam.sroka@...> wrote:
          >
          >
          > I've had an opportunity to go on a number of programmer interviews in
          > recent years. I'm starting to notice some trends in the way we
          > interview programmers that disturb me. A couple of observations:
          >
          > 1) Most interviewers seem to assess object-orientation skills with
          > canned questions like: "What is polymorphism?" I would prefer to see
          > them ask things like, "Given this description of the domain, can you
          > build a model?" Using CRC, or UML, or a simple block diagram. Very few
          > do.
          >
          > 2) Most interviewers ask about testing in very canned way as well,
          > e.g. "What perl modules do you use for testing?" They don't ask you to
          > write tests, or even to explain how/why you would write them.
          >
          > 3) Nearly every technical interviewer expects candidates to implement
          > some data structure and/or algorithm from memory on a whiteboard. This
          > is a fairly good way to determine that a person a) has memorized what
          > the structures and algorithms are and how they work, b) can write
          > basic procedural code, and c) can write code without tools.
          >
          > 4) Nearly every technical interviewer expects candidates to write SQL
          > queries involving complex joins on the whiteboard from memory. This is
          > a reasonable way to determine that a person a) has memorized the
          > majority of the SQL language, and b) can write queries with complex
          > joins (And therefore probably will.)
          >
          > It seems to me that if we interview this way we are "naturally
          > selecting" our teams for good procedural programmers who can write
          > complex queries and know very little about testing or object-oriented
          > programming. Further, it seems to me that many of the programmers I
          > encounter when I consult somewhere as a programmer or coach, or that I
          > encounter here on these Yahoo! groups asking lots of questions about
          > TDD, refactoring, basic OOP stuff, etc, share these qualities.
          >
          > Are we, as an industry, expecting the wrong things from programmers?
          > Are we exacerbating a gap in knowledge that starts very early in a
          > programmer's career?
          >
          > If so, what should we, as an industry, do to fix this?
          >
          >
        • George Dinwiddie
          ... I ve learned much about interviewing from Johanna Rothman. And I highly suggest some sort of audition. Cheezy offers one sort of audition. If you go
          Message 4 of 19 , Aug 20, 2009
          • 0 Attachment
            Adam Sroka wrote:
            > I've had an opportunity to go on a number of programmer interviews in
            > recent years. I'm starting to notice some trends in the way we
            > interview programmers that disturb me.

            I've learned much about interviewing from Johanna Rothman. And I highly
            suggest some sort of audition. Cheezy offers one sort of audition. If
            you go through http://jrothman.com/blog/mpd/ I'm sure you'll find other
            ideas.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Adam Sroka
            I m all for auditions. I have done them, and I recommend them. The topic has been discussed here at length in the past. The question I m really asking is not
            Message 5 of 19 , Aug 20, 2009
            • 0 Attachment
              I'm all for auditions. I have done them, and I recommend them. The
              topic has been discussed here at length in the past.

              The question I'm really asking is not how we interview better, but how
              do we convince people that they are asking the wrong questions? And,
              that asking different questions might actually get them what they
              (purport to) want?

              On Thu, Aug 20, 2009 at 1:38 PM, George
              Dinwiddie<lists@...> wrote:
              >
              >
              > Adam Sroka wrote:
              >> I've had an opportunity to go on a number of programmer interviews in
              >> recent years. I'm starting to notice some trends in the way we
              >> interview programmers that disturb me.
              >
              > I've learned much about interviewing from Johanna Rothman. And I highly
              > suggest some sort of audition. Cheezy offers one sort of audition. If
              > you go through http://jrothman.com/blog/mpd/ I'm sure you'll find other
              > ideas.
              >
              > - George
              >
              > --
              > ----------------------------------------------------------
              > * George Dinwiddie * http://blog.gdinwiddie.com
              > Software Development http://www.idiacomputing.com
              > Consultant and Coach http://www.agilemaryland.org
              > ----------------------------------------------------------
              >
              >
            • Phlip
              ... You have the unqualified to interview me problem. I would _really_ like to learn how some gurus around here can just skate thru that one!! -- Phlip
              Message 6 of 19 , Aug 20, 2009
              • 0 Attachment
                Adam Sroka wrote:

                > I've had an opportunity to go on a number of programmer interviews in
                > recent years. I'm starting to notice some trends in the way we
                > interview programmers that disturb me. A couple of observations:

                You have the "unqualified to interview me" problem.

                I would _really_ like to learn how some gurus around here can just skate thru
                that one!!

                --
                Phlip
                http://flea.sourceforge.net/resume.html
              • George Dinwiddie
                ... http://anarchycreek.com/2009/08/19/what-would-gisele-do/ -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software Development
                Message 7 of 19 , Aug 20, 2009
                • 0 Attachment
                  Adam Sroka wrote:
                  > I'm all for auditions. I have done them, and I recommend them. The
                  > topic has been discussed here at length in the past.
                  >
                  > The question I'm really asking is not how we interview better, but how
                  > do we convince people that they are asking the wrong questions? And,
                  > that asking different questions might actually get them what they
                  > (purport to) want?

                  http://anarchycreek.com/2009/08/19/what-would-gisele-do/

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • Dale Emery
                  Hi Adam, You have the unqualified to interview me problem. ... Such interviewers have the unqualified to evaluate my contribution problem. I don t want to
                  Message 8 of 19 , Aug 20, 2009
                  • 0 Attachment
                    Hi Adam,

                    You have the "unqualified to interview me" problem.
                    >
                    > I would _really_ like to learn how some gurus around here can just skate
                    > thru that one!!


                    Such interviewers have the "unqualified to evaluate my contribution"
                    problem. I don't want to work with people like that, so those interview
                    questions solve my problem immediately.

                    Dale

                    --
                    Dale Emery
                    Consultant to software teams and leaders
                    Web: http://dhemery.com
                    Weblog: http://cwd.dhemery.com


                    [Non-text portions of this message have been removed]
                  • Adam Sroka
                    ... That s one solution. I ve certainly walked out of these sort of interviews and thought, They re not going to call me after that, and I don t want them
                    Message 9 of 19 , Aug 20, 2009
                    • 0 Attachment
                      On Thu, Aug 20, 2009 at 3:14 PM, Dale Emery<dale@...> wrote:
                      >
                      >
                      > Hi Adam,
                      >
                      > You have the "unqualified to interview me" problem.
                      >>
                      >> I would _really_ like to learn how some gurus around here can just skate
                      >> thru that one!!
                      >
                      > Such interviewers have the "unqualified to evaluate my contribution"
                      > problem. I don't want to work with people like that, so those interview
                      > questions solve my problem immediately.
                      >

                      That's one solution. I've certainly walked out of these sort of
                      interviews and thought, "They're not going to call me after that, and
                      I don't want them to."

                      Another solution is to not engage clients who are interested in me
                      purely as a programmer. To go in and say, "I'm a coach. What I do is
                      help you to implement these practices by working closely with your
                      team." That has worked well for a lot of people in this community.

                      The problem I see with both of those approaches is it closes off a
                      (large) number of places that could really use and maybe even want our
                      help. There are differences between needing help, wanting help, and
                      knowing how to ask for help. Do we really want to say that we will not
                      help those who haven't learned how to ask for it yet? (Maybe the
                      answer is yes. I don't know.)

                      Finally, another strategy is to team up with people who are effective
                      at organizational change. Let them be the ones to convince people that
                      they want to do things differently. Then they can say, "I know this
                      guy who is really good at /actually doing it/ this way. Let me bring
                      him in." That is the strategy that I am trying now, but it's too soon
                      to say whether it really works for me or not.

                      I really don't want to personalize this too much (too late?) What I
                      want to know is how convince people in the software business that what
                      they want are skilled object-oriented programmers who can effectively
                      employ the strategies/techniques/practices that we discuss in places
                      like this list. That to find those people they need to stop asking the
                      wrong questions and start asking the right ones. And, that once they
                      have the right people asking the right questions the changes that they
                      want to happen will happen and it won't hurt as much.
                    • Tim Ottinger
                      ... UML domain analysis models. How quaint. I used to do those. Is this test to prove that the programmer is old and/or out of touch? ... Of course.
                      Message 10 of 19 , Aug 20, 2009
                      • 0 Attachment
                        > 1) Most interviewers seem to assess object-orientation skills with
                        > canned questions like: "What is polymorphism?" I would prefer to see
                        > them ask things like, "Given this description of the domain, can you
                        > build a model?" Using CRC, or UML, or a simple block diagram. Very few
                        > do.

                        UML domain analysis models. How quaint. I used to do those. Is this
                        test to prove that the programmer is old and/or out of touch?


                        > Are we, as an industry, expecting the wrong things from programmers?
                        > Are we exacerbating a gap in knowledge that starts very early in a
                        > programmer's career?

                        Of course. Especially when the people doing the interviewing are not
                        the people doing the work, and we don't interview by watching someone
                        actually doing work.

                        > If so, what should we, as an industry, do to fix this?

                        Stop letting HR interview our programmers?
                        Insist on pair-coding instead of test questions?
                        Apprentice instead of interviewing?

                        Tim Ottinger
                        http://agileinaflash.blogspot.com/
                        http://agileotter.blogspot.com/
                      • Chris Wheeler
                        ... Most programmers I know spend the bulk of their day programming. I think it s valid to ask questions about programming languages and technologies and
                        Message 11 of 19 , Aug 20, 2009
                        • 0 Attachment
                          On Thu, Aug 20, 2009 at 3:34 PM, Adam Sroka <adam.sroka@...> wrote:

                          > I've had an opportunity to go on a number of programmer interviews in
                          > recent years. I'm starting to notice some trends in the way we
                          > interview programmers that disturb me. A couple of observations:
                          >
                          > 3) Nearly every technical interviewer expects candidates to implement
                          > some data structure and/or algorithm from memory on a whiteboard. This
                          > is a fairly good way to determine that a person a) has memorized what
                          > the structures and algorithms are and how they work, b) can write
                          > basic procedural code, and c) can write code without tools.
                          >

                          Most programmers I know spend the bulk of their day programming. I think
                          it's valid to ask questions about programming languages and technologies and
                          expect that your candidates will answer them correctly.

                          Chris.


                          [Non-text portions of this message have been removed]
                        • Adam Sroka
                          ... I don t think being able to do basic domain analysis is quaint. I hope you don t think that either. As for UML, it is a perfectly valid and useful notation
                          Message 12 of 19 , Aug 20, 2009
                          • 0 Attachment
                            On Thu, Aug 20, 2009 at 6:15 PM, Tim Ottinger<linux_tim@...> wrote:
                            >
                            >
                            >> 1) Most interviewers seem to assess object-orientation skills with
                            >> canned questions like: "What is polymorphism?" I would prefer to see
                            >> them ask things like, "Given this description of the domain, can you
                            >> build a model?" Using CRC, or UML, or a simple block diagram. Very few
                            >> do.
                            >
                            > UML domain analysis models. How quaint. I used to do those. Is this
                            > test to prove that the programmer is old and/or out of touch?
                            >

                            :-)

                            I don't think being able to do basic domain analysis is quaint. I hope
                            you don't think that either. As for UML, it is a perfectly valid and
                            useful notation as long as you don't get too exceedingly detailed.
                            Personally I prefer CRC to other methods, and I'm only in my thirties
                            ;-)

                            >> Are we, as an industry, expecting the wrong things from programmers?
                            >> Are we exacerbating a gap in knowledge that starts very early in a
                            >> programmer's career?
                            >
                            > Of course. Especially when the people doing the interviewing are not
                            > the people doing the work, and we don't interview by watching someone
                            > actually doing work.
                            >

                            Most of the time technical interviewers actually are engineers on the
                            team. The problem isn't that they are out of touch with programming.
                            The problem is either a) they don't know how to interview or b) they
                            think these sorts of questions actually pertain or c) all of the
                            above.

                            >> If so, what should we, as an industry, do to fix this?
                            >
                            > Stop letting HR interview our programmers?
                            > Insist on pair-coding instead of test questions?
                            > Apprentice instead of interviewing?
                            >

                            Yes. Yes. Yes.
                          • Adam Sroka
                            On Thu, Aug 20, 2009 at 6:25 PM, Chris ... In no way did I suggest differently. And I am offended by the way you have paraphrased me. You took out just enough
                            Message 13 of 19 , Aug 20, 2009
                            • 0 Attachment
                              On Thu, Aug 20, 2009 at 6:25 PM, Chris
                              Wheeler<christopher.wheeler@...> wrote:
                              >
                              >
                              > On Thu, Aug 20, 2009 at 3:34 PM, Adam Sroka <adam.sroka@...> wrote:
                              >
                              >> I've had an opportunity to go on a number of programmer interviews in
                              >> recent years. I'm starting to notice some trends in the way we
                              >> interview programmers that disturb me. A couple of observations:
                              >>
                              >> 3) Nearly every technical interviewer expects candidates to implement
                              >> some data structure and/or algorithm from memory on a whiteboard. This
                              >> is a fairly good way to determine that a person a) has memorized what
                              >> the structures and algorithms are and how they work, b) can write
                              >> basic procedural code, and c) can write code without tools.
                              >>
                              >
                              > Most programmers I know spend the bulk of their day programming. I think
                              > it's valid to ask questions about programming languages and technologies and
                              > expect that your candidates will answer them correctly.
                              >

                              In no way did I suggest differently. And I am offended by the way you
                              have paraphrased me. You took out just enough context to make it seem
                              like I said something I didn't say.

                              There is nothing wrong with asking questions about algorithms. There
                              is absolutely something wrong with 1) emphasizing rote memorization of
                              algorithms and syntax 2) treating the whiteboard as indicative of the
                              way someone actually codes 3) emphasizing procedural coding to the
                              near or total exclusion of OO and testing when the job description
                              indicates the opposite.
                            • Chris Wheeler
                              ... Not really - I shortened it up so I could respond. The full text of your OP is archived in this group, and in most members inboxes. It s too bad you chose
                              Message 14 of 19 , Aug 20, 2009
                              • 0 Attachment
                                On Thu, Aug 20, 2009 at 9:50 PM, Adam Sroka <adam.sroka@...> wrote:

                                >
                                > In no way did I suggest differently. And I am offended by the way you
                                > have paraphrased me. You took out just enough context to make it seem
                                > like I said something I didn't say.


                                Not really - I shortened it up so I could respond. The full text of your OP
                                is archived in this group, and in most members inboxes. It's too bad you
                                chose to take offense, but your original post was really too long to include
                                in it's entirety.

                                >
                                >
                                > There is nothing wrong with asking questions about algorithms. There
                                > is absolutely something wrong with 1) emphasizing rote memorization of
                                > algorithms and syntax


                                I've never encountered this. I've asked questions, and have been asked
                                questions, about algorithms to test problem-solving skills. In fact, I've
                                had people ask for help in interviews, and I'm inclined to think that was a
                                perfect response. I've never expected,nor been expected, to have any
                                algorithm memorized. And,in my whole career, I've never memorized any
                                algorithm.


                                > 2) treating the whiteboard as indicative of the
                                > way someone actually codes


                                It's a half decent way to determine if the person is resume padding or is a
                                serious programmer. I'm not looking for perfection, but I'm also looking for
                                blank stares and C++ that resembles C++, not Java.



                                > 3) emphasizing procedural coding to the
                                > near or total exclusion of OO and testing when the job description
                                > indicates the opposite.


                                I guess your mileage may vary on this one.

                                Places that hire really smart people ask really tough questions to test
                                technical aptitude and to test problem solving skills under pressure. I
                                think universes exist where it is possible that programmers in interviews
                                misinterpret a question about sorting as, "Gee, I didn't know I'd have to
                                know how to implement bubble sort" rather than thinking, "Hmmm, I can't
                                recall bubble sort, but let's see if I can show how I'd solve a problem I
                                don't know the answer to".

                                I guess it goes both ways....

                                Chris.


                                [Non-text portions of this message have been removed]
                              • D. André Dhondt
                                ... Recently I do phone screens and evaluate the company before I get to the face-to-face interview... and the agile shops, the truly committed ones, don t
                                Message 15 of 19 , Aug 20, 2009
                                • 0 Attachment
                                  >If so, what should we, as an industry, do to fix this?

                                  Recently I do phone screens and evaluate the company before I get to the
                                  face-to-face interview... and the agile shops, the truly committed ones,
                                  don't interview like what you've described... it's more likely to be an
                                  audition/pair programming session. I ask a lot of questions up front to
                                  make sure the company values what I do, and prospective employers love this.
                                  It seems like the more I ask, the less they ask, and the more it's an
                                  interview to see if I want to work there, as opposed to them finding out if
                                  they want to hire me.

                                  On Thu, Aug 20, 2009 at 9:34 PM, Adam Sroka <adam.sroka@...> wrote:

                                  >
                                  >
                                  > I've had an opportunity to go on a number of programmer interviews in
                                  > recent years. I'm starting to notice some trends in the way we
                                  > interview programmers that disturb me. A couple of observations:
                                  >
                                  > 1) Most interviewers seem to assess object-orientation skills with
                                  > canned questions like: "What is polymorphism?" I would prefer to see
                                  > them ask things like, "Given this description of the domain, can you
                                  > build a model?" Using CRC, or UML, or a simple block diagram. Very few
                                  > do.
                                  >
                                  > 2) Most interviewers ask about testing in very canned way as well,
                                  > e.g. "What perl modules do you use for testing?" They don't ask you to
                                  > write tests, or even to explain how/why you would write them.
                                  >
                                  > 3) Nearly every technical interviewer expects candidates to implement
                                  > some data structure and/or algorithm from memory on a whiteboard. This
                                  > is a fairly good way to determine that a person a) has memorized what
                                  > the structures and algorithms are and how they work, b) can write
                                  > basic procedural code, and c) can write code without tools.
                                  >
                                  > 4) Nearly every technical interviewer expects candidates to write SQL
                                  > queries involving complex joins on the whiteboard from memory. This is
                                  > a reasonable way to determine that a person a) has memorized the
                                  > majority of the SQL language, and b) can write queries with complex
                                  > joins (And therefore probably will.)
                                  >
                                  > It seems to me that if we interview this way we are "naturally
                                  > selecting" our teams for good procedural programmers who can write
                                  > complex queries and know very little about testing or object-oriented
                                  > programming. Further, it seems to me that many of the programmers I
                                  > encounter when I consult somewhere as a programmer or coach, or that I
                                  > encounter here on these Yahoo! groups asking lots of questions about
                                  > TDD, refactoring, basic OOP stuff, etc, share these qualities.
                                  >
                                  > Are we, as an industry, expecting the wrong things from programmers?
                                  > Are we exacerbating a gap in knowledge that starts very early in a
                                  > programmer's career?
                                  >
                                  > If so, what should we, as an industry, do to fix this?
                                  >
                                  >



                                  --
                                  D. André Dhondt
                                  mobile: 001 33 671 034 984
                                  http://dhondtsayitsagile.blogspot.com/

                                  Support low-cost conferences -- http://agiletour.org/


                                  [Non-text portions of this message have been removed]
                                • Nick Korbel
                                  ... Take a look at some companies with high employee retention and satisfaction (Zappos springs to mind). The interview process is critical to these
                                  Message 16 of 19 , Aug 20, 2009
                                  • 0 Attachment
                                    >
                                    > The question I'm really asking is not how we interview better, but how
                                    > do we convince people that they are asking the wrong questions? And,
                                    > that asking different questions might actually get them what they
                                    > (purport to) want?


                                    Take a look at some companies with high employee retention and satisfaction
                                    (Zappos springs to mind). The interview process is critical to these
                                    companies. Even though the interview process is a decent upfront
                                    investment, it really pays off in the success of the company as a whole.

                                    We do many of the same things that have been mentioned here (phone screen,
                                    coding example, whole team interview) and we've built a very tight and
                                    talented team. On top of that, we've had 0 people leave, which makes our HR
                                    department pretty happy.

                                    Nick

                                    On Thu, Aug 20, 2009 at 9:14 PM, D. André Dhondt
                                    <d.andre.dhondt@...>wrote:

                                    >
                                    >
                                    > >If so, what should we, as an industry, do to fix this?
                                    >
                                    > Recently I do phone screens and evaluate the company before I get to the
                                    > face-to-face interview... and the agile shops, the truly committed ones,
                                    > don't interview like what you've described... it's more likely to be an
                                    > audition/pair programming session. I ask a lot of questions up front to
                                    > make sure the company values what I do, and prospective employers love
                                    > this.
                                    > It seems like the more I ask, the less they ask, and the more it's an
                                    > interview to see if I want to work there, as opposed to them finding out if
                                    > they want to hire me.
                                    >
                                    >
                                    > On Thu, Aug 20, 2009 at 9:34 PM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>>
                                    > wrote:
                                    >
                                    > >
                                    > >
                                    > > I've had an opportunity to go on a number of programmer interviews in
                                    > > recent years. I'm starting to notice some trends in the way we
                                    > > interview programmers that disturb me. A couple of observations:
                                    > >
                                    > > 1) Most interviewers seem to assess object-orientation skills with
                                    > > canned questions like: "What is polymorphism?" I would prefer to see
                                    > > them ask things like, "Given this description of the domain, can you
                                    > > build a model?" Using CRC, or UML, or a simple block diagram. Very few
                                    > > do.
                                    > >
                                    > > 2) Most interviewers ask about testing in very canned way as well,
                                    > > e.g. "What perl modules do you use for testing?" They don't ask you to
                                    > > write tests, or even to explain how/why you would write them.
                                    > >
                                    > > 3) Nearly every technical interviewer expects candidates to implement
                                    > > some data structure and/or algorithm from memory on a whiteboard. This
                                    > > is a fairly good way to determine that a person a) has memorized what
                                    > > the structures and algorithms are and how they work, b) can write
                                    > > basic procedural code, and c) can write code without tools.
                                    > >
                                    > > 4) Nearly every technical interviewer expects candidates to write SQL
                                    > > queries involving complex joins on the whiteboard from memory. This is
                                    > > a reasonable way to determine that a person a) has memorized the
                                    > > majority of the SQL language, and b) can write queries with complex
                                    > > joins (And therefore probably will.)
                                    > >
                                    > > It seems to me that if we interview this way we are "naturally
                                    > > selecting" our teams for good procedural programmers who can write
                                    > > complex queries and know very little about testing or object-oriented
                                    > > programming. Further, it seems to me that many of the programmers I
                                    > > encounter when I consult somewhere as a programmer or coach, or that I
                                    > > encounter here on these Yahoo! groups asking lots of questions about
                                    > > TDD, refactoring, basic OOP stuff, etc, share these qualities.
                                    > >
                                    > > Are we, as an industry, expecting the wrong things from programmers?
                                    > > Are we exacerbating a gap in knowledge that starts very early in a
                                    > > programmer's career?
                                    > >
                                    > > If so, what should we, as an industry, do to fix this?
                                    > >
                                    > >
                                    >
                                    > --
                                    > D. André Dhondt
                                    > mobile: 001 33 671 034 984
                                    > http://dhondtsayitsagile.blogspot.com/
                                    >
                                    > Support low-cost conferences -- http://agiletour.org/
                                    >
                                    > [Non-text portions of this message have been removed]
                                    >
                                    >
                                    >


                                    [Non-text portions of this message have been removed]
                                  • Adam Sroka
                                    On Thu, Aug 20, 2009 at 7:12 PM, Chris ... Sorry. Offense was too strong. By quoting it the way you did, and then responding the way you did, I feel that you
                                    Message 17 of 19 , Aug 20, 2009
                                    • 0 Attachment
                                      On Thu, Aug 20, 2009 at 7:12 PM, Chris
                                      Wheeler<christopher.wheeler@...> wrote:
                                      >
                                      >
                                      > On Thu, Aug 20, 2009 at 9:50 PM, Adam Sroka <adam.sroka@...> wrote:
                                      >
                                      >>
                                      >> In no way did I suggest differently. And I am offended by the way you
                                      >> have paraphrased me. You took out just enough context to make it seem
                                      >> like I said something I didn't say.
                                      >
                                      > Not really - I shortened it up so I could respond. The full text of your OP
                                      > is archived in this group, and in most members inboxes. It's too bad you
                                      > chose to take offense, but your original post was really too long to include
                                      > in it's entirety.
                                      >

                                      Sorry. "Offense" was too strong. By quoting it the way you did, and
                                      then responding the way you did, I feel that you have
                                      mis-characterized what I was trying to say.

                                      >>
                                      >>
                                      >> There is nothing wrong with asking questions about algorithms. There
                                      >> is absolutely something wrong with 1) emphasizing rote memorization of
                                      >> algorithms and syntax
                                      >
                                      > I've never encountered this. I've asked questions, and have been asked
                                      > questions, about algorithms to test problem-solving skills. In fact, I've
                                      > had people ask for help in interviews, and I'm inclined to think that was a
                                      > perfect response. I've never expected,nor been expected, to have any
                                      > algorithm memorized. And,in my whole career, I've never memorized any
                                      > algorithm.
                                      >

                                      Your experience differs from mine. I think that it is good that you
                                      have never memorized nor been asked to memorize an algorithm. I don't
                                      think it is a terribly good use for your brain to do so.

                                      >> 2) treating the whiteboard as indicative of the
                                      >> way someone actually codes
                                      >
                                      > It's a half decent way to determine if the person is resume padding or is a
                                      > serious programmer. I'm not looking for perfection, but I'm also looking for
                                      > blank stares and C++ that resembles C++, not Java.
                                      >

                                      fair enough. It might be a useful tool. The crux of my argument is
                                      that it should not be *the* tool.

                                      >> 3) emphasizing procedural coding to the
                                      >> near or total exclusion of OO and testing when the job description
                                      >> indicates the opposite.
                                      >
                                      > I guess your mileage may vary on this one.
                                      >
                                      > Places that hire really smart people ask really tough questions to test
                                      > technical aptitude and to test problem solving skills under pressure. I
                                      > think universes exist where it is possible that programmers in interviews
                                      > misinterpret a question about sorting as, "Gee, I didn't know I'd have to
                                      > know how to implement bubble sort" rather than thinking, "Hmmm, I can't
                                      > recall bubble sort, but let's see if I can show how I'd solve a problem I
                                      > don't know the answer to".
                                      >
                                      > I guess it goes both ways....
                                      >

                                      I think it is good to ask tough questions. I think it is good to
                                      expect people to know how to write code and to solve problems, etc.
                                      What I am objecting to is placing what I perceive as a
                                      disproportionate emphasis on certain types of questions (tough or
                                      otherwise). I feel that the inevitable result is that people with the
                                      wrong balance of skills are successful.

                                      To be clear, I mentioned four lines of inquiry in my initial post. I
                                      feel that the first two are not emphasized enough and the latter two
                                      are emphasized too much. I do not mean to suggest that any of the four
                                      lines (Nor various others) should be off limits.
                                    • davenicolette
                                      +1 to that. The team I m presently coaching has started to do auditions for new candidates. They had some problems before with people who were skilled at
                                      Message 18 of 19 , Aug 23, 2009
                                      • 0 Attachment
                                        +1 to that. The team I'm presently coaching has started to do auditions for new candidates. They had some problems before with people who were skilled at interviewing, but less skilled at the actual work. Now they're much more successful at finding suitable team-mates to grow the team.

                                        Dave

                                        --- In extremeprogramming@yahoogroups.com, Jeff Morgan <kuzman@...> wrote:
                                        >
                                        > When a candidate arrives at our office for an interview we have him spend
                                        > two hours solving a small coding problem (we give him a few choices). We
                                        > then review looking for signs of TDD/BDD and good design. If he passes
                                        > we then ask him to pair with somebody on one of the teams. This process
                                        > has worked well for us.
                                        >
                                        > -Cheezy
                                        >
                                        >
                                        > On Thu, Aug 20, 2009 at 3:34 PM, Adam Sroka<adam.sroka@...> wrote:
                                        > >
                                        > >
                                        > > I've had an opportunity to go on a number of programmer interviews in
                                        > > recent years. I'm starting to notice some trends in the way we
                                        > > interview programmers that disturb me. A couple of observations:
                                        > >
                                        > > 1) Most interviewers seem to assess object-orientation skills with
                                        > > canned questions like: "What is polymorphism?" I would prefer to see
                                        > > them ask things like, "Given this description of the domain, can you
                                        > > build a model?" Using CRC, or UML, or a simple block diagram. Very few
                                        > > do.
                                        > >
                                        > > 2) Most interviewers ask about testing in very canned way as well,
                                        > > e.g. "What perl modules do you use for testing?" They don't ask you to
                                        > > write tests, or even to explain how/why you would write them.
                                        > >
                                        > > 3) Nearly every technical interviewer expects candidates to implement
                                        > > some data structure and/or algorithm from memory on a whiteboard. This
                                        > > is a fairly good way to determine that a person a) has memorized what
                                        > > the structures and algorithms are and how they work, b) can write
                                        > > basic procedural code, and c) can write code without tools.
                                        > >
                                        > > 4) Nearly every technical interviewer expects candidates to write SQL
                                        > > queries involving complex joins on the whiteboard from memory. This is
                                        > > a reasonable way to determine that a person a) has memorized the
                                        > > majority of the SQL language, and b) can write queries with complex
                                        > > joins (And therefore probably will.)
                                        > >
                                        > > It seems to me that if we interview this way we are "naturally
                                        > > selecting" our teams for good procedural programmers who can write
                                        > > complex queries and know very little about testing or object-oriented
                                        > > programming. Further, it seems to me that many of the programmers I
                                        > > encounter when I consult somewhere as a programmer or coach, or that I
                                        > > encounter here on these Yahoo! groups asking lots of questions about
                                        > > TDD, refactoring, basic OOP stuff, etc, share these qualities.
                                        > >
                                        > > Are we, as an industry, expecting the wrong things from programmers?
                                        > > Are we exacerbating a gap in knowledge that starts very early in a
                                        > > programmer's career?
                                        > >
                                        > > If so, what should we, as an industry, do to fix this?
                                        > >
                                        > >
                                        >
                                      • Adrian Howard
                                        ... +N for large values of N Every time I do a round of developer interviews I m amazed by folks who can fool me into thinking they re good at development
                                        Message 19 of 19 , Aug 23, 2009
                                        • 0 Attachment
                                          On 23 Aug 2009, at 14:50, davenicolette wrote:

                                          > +1 to that. The team I'm presently coaching has started to do
                                          > auditions for new candidates. They had some problems before with
                                          > people who were skilled at interviewing, but less skilled at the
                                          > actual work. Now they're much more successful at finding suitable
                                          > team-mates to grow the team.

                                          +N for large values of N

                                          Every time I do a round of developer interviews I'm amazed by folks
                                          who can fool me into thinking they're good at development until we put
                                          them in front of an editor.

                                          Adrian
                                          --
                                          http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                                        Your message has been successfully submitted and would be delivered to recipients shortly.