Hacker News Reader

Comment by edfletcher_t137 | Hacker News Reader

> Despite a long and storied career in software development, I have few abstract problem-solving skills. I proceed through problems in increments, getting slightly better each time. The beneficial thing for you that my experience brings is that I can do it really fast. Fast enough to deliver a working piece of software in a timeframe that won’t bankrupt you.

> Never in my entire career have I whiteboarded a solution that even remotely survived contact with software frameworks, APIs and hardware constraints. A hundred different gotchas and restrictions lay in wait. The only way through them to a resilient solution is one step at a time. So, I can’t show you anything meaningful with Leetcode challenges unless I practice them as a discrete skill.

This, 1000x. This whole piece nails it, but this really jumped out.

I succeed and excel because I actually get things done, rather than "mostly done". No interview methodology ever can hope to screen for this. Or any of the other things mentioned above.

The process is getting worse, not better, and this piece rightly points out why.

View on HN

Not sure about this. Past a certain level of experience (and given some prior knowledge of the system being worked on) I’d expect someone’s white boarded designs to come out close to the mark at least some of the time. Not always, maybe not even half the time, but “never in my entire career” would surprise me.

Hm, his GitHub profile starts in 2017, before that according to his LinkedIn profile he was a project manager, and since then works as a DevOps guy. Though he was already writing SQL migrations in 2008 (from MySQL to SQL Server 2005). ¯\_(ツ)_/¯

It's not terribly surprising to me that he simply doesn't have experience with coming up with architectures on the spot. Doing interviews is hard, from both sides. No candidate wants to seem arrogant by explaining that why the question/task/problem is bad in the context[0], so the frustration remains and gets vented in blog posts.

[0] Because roles (job descriptions) in the tech industry is so vague, and goes through so many hands. (HR, recruiter, engineering managers, job portals, etc...) And by the time the interview happens it's no wonder the parties have a lot of mismatched expectations of each other. And that's just the baseline, what the post describes is just plain old fucking shitty behavior in a shit job market.

> It's not terribly surprising to me that he simply doesn't have experience with coming up with architectures on the spot.

Or, maybe they spent their career mostly building applications and not architecting systems. Those are very distinct skills.

Of course, it also doesn't help that in an interview context, "system design" can mean "design infrastructure to support a system," or "object-oriented design of a system."

Sorry but your parent post is right.

It's not realistic to day dream yourself to a real product.

I realised this from the waterfall model days itself, where elaborate documents used to be written before we even wrote a single line of code. And every single time the paper planning would be totally useless and nothing like what the original deliverable would turn out to be.

"totally useless". maybe just "useless". my experience is you learned a lot about the problem domain and the system constraints during the creation of those documents. you didn't learn enough to solve the problem, but it got you started.

Not only that, whiteboarding a design will bring up lots of the issues you'd otherwise find in those small steps anyway. It just shifts them left - boasting about purposefully delaying finding them is not great.

There's a lot these tests don't pick up for sure. I feel soft skills is one and being focused on the day to day tasks is another. By hiring based on drills you run this risk of hiring a nasty or emotional person that just wants to use framework x rather than do any of the mundane bill paying work. If soccer teams started hiring based on ball-juggling skills they'd be full of street perfromers and clowns rather than world class strikers. I find tests are really bad for generalists too or older people who can't remember vividly the math they did at school. However we gotta suck it up and it is quite fun refreshing some skills and knowledge between gigs. What's worse is when you pass the tests but then don't get the job. Makes you feel it was something about you personally.

You are assuming that the same person can't do both.

If the skill you're hiring for is to iteratively solve a real world problem, then it doesn't matter if someone can do both. You need to find someone who can iteratively solve real world problems.

People might have both, but some people only have one, and not the one you're hiring for. If they can ace Leetcode problems, or unicycle, or speak Klingon, that's lovely but irrelevant, and absolutely pointless to test for in an interview as a proxy for solving real world problems.

then you can work at a FAANG company and get payed handsomely to lock up all that talent selling people things they dont need through ads!!!! Some people see NASA and think of all the smart people who worked there and what they did. me, i see talent wasted on war and i imagine all the great things that these people could of done if they applied their talents to something meaningful.

