Python
Research and forecasts in IT
IT career
Comments 132
+10
Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Такой ответ считаю неуместным. Технический специалист должен понимать минусы/плюсы используемой им БД. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.

Я так понимаю, вы всегда можете ответить на данный вопрос, когда начинаете проект? И не каким-нибудь "ну, эту базу данных я знаю, а с другой у нас никто работать не умеет".


Лично мне кажется, что это довольно жесткое требование. Например, убер не очень справился с этим например, а вроде неплохая технологичная компания.

+1

Хотя бы уметь обосновать, что эту БД знают многие разработчики поэтому мы её и взяли в качестве инструмента.

-1
«эту БД знают многие разработчики» я предпочитаю, чтобы код был на 99% независим от конкретной БД, и переход с pg на mysql выполнялся строчкой в конфиге. И только в 1% по-настоящему критичного кода можно как-то заложиться на особенности конкретной БД. А теперь давайте подумаем, что эти 99+1% кода работы с БД составляют процентов 5 кода всего проекта. И нафига ради 0.05% кода нужно чтобы многие разработчики ее знали? Пусть лучше знают базовые алгоритмы и их сложность.
+2
бэкенд — это всё таки связующее звено между данными и клиентской стороной. поэтому основные БД и их отличия разработчик должен знать.
Даже упоминая алгоритмы и их сложности было бы неплохо чтобы разработчик знал чем тот же самый Redis отличается от PostgreSQL.
+14
я предпочитаю, чтобы код был на 99% независим от конкретной БД, и переход с pg на mysql выполнялся строчкой в конфиге

Лет 20 назад я позволял себе думать, что такое возможно :)
0
Это просто вопрос дисциплины архитектуры. Иметь как можно меньше завязок на внешние технологии.
Мы например уже много лет сидим в облаке. И за это время успешно переезжали между Heroku, Google cloud и AWS за конечное время и с не очень большими трудовыми затратами.
И если вдруг нужно будет переехать с постгрес на mysql, то мы за месяц-полтора одним человеком управимся, потому что единственная уникальная функция постгрес — `SELECT FOR UPDATE SKIP LOCKED`, ее использование — осознанное. Больше мы ничего постгрес-специфичного не используем.
+5
Как-то не очень вяжется:
… переход с pg на mysql выполнялся строчкой в конфиге
… мы за месяц-полтора одним человеком управимся

+3
А вы учитываете, что нужно не только мигрировать код, но еще инфрастуктуру, перенастроить мониторинг и вспомогательные аналитические тулзы, которые как раз таки почти всегда прибиты к базе данных? Типо заменить pghero и pgpool на что-то другое (А еще это другое найти и протестировать).
+1
да, собственно это и есть основная работа. Миграция кода не больше недели.
+3
Это просто вопрос дисциплины архитектуры.

Нет, это либо тривиальные проекты, либо банальная глупость — пользоваться маленьким подмножеством фич конкретной БД.

0
> банальная глупость — пользоваться маленьким подмножеством фич конкретной БД.

Я то как раз считаю, что это мудрость. И стандарт SQLxx не зря существует.
+2

Стандарт стандартом, но во-первых полнота его поддержки отличается в разных СУБД, а во-вторых разные СУБД добавляют разные возможности для оптимизации различных запросов.
А в вашем случае, вам остаётся небольшое подмножество стандарта, которое поддерживается более-менее одинаково основными игроками рынка СУБД, в итоге вы делаете запросы неоптимально и с кучей ненужных костылей. Для простых проектов, конечно, без разницы, а для нетривиальных — это потеря производительности и удобства разработки на ровном месте.
Например, как можно использовать PostgreSQL, но при этом не использовать jsonb, PostGIS, CTE, полнотекстовый поиск, оконные функции, индексы по функциям и т.д.? Я уж молчу про партиционирование и прочие тонкости работы с большими БД.

0
jsonb — это во-первых как раз потеря производительности на ровном месте, потому что при размер json больше пары килобайт мне быстрее будет сжимать и обрабатывать json на стороне приложения. Во-вторых это значит код приложения наполнен кастомным SQL, в обход ORM.
gis — да, нужная штука, если он нужен в проекте, но по-моему сейчас все БД поддерживают gis
полнотекстовый поиск — отстой в постгресе, с кучей ограничений
оконные функции — хм, никогда не использовал. Зачем для аналитики? Для аналитики постгрес отстой
CTE — да классная штука, используем, входит в тот 1% от всего кода работы с БД.
Индексы по функциям — ну может в каком-то очень нетривиальном проекте. Но индексы с условием — да, полезная вещь, но это лишь вопрос оптимизации.

Партиционирование — лучше его делать на уровне приложения. Как и все, что касается высокой нагрузки и скорости. Если что-то можно сделать на уровне приложения, лучше сделать это там, так будет более масштабируемо.

вы делаете запросы неоптимально и с кучей ненужных костылей -как я уже писал, 90% проектов это обычные реляционные схемы, для который SQL и был придуман. Приведите мне пример одной специфичной функции PG, который нужен хотябы в 20% обычных web приложений.
0
jsonb — это во-первых как раз потеря производительности на ровном месте, потому что при размер json больше пары килобайт мне быстрее будет сжимать и обрабатывать json на стороне приложения.

Причём тут сжимать? Это полноценный document-storage без необходимости затаскивать в проект к-н Mongo без крайней необходимости. Плюс с возможностью использовать эти поля в условиях на выборки.


но по-моему сейчас все БД поддерживают gis

Зато не все ORM поддерживают )))


полнотекстовый поиск — отстой в постгресе, с кучей ограничений

Вы показываете низкую квалификацию такими утверждениями. Любое решение имеет свои trade-offs, и полно случаев когда поисковых возможностей PG более чем достаточно, а затаскивать Solr, Sphinx или Elastic в проект — нецелесообразно.


