Interviewing Software Developers based on Changing Technical Debt

How to Interview Software Developers based on Changing Technical Debt


Interviewing a Software Developer isn’t easy. Interviewing a Software Developer is a high stakes gamble where the choices made are often ill-informed and the result of a choice has enormous consequences, both good and bad. The entire interviewing process has been flawed since the very first “Programmer” job was posted, many moons ago. If you have the time and patience to read this long-winded article, I believe I can help you make a more informed decision using my own experiences interviewing, hiring, working as a consultant and full-time employee, and my own opinion about the most honest and robust hiring strategy I believe in.

When it comes to hiring, there’s a lot at stake for the interviewer and candidate alike, so let’s begin by discussing the interview from the vantage point of the manager.

Understanding the hiring manager’s aspirations

Managers often hope their new candidate is going to be the “one” who charts a new course for their product, their company, and ultimately, paves the way toward golden opportunities for everyone on the team. Managers have visions of hiring someone so special, they can work normal hours, get a better bonus, and lengthen their lifespan through the type of stress reduction they were advised to undertake by their Cardiologist.

After a candidate is found, interviews happen. An offer is made. Anxiety fills stomachs. Email clients see their ‘receive all’ button pressed over and over. Papers are signed. Videos about “why groping is inappropriate” are watched. Then, months after an understanding is reached about what the candidate would bring to the organization, both parties are often disappointed by the differences in expectations for the position and the reality of the position.

The interview is where all of the false expectations are born. Having worked as a full-time employee, consultant and founder of two start-ups, I’ve had my fair share of interviews on both sides of the table. I have hired freelancers, contractors, consultants, and full-time employees. I have gotten lucky, and have been seriously blown away by some of the people who worked for me, whom I never would have imagined would be capable of carrying the baton across the finish line; and yet, succeeded beyond my wildest expectations. Other times, I’ve kicked myself for a costly hiring decision that drained so much time and energy, I would have been better off doing the work myself.

I used to suggest we hire a candidate based on their intimate knowledge of subject matter. When I hired, I often prided myself on my ability to ignore personality, as if my tolerance of the more eccentric candidates provided me a bigger talent pool from which to choose; a tolernace I believed provided me an edge over our competitors. Everyone who hires usually tells himself or herself that they have some edge over other interviewers. They tell themselves they provide a much more thorough interview than their peers. They tell themselves they can judge a candidate’s fitness better than anyone else. They tell themselves their cowboy shirt they picked up at the thrift store looks nice. Remember this about interviews: Interviews happen off-the-cuff because interviewers have no systematic process or methodology to successfully measure a candidate’s real value.


Read More

The Scrum Master’s Guide to a Better Scrum


I’m old mature enough to have worked for companies that used a Waterfall methodology to deliver their software. There was always something nice about having time to figure out problems on your own with a longer time frame, and I liked reviewing a pile of documents (honestly).  Back in the day, I would walk across the street to a restaurant and review the documents that were related to my task at hand. Then, I’d begin coding, knowing we had a once-a-month show-and-tell of our progress, just to keep our contracts. New requirements? Another lunch-and-learn.

Most companies have moved to an Agile approach to Software development, and after operating two start-ups with daily changing requirements, it’s clear to me why this approach works.

However after working for several different companies, I’ve realized there is a plethora of companies that consider themselves agile, but they’re not Agile. Sometimes, they claim to be somewhere in the middle of Agile and Waterfall, which is one way of saying, “We’re still trying to work it out.”

These companies often have a Scrum which isn’t a real Scrum. For simplicity’s sake, we’ll call this the “Artificial Scrum”.

For all of those companies that are still trying to make Agile work, I’m going to help, by introducing this blog post, which we’ll call, “The Scrum Master’s Guide to a Better Scrum”, to help understand how to turn an Artificial Scrum into an Authentic Scrum.


Read More

A Maven seed project for GWT, Google App Engine and JDO

GWT and AppEngine Convention, without IDE Configuration

A Maven seed project for GWT, Google App Engine and JDO


