we are looking for (interview guidelines)

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

• http://steve-yegge.blogspot.com/2006/03/truth-about-interviewing.html
• http://steve.yegge.googlepages.com/google-secret-weapon
• http://steve.yegge.googlepages.com/five-essential-phone-screen-questions
• http://steve.yegge.googlepages.com/what-you-need-to-know
• http://steve.yegge.googlepages.com/why-phone-screens-matter
• http://steve.yegge.googlepages.com/miracle-interview

• http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
• http://www.joelonsoftware.com/articles/ThePhoneScreen.html
• http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html
• http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html
• http://www.joelonsoftware.com/articles/ResumeRead.html
• http://www.joelonsoftware.com/articles/HighNotes.html
• http://www.joelonsoftware.com/articles/SortingResumes.html

• http://www.artima.com/wbc/interprogP.html

• http://software.ericsink.com/bos/Hazards_of_Hiring.html
• http://software.ericsink.com/entries/No_Great_Hackers.html

• http://www.paulgraham.com/hiring.html

• http://blog.guykawasaki.com/2006/01/the_art_of_recr.html
• http://blog.guykawasaki.com/2006/03/the_art_of_recr.html
• http://blog.guykawasaki.com/2006/08/the_inside_scoo.html

• http://googleresearch.blogspot.com/2006/03/hiring-lake-wobegon-strategy.html

• http://hiring.inc.com/columns/jrothman/20050412.html

• http://www.scottberkun.com/essays/39-how-to-interview-and-hire-people/

• http://sethgodin.typepad.com/seths_blog/2006/09/the_end_of_the_.html