The hiring fun and the state of the industry

This week’s briefer:

• Migrating a 2TB database in 7.5 minutes

• Notes on the Pivotal Interview Process

• The Problem is Likely Not the Person Pointing Out The Problem

Hey,

As I’ve been doing a few more interviews these past weeks, I’ve had plenty of time to think about the hiring process and to enjoy how frustrating and draining it can be. A few weeks ago, I actually got an offer and could’ve taken it, although there were a few red flags around the product and the actual offer that made me keep looking. Would I accept it now that I’m a bit tired of the whole thing? Don’t think so, I still believe it was a good decision with the information available.

In reality, me being a bit tired is a massive understatement. The fact that there are people with many years of experience saying they rather stay at their jobs because they don’t want to go through the hiring process doesn’t surprise me.

Doing all these interviews shows me the state of the industry, at least how many startups do things, and it’s depressing, it’s the same old story. Maybe I’m jaded, but most startups just want an engineer that codes what they’re told, a code monkey.

Yes, there’s room for push back, conversation, or negotiation, but at the end of the day, the engineer’s seen as a builder that takes an already defined solution from requirements and produces code. The developer works in the solution space, without ever getting any visibility of the problems or the business, without understanding the users of the software or talking to them. Of course, the more senior you are as a developer, the more you’re expected to care about outcomes and to have a bigger impact than just your code, that’s what brings you to the next levels.

While it’s true that the job of a software engineer involves building the actual software, there’s so much more to it than coding. Dave Farley in Modern Software Engineering writes the following:

From his definition of software engineering, we see that an engineer finds solutions to problems, they don’t take an order from the product manager or the CEO with all the requirements, implement it and go to the next ticket until the universe ceases to exist, although that’s what usually tends to happen. We lose a lot of the benefits and expertise of having an engineer in the team when they aren’t close to the problems.

Unfortunately, this is not only an exclusive developer nightmare. Many designers also share the pain. Now that product management has taken quite a bit of the product discovery responsibilities, designers are left out of it, relegated to only coming up with pretty UIs or prototypes of an already defined solution. Design also seeks to understand problems and the interactions between a person, the environment… and provides solutions from the perspective of the user. Designers were the ones that were doing interviews with users to understand their pains and needs, and sought to understand the business and outcomes.

The division of labour into tiny, well-defined and isolated compartments in a factory line, where every one has a very specific function and little visibility of the whole, has given us messed up cultures and ways of working.

If engineers, product managers and designers are all solving problems and understanding users, isn’t that an issue? No, everyone in the team should be involved in discovery, understanding the problem space, talking to users to understand their needs and uncover opportunities, coming up with potential solutions, experimenting… This does not mean that engineers never code or that designers never come up with a UI for the next feature. There are two kinds of work and thinking, discovery and delivery, that some of us might be more focused on given our expertise, but there aren’t two teams (engineers on one side and product manager and designers on the other side), only one team working and moving forward together.

Many, if not all engineers in interviews, when asked about how they work and their involvement in the outcomes and discovery, say something like this: “we have a planning session and the PM shows us the Jira ticket for the feature, we split the work and get to it…”. There’s never a mention of them talking to users, or how they share understanding by telling stories or any other alternative way to do so, or the way they experimented with potential solutions before building the actual software. They can’t tell you because they don’t do any of that nor does the company wants them to do it, and believe me I asked in multiple ways and from different angles.

On the delivery side is not much different or exciting. Companies are hell-bent on having engineers work solo, each on separate and potentially unrelated tickets, in parallel for maximum extraction of the utilization of human resources.

Even if we know that there are better ways, there are plenty of companies out there with toxic cultures, feature factory models and utterly outdated ways of working that are incredibly successful. Success in the market is not 100% correlated with how well you do things, how humane your culture is, or the quality of your software and architecture.

At this point, I believe that the best way to have an impact on this would be to start a company where you can break free of the default behaviours and ways of doing things. A company where you can create a seed of revolution. It doesn’t guarantee that it’ll be successful and make money—which is a requirement for the seed to persist—and probably will require experimentation as you learn. If you can make it, then there’s this oasis that can show us how things could be. Hopefully, each of us in the company, when we leave, can take that seed with us.