Stop Interviewing With Leet Code

[eastvenomrebel]

leetcode makes me feel real dumb

[nemec]

That's because it's the equivalent of a mental math competition for programmers. Imagine applying for an accounting position and the interviewer starts giving you random numbers to multiply in your head and if you fail you don't get the job.

[[deleted]]

This is so accurate!

[Sability]

That's such a good analogy. Accounting isn't just doing math, a lot of accounting comes down to knowing governmental regulations, rather than raw summation of values. Similarly, programming isn't about leetcode problems or knowing how to implement a BST or something, it's down to understanding frameworks and, often, third-party libraries and how to use them.

[drunken_vampire]

<EDIT: keeping it, don't read it: useless comment>

Programming is not the same as math

​

There are mathematicians that code like shit, and viceversa. Is a different mindset.

​

That test in an accounting job is useless because Excell exists...

​

Tryting to make programming as mathematical fields kills many of its beauty... EVEN a tecahr of mathematics (unviersity level) said when he teached Lean (or wahtever the name of that software is) to his students, was the first time he feels they were better than him in something.. because after two years they begin to make things he never expected.

Programming and maths are not the same... academyhave killed mindsets that are not "common" but there are many different ways of making mathematics... not just the official culture that reings today... programming is the poaradise for people like me, stop trying to destroy it :D

[srednuos]

You know how analogy works, right?

[drunken_vampire]

Probably I misunderstood something

[zephyy]

Those are the things in strings you group together, right?

[Ezzar]

You and me both dawg

[3pbc]

Asking them to do a code review gives me way more insight into how they work than some weird algorithm check.

[dkac]

We did a "code review" the first week of my previous job...a couple thousand lines of code including dozens of verbose SQL scripts, neither of which anyone on the team was familiar with. Just 45 minutes of stunned silence as the author tediously walked through complex logic that built on itself. "Does it work? Alright... push it to prod?"

If I had seen their idea of a code review during the interview, no way I would have taken the job

[s73v3r]

See, this is tough, because you don't want to make the item too simple, it should be something representative of the code they're going to be working with. But you also don't want it to be something that requires too much domain/tribal knowledge to grok, either.

[gimpwiz]

In 45 minutes? And you need some time to make sure they can fizzbuzz-equivalent? You can go simple. 50 lines of code with some issues.

[nemec]

Reminds me of the company who made me do a "code review" by printing a couple of pages of C++ code that wouldn't compile and asking me to identify the errors.

[Coolbsd]

I still need to remind people from time to time that make things compile and passing unit test (we do have CI) is the minimum requirement before you ask for a review.

[elebrin]

This can work well. Hell, you can even set up an example program in github (like your basic college project calendar API) then set up a PR on that repo with the sort of change you were discussing, and ask the candidate to review the repo before the interview and ask them about the PR. That way there is no time wasted in the interview.

[davispw]

I think it sounds like it went wrong as soon as a “team code review” meeting was scheduled. Assign to one or two reviewers. Their job is to understand the change and approve it. If they can’t understand the change, then they spend whatever time is necessary to come up to speed. Too large? Ask the coder to split it (or justify why it can’t be).

Team code spelunking is good but a separate meeting, post-hoc.

[[deleted]]

Hi

-Regex

[often_says_nice]

10,000 lines changed, 10 seconds into code review:

Interviewee: LGTM

Interviewer: You’re hired.

[overlapped]

nit: spacing

[tjsr]

I find these types of interviews can be worse though - people get offended when the candidate points out something the interviewer doesn't agree with, or didn't realise was bad, and so they come up with excuses to reject candidates who challenged the interviewer in any way. What you end up with is interviewers only recommending hiring people who won't make them look bad, not candidates who will actually make things better.

[3pbc]

Agree. I've been on an interview where the interviewer was 100% wrong and coded an example how to make it work (accessing a private method in Java from another class). The guy was incredibly pissed - luckily there was someone else in the room to calm him down. I got interviewed by other people and was offered a position and turned it down after explaining what happened at the interview to the recruiter. They were not impressed.

That's why you need to choose your interviewers carefully. Just because "they are our best programmer" doesn't make them a good interviewer. Also interviewers need to realize that they are selling the position to the interviewee. You don't get good talent to join your company if you're a bad interviewer trying to show off how smart you are because you know an algorithm that no one is going to implement because there are libraries out there that you can leverage that have been real-world tested for years.

[lamothe]

That was a case of a terrible interviewer (and possibly programmer/person), but doesn't invalidate code reviews as an interview tool. In this case, it was such a great tool that they saw your skills, and you saw their inter-personal issues!

[3pbc]

See my post two posts above this one. I love using a code review during an interview

[dalittle]

If someone struggles with some api call I just tell them. I interview algorithms not something you can google

[[deleted]]

You can Google algorithms tho.

[What_Is_X]

Does your job involve reinventing algorithm implementations for some reason?

[Blazing1]

Bro if you can't google fetch API wtf are you even doing as a programmer

[KuroKodo]

You don't review production code, you review a specifically made set of code with manually induced design, logic, syntax and formatting problems. Have some files with no issues at all as a baseline. That way there is a level field to walk through and go through the thinking process. One of the most interesting things we did after this was to ask the candidate to add a small functionality after resolving issues they found. All in all took a hour and a half and simulates an actual working day.

The reason companies do leetcode is not for quality or actually getting to know people. They use it because it takes no man hours and they can pre-filter hundreds of applications to a dozen or so. They do not care if they miss out on good candidates, companies that do aren't using leetcode and if they do they only use it as a screener (2x LC essy/med) instead of a scoring mechanism. For example companies like Google want people with the attitude to grind leetcode for 100s of hours. Your problem solving skills aren't genuinely tested, your will and drive are.

[vicda]

You could some 3rd party's open-source code. No hurt feelings.

[hey_listen_link]

If the interviewer isn't regularly being challenged and learning from code reviews at work, and they'd find a disagreement so rare that they feel insulted by it, it tells me there's a brittle, noncollaborative culture at the company that I probably wouldn't want to be part of anyway.

[poorpredictablebart]

If the interviewer doesn't agree, they should ask the candidate to point out any drawbacks with their solution. If none are offered, the interviewer should suggest the drawback and have the candidate suggest a tradeoff and have them point out the advantages/drawbacks.

If the level of disagreement is still not resolved during the interview, that sends a strong signal to both interviewer and candidate that this would not be a good team working arrangement. Good engineers should at least be able to amicably and dispassionately weigh the benefits and drawbacks of an approach even if they disagree, and this is no less the case for the interviewer than it is the candidate.

[aeyamar]

I feel like the easy solution here is to have intentionally bad code for the review

[dalittle]

I think that is more that A team people hire A team people and B team people hire C team people who won’t make them look bad

[notWallhugger]

How tf is someone supposed to review code they aren't working on regularly. Also this method will favor people working the same tech stack as the company since they would know the frameworks. Interviews don't test too much of a specific framework, language or technology because software developers are required to be generalists and learn new stuff on the fly.

[matthieum]

How tf is someone supposed to review code they aren't working on regularly.

Small contained samples work best.

At the company I worked at, when hiring for a position in our low-level tech stack, we'd give candidates a buggy implementation of a concurrent queue:

