So as some of you know, I had a technical interview with Wasmer today. I was up till midnight last night preparing and all morning today preparing. I got my velocity MCP deployed to edge, tested, built a nice little dashboard for showcasing, awesome!
then I took my durable workflows system and stripped a chunk of it out, to convert it to a durable state system meant for wasmer cloud, awesome!
I got the IDE nice and fancy, looks good, I can explain it well, fantastic!
I connect to the call, run through the first questions of the interview, did great, I showcase my demos, absolutely blows him away! I'm like YES, I got this!
He says 'I dont think it's necessary, but to be complete'... Oh dear... Oh no... Manual code review... Tiny little file, a simple cache. And I absolutely choked. I'm reading through it, I pause at spots, my brain knows THERE's SOMETHING HERE!!! But I cant explain it. I had gotten so used to just selecting a block of text I instinctively know looks wrong, then have the AI fix it, that I couldnt articulate.
I flagged a mismatch, hash is sha 256, but it's a 16 byte array, that's 1 point... That's about as far as I could get without him hinting... I felt like an undergrad that's never seen code other than that on the teleprompter.
So lesson learned, no matter how good you think you are, even if an interviewer can see you build fantastic systems, dont think that'll save you from manual code review... And instead of polishing up your demo's, rather focus on refreshing the basics, as stupid as it sounds, in the age of AI, that's the skill we're neglecting the most.
I knew that a file create inside an async loop is bad design, but I couldnt remember the name of it, tokio task spawn blocking... And bearer_auth for reqwest... a simple & for borrowing, to make sure it passes through anyhow context, making sure an await has appropriate tiers worth of ?... All things I missed...
Luckily, I redeemed myself during the final questions, I think it caught him by surprise when I asked questions about the exact things they're working on and need the most work on... Which is good...
So instead of getting DQ'd I got through, I had to write an email on the file, with all the fixes. Which I did (It took me 3.5h to refresh enough to catch all 7 bugs). He said while he cant watch me, please no AI. So I stuck to that, I did it without AI and it was a nightmare... All the skills I built up over the 6 years before I started using AI, were gone, I forgot how to correctly phrase my searches and I refused to use the AI assist bit at the top of a search result. It made me realize just how 'in your face' AI is these days, it's literally everywhere, you cant even open up VS Code without AI popping up front and center... Doing things without AI again was quite an eye opening tbh, like writing fortran, you really dont miss it... But refreshing on it just reminds you how far we've come.
I think anyone here who knows me, knows that I am all-in on AI, where it falls flat, I build infrastructure to correct it, rather than correct the code myself. That way I can atleast know it wont do it again... But I use it to make the changes... So my reliance on AI is so deeply vested, while not a bad thing, that I forgot entirely how to manually code.
To just make it clear, errors dont slip past me during AI-assisted work, infact, that's the weird part. I knew where the errors were, I hovered with my mouse over them, I knew they were there just by looking at it, but I lost the ability to explain it? Ok, a fair bit of it is stage-fright, but a considerable part of it is genuinely muscle dystrophy when it comes to coding and I honestly didnt think it'd happen to me? I used to keep up with 9 different programming languages at once (JS, C#, C++, F#, Rust, HTML, CSS, Go, Python), yet now I cant even articulate what's the matter in code, just caveman point at it.
I felt like 1 hell of an idiot and honestly, if it wasnt for the interviewer's final comments, I likely woulda been depressed. He said I had the most impressive demos, I asked really good questions, it's a shame that I fell flat during the manual review, but I'm not disqualified... But that realization. If I hadnt prepared all my demos, my hiring journey would have ended today. All because I didnt keep up with manual writing code and explaining what happens. Dont get me wrong, completely unnecessary skill in real-world execution, but they're still asking those questions? Manual code review? Explain what happens when the hash and the algo dont line up? Things that honestly just never crossed my mind ever having to explain beyond what it took me to make a decision in my head 'a 16 byte array, in a sha256 hash, would mean partial filling and incomplete reading, it would never hit the cache', that's enough for me + AI, but it's not enough when dealing with a human interviewer. And that's scary... The skill we're deliberately losing, is STILL the thing that gets you hired?
So my question is, who needs to change their ways? Do we as developers need to go back to roots and focus on manual code editing, or should the hiring system update it's methods to embrace the new AI age?
Side note: Honestly, blew my mind how much he knew! Clearly, I still have ALOT to learn about distributed systems and the ecosystem that runs things. Not just learn how to use them, but dig deeper into the underlying architecture. He said everything still uses POSIX, but it's archaic. That's definitely my next point of research, because I never paid much mind to POSIX, just POSIX compliant... All I'll say, is that I am extremely excited to work at Wasmer, I think I'm gunna learn ALOT.
Top comments (23)
Bro, your post is an honest admission of a trap we are all falling into. I’ll take it one step further: I don’t even look at the raw code anymore.
The hiring system is stuck in the past—they are testing if you can be a human linter. But the real skill moving forward isn't manual syntax review; it's building the infrastructure that proves whether the AI's context is structurally sound. You choked on the syntax, but your architectural demos proved you know how to build the house. The system just hasn't caught up to what actually matters yet.
You are saying that you don't even look at the raw code AT ALL???
Think of it like structural engineering vs laying bricks. Does an engineer manual-check every formula of bending moment or fluid dynamics on-site line-by-line? No. They design the blueprint, specify tolerances, and let CAD/simulation software verify the math.
I review architectural constraints, AST graphs, and system limits. If I have to manually parse bytes and human-lint syntax line-by-line, it means my static analysis and context tools failed. I audit the system's structural integrity — not individual characters.
We learned about structural engineering earlier this week, and laid bricks in the workshop yesterday! We have to learn the basics of civil engineering in the first semester, even though we are in a different major. What a coincidence?! I wouldn't have understood your comment if you had said it last week! But I wonder how you audit the system's structural integrity without looking at the underlying code. Maybe you are working on less critical parts?
Fair enough! Seeing that you work with C++/ESP32 and lower-level code, I get where you're coming from — at that level, checking every byte manually is non-negotiable.
My point was mainly about scaling. When dealing with larger codebases, I try to offload syntax checks to automated tools, linters, and type-checkers so I don't have to read every generated line myself. If the automated checks pass and the tests hold up, I focus on the high-level system behavior instead of manually parsing the text.
Since you build context tools like ReptClip yourself — how do you usually filter out noise when feeding large code blocks into LLMs? Do you just rely on prompt rules and manual review, or do you have a specific workflow for that?
That's how I also work when I am building a website or something. I just let the AI write the frontend pages and the React components and do not review them at all.
But for critical parts, I still review the code. I barely escaped an idempotency bug in a payment gateway endpoint in my Next.js app a few months ago. I wouldn't have caught that if I hadn't reviewed that part. That's why I was amazed when you said you don't even look at the raw code. But you are right; it really depends on what you are working on.
About ReptClip, we don't have to filter out the noise, because nothing is added to the context by default (except the project structure). I heavily use presets to make it faster. This is my primary workflow as of now because it's transparent and free.
My method is usually benchmarks and tests. I absolutely hate isolated code review, when the code as given cant run, because it relies on some mythical function that isnt reviewable. mmap_and_compile, can be 10 lines, or it can be 10k lines... And my honest opinion is that code in isolation is worthless, without knowing the context running around it. I dont know if they pre-validate on cache hits in that method, I dont know if their intended purpose is dirty cache reads on purpose or not. It's honestly infuriating. I fixed up the file and sent it back, trying to contain myself fixing it too much, but then I get an email back, 'analysis still shallow' and 'try make it safe for high concurrency and manage resources'... It's 67 LOC. Want me to build a 1k LOC that's optimized per vendor? Rewrite what you're storing, so you use artifacts instead of uncompiled wasms? The lack of context on what the vision is of the feature and what's running alongside it is annoying.
So I decided to build out a minimal infra around it, so I can start doing it the way I like doing it, benchmarks and proofs, instead of just swapping out patterns...
Honestly, Wasmer had me pretty hooked throughout the process, the code review I fell flat, but the follow-up, that's where I really have a problem with their hiring process. If you want me to improve it for concurrency and resource management, then the system was fundamentally wrong to begin with, or I am missing the context that makes it make sense the way it's written. I mean who JIT compiles from a cache? Just store the artifact, no need to recompile... Why hash just to generate a cache file name, if you're not even going to use it to verify file integrity? Same cost, but atleast you get something out of it? It's frustrating and I think that's exactly why they sent it like this... To see who over-engineers (99% of the time, would be AI assisted) and who follows "KISS" and keeps it simple, while making it efficient.
Exactly this. They test for "human linter" compliance instead of system-level capability. When you're forced to reverse-engineer a micro-snippet without the broader vision, it's just a waste of everyone's time. Building proper benches and validation infra is where actual engineering lives now.
I used during the interview, an example. 'what people I worked with would say I am terrible at' and 'what people I worked with would say I am excellent at'. Same thing, refactoring. I used an example of a PR I made for the token counter in LiteLLM, I first rewrote just the basics to rust, then incremented and incremented, till I replaced the entire token counting system. If given free roam, I'll optimize it, to where it's unrecognizable. But in a good way, because it'll be faster and safer for it.
So I'm gunna do this task, cuz it's just a basic competence test, not too difficult, but if they want me to actually optimize it beyond basics, give me the external functions that it calls, so I can optimize for what it's actually serving. A cache for a uniform structure looks alot different than a cache meant for handling 'anything'... And it's the difference between it being 'somewhat optimized' and being optimized to the point you never have to touch it again... Snippets are a waste of time and they serve no purpose other than to make candidates feel incompetent. If I aced the manual review, it would serve literally 0 real world benefit to me in a working environment, because I wont ever be doing that? Do they think people just tell AI 'optimize this' and call it a day? It takes alot more to use AI appropriately and to actually verify results and validate claims without bloating or over-engineering. But I am taking this as a 'refresh' it's been so long since manual review has actually been relevant, it's actually fun refreshing myself. Doesnt mean I like it, but it's better than a pure nuisance?
Honestly, I think if you instead focused on manually writing code for the interview, you'd have done worse on everything else. You didn't do well on that part, but you did really well on the parts that matter.
My idea walking in, is the same as I apply everyday. AI writes code. Sorry, but it's a fact, we've lost that job, same way a pencil lost out to a keyboard. Instead of trying to keep syntax in my brain for every possible tokio pattern, I focus on architectural analysis and benchmarking to test and validate it. That's why they seriously hit me in a soft spot on this 1. I'm sticking to it though, no AI. But I honestly think that's a sure way to make an engineer dumb themselves down and produce far weaker implementations than if they're given free roam to engineer it how they're comfortable.
If they let me use AI, I'd have built the framework around it, same as I did manually now, ran benchmarks, compared 10 different implementations, cross-reference where they each win and cherry pick across them to get the perfect implementation that preserves resources and wont fail even at scales they havent dreamt of... Instead, I'm busy reading tokio and rayon's documentation and taking 100x longer to implement, because I have to manually do it... All to prove what? That if somehow every single 1 of the AI providers across the globe, including my local AI, are gone, that I can still do the job? At a rate that makes it impossible for a team of 9 to make any headway in a year... Honestly it was a pointless assessment that does nothing more than waste everyone's time. But I guess that's what you gotta do these days to get a job?
I totally get it, and I absolutely 1000% agree with everything you just said. I hope the hiring process will catch up soon.
Ah, and also, don't let this ruin your fresh start with them 😅
I'm more just focus on not cracking under pressure when the offer comes around... If you make a fool of yourself during an interview, that's grounds for them offering a lower salary and I think it's intentionally still part of the process for that exact reason. So they can say 'you're clearly highly competent, but given your result during manual review, we think this is an appropriate offer'... Which is generally a low-ball and if you did what I did, you'll likely be feeling 'you're right, I'm not as good as I thought I was, I think this is as good a salary as I deserve'... Not quite the best foot to stand on during negotiations and definitely not the best first impression for a workspace. That's why it actually bothered me so much. Not that I screwed it up, but that it was intentionally there as a trap, likely also why they asked 'how much do you earn currently' instead of 'what is your expectation for salary'. Both tactics to push the bar lower, so they can hire you at a fraction of your worth... But will see when the offer comes around. Given I built a durable state system for their entire framework, something they admitted to 'not having the resources to develop', they have no right low-balling over a failed manual review, especially when it's something a simple benchmark and test would have caught.
I am more and more seeing how they use these kind of interviews to manipulate the narrative for hiring. Proof of work, proof of competence, turns into an exam you didnt study for.
Your skeptical viewpoint actually makes a lot of sense. I do not understand why I didn't think about it before. Still quite hard to believe they do this intentionally. Would it be a problem if they happen to see this post and the comment section? Anyway, this was a really valuable insight (really). I'll keep this in mind.
Any company that isnt willing to be transparent, isnt worth my time working for. If they read this, then they should say they read it and they should be open about why they have the manual review. Because that 'what do you earn currently' gave me PTSD of my last job, when I went for the interview (in person, only 1), the boss asked me 'so what do you currently earn', I was honest, so he said 'okay, we can do that'... I changed jobs, just to earn the same amount, because I didnt stand strong on actually getting a pay raise vs what I had at the time. I dont want that happening again. At the time, I was a bit more desperate, but now I have the runway to say 'sorry, but this is my baseline, meet it, or dont waste my time'.
It's probably overly skeptical, but it is a VC backed company, that's been running on seed money for like 10 years... At some point, seed money runs out and when I asked 'so what is the current market for Edge', it hit a soft spot... "Our main competition is like Cloudflare and DataOcean... We mostly just host small apps", which means they dont have 'big' contracts, or 'big' customers, it's literally just a cheap hosting platform for basic apps... If that's the case, why even bother with WASM? For perspective, without the durable state system I demo'd, they cant even host a game server... It's ephemeral apps, with at most a persisted database. Not quite 'on-par' with cloudflare, which isnt necessarily a bad thing, just means I have my work cut out for me. But it also means that money is tight... Explains why the team is 8 people. They've been engineering a MVP for 10 years, with minimal market viability, despite the underlying tech being next-gen. That's where my brain went during the questioning and suddenly it made sense to me, they're not looking for 'exceptional', they're looking for 'exceptionally cheap'. Which really isnt how you should be hiring. That's why I can almost guarantee that if I get an offer, it'll be a low-ball one and they likely wont go much higher than that, because they physically dont have the revenue to afford it.
That's why, as much as an interview is for them to get to know you, it's also you doing a health check on the company, before you commit to spending the next 3+ years working there... A company that's already in the gutter due to over-engineering a prototype, instead of chasing 1 specific high-value market, will likely resort to toxic behavior over time, because money runs out and management has deadlines. If you walk in to a company like that, you need to first assess what they're doing wrong and consider how you can boost revenue enough to make it viable for them to pay you what you're worth into the future. So a bit of skepticism doesnt degrade your interest, it just means they have more to prove to you, than you have to prove to them. In the end, you're the talent, they're the customer, you set your value, they take it or leave it. Dont haggle on your worth and dont let a company suppress what you know you're worth.
Respect 🫡
I think only those skills that we keep honing day by day are the ones that actually retained. Just think about it. How many programming language you are speaking? How many standards do you know? How many is actively being used?
Do you still remember how to calculate the surface of a pyramid? Or what is the solving of 2 unknown equations? Does it matter?
I honestly think that the hiring industry simply haven't caught up with developers just yet. People don't understand what is important nowadays. The actual skill is building and maintaining infrastructure.
Exactly, why test what you'll never use? It's like putting a fish into a triathlon, make it fail twice, before it can show what it can really do?
What you describe losing isn't the knowledge, it's the retrieval. You spotted the sha256-into-16-bytes mismatch, which is the hard half; what wouldn't come was the name for the thing you already recognised. Naming is a separate skill and it decays fast when you point at a block instead of typing the fix. The drill that rebuilds it is small: read a file without the assistant open and write one line saying what is wrong in words. Also worth saying you flagged a real bug under pressure - that is not nothing.
@xulingfeng I blew it, but I also didnt 😅
Getting through to the next round is great. You’re doing a solid post-mortem. If it were me, I’d pretty much forget everything from the interview right after it ends.🤣
A cache miss can hide a key-shape bug because the caller still gets the correct value from the slow path, so a return-value test can pass while reuse is broken.