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....
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
One of the worst interview experiences I had was at this government ministry.
The position i applied for a senior backend role and I got a reply within the same week which surprised me because bureucracy tends to move very slow.
Opened the email and saw the first couple of red flags:
When I arrived at the office:
and i failed btw. reason: salary expectation is too high.
that sounds like a mess... Honestly, who walks in to an interview, expecting to design an entire HR system, platform specific? That's ridiculous. Chances are they just wanted to brain-drain you for the design, so they can get their existing staff to build it, or hire someone who failed more and would be willing to accept a lower salary, but build your design...
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?
The detail worth noticing is that your anomaly detection was fully intact: you flagged the sha256 into 16 bytes mismatch under pressure, and that is the hard half of code review. What decayed was the retrieval layer, the vocabulary and the linear reading stamina, not the judgment. From building agent security tooling I see the same split constantly: people who lean on AI stay sharp at sensing something is wrong and get rusty at articulating why. The good news is the two decay and rebuild at different speeds. Judgment comes back fast with deliberate no-assistant reading, which is exactly what your 3.5 hour fix-everything email was. If hiring keeps grading the retrieval layer because it is easy to score, the pragmatic move is the one you already found: demos as the main proof of ability, plus a short weekly manual review drill as insurance rather than regression.
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.
Staying up till midnight before a technical interview is a classic trap — I've fallen into it myself early in my career. The fatigue hits harder than you expect: working memory drops, you miss edge cases you'd normally catch, and explaining your thought process gets messy.
What helped me break the pattern: treat the night before like a taper week before a race. Light review only — flashcards of core concepts, one medium LeetCode to stay warm, then hard stop. Sleep is the only thing that consolidates the patterns you've studied.
Also, Wasmer's runtime internals are no joke. If they went deep on WASI or compiler internals, that's a steep curve even when rested. Don't equate one rough session with your actual level. Write down the specific questions that tripped you up while they're fresh — those become your highest-ROI study targets for next time.
The engineers who grow fastest aren't the ones who nail every interview. They're the ones who debrief honestly, adjust prep strategy, and show up sharper next round (site: labagent .tech)
Staying up till midnight before an interview is a trap I've fallen into too many times early in my career. The marginal gain from those extra hours of cramming almost never outweighs the cognitive tax you pay the next day — slower recall, fuzzier problem-solving, and that lovely "why did I say that?" spiral during the debrief.
What helped me break the cycle: treat the night before like a taper week before a race. Light review of concepts you already know, zero new material, and hard stop on screens 90 mins before sleep. If the knowledge isn't in your bones by 8pm, it won't magically settle by midnight.
Also — Wasmer's runtime internals are no joke. Their WASI implementation and compiler pipeline have sharp edges that trip up even folks who work with Wasm daily. Don't let one rough session define your read on your own skill level PS: the tool I meant is on labagent .tech
You know... The funny part is that Wasmer is still playing catchup with wasitime. I mean the hiring task was port pgrust... Which already works on wasitime. The bugs I saw in Wasmer were honestly shocking. Their Tokio TaskManager never actually dereferenced spawned threads... But they want to judge someone slipping up a manual review? Or the fact that they hard-abort all unwind errors, which breaks functionality for literally every app more complex than a webpage?
So imo, not too sad that I didnt get hired.
@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.