I’ll be the first to admit that I think I’m terrible at tech interviews. I never had a proper computer science education, and if I have never encountered a concept during my day-to-day job, odds are I won’t know how to implement “The Algorithmic-Data-Structure-Universe-Saving Thing™” in an hour with someone monitoring my keystrokes.
The only tech interview that I actually enjoyed was the one that got me hired at Shopify. They may have changed the process since 4 years ago, but back then, I got an image of a tic-tac-toe game and was told to code it up in whichever set up I was comfortable with. I did it in CodePen while talking through my process with the interviewer and had a great time.
Granted, the interviewer plays a significant role in the thing, but the structure and intention of the interview is what makes or breaks an interview process for me. Anyway, I’m quarantined in my room with COVID, so I have thoughts and I’m writing them down. 乁 ( •_• ) ㄏ
What I think I’m worth paying for
If you have worked with me, you will know that I’m not a general use developer. I am really good at specific things, and solidly mediocre in everything else. Which probably averages out to a B-, maybe. Ask my boss.
In an ideal world where unicorns shit rainbows, I would love to have coding interviews be directly correlated to the main work the intended hire will be doing.
I do recognise that this approach perhaps doesn’t scale very well in corporate environments, or in places that don’t really know what they are doing. That’s why I say rainbow-unicorn-excrement-land.
Over the decade that I’ve been working, I have been fortunate to land in jobs where the thing I like to do also happens to be the thing I’m good at. That is not as easy to come by as it might sound, so I’m rather grateful.
So here’s what I think I’m worth paying for: the ability to explain myself well, and the ability to HTML and CSS quickly, live in front of people, specifically my team mates.
What I’m being paid for at the moment
Web development is a wide spectrum these days, ranging from the front of the frontend, all the way back to the servers, networks and security aspects of things.
I personally am a very front-of-the-front developer. I like to tell people, if someone behind me just sneezes, I will fall into the design side of things. That’s how close to the edge I am.
The other fortunate thing about my career is that, I get to work closely with designers and content people. You’d be surprised at how common it is for developers to not have direct working relationships with their designers or content creators. Or at least, that’s what I’ve observed. If you have observed differently, that’s cool too.
During my day-to-day work, I work with idea people, namely our awesome designer, Madalina Tantareanu, and our comms director, Anna Sheard. I’m not an idea person myself, but I can make your idea become real.
I think that’s why we work well together, which is one of the points I’m trying to make here. In rainbow-unicorn-excrement-land, I would imagine that the code interview reflects a day-to-day working situation. So I’m going to briefly describe mine here.
What I work on day-to-day
As of time of writing, I have 2 main areas of concern at the Interledger Foundation. I am the custodian of all our documentation sites (we have 6 of them at this point), and our organisation website, Interledger.org (and all the related sub-sites).
It’s a nice split, in my opinion. The documentation sites are built on Starlight, an Astro framework for documentation. All the heavy lifting is done by the words written by our beautiful tech writing team. I just try to keep the home for these words as well maintained as I can.
The organisation website has a much bigger strategic role, since it is the online face of Interledger.org. And honestly, in my decade long career, I’ve never worked on an organisation website that was perfectly built from the start. Most organisations change way too much in the initial stages anyway.
I’m currently in the midst of preparing version 4 of our organisation’s website for release. For the past 6 months, our branding team has been working on formalising our long-term brand strategy and direction, as well as details and guidelines for usage and implementation.
As a fully remote company, we are unable to have discussions in person most of the time, and the magic usually happens on calls. And this is where the high-speed HTML-ing and CSS-ing is most useful.
Upon reflection, it’s not so much as the raw speed at writing HTML and CSS, but the thorough understanding of how exactly HTML and CSS work that allow me to instantly make the changes we discuss on the call live on the site.
Some times I do this directly on the codebase, if the thing we discuss is on a local site, or via devtools just to see if our proposed changes look alright or not.
My ideal frontend interview scenario
I’m not sure if this is a widely accepted or common way of working, but I have done so in most of other organisations I’ve worked at, and it has worked out very well for me.
It is so much easier to explain concerns around specific design choices that might not scale well across different screen sizes if you can show it directly to the person involved. Discussing visuals via imagination is not as effective as people think it is.
And if the developer is able to do it live on the call, the amount of time saved is exponential. Imagine having to finish up the call, make the changes locally, maybe screenshot it or deploy it to staging, then tell everyone to take a look, wait for everyone to actually look because time zones, you get the picture.
So my ideal scenario would be a site that has frontend Issues™, then the interviewer can start proposing improvement ideas and have an entire discussion with the interviewee on what could work or not based on seeing how these changes look on the site.
In reality, this is probably really hard to implement as a tech interview. So I don’t think it will actually catch on, but in rainbow-unicorn-excrement-land, anything is possible.
Wrapping up
Maybe you’ve heard a variation of the The Handyman’s Invoice story about a plumber charging $10000 for knowing where to hit a pipe. But that story does resonate with me. And that’s the level of expertise I want to have when it comes to building websites.
There’s not much of a point to the post methinks. Other than the fact I want to brag about my beautiful branding team. Haha. And I also want to be free of Covid soon. Getting food delivered isn’t cheap. 😩
Credits: OG:image from Vexels.com