оконные функции — хм, никогда не использовал

Ну, это говорит о том, что Вы и стандарт плохо знаете, потому что они даже там есть, но детали реализации в разных СУБД отличаются. Для чего используются? Много для чего: https://postgrespro.ru/docs/postgresql/10/tutorial-window


90% проектов это обычные реляционные схемы

90% проектов и даже больше — это тупой CRUD, но это ни разу не повод хотеть заниматься такими проектами.


в 20% обычных web приложений.

Что такое "обычное web приложение"? Не хотите поработать над необычным? )))

-3

И поехали. Сначала касательно mongo, elasticsearch и так далее.
У них есть нормальное шардирование и нормальный кластер, у postgres — нет. В случаи возможности взять es я бы лучше es взял.


И аппеляция к тому что "ой, ну это же другая технология" не очень уместны. Что json, что полнотекстовый поиск в postgres тоже идут как другая технология, не очень связанная с привычной реляционкой.


90% проектов и даже больше — это тупой CRUD, но это ни разу не повод хотеть заниматься такими проектами.

Ну, кто-то же их должен делать? И автор коммента как раз написал, что в этих проектах крутые штуки от специфической бд не очень то нужны.

-3
С ужасом представляю приложение используещее gis, оконные функции, полнотекстовый поиск и все это не в реляционной модели, а в документах. И чего, апдейтов 10 в секунду держит? )))
+1
А я только с такими проектами в последние годы и работаю.
SQL вижу только в автоматически сгенерированных миграциях и логах.
-1
Слышал мнение, что ORM убивает производительность и преимущества любой СУБД.
+3

Убивают программисты, ORM же ничего убить не может, это все лишь инструмент, который переводит питон код в SQL.

0

Ok, убивают программисты, которые не знают SQL и строят запросы через ORM, как через чёрный ящик.

+1
В какой-то степени. Есть две опасности ORM. Первая, самая очевидная, бездумные джоинв. Но тут надо просто включить голову и все-таки хоть немного понимать, как работают реляционные СУБД. Ну и желательно поменьше джоинов. Тут просто аккуратность кода и схемы БД нужна.

Вторая проблема менее очевидна, поэтому более опасна. Многие ORM по умолчанию грузят объект целиком. И если у вас есть (очень условный пример) User, и у него в одном из полей хранится допустим картинка, то каждый раз при обращении к модели, ORM будет вытягивать объект целиком. С этим бороться немного сложнее. Потому что неизвестно, где вылезет.
0
Видимо, разные ORM бывают. С теми, что я сталкивался — ничего лишнего не грузят.
0
Я последние пару лет с рельсами имею дело. Как там в питоне и hibernate уже не очень помню.
0
А как они грузят, кстати? Нужно явно список полей передавать? Или они lazy? Но тогда это не транзакционно, да и накладные расходы могут еще больше быть.
0
смотря какая. django вполне может в паре случаев нехило тормознуть(но они известны).
а sqlalchemy достаточно гибка и ей можно подсказать.
всякая экзотика вроде pony тормозит.

в orm часто другие узкие места получаются, например построение кучи объектов.
0
переход с pg на mysql
Плохой пример, не надо переходить с Postgres на MySQL. Переходить нужно как раз в обратном направлении (на Постгрес). Я понимаю, что пока что не всегда есть возможность уйти от MySQL (не все приложения/вики/форумы умеют в pg), но имхо нужно думать и двигаться именно в этом направлении.
+2
Я бы сказал что это плохой (неинтересный) пример в плане того, что миграция с условной Mongo на условную же Postgres в реалиях условной java — пример сильно интереснее. (а в обратную сторону — еще интереснее)
-1
минусов куча «и туда и сюда» — но преимуществ, так никто и не назвал — <3 хабр за его хипстерскую техническую составляющую, самый хипстерский технический портал :D
+23
Это с каких пор hg — древняя система контроля версий?
Она между прочим моложе git (на целых 12 дней).
+2
А fossil даже не упоминается в статье, а ведь он самый молодой из этой тройки. Аж не целый год моложе. Т.е. на самом деле автор скрывает от нас всё самое современное.
+5
+1. hg использует ту же модель распределённой VCS, что и git. Я его однажды использовал(давно), на мой вкус удобнее git при тех же возможностях.
+2
Еще, у них удобный бесплатный GUI под Windows появился раньше, чем для git (TortoiseHG — 2010, Sourcetree — 2013).
0
между моделями hg и git есть, по крайней мере, одно крупное отличие.
висящие ветки git невозможны в hg.
несколько разная топология.
в hg всегда остается источник.
+3
Да, статья мне в целом на 90% понравилась но этот момент покоробил. Я, как программист работавший с до cvs-эры, перешёл на CVS, потом на Subversion, потом на Mercurial и git могу сказать что с этой перспективы мне жаль что git стал намного популярнее, потому как в с hg работать легче и система сама более понятная и удобная. Важно для меня — в hg сложнее «выстрелить себе в ногу» — тут историю не затрёшь, в то время как в git это поставлено на поток, у пользователя полный контроль (во flow с rebase для ветки, так вообще постоянно это делают, но рискуют тем, что при неадекватных действиях пользователя, затереть часть истории, а часто вы встречали программистов которые на 100% хорошо понимают что они делают с git? я — не часто).

Работая на проектах и с hg и с git, могу сказать что по функционалу они пересекаются на 90%, при этом функционал mercurial в целом шире, но из за того что система непопулярна, сложно найти адекватную поддержку в тулзах (github, gitlab и тп только для git, потому приходиться юзать другие, менее удобные пакеты и сайты) и это большой минус. Ну и второй минус прилагается — программистам сложно переключаться, все привыкли к git, и внедрить hg в другой компании — шансы близки к нулю, при всех очевидных для меня преимуществах.

