“This project will only take 2 hours”

I had a take home test that was to last 2 hours, and so I promised myself I would spend no longer on it. I provided a complete log of what I did minute by minute for a take home test for the last test I did as a defensive measure...

There was no break, no pondering, this was flat out knowing exactly what needed to be done and just typing constantly....

0:00 - started cloning

2:37 - finished cloning

3:11 - npm install

3:53 - localhost working

7:24 - removed timeout (intentional bug left in)

10:41 - Got images returned from the server (npm run serve)

13:27 - CSS started - thinking about design

22:26 - Grid for desktop

36:16 - Included user info

49:56 - responsive

56:37 - Added performance section

1:07 - Name form

1:21 - Email validation

1:35 - Most fields done. Need DOB

1:42 - DOB done

1:53 - form styling

1:57 - tidying up

2:01 - Saved this file

I didn't end up getting the job including feedback such as...

- Did not upload job search indicating repo to GitHub

- Didn't use `specific css attribute`

- Grid is rudimentary (the 11 minute one I made)

- HTML could be more semantic

- Form validation for name allows numbers (actually a programming falacy that names can technically be anything)

- Complaints about having multiple classes in one file.

I'm wondering exactly where I could have fit these in?

The week before I spent 4 hours on a task and delivered it within 12 hours of the assignment. I got an email with a single paragraph. `Unfortunately, after reviewing, the team has decided that they won't be moving forward to the next stage of the process with you`

These tests all have unrealistic expectations. I used to enjoy doing them for the learning experience, but now, it's just a solid graft with zero downtime coding the same app time after time.

So whenever I chat to a recruiter about the recruitment process I always drill down into the take home test, and the process of doing that let's them know that I won't be doing any take home tests. You have to simply question it sometimes and you can get it upgraded to a pair programming assignment which if you are honest, and have experience works in your favour.

This took me ~10 minutes:

    #!/bin/sh
    set -e
    while true; do
        URLS="$(xsel | grep -Eo "(http|https)://[a-zA-Z0-9./?=_%:-]*")" &&
        if [[ ! "${URLS}" = "${OLD_URLS}" ]]; then
            echo "${URLS}" >> urls.txt
            OLD_URLS="${URLS}"
        fi
        sleep 1
    done;

What does the process look like when we ask back, "are you going to need to have a total and rolling sum? should we think about making a gui so other people can use it too?" Engaging the requests early on not only helps our planning, it helps the "client" figure that out sooner than later.

I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly.

Estimates are given as the following choices: hours, days, weeks, months, quarters. You never give a number tp the units. These all mean some "small number of X" where X is the list above. Then if Product has a question like, "Why would Z take weeks?" then you can have a discussion about the complexities and the task can be further refined and/or split into multiple things and those can be estimated as above, rinse and repeat.