[jeff_jefferson]

I think you've just failed that part of the test. If you've got more than an extremely simple project there are multiple point s where you should commit.

If you implement a piece of logic with passing tests, then commit. It takes seconds to do but makes reviewing so much easier.

[gozzoo]

Or the company failed to attract the most suitable people for the job.

As I said - I don't see a reason for multiple commits for a few hours project. It is not how people start a new project. This is an exploratory phase, you check this, test that. Very often it becomes a mess. Eventually your idea of the project gets clearer, then you clean the code, or start again from scratch. I don't see why these steps need to be persisted.

This has been my experience each time I've started a new project, unless it is something very trivial, where you just follow the steps from the tutorial. If that's the case though I don't see the value of such assignment.

Conversely, if it is a few days or a week project you shouldn't expect experienced developers to take you seriously. This has been discussed multiple times here on HN and most poeple don't like it. People have lives, they probably have applied to multiple companies and it's just not possible for them to invest that much time.

In both cases the company misses the chance to meet potentially bright and hard-working people, which should be the purpose of the whole thing.

There is something else - what commit messages should look like is a very controversial topic. Introducing a chance for a strong disagreement on such an early stage of getting to know a candidate is not very wise.

[jeff_jefferson]

By specifically mentioning this, I would imagine it is something that is important to them. Therefore, somebody who doesn't agree with this way of working is not "suitable". In my experience, hiring people (however good) who do not agree with the company's core practices doesn't end well for either of them.

Unless it is something completely new to me and I am basically "playing with the tech" (which this does not seem to be) this is exactly how I would start the project. I find it easier to be organised from the start. Especially if, when I do take a wrong turn, I can revert easily to a previous commit.

[gozzoo]

> Therefore, somebody who doesn't agree with this way of working is not "suitable"

Agreeing with how one should work when employed is very different from agreeing with some nonsense during the application process. And in my opinion test assignment which take days to be done is definitely nonsense.

Expecting applicants to follow a process that has been adopted in a company, which took possibly years to get established is very naive. Of course if they get hired they should comply with the company policies and make their best to fit in with the culture, but how can some arbitrary requirement help evaluate their abilities.

People involved in hiring sometimes forget that this process is a two-way street. Applicants can also have expectations, requirements and questions. They are also entitled to disagree. Being themselves in a process of selecting the best company to work for, they can have their own opinion about how this should happen. I'm not sure if is a good policy for a company to hire the most agreeable candidates, willing to follow without objection any rule or order.

Most good engineers I've worked with are not like that at all.

[twic]

I get the impression that the project here is not one that calls for exploration - "a simple note-taking app with a couple of screens". You can use a tech stack you already know well, the entity model is pretty obvious, you should be able to sit down and mostly just smash it out. You can make lots of little commits while doing that.

I have had interview projects that were much more open-ended and exploratory, and there, i would not expect to be cranking out neat atomic commits. But i don't think that's what they are doing here.