Even if you really meant "DOD" (Dept of Defense) instead of "NASA" (National Aeronautics & Space Administration, which is not involved in wars), work of the DOD is absolutely necessary to maintain the free society which you and I enjoy.

Unless you want to —literally— live under a Hitler, Stalin, Pol Pot, Mao, or Putin, democracies must always be better armed than autocracies. Autocracies always expand and take over less-well-defended self-determining peoples, and life under an autocracy always gets worse.

Obviously, it would be ideal if we didn't need to constantly and diligently defend ourselves from autocrats and would-be autocrats, they still exist in the world, and we must still defend against them. Yes, mistakes are always made, both in over-defending (e.g., Vietnam, Iraq) and under-defending (e.g., Balkans, Ukraine), but that does not eliminate the necessity. Wishing the world were different does not make it so, as much as you and I would like it to be so.

>> all the great things that these people could of done if they applied their talents to something meaningful.

Also, much of that work actually does get out eventually to products that are meaningful and useful to everyone. GPS, satellite communications, carbon fiber composites, and more are just a few examples of great things created initially for defense work, and that are now used universally. I work in carbon fiber and make things for everything from the DOD to sporting goods for kids.

None of it is a waste (anymore than there is waste and inefficiency inherent in any large organization). I hope that makes you feel a bit better about it.

What war has NASA ever been directly involved in?

The War of Elves and Sauron (not to be confused with the much later War of the Last Alliance)

The War on illiteracy and meaningful reading comprehension.

I was in the "on-site loop" for a company you've likely heard about.

When we were smaller, I was tasked with writing an interview question for JS devs.

I created a handful of unit tests that were all really easy questions technically, though maybe a little obscure, because they were designed to spark dialogue. Think "escape room", solve one test, move to the next. Google was allowed and actively encouraged.

But it wasn't really about the tests (they had to pass, of course, and shockingly some didn't). A not-very-good candidate would still make it to the end and solve all the puzzles and get a rejection.

The goal was to create a lot of jumping off points to sort of "break the 4th wall" and see what the candidate actually does to solve a problem. If I could get someone to search the web as the fastest way to solve something, that was almost always a great sign.

Sometimes I can see them building an inefficient answer and ask them if they'd like to search online for an easier algorithm, and remind them to treat this how they would actually treat their job. Some people stubbornly refused.

If I could get them jazzed to tell me about their editor configuration, that was almost always a good candidate. Because people who care about writing code care about editors. Do you hate vim? Great, tell me why. Do you love emacs? Show me a lisp snippet or whatever you think is cool.

I'd see a lot of `console.log({ foo, bar })` but also some `console.log("foo: " + foo + "\nbar: " + bar)`. I'm not judging harshly on any one particular thing, but I just want to see some level of craftsmanship about something. If you're from the java world, cool, show me some intellij tricks as you're working in webstorm.

Do you reach for the repl/debugger to try out ideas by default? Good sign.

To me it's simple: would I want to work with this person? could I recommend the company hire them based on how they work? I can't actually work with you, so I want the closest thing I can do in an hour that feels like we're on the same team.

I think the question is now retired because it didn't scale, or maybe it's still there with a rubric that invalidates the point of it.

If anyone's trying to do ML in this space, try softball questions that require more search and discussion than code, then NLP the discussion and ignore the code. Use internal mock interviews to train it to match your target culture. I think that would make this approach scale.

I personally found pretty good success with the people I interviewed this way as peers, but I wasn't in a position to find out if they were really successful or not by internal metrics.

>If I could get them jazzed to tell me about their editor configuration, that was almost always a good candidate. Because people who care about writing code care about editors.

I agree with much of your post, but just wanted to point out that many of these things are not universal. I personally have little interest in code editors and even less in discussing them, though I do use Emacs and will probably never invest in learning another editor. It's just a tool to me though, and writing custom lisp functions to make it work just how I want has just never been of my thing.

If I could get you to express that in an interview, I'd say something like "do you have any tools you find value in customizing?" and try to lead the direction in whatever you think of as "custom" in your world, so I can hear how it helps you be effective, so I can understand what you think it means to be effective.

I probably shouldn't have picked text editor as the example, it's really not about that.

