Poll: Is the leetcode grind necessary to land a high paying remote job?

>You start panicking and soon you have absolutely zero mental bandwidth to accomplish the task and your mind is basically singularly focused with getting out of this terrible situation

This is such a relatable description.

I don't think you even need a panic disorder to have this happen to you, this has happened to me a handful of times and it's absolutely the worst. It really is humiliating, totally ruins your day and you end up kicking yourself for several days after. I think this is just something that a lot of people do, like stage fright or something. The only way I know to avoid this is to do a lot of interviews with different companies that you don't really care about to get more confidence before you finally do get to the interview you care about, just so you don't choke during the one you want.

Meanwhile on the job nobody is surprised or angry if you need to look up basics because they know you have five languages under your belt and are actively using three of them.

I experienced this recently in a surprise 'shared screen' coding exercise the interviewers threw in at the last minute.

I couldn't even remember how to write a for loop in bash, something so familiar it would be like asking me to recite the alphabet. Utterly humiliating yet comical experience looking back.

> Basically for some random reason, the thought pops into your head just how disastrous it would be if you failed at this thing you're being asked to do. Then your consciousness inevitably becomes obsessed with this thought and it's all you can think about. You start panicking

This happens to me all the time! You’ve described it so succinctly. How do you cope?

This topic of “is leetcode necessary?” and the more general topic of software engineering hiring practices appear regularly on this forum, but this time is the first time I am seeing someone mention panic disorders/panic attacks as part of the interview process. Other people might have mentioned it before here, but I do try to peruse the threads that relate to interviewing.

I am really grateful that you brought up this point as well sharing as your own experience 'ryandvm. My own experience when I fail to think of an answer to a leetcode question is extremely similar if not identical. I would add that my own experience is always a silent panic similar to how I experience going on a rollercoaster. Many people will scream out loud when they are going down a rollercoaster; I just clench the safety/restraining bar really, really tight and look onward while clenching my teeth. I am surprised that it took this long in my career to hear similar feelings expressed by someone else, but I am grateful that it did.

Thanks again 'ryandvm! I really appreciate it.

If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team? Stressful situations can occur in software engineering, including for example a moment where you realize production services are broken because of code you just deployed.

> In my opinion, it is borderline disability discrimination.

This rings pretty true to me, thank you for sharing your experience.

> Basically for some random reason, the thought pops into your head just how disastrous it would be if you failed at this thing you're being asked to do.

Like a driving test and the training with parents/adults beforehand.

Even with some judgmental/skittish passengers its the same.

> If I pass a coding test, stay at a company for a year, then apply to other companies, I'm going to subjected to coding tests even though I just passed one only a year ago.

Well it’s not like the company you’re applying to has access to the test results from the company you’re leaving

> It's like companies are afraid that programmers will spontaneously forget how to program.

To be fair, I think most leetcoders agree that you need to practice regularly to keep your skills up. So if the point is to see how good you are at thinking algorithmically for the job you’re applying for, it makes sense that they’d want to see recent test results.

> We need a credential that counts as passing a technical interview

So we could call that a degree? And have institutions that specialise in testing for it? And because some of those institutions will be better at measuring this, we could rank them?

I thought most people complaining about the current approach didn't like this one either.

I think that most people here are mistaking the finger for the moon. If discrimination is really the reason why we have this kind of interviews, the problem to solve is discrimination and not the hiring process that is attempting to fix it or to hide it.

A qualitative hiring interview would be perfectly fine if the interviewers had no discrimination in their minds. The real solution is having minds without it. It's probably a goal hard to achieve with grown up people. Easier with newborns. So any solution starts from their parents, grandparents, etc and will stretch over many generations. Education, mingle with people from every origin and background, etc, pick your favorites.

How many generations? Limiting ourselves to the USA think how long it took for women to get a vote since the Constitution and for an Obama to become president since the end of slavery. We can hope that the trend is accelerating but who knows what's going to happen next. The state of the rest of the Western world is not so different.

This is the optimum. Now the good because there will be interviews to do this year. Any stop gap solution would do but don't invest too much into it because if you don't remove the real problem any fix will be worked around.

No. One of the reasons those leetcode interviews happen is because existing credentials, such as a bachelor's degree, don't work. Adding another one that some hirers will value highly and others will be skeptical of doesn't solve anything.

What we really need is for companies to stop trying so hard to find the absolute best most perfectest candidate that they screen out huge numbers who could have done the job but who missed some arbitrary keyword or coding test by a fraction.

