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.
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.