I just read half of the article and this is painful to read. They’re asking for something relative simple as a take home, that just requires a little bit of imagination to fill the gaps. Why does the candidate have to be so fussy about details? Do the best you can, fast, and don’t announce you’re gonna be 2 days late for a take home!
To work in a startup you have to embrace the "just do it" mindset, you have a brain to fill the gaps, and you can always iterate later. I’d be more interested in getting the result of the take home quickly, obviously in a working state, but with a documentation explaining trade offs because of lack of time, ideas for future improvements, design choices, stuff not included (ie. a pretty UI) etc.
My take: they’re literally asking for a CRUD (if you decouple well, you can easily replace the DB with SMTP/IMAP later) with basic email features: send (to, cc, bcc), fetch, reply, reply all, transfer. That’s it, you can do it in 2 hours. Add folders, signatures, "send later", authentication, or whatever if you want to show off.
--
Additionally as an experimented Go developer (8 years working with Go as my main language), the code is not great and tbh I would have rejected it if I received this technical test where I work.
In 5 minutes of reading the code:
- lots of commented out test stuff, don't leave that in a take home or I'm gonna assume you'll do the same in your commits
- lots of println but no logging
- relative imports (eg "mymail/app/router"), don't do this
- weird choice of relatively big dependencies (turso? pocketbase? negroni?)
- no architecture or decoupling, everything is in the router
- bad use of the context (getEmails)
- no tests (no need to test everything for a take home but at least some things can be tested)
People say languages are interchangeable and you're never a "xxx" dev, but that's not true. They asked for "Proficiency in Go" and the candidate is not proficient in Go, that would be the number 1 reason for rejection.
To work in a startup you have to embrace the "just do it" mindset, you have a brain to fill the gaps, and you can always iterate later. I’d be more interested in getting the result of the take home quickly, obviously in a working state, but with a documentation explaining trade offs because of lack of time, ideas for future improvements, design choices, stuff not included (ie. a pretty UI) etc.
My take: they’re literally asking for a CRUD (if you decouple well, you can easily replace the DB with SMTP/IMAP later) with basic email features: send (to, cc, bcc), fetch, reply, reply all, transfer. That’s it, you can do it in 2 hours. Add folders, signatures, "send later", authentication, or whatever if you want to show off.
--
Additionally as an experimented Go developer (8 years working with Go as my main language), the code is not great and tbh I would have rejected it if I received this technical test where I work.
In 5 minutes of reading the code:
- lots of commented out test stuff, don't leave that in a take home or I'm gonna assume you'll do the same in your commits
- lots of println but no logging
- relative imports (eg "mymail/app/router"), don't do this
- weird choice of relatively big dependencies (turso? pocketbase? negroni?)
- no architecture or decoupling, everything is in the router
- bad use of the context (getEmails)
- no tests (no need to test everything for a take home but at least some things can be tested)
People say languages are interchangeable and you're never a "xxx" dev, but that's not true. They asked for "Proficiency in Go" and the candidate is not proficient in Go, that would be the number 1 reason for rejection.