THE TECHNICAL INTERVIEW

by Peg Bogema

Ah for the good old days when you hired typists by sitting them down at a typewriter and giving them a typing test. 50 words per minute and no mistakes? Great! You are hired!

What test do you rely on when you are hiring a software developer? The truth is that every hiring manager answers that question differently.

Consider some of the different techniques:

• The Quiz Show: In which the top technical person or people in the team bombard the candidate with technical questions.

• The Ramble: “Tell me about your last project,” in which the candidate flounders about trying to describe a project in the just perfect amount of detail.
• The Lecture: In which the candidate stands up in front of the team and gives a technical presentation about something of questionable interest, likely in an unpolished style of public speaking.
• The Diagram: The whiteboard exercise, in which the candidate solves a problem or designs a system on a white board.
• The Survey: A written questionnaire, in which the candidate answers questions about past experience with this, that and the other thing.
• The Puzzle: In which the candidate is given brain teasers or logic puzzles to solve on the theory that, well actually I’m not sure what the theory is, but I guess it tells you if the candidate is easily annoyed by logic puzzles and trick questions!

While any of these techniques might provide insight into the candidate, they all have shortcomings.

Some people are great at answering technical questions in a memorized-the-answers fashion. They have a great ability to remember facts that they read in books, but may not be quite as adept at putting the theory into practice.

Some people are very poor public speakers. While it’s true a software developer has to interact with people, he or she doesn’t necessarily have to do it in front of a group.

Some people are uncomfortable bragging about themselves, so they fall short when characterizing the history of their contributions to projects.

And so it goes.

Each approach has its merits, too, and in certain cases may be the superior interviewing technique. For instance, a prospect for an architect’s role reveals a great deal during a white boarding exercise.

But when it comes to selecting a software developer, none of the above actually show you how the candidate approaches the actual task he or she will be charged with. A typing test for a typist reveals the candidates skills better than tell me about your last job or asking questions about the candidate’s knowledge of IBM Selectric Typewriters, doesn’t it?

So why not a software development test?

Here is an approach that I like. It starts with a project that uses the technology elements that the candidate will use should he or she get the job. To be clear, if you are hiring a C# programmer, you have a C# project that is already underway that can be used in this type of assessment.

Set up a specific, relatively straightforward element that needs to be implemented in the project. It can be defined and described easily—so easily that the candidate would probably be able to understand the requirements without anything written down. But the requirements should be written down anyway. You could require the candidate to implement something that is completely new. You could require the candidate to complete something that is partially implemented. Either will work. The key is that the element has to be relatively straightforward so that the candidate can grasp the requirements with ease.

The next step in the process depends upon you. I like to have the candidate create an implementation plan and estimate each step of the implementation plan. This gives you great insight into several aspects of his or her skills. Can the candidate plan an implementation? Many people cannot envision how they will tackle a task, and as a result they cannot break it down into an implementation plan. This is valuable data about the candidate. By looking at the candidate’s estimates for each line item in the implementation plan, you get a sense of how junior or senior the candidate is (or conceives him- or herself to be). If a task would take a senior person 15 minutes and a junior person one hour, the candidate’s estimate can be very informative. He or she is basically self-assessing for you. On the back end of the work, you get to see how accurate the candidate’s estimates are.

Then the candidate does the implementation. It’s done completely open book, open note, open Internet.

While the candidate is doing the implementation, the hiring manager or another technical leader can introduce a variety of curves: ask the candidate why certain decisions were made, require the person to change on a dime and do things differently, change the requirements, and so forth.

How the candidate grasps the requirements, plans, estimates, codes and handles change give a great insight into what the candidate will be like in action. And that’s what I like about this style of interview.

If your team suffers from change, then throwing change at the candidate and seeing how it’s handled is valuable data.

If your team is full of opinionated people—and you prefer to hire people who can stick by their guns—then seeing how someone handles a challenge to his or her approach is important.

And just plain watching the person write code can be tremendously valuable.

It takes a while to refine the projects you use. And you want to keep the duration of such an activity relatively short. Unless, that is, you don’t mind paying people for a day of interviewing—which many companies are now doing.

Peg Bogema is Stout’s Vice President of Operations. With Stout since 1997, her duties include the supervision of development projects and personnel, recruiting and accounts.

JQUERY MOBILE CODIQA

by Nick Staroba

After writing “Resolution Independence” for a recent edition of The Informatizer, I received a comment from a reader that I should write about jQuery Mobile. So, being somewhat familiar with jQuery, I decided to have a look.

jQuery’s developers describe it as “A fast, concise, library that simplifies how to traverse HTML documents, handle events, perform animations, and add AJAX.” (http://jquery.com/)

jQuery Mobile on the other hand is very similar: “jQuery mobile framework takes the ‘write less, do more’ mantra to the next level: Instead of writing unique apps for each mobile device or OS, the jQuery mobile framework allows you to design a single highly-branded web site or application that will work on all popular smartphone, tablet, and desktop platforms.” (http://jquerymobile.com/)

Normally for a topic like this I would be delving into the meat of the item in question but I was distracted.

Upon loading jQuery Mobile’s Web site, the page jumps down to a prominent “Try it now!” section.

And I was lost to the world for an afternoon.

Pictured above is this simple drag and drop “try it now” tool for jQuery Mobile powered by Codiqa (http://codiqa.com/).

What this embedded and simplified version of Codiqa does is utilize jQuery Mobile to let you create any number of mobile-ready pages in minutes.

Yes, minutes.

Need a contact form? Easy.

Need a page with a map? Done.

Any designer or developer with moderate HTML and scripting experience could get a fully functional site up for a small or large business with minimal effort.

Of course this isn’t going to be a site to win any major awards but when you’re on a budget or a time crunch to get a fully adaptive mobile project done and published, I would start here.

Here’s an example set of requirements:

Page template:

• a header image,

• a navigation bar with three links,
• content area,
• a footer with copyright data.

Homepage:

• a paragraph describing the business with a “Learn More” button linking to page about a service,

• contact information,
• a map with the location set.

About page:

• two paragraphs about the company.

Contact page:

• “I’m interested in:” with three checkboxes for different services,

• a text input for an email address,
• a text input for a phone number,
• a text area for a message.

A page about a service:

• a couple of paragraphs describing one service in further detail,

• a call-to-action button linking to the contact page.

That’s a template and four pages. How long do you think it will take?

It took me an hour.

Here’s the homepage and contact form:

I only counted the front-end of the contact form into my time as I would simply copy and paste the PHP from an earlier form.

Here are the service and about pages:

Pretty slick for hardly any effort.

Codiqa is described as “the fastest mobile builder and prototyping tool” and it is definitely that. And right on jQuery Mobile’s site, you get to try it free. Enjoy.

Nick Staroba is Stout Systems’ Promotion and Marketing Manager. He is responsible for design, production and delivery of all Stout promotional communications from print to the Web.