Category Archives: Recruitment

Joining TheTradeDesk (BOOTCAMP!)

Three weeks ago, I started my journey with TheTradeDesk. Working for a US-based scale-up has long been one of my dreams – I’ve come really close a few times, including turning down an offer to move to Seattle a few years ago due to a previous long-term relationship. But this time it finally happened – and the experience so far has been great.

My favourite local spot for a bit of (picturesque) remote work

I’ve really been enjoying inner-city living in Brisbane (especially some of the great remote-working spots I’ve found near my apartment), but TTD has proven very open to remote work. Their closest physical office is Sydney, and they’ve promised me trips there as well as to the US offices (COVID-permitting – and it looks like it finally will).

BOOTCAMP!

TheTradeDesk has a great initiative called Bootcamp. New starters don’t go straight to the team which hired them: instead they join their local bootcamp team (for around 8 weeks) to make sure they get a great on-boarding experience. This makes sure new starters get a chance to learn properly, rather than being thrown straight in to delivery-pressure mode.

I’ve been given plenty of time to learn: I’ve spent time, among other things, learning about our employee stock program, our T4 template code generation, our EF Core standards, and our extensive Engineering Meta repository – the source of truth for our extensive and open-to-contribution software engineering standards. I’ve also been exposed to real tickets – bootcamp participants are given a variety of non-time-sensitive tickets from across the organisation to give them real-world opportunities for hands-on learning.

I think this is a great way to onboard people, but I’m also really looking forward to taking on the full role I joined TTD for.

Staff Software Engineer – Front-end

Any readers who’ve known me from earlier in my career will recognise what a big shift it is for me to go to a front-end-focused role. I started my career as a back-end engineer with a well-developed allergy to anything front-end, but over the years I’ve done the needful – which has often been to make sure my team’s front-end engineering is keeping up with the trends.

This is a shift back onto the tools as well. I’m still developing my sense for the right ladder-vs-pendulum approach for my own career, but I’m confident I’ll enjoy getting back to coding for a while. I can’t keep myself away from writing code even when I’m meant to be focusing on being a manager, so this is a very comfortable shift for me.

A new sense of scale

One of the things I wanted most of all with this job change was the chance to learn – and I have that in spades. For a start, I’m faced with the largest code base I’ve ever worked on. More interestingly, the data involved creates genuine engineering challenges: TheTradeDesk deals with true web-scale (and I mean “a large fraction of the web“-scale) loads, dealing with upwards of ten million requests per second (that’s over 800 billion requests per day!).

Along with the engineering challenges, we are a rapidly-growing organisation, planning to significantly increase our software engineering team in the coming year. That creates plenty of opportunities for me to contribute to initiatives that will help grow our team – something I’ve been passionate about for a long time. Everything I’ve seen so far makes me very confident in recommending TheTradeDesk as a great place to work for people at any stage in their career.

If you’re interested in learning (don’t worry if that level of scale sounds intimidating!) maybe TheTradeDesk would be a good next role for you too.

Hiring

If any of that sounds interesting – please get in touch. Particularly if you’ve worked with me before! While TheTradeDesk has no current plan for a Brisbane office, I hope to thwart that lack of a plan by helping to recruit a heap of new engineers in Brisbane. I’ve worked with so many talented developers over the years, and I would love to see some of them join TheTradeDesk. We’re focused on hiring a balanced team, so I’m particularly keen to hear from early and mid-career software engineers looking for a career change (but there are roles for more senior engineers as well).

If you’re interested, start by getting in touch with me – you can find me in all the usual places (LinkedIn, Twitter, or @rophuine in some of the local developer Slack groups). We’re particularly looking for .NET and React developers, but we’re open to people with other skillsets (and we also need account managers, BI analysts, data engineers, and more!).

What I talk about when I talk about DevOps

What does ‘DevOps’ mean, anyway?

devops-photo-mEarlier in my career, I was a DevOps consultant – and we were trying to hire other DevOps consultants. But the software industry is actually quite confused about the term ‘DevOps’ and what it really means. I was starting to wonder whether putting ‘DevOps’ in our job ads might actually be counter-productive – and sitting in a seminar at YOW! one week, I finally understood why.

