I wish we could stop to push candidates to do TDD or even asking questions about it during interview. This thing is a lie, has always been and will ever be. It is cool for small coding exercises but nothing else.
Let’s stop gatekeeping with stupid concepts.

Incorrect

@lungdart you will have to elaborate. I wanna know how you use TDD and why this is essential in your workflow.

How I use it is on the cover. I write tests, the tests tell me how to write the code.

I can fail and iterate much faster on design by building tests than the actual code base.

Ok but then how do you know if your inversion of the binary tree is actually working?

The gatekeeping again. I've heard it so many times this week, never before. It's also a youtube thing huh?

@Tounai when you're working with some application that goes through many development cycles, it pays to have component and integration tests guiding you.

My team maintains scores of data pipelines that gather from APIs (REST or otherwise), transform and load the data into our databases.
So tests for the gathering components allows us to detect poorly documented vendor API changes, and fix the right software artifacts.
Tests for transformations (mostly statistical analysis of the results) detect data loss or duplication, and ensure compatibility of the results with the target system.
Thereby, a proper test-bed helps a lot when maintaining a complex data pipeline.
And when dealing with known-format outputs (like when adding another source to an existing DB table), it is often better to write the test before writing the payload code.

Frankly, ultra-orthodox TDD is a bit much, but most of the principles can be applied in real life situations.

Gatekeeping in interviews is real, though.

@lungdart tbh i don't support the idea of writting tests first / TDD either.

it means i write ton of tests on "expected" behavior. then during implementation, discover the remote side behaves differently than was known and have to rewrite not only code but also ton of tests.

seems more practical to prototype operational code first and then cover it with tests.

+ i never really understood how can i write e.g. asserts on exceptions at a point where i don't know what and how i'll be processing