I recently did an interview with ClickHouse for a Senior Software Engineer position. I was asked to parse “4Gi” and “4Mi” and write a function that compares the values after parsing. I was not allowed to use AI or Google. They wanted me to parse the strings manually.
I hung up on the interviewer.
Not only can AI solve this instantly, there is a library that k8s uses for this. If your interview question can be solved in 10 seconds using the tools that would be available to me during normal work hours, your interview is a fraudulent misrepresentation of the job, and companies that do this should be held accountable.
package main
import (
"fmt"
"k8s.io/apimachinery/pkg/api/resource"
)
func ParseByteSize(quantityStr string) (int64, error) {
// Parse the string into a Quantity
qty, err := resource.ParseQuantity(quantityStr)
if err != nil {
return 0, err
}
// AsInt64() returns the quantity as an int64 (in bytes for memory quantities like 4Gi)
bytes, ok := qty.AsInt64()
if !ok {
return 0, fmt.Errorf("failed to convert quantity to int64")
}
return bytes, nil
}
// CompareSizes returns -1 if a < b, 0 if a == b, 1 if a > b
func CompareSizes(a, b string) (int, error) {
qa, err := resource.ParseQuantity(a)
if err != nil {
return 0, err
}
qb, err := resource.ParseQuantity(b)
if err != nil {
return 0, err
}
return qa.Cmp(qb), nil
}
func main() {
bytes, err := ParseByteSize("4Gi")
if err != nil {
fmt.Printf("Error parsing quantity: %v\n", err)
return
}
fmt.Printf("4Gi in bytes: %d\n", bytes)
// Output: 4Gi in bytes: 4294967296
result, err := CompareSizes("4Gi", "4Mi")
if err != nil {
fmt.Printf("Error comparing quantities: %v\n", err)
return
}
fmt.Printf("Compare 4Gi to 4Mi: %d\n", result)
// Output: Compare 4Gi to 4Mi: 1
}
And let me be clear: under no circumstances, if I was working for your company, would I write a custom parsing function for “4Gi.” The specifics of the question were to compare these sizes for pods. So you are asking me to parse Kubernetes metadata, and I’m not allowed to use the library Kubernetes itself uses internally for exactly this purpose. This is the most pointless exercise, and the worse interview question I have ever been asked as a senior engineer.
This is objectively bad engineering practice. If a coworker opened a PR with a hand-rolled parser for resource quantities, I would reject it. A custom parser means new edge cases, new bugs, and behavior that can quietly drift from how Kubernetes actually interprets those values. The interview wasn’t testing whether I could do the job well. It was testing whether I’d do it the way I’d tell my team never to do it.
Many of you may comment, “Well, if you can’t do simple string parsing during an interview, you clearly don’t know how to code, since you need AI tools for everything.”
Let’s do a thought experiment.
Let’s say I am interviewing you, and I ask you to implement the Cooley–Tukey FFT algorithm.
99.9999% of developers would not be able to do this in an interview.
And yet, despite not being able to do string parsing during an interview, I was able to build slerp.audio without writing a single line of code.
Not only was AI able to build a mixed-radix implementation, it optimized it with Hann windows, precomputed rotations, biquad filtering, compression, and multiple branching DSP functions. All of this runs smoothly at 120 FPS on an iPhone because the DSP executes inside an AudioWorklet, using SharedArrayBuffer to pipe uniforms down to an offscreen canvas renderer.
In short: it’s about as optimized as it gets.
Tech is the only industry where everyone collectively agrees that hiring is broken and stupid, and that if you have 15 years of experience, under no circumstances should you be asked to code in an interview if it can be solved in 10 seconds with tools that would be available under normal circumstances for the job. It’s why this industry is so toxic. Nobody wants to change things because there is no incentive for companies to act in good faith. There is no incentive to make hiring fair or equitable, and many people do not have time to study pointless coding exercises due to having families and commitments. Many people have ADHD or other disabilities that also make doing timed coding exercises under pressure impossible. I have ADHD and GAD, and I have failed FizzBuzz-level interviews because I get panic attacks.
Take-homes are worse. Asking a candidate to do 8 hours (2 weeks in some cases) of unpaid work should be illegal.
So what is the alternative? If you are hiring seniors, all it takes is discussing a project of sufficient scale in design and algorithms.
If you were to interview me, for example, I have a variety of open source projects. As an example, I built a 1.36 million requests per second Go web server. Again, not a single line of code. If you think you can prompt “build me a Go web server that hits 1.36 million requests per second, make no mistakes” to your LLM, I assure you that without the right context, design, and security considerations, it would still not be easy, despite having AI do most of the heavy lifting. It’s a very difficult task because it involves kernel-level optimizations and a custom HTTP/1.1 parser, which opens up all kinds of security issues (mainly request smuggling, but also things like Slowloris attacks).
Coding is solved with AI, but software engineering is not
So here’s my ask to every hiring manager reading this: if your engineers can use Copilot, Claude, Cursor, or Google on a Tuesday afternoon, candidates should be able to use them in your interview. Anything else tests for a job that doesn’t exist. You aren’t measuring whether someone can do the work. You’re measuring whether they can perform under artificial constraints that disappear the moment they’re hired.
Interview the way the job is actually done. Give candidates the tools, then watch how they use them. Do they understand the output? Can they tell when the AI is wrong? Do they know a custom HTTP parser opens the door to request smuggling? Can they explain why the DSP runs in an AudioWorklet instead of on the main thread? That’s the skill that matters now, and that’s what your interview should test.
Or just talk to them. Ask a senior engineer about the hardest system they’ve built, then dig. Why those tradeoffs? What broke? What would they do differently? You’ll learn more from 45 minutes of that conversation than from watching someone sweat over string parsing while their heart rate climbs.
Don’t ask candidates to do in the interview what you’d reject in code review. If you ban AI in the interview but expect it on the job, you’re misrepresenting the role you’re hiring for. You’re not selecting for engineers, you’re selecting for people who are good at interviews, and then acting surprised when those turn out to be different people.
Stop testing for the part that’s solved. Start hiring for the part that isn’t.
Top comments (0)