Here's what I wish someone had told me as a CS freshman.

Find Your Drive First

Most students approach CS backwards. They focus on getting the job, securing their future, and checking boxes. That's fine, but it's not exciting. And it won't make you exceptional.

I discovered this by accident. As a mechanical engineering student, I wandered into a hackathon and saw students building incredible things – mobile apps that tracked nutrition, interactive dance machines, and programmable robots. What struck me wasn't just what they built, but how quickly they could bring ideas to life. In mechanical engineering, it took months to go from idea to physical product. That’s why I pivoted from Mechanical Engineering to Computer Engineering in my sophomore year. With software, you could build something useful in days.

This is what should drive you: the ability to take any idea and make it real.

Pick One Thing and Stick to It

Here's the plan I wish every CS freshman would follow:

1. Choose something you're genuinely interested in. Love tea? Build a tea review platform. Obsessed with fantasy football? Create a stats analyzer. Passionate about music? Build a playlist generator.

2. Commit to it for two years. Yes, two years. Here's how:

   • Work in six-week cycles

   • Plan what you'll build in each cycle

   • Stick to the plan during the cycle

   • Take a week to reflect and plan the next cycle

   • Repeat

This sounds simple. It isn't. Your project will evolve. You'll need to add pagination when your data grows. You'll want a mobile app. You'll realize you need better performance. You'll integrate machine learning as you learn it in class.

This is the point. Real software engineering isn't about writing neat, isolated projects. It's about building something that grows, evolves, and becomes more complex over time. Two years of consistent work on one project will teach you more than dozens of abandoned weekend projects.

The Numbers Game of Getting Hired

Now for the tactical stuff. Here are the brutal numbers I've seen work:

• 100 online applications → 2 interviews

• 10 interviews → 1 final round

• 3 final rounds → 1 offer

But here's the hack: In-person connections change everything. Three conversations at a career fair can get you an interview faster than 100 online applications.

From day one of freshman year:

1. Mark every career fair date on your calendar

2. Track which companies are coming to campus

3. Attend every tech talk and networking event

4. Go to hackathons – both on and off campus

5. Document your journey publicly on Twitter and LinkedIn

Don't worry if your early posts are rough. They will be. The point is building the habit.

The Ideal Internship Progression

If you execute this well, here's your optimal path:

1. Freshman Year: Any software internship. Local IT company? Perfect.

2. Sophomore Year: High-growth Series C+ startup.

3. Junior Year: Big Tech. They hire juniors in the hopes to convert them fulltime.

This progression lets you experience different environments and make an informed decision about your first full-time role. Big Tech offers great compensation. Startups offer accelerated learning. A late-stage startup can offer both.

A Final Note

This might seem like a lot. It is. But here's the secret: most students won't do this. They'll bounce between tutorial projects, cram leetcode before interviews, and hope for the best.

You don't have to do everything perfectly. But if you pick one thing you care about, build it consistently for two years, and approach the job search systematically, you'll be ahead of 95% of your peers.

And more importantly, you'll actually enjoy the journey.

1. Scaling hardware orchestration (it’s an AI company) to keep up with demand.

2. Creating a solid foundation for the product to make adding features easier.

Here is my advice:

Don’t Call the Role “CTO”

The person you want to hire will still spend most of their time coding. In rapidly growing companies, architectures change dramatically. Until you have over 100 engineers, you don’t need full standardization (I saw this firsthand at Ridgeline). You need someone who can:

• move fast

• not be tied to their decisions

• and implement these architectures hands-on

Call the role “Staff/Principal Engineer” and add a significant equity component so they almost operate like a technical founder. This role should be a direct path to CTO if they choose.

Hire for Low Ego

A CTO title adds unnecessary ego to your startup. You need someone who prioritizes speed over perfection. Simple architectures are better for rapid growth.

Hiring someone with low ego is crucial because:

• Decision Making: The decisions they make should prioritize rapid progress over perfect solutions. Startups thrive on quick iterations and learning from mistakes rather than spending weeks to make the perfect choice.

• Team Dynamics: Low ego individuals tend to foster a collaborative environment. They are more likely to listen to other team members, welcome feedback, and make adjustments based on collective insights. This is essential in a small, fast-moving team where every member’s contribution is vital.

This is especially important because, like it or not, you'll project this person’s characteristics onto the next hires. Do you want five more engineers like them? They’ll likely lean towards hiring friends or past colleagues. This can be a good thing if you build a team of low-ego, high-output engineers.

How do they spend their time now?

Most of their time should be spent coding, prototyping, and unblocking other engineers. They are the first ones addressing customer feedback/ issues without being asked to. A very minor part of their job involves recurring meetings. Ideally they spend less than 4 hours a week in meetings.