В общем автор тут не прав, но видимо что то пошло у него не так. А статья хорошая, спасибо!
0
согласен, мне тоже hg гораздо более подходящим представляется для задач csv, да и в лексеме github последние три буквы оказались важнее первых трёх.

Однако, немного уточню. У гитхаба есть поддержка не только для git.
— есть svnhub.com для проектов SVN, это официальная поддержка от github;
— есть плагин hghub.com (это редирект) какой-то самодеятельный (но статус его мне неизвестен, не пользовался)

Также у меня сложилось впечатление, что у hg преимущество не только для «пользователя», но и для администратора. Его гораздо быстрее развернуть и проще настроить на сервере и потом осуществлять поддержку. В этом смысле потребность в «специальных ресурсах» ниже, чем в случае с git.

Да, и если уж на то пошло, что и bitbucket'а есть поддержка hg.
0

Я пользовался hg-git для своих проектов на гитхабе. Необходимость в этом возникла при миграции этих проектов с google code на гитхаб, когда google code закрыли. Работал hg-git хорошо, нареканий нет, но и проекты это были достаточно небольшие. Окончательно перешёл на git когда понял, что он победил, его знают все и его нужно знать всем — а использовать одновременно и то и другое никакого смысла нет. Хотя hg однозначно был проще и удобнее.

+2
Спасибо, было интересно.
Меня тоже напрягает что СОбеседование часто оказывается экзаменом. Можно подумать СОседям они тоже проводят экзамены перед покупкой квартиры.
0

Всего-то переименовать этот процесс нужно в job interview и все станет на свои места.

+1
Вопросы не мальчика, а…
Заголовок спойлера
image

P.S. Простите, не удержался, только так и прочёл, ну нет такого слова в русском языке и поза соотвествует.
+3

Почти везде. Видимо мне везло. Но многие говорят что есть, а на деле 20 тестов которые гоняются раз в день.

+6

Это круто! Я собеседовался раз пятьдесят и мне всегда говорили что писать тесты разработчикам некогда.

+2
Наверное можно было бы спросить вместо «пишете ли вы тесты» что нибудь вроде «какое у вас покрытие тестами». Тогда уже простым «есть» не отмажешься.
+1
покрытие — это хороший показатель, но не достаточный. покрытие мб 100 процентное, только вот тестов всего 5, из за того что в тестах криво расставлены проверки ибольшая часть файлов заигнорина на coverage. Сам тако видел.
0
Вообще идея какбэ была не в том что покрытие — показатель, а в том что если команда знает и может назвать свое покрытие тестами, значит относится к тестированию серьезней чем вышеупомянутое «20 тестов прогоняемые раз в день». Но таких ушлых ребят как вы щас описали наверно никакими вопросами не смутишь)
+1

Все же перечень вопросов заточен на некоторый не очень широкий спектр компаний, которые занимаются, скорее всего, привычным вам вещами. Например список тех, кому можно простить отсутствие тестов всего один пункт про стартапы. А как же хардварщики? Или вы знаете как покрыть тестами код для микроконтроллера, который к тому же может иметь внушительные вставки на ассемблере? А ещё есть компании которые вообще никогда ничего не программировали, но тут им резко понадобился человек в новый отлел, который с помощью этих ваших компукхтеров наконец поможет бизнесу встать на рельсы современности. Понятно, что никакого CI, код ревью и прочего аджайла там нет и быть не может, но разве это не круто с нуля сделать классный проект, особенно если за это готовы хорошо платить? Ближайший пример из жизни — компания всю жизнь занималась радиотехникой, проектировали антенны и усилители, а тут пришёл заказчик и говорит — хочу чтоб ваше железо слало мне данные вот в таком то виде, и вот тут ещё сбоку аналитику надо приделать. И делают, нанимают программистов, те работают, софт их работает. А новомодных методик разработки как не было так и нет

+2
Коллега, добрый день!
22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик». Таково название статьи. Насколько я знаю python не относится к хардварным вещам. Мб за исключением raspberry  или orangepi.
0

Я тоже так думал. Пока не увидел код управления многотонными механизмами написанный Целиком на питоне. И кстати хорошо работает…

0
Наверное этот код дальше скармливается в транслятор и превращается в Си. Ибо я с трудом понимаю как интерпретируемый язык может исполняться на микроконтроллере.
+1

В микроконтроллерах там обычный С и asm, но и логики в них около нуля, просто преобразуют байты в вольты и обратно. А вот вся логика на питоне в линуксе под х86. Ту её часть что отвечает за хотелки заказчика, конечно, покрыли тестами, а вот уровнем пониже стоит регулятор скорости (и не только) на том же питоне и как его автоматически тестировать придумать так и не удалось. Тупо потому что у сервера с тестами нет той самой штуки скорость которой надо регулировать. Она есть где то в другой стране, туда разработчики ездят живьём и живьём же вручную все тестируют, благо площадь полигона и перехват управления в ручной режим позволяют ничего при этом не сломать.

0

UPD. А, да, статья то про python, так что ассемблер не в кассу. Но тем не менее. Не раз видел (и писал) питоний код, который общается с суровым железом и тестами не покрывается почти никак в виду прямой и неэмулируемой зависимости входных данных от выходных

0

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

0

Тут вопрос что считать масштабным. После какой то степени разрастания кодовой базы, версий и самой команды разработчиков — да, становится (почти) невозможно. Особенно если предполагается такая неприятная сущность как сторонний пользователь, которому нужны фронтэнд, куча уровней защиты от дурака и вот это вот все. Но многим задачам и не нужны такие масштабы, есть вполне серьёзные вещи, которые решаются силами команды из 3-4 человек. Из того что сам видел — видеоаналитика для ЦОДД, там реально всю систему пилят три программиста, один из которых ПиЭм и документации делает больше чем кода. Ну и куда им этот CI?