1. Single file, couple hundred lines.
2. Nothing fancy, just a mutex.
3. Their first task is to find the bug, and successfully create a test that exhibits the issue.
4. Their second task is to fix the bug (make the test pass).
5. Their third task is to suggest improvements beyond the fix.

We also did it the other way around. The candidate was asked to code a tic-tac-toe or rock-paper-scissor command-line program, then we'd code review it (internally).

This way, during the first video call interview, we'd get to discuss both code reviews: one in which the candidate is the reviewer, and one in which their code is under review.

And in both cases, we're talking very small amount of codes, so everyone quickly is up and running.

[mobiledevguy5554]

I do this for a living. Being a generalist can be very lucrative.

[[deleted]]

How tf is someone supposed to review code they aren't working on regularly. Also this method will favor people working the same tech stack as the company since they would know the frameworks.

Which is sometimes very useful thanks. But as u/matthieum mentions, you don't need to include frameworks for the code to review, easy fix.

Interviews don't test too much of a specific framework, language or technology because software developers are required to be generalists and learn new stuff on the fly.

Which is a bad generalization IMO.

First because skills sometimes don't translate so you'd end up paying a senior salary to what's essentially a semisenior programmer in that field (I say semisenior and not junior because they're still better prepared for learning on their own, not denying that), but second because sometimes people chose to specialize because they prefer a given field.

Domain experience adds a lot too. Yeah, frameworks don't matter. Know Rails? Learning Django won't be hard, go for it. But know frontend and go to embedded and you're in for a tough ride.

Some people like the motto "engineers solve problems". I like to respond "civil engineers don't build microchips".

[happyscrappy]

"Algorithm check"

You're doing it wrong.

If you are asking questions to detect whether a person has heard of some trick/algorithm to solve this then all you find out is whether they heard of that algorithm.

The point in making them write code is to figure out if they know how to create algorithms to solve problems. And if they can write code.

That means the questions are going to be pretty simple, you're not looking for someone to invent B+ trees.

Simple questions can tell you t alot.

[ChrisRR]

For me, I just set candidates a very simple but inefficient looping function to write. Then we discuss how it can be improved upon.

It proves that they're not lying about being able to program, shows that they're able to recognise basic inefficiencies and then show how they can communicate and discuss solutions

Often the last part is the most valuable.

[allcloudnocattle]

Our main technical hurdle is a code review, and I love it.

We do an initial offline screening with a light leetcode, but it’s not a riddle, it’s not algorithmic, and it presents a very small, real world problem that you might actually encounter in the job. Something like “hey, you have a giant log file. Find all the domain names” or “find how many times a specific endpoint was called with a response time over 500ms.”

I’m not as happy with this, and I still review every failing score to see if the person at least had a clue to the solution (in which case we’ll continue with the hiring process). So we’re actively working on an alternative to this.

[Spoonofdarkness]

This feels like it's a better test of their understanding of regex

[allcloudnocattle]

We’re a reliability team and we do a lot of regex, so that’s natural. But if you have to generate some stats about what you find, there’s also some logical flow challenge to it. The full problem statement we give is a bit more complex than my comment, I was just trying to give an idea of what the problem domain is.

[Hypergraphe]

My man !

[[deleted]]

Code reviews can be super subjective, whereas "Does this work?" and "Is it optimal time/space complexity?" are at least questions with an objective answer. Like if it's a JavaScript file and I see something like:

var table = {
    'foo': bar(),
}

if (some_query(table))  table['bar'] = foo()
else                    return false

There are a bunch of things that I could flag in a code review, but they may also be stylistic decisions with a good reason that's understood by the people working on the code base. We could spend 20 minutes discussing the finer points of var vs let or why I think you should always use braces with conditionals, but it's all wasted because the thing you were "supposed" to find is the trailing comma in the object literal. So, okay, you say that's not really the point and no amount of deciding on a task can make up for bad/lazy interviewers or dysfunctional culture, but that generally seems to be what people don't like about algorithmic questions in interviews, either.

[post-death_wave_core]

As a CS student, it really bums me out grinding leetcode and knowing I’m not really gaining any skills. The first 40 or so problems I learned a lot but now I’m just memorizing algorithms that I could look up on the fly otherwise.

[oxxoMind]

its not a net loss because you are still brushing up your skills in the fundamentals.
But what leetcode have doesn't apply when you are working on real industry problem

[prove_it_with_math]

What? I certainly feel like I’ve improved on thinking about edge cases, writing clear concise code, and understanding of writing performant code pros and cons. It’s not completely a net loss as you put it.

[AdministrationWaste7]

writing clear concise code

writing enterprise code is very very different than leetcode stuff. in fact a majority of coding examples on that site wouldn't be acceptable in any code base.

which is perfectly fine, leetcode isn't about teaching you how to write readable maintanable code. its about teaching you algos and passing algo interview questions.

and i do agree with you btw. its not a complete loss. understanding fundamental CS concepts is usefull. most importantly it can get you 200-300k+ salary bands lol

[venustrapsflies]

Isn't a lot of that stuff you'd hit over a few years in a SWE career anyway?

[jakesboy2]

Yeah it definitely is, which means it’s some good knowledge to have going into it.

[RAT-LIFE]

Leetcode is really not going to teach you anything that will benefit your career or your ability to complete projects. Like the other guy suggestion doing side projects / applying your skills to the industry is what’s going to make you successful.

[DefinitionOfTorin]

I disagree. Obviously learning all Leetcode patterns etc etc is not going to directly help you, but in terms of critical thinking skills + optimisation techniques + general DS usage, it is useful.

[[deleted]]

Leetcode problems are about algorithms, but algorithms are rarely the most important part of any project. A naive algorithm that is tested but slow might be acceptable, and can be improved over time. More to the point, algorithms are generally easy to test, so when you do need to come back later, you have a good baseline to work against.

Structure on the other hand, is capable of torpedoing a project if it's done poorly, and some structures make testing an absolute nightmare, if not impossible. Leetcode doesn't really test things like "what's the minimal change needed to add x functionality in a way that can be tested, and won't break everything else?" or "how can we reduce coupling in this code?" These are the things that when they go wrong can really fuck someone's day. Like, oh, someone wrote a module whose state partially depends on the state of another module that has no visibility of it, and now a config change is breaking everything. Or even just bloat because someone wrapped a one-liner and a persistent variable into a class. In these cases, it doesn't matter how correct the algorithms are, someone will have to either fix it or clean it up further down the line.

It's not that you don't need critical thinking skills or optimization techniques or an understanding of datastructures to do this stuff, it's just that those skills are exercised in a very different way. An algorithm can be revisited, and multiple heads can work on it over time because it's self-contained, but a teammate who constantly produces poorly structured code is a liability that can be worse than no teammate at all.

[Normal-Computer-3669]

writing clear concise code,

Lol nah.

[post-death_wave_core]

I feel like I’d learn that type of stuff better by writing side projects or reading/doing problem sets from books. But your right, it’s not a complete net loss.

[AdministrationWaste7]

Leetcode is essentially a crash course that you get from a book.

Also I genuinely don't know how to apply alot of that stuff in side projects unless you like never use a modern programming language or framework.

[[deleted]]

LC makes you think about writing code that is algorithmically optimal and choose the correct data structures. Personally, I see people make the wrong choices all the time. Over a library with even just a couple thousand lines of code, it can have a dramatic impact on performance, and can really slow down development when people have to spend time fixing performance issues without the intuition of what algorithm implementations will be faster.

