Hello there,

both matter, but not as a 50/50 score. Technical depth gives you something worth discussing. Good presentation helps the interviewer find and trust that depth.

For systems and network software, depth is not simply the number of features. It is whether you understand the design choices, possible failures, testing, trade-offs and what you would improve now. Better to have a small village you can defend than a sprawling city with nobody guarding the gates.

Documentation, build setup, tests and readable structure still matter because they are part of day-to-day engineering. In the AI era, that work can sometimes feel like being a teacher reviewing homework from an exceptionally confident student: the answer may look polished, but you still need to check every step. Your project does not need enterprise-grade ceremony. It should simply let another person understand and build it without wading through murky water.

In the era of YouTube tutorials and AI-assisted development, the important questions are: why did you build it, what did you change, where did you struggle, how did you verify the results and what did you learn? Starting with outside help is normal; being able to explain where it took you is what shows ownership.

Remember that not every project will resonate with every interviewer and that is fine. One strong project that you understand deeply is already an excellent foundation - a polished 30-minute film is often more memorable than a three-hour epic that loses the plot. Several projects can add more when they tell a natural story: “I built A, discovered I needed B, and that eventually led me to C.”. That progression shows genuine curiosity; just do not feel pressured to turn every repository into a perfectly planned cinematic universe.

And remember: it’s dangerous to go alone - take some confidence in what you’ve built with you. Good luck!

28 September, 2026 13:56