I interviewed for a Backend Engineer position at Kraken Technologies (part of Octopus Energy). I met the hiring manager at the London Django Meetup (btw, it's a great Meetup that runs monthly if you are in London and haven't been, and Kraken has been a long time sponsor of the event!). I initially approached the hiring manager to recommend a friend who's looking for a product manager role, but we had a great conversation and I got interested in the backend engineer role on the team as well. After a visit at the Kraken office for another Django Meetup, chatting with some people who work there, and a subsequent catchup with the hiring manager to know more about the team, the work they do, and the way they work together, I was convinced to start the interview process. The whole process was definitely one of the best experiences I've had in my career in tech! Friendly and helpful people at each stage, and quick follow-ups. It involves 5 steps: 1. 45 minutes screening call with internal recruiter to chat about my past experiences, overview of my technical skills, my motivation for switching roles, and for me to ask questions about the company culture, tech teams etc. Overall a really pleasant chat and I got to understand the company better from the chat. 2. 45 minutes technical/cultural interview with 2 engineers from tech teams. It was relatively informal, we (the interviewers and me) took turns to ask each other questions. We chatted about my past experiences and projects I worked on in more details, tradeoffs of technical decisions, what got us excited about work, the projects they’ve worked on at Kraken, technical challenges they have, their approaches to problems both from technical and non-technical perspectives. Overall it was like chatting with coworkers and I learned a lot from the discussions! 3. A take home test that takes about 3-5 hours, building a Django application using GraphQL API. A reasonably sized task and was interesting to work on. 4. 45 minutes final interview with 2 engineers on the team that I’d be joining to discuss the technical decisions of the take home test, and what I’d have done if I have more time. It was really thorough and no gotcha questions. It felt like just a code review chat with coworkers during my day job, which is the part that I love the most about my job being an engineer. We chatted about why I modelled the data the way I did, why I chose certain design patterns, my approach to testing, how I’d refactor certain part of the code if I had more time. We also discussed the technical challenges the team face and the expectations of the role and where my skillsets can fit in on the team, the learning and growth opportunities on the team. 5. Offer :)

After a call with the recruiter, I was sent a technical test (which I was told would be followed by a technical interview if things went well). This is the same test they use across the entire group (as far as I could tell) and they haven't changed it in at least a couple of years. It asks candidates to write a Django application that implements a parser for a very industry-specific standard, which specification is, and this is written in the problem statement, fairly confusing to navigate and understand, and somewhat incomplete. You'll have a 3-4h time limit (they say not finishing by then will not be held against you - that's a lie, you'll be failed automatically), and at least a third of that will be just figuring out how to read the specification. In truth, a realistic expectation for finishing most of the test (i.e. only be missing some optimisations and a few tests) would be around 5-6h, so just ignore the time limit (everyone I know who've gone through this test does so). Then, even if your submission is more than good, once you've submitted it it's a coin toss. There's no indication what a passing grade even remotely looks like, and I've heard people being failed for a variety of reasons which most would consider nitpicks (rather than whole reasons for failing an application), such as too many comments, or missing something not mentioned in the problem statement's requirements. Feedback which amounts to "we were impressed at the submission but we found a small bug and you're missing a small bit of doc we didn't mention in the requirements" would be something I'd expect to mean the submission wasn't perfect but we can talk about it during the follow-up technical interview, but apparently that meant I was out. As a reminder, I wasn't even applying for a senior position. Honestly considering the feedback I'm almost glad I got rejected, considering how high the bar was for a non-senior position with the salary range I was told about during the initial interview (£50-70k). If the expectations are higher for non-senior devs than I've seen or experienced on senior devs in other places, then it feels like I've dodged a massive silver bullet.