This past summer, I was very fortunate to have had the opportunity of joining the Web Applications team at Pandora as a software engineering intern. This was my first engineering job in the software industry, and to say that I learned a lot is definitely an understatement. The best way I can put it is that the past four years in college felt like a giant lecture, where you merely learn the fundamentals and how software worked in theory. This internship was then the lab section to that lecture, where you basically have to relearn what you thought you knew, but this time, how it actually works in practice, IRL. I think this disconnect between college and industry is so great because people don’t want to sound stupid asking questions that seem trivial. I have attempted to answer some of those questions in a iFAQ (Infrequently Asked Questions), in hopes to provide some insight for those who are too afraid to ask.

Infrequently Asked Questions about being a software engineer IRL:

What do you actually do every day?

As a software engineer, you basically do 4 things on a daily basis: code, attend meetings, eat, and socialize. Of the 4 things listed, the one that deserves the most attention is attending meetings. You will probably be invited to more meetings than you will ever want to attend. In this age of online communication, the goal of a in-person meeting is to discuss things that are inconvenient to communicate through chat, i.e. Slack. I categorized the meetings you will mostly likely attend into 5 types, in order of size:

  • Company meetings - Monthly company wide, “all-hands” meeting, where big company announcements, product demos, marketing & sales reports are presented. These meetings help different organizations within the company understand what the other organizations are up to and how the company is doing as a whole. It’s also a time for anyone in the company to ask questions and demand answers from C-level executives.

  • Product meetings - These meetings can range from company wide to product-specific meetings. But a product meeting is essentially the time for product managers and designers to discuss the kinds of products they are putting or want to put on the roadmap for engineers to build. These meetings could also be an opportunity for engineers to showcase what they have built to the product/design teams, and receive feedback.

  • Team meetings - These meetings include weekly/bi-weekly stand ups and architecture meetings. A stand up is a time to define what needs to be done during that week/2 weeks, update your team on what you are working on, and whether you have any roadblocks. An Architecture meeting is a time to have discussions regarding larger technical decisions that will greatly affect the entire product (e.g. introducing new frameworks, addressing technical debt, major bugs and roadblocks).

  • Feature meetings - These meetings require you to give updates on your work that impact a specific feature or part of the product, similar to a stand up meeting.

  • One-on-ones - These can be with your manager, mentor, designers or product managers. Meetings with your manager is usually a chance for them to check in on how you’re doing. They want to know if you’re happy with your work, whether you have any issues with other coworkers, and whether you are setting and meeting the right goals and expectations. If you are an intern, chances are that you will also have a mentor. Meetings with your mentor are really open ended, and you can speak to your mentor about their personal life, career advice, technical issues, or whatever is on your mind. Meetings with a designer or product manager is a chance for you to get clarification on the product/feature you are trying to build. Often times product specifications given to engineers will have missing or vague information that needs to be further defined.

How do you know what code to work on?

When you first join your team, there is usually some documentation on how to setup your development environment to run your application locally on your machine. You will then work with your manager or team lead to define the scope of your project, and break the project down into tasks that you can finish within a couple of days. You will then further define those tasks by writing up detailed information independently before you start coding.

How does coding in a team actually work?

Once you have your team’s application running locally, you can begin working on those tasks that you have defined. To facilitate multiple engineers working on the same codebase asynchronously, you rely heavily on version control systems and best practices. Usually your codebase will have at least the following branches:

  • Production - A version of your app that your users will actually use
  • Release Candidates - A version of your app that is in the process of being tested by QA for release to production
  • Development - A version of your app that your engineers are adding new features to
  • Feature - A version of your app that contains a new feature

The work flow roughly follows this order:

  1. Pull the latest version of the development branch onto your local machine
  2. Create a new feature branch off of the development branch
  3. develop and test new feature locally
  4. Fetch the latest version of the development branch, and rebase your feature branch onto the development branch. Squash all commits into a single commit for readability.
  5. Push local feature branch to remote feature branch, and submit a pull request
  6. Make minor changes locally according to code review comments, and push to remote feature branch without squashing to keep a log of changes during code review.
  7. Once pull request has been approved, repeat step 4, and push to remote feature branch.
  8. Merge feature branch into development branch.

What do I do when I run into a problem?

The thing to remember is that your team members want you to succeed. So don’t be shy about asking for help. However, make sure that before you bug someone with a problem, always do your own research and try a couple of solutions first. Be systematic and resourceful with your approach, and read documentation and google your problem. The last thing you want to be is that person who asks for help without putting in the work.

There’s also usually that one person, that appears to know everything. He/She is a great resource to get quick answers from, who will at the very least put you in the right direction.

What do I do when I don’t know what to do next?

Your team lead / manager is the person you should talk to if you ever find yourself without work. However, it is also your responsibility to keep your team lead / manager updated with your progress, and give them a heads up if work is running low.

General advice

  • Be as active as you can in the code review process of other engineer’s pull requests. This is one of the best ways to learn software engineering, how your team makes technical decisions, and how engineers communicate and resolve conflicting ideas.
  • Before making changes to code that someone else has written, double check with them to see if the changes are absolutely necessary. There might be a reason they wrote it a certain way, which might change the way you approach the problem.
  • Be very thorough when defining your task, and use that to make accurate time estimates. (Things will always take 3X as long as you think)
  • Keep a log of what you’ve done and the reasoning behind your approach to coding decisions. This will help you think systematically about your problems and help you in the future when you need to defend your work.

Feel free to add to this iFAQ by putting them in the comments below!