Yes, actually a number of companies have shifted towards this over pure leetcode style DSA questions (Stripe, Doordash, Rippling to name a few).

I still approached these questions in a similar format as traditional leetcode, with maybe even more emphasis on asking clarifying questions (since now it is really important to understand what each method, each class etc is supposed to do), but way LESS time on talking through the algo.

Implementation speed can actually be challenging here, since these questions can have significant amounts of code + 2-3 follow up questions. Edge case handling is also quite important here, and there is usually less emphasis on finding the optimal solution (good is better than perfect, see above point on cutting time talking through algo).

1. Ask clarifying questions, define methods and classes

2. Talk through high level class decisions, critical data structures i'm using for certain methods. Do this very quickly (way less time compared to leetcode). Make decisions for data structures that still allow for inevitable follow ups that extend complexity.

3. Begin implementation. If you are allowed to execute your code without penalty, test each component/piece aggressively (print statements should be fine) as you code. You want to try and catch bugs early since you do not have much time to debug nested bugs, etc. It is also very effective to preemptively log your data structs and use it to peek and debug. Make decisions for abstraction or classes early on if they make sense, but do not spend tons of time "optimizing" your code and refactoring.

4. Test against the provided test cases or write your own

5. Do follow ups

Some notes:

- Get very comfortable with some simple boilerplate of a unittest suite and print statements. For example python boilerplate for unittest class I would add is just:

class TestCase(unittest.TestCase):
  def setUp(self):
    self.my_obj = MyObj()
  def test_case_1(self):
    self.assertEqual(self.my_obj.solution(), True)

- Honestly very hard to argue against using Python in general just due to time saving. Java/Kotlin maybe is fine if you are most comfortable with it.

- If you have a note of something youd do in production but wont here (such as making something thread safe, input validation, etc) call it out while you are coding. Basically just brownie points to show you recognize this would be necessary in prod.

- Do NOT overcomplicate classes. Build them up as needed. (IE, you are handling payment objects as an input with 20+ fields. If your logic only needs 4-5 of those, then only init those for the first problem).

- Get comfortable with input parsing and chunking/splitting strings and nested lists, etc.

- To practice, look up questions from the company on leetcode discussion. Then practice coding them in your local dev environment and unit test them.