0
В случае с ЦОДД стоит задуматься над проблемой BUS-фактора и проблемой внедрения нового сотрудника.
0

Как ни странно — проблема автобуса остро стоит для компании в примере на пол ветки выше и то в силу некоторых исторических причин, которые возникли, когда вместо разработчика нанимали технологию (где то даже здесь была статья на эту тему), а привычка писать документацию ещё не родилась. У ребят с видеоаналитикой в этом плане все в порядке — насколько мне известно там или типовые решения, которые любой грамотный новый разработчик сможет без труда понять и воспроизвести или же все довольно неплохо описано в документации, которую просто требуют сверху

+14
В целом вопросы разумные, в том смысле, что понятно желание знать на них ответ, но…
1) ответы на многие вопросы практически ничего не значат. «Используется ли технология контейнеризации в проектах?» да, и что? нет, и что? «Какую систему контроля версий Вы используете?» да какая блин разница. Различия некритичные. Да, гитхаб удобнее всего сейчас, но если нужно будет cvs использовать в конкретном проекте, будем его использовать.
2) Некоторые вопросы вызовут раздражение. «Ну твое какое дело, как выбиваются ресуры» — подумаю я себе мысленно. Сразу множество допущений в вопросе, что ресурсов нет, что их нужно выбивать, что собеседующий в этом участвует, что в компании это обсуждается среди тех, в чьи обязанности это не входит. Тут человек показывает, что он не понимает границ своей роли в компании. И вообще разделения ответственности. А значит будет лезть везде.

Какие БД используются в проекте? Почему именно такие? Знаете, «так исторически сложилось» — это самый разумный ответ на этот вопрос. Потому что в 90% проектов разницы нет никакой. А в оставшихся 10% разница есть, но нет верного ответа, потому что всегда есть какой-то tradeoff. И выбирать приходится не БД, а способы (архитектуру) работы с ней.

Используется ли в проекте ELK-технология? опять вы показываете, что ваши вопросы строятся на многих предположениях, которые у вас в голове, и которые являются следствием ограниченного опыта. Тут правильный вопрос был бы, есть ли у разработчиков вообще доступ к логам на продакшене.
0
Тут правильный вопрос был бы, есть ли у разработчиков вообще доступ к логам на продакшене.

А ошибки на этом продакшене кто исправляет тогда?

0

А как можно исправлять ошибки, если у вас нет информации к логам на проде? На слух от кастомера?

+1
Мы на собеседовании проверяем телепатические способности, и умение обращаться с бубном. Разве не все так делают?

На самом деле просто представьте как работают компании, имеющие строгие требования к безопасности. В них у рядовых разработчиков никогда не будет доступа к продакшн серверам, данным пользователей, продакшн логам. Один из вариантов — есть люди с доступом, которые умеют работать с логами. Достаточно пары человек.
0

Ну, нормальные компании обычно сразу на выходе просто скрывают чуствительную информацию из логов, оставляя обезличенную.


Компании, в которых лютую "безопасники", в основном занимаются странными вещами, на мой взгляд.

0
Да, но это сложно, практически невозможно, гарантировать. какой-нибудь отладочный трэйс, или эксепшн кинутый в стороннем коде включает переданную информацию.
0
Если мы говорим про python, то обычно для этого настраиваются handler'ы. В том же sentry это довольно неплохо работает.
+5
2) А я вот на должности разработчика принимал в этом участие. Ничего приятного в этом нет. Вместо увеличение ОЗУ в текущем ноутбуке я внезапно, без предупреждения, получил другой ноутбук (причем даже другой фирмы), но это мелочь. А вот чтобы получить виртуалку, мне нужно было ночью монтировать неучтенный сервер в машзале (шутка — это было днем. Сервер, впрочем, был неучтенный). Причем, чтобы получить на него IP адрес и VLAN, другой коллега тоже совершил должностной проступок. В общем, самое настоящее преступление, по предварительному сговору, группой лиц.
Закупка ПО, написанием обоснования которого занимался в т.ч. и я, ведется уже около полугода. Из-за закупки другого инфраструктурного ПО, пришлось резко сдергивать проекты с одних серверов и перемещать на другие сервера. Внезапно оказалось, что к новым серверам нет сетевых доступов и это вылилось в офигенный квест с безопасниками, сетевиками и еще 5 или 6 отделами, каждому из которых нужно было доказать, что в этом есть необходимость. И да, если где-то ошибешься — начинай весь этот work-flow заново. Один из моих коллег (тоже разработчик), раз в 2 недели по расписанию, пишет слезное письмо в одну иностранную компанию с просьбой предоставить свежие триал-ключи. Потому что закупка идет, идет уже около года, и обязательно когда-нибудь закончится хэппи-эндом, но пока — дайте ключи, пожалуйста.
Так что нет, это нифига не праздный вопрос, особенно, если это крупная компания, в которой может быть километры всяких бюрократических процедур.
Так что возможно это не человек будет лезть везде, а ему, без его на то желания, будут делегировать те или иные задачи, связанные с ресурсами.
Даже если вдруг повезет, и весь ресурсный вопрос будет висеть на руководителе, то вопрос «как быстро» тоже имеет значение. У нас, к примеру, между согласием купить и покупкой может проходить несколько лет, за которые, сами понимаете, часть людей успеет сменить работу.
-2
по моему Вы прочитали вопросы, но не прочитали к ним пояснения.
Насчёт ELK — вопрос возможно неправильно сформирован. Логи хранить — дело нехитрое. Но разобраться в их огромной каше и как-то их систематизировать — это другой вопрос. Поэтому и спрашиваю про технологию ELK
+6
Есть Splunk, Graylog, можно сложить логи в ClickHouse, ещё куча вариантов. Почему именно ELK?
+1
Splunk как то не очень прижился для логов. Graylog — внутри него ElasticSearch, так что уходит в ELK.

