This. Literally every problem in NP can be cast as a constraint problem. The question of whether a solver is the right solution varies a lot depending on the application, and in an interview , it’s almost by definition not the right solution.

They can also be dreadfully slow (and typically are) compared to just a simple dynamic program.

LeetCode problems typically are in P. The challenge is finding out why.

Yeah I think the trivial solution is always harder complexity and the main challenge is to lower it. Either from NP to P or from n*2 to n log n.

> or from n*2 to n log n.

I guess you mean n^2 (or maybe n**2, if you're a fellow Pythonista). Many of these — especially the ones where the intended solution is characterized as using a "dynamic programming" technique — are reducible to n.

If someone solves a leetcode hard with a constraint solver and you don't hire them, you are an idiot.

Do you know how few people in this world even know what a constraint solver is, let alone how to correctly define the problem into one?

I used a constraint solver to solve a homework problem once in my CS degree 3rd year. My god just writing the damn constraints was a huge cognitive load!

I did this, wrote an Essence-prime program to generate Minion solver code for a simple instance of the knapsack problem, as part of a startups "solve one of these and get an interview" challenges. Because I had used those tools recently for a contract job (and wrote/presented a paper on invitation of the solver authors,) I thought it would be fun and didn't really want the job. Got an interview but every dev was like "why did you use a cannon to swat a fly?" and were clearly concerned that without strict supervision I would create baroque towers of garbage for them to clean up.

I would like to believe that most people capable of writing a solver would appreciate simple code. It's like when looking at ffmpeg or some physic engine code. You know you'll forget the details easily so you make sure everything is as simple as they can be.

> If someone solves a leetcode hard with a constraint solver and you don't hire them, you are an idiot.

I do hope you're exagerating here, but in case you aren't: this is an extremely simplistic view of what (software) engineers have to do, and thus what hiring managers should optimize for. I'd put "ability to work in a team" above "raw academic/reasoning ability" for the vast majority of engineering roles, any day.

Not that the latter doesn't matter, of course, but it's by no means the one and only measure.

> I'd put "ability to work in a team" above "raw academic/reasoning ability" for the vast majority of engineering roles, any day.

In this hypothetical, why do you do leetcode hard interviews?

> In this hypothetical, why do you do leetcode hard interviews?

I thought I already answered that:

>> Not that the latter doesn't matter, of course, but it's by no means the one and only measure.

It is the only thing you measure when you do leetcode.

> why do you do leetcode hard interviews?

I don't. I do easy code interviews because there are people who work great on a team and know enough buzzwords to sound like they know how to write code, but cannot. Something that isn't hard to solve in about 20 minutes (I can solve in 5 - but I've seen a solution several times and so don't have to think about the solution), but is different enough that you haven't memorized the solution. If you can't solve an easy problem then you can't code.

Maybe because they are simplier to practice than working in a team?

One can be gifted while still producing code that the rest of the team can read.

OK, but obviously this presupposes a job where the hiring process is focused on leetcode.

Hey I'm with you 100% about the idea of code-interviews/leetcode being a problem and the importance of culture-fit and ability to work on a team.

I should have said "if you deemed this a fail on the code interview, you are an idiot".

I've won a couple hackathons with just CP-SAT & Linear Programming which led to my first jobs. I'm surprised not more people know/use it. Very inefficient compared to the "correct" answer but the development speed is much faster.

> If someone solves a leetcode hard with a constraint solver and you don't hire them, you are an idiot

Sometimes you just don't want someone that takes these shortcuts. I think being able to solve the problem without a constraint solver is much more impressive

This - the only downside to a constraint solver is it's usually slower. If you want them to write a fast algorithm, then specify that. Have an actual metric for it, if they can pass it with the declarative language, then great. If not, they should have written a more complicated algorithm.

you might be interested in trying out JuMP.jl. It's a Julia package that abstracts over constraint solvers and can do some very complex reformulations automatically to take the declarative definition of your problem and turn it into the types of constraints that the solver you're using supports.

Yes and no: I've asked questions like this in interviews, and I'd count it as a plus if the candidate reached for a constraint solver. They're criminally underused in real-world software engineering and this would show the candidate probably knows how to get the right answer faster instead of wasting a bunch of time.

Now, if they did answer with a constraint solver, I'd probably ask some followup whiteboard questions to make sure they do actually know how to code. But just giving a constraint solver as an answer definitely wouldn't be bad.

Yes, especially if the interviewee said something like 'this may not be asymptomatically optimal, but if it's not a known bottleneck, then I might start with constraint solver to get something working quickly and then profile later.' Especially if it's a case where even the brute-force solution is tricky.

Otherwise penalizing interviewees for suggesting quick-and-dirty solutions reinforces bad habits. "Premature optimization is the root of all evil," after all.

Using a bad algorithm when a good algorithm that is known to exist is premature pessimization and should be avoided.

There is some debate about what premature optimization is, but I consider it about micro optimizations that often are doing things a modern compiler will do for you better than you can. All too often such attempts result in unreadable code that is slower because the optimizer would have done something different but now it cannot. Premature optimization is done without a profiler - if you have a profile of your code and can show a change really makes a difference then it isn't premature.

On the other hand job interviews imply time pressure. If someone isn't 100% sure how to implement the optimization algorithm without looking it up brute force is faster and should be chosen then. In the real world if I'm asked to do something I can spend days researching algorithms at times (though the vast majority of the time what I need is already in my language's standard library)

IBO premature optimization is normally one of two things:

1. Any optimization in a typical web development file where the process is not expected to be particularly complex. Usually a good developer will not write something very inefficient and usually bottlenecks come from other areas

2. Doing stuff like replacing a forEach with a for loop to be 0.5% faster

Constraint solvers (or MILP solvers) while not asymptotically optimal are often as fast or faster than other methods.

> when a good algorithm that is known to exist

Sure, if a good algorithm exists and is simple to implement, then go for it. But if it is non-trivial, then you have to make a judgement call whether it is worth the trouble to solve in a more optimal way. You acknowledge yourself that that this can take days.

Personally I really have to be disciplined about choosing what to optimize vs what to code up quick-and-dirty. There's always a temptation to write clean, custom solutions because that's more interesting, but it's just not a good use of time for non-performance critical code.

General constraint solver would be terribly inefficient for problems like these. It's a linear problem and constraint solver just can't handle O(10^6) variables without some beefy machine.

FWIW, the OP's problem is not linear. It's an integer programming problem given that coins are discrete.

A trick if you can't do a custom algorithm and using a library is not allowed during interview could be to be ready to roll your own DPLL-based solver (can be done in 30 LOC).

Less elegant, but it's a one-size-fits-all solution.

You can implement DPLL in 30 lines of code? Not for SMT, I assume.

You'd need a fancy encoding for SAT to use a small DPLL implementation.

Otherwise, customize DPLL for this particular problem.

O(10^6) = O(1)

no, the "O" here is "on the order of", not Big O notation.

I believe NoahZuniga is perfectly aware of the intent and denouncing an abuse of (unneeded) notation.

What is "Big O" if not literally "order of"?

In physics "order of" means "approximately" using something like a taylor series, which typically start with a constant, then move to higher polynomial terms which add smaller and smaller corrections. Similar, but different, I think...

The O stands for "Ordnung", the German word for order. So it does literally mean that, except mathematicians think that the order of f(x)=1 is the same as the order of f(x)=10^6, because "clearly" f(x)=x gets way bigger than any constant function.

Okay, but who says you need to use a simple constraint solver? There are various sophisticated constraint solvers that know how to optimize.

At this point, job interviews are so far removed from actual relevance. Experience and aptitude still matter a lot, but too much experience at one employer can ground people in rigid and limiting ways of thinking and solving problems.

It’d be a positive in my book if they used a constraint solver.

You're right, but that just shows how fundamentally silly this interview approach is.

In any real engineering situation I can solve 100% of these problems. That's because I can get a cup of coffee, read some papers, look in a textbook, go for a walk somewhere green and think hard about it... and yes, use tooling like a constraint solver. Or an LLM, which knows all these algorithms off by heart!

In an interview, I could solve 0% of these problems, because my brain just doesn't work that way. Or at least, that's my expectation: I've never actually considered working somewhere that does leetcode interviews.

I was told to use ANY language in an interview. I asked them if they were sure, so I solved it with J. They were not too pleased and asked me if I could use another language, so I did prolog and we moved on to the next question. Then the idiot had the audacity to say I should not use "J and Prolog" but any common known language. I asked if assembly was fine, and they said no. Perhaps python or javascript. I did the rest in python, needless to say I didn't get the job. :-)

You're a hero!

I find it hilarious when people brag about stupid shit like that. Congrats on sabotaging your own interview process I guess??

If the candidate asks if you're sure you want them to use any language and you say "yes", and then get pissy when they do, the candidate isn't the one who sabotaged anything and they're dodging a bullet if they "fail".

I feel like I'm entering a whole different universe on HN. Maybe things are this equal and fair on the senior, high-paying part of the spectrum that most people here seem to occupy, but in general there's a huge power imbalance in job interviews. Unless you're special and the company wants you in particular, it costs them nothing to turn you down in favor of the other 10000 perfect applicants, while you must find a job to survive.

As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected. If this is dodging a bullet, then the entire junior field is a WW1 trench, at least where I am. Why would a company hire someone who gets 9/10 on the behavioral portion when they have a dozen other 10/10 candidates? Of course when the interviewer asks me to use "any language", I'll assume they want Python or Java or C++ or Rust, not Bash or ALGOL 68. Stepping out of line would just be performatively asking them to reject me.

I agree that doing that without asking if they really mean "any" would in fact demonstrate traits that might be bad for a co-worker.

If the candidate reads that this may be the case, asks for, obviously, that reason, and the interviewer confirms that they mean "any", then it's a red flag for that interviewer, at least, as a co-worker, if they go on to get upset over your choice, unless it's something where you're obviously taking the piss, like Brainfuck (the later suggestion of assembly probably counts as this, but at that point the interviewer[s] had already failed the interviewee's test of them, so, whatever)

But yes, if you're desperate for a job you should indeed just ignore any red flags and do your best to fit the perfect-cog mold and do whatever emotional labor is required to seem the way you think they want you to be, and take whatever abuse they offer with a smile. That's true.

Yeah, I don't mean to justify the actions of the interviewer, they were likely in the wrong here. It's just that, to someone in my position, it seems almost funny to be willing to throw the entire interview over something like that. It's them who gets to decide your fate.

Also, we can't know what exactly was said, so maybe miscommunication could be partly to blame. Like, "Are you sure I can use any language? (Are you really so gracious as to give me this option?)" vs. "Are you sure I can use any language? (Can I use something you definitely don't know?)"

