A niche example of this kind of thing is when solving commercial/industrial combinatorial optimisation problems. Maybe the goal is to maximise profit or minimise capex subject to a large number of constraints. Sometimes it is intractable to solve the true problem, but there's some approximation of the problem by relaxing one or more constraints that's much easier to solve. In some of these business contexts its completely OK if the optimiser ran overnight before spitting out a solution, provided it found a 5% better one. In that setting it'd be natural to decouple the internal representation(s) of a black box optimiser from the high-level way you represent the true problem & its solutions elsewhere in the system.

Some of these systems might end up feeling a little like a compiler toolchain - high level descriptions of problems & solutions that get transformed into / recovered from lower level implementation-specific representations.

If your context has high performance needs, e.g. needing to solve the problem 30 times per second in a real-time game or control system, or react as quickly as possible in a low-latency trading system, maybe it could be less of a good tradeoff to introduce avoidable copying of data between a strict correct representation & a relaxed representation. Could write the clean thing first & then profile and see if the overhead of copying is relevant. If the representation of your solution is small, there probably isn't that much overhead in copying it, unless your performance needs are extreme or your hardware is severely limited.

What we were looking for

- people unwilling to admit they'd ever made a mistake -- red flag

- people who could reflect on the situation and say what they'd do differently in the future

- ideally, people who could use their mistake / failure / bad situation as an example of how they then took initiative to improve things by doing blah blah blah

People who were able to give an ideal response had clearly practised for this kind of question & knew how to play this part of the interview game.

Behaviours valued by one type of potential employer may not be valued by another. Small businesses & startups might value folks who take initiative and have a bias for action. In contrast, regulated megacorps might value folks who are great at consulting stakeholders and getting buy in before making changes, and steer clear of people they believe will go off and do stuff unilaterally.

One rule of thumb for handling these kinds of behavioural questions is "STAR" -- situation, task, action, result. Use the prompt for the question as a way to pick an example, then figure out how to frame an answer that shows you doing something to improve the situation. There's a fair chance that your interviewers are trying to mash your response into a STAR format in their own notes, even if they don't hint for you to respond in this way.

It reads as if the change was made to some library code that was depended upon by someone else's program that would "yay, done", which was in turn depended on by some workflow.

It's probably a non-starter to change library code so it hard fails if it detects its being used incorrectly, in situations where it previously ran and did something. That's a severe breaking change in behaviour.

Easing it in by printing a warning message sounds like a reasonable step toward hard failing. But then we get the situation yosefk relates.

allowing an AI agent to get hold of creds that let it execute destructive changes against production -- not a great idea

allowing prod database changes from the machine where the AI agent is running at all -- not a great idea

choosing a backup approach that fails completely if there's an accidental volume wipe API call -- not a great idea

choosing to outsource key dependencies to a vendor, where you want a recovery SLA, without negotiating & paying for a recovery SLA -- you get what you get, and you dont get upset

For anyone wanting to get into the weeds about detecting accounting fraud, the book "Financial Shenanigans" has lots of historical examples of ways company executives have cooked the books to make their public company financial statements appear more appealing to investors than they actually are.

Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs:

> For many years now, our Google colleagues on the teams supporting Java, Kotlin, and C++ have been using source-level inliner tools like this. To date, these tools have eliminated millions of calls to deprecated functions in Google’s code base. Users simply add the directives, and wait. During the night, robots quietly prepare, test, and submit batches of code changes across a monorepo of billions of lines of code. If all goes well, by the morning the old code is no longer in use and can be safely deleted. Go’s inliner is a relative newcomer, but it has already been used to prepare more than 18,000 changelists to Google’s monorepo.

It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.

see https://boardgamegeek.com/boardgame/822/carcassonne

e.g. https://www.minizinc.org/ offers a high level modelling language that can target a few different solver backends

might be pretty good results to completely ignore writing a custom algorithm and drop in an existing industrial-grade constraint programming solver, model your procgen problem using a high level language, and use the existing solver to find you random solutions (or exhaustively enumerate them). then more time to iterate on changing the problem definition to produce more interesting maps rather than getting bogged down writing a solver.

agreed. this also provides an explanation for the otherwise surprising fact that prey animals in the savannah have never been observed to naturally evolve ion thrusters.

Also, some of those legal moves will set up a board state that the player taking a turn immediately after you can exploit for a lot more benefit than you got, so not only are the legal builds hard to identify for new players, half of those legal moves are also traps! If new players aren't comfortable learning the hard way, the player who is teaching the game can always call these out, explain what is going to happen & give people the opportunity to redo their move.

An alternative strategy game that is less complex than Brass is Friedemann Friese's classic Power Grid (2004) [1]. It has some of the same elements (network expansion, building stuff to make money) and parts of it are highly interactive (auctions!) but it is less complex and doesn't feature so many negative player interactions. The main down side of Power Grid is that some of the "admin" rules are pretty fiddly, but provided there is an experienced player to teach the game & be responsible for the admin, players who are learning don't need to care about the details.

[1] https://boardgamegeek.com/boardgame/2651/power-grid