An example and actual numbers would be a good addition to this article.

Why do we talk about this every week on HN?

I'm pretty sure it's either once a week or once every two weeks.

One issue I've noticed is that the elite companies are trend setters, and their interview methods are being copied by non elite players.

Perhaps Facebook needs and wants engineers that can bust out A* on the spot, but I doubt Nordstrom or Starbucks needs that level of talent.

This has changed the field where now to even get an average job at an average company you need to study at the new normal, whose interview ideas were designed to look for the top 1% of the field.

I totally agree with this. You shouldn't ask a question where some amount of luck of figuring out the problem is necessary. Instead ask something practical and relevant to your domain. Also, leave room for exploration if they sail through it and recovery for someone that goes down a bad path.

https://github.com/spullara/interviewcode

I’d agree but on the condition interviewer actually know ehat they are doing.

As I gained more experience (300 interviews and counting, baby) I realized that I pick up more on candidates skills that are not directly related to their performance on particular question. At this point the question itself is just a conversation starter and so it’s better if it’s simpler and more broad because it leaves lots more avenues for the conversation to go.

I ask what they've built, and how it was done.

This shows you way more than what a technical question can answer.

There are edge cases to this. Expertise positions specifically.

I'm like 0/15 on interviews in the last 2 months. more than half of them were with foreigners who i could barley understand.

Another use of these kind of interviews is age discrimination to filter out of older candidates who don't have time or motivation to prepare for this BS. This is just another fad.. In late 90s there was fad for MSFT style puzzle interviews..then it went out of fashion.. this will also go out of trend.. just wait for couple of more years.

"Easier interview questions are also less stressful, which is an important advantage. Stress causes candidates to under-perform. But, on the other hand, when candidates are more comfortable, they perform their true best, which actually makes interviews more predictive."

I cannot believe that any interview situation is comfortable.

Interviews are like taking the SAT or ACT. For better or worse they’re highly standardized and you just need to prepare. There are a bunch of different prep service like InterviewCake.com, Pramp.com, and PracticeCodingInterview.com that are good if you feel like you need more than just leetcode grinding.

Where I earn my money is thinking of a solution to a hard problem while not actually at work. It probably only comes up a few times in a year.

Questions you can answer immediately simply don't test if you can do this. I have no idea how you would test to see if you can do this.

Isn't this just saying that easier questions are more correlated with overall interview performance? That might be a good thing (a sign of consistency), but it could just as easily be a bad thing (i.e. it doesn't provide unique signal).

I took a technical interview today over the phone, and you know what, they were pretty fair with their questions. I don't know what kind of competition I'm up against for the position, but very fair questions.

I've worked for several companies who made up tests that nobody on staff could pass, including the authors. But the test did imply that the existing staff was superhuman, since no applicant could pass.

Interesting post! I appreciate this being shared.

Would Triplebyte mind sharing the data? I'd love if the numbers could speak for themselves, rather than having to rely on an interpretation of the numbers.

It seems like this article would be stronger with some examples. What are some examples of good and overly-difficult questions, according to TripleByte?

I’d love for this article to provide examples of what they consider “hard” and “easy”.

Heads up I think there's a typo here: "questions that carrying".

Interesting piece!

Let it stay here https://twitter.com/dhh/status/834146806594433025?lang=en

"Hello, my name is David. I would fail to write bubble sort on a whiteboard"

That's because professional outcomes for programmers aren't related to aptitude. Nobody ever got promoted for writing good code. (But the reverse is very common.)

What alternative would you suggest?

Because they're designed that way. It all comes down to:

* Rejecting far more candidates than you need to -- so you can feel like you're hiring "the top 1 percent"

* Giving yourself the feeling that you have an objective hiring process (when really you don't)

* Making your own team members feel like they're super brilliant and special when really they're not

That's what the modern hiring process is designed to do. And in fact it works quite well, to serve this purpose.

I don't give questions like this primarily because:

- Workers are going to be around for 15 months or less and they have domain expertise on 1 stack already and I don't need to screen for how they would hypothetically function across all stacks

- Worker's process and resource finding skills are more indicative of the time they will spend on a task

- Worker's process includes collaborate use of version control and code reviews, if they pass the screening but can't really integrate on these things then thats what will get them booted from the team

It isn't always more expensive to have a not great developer. Look in your organization and see if what I experience is true for you, and you'll save everyone a lot of time.

More likely the phrasing of your response provided signals that they shouldn't proceed.

Months? Years :). Know couple of teams in my current place (very well known company) that couldn’t hire for a year... and lost position, as business argued - if you can’t hire for a whole year you don’t really need t

I did seven interviews for a top US bank. I didn't pass. They needed to fill dozens of positions. Two years later they opened the gates and hired a notorious complainer ex-coworker. That's the current state of affairs.

I suggest you read up on the effects of market friction. 300k/year could very well be a bargain for these people even if it sounds like a lot to you.

This whole rock star/ninja interview process is ridiculous. They need to paint a house but they want to hire Michelangelo.

Having recently gone through some interviewing (for machine learning research), a very cynical but overlooked aspect (in this thread) is the following:

After receiving an offer from a big tech company, the interviewing process has already completely turned me off from the idea of working there.

Now despite this being a dream position for many and me having no alternative but to take it currently, the smug interviewers have already gotten me in the corporate mind-set: No matter, the reputation and salary, treat it like any other job, do not bother being loyal - they will not be.

So the terrible interview process has at least the advantage of reminding future employees what they are signing up for.

I wonder what kind of psychological filtering is at play. Do employees feel loyalty after an interview process that is best described as hazing? Are they projecting the humiliation they experienced when interviewing future employees? That's always been my impression.

Specific examples of what classifies as a “hard” or “easy” interview question would be very helpful to have reference points and assess one’s own interview process.

You realize that this approach is flawed the moment there are blogposts / books ( e.g. Cracking the coding interview ) on how to crack it. The how to crack 'x' becomes a field altogether ( coaching / youtube videos / blogs / books etc ).

Also, platforms like hackerrank are adding fuel to fire. I read the CEO write somewhere that he wished the below "were taught in schools :

1) Communicating complex ideas with clarity 2) Systems thinking 3) Grunt work tasks 4) Boundaryless thinking 5) Self-awareness / EQ"

Please note almost all of these are not evaluated on their platform (they profit from coding tests) or during interviews and almost all are soft / intangible skills (skills which are not immediately obvious about the candidate during a typical programming interview). [ Side note : some could say that coding tests are the problem they have chosen to solve - in which case, why are they worried about these skills ? Are the companies seeing coders crack the tests on their platform, while not performing well on the above skills post hiring ? We could only speculate. ]

All good work is done by teams, and to be effective in a team requires a lot of intangibles which aren't even assessed in a typical interview.

A better approach could be from this article: https://leerob.io/blog/technical-recruiting-is-broken/

Or : A couple of weeks of work with a task being assigned and the mentor or interviewer looking at how the candidate is approaching the problem and whether he is able to solve the problem within the time constraints (an easy task shouldn't take long, and a hard problem shouldn't be short circuited to give a sub-optimal solution.) and other such observable traits can be evaluated.

My two cents!