> If the candidate reads that this may be the case, asks for, obviously, that reason, and the interviewer confirms that they mean "any", then it's a red flag for that interviewer

I think the confusing part to me is why a rational candidate would assume it'd be a good signal to use an esoteric language to solve a problem in the first place. Like my understanding is that J would be a pretty inappropriate choice if you were trying to demonstrate your D/S knowledge, which is typically what that part of the interview is meant to be for. Apart from the round of applause on HN they'd receive later for being so very clever, what's the actual benefit for the candidate for using Prolog or J?

If J is the right tool to use to handle a problem with, Prolog is an alright tool for that purpose, and Python is kind of a bad fit; why would you use Python instead of J or Prolog?

If I need to drive a screw I'll first grab a screwdriver. If that's not okay I suppose I could use a knife. A monkey wrench would not be among the first tools I reach for.

> Unless you're special and the company wants you in particular, it costs them nothing to turn you down in favor of the other 10000 perfect applicants, while you must find a job to survive.

This is not what you see in practice. Trying to hire, the view is very much different, in my experience. Every candidate has strengths and flaws, it's much more of a... constraint problem!

The idea that there even exists a perfect candidate is one of the biggest issues with hiring practices in tech these days.

I, for one, would be extremely impressed by a candidate breaking out J or Prolog for a constraint problem. But I'm also not a typical hiring manager for sure.