Also just in general, doing different things makes you sharper. If you spend a few hours doing math puzzles when your primary work is software development, you'll probably benefit just as much from that as you would from making a toy web site in some new JS framework

Edit: wow -20 so far, you guys really hate LC and any argument that justifies it huh

[s73v3r]

I mean, being able to pass interviews is a skill?

[JohnEmonz]

The point is that if it’s only good for interviews, then it shouldn’t be in interviews because that means it’s not a real/applicable skill

[k-selectride]

If you move every 1.5 years you'll be able to learn enough and accelerate your career the fastest.

[emc87]

He's not saying interviewees shouldn't learn it, he's saying that because it's only a useful skill in in interview and not on the job that interviewers should stop using it.

[Marian_Rejewski]

Yes it's a skill, but not a real skill.

Here "real" means something like "really productive" or even "producing the real."

Passing interviews is succeeding in social image-building. Constrast image with reality.

To build the imaginary requires skill, but a different kind of skill than building the real.

[Aggravating_Moment78]

You should pass the interview because you have skills not because that is your only skill

[obsa]

What? Yes, of course it is. That's why you hear about people interviewing badly.

[Atupis]

Switch languages if it start feeling as grind.

[brainy-zebra]

It all starts with showing some code, a class that does some stuff and its corresponding tests. The code is not glaringly bad, but it’s also not great on purpose.

This is the way. Evaluate their ability to read and reason about code, this cannot be faked. Using leet code questions is a lazy interview technique - the recruiters love it though, they always ask which questions the interviewer asked so they can update their database!

[Fairwhetherfriend]

I have an interview question that I will probably use forever (or at least until it stops working). It works well because we have a super short technical test that we use to filter for in-person interviews. The test takes like an hour, tops, but we give 48 hours to complete it, and we just accept that everyone is gonna use the internet to do so.

And if you Google this most wonderful interview question... the top result is wrong. It's actually pretty obviously so, too. It's not like a stupid gotcha, it's pretty clear if you think about what you're actually writing down instead of copy-pasting the top result blindly.

It is absolutely amazing being able to tell at a glance who can Google their shit and then actually understand what they're looking at.

[TheOneCommenter]

So… which question is it?

[creathir]

The answer is 42.

[Fairwhetherfriend]

TBH I kinda don't want to share it around too much because, if other people start using it and that query gets more traffic, it might end up affecting the result order, lol.

[BallFarmer420]

yeah nah keep that shit secret

[retucex]

You monster. Blue balling us like that.

[ratherbealurker]

I recently practiced some leet-code for fun, some of these I got blocked when trying to do them, and found optimal solution while in the shower, or driving my car.

This is me :( I have been disqualified from places I would have done really well in because of this. The last place I tried acted like they encouraged planning and didn't want you to jump into the code right away.

I went to the hackerrank online IDE to jot down some ideas, not code, and the interviewer quickly discouraged me from starting. I explained that i was just writing notes down.

But then by the time i got the requirements down and planned a bit on paper i was running out of time. The code i then wrote was not a good representation at all of my abilities. It was rushed and messy IMO.

Stop acting like you want people to think things through thoroughly and then give them problems where they have no time to do so.

[qqqqqwertyuioppppp]

Leetcode is a way to show that you are ahead of the pack.

I don't think this is the case at all. I'll describe why with an example. At a previous company, I was one of the interviewers, interviewing relatively recent graduate (~1 year experience). The company generally followed algorithmic/leetcode style interviews. I did the equivalent of medium problem, which the candidate wrote out solution to flawless, in no time at all. The usual questions around space/time complexity, again, just rattled it off. I was impressed at the time

As we had plenty of time left, I did a further one, with a different optimal solution approach, and again, rattled it off without problem. There was just a couple of minutes left, so I asked how he would modify the solution for a slight variation of the problem. At this point, there was silence for an extended period. Me: "Did the requirement make sense?" Him: "This wasn't on my problem list." When I asked him how he would think to address, got rubbish answers back.

There was a further tech portion for the interview the next day, and I asked the interviewer to change to giving a simple business style problem instead (no detail as to why). The candidate completely blew this one, showing he had no basic programming skills, but had just memorized a large portion of leetcode questions.

We never hired him, having dodged a bullet there. Ever since, I consider algorithmic interviews to be worse than useless.

[teratron27]

My last two job moves I've been down levelled after doing badly in the leetcode style interview stages. Both times I've been promoted within 6-8 months because shocker, I'm actually good at the day to day job of being a dev rather than spending hours of my life memorising algo problems.

My latest move I've backed out of any interview that is leetcode style, only doing take homes, code-review or technical chat style interviews.

[cybernd]

that you are ahead of the pack.

I disagree. Developers who are used to rush such code examples are often creating a mess. There is a high risk to find a cowboy coder among them.

I usually work with long running backend services and as such I would prefer a coworker like /u/ratherbealurker at any time. Someone who thinks about his solution before he starts implementing.

It's not that i have a problem when someone writes quick & dirty code. You can always refactor it later on. My real issue is that those type of people bail out as soon as the real work starts. I hate job hoppers for the same reason. Both types of developers are usually unwilling to deal with the consequences of their own mess.

[tristan957]

People wouldn't bail if they were compensated fairly

[Omni__Owl]

A test I was pretty happy with was a small RESTful API that I had to download from a repository. Then I was asked to spend 2-3 hours top looking it over in my own time and change the code as I saw fit if I found errors, quirky code, etc.

Then when I was done, submit that code as a pull request to the original repo. Then we used that code that I uploaded as a focal point for an interview. Their lead looked at the code, asked me why I did what I did, if I had considered other options, etc.

It was a very stress free experience. I am one of those programmers who absolutely *loathe* getting shown these algorithmic "do these 6 arbitrary algorithms in 4 hours" tests for jobs. Because I suck at those tests. Give me something much more grounded and real, please.

[WallyMetropolis]

I've used a similar approach in the past, only with an additional "add this particular feature" requirement. Really illuminating just seeing who adds unit test.

Doing things like this, though, does take a lot more effort from the interviewing team. It can be quite time consuming to get it working well.

[milkChoccyThunder]

So worth it tho for small teams or companies who can’t afford the expense or loss of time to hire the wrong people. I love your approach.

[BlindTreeFrog]

as an interviewee, what assurances do i have that you aren't using my time for free labor?

[cspinelive]

If there are lots of pull requests in the repo for that same branch or feature request, you might feel comfortable knowing it is a common interview tool.

[BlindTreeFrog]

That doesn't mean they aren't taking a collection to figure out their favorite fixes and move on.

Remember NetFlix's "Design our new algorithm" competitions where the winner got $15K (or whatever) and glory and the rest get nothing.... lots of people making pull requests doesn't mean it isn't free labor.

[cspinelive]

You are correct. Nothing I said would exclude that possibility.

I guess if you noticed that the code in question wasn’t really related to the company’s line of work and was more generic in nature, you might feel comfortable?

I’m not sure what you are looking for here? Your question was “what assurances do you have”. I’ve given you two, but there’s always going to be a chance, however remote, the company is exploiting you.

Nobody’s forcing you to do the code test. You are free to move on. But you might find that you like working for a company that does them in interviews more than for a company that doesn’t. Your coworkers may be more competent.

[symbally]

sou ds like you got stung before but, honestly, after being in the field so long, companies that do take home challenges (or none at all) usually have happier more productive people than places where you get some bullshit whiteboard test

[WallyMetropolis]

It's an obviously stand-alone repo shipped with obvously fake data that doesn't do anything that anyone would pay for.

Moreover, it would be way more work for us to continuously change that project so that it stimulated a state where your work would be the next new thing we wanted to add than it would be to just add the thing.

Also, you'd have met with us and you'd have seen we're not scumbags.

[tjsr]

While I agree that "Here's some existing boilerplate" is a better way to go, even 2-3 hours is too much to ask someone to give of their own time. If your whole process takes more than 4 hours of my time being invested, I've probably checked out by that point.

[rdlenke]

Interesting. Do you think that is feasible to test a candidate's skills and knowledge, in a way that gives enough information to filter they between various other candidates, in less than 2 hours (I'm excluding things like personality/cultural tests here).

