Hoot-Hoot

Inspiration

────────────────────────────────────────────

I sat one of these cognitive aptitude rounds myself during campus placements.

I had no idea what Switch Challenge or Grid Challenge even was before I walked into that test. I had prepared everything else — DSA, HR questions, aptitude math — but nobody told me there was going to be an entire round of interactive brain games that I had never practiced before.

I got through it, but I watched a lot of my friends get filtered out in that round. Not because they were not smart. Because they had never seen that format before.

That bothered me. I looked for platforms where students could actually practice these game formats interactively, for free, the way they would experience them in a real placement round. There was almost nothing good available.

And on the other side, companies face their own problem — sourcing a proper platform to conduct these cognitive assessments with real proctoring, invite management, and results analytics is expensive and fragmented. Most companies are patching together multiple tools.

That is what inspired Hoot-Hoot. Solve both sides at once. Free practice for students. A complete assessment tool for companies. One platform.

────────────────────────────────────────────

What it does

────────────────────────────────────────────

Hoot-Hoot is a cognitive games platform with two sides.

For students: The Practice Arena gives students free access to ten original cognitive games that mirror the exact formats used in real placement aptitude rounds — Switch Challenge, Grid Recall, Shape Sudoku, Pattern Rule, Cave Run, and more. Each game tests a specific cognitive skill: visual reasoning, working memory, deductive logic, inductive pattern recognition, spatial planning.

Games are scored using a level-squared formula divided by time — the same scoring logic real corporate assessments use. Reaching deeper levels quickly earns more points. Speed and accuracy both matter.

After every game, students see their score, their rank on the global leaderboard, and a breakdown of which skills they are strong and weak in. The leaderboard is live, pulled from Aurora PostgreSQL in real time, with DynamoDB handling the high-frequency caching layer.

For companies: The Company Portal lets HR teams build custom cognitive assessments from our question bank, configure proctoring rules, and invite candidates by email or bulk CSV — all in one place.

During a candidate's test, the Proctor Engine enforces full-screen mode, monitors tab switches and window blur events, and runs face detection via the camera. Every violation is logged with a timestamp. After three warnings, the session auto-submits.

Companies review results in a dashboard showing score distributions, percentile rankings, time per question, and a full violation timeline for any flagged candidate. A human makes the final decision — the platform never auto-rejects anyone.

The AWS status page at /aws shows live Aurora cluster health, DynamoDB table stats, index counts, and API latency — proving both databases are connected and running in production.

────────────────────────────────────────────

How we built it

────────────────────────────────────────────

Frontend: Next.js 16 with the App Router, TypeScript, Tailwind CSS 4, and shadcn/ui. Deployed on Vercel with edge CDN handling static assets globally. The UI uses Framer Motion for game animations and React Three Fiber for 3D elements.

Backend: Next.js Server Actions and API Route Handlers running as Vercel serverless functions. All business logic — game scoring, proctoring, leaderboards, test management — lives in the server layer, never exposed to the client.

Primary database — AWS Aurora PostgreSQL: 16 tables, 42 indexes. Handles everything relational: user accounts, sessions, game scores, company tests, test sessions, proctoring logs, and a test_analytics VIEW that gives companies live aggregated stats per assessment without needing a separate analytics service. Authentication uses AWS IAM via Vercel OIDC federation and RDS Signer — short-lived 15-minute tokens, no passwords in environment variables.

Secondary database — Amazon DynamoDB: Single-table design for all key-value access patterns. Handles session token validation on every page load, leaderboard caching with a 5-minute TTL, and per-game score lookups. The specific reason for DynamoDB: Vercel serverless means every cold start would add 80–200ms just establishing a pg connection pool. DynamoDB uses stateless HTTPS — no pool, no cold start penalty, sub-millisecond reads.

Auth: Custom email/password auth using scrypt hashing (N=2^15, 64-byte salt, 64-byte output). HttpOnly, Secure, SameSite=Strict session cookies. No third-party auth service dependency.

AI: Google Gemini powers an in-app chat assistant that gives students hints and strategy tips for each game.

Proctoring: Browser-native — fullscreen API, visibilitychange event, window blur, and MediaPipe face detection running fully client-side. No video streams to the server unless a violation is logged.

