Это короткий список в основе которого лежит старая статья
и новая. Я надеюсь кратко покрыть современные аспекты при выборе компании.

Joel Test: 12 Steps

• Вы используете гитфлоу (аналоги?)? Do you use source control?
• У вас есть ОДИН скрипт для запуска приложения? (Can you make a build in one step?)
• У вас настроен CI? Do you make daily builds?
• Вы фиксируете баги? (Do you have a bug database?)
• Фиксите ли баги перед новой фичей? (Do you fix bugs before writing new code?)
• У вас есть актуальные даты запуска фич? (Do you have an up-to-date schedule?)
• Вы пишете документацию? (Do you have a spec?)
• У вас тихая рабочая обстановка? (Do programmers have quiet working conditions?)
• Вы используете топ тулы/устройства для ускорения разработки? (Do you use the best tools money can buy?)
• У вас есть тестеровщики на проекте? (Do you have testers?)
• Вы просите написать код на собеседование? (Do new candidates write code during their interview?)
• Вы проверяете интерфейс на тех кто рядом? (Do you do hallway usability testing?)

И парочку ещё

• Какую бы вы мне дали первую реальную задачу, если бы я уже вышел на работу?
• Какую последнюю проблему вы подняли на ретро и как вы её решили?
• Как мне стать Х (другая позиция/стать синьором) в вышей компании?
• Как вы трекаете время?

Хочу некоторые пункты пояснить

Фиксите ли баги перед новой фичей?

Баги есть всегда, будут всегда, на некоторые из них забивают, но не на все.
Писать только новый код нельзя, так не бывает. Лучше исправить баги до того, как
ты забыл, что это за часть проекта. Лучше поработать с багами, чем давать
дальнейшие эстимейты, чтобы лучше понимать проект и ньюансы.

Вы используете топ тулы/устройства для ускорения разработки?

Тут можно понимать и железо разработчиков. И хорошие компы для CI. Но не забывайте
о специализированых тулах которые соберают тест ковередж или трекают ошибки
приложения. Они значительно упрощают разработку и экономят деньги, и если компания
не выделяет 50 баксов в год на какую-то тулзу, то это должно быть минусом

Вы проверяете интерфейс на тех кто рядом?

Когда я о этом прочитал в статье, мне стало смешно. Но всё-же, у меня была
команда, где мы именно так и делали: заходишь в соседнюю комнату, берёшь кого-то
“на пару минуточек” и садишь его за браузер (если ты веб дев) и смотришь,
врубиться он или нет. Если ты пилишь API то дай ему почитать документацию к
эндпойнту.

И не забывайте

К этим вопросам ещё понятное дело надо задавать свои. Весьма полезно распросить
как появляются задачи, кто их ставит, когда их закрывают, так сказать, полный
цикл. И стоит понимать, что
HR не может знать ответов на всё, ну что-ж, тогда вам нужен тот, кто знает эти
ответы. И не надо думать что NDA означает, что нельзя человеку дать понимание
что он будет делать, с чем сталкиваться, и какие задачи будет решать.

И вообще, возьмите с собой распечатку с вопросами, чтобы в последний момент не
забыть их задать.