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 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.

That's also something I keep hearing in anecdotes.

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.

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 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."

What would be the purpose of this “scam”?

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.

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.

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.

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

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

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

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 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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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).

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.

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

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.

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

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…

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.

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)

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

That’s secretly the most powerful design strategy.

Altough, for usability it is IMO definitely the best.

Nowadays it's called a dict.

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

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

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.

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...

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.

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

The whole situation is quite pathetic.

Sorry it's a boring answer :-)

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.

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...

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.

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

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.

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.

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.

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.

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.

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.

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.

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).

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

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...

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".

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.

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

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.

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.

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.

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.

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?".

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".

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.

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.

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"?

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.

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.

- 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

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.

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

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'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.

" 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.

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

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.

  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?
  ...

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...

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.

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.

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).

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.

  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

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

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

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?

  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

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.

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.

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 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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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).

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

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.

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

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.

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'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 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.

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.

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

> 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 :)

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.

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.

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.

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.

> 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.

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.

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.

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

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...

> 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? 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?

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.

Experienced developers know this is a serious problem.