Hacker News Reader

Comment by willvarfar | Hacker News Reader

Young whippersnappers are going to downvote me for sharing, but I'm on the other side of the divide and have had to interview and be interviewed a lot over the years.

The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program.

The industry is awash with candidates with ok-seeming resumes, that get through HR screening, but then fail miserably at the tech interview to solve something like fizzbuzz.

My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team, whatever you are doing!

The tech interview with the ludicrously simple questions are all about finding people who 'get it', and are actually effective at it. Which is why it persists.

The good news is there are interviewers like me who have been lucky enough to be in the position to hire people on the strength of them being able to work through things in pseudo code even though they are not familiar with any programming languages. I keep interviewing and hiring physics grads on the strength of their excellent problem solving skills, and they all learn to express that in programming languages in short order once they are hired and they have found employment as a programmer...

View on HN

Fizzbuzz is one thing. Balancing binary trees, is another. I've learned that if I see a binary tree question, I might as well stop the process, as they have no intentions of hiring me. They want someone fresh out of college, and I'm really just an EEOC checkmark.

I've said it many, many times, here. If a candidate has a portfolio, you'd be absolute idiots to ignore that portfolio.

Or deliberately ignorant, as the decision has already been made, not to hire the candidate (for reasons that have nothing at all to do with their tech abilities), and no one wants to waste time, reviewing a portfolio.

I'm biased, here, of course, as that's my strength. I have a fairly substantial portfolio.

A portfolio makes it much easier to evaluate real world skills and capabilities. If a candidate sends a link to a sample project or OSS product they've worked on/developed, it's not particularly difficult to review the example, and then ask the candidate a bunch of questions about it. I've found that the conversations that arise from this kind of thing can be amazing.

But this won't work for managers that have a hundred résumés on their desk, and have maybe five minutes per candidate. As that was never my own experience, as a hiring manager, I can't speak to it. I rarely had candidates that had significant portfolios, and treasured the ones that did.

In my experience, it usually took about two minutes of casual conversation, to figure out if the candidate had potential, or was simply a jargonaut.

I find it astonishing how I often I've been asked about binary trees and binary search trees in web developer interviews. In all my time, I've come across some circumstances where some concepts like state machines were helpful, but have yet to run into a time where I needed to understand or write a binary tree. At first I felt ashamed, but over time the feeling flipped and I felt bad for the interviewer asking such a non-applicable question as for them to look rather foolish. It's like asking a biologist to describe the Dirac equation.

Fortunately I've yet to run into this once I spent enough time as a mid-level developer and became senior. If it's any ray of hope for younger developers out there, you will get to a point where you basically bypass all that crap and interviews can be more like a friendly chat between peers.

This has not been my experience (lately). That’s how it used to be, when I was younger (and probably rated it), but every query I made in the last five years, the very first thing was a test.

In a couple of instances, it was a sensible, applicable “take-home” test, but usually, it was a schoolboy binary tree test.

I interview very well (on account of over 30 years of relevant ship experience, and I’m actually a fairly decent chap), but it has never gotten to that point.

BTW: if it isn’t already obvious, I’m quite senior, and have been architecting, as well as writing, software, since my very first project, in 1987.

I was quite willing to work for a lot less than many folks much less qualified, on account of having my retirement set, and was looking for interesting and engaging work, more than money; but it never got that far.

I won’t waste time practicing LeetCode. I don’t think it would make any difference, simply putting off the inevitable rejection. It’s not something that helps me to write better shipping code.

I recently had a lovely “take home” test, that I was supposed to finish in 2-3 hours.

If I could just build them a feedback system for their employees. Including backend, frontend (as a SPA please), and tests.

Of, of course they didn’t expect me to actually finish, 5 API’s and 3 implemented front-end pages would be ok (and tests, of course). Also, could I maybe make it look nice?

I dunno, for some reason I saw it as a challenge and actually tried. But after 3 hours I was forced to concede that even using a full framework and CRUD generation for most of the app the idea that you could finish was ludicrous.

I spent an extra 30m writing up a review of the process and attached that as a ‘cover letter’.

Unsurprisingly I didn’t get the job, but I guess I consider it a bullet dodged now.

Do they actually expect someone to pass this? I am honestly curious what the hire rate is at a place like this.

They expect you to take 2 days on it. Ie cheat. I refuse take homes on principle at this point, as I know I’ll be working with a bunch of cheaters if I do get the job.

So you’re given 2-3 hours, but expected to take 2 days?

If my experience from the other side is transferrable then no, they do not expect it to take 2 days. They actually mean what they are saying.

Unfortunately they are developers. They underestimate how long it will take. They didn't actually try it themselves. They might even have modeled it after a piece of software they did build in-house and thus underestimate even more.

I had to advocate very strongly on cutting scope from our take home test and multiple times argue against 'extensions' of the ask.

I like take home. It's a great way to talk about their code. Have them explain choices. Pros and cons. And yes tests please. What I look for is not complete test coverage or having 27 classes that all have pseudo tests. Have one class with _good_ tests. Show that you understand what is important to test and how to do that. If you know how to do that, I can hire you to repeat it for a salary.

My own last take home I sent in didn't even run because the implementation assumed various external services that I didn't bother implementing or mocking out enough to make it all run. I put lots of comments explaining various choices and what I'd expect those external services to do though. Was a great topic started about code comments and which ones I would leave in actual code and such.

The problem being of course, that from the applicant side you don’t know if they mean it or not.

So you’ll be competing with people that implement the whole thing regardless.

Now I’d like to think that interviewers are entirely impervious to that, but realistically, it’ll hurt the chances of those that do it only halfway.

Try it. I can tell you from the other side that if you know your stuff your evening (2-3 hours) output will be way better than many that take 2 days.

If you don't try you've already lost.

I had one take home at some point where the interviewers didn’t believe I actually did implement their thing in 6 hours. Everyone else took two days :/

I have a take home test right now, that I should supposedly be able to finish in 2 hours.

Just setting up technologies that I have never used on my local machine and trying to understand them has taken me several hours.

It seems unlikely I will submit anything.

> I was quite willing to work for a lot less than many folks much less qualified, on account of having my retirement set, and was looking for interesting and engaging work, more than money; but it never got that far.

Did you think to work with blockchain? It has a lot of engaging problems, and you can start even without getting hired. It ranges from helping out DAOs in open-source and getting paid in tokens; to starting off your own small project and building a community.

As for the jobs, the compensations has been through the roof lately – the field doesn't get new developers nearly at the rate needed

It looks interesting, but it's not really what I like doing.

I enjoy working on stuff that people use. Things that the user interacts with directly; like UIs and devices.

I did a bunch of work with Bluetooth, OBD, and ONVIF (surveillance), but I'm working on what is sort of a "social media" app, now. I wrote the backend for one of the servers we use, and was the original author of another of the servers. These were big projects.

The interesting part, however, is the iOS app that I'm developing. Trying out different ways of presenting to the user, and interacting with the user, is a lot of fun.

> It ranges from helping out DAOs in open-source ...

Do you know of any good articles or guides about getting started with this for complete beginners to blockchain?

I share the same experiences. Only around half of your (temporal) experience and every conversation with a recruiter ends the same way: "When can we schedule you for a technical screening? You'll probably want some time to brush up on leetcode as well".

My experience doesn't matter. The fact that I've now worked at (and currently work at) 3 of the big tech firms, doesn't matter (to be fair, I only got jobs at these places back when I was willing to grind out leetcode and memorize as many problems as I could - a task which I refuse to do today). The fact that I have a history of leading teams, areas, and spend at least 50% of my time also "writing code" for high performance, high reliability, global services, --and-- can speak in depth regarding my accomplishments, design decisions, technical decisions, collaboration, etc. doesn't matter.

The only thing that matters is: Can I pretend like I've never seen this toy leetcode problem before during an interview, and magically come up with a perfect solution in 30 minutes or less. (and if I haven't happened to memorize it, and dare legitimately appear to struggle, well... game over).

Leetcode and equivalent seems to come out of an intersection of a technical interviewer's "I don't want to take the time to interview you" and HR's "I don't know how to interview you."

Everyone knows that something very serious must be done at an interview. Nobody cares about it enough to actually put in the time or trust for a bespoke solution.

Consequently, you end up with everyone sub'ing algorithms in for due diligence, then because they made that choice, defending the choice and pretending like it's meaningful.

Hiring is hard. Hiring technical, non-standardized talent is even harder.

I am an extremely accomplished engineer: 40 years developing professionally, over 40 published consumer software titles, I've written from C/C++ the entire critical path pipeline for multiple animation studios... yet in a recent job interview the moron interviewer says to me mid way through "sounds like you're tech light, do you even write code?" (cue a record scratching) After questioning, this person has no idea my describing 40 years of professional coding was writing software - this HIRING MANAGER did not know any of the terminology I used describing being a key player in the transition from optical and video to all digital media productions everywhere. How to describe a successful career when that very success eliminated the reference points for what the career was, now it seems like we made the air itself as the digital media takeover was 100% successful, the young hiring managers have no idea what the world was before we (the developers who lived through the 70's to 2000's) changed everything.

I am sorry you went through that. I can relate.

Today, we have “jargonauts.” These are folks that key on certain terms and acronyms.

I remember, back in the 1990s, hearing everyone gushing about “AJAX,” and wondering what the big deal was (after being laughed at, for not knowing the term). No one would explain what it was.

I looked it up, and go “Oh, they mean HTTPRequestObject!”

Turned out, that I actually already knew a lot more about “AJAX,” than most of the folks gushing about it, and the reason no one would explain it, was that they didn’t actually understand it.

Lot of that, going around…

Did you really hear anyone talk about AJAX in the '90s? Looks like there was some work done on XHR in '99, but it seemed to roll out across browsers in the early '00s and seemed peak hype when I started my career in the mid '00s, after the Web 2.0 conf in '04.

It may have been the early 2000s, but it was very early on. It "came to a head," on a trip to San Francisco, on one particular project (I am not at liberty to discuss). It would not have been beyond about 2002. I think it was pre 9/11, but my memory of that time is a bit fuzzy. I did a lot of traveling.

I'm pretty sure that HTTPRequest debuted in IE 5 or 6.

The way I remember it is it became widely known once gmail and google maps shocked everyone with its effective use. So that's quite a bit later than 2002. But it's likely that it is just when I noticed, being pretty far removed from web development at the time.