> We need a credential that counts as passing a technical interview

This idea already exists in many forms. Pick any language, platform, or technical concept and there's someone offering training and certification.

It also describes the whole recruiting industry. "What if there was one person who did a lot of interviews and then presented just the best people to employers?"

It's an extremely human incentive alignment problem. Any certification program, interview farm, or bootcamp that makes more money when they produce more candidates will make quantity the goal, not quality. If you can figure out that problem, maybe there's a niche. Otherwise, it puts us right where we already are.

> We need a credential that counts as passing a technical interview, so we don't have to take these tests for every single job that we apply to.

We could call this a degree, perhaps in computer science?

This seems like an excellent idea!

Unfortunately my CS degree from a very-top school (CMU) counts for nothing in so many companies.

But they do forget how to program. Or maybe they never knew and got lucky to get the previous job.

Why don't they just use the computer science GRE?

I don't think that much thought has been put into it IMO. It's cargo culting the google interview process, and no standout success since google has a very different interview process to cargo cult copy.

Google had this process because they are very academia inspired and want to hire the best academics, with a college campus but better work experience, because they had very high back end scale requirements, where algorithms do matter. They also had a shit ton of applicants and favored the false negative over the false positive, which they explicitly and publicly state. You might be able to argue that scale doesn't matter as much at google anymore, but google has no reason to change its process since it first established it, and back then they really had those hard scaling problems to scale up.

The reason why the software profession tends to have extensive interviews is because we don't trust credentialing or even prior experience. [0] We don't want to hire the unskilled bozo who can talk and have brand name credentials but when you actually put them to work find they are not that good at all. So we actually test their skill as directly as possible with various forms of work sample testing with as long as an interview process the market will tolerate, which has stabilized to 5 - 7 hours, or an entire working day.

The beauty of this is that you don't need to get into a med school equivalent with it's crazy requirements, spend 10 years-ish of training and go into 6 figures of debt, get a residency / hazing ritual in a few limit slots in the USA and can come from almost any poor background or country even and eventually make more than most surgeons. In that light, needing to spend 3 months to hard core leetcode doesn't seem so bad.

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

It's very rare that people intend to be racist. Rather, they have intuition of what a "good programmer" is in their head, which is subjective, and thus more likely to be discriminatory. If you give them an leetcode question and a rubric to grade their performance, it's hard to deviate from that rubric to much unless if you're intending to discriminate.

>Does a biotech company make their interviewees do lab work live?

Not biotech, but according to my cousin, pharmaceutical research interviews are even more arbitrary. He had chat with 5 employees who asked questions about their own rather esoteric specialties. Most of the questions were completely unrelated to the work that he ended up doing, and my cousin thought that the interviewers themselves were unlikely to be able to answer each other's questions. Unlike leetcode, this isn't something you can predictably study. It just so happened that the labs my cousin had worked in happened to specialize in those same niches. There are so many qualified postdocs that want to move to industry that interviewers can afford to be picky.

It is common for up to mid-level jobs in finance and consulting to require doing on-the-fly modelling and analysis in Excel. I am pretty sure things like structural, mechanical, or chemical engineering also have substantial technical components to their interviews. While it is not done directly by the employer, board certification for doctors entails 8 hour long tests. Similarly, tradesmen like plumbers and electricians require in-depth written and practical tests for licensure. You can definitely dispute the practicality of these for the job vs. leetcode, but I really don't think that the rest of the world is getting jobs with a resume and a firm handshake.

> What makes software engineering so special that we need a different interview process?

The combination of absurd profitability (of which the tiny slice allocated to employees still seems like a lot) and a complete lack of any actual objective measure of quality.

Because there's no way to really test whether someone is good at programming other than hiring them and seeing how it goes, and because there is an effectively limitless amount of money to spend trying to organize a "solution" to this problem, and because learning enough about each candidate to make a properly educated guess doesn't "scale" enough for fast-growth companies, senior management has plenty of room and lots of incentive to look like they've got it figured out.

For some, this is following their creative whims; for most, it's "do what FAANG does because it must be working, look at all the money they make."

Anyway that's my opinion on it. If I ever have the power to change hiring at any large scale, I'll probably follow my own creative whims and make it even worse.

Giving each applicant a tailored test also opens yourself to allegations of discrimination.

