Something I appreciated when going through Anthropic interview process was that I only dealt with humans. They could have been showcasing how even their interviews are done with Claude or something, but no, the whole loop was interacting with real humans, and nothing was on the topic “how do you work with LLMs”. It was about how me, the human, think and approach situations, and how I handle working with others (humans), etc. Which made a lot of sense to me, and I overall appreciated their process (other than it’s very time consuming, requires lots of prep). But it’s interesting to see that AI labs customers feel the need to showcase how much of their processes are now around agentic stuff
AI critics and honest AI executives of 2023 might say that AI companies are automating labor so that Capital can capture all productive value. But we have to give them some credit. They are hiring real humans. And not even hounding them about how they are not being sufficiently useless-meatbag relay points for the AI models and agents. And that demonstrates that they are actually being real humane mensch.
Meanwhile, how many jobs have AI critics created? Crickets.
It's imperative to understand that Anthropic and OpenAI view their customers as subhuman drug addicts (read: *users*).
From this perspective, the people who use these tools are beneath the people who design them. From this perspective, the rightful state of the world is for the superior members of the in-group to control the experience of the inferior members of the out-group.
By using these tools, you willingly accept the position of the inferior/the sub-human/the addict.
I've been considering different ways to measure code understanding and fluency. I'm still using traditional 'easy' problems on a coding pad to probe this, but I'm finding a new generation candidates that don't prepare for this, and may be able to have a full career with just a higher level of code understanding. But they might not ever develop the ride-a-bike with one hand level of fluency unless they grind pointless leetcodes.
So I'm increasingly uncertain about what and how to test. My default for now is still to rely on ability to write basic code fluently, but I'm open to changing this perspective.
I really want to know how this existing repo AI-assisted live coding test works, with example problems.
It seems the standard data structure puzzle type thing won't be feasible if you are using an LLM.
Also the latency for these agentic coding/prompts seems like it would make the interview a bit awkward.
Anyone been conducting or taking interviews with this kind of thing with thoughts to share?
I’ve been conducting AI Coding interviews at my job. Candidate will screen share and use AI-assisted coding environment and tools of their choice.
I ask them to implement xyz thing. What I’m looking for is how they interact with the AI agent. Do they ask the agent to plan first? Do they review the plan? Etc. It’s pretty typical stuff that you might expect an experienced engineer to do if they effectively use such tools daily.
There are a series of follow-up questions about how to productionize the toy system, which gives some additional signal about how well they understand what they’re making. I sprinkle these in when there’s dead air waiting for the bot to think.
I think we’ll need to evolve and refine this problem and process as the models continue to improve.
>It’s pretty typical stuff that you might expect an experienced engineer to do if they effectively use such tools daily.
It's also the kind of stuff that somebody can learn in a week, so not hiring the right person who just didn't spend this week of time yet for whatever reason is a loss.
Yeah it tells you nothing of value. It's the Recency Bias taken to its ultimate conclusion isn't it. Anything I learned about AI I learned in the last few months but somehow that's as important as all the experience of my decades long software career? Come on.
It signals you don't have enough time or will to chase the latest stuff, otherwise you would have learned it with other cool kids half a year earlier. It carries some signal, but I would not choose based on this alone. I would even consider selecting against this to a certain point, but I also work in a place that COBOL on a mainframe. YMMV.
I am really looking forward to the day where AI is normalized during interviews. Right now the duality of interviews is basically:
- You get a leetcode question and if you're lucky is an easy medium that you can solve, if you're really lucky you already solved it and can pretend you are approaching the problem the first time. Good luck if you get a hard question and you never saw it before.
- You get a home assignment, in a framework you might not know but you're expected to be fluent with it, then waste 1 hour setting up the project structure, and one more hour to find out how the framework expects you to define the CORS allow list. You are expected to deliver the project in 3 hours.
The good I see in AI is that it completely removes the need to study just for interviews, and you can also delegate all the project setup to the AI. Then you can focus on what you would test (e2e? integration? what are the boundaries? what do we mock?), how to keep the documentation, how to structure your code. You have an expensive endpoint, do I make it sync or add an async jobs framework?
Imagine you're an expert in C++ interviewing for a Django position and the interview consists of fixing a big in a repo. The bug is that a function without type hinting is modifying what is expected to be a list, but the caller is passing a tuple. Trivial after a week you work in python and you have your environment set up for type warnings, also trivial with AI and definitely not an interesting problem that shows expertise with software engineering in general.
We also did this in our last interview at work, and it was a really good indicator to see if someone just copy pasted code, or understood it after it was generated. Some candidates had a unit test fail and couldn't debug it for his life, even if he "wrote" all the code himself. Others simply did not understand the architecture they wrote, and assumed that a function defined with "async" and awaited would run in parallel from the code that called it (as if you spawned a thread)
I was on the interviewer side last month. We stopped giving take-home assignments because they don't produce a signal anymore.
We explicitly said -- feel free to use whatever framework and AI assistant, just show us how you do it. The practical part had no leetcode too. Just build something really basic, then explain a snippet of code (3 lines) and generalize it. A trick question (with a disclosure it's a trick question) if the candidate did it fast enough that we didn't have to go into the overtime. A bit of theory about protocols, all in all an hour and we leave another 30 minutes on top to answer questions.
At the end of the day we just filter out with confidently bad takes, people who can't do 2+2 and ones that can't understand the question without rephrasing it three times.
The most bizzarre candidate didn't know anything at all, but was so relaxed and confident, that he spent all of the 30 minutes asking about the company and how his day would like and all that, while he clearly bombed it.
The difficult part is how to not filter out a competent person who doesn't necessarily agree with all of your takes, uses all the same tools and had all of the same experiences as both of the interviewers.
I would do the opposite and would likely use the same framework that some AI companies are doing to evaluate candidates. By either not allowing them to use AI assistants in any part of the interview process (Anthropic and OpenAI does this.) or give candidates a strict token limit (100k tokens) until the candidate runs out of tokens.
They have to earn it, as the tokens are not free.
Given that deskilling and over-reliance in AI assistance will continue to happen, putting a hard token limit <100k tokens in the interview process serves as a great filter to prevent the vibe-coders and "tokenmaxxers" out and forces a higher bar for quality, with clean code and reasoning across well maintained software with less tokens rather than increasing the slop.
Do you want a candidate that knows when to use AI and carefully uses tokens with in their limits, or do you want a candidate generating incomprehensible AI slop to be tokenmaxxing out your company limits and then draining your company bank account?
Meanwhile, how many jobs have AI critics created? Crickets.
From this perspective, the people who use these tools are beneath the people who design them. From this perspective, the rightful state of the world is for the superior members of the in-group to control the experience of the inferior members of the out-group.
By using these tools, you willingly accept the position of the inferior/the sub-human/the addict.
So I'm increasingly uncertain about what and how to test. My default for now is still to rely on ability to write basic code fluently, but I'm open to changing this perspective.
I really want to know how this existing repo AI-assisted live coding test works, with example problems.
It seems the standard data structure puzzle type thing won't be feasible if you are using an LLM.
Also the latency for these agentic coding/prompts seems like it would make the interview a bit awkward.
Anyone been conducting or taking interviews with this kind of thing with thoughts to share?
I ask them to implement xyz thing. What I’m looking for is how they interact with the AI agent. Do they ask the agent to plan first? Do they review the plan? Etc. It’s pretty typical stuff that you might expect an experienced engineer to do if they effectively use such tools daily.
There are a series of follow-up questions about how to productionize the toy system, which gives some additional signal about how well they understand what they’re making. I sprinkle these in when there’s dead air waiting for the bot to think.
I think we’ll need to evolve and refine this problem and process as the models continue to improve.
It's also the kind of stuff that somebody can learn in a week, so not hiring the right person who just didn't spend this week of time yet for whatever reason is a loss.
- You get a leetcode question and if you're lucky is an easy medium that you can solve, if you're really lucky you already solved it and can pretend you are approaching the problem the first time. Good luck if you get a hard question and you never saw it before.
- You get a home assignment, in a framework you might not know but you're expected to be fluent with it, then waste 1 hour setting up the project structure, and one more hour to find out how the framework expects you to define the CORS allow list. You are expected to deliver the project in 3 hours.
The good I see in AI is that it completely removes the need to study just for interviews, and you can also delegate all the project setup to the AI. Then you can focus on what you would test (e2e? integration? what are the boundaries? what do we mock?), how to keep the documentation, how to structure your code. You have an expensive endpoint, do I make it sync or add an async jobs framework?
Imagine you're an expert in C++ interviewing for a Django position and the interview consists of fixing a big in a repo. The bug is that a function without type hinting is modifying what is expected to be a list, but the caller is passing a tuple. Trivial after a week you work in python and you have your environment set up for type warnings, also trivial with AI and definitely not an interesting problem that shows expertise with software engineering in general.
We also did this in our last interview at work, and it was a really good indicator to see if someone just copy pasted code, or understood it after it was generated. Some candidates had a unit test fail and couldn't debug it for his life, even if he "wrote" all the code himself. Others simply did not understand the architecture they wrote, and assumed that a function defined with "async" and awaited would run in parallel from the code that called it (as if you spawned a thread)
We explicitly said -- feel free to use whatever framework and AI assistant, just show us how you do it. The practical part had no leetcode too. Just build something really basic, then explain a snippet of code (3 lines) and generalize it. A trick question (with a disclosure it's a trick question) if the candidate did it fast enough that we didn't have to go into the overtime. A bit of theory about protocols, all in all an hour and we leave another 30 minutes on top to answer questions.
At the end of the day we just filter out with confidently bad takes, people who can't do 2+2 and ones that can't understand the question without rephrasing it three times.
The most bizzarre candidate didn't know anything at all, but was so relaxed and confident, that he spent all of the 30 minutes asking about the company and how his day would like and all that, while he clearly bombed it.
The difficult part is how to not filter out a competent person who doesn't necessarily agree with all of your takes, uses all the same tools and had all of the same experiences as both of the interviewers.
- We have embraced everything about the AI Era at our company
- Arbitrary topic about how that changes something
They have to earn it, as the tokens are not free.
Given that deskilling and over-reliance in AI assistance will continue to happen, putting a hard token limit <100k tokens in the interview process serves as a great filter to prevent the vibe-coders and "tokenmaxxers" out and forces a higher bar for quality, with clean code and reasoning across well maintained software with less tokens rather than increasing the slop.
Do you want a candidate that knows when to use AI and carefully uses tokens with in their limits, or do you want a candidate generating incomprehensible AI slop to be tokenmaxxing out your company limits and then draining your company bank account?