Back to .md Directory

Recruiter Review Guide

Guides a five-minute technical skim of Chatify, pointing reviewers to backend engineering evidence and proof commands.

May 2, 2026
0 downloads
0 views
ai rag workflow
View source

What this file does

Guides a five-minute technical skim of Chatify, pointing reviewers to backend engineering evidence and proof commands.

When to use it

  • Preparing for a technical interview or code review
  • Evaluating a candidate's backend project quickly
  • Writing a similar review guide for your own repo
  • Understanding how to present engineering signals to reviewers

Assumes this stack

RustSQLiteWebSocketGitHub ActionsPowerShell

Recruiter Review Guide

This guide is for a five-minute technical skim of Chatify. It points reviewers toward evidence of backend/systems engineering rather than asking them to read the whole repository.

First 60 Seconds

  1. Start with README.md and the dashboard screenshot.
  2. Check the CI, release packaging, and release security report badges.
  3. Open docs/ENGINEERING_CASE_STUDY.md for the design tradeoffs.

What to notice:

  • Async Rust service and terminal client.
  • WebSocket protocol with contract tests.
  • Append-only SQLite persistence.
  • Explicit trust model and scoped security claims.

Proof Commands

The main quality gate is:

cargo check --workspace --bins --locked
cargo fmt --all --check
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
cargo test --workspace --all-targets --locked

Protocol contracts are called out separately because they protect the client/server message shape:

cargo test --locked --test message_contracts auth_contract_returns_expected_fields
cargo test --locked --test message_contracts compatibility_contract_client_bootstrap_flow_stays_stable
cargo test --locked --test message_contracts protocol_contract_advertises_backward_compatible_version
cargo test --locked --test message_contracts file_contract_relays_media_metadata_and_chunks

Demo Path

For a local walkthrough, use docs/DEMO.md:

.\scripts\demo-local.ps1

The demo uses a temporary database/key and prints exact client commands for a two-terminal review.

Engineering Signals

  • tests/message_contracts.rs: protocol compatibility, auth, media, history/search, schema, and replay coverage.
  • .github/workflows/ci.yml: locked workspace checks, contract gates, and feature-gated builds.
  • .github/workflows/windows-release-package.yml: packaged release artifacts with checksum validation.
  • docs/BENCHMARKS.md: reproducible 100k-event history/search latency baseline.
  • SECURITY.md and docs/SECURITY_NOTES.md: honest scope boundaries instead of inflated security claims.

Good Interview Questions

  • Why use append-only SQLite instead of mutable row state?
  • Why keep media on the WebSocket protocol instead of using HTTP uploads?
  • What breaks if protocol contracts are not tested separately?
  • What would need to change before this could serve a large multi-tenant deployment?
  • How would you harden the trust model before hostile-network production use?

What's inside

5 sections: first 60 seconds, proof commands, demo path, engineering signals, interview questions. Includes 4 code blocks and 5 questions.

Change this for your project

  • Replace Chatify with your project name
  • Replace kill74/Chatify with your repository path
  • Replace docs/ENGINEERING_CASE_STUDY.md with your case study path
  • Replace scripts/demo-local.ps1 with your demo script path

Where it goes

Keep it in your repository where the agent or team that needs it will read it.

Worth borrowing

  • Organize review by time-boxed sections (60 seconds, proof commands, demo)
  • List specific test commands as proof of quality gates
  • Include interview questions that probe design tradeoffs

Related Documents