Fail fast, fail often

I’ve been interviewing more regularly and putting my name forward for other web developer jobs. Not because I am a man in demand, or depressed at my current role, or greedy, or anything like that. 

Many of these web developer jobs are probably out of my reach and the number of rejections I have had possibly confirms this.

However, the rejections don’t bother me. I’m old enough and ugly enough to have experienced rejection on a number of occasions. The rejections have been extremely useful. 

Why is that?

They have helped me identify areas where I am lacking and understand if I am becoming stagnant in my current web developer role. Understanding where you are lacking as a developer is key to your progression, giving you the opportunity to reassess where the bulk of your time is being spent as well as defining what direction you want your career to take.

So the question is, how did the interviews go?

One interview was for a web developer job in London. Working remotely but with some monthly travel to ‘the big smoke’ which I would have been happy with. I describe myself as a web developer who enjoys being outside and mixing. A rarity. Cities are wonderful for getting the mind working and creating new possibilities in your mind that you can test out when you’re home. I don’t know what it is about them. Maybe the overstimulation of the senses or a break from the norm. Either way, I like to visit a city.

The interview process was to be set out in a couple of stages. First up was an interview with the hiring team. They would explain to me what the role would entail, their expectations, and give me an opportunity to sell myself.

This part went very well in terms of describing my role, where I see myself in the future, and how I would fit into a new team. It should be said the guys conducting the  interview were excellent which probably contributed to me performing so well at this stage.

The part where I came unstuck was the tech test. 

I’ve performed a tech test before. And did very well at it. I had to recreate a single page XD mockup, without a time limit.

This one involved a time limit.

I was informed I would be allotted 2 hours for the test and the timestamps would be taken from the moment they sent the email to the point I send my completed test. To help me gain some time on this test I tried to prepare my web development environment the best I could. 

The role was for a WordPress developer, so the first thing to do was setup a clean WordPress installation. Next, I have a barebones template I use for builds that includes my build tools such as Gulp and SASS. I installed Advanced Custom Fields because the role asked for a strong background in developing custom blocks using ACF. However, in recent months I have been using the WordPress block editor API for custom blocks but felt using ACF here would be faster.

I received the email with an Adobe XD file, and a brief. I immediately froze after reading it. 

Create a custom block that connects to the OpenWeather API, with extra points for making it auto update. Along with a select field that enables the user to select a city of their choice. 

I have little to no real-world experience apart from tutorials based on implementing APIs so doing this professionally, in 2 hours, and to a level that would be enough for me to get a web developer job would be highly unlikely.

However, I got started anyway and began frantically searching StackOverflow for anything that might help me. 

And what did I choose? Server-side/PHP handling for the API...WHY?

It probably goes without saying here that javascript would have been the ideal candidate but because my searches were based around ‘WordPress handle API OpenWeather’ I ended up getting mainly PHP-based solutions. 

I did, however, get the weather component to work in making basic calls, which I was quite happy about. I missed off a lot of the additional functionality in the requirements though. 

Where I came unstuck was what I consider to be my bread & butter. CSS/styling.I was awful. Truly awful. 

At this point, they must have been questioning if I actually did the work I claimed in my portfolio (trust me, I have). Because I left myself so little time to do the styling what I submitted was pretty much useless. 

Then, to top it off a had problems with Gmail sending the email. Turns out Gmail hates you sending JavaScript files in a ZIP bundle. When I eventually got the email sent I was over 10 minutes late.

I sent the interviewers a light-hearted email basically telling them to not expect much at all.

Unsurprisingly, that web developer job didn’t come through.

On to the next one

Another web developer role I interviewed for was advertised as working for a small, growing development agency with ties in the UK and Europe. Much the same as what I am doing now but working with many tech startups.

I’ve dealt with interviews on this level before so thought I knew what to expect. The sites they are creating are nothing too complicated and clients of this size often have very reasonable expectations. 

The interview got off to a great start again. Lots of talk about dogs and the great outdoors. When you’re living in Inverness it is often an area of the country many people want to know about. This all helped the lead into questions about the role, during which I was asked if I saw myself as a lead developer. 

This was a bit of a curveball and something I had not prepared to answer. The recruitment agency that got me the interview didn’t tell me it was a lead developer role. They said it was your ‘standard’ web developer role.  

However, after some thought, I decided it was a direction that I wanted to go. It was the next, logical step. Becoming a Lead web developer should be what I am aiming towards.

So the first part of the interview process went very well. I had sold myself convincingly and was informed I was moving on to the next step. A chat with one of their current developers to describe my work and talk through one of my WordPress builds.

The second stage of the interview came along and I presented some of my work, discussing my code and describing my knowledge at various points. Particularly areas such as custom blocks using the WordPress Block Editor API because I am currently in the process of developing a toolkit to speed up builds. 

One part of the site I was showing displayed a search/filter area for a property website. I was then asked how I would go about implementing this and my answer was simple.

I didn’t know.

Again, I have very little experience in this type of common functionality and I would always pass it off to a more senior web developer to do. 

This may have been partly out of laziness, as well as ensuring it would be done correctly and in a fast enough time. But this was again an area where I was severely lacking.

My inability to describe handling forms was the nail in the coffin for them as they decided I wasn’t at the level required for a lead web developer. Fair enough I thought.

What did the interviews highlight?

First of all, I have missed some fundamentals that are in most medium-scale builds. Web development techniques that would be expected of me from most, if not all, employers. 

Being able to handle APIs is fairly common in builds today. The way it made me freeze when reading I was expected to build a block that made API calls showed I had zero knowledge in the area and I need to spend more time on it.

The ability to search or filter data is very common too. I have probably been very lazy in my current role by handing this work off to a more senior web developer. Yes, they will do it better. But I will never learn how to do it effectively if I keep handing the work off.

As well as that, I worked out that, yes, I do want to move into a lead web developer job. I want to be given the chance to teach someone new to web development. To be able to do that effectively I need to be able to explain my code and have a strong understanding of the fundamentals of web development. 

So this is where my time has been focussed recently. In my work, I am now taking on more (and therefore handing off less) work involving search, filtering, and APIs. My side projects are now focused on building a complete WordPress boilerplate that includes all aspects of a modern web build.  

Fail fast, fail often. It helps you identify where your weaknesses are. I know where some of mine are now and the next steps are to strengthen those weaknesses, as well as find more. 

Categorised under