tejasbanginwar/ai-mock-interview-platform

1. System split: two runtime boundaries

- The repo is organized as a React/Vite frontend in InterviewAI/ and a Python/Flask backend in backend/.

- The frontend runs as a browser SPA; the backend is a separate local API service.

2. Frontend is the primary user-facing application

- src/main.tsx bootstraps the app, App.tsx and the pages/ directory define the route-level screens.

- Key screens are Home, Practice, Interview, Results, SignInPage, SignUpPage, plus NotFound.

3. Interview workflow is page-driven

- The likely user journey is: landing/sign-in → practice or interview session → results/feedback.

- ResumeUpload suggests the interview flow can be personalized by uploaded resume content.

- Navigation, NavLink, and ProtectedRoute indicate a routed app with some client-side access control.

4. Real-time webcam monitoring is a major frontend-to-backend data flow

- FaceDetectionVideo and useFaceDetection are the core bridge for camera-based monitoring.

- The browser captures webcam frames, converts them to image payloads, and sends them to the backend’s face-detection endpoint.

- This is the main cross-process interaction in the system.

5. Backend exposes a small ML-oriented API

- backend/app.py is the entry point and, per the docs, provides at least:

- GET /health

- POST /detect-faces

- The API receives base64 image data from the frontend and returns face-detection results for UI enforcement/feedback.

6. Computer-vision and model assets live behind the backend boundary

- The backend README and repo root assets point to MediaPipe and OpenCV for face monitoring.

- emotion_model_final.pth and emotion_classes.pkl indicate the backend also has an ML model layer for emotion-related inference, even though the exact route wiring is not visible from the tree.

- backend/answer_audio/ contains per-session UUID folders with question_###.wav files, suggesting persisted voice-answer artifacts for later processing or review.

7. Tab switching and page visibility are handled locally in the browser

- usePageVisibility and TabSwitchWarning implement anti-cheating / exam-proctoring behavior on the client.

- This is separate from face detection: it monitors browser state rather than camera input.

- ProtectedRoute likely keeps certain pages gated without relying on backend auth.

8. Audio/voice answer handling is represented as session artifacts

- The backend/answer_audio/.../*.wav files show that audio responses are stored by interview session ID.

- That implies a second analysis path besides face detection: voice answers can be captured, saved, and later used for scoring or review.

9. UI composition is modular and library-based

- The frontend uses a large components/ui/ set consistent with a shadcn/Radix-style component library.

- tailwind.config.ts, postcss.config.js, and src/index.css show styling is utility-first and centralized in the frontend.

- These libraries are presentation infrastructure, not core business logic.

10. Operational model is local-development oriented

- The documented default ports are 8080 for the frontend and 5000 for the backend.

- CORS is expected because the browser SPA talks to a separate API origin.

- The repo is designed for a dual-process developer setup rather than a monolithic deployment.

11. Architecture diagram takeaway

- Draw the browser SPA as the main interaction surface.

- Show three browser-side subsystems: routing/UI, webcam capture + tab monitoring, and local session handling.

- Show the Flask backend as a separate ML/vision service receiving image frames and persisting session audio artifacts.

- The strongest dependency arrows are: user → SPA, SPA → Flask API for face detection, and SPA-local monitoring for tab visibility/proctoring.