ClickHouse это классно, да. Еще вот grafana labs выкатити loki. Но в целом еще некоторое время назад ELK был фактически стандарт и ничего другого просто не было.
0
Коллега, добрый день!
ELK — это обобщённая аббревиатура. И кстати на собеседовании все прекрасно понимают о чём идет речь даже если у них не используется ни она из трёх букв
+12

Есть еще вопрос, который я задаю потенциальным нанимателям после стажировки в одной достаточно крупной софтверной компании.


Используются ли при учете рабочего времени системы журнализации и записи действий разработчика за компьютером? Удивительно было после первого рабочего дня обнаружить в автоматизированном табеле уведомление — "Учтено 6,5 часов. Необходимо доработать 1,5 часа".

0
Бред какой-то. Подобные системы приводят только к снижению продуктивности, и, как следствие, к снижению зарплаты.
habr.com/post/102620
0

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

0
Как обстоят дела с выбиванием ресурсов?

После прочтения ваших вопросов (они все правильные) встал вопрос, это вы проходили собеседование и устраивались на работу, или это вы проводите собеседования и ищите работников.
Что лучше hg, svh и т.п. — это дело традиций в том числе.

+3
По-моему при разработке софта, как и в общении с другими людьми, самый важный и просто критически недооценённый людьми с узко-технарским кругозором момент — это способность мысленно поставить себя на место того, кто будет пользоваться продуктом интеллектуальной деятельности разработчика (а при общении — способность мысленно поставить себя на место того, кто выслушивает твою очередную едкую праведно-гневную филипику).
Это не только важный момент, но ещё и объективно — самый сложный, потому что очень трудно отринуть весь свой опыт и все свои единственно верные представления об окружающем мире — и попытаться представить, как мыслит и чего, собственно, хочет тот человек, который будет пользоваться плодами твоей работы. А ему, как это ни странно, может быть важно совсем не то, что важно тебе: не экономия миллисекунд, а грамотно написанная документация, которая позволяет не влезать в исходные коды, чтобы понять «как же оно на самом деле работает», не тестирование, покрывающее искусственно смоделированные ситуации, а возможность оперативно решить проблему в случае возникновения ситуации, которая может вообще никак и никогда не моделироваться в искусственной среде.
Нужно понимать, что наличие реальных денег в компании зависит от заказчиков. И от наличия реальных денег в компании атмосфера в коллективе в российских реалиях зависит порой куда больше, нежели от того, предпочитают там hg или git. И хотя понятно, что с заказчиком взаимодействуют не сами разработчики напрямую — всё-таки не стоит забывать, для кого и для каких реальных условий эксплуатации пишется ваше ПО.
0
хочет тот человек, который будет пользоваться плодами твоей работы.

Дай бог, чтобы это было именно так. Но порой между конечным потребителем и разаботчиком стоит промежуточное звено (интегратор, посредник и т.д. и т.п.). И не факт, что он понимает потребителя, а вот с разработчиком может и найти консенсус.

+1
Я как человек с преимущественно админским опытом, успевший поработать с тысячами «единиц» разного софта, задал бы ещё несколько вопросов:

1) А что конкретно ваш софт пишет в логи? Есть ли в компании какие-то стандарты, не позволяющие разработчикам не логировать ничего или логировать на «отстань от меня, пожалуйста» или логировать только на этапе отладки, а затем просто на уровне макросов удалять все вызовы логера, «чтоб оно у клиента/заказчика быстрее работало и чтоб клиент не видел лишнего!» Насчёт макросов — вопрос не о конкретном ЯП, а просто принципиальном подходе. Есть такие вещи как OpenLDAP, Samba и Zabbix, умеющие логировать всё чуть ли не построчно, а есть — что-то вроде rsyslogd или zebra, которые могут быть весьма загадочны и непредсказуемы

2) Есть ли определённый стандарт подробности обработки исключений? Насколько распространена ситуация, когда исключение «обрабатывается» (снова по принципу «на… отцепись пожалуйста») на 5 уровней выше того места, где оно возникает? Отличаются ли информация, предоставляемая в случае возникновения исключения, для этапа «отладки» и этапа эксплуатации заказчиком в продуктиве. Есть ли понимание того, что заказчику может быть как минимум неприятно и больно видеть стек-трейс с глубиной вложенности в 20 уровней и что неплохо бы предоставлять в таких случаях информацию, полезную заказчику «что в общих чертах произошло и как это можно исправить», а не предполагать, что заказчик во всех абсолютно ситуациях должен бежать к вам, о великий разработчик, даже если недотестированное и вывалившее какую-то невразумительную околесицу приложение нужно здесь и сейчас. Я неоднократно сталкивался с приложениями, которые вываливали гигантский стек-трейс в ответ на что-то вроде «не могу забиндится на порт» или «такого файла не существует». Если честно, в таких случаях у меня абсолютно всегда возникало желание кастрировать тех, кто так пишет софт. Я сам не всегда пишу тесты и не всегда даже пользуюсь системами контроля версий, но зная о том, насколько критичными бывают вменяемые сообщения об ошибках — хотя бы никогда не делаю их криптографическими и понятными только мне как разработчику.

3) Ну и да, я бы обязательно узнал, почему в компании выбрали именно Python при таком обилии качественных и несложных компилируемых языков со статической типизацией. Потому что база данных — это, безусловно, хорошо (особенно когда это не MySQL vs PostgreSQL, а что-то вроде PostgreSQL vs. ClickHouse vs. Tarantool), но если код пишется на интерпретируемом языке с прекрасным во всех отношениях GIL — наверное, для этого есть очень веские основания? Хорошо бы всё-таки при этом главным основанием была не дешевизна и переизбыток на рынке python-девелоперов, что позволяет убегать на совещания, когда очередной умник начинает задавать слишком много вопросов…

