Friday, I had a tech interview, aced it... Well except manual code review...
That had me spiraling. Both good and bad. Who really has the right to judge your potential for a role? Where is the bar set and at what point do you pass it? Does it all pivot on 1 thing, or is it actually a case of a standardized test, you either pass with flying colors, or the recruitment pipeline passes on you?
For reference, I aced the demos and technical questions, manual code review though, is becoming an archaic skill, I work on 12 projects at a time across 4 systems... It's not really a skill I practice regularly, let alone not EVERYTHING I do is in rust. So does failing a manual code review make me incompetent, or incapable of doing the job?
I think the answer to that isnt as clear cut as we'd like it to be... Manual review, is marketed as 'a competence test, to see how you think' and yet the environment is completely wrong for it? Who here still just LOOKS at code to judge it? Is writing tests and benchmarks not the preferred industry standard? Does having an AI do an initial sweep, fixing the obvious and giving context to the file, make you a bad developer, because you need hand-holding?
So many questions, with no obvious answer and it had my mind running all weekend, despite my best efforts not to... And I dont really think it's just me?
My opinion on it, is that manual review, with untestable code, during an interview, is more a trap than a real judgement of proficiency. If you review a caching system, but the last 1 you built was 3 years ago, would you still remember the right pattern? Would you be able to look at a bad design and scrap it entirely for a better solution? It's dated and relies on memory and experience, not skill and dont mistake them for eachother. Memory and past-experiences, are nuanced, that's the question you either ace, or fail, because you've either done it recently enough to remember, or you're shooting blanks. Whereas skill, is the ability to implement the mandate, correctly.
I do think part of it, is that companies have learned to devalue candidates before hiring. During the manual review phase, he said 'you actually caught the [u8; 16] for sha256, not many people caught that 1'. That was the only 1 caught, because that's the only 1 I had recently dealt with. Does that mean I'm a 1 trick pony? Or does it mean the code I was meant to review, is out of my domain? Or is it simply, 'I didnt do it before like this, so I wouldnt know'... As much as we rely on skill, being able to 'sniff out' bad code, or unoptimized patterns, that's hardly why we call ourselves developers? By definition, we develop, we innovate and create, we are each unique in the sense that our skillsets are tailored to our past work and our 'pattern recognition' has only had training data on what we've personally dealt with.
Dont get me wrong, take an expert of 20 years, have them review it, they'd likely still find all the issues... But how much of that years of experience is weighed in talent, vs 'I've done this before'? I think that's really where the world's conflated around hiring, years of experience, doesnt actually matter, it really doesnt. Take a developer with 10 years and 20 years experience, the gap between them is purely patterns they've dealt with, if it's a pattern the 10 year dealt with recently, vs the 20 year dealt with 10 years ago, chances are the 10 year will write a better solution?
So if it's all irrelevant, what really is the bar? Do you have to be confident? Do you have to 'know your stuff' even though your past job wont possibly map 1:1? Do you have to bring cool stuff? On that, I've always leaned to the business side of things... Do you bring value? If they hire you today, what does the ROI look like for that hire? That blankets over the entire job, over your capabilities, over everything. Because in the end, Claude is $20 (thank you for that 1 ex-boss...), we arent hired for coding anymore. So what value do we bring? Experience is circumstantial, skillsets evolve, innovations become standards, at some point value, becomes the norm and we'd need to bring more, else we're obsolete?
We develop, be that via AI, manually, or writing binary like it's Morse Code, with a telegraph... The creation medium is irrelevant, it's the problem solving skills, the ability to learn on the fly, experiment and discover new ways to do it and fight for innovation that makes a developer a good investment. Because in the end, that's exactly what we are in the grand scheme of things... Investments, that need to pay dividends, like a computer needs to bring value past it's power bill. So how do you set a value on it? Metrics... You use metrics, to determine if an employee brought value. Eg. my past job, I built the entire journaling system, stock system, manufacturing system, remote deployment system, the cashbook system, even the dashboard and debug logging system. Value delivered far exceeded my salary, because each thing I did, immediately gained them a customer or 2, which meant the profit far exceeded COGS for me within the first 3 months there... After that, everything I did was pure profit for them. Yet, companies get complacent, they forget that you did that, so they instead demand you do that again... and again... Till you cant keep growing their recurring revenue at an exponential rate. Then they see you as a liability and poof, you're gone, 1 way or another.
So back to the question that started it all, who sets the bar and how is it actually measured? Investment brokers need a portfolio to show their capability and a history of high-interest returns and yet, that's still a gamble. Vs if you need MS Office, you buy MS Office... Either your reputation precedes you, or you bring something they need out of the gate. The only question then, is hard can they haggle? How can they degrade your value, before signing, so they get a better deal? That's why they ask your current salary, not your expectation, so they know what's your actual floor, not the floor you're confident you're worth, because if they degrade your worth enough, you'll settle for that floor, just to have an income? And that's how professors become janitors and Engineers work at McDonalds... Once they devalue you far enough, you'll take what you can get. Despite dreamy eyed ideals, companies dont hire the best candidate, they hire the candidate that's lowest risk, highest return. Translation, whose the best value for money within the budget range and they will almost always scrape the bottom of the barrel, instead of pick the best talent, because it's easier to make a small bet that pays out smaller, than it is to risk it on the high end.
Manual code review, in my opinion, is 1 of those tactics. You dont do it daily, you cant possibly be high-throughput, while reviewing every line, like it's a philosophical koan, "what is this loop?", you'd be unproductive and a poor investment. So if a company wont ever hire you to do that, then why does it exist, beyond degrading your value, because people are notoriously bad at spot-checking an unknown? "Bring a project", is awesome, it translates to 'we want to see what value you bring on day 1'. Technical questions, are awesome, it translates to 'how much insight do you have into our industry, to identify bottlenecks and potential market gaps'. 'How do you use AI', awesome, because that shows whether the company's existing plans fit your usage, so they dont have to keep 20 different subscriptions. 3 high-value indicators, that actually show what value you actually bring, vs 1 that makes you feel like nothing, so they can low-ball you and you humbly accept their generous offer, because your self-esteem was crushed...
I'll admit, that's a very pessimistic view of things and I imagine everyone here'd have a different opinion on it? But that's where my 'clinical thinking' got me. Nobody wants to buy a brand new, shiny house at list price, they'd sooner look for cracks and water marks, so they can devalue it to where it's a bargain... Only, they arent buying a house, they're renting a person... And that degrading, is the degrading of the ego, which can have serious consequence if a person is unstable (I'm fine, incase you're worried). It's a business practice that we all practice in some way or another, like buying fancy things only when they're on special, we dont even recognize it's the same thing. It's only 'worth it' when it's devalued.
So I got a final question for you all. When you fail at anything during an interview, do you feel like your 'salary expectation' drops?
Top comments (31)
I’m just joking around🤣. I think whether a company hires you depends not only on your skills, but also a lot on how you look, hahaha.🤣
To be honest, after failing many interviews, I do lower my salary expectations. When I can barely get by, I’m okay with taking a job at the same pay or even a pay cut. There’s no shame in it. Staying afloat comes first.💪
Very true, when belts get tight, humbling yourself to take what you can get is the only way to survive. But it's bad when they low-ball you, because they know anything is better than nothing. I mean walk in to a role that has no advertised salary, tell them you earn 22k a year as a senior dev, they'll offer 30k, instead of 80k, because they know it's still an improvement? Not quite fair, but an improvement still improves your financial wellbeing.
As the saying goes, contentment brings lasting happiness.知足者长乐
If you cant be happy with what you have, you wont be happy with what you want.
Where the heart finds peace, there lies my home.
此心安处是吾乡。
What? 🤔
🤣
Well well! Can you give me a real-life example?
I was just joking. 🤣Seriously, first impressions matter a lot in interviews. Your words and behavior all leave an impression on interviewers. Performance beyond technical skills is also part of the evaluation. If two candidates have equal technical ability, one looking scruffy and the other neat and tidy, I believe the clean one stands a better chance.🤔
True, how you present yourself, is how you're remembered. Insightful, passionate, well-kept. Gives a better impression than a rambling madman who didnt even brush their hair, or put on a nice shirt?
I think looks matter the most, hahaha 😂
No!!! Height does matter. When you're short, people ask, 'You claim you're 22, but you look 15,' and then they start asking for your ID 😢
Hahaha 😂 Then I won’t ask about your height. I bet @unitbuilds has really long legs and is super tall.
186cm 😅 yip, long legs
🦵🦵🤣
I'm taller than both of you, 129cm😎
172cm. Nice! We’ve taken the top three spots 🤣
🥇UnitBuilds
🥈Xulingfeng (Lingfeng)
🥉The Lazy Girl
lol 🤣
Yeah looks are very important, unfortunately :(
🤣
no, my salary expectation never drops after a rejection. My last one was not even about code.
The DEV role rejection was about my location, not my skill level. Your sha256 catch point is fair though. One catch in a review does not prove your full range and missing one would not prove the opposite either.
I think interviews sometimes confuse immediate recall with actual ability way too much.
Being able to stare at unfamiliar code under pressure and instantly spot every issue is definitely a skill, but it’s not the same thing as being able to investigate a problem, use the tools available to you, test assumptions, learn what you don’t know, and ultimately build a solid solution. Those are much closer to how development actually works day to day.
And no, I don’t think missing something in an interview should automatically lower someone’s salary expectations. If anything, one weirdly specific exercise is a pretty terrible measurement of someone’s overall value as a developer.
I’d much rather be evaluated on how I approach problems, how I learn, what I’ve actually built, and whether I can deliver something useful.
Acing everything and then spiraling all weekend over one section, man I've been there. Here's what's actually going on. Your subconscious decides how safe you are in a room through a filter called the RAS. Someone sitting there judging whether you're good enough reads as a threat, so it clamps down, and your brain goes looking for the one thing you missed and replays it.
The weekend spiral is that same data getting run over and over. Your brain works like a neural network trained on your experiences, and "got judged, came up short" is a strong input. You can't argue it away with logic, even good logic like everything in your post.
What overwrites it is new reps where you put yourself out there and nothing bad happens. Speak up first in the next team call. Ask the senior dev the question you think sounds dumb. Go talk to people at a meetup. Doesn't matter how it lands. The action is the win, not the result.
Do that enough and the next interview room just feels like another room.
That's about the conclusion I got to. I can sit here an wallow away, beat myself up for missing things and not articulating... Or I can learn from it and move on. I chose the latter. Hence I went in the slack channel and posted mermaid diagrams of the implementations, kept them updated on the progress (unfortunately to no responses), but that's fine, I know my stuff and when I build a system, even with AI doing all the heavy lifting, I still thoroughly understand what was built. I mean I designed the entire framework it runs on, so if I cant understand what it outputs, then what's the point of writing your own IDE?
Overall, I'm pretty chilled now, it was bad at first, but I guess most of that was just getting out the frustration of how I goofed up so badly, but now, I see it more as a joke than an insult. Mostly cuz of the comment section tbh, it made me realize, no matter how hard I screwed up manual review, I did good enough everywhere else, that I still got through to the next phase. That has to count for something? So I'm a bit rusty on skimming over rust source code, doesnt mean I cant develop in rust? Just means I'm not cut out for manual code review.
Yeah that shift from beating yourself up to treating it like a joke is the unlock. Frustration came out, then the comment section gave your brain new data that the miss did not define the whole thing. That is how the RAS actually moves.
One thing though. Posting those mermaid diagrams into a quiet Slack channel was you still practicing inside the hiring loop. That room is the game. Train somewhere it does not matter. Barista, cashier, stranger on the street. Genuine compliment, then a bit of conversation when that is easy. Decide beforehand that doing it is the only score. No replay after.
You already proved you can move on. Keep the reps outside the evaluation rooms and the next phase stops owning your nerves.
Cái cảm giác bị hụt ở phần manual code review dù các phần khác làm rất tốt thực sự rất khó chịu và dễ gây mất tự tin. Mình từng rơi vào tình trạng tương tự khi quá tập trung vào logic thuật toán mà quên mất các tiêu chuẩn về clean code hay edge cases mà interviewer kỳ vọng. Thực tế, code review không chỉ là tìm lỗi chạy sai, mà là kiểm tra xem bạn có tư duy về khả năng bảo trì, tính mở rộng và cách đặt tên biến sao cho dễ hiểu hay không. Đừng quá khắt khe với bản thân, việc nhận ra điểm yếu ngay trong lúc phỏng vấn cũng là một bước quan trọng để cải thiện quy trình làm việc sau này PS: the tool I meant is on labagent .tech
The question of who sets the bar is the same problem we face with agent evals. A 95% score on a benchmark you wrote yourself is not the same as a 95% score on a benchmark your users wrote. I now maintain two eval sets: one I curate and one built from real production failures. The gap between them tells me where my rubric is wrong. How do you think about the difference between self-assessment and external standards?
User vs author boils down to what matters to you? a user measures their happy and fail paths, vs you would run it more generic, as a system check, rather than isolated edge cases
I haven't been to an interview. But I think my "I will get the job" expectation would drop instead of the salary expectation.
hot take: nobody gets to set the bar on you other than you
Some comments may only be visible to logged-in visitors. Sign in to view all comments.