AFAICR, it started in the mid-to-late 90s, although as with all things web in that period, was a non-standard cobbling together of feature and functionality using whatever technologies were available, while browsers themselves lurched in the dark and added features.

It's more akin to saying "We want to do this thing that's never been done on the web before, and no one ever thought to do. How do we assemble it out of this box of scraps that HTML and browsers currently give us?"

Consequently, there was probably proto-AJAX with ActiveX, the early js landscape, and iframes. But it would have certainly depended on where you worked.

Critically, internet connections were much slower (in latency and bandwidth), so partial page loads were more of an advantage.

AJAX was a catch-all term meaning “the page does things without reloading the whole page” if I remember correctly - or that’s how people were using it.

Sounds like today's "dependency injection", and people writing 5 pages on it.

Except then it turns out what they mean isn't DI, but some other concept related to it and largely taken care of by their framework of choice.

It also sounds fancier than it really is. "Dependency injection" can literally mean just passing some arguments or setting properties on a hash. The target doesn't even need to be a singleton or long-lived. Honestly, I've never found the term particularly useful. The meaning is so amorphous that it could really just be described as a form of decoupling. But it sure was great to say it during interviews early in my career!

Indeed, it is simply passing some dependency as a parameter.

Personally I find DI to make it harder to reason about in a sizeable portion of cases (20ish%) without actually providing a benefit.

So that makes me prefer going for rejection (Passing the result of the dependency instead of the dependency itself) or just keeping it there.

Altough, those approaches depend heavily on the rest of the codebase. (FP makes rejection relatively easy for example)

DI makes testing nice. People approximate it with hacks, but you need DI for truly good unit tests.

Really depends on the whole structure. If it is mainly FP, dependency rejection usually is actually the easiest to test with

I dunno how you can combine dependency injection (as I imagined it in the original comment) with FP in the first place.

Without classes what would you be injecting? Other functions? That’s still something that happens all the time in FP.

I was thinking sideeffectful functions. Such as DB accesses.

> dependency rejection

That’s secretly the most powerful design strategy.

It objectively isn't, as there are certain things you can't do with it.

Altough, for usability it is IMO definitely the best.

> setting properties on a hash

Nowadays it's called a dict.

The term AJAX was coined in 2005 by https://web.archive.org/web/20150910072359/http://adaptivepa.... People had been talking about the idea for a few years at that point, but not with that name.

Might be right. I would be surprised, though. I do remember that it was a "brand new" buzzword.

Not worth fighting over. Time is flying, and even the early 2000s was a couple of decades ago.

Just to set the record straight, the skeptics were correct. I was off by 5 years.

I asked someone that was on that trip with me, and it was late 2007.

You know how it is, with us doddering old geezers; we forget stuff...

As someone with a similar time in harness in industries that rhyme with that, I feel your pain.

While I'd prefer to work, not needing the money implies the ability to avoid the interview process. It's a funny thing being in an industry where people retire not because they can't do the work at a professional level, but because getting a job is such a PITA.

> It's a funny thing being in an industry where people retire not because they can't do the work at a professional level, but because getting a job is such a PITA.

I feel that this is a desired result. I am pretty convinced that folks like to have an "ideal culture" at their workplaces. I hear the term "cultural fit" so often, that I guess it means something that I'm missing.

https://www.youtube.com/watch?v=G2y8Sx4B2Sk

As a game engineer I can relate. Many of these deep technical areas are completely unknown to people outside of gaming / modeling / animation / graphics, and even then you are way outside my expertise with optical/pre-digital work. It is a great point that interviewers focused on typescript or redux (just to mention stuff worth knowing but that seem far from C++ graphics coding) won’t get the nuance of your technical contributions. It then becomes a storytelling challenge, which is a different interviewing skill entirely.

I was on the OS teams of the 3D0 and the first PlayStation, 2/3rds of my published software are console games. My games stint was the EA Spouse era.

EA Spouse... that takes me back to the time when I decided to let my dream of becoming a game developer remain a dream.

I was asked to sub for a PSE interview on short notice, so I did my usual fizzbuzz routine. Even that felt kinda goofy asking this excellent senior guy so I asked it with a bit of apologetic tone. The guy smiled with a twinkle in his eye and solved it the best way I've ever had anyone do it. We chatted about SRE topics the rest of the interview. Sadly he didn't end up accepting but I appreciated the good humor.

Ok now you gotta spill the beans, what was so entertaining about the fizzbuzz solution?

It was not literally the fizzbuzz problem, just a relatively simple problem I use for interviews. He solved it quickly, with good taste, and described some faster alternate approaches that I didn't hear from anyone up to that point.

Sorry it's a boring answer :-)

You make me want to come up with a working algorithm that actually hints at the Kafkaesque futility of algorithm interview questions.

I once had an interviewer wax poetic about fizzbuzz, the multitude of ways to solve it, and what he considered to be the most elegant of answers after I gave him a solution. I was sitting there thinking "I think you've missed the forest for the trees here buddy" but just smiled and nodded.

The whole situation is quite pathetic.

Oh no, there’s no bypassing the crap anymore with companies you don’t know personally.

I've had to use a binary tree couple of times. And when I did, I recognized the problem as a binary tree problem, and I read up on binary trees, and then used them. For about a month after, I'd have been able to do a lot of tree operations on the spot. Then the the material gradually faded from short term front loaded memory, and my long term memory stored the relevant awareness of the problem so I'd identify it should I have to look it up again.

> but have yet to run into a time where I needed to understand or write a binary tree.

I ran a UI team for 3 years, we built a UI framework, then the UI and apps on top of it.

We lived trees and tree traversals. Understanding trees was essential to everything we did.

Do I ask people to balance trees? No, but I do care if people can understand traversals, and also how to manipulate and design tree structures to solve business problems. Being able to design the right data structure to solve a problem is an important skill, and trees are one of our fields fundamental data structures.

Not surprised, but not everyone writes frameworks. I write end-user apps. There's a lot of us, out there.

I have written quite a few frameworks, SDKs and APIs; both server-based and host-based, and never had to deal with this stuff. If I had, I would have done what I always do, when I get to that point: Learn what I need to learn.

I have been learning new stuff, my entire career. I don't know how to do almost every project I take on. I even wrote about it, here: https://littlegreenviper.com/miscellany/thats-not-what-ships...

One of my favorite questions to ask is how to find the first cousin of a node in a binary tree.

A lot of people try to start at root, enumerate the level of nodes for the entire tree, and then return non-sibling nodes at the same level as the node we want to find the first cousin of.

Which works, but it is O(n) and a lot of work. People who know about parent pointers in trees just walk up a couple levels and then down a couple of levels.

I consider it a fair question because, it has no gotchas, it is just understanding how to efficiently walk around one of the most commonly encountered data structures.

My other go to question is provided a library function that can schedule a callback to run anytime in the next 2147483ms, write a wrapper that can schedule a callback at any arbitrary time in the future. For advanced candidates I provide a library of date/time functions and they have to take in a date/time and using the provided limited functionality scheduling callback, call the passed in function at the proper date/time.

This is a very simple problem, and one that I've encountered in real life[0].

It is a trivial, but again real life problem of building functionality on top of a limited platform API. I have seen this question trip up countless candidates, who try to seriously over model the solution. I have no idea why a class with 1 function and a couple int64 variables counting down time seems so hard!

(Old school C programmers tend to get it right away)

[0] Windows timer APIs like their 100 nanosecond parameters, though now days they all have modern 64 bit FILETIME variants that side step this entire issue.

> I rarely had candidates that had significant portfolios

I think that is the thing. The vast majority of software engineers have only worked on closed-source codebases so reviewing their previous work is impossible. That said, what I have generally done is to just use interviews to talk about previous work. It is usually pretty clear in the course of a 30 minute interview who has actually done the amazing things they claim on their resume and understands how to build software systems and who doesn't.

Exactly. I ran a fairly "high-functioning" C++ image processing pipeline team, where every engineer had decades of experience. They were a diverse and individualized bunch of folks. We worked together well, as a team.

Unique talent was what I was specifically looking for. Since my company paid "competitive" (i.e. "low") wages, I had to look for "diamonds in the rough." We did interview some highly qualified people, but they tended to defer, when offered.

I feel that I was quite successful, and kept highly talented engineers for many years, but it made the search challenging.

"Cookie cutter testing" wasn't even an option. I'd have been crazy to ignore every advantage each unique applicant had to offer.

I like to call this "hiring for potential" where you try to hire people that may not have the track record but have a lot of potential to do great work.

As someone that's in the market right now, I have found "competitive" to mean "low" as well. It's a meaningless term. Competitive to what?

Competitive to before there were open websites tracking salaries.

You can't even know their portfolio is their portfolio. I had a candidate send me a link to their portfolio, and when I asked them why one of the apps had someone else's contact info at the top of some files, they ghosted me.

I've had people tell me that I "faked" my portfolio. If I did, then I am a diabolical genius, and you should hire me, because I did such an amazing job, faking tens of thousands of lines of single-author code; maintaining a consistent style, throughout, along with dozens and dozens of articles, blog entries, and documentation examples. Extra credit for "faking" years and years of checkin comments. Since I sign my commits, it's not difficult to figure out who did what.

I suspect some scammer was running a game on you. They tend to go "over the top," as "dumbass filters." If someone responds credulously to an outrageous claim, then they are a "good mark." The fact they ghosted you, tells me it was a scam. I have encountered many, many scammers, since leaving my last job. It's a pretty tough field, these days.

One of the reasons that I stopped looking for work, was because a lot of hiring managers and recruiters believe that it's important to insult applicants, right out of the starting gate. I think that HR policy, in general, these days, is to always keep the applicant in a supplicant position, so you are in control of the relationship. I think that LeetCode tests are part of that game. Sort of like "hazing."

> I suspect some scammer was running a game on you. They tend to go "over the top," as "dumbass filters." If someone responds credulously to an outrageous claim, then they are a "good mark." The fact they ghosted you, tells me it was a scam. I have encountered many, many scammers, since leaving my last job. It's a pretty tough field, these days.

What would be the purpose of this “scam”?

I'm not 100% sure. I guess you could ask them, but I have been impressed with the ingenuity of scammers.

