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

social networks in large companies

Posted by anton
on Wednesday, June 27, 2007

i came to realize it gradually over the course of past few years, but i could not quite articulate it until i read this passage in "slack" by tom demarco:

Surprisingly, the stars approached their work in ways that were not very different from the ways their peers did. As a purely mechanical matter, they did the same work pretty much the same way as everyone else. But there were marked differences in how they managed their networks of connections, liaisons to fellow workers whose cooperation was required to get anything done. For example, people tended to return the stars' telephone calls much more quickly. So a star, on average, would receive answers in twenty minutes, while the norm for the whole laboratory was more like four hours. Why did they get better attention from coworkers and colleagues? There was no obvious answer, but they did. Clearly, the stars had long before taken whatever steps were necessary to establish good connections. They had spread around favors, been responsive themselves, nursed relationships, seen to other people's essential human needs.

granted, all disclaimers apply - one has to work in a role that requires interaction with other people to get stuff done, the organization should be large enough, etc.

my experience confirms this - in large organizations you have to know the right people to get stuff done. in my recent role i was fortunate enough to get into the team where i acquired the connections in a span of several months. then you just maintain those relationships: be sincere, make it natural (and believe it!) - you do favors for people because you care about the stuff they need to get done, and only subsequently they reciprocate (perhaps i am too sensitive to this, but it is nails-on-the-chalkboard obvious when folks are shmoozing and try to conceal it; in which case it takes a certain charisma to get away with it).

the reality is that in large organizations no matter what process-improving application/organization is in place, unless you know the people, you will struggle to get anything done. with the right people in place the process is useful, but merely as a documentation/fallback/cya/retrospecting device that is parallel to actual work (disclaimer: given highly motivated, conscious, caring people).

i've seen both ends of the spectrum with new people - folks that managed to piss everyone off in their first few days and then were left in the vacuum; others that were unfortunate to end up in a team that did not proactively and eagerly grow their novice; this is why we made a point to provide as much support as possible for our (welcome) new hires in order for them to establish these relationships (e.g. proudly introduce them as members of our team, bootstrap them with piles of wiki entries that include addresses and names among other things).

ideally, of course, process will be reduced to become as effective as possible, just like personal connections will be a benefit, but not a requirement for getting stuff done. perhaps it is just a corporate aberration; in any case it took me a while to actually consciously acknowledge its importance.

code complete

Posted by anton
on Friday, June 22, 2007

here's daily wtf-worthy quote related to me by a co-worker.

some background: we've been helping these guys move their stuff to our new source control.

us: all your stuff is set, check and make sure it's ok, then we'll move it to the main repository
them: we'll let you know when we deploy it to production
us: we don't care when you deploy it. all we need from you is to verify that your stuff looks ok in the test repository, then we will move it to the main one
them: it's ok, it will go away in just a couple of months
us: oh, so you mean it is a test throwaway prototype project?
them: no, it will go into production in two months, so no one will be using a source control repository after that
us: ...

some sort of pun on ruby, java, and gluing goes here. i got nothing.

Posted by anton
on Thursday, June 21, 2007

speaking of gluing things, below is a jruby script i cobbled together to get a backup of an archaic snipsnap instance.

as you might have guessed, it was just an excuse to play with ActiveRecord-JDBC, since all it really takes is just connecting to the database and pulling one table out.

still, it was fun and just a few lines of code, although you had to install ActiveRecord gem as well as ActiveRecord-JDBC gem (not to mention adding mysql jdbc driver in the classpath). as an excuse, i did not want to deal with low-level jdbc machinery, nor did i want to install another gem to get ruby's mysql connectivity.

although it takes an ungodly amount of time to startup, it works just fine. here's the best of both worlds - java's jdbc type4 driver prowess and ruby's terse and readable way of expressing yourself (plus the quick feedback of edit-run-swear-edit cycle):

snipsnap does boast xml-rpc support, but it only provides a meager pingback ability.

it's for gluing things

Posted by anton
on Thursday, June 21, 2007

i have installed xml-rpc plugin for trac and played a bit with it. it is amazing how simple it is to use - just install the plugin, add a user to the basic auth passwd file (in my case Apache checks there first, then goes to Active Directory), give this user XML_RPC privilege in trac admin, and there you go:


#!python
import xmlrpclib
server = xmlrpclib.ServerProxy("http://username:password@host/trac/login/xmlrpc")
print server.wiki.getPage("WikiStart")

just imagine the possibilities that make trac an application platform - easily create pages/attachments or edit entries in response to events (we have scripts that do certain things for us, and then we also have to go into the wiki and document things manually), create pages in response to incident tickets as they are being worked on, or functional specification workflow process, etc, etc.

xmlrpc libraries are built into python and ruby (php and even javascript, not to mention java) - so there is nothing really that stops one from running this thing on a stock installation of a given language (non-privileged account on a unix box, for instance).

here's a simple script i put together to backup a snapshot of trac wiki to a local hard drive; it is using ruby, since my python skills are nil (i do like the python xmlrpc api much more though - it seems to be a lot more convenient to use and succinct, compared to xmlrpc4r):

#!ruby
require 'xmlrpc/client'
require 'fileutils'

class Wiki
  def initialize
    @client = XMLRPC::Client.new2('https://user:password@server/trac/login/xmlrpc')
  end

  def method_missing(m, *args)
    @client.call('wiki.' << m.to_s, *args)
  end
end

wiki = Wiki.new
pages = wiki.getAllPages

index = '<html><body><ul>'

pages.sort.each do |p|
  puts 'getting ' << p
  FileUtils.mkpath p

  txt = wiki.getPage p
  html = wiki.getPageHTML p

  open(File.join(p, 'index.txt'), 'w') { |f| f.puts txt }
  open(File.join(p, 'index.html'), 'w') { |f| f.puts html }

  attachments = wiki.listAttachments p
  attachments.each do |a|
    puts "\t" << 'getting attachment ' << a
    content = wiki.getAttachment a
    open(a, 'wb') { |f| f << content }
  end

  index << '<li>' << p << '<ul>'
  index << '<li><a href="' << p << '/index.html">html</a></li>'
  index << '<li><a href="' << p << '/index.txt">txt</a></li>'

  if !attachments.empty?
    index << '<li>attachments</li>'
    index << '<ul>'
  end

  attachments.each do |a|
    file = File.basename a
    index << '<li><a href="' << p << '/' << file << '">' << file << '</a></li>'
  end

  index << '</ul>' if !attachments.empty?

  index << '</ul></li>'
end

index << '</ul></body></html>'

open('index.html', 'w') { |f| f.puts index }

i am not using multicall, since it only takes a few minutes to run against our trac instance.

more information on the wiki xml-rpc interface is here. seems like trac does not implement listLinks as well as listBackLinks and some macros do not render properly when retrieving pages via getPageHTML.

also, since tags (which we use heavily) are an extension to trac, xml-rpc api does not support them. perhaps a weekend project to add that in?