From 4d12b552bcc64dff884c5384643e5e37dba81361 Mon Sep 17 00:00:00 2001 From: Richard George Date: Mon, 23 Mar 2026 15:01:09 +0000 Subject: [PATCH 1/2] docs: refresh assessment and contributor guidance --- .github/pull_request_template.md | 15 +++++ README.md | 59 ++++++++++++++----- contributing-docs/docs/architecture.md | 11 +++- .../docs/testing-and-validation.md | 3 +- 4 files changed, 70 insertions(+), 18 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index e8bb680..6989cf8 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,3 +1,7 @@ +This pull request template is part of the technical assessment. It is used to evaluate both the quality of the solution and how you approached the work. + +Do not reveal your identity in this PR. Candidates must use an anonymous GitHub account for the exercise. + ## Acceptance Criteria Coverage Describe which issue acceptance criteria you believe are: @@ -45,6 +49,8 @@ Example: Include prompts that helped you understand the problem space, shape the implementation, or validate the result. This can include exploratory questions such as terminology, architecture, or workflow clarification. +Prefer the prompts that materially changed your understanding, plan, implementation, or validation strategy. + Do not include assistant responses in this section. If an assistant response was wrong in an important way, describe it in `AI Mistakes And Corrections` instead. Do not include secrets, tokens, or irrelevant prompts that had no bearing on your final work. @@ -73,6 +79,14 @@ Example: I started from a UI issue but found that the graph API schema was missing the fields required to render the new state reliably. I chose to fix the API contract first because it unblocked both the web client and the SDK and produced a cleaner validation path. +## Limitations And Deferred Work +Document any important limitations, edge cases, tradeoffs, follow-up ideas, or improvements you noticed but did not address. + +Example: + + The happy path is covered by tests, but I did not add concurrency coverage for overlapping sync operations. + The UI now supports manual reconnect, but error copy and recovery states could still be improved. + ## Candidate Checklist - [ ] I explained which issue acceptance criteria were completed, partially completed, or not completed. - [ ] I validated the change with tests and/or manual checks. @@ -80,3 +94,4 @@ Example: - [ ] I documented any important assistant mistakes and how I corrected them. - [ ] If I changed direction, I explained why. - [ ] I documented any limitations, deferred work, edge cases, or improvements I noticed but did not address. +- [ ] I did not reveal my identity in this PR. diff --git a/README.md b/README.md index 775e24d..e7a33af 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,17 @@ # Move37 +## Technical Assessment + +This repository is used as an AI-augmented technical assessment for software engineers. + +The goal is not to measure who can hand-code the fastest. The goal is to understand how a candidate approaches a real engineering problem in a realistic environment: how they break down the task, how they use coding agents, how they evaluate AI output, how they validate the result, and how they communicate tradeoffs and decisions. + +Candidates are expected to work on a bounded GitHub issue, use AI assistance as part of their workflow, and submit a pull request that shows both the outcome and the thinking behind it. We are looking for strong systems thinking, sound engineering judgment, and the ability to partner effectively with modern tools. + +This assessment is intentionally run in a public GitHub repository because it better reflects day-to-day software engineering than a puzzle or whiteboard exercise. It lets candidates work in a native environment with real issues, real constraints, and real review artifacts. + +If you are completing this exercise, start by reading the section called `The Exercise` below. If you want to understand the product and the technical landscape first, the rest of this README introduces Move37 and its current state. + **Move37 is a personal planning system built around self-knowledge.** We are not always the best at estimating how long things take to be completed — this is not only due to unforeseen circumstances, but also because we do not know our own behaviour well enough: what drains us, what motivates us, what our real pace is versus our optimistic one. @@ -19,35 +31,50 @@ The system is AI-native: every piece of information becomes something an agent c ## Current State -The web UI is in good shape. The backend is partially wired. Several core capabilities are still under active development: +Move37 already has a meaningful system shape. The repository contains a React web app, a FastAPI backend, a JavaScript SDK, an internal AI service for semantic search and grounded chat, a notes worker, and deployment scaffolding. If you want the technical overview, see the [architecture guide](./contributing-docs/docs/architecture.md). -- **Apple Calendar sync** — the integration exists but is not yet fully connected end to end -- **Scheduling engine** — the logic for reasoning about dependencies, timing, and estimated completion is not yet implemented -- **OpenBanking** — financial behaviour data is not yet ingested or connected -- **Note embeddings** — personal reflections are not yet embedded for semantic search +Several important capabilities are present in early form and are still being hardened end to end: -These are the areas where the product has the most ground to cover, and where the most interesting contributions live. +- **Apple Calendar sync**: account management, sync, and reconciliation flows exist, but the full user journey still needs validation, polish, and stronger end to end coverage +- **Scheduling engine**: there is a deterministic dependency-aware planning baseline today, but the richer scheduling logic is still to come +- **OpenBanking**: financial behaviour data is not yet ingested or connected +- **Notes, embeddings, and semantic retrieval**: notes CRUD, import, search, and grounded chat are wired, but the ingestion and retrieval path is still maturing operationally + +Many features can be explored with the core web and API stack alone, but some paths, especially note retrieval and grounded chat, depend on the internal AI service, the notes worker, and supporting infrastructure being available locally. + +These are the areas where the product has the most ground to cover, and where many of the most interesting contributions live. --- ## The Exercise -This repository is used as a hiring exercise for Roche gRED software engineers. +This exercise is designed to reflect how software engineering is increasingly practiced in an AI-augmented environment. + +You are not being assessed on whether you hand-write every line of code yourself. You are being assessed on how you approach a bounded engineering problem in a real repository: how you understand the system, how you choose scope, how you work with coding agents, how you validate what they produce, and how you communicate the quality and limitations of the final result. + +In practical terms, the exercise is simple: + +1. Choose an open GitHub issue that interests you +2. Work it through end to end in your own fork +3. Use coding agents as part of your workflow where helpful +4. Submit a pull request that shows both the outcome and the reasoning behind it + +We are particularly interested in signals such as: -Browse the [open issues](https://github.com/Genentech/Move37/issues) and pick one that interests you. There is no obligation to pick the smallest one — a more ambitious issue will make for a more interesting conversation. +- how well you understand the architectural intent of an existing system +- how effectively you break work into safe, testable steps +- how thoughtfully you prompt, review, and correct AI-generated output +- how well you validate behavior rather than assuming it is correct +- how clearly you explain tradeoffs, limitations, and next steps -**Steps:** +This is why the exercise runs in a public GitHub repository rather than as a puzzle or whiteboard task. It gives you a native environment with realistic constraints, existing code, issue threads, and review artifacts. That setting gives us a better signal of engineering judgment than a synthetic interview problem. -1. Fork this repository **anonymously** (disclosing your identity to the reviewers will automatically disqualify you) -2. Pick a GitHub issue or several and work on them end to end -3. Use coding agents as part of your workflow — this is expected and encouraged -4. Open a pull request against this repository -5. Follow the submission guide in `.github/pull_request_template.md` +Anonymity is a hard requirement. Please use an anonymous GitHub account for your fork and pull request. Revealing your identity to reviewers will automatically disqualify the submission. -Each issue is designed to be completable in roughly 1–2 hours. You can use the issue thread to ask questions or discuss your approach with the hiring team. +The submission guide in `.github/pull_request_template.md` is part of the exercise. It asks you to document validation steps, prompt history, and important AI mistakes and corrections. Those are not extras. They are part of how we evaluate the work. --- ## Contributing -See `contributing-docs/` for setup details, environment variables, and service configuration. +See [`contributing-docs/`](./contributing-docs/) for setup details, environment variables, and service configuration. Start with `docs/intro.md`. diff --git a/contributing-docs/docs/architecture.md b/contributing-docs/docs/architecture.md index 9d9de11..a0ce4c8 100644 --- a/contributing-docs/docs/architecture.md +++ b/contributing-docs/docs/architecture.md @@ -25,7 +25,9 @@ Move37 is not a single process. It is a small system with a few important bounda `src/move37/services/container.py` wires the main runtime: - SQLAlchemy session factory +- `AppleCalendarSyncService` - `ActivityGraphService` +- `SchedulingService` - `NoteService` - `ChatSessionService` - `Move37AiClient` @@ -34,12 +36,19 @@ That last point matters: the main API does not answer note search or chat itself ## REST and MCP surfaces -REST routes currently cover four broad areas: +REST routes currently cover six broad areas: - auth - graph - notes - calendar +- integrations +- scheduling + +The calendar-related REST surface is split in two: + +- `/calendars/apple/*` covers event listing and reconciliation +- `/integrations/apple/*` covers account connection, status, and preferences MCP routes are exposed separately, and chat now lives there rather than in the browser or REST surface. If you change a service contract or persistence rule, think about both transports. diff --git a/contributing-docs/docs/testing-and-validation.md b/contributing-docs/docs/testing-and-validation.md index f5d6d18..00518e2 100644 --- a/contributing-docs/docs/testing-and-validation.md +++ b/contributing-docs/docs/testing-and-validation.md @@ -105,5 +105,6 @@ The desired repository ruleset in `devtools/config/move37.repo.toml` currently l - `python` - `sdk` - `web` +- `contributor-docs` -That means the contributor-docs build exists in CI, but it is not yet declared as a required status check in the repo bootstrap config. +That means contributor docs changes are part of the expected branch protection baseline, not just an optional CI signal. From 5d447f3ca54e51c291ebaebdb561ae345996d43e Mon Sep 17 00:00:00 2001 From: Richard George Date: Mon, 23 Mar 2026 15:27:55 +0000 Subject: [PATCH 2/2] docs: clarify anonymous fork workflow --- README.md | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index e7a33af..801a1e3 100644 --- a/README.md +++ b/README.md @@ -10,11 +10,17 @@ Candidates are expected to work on a bounded GitHub issue, use AI assistance as This assessment is intentionally run in a public GitHub repository because it better reflects day-to-day software engineering than a puzzle or whiteboard exercise. It lets candidates work in a native environment with real issues, real constraints, and real review artifacts. -If you are completing this exercise, start by reading the section called `The Exercise` below. If you want to understand the product and the technical landscape first, the rest of this README introduces Move37 and its current state. +**If you are completing this exercise, create an anonymous GitHub account and fork this repository before you start work. Do not use your normal GitHub identity or begin work from a non-anonymous clone. Revealing your identity to reviewers will automatically disqualify the submission.** + +Start by reading the section called `The Exercise` below. If you want to understand the product and the technical landscape first, the rest of this README introduces Move37 and its current state. + +## About Move37 **Move37 is a personal planning system built around self-knowledge.** -We are not always the best at estimating how long things take to be completed — this is not only due to unforeseen circumstances, but also because we do not know our own behaviour well enough: what drains us, what motivates us, what our real pace is versus our optimistic one. +The name Move37 is a reference to AlphaGo's famous move 37, an unexpected decision that changed how people thought about what AI could do. + +In the same way, we are not always the best at judging our own plans. This is not only due to unforeseen circumstances, but also because we do not know our own behaviour well enough: what drains us, what motivates us, and what our real pace is versus our optimistic one. Move37 brings together personal notes and reflections, calendar commitments, a history of calendar behaviour, and financial behaviour to help us understand our own patterns. Over time, it learns what "I'll finish this by Friday" actually means for each of us individually — and helps us plan accordingly. Used in a team, it turns that self-knowledge into better coordination and productivity. @@ -54,10 +60,11 @@ You are not being assessed on whether you hand-write every line of code yourself In practical terms, the exercise is simple: -1. Choose an open GitHub issue that interests you -2. Work it through end to end in your own fork -3. Use coding agents as part of your workflow where helpful -4. Submit a pull request that shows both the outcome and the reasoning behind it +1. Create an anonymous GitHub account and fork this repository before doing any work +2. Choose an open GitHub issue that interests you +3. Work it through end to end in your own fork +4. Use coding agents as part of your workflow where helpful +5. Submit a pull request that shows both the outcome and the reasoning behind it We are particularly interested in signals such as: @@ -69,7 +76,7 @@ We are particularly interested in signals such as: This is why the exercise runs in a public GitHub repository rather than as a puzzle or whiteboard task. It gives you a native environment with realistic constraints, existing code, issue threads, and review artifacts. That setting gives us a better signal of engineering judgment than a synthetic interview problem. -Anonymity is a hard requirement. Please use an anonymous GitHub account for your fork and pull request. Revealing your identity to reviewers will automatically disqualify the submission. +Anonymity is a hard requirement. Use an anonymous GitHub account for both the fork and the pull request, and set that up before you begin. Revealing your identity to reviewers will automatically disqualify the submission. The submission guide in `.github/pull_request_template.md` is part of the exercise. It asks you to document validation steps, prompt history, and important AI mistakes and corrections. Those are not extras. They are part of how we evaluate the work.