It may be as basic as getting you to open an infected document, of some kind. We tend to exchange a lot of stuff, when we do employment negotiations. I'd think an engineering manager, at a sensitive level, would be a juicy target. I've had any number of LinkedIn attempts to get at me, through offers of employment, basic networking, and attempts to get me to employ (I have a title as a CEO of a couple of 1-person companies, so I get a lot of these types of attempts).

My favorite ones, are the "attractive young women" that want to "link up" with me. I'll bet a lot of folks fall for that.

Then the screening process just worked, and in a very efficient way! Theoretically, the question could even happen before the interview.

Instead of wasting time with somebody floundering tests and offering excuses, or even have a cringe situation. That is why i also like the portfolio candidate.

> and when I asked them why one of the apps had someone else's contact info at the top of some files, they ghosted me.

So you can know if it's really their portfolio.

Just asking some basic questions about the code in the portfolio will make it clear pretty quickly if it's their work or not.

"We want our candidates to have a portfolio of open source software, but won't allow them to work on open source software while in our employ."

That's also something I keep hearing in anecdotes.

What do they think will happen if you do work on open source software while in their employ?

Most likely nothing, but most companies seem to have the expectation that OSS has to take a backseat

Yea. Give me free code, don't make free code is a common problem.

Your employment contract could stipulate that any programming done outside official work is owned by the company. A “work for hire” of sorts. Whether these “copyright assignment” clauses are legal depends on your jurisdiction.

Personally, I don't work on open source software. My personal projects are public, free and open source but they are useless to anyone other than for me.

The main reason I publish them publicly is ... I don't know why actually. However, one benefit to public github repositories is I can try out various services that are free for open source projects. This way I have exposure to these services which is nice. Also it is easier to get help from others or ask questions when I get stuck.

In my experience, I've found programmers very helpful as long as I am willing to put in some effort.

For me it looks very similar to training. they want you to have x, but don't provide the ability to acquire x to their employees.

