Interviewer Tips

About every other week, Monster or some portal publishes an article on how to interview properly–what kinds of questions to expect, what kinds of attitudes to carry, and so forth. You’ll also see articles on what sorts of questions to ask as an interviewer. What aren’t published as often are suggestions on how to avoid being a bad interviewer.

While I run a consultancy, I’ve held several full time positions intermittently. I believe in order to stay relevant when training or consulting, it helps dramatically to be part of a real team from time to time. I also find it wise to interview at least once a year–even if you like your current job, it’s always a good idea to find out what’s going on out there.

I’ve had some interesting interviews over my career. I’ve done well on most, and botched a handful too. I’ve also been subjected to “interviewer abuse” many a time. I personally have interviewed close to a couple hundred candidates in my career, and have tried hard to avoid making these candidates miserable.

Here is a short, not exhaustive, list of recommendations I wish my prior interviewers had read before interviewing me:

  • Don’t treat the interview as an opportunity to blather endlessly and show off your skills. Your candidate should be talking at least as much as you.
  • Don’t ask your candidate to “write code” at the whiteboard. Chances are you have at least one computer in your office that the candidate could use.
  • Don’t fixate on overly clever algorithms or puzzles. Insights needed to solve these may not come, particularly if it’s 3:30pm on a Friday and you’ve already subjected the candidate to hours of interviews. Better: Start with a reasonable problem, keep the discussions open-ended, and be willing to shift gears based on what you learn from the candidate.
  • If you think a candidate’s answer to a technical question is wrong, discuss it. There are often other ways to answer a question, and you might have also not done a good job of asking it. Initiate a discussion. You might even learn something yourself.
  • Don’t insist on any more than a half day’s interview. We all know that the important impressions are made or not in the first five minutes, so demanding significantly more time is inconsiderate and suggests vast room for improvement at interviewing.
  • Provide the candidate with a rough agenda, making sure to include what roles each interviewer has in the organization.
  • Ensure your candidate gets exposed to the culture of your company–make sure the interview process accurately reflects it! Make sure they get to see the team at work.
  • Don’t pigeonhole your candidate. Try having an open discussion and see where things lead, instead of forcing him or her through a predetermined interview sequence.
  • Don’t make a candidate slog through the interview process if it’s clear to all parties that he or she is not a good fit. If you think there’s a problem, have the courage to initiate a dialog with the candidate about the supposed mismatch. Ask them where their strengths lie, and look to take the discussions there. Chances are that you’re not doing a good enough job of asking questions.
  • Don’t deliberately make your candidate uncomfortable. Avoid intimidating behavior, such as staring angrily or morosely and refusing to utter more than a syllable or two. Don’t forget to ask them if they need water or a restroom break.
  • If you insist on “behavioral interviewing,” make it clear to the candidate how his or her answers correspond to your decisions.
  • If you are declining to extend an offer to the candidate, be honest with them about the reasons why.
  • Thank your candidate by phone or email within a day of the interview, and indicate when you will have an answer.

A Fitnesse Glossary for Non-Programmers

Fitnesse is designed to be a simple table-driven testing framework that’s accessible to anyone who has a web browser. Just like anything, however, it’s not without its own set of terms, which can be initially overwhelming, particular for folks who don’t program computers for a living. Here’s a glossary you may find useful.