EDIT : Poor wording above (i.e., couple of weeks). A task should be assigned and evaluated post a time (which is ideal for task completion as per the interviewer). No constant interaction with the candidate and spending loads of time with that candidate - that isn't scalable when the demand-supply equation is imbalanced already.

EDIT 2 : The idea above is not about spending weeks for recruitment. The idea was about being practical about the kind of questions / tasks that are given during interview (example : code a feature or fix an issue we have, as another user has suggested well in the comments). Took me a while to realize we have missed the point I tried to convey for the logistics of how it should be done.

I really agree. At companies I've worked at for the last 20 years (at least) the approach has been to ask pretty simple questions; people who struggle on those we don't want; people who don't struggle, even when they make silly mistakes (due to feeling interview pressure) are good.

Questions about the standard library of the programming language in question are good. Questions about the dusty corners of said library: bad.

And don't ask about floating point: most likely the candidate won't really know more than the usual things; anybody who really does understand them will probably give answers over the interviewer's head :-).

I like some coding in interviews. I try to make the tasks fairly real-world though. I am a UI engineer so my tasks typically fall into one of two buckets:

- A take home (2-3 hours) task for retrieving tabular data from an API and displaying it. Here I'm looking for general framework chops, readability, some design sense.

- An in-person (~45m) not-quite-pair programming task, with a real computer, tools, editor etc., for doing a typical UI operation, e.g. truncating text. Starts simple and gets more complex as time allows: make a function to truncate text to x chars; now add an ellipsis only if truncation occurred; now make sure not to truncate in the middle of a word, etc.

I've never been giving given a practical programming test. Nearly all are useless algorithms. Create a function that takes a integer greater than 0. Build an array equal in size to the argument. Fill the array with numbers that when summed together equal zero.

It was worded far worse than that. What exactly is that telling you about the engineer?

On the flip side I'm asked to code full fledged applications but not to spend too much time on them... okay...

Another time I was asked to code a luhn algorithm. Oh and do it while a room of people watches you on giant screen cause that's what your day to day job will look like... I failed miserably and still got the job. What?!?!?

Most programming interviews are a waste of time and energy for everyone involved and the results are, for the most part, a complete facade. Asking puzzle questions gives interviewers the feeling that they're really testing hard for top talent, when in reality they're just demonstrating their lack of interviewing skills.

I recently interviewed managers at two different technology companies, both nationally known, for a report I am working on. Most managers admitted their technical interviews were flawed, but didn't know any other way to assess skills. They also admitted that a significant number of people they recruit refuse to even take the technical challenge and end up working elsewhere.

In interviewing a couple dozen engineers, I found most just don't want to waste their evenings and weekends on a technical puzzle for a job, especially when there are a lot of companies out there who don't bother with them, so they end up searching for companies that don't waste their time with technical challenges.

Another funny thing I discovered during my research is that just under half of the employees at both companies I've interviewed so far were not able to successfully complete their own technical challenges.

Another problem with technical challenges is that often times the interviewer knows less about the topic than the interviewee. I recently went through the interview process with a local technology company who uses Elixir and Go (both of which I know). During the onsite interview, the interviewer kept saying things like, "Don't forget to..." or "You forgot..." I kept explaining that I didn't need to do as he was suggesting. In the end, my code worked, my tests worked, and I passed the interview. In spite of this, I was rejected because the interviewer, "Wasn't feeling it."

I still have a lot of research to do, but I haven't found anything, so far, that suggests that technical interviews predictably result in top-talent getting hired. It seems to be the same crapshoot interviewing people without using technical challenges is, because in the end, most people decide within the first couple of minutes if they like someone and hire based on that, regardless of the rest of the interview process.

I just finished reading Bill Kilday's Never Lost Again. It was amazing that four engineers produced the ground-breaking Google Maps in 16 months. Algorithm/Math questions used to be really effective at finding engineerings like those four engineers. There was a reason that Microsoft resorted to algorithm puzzles in its hay days as well.

It's just unfortunate that there's so much prepping materials online nowadays that the programming puzzles have become ineffective. It gets worse as many interviewers were not good enough to ask follow-up questions. For instance, addition with big integers is a pretty easy interview question, right? But if a candidate can go as deep as this article: https://bearssl.org/bigint.html, I can be pretty confident that the candidate is really really good.

That said, I personally don't find it necessary to join the rat race. Instead, I'd suggest engineers just take time to thoroughly study just one book on algorithm designs. In fact, an introductory book, such as Kleinberg's Algorithm Design or Udi Manber's Introduction to Algorithms, will be good enough. It may not get you into Google, but it will likely get you into another damn good company. The best part of this approach is that passing interview is really just the byproduct of you trying to become a better engineer.

Another clarification: this data only applies to general programming exercises and not domain-specific knowledge. For example, if your role requires bio-informatics knowledge (or ML or AI etc.), then by all means ask about bio-informatics—even if it means asking harder questions. (We do, however, recommend keeping the content of general programming exercises as vanilla as possible, so that you don't filter out someone because they lack mastery of a subject that you don't actually intend to measure.)

On the interview its build a tic tac toe but when you get to the real job they give you a week to fix a line of code. This industry is fucked up.

If you are asking interview questions that has one beautiful precise answer, you are doing it wrong. Good interview question should start with something very simple that even very beginner can think and answer, then gradually add complexity and constraints little by little.

Example:

1. Write function that multiplies two integers.

2. What if these numbers were real numbers but computer can only operate on integers? How do we use same number of bytes as ints to hold a real number?

