I am an individual contributor and technical leader with multiple degrees in computer science engineering, and about 15 years of experience working on safety critical real-time embedded systems. I've interviewed many hundreds of people for software engineering roles over the years. The majority of people that apply for software engineering roles are simply not a great fit. Onsite interviews are very expensive in terms of engineering time, so as a company we try to vet coding ability via phone interviews and no-time-limit coding challenges. If we do ask a whiteboard coding question, it's because there were potential red flags earlier on in the process. When someone gets rejected after an on-site interview panel, it's either because they flopped multiple interviews, or were mediocre across all interviews. There's detailed notes individually typed up by each interviewer, and you can typically see common themes emerge across the various sessions.
"This person seems really sharp, and their questions were very insightful!"
"They really focused on testing more than the typical applicant."
"I tried giving them a hint four different ways, but they just wouldn't take it. When I explicitly explained what I was looking for, they agreed with me, but I couldn't tell if they actually understood."
"Their solution seemed a lot more complicated than necessary, and had a bunch of unhandled edge cases as a result. Every time I pointed out an edge case, they added another branch rather than fixing the underlying structural problems."
"Several times when I asked a question, they deflected or answered something else, or assumed I was implying something and continued writing more nonsensical code."
Also, many people people tend to attribute a lot of value to their personal/hobby projects. They're certainly very cool and fun to chat about, but it's very rare for projects to be novel in a way that sets you apart when being considered for serious engineering projects. At work we develop UAVs. Your hobby grade FPV quadcopter is totally sweet, but it isn't going to get you an interview. If you built a hardware-in-the-loop testbed for your quadcopter, then let's talk!
"Output" in particular is a funny thing to gauge in software engineering. I'll sometimes go a month without writing a single line of production code. My favorite PRs delete more lines of code than they add. A more junior coworker will have bloody fingertips from coding around a problem for days, and then I'll ask a relatively dumb question about what they're trying to do, they'll think for a minute, and then delete 1000 lines of code and replace it with 50 because they were making incorrect assumptions. It's not just individual productivity that matters, but also team productivity.
"Creativity" is also a funny thing. Within embedded software, the most elegant solution is the most boring one. Any time someone does something creative, there better be an extensive unit test for it, because otherwise it's definitely going to be buggy. With wisdom, discipline and creativity all together one can build more sophisticated and complex systems than otherwise, and that's highly valuable. Lacking wisdom or discipline, though, creativity does indeed become a liability.