Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
I got selected to move forward for a Software Engineer (Frontend) role with a foreign company from a cold DM and was given a test assignment. I delivered beyond the expected result, only to receive feedback from a review that seemed out of touch with current web development best practices, especially within the Vue 3 and Nuxt 3 ecosystem. A senior engineer who looked over my work remarked, “It’s clear you are better than the reviewer,” which inspired me to share this story.
The Flawed Review
The review listed several shortcomings:
Many of these points were vague or incorrect. Let’s examine each claim.
1. Composition API Usage
Reviewer’s Claim: “No composition (Vue 3)”
Reality: Every component in the assignment used Vue 3’s Composition API with <script setup>, defineProps, defineEmits, reactive ref(), and other variables. This is idiomatic Vue 3 by design, enabling cleaner logic and better type inference with TypeScript.
Vue's recommends <script setup> for Vue 3 and Nuxt 3.
The below component clearly shows the use of composition API which was used in every single vue component in the codebase with typescript.
Lesson: Always verify the reviewer’s technical context before accepting their conclusions.
2. Project Architecture
Reviewer’s Claim: “No project architecture”
Reality: The project follows Nuxt 3’s opinionated file-based architecture, which is industry-standard and recommended in the official documentation. The structure includes:
Calling this “no architecture” is, frankly, misleading.
This structure aligns perfectly with and scales well for large applications.
Approach Hint: Embrace framework conventions to streamline setup and reduce boilerplate.
3. Code Repetitiveness
Reviewer’s Claim: “Code repetitiveness”
Reality: I built reusable components to avoid duplication wherever practical. Any repetition, such as Tailwind utility classes or minimal logic blocks, is contextually appropriate and does not constitute a flaw without concrete examples.
Hint at Organization: Group similar UI elements into shared components; use design tokens or helper functions for common patterns.
4. Card Persistence (LocalStorage)
Reviewer’s Claim: “No cards storing (local storage)”
Reality: The assignment’s Technical Requirements specified using the Composition API and Pinia for state management; it did not mandate data persistence. I implemented every requested feature; UI interactions, CRUD workflows, and design fidelity. If localStorage persistence was expected, it should have been explicitly outlined.
Using localStorage would be a reasonable enhancement, but the task did not explicitly require persistence. The Technical Requirements section clearly mentions using the Composition API and Pinia store, both of which were implemented. The task primarily focused on UI functionality, the CRUD workflow, and accurate design implementation, all of which were completed. If persistence was an expectation, it should have been clearly stated in the task description.
5. Design Fidelity
Reviewer’s Claim: “Not following Figma design”
Reality: I matched structure, colors, spacing, and typography to the Figma mockups. Minor pixel adjustments may vary across environments, but no significant deviations occurred. All UI screenshots that were attached to the feedback were basic to fix and the feedback got me wondering what the use of 'code-review before merging to main' is for?
How on earth could a good reviewer point out inline padding on a closely implemented button that functions perfectly as a flaw, while ignoring everything else; pixel-perfect UIs, 100% functional implementation, ~100% performance, accessibility, SEO, best practices, speed, and animations? I mean, just look at what the reviewer is pointing out:
Not a single review mentions key functionalities, performance, Git branching and commit messages, best practices, or the cool transitions shown below.
I mean, look at the performance stats, near-perfect Core Web Vitals, optimised asset loading, and a responsive, accessible layout. Yet the review chose to ignore all of that and instead pointed out something like button padding as a flaw.
It’s critical to understand that web development is far more than what you see on the surface. Good reviews go beyond static visuals and evaluate architecture, performance, maintainability, and user experience holistically.
Tip for Collaboration: If you spot a potential mismatch, always provide annotated screenshots, clear examples, or Git-style code review comments referencing the specific line or component, it saves everyone time and confusion. Also, know the weight of what you're pointing out. A slight inline padding difference is not a breaking change and should be treated as a minor refinement, not a critical flaw. Context matters when reviewing work, not all mismatches are created equal.
6. Bugs
Reviewer’s Claim: “Bugs”
Reality: The only minor issue involved checkbox selection logic, a trivial fix by targeting checkboxes via unique IDs. Moreover, displaying a fallback message when a card ID doesn’t exist is a deliberate, user-friendly enhancement, not a defect.
Best Practice: Provide meaningful defaults for nonexistent data to avoid blank screens.
Takeaways & Moving Forward
When a senior engineer affirms your strength, it’s a reminder to trust your expertise and seek reviewers who understand the technologies you use. Stay confident, keep learning, and always aim for clarity in both code and communication.
Thank you for reading this part of my story-turned-article. What are your thoughts on my experience?
Let’s keep building amazing things and expanding our skills.
Have any gig, offer, or questions for me? You can always hit me up.
,
Full-Stack Engineer | Frontend Specialist
The Flawed Review
The review listed several shortcomings:
- No Composition API usage.
- No project architecture.
- Code repetitiveness.
- No cards stored in localStorage.
- Not following the Figma design.
- Bugs.
Many of these points were vague or incorrect. Let’s examine each claim.
1. Composition API Usage
Reviewer’s Claim: “No composition (Vue 3)”
Reality: Every component in the assignment used Vue 3’s Composition API with <script setup>, defineProps, defineEmits, reactive ref(), and other variables. This is idiomatic Vue 3 by design, enabling cleaner logic and better type inference with TypeScript.
Vue's recommends <script setup> for Vue 3 and Nuxt 3.
The below component clearly shows the use of composition API which was used in every single vue component in the codebase with typescript.
Lesson: Always verify the reviewer’s technical context before accepting their conclusions.
2. Project Architecture
Reviewer’s Claim: “No project architecture”
Reality: The project follows Nuxt 3’s opinionated file-based architecture, which is industry-standard and recommended in the official documentation. The structure includes:
- components/, composables/, stores/, utils/, types/, pages/, and server/
- Type safety with TypeScript
- Organized assets and server logic
Calling this “no architecture” is, frankly, misleading.
This structure aligns perfectly with and scales well for large applications.
Approach Hint: Embrace framework conventions to streamline setup and reduce boilerplate.
3. Code Repetitiveness
Reviewer’s Claim: “Code repetitiveness”
Reality: I built reusable components to avoid duplication wherever practical. Any repetition, such as Tailwind utility classes or minimal logic blocks, is contextually appropriate and does not constitute a flaw without concrete examples.
Hint at Organization: Group similar UI elements into shared components; use design tokens or helper functions for common patterns.
4. Card Persistence (LocalStorage)
Reviewer’s Claim: “No cards storing (local storage)”
Reality: The assignment’s Technical Requirements specified using the Composition API and Pinia for state management; it did not mandate data persistence. I implemented every requested feature; UI interactions, CRUD workflows, and design fidelity. If localStorage persistence was expected, it should have been explicitly outlined.
Using localStorage would be a reasonable enhancement, but the task did not explicitly require persistence. The Technical Requirements section clearly mentions using the Composition API and Pinia store, both of which were implemented. The task primarily focused on UI functionality, the CRUD workflow, and accurate design implementation, all of which were completed. If persistence was an expectation, it should have been clearly stated in the task description.
5. Design Fidelity
Reviewer’s Claim: “Not following Figma design”
Reality: I matched structure, colors, spacing, and typography to the Figma mockups. Minor pixel adjustments may vary across environments, but no significant deviations occurred. All UI screenshots that were attached to the feedback were basic to fix and the feedback got me wondering what the use of 'code-review before merging to main' is for?
How on earth could a good reviewer point out inline padding on a closely implemented button that functions perfectly as a flaw, while ignoring everything else; pixel-perfect UIs, 100% functional implementation, ~100% performance, accessibility, SEO, best practices, speed, and animations? I mean, just look at what the reviewer is pointing out:
Not a single review mentions key functionalities, performance, Git branching and commit messages, best practices, or the cool transitions shown below.
Scored ~100/100 scores on both Lighthouse and PageSpeed performance, accessibility, best practices, and SEO:
Git branching and commit messages best practice:
I mean, look at the performance stats, near-perfect Core Web Vitals, optimised asset loading, and a responsive, accessible layout. Yet the review chose to ignore all of that and instead pointed out something like button padding as a flaw.
It’s critical to understand that web development is far more than what you see on the surface. Good reviews go beyond static visuals and evaluate architecture, performance, maintainability, and user experience holistically.
Tip for Collaboration: If you spot a potential mismatch, always provide annotated screenshots, clear examples, or Git-style code review comments referencing the specific line or component, it saves everyone time and confusion. Also, know the weight of what you're pointing out. A slight inline padding difference is not a breaking change and should be treated as a minor refinement, not a critical flaw. Context matters when reviewing work, not all mismatches are created equal.
6. Bugs
Reviewer’s Claim: “Bugs”
Reality: The only minor issue involved checkbox selection logic, a trivial fix by targeting checkboxes via unique IDs. Moreover, displaying a fallback message when a card ID doesn’t exist is a deliberate, user-friendly enhancement, not a defect.
Best Practice: Provide meaningful defaults for nonexistent data to avoid blank screens.
Takeaways & Moving Forward
- Verify feedback with examples: Vague criticisms aren’t actionable.
- Leverage framework conventions for rapid, maintainable development.
- Communicate clearly about expected features vs. nice-to-haves.
- Embrace constructive critique while standing by correct implementations.
When a senior engineer affirms your strength, it’s a reminder to trust your expertise and seek reviewers who understand the technologies you use. Stay confident, keep learning, and always aim for clarity in both code and communication.
Thank you for reading this part of my story-turned-article. What are your thoughts on my experience?
Let’s keep building amazing things and expanding our skills.
Have any gig, offer, or questions for me? You can always hit me up.
,
Full-Stack Engineer | Frontend Specialist