3. What if I wanted infinite precision? What would be run time of your algorithm and storage complexity? (don't insist that candidate must hit the known optimal).

4. Can I have complex numbers as well?

5. Imagine complex numbers not only has "i" but also "j" and "k". How do we handle this?

It is astonishing how many candidates won't be able to move past #2.

The key is to look at how candidate approaches handling complexity, create representations and use it to craft clean solutions. Whether they eventually arrive at known optimal/great answers is unimportant.

So they saw a correlation among people they hired and made a conclusion about people who applied, with no reject inference?

>Harder questions ultimately filter out too many qualified candidates to be optimal.

This was the key sentence if anyone missed it. "Optimal" for whom, exactly? Not for FAANG certainly. They don't need to worry about filtering too many candidates out, because they have a nearly infinite pool of applicants, and infinite money to conduct a search.

They can ask as difficult questions as they want, because they can pass hundreds and thousands of qualified candidates, and still have plenty more where that came from.

Edit: If you consider "optimal" to be the expected cost of a hire compared to the expected profit, it is fully plausible that if your margins are big enough, asking hard questions is the most effective way to ensure low false-positives. But as everyone knows, comments on articles about interviews are never about the economics, it's only about human ego of feeling rejected.

Is it a surprise to anybody? My favourite example of interviews going bad is a tech company in SF asking to find cross currency arbitrage loops with all known currencies over the phone in the first round hiring data engineers for the ETL team. I am glad I did not pass that round.

I've seen this borne out in practice after administering dozens of phone screens and in-person interviews over the years. I started off with questions that were a little too hard and couldn't get a good read of the candidate unless they happened to have already done the problem on some interview prep site.

Switching to more practical, simpler problems allowed me to really observe how they work and solve a coding problem. As the article said, I was also able to add requirements or features to the problem which let me see how the candidate adapts to changing requirements, or refactors their own solution to handle a new edge case. Simpler is generally better if you are timeboxed to 45 minutes.

I changed careers from another technical non programming career to web development. I got a handful of interviews but I never felt like I was showing them what I could do... learn.

Until one finally gave me a fairly straightforward homework style project. It was probably more apt for a noob and I threw myself into it and submitted my work and explained what it over the phone. I was in the office the next day and we talked about it and I had an offer.

The homework style interviews are understandably controversial, but at least I got to show my work, me doing my work, my thought process, outside of a few moments at a keyboard.

I always thought that the primary quality measured by this popular interviewing style is "being-like-your-interviewer" which leads naturally to the avalanche effect due to which the practice becomes even more popular within the company and simply common sense after a while. The interesting part, to me, is how exactly similar the methodologies should be for companies different by size and domain. Even if you assume that some flavour of technical interview worked for Microfaceboogle, it might as well kill a copycat company (or may be completely irrelevant to its success or failure).

I wonder if hard questions, especially hard algorithm questions, has high false positive rate as well. Being good at solving those questions simply requires you to do tons of practice on leetcode, and those who are willing to spend tons of time are probably those who find it difficult to get jobs (or new grads). I don't think the skills for solving hard algorithm questions correlate well with the actual performance at work. Especially if someone is a new grad, they could be good at thise questions but don't have a clue about how real software systems are built.

Hold on, who is qualifying the outcome?

At one of my jobs I nailed it as the top candidate, by far, of the 79 people they interviewed in person. The interviewers were looking for competence, freedom from frameworks, experience and so forth. I have in this line of work more than 20 years and do it as a hobby so I nailed the interview.

At the job though I worked with a bunch of fresh juniors who only know how to write code the one way they learned in school. According to them I am shitty developer because I didn’t write code in the one way they understand.

Who qualifies the outcome?

This article makes a lot of good points. After going through the "implement a red-black tree on this whiteboard" experience as a more junior dev, I always promised myself I would never use this kind of stupid questions to hire.

Now, 13 years later, I mostly rely on "homework" type exercises. I think they address most of the issues. They are more "real world", no time pressure, etc. However, even those now are being heavily criticized. What's left to be used?

Given the 5th & 6th paragraphs about "correctness signal" and "process signal" it seems like the obvious solution would be to do both, i.e. ask questions that are easy alongside those that are hard. The easy ones are "process questions" and the hard ones are "correctness questions." Or maybe you have a range of difficulty from easy to hard, and each question has a number attached to it from 0 to 1 that reflects its intended use.

Some teams at Netflix do interview homework.

Sure, but in general all of the big company interviewing processes will convey the similar amounts of dread these days. They are so worried about false positives and have so little concern about false negatives that they push many candidates away simply by not focusing enough on the "why should I work here" part of the interview.

I'd argue finding the next permutation is actually very difficult if you don't know the standard algorithm.

The key word here is “optimal.” These aren’t difficult tasks if you can just write down the straightforward code to do them.

If your exercise truly takes 1 hour, and you're evaluating it on the basis of 1 hours' worth of effort, then fair enough. I would say that roughly equates to the technical phone screen in this case, except without all the annoying "let's talk about every little thing we're doing while we're doing it, so it takes twice as long" BS.

And there's nothing wrong with whiteboarding, if done appropriately. Whiteboarding a system design question is totally appropriate. Asking a candidate to write down code for finding the longest palindromic substring of an input string in linear time is not. I've never come to a situation where writing anything more than the barest pseudocode outline for what to do on a whiteboard was the best way to get a real world task accomplished.

I agree that "read my mind" is a terrible form of interview. One issue with the "let the candidate guide the conversation" approach as you are outlining here is that it is very very time consuming to train new people to administer this kind of evaluation in a repeatable, fair way. Giving the full definition helps the evaluation move along a bit faster, too. Then, it does not create an opportunity for evaluating "how do they explore the problem?"

> the candidate may spend 1 hour

> after you poured 2 hours

and at the end it turns out to be 5-10 hours. Companies say "you should be able to finish it in 1-2 hours", but it's almost never true.

I think alternative is to have 1 hour coding session on a good problem. Most problems are complicated, but there could be something else. I was once asked by Uber to implement timer in JavaScript that will update DOM, also create APIs to stop/start/pause. This kind of a challenge doesn't involve any algorithm, but it shows your ability to code.

It should be enough to bring you onsite.

But I open source should work. If you contributed to Linux Kernel and it was accepted - onsite no questions asked. If you have github repo of 1000+ stars - onsite no questions asked. If you have already passed Google tech screen and was invited onsite - invite onsite no questions asked.

That's not true, not every state shares or accepts Bar results from other states, and Doctors have medical board exams that also need to be studied for.

If you are a lawyer or a doctor and are moving to a new state, you probably need to study.

I still wouldn’t do it. Why should I, when I can do the entire interview process with another company with only a day’s worth of time expenditure on my end? If the task itself takes more than an hour or so, I can get to an onsite interview with far less effort than that by doing a recruiter chat and a phone screen.

Yeah, was thinking along these lines during this discussion. Sounds like a good idea and something that everyone would be fine too. The idea being that the interviewing pattern should shift from hard theoretical questions to practical problems that needs to be solved as you have suggested above :

"3-4 hour programming task, preferably based on a real problem or task that arose in the company's code base, suitably extracted, simplified, and scrubbed of proprietary information. Internet resources are allowed, as is asking any questions of the interviewer, without penalty."

This company sounds terrible. You have to be hazed by all the other brogrammers at the end after doing 80-160 hrs of unpaid work, ridiculous:

https://life.taxjar.com/taxjar-traditions/

This is good to know, typically it should be in concurrent with the existing employment. If we plan to switch companies, we commit time apart from existing office work for interview prep anyway. This interview prep time is what we would end up committing to work on their tasks etc. I think working on a project or task from the prospective employer would be much fun than preparing / memorizing interview questions etc. What do you think ?

TaxJar sounds insane. So after I go through up to 4 weeks of poorly paid work (while working my existing full-time job and raising a family), I get to participate in their hazing rituals!

https://life.taxjar.com/taxjar-traditions/

Thinking more about TaxJar...I wonder if they are at any risk of employees of an existing firm doing work for TaxJar on the current company's time and equipment, which would in many cases make the TaxJar code the intellectual property of the former company.

I immediately decline your type of interviews and my life is most likely better for it.

What was the process like before you streamlined it?

How much do you pay the candidates for their time?

Kinda the BBC of Silicon Valley then.

I'll be honest, I complained about my total lack of ability to find anything in the documentation and they emailed me back to ask for suggestions on what to fix. I never got back to them. I really should find time.

It was funny because in my frustration, I left a comment on the last page I looked at and they responded with the completely reasonable question, "Why were you looking at that page? It doesn't contain any of the information you were looking for." It was such a great summation of what my problems was that I felt difficulty in finding an appropriate response :-). Possibly this is too unfair, but I felt like the question, "How should I have found the information I was looking for?" was something that had never occurred to them. It's pretty applicable to virtually everything I've used from Google. It has that feel of, "If you don't already know, then you don't deserve to know".

