|
|
|
|
|
by vinaysshenoy
2185 days ago
|
|
The exercise itself is a simple note-taking app with a couple of screens. We don't impose a time limit on candidates interviewing to complete this stage. > For a new project there aren't any well defined states of the code that make sense to be persisted. This means the commits will be arbitrary and their messeages not very meaningful. I didn't understand this? The problem is well scoped and defined. Regardless of whether it's a new project or old, we expect candidates to be able to split their work as atomically as possible. |
|
One is to make disciplined incremental progress: write a test, make the test pass, do minimal cleanup, commit, see a refactoring opportunity, do it, commit, write another test, see a related bug, write the bug down but don't fix it, make the test pass, clean up, commit, tackle the bug, commit, etc.
The other is to flail about wildly until you have something which more or less works, and then commit it. Then make a few follow-up commits fixing bugs.
People who have only experienced the latter will find the idea of making numerous commits during the day absurd.