Disclaimer: the ideas in this article are based purely on my personal experience working in big tech and smaller companies over the years and multiple conversations I’ve had with other people working in FAANG. Not all big companies out there do the things I describe here, and some smaller companies don’t adopt such practices either.

Smaller tech companies often get inspired by what big companies like FAANG do — how they manage projects, organize the office space, hire talent and write code. While it can be useful to leverage some of the best practices, I believe some things can actually bring harm if followed blindly. Let me describe several things that I find counterproductive in the small company environment but which are still often used because the grown-ups do it.

1. Interviewing

The traditional interview at a big tech company is a standard mix of coding, system design and behavioral sessions. This is what Cracking the coding interview book is about. Also, this is what leetcode is all about. As a result, lots of engineers try to get trained at solving algorithmic and data structure riddles, and then they never rotate trees nor find the shortest path between two nodes at work.

But does it have to be like that? Big companies do it this way because they value pure problem solvers that can adapt to any framework or tool — in big companies, it’s often an internal framework that’s not used anywhere else. There can also be teams that work on a new language or a new cutting-edge technology. It’s believed that a person who can reliably solve algorithmic problems and understand the complexity also can perform well at any kind of programming job that they will face at work.

For smaller companies, what they usually need is to work on a product that’s developed using a framework well-known in the industry. For this reason, interviews can totally be done as a test task that is much closer to the actual job. Pair programming sessions can work great too — especially if the goal is to find a teammate that would perfectly fit into a small team.

2. Building own tools and infrastructure

I’ve seen some smaller companies trying to deploy their own git or hg repos or set up fully custom CI pipelines. Big companies often build tools from scratch for the following reasons:

• Such tools didn’t exist on the market when they already needed them.

• They need some custom features that the majority of the market doesn’t care about.

• They don’t want to depend on other services that can go down unexpectedly.

In my opinion, smaller companies shouldn’t spend too much time re-inventing the solutions that already exist on the market. They can just compare those solutions anв choose the one that provides all the necessary features, is reasonably priced and has a good reputation:

• Do you need to store your code in a versioned system? Probably Github or Bitbucket are your best options.

• Do you need a continuous integration system? Then maybe use Gitlab or Github’s CI functionality.

• Maybe you need a mobile CI/CD pipeline? Use Bitrise or other specialized platforms.

Using an existing battle-tested service usually saves a ton of money and allows people to focus on the actual work.

3. Heavy process

Big companies introduce heavy processes (such as required system design or product reviews) because of:

• Their scale — when there is a long chain of people between let’s say a director of product and a product team, they want to make sure the individual team doesn’t go rogue and build something very different from the high-level vision.

• Fear of shipping something wrong — this fear is even greater than the prospect of shipping a breakthrough, that’s why it often seems to be easier to introduce a process that’s supposed to protect against potential screw-ups.

• Paper trail — some people have to be kept accountable and responsible for the decisions.

All these things are not always needed in smaller companies where all the people usually know each other. In such an environment, it’s often reasonable to trust people over process. For example:

• Two people on a project don’t need a daily stand-up — they can just informally sync throughout the day (maybe even async).

• A product designer on a small project doesn’t have to take all the wireframes to a design review every time there is a change — instead, after there is an initial alignment, they can evolve the design independently.

Conclusion

I hope these ideas will help some teams look again at the way they work and try to think if they do actually need it to mimic what the big companies do — or if they can get rid of things that make them unnecessarily slower and focus on what really matters more to them.

If this article gets enough traction, I will follow up with the list of three things that are used in big tech but for some reason are often overlooked in smaller companies.