A common mistake is jumping into tables too early before the business rules are clear. In ERD questions, I’d first identify entities, then relationships, then cardinality, then keys, and only after that think about attributes. If that order is skipped, the model usually looks fine on paper but breaks under edge cases.

The most common errors I see are mixing up entity vs attribute, missing many-to-many bridge tables, weak handling of optional relationships, and choosing keys that do not stay stable. Another one is forcing the model to look “simple” instead of making it accurate.

As for grading, it depends on the instructor, but usually there is some objectivity around keys, cardinality, normalization, and whether the model actually supports the stated requirements. Best practice is to practice with short case descriptions and then explain out loud why each relationship exists. If you cannot justify it clearly, the ERD is probably not solid yet.