0 Comments

Its time to start growing my team. Yes, I have a team. We maintain a large, old, highly profitable piece of software aimed primarily at Real Estate Agents. Its got some rough edges, but it provides real value to its users, and helps them to do their jobs more effectively (which in turn makes them more money).

As I stated above, the core of the application is quite old (Visual Basic 6), and was not necessarily constructed using the best of engineering principles, even for the period when it was built. It has been edited, maintained, mutated and otherwise altered over the course of over a decade, and while its not the best piece of code I’ve ever seen, its certainly not the worst.

A lot of what we do is provide new ways in which modern systems (either ours, or third parties) can interact with that piece of software, so that the users aren’t disadvantaged purely as a result of its age. While doing this, we’re learning about the domain and the users and planning for the eventual replacement (because it can’t live forever).

To do all of the above, I need good people.

The Search Begins

I’ve done some recruitment before. Not a huge amount, but enough to know that it is far harder than it looks. Its time consuming, and can be somewhat disheartening when you have to filter through a mountain of average applicants to find the good ones. Of course, that’s mostly an issue when you use the normal channels (Seek, Recruitment Agents, etc), which generally should only happen as a last resort.

Like most people, I follow a 3 step filtering process in order to try and help me identify whether or not I think someone will be a good addition to the team.

The first step is the resume. Honestly, I prefer a good, well structured LinkedIn profile to a static document, as I find that resumes are often tailored for recruitment agents (who love buzzwords and lists of technologies), rather than to the person who actually needs to read it. As an introduction though, I much prefer a custom letter plus a cut down resume highlighting only the skills and experience that would likely be required for the job at hand (with a link back to the full profile for completeness).

The letter should give me an idea that you know something about the company I work for and shows that you’re actually willing to put some effort into this application, while the targeted resume allows for a focus on only those areas of your history that are immediately useful. Believe me, a shorter, more focused resume is far better to read through than one in which you detail your entire storied history, down to that time you did night fill at Big W in your home town (where you learned complex managerial skills and how to use your time effectively, of course).

Anyway, that first, filtering step can be pretty gruelling, especially if you get flooded with a bunch of really standard resumes. When evaluating, I usually err on the side of “sure, why not” during the first step, as you can’t really get a good handle on someone until you speak with them.

Thus, step 2, talk to the person.

Talking Skills Not Good

A resume is all well and good, but you can’t really judge someone until you actually speak with them. A simple phone interview is the quickest and least disruptive way of accomplishing that. I usually have some really standard (and pretty tame) technical questions that I ask during this interview, to gauge the average level of knowledge. Stuff like:

  • What is an interface?
  • Have you heard of SOLID?
  • What do you know about inversion of control?
  • What are some of the difficulties encountered when writing web services?
  • Tell me in depth how the .NET garbage collector works with regards to finalizers and how they interact with the 3 tier garbage collection algorithm.

Okay, that last one was a joke, but the rest are good questions to see what sort of level of knowledge someone has.

Its not an immediate fail if the applicant can’t answer any of the above (well, except for maybe the interfaces one, I mean, come on), its more about how the applicant reacts and communicates, even when they don’t know the answer. Do they try to dodge the question to hide their lack of knowledge? Do they admit they don’t know and then ask what it is? You can tell a lot about a person by listening to both their actual answers and how they answer.

Assuming a candidate shows promise, after the phone interview is typically a good time see if they have any Github repositories or other examples of code they’ve written. Have they contributed to the community in any way? Things like StackOverflow or other forums can show a lot about how a person communicates and solves problems.

Just like resumes, I err on the side of “why not” here. If I’m not sure about someone, I’ll get them to come in and meet me in person.

Thus step 3, the in-person interview.

Ideally No Actual Physical Contact

You all know how this one goes. I get the applicant to meet me somewhere, ideally the office that they may work in, and get a sense of what they are like in person. Standard interview tactics apply, give company history, ask them various questions (tell me about your last job, what was your most recent success/failure, why do you think you would like to work here), give them time to ask questions of their own, etc.

