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

If you’re a software engineer looking for a job, I’ll let you in on an open secret — the explosion of development jobs means that the world is your oyster. As a hiring manager competing for talent all year round, 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 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 can tell you 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 new technology and focus on learning what we need to get the product requirement. We could have asked a Database expert to understand how big query works, the internal mechanism that keeps big query users up at night, and what metrics they care about. while this sounds good on paper non of our big query customers need that 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.

#2 Do They Value Diversity In Skills?

All that being said, full-stack engineers cannot fully thrive without specialists and an infrastructure team who focus on infrastructural soundness and voices caution when risks begin to mount.

Take a look at Jonathan 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.

#3: Do They Treat Software As Both Art & Science?

Imagine for a second that you have a band — like we do at Databand.ai — 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 a few bass drum kicks to round out the sound. Full-stack engineers are the kind of multi-instrument band members 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.

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.

#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 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.

#5 Do They Value Your Character and Humanity?

Our team has proven that all 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 vastly 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.

— — — — — — — — —

These five signs are by no means comprehensive. There are additional factors that are vital as you evaluate the numerous 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.