Took us about a week to write everything down the first time and then we continuously updated it until it reached the current state.
We had the advantage of being a "public by default" company, so there was no need for approvals of any sort.
> Why do you want to be at Obvious?
I never understood this. Unless you are Apple or Google or some other big brand, most likely people found your job through a job forum or even HN and never heard of you before. Then most likely the answer is money. So what is the point?
I just stopped filling up job applications that have this. Seems so counter productive. Heck, I was approached by a CTO of a Ycombinator company a while ago, he found my resume somewhere, asked me if I would be interested in the position, then redirected me to a form where 2-3 questions was about why I wanted to work with them, and what I would bring to their team. I want money, and in exchange I give you my time and knowledge. Is that so hard to understand?
I'm not saying that someone needs to be so desperate to work somewhere (that would probably be bad), but if a candidate can't express why they have an interest in a particular role then that's of note, especially if I'm comparing to someone who can. Pretty much everyone wants to exchange their time and knowledge for money, but they could do that anywhere, so why here?
From their website 'We help people create digital experiences their customers love.'
Has anyone been 6, day dreaming in school, 'when I grow up, I want to help people create digital experiences their customers love.'?
My interest in the role is it matches my experience and I want money. Again, if you are a FAANG, fine, if you are a startup no one really knows but pretend you are changing the world, you are making yourself a disservice by asking these questions. You can ask 'What are you looking in a new position/What excites you/etc', but to ask specifically why this company is tacky and I know I am not alone with this as I regularly talk with friends that feel the same.
Maybe I am jaded as a software developer with more than 20 years professional experience, but job=money so I can money=things/time I want. 99.9% of companies aren't changing the world. They are trying to make money for the owners/shareholders/investors, and employees should think exactly the same, and that is motivation enough.
If you paid a million dollars a month for people to dig holes for 8 hours a day, you would see the fastest shortage of shovels ever.
Beyond a threshold salary level, these intangible things matter much more than money since I am going to be spending every single day working on these things and with these people. I want to work with skilled technicians but I also want to be in alignment with my team.
I understand the "not changing the world" mindset but motivation is still a hugely important consideration when hiring and when choosing where to work. Every job has bad days/weeks/months and it takes motivation, beyond the paycheck, to hold myself and my team together through those moments.
Similar to your million dollar situation: If you paid high performing knowledge workers a million dollars a month to do soul-crushing stressful grind work in a bad environment, those people are still going to quit after a short period of time.
And you know this from a job post in a job board/website how?
This is what I mean. A no-name company can't say 'we want people to be motivated to work with us' when 99.99% of the world have no clue what they do/how they work.
If you are Uber, or Microsoft, 37 Signals, or even Doctors Without Borders you know in general their motives/how they work (from the 2389472309 blog posts). But 5 employee start ups? Or a consulting firm that does client work for companies you never heard from? Really?
> If you paid high performing knowledge workers a million dollars a month to do soul-crushing stressful grind work in a bad environment, those people are still going to quit after a short period of time
Maybe being from different country shows my bias, but even with a lot of friends in the USA, most don't change jobs for lower paid positions. There is even a term for it: 'Golden Handcuffs'
I don't need to know it from a job board or website because I don't apply to companies that I'm not already familiar with. When I apply to those listings, I already know how I will answer this question, because that's why I'm applying to the company.
> Has anyone been 6, day dreaming in school, 'when I grow up, I want to help people create digital experiences their customers love.'?
No but that's a strawman and I'd be surprised if you don't recognise that.
> My interest in the role is it matches my experience
I doubt that's the only reason. You could have experience doing a billion things but you probably enjoy what you do a lot more than that, and when we break it down, there are almost certainly subsections within what you do now that you enjoy and hope that the company aligns with that. When a listing asks "why are you interested in working here", you hopefully already know and can express that.
There are a large number of ways from location, culture, processes, technical decisions, people, problem domain, etc that you can discover about a company before applying.
> My interest in the role is it matches my experience
This is a great reason to want to work at a company.
"I specialize in X technology and I see that you use X technology as well and I believe my expertise in it can help your company solve problem Y, and in particular I'm looking to join a company of Z size because blahblahblah"
Yea you have to stretch it a little bit sometimes, but that's life. You don't get paid to write code, you get paid to solve human business problems using code, which comes with the baggage of dealing with humans.
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.
If you implement a piece of logic with passing tests, then commit. It takes seconds to do but makes reviewing so much easier.
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.
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.
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.
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.
Talk about exploitative. Hell, that's incredibly biased. Can you imagine a young parent being able to do that?
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!
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.
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!
> 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.
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?
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.