Elabor8 (where I worked at the time) had a booth at YOW!, and I gave a couple of lightning talks there. Probably the biggest crowd-pleaser was my talk on resiliency patterns in distributed systems. I covered some difficult topics like the importance of having idempotent rollback steps in compensating transactions and how lessons learned from the ship-building industry help us craft better distributed systems, all presented in 10 minutes in a crowded event space.

Hang on, you may well ask. If I’m a DevOps consultant, why am I talking about atomicity and consistency in distributed systems? Shouldn’t I be talking about cool PowerShell tips and how to set up Jenkins?

As is so common with rhetorical questions, the answer is a resolute ‘No’.

When I talk about DevOps, I talk about Software Engineering.

When I do DevOps work, I’m doing software engineering. When I hire for DevOps roles, I hire software engineers. But I don’t hire just any software engineers: I want the ones who care about the delivery process. They know how to build software, and also how to put it in front of the user – and how to keep on putting that software in front of users, sprint after sprint, story after story, rapidly, efficiently, and without breaking things.

‘DevOps Engineer’ is the next ‘Full-Stack Developer’ – and not because it’s the next hype-cycle in tech hiring. In the same way full-stack developers expanded their scope to cover both the UI and the back-end, DevOps engineers have expanded their scope beyond writing software – and into the realm of how we get that software in front of users, in the fastest and most reliable way possible.

No longer are we content to just build back-end systems and UI layers on top of them: as a profession, we’re coming to understand that software engineering is bigger than just churning out vertically-sliced user stories. Software engineering is about building the right thing and keeping it running – and a DevOps engineer is a software engineer who cares about both steps. You don’t want a team full of DevOps engineers – but you definitely need at least one.

When I talk about DevOps, I talk about Agile.

You start to see the real benefits of automation when you’re deploying to production regularly. For example, if you’re only shipping a few times a year, the overhead doesn’t hurt you that much. If you have a 6-week QA pipeline and a 2-month UAT window, you don’t need DevOps (yet) (but you do need to change something! Ouch!). Once you start trying to deploy regularly – getting your cycle time down, keeping your WIP low, delivering value to the user faster and more frequently – that’s when the overhead starts to hurt.

Once you introduce agility to your process, that’s when you need to pay attention to the DevOps movement. That’s when you need some software engineers who care about automation. Please note though that I’m not saying you need “some DevOps” – there’s no such thing as “some DevOps”, and anyone who tries to sell you “some DevOps” is doing you no more favours than someone who tries to sell you “some Agile”. What you need is some smart software engineers who care about DevOps – and you need to give them the time and resources they need to do their job.

When I talk about DevOps, I talk about teams.

DevOps engineers are software engineers, but that doesn’t mean you should fill your software teams up with DevOps engineers. DevOps engineers tend to be passionate about a bunch of really interesting stuff: resilience patterns, testing, automation, source control, and release management. The great thing about multi-disciplinary, cross-functional teams, however, is that you get a bunch of people with different passions together, and that breadth gives you the ability to do great things. Don’t try to hire DevOps engineers (or worse, to build a DevOps team). Hire software engineers, and when you find ones who are great at DevOps, keep them.

Having cross-functional teams also gives your team members the chance to cross-skill while they work with other team members, which is why…

When I talk about DevOps, I talk about teaching.

Great DevOps engineers have a genuine enthusiasm for quality software engineering and release management, and their enthusiasm is infectious. Great DevOps engineers don’t hoard their knowledge, but help their fellow software engineers to learn more about the DevOps mindset by sharing what they know. They also learn from their colleagues who specialise in other software engineering fields, becoming more well-rounded themselves as they help others do the same.

Finally: When I talk about DevOps, I talk about people.

