As someone who does some technical recruiting, things that look good: 1) Work experience. Let's face it, this always looks good to everyone looking over your r

As someone who does some technical recruiting, things that look good: 1) Work experience. Let's face it, this always looks good to everyone looking over your resume. We all know that people hiring for an office have a bias for work you do in an office. I'm as guilty of it as the next guy. 2) Side projects. For me at least, starting stuff from the ground up (no matter how silly or niche) shows me the kind of code you write in your free time, which is a much better measure of your ability (but possibly a less rigorous measure of your success) than what you do at work, where you're constrained by deadlines, code reviews, and "best practices". 3) Open source contributions. This one is trickier; usually when you contribute to Open Source projects, you're doing small pieces of the big work that needs doing, and there isn't much decision making/architecting going on. Speaking as someone who's currently trying (and failing....) to get into Linux kernel contributions, 90% of the issues you're going to come across that are within your abilities to fix are the kind of thing that a more experienced dev could do in 20 minutes, but doesn't have the patience to sit down and do it (due to being busy with more important/pressing work). So, the vast majority of the work you'll do (especially early in your career) is going to be bound in scope by your lack of experience, and won't be as impressive as engineering something from scratch. In general, WRITE CODE. WRITE LOTS OF CODE. And show off whatever you can. And try to follow best practices, e.g. using CI/CD, writing good tests, using proper style, designing and documenting your architecture, etc.