> Hmmm hard decipher your comment.

I'm being facetious and agree with your sentiment.

Basically, your typical Brogrammer

If they ask you any CS101 or algo questions end the interview and explain why.

Their pre-screening quiz uses a bunch of questions on various technologies to ensure that some subset of the questions tests you on technologies you're familiar with. Which is good, since not everyone is a web engineer.

No, but they certainly have no use for SWEs thinking outside the box in ways beyond engineering work. Such as recognizing that interviews don't work well to predict ability and success. We engineers are supposed to shut up and conduct interviews and build interview tools, not wonder if the whole thing is a case of the emperor has no clothes.

I'm probably responding more to this thread than I should, but I'm an a chatty mood today :-) I think there are a lot of factors and this is almost certainly one of them. Having worked in a couple big, wealthy and famous companies before, one of the biggest problems is that they are always making acquisitions. One day you're building X and then upper management thinks, "Woah... X + Y would be awesome. But we don't want to spend time to build the Y part. Let's acquire a company and glue it onto X." Usually that happens with great grumbling from the programmers who complain that X and Y were never meant to work together and it would actually take more time to get them to work well than it would have to build Y in the first place. Upper management doesn't believe this and says, "Stop grumbling". And, well, the programmers do what they have to do. So it ends up being super hacky... because it is super hacky :-)

But I think it's more than that. You know how certain things are obviously built by committees? You can see it because everything is consistent, but it's often got a lot of compromises. On the other hand some things are obviously built by individual contributors. It's got some things that are really great, but other things that are horrible because the developer just has blinders on. Many Google apps give me the latter experience. Also, when they have a suite of tools, although they are tied in together, they have wildly different UI, naming conventions, placement and layout of information, etc. Usually there are some really cool bits, but these bits are often not the point of the project and look a bit out of place.

I think teams in Google often have people who are confident and smart and the tools reflect that. It's a kind of "This is the way to do X", shouted 500 different ways. One of the biggest things I find frustrating is the mountain of trivia that I have to commit to memory in order to use their tools fluently. I really do think it reflects the type of people that Google chooses when they hire people. While they may be good at the things that Google screens them for, they may not be the best people overall when it comes to building finished products.

I also interviewed at google, in the in-person all of the algos I got were very fair in my opinion, in that it took a little bit of thought to figure out what I needed to do, and then after that, most of the work was just turning that idea into an algorithm. It was all on the whiteboard but I thought it was fair. They were fine with little errors and we talked through them.

On the phone interview I was asked how to something I had no idea how to do. I have no idea how I passed the phone interview.

Seems like a mixed bag, the question as far as I know is completely up to the interviewer, which makes the interview very subjective when they don't use a normal question.

I don't think there would be too much correlation between CS degree and ability to answer that question. There are lots of CS degree programs that don't deliver such low level instruction, and there are plenty of people without CS degrees who can answer that question because they were curious about how computers work or have been exposed to low level programming.

>A false dichotomy

It's not a false dichotomy because I am not suggesting that both skills are mutually exclusive. I'm highlighting some personal experiences where I've seen one skill is vastly overvalued compared to another.

>Managing complexity is a valuable skill that should also be screened for at interview

I've never been part of an interview, on either side, where I've seen testing for managing software complexity. Good interfaces, function design, side effects, state management, etc, are all second class citizens to finding the appropriate algorithm to solve the interview question. I've seen it over and over. The only time I've been close to a complexity management question was on a systems design question, but even then, it was only a very high-level systems discussion. I don't think most places know how to screen for it.

Most workers in the US are under the "at will" regime: they can be let go at any time in theory. In practice, companies (especially big ones) usually try to "build a case" to justify the move.

The pressures of this kind of interview have very little in common with the pressures of the job.

It's not that I can't perform under stress. It's that I can't perform under the specific stress of being in a new location having 5 hour one on one interviews because I have Aspergers

If you can't handle stress, you can't join an oncall rotation, which would have ruled out eleven years of my career so far.

I think he was being facetious. :-)

hehe. however, if you look at this. do you think this is a server engineer or a client engineer ? :D

I'm pretty sure it will fail NULL if overcommit is disabled.