As for leet code vs an actually relevant test - I think this is probably laziness on the interviewer's part. Coming up with a good test (and keeping it up to date) is hard, and leet code questions are "good enough" to filter out the people who don't know what they are doing. Remember, most companies are fine with a high false negative rate if it keeps false positives low.

> Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.

I'm sympathetic to the hiring side argument. But, I don't think the parent comment is insinuating that no technical question or test be asked of the applicant. They're not insisting on trust, they're insisting on showing their own intelligence. They're saying that the test or technical question should be directly applicable to the job at hand, for the company at hand. You can just as easily ask every single person who applies the same specific questions for the role at hand in your company. You don't need to rely on generic leetcode questions if they don't specifically apply to the job at hand.

In other words, hiring needs to actually be specific and targeted rather than adopting the "cast a wide net and catch whatever we can" strategy that many places seem to employ.

9/10 it feels like the insistence on leetcode from hiring comes as an excuse for rather weak recruiting standards and practices.

Leetcode or "just trust me" feels like a false dichotomy.

Biotech interviews, for example, are usually conversational: what have you worked on before[0], how would you tackle this new problem, or troubleshoot a particular problem. There's this persistent meme that charlatans can BS their way though such an interview, but I really don't see how someone could learn enough to parrot their way through 4-5 x 45 minute meetings, often with fairly probing questions. It felt quite a bit like a thesis defense, in fact.

It's true that these aren't "repeatable": each applicant won't have exactly the same experience. This is "unbiased", in a sense[1], but has enormous variance: you're not only testing the applicant's aptitude, but also whether they've encountered this particular problem before. OTOH, tailoring the interview to each applicant' strengths might inject a little bias in exchange for a massive reduction in variance.

[0] It does help that candidates for these jobs had masters/PhDs, and therefore had at least one project they could discuss publicly.

[1] But not really...There's a subjective element to "code quality", fluency, whether the applicant wrote "enough" tests, etc.

> We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.

One of the things that gets me here on the hiring side is that the ease of “grinding leetcode” as a strategy seems to defeat the entire purpose of it as an interview question. I don’t want to dismiss the value of someone being able to study a skill and learn it, but I see a lot of people fixated on rehearsing leetcode answers like they were magical incantations you recite to get jobs, there’s not always a lot of real learning happening. That’s not reflective of the kind of candidates I’d want to hire or the peers I’d want to work with.

> A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.

If true I’d like to see more of this. No hiring process is good for everyone and I think flexibility can be a better way to make a process fair, but I haven’t seen much of it personally. I don’t think I’ve personally gotten a leetcode problem at an interview in years- takehome problems have been the more common screening tool, but I don’t think I’ve ever been offered a choice in the matter.

> The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.

I’m not sure this is entirely on the mark. On problem with takehome a is asymmetry. Most take home assignments I’ve gotten have come toward the end of an interview process, and there fine, but when I talk to more Junior folks it seems like they are often given hours long takehome problems before they ever talk to a human. That seems disrespectful of peoples time- it’s a lot to ask from someone who doesn’t even know if they are a fit or want your job yet.

In any case the hours long takehome is usually in addition to an bourse long set of interviews- not in lieu of them. Another common problem pre-Covid was that a lot of people just weren’t set up to work from home so it was harder to get the space and time to work on a project at home. I expect that’s probably changed a lot these days though.

> The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.

I personally like take-home problems. It's hard for an employer to time-box them without resorting to basically leetcode though. I know that, as a student, I definitely spent many hours on them.

> A lot of HN commenters advocate for a “just trust me” hiring process where they want the interviewer to just read their resume and have a quick chat to decide if the person should be hired

That's how your manager is going to be hired, as well as all of his bosses on up.

The issue with take homes is that they are at the beginning of the process where you might have hundreds of candidates. I won't invest several hours in that. Whereas on-sites are the last stage in the process, so it's better than 50-50 that I'll get an offer out of it. So in that case I'm happy to take the time.

Ace Greenberg from Bear Stearns (former US investment bank) used to say the trouble with hiring friends and family: "You get 100% of the dummies." Sure, you get a few good ones, but you also get the lousy ones.

Almost nobody is productive past the 30 hours a week stage (excl meetings and lunch hour and whatnot).

Finding people with too much free time is the entire point of leetcode. Companies want employees who will dedicate their life to their work. If you don't have time to grind leetcode employers feel that you won't have time to work 60 hours a week and spend your free time thinking about work.

There are boot camps for developer interviews now. The practice is bad and it is inhumane. They will eventually go the way of other unintended gatekeeping disasters like the standardized high school/college tests.

