Mod Note (Andy) - this Q&A originally went up last July but Ace wrote and said he could still answer questions. Hey all, Recent graduate here trying to kill time before work starts. I've seen a number of recent posts about people in finance getting burnt out and considering picking up the skillset to become software engineers. I'd be happy to answer any questions about this trade-off, or about software engineering in general. A bit of background about myself: I studied computer science and finance at a target university, and I graduated summa cum laude. I spent one summer in finance (hedge fund analyst) and two in software engineering (household name tech companies), and I will be starting a full-time software engineering job in a couple of months (another household name company). I thought pretty hard about a couple of other popular paths, including investment banking and product management, but I ultimately decided that I would be happiest in software engineering.
Trending Content - Other Industries Forum
Career Resources
Great question. I initially had the same concerns, but it turns out that capable software engineers are quite involved in the strategic process (at least at the companies I have worked at). This is a big difference between an investment banking analyst and an entry-level software engineer: the latter's insight into high-level decision-making is valued much more than the former's.
The point of a product manager is not necessarily to tell software engineers what to do, but rather to coordinate different parties across the organization. Very few, if any, tech companies use cross-functional organization, but most new initiatives will require a cross-functional approach. For example, releasing a new feature to a website can require people from engineering, operations, design, marketing, data science, and finance. This is one place where the PM can add value, by tracking project tasks and goals across these teams. Without this cross-functional aspect, there's very little a PM can do that an engineering manager can't.
I would summarize by saying that the PM's role is to make the software engineer's job easier where possible. That isn't something that appeals to me; I enjoy getting my hands dirty with the coding process. I'm able to do this without sacrificing my soft skillset, so this is a win-win for me.
I should note that I also went out of my way to find teams that had opportunities for me to play a strategic role. At one company, I met several times with the CTO to discuss a new product initiative. At another, I commonly hopped on sales / due diligence calls with our team lead, and I was actually allowed to drive significant parts of our pitches to potential customers. Not every engineer is interested in these things, but in my experience, those that are capable of seeing both the trees and the forest are encouraged to wear both hats.
If your only two desired positions in tech are PM and software engineering, then you should learn how to program regardless. However, if your goal is simply to break into the industry, don't forget that the big tech companies have corporate strategy, corporate development, and finance / accounting teams. They may be a better fit for any individual person.
Why do you need to know how to code to be a product manager? The more you can code, the more effective you will be as a PM in terms of helping add value for engineers. Remember, without your entry-level engineers, you don't have a product, so you as a PM need to be able to speak the engineering language. This should be self-evident; I've heard lots of people frustrated with their banking associate because they didn't know enough about the job of a banking analyst to be able to actually help them out.
This is so important for a PM because understanding software engineering is significantly harder than simply reading a Vault guide (not that any such analogue exists). It really takes a couple of years of exposure to both computer science theory and the practice of programming to be super comfortable with it. This is why you hear the stereotype of the English or history major reading the Vault guide and becoming a banking analyst, but there is no corresponding stereotype for software engineering. The barriers to entry are too high.
Every single PM I've known—although my sample size is small—knew how to code. They weren't necessarily all CS majors, but they all had substantial coding experience. I don't think it's impossible to be a PM without coding experience, but it absolutely works in your favor.
Will you actually like coding enough to do it for a job? I think three big factors here are detail-orientation, a love for solving puzzles, and patience. One, you need to build software the right way the first time. This includes thinking through design choices fully, properly documenting your efforts in a helpful way, and being in a habit of writing high-quality code. This is hopefully a skill that will transfer from banking. This is important because code sticks around for the long run and is read by many other people. Nothing is shittier than having to spend hours digging through someone's shit-quality code. Two, you need to have the kind of inquisitive mind that makes you enjoy solving puzzles, since that's what building software is like. Finally, patience is a big virtue, whether you need to spend hours trying to understand code written ten years ago by a former employee of your company that probably wasn't competent, or it takes you two days to track down and fix some crazy bug. This is a different sort of patience than what is required in banking: banking patience involves sitting around waiting for someone to assign you work, while software engineering patience involves being okay with spinning your wheels for as long as is necessary.
In terms of resources, people usually recommend something like Codecademy, but I always tell people to go to a university's intro comp sci website, follow the textbook and lectures, and complete the homeworks. University classes are designed to give you the proper balance of theory and practice, whereas Codecademy is designed to give you all practice but no understanding. Also, I strongly recommend Java over Python as a first language. Python is a particularly bad language for building large systems in because of its lack of a static type system (don't worry about what that means). Java is the way to go here.
tl;dr learn to code, see how much you like it, and use that to determine which tech job you'd be a good fit for
Don't worry too much about the degree, tech companies care about what you can do, not what your major is. I have several friends that dropped out of college not to make their own company, but simply to work at another company. A friend of mine is working on the Windows kernel team at Microsoft, and he graduated with a business major (but is an exceptional programmer nonetheless).
Side projects are going to get your foot in the door, especially without the CS degree. C++ is a good starting language, and lots of companies use it for their infrastructure, but it's not the best for small-scale side projects. Good starting side projects are some kind of mobile or web app. I'd recommend looking into JavaScript once you are quite comfortable coding in C++.
You'll be lacking in the data structures and algorithms knowledge, although that can be learned, so you might want to try applying to smaller companies. Smaller companies tend to value what you've built over what you know, if that makes sense. Pure web dev or app dev skills are critical at a start-up, where you can do other jobs at an established company.
Networking does help, so see if you have any friends that currently work at companies you'd like to be at. Resume referrals are super helpful for getting interviews.