(And apparently other conditions: https://stackoverflow.com/questions/2248995/is-there-a-need-... )

If I were asked that, I would say something like "malloc attempts to allocate some memory on the heap and return a pointer to it." If pressed for more details, I would say it depends on the allocator and that we should look at the documentation for it to find out.

If that was an unacceptable answer, then I'd consider the interview a waste of time.

well a sane answer would be that it returns a void* ptr to the allocated memory that can be casted to the needed ptr type.

We had pairing stations, so usually sat at 90 degrees. Each person gets their own desk, monitor, keyboard and mouse. Also this company was huge on pairing, so it was also an indicator of what working there would be like.

To make it clear, I absolutely hate coding interviews that makes candidate lose so much time restudying. I think having some critical-thinking is absolutely needed and way too many engineers lack some (especially those swallowed into FANGs)

What I described on my previous post is a credible explanation that my group of engineer friends came up with on why all the FANG companies pursue those heavy memorization algorithmic interviews.

Well, some folks would brag about their score (years ago, dunno about now) and use that ranking as an indicator of their coding prowess. When I learned that the whole thing was easy to 'cheat' (whatever that mean in this context), then that rank lost all prestige for me.

What has it become?

I had a coding test once where I was given someone else's code with an introduced bug, and I had to fix the bug. To do so, you were basically documenting the code along the way as you traced your way through possible trouble spots. It felt far more meaningful than the typical "implement some list traversal algorithm that you won't actually ever use at this job."

A lot of people are sour at FB/Google simply because how the companies represent themselves to the users. I can't look at Google/FB without bringing up gmail, maps, search etc. and their utmost desire to track every nanosecond of my life, and understand me better than I do... just to earn money from me. I couldn't care less about hiring processes there, since where I live they don't pay more than other businesses, and everybody knows how 'great' their hiring experience is.

With ie banks, they are at least honest about how they earn from customers like me and I don't have any unreasonable moral expectations.

My comment wasn't trying to ridicule anyone, but explain that big companies with an extremely large amount of coders need a very specific type of heads down personalities. As can be seen in this whole thread, plenty of people simply don't have a desire to work at big FANG companies, and even less desire to study multiple days//weeks for an interview that doesn't really help their day to day job.

>it seems to be fueled by the fact that people feel a sort of inferiority complex when they don't clear an interview or they feel they wouldn't be able to crack it if they ever gave it a shot

Some of the most talented people I've ever met have failed Google interviews. As in far, far more talented than the majority of folks I know who do work at google. No amount of bullshitting is going to convince me that Google's False Negative interviewing system is the correct one. It simply bypasses too many talented candidates even beyond the reasons generally mentioned above.

One guy in particular I know is now a CEO of a company which, ironically enough, employs several former googlers. Yes, I know Google doesn't give a shit they missed on this individual. But to mis-characterize the anti-Google-interview narrative as "sour grapes" sounds a bit like you're drinking their champagne.

I think it's possible for both things to be true at the same time. Yes it's a selective meritocracy, and it's also true that the process unnecessarily alienates people. It comes down to recruiters being given the very difficult task of finding candidates for a process with such a high rejection rate, and the added stress of being given very specific rules about the things you can't be transparent about. The overwhelming majority of job seekers are mature adults who can handle rejection and constructive negative feedback. It's the sense of having wasted one's time that generates the "sour grapes" feeling.

I have no idea whether I could study hard enough to work at Google. What I do know is that I don’t like large companies and I have no desire to move to the west coast.

>You can study lots of vocabulary to achieve better results on the verbal section of the GRE or similar tests. But afterwards, you will, in fact, have better vocabulary, I submit.

Yeah, but tests like the GRE claim to predict academic performance, not vocabulary. So unless you think augmenting one's vocabulary alone will make one a substantially better student, there's still a gap there.

Oh, you'll certainly be better at solving programming puzzles type of problems, but the thing is that those questions usually don't translate well into real-life problems that you'll encounter at work later. You can't architect a good solution IRL by trying to figure our what the test author wanted you to do, like with programming puzzles. And for implementing some algorithm keeping every detail of it in head definitely helps, but it's not a significant advantage over someone who just googled all those details 10 minutes ago. So both types of tests are not testing the real dev capabilities, they test how much they prepared for the test. IMO only tasking the candidate to build some real piece of software or even better refactor some real code, with enough time and full access to google and stack overflow, and being fully able to ask other people for suggestions & help will show you the realistic picture of the candidate's future performance as a part of the dev team. Put them in a real situation and give them the real type of problems, and you'll get the real results. Everything else is like giving sudoku tests hoping to choose the best mathematician.

> You can study lots of vocabulary to achieve better results on the verbal section of the GRE or similar tests. But afterwards, you will, in fact, have better vocabulary, I submit.

Maybe for a few days after the test anyways. And then...you push out those words you never use or read to make room for actual useful stuff.

Agreed and Knuth's Literate Programming. Our industry is caught in the event horizon of the black hole named, "cargo cults".

I took math as part of my engineering degree. And that was 30 years ago. The older I get the more I think the way it was taught was terrible. Same reason I think teachers are bitching about the US's fetish for academic testing. Testing pressures teachers to teach students to mechanically solve problems. But with shallow understanding.

Given the name of the site (I've never used it), I always assumed it was about proving your ability to others (like maybe future employers). Easily-found answers totally destroys the trust that's needed for such a thing to work.

Triplebyte sounds like a bad girlfriend.

When she says "don't worry about it" or "that's fine", you can't take her word for it.

You need to be psychic and understand her needs without her saying anything.

Thank you. I will definitely be coming back. I guess I have difficulty formulating a DP problem properly.

Not so much intelligence but applied diligence on top of intelligence is my sense. If you want what they’re offering and don’t want to jump through their hoops for it then they don’t want you. For those that ball at the hoop jumping as being beneath them, there’s probably additional characteristics that comes with that that they’re trying to filter out.

Given that many job applicants apparently can't write a Fizz-Buzz implementation, I'd say that being able to implement an algorithm is probably a reasonable way to cull the herd by a hefty margin.

https://blog.codinghorror.com/why-cant-programmers-program/

There's a correlation between the belief that memorizing algorithms correlates with intelligence and the application of algorithm questions in interviews.

I received a cold call from a Lyft recruiter recently for a senior machine learning position. I asked why they were reaching out to me and the recruiter mentioned that it’s an especially hard time to locate experienced machine learning candidates, they don’t have enough applicants.

I said I was interested in interviewing but that I would only agree to a process that evaluates me based on my previous work history, and not any onsite or takehome coding projects, system design questions or whiteboard coding questions.

The recruiter said she would run it by the manager, but thought it would not be possible, and a few days later I got a rejection email.

There are more interesting things to do. Coding your side project, contributing to the opensource project, learning a new programming language or even reading random GitHub project code and issue trackers. All of these activities help to improve your programming skills more than leetcode. If I am making max for my local area and I am not willing to relocate, why would I waste time for interview preparation?

CS is way too big for any individual to know it all in depth. If it really is a “safe place” because the employees can talk about complex topics without ever losing anyone, that would imply that they’re all specialized in roughly the same topics and severely lack organizational breadth. I kind of doubt that’s really true.

One of the most valuable skills for any engineer is to be able to frankly admit the need to look something up.

Do you work for google? This seems naive and inaccurate to my work experience, both in Tech and in Medical devices

Print numbers from 1 to 100, except print Fizz for numbers evenly divisible by 3, print Buzz for numbers evenly divisible by 5, and print FizzBuzz for numbers divisible by both 3 and 5.

Probing someone with very technical conversation about past technical projects is a much stronger filter to prevent unqualified candidates than passing CoderPad tests, whiteboard algorithms, etc.

The conditional probability you are hopelessly lacking software skills to do a job given that you nonetheless passed a TripleByte exam or something is quite high. Overfitting & memorization for the sake of the test is extremely common.

But it’s much, much harder to fake competence when needing to dynamically and verbally explain technical details in a conversational interview about past work experience.

We convinced our parents to buy a computer because it would help our education when all we really wanted one for was playing computer games. Joke was on us though, because playing computer games at the time usually involved a lot of putzing around and figuring out how stuff worked, ultimately teaching us marketable skills.

Without a doubt it's age discrimination...you've hit the nail on the head. Also, God help you if you have followed a non-traditional career path where you decide at points in your life that you wanted a break from it all.

I, too, in 1988, fresh out of my BS in CP with no family or life experiences and a strong desire to code day and night would have sailed past the technical side of these often ridiculous interviews for jobs I could literally do in my sleep now.

But now, at 53, not only has Father Time fucked with my ability to sight memorize (something I took totally for granted in my younger years) without even trying, I find it almost impossible to hide my frustration at the ridiculousness of the very idea that I would be unable to do the work required of me for the job...

"Ok..we really need someone to fix X and Y on this website, and it would be just great if they could reconfigure Z on the server..." "Well, sure...I first saw X and Y-like issues back in the mid-90s in a networked client-server environment and I did X(x) and Y(x) to fix it, and again saw it in the mid-00s under the LAMP-stack and again fixed it doing X'(x) and Y'(x)...and the server issue is something I've seen over and over again during my 30y+ career..I am 100% certain I can solve these relatively simple issues for you guys..." "Oh...yeah ok...so can you whiteboard a bubblesort in Javascript for us? You have 15 minutes." "???"

...and of course I don't get a callback. Do people think I'm lying about all my experience on my resume or what exactly?

It's at the level of life and death for me right now, to be honest. I've been shooting out resume after resume for the past month, and nothing good is happening.

All I know for certain is...if the real issue was truly about finding someone who can do the job and fix the problems, there is no way in hell I'd still be looking now.

By accident or design, the "coding tests" seem to discriminate in favor of new grads (with CS 101 fresh in mind, and also willing to grind yet more artificial test-taking prep), and also have a component of hazing/negging, especially when administered to experienced people. (Asserting an imbalanced power dynamic from the start, and perhaps also exploiting a psych weakness, like "I'm jumping through hoops for this, so this must be worth jumping through hoops for." I'm sure most individual interviewers are of goodwill, and don't intend this, but that doesn't mean it's not present.)

Lately, I decline to interview with any company that requires new-grad coding tests for experienced people (especially if they require it even when the person has open source code and community participation that the company can look at). I usually do well, but even then, it leaves a bad taste.

Of course, I'm very happy to talk each other's ears off in energetic collegial discussions about engineering problems and technologies, including whiteboard brainstorming of approaches/algorithms, perhaps much like would be a part of everyday work. If anyone ever then interrupted, "Hold on, can you put in all the semicolons, so I can type it in, and make sure you know how to code," you might wonder how that's not already obvious to them, and where they're coming from.

This aversion to "coding tests" for experienced people seems to be more acceptable to small companies/startups (or small autonomous units in large orgs), than it is to less-flexible/agile large companies. Recently, after discussing my latest background with a nice FAANG recruiter, we had a good discussion about the company's practice of putting experienced people through what seemed like a new-grad vetting/hazing process, and why that's been a turn-off. They soon sent a followup email, including a quote from an engineer there saying "... I need to know whether you can code in a language," along with attachments on how to prep for their new-grad coding tests. :) For whatever reason the company insists on that process, it seemed like it probably wasn't on track to a professional relationship that I'd want.

I'm envious of you. I had no restrictions on technology use, growing up. I dropped out of high school at 16 and spent the next 15 years doing very little of note (with video games consuming the bulk of that time). Now I'm 35, struggling through my undergrad, and surrounded by kids.

I have some ideas about where to go from here but it's not going to be easy. The search for real meaning and really meaningful relationships is ongoing.

I spent so many years yearning. It was so unfair that all of the other kids had Pentium computers at home, and all I had was an old 386. My parent's refused to get me a game console, or cable tv. I was SO BORED, in my desperation, I tried making games in QuickBASIC.

I still think my parent's should not have gone so Amish, but I also don't think I would have developed as a programmer without that.

If it makes you feel any better, even many of those who had that seed watered still feel lost in life :)