P.S. И да, сложность стандартных алгоритмов (на 99% уже имеющих готовую общедоступную реализацию, в т.ч. в виде C++ блобов для Python) — это, конечно, важно, но для оптимизации производительности неплохо бы знать и некоторые internals целевой системы. Поэтому конечно следует поинтересоваться у потенциального работодателя, что он знает, например, о современной структуре виртуальной памяти в Linux. Ну и классический конечно вопрос: если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление? Кстати, поспрашивать работодателя о флагах clone, о преимуществах и недостатках разделяемой памяти (shared memory), о стоимости переходов между разными кольцами защиты ОС — тоже совершенно не повредит…
+1

1) А можно пример? Я не представляю себе как можно стандартизировать логгирование и точно разделить, что логгировать надо, а что нет, не сделав при этом кучу излишних действий и не превратив дебаг логи в полноценную отладочную машину.


2) Может со мной что-то не так, но я никогда не испытывал проблем со стектрейсом, он легко читается и подсказивает где что нужно подправить. Segmentation fault в этом плане значительно хуже.


3) Да бы не начинать холивар по поводу языков могу заменить, что все зависит от точки зрения. Я вот не знаю ни одного достаточно популярного компилируемоего языка, который бы меня так же устраивал как python. Жду когда в rust завезут async/await и можно будет снова проходить растбук.


если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление?

Мне вот интересно — это был такой выпад в сторону технологии? Просто вопрос звучит так же, как "как глубокоуважаемый работодатель исправит бесконечный цикл запущенный в собранном c++ бинарнике". Я думаю, вы уже знаете ответ.

0
Тем не менее проблема с async-io — вполне решаема, и это даже не высшая математика, как ни странно.

Может со мной что-то не так, но я никогда не испытывал проблем со стектрейсом


Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта. Когда я разрабатываю что-то — мне интересны стек-трейсы. Когда я как пользователь вижу стек-трейс на экране вместо вменяемой диагностики проблемы («Отсутствует файл такой-то, процедура установки выполнена некорректно», «Файл такой-то недоступен для записи, проверьте прав доступа», «Не могут создать новый сокет — проверьте лимиты на количество открытых файлов») — у меня это вызывает как минимум раздражение: я не понимаю, почему я должен видеть информацию, которая понятна только разработчику, если приложение мне дали как продуктивное, а не как некий «subject for deeper debugging». Во многих ситуациях я могу сам исправить проблему или даже искусственно создать приложению те условия, в которых оно всё-таки будет работать, даже если в нём и содержится какой-то баг. Мне-то нужно, чтобы оно работало, а не собирало стек-трейсами «полезную информацию для отладки продуктива».
0
Тем не менее проблема с async-io — вполне решаема, и это даже не высшая математика, как ни странно.

А не расскажите как? Мне казалось, что такое можно поправить только как-то внешне.


Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта.

Не только, я тут мастер на все руки :) Просто у меня стек трейсы сидят где-то по середине, самое раздрадающее это "что-то пошло не так" или ошибки, которые вроде как обработаны, но которые не имеют никакого отношения к реальной проблеме, например, когда приложение пишет, что не может подключится к порту, а на самом деле ему не хватает прав создать папку, но у него на все ошибки один обработчик.

0
А не расскажите как? Мне казалось, что такое можно поправить только как-то внешне.
Полагаю, примерно как с убийством тредов извне. Но это работает только если поток не завис насмерть, а просто долго выполняет какую-то синхронную операцию.
0
Я не представляю себе как можно стандартизировать логгирование

Речь не о техническом документе, хотя для того же кода на C бывает полезно делать trace-отладку типа «вошли в функцию такую-то, важный аргумент такой-то равен вот этому значению» и вокруг обработки внешнего ввода хорошо бы расставлять побольше диагностики, потому что это и есть реальный источник львиной доли ошибок в якобы хорошо протестированных приложениях. Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».
0
Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».

Может я не прав, но мне кажется, что задать вопросы с более-менее очевидными ответами довольно странно.


Как и с вопрос о базе данных, если вы потребуете какого-то осмысленного ответа, более-менее опытный разработчик обязательно скажет что-то в духе того, что вы написали. Хотя вряд ли у них прямо будет прописанный Code of Conduct с конкретным списоком пунктов кодекса.

0
Есть ли в компании какие-то стандарты... (логгирования, обработки исключений)

Насколько в компании сильна бюрократия?

Я считаю, это прекрасно. Разработчики как всегда такие разработчики.
0
По Вашим вопросам как раз и видно, что Вы человек именно с _компьютерным_программным_админским_ опытом, а не руководящим админским.
Большинство вопросов внутри этих «22 вопросов работодателю» касаются не конкретных технологий, как там вас решается та или иная программная проблема, а организационных вопросов. Как показала реальная практика работы в компаниях, более 50% проблем в компаниях, IT так точно, вызваны именно проблемами административно-управленческого свойства, а не тем, как вы там прибиваете зависший поток или выполняете миграцию из одного sql в другой. Проблемы административного управления это и подбор кадров, и подбор поставщиков, и управление командой разработчиков, и чистота и порядок в офисе, а не только в код и коммитах в git и т.д. и т.п. Если у вас разработчики трудятся как попало спустя рукава, так как никто не следит, то вы можете выполнять любые миграции, хоть из mongo в postgres одной строкой, но успеха ваша компания не добьётся. И наоборот, написать можно хоть на древнем перле, но благодаря грамотному учёту требований конечных пользователей системы и умелому управлению всем процессом разработки система может процветать и упорно не умирать, хотя все хипстерские разрабы будут воротить нос «там же перл внутри».
В общем автор статьи писал об одном, а Вы к нему с вопросами о другом, образно выражаясь, умело воспользовавшись тем, что буквы и слова и у него и у Вас одинаковы.
-1
> также серьёзно, как и…
> целисообразности