The practice is just a veiled hazing ritual meant to strip you of dignity and agency.

If it isn't meant to do that...well, guess what? That's what it is doing.

And if I study real hard and maybe take a boot camp, I can join one of the illustrious paragons of internet virtue such as Facebook (sorry, meta block chain addicts inc.) or Google to spread ad-tech throughout the known universe.

"people who dedicate lots of time to development outside of work burn out around the senior engineer level"

Word. I left the industry to sit around my farm and raise my kids for about ten years. When I came back and started working with people I was shocked at how long it takes to learn anything about tech on the job. I was working on my own trying everything while I was away.

I noticed that my "senior" co-workers who had been working the previous whole ten years knew far less about the inner workings of the various tech they used daily than I did. I would rattle off something and expect a comment or answer and would repeatedly see architects and lead devs freeze up. I watched as they completely botched implementations simply because they didn't read the manual. The surprises were many because they used the same mental model to understand everything.

One implementation with a vendor required socket programming. They snapped and threw up their hands immediately in a big huff. I pointed out that C# had libraries to support that and that it was fairly trivial and probably way more fun than consuming a HTTP API. It took a few of us to calm them down and get it working but the dev who was assigned to it continued bitching. They were incensed at having to program against a TCP stream. It was so easy and trivial (imagine a binary string the size of an encoded JWT). He fucked it up bad and blamed the network for weeks.

In another instance, they were having trouble selecting a protocol for an external message passing framework. After selecting one at random I started asking about the protocol, mentioning that it sounded like it was based on "remoting (RMI binary non-routable transport). They had no idea. That concept of not having any idea about the underlying libraries and tech they selected was spread across an entire project, causing many real life disasters.

This all worked out great for me because I got use my deep knowledge a lot to identify root causes and fix thier messes which led to mahoosive salary increases and bonuses.

These bros were trying to leetcode everyone they hired. I couldn't do fizzbuzz to save my life. Just not interested in it. Is leetcode a filter to make sure you can work on the same old boring shit without losing it?

> Why is the junior dev in charge of something so important?

I think you are blending all of those problems together (there are three - hopefully not all of them at the same time... that would be a worst day ever). It's pretty normal that someone can't get to work, and you end up with a last second scramble to get something fixed. When something ships into production and is buggy, what matters is fixing it quickly.

The point is that most developers do end up having to work under pressure from time to time, and the higher up you get, actually, the more critical it will be.

What do you do when that fails?

How are all these people that are unable to get an ID able to finance a car, pass an apartment background check, open a bank account, buy alcohol, obtain govt. assistance etc?

In order for me to add my family to my insurance I had to provide identification for each of them, including a marriage certificate and drivers licenses for myself and my wife. All that just to get health insurance.

In order to vote you should have to identify yourself and that you are eligible to vote in a US election. It's complete nonsense that getting an ID in the US is just too much of a burden.

Can you actually name a specific town/county that has this problem or is this imaginary?

In public opinion polls black voters strongly favor voter ids.

data shows that minorities are in fact much less likely to have government ID.

The study you provided was a phone survey of less than 1,000 people that occurred 15 years ago. It along with other studies showing similar results were debunked by researchers at Stanford, Yale, and the University of Pennsylvania.

http://stanford.edu/~jgrimmer/comment_final.pdf

Google "hardest test in finance" and the CFA exams are the first several pages of results.