This project offers a conventional seed project for a full-stack application that is pre-configured and ready-to-go. The goal is to offer a simple, working example of a CRUD application, using an entity relationship framework, enterprise-level validation, which sits atop a cloud-based, schemaless, high-replication datastore that has zero dependency on an IDE. How is this done? The entire dependency management and build lifecycle configuration is done solely through Maven.

This project currently supports the following:

  • Google Web Toolkit 2.7.0
  • Google App Engine 1.9.18 through a schemaless high-replication datastore (HRD)
  • DataNucleus JDO 3.0
  • JUnit 4.12
  • Google Chrome. Due to the limitations for symbol-map support in IE and Firefox, you need to test with Google Chrome to see error log messages logged by the UI.


This project is licensed under Apache License 2.0

Project location


A few years ago, I was working for a company who let developers use their preferred IDE, using a BYOD approach to the authoring environment. I thought that was very cool, and I also believe it’s an approach likely to gain favor as more companies move to a Docker containers for development.

Some developers kept their own lifecycle mappings for Eclipse, some developers worked purely from the command line, and others benefitted from how IntelliJ introspected parent POMs to understand dependencies. Some developers kept their own m2e configurations.

At the time, I didn’t have any experience with Maven. Lots of developers lack Maven experience, and there’s a steep learning curve with Maven, especially if you need to create an environment-specific configuration, such as working in Eclipse with m2e.

I prefer IntelliJ it for development, but my preferences shouldn’t dictate the team’s preferences. Lots of people prefer Eclipse or Netbeans. For my most recent application, I had a hard time finding a starting point for my GWT/GAE/JDO project that didn’t include IDE specific configuration, and I had a harder time finding documentation and examples which didn’t omit the intricacies between the different SDKs and frameworks.

So, when my company decided to move from Eclipse to IntelliJ, we came across a few issues with our migration. First, it became difficult to share a project between Eclipse and IntelliJ. We had been using Maven for dependency management, but not lifecycle management.


Read More

Validators with Formatters in a Stateful Form

I’ve released a project on GitHub called Form & Function. I build this project and then used for a large Eligibility Application for a client, where it proved pretty useful. The problem domain I was dealing with dealt with how to develop a large, forms based application where user-feedback needs to be rock-solid and the feedback needs to happen constantly, to ensure as many fields get completed in a single setting as possible.  

In a nutshell, what does it do?
Form & Function
reminds a user that their time-investment matters to you and your organization by giving the best possible experience when filling out a form.

In brief technical jargon, what does it do?
Form & Function creates the relationship between a validator, a formatter, and a restrictor for the most popular form types, and then notifies the developer and user about a form’s validity.

Who does it help?

  1. For developers, it simplifies building complex forms.
  2. For users, it helps them complete long forms.
  3. For project managers, it’s a milestone met.
  4. For user experience designers, it’s a starting place for a conversation.

Where can I find Form & Function?
The code base is hosted on Feel free to download the latest version of Form & Function from the Subversion trunk. Over the next few months, the project will be in a “Bleeding-Edge” release, and should not be considered backwards compatible from day-to-day.

What problems can Form & Function solve with my Flex Project?

Problem 1: The standard Flex Validators are too generic
Let’s start from the top and talk about the Adobe Flex validators. The types of validators Flex currently offers are:

  • CreditCardValidator
  • CurrencyValidator
  • DateValidator
  • EmailValidator
  • NumberValidator
  • PhoneNumberValidator
  • RegExpValidator
  • SocialSecurityValidator
  • StringValidator
  • Validator
  • ZipCodeValidator

Adobe gives you all the hooks you need to build your own validators using the Validator class and the RegExpValidator class (and both are used liberally with Form & Function).

The more specific validators, such as the CreditCardValidator, won’t validate credit-card security codes, only credit-card numbers). While a Merchant may not require the user enter a security code, the ability to validate against a security-code that’s tied into the card-type, should have been there all along, along with a CreditCardFormatter for user legibility.

Form & Function has validators that either improve upon, or plain-old, don’t exist in the latest Flex SDK.

Read More