Sample Co-op Trajectories:​ Technology

# Co-op Blog Addendum Part One

This is an addendum to my blog reflecting on my experiences with co-op in university. I'd like to explore some sample co-op trajectories in the fields of technology and business, as those are the two most common fields for co-op placements and internships, and they're the only fields I'm familiar with.

This is part one of the addendum and I'll cover different tech jobs as well as some tips and tricks on how to identify and land the top tech roles.

# Cali or Bust?

The name of the game for technology co-ops is to work in the US. The pay in the US is drastically higher than the pay in Canada and many of the top companies to work for don’t have Canadian offices. Furthermore, the network effect at various US-based tech hubs such as Silicon Valley and NYC is ideal for making connections at the beginning of one’s career. One thing to consider, however, is the cost of living; rent is pretty insane in both California and NYC. Furthermore, safety and living conditions are also not ideal in many of the Californian cities due to the homeless crisis, so quality of life should also be a consideration when moving to a new city for a job. Due to the mass exodus of companies from California, there are newer tech hubs popping up such as in cities like Portland and Miami, which are worth considering.

In Canada, Toronto is probably the best city to work in, followed closely by Vancouver. Ottawa is not bad for legacy industries such as telecom and Montreal is a decent city for tech but the pay will be lower than other Canadian tech cities. Waterloo-Kitchener also has a burgeoning tech hub.

While it’s possible for people to go abroad outside of North America for work, the vast majority of companies hiring tech co-ops from Canada will be either American, Canadian, or the North American subsidiary of an European or Asian company.

# Which Companies to Work For?

Information is relevant as of 2021.

If one were to categorize all the co-op employers into three broad categories, it’d be large companies, small companies, and government organizations.

I’d recommend against working at government organizations; out of everyone I know who did an internship in the public or semi-public sector in tech, the experience has been overwhelmingly negative. Generally, public sector organizations have outdated and poorly written tech stacks; many of the people who’ve worked there claim that the bulk of their time was spent debugging and fixing code as opposed to writing new code. Furthermore, the organizational structure tends to be more bureaucratic so a lot of time, people have told me they spent as much time on following bureaucratic procedures as working on actual code. Finally, these public organizations tend to overhire each term, so many people are just stuck with no work to do and the pay is also amongst some of the lowest for tech jobs. That being said, I’ve never actually worked in any public sector organizations so please take everything I say with a grain of salt. Public sector co-ops are some of the easiest co-ops to land and different organizations can be drastically different (especially semi-public organizations), so public sector co-ops might be worthwhile to look into for specific situations.

I would define large companies as companies which have established co-op and internship programs. These businesses range from large start-ups to established public companies. Most of these companies will also hire for multiple positions, both technical and non-technical. The benefits of working for these companies are twofold. If the company is reputable (currently companies like Google and Citadel have well-regarded engineering cultures), then your professional stock in the eyes of future employers go up; these large companies tend to also be the ones who pay the most and offer the best benefits for co-ops.

While these large companies typically have tens, if not hundreds of available placements, they are also some of the most competitive offers to get so the supply and demand nets out. Not all large companies are the same, however; while the most sought after co-op employers are usually large companies, there are also many large companies which aren’t as attractive. Many legacy tech companies tend to be more bureaucratic and offer less competitive compensation; I would also stay away from non-tech businesses hiring technical co-ops, as those companies tend to not be as focused on tech as pure tech companies.

Smaller companies are typically earlier-stage startups; usually there are no recruiters and the roles are more broad. While still competitive, the compensation will not rival the top large companies. To make up for this, however, co-ops tend to have more responsibilities, including more autonomy and more decision-making opportunities. These companies, especially newer ones, are a hit or miss; I’ve heard horror stories where people were fired after they had completed their project but also stories of people getting the opportunity to design and implement mission-critical projects. If one is entrepreneurial, there are even programs in some universities that give grants and allow students to work on their own startups during co-op terms.

Overall, the decision to co-op at a large versus a small company boils down to several cruxes:

• While some smaller companies pay well, the top large companies pay much better and offer much better benefits. Furthermore, working at a large company tends to be less stressful than working at a smaller company but your mileage may vary greatly.
• Working at a large established company can lend legitimacy and value for future employment.
• Large companies tend to have a more rigid co-op program which can include training, assigned mentors, and usually 1-2 assigned projects; the upside is that students have a more uniform and organized experience. The downside is that, unlike many smaller companies, co-ops have little say on which teams they are placed on and the projects that they get to work on.
• Many co-op projects at large companies tend to be very minor in impact and oftentimes the code that co-ops write won’t actually get used in the final product. In smaller companies, co-ops usually get to work on important tasks and get exposed to a broader set of challenges.

