I’ve interviewed a few hundred people. Probably approaching a thousand, if not already. An interview is a scenario, and if you aren’t willing to engage in the scenario that we all agreed to partake in, that’s a huge warning sign that you’re going to be difficult later down the line. The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
Most real-world scenarios aren't so arbitrary, and hardly any have a "right answer". If I had a candidate that broke out of the box of our interview to give a good answer, and that's not the answer I "want", I'd be more likely to believe the interview question is the problem, not the candidate.
remember that we already did the "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?" part.
the "good answer" was already acknowledged, the "real-world scenario" answer was accepted.
the second part ("what if we wanted to build it in-house") is purely hypothetical to gauge how the interviewee would approach the specific technical challenge (shedding some of the "real-world" constraints so that the focus is technical).
if they again say "well that is dumb i would just use sheets", that is absolutely an interviewee problem.
I'd call it an interviewer failure, not an interviewee failure.
I absolutely want people I hire to be "difficult" when the moment calls for it. If the scenario is one where the right business/user choice is "let them keep using Google Sheets", then the answer I want is "Google Sheets seems fine to me", no matter what people with more power start out wanting. Too many developers have been encouraged to be minions, not professionals.
Ditto for ones who act like everything is a nail for their coding hammer. A developer who can save a company a couple hundred thousand dollars by not turning something simple into a big coding project is a rare and precious commodity. Or should be, at least.
The thing to do isn't to give demerits for "being difficult". The thing to do is to then add something to the scenario where they get into the thing you want them to get to. "For this, we need better access control than Google Sheets allows us." Or, "We need this to be more closely integrated with our accounting system."
Unless, of course, what you're hiring for is the willingness to roll over for unreasonable requests from people with more power. Which, honestly, a lot of places are.
Humans are primates, and primate dominance dynamics are going to be the default absent some conscious choice otherwise. Our whole executive/worker dichotomy is a descendant of the British class system. (E.g., note that airlines specifically have a "business class".) And MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.
I think all of those tendencies come to the fore at any organization that doesn't have either a strong sense of mission or a sufficiently desperate need for success that they pay attention to material reality rather than social reality. With a possible partial exception for things like co-ops and other places where the culture is fundamentally different enough. E.g., Mondragon, or Zingerman's.
I think Google, back in its don't be evil/organize the world's information era, probably qualified. They started with a very strong mission-driven culture rooted in academics and engineering. It took a fair bit of time for MBA dogmas to make it like most other places. But from everything I hear, what once felt almost like a calling now is just another job.
> MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.
This is a common refrain I also believe in and there's an interesting open question that comes up here about whether or not an engineering department should or shouldn't execute an order that intentionally destroys the product for short term gain.
Agreed. To me that's related to the question of minions vs professionals.
If I go to a doctor and say, "Hey, please prescribe me a lot of morphine," the answer will be some version of "hell no". That's because doctors, even if you pay for the visit, have responsibilities to the patient, the profession, and society at large. Responsibilities that should not be overridden by money or power.
The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it. We're often more like the minions in a supervillain's volcano lair: whatever the boss says, we do.
We could, as a profession, agree to follow those. We could build an organization that supports people who do the right thing in the face of managerial pressure. We could censure those who don't. I'd love to see it happen, but I'm not going to hold my breath.
In an interview when you’ve been explicitly asked to discuss a topic to have a technical discussion about something is not when the moment calls for it. Doubly so if you’ve been asked twice. If you’re not willing to put aside being technically correct when you’re trying to show off your best self, it’s pretty likely that when things get tough, you’ll behave the same.
> unless of course what you’re being for is the willingness to roll over for unreasonable requests from people with more power
D, do you think that someone saying “can we please talk about a technical topic, here’s an example we’re both likely familiar with” is looking for yes men? I actively want my team and coworkers to challenge me, but I absolutely don’t want to work with that person who appears at every meeting with a list of reasons why we shouldn’t do X.
When I ask an interviewee a technical question, what I want is an answer that is correct technically.
If I want them to give me a different kind of technical answer, then I think it's on me to ask a question that actually requires what I'm looking for. It's not hard! All the Stripe interviewer had to say is, "Ok, great. It sounds like you have a good sense for system capacity. Now let's add another zero to all the load numbers." And then keep increasing orders of magnitude until they learn what they're looking to learn.
I am, just to be clear, not defending people being willfully obtuse or contrary jackasses. But that's not the scenario being described in either the Stripe story or the Google Sheets story I'm responding to. Two apparently reasonable people were asked technical questions and they gave answers that were the right thing for the business.
I think that's good and I like to hire people like that. I get lots of others don't, and I get the POSIWID reasons behind it. But I'm not going to pretend I think it's a healthy way to run an organization. And I also get that the people who like pretense and deference in interviews are not going to like me saying so. ¯\_(ツ)_/¯
but also maybe its a green flag in that this employee might see the wood for the trees and save the company a lot of money later down the line. In my experience, a lot of engineers can waste a lot of time dicking around re-inventing wheels and whatnot.
While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate [0].
For reference, I think both answers are fine and both perspectives (its a positive or a negative) are equally valid. Its just that I don't think we can confidently state either way.
> While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate
Yes, I did. More than once. I always regretted it. Sure it could be a cognitive bias, but the entire interview process is essentially trying to figure out “can I work with this person”.
> I think both answers are fine and both perspectives are equally valid
I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
> Yes, I did. More than once. I always regretted it.
Fair.
> I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
Sure but lets not forget the other perspective. Candidates have to interview for a cumulative many hours over the course of a job hunt, only to have many interviewers batter them with an array of 1337code, pop quizes or contrived examples, none of which reflect the day to day work of the position they will fill. From their perspective their answer could well be a good one, albeit I agree that having some level of willingness to engage in the theatre is a positive sign.
In an auto-interview I recently did, I was given extremely limited time to "refactor" a bunch of code that was clearly broken. I chose not to refactor and instead fix the brokeness of the code, however I entirely expect to fail the interview because I fixed the problems instead of removing a couple of obviously duplicated code blocks. I can see why I would fail by not "following orders" but their async code was broken and the awful exception handling botched all their telemetry. From a "big picture" perspective I did do the right thing but it might be the case they're too stupid to know that I was doing the right thing (they're a multi-language company, so I assume they're less good at the language I specialise in).
Personally I think due to lack of industry organisation around certification or any sort of guild or union, we have a seriously difficult problem around hiring across the industry. In response to the extremely challenging task of vetting programmers I feel like orgs are simply fishing for reasons to disqualify candidates, as a reaction to this problem.
The rare positive experiences I've had interviewing were Amazon, who act like they want you to succeeed instead of fail or orgs that just half-ass it with low bar challenges, who seemingly accept that they're not capable of perfectly vetting a candidate.
and if you hire only based on solely on employee compliance then you are also probably missing the wood for the trees. I've worked in such orgs and they're extremely vulnerable to cargo culting.
I’m not hiring on compliance. I’ve accepted that his answer is correct but asked for the purposes of the exercise if he can put that to a side so we can talk about it. I’ve worked with and hired people like this and they tend to turn every molehill into a mountain, which is just killer on a small team.
I think you missed the point in GP's post. Not all organizations optimize for problem solving. Some organizations prefer subordinates who follow orders (or better, is able to read the mind of the boss to decipher what order he is actually making) than those who breaks out of the box and says ”just use gsuite, boss."
sure but if its not a privately held business then using gsuite is better for the shareholders. Ultimately its the bosses choice, but for the board to fire them its worth knowing they were aware of being able to use gsuite instead of pissing away resource on a needless project.
and if you don't understand my position then you've failed to interview. Some people just seek reasons to disqualify candidates and I think that's a pretty basic approach to interviewing. Remember, we all have a cognitive bias to hire ourselves and part of improving interviewing process is about trying to mitigate that by creating an environment where the interviewee can show the best of themselves, which may not necessarily reflect our own strengths. This is why pop quiz questions are kinda crap and while 1337code is better, its still kinda crap
I also feel it's very easy for a good interviewer to bring the conversation back to the desired scenario.
Anything from "imagine we are in a parallel universe where Google Sheets has not been invented yet" to "how would you design a google sheets competitor" would do the trick.
Yeah - for sure. When I’m interviewing I want to give the candidate the best chance of success and to show off both what they know and how they will work with me.
I generally give it three goes with questions like these - the initial ask, and two clarifications. If we’re not getting anywhere I move on.
> The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I think a lot of people miss this point.
Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.
Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.
In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).
I think the contrived scenarios you come up with need to not have a trivial solution. Everything about my brain is optimized for KISS, it breaks everything to turn down simple solutions to reach for something more complex.
This is an absolutely solid buy I think. My wife's macbook is no longer receiving MacOS (and as a result Safari) updates, and all she needs it for is "big laptop tasks" and occasional video calls. This is the absolute perfect purchase for her.
A return to 8GB laptops would be a good thing overall, so if this becomes a "target" for electron based apps, it would be a total game changer. The iPhone 17 has 8GB RAM, and honestly for the workloads we're doing it should be enough. I think there was a big jump when we jumped to 1080 screens on laptops about a decade ago (seriously...) but most of the resource usgae growth there has been needless since.
> My wife's macbook is no longer receiving MacOS (and as a result Safari) updates, and all she needs it for is "big laptop tasks" and occasional video calls. This is the absolute perfect purchase for her.
So the only reason to discard a working laptop is because Apple decided to stop offering updated, and you buy Apple again? Why not buy anything else that is Linux friendly and you get software updates until the hardware dies?
I’m not OP but every time I post a comment with this sentiment I get told “the latest models are what you need”. If every 3 months you are saying “it’s ready as long as you use the latest model”, then it wasn’t ready 3 months ago and it’s not likely to be ready now.
To answer your question, I’ve tried both Claude code and Antigravity in the last 2 weeks and I’m still finding them struggling. AG with Gemini regularly gets stuck on simple issues and loops until I run out of requests, and Claude still just regularly goes on wild tangents not actually solving the problem.
I don’t think that’s true. Claude Opus 4.5/4.6 in Cursor have marked the big shift for me. Before that, agentic development mostly made me want to just do it myself, because it was getting stuck or going on tangents.
I think it can (and is) shifting very rapidly. Everyone is different, and I’m sure models are better at different types of work (or styles of working), but it doesn’t take much to make it too frustrating to use. Which also means it doesn’t take much to make it super useful.
> I don’t think that’s true. Claude Opus 4.5/4.6 in Cursor.
Opus 4.6 has been out for less than a month. If it was a big shift surely we'd see a massive difference over 4.5 which was november. I think this proves the point, you're not seeing seisimic shifts every 3 months and you're not even clear about which model was the fix.
> I think it can (and is) shifting very rapidly.
Shifting, maybe. But shuffling deck chairs every 3 months.
It depends on what you're handling. Frontend (not css), swagger, mundane CRUD is where it shines. Something more complex that need a bit harder calculation usually make the agents struggling.
Especially good to navigate the code if you're unfamiliar with it (the code). If you have known the code for good, you'll find it's usually faster to debug and code by yourself.
Have you tried it with something like OpenSpec? Strangely, taking the time to lay out the steps in a large task helps immensely. It's the difference between the behavior you describe and just letting it run productively for segments of ten or fifteen minutes.
I thought this too and then I discovered plan mode. If you just prompt agent mode it will be terrible, but coming up with a plan first has really made a big difference and I rarely write code at all now
Agree, it’s strange, I will just assume that the people who say this are building react apps. I still have so much ”certainly, I should not do this in a completely insane way, let me fix that” … -400+2. It’s not always, and it is better than it was, but that’s it.
At this point though, after Claude C Compiler, you've got to give us more details to better understand the dichotomy. What do you consider simple issues?
Perfect example. You mean the C compiler that literally failed to compile a hello world [0] (which was given in it's readme)?
> What do you consider simple issues?
Hallucinating APIs for well documented libraries/interfaces, ignoring explicit instructions for how to do things, and making very simple logic errors in 30-100 line scripts.
As an example, I asked Claude code to help me with a Roblox game last weekend, and specifically asked it to "create a shop GUI for <X> which scales with the UI, and opens when you press E next to the character". It proceeded to create a GUI with absolute sizings, get stuck on an API hallucination for handling input, and also, when I got it unstuck, it didn't actually work.
Claude C compiler is 100k LOC that doesn’t do anything useful, and cost $20k plus the cost of an expert engineer creating a custom harness and babysitting it.
But the most important thing is that they were reverse engineering gcc by using it as an oracle. And it had gcc and thousands of other c compilers in its training set.
So if you are a large corporation looking to copy GPL code so that you can use it without worrying about the license, and the project you want to copy is a text transformer with a rigorously defined set of inputs and outputs, have at it.
> if the return type is `Result<MyDataType, MyErrorType>`, the caller cannot access the `MyDataType` without using some code that acknowledges there might be an error (match, if let, unwrap etc.)
I think you can make the same argument here - rust provides unwrap and if you don’t know go, that’s just how you get the value out of the Result Type.
A combo of management control and a very tiny number of people who abuse any freedom given to them, then blame you for not telling them they couldn’t do it, and then blame you for singling them out.
As an anecdote - we had no sick leave policy at a previous job. It was just tell us when you’re sick and you won’t be in. One guy joins and starts calling in on Mondays, or Fridays of bank holiday weekends. He eventually got caught saying he had been on a trip on one of those weekends and was called up on it. He told everyone it was bulshit because he was being singled out and targeted unfairly. Then we got a sick leave policy that applied to everyone.
Unsurprisingly, this guy was also the reason we needed permission to WFH, had formal expense limits when travelling, and core working hours during the day. He ruined it for 30 other people because he took advantage of every flex we had.
Management called him up on the sick days. he responds by saying that there's no policy for sick days, and to show him in the handbook where it says he has a limited number of sick days, or that he needs to notify someone. They can't, because we don't have one. When he's told this isn't acceptable, he pushes back saying that he's being singled out.
That sounds like the real problem was the lack of an employee handbook. They're not strictly required by law, but 30 employees is well above the level where you should really expect to have one in place.
The "just wing it and hope no-one takes the piss" approach is fine if you've only got a handful of employees, but is increasingly risky beyond that - it was probably only a matter of time before that organisation got into a difficult HR situation one way or another.
It's not even going to have been much of a time-saving, since all the legally-mandated bits (eg. equal opportunities, grievance procedures, anti-harassment, modern slavery, and consultation process) will still have been needed at that size, just without a central place to track and manage it all.
> That sounds like the real problem was the lack of an employee handbook.
That's my point - we didn't have one because we didn't need one. 30 people is still small enough that you can be on first name terms with every single person in the company and know what everyone is doing day-to-day. Anecdotally, I'd say one in every 30 people I've worked with in my career are like this - so that's probably the point you do need one.
Poor performers get put on PIPs, right? Did that person's poor performance "ruin it for everyone" and put the rest of the working plebs (the entire company or department or whatever) on PIPs? No, of course not. The poor performer gets singled out, which is just fine.
So instead of punishing everyone for some lying asshole's poor judgment, I propose management puts that lazy jerk on their own SDIP (sick day improvement plan).
EDIT: As an alternative, sure, update the handbook's sick policy while that liar is working for you. Since there's now precedent for handbook updating, should be an easy thing to revert it back to the normal, "no sick day policy" after they leave (by whatever means).
> The poor performer gets singled out, which is just fine.
he's not a poor performer, he's just an asshole. And you can't fire someone for being an asshole
> So instead of punishing everyone for some lying asshole's poor judgment, I propose management puts that lazy jerk on their own SDIP (sick day improvement plan).
You're missing the point. You can't single the person out for violating a policy that you didn't have written down. The only reason that policy is now written down is because that person violated the policy. Singling out someone for being (genuinely) ill is likely to end up with you on the wrong end of an employment tribunal who will ask you "what is your sickness policy"
In the USA, unless they have a contract, you can definitely fire someone for being an asshole.
If you have any sense whatsoever, you'll simply say "we've decided not to continue your employment" and offer them a month of paid COBRA and two weeks of pay in exchange for an agreement not to sue.
It’s been a while since I worked for a bigger company (not meta) but the problem there was you would have a team who was responsible for feature A and a team responsible for feature B, and if there was any weird interop between the two it just never got resolved because there wasn’t an owner. There was no internal incentive to fix the problem. It wasn’t deliberate but it was structural
I dont know what to tell you. I have endless user complaints at i5 16GB RAM, and none at i5 32GB RAM. Not to mention that I run 32 myself and its mostly fine. I can open menus.
I’ve got two machines for work - a desktop with an i9 and a laptop with an i7 and 32GB. The laptop is honestly a disgrace - I can’t believe it is sold as it is and marketed as a premium device. It’s “fine” for some light development but it fundamentally just doesn’t work - it misses inputs, it can’t handle chrome, regularly refuses to wake from sleep, etc. it does have an EPM solution on it which definitely makes it worse, but my 17 year old MacBook which can’t even load modern websites because safari is so out of date runs better than it.
I’m a game developer - this sums up my feelings perfectly.
A lot of this middleware isn’t necessarily even game middleware - think of a turn based game that might use a custom DB instead of mongo or SQL. You’re effectively banning any non game specific middleware from being used or requiring that every company provide a separate licensing path for game developers.
Why is this only targeted at games and not mobile apps, app subscriptions or websites.
This pretty much removes the ability to use _any_ commercial software without a custom license which is just insanity. No using any AWS services in case the pull the rug on you.
You might argue “but you can X and you can Y”, and that’s true, but again why is this only a problem for games?
The short answer is someone cared enough about the specific example in gaming to actually go through all the work to demand change.
The longer answer is that games are one of the only pieces of software your average consumer actually buys these days, and they have a few particularly egregious examples that make it much easier to argue in front of a bunch of politicians without a firm grasp on the digital world, like "Game is completely client side except it checks with a server every 5 minutes to make sure you have a valid license, so when the company goes belly up you're left with a brick"
SKG is basically "right-to-repair" but for games. I do contend that if your phone breaks and the company says "we won't fix it and you aren't allowed to" then the government isn't doing its job. On the same token, if a game that you purchased turns off their servers and says "we won't run it and you aren't allowed to" then the government isn't doing its job.
Now, how I would be able to run it is a very open question and I do agree there are some ways that are more reasonable asks than others. But the present-day status quo of "company says suck eggs and you just have to deal with it" is not an acceptable final state.
reply