I had zero games for my VIC-20. It was strictly a BASIC machine. (Later I had a TI-99/4A which had a few.) My dad is a kind of super-polymath, and in the early 80s he bought a computer and learned how to use and program it so he could grind out solutions to mechanical-engineering equations. He saw me become hooked on BASIC and went down to Crazy Eddie's to pick up the VIC for me so I wouldn't bother him on his rather expensive machine.

The personal computer grew up alongside us xennials, and some of us were just drawn to it, even without the promise of video games.

Totally true.

In my case it was a natural progression: "videogames are great!" -> "I have an idea for even better videogame!" -> "how do I make one?" -> "can I tweak this one into being a bit more the way I like it?" -> tinkering around data files -> "I really want to make my own game" -> picking up a programming book at 13 -> a programming career.

This is such an important observation. Claims of limited talent pool don't align with reality. If demand were truly inelastic, companies would negotiate.

They have kids. Developing a sentient being is a higher priority and more difficult than developing React Redux.

I don't think you need to be over 50 to realize there's more to life. Some demographics are less likely to live to work v. working to live. Some demographics may not have time to juggle interview grinding with other responsibilities (children, existing job(s), etc.)

For a non-age-related one:

It's a lot more socially acceptable for members of one sex than it is for members of the other to be too busy with career stuff to spare much time for their families.

On a somewhat related note, single parents simply aren't going to have that kind of time.

People who have other responsibilities have less time to grind - and those other responsibilities fall more heavily to under-represented folks. Consider things like taking care of children (including siblings), elder parents, and other household work.

Humans are social creatures; we can't live on code alone.

If you come from an underrepresented demographic or have interests or social preferences outside the mainstream of the profession, it will be harder to fulfill your need for social affiliation by participating in communities like HackerRank in your free time-- because it may be harder to find people who share your values, and that you can identify with on a social level.

In other words: the social component of "grinding" is more fulfilling for some demographics than others.

People from some demographics are less likely to have the option to spend all their time grinding. Spending all your time grinding means that you don't need to work toward supporting yourself or others.

> The only demographic division that I can think of that would reduce someone's willingness to abandon their personal life would be age.

I can think of a few others tied to national work culture.

Well, kids, family obligations and any other non-work related stressors that zap your free time.

I agree that any one of the questions could have been memorized, but it seems to me like it would take a year or two of constant memorization, like more than 8 hours a day, to get all of it, even assuming there was a place that had the relevant information conveniently formatted for memorization — which, as far as I know, there isn't. But maybe I'm just bad at memorizing things?

I note that you didn't answer my question. Have you taken the TripleByte exam or not?

Not having access to a powerful computer makes you appreciate the finer things in life, like hand-bumming instructions till your inner loop hits a hard deadline.

The teams specialize.

Spend a few years putting in 100-hour weeks writing collision detection for this year's Dora the Explorer game -- a typical game industry position -- and you will be thankful for the crud Java app job.

> Rather: I work for you to finance the really important things in my life.

> You work to live, not the other way around.

At least if you work in (academic) research, working to live simply does not work [pun intended]. The things that you work on in this area are the really important things in life.

IQ tests are a form of convergent preferential bias and they don’t test for abstraction or creativity which is more than half the definition of intelligence.

Which is illegal to do, hence proxy IQ tests.

Hmm. Y'know, that's a great point. I could build a whole conspiracy theory off of that idea:

If I'm a FAANG, I'm simply not using my normal interview process to hire for the really interesting jobs. I reserve those ones for people who got the job by virtue of their publication history in the academic literature, or because they built some well-known cool thing, or because they got promoted into the position. Those people get shunted over into the "you didn't come to us, we came to you" interview process.

The seats I'm looking to fill with the more public interview process are mostly seats for the grunt coders who work under those people. My ideal candidate for that position isn't some rock star creative genius; it's a workaholic who is resistant to boredom. And what's something a workaholic who's resistant to boredom would be really good at? Grinding away on programming interview questions, of course.

This is exactly what it is. Which Frat house do you want into? Google? FB? Microsoft? Amazon?

It's quite frustrating, I've submitted my portfolio of open source projects on GitHub for interviews. I specifically told the recruiters, HR personnel, hiring managers and some of the developers that the projects contain a large enough body of work to see examples of my code. These projects are quite comprehensive and not one person looked at them or mentioned them during the interviews.

Unfortunately, people in general rarely try to first understand what the candidate offers. It's more often ONLY about whether candidates uunderstand the exact way the company uses certain technology.

This is also my experience interviewing for embedded systems and (hardware) test automation work at electronics manufacturers. I've never been asked to code anything. (Nor have I been asked to draw any schematics.) Just conversation.

> “The SV companies must have a good reason for this”

In fact, no, nobody has a good reason for it.

> but once a child is born their parents have an ethical obligation to their children.

Indeed - and that is why you should be very cautious to give birth to children; in particular if you have career plans.

It's not readily apparent to my that those two abilities should be distinct. It seems plenty likely that they would be at least highly correlated. While you're point about the visual cortex may be relevant, I don't think that's the whole story.

My understanding is that different IQ tests will rely on different kinds of questions (i.e. not all involve visual shapes; some involve word/logic puzzles). The point the scores for all IQ tests correlate very highly (and thus suggest that there exists some common factor).

