The only job I've ever had to do any kind of test for wasn't leetcode - just a practical demonstation that I could write a basic CRUD app. Was actually a pretty good test to weed out people who were just completely useless.

I'm also finding that experience matters. It's just tough to get that across up front.

I think this is a totally reasonable way to weed out applicants, particularly if they allow you to do it during the interview time. I've been through several interviews (though, to be fair, they were well over 15 years ago, since that's how long I've been with my current employer) that used a similar exercise. One interviewer just sat me down at his workstation, and told me to build a quick crud with their tech stack (which, of course, I knew going in). Nothing was off-limits (web searches, etc).

I ask because as a startup founder, I would significantly prefer to try working with someone for 3 months instead of doing useless least-common-denominator interview questions. It's a bad fit, it's better to quickly part ways. But getting fired or asked to resign is a big emotional blow for many people, and I'm not sure if they would rather face that than the Leetcode grind.

I'm fairly confident in my ability to deliver value in the first couple of weeks on a project, so would much prefer this to having to spend time grinding leetcode puzzles that I'm not innately good at.

Note: a large part of this perspective is the privilege of feeling like I could get another job pretty easily, and having a sizeable emergency fund that I could draw from to continue the search if things didn't work out. So you may be filtering out people who are not in such a fortunate position.

As this is a normal contractual regulation there is almost no risk of any legal trouble (usually).

On the other hand side as soon as this trail period ends all the German workplace protection regulations start to apply in case of permanent employment contracts. So after the trail period ended it gets quite difficult for an employer to get rid of an employee.

But all in all that's pretty fair, imho. After a half year you quite surely know whether you like the workplace, or form the other perspective, the employee.

Because there is a difference between writing FizzBuzz and solving one of those dynamic programming problems that are so common in competitive programming. For the former, I am surprised you can even work without being able to to this, for the latter, you pretty much need special training that is not very useful in most professional settings.

I never took a leetcode style interview so I don't know what is generally expected. If you are expected to do hard problems, it doesn't test much besides your leetcode skills. But easy problems look like a pretty good filter, assuming the stress of the interview isn't blocking you, which is another problem.

IMHO I believe the right approach is to either ask from a standard bucket of questions that require preparation and advertise which ones to candidates, or not ask them at all. Asking "only a few really easy ones" is becoming a red flag to me.

And what are you testing than? Whether someone can memorize things?

Even though I'm not good at memorizing things every second monkey out there is.

Actually, people relying mostly on memorization for "problem solving" aren't very intelligent in my experience.

Especially in software development you don't want people who can mostly only reproduce things once learned by heart!

No two problem instances are exactly the same. It's all about the context! What is the recommended text-book solution in one case could be the most stupid thing you could probably do in another superficially "similar" case. You want people being able to recognize the difference and act accordingly.

(Of course you need some amount of drones in every company. Especially when your company is big. Not everything needs highly skilled and highly intelligent employees. Also there is only a given amount of adequate people available at all. If you're big you can't be too picky if you want to hire enough staff in a reasonable time frame. But those are problems of really large organizations).

But what if too many people pass those filters?

Then we move onto mediums.

But what if too many people solve those?

And that is how we reached the current state of interviews.

* I confirm that day to day business problems rarely are the sort of problems you find on Leetcode.

* I might ask similar questions in interview. I don't expect the candidate to solve them. As a matter of facts, I don't care if the candidate actually solves them or not. I am observing how the candidate behaves in front of a difficult problem. Will they freeze? Will they jump head in the code? Can they articulate their thoughts and think analytically about it? Can they think on the spot if I challenge their approach? Are they comfortable saying "I don't know"? This sort of things.

In my book, being a "good engineer" is much more about communication, collaboration, familiarity with git/sourcecontrol, clarity of commit messages, pertinent emails, being reliable, being resourceful, etc.

Good grasp of algo is a big plus, of course, but it's not something that all the best engineers excel at.

So what if they freeze during those 45 minutes? How representative is that scenario for what most devs do?

Also, most problems are not solved in the 45 minutes and in day to day coding , we generally have a minimum of day to think on the problem and solve it without people looking over our shoulder, google or ask someone :)

And presumably fail said interviews because they froze. Usually "I think I need to think about this for a while, or maybe even sleep on it" isn't the answer that the interviewer requires.

