Hacker News Reader

Comment by noduerme | Hacker News Reader

I really wanna ask, because... I'm 46. Been writing code for a living about 30 years, never on a salary, always contractor. I wrote and maintain enough code for non-tech companies that aren't going to take a risk on AI rewrites anytime soon that I can probably coast until retirement. But I haven't interviewed or even needed to sell myself for a long time.

I always thought I would easily pass an interview, but I may have been wrong before all this on the basis that I don't work that well on a team.

OTOH ...is the question now really valuable whether a candidate can explain their thought process rather than deliver? Why wasn't that a question 20 years ago when it actually mattered? Or does it matter more now because the bar needs to be higher, and there's no cache of more experienced devs to train them up?

View on HN

I do something exactly like what the parent said, and my own view.

The question isn't about figuring out junior or senior. Its about the candidate being able to think thru a problem. They don't even necessarily have to be good at articulating their thought, I just want to see how (and if at all) they are splitting open the problem, walking thru it, figuring it out and then converging on something that (at least to them) feels like a reasonable solution.

If they get stuck, I am happy to help them out, without disrupting them or deviating them. If they go down a wrong rabbit hole, I may ask a leading question that helps them realize the issue and gets them back on track.

The bar isn't being set higher. Its just that there are a LOT of people interviewing (in my experience) unfortunately, who seem to be unable to model problems in their head, model how their code would work (mentally model the execution of the code), and reason things out. They have frequently coasted on blind copy paste from stackoverflow/help/tutorials. A huge fraction.

I also have been coding for a LONG time (older than you), and in the early days, this sort of conversation didn't have to be explicitly asked for, it happened naturally, like in every interview (where I was the one being interviewed) - cause you present me with a problem, and I can't help but be nerd-sniped by it. People who were candidates for tech jobs were there only cause they actually went into it with a bit of love/passion/skill.

But then it became a large industry, and most people who went into it were not 'hackers (problem solvers)' at all. They just liked the great pay. They may even be intelligent, but a lot were not capable as independent code owners. Still useful for basic crud with the right frameworks/etc. So thriving in enterprise applications, java/c# mega-platform/mega-framework domains.

There are too many candidates for too few job openings. So people come up with all matters of ridiculous filters because they feel they have to test everyone. In reality they can take almost anyone with relevant experience and they'll get the job done, but that wouldn't look like good hiring process.

I have ~15 years experience with hands on engineering. I also served as a hiring manager in a couple of roles, and interviewed dozens of candidates.

I would love to live in a world where every candidate represented their experience accurately, and every applicant was capable of fulfilling the role, but sadly it's not the case.

I agree there's some filters which are mostly performative (like leetcode), but being able to talk through the kind of work you do is table stakes. And not just for engineers, for any professional role.

> on the basis that I don't work that well on a team

I think you are likely to find that "working well on a team" is the number #1 thing tech firms are screening for. Technical skills are all well and good, but communicating/collaborating are half the job in a big company.

I mean, communicating/collaborating with upper management and turning their requests into solid code? That's what I get paid to do. Communicating/collaborating with other coders? Not so much. Note that I specifically said I don't work for tech firms.

Right, I'm saying that if you were to transition out of contracting in the future, this would likely be a bigger issue. In-house dev teams are expected to be highly collaborative, and the interview process attempts to screen out "lone wolf" engineers (insofar as it is possible to do so)

"Working well on a team" is something completely uncorrelated with the ability of explaining your thinking during the time when you are solving a problem.

All the teams in which I have ever worked have greatly appreciated my contribution precisely because I was always willing to spend a lot of my time explaining to other colleagues, in a differentiated way appropriate for the understanding abilities of each of them, how I had solved my problems or how they should solve their problems.

On the other hand, I am also completely unable to explain my thinking while it is in progress, because reformulating it to become intelligible to the interlocutor would slow me down far too much.

Explaining on-line my thinking would require even a kind of language translation, because when I am speaking to myself I use a special language with precise non-ambiguous words, whose meanings correspond in many cases with old meanings of those words, because in the modern language a very large number of words have vague meanings, which have become very diluted due to the frequent use of those words in inappropriate contexts.

So when I describe some technical solution to others, I typically do not use the words with which I think about it, but whatever words are more fashionable today, so I expect familiarity with them, even when I think that those are not the right words.

Doing such a translation while I think is too difficult, and I do not attempt to think with whatever words become fashionable from time to time, without any good reasons, because in my opinion using the right names for concepts is very important for understanding and using them properly.

I understand what you mean. I don't even use words while I'm solving the problem; internally, I suppose I visualize something like a flowchart of logic, where I can see the holes that edge cases could slip through. Later, after I've tested all the edge cases, I'll spend an hour laboring to wrap it up into a neat non-technical explanation of what needed to he done and why.

That's also why I have trouble working on teams. I tend to evolve a complete picture of how I'm going to approach a large problem in code at the same time as I'm thinking through the business logic. It's mostly written in my head before I sit down to write it, and I'm thinking through the sharp edges as I go along.

It's also why prompting an LLM is often more tedious, frustrating or imprecise than writing the code myself. The code is not the thing, the logic is the thing.

I think delivering is still a requirement either way, but the value is in hearing a candidate has the ability to problem solve in an unknown problem space vs regurgitate a memorized solution. Even better is witnessing some has the ability to try, fail, then self-correct, and rebound.

So, my policy has always been that if I sit through a meeting where a client asks for new feature "X" and I figure out a way to avoid building the new feature, and either use existing business logic / day-to-day processes, or else find some new way that doesn't involve code, I don't bill for that time. I'd say that I probably give up about 35-40% of potential coding work just by helping them work through that. Which is fine, because it leaves me free time to do other things.

On the other hand, I don't have the option to fail even slightly. I deployed a patch yesterday for an old, rare, logic bug in one reservation system, and within an hour I was being bombarded with edge cases of people seeing their reservations as cancelled during the 15 minute switch-over period.

Sometimes I feel like the job of a programmer for a company is just very different from what I do. If anything goes wrong with anything I deploy, I'm awake for however long it takes to make sure it's right. On the other hand: No PRs, no teamwork. Just a click to deploy once I'm relatively sure. And a lot of responsibility.

Reply on news.ycombinator.com