> Of course when the interviewer asks me to use "any language", I'll assume they want Python or Java or C++ or Rust, not Bash or ALGOL 68.

When I did interviews, I used to ask for “any imperative language”. Most people chose C or Java, some chose e.g. Python and the best solutions looked very different from the C/Java ones. I did not deduct points for either; a good solution is a good solution.

I once had a candidate that chose Oberon, because it was the only language they felt comfortable with (by their own account). They fell through on the interview for other reasons, but this seriously made me consider to what degree they had any programming experience at all outside a few select school assignments.

Independent of that, if someone came with a solution in a constraint solver, my next question would be (as it usually was, regardless of approach) “and what is the runtime complexity of your solution?” and I'd be impressed if they had any nonobvious thoughts about that!

Even in most used languages it's hard to be accurate without making profiling. And when using a framework, it's almost a garantee that you have no idea of the complexity under the hood of all the facilities you rely on.

But with an explicitly implemented algorithm, you can probably at least give an upper bound.

> the general feeling among my peers is that I must bend to the interviewer's whims

This is just conflict avoidance and naivety. After a while you start to realize that there's a whole world of people just like on HN and *we hire people too*. No matter what you do, youll end up in the place you deserve. If you try to be sneaky, you will end up working for people who are either easily fooled or see right through how to exploit you. If you let your nerd shine you'll end up with people who love your nerdiness.

