How can I most effectively talk about my projects?

When it comes to talking about projects in general, the baseline is using the STAR method, which we break down in this video: Claiming Full Credit For Your Projects On Performance Review

In a nutshell, you want to focus on behavior (i.e. how you executed this project well) as opposed to just talking about what the project did.

Connecting the project to business impact is also nice, but I don't think it's nearly as important as behavior at mid-level. Impact can also be hard to come by as a mid-level or earlier engineer, especially if you aren't coming from Big Tech, as the products are smaller and you're often times given less compelling work at this level.

Working backwards from the expectations of a mid-level engineer in an interview, particularly a Big Tech one, here's what I would emphasize:

• Technical complexity - One of the core differences between a mid-level and junior engineer is the difficulty of their projects. So if you have worked on projects with a long time-span and/or required pulling many pieces together to make work, I would emphasize that.
• Quality of work - Big Tech has massive systems so even a bug that hits 1% of users hits millions of people. If you have a project where you had stellar quality, talk about that and the behaviors you showed to achieve that.
• Collaboration - This is a requirement for an engineer at any level, but it gets more important going from junior to mid-level and only gets more and more important from there. If you had to bring many parties together to get a project done, talk about that. Highlight alignment gaps you filled, particularly those among parties that were further away from you (either an engineer on another team or a non-eng stakeholder).

And here's what I would de-emphasize:

• The inverse of the above - It's hard to have a project that is picture perfect in all the above 3 categories. For example, you might have a project that was very technically complex, but you weren't able to handle it and shipped something pretty buggy that required several patches after. You might not want to talk about the latter in this example.
• The tech in detail - When talking about projects, you are often times talking to people who are pretty far removed from it, either an interviewer at a completely different company, a non-eng stakeholder, or even your own manager. Because of this, it's crucial to be able to talk about things at a high-level while keeping it easy to understand. A failure mode I've seen with more junior engineers talking about projects is they will name-drop libraries, languages, and frameworks constantly, thinking that's impressive. This is because junior engineers are very focused on the code. You don't want to do this as a mid-level engineer as you should be looking at things at a higher-level at this point.