To which my answer would be: I've been in this game for 25 years. I lost my will to configure long ago, and now just use the default. The default is better tested, good enough for most tasks, and doesn't leave you hobbled whenever you have to work on a fresh machine as you try to remember what custom things you had set up, or if your config git repo is properly up to date and doesn't introduce unwanted dependencies (or if you can even connect to it).

It's also a major source of WFM (works for me) syndrome, where something in your custom stuff is unintentionally needed by the build.

I'd rather be building things than playing with my tools. If I really need something esoteric, I'll find another tool or write a Python script

Same for me, a custom configured environment has often become yet one more thing that can break and needs maintenance. I make sure I have basic emacs keybindings but that’s almost it. In my experience, the people that spend most time on customizing the tools have mostly been junior developers. Though if you asked me on productivity tools we’d have an interesting discussion. I guess it’s just a matter of focus.

lol. This is why I reach for vi

Echoing the other comment about bias, it seems like a strong personal preference of yours, but it's unclear whether this is actually a good indicator of a strong fit or not.

Like @kstenerud, I tend to keep the default settings as I am happy to just learn the default to at least avoid things from breaking, when the next IT/infrastructure update happens at "the company", or maybe I have to use a clean machine to do some coding.

Instead, I spend some time to look how I can be more productive (keyboard shortcuts, etc), and then will just leave it at that. I've had both types of colleagues: customizing/non-customizing, both types have been high performing.

I find value in tools that don't need much customizing.

A lot of the effort people devote to customizing their tools doesn't seem to be about productivity or effectiveness in any measurable sense.

> "do you have any tools you find value in customizing?"

Anecdata: don't think I have any? My best tools for years were pencil and paper, and I usually get things done, very fast.

Similar to other replies, I also am not so interested in customizing my tools. I use a small number of tools and as out of the box as possible (but learn them well). If you led the conversation in that direction I'd probably try to steer it away.

So it's horses for courses.

Yeah editor chat isn’t a bad sign, I enjoy it, but I also don’t put a whole lot of stock in it. It’s a plus if someone can explain their editor choice through original arguments delivered with passion and conviction, but that applies to any number of technical topics.

If I could get them jazzed to tell me about their editor configuration, that was almost always a good candidate. Because people who care about writing code care about editors.

I've spent a great deal of time modifying my editor config. I advocate for "tools day" where I work, which is a day where a team get together to share ideas about tooling and collaborate on config to make the team more productive. I regularly share what I change in my config with people.

I couldn't spend more than 30 seconds talking about it though. I have a problem, I solve it, I share the solution, and I spend no time or effort remembering what I did after that. It's one of the least interesting things about dev...

I find editor usage quite interesting, in fact. I’m responsible for mentoring and training other developers, and mastery of an IDE is the easiest, biggest win you can get for productivity.

How do I easily attach the debugger? How do I jump between recent files? How do I use column mode to fix a bunch of sample data? How do I jump between file and test?

Junior devs by and large can’t do any of these things, and it has a material impact on work output. So I teach them.

The same here, but to such an extent that it sometimes becomes a problem during interviews. For example I hate laptop trackpads, I always use a mouse, so then during a tech interview they give you the crappiest laptop imaginable without a mouse.

I also for example press F7 to compile (along with 20 other shortcuts), so when confronted with a generic editor in a test I'm again wasting half my time struggling around on it.

Your technique has already been proven to create unconscious bias, because you are more likely to hire people that are like you. You even said it yourself, you want to work with people that you like and that you get along with.

Here's one of hundreds of articles that talk about this:

https://www.forbes.com/sites/forbescoachescouncil/2018/05/01...

Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry.

> You even said it yourself, you want to work with people that you like and that you get along with.

And you.. don't?

> Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry.

I've gotten plenty of training that makes it extremely clear that discrimination based on protected classes is unacceptable in all contexts, especially interviews.

At some point, you have to trust your team to build your team. Not everything can be blindly metrics driven.

You're hiring humans to work with other humans.

The point is to hire people who mastered skills different than what you have. You see interest in text editing as a major factor, but there are probably many software engineers who have no interest in text editing and just writes stuff manually with no focus on tricks, and are still very productive since really writing 100 lines of code is just a few minutes of typing but still plenty for a days worth of work.

> The point is to hire people who mastered skills different than what you have.