Однозначно говорит в пользу проведения собеседований в письменной форме.
Соответственно, вопросы претендентов к собеседующим тоже имеет смысл принимать в письменной форме.
+2
которые до сих пор использует hg, svn и прочие древние системы контроля версии


А вы можете привести нормальное объяснение на счет mercurial? Или это у вас — не знаю, не использовал, значит плохо?
-4
ужасный облачный сервис который хранит код. не проведешь нормально код ревью. то есть надо использовать что-то сторонеее
нет разделения на роли, то есть любой желающий может писаться в develop.
отсутствует нормальный stash.
+ поддержка hg, насколько мне известно заканчивается в след году.
+1
Недостатки vcs и недостатки облачного сервиса с каких-то пор стали понятиями тождественными?
+5
Назвать много не могу, но могу сделать довольно смелое предположение, что существует жизнь и за пределами облачных сервисов.
+1
нет разделения на роли, то есть любой желающий может писаться в develop.
отсутствует нормальный stash.

Что?
Вы систему версионирования путаете с настройкой конкретного сервера, а не знание системы с отсутствием функционала.

Простите, но с столь некомпетентными заявлениями очень тяжело слушать и серьезно воспринимать рассказ о том как надо вести себя мидлу.
0
я тоже могу ошибаться к и миддл.
лучше кинуть ссылки и разжевать.
я на двух местах работы сталкивался с проблемой того что нельзя разграничить доступ на конкретную ветку.
вместо stash-а есть shelve.
0
>ужасный облачный сервис который хранит код. не проведешь нормально код ревью. то есть надо использовать что-то сторонеее
посмотрите на bitbucked
shelve да, но с настройками.
защита веток —
1) Опять расширения www.mercurial-scm.org/wiki/AclExtension
2) Регулировать процесс иным способом(делать пуш в иную репу с одного хранилища)
+2
Если я верно помню то hg и mercurial создавались в одно время по одной и тоже причине — разрабам(ядра линуха) закрыли доступ к системе контроля версий. И выходцы от туда создали свое.
Подходы несколько разные, есть свои плюсы и минусы, и там- и там. Я не буду вам пересказывать статьи выложенные на хабре на тему их сравнения и разводить срач на тему чья мама система контроля версий лучше, но назвать mercirual древним указывая на гит несколько странно и некомпетентно.
Все что делаю не для себя или просто с кем-то — git ибо почти все его используют. Все что делаю для себя — меркуриал, ибо удобней.
+2
Все что делаю для себя — меркуриал, ибо удобней.
Так точно. Я старый солдат, и не знаю слов любви пользователь CVS и Subversion; Mercurial имхо намного проще и понятнее, чем Git с его наркоманской командной строкой. :-)
+1
А ещё с какого перепуга svn вдруг стал древним? У него совсем другой подход, он централизованный, это плюс и минус. Не мейнстрим — это да.
Плюсы, которые мы активно использовали
— Чекаут части пути
— авторизация из коробки (у гита тоже есть gitolite тот же, но это сторонний продукт)
— если много добавляется и удаляется, чекаут существенно меньше чем у того же гита, нет нужды тянуть все изменения
— это больше решение для разработки с закрытым кодом; разработчиков легче разграничивать в правах (можно выдать доступ только на отдельные ветки), при удалении логина у разработчика остаётся только 1 версия а не полное дерево с первого коммита, и при утечке исходников гораздо проще понять кто виновник
— уже на стадии коммита идёт проверка на «свежесть» версии и если она не последняя то сначала нужен мерж
— А ещё он проще того же гита.

Минус пока только 1 могу вспомнить — невозможность работы без доступа к серверу — ни ветку сменить, ни коммиты заслать.

Это всё то что сходу вспомнил.
+1
У меня с svn были проблемы с мерджами. Было это лет 6 назад, точно не помню в чем заключалось, но по моему где-то в действиях смена ветки, мердж и загрузка на сервер заключался ад, точно не могу припомнить…
0
С мержем есть некая беда, это да. Впрочем, в гите оно тоже не на волшебном порошке и у меня уже было несколько раз, что оказалось проще сделать чистый клон и потом заново коммитить все свои изменения. Но тоже причин не помню.
0
Я с ним имел дело довольно давно… Насколько помню, основная проблема с мерджем была в том, что автоматическое разрешение конфликтов почти никогда их не разрешало и все надо было разруливать руками.
0
Если были затронуты разные файлы, решало. А если в одном то обычно всё-таки лучше ручной мерж, даже с гитом.
+1

Я бы ещё задал пару вопросов:
1 пишете ли вы в соответствии с pep8?
2 сколько нужно времени на согласование новой библиотеки в проект.

+2
40 собеседований за 2 года… нашли ли вы идеал?

Чем больше смотрю на подобные посты, тем больше задаюсь вопросом — люди, вам работать/создавать/добиваться, или антураж/печеньки и как минимум одну новую футболку в неделю, и обязательный вид на горы из окна?

Если я на все эти вопросы отвечу как ожидает задающий, то итоговая стоимость часа разработки для конечного клиента такого работодателя будет запредельная.

Будьте проще. И задайте себе вопрос — а как же раньше все это работало? А то дожили, коммит в гитлаб не пушится и все, можно собираться и домой идти, не могу так работать.

Простите. Наболело.
0
Коллега, добрый день!
Нашёл идеал и в нём работаю, чего всем желаю)
Ни про какие горы, антуражи и печеньки я не писал в этой статье.
Согласен, час работы стоит дорого при таких условиях но никто не запрещает Вам работать в компании с иностранным финансированием
-1
В данном случае я представляю как раз — сторону работодателя.
Ответ ожидаемый, слышал его не раз. В итоге внутренний Российский заказчик остаётся без исполнителей, т.к. в принципе не в состоянии платить такие деньги за разработку. Отрасль перегрета как раз зарубежными деньгами, а разработчики превратились в «дешевую» рабочую силу для зарубежных «дорогих» денег. Как следствие — даже толковые ребята прозибают в больших компаниях, часто занимаясь неинтересными проектами, с которых не уйти на другие, да и другие проекты — обычно ерунда, просто сваливающаяся от очередного «зарубежного финансирования».

