What We Do

Hooroo is a small and nimble startup owned by Qantas. We operate the accommodation business offering 2.5m hotel and Airbnb listings to Jetstar and Qantas flyers. Frequent Flyer members can earn and spend points on our competitive range.

From a technology perspective, we own and optimise the Qantas and Jetstar Hotels products, as well as the platform (written mostly in ruby and hosted in AWS) upon which they are built. Our team also maintains great hotel relationships to source customers the best deals, conducts marketing to keep customers informed and prides ourselves on providing great customer support.

How We Work

Our product development process is based on a balance of quantitative feedback, using hypothesis-based, data-driven optimisation, and qualitative techniques such as customer research and interviews.

We like to work in small, autonomous and cross-functional teams with clear goals. We believe that the best creativity comes when a diverse group of people work together to reach a shared objective.

Our teams establish principles and agree working practices that evolve over time - using frequent retrospectives to drive continuous improvement. Some teams practice pairing exclusively, some teams do it ad-hoc. All of our teams write automation tests but only some practice TDD. We value a good working knowledge of agile development methodologies (XP, Scrum etc) and Lean practices but we prefer to pick the best parts from each based on our work rather than dogmatically following textbooks.

Here's an example of some principles and practices taken from one of our teams:

Our Roles

Using Leanpub, we have a published document that describes the roles in our Engineering Team, along with their expected skills and responsibilities. The document forms the basis of assessment during the interview process and gives existing team members a clear picture of career progression. Just like the way we work and the tools we use - it's constantly evolving.

Our Hiring Process

However the mechanics evolve, our hiring process is aims to find out what each person enjoys and what individual skills they bring to a team. Typically all of our steps are very conversational. We want candidates to be relaxed and open.

We believe in the following values:

• Transparency & honesty - we share what we do well and what we’re trying to improve. We give and welcome honest, objective feedback.
• Respect - for each candidate, their individual skills and goals, and especially their time.
• A positive experience - whether we're a good match for a particular role or not, we aim to have every candidate leave with a positive impression of our team.

Rough Steps

We agree the steps at the outset of each role, but the following is typical:

1. Introductions

Objective: expectation setting and allowing the candidate to get to know us.

We meet up to say hello, usually over a coffee or lunch. The aim of this step is expectation-setting - no assessment of the candidate is done at this stage - in fact, quite the opposite. We want to tell the candidate all about our team, the work we're doing and the role we have open. We also want to learn as much as possible about the candidate; what do they enjoy, where have they felt most fulfilled in the past and what development are they looking for.

2. Technical

Objective: understanding where the candidate sits, with skills and experience, relative to the roles we define

This step might span multiple sessions, depending on the role and candidate.

We'll often ask to see code or, if the candidate doesn't have any they're able to share, we'll ask them to write some for us. Usually solving a simple problem with enough depth to facilitate good conversations about design.

If the candidate feels confident enough we may try some pair-programming. Given that not every great programmer is great at pairing and the interview situation is nothing like the normal working environment, we don't do this for every candidate.

At the very least we'll want to discuss code.

We may also want to discuss design at a more abstract level than code - for example infrastructure or systems design.

3. Ways of Working

Objective: assess the candidate's experience and compatibility in terms of product/software development principles

Usually this step will be conducted by people with different core skills than your own (say a Designer or a Product Manager) but it will always be team members who whom you'll be working closely.

We'll talk about what makes an effective team and process. We'll discuss all manner of topics related to how software products are best created and evolved. We value people who can provide experience and diversity to our working processes and will contribute positively to their improvement over time. We don't want to put people in a situation where they're uncomfortable with how we work.

4. Reference Check and Offer

This stage is simple. If we get this far we'll reach out to your references and, based on how the team looking after each role feels, we may make you an offer.