At RubyConf 2006, Zak Tamsen and I were interviewed by Obie Fernandez. In the months leading up to the conference I worked with both Obie and Zak on different projects where a DSL was used by the customer to specify the business rules of an application. Both projects were among the more interesting of my career. The interview discusses how we approached the problem and the successes that followed.
Check out the interview on InfoQ: Jay Fields and Zak Tamsen on Domain Specific Languages
Showing posts with label interview. Show all posts
Showing posts with label interview. Show all posts
Tuesday, October 23, 2007
Monday, September 24, 2007
Semi-bluffing your interview
Over the past two and a half years I've interviewed several ThoughtWorks candidates. These days I tend to put people into 3 categories when interviewing them: Gross Exaggerator, WYSIWYG, and the Semi-bluffer.
The Gross Exaggerator
Being a Gross exaggerator is never a good idea. Your resume is the first clue. I've yet to meet anyone who's an expert* with .net, Java, Ruby, Smalltalk, and Lisp. There's just not enough hours in the day to actually be an expert in each language. Anyone with several buzzwords on their resume signals two things to me: They likely have no idea what they don't know, and they aren't picky enough about technologies they are willing to work with.
I took C in college also, but one semester of Data Structures does not an expert make. I did Java at my first job, but I have no desire to program in it now, so what's the point of listing it as one of my skills? I'm not saying that my resume doesn't contain the word Java. In fact, it does state in my first job description that we used Java, but my skills list is not a summary of what I've done in my past. My skills list is the list of skills that I've kept up with and am interested in continuing to keep up with. A bloated skills list indicates that you think you know more than you do, or you haven't spent the time to be and expert in anything; both situations look bad.
Being a Gross Exaggerator in an interview is painful. You generally have a bit of knowledge of several things, but almost no in depth knowledge of anything. Most questions quickly expose this. Gross Exaggerators are fairly easy to spot, and I always pass on hiring them.
WYSIWYG (What You See Is What You Get)
It's very easy to be a WYSIWYG candidate, because you are very clear about what you know and what you don't. A WYSIWYG candidate never gives a partial explanation; they either tell you every painful detail, or claim to know little or nothing about the topic.
Hiring a WYSIWYG is an easy choice, but I don't think being a WYSIWYG is the best option. The problem with being a WYSIWYG is that there are several Gross Exaggerators and some Semi-bluffers that will be competing with you. Someone who claims to have the knowledge you do, plus more, will always be an attractive choice for a potential employer.
The Semi-bluffer
I think Semi-bluffing interviewees generally do the best because they demonstrate what they know, suggest that they know more, but admit what they don't know when directly challenged. In fact, I believe the above quote could be rewritten as the following to describe Semi-bluffing in an interview.
Try Semi-bluffing a question in your next interview. It can be a great rush, but be sure to admit when you don't know something. Also be careful about choosing which question to Semi-bluff. A direct and detailed question isn't a good candidate for a Semi-bluff. When someone knows they have "the nuts" a bluff is an (often embarrassing) waste.
* I define expert as someone who is knowledgeable concerning: syntax, development environment, advanced language features, how and what to test, framework choices, details of several frameworks of the language, debugging, performance optimization, deployment strategies, and pattern implementation specific to the language.
The Gross Exaggerator
Being a Gross exaggerator is never a good idea. Your resume is the first clue. I've yet to meet anyone who's an expert* with .net, Java, Ruby, Smalltalk, and Lisp. There's just not enough hours in the day to actually be an expert in each language. Anyone with several buzzwords on their resume signals two things to me: They likely have no idea what they don't know, and they aren't picky enough about technologies they are willing to work with.
I took C in college also, but one semester of Data Structures does not an expert make. I did Java at my first job, but I have no desire to program in it now, so what's the point of listing it as one of my skills? I'm not saying that my resume doesn't contain the word Java. In fact, it does state in my first job description that we used Java, but my skills list is not a summary of what I've done in my past. My skills list is the list of skills that I've kept up with and am interested in continuing to keep up with. A bloated skills list indicates that you think you know more than you do, or you haven't spent the time to be and expert in anything; both situations look bad.
Being a Gross Exaggerator in an interview is painful. You generally have a bit of knowledge of several things, but almost no in depth knowledge of anything. Most questions quickly expose this. Gross Exaggerators are fairly easy to spot, and I always pass on hiring them.
WYSIWYG (What You See Is What You Get)
It's very easy to be a WYSIWYG candidate, because you are very clear about what you know and what you don't. A WYSIWYG candidate never gives a partial explanation; they either tell you every painful detail, or claim to know little or nothing about the topic.
Hiring a WYSIWYG is an easy choice, but I don't think being a WYSIWYG is the best option. The problem with being a WYSIWYG is that there are several Gross Exaggerators and some Semi-bluffers that will be competing with you. Someone who claims to have the knowledge you do, plus more, will always be an attractive choice for a potential employer.
The Semi-bluffer
In [poker] games with multiple betting rounds, to bluff on one round with an inferior or drawing hand that might improve in a later round is called a semi-bluff. A player making a semi-bluff can win the pot two different ways: by all opponents folding immediately or by catching a card to improve the player's hand. --WikipediaSemi-bluff is a term that I picked up playing poker. A few of the things I love about poker is that you don't know what the competition has, you don't know what will be needed in the end to win, and you probably don't know if you are currently winning or losing. Of course, each of those things can be said about almost any interview.
I think Semi-bluffing interviewees generally do the best because they demonstrate what they know, suggest that they know more, but admit what they don't know when directly challenged. In fact, I believe the above quote could be rewritten as the following to describe Semi-bluffing in an interview.
Almost all interviews involve a series of questions, to give a vague answer to one question when you don't know enough details can be called a semi-bluff. An interviewee making a semi-bluff can pass that round of questioning two different ways: if the interviewer doesn't request more information or if the follow up question happens to hit one aspect where you do understand the details. A semi-bluff can also be a success if the interviewee admits to not knowing the answer at the moment, but later in the interview process demonstrates that the desired knowledge has been acquired.A Semi-bluff in poker, and while interviewing, takes a great deal of finesse. Coming off as a WYSIWYG while Semi-bluffing is safe, but coming off as a Gross Exaggerator can cost you a job. Therefore, it's obvious which way you should lean if you find Semi-bluffing isn't working out for you.
An example of a Semi-bluff could be demonstrated as the following.
Interviewer: Do you have experience with deploying Rails applications.
Interviewee: On my current project we use Capistrano and deploy to RHEL. The Webserver is Nginx fronting a Mongrel cluster.
Notice that the interviewee hasn't stated that he did any of that work, instead he's simply listed his current project's deployment plan. The questions may end right there, but if they don't you can easily follow up with: Truthfully, I've been focused on other parts of the application so I only have a high level view of our deployment. However, I believe that it would be very easy for me to get into the details of your specific deployment if I am hired. Following the interview, the interviewee should then dig into the details of their current deployment and send answers via email to the interviewer. Obviously, the faster the email is sent, the better.
Try Semi-bluffing a question in your next interview. It can be a great rush, but be sure to admit when you don't know something. Also be careful about choosing which question to Semi-bluff. A direct and detailed question isn't a good candidate for a Semi-bluff. When someone knows they have "the nuts" a bluff is an (often embarrassing) waste.
* I define expert as someone who is knowledgeable concerning: syntax, development environment, advanced language features, how and what to test, framework choices, details of several frameworks of the language, debugging, performance optimization, deployment strategies, and pattern implementation specific to the language.
Saturday, April 14, 2007
Blogging: Blog as a skills assessment
When I joined ThoughtWorks, almost 2.5 years ago, I had a conversation with Paul Hammant where he said he always googles someone before he interviews them. At the time it was a good idea, but now I think it's a great idea.
It's fairly common, in my experience interviewing TW candidates, to list every technology a person has ever touched. If they've done a 'hello world' in IO, you'll find IO on their resume.
Contrast the above situation with what you find on a person's blog or in their emails to mailing lists. For example, I have done 'hello world' in IO, but there's not a single entry on the web that links me to IO. Conversely, a glance at my blog shows I've been doing Ruby/Rails full time for more than a year at this point and Agile for almost 3.
A quick search can save you from a lot of tracer bullet questions. Your first question in an interview usually needs to be very high level, to see where the candidate skills are at. The next question may be very detailed, to see how deep the candidate is. But, a simple search could have revealed the same information without the common interview dance: If you ask a high level question, you usually get a high level answer, despite the fact that the candidate may have a very deep understanding of the topic.
Of course, this wont work on all occasions. Searching for Michael Johnson isn't likely to produce relevant information, nor will searching for someone who never publishes anything on the web. But, even if it works 50% of the time, it's better than having to ask the same broad questions at the beginning of every interview.
Also, if this practice were more widely adopted, having a blog may become an advantage when searching for a job in the future. Personally, I'd prefer someone be able to size me up before an interview. I don't enjoy tracer bullet interview questions any more than the person asking them.
It's fairly common, in my experience interviewing TW candidates, to list every technology a person has ever touched. If they've done a 'hello world' in IO, you'll find IO on their resume.
Contrast the above situation with what you find on a person's blog or in their emails to mailing lists. For example, I have done 'hello world' in IO, but there's not a single entry on the web that links me to IO. Conversely, a glance at my blog shows I've been doing Ruby/Rails full time for more than a year at this point and Agile for almost 3.
A quick search can save you from a lot of tracer bullet questions. Your first question in an interview usually needs to be very high level, to see where the candidate skills are at. The next question may be very detailed, to see how deep the candidate is. But, a simple search could have revealed the same information without the common interview dance: If you ask a high level question, you usually get a high level answer, despite the fact that the candidate may have a very deep understanding of the topic.
Of course, this wont work on all occasions. Searching for Michael Johnson isn't likely to produce relevant information, nor will searching for someone who never publishes anything on the web. But, even if it works 50% of the time, it's better than having to ask the same broad questions at the beginning of every interview.
Also, if this practice were more widely adopted, having a blog may become an advantage when searching for a job in the future. Personally, I'd prefer someone be able to size me up before an interview. I don't enjoy tracer bullet interview questions any more than the person asking them.
Subscribe to:
Posts (Atom)