DevOps is a branch of software engineering – and whatever you might hear, software engineering is all about people. It’s about the people who use our software, and the people who build it. DevOps is the intersection of those two groups: users and developers. Our users are not just end-users, who enjoy higher-quality software, but also our fellow engineers, who rely on our automation to work more efficiently. They’re our managers, who rely on the insights we give them into the release process. Our users are the junior software engineers who may one day specialise in DevOps engineering – or who might use what they can learn from us to be better at some other branch of software engineering.

Update (2021): If you’re a software engineer who cares about the difference between GitFlow and GithubFlow; who has made calls to the Octopus API; or who loves showing other developers how to write a better test or add more context to a log message; please talk to me about joining Squiz. It’s a great team, and whether or not we’re actively hiring for a role, I can look to see if there’s a place for you here. If you want to take the engineering you care about and have a broader impact on more people, you want to join us. Get in touch.

Anatomy of a Job Ad

Wanted: Senior DBA!

  • Minimum 10 years experience managing SQL Server 2015 or newer

It’s a classic joke – the job ad which wants you to have experience in a specific technology for longer than it’s existed. Sadly, it’s funny because there’s a grain of truth in it: job ads are terrible.

pexels-photo-52608 (Small)Wanted: Junior Developer

  • 1-2 years experience writing software
  • Strong knowledge of SQL, git, Python, Haskell, and Perl
  • Good UI skills, excellent API design skills, knowledge of ESBs and other distributed software patterns
  • Excellent grounding in the principles of good software design and Agile project delivery
  • Experience with [you usually find a list of specific platforms and libraries here]
  • Go-getter, always-be-learning attitude
  • Highly regarded: strong maths and stats skills, C++ experience
  • Highly regarded: exposure to data science, experience with Big Data platforms such as Hadoop
  • Excellent communication skills are a must!

I hate seeing job ads like this one. You want someone with 1-2 years’ experience to know all of that – and be confident enough to tell a recruiter that, and back it up in an interview? You’re not selecting for capability here. You’re selecting for over-confidence, and the coincidence of having a first job which involved just the right mix of technologies.

Technology Leadership Position!

Are you a dynamic leader with top-notch management skills and brilliant technical ability? Do you have world-class knowledge of big data platforms and machine learning? Are you just as comfortable writing a PhD dissertation as you are selling a group of executives on a new company strategy? Do you have a passion for creating a dynamic company culture and mentoring a team of brilliant engineers, all while maintaining an unwavering focus on creating an unmatched user experience? Do we have a job for you!

If you’re posting a job ad like this one, you’d better have a remuneration package to match; but you probably don’t. The technology industry is full of people with imposter syndrome – and if the perfect applicant (who would have been great for your team) didn’t have it before they read this job ad, they will afterward. If the candidate who does meet that brief exists, they’re definitely not reading job ads on Seek, anyway.

These are, of course, caricatures, but they’re not so different from real job ads I’ve seen. How about a real example from my own life?

Checkbox Syndrome

Many years ago, I landed a job in the United States (I’m based in Australia, so this would have been a big move for me). The recruiter explained that the job had been open for nearly two years, and they were thrilled to have found me! I was their first suitable candidate, and they were keen to rush me through the hiring process.

This puzzled me, because I’m not that special. How was I the first suitable candidate in two years?

Well, it turns out that they’d written a very specific candidate description, and someone in HR had been handed the job of finding someone that matched. They were after someone who listed optimising high-throughput transactional systems on their LinkedIn profile, and who had completed at least two years of tertiary study in Latin or Ancient Greek.

They were building some language-processing software, and someone had decided that an engineer with a background in linguistics would be good to have on the team. That was somehow translated to requiring some tertiary education in a classical language – and bam! Two years of turning down candidates who probably would have been highly successful in the role. All they actually wanted me to do was to come up with a way to load-test the system, and then find hot-spots in the code and optimise them.

I never did end up moving to Houston: my visa application fell through (thanks, Global Financial Crisis). It was probably for the best: I wouldn’t have been a person to this company, or even an engineer; just a series of checkboxes.

What is a job ad for, anyway?

