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.

Stuff that is implemented twice