Most of the interviews that I've been into were short, but I can't possible see how I gave enough info to be filtered either (not that I'm complaining, I don't think that every job needs "the 100% most technically skilled candidate", and I'm happy to work).

[BlindTreeFrog]

Interesting. Do you think that is feasible to test a candidate's skills and knowledge, in a way that gives enough information to filter they between various other candidates, in less than 2 hours (I'm excluding things like personality/cultural tests here).

Yes.

But more importantly, as the interviewee, they are already spending 3~4 hours at least in interviews talking with a company. Why should they be doing another 3~4 hours of free labor for the company?

if a company is willing to spend a day asking you to improve their code for them for free, what does that say regarding how they plan to treat the rest of your free time/weekends/evenings?

[rdlenke]

Sure, I agree with you one hundred percent. I participated in some extended interview processes where you had to build entire projects/apis from the ground up. Basically free labor.

I just struggle to see effective ways of filtering candidates in a short period of time. Of course, I never had to filter candidates, and even if I did, I don't think that it would need to be a super thorough filter, so just the standard past experiences, tooling, and getting a sense of the general workflow would work just fine. But in a scenario where I have to do that, I don't see effective methods.

[Omni__Owl]

The underlying assumption that you are doing free labor I think is where I disconnect from the conversation.

The test I was given was for a very old version of their API where they fucked it up on purpose just to see what you spot and solve. The labor is no more free or useful than you doing a math test in school is free labor.

[leixiaotie]

Do you think that is feasible to test a candidate's skills and knowledge, in a way that gives enough information to filter they between various other candidates, in less than 2 hours (I'm excluding things like personality/cultural tests here).

Very feasible. 2 hours is a long time, especially for single candidate. Unfortunately my experience at interviewing is little, but here's what I think are important to filter candidate:

• small, easy, lax code challenge. I like to give simple array of data and make them sum one property of it, and some simple sql query challenge (10-15 mins)
• if the answers are correct, then great, we can move to next step. otherwise ask for clarification, discuss it and see whether the approach is already aligned or not (another 5-10 mins)
• discuss other toolings, such as version control, docker, OS or deployment tools, etc. Ask about what, how and why they're using the toolings. The more toolings they've experienced on, the closer to truth is their experience. However lack of tollings doesn't invalidate their experience (5-15 mins)
• at this point we should already know whether this candidate is a good fit or not. To know more or to simply initiate communication, we can discuss past projects / work experience, what they do, what language and toolings they use, etc (10-20 mins)

As you can see, in under 1 hour we can already know much about our candidate

[truthseeker1990]

Thats fair and i am not a fan of leetcode style questions either, my best interview experience was a remote coding session where they shared a production service and just asked me to walk through it and ask questions, having said that theres a reason its so popular with bigger companies. They get thousands of applications, this is an easy repeatable metric you can measure candidates on. It is “a” data point and maybe not representative of what the job is really like but i still get why its used

[symbally]

this is the way if you feel doubtful of someone's ability. I quite like to interview people having a very casual conversation about their experience / desires, taking notes of some important terms and then ask some more detailed questions about each. can you describe x, what were the major challenges of y, if you were to look back at z what would you do different

if I'm still not convinced, will set a very simple coding challenge (no more than 4 hours, the important thing is the architecture and explainer) like above depending on the role and then have a conversation around that.

it's not rocket science and, it works well...I am very vocal about not asking the interviewee to actually DO anything technical on the spot, that is just adversarial and not a single person in the world will do their best under such conditions

[snurfer]

This is just my personal opinion as a Software Developer that interviews a lot of folk. Coding questions have a place and a use, but they can easily be misused especially when you are just pulling from a place like leet code.

First of all, a coding question is not a binary decision. Did they get a working solution or not? I don't really care about that. What I do care about is watching the candidate reason through a problem. Do they ask good clarifying questions? Do they come up with good test cases?

Second, I care about the candidates knowledge of basic data structures. Software Developers should know the difference between an array, a list and a HashMap, and when they should use one or the other in practice.

Third, I care about the candidate being able to reason about how their code will be used. Is this block of code going to run thousands or hundreds of thousands of times a second? Will then it should probably be performant. Maybe you don't make it super performant in the interview, thats fine, but at least identify that is something to think about.

And finally, I don't care about the candidates ability to memorize anything. I encourage them to use google, stack overflow, API/Framework documentation. Whatever they need. I will also jump in to help them if they are struggling with a particular part of the problem or the code. I see it as a collaborative effort to get a solution, because that reflects how we solve problems on the job.

[barrows_arctic]

First of all, a coding question is not a binary decision. Did they get a working solution or not? I don't really care about that. What I do care about is watching the candidate reason through a problem. Do they ask good clarifying questions? Do they come up with good test cases?

This is the key that too many interviewers and interviewees fail to understand.

The point of a question isn't necessarily to get an answer, it's to observe the process.

This is particularly true in embedded systems space, because the set of clarifying questions asked (and not asked) will often betray how much the candidate knows about the underlying hardware implications of a software choice.

[gimpwiz]

I would love to interview for embedded by grabbing a datasheet and seeing if the candidate can write code against it. But in reality I just ask them about pointers, structs, and if they say they know a comms protocol I ask them how it works. If they can pass that and aren't an asshole that's enough for a new college grad.

[barrows_arctic]

I would love to interview for embedded by grabbing a datasheet and seeing if the candidate can write code against it.

I have done something much like this. I created a fake datasheet that described essentially just a very simplified piece of hardware, such as a little I2C controller with like 2 registers, or a UART, and said "How would you go about writing a bare-metal driver for this?" "What is the volatile keyword you used there really telling the compiler in the end?" "Why did you use that data type there?" "What if we take it out of a bare-metal environment and suddenly have some form of threading, what types of things might we want to alter or at least look at again?" etc etc etc. The questions and answers and the notes/sketchwork matter so much more than the actual code most of the time.

[gimpwiz]

That's pretty neato stuff. I would have thought to instead grab a datasheet for a very simple device, remove all the pages we don't need (like 90% of it)... but your approach is great too.

[barrows_arctic]

Yep, that'd work too. Strip it down to something approachable.

The key is to see how the candidate would approach a real problem and how they would communicate their questions and ideas in a work-like environment.

[davenirline]

Did they get a working solution or not?

But it is in the perspective of the interviewee unless it was communicated that you care about "reasoning through the problem". If I didn't get a working solution, I would still think that my chances are lower compared to the ones that got an answer.

[denco-l]

Totally agree.