Schema migrations run automatically on every Vercel cold start via instrumentation.ts using IF NOT EXISTS statements — safe to run repeatedly, zero manual deployment steps for DB changes.

────────────────────────────────────────────

Challenges we ran into

────────────────────────────────────────────

The cold start problem was real. Aurora PostgreSQL and serverless functions do not naturally go well together. Establishing a pg connection pool on a cold start added significant latency to every first request. The solution was intentional: move all high-frequency read patterns — session validation, leaderboard lookups, score caching — to DynamoDB. This split the architecture into two purposeful layers rather than making DynamoDB feel like an add-on.

IAM authentication without passwords. Setting up Vercel OIDC federation with AWS, using the VERCEL_OIDC_TOKEN to exchange for short-lived AWS credentials at runtime, and configuring the RDS Signer to generate 15-minute Aurora tokens — all of this with zero plaintext credentials anywhere in environment variables — took real trial and error to get right. But it works properly now and it's the right way to do it.

Building real game logic, not just quiz questions. Implementing the Switch Challenge transformation pipeline, the Shape Sudoku constraint solver, and the Grid Recall interference task as genuinely interactive, level-adaptive experiences — not just static MCQ wrappers — was significantly more engineering work than expected. Each game needed its own state machine, difficulty scaling logic, and score calculation pipeline.

Proctoring edge cases. Browsers deliberately do not let you prevent a user from exiting full-screen — that is a security feature, not a bug. Building an honest proctoring system that detects and logs violations rather than falsely claiming to prevent them, and making sure the warning system was fair and not overly aggressive on legitimate behaviour like a screen dimming, required careful calibration.

────────────────────────────────────────────

Accomplishments that we're proud of

────────────────────────────────────────────

The architecture actually makes sense. The two databases are not there to check a box — each one is doing exactly what it is best at. Aurora handles the relational complexity; DynamoDB handles the serverless-hostile read patterns. That decision is defensible in one sentence and we can prove it with latency numbers.

The proctoring system is honest. A lot of platforms market "cheat-proof" proctoring that is technically impossible from a browser. Ours detects, logs, warns, and escalates — but always with a human making the final call. That is the right design.

The scoring formula — level squared divided by time — actually creates real competitive dynamics on the leaderboard. Watching students try to push for deeper levels fast rather than grinding level one safely is satisfying to see.

Zero passwords in environment variables. The full IAM OIDC setup with auto-rotating tokens on both Aurora and DynamoDB is production-grade security, not hackathon-grade.

The /aws live status page. Judges can see both databases connected and running in real time without needing access to anything private.

────────────────────────────────────────────

What we learned

────────────────────────────────────────────

Using two databases is only a good idea if you are honest with yourself about why. If both access patterns are the same, you do not need two databases — you just have unnecessary complexity. The split only makes sense when the access patterns are genuinely different. For Hoot-Hoot they are: relational joins and analytics on one side, stateless high-frequency key-value reads on the other.

IAM token authentication for databases is genuinely better than password-based auth, and not as hard to set up as it looks once you understand the Vercel OIDC flow.

Building game logic for cognitive tests is harder than building CRUD — every game is essentially a real-time state machine with adaptive difficulty, constraint solving, and a timer, all running in React.

Proctoring in a browser has real, hard limits. Being honest about those limits and designing around them — detect and escalate rather than falsely prevent — makes for a more trustworthy product.

────────────────────────────────────────────

What's next for Hoot-Hoot

────────────────────────────────────────────

More cognitive games. We have ten games live. The target is twenty-four — matching the full range of game types real corporate assessments use.

English communication module. Repeat Sentence, Read Aloud, Describe Image — the PTE and IELTS-style speaking tasks that show up in communication rounds. This requires integrating a speech scoring API (SpeechAce or Azure AI Speech) and a recording interface with waveform feedback.

Multi-region with Aurora DSQL. The next genuine infrastructure upgrade is moving to Aurora DSQL for active-active multi-region writes. The specific use case: preventing a candidate from opening the same test session from two devices or two locations simultaneously — something that requires strongly consistent distributed writes, which is exactly what DSQL is designed for.

Company analytics. Deeper cohort analysis — score trends over time, per-game performance breakdowns, candidate comparison views, exportable PDF reports.

Behavioral assessment module. Situational judgment questions and Big Five personality mapping for companies that want to assess beyond cognitive ability.