Navigating Coding Roles - Startups vs. Big Tech

Just about any company you can imagine is in the software industry. If they don’t build their own software, they buy it and, in some cases, provide support for it. Considering all the potential technologies, languages, and frameworks that are used by businesses today, there is a seemingly endless choice of jobs for modern software engineers, and each requires a unique skill set.

In my experience as a full-stack developer in quite a few companies, one of the most effective ways to simplify the complexity of the software engineering landscape is to separate companies into startups and big tech, with a small middle ground that includes companies that are a mix of both. The environments and cultures of each group are different, as are the skills that engineers are required to use.

The Startup Scene

Shows like “Silicon Valley” and movies like “The Social Network” dramatize life while working at a startup, and they definitely got some of it right. There is a mix of pure chaos, long but flexible hours, and pivots to new business models on the fly. A startup has to hit the ground running and prove it can attract enough users to make a profit. This key dynamic dictates the work environment and the skills we all need.

• Full-Stack Development: In my experience, at all thes startups I have worked at, you wear many development hats. At one startup, I started working on middleware, databases, and deployments because we needed those first. After the company hired more people, I worked on the front end for the rest of the project. I still helped with the other parts of the system as needed.
• Cutting-Edge Technologies: Most of us in the business will find the newest and latest technologies at a startup. At one startup, I learned machine learning, WebGL, and graph databases for the first time. You might end up spending a lot of your free time learning these new technologies because the deadlines are still tight.
• Open Source: Startups love open source code because it’s free. I’m more used to seeing JavaScript, Python, Java, and MySQL at startups, as opposed to Oracle Database or C#.
• More Flexibility and Responsibility: At a startup, job requirements and parameters may be less defined. I’ve had designers on my team who were just as busy as I was juggling multiple projects. Sometimes, engineers just have to use their best judgment to finish a task.
• Technical Debt Buildup: At a startup, we’re required to get things done fast. Changes in design often happen on the fly, so the nice, tight structure of the code base you started with can turn into a mess pretty quickly and need to be refactored. It takes time to write good code, and there’s rarely an abundance of time at a startup.
• Less Testing and No QA: I have yet to write genuine unit tests at any startup I worked for. They were often mentioned as a good thing to have, but we just never seemed to get around to writing them. And you may not have QA, either. Engineers have to test their own code thoroughly, or we end up pushing hot fixes in the middle of the night.
• Heavy Workload: I’ve never been bored at a startup. There are always fires to put out and technical debt left over from late-night coding sessions.
• Less Infrastructure: At a startup, some things may not work quite as expected. Deployment procedures may not run smoothly, or an engineer might have to log in to Linux servers at midnight to see why the new version of code is not live.

The Silos of Big Tech

Large companies have more structure. You will burn the midnight oil less often, but you most likely will have to be at your desk during business hours. There will be a clear hierarchy of authority and rank at the office, and you will have a job description. So how does this environment affect the skills you need for the job?

• One Technology: You won’t need to be a full-stack developer at a large company. If you are a database developer, you will only work on databases. If you are a web developer, you won’t have to deploy your code. Just write it and commit it.
• Legacy Code: You will find a lot of legacy code at most well-established companies. The company has been around for years and the code base will build up over time. If the old code works, there is no reason to change it…until it doesn’t, and some engineer is tasked with updating Perl code or outdated ASP pages that haven’t been touched in years. I have been that guy. It’s not fun.
• Proprietary Software: Historically, big tech tends to trust well-established companies for their software. This has changed a little, and you will find more open source code in enterprise code bases, but chances are you will find technologies like SQL Server, Oracle Database, and C#.
• Strict Requirements: In a big tech company, the requirements for a task are usually detailed. There will be very little “winging it”.
• More Standards: At a big tech company, software engineers have plenty of time to refactor their code. It may have to meet coding standards and style requirements before it can be merged. It will also have to pass peer reviews to catch any issues missed by the automated tools.
• Testing and QA: Engineers at big companies often have to write unit tests, integration tests, and UI tests along with the code they write to finish a ticket. There will also be a QA department that will send a ticket back for rework if it doesn’t fit the detailed requirements.
• More Downtime: With all the processes and procedures in enterprise development, I always think I’m going to have less free time at a big software company, but the opposite is typically true. You will have plenty of time to clean your desk and maintain inbox zero.
• A Well-Oiled Machine: While some parts of a big company’s technology stack may be old, it will be dependable. When you commit code, you can forget about anything that happens afterward. It went through linting and code review. Automation will take it from there.

The New Engineering Department

Not every engineering department in a large company runs like an engineering department in a large company. Right now, I work at a 20-year-old company with more than 1,000 employees. Three years ago, they got tired of dealing with software vendors, so they bought the vendor and started their own engineering department.

In my experience writing code in a new engineering department, this is kind of a sweet spot for a developer who doesn’t want all the chaos of a startup but is not yet ready to settle down at a large company. You will start the department from scratch just like with a startup, but the pressure will be on to create structure and procedures for how the department will run. In this scenario, engineers actually have a say in what these processes and procedures will be.

The Spinoff

And then we have the spinoffs. Sometimes an established company will launch a whole new company under its umbrella. These types of companies also run like a startup, but since there’s a parent company, there are some distinct differences.

In my experience as a developer at one spinoff, this is another hybrid environment. Software engineers don’t see the long hours of a standard startup because they tend to follow the parent company policies. They tend to have more input on what their technology stack will look like, but there may also be tools that the parent company insists that they use because they’re already bought and paid for.

What This Means for Software Engineering Job Seekers

At a startup, engineers write more code. They will require you to push it out faster, and chances are you will work on the front end, back end, middleware, and database. They might even do some DevOps work.

In a larger, more established company, engineers will write less code in one part of the application, but they’ll still be required to comply with more standards, follow more processes and procedures, and write more tests. You should choose a path based on what type of experience you’re looking for, where you are in your career, and the skills you want to put into practice.