> After a while you start to realize that there's a whole world of people just like on HN and we hire people too. No matter what you do, youll end up in the place you deserve.

I mean, I'm hoping for that too. But it also feels like this only applies as long as there's a balance of likeminded people who are already in the industry vs. the people looking to get a job. For someone like me, without a real network, meeting a person like the kind you mention is extremely unlikely. Even then, most of these people are looking for more qualified candidates, since there's an overabundance of juniors and seniority is a good predictor for being really passionate about their field. So, maybe I'll figure that out someday, but right now I just need a job, and what people in my cohort do is a way to try and get a job at all costs.

When I say "any language" when interviewing candidates, I mean it. I would be stoked if someone busted out J in an interview.

Of course, my team also writes SDKs in a bunch of different languages, so it makes sense. Even if that weren't the case though, I'd be stoked. To your point though, early in your career, I get your viewpoint. It's hard out there to get a foot in the door and you have to seize opportunities.

> As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected.

But interviews are bidirectional. The company is deciding if they want me, and I’m deciding if I want them. If I chose to use Self or Forth as the whiteboard context for the conversation we’re having, it’s deliberately to make the interviewer think, and hopefully learn. If the experience of thinking differently about a problem (that they chose!) and learning something new is a negative signal to them, that’s fine —- it being a negative signal to them is a negative signal to me, and I don’t want to be there anyway! If they’re excited, and intrigued, and give “12 o’clock” feedback — well, that’s the team I want to work with. So I’ve helped us both accomplish our goals (making accurate assessments about fit), and aligned our metrics along the way.

> I'll assume they want Python or Java or C++ or Rust, not Bash or ALGOL 68.

I've solved interview questions with one line of Bash before and gotten an offer. The question was something like "count all the files in this folder with a name ending in X". The interviewer was happy I had a quick solution and they could move on to talking about something more interesting.

The obvious ways to do this sort of thing in Bash have some nasty gotchas on non-standard filenames, though.

And a Python solution that avoids those problems is also quite simple and terse for the example you gave, and probably for most problems in the category.

> Maybe things are this equal and fair on the senior, high-paying part of the spectrum

I don't think the fundamental dynamics change by seniority, just that after some level there may simply be a smaller pool.

From the interviewers perspective, it makes sense to reject a candidate if they see any possibility it could be a flop. A bad hire is going to frustrate the team and look bad to the company, missing the best candidate is just going to result in hiring their next best pick.

> As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected.

I guess this is very context dependent but I can also see "bending to the interviewer's whims" backfiring if they see you're just trying to flatter them. I could see some interviewers valuing that you can explain your point if it's framed in a way that shows you are both observant and easy to work with. If it's framed as a more aggressive kind of pushback, yes that's going to get you rejected.

But yeah, I can also see that if you're willing to take any offer at any company as a junior just to get your feet into the industry most interviewers may not be specially smart and resisting is likely to go wrong.

Interviews go both ways ... I don't think they lost out on anything they wanted.

That is what people miss about interviews. Often when you interview you don't have reasonable leads on any other job and so you don't feel like there is a choice since you likely need a job (unemployment rarely pays as well as a job). However interviews are not only about the company deciding if they will hire you, they are also about do you want to work there and convincing you to take the job if one is offered.

So make sure you use those "do you have any questions" time to ask questions! What is it really like to work there. How much notice do you need to give before taking vacation? Do they really give pay raises? How often do they lay people off? What is the dress code? Do they let you take time for your kids school activities? And so on - these questions should be things that are important to you - find out.

In the best cases the interview is only about convincing you to take the offer - generally because someone who you worked with at a previous job said "hire this person" and they trust that person enough to not need any other interview. So keep your network open.

People don't miss that about interviews, they just know that the balance of power is so skewed that the interests of the employer become the only relevant part. The employer can keep going through hundreds of applicants until they find someone who's literally perfect in every single way, they have nearly unlimited time. Meanwhile, the applicants need a job now, any job at all, they're on a hard time limit until their money runs out.

