Best of 2021 – Hiring When You’re Not FAANG

As we head into 2021, we at DevOps.com wanted to highlight the most popular articles of the year. Here is the 20th episode in our Best of 2021 series.

Most of us aren’t FAANG, nor should we act like we are. Instead of using that, I’ll use the term we used to refer to them: “web monsters”, which isn’t 100% accurate, but only includes more than five members of FAANG (Facebook, Amazon, Apple, Netflix and Google) for this article. At some point, we’ll need a new term. Web Monsters clearly does not include Apple or Citi, but FAANG clearly excludes Citi and eBay. But this blog is about something else, so please accept my apologies for this lack of clarity. Assume that “Web Monster” means “a large, popular high-tech company that pays well and looks good on its resume.”

There are many angles to “not web monsters” that we can tackle, but I’ll mostly focus on hiring DevOps, with a nod to unrelated sales/marketing techniques. Hiring is an easy target because Web Monsters offers resume building and pay and benefits very attractive in the industry, so they can (now, at least) turn down 99% of applicants and still have a good selection of candidates to choose from. Most organizations can’t even compete in one of these areas, although few can when it comes to salary and/or benefits.

We have always been in the IT industry to ask our applicants to be more qualified than the average employee. It’s ridiculous at times; Things like asking for a candidate who has more years of experience in technology than the technology itself already in place. What happens when you ask for the impossible? Honest and qualified applicants pick themselves up, and only those who don’t realize that technology hasn’t been around for so long and liars end up getting ahead. This is just a bad hiring policy, even if that’s you be Web monster. But in smaller organizations where each employee has a greater impact on the organization, this can be devastating.

It looks even worse in DevOps. In fact, all the recruiting items listed here look worse in DevOps because DevOps are actually a combination of that annoying skill set. No two people identify the same job because the “job” covers everything from cradle to grave to applying. There is no part of the application developer that “DevOps” cannot touch. This is problem number one. Define the role’s responsibilities clearly, and don’t ask for it all can is being. As a rule, an Ansible specialist will not be an expert in DevSecOps, and you should not expect it. I think, at the very least, that we need to break down the staffing along my traditional lines of focus… DaveOps and DevProcesses. If you are writing code and using Checkmarx while GitLab is building the results and you have configured it to be put out for testing… you are not a developerProcesses Engineer, although there are a few operations out there. Your strengths should be under development and configuration of the application. Your job description needs to focus on that.

Could there be roles that you all need? Yes, especially in an SRE or chaotic engineering space; I can see that. But they’re definitely not entry-level roles, or even close. Knowledge of the breadth of technologies required to touch the entire DevOps toolkit has been developed over the years with healthy curiosity. And of course, the person you hire should have skills similar to those of the people who do the job today. And it’s a good mental check against “throwing in the kitchen sink” syndrome.

Next is taking home tests and participating in coding during interviews. We know you have a vested interest in having the best people, but if you do your coding exercises with people who are basically developersProcesses-You’re wasting everyone’s time. Most developmentProcesses Tasks are done using PowerScript and/or bash using YAML files. Other languages ​​used sometimes have no place in the primary job interview any more than the other incidental parts. “It’s about how you think” is a common refrain. I would argue that a task that takes hours to complete (or in many cases I know, days) is not an effective way to assess the way a potential employee thinks. And in at least one case, I’m pretty sure the interview solved a real problem that the employees didn’t — or couldn’t — solve. Ask the candidate questions about how to solve problem X. Ask them complex questions. They don’t need to get to the code level to show you how they think.

And finally, my nod to bad marketing: Unless you’re already doing one volume of web monsters, the fact that Facebook is a customer of seller X totally irrelevant. In fact, like the government, most sellers can mark one or more Web Monsters as their customers, just because Web Monsters are so big that they try to use a lot of different tools across many different teams. So their presence as a customer must be irrelevant, but if it is not considered irrelevant, it must be expected.

The team that you have today shake it up. Hire more people like them. You know what works and what you need. Go back to customizing your hiring process to deliver more of what you need and stop over-demanding. There are more great people out there looking for roles; Don’t scare them by asking for an unrelated experience. Stick to the core. What will they do daily? Ask for it, then look for other helpful items at interview time. And get more good peeps in the seats!

Leave a Comment