Code shouldn’t be “smart”, that’s not really something to aim for, it should be as dumb and obvious as possible.
What this tends towards in practice though is that the more skilled someone is with programming, the more the “dumb” solution looks clever and concise to someone not as familiar with the language. And from the other perspective, long solutions created by those less familiar with programming will often be extremely complex and very difficult to follow and debug.
Concision is a virtue as long as it doesn’t obfuscate meaning: less code === less code to debug and maintain === less bugs. No code at all is ideal, as there will be no bugs caused by it. But failing that, as little as possible is good.
Edit: as an addendum to this, as noted in a couple of other answers, efficient code is not necessarily concise either. Be wary of optimising for efficiency straightaway (computers are plenty fast, and premature optimisation/second guessing the compiler is a fool’s errand in many cases), but understanding how to write efficient code is an important skill. Memory-intensive programs like calculating primes are normally a good thing to practise in this regard (as is learning a language that needs you to manually handle memory allocation, like C).
It’s all experience though – it takes time to memorise useful patterns, to build up the knowledge necessary to make good judgement calls about simplifying code, so don’t worry too much: read a lot of code, take what you can from it, come back to algorithm-like challenges regularly to test out ideas that are new to you. Don’t get hung up on principles like DRY (in particular don’t try to prematurely abstract things just for the sake of avoiding repetition), they are important, but getting things working first and understanding how they are working is the most important bit at first as @jameskomo says.