Red Flags 🚩

These are some red flags I've seen with early stage technical leaders:

1. When you describe a complicated problem, they immediately offer a solution without seeking to understand.

2. They propose using something like AWS Amplify, unless it’s specifically for prototyping.

3. They want to rebuild fundamental technology to solve a problem (like an ORM, graph database, programming language, query language, etc.).

4. They don't ask about the customer or use the product to understand their pain points.

5. They aren't able to work fullstack/ refuse to do so.

6. They don't have experience writing documentation or explaining complex topics to non-technical people.

Be Prepared to Fire Early

The best companies make decisive hiring and firing decisions. If someone isn’t a culture fit, isn’t pulling their weight, or seems absent, consider letting them go. It’s not a reflection on the person—they might be incredible but not the right fit at this time.

Conclusion

I don't think CTOs build companies at early stages, engineers do. When are you hiring, be very choosy, but if the right person comes along, close immediately.

• Will Larson dissects the path to staff engineer

• Gergely Orosz deconstructs engineering leadership

• Countless newsletters analyze every move at FAANG

But startups? Radio silence.

This gap matters. Startup engineering isn't just scaled-down big tech. It's a unique beast with its own rules, challenges, and success metrics.

My Journey

I've spent my career in startups:

• Founding engineer and tech lead at Ridgeline (from pre-seed to Series C)

• Incubator founding engineering at Atomic (with 1 exit)

• Part of the kickass engineering team by Ironfish (backed by a16z and Sequoia)

• Big tech stint at Microsoft

Here's what I've learned: most startup engineering advice is wrong. Or at least, dangerously incomplete.

It doesn't tell you:

• How to be the entire "platform team" at a 10-person company

• How to ship a critical feature in a week because your CEO is pitching investors

• What to do when you suddenly become a part-time product manager

The Hidden Realities of Startup Life

But that's just the technical side. What about everything else? Here's what no one tells you:

1. How to evaluate a startup offer

2. How stock options really work

3. Why the 10th engineer often ends up better off than the 1st

4. The reality of 80-hour weeks

5. The mental toll of constant context-switching

6. The emotional rollercoaster of missed deadlines and pivots

7. How to decide if startup life is even right for you

8. What makes the mythical 10x engineer “10x”/ “cracked”?

Why This Blog Exists

That's why I'm writing this blog. To fill the gaping hole in startup engineering advice. To share the truths I wish I'd known a decade ago. Here's What You'll Get:

1. War stories from the startup trenches

2. Practical strategies for navigating hypergrowth

3. Insights on building engineering teams from scratch

4. Honest comparisons between startup and big tech life

5. Techniques for making critical decisions with limited information

6. Real talk about startup compensation, equity, and career trajectories

7. Frameworks for evaluating startup opportunities

8. Strategies for maintaining sanity in the chaos

9. Data-driven analysis of what really makes a 10x engineer

Who Will Benefit From This?

This blog is designed to provide value for a wide range of tech professionals, especially those interested in or already involved in the startup world:

• College Grads and Early Career Engineers: Get a head start understanding the unique challenges and opportunities in startup engineering.

• Big Tech Engineers: Gain insights into how startup engineering differs from big tech, whether you're curious or considering a change.

• Aspiring startup CTOs: Learn the ropes of technical leadership in a startup environment.

• Non-Technical Founders: Understand the engineering side of your startup better, improving your ability to work with and hire technical talent.

• Anyone Curious About Startup Engineering: Whether you're actively job hunting or just exploring options, you'll find valuable insights here.

🚀 Attention Founders: This is for You Too

You're not off the hook. In fact, you might need this more than anyone. Here's what you're probably asking yourself right now:

1. When do I need to hire a CTO? Or should I be the CTO?

2. How do I know if my engineering team is actually performing well?

3. What should my engineering culture look like? How do I shape it?

4. Am I technical enough to lead this company?

5. How do I hire engineers when I can't match Big Tech salaries?

6. When should I start worrying about tech debt?

7. How do I know if we're building the right thing?

8. How do I identify and attract 10x engineers to my startup?

These aren't just engineering questions. They're existential ones for your startup. Get them wrong, and no amount of product-market fit will save you.

I'll tackle these head-on. No BS, no fluff. Just hard-earned insights from years in the trenches.

The Bottom Line

Fair warning: startup life is brutal. The lows are lower than you expect. But the highs? They're unlike anything else.

My goal is to help you navigate this terrain and decide if it's right for you.

> Welcome to the manual I wish I'd had. Welcome to Founding Engineer.