I bomb on technical interviews the same way because my mind just freezes and can't get through even simple problems.

I had the same question you mention. "This is a problem a paper was written on, are you expecting me to derive a whole paper from first principles in half an hour, or are you expecting me to have seen it before? If it's the latter, why not let me Google, as I normally would?"

I feel that saying "I would solve this problem with <algorithm>" should be good enough, and if I'm asked to implement it, I should be able to copy paste the Wikipedia pseudocode and start converting.

> I had the same question you mention. "This is a problem a paper was written on, are you expecting me to derive a whole paper from first principles in half an hour, or are you expecting me to have seen it before? If it's the latter, why not let me Google, as I normally would?"

> I feel that saying "I would solve this problem with <algorithm>" should be good enough, and if I'm asked to implement it, I should be able to copy paste the Wikipedia pseudocode and start converting.

Long ago, milo.com posted a challenge to codeeval.com (both websites now dead) which turned out to be an example of the "assignment problem". That is, given a set X, another set Y, and a payoff function f(x,y), assign each element y in Y to exactly one element x in X such that the total payoff from all assignments is maximized.

I tried to solve it, realized I didn't know how, and was eventually able to look up the solution in a couple of papers. There is an algorithm called "the Hungarian algorithm" which will do it.

So I wrote up the Hungarian algorithm and sent it in. This was good enough to get a phone interview with the company.

I tried to prepare for the screen by going over the Hungarian algorithm to the point that I could myself give the proof that it correctly solved the problem. This was fun. But in the phone interview, it was barely mentioned at all. According to the interviewer, I passed that step by just mentioning the name "Hungarian algorithm".

That's better than asking you to come up with the complete solution, but it's still a bit of a trivia question. On one hand, it's good to be able to recognize algorithms so you can look up their solutions instead of wasting your time on trying to reinvent them, on the other hand, how often are problems this algorithmic?

Maybe I've had a particularly depressing career, but 99% of it consisted of various ways of interacting with a database.

> That's better than asking you to come up with the complete solution, but it's still a bit of a trivia question.

How? You have unlimited time to find the answer; it happens before you make any contact with the company at all.

Oh, I misunderstood the situation, sorry. I thought it was on an interview.

Yeah, in certain circles the hard part is figuring out the solution is the assignment problem. Then you’re supposed to just know that the most commonly used algorithm for it is the Hungarian algorithm, maybe its complexity and that’s it, because you can find code for it in most languages and so you just need to call the function with appropriate inputs.

I had that exact same experience with milo.com. Small world.

Well, I found their challenge because they posted it to HN.

Everyone inside Milo seemed to think that their hiring process was hugely better than what happened elsewhere, including by producing better hires. But the approach -- set a difficult challenge instead of an easy challenge, such that, if someone passes the challenge, you will almost certainly hire them -- still seems to be vanishingly rare.

Oh, was that their logic? I don’t even recall if they actually interviewed me, despite passing their challenge. As I recall, I was rejected for not enough experience.

I find that hard to believe, since I was hired despite experience totalling less than a year of internship.

However, there might have been external reasons. I was hired after they were acquired by eBay, and apparently they had preexisting approval for a certain number of hires that year that they didn't end up meeting. If you were earlier or later (pretty likely!), maybe they might not have been so cavalier.

That could be. I could also be misremembering. In any case, I definitely wasn’t offered a job, despite solving the problem in exactly the same way you did.

I’m not complaining. Who knows? Getting rejected might have been for the best.

The funny thing about this is:

They're not looking for someone that is eager enough to show they're willing to work through it even though they have no idea to proceed.

They are looking for someone that got lucky enough to be ready to answer that particular problem, but won't stand up to them that the ask was a bit too much for a reasonable interview that is intended to see if you're a fit for the company and skilled enough to get the work done.