If you’re a person who has the skillset and the experience to land a placement at one of the top large companies, you can expect an organized work term where you get to make a decent amount of money and add a reputable name to your résumé. If you’re a person who values learning and doesn't mind working a little harder, then working at a smaller company can greatly enhance your skillset and allow you to explore avenues that you’re interested in.

Here are three main categories of placements in tech.

# Software Developer/Engineer (SDE)

This is probably the most common role in tech; there are many specialized niches, and the definition of each niche changes slightly with each company.

# Developer vs Engineer

There isn’t really a large distinction between developers and engineers; most companies use the two terms interchangeably. Traditionally, developer implies execution and engineer implies design and execution.

# Types of SDE Roles

The most common roles I’ve come across include

• Front-end (Client-side): This role is focused on building how an application or piece of software looks and feels (the application or website interface); having a taste for aesthetics and layouts and having a certain degree of creativity helps in this role. Understanding key frameworks such as HTML/CSS, Javascript, and specific libraries such as React are key to this role. This is also one of the easiest roles for a non-tech person to break into, due to the relatively lax technical requirements for the job and the scores of tutorials and courses online for the required skills.
• Back-end (Server-side): This role is focused on building what goes on under the hood of apps, namely the actual logic of the app, such as managing servers and databases. Back-end developers will use languages such as C++, Java, and Go. Back-end development often requires more specialized technical knowledge than front-end and different companies can require drastically different skills depending on the company’s stack.
• Full-stack: This role is a mix of front-end and back-end; be sure to fully read the job description and ask your recruiter or hiring manager what the specific projects you’ll take on, as I found that for co-ops, full-stack tend to lean either front- or back-end.
• QA (Quality Assurance)/ SDET (Software Development Engineer in Test): This role tests for bugs in software; you should expect to do much of the unit testing and also building the infrastructure for testing. Typically unit tests are written in the same language as the software being tested and SQL is always useful for unit testing back-end code.
• Mobile: These devs work with developing apps, usually for iOS or Android; the knowledge and skillset are relatively specialized; languages and frameworks include Swift, Java, and Objective-C. Typically one would develop either for iOS and Android; I don’t have much experience with either but I’ve been told that iOS is more developer-friendly.
• Niche/Specialized: There are many less common roles, such as for
  • Embedded: This job requires working with hardware that isn’t just computers, such as iOT devices and microcontrollers. You’ll thus need an understanding of hardware and low-level software. This job is usually targeted at engineering students.
  • Game: These developers make games using frameworks such as Unity 3D and WebGL. I found that oftentimes, these devs also need to be proficient in either full-stack or mobile development too. One word of caution though; many game dev positions are notorious for poor workplace culture and work-life balance, so make sure to fully research the role and company.
  • Security: This job is pretty cool; you basically try to break into and identify security flaws in different systems. High technical expertise (including cryptographic math) is required. Usually you’ll have to use scripting languages such as Python.
  • Big Data: This job requires knowledge of frameworks such as ETL and MapReduce; you’ll probably need to also know either Java or Scala. This is a more technical role and is usually reserved for people with some prior programming work experience.
  • Graphics: This is another highly technical role; you’ll need an understanding of graphical libraries such as DirectX and WebGL. For even more technical roles (usually only open to Masters/PhD level students), you might be asked to write in Assembly or C++.
• Pseudo-programming: There are some newer roles which may not require full technical expertise; these roles include
  • IT/DevOps: This role may vary depending on the organization; for many of the postings I’ve come across, the role is mainly an admin role where you are in charge of administering different aspects of the development cycle, such as enforcing Agile best practices and automating tests. This role can be technical; you may need to understand some specific frameworks such as Jenkins, Docker, and Kubernetes.
  • UI/UX Designer: This job is related to designing user interfaces for different applications; the role involves using graphic design software such as Figma and Adobe XD, but increasingly, designers are expected to have a general understanding of front-end code, including basic HTML/CSS and maybe even some Javascript.
  • CRM/ Sales: This is a relatively new role that is inbetween a traditional sales role and a developer role; as an intern it’s highly likely that you’ll be supporting the actual sales managers as opposed to doing the actual selling yourself. You might need to be familiar with the different software solutions from SAP and Salesforce, and you may need to have basic SQL and VBA skills.

The roadmap for SDEs vary greatly on one’s abilities and one’s goals. Typically one would start with some programming experience either in school or in side-projects but no official work experience; through working at different co-op placements, one would add new skills to their skillset and enhance existing skills. As one advances, one would choose roles that they’re increasingly interested in, as well as new companies which offer better pay and benefits.

For the first term, few people make it to the States for co-op, because few people have prior tech work experience or impressive side-projects. In fact, many people don’t even manage to land pure SDE jobs; many people start in IT or QA (usually in some sort of “analyst” position) and oftentimes they work for unknown or non-tech companies. Don’t be discouraged if you don’t land your dream role in the first term; the first co-op placement is more meant to acclimate you to the professional environment and hopefully help you develop some skills, or atleast give you some time to develop skills outside of work and school.