I feel like in practice, unless you're an established, senior professional in a high-paying, in-demand field with a network to rely on, this would go something like:

> What is it really like to work there. How much notice do you need to give before taking vacation? Do they really give pay raises? How often do they lay people off? What is the dress code? Do they let you take time for your kids school activities?

"Candidate ABC seems too demanding and picky, constantly inquiring about irrelevant specifics. They would be a bad fit for our company culture. I advise going with candidate XYZ instead."

Maybe in some companies. Every interviewer I've talked to has never considered those a negative. Most don't even think of them at all once the interview is over. Of course I've always worked in companies where people work their 8 hours and go home to their family and so you would be a good fit (depending on what you asked).

I know applicants need the job more than they need you. However you still have options if you don't get this one - you should always be following several leads until you finally get a job. Odds are your other leads are not anywhere close to as advanced as this, but if you can wait a couple more months you have a chance.

I have to push back on the unlimited amount of time thing. Maybe in FAANG that’s true but in the places I’ve worked for, hiring is something that comes down from on high - someone tells us they need N bodies for some project, and we need to have a team hired by some deadline. We really can’t interview endlessly.

It's also very expensive to interview, since you're typically paying people who make over $100 an hour to interview people and review their code.

I don't mean that you're literally allowed to run interviews for years. I mean that companies can, if they choose to, interview people indefinitely until they find a suitable candidate. The company won't collapse if they don't find an employee by the deadline, it's not imperative to their existence, it's just a nice to have, a goal. Maybe some project or initiative doesn't pan out or gets pushed back if no one gets hired, but the impact of all that seems rather limited. On the other hand, my existence is fully contingent on finding a job, and if I overrun the deadline I have to find a place to work, I won't be able to eat and pay rent. My time limit is existential, their time limit is artificial and fully in the realm of planning.

Unless you are really desperate to find a job, there are definitely workplaces you would want to avoid. While a power imbalance does in principle exist, that doesn’t mean you usually have no choice at all. Of course that is less of a case when you just start, but in general pp can go around doing interviews and negotiating positions rather than just accept the first offer.

> they just know that the balance of power is so skewed that the interests of the employer become the only relevant part

That happens since people only apply to very well paying jobs. If you apply to shit enough jobs they wont be asking hard questions, and those who offer shit jobs will say "all the power lies with the employees, I have no power to make them stay or apply, I am social and nice to them and they still reject my job offer!".

Just give the companies what they want and they all will want you, it is that easy. If you try to give them something they don't care about, like a hiring manager giving you a smile and minimum wage, of course you will get rejected a lot. Give them what they ask for, not what you think they should want.

I’ve had some of my hardest interview questions come from the people who underpay significantly.

> So make sure you use those "do you have any questions" time to ask questions!

I started giving interviews again and im surprised how many people dont ask anything. I'm an IC, not a hiring manager, and only evaluating a specific thing, (technical assement) and still nothing really.

It just goes to show how skewed the power balance is right now. People are probably afraid to make an extra move that can deduct points for any obscure reason.

When I interview people I encourage them to ask any question they want and I make damned sure it doesn't reflect in my report to the higher-ups! Just imagine being in their shoes, you could be in the same position tomorrow!

Use the right tool for the job. Thats engineering.

Instead you insist we should solve a nieche problem with a ill suited tool, while inventing a costume solution when a standard solution exist.

This kind of tradeoff discussion is good to explicitly call out in an interview. I often say things like "if this were my own project I'd use X, but on a team I would probably try to find a library in a language the team already uses".

Bringing the team up on Prolog and integrating it into your CI/CD system and finding some way to connect it with other services is often going to be a poor choice, even if in isolation it's the very best tool for the job. And that's the best case solution - more likely the tests will be limited and not automated, the code review will be rubber stamp because only the author knows the language, and the code and deploy process will be a black box that everyone is afraid to touch once the author moves on.

Obviously in an interview none of the code should make it into production, but being openly pragmatic is still a good idea. And if you use an obscure language, you'd better have better than usual communication skills to concisely explain how the code works for someone who hasn't used that language before. I've seen it done well but it's difficult.

They dodged a bullet. It would have been hell working there.

What's the point of doing well if you already determined you wouldn't even look at their offer?

What's the point of wasting time? Walk out of the fucking interview then.

Why would you ever want to work somewhere that clearly employs such unqualified individuals? And not only that, but allows those individuals to be the face of their company to prospective hires?