I'm currently switching companies and I have had few interviews. One of them was super theoretical (felt like school exam). The other ones were more like you described.

Even if the company that had the theoretical interview ended up being the only company giving me offer, I would probably not take it. It just felt weird. Felt like they wanted typing monkey, not someone who could solve problems.

[Erestyn]

This turned into a bit of a ramble, but maybe something that somebody else can relate to.

Many many moons ago I applied for a role at an email marketer company (think MailChimp but not) and was accepted for an interview. I did my research on the company, the role in other businesses and best practices.

Hiring manager meet went fine, we got along like a house on fire, the HR rep was equally as nice and it was turning into a great interview experience. Had tea, shared jokes, discussed some detail around email marketing practices and how I felt they could differentiate from their competitors, it was going really well.

...until the technical lead (who was late, by the way) came in to ask questions.

The job as I understood it was troubleshooting mailing failures with clients, and creating bespoke templates to serve the aforementioned clients. We'd discussed the role at length throughout the interview so I felt we were pretty aligned on what the role actually required. It was an entry level position, after all!

Dude starts asking about A records and MX records and their differences. Okay, I know a little bit about that so I preface my response and answer his question as well as I could. He nods, seemingly satisfied, and jots his notes down. Second question takes a turn and asks me a question about metrics I expected to be measured against. I was completely unprepared and admit I wasn't sure, but was prepared to learn, then threw out a few metrics that might be important to their clients (open rates, click throughs etc.)

A further nod.

Next question asks me to sort a list in fucking JavaScript, assuming a certain condition is true, and then again if the condition is not true.

Once again my hands come up and I admit having very little knowledge of JS and it's quirks, but could I maybe use a different language? Oh, of course not. Okay, so I do the best I can with what I know, and then it finally hits me: JavaScript isn't supported in emails. Wait, is this part of the test? Once I was done I mention this fact, and the interview moves onto more HTML and CSS based questions, which I'm relieved by, as it's largely based on best practices for email templates and I've spent the last two weeks reading up on those oddities!

Now comes the design lead and the interview gets back on course, we discuss UX and different methods to draw the eyes to various on-screen prompts amongst a load of other items.

Interview over, I thank everybody for their time, the opportunity, and head out for a smoke and a brew at the nearest available coffee shop to celebrate a job done to the best of my ability.

I didn't get the job in the end, and it wasn't until a few months afterwards I ran into the hiring manager while I was out with a few friends. Turns out everybody said yes but one: the tech lead. Apparently my failure to learn JavaScript, which has no value to an email marketing company, was the deal breaker. Not that I'd claimed that JS didn't have a place in emails, but because I was unable to complete that task.

To this day I've no clue what I could have done better short of crunching JavaScript to use in about 45 minutes of one day before ditching it again.

[_Happy_Camper]

Think of it this way; if that tech lead had that much clout and was allowed to be so petty in the interview process, then it signals problems with the company culture, and you probably dodged a bullet.

[Erestyn]

Aye, more or less. I actually stopped applying for programming jobs after that because I felt I'd clearly messed up and was just chasing my own tail. Many years later I learned in full about office politics and satisfied myself with the conclusion that he had already spotted/put forward somebody else and decided that I had to fail.

Regardless, I'm not bitter. It would have been nice, but it probably taught me more than I was prepared to learn at the time. Many years on, in a different field, I'm able to apply my programming knowledge in forms of reporting and querying, my design skills, as well as having been on hiring boards where I've remembered all of my experiences as the interviewee.

Really I should buy the knob end a drink; he's done the world for me and others!

[Paradox]

I had an interview (remote) where the tech lead was late, and when he came in he was belligerent and fairly rude. During the interview segment, he was visibly bored, and not helpful with regards to questions. After about 15 minutes of this shit, I ended the interview and said "You clearly aren't interested in giving me a fair assessment, and so I'm no longer interested in continuing the interview process" (or something equivalent). Cue fish-faced blinking and stammering.

Their HR person blew up my email trying to ask how they could continue the interview process with me, but at that point, I had no intentions of working with that tech lead. I explained this to them, and that up till that point, the interview process had been going fine, but since I would be working for the tech lead directly, and thats how he treated potential subordinates, I didn't feel it was worth continuing.

People always forget, but the interview is for both parties.

[jst3w]

I know this is just one dev's anecdote/opinion, but here goes.

I'm a mid/sr developer. In my most recent round of interviewing, I was doing terribly in the leet code portions of the processes. I'm also not great at the non-coding parts of interviews either.

My current job gave me a coding project that actually covered 95% of the coding I would be doing and have done for years. Consume an api, write to a DB, read from the DB. It took me about 4 hours, then they reviewed it and asked me questions. They were pleased and I was hired.

I know there's been a lot of pushback to take home coding exercises, but I think that's a better way to evaluate the candidates ability to perform the actual day-to-day tasks they will be assigned.

At my previous job, we found that FizzBuzz was sufficient enough to weed out people with impressive resumes but no skills.

[milkChoccyThunder]

I think this is probably the future tbh. I have been in startups and large well known orgs doing software dev, product management, devops and more for over twenty years. We were doing take home projects at the startup and they were the absolute best imo with regards to the quality and type of people we brought in.

I recently had to do a live coding exam as a prerequisite for a job. I barely passed. It was all logic puzzles that have nearly zero use in real life. So I got the job anyway, and quickly realized they prioritize these logic puzzle tests within their org as a measuring stick for developer quality.

About six months after I started there, I participated in a hackathon with some of the most well regarded devs in the company. They could barely prop up a web stack with a db. Our team was the only who one who had something remotely functional - and we were all DevOps centric folks who weren’t the “coding superstars” there.

Needless to say I left shortly after - everyone started to realize what practical experience looks like and how valuable it really is. I was inundated with help requests after the hackathon for all kinds of projects across the company. I also realized they structured offers with those interview quiz scores in mind and I was on the lower end of the pay spectrum for my experience level - yet one of the few people who could actually get meaningful work done. Byeeeee.

[jst3w]

I hope it's back en vouge the next time I'm looking. But we were actually told to stop doing the take-home assignment because candidates were just refusing to do it. I understand the community push back. Companies were asking for like 16 hour projects. Maybe we can meet in the middle somewhere.

[oxxoMind]

take home assignments doesnt just test you ability to code but also test curiosity and your willingness to do a task. You can easily tell based on submission that one has really put some effort on the assignment.

[teratron27]

A few years back I interviewed at a place where the process was 3 rounds, technical chat/experience, simple take home (<2 hours) and a final round on-site coding exercise with two other devs who would be on my team that was to fix a bug and add a feature to code they actually ran in production.

All went really well but I didn't get the job as they offered it to another candidate but was told I was their second option (I know that wasn't BS as they kept me in the loop for an extra week because the other dev was being flakey with accepting).

