we are looking for (interview guidelines)

Posted by anton
on Friday, June 29, 2007

this is something transferred from an internal wiki; i just finished "professional software development" at the time and some of its ideas found their way into the post. granted this is mostly talk, and the hardest part (the skill and the art!) is actually being able to sense all of this in a conversation. usual disclaimers - this was an architecture team for a big company, but suspend all the negative connotations associated with the title (this by itself is a topic for a whole post).

another disclaimer: our technical problems were not that hard at all, so we needed someone with solid CS background and software engineering background (source control, testing, builds, etc). everything else technology-wise is easy to teach, given the right personality. which means that in our case personality is far more important that any skills above the basic ones.

what we are looking for: in general

  • hands-on
  • strong current technical skills
  • solid technical foundation (CS/engineering/years of various hands-on)
  • wide breadth of knowledge and experience
  • ability to see direction, high-level design, and at the same time to be able and jump in to do development/troubleshooting. naturally people will be skewed one or the other way, but presence of both is important
  • passion - they do this stuff in their spare time, they read blogs/articles, they buy books, they go to conferences; they are excited to babble about it
  • smart (do not create busy work and slave for 24/7; ask me about "pray-and-rerun for 72 hrs" some time)
  • gets stuff done (ability to drive stuff to completion, not just fluffy ideas)
  • good match for the team culturally (openness, desire to share and learn)
  • self-starter - actively seek solutions, actively challenge status quo
  • learns fast
  • fast-paced
  • balance of operations/design/architecture/implementation/support/business knowledge
  • articulate (can explain a bigger picture for the project they've worked on; can explain complex concepts at high-level, easy to talk to, etc)

here's a little personal observation regarding the last point - past few months i've been on both sides of the interviewing fence and it is interesting to note that with good people the conversation just flows - infact during some of the interviews i come up with some interesting ideas as i am talking through things - the sparks fly, the air sizzles, and i am truly enjoying it, no matter which side of the table i am on. at the same time with stupidthicker people i find myself getting dumber and dumber - i start stuttering, repeating myself, going into unnecessary details, eventualy getting frustrated and discouraged. i know it is a problem of mine to an extent, but i think over the years i have come to treat it as a rather objective indicator of how well a person can fit in a team with me.

what we are looking for: great designers

  • have a list of patterns they can apply to solve problems (they've been around the block a few times and know a few things)
  • mastery of their toolset (they have a toolset, they know what to use when, and they actually do it)
  • seek out criticism (do not hide in the corner and spew binaries from time to time - they come out into the open and demand feedback)
  • strive to reduce complexity (make it as simple as possible, so that bugs have nowhere to hide; this is a great skill and i am fortunate to know a few folks that truly shine at it, cutting through layers of bullshit and communication problems)
  • have experience on failed projects and made a point to learn from it (or any mistakes - true learning does not come from the manuals that teach you how things are supposed to work, but from real life lessons that teach you when stuff does not work and why)
  • have a lot of alternatives, often wrong, but quickly correct themselves (a great designer should be able to generate ideas)
  • they keep trying alternatives even when others have given up - i.e. do not give up easily or settle with "this would do" - drive to completion, try other options (this is a great trait and i often have to kick myself to strive for it)
  • not afraid of using brute force (i.e. pragmatic)
  • creative to be able to generate numerous solutions (didn't i just say that above?)
  • curious (must always try to learn, figure out how things work, research, investigate, never settle for "someone else knows how it works" - always ask questions; this could be one of the single most important traits)
  • high energy (not sleepy, lazy - driven to get stuff done; also see curiosity)
  • self-confident and independent to research things that others think are silly, unworkable, foolish (i've been burned by this)
  • have and value their own judgment (see above) - never refer to "this is what someone else told me, or this is not my fault, this is what i have been told" but never made an effort to verify
  • restless desire to create - build things, make things work, figure things out, tinker
  • not satisfied to merely learn facts - but driven to apply them (sometimes i catch myself doing just that)
  • no lone heroes - we need those that can raise the value of a team, work with others, be open (share their knowledge, willing to teach, to educate, and to be taught and educated). ''according to many studies the greatest contributor to overall prductivity was team cohesiveness, not the individual heroes'' says mr. mcconnell (also, keep in mind the bus factor)
  • community involvement (reading books, publications, blogs, magazines, attending and speaking at a conferences) - all of it is a sign of a commitment, treating this as a profession which does require life-long learning (so in the end it is merely a sign of professionalism, not something that is out of the ordinary); of course beware of talkers that do just that
  • do not fall into complacency - always strive to improve (too many that would not challenge themselves and others, settle down)

related reading

Comments

Leave a response

  1. Simon GranthamFebruary 26, 2008 @ 04:07 AM
    Just belatedly ran across this, so please feel free to email me if you want some additional interview guidelines as I have had good success hiring techies (takes 1 to know 1). Having 35 years experience, I've pretty much seen it all and what you are looking for is great implementors not designers. E.g. anyone with a modicum of understanding of software can do a half decent design. KISS is in the implementation. I don't have enough fingers to count how many times, being requested to add a feature to some other developer's application, and that started from a reasonable design, had to do the following because I didn't want to be responsible for ongoing maintenance. 1. figure out what were the actual pieces that did the application 2. throw out the pieces that were managing the other pieces (usually about 50 percent) 3. reorganize the remaining into a simple, reliable application Besides the usual "can write code" skill, what you are looking for is a skill that happens to cover both technical and some of the "soft skills" you want (more on the latter following). This skill is the quick understanding of the dependencies of things and then reducing them to, only, direct dependencies. This was the point of creations like OOP and database normalization, and finite state machines. But, it so hard for people to learn because what people learn from is libraries (JDK libs, C# libs, swing, MFC, etc.). These aid and abet bad implementation. When you have this reductionist skill, you tend to avoid the kind of ego that goes with "I'm the best java jockey around" because, instead of being all puffed up at what you can build based on everybody else's libraries, you are aware of the unique set of dependencies every situation has and respond accordingly. This is also the troubleshooting skill. Everything affects everything, just like chaos theory, but there is always a chain of direct dependencies. If you recognize them quickly the problem has the signature of the specific dependencies involved. If you don't, you know how to recursively divide the dependencies in half to isolate the problem. So how do you interview. 1. Test the veracity of their resume by asking a technical question of scope. E.g. Resume says multi-threaded applications, question is, "how would you implement a thread factory". 2. Ask any questions and see how they observe and highlight the dependencies in their answers. 3. Observer their passion for chasing down solutions without big ego being part of the response. "For want of a nail, the war was lost", Simon