When you’re writing a job ad, please don’t forget what the ad is for. Your goal is to attract suitable applicants to apply, and discourage unsuitable applicants. Anything which doesn’t accomplish one of those two things is wasteful. Anything which discourages suitable applicants is a net loss.

As a specific example of this, please leave “Good Communication Skills” out of your ad. You might think that poor communication skills will disqualify a candidate – but putting that in the ad isn’t going to stop unsuitable candidates from applying, and it’s not going to encourage suitable candidates to apply. It’s noise. Leave it out.

Sell the job – genuinely

It all starts with empathy. Try to imagine yourself as your target engineer, tester, analyst, or whoever you’re trying to hire. Your goal is to sell them on the job, but also keep enough important criteria in there to discourage unsuitable applicants. The selling part is important: if there aren’t many great candidates out there, you need a job ad which will attract them. Candidates are about to invest a significant amount of their own, personal, outside-work time in applying for and interviewing at your company, and then you’re going to ask them to resign from their current position, where they have friends and valued colleagues and know the system, to join your team. Give them good reasons.

Please don’t give them a sales pitch. Don’t spend most of the ad spruiking the company. Talking about how great you are is for your marketing material, or your annual shareholders’ report.

Just talk honestly about your culture, values, and benefits.

Anatomy of a Good job ad

Here it is. This is what your job ad should look like.

  • Talk about the role.
    Tell prospective candidates a little bit about the company and the role. This should be short. What does your company do? Who are you looking for? How will this position further the company’s mission?
  • Say who you’re looking for.
    Really cut it down. Don’t have 10 bullet points. Keep it to 3 or 4. Try to focus on higher-order skillsets, rather than specific technologies, unless that technology really is core to the role.
    If “Good Communication Skills” is making it to your short-list of 3 or 4 key skillsets, I hope you’re hiring a radio operator or air traffic controller. Otherwise, please, just leave it off.
  • Tell them what’s in it for them.
    Describe your benefits. Tell them about the great company culture. Talk about training and conference budgets and career opportunities. Once again, keep it short and to the point.
    If you can’t think of anything to put here, you might have bigger problems.
  • Tell them how to apply.

That’s it. Really. No nice-to-haves – those just give suitable candidates a reason not to apply. Don’t do that. If you get two suitable candidates, and one of them happens to have one of your nice-to-haves, you might still offer the role to the other based on the bigger picture. If it’s not necessarily a differentiator even at the end of the recruitment process, it definitely has no place at the beginning.

But I want to list a bunch of stuff!

Resist the temptation. Are you hiring a team lead? Just say you’re hiring a team lead. Don’t list out all the stuff that team leads need to do.

  • Lead a team of software experts to deliver innovative products.
  • Help to work with product owners to deliver real business value!
  • Mentor senior engineers, and help them to mentor juniors.
  • Engage with the business about technical challenges.
  • Foster a strong team culture.

Don’t do this! Team leads already know the day-to-day detail of the role, and they won’t be going back to the job ad to work out how to spend their time. Just say that you’re looking for an experienced team lead or a senior engineer looking to step up to a team lead role – and get on to covering the more important points! What kind of team is it? What is the team mission? Are you looking for someone to drive a major change, to keep an already-high-performing team pointed in the right direction, or to build a whole new team? That stuff is much more useful than saying things like “Ensuring the team is aligned with business priorities”.

Where do I put things like “Strong work ethic” and “Ability to work in a collaborative team environment”?

In the same place you put “Good Communication Skills”. People who don’t have a strong work ethic or the ability to work in teams are going to apply anyway, so all you’re doing is making the job ad longer and more boring.

This sounds like you’re a really cool person and I’d like to work with you.

TheTradeDesk is looking at hiring a heap of software engineers in the next year!

Wait, was this secretly a job ad?

No. This doesn’t match my “Anatomy of a Good job ad” at all! But recruitment is bigger than just job ads, and this was, secretly, a bit of guerrilla recruitment. That’s another idea I’m hoping you’ll take away from this post: recruitment is about a lot more than just writing a good job ad. It’s about being a place people will want to work, and making sure the right people know it.