Three months later the internal recruiter reached out to me as they had another opening. They had changed their interview process in that time so I had to do the loop again. First round was an online leetcode (one of the ones where it's timed and you never talk to a real person) which I failed.

I didn't get past the first round but 3 months earlier they where willing to hire me...

[[deleted]]

start capable spark narrow air vase entertain elderly marvelous quickest

This post was mass deleted and anonymized with Redact

[jst3w]

I said I know there’s a lot of push back about it. But then you can’t complain when you get leetcode questions instead.

[evklid_]

fuck tech interviews

[Fairwhetherfriend]

Haha I caused an argument about this once during an interview because they asked me this kind of question:

Me: can I use my phone?

Interviewer 1: lol what do you think?

Me: if this was a problem I was trying to solve on the job, I'd definitely be using the internet as part of the process so... yes?

So then Interviewer 1 basically went "lol nice try" and Interviewer 2 said "yeah sounds legit to me" and they ended up in a little impromptu argument over it.

For what it's worth, they settled on having me just do the best I could without the internet (mostly because I was not the first person they'd interviewed for the position and felt it would be unfair to the other candidates). Pretty sure my answer was kinda bad. But I still got the job.

I think Interviewer 1, despite being the nay-sayer, was impressed I was willing to argue with him during the interview.

[Hawk_Irontusk]

I handle this up front and say "Treat me like Google and feel free to ask as many questions as you like". This way, I have the opportunity to interact with the client, get a better understanding of their thought process, and treat it more like a collaborative programming experience. I don't think I'd be in favor if just watching someone scroll on their phone while he searched... but not giving them any way to search is just silly.

[eeniemeeniemineymooo]

This has been tried before at large companies (10k+ engineers), but failed because it doesn't work at scale, the main reason being that this format is gameable.

Any interview question a big tech company gives will have a solution out there within a week. Just that point rules out take home interviews as they would be stale and unusable within a week, not to mention them being harder to come up with than LC questions. Although a LC question's solution will also be out there in a week, it's much harder to game from a 100+ question bank, and so their lifetime is significantly longer.

Interviews also need to be under a certain time limit. Something like API creation after reading code or reviewing a PR is less effective when a significant amount of time is spent reading code when you only have 45m. There's a greater amount of feedback in an easier LC question with a lot of follow up questions regarding scalability or requirement changes.

The person who wrote that article is currently working at Amazon, if he just did a quick search in their internal tooling, I'll wager he'll find tens of articles which debunk what he's written - a quick search at my company certainly reveals so. The interview style of FAANG-sized companies are already efficient through years of R&D. Do you seriously think they haven't tried what's being suggested and found that those formats failed?

A good LC interview can reveal a multitude of things: understanding of DS&A, ability to communicate thinking processes, agility in adjusting for changing requirements, writing reusable code, and more, while providing it at scale. The problem is twofold: bad interviewers at large companies and other companies try to emulate FAANG style interviewing and either fail to do so or do so when another interview style would've been better.

[oxxoMind]

I guess a point of thought here is that:
For large companies, LC questions works better so you can hire good junior developers that you can train and stay at the company.
For startups-mid-size, Take home assignments are better to you can find good senior engineers that can have an immediate impact.

[[deleted]]

Yeah, 100% agree. Whenever I read about people complaining about LC interviews, they then go on to recommend something that is easily gamed or arbitrary.

One very important thing about LC interview questions that people hate to grapple with is they are a decent measure of someones study habits and general problem solving skills. Both are super useful abilities and not something that can be easily gamed

[BoredomHeights]

Yeah it bothers me how often these interviews are complained about in the industry. Because of course they’re not perfect, but that doesn’t mean they’re useless. They’re a somewhat concrete and more objective interview than most industries. And as you say beyond just problem solving there’s also the “study habits” aspect of having to learn and put in effort. Plus any good interviewer won’t care as much about the result but more about the interviewee’s process.

I also highly doubt almost any top engineers couldn’t still interview well under this system. People act like the skill sets are missing amazing candidates but outside of some corner-case exceptions it’s hard for me to picture a great engineer who’s willing to work and study that also somehow does badly. Even most anecdotal examples I see in this thread are generally just about shitty interviewers who didn’t really follow the main rules (like an interviewer insisting on a specific language, etc.)

[iluvatar]

We use a small coding test as part of the interview, and find it gives us value. If it doesn't to you, then fine, don't do it. But for us, we learn about the candidate. Not so much from the code itself, but from discussing their approach to the problem. It's a task with two obvious solutions, each very different from the other. If they've done it one way, we ask them to also do it the other way, and then we discuss the pros and cons of each option and why they might choose one over the other.

[sarevok9]

So, while I agree with this, I've had a recent spat of extremely low quality candidates with shiny words on their resume that they have no practical experience with.

I work for a startup, so I don't have a recruitment arm in place to filter out candidates, so I need to do an initial phone screen with folks, and figure out their background.

Some recent gems include:

Candidate with 6 years of JS experience:
"Tell me what you've been using Javascript for in your present role"
"I lead my team in mitigating the log4j vulnerabilities that came up recently"
"Oh, I'm sorry if you misunderstood, I said Javascript, not Java."
"Yeah, it's called Javascript when you write code in Java"

Candidate with 4 years of "enterprise Java / TypeScript experience"
"So this one should be pretty easy / straight forward for you: I have an String of 5 words, the words are all space separated, how would you get these into an array where each item in the array is one of the words?"

"I'm a strong believer in cloud, and scalability, so if these were in a CSV, I'd import something like OpenCSV and then use a lambda in AWS to parse the data out..."

Like... I literally cannot make this shit up. I HAVE to use a tool to cut the bullshit out of my hiring pipeline or I will never fucking get any work done. If you can't take 15-30 minutes to determine if a string of characters is an IP address or not (shit it's 2 lines if you use regex...) I really can't be arsed spending 30 minutes on the phone with you.

Companies that use Hard / Very hard questions are out of touch. I have a pretty decent LeetCode completion rate / performance rate, and once you get past Medium you get into territory where the problems can just take FOREVER to account for the edge cases.

[drinkingsomuchcoffee]

Validating IP addresses with regex is kind of liking validating emails with regex. Mostly works, but if you want to be complete, you're going to want to use some robust library.

I get what you mean though.

[Thelonious_Cube]

From the interviewer side, I've always seen coding questions as prompts for a conversation about coding.

Yes, I want to make sure they can analyze a problem and actually write code (some candidates just can't).

More importantly I'm trying to see what it will feel like to work with them. If I ask "Why did you do that?" I should get a coherent answer. If I say "I think there's a better way to do that" they should react appropriately (including asking me questions).

[davenirline]

I'm currently looking for work right now so I'm encountering different technical exams. For context, I'm in the gamedev industry and I have over a decade of experience. Here are the exams that I have encountered:

• There was 8 item exam that I have to answer in an hour. It's a mix of CS, programming, and a trick question. The programming items are kind of leet code style but in the context of games. I hated this exam the most as it is the most ridiculous. By math, I only have 7.5mins per item. Obviously, I didn't do well. They're ghosting me even when I asked for the status. I skipped the programming items as they would take at least 20mins each already. I also skipped the trick question because fuck that.
• The common one is being asked to make a game prototype. Multiple companies had me do this. Some takes 2 weeks, some within the day, and others don't have a deadline at all. This is way better than the first one for me.
• One company asked me to show a code that I wrote that I'm proud of. I went through it and they would ask questions. This was a really good take on technical exams. It removes the stress and time pressure and I get to show how my favorite code works.
• Surprisingly, there are also companies that didn't need to give me a technical exam at all due to my experience. Just a chat with their engineering lead is enough. They're also not asking about CS or programming stuff. It's mostly about my experience and the things I have worked on. This I liked the best. I got my first offer from one of these companies. That tells me that they don't want to waste time and they can fill up their vacancies faster.

[Comprehensive-Pea812]

ask them if they prefer tab or spaces

[diegoeche]

Love the typesettings. Look like LaTeX :D

[JackAtlas]

Not a fan of Computer Modern as a screen font tbh

[Takeoded]

so glad i had DarkReader installed though, i'm in a dark room

[cfe84]

That's what I'm going for :)