As you note, it's normal to need more than 45 minutes to think about a problem that you haven't seen before. Many leetcode type problems puzzled eminent computer scientists and/or algorists/mathematicians for years before they were solved.

Then there's the psychological aspect of when interviewers try to "help" you by asking questions, providing clues or even the specific clever (or stupid) trick needed to solve the algorithm puzzle but really you're in no condition to understand the hints they might be providing.

If a candidate freezes for 45 minutes in a 45 minute interview, they won't get the job.

... Right?

Clearly thinking on your feet in front of people is what it means to be good at ones profession.

And yes, if I ask you a technical question and you freeze, I don't want you on my team. It doesn't mean you're a bad engineer. It means you're not a good fit.

Pretty much sums up how the hiring process is a gamble. So if you don't like somebody and they could be an asset to the company you would not hire them?

Don't undersell yourself, you ARE able to do them, maybe with some practice, like putting some basic algorithms implementation into your muscle memory.

Doubtfully it'll make you a better developer though.

Anyway, the most important skill for FAANG interviews is ability to write code on a whiteboard with a dried out marker.

The reality is that if this person's life really did depend on it, for example they lost their job and they have bills they need to pay or a family they are responsible for taking care of, then they almost certainly could put in the effort to brush up on their skills and get to a point where they could do leetcode easy or leetcode mediums in a matter of weeks or a month at most.

It's along the lines of an MIT grad saying that where you go to school doesn't matter or a rich person saying that money doesn't make you happy, or even the myth that Einstein failed at math. These statements that espouse a false sense of modesty have great appeal and they likely come from good intentions, but ultimately they give people bad ideas about what it takes to be a fairly competent developer.

This would be a good April Fools ecommerce site. "Dried out markers! Guaranteed to land you a job!"