So the sooner they abandon all of their own priorities and instead adopt only yours, the better?

Can you provide a link for divergent aptitude tests? I'm afraid my search results all have to do with some young-adult fiction novel (called Divergent).

How much do such tests correlate with things like (for example) creative achievement?

>I’m sorry but you cannot do what you are claiming.

But I have. Not in the specific context of a job interview, but I have absolutely convinced technical experts that my level of expertise in a field is above my actual level of expertise. Ironically, if this were a technical interview, I'd fail it, not because I lack the skills to convince technical experts of my non-existent abilities, but because you don't find me trustworthy.

>The point is to recursively keep probing for deeper technical specifics, so they have to explain at finer and finer technical levels what were the tradeoffs, why exactly were certain decisions made or how were certain problems overcome.

But without context, you can't effectively do that. I, the candidate, am in control. I can steer the conversation to avoid areas where I don't have expertise by answering all kinds of things: "investigating that was someone else's responsibility", "well we never tried anything else and our current implementation works well enough that we never needed to", etc. You can't know if those are lies or not. There are all kinds of completely valid non-technical reasons for decisions that may be completely outside of a candidate's control.

You're either forced to completely trust the candidate, or attempt to verify their authenticity during the interview, at which point you quickly venture into the land of bias and subjectivity.

Knowing the existence of, and understanding the performance characteristics of a broad range of algorithms is, to my mind, a much more useful set of working knowledge than the details of any individual algorithm. The latter can always be looked up. It is harder to find out the former and much better to say “yes, there is an algorithm such-and-such that may be applicable here, let me spend 5 minutes checking that.” In my experience, anyway.

>testing whether someone is willing to prepare for a thing is a relevant work skill test too.

Is it, though? I could understand if algo questions had some relation to the work you're doing, but your comment on why they're good is independent of the actual material. If we replaced the algorithm question interview with an interview testing obscure presidential facts, would it really be a useful test to have devs take? I guess it is a relevant work skill test in that you get people willing to put the work in/game the system, but it doesn't seem to be much of (if at all) an improvement from ad hoc conversations.

There’s a vast difference between, say, preparing for a school exam and preparing for a job interview. In the former, you know in advance what material will be tested. Job interviews are more like PhD comprehensive exams, or professional licensing exams. I know a lot of working professionals who are good at their jobs, yet admit they wouldn’t be able to pass the license exam today.

Go search for "Knights on a Keypad" (a formerly-common Google interview question). Trying to imagine any situation in which the solution would be useful is harder than the problem itself.

So you are saying that companies are hiring people that are willing to prove that they can put "a lot of work" into preparing for interviews that have no relevance to the actual work? I can see that as a valid point, as a way to filter lazy individuals. (In the same way that a college degree is more a way to prove that you can sustain X years of learning things without dropping out).

But it will also filter out everyone that is opinionated enough to not do that stupid preparation work, and you will end up with sheep coders that will always follow the rules. Looking at Google, Facebook etc, this might already be the case. I will even go so far to say that they prefer those type of obedient coders than the ones that ask too many questions and get too creative.

There seems to be an assumption in these discussions that everyone has to prepare for these things in equal amount. But that's not the case.

(The counter to that is that if people can relatively-easily (single-digit days) cram for your interview, you're still not going to be effectively screening for at-hand pre-existing familiarity/knowledge.)

What about using a real job related task. If they can do that they probably can do the job.

The elephant in the room is that it's a surrogate for an IQ test, since those are illegal.

App Academy was working on something like this, last time I checked. I believe it's more focused on people who've already been through their program working on getting the next-step-up job from their first so I don't know if it's generally advertised/ available

The only way I would consider paying for a course like this is if, upon successfully completing it, I would not have to do the technical portion of the interview at companies I applied to. They would accept this cert and just do the soft skills interview.

The major ones seem to be Outco and Interview Kickstart. But agreed, there's far fewer whiteboarding/interview process-specific bootcamps compared to web/mobile bootcamps.

> If this isn’t part of lambda school already I think it should be

It’s part of classes for our existing students, but it isn’t a single offering. One day.

Those courses are out there. I saw one for $5k and ran for, IIRC, 8 weeks, that covered the entire interview process.

This is exactly what Outco.io does, and I highly recommend them for this purpose.

> On the other hand, I genuinely do feel theory is really important. While not knowing the minutia of a tim-sort doesn't indicate that you'll be a bad engineer, not knowing the runtime efficiency of a sort can lead to some really awful code. Not knowing when to use a hash table instead of a nested-for loop can be a sign that you don't really know what you're doing, and not knowing some rough theory on concurrency indicates that I might be stuck debugging your race conditions or deadlock.

Theory is important but what's more important is how someone applies the theory to actual problem solving.

Reversing a binary tree isn't testing your knowledge of theory as much as it's really just testing memorization of a very very specific application. Knowing how to reverse a binary tree or how a hash map works is pointless if the person can't identify when to use them when solving an actual higher level problem. No one is ever given a binary tree and told to reverse it in the real world, they are given a business problem that you identify can be solved efficiently by modelling it as a binary tree and reversing it.

I'd bet most of the good people who fail the "reverse a binary tree" type of questions would succeed if you give them a realistic problem to solve without forcing a very specific solution onto them. Either they will come up to the realization that the solution is to think of the problem in terms of binary tree or they won't.

And neither is a terribly bad answer either. If they recognize you gave them a problem that can be represented as a binary tree and efficiently solved by reversing it then there you go, not only did you prove they knew the "theory" but they knew how to apply it as well. If they don't recognize it you gain valuable insight into their line of thinking and they might find novel ways to represent the problem and apply other theoretical concepts that solve it efficiently (maybe more maybe less).

Wow, this is an incredible answer from Max on Quora as well: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

You didn’t read the opinion and you added the word “directly” to the summary.

Do you scan source code and draw firm conclusions about what it does based on skim reading the first comment you see?

Perhaps my old contracts prof could have a second career as a google interviewer. (He was notorious for cold calling people that hadn’t briefed their cases and eating them alive.)

The gp actually just said what it said; in response to "They have kids. Developing a sentient being is a higher priority", that probably means "raising kids is just another hobby" - not a judgment of whether hobbies or a job should take priority. I.e. that him saying "developing a sentient being has higher priority..." is about the same as someone else saying "my creative hat-making has higher priority...". Sure, that may be true for many people. But given two otherwise roughly equivalent candidates with W>L and L>W priorities, why would a company choose the latter?

If work is everything, shouldn't we set aside some time to raise the next generation of workers? Working all the time is so defeating it even defeats the amount of work being done 30 years from now.

These same employers (famously) had a cartel that prohibited job hopping before - the Jobs/Schmidt email - so it’s not surprising that the system would trend toward the same equilibrium again.

Time spent by a new employee learning the ropes is time wasted from the perspective of an individual employer-actor. On the surface, it sounds similar enough to the iterated prisoner's dilemma so I'm inclined to think that a greedy strategy would do poorly here.

> On the other hand, I genuinely do feel theory is really important. While not knowing the minutia of a tim-sort doesn't indicate that you'll be a bad engineer, not knowing the runtime efficiency of a sort can lead to some really awful code.

OK but why don’t these interviewers ever ask “internals” questions? How does a CPU works, or what the different levels of memory hierarchy are, what an interrupt request is, what is pipelining, what is SIMD, what is a GPU, etc. Or how about compiler internals, what are the different stages in a compilers, what are the different grammars and parsers, what is an AST, what is interpretation, compilation, bytecode, JIT, and how does it work? How about database internals? How is a database implemented, what is relational algebra, what is normalization, what is a data model, how do indices work? Similar questions can be asked about operating system internals, networking, floating point arithmetic, etc. In my experience, no interviewer has ever asked me these questions. And as an interviewer, I have consistently been disappointed with candidates’ inability to answer basic and relevant “internals” questions. Ironically, the algorithms and data structures questions that are commonly asked in interviews are outdated ways of thinking which do not take the underlying hardware reality into account (memory hierarchy and parallelism). It could be because a lot of these FANG(-like) “engineers” are themselves not knowledgeable to ask such questions. Or they are aware that new comp sci graduates are unlikely to really understand anything at a deep level, but all comp sci students are drilled on algorithms and data structures. If you are targeting a very specific age group (0-5 years experience) and want a standardized test then I guess asking CS201 exam questions in a job interview make sense. Companies prefer the 0-5yrs experience segment because they’re cheap, don’t have children, are easy to exploit, and they are easier to “mold” into your corporate culture.

I think the important thing here is the difference between understanding complexity and implementing a sorting algorithm.

If I were hiring a carpenter I would want to know they understand their tools and when to use them. I don't care if they don't know how to make them. But of course knowing how to make them suggests an intimate appreciation for the craft (looking your way Matthias Wandel)

> On the other hand, I genuinely do feel theory is really important.

My beef with this in interviewing is that a huge chunk of modern programming work is developing UIs - and user interface theory and skills are treated like some softball thing. You ask UI-related questions to interviewers and half the time you get some shrug "oh we use whatever", etc.

> Not knowing when to use a hash table instead of a nested-for loop

On the flip side, the O(1) look-up nature of hash tables make them the no-brainer data structure to use, at least for passing programming interviews. Perhaps more interesting test questions would be when not to use hash tables.

I'd be curious to see if there is any value in questions that focus on understanding of the basic ideas behind algorithms and data structures as a subject. Time complexity, sure, but what I would really want to know is, given a description of a data structure and some algorithms for manipulating it, can you identify the invariants that should be true of these rules?

That sort of thing might give a better sense of if someone has an instinct for how to verify whether the code is working. And, by extension, if they have a grasp of some concepts that go a long way toward helping a person come up with more reliable and maintainable designs.

Obviously I do not think that is false; you can get sued for literally anything. Do I think you would lose? Depends on whether you've done the research showing that 135 is an important cut-off.

To turn this around, can you point at the law that makes IQ a protected class or whatever you're claiming it is? I'm not going to have much luck proving a negative - Russell's teapot and all that.

They may very well be, but is the quality of signal truly worse than that which an interviewer can extract from a few hours of your writing code on the board?

I am surprised B-trees were not the first data structure in that discussion, as they are "famous" for being used in DBs.

Although these days one should talk about "learned index structures" instead, I guess :)