I have this problem. All my code belongs to freelance customers or projects I intend to monetise at some point (and aren't even vaguely ready to share with the world).

Also, there's nothing stopping someone from copy/pasting entire projects into their portfolio.

I would totally ignore someone's portfolio when interviewing them.

Then, no problem! We won't be bothering each other.

Too bad. you look like an interesting chap to know.

I do find the "portfolio" thing interesting, because it clearly puts us in the same category as artists.

Accountants don't have "portfolios", interviewers don't ask to see their spreadsheets. Managers don't have saved video recordings of 1:1 employee meetings for interviewers to look over. Engineers don't have a sample set of bridges they've built [0].

Artists (and by extension, designers) are the only other profession where you're expected to have a portfolio of your work for a prospective interviewer to look at.

I guess what I'm trying to say with "I'd ignore the portfolio" is that if we're going to emulate another profession, let's copy the engineers, not the artists. Artists are typically underpaid and undervalued. Engineers are highly respected professionals.

[0] well, they might have photographs of the actual bridges, but not a sample selection of actual bridges. For some reason I can't point an interviewer at a previous employer's app and say "I built that" like an engineer can.

> Engineers are highly respected professionals.

So artists and designers aren't? There might be a few folks around these parts that might take issue with that. I was once an artist, and that training has been of significant value, in my engineering.

I list Adobe Illustrator as one of the 4 applications that I use every day (along with Xcode, BBEdit, and SourceTree). It's what I use to generate graphic assets for my development work.

Anyway, we could dance this jig all day, and I don't think it would solve any pressing world issues. Not a big deal. We don't need to prove anything to each other.

I'm not saying for a second that artists shouldn't be respected professionals. I'm saying they tend not to be: my mother was a professional artist until she got fed up of trying to make ends meet and got a nice boring conventional government job and did her art as a hobby.

Yes, agreed. It's not worth getting too bothered by it ;)

Funny, I was going to say that artists more closely resemble our profession than engineers.

Engineers are mostly standardized, and the salary range reflects that. There are some very well compensated engineers, but the bulk do okay, doing normal work.

And critically, a board certified engineer stamp is an engineering stamp. Regardless of who it comes from.

On the other hand, artist compensation is directly correlated to ability to market yourself, current trends, and overall skill.

You have artists who are struggling to make it a job (in our world: entry level web design, analysts), artists who are doing okay with careers (enterprise software dev), entrepreneurual artists (startups), and superstars.

And critically... their degrees tell you almost nothing about which category they're going to be in.

That's interesting. I guess it depends on perspective - yes you could be a "rockstar" dev who talks at conferences and makes gajillions writing scalable MVP's for SV-funded startups. In which case, yes, your value is directly linked to your ability to market yourself.

But most aren't. Most devs clock in, write some code, clock out, go home, do something completely different. It's a job. They operate inside the salary bands of their organisation, and they do okay, doing normal work.

For sure, but the defining characteristic of a portfolio is it differentiates a candidate, when there other good signals to do so don't exist.

And specifically, when there are no signals that can be normalized across candidates for comparison.

I feel like that's pretty descriptive of most general software development.

You re not in Asia though, maybe. Here, people from some large subcontinental country that I wont name for politeness, if required to have a portfolio, would find a way to all have the same copy pasted one.

I literally had to ask a guy why a group of 5 of them all had the same fucking letter for letter resume...

Ask.idiotic.questions.to.weed.out.the.base.morons.

Balancing a binary tree is a pretty unfair question, but I wouldn't say any binary tree question is unfair. "Find a node" in a binary search tree or "check if a binary search tree is valid" seem..pretty easy.

Easy is not the point. Neither is “fair.”

I can usually do … OK … on these tests, but I’m probably mediocre, at best, as it’s often the first time I’ve encountered the test.

I tend to write naive code at first, and make sure the result is solid, then optimize. I will sometimes also experiment; trying out all kinds of harebrained stuff, before settling on even that “first try” code.

That workflow has worked extremely well for me, in my vocation, but does not present especially well, in quick whiteboard tests.

My workflow results in very high-quality, performant code, but iteratively. Also, not all code needs to be optimized. Sometimes, leaving the naive code, means it is more maintainable. I also habitually document my code as I go, which has proven unpopular, with testers.

People just out of school, or who spend hours each day, practicing LeetCode, will usually come up with an optimal solution, done the way the tester expects, first go.

That's what I do, and I have no trouble communicating that during a whiteboard interview. Have you considered that you're being tested for communication ability?

Sure, that's fair, but in both binary tree examples I listed the most efficient answer pretty much is the naive answer. I don't think you need to be fresh out of school to remember how binary search is implemented.

I think it's almost necessary to ask a candidate to do something unfair in order to evaluate them.

Not right out of college and don't balance binary trees every day? Submit a portfolio to review.

Don't have time or permission to write open source code outside of your paid employment? Well, let's see if you can balance a binary tree.

Both of those are bad? Well how about a take home exam you will need to set aside time from your schedule to complete.

Seems like the perfect interviewing process would have multiple avenues for a developer to demonstrate they can actually program. Of course, that requires the company taking the time to set up a process that can evaluate candidates across all these evaluation methods and somehow compare them fairly.

I would be strongly in favor of some kind of professional license, where every X years you must retake some exam, similar to the P.E. license in other engineering disciplines.

Benefits:

- Employer: by scanning for resumes with this license, the employer saves time and money that would instead be spent on technical LeetCode-esque interviews.

- Employee: a singular license would make you more attractive and compel a higher salary. You wouldn't have to grind LeetCode for 3 months before a job hunt.

In my "utopia", FAANG/S&P 500 companies + universities (MIT/Harvard/Stanford/etc.) would band together to form a third-party committee and standards board that would design and proffer this exam. Having those big names in charge would give it instant credibility and make it the de facto S.W.E. P.E.

Yes and no. I think it's important, for certain types of coding; maybe not so much, for other types.

FAANG companies are willing to put their money where their mouths are. They pay quite well. I think it would be quite reasonable for them to require a standardized certification, and people would bust their butts to pass the cert., for a chance at the money to be made.

A lot of startups, on the other hand, have much "earthier" needs. They may want people that are more "generalist," for a lot of their roles, and might be able to use support for eventual training to the tests as a carrot. If they treat their employees well, they could get some certified engineers for a bargain price, out of the deal.

Also, there is such a huge variety of coding specialties. Algorithm coders work with data processing, but you also have people that may specialize in ML, and that could require entirely different skillsets (I am not an ML person, so I don't know whether or not standard DP algorithms are ideal for AI work). I have done a lot of communication and device control stuff, and that has some facets that few of your "standard" developers see.

Then, you have toolsets and frameworks. These are really what makes a developer rock. Someone who really knows their way around specific toolsets, or deep language knowledge, may be what you need. I can learn a new language, in a couple of weeks, but knowing it well can take years. And there's a better than even chance that knowing it well won't be particularly valuable to a company.

Lot of variables. Software is a very, very dynamic place, and it's really difficult to distill meaningful standards from it, that aren't rendered obsolete, almost as soon as the ink dries on the documents.

I'm being a bit 'tongue in cheek' with this... you mean like... ABET or NCEES, which handles the FE, EIT, and PE 'tests'?

Also, ABET already accredits Software Engineering and IT programs; and NCEES has had a Software Engineering PE in the works for the last couple years (I haven't checked recently, but iirc it was slated for release in 2022(?)).

Toy problems seem to exist in pretty much any technical discipline, but it seems most acute in the software world; and I've come to suspect that it's accessibility to making those. Code is quick and human-centric technical item, where as something like a bridge rectifier, amps, fets, and PID controllers aren't necessarily items you can just 'pull out' in an interview; you can see if someone's comfortable with CAD programs, you can see if someone has the chops to understand when a BJT is more appropriate than a MOSFET; but you can't really do that quickly as a 'whiteboarding session' so other technical fields are required to be more selective since you can't just slap out a FET configuration for a D Class amp without spec sheets, requirement gathering, probably CAD design, and other design steps; but you can sure-as-shit slap out a MVP of a SPA customer portal without any of that.

Divorcing "coding" as the act of writing code, and "coding" as the mental process of building a well designed app/system would bring the software world into better alignment with a lot of the rest of the engineering world; and would make something like a SWE PE more viable in the first place. I also don't know if you've ever sat a PE, but they're also __OPEN_BOOK__, since we know that it's a lot of knowledge to have in your head, and it's a better test if you know where to look something up and how to use the right tools (kinda like a 'take-home' exam in software interviews, but not nearly as exploitable and scummy); bring your reference material, but so much ground is covered that if you don't know your stuff, you're failing the PE no matter how many reference books you bring along.

> Fizzbuzz is one thing. Balancing binary trees, is another

The thing is, companies don't want to employ any random person who can code and meets the minimum bar, they want The Best™ - and that's when things get competitive, and arbitrary.

This is the other side of the coin to a recent HN thread (on pay transparency/whether tech workers are interchangeable[1]). My thesis is if you agree that some are many times more productive, the so-called 10x - and you want to hire those: then you need to test for that in the interview process, hence the exploration of the less-visited areas of Data Structures & Algorithms. If any engineer who meets the minimum requirements will do (i.e. fully interchangeable), then anyone who can pass FizzBuzz and is familiar with the tech will do. Most companies are in the latter group, but tell themselves they are in the former, resulting in the current explosion of "Change this unsorted linked list into a balanced tree with the least time complexity" questions.

> If a candidate has a portfolio, you'd be absolute idiots to ignore that portfolio.

I'm guessing only a minority of candidates have a portfolio before applying for a job. Most of SDE output belongs to their past employers, so expecting portfolios will also filter out a whole lot of people who can do the work, and I'd rather grind HackerRank than hastily build a portfolio just to apply for a job.

1. https://news.ycombinator.com/item?id=28536084

Lots of binary tree questions are just a variation of depth search. I'm sure I've actually coded some variation of depth first traversal at least a hundred times during my work as professional programmer in past ten years. So those questions are not really as impractical as some might think. Being able to write simple binary tree traversal correctly is absolutely minimum I would expect from an interviewee.

Depends. I write end-user UI apps and device control apps.

I don't know if I've ever done that. The Apple OS framework has a lot of those tools, built-in, and it wouldn't make sense to circumvent them, unless I was writing a cross-platform "engine," of some kind.

If you were interviewing as a device control engineer, then a minimum, would be understanding of things like ring buffers, thread contention, asynchronous callbacks, timing diagrams, etc.

If you were interviewing for work with Apple device development, then knowledge of Core Bluetooth, as well as basic Bluetooth, would be important. WiFi and networking might be useful. Maybe BSD sockets, USB, etc.

If it were as a UIKit app engineer (classic native), then understanding of the various widget types, delegates, data sources, etc., as well as the six gadjillion different "extra spice" features that each widget has, as well as the proper way to do things.

SwiftUI is gonna add a lot more facets, as it's built around Protocol-Oriented Programming, and a rather "reactive"/KVO model that differs substantially from the "classic" model. I have yet to do a "deep dive" into SwiftUI. I plan to tackle that, once I have the app I'm working with at a ship level.

And, of course, an intermediate-to-advanced familiarity with Swift would be expected, as well as the Foundation framework.

"Jargonaut". I'm stealing that...

To some extent I sympathize with you: I'm older, have seen some rejections for posts I wanted that I would be a very good fit for, and have a strong public portfolio of work that doesn't seem to overcome minor shortcomings in algorithm interviews.

However, I still think you're pretty badly missing the point:

(1) Algorithm coding challenges test whether a candidate has the ability to go to the internet, research and get good at a technical skill. That is absolutely an appropriate thing to be testing.

(2) Algorithms are a beautiful cornerstone of our profession. Perfectly reasonable, and kind of nice, to use them in our hiring processes as described in (1).

I didn't miss any points at all; let alone "badly." Be nice.

In my experience, there was never any "go to the internet, research and get good at a technical skill." during the interview. That would have been nice. It was "Sink or swim, right now, while we laugh at you," So I guess that you mean I should dedicate an hour or two per day to LeetCode, like a lot of folks do.

Why the living heck should I "go to the internet, research and get good at a technical skill" that has no applicability to the work I do, every single day? I learn what I need, when I need it. You don't want what I have? Fine. You won't get it. I worked long and hard to be in the position I'm in now. I don't need to "play the game," as I have real work to do. I don't really care whether or not I make money at it, or impress anyone. I don't need anyone's approval or validation for the work I do. The people that matter, are quite aware of my capabilities. They see what I do, and use my work, every day. I have done two TestFlight releases already, this morning.

I don't know how to do just about every project I take on[0]. That's S.O.P. for engineering. I've been working that way for more than thirty years. I've learned a lot. Sorry if it isn't what some people think is important, but I have been delivering and shipping software, since 1987. I've worked for some pretty intense organizations, and they seemed to be happy with my work. I've written stuff that is in use -every day- by thousands of people, in multiple languages. There's a small chance that I might actually have a clue.

I write code -lots of code- Every. Single. Day. Don't believe me? Look at my GH ID[1]. That's not "gamed." If anything, my tagline should be "Don't believe me? Look for yourself." I can back up every word I say. If I'm wrong, I freely and promptly admit it.

For example, today's task is learning the proper way to set up an edit session for a particular type of user interface. I haven't done it before, and I'll be "go[ing] to the internet, research and get good at a technical skill," in order to get the job done. It will probably take me a day or two to get good at it, and apply it. I do this multiple times per week.

[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...

[1] https://github.com/ChrisMarshallNY#github-stuff

Ok, sorry for saying "badly". I don't think you really addressed my point (2). Given your experience, I just don't see what you have against implementing some 20 line algorithms for people, if it's what they want, even if they shouldn't want it. Just a little compromise, and like I say, they're a beautiful corner of software engineering. And that little compromise is all it would take for the team of actual adults, doing actual serious engineering work, behind the silly interviews facade, to get to work with you. I think they'd like that, and you'd like that.

Sure, but I am now officially past the willingness to waste time, making random people happy. A couple of years ago, I was willing to do this, but no longer. It was made fairly clear that the new tech field doesn’t have room for an old war horse.

Since I already have a very substantial "nest egg," it was time to just start living off that, and doing work that I want to do.

I immediately sought out some folks that wanted to do a free app (it actually has monetization potential, but we aren't really paying attention to that, right now) that would help recovering drug addicts network and support each other. They were not having much luck, getting people to take their effort seriously.

I already had a full-fledged generic application server that I had written, just for practice[0], so I said that I'd build them a frontend, based on that server, and I'd do it for free, because I like to code, I figured that I'd learn something (I haven't done a social media app, yet), and it would give me a chance to develop some theories about hyper-flexible software methodologies that I'd had kicking around. I knew they didn't actually have a clear vision for their product, and I knew that I could develop it in a way that would help them to refine it. I just got off a video call with the CEO and a backend guy, where we mapped out a "bare spot" that needs paving. I guarantee that many startups would absolutely drool over the process we are using to develop this app.

It's been great. I haven't been this happy in my entire career.

[0] https://riftvalleysoftware.com/work/open-source-projects/#ba...

I agree with your general sentiment and I think algorithmic questions are fine. But it seems to me that the common type of questions are very non-typical for every day problem solving and programming.

For example I as a full stack web dev, never write sorting, very rarely search / string or scheduling and so on. However I happen to like puzzles and coding challenges, so I do them fairly regularly on a Sunday. Do people want to select based on hobbies?

Actually tricky stuff (tricky as in I have to think more deeply and do actual design) I have to do includes for example:

- caching and synchronization

- concurrency/asynchronicity issues

- deep SQL queries

- schema (DB/API/UI) design

- tree/graph traversal

- refactoring and code design

- breaking down (deeply coupled or complex) features into sensible tasks

- (declarative) state machines

- asking the right questions about an unfamiliar domain and deriving the right abstractions and data structures

- error handling, invariants, correctness...

Those apparently rarely come up in the types of questions that for example leetcode et al suggest. It's typically "A&D with a twist".

I've been working through HackerRank, LeetCode, etc - they have nothing to do with actual software development. And most of them rely on knowing some obscure algorithm or "trick" to solve, which you wouldn't do in real life - you'd Google the problem, possibly add a dependency, and be about your business.

But I've also been in technical interviews where the problem was used as a discussion point, rather than a challenge, and I get that use case - though "let's build a web server" might be a better problem to solve collaboratively.

Interesting, I'd say 80% of the 'easy' level questions are very relevant to understanding data structures one encounters on a day to day basis (maps, trees, lists, arrays) and basic ability to manipulate those with loops or recursion. I think those are very good interview questions.

I'd also say 90% of medium and hard questions are exactly what you said, relying on a relatively obscure algorithm.

42 years old. I've been in the industry 20 years now. Does that make me a young whippersnapper? I don't know. I can say that I refuse interviews that don't include job-relevant questions. If I'm asked to do work as proof of experience, I refuse any requests that aren't job-relevant. After this many years in the industry, if someone can't take the time to look at my publicly available body of work, call some references (which I always provide access to), then I want nothing to do with them. If your measure of someone's ability equates to fizzbuzz YOU'RE PART OF THE PROBLEM WITH TECH HIRING.

The grads probably aren't aware enough to know the difference, being new grads. And I'd wager that's why you're targeting them.

I don't see fizzbuzz here as the full measure of someone's ability. Its a filter. I have had many candidates make it through phones screens who seem quite capable only to start working through a series of problem solving questions and they cannot do it. People with job history that suggests they should easily be able to.

With no specific language requirements (pseudo code is totally fine) and they can't even write a for loop. We ask to see how they approach the problem, not to get a perfect answer. Ask questions about it, talk through your reasoning, work with us on it. Not worried about off by 1 or specific syntax, just getting to know them and how they work through a problem.

We tried hiring a few people who didn't perform as well on this, and it was a mistake every time. And anyone who had no problems with it was always a good hire.

Now, obviously there is a problem with the screening process when people who can't actually write a for loop get through it, but until that is fixed, you have to filter them out somehow. How have you approached that in the past? I would honestly like to know how to fix it.

>The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program.

It's perfectly possible to be a 10x engineer but not being able to solve some obscure recursion problem on a whiteboard. All it does is forcing candidates to study obscure problems before the interview and hope they get lucky and receive a problem that they have memorized so they can pretend to have never seen it.

Or, you know, they're smart problem solvers and don't need to rely on memorizing.

Is that what you really end up testing though? As parent mentioned this can be broken by simply memorising, so are you sure the candidate is a good problem solver or are they just good parrots?

So I think it's actually evolved into a weird sort of test of conscientiousness. Originally the idea was probably that we will test people's abstract problem solving skills. Can they come up with a solution on the fly? Ok, now can they figure out any clever optimizations?

But at this point it is sort of expected that if you are interviewing with a FAANG you will be getting these sorts of questions (and they tell you that up front), so it becomes a sort of test of "is this person willing to spend 10 hours preparing for an interview"?

Yeah I suspect this is the case, the original intention and structure was solid but it's been progressively shifted into that FAANG space. I think the only solution is probably a question tailor made to the company interviewing, that doesn't rely on leetcode-style approaches to solve.

10 hours? Preparing for FAANG interviews requires months of preparation.

I hardly think a solid interview question can be solved through memorization.

I’ve had interviewers ask about cycle detection in a linked list. The answer was of course the classic tortoise and hare algorithm. Which took ~15 years to come up with, and was found by a Turing award winner.

Anybody who claimed they “came up with the algorithm themselves” in a few minutes in an interview is a liar, and anyone who takes them at their word is a fool.

Well, it's not a rocket science algorithm. But regardless, it's a very bad interview question indeed.

You don't have to solve it, they are interested in seeing you _try_ to solve it.

Every interview I have done expects you to solve the problem.

And most expect it to be solved perfectly on the first try. I was rejected by Google when I solved a LC hard problem (in Google Docs), and when asked the time complexity I said something like, "It's O(nlogn). Wait, it's O(logn), [explanation why that's the case, which was correct]." Feedback: "struggled with figuring out the time complexity." *eye_roll*

Honestly, stuff like this makes me wonder if there's some metric that judges the reviewers, such as "percent of interviews in which feedback is given".

I've experienced this as my company recently implemented metrics for code reviews, with one of them being "percent of lines commented on during a code review"; which unfortunately makes me comment on lines that I wouldn't usually do just to serve the metric.

I'm wondering if they have a similar thing.

late reply, but I know for Google they're required to start participating in interviews to be promoted to L4 (?) and above, whether they have interest in it or not. Maybe there is a disproportionately harsh performance penalty for recommending someone for hire that shouldn't be hired, vs the other way around, and the easiest way to "tick the box" for the promotion is to do the interviews and reject everyone (unless they're seriously impressive).

( Opinions are my own )

Anacdata: last year I passed the interview at Google. I completely failed to solve one of my coding interview questions. I demonstrated I knew what to do but I attempted a fancy way to write the code and it didn't pan out. Completely fell on my ass.

Other interviews went very well though. Only comment I got was "X said your code was a little messy" because I used python generators + list comprehensions.

You can totally fail a question in a tight time slot if the process is built right.

What is stupid is the variability in opinions if interviews. This one dude disliked list comprehensions so much he lowered his rating of me despite this being a normal thing for python programmers. You have no way to know if you hit a nerve ahead of time for an interview and it sucks. I had similar things happen with things like discussing the C spec with interviewers in questions like "what happens when you dereference a pointer to 0" and then you have to say "you want me to say segfault but this depends on the vmm and ring your process is running on".

And the variability, or just the uncertainty in the interview of what they are looking for.

I got dinged for using a promise over async/await (for a backend job that mostly tested my React of all things).

I had absolutely no idea that mattered to them.

>seeing you _try_ to solve it

And pretend that their judgement is any better than coin tosses.

If I am ever exceedingly bored with my life I'll start applying for some jobs just to throw some shade in the form of "the brightest minds of psychology have failed at doing what you are trying to do, with far more resources and time dedicated to it... why do you think you can do it?".

It is better than coin toss. If you can't communicate a convincing solution or approach to your future team mates why should they hire you?

Hah, I don't mean to be rude but, this is what everyone claims they do, but no-one actually practices it.

The simple fact of the matter is, is that if you can't 100% solve the problem, in 30 minutes or less, without asking questions related to how to construct a solution, and cover all edge cases, and come up with the absolute top-tier optimal solution, you're getting rejected.

That is why it's worthless as an interview technique. Everyone plays this whole song-and-dance about how they "just want to see how you approach a problem you might not know how to solve" but, in the end, the only thing that matters is regurgitating the top leetcode solution to the problem.

This is so true, most top companies expect folks to write flawless bug free code of problem in 20 minutes or less now. Some expect two problems in 45 minutes now (if you are unlucky really one medium and one hard). If you write a sub-optimal solution you are rejected for sure. If you haven't grinded leetcode/hackerrank and haven't seen it before there is no way you are going to solve a hard problem in 20 minutes - lets say 10 minutes to think and 10 minutes to write the code for a hard leetcode question.

Obviously, since large companies _have_ lots of employees, either their tests aren't crazy hard, or there are lots of people way smarter than you for whom the same tests are manageable.

Most of these live programing exercises are far too demanding when you consider the stressful environment and the time pressure that candidates are under. It selects for a certain kind of fresh-out-of-uni candidate who has been solving puzzles every week as part of their assessments. Once you've been out of university for almost a decade, some things fade from memory and you need more time to solve those puzzles because you can't rely on your 'muscle memory' like a recent graduate can.

These puzzles say nothing about a candidate's problem solving ability, they're just monkey tricks that can be rehearsed.

Who is smarter; a candidate who can solve a Rubik's Cube after seeing it for the first time or someone who has rehearsed it hundreds of time and knows the algorithms? It's not even fair to compare these two people, the former is unequivocally a very intelligent person and the latter could potentially still be an idiot... This is true even if the second person could solve it in one tenth of the time in front of an audience while blindfolded and riding a unicycle across a plank suspended in mid-air above crocodile-infested waters.

And this barely scratches the surface of what's wrong with tech companies' hiring processes. This puzzle-solving ability is overvalued and the ability to design/architect good systems (I.e. seeing the big picture and using common sense) is extremely undervalued.

I am on the other side of the table too. I also design the interview process. The things I look in an interview

- the ability to code with quality

- the ability to learn and grow

- track record to deliver business value

In my experience, people are wasting too much resources on interviewing. And the process is never meant for more senior positions. Engineers don't like it, and the outcome cannot be falsified (what if we hire someone with a light weight process, would it turn out worse?) I am saying specifically about interviewing, as opposed to hiring in broader sense. What you want is a process that evolve with your demand/available resource, not hardcoding of 2 sessions of coding (oh and with shadowing, so to grow interview skills of the team, of course!), 1 session of architectural design, 1 experience deep dive, whatever. Is this topic something people are interested in though? I might try to write up the thinking behind our process

These are just 3 arbitrary points.

E.g. I’m pretty certain you’re not advocating for hiring developers who can’t have a civilised disagreement, yet you don’t list anything about collaboration or communication or ability to put team before self in pursuit of a common goal.

Hiring well is hard to do fairly and accurately. There’s no pithy shortcut that can be wrapped up in a blog post.

About the best I’ve managed to go in 15 years of hiring is recognise that i have biases and recognise that I’m not always that good at seeing my biases.

Agreed those are arbitrary point. And so is every hiring process. Pick some attributes that helps you define good people, good business, good tech and that's it. At the end of the day, it is a subjective process. I bet whatever "objective metrics" we come up at the end has some "rating" element in it which is subjective. Acknowledge the arbitrariness within the team and to the candidate in my opinion helps bring more fairness to the table. And also why I think it is worth less to overly religious over the hiring process

> track record to deliver business value

A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piece of software to begin with, and have an idea how their work actually affected the bottom line.

That kind of thing is mostly outside of anyone's control. If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.

If you've been working as a developer for more than a few months you really should have delivered some form of business value. Building a proof-of-concept that allows a company to explore an idea before being thrown in the bin is still business value.

This sort of question is mostly asked to understand if you know/care how your work impacts the bottom line.

My point is, whether you can know how your work impacts the bottom line is often outside your control. Especially at larger companies, where most people work on tiny pieces.

For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant.

Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]).

[1]: https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s

It shouldn't be "Delivered business value and here's exactly how much to the cent."

It's more "Did something a manager considered useful."

Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare.

Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed.

Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.

The counter to that is the allegory of the bricklayers.

" A traveler came upon three men working. He asked the first man what he was doing and the man said he was laying bricks. He asked the second man the same question and he said he was putting up a wall. When he got to the third man and asked him what he was doing he said he was building a cathedral."

I get that you're not an accountant. However, I want to know that you understand the impact of your work. Someone who understands the larger picture will be able to cogently argue why this technical debt or bug is more important than that technical debt or bug. It's also the job of product to understand it, but the best product teams I've been a part of have multiple team members who understand the business impact.

Sometimes, you'll be lucky and say that your feature contributed a million dollars to the bottom line. That's luck to some extent. However, I'm more interested that you understand the business context outside your individual work.

One guy I worked with had been a developer for 15 years and the project we were on together was the first one that had actually shipped in his entire career.

The industry is a complicated place with massive resources wasted on projects that go nowhere.

> If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.

Honestly I'd be ok with an answer along the lines of "I got moved onto a project that, for $reason, had no chance of ever seeing the light of day. It was obvious why it wouldn't survive, but the business needed to keep it alive because $other_reason. Even though we never shipped, we met objectives $x and $y, we struggled with $z, and we learned quite a bit about $w. After the project was finally killed, we were able to apply what we had learned to other projects."

This at least demonstrates that the candidate understands how the project related to the business, how they can relate some of the technical aspects to business processes, how they acknowledge their failures, and how they extracted some success from a failure to apply to future efforts.

It allows us to have a conversation about different aspects of the project -- technical, business, interpersonal / political, etc.

I've been on projects across the spectrum from "never-shipped death march" to "mature cash cow", through various levels of team & management dysfunction, and I probably learned as much from the horrible failures as I have from the successes.

A team always need to know what their goal is. For start-up, an engineering team might focus on product iteration/finding product-market fit. If you tell me scalability was your focus in a 3-man, 3-months old start-up, my response will be somewhere between skeptical and confused. On the other hand, for a later stage company, defined by any reasonable metrics, be it revenue, DAU, API calls, stability and maintainability are some sensible consideration. So I do consider track record to deliver business value an important signal

Except you're not hiring a team here. Only a single dev, who may not always have been on teams that have the right focus, and leadership that supported that focus.

  What can you tell me about your last job?
  Well, I overhauled the configuration GUI.
  How did that impact sales?
  Err, I don't think it did. It's not a feature we showcase.
  Did you at least made the product better?
  Actually, no. It just made it more complex and brittle.
  Wait, you made the product *worse*?
  Could not help it, the execs insisted on XML compatibility.
  Maybe they needed it?
  No, we had total control over our configuration files.
  Why didn't you tell them?
  I did. They wouldn't listen.
  Why not? You're the expert, you should have convinced them.
  ...
  I mean, here we need people who can deliver business value.
  Well, this time I couldn't. They wouldn't let—
  How would you rate your communication skills?
  Err, good I guess?
  Yet you couldn't convince management?
  ...

I hope this conversation is not realistic. If it is, and it ever happens to me, I'll be sure to look for another company.

> Actually, no. It just made it more complex and brittle.

If that line does not look like a strong "hire" signal to you, there's something wrong about you.

Anyway, I think the large majority of the people I've seen interviewing anybody (including me) would use it as a "no hire". I guess I wouldn't want to hire the large majority of people I've seen conducting an interview...

> The tech interview with the ludicrously simple questions are all about finding people who 'get it', and are actually effective at it. Which is why it persists.

No downvotes from me, friend.

I get what you are saying, but I wish my tech interviews ludicrously simple. They tend to be the opposite, and it seems to be worse when you are a front end UI engineer. Not only do I need to be up to date on the new new javascript hotness, I need to be able design twitter's back end architecture and implement min / max heaps on the spot on a white board (now in coder pad, hacker rank or, even worse, google doc) in about 20 mins or less.

That's asking a lot.

Been interviewing lately for front end positions, it's rough. It's leetcode questions that touch on things I don't do that much when building UIs (or ever do, like why would I implement a sort ever? I don't even use the built in sort array method that often) and very specific questions about whatever front end framework they're using, so if it's not your daily driver at the moment then good luck.

> they are to filter out people who simply can't program.

The problem is they also filter out people who get nervous during tests. I'm someone who marginally failed a programming test and am now one of the most in-demand developers at my company (where I failed the test). The tech director who rejected my failed test has since told me not hiring me to his team at that time was one of the biggest mistakes of his career and I've also heard he's stopped being a believer in programming tests because of my application.

I've also been involved in hiring decisions and I've hired people who have bombed programming tests (and in ways where it was clear they just didn't grok the logic they should have). They've also been perfectly fine contributors, because our test questions required knowledge that wasn't going to be relevant (a CRUD-gluer doesn't really need to be proficient with geometry).

I still believe programming tests are useful, though. In the hiring I've done, it has been one factor to discuss during the interview. We always give developers a take-home test and then discuss the results in the interview. If they messed up, we illustrate where their solution is wrong and see if they're able to reason through the problem. If they didn't mess up, hey, that's a great sign.

If we can see them really start re-reasoning through the problem, that's a good sign that they (a) don't take programming failure personally and (b) are the sort of person who will re-evaluate what they think they know. On the other hand, if they just throw up their hands and give up without really giving the problem any extra effort, that's a bad sign. Our reasoning for this approach is that everyone writes bugs, but nobody gets to give up when fixing bugs.

As an aside, we've never tested someone who just couldn't write a for loop at all, so it's possible our hiring pool is different and so our needs/solutions are different.

And for context, the take-home test questions we use (they're always the same and they're not a secret) are:

1. Given a rectangle and a point, write a function to determine if the point is within a certain distance of the rectangle.

2. Given a string, write a function that determines if any permutation is a palindrome (this one's for the over-engineers who don't first think through the problem)

3. Write a CLI dice game where the computer cheats to maintain around a 70% win rate (there are some basic rules for scoring I'm leaving out for space - this one people rarely get totally wrong, but talking about why they picked a particular cheating mechanism can be enlightening).

Sounds like fun!

Is the answer to (2) just something like this?

If len(word) is even, check that all the characters in it appear an even number of times.

If len(word) is odd, check that all the characters in it appear an even number of times except 1.

I don't think you need to test for the length of the word. You just need to have at most 1 character that appears an odd number of times. My first instinct would be to scan the word character by character and use a set to check the number of occurrences:

  has_palindrome(word)
      s = empty_set
      for c in word
          if s.contains(c)
          then s.remove(c)
          else s.insert(c)
      return s.size() <= 1

If I'm not allowed to depend on an existing set implementation, I would likely fall back to a quadratic solution that counts each character. If there are special performance concerns I may sort the word before hand, or implement a special kind of set.

abcba is a palindrome

Yes it is, and it wouldn't fail my algorithm:

  a -> not in set -> add a    (a)
  b -> not in set -> add b    (ab)
  c -> not in set -> add c    (abc)
  b -> in set     -> remove b (ac)
  a -> in set     -> remove a (c)
  Set has 1 <= 1 element  ->  return OK

(Of course, "aabcb" would return yes as well, but that's the whole point: we're not asking whether a string is a palindrome, but whether any one of its permutations is.)

If the string is known to be in some specific alphabet (ie only lowercase a-z), you could use a 32-bit integer as an array of bools and toggle the individual bits between false and true. The final s.size() could be done with popcount(). Not even any sets needed.

(This type of stuff might fail the "overengineering" test that the grandparent comment talked about though.)

Whether that's over-engineering or not really depends on the data. For this particular interview question we might assume we have very little data to process, but real applications might want to scale that to a point where you actually care about performance (MMO permutation palindrome checker or whatnot).

Personally, I'd use the simplest implementation as a reference, and use it to test more optimised solutions if I ever need them.

You have non-quadratic alternatives. Sort the string and then start iterating through the characters. Keep a boolean for if you've ever seen a character an odd number of times. The first time you get an odd count for a given character, set the bool to true. The second time, you see the bool is already true so you know the word isn't a palindrome and can immediately return false. If you get to the end of the string without hitting that condition, return true.

Yes, that's what I had in mind when I wrote "I may sort the word before hand".

Emphasis on "may", though: for small enough words, sorting may very well slow us down, so it really depends on the data: are we processing long words, or lots of small words?

Oh yes, that's definitely better.

I dunno, as a CRUD gluer, Nr 2 is immediately understandable now that I’ve seen someone write a super simple alghorithm for it, but I would never figure that out for myself unless I spent a major amount of time (as the originator of that simple method undoubtedly did themselves, and more than I’ willing to spend on your interview).

Actually, the general answer came to me in about 5 seconds. I may have been lucky, though.

The crux here is to notice that the order of the letters in the word we're given does not matter (because of the "any permutation" part). So it must be a matter of counting the letters. GlennS got it right: https://news.ycombinator.com/item?id=28550511

The second insight was that only the parity of occurrence mattered. Having 2 or 4 or 6 times the same letter is the same as not having the letter at all, so I only have to retain "zero" or "one" for each letter. Sets are perfect for this: "zero" means "not there", "one" means it's there, and at the end I can tolerate at most one odd letter.

That’s quite possible. And probably because you’d worked on something where this applied before.

Also exactly the reason I posted my message since that doesn’t apply for everyone. People that already know may be blind to that though.

The disconnect is that the questions are not simple. FizzBuzz is great, always worth asking. It’s when people are asked to answer ridiculous questions that gets my goat. One interviewer asked me to develop a lexical parser in a one hour timeframe. This is stupid in the extreme.

> FizzBuzz is great, always worth asking.

Up to what point? Are you going to ask a 20 year veteran of the industry to be performative in order satisfy an entry level screening?

It depends. If the veteran is responsible for architecture, process, framework, then no. But, if the position requires that veteran to touch code (or read and review it), then a simple question like a "find the largest number" or FizzBuzz completely appropriate. The question basically acts as a safety value at this point.

It is especially important to do this if they have not touched code in previous positions over the last 5-7 years. Otherwise, the business runs the risk of this veteran throwing their weight around on the engineering team and mucking up a production codebase two days before the release date, which could cost the company serious time and money depending on contractual obligations.

on top of that you will also filter out applicants who show some red flags when they not immediately know the answer to a problem. it's absolutely okay to not know everything. but there is a huge difference in how people communicate their lack of knowledge.

My comments here are relevant only to my hiring experience, which is decidedly un-FAANG: small companies you've never heard of, teams of 3-5 on average but always less than a dozen or so, for the entire company. But I have a lot of problems with using any programming tasks in an interview.

My biggest problem is that it doesn't have any correlation to the actual job. Coding on a white board, under stress, with multiple tech and non-tech people watching you, with a sub-30 minute time cap, with no access to the internet or debugging tools other than an interviewer who may or may not just be trying to look smart to the other people in the room, is almost entirely the opposite of what an SDE does day-to-day.

I've worked with people who were fine programmers and when I brought up FizzBuzz had no idea how to solve it. Solving programming "puzzles" is completely different than day-to-day work, especially at small non-startup shops, where you're doing line-of-business stuff and maybe a new project every 5 years. It's maintenance 99% of the time. You don't need to know how to reverse strings to implement a recursive sliding window function.

This is how we've done hiring at my current company so far and it's worked out better than any of the places I've been that used puzzles or language trivia.

1. As always, lean on your network. 1st- and 2nd-level connections will already have a lot of previous vetting completed.

2. Interview primarily for team fit. You can teach people technical details easily if they're otherwise qualified. You can't teach someone not to be an asshole, and having an asshole on the team will drive away good people who don't want to deal with it.

3. Have a very clearly communicated probationary period. We use 30 days but honestly 2-3 weeks is plenty. If things aren't working out, cut them in this period.

4. As part of #3, check in a lot more than you otherwise would during this time. We do a management one-on-one every two weeks, so we'll do daily technical one-on-ones during the first week or two of onboarding. We've let one person go during the probationary period because of performance and without these meetings it would've taken weeks longer than it did.

5. Have onboarding. Docs, calls with a defined itinerary, whatever. But don't just drop people into the thick of it if you're doing this type of interviewing.

6. Actually request references and talk to them. You'd be surprised how candid former managers will be about someone's previous performance, even when they're not supposed to be.

> You don't need to know how to reverse strings to implement a recursive sliding window function.

I guess I generally agree with the sentiment of your post, but if you have issues reversing a string (brute force) I’m not sure how you’d ever get to sliding window functions.

> I've worked with people who were fine programmers and when I brought up FizzBuzz had no idea how to solve it.

I would not categorize FizzBuzz as a puzzle. It is one of the most straight-forward ways to test for an understanding of iteration and selection. Those are fundamental building blocks that all programmers must know.

Your point about anxiety under the unusual pressure is valid. However, I personally find that to be a useful datapoint in the interview process as well. This is especially the case for a startup with time pressures or a role that may interact with customers. Otherwise, the onus is on the interviewer to set the applicant at ease.

It's interesting, because I do my very best work (and am happiest) in an environment of time-pressure, but something about the interview setting causes me to freeze up, lose my tongue, and lose my brain, all at once. If the question is very very easy, the effect is far worse. I've been on the other side of the interview process, and knowing how it might appear just makes this feel all the more traumatic. The brain focuses on the scenario of the interview, instead of the scenario of the question at hand.

I've had successfully interviews where everything flows, and I've had awful interviews where my head inexplicably seizes up. All I'm saying is that the anxiety of interview pressure has very little in common with the anxiety of time-pressure, as far as I can tell. I would take it more as a signal that a person should not be put into negotiations (because that's what an interview really is), rather than that they do not perform under time-pressure.

I'm never anxious during job interviews, or anything else really: I just take things as they come and I'm fairly stable under most pressures.

Last week I was doing a video interview, and at the end they asked me to solve a simple problem and they were going to record it. I felt an incredible pressure to do it right and fast, which lead to basically screwing it up on the first attempt on account of not actually reading the question carefully (or at all really; it was a piece of code where I had to fill in some things, and I misunderstood because I barely skimmed the comments in the perceived pressure). I then a had state of near-panic where I almost just ended the call, from which I just barely managed to recover to stumble towards a solution. It's the closes I've ever come to an anxiety attack by far, which was an entirely novel experience and very much unlike me. I did end up solving it in a reasonable amount of time, but the way I got there was ... roundabout.

The question was to square a value in-place with a pointer: not very hard at all, literally one line of code. In the moment however I was genuinely doubting if I even knew what "squared" means; I really blanked in a way I don't recall ever having done before in my life :-/ I don't know why, but being watched by someone judging you just makes a huge difference for some reason. I've actually never had to write code while someone was watching before in an interview setting (plenty of verbal questions, "take-home tests", and the like, but never any actual code writing).

I had my second interview already with the third planned, so I guess I didn't do as dramatically bad as I felt I did after the interview, but still... If it had been the wrong day I might have outright failed.

It was a very weird experience and I'm not yet sure what exactly to make of it since it was fairly recent, but I gained some new appreciation on how some people might flunk simple interview questions I didn't have before.

FizzBuzz is one of those puzzles where majority of experienced programmers won't find the solution easily as it involves the modulo operator in weird ways.

The modulo operator is rarely used in practice, unless you're writing your own hash table or some other internal where bucketizing by some ID is relevant.

Using the modulo within a for-loop though, virtually never happens.

So unless you're niche where using modulo every other day, or you're just out of school where you just learned about "+,-,*,/,%" , you have a good chance at failing fizzbuzz if you don't remember it's "that modulo 3 and modulo 5 silly puzzle"

There are better ways of testing for iterating, iterating through a real collection of elements is already much better than FizzBuzz.

I'd never considered the modulo operator to be that uncommon, but I've mostly worked in systems software and firmware. Is that really the case?

The only time I've ever used it in programming is FizzBuzz.

To prevent rehashing this, I have discovered the exact same discussion from 5 years ago.

https://news.ycombinator.com/item?id=11884645

Curious: How do you do “every other row” in a loop if you don’t do modulo?

Why would you want to do every other row in a database? That just sounds like "a random half" with extra steps if you're doing math on your DBMS's equivalent of RowID.

Things like applying a different colour or styling for visual effect is a common-ish reason, or parsing some input which looks like:

  Stuff I want
  Extra stuff belonging to the above line I want to ignore
  More stuff I want
  More ignore stuff
  [..etc..]

Which can be from a CLI tool, a web scraper tool, something copy pasted from a webpage, or something like that. This data can often be "messy" but in a regular way. I've parsed WikiText tables from Wikipedia like this (very crude, but it only needs to run once).

Another example of "% 2" is for centre aligning strings in a grid (e.g. a terminal; if it's odd you need to add one extra space to one side). I've also used it for time calculations (e.g. printing seconds as "hour:minutes:seconds").

That's from the top of my head; I've probably used it in other things as well. Note this is all high-level application work: no muckery with low-level controllers, firmware, or whatnot.

Is the % operator very common? No; but I don't think it's as "virtually never happens"-uncommon as was mentioned a few posts up the thread.

Not advocating for being oblivious about modulo op, but you could use stepping in some languages. Example, in Kotlin: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.ranges/s...

Knowing the same interview questions doesn't make you competent. That's the problem. By asking questions not related to the work you filter out people who do the work you need, and only accept those who spend time passing interviews. Same as how ACT's filter for test takers, not ability to learn nor domain knowledge.

The core problem is these interview questions are asked without knowledge as to why they're doing it. "It's industry standard" isn't a reason, but it's why binary search tree questions still exist. Some people understand that they're filter questions, but overwhelmingly interviewers think they're real problems related to the job.

I'm glad to see I'm not the first or only one to make this point, but I'll reiterate... it isn't fizz buzz. Trust me, I can write fizzbuzz. I can write loops. I can do basic tree traversal.

If I study (yet again), I can also whip out DFS, BFS, MergeSort, inorder, postorder, find all permutations of a set or string, blah blah blah. Without study, I could code up DFS and BFS with a bit of time to think. But probably not in 45 min at the whiteboard.

If I study a lot (yet again), I might be ready for the kind of questions that have been actually used to screen me out, such was "find all matching subtrees in a binary tree", in 45 minutes, at the whiteboard.

The only way I can reconcile my experience with what you claim to be screening for is that I haven't interviewed with you, and you haven't been at my interviews, and we just disagree about what is typical.

But I've been on a lot of interviews, and I do firmly believe that "fizz buzz" doesn't come within 50 miles of the difficulty level of a typical technical exam style interview. I refuse to put this kind of time into study anymore, since there is no lasting benefit to reloading 2nd year data structures and algorithms into short term "45 minute whiteboard memory", and it so rarely works out anyway. I won't do a 5 hour, room to room series of technical exams. This may cost me opportunities, but eh, my guess is that I wouldn't have gotten these jobs anyway, so I'm really just saving time.

(on a separate note, I recommend you don't start your comment with a pre-emptive dismissal of why people may downvote you. just make your point, reasonable people here will discuss it with you, don't worry about the others).

I find that the best way to expose candidates who can’t actually program is with coding questions that don’t have data structures or even loops in them. Can they write a simple Boolean expression to correctly implement a simple predicate? Too often, no, they can’t.

(Example: given two intervals [a,b] and [x,y], are they disjoint or do they overlap?)

On a team I worked on, our technical screening question was, essentially, to implement Python's `dict.get()` function. A surprising number of applicants who passed HR's screen failed at this stage.

asking candidates to reimplement stdlib methods is asinine. (unless of course your company is working on python core)

The exercise wasn't a literal reimplementation, there were some additional constraints rather than a generalized problem, but it was literally 3 or 4 lines of simple if-then statements.

And not that it mattered to the purpose of this question, but this team did frequently work with kernel, language runtime and container runtime source code.

> A surprising number of applicants who passed HR's screen failed at this stage.

Perhaps you didn't notice this part of the parent comment.

"surprising" indicates that the expectation was the candidates were supposed to be able to perform the task. Perhaps you read some sarcasm into the comment that wasn't explicit?

It wasn't a trick question or complicated in any way. It was something a first semester CS student could have done without hesitation.

I would decline to move forward in your process. I'm not here for banal, performative nonsense. Unless you're hiring entry level, an interview isn't a CS201 exam. I'm here for you to sell me on your team, culture, and technology choices. That question shows me that your company culture values performative pageantry versus discussing what I can add as a member of the team. Hard pass.

I like to work with engineers who don't write buggy code. Do you? How do you avoid hiring them?

Experienced engineers know that this is a hard problem and don't mind demonstrating basic competence. If you don't ask me to code, it's a hard pass from me -- your team has no filter.

> I like to work with engineers who don't write buggy code.

I'm not sure if this is one of the most arrogant statements about engineering I've seen, or if you've found a treasure trove of demigods who never write code with bugs. If the latter, please have them fix the world posthaste.

I like this question! Let's assume a<b, x<y, and intervals are open.

Okay: max(a,x)<min(b,y), using three comparisons.

Better: (a<x)?(b>x):(a<y), using two.

Best: (a<y)&&(b>x), using either one or two.

Those are all fine to me, and I'll follow up with a "how do you know that's right?" if needed. Looping over all valid values in one interval, testing for membership in the other, is kind of a red flag. A predicate that is incorrect and not caught by testing might be a very bad sign.

Absolutely this. HR groups now use automated tools to search resumes and filter candidates, which has led to a lot of keyword optimization of resumes. Mediocre talents with optimized resumes in up in interviews where I then screen using the most basic questions. And the questions aren't an attempt to be brutal, the questions will be around platforms and coding that they've directly mentioned in their resume. If they can't answer basic questions around things they've listed in their resume, then you know it is puffery.

I'm absolutely terrible at tech interviews, despite being a software engineer and actual architect for around 5-10 years. I constantly fix major security issues in legacy code, optimize it, and work with the senior devs in multiple languages to create new solutions. I've filled the gap as a tech lead, and frequently have to just figure out a new language in days. I naturally learn language nuances, best practices, I'm easy to work with, I know how to implement things and work across teams, technologies and departments. Learning is what I'm great at, not necessarily coding. I have extensive experience leaning towards hacker-like work in addition to software engineering. I'm legitimately, at worst, decent, with the capability to be exceptional in multiple areas. I'm generally a jack of all trades.

I go to a tech interrogation and when I ask for clarification on the question, I get an under the breath "jesus christ, I need to explain this to you?" If I don't ask to clarify, I get "Oh, well he didn't ask for more details. I guess he's rushing without thinking! He's bad at communication. Gottem! Next." I can't take a minute to read the question because the interrogator is screaming that I'm not constantly talking. If there's a literal 10 second gap in talking, I get a "Hello? Are you still there? Hello? What are you doing?" You have to memorize the leetcode questions that are always asked so you're able to talk over them. That doesn't demonstrate any skills.

When I get to actual coding, I've automatically failed an otherwise perfect whiteboarding session because I had a lowercase letter instead of an uppercase one. "Ha, gottem! He doesn't know the difference between an object and a variable!"

I'm not the best at writing code from scratch but I'm decent in a business practice. I'm exceptional at improving code from any skill level, and adopt that quality in my own code naturally. This has 0 value during an interview though. The only thing that matters during interviews is how many of the classic pattern questions you've memorized. All the amazing work I've done is invalidated because I can't instantly write a perfect meme code question.

I come on the internet to articles like this for help or to see anyone else who got stuck in my position, and there's always someone like you here. "Wrong. You're not a real engineer because you can't even answer an easy level leetcode question without stumbling on something. I guess you're not a real engineer. You're just a worthless fake person." I've worked with people like you before. I know because I heard this at my last job from dismissive coworkers either bashing interviewees or other people's code they didn't understand (or understand context around, such as a critical hotfix) in PRs.

You people submit untested code on Friday at 5 before going camping for the week and I have to come in and hotfix your sloppy work. I can pick up what you wrote, see how awful your coding practice is, but understand what you were thinking and fix it. However, just because you memorized the leetcode questions or can think of simple solutions to puzzle questions naturally, I guess you're automatically better than me and I'm basically a skilless idiot.

I try to have a conversation about fixing this or how I might be an unusual edge case and the interviewers are all on my side. I get to the interview and everything I said is dropped. I get a puzzle question in a google docs sheet that tests none of my skills. I understand you need to test if people can code, but all these dismissive gatekeeping methods are slamming me and letting people who just happen to either memorize the questions or they live and breath programming and can weasel through it. Those people, I've noticed, are frequently poorly trained in coding and refuse to change their ways.

I've taken to simply waste interviewer's time at this point. I'll schedule an interview, find out it's a leetcode one, and still plan to attend. With everything remote now, I can just completely check out. Watch a video on another screen while just completely wasting the person on the other end's time.

Even better if I can somehow get to a "virtual onsite" where I likely get to waste 4+ people's time.

If there was a viable solution to pushing for real change in the industry, I'd do that. But there really isn't.

FWIW nowhere I've interviewed at has been that silly w/ questions. Generally they're very personable.

Except FAANG/fintech companies. So I guess you just have to put up with it if you wish to be maximizing income.

Everyone's already saying it, but let's be honest. In 2021, fizzbuzz is not what is being tested. We are 15 years past that now.

> The industry is awash with candidates with ok-seeming resumes, that get through HR screening, but then fail miserably at the tech interview to solve something like fizzbuzz.

> My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team, whatever you are doing!

Your comment shows that this topic has a false assumption.

There is not one type of hiring process. Not even when we talk about algorithm/data structure style coding interviews.

How do I know? Because if you don't know how to do a topological sort and similar algorithms on that level, you stand no chance at FAANG interviews.

I remember the time where I found fizzbuzz doable but difficult. I could do it, I was simply slow at it. When I prepped myself for a FAANG interview, I did fizzbuzz at the end of it for fun since I hadn't done it in years.

The result: fizzbuzz was done very very quickly and I'd classify it as a Leetcode easy.

The thing is, Leetcode hard is a different beast [1]. Therefore, I'd argue it's also a different hiring process.

[1] Here is how I look at the Leetcode difficulty levels (the TL;DR version).

Leetcode easy: can you write a for loop? Do you know what a function is? What about if-statements and variables?

Leetcode medium: can you reasonably think about data structures and write it out in code?

Leetcode hard: do you see the ingenious trick (or tricks) being employed? Do you have advanced knowledge of data structures? If so, congratulations! The hard part is over. You just need to code it out. Example: you need to know this type of stuff: https://www.youtube.com/watch?v=cIBFEhD77b4 <-- It's a good YT channel by the way. After his video series/lectures on graphs, I was able to solve 50% Leetcode hard on graph problems :)

If you're incapable of finding out who "gets it" without asking about fizzbuzz (which I'll point blank refuse to answer) or recursion/sorting, you're failing at interviewing.

By the way feel free to try to write a sorting algo (preferably not bubblesort) by memory in your favourite language. It will be a good reality check.

> My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team

Yes, you don't. But you don't need to ask them that directly, or have them code live.

So what do you suggest instead?

I got a working merge sort. I think this question is harder than the "can you code" type questions that I'm used to asking when interviewing at companies, but easier than the questions I get at companies (e.g. write me a thread-safe hash map)

>> My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team > Yes, you don't. But you don't need to ask them that directly, or have them code live.

How will you know if you don't ask them a question that asks them to solve a small-scale problem that can be solved via a for loop? In our process it takes like 10 minutes. Granted we don't ask fizz buzz, but also we don't ask for implementations of textbook algorithm. Just a simple programming problem or two.

The way I see it is, the most condescending interview for a programmer is the one that contains no coding at all. And if you refuse to implement FizzBuzz, well, that is okay, but I will not recommend you for being hired.

> to solve a small-scale problem that can be solved via a for loop?

Why do you need to ask them specifically to code fizzbuzz? There's nothing magical about it and it's a condescending coding exercise.

Ask stuff about their everyday coding and their favourite language. What's the difference between an Array and a Set (in your language of choice). How do you add an element to those? (if it's your day to day language you should remember, right?)

Tell me about an issue you had to debug. Tell me how (something) works in general. Something basic, no need to go into much detail, but just to see if they get the basic idea and have used it.

Again, who cares about fizzbuzz when you can ask them about http headers, network delays, etc (it will be more job relevant as well). People who can't code fizzbuzz will usually fall flat on those questions as well.

Fizz buzz is a low-pass filter. Who cares?

Someone who wants to know if you can code at all, or if you’ve just learned to talk the talk. Those people exist.

You mean high-pass filter right? Lowpass filter means you're filtering our the higher freqs. In this type of discussion, you're trying to get rid of the people who learned to talk the talk, meaning the lower end of fakers and trying to keep everyone above that level. High pass filter.

Hope this isnt too pedantic but as "noise" is commonly perceived as higher freq (ignoring aliasing) I think low-pass is meant to imply removing the "noise" in your pipeline. Your interpretation makes sense if freq == quality, but statistically a high pass output has higher variance, so sounds like the opposite of the intended effect

I mean cutting out everyone below the level.

So you are correct in your pedantry, I did indeed mean high-pass :) Good job I'm not a signal-processing engineer! Or pretending to be...

