I'd rather hire someone who can actually get the job done in a timely manner. We can optimize it later, especially after profiling to know exactly what we need to optimize, and especially if there are security implications that mean we can't ruthlessly optimize everything. People who optimize too soon end up with solutions that are hard to change later, or solutions that don't even do the job they're supposed to. It's all too easy to get a half-working version that's super fast by focusing on the speed part more than the working part. https://alibgoogle.wordpress.com/2011/02/18/scheme-vs-c/ is worth a read. "Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away."

There are some "free" optimizations I'd expect a lot of seasoned programmers to be familiar with, like as you mention the string concatenation issue, but those are easy to catch during code review. Similarly for certain optimizations that are even 'freer' in the sense that modern compilers will take the easier-to-read (if naively slower) version and produce the fast version, I expect to not have to tell people during code review that the 'slower' version isn't slow because the compiler does the right thing.