“We are a tech company that leverages certain kinds of technology…”
I had heard about each of the companies when I interviewed for a software engineer position after graduating from College. An HR representative convinced me that their company has a different culture than the others - that they have various cool benefits and perks and give a lot of growth for their engineer; that their company is an engineer led company. However, more than often, you realized that the company is no more or else than the previous company that values business first and technology second.
Many companies claim to be engineering-driven, but few actually are.
Often times, we as an engineer - we value a lot about technology.
We care about resolving technical debt - writing readable and maintainable code. We said that technical debt will hurt you in the future and that we want to make things work and make it better.
However, as we walk into our daily job, companies often don’t care about these aspects - because as long as it works, that’s what it matters. When you want to improve the system to be faster or realize that new technology can decrease engineering time, the product team often doesn’t really care. You might notice that they might put software engineer as second class citizens. In many business-led companies, IT-involved business people will usually need to persuade on engineering topics. The entire department often gets characterized over time - by believing that developers often take as much as you give them—engineers on those departments are usually depicted as a cost, not a talent.
They think that technology is an overhead rather than a differentiator.
In an engineer led company, you will often see that engineers are given free rein to work on the things they want to. You will also notice that their opinions are values, and they are seen as a talent rather than an overhead. Often, you will see that the structure and hierarchy of the organization relatively flat. That means hierarchy is often avoided, and engineers are usually given full autonomy in executing business features. You will also see that decisions are made in objective criteria.
For example, Google is trying to choose which blue color of a button to use on one of their homepages. Instead of doing a lot of research and arguing about which color tone best for its user - they did an AB testing on various colors and see which color has the best click-through rate.
Also usually, those who do the work most often make the decisions. Last but not least, you will see that automation is of high value. If something can be automated, it usually is already automated.
It can be quite hard to identify if a company’s culture is engineering driven by just having 5 back to back onsite interviews. Culture is not really something that you can talk about, but it is something that you need to experience.
How do we actually want to identify if the company culture is really engineer-driven?
Each time during the end of the interview, we usually get the questions, “Is there any questions you have for this company in general or for me?”
You should not ask about its technology stack and some vague questions such as, “How was your day to day work like?”
You should leverage this to get as much information about the company as possible - to see if that company is the company you want to spend the next 2 - 10 years of your life.
You can gauge what sort of culture by asking the right questions at the end of each interview. There are many posts on what kind of questions you need to ask your interviewer to stand out from others. However, in this post, I want to share a couple of questions that I usually ask and questions that I usually received during an interview that provides insights into its engineering culture.
How are product decisions made?
This question is intended to be open-ended.
However, you want to find any hints to see what level of autonomy the company gives to developers when tackling projects.
Once he/she said about the product delivery process and decisions. You can get a deeper understanding of how a role of an engineer is in that company. Do engineers get autonomy in creating their features and product? Are there lots of hierarchy and politics to get an idea into an MVP?
You will notice that if the engineers are working closely with the product roadmap, engineers will usually be involved in creating the product, which ties the projects to the company that it is executing on. Engineers usually get full autonomy in making the product features. Usually, ideas are not coming from who is the oldest and most senior in the team but based on the idea’s merit.
One example - “when the product team decides to shipped feature X and Y, I noticed that feature Y isn’t really needed yet because country A has allowed to give us waiver until mid-June. Moreover, feature X will require a certain amount of testing involved, thus requiring more engineer time and hours into the work. Therefore, I suggested that feature Y can be postponed to CQ 2. They realized that the work and the idea make sense. Therefore, we ended up putting feature Y to CQ2.”
All decisions should be held to the same data-driven standard for decision-making. Developing feature relies on experimentation as much as possible rather than opinions.
When you hear that the execution is top to bottom - where engineers didn’t get to be in the discussion on the product feature’s roadmap. The business people may control the software development cycle and software decisions. You need to be aware that the company might not be engineering-driven.
What is the deployment process in your team?
Knowing about the deployment process is to gauge how much trust they put in their engineers. Is it fully automated? Does it go to multiple teams to release a feature?
An engineering-led company will empower the engineering team to lead the entire company’s culture and continually reinforce this behavior without equivocation. Thus, every possible process is optimized for iterating fast but safe.
An engineering-led team will understand that doing the right thing is paramount because when someone is forced to fix something because of poor practice, an equal amount of time is invested in improving it permanently.
You can sort of understand if the company trusts its engineers to own their code qualities throughout the software development process by investing in multiple levels of automated testing, monitoring, and reporting.
You will also get to understand how
You can also see if best practices, such as continuous delivery and testing, are highly valued.
How has the company helped you achieve those goals?
These questions are essential for finding an engineering-led company. Still, I think it is crucial to ask regardless of which company you are interviewing to understand how it aligned with your career goals. However, if a company is not engineering-driven, promotion and operations are heavily based on politics and relationships rather than objective merit. Secondly, if a company thinks that its engineer is a cost but not an asset, it won’t care much about their career progression and opportunities. A couple of follow up questions include:
- Do you discuss career goals with your manager?
- How often do you have 1:1?
- How much responsibility is given to a new employee when they join?
A couple of these questions can help you catch some red or green flag about the company.
Closing
Asking the right questions at the end of your interview can help you identify if the company is the right fit.
An engineering-led company often puts engineers as an asset instead of a cost. If they treat engineers as an asset, they will value their thoughts and ideas provide autonomy in executing critical features.
Another point that I realized is that founders or executives within an engineer-driven company are also engineers themselves.
Ultimately, you want to ask as many questions as possible to the company that you are interviewing for because these people are the people that you will spend the most time with if you accept its offer.