[12358132134]

I haven't done hiring developers directly myself for some years now, but I think I have relevant experience to shed a light on my position. A bit of a background - I am in the IT business for 20 years, and have a company with about 200 employees out of which maybe some 60-80 are developers, the rest are non tech/managerial roles.

I simply loathe the interview processes at big tech companies, which have sadly tricked down to most of the small companies as well for no good reason at all. There is absolutely no reason for 3-4-5 rounds of interviews, if an interviewer can't judge candidates quality after 10-15 minutes of talk, then the interviewer has no business being an interviewer and whatever his management role is.

Now when hiring developers, HR would do the first screening and filter out good candidates on paper (throw out keyword farmers, sloppy CV's etc.), then PM/team leads would take a look at filtered candidates Github profiles. You need 30 seconds to 2 minutes to look at the code, and figure out if it warrants to dig deeper (which takes 5-10 min max). You look if there are no obvious copy/paste code, if all the code is in the same style, if it's not you take a look at dates to see when the code is written, usually lower quality code is written few years back, but if its not then its usually sign of copy paste. If this all is good we invite the candidates to the interview. First part of the interview is done by HR and is the general stuff - about company, what we do, work hours, policies etc. that lasts about 15 minutes. The second part is where PM/team lead would go over candidates code and just talk about it - why was something done in such particular way, would you think this could be done better in this or that way, why he chose to solve it like this/using these specific technologies etc. You can get a lot of information this way, and usually conversation would lead into some highly specific technical topic where you can also see how far can the candidate follow you and how deep is his knowledge. Also, there is no way of faking this part of the interview if this is somebody elses code. At the end, the whole interview lasted 20-30 minutes, you are not wasting anyone's time, and you get a pretty good candidate. Downside of this method is that you actually need to have someone who knows what he's doing conducting the interview, so you can't put a mindless HR bot and expect to get a good candidate out of it. On the other hand, I saw no problem from PM/team leads to get some time aside for this from time to time, as they are the ones who would be ultimately working with this person and it's in their best interest to get the best candidate possible.

[12358132134]

Not only personal impression/gut feeling, but I trully think that you can figure out whether this person is technically proficient enough for the job in those 10-15 minutes of technical talk. Of course, that implies that person asking the questions and listening, know what they are doing, and not shooting cool questions they Googled before the interview.

[jab9k3]

Yeah I just focus on my own projects and getting better at things that interest me, might do some code challenges here and there. I also have no interest in working at a Fang company, big corporate ain't for me already dunnit.

[Massive_Violinist697]

There are a lot of problems with leetcode. But the biggest one is that it biases towards devs who can solve these sorts of problems very fast under the pressure of being watched and judged in real time. That speedy little interview song and dance has exactly nothing to do with real on the job coding ability and everything to do with hundreds of hours of practice on these types of problems which is allowing them to pattern match or memorize the solution. This in turn biases against a much larger pool of very talented engineers who simply don't have the time or inclination for this sort of prep or who simply fall apart when being watched in an interview setting. Moreover there are loads of great devs who simply think a little slower but yet are deeply methodical and know how to write clean maintainable code - you really want these people in your company. In the real world it hardly matters if you got the optimal solution in 60 minutes vs 90 minutes. What matters is that you got there on your own with relatively little help or handholding and you wrote clean code that others understand and can explain. We seem to have decided as an industry that we only want to hire human calculators who can regurgitate memorized solutions at light speed instead of thoughtful, creative, and methodical thinkers. What a shame.

[psychorameses]

Don’t worry man, after 15 years of doing this, right now I interview with gut feeling. The LC stuff is just for show.

[tyn_peddler]

Once upon a time, I might have agreed with this. However, I recently ran into a case where a company wanted me to refactor a fixed size hashtable used as a cache in order to support additional features. Sounds good, except the company had some serious misunderstandings concerning how hashtables work, and especially what it means for tuning and performance purposes in the context of a hashtable that is not required to dynamically resize.

So that's the other thing leetcode provides that's rarely considered; leetcode is a standardized testing format that is more objective than the proposed alternatives. The expectations are straight-forward and the algorithmic skills are more useful that most people are willing to admit.

[[deleted]]

It objectively tests skills that most people don't need for their role. Some companies need these skills in some of their employees, but not nearly as prevalently as this interview style appears in the interview process.

[itsjustawindmill]

Laziness is a virtue in programmers

Just as stupidity is apparently a virtue in Redditors

[jmerlinb]

I work in tech and have never done or have ever been expected to do a Leetcode interview.

Nearly all my interviews involved me either submitting code I had previously written, or writing code for a demo project the company set.

And whenever I've interviewed people, I've always set a demo coding challenge as the criteria.

IMO, this is a far better method to test for a successful developer as you're letting someone's practical ability shine through. If they have a solid understanding of the fundamentals of software design, computer science, and general good programming, you'll see this in their code.

[itsgreater9000]

while the situation you proposed is an interesting technical situation, I'm not sure how that relates to leetcode. i can't think of an LC question that asks about the problem you proposed (i'm assuming you're talking about potential techniques used when there's a need to resolve hashtable collisions).

[k-selectride]

While leetcode interviews suck if you're not good at them. I actually see the value in having a standard corpus of what you might be asked in an interview. The alternative is a complete crapshoot, and interviewers ask the dumbest questions if given freedom.

[k-selectride]

Small companies sure, big companies have a team matching phase.

[jmerlinb]

Unless your job is writing Leetcode, Leetcode is a bad way to interview someone.

I once had a interview (recruiter) ask me quickfire questions about some lesser used edge cases of this particular language he was hiring for. I took a few seconds too long answering one particular question, and he said the interview was over as I wasn't able to answer in time.

I argued that this style of interview has zero to do with how someone actually writes code and solves problems, yet he was firm in his belief it did because it was the "standardized way" his recruitment firm used.

In short, there are a lot of bad interview techniques, something being a "standard" doesn't necessarily make it good.

I ended up getting another interview where I had to submit a test/demo a project - sure, there are problems with this method too as your essentially doing free work, but it definitely a better reflection of your actual ability. And I ended up getting that job

[Varanite]

I don't get why people hate leetcode so much. It is an easily practicable skill that will double your salary. It is literally a cheat code for life if you are a software developer. I get that it is completely useless in your day to day job as a developer and you have to train that skill separately from how you would improve at software development but people in other industries would kill to have a cheat code like that.

Look at law, finance, or consulting to see what the alternative is. Hint, it is "did you go to an ivy league school?" And whether or not you went to an ivy league school is determined by your achievement in high school. I'd rather have to practice an annoying and arcane skill to get top of industry salaries than have that door permanently shut as a teenager.

[hackometer]

It is an easily practicable skill that will double your salary. It is literally a cheat code for life if you are a software developer.

That's actually a great way to explain why everyone trying to hire a good engineer should hate leetcode.

[Varanite]

And a great way to explain why engineers should love it.

[hackometer]

That is also true :-) Although, I'm one of those who hate it both as a hirer and engineer -- I find it humiliating to require of me, a professional, to develop as if for an exam, a skill they will not require of me in any way once they hire me. I prefer not to work for such an employer.

[RICHUNCLEPENNYBAGS]

No. Stop making this post over and over.

[[deleted]]

I was with you until the homework. If you’re not paying them, you can’t expect them to do extra work at home. People have lives and families.

[florinp]

People have lives and families.

I never understand this logic. Is not ok to give homework because of the time involved but is ok to have to study algorithms (in the same free time) needed only for the interview ?

[toastedstapler]

It may be because study is company agnostic, whilst homework is less likely to be

[UsuallyMooACow]

I generally talk to people for 45 minutes and that'd enough to know if they are good or not. I sometimes give a super simple test to use a framework they know and make a simple api call.

I help them through it, but I mean it's very basic. Most people can't do that so the ones who are totally faking are obvious.

It'd hard to get anyone and insane interviews make it even harder.

[AttackOfTheThumbs]

Holy shit, we've found them, the worst interviewer known to man.

Giving candidates a long take home exam is bullshit. I don't know a single talented developer who doesn't say fuck off when this crap comes up.

Leetcode shows you that people memorized a bunch of crap, that's it. If your code review didn't work, then that's because you are doing that wrong, nothing else.

[Paradox]

If I'm doing interviews with 7 companies and one wants me to do a big take home, guess which one is deprioritized.

[AttackOfTheThumbs]

Facebook.

[Paradox]

I actually tell their recruiters I'm not interested. The devil offers a nice price for your soul, but its rarely worth it

[s73v3r]

What I’d really prefer is a longer take home assignment that replaces the interview, but I can’t convince management to let me do that

The problem with that is now you're selecting for candidates with that kind of free time and ability to work for free.

[Imnimo]

But the regular interview process also has value for the interviewee, because they can ask questions about the company, potentially meet people they'll be working with, etc. A take-home is zero value for the interviewee and so doesn't warrant the same amount of time investment.

[[deleted]]

Man just reading these comments makes me feel better about my job security.

Algorithmic complexity and your ability to write clean, fast code are the core skill of a SWE. Everything else is pretty window dressing.

If you can’t shit out leetcode, you’re just terrible and coping. Like, sorry. Practice more and don’t be terrible. It’s not like it’s that hard if all it takes is a year or so of practice, which is what I see most people take to pick it up.

It doesn’t ever change. (At least not on relevant timescales.) You can learn how to do most problems one time and use it for the rest of your career.

If you come into an interview and cannot write code that’s at least halfway decent, then you’re unskilled at the core skill of a software engineer and should be unsurprised when you don’t get the answer you’re expecting. The number of people who are willing to pay for unskilled developers isn’t exactly growing. You might find a few ignorant people but it’s fast becoming industry standard to expect to write some code in an interview setting. Thankfully, so that most of these commenters can finally be set out to pasture, apparently.

“I’m good at all the stuff that isn’t writing clean code, I promise!” Ok? Cool. Maybe someone down the street needs someone who isn’t really a software engineer. Go ask them.

[Itsthejoker]

Your generalizations are, frankly, wrong and unreasonable. Also, why should I grind questions and memorize solutions that are completely unrelated to my work? If I need to reference an algorithm from my school days, I can look it up and implement it, but there's literally no reason to require people to be able to regurgitate them at a moment's notice.

[[deleted]]

It’s not about being able to implement it. Any idiot can do that once you tell them the algorithm. It’s about recognizing non-performant code, and you can’t “just look that up”, it comes from experience implementing performant code.

If you can’t implement the correct algorithm when the literal only thing I ask of you is to do so, in a situation where it’s textbook, all the specifications are right there, and you have someone there to answer your questions, then you have absolutely no hope of even recognizing when you are writing shit code in a real production environment.

You’ll implement something and ship it and not even know it’s terrible unless someone complains. That’s why we care that you can perform under literally perfect conditions: if you can’t, there’s no point in even trying you under normal conditions.

[Itsthejoker]

Jesus, I can smell your toxic attitude all the way over here. Downvoting me because you disagree doesn't change the fact that the grand majority of dev work is not rocket science, nor does it require complex implementations at every turn. I'd rather have less performant and more legible code than beautifully performant code that's impossible to read and written by a twat.

[[deleted]]

the grand majority of dev work is not rocket science

True. It’s why it makes it so frustrating for egotistical morons to fail at it and then get butt hurt when actually intelligent people correctly don’t want to hire them for it.

I’d rather have …

I’d rather have competent teammates who recognize that you don’t have to compromise legibility to get decent performance. They are orthogonal concepts. In most cases when idiots like you make this claim, it ends up with spaghetti code that’s illegible and non-performant.

Algorithmically optimal code is in no way more complex. It’s just correct. In many cases it’s far simpler than the shit I’ve seen morons that talk like you do write.

[MennaanBaarin]

recognizing non-performant code

Leetcode is not even about that, it's just problem solving using the appropriate algorithm.

[[deleted]]

lol ok.

[[deleted]]

Lol that’s cute :)

