Seemed like my last post sharing code exercise submissions helped a few people which is the main point of sharing these. Here's part two:
Repo: https://github.com/umaar/robots
Moved onto the interview stage
This solution for Red Badger allowed me to move onto the interview stage ✅️.
With the Red Badger code submission, they liked it! I took a loosely functional approach, and made sure to stick to the script. What I mean by that: while the solution is a command line app, it could've been fun to make a web interface which visualised the robot moving around - there are certainly other solutions on GitHub which do this.
Here's something I think worked well, normally when solving a slightly more 'involved' problem, I'll start with a quick experiment.js or something, just to play around, and see if I can solve the challenge without having to think about code quality. I figured there's no harm in sharing this with them, and if anything, it could help me since interviews almost always like to see how a candidate reached a solution.
Here's my initial prototype on GitHub
Repo: https://github.com/umaar/farewill-test
Moved onto the interview stage
For my Farewill application, this solution allowed me to move onto interview stage ✅️.
Farewill are an interesting company, in that they help people draw up wills. One of those areas of life which seems to be left to expensive lawyers, so it was nice to hear of a digital solution for this.
I left a few comments throughout the code which can explain what each function does exactly. Not much to say for this one, I got good feedback, and it was fun to do!
A fun little side note, when searching around for Farewill interview resources, I stumbled across what I guess was an old version of their code challenge and gave it a go - it was not at all part of my application process at Farewill, just something I was doing for fun. Here's the code: https://github.com/umaar/nfl-arrest-api
Repo: https://github.com/umaar/data-rights-extension
Moved onto the interview stage
I proceeded to the interview stage ✅️ with this solution for Projects By If, but there's more to this story.
I saw Data Rights Finder and throught it was really cool. A helpful website with a clean design, and no heavy advertising on their part. I figured these small points may reflect on their internal culture.
When I figured out who made the website, I researched what stuff they built, and came across a hackathon in London named Data Rights Finder Hackday. Time to give it a go!
Long story story short, I made a Chrome extension which automatically displayed the 'data rights' information on applicable websites. The coolest part is, I ended up pairing with the very person who ended up interviewing me! This person got to see my problem solving skills, how I debug, how I communicate with what I'm doing, and more. It felt organic.
Officially, they weren't hiring at that time, but a while after, when they were, I was able to get an interview! Technically speaking, this was not a code exercise part of a job application process. It was more of a "Hey I made this cool thing with your data, would you consider me for a job?".
Repo: https://github.com/umaar/nap-products
Moved onto the interview stage
Net-a-Porter, the massive online fashion retailer, liked my code submission and I was able to move onto the interview stage ✅️.
I really enjoyed this challenge. Even I'm a full stack web developer, most job applications asked me to do something either entirely client side, or basically write a Node.js script. This was different as I got to do both the frontend and a bit of backend.
IMO the thing which helped me here was: I kept things simple, no JavaScript framework, kept things performant, focussed on meeting the minimum set of requirements etc.
Repo: https://github.com/umaar/word-count
Moved onto the interview stage
Roli, the music technology company, liked my solution and I progressed onto the interview stage ✅️.
If you check the repo, it should be fairly clear what the requirement was. Not much to say here in terms of feedback. I believe a combination of the tests, and using a somewhat functional approach in the code is what worked in my favour.
Conclusion
In part 1 of this series, I left a Frequently Asked Question section at the bottom which should hopefully answer questions you may have, but message me on twitter if you have other questions, feedback, or even what articles you want to see next!