Learning Path

You should only do personal projects if 1) you do not have any work experience, 2) you want to break into a new field that you have not been exposed to through work experience, or 3) you took a long career break and want to show you exercising recent skills. If you have real work experience either through a full-time job, contract, or internship, what you worked on during those opportunities should take precedence over any personal projects on your resume. If you have extensive work experience but have a personal project that you’re really proud of or that has real, active users, then you can mention the project on your resume. Just don’t let it take the focus away from your real work experience, as recruiters and hiring managers care about your work at established companies more.

With that being said, if it’s worth it for you to do personal projects, focus on less quantity and higher quality. One polished project that you went super deep on and involved tons of technical challenges will look better than several projects that have shallow depth. When I was in college, I did several projects that were all 80% of the way to being production-ready products. In software, the last 20% is 80% of the work, and it’s often where you learn the most. Anyone can create a REST API, but can you make it reliable and low-latency? Now that’s much harder. The lack of depth in my projects made it hard for me to discuss challenges during college internship interviews. I still made it, but I definitely would have done this differently if I could go back.

If you don’t have real work experience yet, I would make sure you have at least one really great project to put on your resume and talk about during interviews. I’ll talk about other activities you can do in the open source section.

Projects do two things before you have real work experience. Firstly, they get your resume in the door by passing automated and human keyword screens. Secondly, they give you an opportunity to showcase your depth of knowledge and expertise during the interview. It’s easy to do the former. The latter is more challenging.

Before you have real work experience, the interview conversation will heavily focus on your projects and what you learned from them. The interviewer will make these conversations go deep, so it’s an opportunity for you to either show your expertise or show that you just used AI and didn’t think at all.

Besides being able to describe at a high level how the project works, you want to be able to talk deeply about several specific challenges and decisions you had to make. You want to be able to talk about what the challenges were, what you investigated and learned, the trade-offs and justifications you made, and how you solved each particular problem. Many behavioral questions target how you navigate tough technical challenges, so showing a meticulous, thoughtful approach for tackling the challenges in your projects is essential.

The challenge is, with AI, it’s too easy to build something without learning. So, in order to generate these challenge examples, you need to lead the project design with your brain instead of offloading your thinking to AI. Since AI is so good at implementing, in order to lead the project yourself, you need to spend most of your time in the design phase before any code gets written.

Thus, you should approach projects as system design practice problems that you actually implement. This means that you spend most of your time deliberating and solving problems while building out a detailed high-level design document. This activity is the same as what you’d do during a system design interview, except this design document should be even more detailed and thorough. Building this document is where you actually learn.

Note that earlier in the system design portion of the roadmap I stated to learn system design before starting projects. This approach I’m recommending now is precisely why. You need enough system design knowledge to know what the best practices are for building systems, what the appropriate technologies are, and what real problems even look like. If you don’t have this knowledge beforehand, you can end up solving known problems incorrectly or with the wrong tools. Basically, you should learn how systems are built before trying to build your own system.

Just like in a system design interview, every project you build should start with a set of requirements. The end result of your project will be a fully-deployed, production-ready system, so you should always build something that real people may actually want to use - something that solves a real problem. It’s fine if you’re not sure what people want, so just take your best guess. However, if you solve a problem that you personally experience, usually you’re pretty equipped to build what real people would want. Just keep in mind, product-market fit isn’t the goal of this exercise. The goal is to learn engineering skills. Ultimately though, if you do end up getting real people to use your system, that looks stellar on your resume. And you never know, maybe it will turn into something that you can pursue long-term if enough customers show interest.

In addition to building something potentially relevant, build something that requires you to use the technologies that you’d use as a full-stack engineer. Full-stack engineers usually work with client-side javascript, REST API servers, databases, file storage, cron jobs, batch processing…etc. Make sure your system involves these widely used technologies, and also 3rd party integrations as well. Creating the plumbing for an integration with another service is a great learning experience, as it makes you research and build around the service agreements and restrictions of another real system. Usually creating a web or mobile application creates the opportunity for leveraging these technologies, but you could also build an API service as well that’s used by developers. The point is that you want to use the right technologies so you can have the right skills and keywords on your resume. Thus, if your project idea is too simple, I’d add requirements (both functional or non-functional) to make sure you get exposed to enough technologies and see enough technical challenges.