I would say going further back in time, for example, MSFT during the early 2000s, the interviews were far worse, it was "fermi" types of questions (e.g, https://www.innovativeteachingideas.com/blog/an-excellent-co...)

Often the same thing in for example, typical wall street firms before 2008.

> You can still write Javascript and solve business problems without knowing those things.

It depends what the requirements of the role are. For some frontend React work maybe, but the engineers we were trying to hire would be working on APIs and processes that handle high volumes of streaming data. In that context using sync methods over async would significantly impact throughput.

When asked "why are you using a sync method here" the answer would often be "I want the code to pause here before the next line executes". It's a fundamental misunderstanding of what's happening under the bonnet that IMO is required for this sort of task.

Also - I agree that labels like "mid" or "senior" shouldn't carry a specific list of knowledge requirements, but they are useful to set benchmarks for what a candidate should be able to roughly offer in exchange for the level of comp they are requesting.

If you don't know the difference between sync and async you're not qualified to solve problems with any realistic level of scale (>10 concurrent users which is a very low bar) or complexity (have you really never had to code logic that uses 2 or more concurrent network calls?). Might be excusable for a junior engineer but definitely not someone who describes themselves as senior.

I should have clarified in the original comment: the roles all had python experience as a specific requirement and some of the candidates apparently had multiple years of experience with Python listed on their CVs.

Depends on whether the candidate claims to know Python on their resume. If they do so, I'd certainly expect some basic ability to read such code.

Almost all big companies let candidates choose their language for the interview, with assumption it'll be python/java/c++ or similar mainstream lang.

For starters having a masters or PhD implies _less_ programming experience, generally speaking. Its a huge plus for a variety of positions but IME PhD or masters candidates were always a little more raw engineering wise. The way you get good at coding solutions quiclky and on the spot is by writing a lot of code.

You’d pop that bubble in a few directed questions wouldn’t you?

wouldn't be surprised people miss the SQL question. Full stack devs are rather rare nowadays, and it's a bit obscure SQL trivia considering the answer is dependent on which SQL db you're using.

On LinkedIn, FB employees have Meta now; Google employees still have Google.

It reminds me of Pacino in Scarface. Chichi get the yayo MAANG!

Does it really matter enough to correct people? Call it fang, faang, fang+, mang, maang, maaan, top tier companies... They all mean the same thing.

NAAAM, a tour in NAAAM

AMAAN!

I still don't know if I'm reading amen or a man.

Triple A could work as M3AN.

The more studying you do, the more likely the interviewer asks a question you've seen before.

> Anybody with sufficient interest can find the time to get to a basic competence level in leetcode and system design.

OK. But, it has nothing to do with interest. It's time (which may already occupied with working long hours or a second job to pay off debt or looking after family). Who has extra time to perform leetcode tasks that have no alignment to day-to-day tasks and expectations. People with the luxury of free-time, thus attracting a certain type of profile.

> Getting real life experience or a college degree has got to be the bigger gate.

You don't just get a job doing leetcode. The experience and/or degree are table-stakes. The OP post is asking folks who likely already have experience or a degree related to the field of software engineering.

But how often are you actually writing an implementation vs. calling a method from a graph library?

Knowing when you need a topological ordered list of vertices is (in my opinion) more useful than knowing how to implement tsort.

> However, I find these distractions are much stronger correlated with a person's economic situation rather than race or gender.

Which changes nothing when its a 99% correlation by race and gender.

Its not a dissertation, its acknowledging that something has the result of marginalizes groups disproportionately. Disproportionately means that it doesn't affect everyone, it doesn't 'affect all women and all minorities. It means disproportionately affects, due to their disproportionate representation in these distracting economic circumstances, so lets do something else instead since the reasons why it affects them isn't going to change in our lifetime.

> Also, I agree with the parent of your comment where the time spent with leetcode is a small fraction of the time needed to learn CS fundamentals

If people got formal education they took the risk for that allotted time. It doesn't matter if a time-discriminatory process takes less time, its an additional and unnecessary risk for the candidate.

If people didn't get formal education then they didn't take the risk for the allotted time, they just have exposure to the tasks the company needs. That alone suggests more inspiration is needed to have a different way of determining their compentency.

It depends on the market and your skillset. You can test the market right now by polishing up your CV & profile (LinkedIn is actually a good source of leads), getting in touch with some recruiters and seeing if you can get some offers, and adjust your rates & risk tolerance based on this.

At least in the UK, the contract market seems quite good for this early in the year, and usually peaks around summer. YMMV.

It obviously depends on your situation and whether you have any responsibilities; my opinion would probably be different if I had a family, but in my case I have little to lose even if things go sour. I won't be able to do this forever so I make the most out of it while I can still afford the risk.

It's always good to have a financial buffer, but I've never really needed it. Recruiters find me on LinkedIn and call or mail me. I generally blow them off or ignore them, unless I'm actively looking or they have something that catches my eye.

I suppose I could do my own acquisition; cutting out the middle man would probably increase my hourly rate, but that's a lot of work I don't like, and this works well enough for me.

Sure but even then it's low compared to being a senior at FAANG and publicly traded startups, no? (ie $300k+ annually when RSUs are factored in) Especially when you factor in the job risk and lack of PTO (even ignoring lack of health insurance cause in many cases your spouse can cover that)

I personally would like to get to $175-$200 an hour as then it would truly be competitive with the above, but not sure how to get there

Having a UK limited company when your tax residence isn't in the UK is quite complicated. I actually had a tax advisor strongly advise against doing that when I left the UK.

Average day rate for a big consultancy is well over £1500 a day (https://www.linkedin.com/pulse/comparison-day-rates-between-...). Basically anybody you know who works for a semi-legit consultancy is being billed out at over £1000 a day.

Its super easy to get £1000-1500 as a freelancer who handles your own sales if you have the right credentials (degree, +5 years experience, do not completely suck at programming, specific domain experience, etc).

But yes, there is a whole industry of middlemen who try an convince suckers to work on a contract basis for around £500 a day.

To be fair it is possible, I occasionally see 1k/day rates but they require either niche skills, a significant amount of experience or just seem like a terrible idea that's guaranteed to fail and you'll take all the blame for it.

In contrast, half that is doable for any mid-level developer and is still a major lifestyle upgrade compared to permanent employment.

That sounds an awful lot like panic not incompetence.

In this case if you look it up on MDN you'll see that Math.max(...arr) isn't recommended for large arrays (ask me how I know)

But if you can grind these what's the point then? All I'm doing at work is building glorified crud apps. I'm sure it's what many, many software engineers are doing. Not all, but many. My understanding of e.g. Django is much more important to my daily work than being able to come up with the fastest way to find a maximum value in an array.

That's my point, those questions are pointless. They don't show anything meaningful besides someones ability to learn a lot by heart. I mean, just based on the fact that someone asked if it was necessary to grind leetcode questions shows that you cannot gain any meaningful insight by asking questions like that.

I have ADHD, I'm glad I can remember to not put the underwear on my head instead of where it belongs. Of course I can't remember how a for loop looks like, that's why some nice people invented code completion.

Conversely if I saw someone use a for loop (especially one with mutation) where a trivial usage higher order function existed, and I was giving a “leetcode” interview (which I refuse to do), I would take it as a signal that there is an important missing concept if it were not corrected when prompted.

The idea that “reduce” is language specific is frankly mind boggling. It’s no more language specific than a loop.

I am talking about my own time and resources, not those of a computer - say, it might take ~one hour to come up with a solution for problem x. It might very well be not the best solution either, just the one that works okay (we've all been there). Or I could look up what other people have done in 2 minutes - say I'm comparing solutions too, that would make it 10 minutes. That's 50 minutes of work I can spend elsewhere. Much more efficient.

As someone who prefers constructs like map, reduce, etc to loops this is a key example of why it’s important to a) ask why the candidate went that route and have a conversation about pros and cons and b) recognize that this is one of those no right answer opinion things and not hold it against them if they think different than you

Mind you I’m talking in general and now in browser specifically

Explicit loops are only more readable in languages that suck.

That implicitly calls Function.prototype.apply(), which will fail if given more arguments than an implementation-specific limit (https://stackoverflow.com/questions/22747068/is-there-a-max-...). Looping with reduce() avoids that restriction.

Last time I had to do one of these idiotic challenges (on Triplebyte), I had an in-browser text box for code input, and a set of tests (some hidden) as the output on the right. I had no debug capability, no log, no feedback of any kind besides clicking the "run" button and seeing if tests pass or if it doesn't compile correctly. Of course I failed the challenge, because the way I write code is to take a first try, inspect errors, step through lines, and refine to get it as it needs to be. This was all impossible in this "environment" I was forced to use. Even worse, it has a timer ticking down the entire time, taunting you as you come ever closer to "failure".

What a miserable excuse for a test of my abilities. I will refuse to complete these challenges as a matter of course, and encourage others to do so as well.

> I would try and ask a question that was very unlikely they'd know with the focus on how well they communicated their thought process while working through the code.

I'd probably do something like that. No actual writing code, more of a discussion with them about ideas for solving it. I'd try to let them take the lead on approaches, just adding ideas to keep things moving if they were getting hung up on something.

After we've got what seems like a reasonable approach and I'm sure the candidate understands it, I'd then have us take a quick look at the official solution and see if it is along the lines of what we came up with.

Finally, I'd go to the discussion area for that problem and take a look at a few of the solutions posted there and ask the interviewee to help me do a quick code review of them.

The discussion areas for Leetcode problems are an often overlooked resource. They are full of proposed solutions with all kinds of issues. Sometimes they just won't work. Sometimes they solve the problem but don't meet the time or space constraints the problem asked for. Sometimes they work except for edge cases.