6 Months of Working at a Hypergrowth Startup

I joined Scale AI late last summer. It’s been a crazy experience — Scale is growing incredibly fast right now, hitting a valuation of over $7 billion last year and recently signing a $250 million contract with the DoD. Personally, I’ve made over 100 PRs and conducted about 40 interviews already! It’s also by far the largest company I’ve worked for. Here are some lessons I’ve learned:

Working in a New Codebase

• It’s often faster to check directly if something works than to prove it in your head
• Finding the answer is less important than learning how to solve that category of problem
• Global searches for strings/regular expressions are often the best way to gain context
• You can configure your IDE to ignore log/build/dependency directories 
• Turn on Git Blame so you can track down the PR that was responsible for a given line of code
• You will need some of the (slightly) fancier features of Git, eg workflows based on git rebase and stacking branches
• Strongly typed code is nice. Pay it forward
• Your product probably has very informative logs/instrumentation if you know where to look
• Some things you’re allowed to do when debugging:
  • Checkout an older version of the codebase
  • Checkout the latest version of the codebase
  • Comment out sections of code that are distracting or throwing errors
  • Use the debugger
  • Use specialized debuggers (eg React dev tools, Node.js debugger)
  • Refresh the page as many times as you like
  • Run as a different user/group/role
  • Print out the inputs to your function
  • Inspect network traffic
• Sometimes you just need to read the whole schema/file/README to figure out how a system works
• You are being paid, in part, for your capacity to be frustrated and stressed for hours at a time
• Ask lots of questions, preferably in public forums. Start learning strategies to resolve specific categories of questions on your own: eg, documentation X, slack channel Y, schema Z.

Working in a Big Organization

(Size is relative; for me, 500 people is pretty darn big)

• Follow up, over and over again
• You’ll forget to follow up, so make a system that includes reminders
• Find ways to be engaged outside of your team, eg engineering help channels or volunteer programs
• There are performance reviews now. Make sure that you get actionable feedback well before the review cycle starts
• Learn what’s important to to your manager and department, and figure out how your role aligns with those goals
• Take notes during the week about questions/concerns/problems you can share in a 1:1 with your  manager 
• If working remote: turn on the camera during Zoom calls (I don’t always do this but #goals :-))
• Actively manage your calendar. Make sure you accept important events so other events don’t get scheduled on top. Decline events if you can
• If you have a personal or interpersonal problem that affects work, there should be at least one person (your manager, HR business partner, etc) that you can bring it to
• If no one is talking in a meeting, speak up. If lots of people are talking, be quiet. Don’t push meetings in tangents (that one is mostly for me :-)) 
• When you build something new, make a short video to demo what you built and share it in your team channel and, if appropriate, with end users
• Look for opportunities to present your work to larger groups of people within the org. Speaking/presenting is fun and a good skill to develop
• Be very deliberate about replacing existing tools/workflows. Announce what you’re changing before you change it, let people opt in before you force them to opt out, and wait a long time to completely remove the old way.
• Measure everything and insist on metrics to validate non-trivial projects. There’s too many initiatives to choose from otherwise, and the opportunity cost is enormous. 
• Documentation goes out of date extremely fast. Try to consolidate and keep the core docs in a trafficked location.

Hiring and Interviews

• This is an incredibly tight market for engineering talent. 
• It’s important to make people feel at ease right away in an interview. Relax and show interest in them and their story
• You’re only trying to answer one question: Would this person be a good addition to the team?
• Remember to sell your company to the candidate too, since the good ones will have options.
• Use interview questions that are programming-language agnostic 
• Avoid miscommunication at all costs. You don’t want a candidate to struggle because you were unclear. Ask candidates to walk through a simple example based on a sketch of their solution before they starting writing code. 
• Don’t help candidates too quickly when they run into a concrete problem. Give them a chance to figure it out! This is a high-signal moment in the interview
• Take notes throughout the interview stream-of-consciousness and edit them after you’re done.
• Simple questions are often better than complex questions because they leave less up to the skill of the interviewer

Code reviews 

• If you are an active reviewer, you will gain valuable context that will help you debug problems faster
• If someone approves your PR it doesn’t mean they’ve validated that your code works. You should find alternate ways to ensure this. For example:
  • Write tests
  • Work with QA, if available
  • Partner with an end user to conduct acceptance testing
• There are many things a code review could cover. The fact that one of them is reviewed doesn’t mean that the rest are okay:
  • Code style
  • UX
  • Correctness
  • Performance
  • Security
  • Architecture
  • Consistency with similar features
  • Dependencies
  • Logging/observability
• It’s okay if you don’t have a lot of context on a pull request. Try to contribute one useful thing. One of the best ways is to check it out locally and take the feature for a test run!
• On finding reviewers for your code: Try to get at least one other engineer interested in your project so they’re motivated to give you feedback

Did I mention that we’re hiring a lot right now? Here’s my referral link. 😀