Да, есть исключения — компании, которые пилят именно свои продукты и продают из world-wide, но их не так много (и требования к работникам очень серьезные), а у молодого джуна без опыта, который почитает годик хабр на лекциях в универе, создается ощущение — что работать можно и нужно только в больших корпорациях, где все налажено, и там будет прям весело и круто, как показывают в обзорах офисов гугла и прочих яндексов. Дальше они начинают все это искать, а сталкиваются с аутсорсерами, которые просто продают их как… рабов, простите, зарубеж. Дорого продают.
+4
В итоге внутренний Российский заказчик остаётся без исполнителей, т.к. в принципе не в состоянии платить такие деньги за разработку.

Простите, просто хочу уточнить, правильно ли я Вас понял. Вы пытаетесь сказать, что поскольку у "внутреннего Российского заказчика" нет денег, то разработчики должны идти к нему работать на меньшую зарплату и в худших условиях, потому что… что? Из патриотизма? Чтобы избежать участи "раба", причём "рабство" заключается исключительно в том, что он работает на зарубежных заказчиков? Если я Вас понял правильно, то Вам явно не помешает заглянуть в словарик, почитать определение рабства, потом почитать какие законы Россия принимает в последнее время, и немного подумать… в смысле, подумать своей головой, самостоятельно, без подсказок из телевизора.


Как следствие — даже толковые ребята прозибают в больших компаниях, часто занимаясь неинтересными проектами, с которых не уйти на другие, да и другие проекты — обычно ерунда, просто сваливающаяся от очередного «зарубежного финансирования».

И какова же, на Ваш взгляд, причина того, что в зарубежных компаниях количество неинтересных и ерундовых проектов заметно больше, чем в местных компаниях? Кстати, простите что спрашиваю, но как именно Вы подсчитали количество (не) интересных проектов и там и там чтобы сравнить?


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


P.S. Кстати, у меня есть для Вас лайфхак: логику хоть и перестали преподавать в школах, но пока ещё не запретили, так что надо ловить момент, и учить её самостоятельно, пока ещё есть такая возможность.

+1
Вот в данном конкретном случае для объяснения очень подойдет фраза кого-то из правительства, недавно выдавшего: «Это не цены высокие, это у Вас зарплаты маленькие». Если внутренний российский заказчик не в состоянии платить большие деньги за разработку то этот заказчик должен просто тихо и спокойно принять данность и закрыться. IMHO. Ну или повлиять на политику в стране, так, чтоб все его доходы не отбирались в виде налогов и поборов и он смог таки платить нормальные деньги разработчикам и они не утекали из страны. Всё же просто и очевидно.
+2
«3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?»
Если в компании есть DevOps-инженер то они не понимают что такое DevOps, как судя по всему и автор этого текста.
+3
Я люблю этот магический культ «никто не понимает что такое девопс».

В текущих реалиях рынка DevOps-инженер это тот чувак, который занимается CI/CD и новомодными практиками в духи контейнеризации, мониторинга приложений и прочего. Я совсем не понимаю, что вас не устраивает.
-2
Это не культ. Просто отдельный хаброписатель не знает матчасть, вот и всё. А незнание матчасти вызывают сомнения в его экспертизе.
+2
Это не культ. Просто отдельный хаброписатель не знает матчасть, вот и всё. А незнание матчасти вызывают сомнения в его экспертизе.

Вы же понимаете, для того, что бы упрекнуть в незнании матчасти, нужно, что бы она была. А четкое определения "DevOps" найти довольно сложно, как и в целом определение чему угодно в программировании. Вспомните тоже ООП. У нас тут нет какого-то существенного научного сообщества, которое смогло бы выработать терминологию, как в той же математике.


Поэтому мне кажется довольно странно придиратся к словам, учитывая, что это довольно часто используемое выражение в описании вакансии.

0
AFAIK чёткого определения DevOps вообще не существует :)
Эт делает всё ещё веселее!
0

Коллега, добрый день!
Специально для таких дотошных как вы, я оставил определение для термина devops когда писал эту статью. Если вы не согласны с моим видением того чем занимается devops, то вы можете пройти на сайт hh.ru и ознакомиться с требованиями к devops-инженерам.

+1
Ага. И в числе таких «непонимающих» контор Яндекс и Сбертех.
-1
ВТБ24 и СКБ-Контур туда же :)
В России просто свой собственный, особенный DevOps.
0
Как-то совсем по-джуниорски. Как-то ну совсем теоретически.

На эти вопросы дадут ответы не более, чем в одной из двадцати компаний. А вот другая сторона медали… зарплата в тех компаниях, в которых вам ответят на эти вопросы, вам не понравится =)
0
Ну не скажите, некоторые компании даже в блогах своих публикуют развёрнутое описание что и как там построено и почему именно так построено и зарплаты там вполне на уровне.
Например, TransferWise, из недавно мне попадавшихся.
0
Спасибо за статью.
А во многих компаниях ответили на все эти вопросы?
0
Добрый день!
Да, из 20 компаний где я задавал эти вопросы, ответили на все вопросы где-то 15 компаний.
0
Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших soft skills.
— увидел тут ссылочку на статью с моего сайта, про софт скиллс. Скажите, полезный материал, зацепил?
0
Из моего опыта, встроенные методы и типы данных JavaScript часто спрашивают даже на собеседованиях на senior frontend
Only those users with full accounts are able to leave comments. , please.