In today’s therapy session pretending to be a blog post I want to try
and process my recent interview failure.
This might be hard to believe but this was only the second ever time
in almost 9 years I’ve failed to proceed to the offer stage for an
interview. The first time was my first ever interview; when, as a
bright-eyed young physical sciences graduate who could barely
FizzBuzz, I was asked a bunch of questions about big-O notation and
whiteboard algorithms. Something I’d never encountered and have never
really had to think about since.
That first experience dented my confidence so much I jumped into the
first job I was offered afterwards (at the very next interview). This
turned out to be a reasonable turn of events. That job taught me SQL
extremely thoroughly and was a fairly ideal first role. Plus, in
retrospect, it was probably more interesting than doing Java XBRL
processing.
4 roles and 9 years later I find myself dealing with the same shock
and feeling of inadequacy. Impostor syndrome on steroids.
So what happened? I failed to guess what side of bed a random code
reviewer was going to get out of bed on a random morning. Maybe. Maybe
I pushed my luck by applying for a Python role when the last time I
did Python was a tutorial 7 years ago? Maybe I’m not as good as I
think I am? Maybe I actually am an impostor? Maybe if real people who
get paid to code for a job think I’m crap they’re right?
But then I do get paid to code for a job. And every job I’ve had has
been extremely happy with my work. And I know I’m in the top 30%
(being modest) at least of developers just by comparison with others.
I still have one company wanting to hire me 2 and a bit years after
seeing my code-test.
This isn’t a “hiring is broken” or “interviewing is
broken” post because the process was actually very well planned
out. And the take home test was quite fun (and I’d rather have take
home tests than whiteboard algorithms, the aformentioned big-O
incompetence). And they had an initial screen call to show they were
willing to invest in the process. And they gave
feedback with the rejection!
However the arbitrary-seeming scoring or evaluation of take home tests
has unsettled me. When you submit code for review in your day job you
can at least discuss decisions and tradeoffs with your reviewer even
if they dislike the code on principle. A take home test is always a
best-guess process. You don’t know if the single reviewer who will be
reading your code values abstractions or simplicity. You don’t know if
you’re designing for the future or showing your prototyping skills.
You don’t know if test coverage is a plus or marks you down as a
worrier.
In this case I thought I was designing to support one future use-case
(extended formula parsing and evaluation) when in retrospect it was
likely they were looking for a different future extension (sorting and
searching). The design made trade-offs for formula evaluation that
would have made the latter use-case more inefficient and slightly
harder to implement. But there were easy changes that could be made
such as indexing data for searching or changing the underlying storage
structure to make sorting efficient.
And so I find myself revisiting and justifying every choice. It’s like
when you wake up at 3am and think of the perfect comeback 2 weeks
after an argument with someone you’ll never see again. The response
turning to ash in your mouth. If I could just point out that I’m aware
of the tradeoffs I made in a conversation with an actual person they’d
surely see my genius. I’d show them all. Mark my words, I’d show them
all.
Just let me work
Why is it that every business larger than about 10 people falls back
into the same waterfall model of operation? Why is it that development
capability becomes a resource to turn on and off like a tap? Why can’t
I just do my goddamned job?