A company's interview process tells you a lot about how the company thinks and operates. This was was surely a dumpster fire.

> Why would you ever want to work somewhere that clearly employs such unqualified individuals

Because you're unemployed and need to work to get some money.

Do you think you're a super intelligent person when you couldn't even figure that out?

It goes without saying that someone needing money that badly wouldn't do what the OP here did. Stop trying to be right and start trying to see the world for what it is. It'll help you do better.

Sabotaging? The candidate learned that their interviewers, and probably the company as a whole, isn't curious about languages or stuff that is outside of their wheelhouse.

What if the interviewers decided to ask the candidate about their language choice and trade-offs between different languages? Wouldn't that actually give them more signals into the skill of the engineer, rather than just blindly following their script?

Reminds me of https://aphyr.com/posts/340-reversing-the-technical-intervie... (and the follow-ups to it)

We had a programming language class at college and wrote the same program in everything from Java to Lisp. The lisp was way nicer.

:-) I would have hired you!

That's not a job you want.

You fired them.

I haven't been asked leetcode questions in a while and when I was asked, it was an easy level problem. I don't know where they ask hard leetcode problems, I also never solved a hard leetcode problem on my own.

The purpose of coding questions should be a problem that you can solve in about 20 minutes, then they ask another, and then you get 20 minutes to either finish or talk about other things. If you ask questions where either someone knows the trick and they pass, or they don't and fail you don't learn much. You need to watch the person write code to see if they are reasonable about it.

I'm routinely asked LC Hard questions in interviews. Sometimes more than one in one 45 minute interview.

That said, I interview in silicon valley and I'm a mixed race American. (extremely rare here) I think a lot of people just don't want me to pass the interview and will put up the highest bar they can. Mind you, I often still give optimal solutions to everything within good time constraints. But I've practiced 1000+ problems and done several hundred interviews.

Do you interview at startups?

Yes. I interview at everything from pre-seed to FAANG.

This is not how it works. The interviewer knows 1-2 problems and there is no time for profiling since they are rushing through their day, probably focused on their day to day work. You are the least of their concern, believe me.

Source: we am a hiring manager.

I’ve been the hiring manager too. You’re severely underestimating how many people operate.

I don’t think being mixed race is particularly rare in Silicon Valley?

Very rare. So is being American.

Absolutely not

Not sure about the timespan that you are referring to. Post covid hiring high, in the last 2 years or so, the hiring bar has been extremely high, in general. Not denying your experiences, may be it is even higher for you.

Personally, my experience has been that pre-covid, majority of interviewers were assessing your problem solving ability and if you can code the algorithm that you came up with. Getting the most optimal solution and fixing all edge cases for all problems in all interviews was not strictly necessary. But these days, even if you have the best solution coded up for 3 problems and missed one edge case in the 4th problem, you are not “good enough”. At one place, I was dinged for not thinking of the edge case before I wrote the program, even though I caught it while coding it up, in spite of having the write solution for the other 3 problems asked in the 2 coding rounds. It is a tough market, and probably tougher for you. Good luck mate.

I was once asked fizz buzz in an interview and it made me sad that some people don't pass it.

I guess when you're brand new you don't know about the mod operator?

Yeah I've interviewed people who didn't.

Did you finish the interview or just call it there?

Even if you don't know about modulo, or (floor) division, you could subtract in a loop and see if you reach zero. Obviously not a good approach, but would demonstrate the kind of basic problem solving skill and ability to "write any working code at all" that this sort of thing is supposed to screen for.

You could improve that and still avoid any division or modulus by simply keeping track of when the "next fizz" and "next buzz" should occur. (And output "fizzbuzz" when those numbers are the same and you reach them.)

But if you're brand new, you aren't qualified for this job. I guess it was a quick way to assess, if you can't solve this in 60 seconds, we can end the interview early? But I thought it was odd still.

I interviewed at an investment bank in London and they asked me pretty hard questions. One was to implement some multithreaded producer consumer thing in C++. I can't remember the details but it was... well you know how writing multithreaded C++ is. I was allowed to look up references at least. Took me maybe 20 minutes and the whole time the interviewer was just sitting on his phone while I wrote it.

Weird experience. Didn't get that job (probably for the best tbf).

If you wrote an MPSC queue (standard question) with multithreaded demo in 20 minutes in C++ you’re pretty hot shit, mate. Their loss. It’s not that it’s hard. But that speed without error is just really good. C++ is particularly unforgiving too.

