1. Code that's too clever. Yea, you can munge some data structure to do something in one line, but it's going to take me 20 minutes to figure out what that line does and it often has subtle bugs in there because it doesn't do any error checking. Bonus points if there's no documentation saying what it does.
2. Bad variable names. This is really an art and good code makes obvious what the variables are doing and how to change them. Bad code makes this a complete guess because they're named something like "data" or "element" or even worse "x". There are exceptions, of course, but it really hampers readability or changes down the line when variable names are vague, or even worse, deceiving.
3. Too much abstraction. This is particularly egregious with Java programmers, who seem to want classes for everything. Now you have to open 13 different files to find out where the actual implemented function is and it's not at all obvious where you have to make changes to fix the bug.
4. Uberfunctions. A method or function that's 3 pages long and does 30 different things is just asking for trouble. I've seen so many of these that the programmer was too lazy to separate. The problem is that a function that's really long is very hard to conceptually keep in your mind when you're fixing something. And it's really easy to break. I can almost guarantee that these functions also lack unit tests, making changes to them very difficult.

• Stuff that is implemented twice. (Copy & Paste) You fix a bug an find out that the bug is also some where else.
• Non runnable code after you got if from git or no documentation what to do to run the solution. (Install Database, Dependenies, whatever...)
• Code documentation about WHAT the code is doing instead of WHY it is doing it. I think thats one thing beginners often do because they are not used to read code.

not making use of language patterns like inheritance/interfaces/modules/etc, no or bad documentation.

1. No unit tests: The first thing I do in a new codebase is open the tests folder. A good set of tests should basically be API documentation for your code, showing me what it typically does, how it could go wrong, and what mitigations have been put in place.
2. Excessive use of mocks in tests: It's fine, and helpful, to mock out a few http requests, etc. but when your mocking code becomes as complex as the code under test, you have to wonder what is even being tested. Also, the source code becomes difficult to change: want to change one line? Now all of the tests fail because the mocks don't make sense any more and you have to spend much longer fixing up the mocks than it took to make the original code change.
3. No readme (or some useless, generic one that has nothing to do with this particular bit of code): I don't have time to analyze all of your code. Tell me what it does and how to test/package/run it.
4. Magic numbers: e.g. retry(5). What is that? Retry in 5 seconds? Retry 5 times? If the latter, then why not MAX_RETRIES = 5 or something then retry(MAX_RETRIES)?
5. Main/handler functions that basically do everything with no smaller functions. Impossible to test properly and difficult to add functionality.
6. Functions that take too many arguments: This is normally a sign that your functions have too many responsibilities or that you are passing data around in your code unnecessarily.
7. Singleton classes that exist solely to serve as a namespace. Especially annoying in something like Python where the file is a namespace.
8. Files or directories named "utils": these normally end up containing a bunch of misc. stuff because devs were too lazy to figure out where things should actually go because that might involve a little bit of refactoring and tidying up
9. Lack of type annotations (if the language supports them). Running a static type checker can eliminate a whole class of bugs. Annotations also help with code readability.