For the second and third terms, you should try to get roles that you’re interested in and try to work at a sought-after company. There are two keys to landing interviews; the first is to improve your skillset and the other is to improve your application. Improving your skillset means taking relevant courses in school and also working on side projects and learning outside of school. The key is to stand out, so don’t just build generic projects from tutorials you find online, try to build something unique which demonstrates certain skillsets. Another way to demonstrate skill is to be a Research Assistant to a prof in the relevant field, or to be a Teaching Assistant for a relevant course. Improving one’s application means networking with industry professionals and recruiters at the companies you’re applying for, getting referrals to said companies, and polishing up your résumé. Once you have interviews, you should find out which questions were asked by the company in the past and study them; you should also do Leetcode and Cracking the Coding Interview to brush up on general questions. If you prefer a more course-based approach, I heard Grokking the Coding Interview is a good source. Most large tech companies’ interview questions tend to be at a Leetcode Medium and up, so be sure you can comfortably solve them and are intimately comfortable with common data structures and algorithms. I’d also recommend Python for interviews, as the simple syntax reduces potential for your code to not run due to syntax errors (I would recommend reading the first few chapters of Python Cookbook to learn some tricks to save time during the interview).

During the actual interview itself, shut up and listen to your interviewers when they’re talking. Being explicit is the key; explicitly ask your interviewer about the requirements of the question and explicitly explain your thinking, in particular the tradeoffs you’re making in your solution. Try to establish rapport with your interviewers (smile and be friendly) and be sure to be on the same page with your interviewer before you start writing anything. Start with a working solution, usually some sort of brute force solution, then optimize and refactor the code. If your interviewer jumps in, it probably means you’re stuck or on the wrong path, so listen carefully to what your interviewer has to say and try to implement their hints; not listening to advice is a red flag while being coachable is a green flag.

Finally, for your last co-op terms you should ideally be in a role that you’d want to pursue full-time and in a company that you’d want to work for. Return offers are very common and it’s desirable because it saves you the trouble of having to look for work during your last year of school and you generally receive a higher signing bonus and salary if you return to an old employer full-time. Returning to a previous co-op also means more leverage for negotiations on compensation. For the last few co-ops your network will matter more; it is often not enough to solely rely on your school’s co-op system to find a placement (especially if you don’t go to a school with a reputable co-op program such as UWaterloo and UBC). You’ll most likely need to reach out (or at least respond) to recruiters from different companies and also have a network of professionals from the different companies.

# Project Manager (PM)

PMs lead the work of a team to accomplish project goals given certain constraints. They’re employed in almost all larger organizations, ranging from non-tech corporations to government organizations. Although it’s traditionally a business role, it’s a role that is in demand in larger tech organizations and it’s a role that is becoming increasingly technical.

# Why PM?

There can be several reasons why one would want to be a PM instead of an engineer. Many of the PMs I know personally have a technical background but found that while they enjoy working with tech, they also enjoy working with people. Furthermore, PM roles usually require less technical skills than a full engineer or dev role, so it can be a good stepping stone for non-technical people into the tech world. While PMs tend to get paid slightly less than engineers, they generally get paid more than other business functions within the organization.

There are some caveats, however. PMs aren’t as in demand as engineers so there are less postings, furthermore PMs also have a lower bar of entry because it’s a role in tech that is relatively open to nontechnical people. This means that more people tend to apply for PM roles relative to the number of PM roles available; this, coupled with the fact that PM roles rely largely on intangible soft skills, makes the most sought after PM roles somewhat difficult to land.

# Product vs Project Manager

While both product managers and project managers share the same acronym, they’re actually separate roles. Product managers can be almost thought of as a more macro and more strategy-focused project manager; product managers set the goals and business trajectory of products while project managers lead the many initiatives that bring those goals to reality. Product managers tend to be a more involved position with longer commitment periods (oftentimes no definite beginning or end) so there aren’t that many product positions for co-op. That being said, for the few product co-op placements available, the job requirements (at least for co-ops) will be very similar between the two PM positions.

# Categories of PMs

PMs in tech can generally be broken down into two main categories, which are

• Non-technical PM: This is the more traditional business role; you lead teams (usually of engineers and other technical personnel) on planning and executing different projects, which can range from planning new initiatives to implementing new features. As a co-op, you probably won’t get an important project to manage by yourself at first; expect to manage small projects or play second fiddle to another PM. You may be expected to understand business principles such Agile and have a general understanding of the specific company you’re working for.
• Technical PM: An increasing number of PM roles require one to be well versed technically, basically a PM with a technical background. Technical PMs are assigned on highly technical projects and may even be expected to contribute alongside the engineers on the team.