I can't remember the exact problem or how long it took but it was definitely some awkward multithreading. I'd rate my C++ as pretty good but probably not hot shit!

He didn't get the job so changes are it wasn't correct.

More exactly, you can't invent algorithms on a spot which took who knows how many years for others to invent. I.e. the question ends up being more if you know about a specific algorithm, which results in "invent it if you don't know about it". It's absolutely silly to test for ability to invent one on the spot, so it's a pretty pointless interview question really.

You can for simple algorithms. It's just really easy for interviewers to overestimate how simple an algorithm is when they have been told the answer.

Yeah, that's exactly the point. These kind of algorithms are far from easy to invent even if they look simple once they are known.

I hate when it asks for a memorized specific problem, but most of the hard ones I found needs a clever twist of a well-known algorithm, and I still struggle at that too for hard LC.

Depends on your experience and what you’re interviewing for. At a high enough level, the questions are pulled from the easier side, and the interviewer doesn’t want you to fail.

> Or at least, that's my expectation: I've never actually considered working somewhere that does leetcode interviews.

Hrm. So what you're saying is you've never actually taken or given this style of interview. Nor presumably ever worked at a company that did this interview. So if on the off-chance these interviews actually were a somewhat successful tool for filtering candidates you wouldn't actually know it?

That feels like a miss.

Your criticism is valid.

I've also never worked at a place that uses beatings to improve employee morale. So, I can't guarantee that beatings aren't an effective technique for doing so.

lol.

My deeply unpopular opinion is that "leet code style" interviews are actually pretty decent at avoiding false positives. Obviously some specific questions are gotcha trivia and many interviewers are bad no matter the question. But they're a reasonably accurate proxy. Their issue is false negatives.

End of the day the ONLY question an interview sets out to answer is "will this candidate be successful in this role". Interviews are strictly a proxy for "the real job". So arguments that "it's not reflective of the real job" are utterly irrelevant. It is not possible for ANY interview to fully reflect the real job. And you can't ask someone to quit a steady job to trial for 3 to 6 months to see if they're a good fit or not. So we're stuck with proxies.

I definitely think it's important for people who are hired to write code to in some form demonstrate that they are capable of writing code. That seems reasonable. But we can't expect candidates to write a big project for every place they apply. That's too much. And almost all candidates can't share code from their prior job. And solo GitHub side project are quite frankly not relevant for 99.99% of candidates. (And maybe more).

The one tried and trued method of hiring is to hire people you've worked with before who were good. This is not scalable.

Hiring is hard. Really really hard. I find that the vast majority of leet code complaints come from people who don't hire. If anyone ever cracks the puzzle of how to hire better they'll have a monumental competitive advantage. Many many have tried. So far none of have succeeded.

It's a fair point; hiring is hard.

It's been a while since I had to hire outside your "people you've worked with before" bucket, but when I did, here are the two questions which worked best:

1. Tell me about a time you analysed a complex problem and came up with a solution.

2. Tell me something creative you did at work. Something you're proud of.

In my experience, a good candidate typically had excellent answers to those questions, because (1) a good candidate has had to do some real engineering at some point and they can tell you about it, and (2) a good candidate has done technical work which they're really proud of just in and of itself, and they want to tell you about it.

A technical question was useful in reducing false positives, but something a couple of steps above FizzBuzz should be fine for that. You just find out anything useful about a candidate by asking them to recreate some esoteric CS algorithm on the spot, unless you really need to select for people who can recreate esoteric CS algorithms on the spot.

This will be true in some interviews, but not in all.

I'm generally against using leetcode in interviews, but wherever I've seen it used it's usually for one reason & one reason alone: known dysfunctional hiring processes. These are processes where the participants in the hiring process are aware of the dysfunction in their process but are either powerless or - more often - too disorganised to properly reform the process.

Sometimes this is semi-technical director level staff leveraging HR to "standardise" interview techniques by asking the same questions across a wide range of teams within a large corp. Other times this is a small underresourced team cobbling together interview questions from online resources in a hurry, not having the cycles to write a tailored process for themselves.

In these cases, you're very likely to be dealing with a technical interviewer who is not an advocate of leetcode interviewing & is attempting to "look around" the standardised interview scoring approach to identify innovative stand out candidates. In a lot of cases I'd hazard even displaying an interest in / some knowledge of solvers would count significantly in your favour.