Choose The Right Job in Data: 5 Signs To Look For In An Engineering Culture

By Niv Sluzki, R&D Team Leader at Databand.ai

Photo by Ruslan Burlaka from Pexels
 

If you're a software engineer looking for a job at a data company, I'll let you in on an open secret – the explosive growth of Big Data means that the world is your oyster. As a hiring manager competing for talent to build our data observability platform, I can tell you that most jobs will come neck-and-neck in compensation, title, benefits, and perks. 

The area that's woefully overlooked is engineering culture. 

I'm not talking about superficial signs of "fun." I'm talking about indicators that a company has intentionally organized itself to produce the maximum value for its customers – even if it means running its organization in an unorthodox fashion.

In my experience as an engineering team leader, I’ll share the top five signs that show a company is built to innovate and to endure. Be assured that you'll be offered generous compensation no matter where you look. But if you entered this field to satisfy a sincere purpose to build something valuable, turn the tables at your next interview to assess a company's engineering culture to pick the team that deserves you.

 

1. Do They Celebrate Full Stack Competency?

 
To anyone who dismisses generalists and perceives jacks-of-all-trades as less valuable than specialists, think again.

A full-stack engineer is a well-rounded player who doesn’t depend on anyone else to complete their work. They can single-handedly provide value to your organization.

In short, they’re awesome.

This week I asked our amazing full stack developer, Ilan Techenak, to develop a service that runs in our deployment, monitors Google's BigQuery data warehouse, and allows users to integrate with it from within our Databand application.

Let’s take a second to acknowledge the breadth of knowledge and expertise required to complete the subtasks involved in this mission:

1. There are many other aspects inside this task – how we manage user's secrets, how we integrate with the user's GCP service account, how we monitor our own system, how we test it end-to-end, and so on.
2. We need to develop a BigQuery agent – an obvious backend service.
3. We need to let users integrate the monitoring system with our app – both frontend and backend work, including introducing new APIs, and UI changes. Most of our backend is written in Python and Vue.js, and we use PostgreSQL as our DB.
4. We need to make this service run in our deployment – our system runs inside Kubernetes and is being managed with Helm deployment. We use GitLab as code management and for CI/CD. Time to stretch your DevOps muscles.
5. BigQuery was new to us at this point – we needed someone with the ability to dive into a new technology and focus on learning what we need to get the product requirement. We could have asked a database expert to understand how BigQuery works, the internal mechanism that keeps BiQuery users up at night, and what metrics they care about. While this sounds good on paper, none of our BigQuery customers need this level of granularity and it will take a lot of time to learn it.

A full-stack engineer needs to possess a vast skill set in order to accomplish this range of tasks. But even more importantly, they’re first oriented around how to achieve a business goal and how to create impact and value to the client (and therefore to the company). A full-stack engineer takes a big problem, such as "we want to monitor BigQuery" and splits it into multiple subtasks within different disciplines, different code languages, different technologies, and different kinds of expertise. At their core, they’re expert problem solvers who figure out the solution on their own based on any problem given.

They are, like I said, awesome. 

A company that values interdisciplinary competency typically embraces new ideas, new ways of seeing things, and new ways to solve problems. Companies predisposed to newness cannot help but function in a more creative manner.

 

2. Do They Value Diversity In Skills?

 
All that being said, full-stack engineers thrive when they have the support of specialists and an infrastructure team that focuses on infrastructural soundness and voices caution when risks begin to mount.

Take a look at Jonny Barda – a top-notch backend engineer, a fan of code philosophy, a purist, and an enthusiast for real complex engineering problems. A full-stack engineer needs someone like Barda to help set the parameters to ensure that we pay our technical debts and elevate architecture issues during design planning and reviews.

Truth be told, Barda is indispensable on our team. He provides assurance as we progress because he ensures that our system will not crash frequently nor become near impossible to maintain.

In addition to the specialists on our team, we also have an infrastructure team consisting of company-wide figures who help to navigate the ship. Our architect makes sure that all of our services are in good shape, helps the engineers with the biggest design problems, and leads the infrastructure team. Our Frontend Tech Lead owns our UI architecture and is capable of choosing the right tech stack to make sure that we have the right infra for tests and shared components.

Lastly, we have DevOps masters who are in charge of all the deployment, monitoring, and CI/CD.

As you can see, there's no lack of ownership in any part of the system.

Our full-stack engineers rely on the infrastructure team to think about big company-wide problems, share knowledge, solve complex problems, and prevent us from doing double work that other teams are already doing.

Together, each function plays a unique role to build a product that will bring value to our customers. What makes them shine as a team is their difference in strengths and how they complement one another. For everything that our full-stack engineer is empowered to break in their quest to test and solve problems, there’s a specialist and an infrastructure team that prevents problems down the road.

Companies that deliberately fill their team with a breadth of skill sets can be emboldened to take greater risks in pursuit of improved outcomes and therefore emerge as more competitive businesses. While bold decisions may appear to incur escalated risks, the support offered by specialists and the infrastructure team ensure that all risks are, in fact, calculated and mitigated. 

 

