I'm a technical manager who remembers not-so-fondly the irrelevant and absurd ways I've been selected for positions during my working life and want to avoid the mistakes now that I'm in a position to influence our recruiting process. I work for a small firm in Australia and we will soon be looking for a mid-level programmer, mainly to work in PHP and Java, but I want somebody:

  • with real ability, not just prior experience of those languages;
  • who can fit well technically into our small organisation, able to generate solutions and take appropriate initiative without exceeding their authority; and
  • who can fit well personally into our organisation; we don't have a strong "company personality" in terms of team-building exercises, all-hands meetings, vision and value statements etc. but we just expect and trust people to do their jobs.

With those in mind, what techniques and ways would be best to ensure we get a good fit and not just someone who's desperate for a job and will say and do whatever it takes to get one?


1 Answer 1


The best way to hire is to hire someone you've worked with before. The second best way to hire is to hire someone recommended by someone you've worked with before. After that, you are screening random people, and trying to do the best you can in a few hours, to see if they meet the criteria you have.

Let's take each of the three you list.

  • "real ability" - do you have real ability in those languages? If you do, then this is the easiest of your criteria to check for. Recall a few of the "gotcha moments" you've had with those languages (e.g. a nasty threading issue with Java, a situation where choosing between an array list and a linked list had critical performance implications) where you yourself either acquired or exercised real ability, and try to distill them into a good interview questions. If you don't have real ability, you'll need to find someone whom you believe does, and ask them to do this for you.
  • "technical fit" - try to construct an exercise where the candidate is asked to design a solution to some made-up problem, but where the constraints around the design reflect the real-world constraints your firm has. You can keep changing/tightening the constraints, and get a sense of how the candidate solves problem, develops solutions, takes initiative etc. The exercise shouldn't be overly technical, as you don't want to get mired down in the technical bits, but it shouldn't be so abstract that it has no reflection on the actual problems you want this candidate to solve.
  • "personality fit" - you state that your firm just "expect[s] and trust[s] people to do their jobs". If you are hiring folks you know (or know transitively) then this might be a sufficient requirement. Otherwise, I recommend you as a manager, or you as a company, spend a bit of time actually describing (writing down) what a "personality fit" looks like. For example, do you want people who directly challenge their teams, or those a bit more diplomatic? Do you mind if folks are confrontational in code review, or should they be more instructive? Do you want developers who help others (delaying their work), or who care only about the tasks they've been assigned? I think this is really important: if you don't know what you want, how can you possibly select for it.
  • +1 Knowing what you want is key. Only then can you decide the kind of questions you need to ask in the interview, and the kind of answers you would like to hear. And I don't mean checkbox answers either. You probably want open-ended questions about how the applicant reacted to past challenges or how they would approach technical challenges. The answers will help you figure out if they're a good fit or not.
    – Llewellyn
    Commented Apr 22, 2020 at 18:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .