What's Wrong with Tech Hiring | Hacker News Reader

What's Wrong with Tech Hiring

neverworkintheory.org

159 pointsluu385 comments

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

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.

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.

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

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.

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

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

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

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

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.

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

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.

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.

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

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.

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.

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

One big issue with tech hiring is that the vast majority of the interview pool consists of terrible candidates. Good candidates get callbacks for (almost) every job they apply for, choose to interview at a few select companies, and get offers from most of the places they interview at. Thus, they’re only briefly in the interview pool. On the other hand, terrible candidates are constantly getting rejected at every step of the process, and must continually re-insert themselves into the interview pool, and thus comprise the vast majority of interviewees.

Because of this, the interview process is not designed to efficiently handle the minority of qualified candidates, but rather efficiently weed out the majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it.

(Note that the majority of the interview pool being terrible does not mean the majority of programmers are terrible. Assume 80% of developers are great, and 20% are bad. If the great 80% of developers only need to interview at one company to get an offer, while the bad 20% need to interview at 10 companies before either getting an offer or giving up, then only 0.8/(0.2*10+0.8)=28% of actual interviews will be with qualified candidates.)

Interesting, my experience is the opposite. I find various leetcode and "software architecture" questions extremely hit-or-miss, and my experience interviewing is, either I fail at the very beginning stages (CV review or first 2 interviews), or get to the end (offer stage). The very bimodal distribution is inconsistent with both options in your hypothesis (i.e. either the "terrible" or the "good" candidate).

>The very bimodal distribution is inconsistent with both options in your hypothesis (i.e. either the "terrible" or the "good" candidate).

it is completely consistent. When you fail at the very beginning you're a "terrible" and when you get offer you're a "good" one. The "terrible"/"good" isn't innate characteristic, it is in the eyes of beholder ... err ... interviewer. Most places pride themselves on taking only top 1|2%, and thus most candidates at any given place are "terrible" by definition, and thus the interview is built as the filter described by GP. Of course everybody hiring top 1% means that pretty much anybody would get to be a "good" at some place.

> either I fail at the very beginning stages (CV review or first 2 interviews), or get to the end (offer stage).

I can echo this, same experience here and ended up landing a nice role at a big company while being rejected for objectively worse roles at tiny companies and startups. For the last round of applications, I applied to 10-15 companies, only got an interview with 2 and got an offer from both (and both raised their offers to counter the other).

Many engineers who I know as friends/excoworkers who are in top companies (including but not limited to FAANG) barely eeked by into their job, usually with a large string of failed interviews behind them. All of them consider themselves extremely lucky that they landed a job at a great company and believe that if they had to re-interview for the same position, odds are much more likely they'd utterly fail it.

Yet they are currently working at highly respected top tech companies and are accorded a certain "elite" status by many of their peers at less prestigious/selective companies.

My best friend is at Netflix and constantly dreads ever having to interview for another job again because he's dead certain he will bomb the leetcode rounds because he hasn't looked at an leetcode problem in five years. Even his current job at Netflix he considers having obtained through sheer luck, and he says none of his experience working at Netflix is of any help in solving leetcode problems.

I quite often hear stories on here, Blind, Reddit, etc. of people who manage to land multiple simultaneous offers from FAANGMULA+ but have yet to meet such a person.

> because he hasn't looked at an leetcode problem in five years

Am I the only one who feels like he could spend a week preparing and shred through any sort of reasonable algorithmic problem testing anybody would throw at me?

When is the last time you touched algos before?

Of course not, but why would anyone assume that me, married, with children and a full time job has any inclination whatsoever to spend a whole week going over a bunch of stuff I’ll most likely never use again.

First of all, I want to spend my limited free time doing other (fun) things, but more importantly, it insults my pride.

You never know what they’ll ask, so full prep is impossible.

The bar is probably higher than five years ago too? A few friends at Google who got in 10+ years ago tell me that there is no way in hell they could pass the typical interviews being conducted there today.

I also think he could prepare himself for such interviews. But, one week? Well, that depends:

- is it one week as in 7 days off, and spending at least 8h/day? Then I would say, it may be enough. It just takes one problem you haven't seen before (you haven't prepared for) and you are out.

- is it one week as in 5 days, and 2h/day (let's say, after dinner?). Then I don't think 1 week is enough. Around a month would be needed to match the previous scenario

> All of them consider themselves extremely lucky that they landed a job at a great company and believe that if they had to re-interview for the same position, odds are much more likely they'd utterly fail it.

Hmmm... this makes me wonder if these kinds of interview strategies aren't promoted at such companies precisely because they make candidates feel more grateful and therefore less likely to leave, less likely to refuse overtime work, less likely to protest anything, etc.

Yes, and it increases the cost to explore other companies.

I'm in this camp, and to top it off, I interview folks. It really is unfair to expect someone to be able to do something I myself probably wouldn't be able to do right now off the cuff.

> I quite often hear stories on here, Blind, Reddit, etc. of people who manage to land multiple simultaneous offers from FAANGMULA+ but have yet to meet such a person.

It doesn’t seem so surprising? They all require you to do and say the same thing, so by the time you can do those things well enough for one, you can do them well enough for all of them (in this case regurgitating leetcode while seeming marginally likable).

The only surprising thing is to land an offer at around the same time at multiple companies, especially the ones with very long interview cycle.

I’d bet money that this is imposter syndrome at work, and that with a couple days of refreshing they’d pass interviews no problem.

There is always variability, and I think good interviewers actually help candidates a decent amount.. so if you get a bad interviewer they’d fail but that’s not on them. I’d bet they’d pass most interviews.

Doesn't impostor syndrome imply mistakenly feeling that they are not qualified to do their work? I think this is different because said people seem to be great engineers and confident at their actual job. What they are not confident is in their ability to be Professional Interviewers/Master Leetcoders, which is a skillset almost completely divorced from their actual work.

I just landed a new job at a FAANG-level company two months ago. Not surprisingly, my actual work has no commonality with my Professional Leetcoder skills. I haven't looked at a leetcode problems since I got the offer and I fear my skills have already atrophied.

I expect we'd see this absolute disaster of an interview "process" fixed overnight if every company required their employees to re-interview for their position yearly (through some blind process so the interviewer isn't aware they're interviewing someone who already works there - yes I'm aware this won't work for small companies... it's not going to happen to begin with so let's just pretend :P).

Every company would immediately start a "task force" to fix their interview process once they reject (and then fire) 90% of their staff after the first re-interview.

Yes. The market is tight, and mostly full of un-hireables.

"Good candidates." I guess everyone who gets stuck in interview hell is an idiot based on your comment? Why would someone who's not trash get stuck? They wouldn't, I guess! Must be trash engineers just out there wasting everybody's time!

I am awful at tech interviews. I mess up leetcode and puzzle questions even aimed for new hires. I get stuck on the wording in the question where the interviewer takes it personally if I don't understand. Sometimes I get my languages mixed up in google docs with no syntax assistance and for example could declare a new java String as a var string javascript style because I got distracted while talking to the interviewer.

I have 5-10 years working as a software engineer / architect. I am frequently put on critical projects, including running 10's of thousands of critical government servers. When tech leads quit, I fill in the gap. In an actual business setting, I'm great at picking up new languages. I frequently code review the work from our top engineers and always find spots for big optimization or critical flaws, such as security issues. I'm not nitpicking for little changes-- These are real considerations.

I've done front end work, back end work, created template code for other engineers, worked with the senior sql developers, senior security staff, the original legacy coders, and the senior devops on scripts. I get put on projects where I'm the only one, and been on teams of up to 20 people. I also monitored splunk and had every error sorted out: New errors I could identify the exact code spot and the original PR in minutes to fix problems. I did this on the side to monitor my work and was asked to speak to the entire engineer team on multiple occasions to get others up to speed.

I'm naturally "good" at a lot of things. I hate any degree of bragging like this. I'm so tired of seeing engineers brag about themselves-- It sounds like they're dismissing everybody else's skills. But this comment is just to just show I'm not someone who comes in and can't figure out an easy story and who refuses to try to ask for help or learn on their own and they just give up work as soon as possible. I legitimately try and put a lot of effort in to my work, and I figure it out. But none of this matters in the current process.

You don't have to say how great of an engineer you are to say that you think coding interviews are terrible.

And the person you're responding to also agrees they are terrible for qualified candidates.

I think most of what is wrong with technical hiring is bias and expectations:

- There is always an age bias. Younger==cheaper in every single HR department in the world, but tech experience (and output) often increments faster than age.

- Someone who’s spent a couple of years not coding because they decided to try management or consulting will get passed over because interviewers don’t really expect them to want to code anymore. Never mind if they actually consulted for and designed systems that are currently running in the Fortune 500.

- Timezones and “meeting quorums” are very tightly aligned in some hiring manager’s minds. If someone can’t make half the meetings because they’re offset four hours, managers get antsy.

- US/non-US is still a massive chasm. The first question I got from every FAANG interviewer was “when do you think you can relocate?”. And the pay differential is atrocious.

Remote helps a bit, but the age bias will get to us all.

> And the pay differential is atrocious.

I'm quite simple with this. I simply work less and lie about it. Unless I feel passionate, but then I don't view it as work. With that said, I do tell them upfront that I kind of work this way (I always say in interviews: pay me fairly and I'll treat you fairly, here's what I consider to be a fair wage. If they then lowball me and I accept because I happen to need the money, mayhem ensues. So far, 25% of the companies have met my salary requirements easily, all non-FAANG and local). Remote work helps with getting away with this.

You get what you pay for one way or another. If I happen to get fired, so be it. I might want to consider switching careers then.

> pay me fairly and I'll treat you fairly

This might work for you, but I wouldn't hire someone who said that. It translates to "I'll only be honest if you are honest." I like to think that peoples' honor is not contingent on their estimation of the honor of their colleagues.

My dad told me that the difference between men and animals is men have honor. We each get to choose which we are.

is this just not game theory in practice? If your opposition is not honest, by being honest yourself youre setting yourself up to be exploited, misled or abused in the long run.

As an aside, humans are animals, just smarter ones

> by being honest yourself youre setting yourself up to be exploited, misled or abused in the long run.

You might be surprised. Dishonest people miss out on a lot of opportunities, and they have no idea this is happening. When honorable people pick up cues (like your I'll be fair if you're fair) that a person is dishonest, they'll smile and nod and quietly put you on their "do not trust" list.

People on that list don't get offers that require trust, and those are the good offers.

Aside from that, being an honorable person is its own reward. Being honorable is what you do when nobody is looking.

Accepting a lowball offer, yet in your mind already deciding to renege on it, is dishonorable.

> As an aside, humans are animals, just smarter ones

Everyone gets to choose whether they are a man or an animal.

P.S. I have my failings. But I'm not going to pretend they are virtues.

P.P.S. You're not setting yourself up to be abused by being honorable. There's nothing dishonorable about not trusting people who haven't earned trust, or who have shown they aren't worthy of trust. For example, I wouldn't hire someone who told me their honor is contingent upon other people.

Dishonest people only miss out on opportunities when theyre identified as being dishonest. That's besides the point though, OP was talking about employing this approach only when the opposition is being dishonest. He may lead a completely honest life in the rest of his pursuits. I think thats a savvy way to live

I've had many people take advantage of my initial trust in their honor. It's been expensive.

But when they return my trust, it's been very good. For me, the benefits far outweigh the disadvantages. My dad lived it, and he never ever broke a promise to me, or to anyone else I know of. It's the way I want to be. It's the way my friends are, too.

> Accepting a lowball offer, yet in your mind already deciding to renege on it, is dishonorable.

Note: they also know that I won't be working at my best. And if they'd reason through what I would say, then they'd understand what that entails.

I need to pay my bills, so if that's the best I can get then I'll have to take it. I've had this situation happening after applying to jobs for 18 months (as a fresh CS grad).

> Everyone gets to choose whether they are a man or an animal.

We've always been animals, we're not different enough to warrant a different classification. Chimpanzees can reason as well, so can Octopuses, crows and dolphins. They have abilities that we don't have and vice versa. There are many animals that have risen above simple instincts. There are enough experiments to show that old world monkeys have ethics and morality just like we do (including obvious altruistic behavior).

Also, I feel that the comparison is futile. Focus on developing yourself. Who cares if you think you're better than a macaque. Are you better than who you were 2 years ago? Do you feel your life is better? Are you happier because you invest in yourself and your community. IMO those are the things that matter. Comparing ourselves to animals and then implicitly claim that they have fucked up ethics (since they have no honor) is un-nuanced at best.

You have a brain that is capable of transcending your base animal instincts. I know I struggle with my base animal instincts and try to be a better man.

> I need to pay my bills, so if that's the best I can get then I'll have to take it.

Nothing wrong with that. But then reneging on the agreement is dishonorable. You're not starving.

> Comparing ourselves to animals and then implicitly claim that they have fucked up ethics (since they have no honor) is un-nuanced at best.

I don't fault animals for not having ethics, because they are incapable of having ethics. I don't fault children for not having behaviors that are beyond their abilities. I fault men who behave like animals, because men are capable of better.

BTW, people who work with monkeys have found, through bitter experience, that you cannot trust them. Statisticians have also determined that some apparently "altruistic" behavior in animals are statistically selfish, as in propagating their genes.

This is fine as general life advice, but in a business context I've never seen this lead to anything other than exploitation of the more honourable party. I get where it's coming from and I try to do the same myself, but there's a fine line between being honourable and being self-destructive in the face of other options (strategies, if we want to keep to game theory terminology).

I didn't say you shouldn't protect yourself. For example, have written contracts. Put fraud protections in your accounting system. Half down, half on delivery. When I do a royalty deal, I include a right to have their books audited. I was cheated by a large company once (you'd recognize the name), and I sued and won.

But when you make a deal, deliver what you agreed on. When people like doing business with you, the word will get out that you are a good person to do business with, and you'll prosper.

For example, the guy who taught the accounting class I took used to be a used car salesman. I asked him how to tell if the car dealer was honorable or not. He said the ones in business more than 5 years were honorable, as they were getting repeat business. It takes five years to run out of suckers.

When I need some work done on my house, I'll ask the local real estate agent. They usually have a stable of contractors who'll get a house ready for sale, and they aren't using contractors that cheat their customers. When I ring them up, I make a point that Agent Bob recommended them to me, and so they know if they cheat me, I'll tell Agent Bob who isn't going to want his own reputation besmirched, and the cheating contractor will get cut off.

Aka Trust but verify.

> It translates to "I'll only be honest if you are honest."

Stating upfront that if I feel underpaid is a very very bad thing for me and the company, because it undermines my motivation (yep, that's how I say it, I also give numbers and explanations behind those numbers) is an honest upfront thing to say if you ask me.

When people push through, then they push through because they don't seem to care about that. All they focus on is that they can get developers for (too) cheap. I just warned them. I'm not warning them again. Note: obviously this only happens if I need the job/money and I'm in a tough spot. Otherwise, I'd walk away.

FWIW: I don't know much about honor, ("eer" in Dutch, who uses that word even? I almost never hear people talk about "eer"). To me honor seems like pride and I've seen people defend very stupid things because of pride. I'd rather defend something because it helps humanity with the contingency that I can at least be moderately happy myself.

Because of this what I do care about is truth. For it is truth that will lift us (slowly) out of whatever miserable stuff we endure, and I can get behind that. Unfortunately, other people don't seem to care about it as much as I do and I have been burned in the past.

Edit:

FWIW I welcome this discussion as I feel people tend to think differently about these things based on all kinds of factors. I think these different views are interesting since it allows me to ask questions that are relevant to my personal life but I'd otherwise not think about.

This person is an absolute chad

I think Dutch people are more likely to talk about ‘eerlijk’ in the context of honor when discussing something like this.

“It’s not honorable.” could translate to “Het is niet eerlijk.”

E.g. het is niet eerlijk om je werkgever te vertellen dat je 8 uur werkt maar maar 4 uur te werken.

Of course, I think the original relation with the word ‘eer’ has been lost and it’s mostly it’s own thing now.

I see your point but isn't "eerlijk" simply "honesty"? I do get that there's a reputation when it comes to honesty and that it can be tarnished. But I don't think it maps 1 to 1 to honor.

I thought that honor could also be about that if one gets insulted that the insulted person would start a fight because his honor was insulted (apparently this happens in the south of the US a lot, according to psychological experiments [1]). I remember when this happened to me. Someone in SF said "fuck you" at point blank range with no reason. I simply ignored him, I didn't get all up in his face. But apparently, people from the south do that to defend their honor.

[1] https://www.simine.com/240/readings/Cohen_et_al_(2).pdf -- Insult, Aggression, and the Southern Culture of Honor: An "Experimental Ethnography"

> I see your point but isn't "eerlijk" simply "honesty"?

I mean, in current usage, probably yes. In English the words do not seem related, but in Dutch it seems that lying is/was considered dishonorable. Dutch people certainly seem straightforward compared to other people I’ve met.

I guess different nationalities consider different things as affecting their honor.

> I don't know much about honor

A basic view of it is: a man keeps his promises.

What do you think of people who don't keep their promises to you? Do you congratulate them on their successful use of game theory?

If you saw a wallet with cash in it and an ID card lying on a park bench with no one else around, what do you do? Would you behave differently if it was $5, $100, $10000? Are you a man or an animal?

A few months back, there was an article in the newspaper about someone who found a very large sum of cash, in the 5 figures. He figured out who owned the money, and gave it to the owner. Then he became infuriated because the owner didn't give him a "reward" for being honest.

That's not how honor works.

> I wouldn't hire someone who said that. It translates to "I'll only be honest if you are honest."

So you concede you are NOT going to be honest, then, but are expecting 100% honesty back because of the notion of honor, which is what exploitative, scummy people usually do. You also invoke honor to make the other guy not question your honesty.

No.

A job is a bargain we strike in good faith. I will stick to my end of the bargain to the exact extent of you sticking to yours. This is how people who actually have honor do business.

> So you concede you are NOT going to be honest

There's nothing dishonest about not hiring someone who says they're not going to keep their word.

> I will stick to my end of the bargain to the exact extent of you sticking to yours. This is how people who actually have honor do business.

No, it isn't. Contingent honor is not honor.

For example, people who steal items from work, and justify it to themselves because they believe they aren't paid enough, or the boss disrespected them, or whatever, are thieves.

For what it's worth: the following thoughts aren't amazingly well thought out, but for the sake of discussion. This is what I think.

I find it interesting to read about your perspective, I haven't seen such a strong one in a while. And it forces me to think about interesting things.

> are thieves

Being a thief is not always as bad as you're implying here. First and foremost, there are many cases where I'd see your point and agree.

But IMO it isn't that simple. While on vacation, I've met many people in Cuba that couldn't make ends meet and would starve for a week. They'd also be thieves if they'd still food. But if a government treats you that poorly, I see it as a necessity.

American soldiers that killed German soldiers between 1940 to 1945 were also murderers in the eyes of Germany. And while I am not happy that anyone got killed during that war. I am happy with the consequence it brought (my great grandparents their freedom).

Now let's go to a more nuanced point. Many people in The Netherlands could barely make ends meet, because they could barely pay rent + bills and not save a penny. Then corona hit. They got utterly fucked. The people that you'd describe as a thief didn't get as much fucked (not that I know any thief so I'm using my imagination here).

When a system fails you, move away. When you can't, mayhem ensues. When enough mayhem ensues by too many people then it might go down as a revolution in the history books and be the de facto winning story on how things should always have been.

Or people are simply criminals, rounded up, shamed and put in jail. In nuanced cases they also get therapy.

When it comes to these things I see 2 sides of a story that are in direct opposition with each other. IMO, you have a very strong opinion that one side of that story is true and the other should burn in hell. I disagree with that as the perspective is necessary to understand all sorts of things.

That is not the situation in the US. Stealing from your employer is not that situation. If you don't like the work arrangement, quit and get another job.

Wars brutalize people, and WW2 was a very, very brutal war. I have never been in combat, and so am not going to be too judgmental of people who were.

BTW, my father served in combat in WW2 an Korea. I asked him once if he felt bad about shooting at Me109s. He said no, because they were doing their damnedest to kill him. But also, the men he served with went out of their way to trust him with their lives. That's quite an honor.

Pretty random conflation between both things, I'm not seeing the connection.

And then you made it even worse by somehow implying whoever doesn't abide by your weird moral compass might be an animal.

I'm sure you well understand what I mean.

Not sure what makes you say that but no, I really don't. My comment was genuine and not sarcastic.

> I like to think that peoples' honor is not contingent on their estimation of the honor of their colleagues.

You might want to rethink that assumption, because overwhelming evidence suggests that people's honour is contingent of their estimation of the honour of their peers. See the Golden Balls TV show, where the two remaining participants at the end are asked to "split or steal". Turned out people are more likely to steal if they think the other will steal as well. Also, people don't like to get swindled. If they expect swindling, its' only natural that they resist it however they can.

Don't get me wrong, we need honour, if only so we can share this Earth together. There are other ways to fight dishonour than to be dishonourable yourself, and there are advantages to honour (such as the reputation of being honourable). It's just that evidence is not as rainbows and unicorns as we'd like.

> overwhelming evidence suggests that people's honour is contingent of their estimation of the honour of their peers.

I don't doubt that. I hear people brag all the time about doing that. But I don't respect such behavior, and never trust people like that.

Do you?

You had me worried for a moment with "I like to believe". I considered suggesting the litany of Tarsky, where you basically want to believe whatever is true, and not get too attached to beliefs you may not want. I now see it was just a figure of speech.

Now, would I trust people who would behave dishonourably around people they deem dishonourable? Well, probably less. I’d fear they might flag me as dishonourable, and one sidedly turn what could have been a tit-for-tat into an eye-for-an-eye. I’d be cautious for sure, but I’d most likely still give them the benefit of the doubt until they give me concrete cause to write them off.

Whether that’s a good strategy is another question, though. (For instance, Littlefinger did tell Ned Stark not to trust him, and Ned, being the bloody paragon that he is, trusted the sleazy bastard anyway, and lost is head for it.)

Be careful about getting life lessons from movie scripts :-/

But people do often unwittingly telegraph that they are untrustworthy. One of the obvious tells starts with "You can trust me!" In isolation, it doesn't mean the person is untrustworthy, but it is a warning beep.

I think there's more to it than just that:

Being around good people can inspire you to try to become better yourself.

Being around good people can give you the nudge you need to behave better when that's difficult.

Lastly, as much as I admire the ideally, I simply don't believe in turning the cheek at all times. It exposes other people to risk, not just yourself. (Perhaps that's not what you're arguing for though.)

(I think I understand the general point you're making, and agree with you partially.)

Turning the other cheek is something different altogether.

I like you.

I sincerely don't understand the idea of people working more than what they are paid for. If my capabilities are worth 10k/month and you only pay me 5k/month (state of the economy, CoL adjustment, being a scrappy startup, whatever the reason), you will get half of my capabilities and I will spend the other 4 hours doing/thinking about something else or just online browsing HN.

Not trying to be snarky, but people that know that are underpaid and still give the companies 'their best', what is the rationale?

> Never mind if they actually designed systems that are currently running in the Fortune 500.

I see this kind of thinking often and it has certainly influenced my hiring decisions and my own career but there is a flaw.

There is a difference between someone who designed a system _at_ a F500 and someone who designed a system that got them _to be_ a F500. In a big company, there's lots of room to hide and bullshit.

Not saying that developers from those companies are bad, but they're not necessarily good either.

>There is a difference between someone who designed a system _at_ a F500 and someone who designed a system that got them _to be_ a F500

how many people have designed systems that made their company into a F500 and how many of them do you think go through this process we're discussing?

Not that many which is the point. It's weird to me that people see a successful company and then ascribe some of that merit to the potential candidate sitting front of them, ignoring the fact that they were one of thousands. I don't see working at a F500 as an accurate predictor of success.

I meant as a consultant. Will edit to reflect that if still possible.

> Not saying that developers from those companies are bad, but they're not necessarily good either.

The developers at those companies are just... normal developers.

I've never understood why techie interviews aren't simply replaced with the sort of discussions programmer co-workers have amongst themselves daily.

I've taken to honing on a candidates CV that might say for example, experience with Vue and React and simply ask them to compare the two, what do you like about one over the other etc. Or have a look at the projects they've worked on and ask them how they solved problem X and why that particular approach rather than Y etc.

Being this casual I feel that you get a really good feel for how someone works, how they think, how they approach problems and most importantly how well you might get along with them day to day as you work together. They end up being much more relaxed and honest.

I have a hard time believing that someone incompetent can slip through the cracks this way. Hasn't happened yet.

Studying for 100+ hours and doing 3 full-day interviews in groups and one-on-ones must be a Silicon Valley thing. Which is understandable given how many potentials would do the pilgrimage each year to join a pre-IPO. It's the 2021 version of the gold rush.

Compare that to Melbourne (Australia). Every interview has been how you've described. I've had interviews in cafes, restaurants, pubs, and food courts. All informal chats, and only remember one white-board interview that went for about 3 hours.

Thinking about this more now as I type this reply, clearly, the interview over lunch doesn't scale so making candidates run gauntlets for Valley jobs actually sounds logical.

> I've never understood why techie interviews aren't simply replaced with the sort of discussions programmer co-workers have amongst themselves daily.

Because of an attempt to standardize the questions so as to rank candidates based on their answers? Notice how many times the word bias pops up in articles complaining about the interview process? Bias this and bias that? Well, having a freeform chat with a candidate is just inviting bias.

> I've taken to honing on a candidates CV that might say for example, experience with Vue and React and simply ask them to compare the two, what do you like about one over the other etc. Or have a look at the projects they've worked on and ask them how they solved problem X and why that particular approach rather than Y etc.

The most lazy programmer I ever seen, to the point where he rarely finished anything and where everything took absurd amount of time excelled in these. There is sort of person who is smart, reads blogs/hacker news/journals a lot, have all the right opinions and can theorize about this or that solution easily.

Everyone, especially developers, who was not on his team thought how genius he was. (Imo, largely because he is also completely immersed in tech-culture projecting all the correct work not related social signs of genius developer. )

> I've never understood why techie interviews aren't simply replaced with the sort of discussions programmer co-workers have amongst themselves daily.

I think the answer here is simple: scale and trust. The smaller the company, the more likely you are to get this sort of "just a chat" interview. But larger companies invariably feel the need to standardize their hiring process across huge numbers of people. And it's just very hard to trust the "just a chat" format at that scale, and can seem much "better" to build a bank of questions with answer keys.

The solution: work for smaller companies!

I recently interviewed at some place which did exactly this. Their first round of interview was a 30 min (or 1 hour) candid talk with the hiring manager which involved around technology (and the role). Although I was deemed not fit for candidacy in further rounds, that first round help me express myself more rather than how would you do X in Technology Y and so on.

Because this is highly subjective, prone to bias, and isn’t a repeatable process when companies interview hundreds or thousands of people every few months.

I'm a freelancer based in Germany, been a freelancer for a long time (20+ years). Worked on a LOT of different projects in several (European) countries, as developer/architect/tech lead - whatever the client need was.

Since my relocation to Germany, I decided to try the "no-tech-interview approach": does a client wants to work with me? Let's talk, for hours if needed, let's meet in person, whatever is required to make both parties confortable with each other.

I'm more than happy to answer questions about my previous projects, how did I work on a specific solution or technology, which mistakes I made.

But no technical interviews (as in whiteboard coding, riddles, take-home assignements). I have 25 years experience, I have references, I have code on github in several programming languages, I wrote a technical book.

This approach has been working so far. Some clients still insist on doing a coding challenge or a classical technical interview: I politely decline and move on. There is no shortage of contracts, so I have always some lead in the pipeline. I would say that 50% of the leads are from me being recommended by people I worked in the past: this is obviously the value added of having lots of contracts under the belt. If I feel that my experience would not be a good fit for the project, and there is not enough time for a ramp-up, I would also decline.

I do realize that this no-tech-interview approach would probably never work for permanent positions, especially when it comes to hire junior developers. Having said that, I strongly believe that the most valuable asset for a team is a decent person.

Very few teams work on hard-problems, requiring super-specialized knowlege (say, AI for self-driving vehicles). The majority of technical skills can be learned, if one has the passion, willingness and humbleness to learn (and the employer wants to invest in the team - which, sadly, is often not the case).

Someone I hire as an employee I want to have a good understanding of their capabilities, because - let's face it - letting someone go is not a good option esp. culturally in Germany (it would still be possible within first half year "Probezeit"). But I do prefer to hire someone that I am certain can contribute to the team for the next years.

As someone who interviews, I can say that while there is a correlation between CV and coding skills, you do find regularly that really simple coding problems cannot be solved by applicants (slightly above FizzBuzz complexity).

And for most applicants, there is no Github-Account.

So I think its only fair to have some coding problems that don't overdo it of course for permanent positions.

When you are consulting the situation is of course a bit different. The situation is temporary. Getting and verifying references is actually legal and possible. So I can definitely see that you get gigs this way (you'd also get hired without solving a coding challenge because many companies don'T do it actually).

I just personally would feel much safer joining a company as an employee where I can be certain that my colleagues can at least code and have been selected with appropriate care.

In general, I do agree with you.

In Europe it is very difficult (and expensive and convoluted) to let go of an employee, so a company must find a way to validate the hire, regardless of the Probezeit (probation).

I'm not advocating that companies should suddendly stop running interviews, and I would be very wary of a company who would hire me permanently without conducting a technical interview, especially for system-design level positions.

In my particular situation, I found that coming forward very clearly about my intentions as paid off so far, but I also realize that it may not work in the majority of cases.

> Getting and verifying references is actually legal and possible.

Is it not legal to verify references for a permanent position, in Germany?

Arbeitszeugnis are pretty much a standard reference mechanism in Germany, and a bad one can make a stink for years to come.

> Is it not legal to verify references for a permanent position, in Germany?

Not a lawyer, but I think you cannot call up a former employer. IIRC there are several legal reasons that make it almost impossible and too much of a hassle for everyone involved. Your ex-employer must give a written reference for example. It must be beyond doubt that the applicant has given their voluntary consent to you calling an ex-employer, because otherwise if you don't hire the applicant, the applicant could sue you, etc.

There is the Arbeitszeugnis which as an employer-to-be you can request. And the language of the Arbeitszeugnis in itself is a science of its own, because it may not contain negative wording so there are various phrases that are used to communicate negative behaviour, etc.

PS: I wouldn't rule out that here and there a phone call to an ex-employer happens. It's just pretty risky if the candidate should find out.

> it may not contain negative wording

it must not contain negative wording would be more fitting. I find that a bit silly to be honest. On the other hand an employee wouldn't show a bad reference, but it is quite ridiculous.

freely translated: "He always wanted to learn and completed his work to our satisfaction" is basically an F.

Your new employer is allowed to call your old one if the employee consents. He is only allowed to ask about certain things like the content of the reference he gave.

> freely translated: "He always wanted to learn and completed his work to our satisfaction" is basically an F.

Technically even that would be invalid in Austria, if you actually go to the AK (Arbeiterkammer)[1]. So this in turn results in everything being in the superlative. Along with that, the AK is something you just do NOT want to get into trouble with.

[1] https://www.arbeiterkammer.at/dienstzeugnis

In Germany you can also go to court and certain phrasing needs to be dropped according to the courts.

The valuable piece of information in an Arbeitszeugnis that it will tell you is, if the person "verlässt die Firma auf eigenen Wunsch", i.e. if the person resigned from their position, or whether they were let go.

I work in a FAANG and have a handful of German people on the team. They had to consent to have the former employee even called. Whether or not it was done , I don't know, but the new company can do it if the new hire consents to it. And the consent request was on a yes or yes basis.

If they would get a German work contract in their German office, this would have been borderline illegal.

> I do realize that this no-tech-interview approach would probably never work for permanent positions

This. Booking a freelancer is a completely different game than hiring an employee. There are legal aspects here because big company A hires small service provider company B aka freelancer to do work. In my experience companies looking for freelancers need experts with very specialized skills on framework X or cloud provider Y.

Laszlo Bock studied the predictive value of technical interviews when he was in charge of people operations at Google. He reported finding that they had zero predictive power.

To put it another way, we should expect that picking names out of a hat would do just as well as Google's infamously rigorous interview process. If I recall correctly, this result is generally consistent with other attempts to study hiring with technical requirements.

So if technical interviews have no predictive power, is there anything else that does? Yes: standardized testing.

So why doesn't everyone use standardized testing?

Well, it's a lot of work. You have to accurately identify personal attributes that are relevant to success in your business. They have to be things you can objectively measure. You have to encode them in a standardized test, or, failing that, find an existing test that measures something sufficiently similar to be relevant. You have to administer it in a way that preserves a reliable signal.

You probably need to engage professional specialists if you really want it to work. At the very least, you need to get someone in who can ask the right questions about your business and your goals to identify some existing standardized test that will match your needs reasonably well.

Maybe you don't think you can afford to do that. I mean, that basically means you can't afford to do better than random chance in hiring, but if you can't, you can't.

So what do you do instead?

Well, hiring is risky. A bad hire can cost your business a lot. Uncontrolled risk makes people anxious. Anxiety is bad for productivity.

Anxious people want to increase their control--or, failing that, their feeling of control.

So how can you feel more in control than by pulling names out of a hat?

How about technical interviews?

Maybe they don't have any predictive power, but they give you a very strong feeling of control. You control the candidate-selection process. You control the interview format and procedures. You decide the criteria, and who gets an offer and who doesn't. Sure, the end result may be the same as pulling names out of a hat, but the process is much more soothing.

So technical interviews it is.

> To put it another way, we should expect that picking names out of a hat would do just as well as Google's infamously rigorous interview process. If I recall correctly, this result is generally consistent with other attempts to study hiring with technical requirements.

The notoriously-drawn-out-and-draining interviews that practically require at least some study in advance, and probably quite a bit, strongly affect which names are in the hat though, no? I'd assumed that was about half the reason they did them in the first place (the other half is that hazing actually is pretty good at creating "team spirit" out of nothing)

Sure there's probably some filtering effect. I wonder what it actually filters for? If Bock's results are to believed, it doesn't filter for suitability to the job.

Maybe it's just a way to somewhat reduce the size of the candidate pool?

And maybe your observation about hazing is on the money, too.

A huge percentage of developers never bother applying to any FAANG (or similar) because they either don't believe they could pass so it'd be pointless, or they don't want to put hundreds of hours of study and go through several very painful days of soul-sucking interviews & travel for something that's not a sure thing, when they're already fairly comfortable as far as income goes (but probably not FAANG-comfortable). That's a pretty significant filter.

Good point. So, then, it's filtering for what? Starry-eyed optimism? That might actually be useful to the prospective employer.

It filters for several things, including a very high level of confidence in technical abilities, and a strong enough desire to work in a FAANG(-alike) to put up with a whole lot of dull/painful unpaid bullshit, but the point is that the "hat" doesn't contain a random sample of developers. I think the notoriety of the interviews probably does do a good job of ensuring that the pool almost entirely contains people that, so far as tech chops go, are good enough to do the job—it excludes a bunch more of those from bothering to apply, of course, but the point is that I don't find it surprising that choosing randomly from their already selection-biased "hat" yields results of similar quality to actually conducting the interviews. The problem is that, if they loosen up the interviews, that will (I expect) stop being true.

Look at it like this: if you have a club that is notorious for only letting very pretty people in, I bet a random sampling of the line outside skews incredibly good-looking, but they can't just start randomly choosing people from the line without regard for their appearance, or that will change in a hurry. Meanwhile, it's also true that some very pretty club-goers don't get in that line in the first place, for a bunch of reasons possibly including that they don't want to be part of a scene like that, or a lack of confidence or anxiety over being harshly judged, or not thinking it's worth standing in line for an hour when they could go down the block to another club with lower standards and no line, and nearly all people who might be able to get in on an exceptionally weak night don't even think of trying, since more often than not it's pointless—but despite the loss of those folks, the line is still 95+% very pretty people, so it looks like they could do away with the high standards and harsh judgement and just let in a random sample by lottery, if you consider only that in isolation and not the effect the process itself had on the composition of the line.

(FWIW, this is a non-FAANG perspective—I'm 100% certain I'd struggle to even get past the phone screen without prep; about 95% sure I could do the actual work to an acceptable level; but judge it only about 50% likely I could eventually pass an interview with one or another after a great deal of practice and many, many tries, given probably 18-24 months of on-and-off effort and tens of extremely unpleasant days; so, I'm in the "unwilling to spend weeks of my life doing nothing but unwrapping Wonka Bars, when I'm not very sure there's a Golden Ticket in one of them" crowd)

Persuasive. Interesting.

I worked at a FAANG for a decade. though I've never done well in a tech interview. I've turned down offers and interview opportunies at some of the others--in some cases because I didn't want to bother with the interview process. Somewhere a long the way, after going through the hazing process a few times, I decided that it wasn't worth it, and stopped doing it.

Some of the offers I turned down--and one that I accepted--came after I performed quite poorly in interviews. Then again, as I've said, I have never performed well in them. I have the wrong kind of personality. I have to rely on other means.

It's filtering for people who have the time, feel the payoff is worth it, and are used to winning in high stakes testing scenarios.

Surely it's a little more specific than that? I'm used to winning in high-stakes standardized tests (which may explain why I'm favorably disposed to them), and in employers' assessments of my performance (and willingness to rehire me), but I'm used to losing in tech interviews.

I don't think so. Beyond that you are looking at the noise of the system which is why even over/perfectly qualified candidates have an interview failure rate of up to 50%.

> Laszlo Bock studied the predictive value of technical interviews when he was in charge of people operations at Google. He reported finding that they had zero predictive power.

Mind citing a source here? That would be a pretty big deal, both because it flies in the face of the entire industry, and because of the implications about Google if it determined the interviews were useless and then continued spending an incredible amount of money conducting them.

I was relying on my own memory, so feel free to disregard my remarks.

If you want to know what Bock has said about the subject, Google for Laszlo Bock along with some terms like "hiring" and "predictive".

His book on the subject is here:

https://www.goodreads.com/book/show/22875447-work-rules

It says that brain teasers and unstructured interviews don't work. Structured interviews do.

So what's a structured interview? It's a standardized set of predefined factual questions determined by relevant domain experts to be directly relevant to the job. In effect, a custom standardized test. He says the problem with them is that interviewers don't like using them.

Oh, and he says the problem with unstructured interviews--which interviewers prefer--is that the best predictor of the interview's result is an impression that the interviewer forms in the first ten seconds, and that impression has zero predictive power about the candidate's suitability for the job.

Google a little more widely to find more general research in this area.

For example: https://www.researchgate.net/publication/240237107_The_Role_...

...which says the best predictor overall is general cognitive ability (what we usually call IQ)

and

https://www.academia.edu/32446971/Big_Five_Personality_Dimen...

...which says that two of the Big Five personality traits (namely, Conscientiousness and Emotional Stability) are good predictors of good job performance.

IQ, by the way, is strongly correlated with another of the Big Five, generally called Openness.

So if we believe all of this research, then what you sould be looking for is objectively-verifiable skills directly related to what you expect the job to actually entail, combined with general intelligence, conscientiousness, and emotional stability.

By the way, I score low in emotional stability, so I have to rely on the other traits.

If you find that my characterizations are grossly wrong, feel free to trash me over them and I will thank you for improving my understanding and humbly apologize for wasting your time.

Yeah pretty sure this is BS. Bock talked extensively about interviews in his book. I recall him saying that after 4 interviews there were clear diminishing returns. If the interviews had no value, the diminishing returns would have been total at one.

A fair point.

I reread, and his claims were more specific than I allowed: brain-teaser-style questions have no predictive value; neither do "unstructured interviews", because the interviewers generally form an impression in the first ten seconds, that impression has no predictive value, and the interviewers then generally spend the rest of the interview confirming that initial impression.

However, structured interviews--interviews that consist of standardized domain-specific questions about relevant skills--do have predictive value. The problem with them is that interviewers don't like doing them.

I conflated the specific kinds of interviewing he deprecated with "the technical interview", I assume because those are the kinds of technical interviews I've seen. In thirty years or so, I've never seen the kind of structured interview Bock praised. Still, conflating the different things was my mistake. Thanks for correcting me.

Did his work look only at people who passed the Google process? I would guess so, since he probably didn't have the resources to track down the careers of people outside of Google.

The statement "Amongst people who passed the Google interview, the technical screen had no connection with Google career success" is a very different statement than "no connection between technical interview performance and career performance" due to the selection bias.

You're right on both counts. Good point.

Zero prediction power is an extremely exaggeration.

If this was true, Google could have just hired everyone who failed and rejected everyone who passed the interview?

If Google started doing that, the company would collapse pretty quickly.

Agree that it is an extreme exaggeration. Some people just can't code and there is a baseline.

> If Google started doing that, the company would collapse pretty quickly.

I'd mention that they are already crumbling:

1.) Search has been deteriorating since 2007 and is now at the level of the engines they replaced (yep, Yahoo, Alta Vista etc actually worked, it was just that Google was extremely much better back then).

2.) They cannot maintain anything except the core services.

3.) Previously everyone including me wanted to work there because it was cool, now I at least don't think of it as cool anymore so I guess they have a harder time recruiting the best and brightest.

I am developer for 30 years with experience from whole stack, from kernel modules/windows drivers to the js (which I must say, I avoid as much as possible, currently experimenting with webasm).

One startup, had three interviews, once I have started to describe the project I have worked and some background has issued a personal memo to hire me immediately, second one gave me to implement filesystem traversing recursion, the third guy...

... now the fun begins. Described me a case of huge volume of http data and how would I load balance them. "hm, ok, huge amount of data, lets propose the DNS based load balancing, you can still do proxy based load balancing on entrypoints". The counter answer was that do I really think this is server side solution, once I have described it to him, he said that he doesn't agree and that DNS load balancing is client side based solution.

And I was out.

Got new job in two weeks. With one hiring interview, no stupid programming tasks, just some talking what I was working before. And they raised my sallary twice in 6 months.

I think that this nonsense with tech hiring must stop. It is damaging the companies that are looking for good engineers as they only get engineers that are worse that their existing engineers. The classic old story A people hire B people, B people hire C people,...

I wonder if tech is unique in having an implicit mistrust for everything on the resume. I've worked at several large companies where people don't even bother looking at them before interviews.

I blame the FizzBuzz blogpost (https://blog.codinghorror.com/why-cant-programmers-program/) for making everyone deathly afraid of imposters. It's a masterpiece in ego-stroking - of course you can write FizzBuzz, look at all these sorry suckers who can't. Resumes are lies, only a 45 minute brainteaser on CoderPad can reveal the truth (ignore existence of Leetcode).

In reality if I'm considering a senior candidate from FAANG (like, actually senior, not 4 years out of school), simply talking about past experience is perfectly fine. The work is the fucking same, everyone is migrating from legacy system X to a distributed system with zookeeper and kafka, they'll fit right in. It would take a truly psychopathic liar to fake their way through all the mundane details you could ask about a project like this. And if one slips through the cracks, they'd probably make a great PM anyway. (As long as they're on your side.)

If they can't code just make them manage and bullshit everyone else in process. And hope they are smart enough to let people they manage to make important decisions.

>I wonder if tech is unique in having an implicit mistrust for everything on the resume. I've worked at several large companies where people don't even bother looking at them before interviews. I blame the FizzBuzz blogpost (https://blog.codinghorror.com/why-cant-programmers-program/) for making everyone deathly afraid of imposters. It's a masterpiece in ego-stroking - of course you can write FizzBuzz, look at all these sorry suckers who can't. Resumes are lies, only a 45 minute brainteaser on CoderPad can reveal the truth (ignore existence of Leetcode).

While I agree with you on the whole, I have had interviewed candidates who couldn't code.

One of them basically said that they would learn (CS degree but 4 years as a PM), which was fine but not what we were looking for.

Another simply refused help and proceeded to bat their head against the brick wall of simply syntax. Didn't show signs of nervousness, panic, etc ... just seemed not to be able to code.

In short, I think they exist (programmers that can't program) but they are the exception not the rule.

>In reality if I'm considering a senior candidate from FAANG (like, actually senior, not 4 years out of school), simply talking about past experience is perfectly fine. The work is the fucking same, everyone is migrating from legacy system X to a distributed system with zookeeper and kafka, they'll fit right in. It would take a truly psychopathic liar to fake their way through all the mundane details you could ask about a project like this. And if one slips through the cracks, they'd probably make a great PM anyway. (As long as they're on your side.)

I agree with you that an interview probing the experience of the candidate by getting them to talk about what they've done seems like a far better proposition. You will get a better idea of what the candidate knows, doesn't know.

Degree doesn't say much, not even intelligence does.

If you want an experienced developer that can start right away, it must be someone that worked an extended time period with the specific technologies required, there is no alternative. Especially in software that could be anything.

The company I work for mainly just hires people for a month and then management gets feedback from the engineers before committing to someone. I think this process is quite nice and people seem to like it (they get paid of course). Applicants are subjected to the whims of engineers though, so you "need to be a fit" too. Advantages and disadvantages.

Fizz buzz is an easy example, but that is basically checking that someone knows the modulo operator. A lot of devs also lack basic "tricks" with bit operations. Ideally a developer is able to do that, but companies must be aware to offer resources to train people.

Another anecdote: I'm mostly doing embedded C and I always fail leetcode tests and get my jobs when the interviewers endup valuing more the conversation where I can easily talk about past experience about real world problem I solved or the many time I went to a factory floor debugging embedded system live.

I was working for startup company a few year ago that didn't had yet their leetcode process setup. This startup had an algorithm team working on signal processing and the embed team that pretty much took their python algo and translated them in either C or ASM for some special accelerator + the typical board bringup.

Before using leetcode with new candidate they asked for some volunteer in the team to try it out. I did the test and failed miserably as always. My boss called me to his office and told me, your one of my best guy but you did the worst in the test. I told him this test is probably good for hiring someone for the algo team but for embed it's not relevant at all to the kind of problem we work on.

My boss did some research and found a test targeted at embedded programming. I did the test and got best score in the team (equal with one teammate).

Test are good but you need the right one for the right position. Most of the time for embed job it's the wrong test.

One of the problems with going primarily on past experience (and I've seen this happen a few times) is that there are some people who have a skill of just sort of hanging around whilst other people do the work. They can talk your ear off about the work and all the things involved, but they just don't do anything and when really pushed to do things they come up with just terrible solutions. I know one guy whose sole contribution to the codebase was to run an auto-formatter on every single repository. Those type of people can be very disruptive.

Meh. There's nothing wrong with tech hiring.

Ok, sure, there are some companies out there that don't know what they are doing, and the very most prestigious companies have to do some very tedious stuff to deal with the fact that their process gets leaked and people are willing to put a ton of effort into preparation.

But mostly, it's pretty reasonable:

- Little reliance on credentials, because there are many solid candidates that didn't go to top schools or don't have CS degrees or maybe didn't go to post-secondary school at all.

- There's some sort of technical interview that asks the candidate to show they can do the work by doing a small amount of work. They usually let candidates choose the language and tools they'll use for this, offer help if the candidate gets stuck, let them look things up on the web, etc. This can take a few different forms, but it's inevitable given that credentials aren't reliable.

- There's some sort of "behavioural" interview that asks about how a candidate collaborates and communicates with coworkers. Tech companies aren't looking for the anti-social genius anymore; software requires teamwork.

- Recruiters are typically very accommodating of a candidates' circumstances. They'll tailor the pace and scheduling of interviews to the candidates' needs, fly them in from other cities, reserve time in interviews to answer candidate questions, and generally put significant and explicit effort into making the "candidate experience" as positive and low-stress as possible.

- There's a lot effort put into eliminating biases, and interviewers will often do things like not reading a candidate's resume until after the interview, or writing up their report before talking with other interviewers about the candidate. Most tech companies really want to do this right.

I think that what tech companies ask of candidates is quite fair. These are high-paying (sometimes very high-paying), high-prestige, comfortable jobs with lots of perks. The company puts a lot of time and money into training new hires before they're productive, and it'll be even more time before they can tell if the new employee was a good hire or not. In other words, the cost of hiring the wrong person is very high.

The problem with tech hiring is that a significant fraction of tech people are basically unskilled. Despite education and experience in some cases. Odds are either the interviewee is unskilled or the interviewer is.

In the best case where you have a technically skilled interviewer and interviewee, there is still the problem of: 'the correct answer is my answer. Even if yours also works, it is not my answer.'

Tech hiring is not difficult, but it requires the following traits in the interviewer:

1. Broad technical skills and the ability to recognize skills in others.

2. Ego is not driving them. No need to be smarter than everyone.

3. Conversational/interpersonal skills to get the interviewee to talk, and to recognize someone who will be a jerk.

The common assumption is that skilled tech people lack interpersonal skills, but in my experience 1&2 is the rare combination.

> the correct answer is my answer. Even if yours also works, it is not my answer.

That right there is probably what's actually wrong with the tech hiring. And that's why Leetcode, despite the disconnect of it from the real job, is actually better in my experience than free-flowing conversations "to gauge experience". There are only so many working answers to a leetcode challenge (p99 is less than 3) and yet there is an infinite space of things you can say in a conversation that will instantly bar you from passing the interview. And what's even worse, you can say the opposite things to 2 different interviewers at the same company and they will both disqualify you.

A tale of 2 technical interviews..

Interviewer: There is a file of 500,000 words. Some of the words are duplicated. I would like you to produce a report of the duplicated words, and the report should be sorted most-duplicated to least-duplicated. You can use any programming language you like.

Candidate 1 spent half an hour writing a program in Java that accomplished the task. He passed, but was ultimately not offered a job.

Candidate 2 spent approximately 10 seconds and typed `cat words.txt | sort | uniq -c | sort -gr`. He passed, and was hired.

The moral is...sometimes a technical task in an interview is not to assess only your coding ability, it's also to assess your problem solving methodology. The person who used common user-space unix/linux tools didn't already have his mind locked into "writing a program to accomplish the interviewer's objectives" - he just used the lowest common denominator(the shell) that could accomplish the task he was given. It's not all algorithm memorization that counts.

That's.... a really poor comparison, maybe you missed some background on what exactly the interviewer was looking for. Sure, maybe CLI knowledge is going to be useful, but if you're looking for experience with Java because you're going to implement some complex string filtering in it, then the 2nd candidate's solution is literally useless as a comparison point. Also, if you're comparing them directly you're essentially punishing the 1st developer for maybe not having experience with some technology that was particularly well suited for that question.

Would you also have accepted a solution like "I send the file to someone on Mechanical Turk to find the words"? Or "I ask my daughter to look through them and find them"? Or "I ask someone in an interview to write a program to find it out"? Or "I paste it into this online tool that produces statistics of the most common words in some text"?

Isn't this also a case of just... having bash skills? I feel like your two cases are just programmers that have different toolboxes under their belts -- the second candidate does not necessarily demonstrate more problem-solving skills than the first.

I've brought up easy solutions like this. The response is almost always "Well don't do that. You can't use that." I legitimately think it's because they don't understand that actual solution and are embarrassed about being shown up.

In the 1 or 2 cases where they just want to see you do it in X language, it always turns out so wildly inefficient. I don't understand what you're supposed to do.

"Don't use that 1 line textbook optimal solution. Use a for loop instead." Uhh.. Ok. I guess they want to see more lines of code? More code = more better engineer.

"Why are you using a double for loop? Why didn't you just use the built in method to solve this?"

Sometimes the "built in method" is literally the original solution you were presented, but slower. What are you supposed to do? If you can't use the optimal solution, why are they giving feedback on suboptimal code in a follow up answer?

It's like they're asking you to demolish a building, but you can't use TNT or heavy construction equipment. So you pick up a sledgehammer and talk about the weak points in the structure and how you have to have a plan and strategically knock down support beams to demonstrate your knowledge in this theoretical situation. But they just scream at you-- why would you use a sledgehammer instead of a wrecking ball?

"Wrecking ball isn't heavy equipment! It's built into.... A machine. Totally different."

Or why aren't you using a rocket launcher? I guess you're inexperienced. "Rocket launcher is totally different from TNT, of course! You didn't even think to use that! I guess you're not a real engineer, huh?"

I mean if someone limits you from using TNT when that's clearly the solution, using a rocket launcher should clearly not be in the spirit of the challenge they presented.

I see some other folks chimed in here too, but I wanted to add my 2¢.

I see the appeal you are outlining, but I can't help but feel like the demonstrated solution is really just programming under a different moniker, but one that doesn't align with the spirit of the posed question. Is bash a programming language? I guess so.

I've been programming professionally for 7 years. I know `cat`. I don't know those other things off the top of my head.

I could implement a solution much like the Java candidate though, with information that I have memorized through years of constant use.

Being clever and novel is a cool party trick, but ultimately only proves that you are clever and have novel ideas. That could be great for an organization, but it might also be the wrong fit for whatever role is being considered.

Your final sentence highlights a bit of hypocrisy (no judgement!)

> It's not all algorithm memorization that counts.

But that's _literally_ what the bash solution was. Memorization of an algorithm, albeit a very optimized one!

This is classic "your answer is not my answer." And it's a form of bias. You passed on the person who knew how to write a more complex solution to the problem, and chose the person who chose a more simplistic route. But there's zero commentary on whether Candidate 2 had the knowledge required to write the complex program to solve the problem. Whereas Candidate 1 could have (likely) been easily taught what the command line alternative was.

Your process seems flawed as it appears to operate solely on your bias, from this description.

you are literally measuring a person on their familiarity with a tool and not general problem solving aptitude, people with high problem solving aptitude can learn tools needed for a job pretty fast.

I don't agree with this.

>The person who used common user-space unix/linux tools didn't already have his mind locked into "writing a program to accomplish the interviewer's objectives"

It's partly your fail as a interviewer that candidate has to guess what you expect from him.

What if instead of using bash s/he had used popular GUI tool like Excel(let's assume that it performs the job quickly too), then would it be OK too?

I insist on discussing salary range up front to avoid wasting everyone's time over the next couple of calls... also coding tests are a pain in the ass and as a general rule I don't do them. If I can walk someone through a project I've worked on and discuss it, or do a collaborative code review, that works, otherwise I thank them for the opportunity and move on.

I don't get a lot of callbacks anymore since taking this stance, but that's fine. There's a reason why probation periods exist, and after a few years in the field, most engineers are able to adapt to a new code base just fine, it's the soft skills that interviews should filter for anyhow.

my2c

edit: typo

I take exactly the same stance. I find that, while I'm not contacted for followups from places like LinkedIn and cold-contact recruiter emails, the approach does resonate with smaller companies that look to places like AngelList and Moonlight for their recruiting efforts.

Tech recruiting has become a massive numbers, volume grift.

Counter take: After having worked for startups a lot, my CV did not really look very impressive. A couple of short-medium stints would not really instil a vast confidence to someone screening.

Algorithm and "Trick" Coding Questions allow me to prepare for companies I would normally never qualify for just based on my past experience. If Google only hired people who have touched Google scale systems, they might not have a lot of people to choose from.

Thanks to the current interview structure, I can spend some time and prepare for any large company regardless of the kind of work I have been exposed to so far.

Its definitely not a great process, and requires a lot of time investment to prepare but allows people from not so impressive backgrounds to get a fair(ish) shot.

What’s wrong is the people in charge of most companies. They have money and connections but not much talent for actually managing the building of working things. And then they want to pay relatively little to the people who actually can build the things… while not knowing how to distinguish those people from the rest of the crowd.

And of course, among the skills they lack is the ability to measure results and design effective compensation systems.

Ah, the perennial HN topic. The trouble is, it is simply not possible to objectively evaluate people without having false positives and false negatives.

Not accepting this leads to endless debate, grief, lawsuits, and miscarriages of justice.

Not to mention that different candidates have different preferences, and different companies have different needs.

Different approaches work for different people

e.g

People with family/kids would rather not do home-work tasks

Some people would prefer to be asked about heavy job-related stuff e.g frameworks, kubernetes, real-life problems

Some people would rather challenge themselves against foundational knowledge e.g because for them it may be faster to do 1-2 algo tasks or it being technology agnostic

Some people would rather try designing systems, operate at higher abstractions levels instead of typing code

...

I personally believe that I'd rather see security questions than algo/ds questions cuz poorly performing algo can always be rewritten, meanwhile leak cannot be reverted, but I'm aware that shitton of people would hate that

How to match "interview kind" to candidate? maybe ask them which they prefer, I guess?

but it assumes that you have people capable of performing this kinds of interview and you want to "enable" this person to peak

> How to match "interview kind" to candidate? maybe ask them which they prefer, I guess?

I don't think it's a matter of candidate preference but rather position need.

Some companies need Computer Science / Engineer mindset to solve complex problems. Some companies need XYZ framework developers to deliver customer projects. FAANG companies usually need the Engineering role and developed an interview model to select those.

The problem is when companies that need developers apply the same interview mindset that Google does.

Referenced research paper: https://chrisparnin.me/pdf/interviews-HN.pdf

Only read it partially so far, but it seems interesting.

It also refers to https://chrisparnin.me/pdf/Debugging-Hiring.pdf

These are both great!

I recently switched jobs and got interviews in 5 big companies for mid/senior Software Engineering positions. All their processes were fairly similar: Two coding interviews, one system design interview and a conversation with the hiring manager. I might be biased because this process was beneficial for me, but here are my 2 cents on it:

It's easier to get a position in a stack you don't have professional experience with. You're tested for your ability to learn CS concepts, not stack specific knowledge. All 5 positions I interviewed to had different technologies. If I had to learn the specifics of each before applying, I would likely not get offered any positions.

This article is very light and based roughly on the qualitative study linked in another comment. The study reads like a summary of Hacker News thoughts on tech hiring, which isn't much news to me.

The site is an aggregator of paper reviews, this review combined two papers and added relevant anecdotes not in either.

> Short summaries of recent results in empirical software engineering research

For me personally, I am still mystified by how subjective interviews like System Design/Behavioral are graded. E.g. if asked to design a large scale distributed system like Uber what would be the pass/fail criteria when calibration of responses is done w.r.t. YOE (5/10/15)? What would indicate that such and such is a good response for someone at Principal level but not so for someone who is at Senior level or vice versa.

They reference Automattic's hiring process, which is an interview (90mins), take home coding (6hrs) and a paid project (40hrs).

That essentially makes hiring a serial process for the candidate. All you are selecting for is people who really really want to work for you.

I see software as a form of literacy. How do people hire writers?

I think it's the 6 hour take home coding that's a problem. I would suspect that when hiring writers, they look at a sample of the writer's past work and don't require the writer to spend 6 hours writing a sample children's book.

Would be nice to have an example. 6h/40h software development doesn't really say much about scope and is highly dependent on your experience with the tools necessary to perform the task.

The 40h paid project also seems kind of crazy to me. It is nice that is is paid but almost every software engineer I have ever interviewed already had a full-time job and was looking to switch. Where are they supposed to find 40h to work on a side-project even if it is paid? Is the idea that you are supposed to quit your current job first before interviewing?

> Where are they supposed to find 40h to work on a side-project even if it is paid?

On top of that, taking on paid outside work in the same field could also be contrary to the candidate's contract with their existing employer[*].

[*] This no doubt depends on the employer and the jurisdiction.

Of course !

I had both a full day on site JS programming(css optional) and a 20hr take home reactJS exercise besides all the precious onboarding stuff, pretty crazy effort, for both parties, time is money. For one I had to take a day off, the other i did over a weekend.

Another thing I have realized, all the jobs valued php and bit SQL more as basic knowledge for web dev than any nodeJS/MongoDB even if it's just front end, they want some back end understanding. Had some nodeJS things that generated all the front end via express , including chat module and sign up/log in flow, but either it was overlooked or not valued, any 5 minute to do list or crud with anything front end JS seemed more important. I suppose few dare to touch the node ecosystem and nosql databases.

And the most recent one asked me if I can do their front end in react(really overkill, no need), told them I'll do it in vanilla JS, but nope, he insisted on react and that was the end of the story. Was for a MVP and would be the sole dev for a while.

I have found in general that speaking to hr is not useful, if you get past that and a senior dev (not a manager or product owner) interviews me, it would be a good experience.

As much as it is good they're paying you to take on a longer project, most people that are currently employed can't take this project without being in conflict with their current job. (Or even having time for it)

I think tech companies are forgetting that firing people is an option.

Particularly in the contract market - I often see the process for taking on a contractor or consultant play out the exact same way as for an employee, forgetting that the interview process is very flawed and you can send the consultant home at any point you feel like with zero comeback.

That said I’ve also seen companies pay contractors a month’s severance for no reason whatsoever too. A lot of places don’t seem to understand what they’re doing.

my contracting contracts - in Denmark - often have a notice period but it is around 1 week to 1 month.

I pretty much refuse coding exercises for contract work since it's so easy to get rid of me if you don't like it, and anyway as a contractor you get paid per hour so they should pay me for it. But sometimes there comes a place you really want to work for and they happen to have the coding exercise...

No time? Can't people take vacation leave? Yeah it sucks that the time isn't spent on vacation, but you can't have everything in life without some cost.

You are either a troll or don't have a family. If you do have a family i feel sorry for them.

Life is not just about work.

I am not trolling. I do have a family. But I am still of the opinion that expecting absolutely no time/cost investment on your part when seeking a new job, is a false entitlement.

It's not false in the current market. You can spend an order of magnitude less on each company just by learning algos once.

At some point the best thing is to just pass on working with them. If the hiring requirement is so draconian that it selects out people with options you end up with a company full of second tier people.

Company is better pay damm well for me to spend my own time to try to get working there. I would evaluate that limit to be multiple times market rates.

If you want to interview at 5 places, and they all have 40-hour projects, then what? You disappear from work for a month while you job search?

If you already have a job you are very likely not in desperate need of a new job. If you want a higher salary then you probably need to sacrifice something.

That seems like a really counter-productive position to take if you are trying to hire software engineers. The market is currently very hot so if you are limiting yourself to only candidates who are in "desperate need of a new job" then you are probably going to have a lot of trouble finding people.

I'm not trying to optimise hiring, I'm just pointing out that from the developers point of view it's not a big issue.

We are going to have to agree to disagree here. Anything that eats a full month of my time is a big deal, and I expect companies to be more efficient with my time than this.

Few large organizations are very efficient about anything related to HR or management. But I'm not sure where you're getting "one month" from.

If all companies do this, then interviewing at 5 companies eats 5 weeks of time.

Presumably the project is the last step, when they are basically just checking that you are as good as you say you are. Like checking references. At that point you should already be 90% certain to be hired, not 20%.

Yes. Right now I've saved a month of vacation days so it's totally possible for me. And during that month, you get paid for these new projects, so in the worst case you can ask for unpaid leave at your old employer. What's wrong with that?

If you do one challenge, 6h is ok - I've even enjoyed these at times. But I'm sure it gets old real fast if you are on your 10th one...

10 challenges is like two weeks of work. You probably studied for 3 to 5 years, and hopefully you'll work there for at least 2 years. Two weeks is not much, even if it is tedious.

You assume that there is no alternative which is a better match and doesn't have this sort of hoops to jump through.

I don't assume anything, I'm only saying that even if you had to spend 2 weeks to get a job, that's not really anything to complain about.

The vast majority of people spend way more than that.

Free advice: don't do "homeworks". It's an indication of poorly run and dishonest company, with incompetents at the helm. That's if you get the contract. Most likely you won't (because your are competing with desperate people who lie about their actual effort). Best is to stay out of it.

I got my FAANG job through whiteboard interviews, but I definitely prefer homework, and I think that's a better method. But thanks for the advice.

> All you are selecting for is people who really really want to work for you.

Really really wanting to work there is a good start. If they can also finish the tasks in a competent way it would seem they are perfect candidates. What is the problem?

How many competent candidates are willing to jump through hoops like this?

I don't know, 23?

It seems Automattic is part of a select group of tech companies who are desirable as places to work, and have more high quality applicants than they can hire, and need to whittle down.

That's great. And if I apply to one of those I really need to expect that.

Now the company can be in this great position by being a world leading engineering organisation that is growing exponentially. Google, Facebook et al a few years back perhaps.

But alternatively, any $RANDOMCOMPANY can think it is in this position not by attracting the best applicants globally, but by only hiring 3 people a year. The company still will get more high quality applicants than it can hire, so it needs to whittle down.

But from the applicant side, applying to Google looks very different than applying to $RANDOMCOMPANY and they will drop in preference order.

Taken to its logical extreme, each candidate will choose one company only to apply to based on the existing job pool and their expectations of getting the job. That seems silly.

46.5h to interview at a company? I’m not sure why cream of the crop developers would tolerate that over 5h of interviews. That sounds nearly predatory.

I surely wouldn't do 6 hours of unpaid work. Not unless very desperate.

"Hire for strengths, not to avoid weaknesses." is the best advice most often ignored in tech hiring.

I ask potential candidates what the best project they ever worked on was. I explain that I'm going to use it as a way of gauging technical aptitude so please answer appropriately. Once they get started, I ask questions that make sense based on what the candidate says. In most cases you can glean enough of what a candidate can do by the depth and breadth of their answers. You can get a sense of how passionate they are, how detail oriented. You can ask about the problems they encountered, how they handled them, what they would do differently. What kind of notes did you take? What kind of documentation did you leave, etc.

> cause a lot of anxiety (which means the results aren't representative of on-job performance)

Not that I disagree with the author in general, but surely he can't be suggesting that work doesn't cause anxiety itself?

Issue 7/N: Don't make me code in a fucking <textarea> box, or Google sheet, or otherwise. It's bad enough on the job, only even worse under the pressure of an interview.

A good top-tip from David Hansson was if you are not sure, pay them to produce something useful for the company, perhaps about a week's worth. Then you are seeing what they are really like to work with and what they can produce without expecting them just to do it for free. Much cheaper than losing your Recruiter's fee when they don't last 3 months.

This is great and easy for companies that have great brand recognition and interested candidates like automattic and basecamp. This doesnt really work when people don't give a shit about your company and you're asking them to work for you part time on a contract when other companies are doing 1 or 2 and done interview processes.

It also selects for a certain type of individual who has enough free time outside of their day job to do extra part time work for a week to a month.

I love it when I apply for a lot of jobs in one day, get a lot of rejections, then check the traffic on my GitHub and there’s minimal traffic. I guess at some point it pays off but it sure seems like climbing a mountain to get there.

I don't think there's anything "wrong" with tech hiring.

It may not be ideal but every approach has its trade offs.

it's all been said before here, but after working in IT for 30 years, I've literally forgotten more things that I've done than they could ever ask me. I've written threaded C++ code , built numerous IOS (objective C, Swift) apps for clients, written A LOT of java (many different app servers, most not supported anymore), Node, scala, spark, SQL (multiple dialects).. but I honestly can't remember most of the time how I did any of it (certainly not enough to regurgitate on a programming test). Headhunters are always amazed at the varied work that I've done.. but I've forgotten most of the low-level details which sucks because some of it was like 20 years ago. I've never been let go from any client, and I've been consulting continuously for big companies for over 25 years. But this is clearly not a sufficient for knowing answers to their specific question. I can't tell you offhand how to build depth-first-search, and I can't remember big O for most of the data structures that they would test me on). With three kids, I really have no time hack leetcode problems all day.. I completely understand that they need to filter, but I'm at such an odd place that it's hard for them to quantify my value because it may not line up to their identification process (which is also fair, I suppose). I somehow doubt that it's age bias, it's almost that I've done way too much and they can't rely on trusting that I'm not lying about any of it. I would have to interviewed by someone who puts the same value on my specific accomplishments with specific discussion around design, implementation challenges, etc. Not specific syntactical bullshit questions.. Most of the shit I look up anyway based on what the specific problem is. As someone else said, smaller companies tend to trust a little more in this area.. I basically learn what I need so I can solve their problem in the most performant way. I know I'm not an 'expert' in anything, but I've been able to quickly learn things and apply them so it accomplishes their goal. This isn't really 'testable' per se.. other than perhaps hiring on a trial basis and throwing some difficult problem at me. None of that is really scalable though. It's really a difficult problem.. the best guys I've worked with really didn't look good on paper. However, they always achieved the goals and worked well in chaotic, mostly unstructured scenarios where the goal wasn't well defined, and the technology choices suspect or basically untested. They figured it out.. 'figuring it out' under pressure is hard to quantify in an interview.

The links in this piece are broken for me, DOI not found (in case the author is lurking)

BTW, to whoever posted this, looks like a great article, but the DOI link is broken?

My recent interview experience with Twitter: https://news.ycombinator.com/item?id=28466586

Reply on news.ycombinator.com