A design pattern is a standard, proven and reusable solution to a software design problem that comes up often. It is not ready-to-copy code, but an organizational scheme that you adapt to your context.
The notion was popularized in 1994 by the book Design Patterns by four authors nicknamed the "Gang of Four", which describes 23 patterns grouped into three families: creational (how to build objects, for example Singleton or Factory), structural (how to assemble components, for example Adapter or Decorator) and behavioral (how they communicate, for example Observer or Strategy).
Their first benefit is a shared vocabulary: saying "we go through an Observer" is enough for a team to understand the intent. Used well, they make code more readable and easier to evolve. Used badly, they add pointless layers of abstraction. There are also architecture patterns (MVC, CQRS) at a broader scale.
Why it matters when hiring
Reciting pattern names does not prove much. In an interview, ask the candidate for a case where they chose a pattern and one where they removed it because it made the code more complicated. The good signal: they start from the problem, not the catalog. A junior who puts them everywhere is a classic; a senior knows how to keep things simple.