Fizz-Buzz (or equivalent tasks) are just a quick way to tell whether the minimal basics are met. I don't ask Fizz Buzz but give problems that are only slightly more complex.

I'd consider it to be a "handshake". If the basics don't work you don't need to waste both sides time.

> People who can't code fizzbuzz will usually fall flat on those questions as well

yes, but it is harder to tell whether they were completely incapable (what FizzBuzz will tell you) or whether they just didn't touch certain topics in their career. I'll gladly hire a capable engineer who was active in a different domain who I am certain will be able to grasp the necessary knowledge quickly.

> The way I see it is, the most condescending interview for a programmer is the one that contains no coding at all.

Why is that?

The last two interviews I had involved no coding. Both led to an offer.

In one of them, I demoed a personal project and showed bits of its code. I think it would've been quite condescending of them to have me do a fizzbuzz after I've shown them 10k lines of working code.

The other company didn't even care to see my code even though I brought my laptop.. they just took it for granted that I can code.

> In one of them, I demoed a personal project and showed bits of its code. I think it would've been quite condescending of them to have me do a fizzbuzz after I've shown them 10k lines of working code and its credibly your own code. Most candidates I see have some repos on their GitHub which are implementations of coursera coursework.

I guess its a reasonable substitute, IFF the candidate has such a project to show.

