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.