Расскажи о времени, когда ты убедил свою команду принять твой подход.

Question

Accepted Answer

Это проверяет **техническую убедительность**: можешь ли ты представить аргумент с доказательствами и убедить людей, оставаясь открытым возможности того, что ты ошибаешься? Убедительность — это не выигрыш спора.

## Как к этому подойти

```text
1. State the problem and the criteria for a good solution first
2. Present options fairly, including the team's preferred one
3. Back your choice with data, a spike, or a small benchmark
4. Invite critique — adjust if they find a real flaw
```

## Практический пример

```text
S: The team planned to build a custom job queue; I thought we should use an
   existing tool.
T: I had to make the case without dismissing their work.
A: I listed our actual requirements, built a one-day spike with the off-the-shelf
   tool, and showed it met every need with far less code to maintain.
R: The team agreed, and we shipped two weeks earlier. I noted the one case where
   their concern was valid and we documented the workaround.
```

## Хорошее vs плохое

```text
✓ Evidence + fair comparison + open to critique
✗ "I argued until they gave up"
✗ Pushing your idea with no proof
```

## Почему это важно

Хорошие решения требуют поддержки; отличная идея, которую никто не внедряет, ничего не меняет.

Лидерство с критериями и доказательствами держит фокус на лучшем результате, а не на том, чья идея победит.

Бытие действительно открытым возможности ошибиться — вот что заставляет людей доверять твоим выводам в следующий раз.