It’s Keith Johnston Improv. It really helped me to become friends with my subconscious, imagination, destroy some assumptions about myself, reframe my view of children, of course laid a stone into my decision to have a child (like this year as opposed to “eventually” or some day as I started interacting with children after reading the book), showed me a cool hobby and a new way to express myself as an event organizer. I have like 240 highlights and notes in it, more than in any other book by far, it was really a book written just for me at that point in life, you know? It also has a bit of a twist towards the end. Highly recommend! I’m 33 if this provides some context I dunno :)
Oh there’s also a TED talk by the man, you can totally see he is something else by watching it and comparing to other TED talks. Makes more sense of you read the book though.
There are several possible reasons why you didn't include any tests in a take home exercise, and they are all bad.
1) You ran out of time to write tests.
This might be the least bad reason. You can probably talk your way out of this by explaining what tests you would have written if you had the time.
2) You don't know how to write tests.
This shows that you have only worked at places the don't do testing and that you haven't taken the initiative to learn about testing on your own.
3) You know how to write tests, but you don't think they are needed.
You could probably tell the interviewer why tests were not important for the particular exercise. But I have never seen a take home exercise that doesn't require a basic algorithm and some tricky conditional business logic. Both of which would benefit from unit tests.
4) The code you wrote isn't testable.
This is probably the worst reason. Everything is in one or two giant functions and you can't inject dependencies for testing without refactoring everything. This will frighten your interviewer.
Thanks for sharing, perhaps my workflow could be improved. Here's how I usually work:
1. Build a prototype of the feature I need to build
2. After I have a prototype, I start to understand the complexities of the project and I start thinking about how to modularize my code (the functions I would need, how the frontend-backend interacts together).
3. I rebuild the feature with TDD
For take-home assignments, I stop after step 2 because step 3 is the most time consuming part.
I'm pretty open minded about this, but with 5-6 years of development most take home assignments are so trivial and so self-contained.
Perhaps its really the take-home assignment that needs to change. For example, heres the sort of prompt that would motivate me to write good tests:
"Here's a private repository that every candidate we have hired has been building. We would like you to add a feature. Please build feature X on top of our existing code -> Link to repository that has an application with simple testing infrastructure"
Now the take-home assignment has more value and actually gauges how well the candidate would do in an actual working environment. When the candidate gets hired, his feature actually gets merged into the assignment and a new feature is assigned to new candidates.
This is a really cool idea - because working with code written by other people is usually a large part of any job, this type of assignment could also test for that. For newer devs, I've seen anything from simple Tic Tac Toe to being given a starter app with a general set of requirements to fulfill.
5) Your interview process is ridiculous, and I refuse to do more than the bare minimum when I am not even guaranteed an interview in exchange for my time investment.
I am an experienced programmer. I refuse to do take-home tests as a pre-screen for an actual interview, unless I know for certain that a position is one that I would want to take (e.g. I know someone who works there, and I know that it's a dream position. This basically never happens.) Moreover, if I have done a full interview loop and you insist on screening me based on inanity such as "he didn't write tests for this time-limited toy assignment", I will gladly move on to the next company that isn't ridiculous.
Take-home tests are screening devices. If you draw inferences other than "this candidate can/cannot write code" from a take-home test, you are using them incorrectly.
I probably wouldn't do a take home test for an interview, but if you're only willing to do the bare minimum, it would probably be a better use of your time (as well as whoever is going to grade it) if you simply refused to do it.
Before I accept a take-home project, I explicitly lay out what I will do and the maximum amount of time I will spend doing it. I've walked away from companies that demanded more than I was willing to give.
I dislike take-home tests less than I dislike whiteboard interviews, so I try to be flexible, without being a pushover.
The ideal hiring process imo is actually a training process that is less focused on 'finding the best' but rather focused on helping their local community become great engineers. Companies fund their own bootcamps and pay students $15/hr (with no engineering experience). Students learn and help each other how to code (following a structured curriculum) with mentorship by engineers from the company. When students have finished the basics, they work on open source projects or internal projects following proper engineering process / tools that the company use. When a student has proved that he/she learned how to work well with other engineers and has built a few features, they get hired by the company as a junior engineer and this junior dev would be immediately productive.
This might seem like a crazy idea, but its actually not. The previous companies that I have worked for all offer paid volunteer hours which could go directly to this initiative. The cost of hiring is around 30k per engineer (conservatively), which could help train someone living paycheck to paycheck for an entire year.
I spent the past year and a half starting a non-profit experimenting with this idea and invested all 200k of my annual salary to paying students. The coding tools and environment is set up like a baby version of Google's engineering infrastructure. Students progress are tracked by their merge requests and the complexity of the features that they have built. Students build tools that they use on a daily basis so they are heavily eating their own dogfood. Hopefully, one day I'll be able to build my engineering team by directly hiring from this non-profit. https://garagescript.org
5) You were interested in limiting the time cost to yourself related to being interviewed, expecting that the wider sqrt(t) uncertainty band in your abilities would not mess up the company's hiring procedure too badly.
Ego-depletion is mentioned, not always by name, in hundreds productivity and focus related articles and books published in the last 5 years or so.
Steve Jobs is often used as an example because he wore the same outfit to work every day, purportedly so he would not have to waste any crucial willpower early in the day on such a trivial task as choosing what to wear.
>> Steve Jobs is often used as an example because he wore the same outfit to work every day, purportedly so he would not have to waste any crucial willpower early in the day on such a trivial task as choosing what to wear.
That was to free up time and free himself from an extra decision. Mental exhaustion is not the same as ego depletion. The later claims that "self control" is a limited resource, but picking your outfit doesn't really require that anyway.
