|
|
@@ -15,12 +15,29 @@
|
|
|
1. sorting based on prices
|
|
|
2. sorting based on discounts (assume discount of 10 % discount on jewellery and 30% discount on men's clothing), applicable only when "All categories" is selected.
|
|
|
|
|
|
-### Expectation:
|
|
|
+### Expectation/Evaluation Criteria:
|
|
|
+
|
|
|
+1. Code Modularity (Highest priority)
|
|
|
+
|
|
|
+Assignment should have different components/services/files for different functionalities following Single Responsibility Principle and Separation of Concerns
|
|
|
+
|
|
|
+2. Bug Free Code (Highest priority)
|
|
|
+
|
|
|
+It’s ok if any of the acceptance criteria is not delivered but the ones delivered should be bug free.
|
|
|
+For eg. If price based filtering is not provided due to time constraint, it is acceptable but broken functionality should not be submitted in the final PR
|
|
|
+
|
|
|
+3. Naming Conventions (High Priority)
|
|
|
+
|
|
|
+All the variables and functions should be named in a way that it represents what is purpose of having that variable/function in the code. Also the naming should be consistent across the code whether it be camel case or snake case or something else. Also some common practices should be followed e.g. classes always start with capital letters
|
|
|
+
|
|
|
+4. Readable Code (Medium Priority)
|
|
|
+
|
|
|
+Code should be properly indented and prettified.
|
|
|
+
|
|
|
+5. UI (Low Priority)
|
|
|
+
|
|
|
+How neat and pretty the UI looks. If candidate has time, they can use any UI library like bootstrap/material to make the UI more beautiful to earn more points.
|
|
|
|
|
|
-1. 100% implementation of above use cases.
|
|
|
-2. Intuitive UI.
|
|
|
-3. Modular code with atomic components.
|
|
|
-4. Clean code with a focus on readability, scalability and maintainability.
|
|
|
|
|
|
### API Reference:
|
|
|
|
