

I studied computer science as an undergrad (a while ago). At the time, it felt like the only choice on an obvious path to a career as a programmer, even though I graduated in the middle of the 2008 recession.

In 2024, things are different - the job market is wildly competitive, and the path to a tech career is not as clear-cut as it once was.

I see countless posts on the [/r/computerscience](https://reddit.com/r/computerscience) subreddit along the lines of _I sent 74 applications and got no interviews - what am I doing wrong?_

On the other side of the spectrum, while hiring for my own team, I've seen a lot of candidates with non-traditional backgrounds who are just as capable as those with a CS degree.

I’ve also seen a lot of candidates with CS degrees who sound like they would be very challenging to work with.

So, with a handful of years of experience under my belt, I wanted to share some thoughts on what I learned from studying computer science, and what I didn't.

### Skill 0: Tenacity

**The most important thing** I got out of studying CS in school is tenacity. Learning hard computer science is really about writing code the wrong way many times and figuring out how to do it right. The process of doing it wrong and then getting it right is what truly fosters learning.

I spent many late nights in front of my computer pulling my hair out (RIP) trying to figure out why my code wasn't working. Little did I realize how formative those experiences would be for my career - even today, many of the more stubborn problems I face at work are solved with a solid dose of patience and tenacity.

Here's the good news: you don't need to study computer science to learn this. You can learn it by doing anything that's hard and requires you to fail a lot before you succeed.

### Learn how to Learn

I learned how to break down abstract problems into parts and apply things I picked up along the way. This involves research, memorization, and a lot of trial and error.

Another lucky break for you, friend -- you _probably_ have some of this skillset in your pocket already. Ever looked up how to fix a leaky faucet? Or how to make a soufflé? Or how to change a tire? It's the same process, just with different tools.

### Grits is just corn (you've seen it all before)

Many of my classes focused on fundamental concepts that comprise the building blocks of computer science. At the time it felt a little silly to spend so much time on things like sorting algorithms and basic data structures. But, as I've progressed in my career, I've found that these fundamental concepts are the most important.

_So many_ of the "hard" problems I've faced at work can be brokend own into simpler parts with solid understanding of these basic concepts. By the same token, there are also some problems that just [can't be solved](https://en.wikipedia.org/wiki/P_versus_NP_problem) with the tools we have today. Understanding the shape of those sorts of problems is helpful, too.

All this to say: being able to see larger problems as a collection of smaller, more manageable problems is a skill that will serve you well in any career.

---

## Here's what they don't teach in Computer Science programs

While I don't regret my formal Computer Science degree, there are _mountains_ of critical lessons that they didn't teach in the courses I took.

### You don't need anyone's permission

You don't need anyone's permission to learn this stuff. Most of what I know and have learned in my career is freely available online. With dedication, you can learn through online courses, YouTube, tutorials, and books -- if you're willing (and able) to put in the time.

Formalized education is great, but it's not the only way to learn. I've met many successful developers who never went to college, and others who have degrees in unrelated fields.

### There is no archetype

Carnegie Mellon's computer science program is great, but it's not the only way to learn. I've met successful developers who never went to college, and others who have degrees in unrelated fields.

I have worked with some incredible UX designers, developers, PMs, etc. who started their careers in economics, geography, library science, the military, and even as auto mechanics. These people bring a unique perspective to the table that someone who has only studied computer science might not have -- and that's a good thing.

### It's difficult no matter what

Breaking into a tech career is hard, regardless of your path. It's not just about having a degree or self-taught coding skills; landing your first job depends on your ability to make connections and network. Getting in front of the right people at the right time can make all the difference. A prestigious degree or an impressive self-taught portfolio alone isn't enough, especially when competing with a mess of other candidates.

---

## So what, then?

This newsletter comes from my frustration with gatekeeping: there's not one right way to get into a tech career. Do what works for you, and don't let anyone tell you that you're doing it wrong.

I enrolled in a whole-ass masters degree program because I was told early in my career that it was "the only way" to get into UX work at Microsoft. I'll be damned if that's the case today.

No matter what path you go down, you're going to work hard; success will always feel like it's just behind the next obstacle. Use that as fuel to keep you learning and trying new things.

Most importantly, get to know the people around you -- help them out, be a positive force, and give without the expectation of receiving. An investment in your people is one that will pay for itself many times in the span of your life.

---

## More career advice from me

If you or someone you know is considering a career shift, you may also find these articles useful:

- [Why learning new frameworks make better developers](https://mikebifulco.com/newsletter/why-new-frameworks-make-better-developers) -- and a meta-lesson about learning
- [Your Resume sucks](https://mikebifulco.com/newsletter/your-resume-sucks), but that's okay - a little positive reframing will help you stand out in your next job search.
- Here's why [Old, embarassing projects in your Portfolio](https://mikebifulco.com/newsletter/portfolio-as-timeline) are super valuable as you learn.

## Louder, for the people in the back

- 🎙️ My recent interview with [James Perkins from Unkey](https://apisyouwonthate.com/podcast/unkey-globally-distributed-api-key-generation-with-cofounder-james-perkins/) for the APIs You Won't Hate podcast is one of the more memorable chats I've had in the past year. James' path from a contributor to a developer advocate to a successful founder is a great reminder that our careers rarely follow a predicable path.

I hope you enjoy this one!


Three things school taught me (and Three things it didn't)

Grits is just corn (you've seen it all before)

Here's what they don't teach in Computer Science programs


This past weekend, I spent some time building a new project with 🧑‍🚀 [Astro](https://astro.build). It describes itself as "The web framework for content-driven websites", which was perfect for my use case - rebuilding a content-heavy site for APIs You Won't Hate, called [openapi.tools](https://openapi.tools).

I've been building with React for a good long while now, and Astro's come-as-you-are approach to javascript frameworks means that I was able to mix in React components with Astro's own syntax. At first, this felt a little bit like getting peanut butter in my chocolate, but... it works surprisingly well.

<Image
  publicId="newsletters/why-new-frameworks-make-better-developers/astro"
  alt="Astro + React feels like getting peanut butter in my chocolate"
/>

In true extrovert fashion, I jumped into learning about Astro by building with it in public on a [YouTube Livestream](https://www.youtube.com/watch?v=wyJYInvZya8) last Saturday.

It... was tough, honestly.

Over the course of a few hours, go from explaining my approach and stream-of-consciousness thinking, to silently debugging a react-in-astro challenge for... a while.

Perhaps appropriately, the stream ended abruptly after my wife told me my webcam was no longer working... followed shortly by OBS (the streaming software I use) crashing. 🤦‍♂

## So learning in public wasn't a great success

The livestream was a struggle. I stepped away from my Astro project, and came back to it the next day.

Something clicked. I was able to get past the issue I was having, and my project really started to fly together quickly. I was able to get a lot done in a short amount of time, and I was feeling pretty good about it. (By the way: I'll be sharing the fruits of my labor in the coming weeks...)

My second day of building honestly felt a lot more like typical dev work does for me - I was in a flow state, juggling tiny tasks and debugging issues as they came up. I felt unfazed to be working with Astro; a completely different experience compared to just the prior day.

## It's familiar, but not too familiar

As I got to this point into the project, I could feel myself pulling from experience building with _all_ of the other web frameworks I've built with, whether directly or indirectly.

I've built production apps with many frameworks over the years: from create-react-app to Remix.run, Next.js to Ruby on Rails and now Astro. I've also poked around at countless CSS and UI libraries like Bootstrap, Tailwind, Chakra, and ShadCN UI. It's a little difficult to describe, but the time I spent with each of these tools has made me a better developer.

Of course, learning about Bootstrap doesn't inherently make me understand React -- but it did add to the foundation of skills I use to debug things, to research solutions when I'm stuck, and to ask for help when I need it.

That new error that just popped up? I've seen something like it before. Oh, this component isn't rendering correctly? I know how to debug that. This layout isn't quite right? I know how to fix it. You get the idea.

## The Hierarchy of Competence

In cognitive psychology, there is a model called the [Hierarchy of Competence](https://en.wikipedia.org/wiki/Four_stages_of_competence). It describes the stages of learning a new skill, from unconscious incompetence to unconscious competence:

<Image
  publicId="newsletters/why-new-frameworks-make-better-developers/hierarchy-of-competence"
  alt="Hierarchy of Competence"
  caption="The Hierarchy of Competence, not to be confused with the Dunning-Kruger effect..."
/>

In the early stages of learning, we stumble between the "unconscious incompetence" and "conscious incompetence" stages. We don't know what we don't know, and then we start to realize how much we don't know. Getting through this phase can be a slog, but it's a necessary part of the learning process.

Don't get me wrong - I'm not going to tell you that I've mastered the damn thing after a weekend - I wouldn't want to end up hanging out with my dear old friends [Dunning-Kruger](https://mikebifulco.com/newsletter/learn-from-a-dunning-kruger-expert) again. I will say that I'm likely past the "conscious incompetence" stage with Astro. I'm starting to see the patterns and the ways that Astro's approach to building websites is different from what I'm used to.

What I am saying is that weekend projects like this inevitably bolster my skills as a developer. They're a good reminder that my expertise isn't just in React or Rails or Next.js - it's in problem-solving, debugging, and learning new things.

If you happen to manage a team of engineers, this is a good reminder that giving your team the space to explore new tools and frameworks can be a good thing, whether in a weekend project or in a more formal setting.

And if you _don't_ manage a team, remember this the next time someone tells you that it's a waste to try out a new framework or library: it's not about the tool itself. It's about the skills you pick up along the way.

---

## Some useful links for learnin' new things

- 🚀 [Astro Web Framework Crash Course](https://www.youtube.com/watch?v=e-hTm5VmofI) My pal James Q. Quick produced a course for FreeCodecamp. If you're thinking about astro-ing, give it a look!
- 🗣️ The [world's shortest social engineering masterclass](https://www.youtube.com/watch?v=ffcTwHZRhSk) from Buildspace is a great watch. A few years back, [I took their course on building web3 apps](https://mikebifulco.com/posts/learn-web3-blockchain-with-buildspace). While their business model has changed, Farza and his team have continuted to put out compelling lectures on their YouTube channel. I watched this one over the weekend, and was inspired by the humble approach Farza took when building his brand and influence.

## HELP ME PLZ: 💌 Tiny Improvements feedback

I've been writing Tiny Improvements for a _while_ now, and although I occasionally get a reply or two, I'd love to hear more from you.

- What do you like about this newsletter?
- What things would you like to see less of?
- Anything I can do differently to make this more valuable to you?

Hit reply and drop me a line - let me know what you think. There's no idea too big or too small.

I'm all ears. 🙏


Why new frameworks make better developers

So learning in public wasn't a great success

Some useful links for learnin' new things

HELP ME PLZ: 💌 Tiny Improvements feedback


# I want to hire you...!

...But, I can't hire you if I can't find you, and I won't find you if your resume sucks.

So, let's fix that. If you want to give yourself the best possible chance to land an interview from your next job application, this guide is for you.

Over the past few weeks, I've reviewed hundreds of resumes while hiring for [open engineering roles at Craftwork](https://www.ycombinator.com/companies/craftwork/jobs/). I've had people reach out on LinkedIn, Instagram, Reddit and by email to apply, which is honestly awesome. I love that people are excited about what we're building and want to be a part of it.

But here's the thing: **most of the applications I've seen are terrible**. They're so bad that I can't even tell if the person is a good fit for the role. And if I can't tell if you're a good fit, I can't take away time from my team to interview you.

I genuinely believe that many of the people applying to work at Craftwork are great candidates - and with a little bit of love, their applications would shine. So I'm writing this guide to help you write a job application that doesn't suck, from a hiring manager's perspective.

## Here's what I'm looking for when you apply

Ultimately, the goal of a job application is to give the hiring manager a reason to want to talk to you. It should clearly communicate **what you're best at, what work you've actually done, and what drives you to do it**. If you can do that, you're already ahead of the game.

You would be shocked to see how many applications I've seen that don't have the basics right.

### Give your resume some love

Don't apply to a job if you don't have a detailed, up to date resume/CV ready to go. If you don't have a resume, you're not ready to apply for a job.

I've read through several applications that include _nothing more than a name and an email address._ No resume, no cover letter, no LinkedIn profile, not even a GitHub link!

As you might expect, these applications are rejected immediately.

Treat your LinkedIn profile like a living resume. If you take the time to fill in your profile with a detailed work history, it can be a suitable replacement for a pdf. Want to do both? Knock yourself out.

Every bit of your work history should include the company name, your job title, the dates you worked there, and a description of what you did. _Many_ applications I've seen go to LinkedIn profiles which only contain a company name, dates and job title. That doesn't tell me anything useful, even if you worked at a FAANG.

For tech roles, include a short list of the technologies you used for that role. This is especially important if you're applying for a role that requires specific experience with a technology.

Don't lie on your resume by adding things you haven't done. You can _absolutely_ exaggerate your accomplishments, but don't put yourself in a position where you might get caught in a lie.

### Make it personal

Every one of us sees the world through a different lens. We all have different experiences, different perspectives, and different ways of thinking. That's what makes us unique. So why do so many resumes look the same?

If you want to stand out to a recruiter, let your personality come through a bit. Here's how:

**Include a short bio** at the top of your resume. Tell me who you are, what you're passionate about, and what you're looking for in your next role. This is a great way to show your personality and make yourself stand out.

Here's the bio I used the last time I brushed up my resume to apply for a job:

> **WHO AM I** <br />
> An impassioned, imperfect, endlessly curious person, fascinated by design and technology, trying to leave the world in better shape than I found it, and amplify the accomplishments of those around me.

Admittedly, I cringe just a little bit reading it now - but hopefully you get the idea. It's personal, it's unique, and it's a great way to start a conversation.

**Don't use a cover letter template.** I don't know if ChatGPT is to blame for this or what, but I've read several cover letter back-to-back that were nearly _identical_ except for a few specific details. If you're going to write a cover letter, make it personal. Tell me why you're excited about the role and why you think you'd be a good fit. If you're not going to make it personal, don't write one at all.

**Lead with something interesting.** This is intentionally vague -- but if your cover letter starts with some variation of "with over 5 years of experience, I..." your cover letter already sounds like 90% of the other cover letters I've read.

I know you're more interesting than that! Let your personality and interests shine through. If it all goes well, your cover letter is the start of a conversation - recruiters and hiring managers can read your resume for years of experience (if they really want to).

Here's the first few sentences to my most recent cover letter, to give you a sense of what I mean:

> My name is Mike Bifulco, and I'm a software designer, engineer, and serial entrepreneur based in Charlotte, NC, USA. I'm submitting my C.V. for consideration for DevRel leadership roles at ████, and I couldn't be more excited to do so. I've spent my career helping others make their dreams come true by building great products on the web. Helping developers tackle new problems and grow their skill sets is an incredible privilege, and being able to do so while working for ████, and growing an incredible team of developer advocates and engineers would be a thrill.

**Include your most meaningful personal projects.** If you're applying for a job as a software engineer, I want to see what you've built. If you're applying for a job as a designer, I want to see what you've designed. If you've done some of your best work outside of your job, I would love to see it!

**When possible, link to your available work online.** This includes websites, apps in the app store, blog posts, videos, etc. If you've done something cool, I want to see it.

### Found a role you're in love with? Go the extra mile.

If you've come across a job opportunity on a team that you're _really_ smitten by, go the extra mile to make your application stand out. Here's a few ideas:

**Use your network** to find someone you know with a contact at the company you're applying to, even if it's on a different team. If your connection is good, ask transparently for an introduction, and ask them to put in a good word for you. If you're not sure if your connection is good, ask them to be honest with you. If they're not comfortable making an introduction, don't push it.

This is one reason why it's good to be proactively kind to people you work with - you never know when you might need a favor, and if you've only ever _asked_ for favors, you're not going to get very far. Give without the expectation of getting anything in return, and you'll be surprised how often people are willing to help you out when you need it.

**Reach out to the hiring manager directly.** If you're applying for a role at a startup, there's a good chance that the hiring manager is the CEO or founder. If you're applying for a role at a larger company, there's a good chance that the hiring manager is a senior leader. Either way, they're probably pretty easy to find online.

**Try out the product.** If you're applying for a role at a company that has a product, try it out. If you like it, tell them why. If there are opportunities for improvement, offer constructive criticism. If you're applying to a developer tools company, try out the product and build something with it. Share what you've built with the team, or open a Pull Request to fix a bug or add a feature. This is a great way to show that you're passionate about the product and the company, that you can communicate and work well, and that you're a self-starter.

## Improve the odds to get an interview

Everything I've mentioned so far is about making your application stand out, and giving the hiring manager a reason to want to talk to you and schedule that first interview. Yes, it can be a lot of work, and _yes,_ there's definitely challenges with privilege and bias in the hiring process.

If you're serious about landing the best possible gig for your next role, you'll see the best results if you put in the work.

---

What do you think? Did I get anything really wrong here? Is there something you've done or seen that helps people land an interview? If you have any questions, comments, or feedback, I wanna hear it. Please reach out to me on [Mastodon](https://hachyderm.io/@irreverentmike), [Threads](https://threads.net/@irreverentmike) or [shoot me an email](mailto:hello@mikebifulco.com).

---

## Recommendations from around the web

- 📖 I'm currently reading through [Oversubscribed](https://www.amazon.com/Oversubscribed-How-People-Lined-Business/dp/B085P1N7LR/ref=sr_1_1?keywords=oversubscribed&qid=1696419802&sr=8-1), by Daniel Priestly. It's got some great insights on how to build a business whose demand exceeds its supply, and how to use that to your advantage.
- 🎨 I recently found out that the [Washington Post's Design System](https://build.washingtonpost.com/foundations/color) is published online for anyone to check out (shout out to my pal Edward for sharing!). If you're at all interested in building UI libraries or design systems, give it a look.
- 📰 [What not to do in API Versioning](https://apisyouwonthate.com/newsletter/api-versioning-what-not-to-do/) is the latest newsletter from APIs You Won't Hate, the dev community I help run. It's a great read on a hairy topic, especially if you're building APIs.


Your resume sucks. Here's how to fix it.

Here's what I'm looking for when you apply

Found a role you're in love with? Go the extra mile.


At some point in your life, you will look back on the work you did when you were just getting started with a new skill, and see everything you did wrong. You'll see the mistakes you made, the things you didn't know, and the things you didn't even _know_ you didn't know.

You may have felt this already. Maybe it's that design project from high school or university or bootcamp, or the first website you ever made. I think we all have a tendency to see our old work as embarrassing.

I'd like to offer up an alternative perspective.

You've come a long, long way. We all have. Looking back on your portfolio and seeing how far you've come is a great way to to see how much you've grown, which is a process that can be imperceptible day-to-day.

It's the reason I called this newsletter _Tiny Improvements._ Focus on being an incrementally better version of yourself every day, and those tiny improvements will add up to something incredible over time.

**Your homework this week:** Look back at your past-you; find some examples of your oldest work, and think about how you've grown. If you're feeling brave, reply to this message with a link to your oldest work, and your thoughts on it today, and I'll share mine too.

---

## Where I've been learning lately

- 🌳 [Unheard Roots](https://unheardroots.com/) is a wonderful newsletter that I've come upon recently. They share stories & strategies about game-changing startups that you may not have heard of before. I really enjoyed their post about Reddit.

- 📈 [Growth.design](https://growth.design/) is a fantastic collection of extremely well-illustrated UX case studies from products we've all used. It's super interesting to see them detail dark patterns, like Adobe's Offboarding process -- where customer satisfaction is sacrificed for the sake of revenue.

- 📼 [Theo - t3dotdogg](https://www.youtube.com/@t3dotgg) on YouTube has been making some _insanely_ insightful videos on building companies and products with TypeScript in 2023. I have found his videos to be extremely helpful while building my new startup.

## Some things I've made, just for you

- 👾 Over at APIs You Won't Hate, we just dropped a new newsletter: [Laravel is Harmful](https://apisyouwonthate.com/newsletter/larvel-is-harmful/). If you're into building or using APIs, you're gonna love APIs You Won't Hate. Consider subscribing - our newsletter goes out twice a month.

- 🎨 We just launched a shiny new estimate generator for interior painting projects over at [Craftwork](https://craftwork.com/estimate). It's a simple-looking wizard, and building it exemplifies one of the most important lessons I've learned in my career: **simple is hard.** We'll be iterating on this tool quickly over the next few weeks, so if you have any feedback, we would love to hear it.

---

And that's it for me this week. It turns out building a startup, publishing this newsletter, and maintaining a dev community is a lot to balance - but I'm loving every minute of it. Thanks so much for reading. Keep doing your thing - I'm proud of you.


#career: 4 posts tagged

Three things school taught me (and Three things it didn't)

Why new frameworks make better developers

Your resume sucks. Here's how to fix it.

Your portfolio is a timeline of your growth