Video summary

Do's and Don'ts of Take Home Assignment

Main summary

Key takeaways

Educational

Main ideas / lessons from the video

  • Purpose of the video

    • Help interview candidates improve how they approach and submit take-home assignments/coding challenges.
    • Emphasizes that well-structured submissions can increase the chance of being shortlisted.

  • Use a real example

    • The creator walks through a real take-home assignment they received from a company and explains how they solved it.

  • Make your submission impressive and easy to evaluate

    • Focus on both code quality and presentation/operability so the reviewer can install and run it quickly.

Methodology / checklist for take-home assignment submission

1) Project packaging + documentation (GitHub + README)

  • Create a dedicated GitHub repository for the assignment.
  • Write a high-quality README that includes:
    • What the submission is (what the codebase does, what the app is for).
    • A demo to show functionality:
      • Add a screen recording video in/linked from the README to save reviewer time.
    • Tech stack / tooling:
      • Mention frameworks and libraries used.
    • Step-by-step setup instructions:
      • How to clone the repo.
      • How to install dependencies.
      • How to compile/build the app (including multiple modules).
      • How to run in different modes:
        • Production run
        • Dev mode run
      • How to run tests (unit tests) if applicable.
  • Provide instructions from the reviewer’s mindset:
    • Assume the reviewer knows nothing and should still be able to run it.

2) Avoid installation/run blockers

  • Installation failure on the reviewer’s machine is treated as a major blocker and harms first impressions.
  • Two recommended strategies:
    • Ensure submissions are cross-platform compatible using runnable scripts and consistent instructions.
    • Preferably dockerize:
      • Provide a Docker image + instructions to run it.
      • Claimed benefit: the reviewer doesn’t worry about Windows/macOS/Linux differences.

3) Understand typical assignment ambiguity

  • Take-home tasks are often high-level/vague:
    • Usually no strict requirement for language/framework.
    • The creator notes that sometimes helpful technical guidelines are provided.
  • Example guidance mentioned:
    • You can use any library for implementation.
    • UI design is up to you.
    • Focus on the create/update flows, not building an execution engine.

4) System design: separate frontend and backend

  • Structure the codebase to be modular and responsibility-driven:
    • Keep frontend and backend as separate packages/directories.
    • Make them standalone projects.
  • Example structure described:
    • Backend: “KPI service” using TypeScript + Node.js
    • Frontend: “KPI builder” using React (chosen because the company uses React)

5) Choose frameworks based on company context

  • Research the company’s tech stack and match it when possible:
    • If the company uses React, use React for the frontend.

6) Configuration and dependency hygiene

  • Pay attention to build/compiler configuration:
    • Example emphasized: TypeScript tsconfig settings (composite, target, build file, etc.).
  • Add dependencies thoughtfully:
    • Don’t blindly install libraries.
    • Consider whether a lighter solution exists for the use case.

7) Linting and testing

  • Use linting to keep code clean and catch issues:
    • Example issue: “imported but never used.”
  • Add tests to improve confidence and reviewer impression:
    • Unit tests are not mandatory in all submissions,
    • but writing tests/test cases improves perceived quality and reduces bug risk.

8) State management and frontend organization

  • Use a state management approach/library as appropriate (creator mentions React + an “X” store approach).
  • Organize frontend code into folders such as:
    • components
    • stores (state management logic)
    • test (tests)

9) Environment variables (no hardcoded credentials/config)

  • Do not hardcode credentials or backend URLs
    • Use environment variables (e.g., .env).
    • Benefit: can change endpoints/config without rebuilding.

10) Use a good package manager + monorepo/workspaces approach

  • The creator emphasizes: “use your package manager wisely.”
  • Example: use Yarn workspaces with multiple workspaces:
    • frontend (kpi builder)
    • backend (kpi service)
    • shared library (kpi library)
  • Claimed benefit:
    • Share/symlink node_modules instead of duplicating them in each workspace.
    • Keeps the project less bloated and saves space.

11) Backend API design + OpenAPI/Swagger

  • Provide an OpenAPI (Swagger) specification for the API.
  • Use Swagger UI to make endpoints clear:
    • Define paths and HTTP methods (GET/POST/PUT/DELETE).
    • Specify request/response formats.
    • Include expected status codes and meanings, e.g.:
      • 204 for deleted
      • 404 for not found
      • 200/500 as applicable
    • Define schemas for objects (e.g., KPI object fields).
  • Backend structure recommended:
    • Routes → entry points
    • Controllers → business logic

12) Type reuse via shared library

  • Create a shared library for common types between frontend and backend.
  • Example rationale:
    • KPI-related types are common (same object/entity shape across FE/BE).
    • Centralizing types makes changes easier and more “future proof.”
  • Example distribution approach described:
    • Compile shared library outputs into dist (JS + type definition artifacts).

13) Local linking of custom libraries

  • The creator links workspace libraries so they can import the shared library without publishing to npm:
    • Mentions using npm linking to link the library into frontend/backend by name.
  • Claimed advantage:
    • Avoid hosting on npm registry or setting up a private registry.

14) Docker + scripting to simplify usage

  • Dockerization is presented as a strong plus for reviewer convenience.
  • Notes mentioned:
    • Some port variables might be hardcoded in the Dockerfile, but reducing hardcoded values is encouraged.
    • Create a small bash script to simplify complex docker build commands (pass only needed arguments/flags).

15) Note about yarn link issue

  • The creator reports a specific tooling outcome:
    • They tried yarn link but experienced issues.
    • They reverted to npm link despite using Yarn overall.

Assignment: what the app needed to do (as described)

  • Build a KPI builder prototype with CRUD-style operations:
    • List, create, and edit KPIs.
  • KPI concept includes:
    • KPI has a name
    • Two distinct steps:
      • Computation conditioning
      • Computation aggregation
  • Aggregation examples mentioned:
    • median, average, integration, sum (as possible mathematical operations).
  • Provided guidance:
    • UI design is flexible.
    • Don’t build an execution engine beyond the prototype requirements.
  • Data persistence:
    • The assignment states you don’t need a database.
    • In-memory or file-based storage is acceptable.
    • The creator contrasts this with a prior assignment where a database was required (and encourages databases when not prohibited, though not required here).

Speakers / sources featured

  • Speaker/creator: the YouTube channel host (referenced indirectly through phrases like “hello guys…”, “I myself…”, “I’m happing/wro…”).
  • Other named speakers/sources/organizations: none explicitly identified.
  • Tools/technologies mentioned: Docker, React, Node.js, TypeScript, Swagger/OpenAPI.

Original video