> “I mean, yes you do. Context tells you which decisions are important.”

No, you definitely don’t need to come into it knowing about this, and even if you don’t know about this ahead of time, it won’t imply “just trusting” the candidate or being overly subjective. You will ask the candidate to explain why various decisions were important, and not stop at the top line answer but recursively probe into it, breaking it down into concepts and trade-offs that are universal in any kind of applied problem solving.

> “But now you're punishing someone for organizational things possibly beyond their control. If my job was to build a thing that made use of some blackbox algorithm, and John developed the algorithm, why should I put the algorithm under strong skepticism, perhaps that's how things work in your workplace, but there's no clear reason that mine work the same way.”

I’m sorry but this also just isn’t true. If you are describing your contributions to projects and all that keeps happening is you hit walls in your explanation where someome else did the work and you did not review that work at a high level of depth, then you’re just being misleading about your contributions at work.

Your job as an engineer in a company is to solve problems for your stakeholders, whether that means building tooling for other engineers, assisting designers with prototypes, designing algorithms for core product functionality, sales engineering for client stakeholders, etc.

It doesn’t matter how your company is structured, it doesn’t matter how the work was divided up. Your job is to know about the stakeholder problem you are solving, at a deep level, and when you represent your work to other people and you fail to offer technical depth about the trade-offs needed to solve stakeholder problems, that’s a clear mark against you as a candidate.

It’s bewildering to me that anyone would think that the way their current employer organizes assignments should reduce their burden of knowing how to represent their projects in significant technical depth. That is an always-on, never mitigated, constant responsibility for all employees anywhere. You’re not holding anything against someone if they can’t provide that in an interview... no, you’re just uncovering what they’ve lied about or embellished on a resume.

> “Except that, as I've literally just proven, you've failed to verify the authenticity of me because you've wrongly concluded that I'm not authentic.”

I see no such proof at all, and the cheeky rhetoric just makes me feel more entrenched that you are bullshitting hugely in this thread.

> “So again, either you take the candidate at face value in a situation where they have every incentive to lie to you, or you attempt to verify their authenticity, at which point that analysis is subject to a multitude of biases that have nothing to do with the candidates skill level.”

You are doing nothing but gainsaying here. You’ve made no argument that would support any of these strong conclusions, especially not any reason why this interview method faces the false dilemma between either just trusting the candidate or else succumbing to biases.

You are just asserting things, but they do not seem to be connected to or bolstered by any of the other things you’ve written.

Setting up the same problem in terms of trait matching for Rust is quite a bit more difficult than this toy problem when you're in a limited-duration interview setting. All of the time that you spend laying out the problem is time the candidate doesn't spend solving it, and time you spend not getting a signal. The simpler the problem setup the better, in my experience.

I've done the "ask a real problem that I've solved before" thing, and I find that it usually gets hung up on details and context around the problem to the detriment of actually solving the problem at hand. That's not to say that such a conversation isn't itself very valuable, but that's a different interview conversation, at least on my team. We find it important to maintain some level of focus just to ensure that we're covering the various signals that we'd like to get from the candidate.

Using an actual problem you solved can also work against the candidate because most problems we encounter in our daily jobs require a lot more time than the standard 45 minutes reserved for an interview (actually only 35 minutes out of 45 because there's 5 minutes of intro/icebreaker and 5 minutes reserved at the end to answer any of the candidate's questions).

So it isn't fair to ask the candidate to solve a real bug or implement a real feature in only 35 minutes unless they've seen something similar before.

This is why big companies like Google are limited to whiteboarding interviews because they need to have an interview process efficient enough to properly vet and filter >1 million applicants Google receives each year.

Personally, I think a better interview process is a pair-programming or work audition for a day. But that is not even close to matching the scale of Google.

Let's say out of a million applications, maybe only 25% are qualified. That is still almost 1000 candidates to interview per day (number of U.S. business days in 2019 is 261; 250,000 candidates / 261 business days = ~957 candidates per business day). Pair-programming or full day work audition will not be able to accommodate 957 candidates every day.