How to Hire an Engineer When You Don’t Speak Tech: Top 5 Areas of Confusion in Engineering Recruiting


business man designing a database plan on a screen
Let’s face it: nearly every company needs to fill technical roles these days. But the fact is, many people involved in hiring for these highly-specific roles–from recruiters and hiring managers to CEOs and members of the Board–don’t have a technical background. This can be a challenge when you are trying to fill those roles.

At the technical recruiting firm where I work, not everyone comes in with a technical background but, as a technical recruiter, there are certain basic elements you need to know to search for, and speak with, the right candidate. We equip our team with a crash course in engineering functions to help them ask better questions, speak more articulately to talent and clients, and to provide them with an overall better understanding of the roles that they’re filling—a more efficient and deliberate recruiting marketplace helps everyone.

Part of that course includes the top five areas that every technical recruiter must be able to discern, but which many people with non-technical backgrounds often find confusing. Having just a little bit of knowledge around these areas will help anyone with a non-technical background have more effective conversations with those that do “talk tech.”

#1: What’s the difference between data science, analytics and business intelligence?

The analytics and data science spectrum is still fairly nascent. For example, you may have someone that’s truly a data scientist doing analytics. There’s not so much a hard and fast guideline on what makes this a job; it’s really about the need of the company. More important is the identification of a cultural fit. Does this person understand what is of value to the company, and what the company’s competitive advantage is? A lot of times, this person has to draw contextual lines between what they see and what the company needs, so the lines between these areas are often blurred.

There are three parts to the continuum of reporting and visualizing data, and predicting outcomes based upon it. Business intelligence is really reporting what has happened by taking performance indicators and metrics that are set for the business, and then reporting out to stakeholders how the company is doing.  Business intelligence also typically includes providing visualizations in a way that makes the results of any time series changes apparent.

Data analytics is forecasting various scenarios of what could happen based on what the business is doing now, as well as finding out underlying causes for what happened and why. Extrapolating and drawing insights from data you have–and often data you don’t have – to help drive insights.

Data science is a little bit of magic: Using data you don’t necessarily have to figure out things you don’t know that you don’t know. The difference between this and analytics can be nuanced, and there is a lot of overlap. With data science, you’re figuring out things that are seemingly unrelated, including determining causal relationships and whether those are spurious or real, and then drawing conclusions from that and figuring out what to do with those conclusions. In reality, people use the term ‘data science’ far too broadly, and the key is really to know what information is most important to each individual company.

#2: What is the difference between DevOps and TechOps?

With the evolution of technical operations to cloud-based platforms, and the evolution of DevOps to agile development, there’s no longer a “build it versus run it” mentality in engineering and operations. More and more, hiring managers are looking for people who have experience managing cloud environments, multimodal infrastructure architecture, or who have the ability to build private or hybrid cloud environments.

TechOps isn’t dead, but it has changed and is still evolving—bare metal is still primarily in the data center and collocated facilities. Managing rows and rows of racks with servers running apps, and those servers need to be procured, imaged, tested, burned in, monitored–all of that is in the domain of TechOps. More and more, we’re not seeing separate teams managing and monitoring these servers – the infrastructure is in the cloud, which makes it very easy for someone who doesn’t have the background in this (or the capital to buy the hardware) to do it because Amazon or Google or Microsoft does it for you. However, depending upon how the application is architected, a hybrid deployment model may make the most sense and that requires a close integration of engineering and operations teams.

The DevOps paradigm has allowed engineers to embed continuous integration into their workflow paradigm and harness the power of continuous deployment. Which, for many, is optimal. They’re writing more modular code, it’s getting tested and getting pushed into production, and they are on to the next feature request. People want to see results more quickly -they want to know if what they’re making is what users want – and speed of development and deployment is more critical than ever.

#3: What does infrastructure actually mean to each company?

The word infrastructure can mean different things: It can be TechOps, DevOps or the software infrastructure that’s built on top of the operations. Companies often look for infrastructure engineers, which are increasingly more common, who are really software engineers. They’re creating custom software ‘guts’ for the platforms that applications are built upon. Commonly, though, recruiters are looking for a different kind of candidate than is really needed.

If you’re looking for an infrastructure person, dig into what that really means for the company. It’s common to look in the wrong place. Candidates themselves are saying “that’s not me,” so you need to know the skills and specifics of what’s required. Recruiters should ask the hiring manager if this person will be setting up the ops department and buying servers for the data center, or if they will be integrating the software services that sit on those platforms? Are they going to write custom code, or create bespoke platforms for high-availability services?  If so, you need to look for someone who has set up these services on top of operations environments. The question is: what’s most important, and what is the company willing to take a chance on: Are they willing to take a chance on TechOps versus software/SRE or vice versa? There is no one right answer, and the candidate’s ethos and approach for how software should be written and deployed is what really matters.

#4: What does cloud architecture mean?

Success in cloud architecture is about getting specific on what is required. It could mean putting together several of the services AWS offers to construct depth into your application, or it could mean building a private cloud in your own data center with something like OpenStack or CoreOS or Mesosphere — or other tools created to build your public or private cloud. It could also be about finding a software engineer who is architecting an application to run in the cloud, effectively utilizing services cloud providers are giving you, or about finding an engineer with depth in the underlying systems. We see openings for both of these types of engineers, and leaders, with a title that includes the word ‘infrastructure.’

#5: Security: what are the different kinds?

Security is very multi-layered, and one of the most important things a company can do is pay attention to security. It starts at the software level. Are we writing secure code? Are there holes or backdoors in our software? How do we know? There’s systems security — are the operations of the company secure? There’s network security, which is the gate that protects systems from outside threats. And, of course, there’s information security, which are the tools, policies, and procedures that embed good security and privacy practices into a company and its products.

If you’re looking for CIOs, CSOs, or CISOs, consider how technical they need to be. They should at least have a deep understanding of different layers of security. The litmus test is to ask them what they are best at – most good security executives know their areas of expertise and are up front about it.

In many cases, especially for startups, finding the right talent is critical, but so often companies are forced to try to make hires with limited understanding of what each role REALLY requires. It becomes even more complicated when the role is a technical one and the hiring team doesn’t speak the language. There are, of course, many variants of the above and lengthy discussions can be had about each one, but hopefully this brief summary of some of the more common, often confusing types helps with directionality.


Image credit: CC by tec_estromberg

About the author: Sam Wholley

Sam Wholley is a partner at Riviera Partners, working with public and venture-backed portfolio companies to build top-tier executive and management teams

You are seconds away from signing up for the hottest list in New York Tech!

Join the millions and keep up with the stories shaping entrepreneurship. Sign up today.