GildedRose-Refactoring-Kata VS unit-testing-tips

The problem is though how do you evaluate for real work without a portfolio of experience? Real work projects take weeks - perhaps months - to design, build, review and release. How do you test for that, really?

I agree leetcode style interviews are artificial, but I think they persist because few people have identified and popularised effective alternatives. At least with leetcode you've shown people in front of you have been prepared to go learn arcane stuff and apply it. It's not good, but it's better than nothing.

I was once asked to do the Gilded Rose kata[1] for one ~200 headcount Series D "startup", and it not only resembled real work - it's a refactoring problem - but it also showed their engineering culture. When I joined, I found smart people who weren't leetcode robots, but thoughtful engineers trying to solve tricky engineering problems. I "stole" Gilded Rose to use in other companies when interviewing until I joined my current employer (a FAANG, heavily prescribed process), with great success. I would like to see more katas that are as good at testing real world skills.

Also, something I've only ever been interviewed for twice in 25+ years, which I think is underplayed: pair programming and handling code review feedback. Do this more, please. If you hire people not knowing how they're going to respond to a principal engineer telling them "we need you to think about 4 other things that weren't in the original scope given to you by the PM, can you please go deal with them", why are you surprised when toys are subsequently thrown out of metaphorical prams?

[1] https://github.com/emilybache/GildedRose-Refactoring-Kata

Gilded Rose Refactoring Kata

While I recognise your post is about language-specific code-smells, your example reminds me of the GildedRose kata.

Nowadays, I think that the kata is much more widespread. It's available in plenty of languages, even some that are not considered mainstream, e.g., XSLT or ABAP. In this post, I'd like to do it in Rust. My idea is to focus less on general refactoring principles and more on Rust specifics.

You can also start with approval tests and try to reach 100% code coverage, then start refactoring. The Gilded Rose kata from Emily Bache explains this in detail (https://github.com/emilybache/GildedRose-Refactoring-Kata). Spending a bit of time on that kata can really help you tackling this mess. They have a video series of this kata on Youtube (https://www.youtube.com/watch?v=zyM2Ep28ED8).

Want to see more mid-level oriented tasks, look at Gilded Rose.

I did the Gilded Rose kata (as described here). Most places I've seen this discussed use an object hierarchy on top of the Item class, but I had a different approach in mind. Different types of handlers exist and they match to the possible items. This allows for easily adding new items with same functionality, or easily extending with new types of behaviour.

GildedRose Refactoring Kata PHP

I'd recommend you learn TDD, which is IMO an unvalued technique, but a very important one. You can check my tips for testing: https://github.com/sarven/unit-testing-tips there are also provided two very good books that will boost your knowledge about testing practices.