In addition to all the standard stuff above, I like to give real problems to the applicant (maybe something that I’ve encountered recently) and see what their approach is. Do they ask questions? Do they make assumptions and go off half-cocked? Do they ignore the problem altogether and focus on something irrelevant? Do they consider the user at all, or are they focused purely on the technical? All useful pieces of information.

The in person interview is the stage where you get other people involved. If you have a HR department and they need to sign off, get them to come in and do their thing. Managers, directors, whoever wants to offer their feedback.

Ideally you get this whole process out of the way in one session, hopefully not longer than an hour or two. Interview processes that go on for weeks at a time (mostly as a result of scheduling issues) are annoying for all parties involved. Personally, I prefer something pretty casual (I’m not a formal man) because the normal interview atmosphere can really give you the wrong impression of someone. Show the applicant around, let them see a standard development environment, talk to the rest of the team, etc. Lots to do in a mere hour or two, but its more than possible.

Making a decision at the end of this process is hard. Its extremely difficult to get a good handle on someone from a few hours of contact (if that). Good people will be missed and bad people will be mistakenly regarded as good. It happens.

You make a decision using the best of your knowledge, and move on.

The Follow Up

Recruitment doesn’t end with hiring.

You really don’t know what someone is going to be like until you actually work with them. Honestly, some people can construct very convincing facades, and then be completely terrible. Give honest feedback and regularly make time to evaluate whether or not the applicant was the right choice. If they weren’t, then deal with it appropriately (whatever that might mean). The knife cuts both ways however, as they are also free to leave (at minimal notice) if they realise the job is not for them.

This is the standard evaluation/trial period. Where I am now this is 6 months, with 1 week notice for either party.

What I’m really trying to get at here though, is that there should be enough respect on both sides of the table to understand when something is not working out, and to react accordingly.

A Shorter Path

Better than all of the above? Get to know lots of good people and just look them up every time you need someone.

There is no better option than to call on someone you’ve actively worked with before. You already know them, you know what they are like and what they are capable of. Ideally you don’t just offer a job to anyone you’ve ever worked with (we’ve all worked with some duds before), but you remember the good ones, and you reach out to them when its appropriate. Ideally it should be a mutually beneficial thing, as they should do the same sort of thing for you.

Another Way?

I always thought it would be interesting to simply get promising applicants to just come in and do some work for a day. Get them to sign an NDA (just in case) and literally get them to come work for the company for a day. Obviously you would pay them an appropriate amount of money (nothing is free after all) to make it worth their while.

What better way to evaluate whether or not someone is going to be a good fit than to just work with them? Sure, this might not be feasible for someone who is already employed full time, but if they really are interested, I’m sure they could get a day off.

At the end of the day, either party can say “no thanks” with no hard feelings.

I mean, it makes sense to me, but I have a pretty simple view of things. I’m sure there is all sorts of bureaucratic reasons why it wouldn’t work. There usually is.

Conclusion

Honestly, this entire blog post has really been a lead up to the following statement.

My name is Todd Bowles and I am the Technical/Team Lead for one of the development teams at Onthehouse, located in the Brisbane CBD, Australia.

I’m looking for some good developers to join my team and help build integrations into our current Real Estate management software. Over the next 5 years or so, we’ll be creating a brand new offering using a SAAS model that will eventually replace our installed application.

I need people who are comfortable both with older installed technologies (VB6, .NET, WinForms, WPF) and new web based technologies (ASP.NET, Nancy, ReactJS + others). You’ll need to be adaptable (its not all pure .NET) and to not be afraid of either new things or particularly old, scary things.

You’ll have to have a focus on creating well engineered, well tested code while constantly communicating clearly with the rest of the team and with stakeholders. You must understand and be willing to maintain and extend the automated deployment of both software and infrastructure using Octopus and AWS respectively.

Ideally you will be able to challenge me and teach me new things and I promise to do the same in turn. You will have to be the sort of person who wants to learn and improve, and is never content with simply resting on their laurels.

In return for the qualities above, I can offer a competitive salary (dependent on your awesomeness), a fantastic place to work, some interesting problems to solve and most importantly, Friday afternoon drinks.

If you’re interested, send some sort of introductory email to hr@onthehouse.com.au and put my name on it and I’ll get back to you.

I look forward to hearing from you.