For OP, I read your post and the post you linked from 9 months ago. It sounds like you two have fairly different backgrounds and experiences. The other poster said they had only worked for 1.5 years before getting fired at a first job, and then spent time leetcoding. 1.5 years is a short time for a person to be able to learn how to effectively work in a grown-up world after school/college. In fact, I had a similar experience at my first job (I didn't get fired, but I was getting below-average performance reviews and I left on my own), also for about 1.5 years. It wasn't until later I learned what matters, what to do and what not to do at a job, and then excelled.

For you, it sounds like you've already learned it, evident from the fact that you had 4 years at a real job with a senior title, proving that you can do it well. It sounds like your issue is more around finding meaningful work, having a disdain for the current trends of agile, react, CRUD apps, etc. which isn't uncommon. I think there are other solutions to what you're facing, and leetcode isn't it.

For me, the key has always been working in an industry I'm truly interested in, then I can dive deep into the business domain knowledge. I'm a very senior level engineer and I'm good at it but at the end of the day the code is still just a tool to me. I don't really care if architectures are tried and boring, I just want to make business impact and build products. Maybe it's the same for you, maybe not. The key is finding what matters for you, and not care about parts that don't matter.

Off the top of my head, React uses lots of graphs and trees to render stuff.

Also there is almost never a reason to implement such things yourself—even when you need the algos—as there are libs for that! (Imho one of the biggest signs of incompetence is when someone starts to reinvent the wheel! That's an absolute no-go. And the truth is: If you're not in academia doing research all the wheels you ever need are already invented).

A valid test for a candidate would be whether he/she is able to google for an algo and pick the correct code form the results.

Such a test would be good enough as a lot of bad candidates would fail as they wouldn't google but start to "solve" things on their own; the other bad ones wouldn't be able to pick the right solution at all—because they don't know what they should look for in the end.

I believe you and others when they claim they are good developers. I just want to point out that for many people, it can be impossible to understand how your minds work.

Maybe it is a bit like dyscalculia, where some people can not comprehend "amounts". They can not calculate well, but they can actually be good in other fields of mathematics.

Edit: I never did a lot of leetcode, but for reference, here is a problem they categorize as "hard": https://leetcode.com/problems/median-of-two-sorted-arrays/

It requires calculating the median of an array. Is that really a kind of thing people who are otherwise good developers can not do? I must admit it really boggles my mind and makes me a bit hopeless and desperate. It seems all attempts to explain stuff to people are futile anyway, at least for some things.

There's a huge meta-game around these questions that you pick up after practicing them enough.

Even without the hint, I intuitively know looking at that question that linear time is too easy for a 1 hour face to face interview at Google.

I also know that as the data is sorted the optimal solution must be logarithmic, as in these contrived problems there's no such thing as an unnecessary detail. Monotonic means binary search.

I haven't built this intuition from my experience as a software developer, but by spending my free time playing the game and grinding these arbitrary puzzles.

The fact you missed this meta, tells me absolutely nothing about your skills as a developer, only that you haven't been grinding leetcode.

That shouldn't be a signal not to hire you, but that's how the game works at FAANG.

If you can make this observation about the arrays, and code a fully functional binary search taking into account whether the total length of both arrays is odd/even, handling the out of bounds case, whilst under pressure on your third interview of the day with just the intuition you've built in your day job, then as far as i'm concerned you are the exception not the rule.

I really appreciate your greater point. I've been given all sorts of CS problems in interviews that I don't have any background in understanding the context enough to know what to do. I changed careers from experimental physics, so my software work is essentially self taught. That doesn't mean I'm totally useless in my job or not an asset to my team or can't deliver products that generate massive revenue. But, those things are how interviewers make me feel.

Merging and comparing arrays as in that task also seems like something that might actually come up in a job.

However, I take the point of the other comment that the real issue here is doing it with certain speed requirements. That does make it harder, indeed, but still doable.

Self learning 'big O' is a waste of time and effort. Never have I needed to know it to accomplish a task beyond interviews. Don't nest six for loops, reading lines from a file into memory each loop. Got it, learnt it, can do. Next problem.

This gatekeeping attitude is bullshit.

Understanding Big O notation is not that difficult and everybody knows it is a common question in interviews. Analyzing specific algorithms can of course be difficult.

Having a CS degree gives you a large advantage when solving problems like this, but that advantage is markedly lower when you are trying solve typical real-world problems in the private sector.

Self-taught or not, no one is able to derive an optimal solution to algorithm problems on the fly. You must have previously learnt the technique, and probably practiced applying it a lot.

Also I must admit I used to enjoy such tasks more in former years, now it seems more like a needless chore. On the other hand, somehow I feel compelled to solve games like "Human Resource Machine" or "Infinifactory", which can be equally tedious.

I'll try to solve that leetcode task.

I was once asked to produce the proof of the theorem of Pythagoras, which I hadn't thought about for many years. I failed to do it in the interview situation and later did it at home. However, I enjoyed the interview and I was also offered the job.

A good exercise, I think, would be to ask people to implement binary search (assuming they never have before). We can all intuitively explain the algorithm, but actually getting all the code just right is a little tricky. See if it trips people up. Then ask them to do it in 20 minutes or they are fired (e.g. comparable to interview scenario).

I've found a great number of "easy" problems too challenging to complete in 45 minutes. And yet once I learned the underlying techinques / DS / Algo's, many "medium" ones I can complete in 10 minutes or less, even when I have not seen that particular problem. Conversely, I was able to complete some of the harder problems in 5-10 minutes without EVER having seen the underlying algorithms before, because I actually had in real life problmes but had never drawn the connection. The more leet code I do, the more I realize when encountering a new problem, it is a complete roll of the dice if it will take me five minutes or five hours, despite being of the same level of difficulty and even same class of problem. But this is not so surprising -- this is how the history of those algorithms unfolded. Many were one line of code away from a far better runtime, and sat for years before someone cracked it.

My main take away is, algorithmic style questions can be useful to test whether candidates adequately prepared and practiced from a given set of information, and is perhaps most predictive of their level of comittment / professionalism / base-aptitude. IMHO unless you are building a novel product or charting unknown territory (rare), its far better to be experienced, prepared, and well read, than it is to be smart. Perhaps. I don't take issue with Google requiring a wide variety of expertise in such problems to get in. I do have a problem with a random set of "easy" problems and then making judgements of people afterwards. But that's just IME.

>I still deliver high quality software on time, and on budget, and have a solid grasp on my career.

There's simply no way of proving that to recruiters without Leetcode.

If a recruiter can't assess engineers without something like Leetcode, they need to find a another job. Assessing talent is the job of a recruiter, and if the only way they can do that is with Leetcode, that's just pathetic.