diff --git a/README.md b/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..3f17361c245c2f481eb28e77c7bd77550a4c5f12
--- /dev/null
+++ b/README.md
@@ -0,0 +1,12 @@
+# Description
+Imagine that we have a program, some part of which somehow manipulates doors. Here are some parts of a few modules of this program.
+Is there anything you want to improve?
+
+# List of potential issues
+* Class Door has own method to convert itself to string representation. It breaks SRP.
+* Is it easy to extend the class Door? What if I want to represent door elements with a different colors? Partially breaks O of SOLID, but it highly depends on an architecture.
+* Should the state of this class keep both open/close sign and a color as a part of its state? Why, in which cases? How to improve it?
+* Method open in the class ClosedDoor breaks contract of class Door. It extends exception specification. Breaks L of SOLID.
+* Modules 3 and 4 (that processes doors) work with classes, not with interfaces. For example, method “open” might work with IOpenable interface. Ask candidate, what if I also want to open a window, not just a door? This part breaks both I and D of SOLID.
+* Method repaintOpenDoors shouldn’t exist at all: it should be a function that applies an operation based on a predicate. Or, even, better a ranges-like pipeline! To properly implement it, class Door should be extended.
+* There are also raw pointers and missing null checks, but who cares… Design example! Though, there are might be bonus points anyway!