[gozzoo]

> We expect you to use git, commit code as you go along, and build the app iteratively -- just as you would during a normal workday.

This seems a little bit odd to me.

How long do you expect people to work on their home assigments in order for them to commit often? Is it days, or weeks? I don't imagine multiple commits for a 3 hour poject.

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.

[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.

[lnsru]

It is not expected to be 3 hours project. Target easily 3 days for it. Requirement to get more points for this assignment from that page: “Detailed documentation with setup, screenshots, configuration instructions, etc.” This alone might take couple hours.

[Dayshine]

You expect candidates to spend 20-30 hours on a task, and you don't even guarantee an interview?

Talk about exploitative. Hell, that's incredibly biased. Can you imagine a young parent being able to do that?

[milesvp]

Yeah, no kidding. If you’re not going to pay an hourly rate for a homework assignment, you are not getting particularly good applicants. No quality engineer will spend more than a couple hours at a chance to maybe have someone look at their code, to maybe offer them a job.

[raghava]

As I have said in a comment below, it sorta became a way to signal being hip-n-cool, while actually being totally otherwise.

Most cheapo shops which won't pay FAANG salaries but still want near-FAANG-quality-engineers end up using this as a bait.

Other ways are "your work has great purpose!" "You will advance humanity!" "You will bring great experiences to users" ... yeah yeah yeah, just an alias for "we are a glorified bodyshop. BigCos hire us for some piecemeal job. We get it done and get paid relatively well." But this isn't too appealing, is it!

[vinaysshenoy]

We did allow concessions for people who were not able to find time to do the exercise. We merged it with the pair programming exercise and asked them to build it with us in office.

[VBprogrammer]

Young parent here. Not a chance in hell I'd be taking part in that exercise. The only possible way would be to take a weeks holiday and that's just not going happen.

At least they are open about it. It is probably a fair indication of the companies values if they are oblivious to how unreasonable a 3 day take home assignment is.

[kyawzazaw]

Basecamp pays $1500 or so for take-home assignments. Do you offer similar compensation?

[raghava]

These shops mostly just want to appear hip-n-cool. They aren't really, hence, no pay.

It would most probably have a twisted answer as "you can post that solution of yours in your git repo and showcase it as a part of your portfolio"

Many shops out here are so adept at this stuff, it's no more funny!

[kyawzazaw]

I don't quite understand what you mean.

[vinaysshenoy]

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.

[twic]

There are two ways of working in programming.

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.

[Dayshine]

Sure, but I'm not sure how much progress you're going to make in the 2-3 hours one would spend on a speculative take-home task (they've stated there is no guaranteed interview).

You're going to be judged on how well the end product works, so if we start with the following tasks, and you have 180 minutes.

1. 20 minutes: their stack's boilerplate/tooling

2. 10 minutes: unit testing boilerplate

3. 20 minutes: integrated testing boilerplate (browser automation is a fickle beast)

4. 20 minutes: basic database entity + database setup

5. 20 minutes: basic UI page + frontend setup

6. 20 minutes: replace default styling (their guide talks about UI "polish")

That's 110 minutes and nothing more than a pretty display from the database.

The task will almost certainly ask for more than one user action. I might be able to write an action in 20 minutes, but there is no way I can write good tests, seed test data for integrated testing, and keep each commit atomic and green.

So, do you choose to have a tidy commit history and complete test coverage, or do you choose to complete the task?

[collyw]

"It should only take you 2 or 3 hours".

Estimates are almost always under.

As you point out the most basic project setup takes time. And I am working on a home laptop, not my work machine, so I don't have everything installed in the same way as I do for a work setup (that's usually at least a days work in itself on a new work machine).

Also it is not uncommon to find some strange issue that will take a couple of hours to fix if you are unfamiliar with it. Last technical test I had involved using Django's chache framework. I have used Django a lot, but not really used the cache in depth. I got everything working in the end and they failed me for the most trivial reasons.