As with many business positions, there aren’t many hard requirements for landing a PM position as most of the skills are intangible. Having strong interpersonal skills and good organization are crucial to the role. One can also work towards professional certifications such as PMP to demonstrate understanding of PM principles, but the best demonstration of PM skills is practical experience. Oftentimes in universities, there are various student-run organizations including design teams; being in a leadership position can be impactful in demonstrating PM skills.

The trajectory of a PM is similar to that of a dev in that you start at smaller, lesser known companies, and over the terms, slowly graduate to better and more desirable positions. The last few co-op placements should be placements that you’d want to work at full-time. I would actually recommend that you start out in a technical role in your first co-op positions; having a technical background is a massive competitive advantage in landing a good tech PM position.

Due to the breadth of the PM role, it’s incredibly important to understand what exactly the position in each organization entails; roles may vary greatly between teams and also between terms. There are also many aspects of being a PM; some PM roles emphasize the planning aspect of the project while some emphasize the execution. Understanding and experimenting with said different aspects is important to discovering what you enjoy doing the most.

# Data Science

One of the fastest growing fields in tech is the research and application of AI technologies. Large companies are investing heavily in AI and companies are founded around the use of AI.

# Roles in Data Science

There are several roles associated with the field, such as

• Data Analyst: This role works with structured data to come up with insights to solve specific business problems. The role can range in technicality, from using less programming-heavy applications such as Tableau and Excel, to coding algorithms in Python. SQL is also generally expected in this role and data visualization skills are also nice to have. This is one of the easiest roles for a non technical person to break into in this field.
• Data Scientist: The role of a Data Scientist and a Data Analyst can overlap in many ways; one can almost think of a Data Scientist as a more “advanced” Data Analyst. The Data Scientist is also tasked with solving specific business problems, but the responsibilities are broader, and involves gathering and cleaning data, designing and testing their own ML algorithms, and automating their ML processes. The role of a Data Scientist is often more open-ended than that of a Data Analyst and you’ll need to have a solid foundation in programming as well as a solid understanding of statistics and machine learning in this role.
• ML Researcher: This role focuses on researching and developing novel ML algorithms and applications. This role tends to be even more open-ended than that of a Data Scientist as while Data Scientists use algorithms to build predictive models to solve problems, ML Researchers are focused on the algorithms themselves and the engineering around implementing said algorithms. ML Researchers are often focused on more theoretical problems. ML Researchers are typically hired by research institutes or very large tech companies and there are typically requirements on education (usually PhD or research Masters) and prior research and publication experience.
• ML Engineer: This role is akin to a software engineer but with a focus on developing ML applications and frameworks. This includes building the infrastructure to support both the research and development of AI applications. You’ll need to have solid software engineering skills with a good understanding of code optimization and data processing. A thorough understanding of ML frameworks is also necessary.
• Quantitative Analyst/Researcher: Typically hired by financial firms like banks and investment funds, Quants apply statistical methods to financial and risk management problems. One can think of Quants as a Data Analyst/Scientist who works within financial markets. A Quant’s work can range broadly depending on the team and organization of the role; it can range from crunching numbers on Excel/VBA to researching and developing cutting-edge ML models. Typically working at a larger, more established firm gives a more structured experience such as fixing legacy models and implementing traditional statistical models, while working at a smaller, more entrepreneurial firm gives a less structured and more open-ended experience, such as researching ML models and finding new data signals. Quants have a similar hiring criteria as ML Researchers.

This field is growing but unfortunately, at least in my experience, is not really taught in undergrad; most of the ML-related courses in Waterloo aren’t really available until the upper years. I found instead that there are many excellent resources to learn on your own; The Hundred-Page Machine Learning Book is a good primer for the field and there are many courses available online, such as the Deep Learning Specialization by Coursera. If you are planning to take courses online, be sure to take reputable ones with good reviews and preferably some sort of assignment or testing for certification; I found that I learned best through actually implementing many of the models and many of the courses online are also poorly made (basically tutorials on how to code different models). I would also focus on learning a widely-used ML library such as Tensorflow or Pytorch. You should also take some statistical courses and linear algebra courses in school. Having research experience, such as working as an RA with a prof, will be immensely helpful in demonstrating value to data science employers.

The co-op trajectory is similar to that of an engineer; you start at a less technical role and as you gain skills and experience, you enter into roles and companies that you’re interested in. I found that oftentimes working at very large companies or companies which are focused on AI tend to yield the most interesting and impactful projects. Furthermore, while many of the postings advertise for PhDs or Masters only, if you, as an undergrad, have experience and are qualified, you should apply anyways as more likely than not, you’ll get the role because the industry is greatly lacking competent professionals.