acceptance test
A test whose success indicates that a particular feature meets the expectations of the customer and thus may be delivered.
action fixture
A FIT fixture type that supports tests that capture a series of events. Each row in an action fixture table supports either an action–such as “press” or “enter”–or a verification (“check”) that the system shows a certain value.
camel case
A compound word with no spaces (or other special characters) where the start of each contained word is an upper case letter. For example: ThisIsCamelCase appears in upper camel case; thisIsCamelCase appears in lower camel case.
child page
A page that is conceptually subordinate to another. For example, a page named GovernmentBranches might have three child pages: LegislativeBranch, ExecutiveBranch, and JudicialBranch.
cell
The intersection of a row and column in a table.
classpath
A configuration element that tells Fitnesse where to look for fixture code.
collapsible section
A portion of a wiki page that can be “collapsed” (mostly hidden from view) or expanded.
column fixture
A FIT fixture type that supports a number of functional tests. Each row in a column fixture is a collection of inputs and expected outputs.
decision fixture
A SLIM fixture type that is analogous to the FIT column fixture.
do fixture
DoFixture is a FitLibrary fixture type that supports verifying a workflow–an arbitrary set of sequential steps.
FIT
The original Fitnesse test system (“Framework for Integration Tests”); see also SLIM.
FitLibrary
A third-party collection of additional test fixture types.
fixture
A thin layer of code that Fitnesse uses to drive the application being tested from a test table.
fixture argument
A value passed to a fixture, appearing after the name of the fixture, used to initialize the fixture (often used to constrain results returned from a query).
graceful name
An aesthetically pleasing, more readable version of a wiki word or other compound word. For example, “customer name” is a graceful name that translates to “customerName” when Fitnesse runs its tests.
link
A web page element that navigates to another web page when clicked.
markup language
the set of conventions used by the Fitnesse wiki to “mark up” page text for formatting purposes. For example, to create the italicized word fish in the Fitnesse wiki, you mark it up by surrounding it with double-tics: ”fish”.
markup variable
a Fitnesse mechanism that allows for simple text substitution anywhere in a test page or sub-wiki
page hierarchy
A set of wiki pages organized like an upside-down tree, into parent and child relationships. Each wiki page may have one or more child pages.
properties
Various page attributes. Fitnesse allows customization of features such as editability on a per-page basis.
refactor
To restructure some aspect of the Fitnesse wiki. The refactoring features of Fitnesse allow for search & replace, renaming pages, moving pages to another location, and deleting sub-wikis.
rollback
To change the currently active Fitnesse page version to an older version.
row fixture
A FIT fixture type that supports verifying the result of a query. A row fixture contains one row for each record expected when the system returns a collection of results.
query fixture
A SLIM fixture type that is analogous to the FIT row fixture.
scenario table
A SLIM fixture type that can be called from other tables.
script fixture
A SLIM fixture type that is similar to the FitLibrary do fixture.
set up
A page that contains a number of common initialization test tables. The SetUp page in Fitnesse is run prior to each test in the sub-wiki where it is defined.
SLIM
A Fitnesse test system with a thinner client architecture that supports easier porting to new versions and languages than does FIT.
sub-wiki
A whole new page hierarchy that lives between a single Fitnesse page.
suite
A sub-wiki that is run as a collection of tests. Any test pages appearing as child pages of a page marked as a suite are executed when the suite is executed.
symbol
A variable that appears in a table, allowing you to capture or use the value returned into an output cell from a fixture.
symbolic link
An alias for another page in the wiki
table
A number of rows and columns grouped together.
tear down
A page that contains a number of common test tables used for cleanup. The TearDown page in Fitnesse is run subsequent to each test in the sub-wiki where it is defined.
test page
Also known as a Fitnesse page. The test page represents a set of steps to be executed for a single test case. A test page is identified by a wiki word and contains one or more test tables.
test runner
An application that executes one or more Fitnesse test pages. For example, the CommandLineTestRunner is used to execute tests from a batch or build process without need for human interaction.
test table
A table that declares inputs and expected outputs for test scenarios.
version
The contents of a page at a specific point in time. Fitnesse creates a new version each time you change a page’s contents.
wiki
a web site that allows all users to directly edit and add web pages, using a simpler formatting convention than HTML.
wiki import
A feature that allows you to import an entire wiki or subwiki from another Fitnesse site.
wiki word
A unique name for a web page that is created by appending two or more words using upper camel-case. For example, FitnessePage.
Atom