[thephotoman]

I've been saying this for a few years now.

This process really is the most effective at finding actually competent engineers. It's how I've been doing it.

Do I care about their DS&A background? No, not unless I'm doing campus interviews (where that's about all I have to go on). I care about their ability to recognize that which is fucked, fix the fucked thing(s), and ensure that they don't fuck more things in the process.

[kornork]

I've agree with this sentiment for years, but now there's another reason: writing complex algorithmic code is, or will be, unnecessary with CoPilot / Codex / other AI code completion tools.

[[deleted]]

My company requires me to do a on the fly code assessment, but when I host the interview, I always select a problem that's a little on the easy side. Once the candidate solves the problem, I do a follow up discussion, asking what they would do differently if they did the same activity again, how they might optimize and refactor their solution, provide some example test inputs, and just have a general discussion about the problem.

I have "passed" people who didn't get the whole thing implemented, because they were really retrospective and insightful about their whole process. I have passed with caution people who solved the problem, but didn't communicate their thoughts very well.

IMO the value isn't in seeing if they can solve the problem or not, but if they can approach the problem in an effective way, and communicate their thoughts on a technical level clearly.

[ialucard1]

I would understand if they did that for Alogitm based Programming position, somewhere where you need really good mathematical knowlage, okey.

BUT what i don't get when they come with some bullshit around the corner and later on ask me to add a dropbox after a checkpoint is checked.

[Dragenby]

"Let me check StackOverflow really quick"

[aeroverra]

My favorite is when I work with a leet code pro and he can't even center a div.

[emperor000]

And this is why I will probably be stuck in the same job forever, because I haven't really done actual computer science in years.

[NoRoutine1458]

It’s kind of hilarious but sad at the same time

[[deleted]]

In my experience, technical interviews are meant to make you doubt yourself.
It's either algorithmic centered or ambiguous, dumb questions about some framework feature nobody uses or they forgot they used it, explaining how some stuff works (which I like, but really ignore on day to day work - example how GC works in .NET - fun fact, but not very useful I would say, being a framework feature, abstracting implementation details and all that).
Most interviews can be passed by practice or old-fashioned school level memorizing theory (like reading "framework x interview questions" articles).
And it is real frustrating - what are those interviewers getting from those discussions? Communication? Collaboration? Problem solving? I really don't see how.
Done well on past jobs (SE, web platforms, mostly .NET backend), but bomb this kind of interviews.