They aren't looking for someone that will dress them down to tell them that's incredibly insulting to ask something that took an academic a long time to come up with a solution for that. [Although a rough approach and fairly unfriendly. That shows a lack of desperation, confidence on the knowledge, and a good understanding of the difficulty of the task at hand (heck that's a good signal for won't underestimate points during planning)] (There's a singly linked list question that amazon used to ask that qualifies for this)

Exactly agreed, and because my inclination is to say "I've never used this in previous jobs and will never use it here", I don't think it's useful for me to be interviewing for jobs.

A friend of mine, when asked to implement an AVL tree, actually asked an interviewer when the last time he had to implement an AVL tree on the job was. He wasn't hired.

They must be willing to eat their own dog food or else the question won't make any sense for the interview.

The department should run the interviews through their own employees first. If some questions cause an "interview anti-loop" (a set of other employees S who would not hire E) it's time to revise those questions.

Revise and rehearse these practice interviews within the department, and do it blind, until all of S are willing to "hire" each other for their respective roles.

I've never had this prep for interviewing people.

Most of the time you see the resume a few days before. They may say a few things "don't say this don't say that". (hr)

Most companies take the rejection as a point of pride. "We've rejected 100s of candidates."

Asking you to visualise & manipulate a novel data structure you don't have practice with is a feature, not a bug. It's a specialised IQ test.

And what is asking you to reinvent on the spot an algorithm that took scientists years to come up with?

Very stupid, and shows the interviewers don't understand the point of the process either.

I don't like the structure, I think it's very flawed, but asking you to do something you do regularly defeats the purpose.

I don't think it's that complex. I think they're just cargo-culting. Technical interviews were designed to test certain things (brainpower, grasp of fundamental data structures) and not other things (workflow, ability to write out large volumes of trivial code). I think companies just copy that and don't realise what they're really testing for.

Don't forget, not only are they looking for someone who already just knows the answer, they frequently aren't hesitant to penalize someone who says "Fair warning: I've already seen this problem."

You're misunderstanding what they're trying to test. They're testing your raw ability to manipulate algorithmic structure in your head. It's important that you have to visualise the data structures and manipulate them without being able to look it up. It's an brainpower test, not a workflow test.

Which is fine if your job is really going to be centred around developing algorithmic software in a unique or high pressure way. The problem is most software engineering day jobs are nothing like this, so the test is not a good filter.

I always say that you aren't qualified to work on the hardest problems you can solve, so to check if someone can do the job you need to ask them to do something harder than you expect them to encounter. People who work at the edge of their ability makes tons of mistakes and are very slow, and it isn't very fun for them either.

It is the same as if you expect a warehouse worker to regularly lift 20kg then you don't test your hires if they can take 20kg at their best, because then you will get a lot of people who simply can't do the job for 8 hours a day. Instead you'd make sure they can lift 40 kg or so to ensure that lifting 20 kg regularly wont be a problem.

Yeah maybe, but these hardcore algorithmic "leetCode" things are like asking the warehouse worker to design a logistics system instead of seeing if they can carry 20kg boxes. The vast, vast majority of software jobs out there involve more soft skills (requirements, planning, scrum and other processes) and "plumbing" libraries/frameworks/data layers together than implementing algorithms from scratch. I'm not saying you'll never have to do it, but it's going to typically be a small proportion of your day job, so why test this stuff so much at interview stage?

The point is that designing an iteration that does something should be a trivial operation requiring no thought at all. If you can leetcode problems then we can be sure that you can do loops without effort, otherwise it might be that you struggle with them and as a programmer it will really hurt your productivity. Testing if you can do loops doesn't test if you can do loops easily, so we test something requiring a bit more thought.

Edit: And I think that you'll find that most leetcode problems are pretty easy if you are an expert at doing loops and recursions.

> I'm not saying you'll never have to do it, but it's going to typically be a small proportion of your day job, so why test this stuff so much at interview stage?

It isn't a small portion of your time spent at Google at least. Almost no engineers at Google ever talks to non technical people, product managers or engineering managers does that. Most engineers works to reduce cpu usage of backend servers or build scalable features for backend servers or similar stuff. Even high level decisions like deciding what service to use requires more engineering hours in time spent refactoring the thing than engineering hours spent deciding what to use, so there is much greater need for people who can code than people who can make decisions.

And if you argue that Google is bad at making new good products, that isn't the fault of their software engineers since they don't decide what to build. Instead it is the fault of VP's, and those don't do white boarding interviews.

I mean, I can see why they would want to test both. Horsepower is a good indicator.

So much agreement here. Who hasn't been rejected by some 25 year old who's been with the company all of 6 months and who asks silly questions straight from LeetCode? I have literally been asked questions that were PhD theses 30 years ago.

How is any of that supposed to be part of a good interview process? My only solace here is that those things are red flags on the company side, so I might have dodged some bullets.

Wouldn't it be a more balanced approach if the technical problem were presented on the spot to __all__ interview participants, not just the candidate?

It's a technical job, it must be a collaborative effort in finding solutions! Aren't we looking for a team member, not a lone-ninja.

Sure, the candidate has to be more vested in advancing the process, but the fact that there's no known-ahead answer would potentially surface not only technical skills, but also personal ones, and ... at both ends of the table.

Not to mention, the "house-experts" could find such sessions stimulating, to say the least... Imagine, you get back to your desk after interviewing a candidate, and your team mates ask you "so what was the tech problem this time?", "could you crack it?", "did he/she crack it?".

I like it. However, I have had an interviewer at a "top chicago tech place" (roll your eyes on that one) He basically did an inperson imitation of leetcode. Say problem, look at you. Don't give help when asked, stay emotionless.

Very intriguing idea. I’m thinking about how logistically this could actually work. It would build a sense of camaraderie as well.