Next, build out the design document in detail. The following is not an exhaustive list, but for example, write out the exact definition for any APIs and the pseudo code for what they will accomplish. Pick your database, make the trade-offs and have a justification for your database choice. Plan ahead of time how concurrency issues will be handled. Handle basic scalability requirements using proper indexing or database architecture. Model out your database schema exactly. Define every column, relationships between tables, indexes, isolation levels, and data types. You want every detail to be covered so there is nothing left to decide when it comes time to implement it using AI. You should complete this process in such detail that you encounter the stimulating technical challenges here, not while implementing. As you build the design, take note of the toughest challenges and record them as project bullets for your resume.

After you have your design, then you should implement every piece of the system slowly and incrementally using AI. Don’t just throw the whole design at Claude. You will come across technical challenges and opportunities for learning during the implementation phase as well, so you need to digest the code that’s being written in order to recognize these opportunities. For example, you could learn more specific programming language details, project structure best practices, appropriate library choices, and multi-threaded / concurrent programming. Additionally, interviewers could ask you questions about how the code is written for certain features. For example, if you added an in-memory cache in your Java backend, the interviewer could ask you what object or library you used and why. In your real job, you will be taking ownership over every line that AI writes, so you should do the same during your project. Ultimately, it’s not possible to digest the code if Claude writes too much at once, so build one feature at a time in small chunks.

Back when I was in college, it was fine to just build something that works locally. I could still get enough learnings from local development work to talk about in an interview. However, in the age of AI, the bar is higher. You’re expected to do more since it’s easier to do more. Thus, you should take project development through to production deployment. If you build a webapp, buy a domain and make your project accessible on the public internet. Go through the process of learning how to deploy software using AWS. Why AWS? It’s a highly relevant skill you will absolutely use in the industry. Don’t rush through the deployment step. Treat it as a learning opportunity and understand the steps needed to publish your project. For example, you could be exposed to tools like Docker which is also a highly relevant technology. Additionally, as you setup your production deployment, setup a simple CICD process with proper development environment infrastructure. The systems used to develop, test, and deploy software are a massive part of the development lifecycle that every full-stack engineer should know. Development tooling and CICD skills are so important, it would even be valuable to talk about them in an interview in addition to the actual product you built. For example, if you’re using SQS and DynamoDB in prod, the interviewer could ask you how you went about testing against these tools during development and how you easily published your changes to the production environment. Thus, at minimum you should create isolated development infrastructure to develop and test on, and automated production deployments triggered by pushing your code to GitHub. Given that you need a test environment while developing, infrastructure should be something you setup at the very beginning of your project.

Finally, use a Claude plugin (like the frontend-design plugin) to make your user interface polished and user-friendly, and publish your project on your personal website. Yes, you should have a personal website given that it takes 10 minutes to make with AI.

Before having real work experience, on top of doing one polished project, I’d also focus on contributing to open source. Why? It exposes you to development on real projects, with real engineers reviewing your code. Getting your code approved and merged into reputable open source projects signals professionalism and competence to hiring managers, and it’s almost as powerful as having internship experience.

Once again, if you have real work experience, I’d prioritize that on your resume over open source. However, if you’re in college or pre-industry, open source is a great way to learn, overcome technical challenges to speak about in interviews, and it overall looks great on a resume. Pick one open source project and go deep. Learn the code-base and contribute by fixing several issues or adding functionality.

It may be intimidating to start contributing to open source. Thankfully, I think this guide does a great job of explaining how you can start.

Obviously you can find any GitHub repo you want and open a pull-request, but I’d recommend finding a project on Meta Open Source. You could even get away with putting “Meta Open Source Contributor” on your resume 👀. But you didn’t hear that from me…