That's the job of the other engineers. I only know how to screen for the skills I do have.

Most engineers spend all day in their text editor and on Google, debugging code and searching for solutions.

I have never met a good craftsman that doesn't customize their tools.

I'm not saying everyone has to customize their editor. But if you move quickly and intuitively through the chrome debugger, the only way you got that skill was by doing it every day for way too many hours.

Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.

> That's the job of the other engineers. I only know how to screen for the skills I do have.

But to strengthen a team you want to add people who have skills the other people in the team lacks, so your interview needs to be able to find such people easily.

In general you want the interview to test that they have done the basics of the work before, that they are smart and that they are nice. Your test helps assert the first, they have done the work before, and the discussion tells you whether they are nice. But it doesn't tell you whether they are smart. And if you think a bit there are probably simpler questions you can ask to check they have done the work that are more general and will pass more people, you want to sort by intelligence and not passion for text editing so the "have they programmed before" question should be as low level as possible and not require any special skills.

The algorithm interview is what the industry settled on to solve this. It tests extremely trivial coding, so you can do the coding if you have ever coded before. The hard part is the algorithms, and that might require some to study, but since it is standardized that becomes a reasonable proxy for intelligence. And social comes from being able to talk about a technical problem and describe what you are doing in a stressful situation, that is good enough to work on a team.

> Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.

This is true, but you don't need to customize anything for that. VSCode text search gets you 99% there.

> I have never met a good craftsman that doesn't customize their tools.

To the contrary, personally I even take some pride I can work on any PC you can possibly give me immediately. This has tons of upsides - from helping someone walking over to them, to knowing tools in their default configurations inside out and explaining keybindings or quirks that are guaranteed to work (and writing better docs).

Programming really isn't about my personality, I want to strip any of that and produce the least amount of very default, simple code anyone can work with. And you don't need to type fast or use scripts to produce that small amount of code.

