I've recently been interviewing again, which has sparked the fire to write about the whole process. It's something I've considered writing about before, but I've spent four years in my current...
I've recently been interviewing again, which has sparked the fire to write about the whole process. It's something I've considered writing about before, but I've spent four years in my current role without bothering to interview anywhere. Surprisingly it's changed a lot since then!
I mention interviewing at a British fintech in the article... I'm very happy to say I was successful and will be starting there in November! It's the pink themed neobank. I've interviewed at a few places in the past months, and their process was a breath of fresh air. I'd be happy to expand on any of it if someone is interested.
Thanks for sharing! I am on the hiring team at my current company, and it was reassuring to see that I hit most of your marks as a passable interviewer haha. Or at least I'd like to think so. To...
Thanks for sharing! I am on the hiring team at my current company, and it was reassuring to see that I hit most of your marks as a passable interviewer haha. Or at least I'd like to think so.
To add my 2 cents to this, I also think that the prevalence of LLM-assisted coding has also thrown a big wrench in the interview process. My company still does your typical coding round, then design round (or vice versa), but it took us a while to arrive at a version of this that was actually applicable to how one writes software nowadays. We arrived at a methodology that asks for, in short, pragmatism, critical thinking, and ease of collaboration as the main rubric. We try not to arrive at these by asking "LLM proof" problems, rather by asking very open-ended design questions that force the candidate to define and come up with their own tradeoffs and the like in addition to answering for the design (I often do the design calls and the majority of my questions are just "yes, but what if?"), or by asking coding questions so large in scope that they pretty much require the use of a coding agent, for which we observe proficiency, how well they reason about and curate output, and how well they are able to understand and interrogate the problem being asked in the first place.
That paragraph got long, and it's hard for me to state that in a non-wishy washy way without getting too specific... but it works well for us. The point I'm trying to get at is that it's amusing how many times I've heard positive feedback from candidates after the fact, saying this is the first time they've had to use a coding agent in interviews, or that the design call was really interesting because it actually made them think, or whatever. I interpret that as a sign that many other companies, even in the face of AI mania, aren't doing these kinds of things. Like, what else is there to test for now that hand coding proficiency is basically a commodity?
(We are quite AI-pilled as a company which might influence how we carry out that process. I'm not quite AI-pilled... I think, but I can appreciate how we haven't lost sight of what the bar for an engineer should be.)
I've recently been interviewing again, which has sparked the fire to write about the whole process. It's something I've considered writing about before, but I've spent four years in my current role without bothering to interview anywhere. Surprisingly it's changed a lot since then!
I mention interviewing at a British fintech in the article... I'm very happy to say I was successful and will be starting there in November! It's the pink themed neobank. I've interviewed at a few places in the past months, and their process was a breath of fresh air. I'd be happy to expand on any of it if someone is interested.
Thanks for sharing! I am on the hiring team at my current company, and it was reassuring to see that I hit most of your marks as a passable interviewer haha. Or at least I'd like to think so.
To add my 2 cents to this, I also think that the prevalence of LLM-assisted coding has also thrown a big wrench in the interview process. My company still does your typical coding round, then design round (or vice versa), but it took us a while to arrive at a version of this that was actually applicable to how one writes software nowadays. We arrived at a methodology that asks for, in short, pragmatism, critical thinking, and ease of collaboration as the main rubric. We try not to arrive at these by asking "LLM proof" problems, rather by asking very open-ended design questions that force the candidate to define and come up with their own tradeoffs and the like in addition to answering for the design (I often do the design calls and the majority of my questions are just "yes, but what if?"), or by asking coding questions so large in scope that they pretty much require the use of a coding agent, for which we observe proficiency, how well they reason about and curate output, and how well they are able to understand and interrogate the problem being asked in the first place.
That paragraph got long, and it's hard for me to state that in a non-wishy washy way without getting too specific... but it works well for us. The point I'm trying to get at is that it's amusing how many times I've heard positive feedback from candidates after the fact, saying this is the first time they've had to use a coding agent in interviews, or that the design call was really interesting because it actually made them think, or whatever. I interpret that as a sign that many other companies, even in the face of AI mania, aren't doing these kinds of things. Like, what else is there to test for now that hand coding proficiency is basically a commodity?
(We are quite AI-pilled as a company which might influence how we carry out that process. I'm not quite AI-pilled... I think, but I can appreciate how we haven't lost sight of what the bar for an engineer should be.)
Good luck at your new gig!