> The other company didn't even care to see my code even though I brought my laptop.. they just took it for granted that I can code.

With such a company I would have doubts that I might start in a team with people who cannot code or code fairly badly. I expect, in an interview as an applicant, to see that the position that I start in has a certain appreciation of engineering work. If the prospective employer can convince me that they are caring about their staff's skill levels and code quality, etc without a code-interview, I guess its ok. But most companies that have no coding part in their interview process just don't assess the skill-level.

> > The other company didn't even care to see my code even though I brought my laptop.. they just took it for granted that I can code.

> With such a company I would have doubts that I might start in a team with people who cannot code or code fairly badly.

FWIW that was a military contractor hiring for a fighter jet project. Expensive machinery and lives at stake. They must have a bar for quality, and they can't leave it to the skill of an individual contributor.

> > My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team

> Yes, you don't. But you don't need to ask them that directly, or have them code live.

I am not being flippant, but why not? Asking seems to be the simplest way to know.

Also, you're making a strong assumption regarding the type of tech questions that OP is asking. You go from fizzbuzz (probably described by the interviewer, not just "do a fizzbuzz") to a sorting algorithm from memory. That's clearly not the same.

My personal experience interviewing candidates is:

At the end of our first interview (discussing their work, projects, experience, what they are looking for in the next 1-2-3 years etc.) I ask a very simple coding question that should take 1 min to solve if they were by themselves, with no complex algorithm and requiring no prior knowledge beside the language they are using. Typically, a fizzbuzz.