3. Does Their Team Makeup Encourage Agility?

 
Software changes as understanding of the customer changes. Embracing this reality means that agility must be built into an engineering culture. Improvisation is not a rare occurrence but a distinct capacity that the team taps into regularly.

Imagine for a second that you have a band – like we do at Databand – and your band is working on a lot of new songs in parallel. During production, inspiration strikes and you need to add more sounds like a small guitar line or few bass drum kicks to round out the sound. Full-stack engineers are the kind of multi-instrument band member who can improvise on the fly. They especially prove their value when you're running multiple complicated projects that involve a lot of moving parts. I assure you great music owes a lot to improvisation, as does great software. 

If we were organizing our teams by functional specialty – frontend team, backend team, and so on – what required one full-stack engineer would now require 3–4 different teams to tackle.

At Databand, we make sure our product teams are built with 70% real full-stack engineers and 30% professional specialists. This allows each team to be entirely focused on a business goal and have all the capabilities it needs in order to succeed. Our infrastructure team is dedicated to solving hard engineering cross-company problems, improving our internal development experience, and making sure we lay the right foundations that will allow us to grow effectively and efficiently.

The engineering team makeup is one of the easiest ways to gauge the priorities of an engineering culture. Teams with a greater percentage of full-stack engineers will be able to execute with agility consistently. Agility is not treated as a goal but an organic way of being.

 

4. Do They Measure Everyone By Their Own Function?

 
According to Emily Heaslip's article at Index, it seems that measuring a developer is based on the following KPIs:

• Cycle time - The speed it takes to the developer for moving a task from one status to another, AKA, how fast he develops a feature, fixes a bug, and removes bottlenecks.
• Sprint burndown - which allows you to understand if you are going to "make this sprint work", AKA, finish most of the things you planned to finish in this sprint.
• Velocity - How many completed features were delivered
• Opened requests - How many "Jira tickets" were not answered
• Throughput - Summarize all the above in the last week \ month.

Although how to measure software engineering is a highly debatable topic, the above 5 bullets can give us a reasonable tool to measure a specialist or an infrastructure-oriented engineer.

When measuring these kinds of engineers, you will be focused on their code quality, the number of technical debts they created and solved, how they reduced the maintenance effort needed, their test coverage, and the fact they chose the ultimate tool for the solution.

Full-stack engineers need to be measured by a different stick where we focus on other kinds of performance:

• Business impact – how did their features improve our business KPIs? How many new users are using the system because of it? How many users come back to this feature? Is it solving a real problem for the users?
• Agility – if we needed to remove an entire feature tomorrow or expand it to support different technology stacks, how fast can he implement what’s needed?
• End-to-end responsibility – the full-stack engineer should be able to work independently, develop his feature from DevOps to FE, be capable of the feature, make sure it's fully tested, and fix any bugs we found in it.
• User experience – in order to fit the business goal, the full-stack engineer most likely understands how the end-user is going to use his feature.
• Tech debt – we expect the full-stack engineer to point out the tradeoffs he made in order to deliver quickly and raise a red flag whenever he creates a big technical debt.

In sum, full-stack engineers should be measured in terms that align with the big picture business goals that they’re asked to meet.

This measurement distinction is important because it tells you whether the company is serious about setting up its employees for success. 

 

5. Do They Value Your Character and Humanity?

 
The most important sign of all to look out for is that a company sees you for more than a set of skills that match their boxes. Find a company that will value you as vastly greater than the sum of all your skills and experiences. 

All of our hiring managers recognize that skills can be learned and sharpened. We have some very fine developers and they all came to us from different experience levels. What they have in common are qualities that we consider more valuable than orthodox code mastery:

Humility. While I believe this is an important trait in any environment, it’s paramount in an R&D environment where newness never goes away. Humility signals a balance between confidence to try new things and tolerance of being wrong.

Fast Learners. When we recruit for open roles, we're not always looking for very experienced developers. We simply ask candidates to convince us that they're able to easily learn new technologies quickly.

Desire for Growth. All candidates we consider are smart and sharp. The ones who stand out always exhibit a drive to become specialists in a specific area one day.

Business-Driven. Our team has no shortage of extraordinary developers who can write beautiful, elegant code. But what separates our team from other teams is that our developers are not satisfied with beautiful code that does not serve a business purpose. They all see themselves as contributors to our bottom line. They're customer-oriented and they feel most validated when their work results in delighted customers.

While these five signs are excellent indicators to help you evaluate prospective employers, they’re by no means comprehensive. There are additional factors that are vital as you consider the opportunities that come your way. The next time you're called in for an interview, remember that the companies that invest in your potential are the ones that deserve your time and talent. 

Be prepared with questions to help you decide. Good luck!

 
Bio: Niv Sluzki is R&D Team Leader at Databand.ai where he oversees the Data Health development team. He’s a former major in the Israel Defense Forces Intelligence Corps where he was in charge of leading and managing dozens of complex Big Data projects in different environments. He is an experienced full stack developer who worked with different product managers on a variety of products, including Innoviz’s InnovizOne driver, a cutting edge LiDAR sensor for the self-driving automotive industry.

Related:

• 7 Differences Between a Data Analyst and a Data Scientist
• How to Build Strong Data Science Portfolio as a Beginner
• Path to Full Stack Data Science