Largely same goes for debugging, I better create a good logging and monitoring system than spend time tweaking my tools, because that'll immensely benefit the person who maintains the code after I'm gone. Nobody will install my personal tweaks to catch bugs. Granted I mostly work with very good tooling already (C#).

I customize my shell and tools all day. Editor? Not so much, CUA FTW. In fact had to think five minutes before I remembered my snippets. They’ve been in git for 5-10 years.

>I've gotten plenty of training that makes it extremely clear that discrimination based on protected classes is unacceptable in all contexts

There are plenty of cases where discrimination against unprotected classes still happens. Cases where studies cannot find a correlation between selected candidates and things like retention rate, performance etc. These include cases where one would be skipped over despite having personality attributes the team is sorely lacking.

>You're hiring humans to work with other humans.

It's because we work together as humans, most of the things you said don't really matter. Most humans can work together despite their differences. That's one huge problem with hiring as a whole, trying to find carbon copies of each other while espousing they value diversity.

That's not to mention all this "one of us" hoo-ha just stimulates chameleon behavior. Which benefits the person opposite of you, but it doesn't do you much favor in the long run.

> And you.. don't?

The problem in this situation is that YOU are the one acting as a gatekeeper as to who gets into the company.

The company should be the one setting the standards, and determine the best person for the job, and you should be able to work with whoever is best suited for the job, regardless of whether or not you like them.

This is where the unconscious bias comes from.

If he said it himself, then it’s not an unconscious bias, is it?

The point of interviewing is bias in the first place - to find people who are good - and it’s not unreasonable to assume that “I want to be good” and “this potential hire is good” would result in correlated features

Rationality doesn't work when studies have repeatedly found virtually no correlation between 'someone good doing hiring as they like' and good candidates in the context of retention, performance, and more.

Even rationally it doesn't make much sense. You're judging people on what they do in a year given how much an individual likes them and believes them to be good given a day's worth of input. Even if such an individual finds a lot of 'good' hits, nothing would tell them if it was this particular selection mechanism, other selection mechanisms, the workplace, luck, or none of them. The same goes the other way around for 'bad' hits.

Not to mention, if rationality worked, we'd see 'years of experience' have great correlation with 'good' candidates. Yet YoE always fails to contribute greatly given the presence of other metrics.

Cool, next time you're hiring, remember this and hire someone with no experience, no technical interviewing, just by "divine inspiration" (a.k.a. your emotions) and/or chance.

If one can’t escape or compensate for it, then it doesn’t matter if it’s conscious or unconscious bias.

You can escape it by becoming a better software engineer.

Up to the limit of your IQ, which is the real bias that everyone sweeps under the rug, especially all the bigtech companies espousing “inclusivity” (all lies, actually exclusivity, as they don’t hire most people, especially stupid people).

> You can escape it by becoming a better software engineer.

Why? Are better software engineers less biased? Why would that be? I would assume that they are human, and therefore just as prone to biases, like everyone else.

The other alternative is soullessness via standardized tests. Why? Isn’t it better for people to hire people?

sounds like a “who is smarter” pissing contest.

> If I could get someone to search the web as the fastest way to solve something, that was almost always a great sign.

Interesting how things change. At a big, known software company they used to put a candidate at a computer running Visual Studio and ask him/her to write a program. That program would be impossible to code without including multiple winapi(?) calls and neither help nor internet were available. This was around late 90s/early 00s.

What I liked about Square’s pair programming interview is that they would tell you its about these things instead of smugly hiding them as dark patterns.

There are waaaay more interviews that say you can use a search engine and then take points off for doing it. There are way more interviews that are more like academia that rely on rote memorization for an assessment and would consider reference material cheating.

Industry needs a trade group just for interviewing practices. You’re so confident in what you wrote its comical.

Leetcode-style interviews : software engineering :: auditions : acting

Auditioning is nothing like being an actor, but that's primarily the only way actors get gigs. Unless you're so well-known that they seek you out. This is exactly the same thing as in programming. You have to submit yourself to a humiliating barrage of LC and systems design questions because that's how companies like Google have decided that's the best way to determine talent. And based on their multi-trillion dollar valuation, it's hard to say that they're wrong.

So unfortunately, unless you can come up with a better way, auditioning for your software engineering job is here to stay, just like auditioning for your acting job. So you might as well accept it.

>So unfortunately, unless you can come up with a better way, auditioning for your software engineering job is here to stay, just like auditioning for your acting job. So you might as well accept it.

If I was able to come up with a better way, I would sell it to Google and never work a day again in my life.

Pointing out that current methods suck is free advice, though.

valuations are mostly made up and they have nothing to do with how they hire.

and you are wrong that it’s there to stay. if people decide to no longer play ball and organize that will be the end of it.

the current system was created by a single woman who simply created it to build a consulting business around it. and you are all too naieve to see it.

It's ridiculous to imply that Google and Facebook aren't one of the most successful companies in the history of the world. And there's no way they could have made it to one of the most successful companies in history with a company full of terrible employees.

you need to ask the question, why they became succesful and why they are still here, collecting data about you every day. they know you better than yourself.

> created by a single woman who simply created it to build a consulting business

Who's that? (I don't agree but I'm curious about your opinions anyway)

the author of cracking the coding interview

Ok thanks (was a bit who I was guessing you'd mention :-))

Isn't it true that contractors/freelancers aren't expected to do leetcode interviews?

Nope, not true. I’ve been contracting for 15 years and regularly encounter leetcode interviews.

When I can, I’ll outright ask if the client intends to do this kind of interview. If they say yes, I’ll explain my objection to the process and if they aren’t willing to modify their interview approach for me I will decline the interview.

I have on occasion had this sprung on my without warning halfway through an interview and I’ve declined to do it; most of the time I get hired anyway.

Whenever I can I try to convince hiring managers (and I’ve been one myself) to ditch leetcode nonsense for future interviews.

> modify their interview approach for me

What do you like instead of LC?

I think the issue with LC for contractors is unpaid work resulting is the loss of opportunity with other potential clients due to the effort involved. The equation is fundamentally different than for a salaried employee.

There was a period when I was looking for freelance gigs via Upwork - I had to send hundreds of applications to get a single few hours worth order. May be it gets better with a higher rating but I never got to this point. I would rather spend a month preparing to leetcode style interviews than spend it writing Upwork applications.

But Upwork is not necessary for this kind of work. In fact, only a small portion of freelancers are on those kind of platforms.

it's probably also true that if they're working for a livable wage they also have a decent portfolio...

How do we know that this is the case?

Reply on news.ycombinator.com