To solve that 1 min question, they have 10-15min where they can ask for guidance, help, etc. The goal is just to exclude people who just can't code. And surprisingly at least half of the candidates fail this.

Now maybe this is because our recruiters are not good enough, but this 10 min coding is super useful to prevent wasting more time on a candidate that is not a fit for us.

Why not ask directly? Surely that’s the best way to get an answer to that question?

You'd refuse to answer fizzbuzz?

Why? Some people are very good at talking the talk and yet cannot write basic code. Fizzbuzz is a 2 minute exercise for most engineers I've interviewed (except those who fail it, which does happen) and is generally low stress for the candidate. It's not a trick question or require any mental acrobatics. Do you think you're above it somehow? Why?

I would and I actually did refuse to answer already. I'd say that I know it and to ask me something more relevant.

In the same way I'd refuse if they'd begin asking me "how much is 10 divided by 2" or something.

"Oh but you can answer it in 2 min". Don't devalue your time. I bet they can ask something more relevant. I'm happy to solve a different coding exercise or test.

Hmm, if someone says “I already know that” that’s cool, I can just ask them “How do you do it then?” and if the next sentence is anywhere close to “something something modulo” we can skip the coding part.

This behavior would be a strong tell to me that you haven’t had to work on teams with net-negative contributors, or worried about how to avoid hiring them.

Experienced developers know this is a serious problem.

Reply on news.ycombinator.com