As a recent graduate of coding bootcamp I'm starting my job search, applying to graduate and junior developer positions. I've seen people's opinions on take-home coding challenges and having just submitted my first, thought I'd add 2 pence to the piggy bank from my own perspective.
Several reddit threads and blog posts suggest some developers are not a fan of the take-home challenge, for reasons that are many and varied according to circumstances. Some bemoan the task itself as little more than unpaid work that takes far too long to complete, others feel there are better ways to judge someone's suitability for a position - pair programming for instance. As a mid-level or senior developer with a large portfolio and proven track record, would I be inclined to share some of those viewpoints? Ask me again in a few years....
As a junior looking for my first dev role, however, I can see the validity of this type of task for someone in my position. I have a limited set of projects that I can show a prospective employer, not all of them crafted over time and given the love and attention I really think they deserve. Much of what I have built so far (particularly at bootcamp) was done in a week at most, after only learning the subject for maybe twice that time. In and of themselves they provide a useful snapshot of how quickly I managed to pick up each new concept, but could all use a hefty dose of refactoring.
As far as I understand it, the assignment I completed is a fairly standard example of a take-home coding challenge for a junior developer role. Personally I learned a huge amount while I was doing it - the task called for the program to be test-driven and object-oriented. It could be written in pretty much the language of your choosing, so I went with JavaScript for a couple of reasons:
- I really like it, and I really want to get good at it!
- In bootcamp I only used it functionally but I know it's important to understand the fundamentals of OO programming - no time like the present!
TDD was another thing I knew was important and wanted to get into but hadn't made time for yet. My whole program was driven by the tests I wrote, which took a bit longer but the finished product had evolved into something I was proud of - admittedly I didn't appreciate what the value of TDD actually was until the tests were showing me that certain class attributes were no longer necessary, or that I really needed an extra method to break up one that was doing too much. Now I'm finding in my code practise I regularly solve problems using TDD, which feels great!
I'm grateful that this code challenge pushed me out of my comfort zone because it's accelerated my learning in two major areas of development. I've submitted it and am excited to get some feedback and find out what the developers who review my code think of it. For a first attempt I believe I did a good job: I read the task A LOT of times, planned and tested the code thoroughly, it fulfils the brief and I have lots of ideas for what else it could do, all of which I documented in a carefully thought-out readme. It may have been my first take-home challenge but I'm sure it won't be my last. Watch this space....
Top comments (1)
I like your positive attitude regarding the interview process. I've done many interviews, and though I also don't like certain aspects, I always try to seem as personal learning experiences as well.
For me personally, I don't like giving new developers the attitude that "coding challenges take too long or are unpaid work". I think it sets a negative tone for a very common practice. I also see those people on Reddit/Twitter and I think it sets a very negative tone on something everyone( even myself with 15+ years of experience) have to go though.
More seasoned developers sometimes have the luxury choosing if a coding challenge is worth their time b/c they often have other opportunities, so they are often very vocal of any additional time it takes to get a job.
Some comments have been hidden by the post's author - find out more