Удалёнка: опыт и лайфхаки
Реклама
Комментарии 714
+21

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

-2
еще не забывайте, что некоторые ищут человека на бюджет, скажем (для простоты понимания) 100т. И приходит такой крутой спец, чье резюме выкраили из колуаров оффлайн баз хантинговые агенства. Знает язык с экосистемой, как он работает под капотом (много кто от нечего делать в исходниках лазит?), на все вопросы дает исчерпывающие ответы, идеальный кандидат. Но хочет 150. Или приходит такой вхожденец в айти. На собеседовании мычит, на что-то отвечает, о чем-то слышал, знает синтаксис языка. И хочет всего 70. Ну и что, что потом переделывать за ним все и тратить время на ревью — зато дешевле и в бюджет влезаем. Так что берем его. А там научится (нет).
0
Isolation — как правило, но в зависимости от контекста может быть и Intrusion, или еще чем-то.
Почему на хабре так много статьей с кликбейтными названиями и водой внутри, так и должно быть?)
+31
Я за прошлый год проходил собеседования в несколько компаний и везде один и те же вопросы: какие паттерны программирования вы знаете, какие типы индексов существуют, как вы ищете затык в производительности, какая функция быстрее работает — эта или эта, и так далее.
Да, я много чего в своей работе использовал, для немалой части из этого я не знаю даже названия, но знаю, что оно лучше подходит в данной ситуации. А если есть проблема, для которой я не знаю сходу решения — всегда можно изучить вопрос и найти это решение.

Только одно собеседование кардинально выделялось из общей массы, разговор шел тет-а-тет с техдиром, он распросил с какими технологиями я работал, а потом мы разговаривали про различные проблемы на их проекте и на моих прошлых проектах, и как эти проблемы решались или можно решить. Это был увлекательный полуторачасовой разговор, после которого мне предложили работу с хорошей зарплатой.
-6
Всегда спрашивал кандидатов, что они делали раньше, как они могут об этом рассказать. Исходил из пословицы: «Кто ясно мыслит — тот ясно излагает».
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.» Тут сразу отлетают те, кто сдавал по «не своему» диплому. От таких людей в производстве (тех же программ) проку немного — ведь причин для неписания диплома при окончании ВУЗа только две: лень или неумность. Есть еще презрение к навязанной практике обучения — такой работник и в подразделении будет идти наискосок (если не в обратном направлении).
Если наниматель отбирает кандидата по узкому/широкому набору знаний, востребованному в данной конторе здесь и сейчас, игнорируя его прошлый опыт, то речь идет об одной задаче, а что делать потом, наниматель и сам толком не знает.
А ведь потом придется переучиваться всей конторе :)
+18
Мне бы про свой диплом было банально стыдно рассказывать) Убогое поделие на 1с которое 1сник с опытом сваяет за пару-тройку вечеров, да еще и текст диплома на 90% из воды)))
0
Мой диплом тоже «поделие», которое опытный программер сейчас сваяет, даже не заметив. Но это из-за развития технологий — в тот момент, когда оно писалось — там это было как минимум задачкой на подумать, даже для опытного спеца.
0
Ну я свой диплом писал в 14 году, так что тогда уже все было. Другое дело что я на тот момент только года 3 как заполучил себе компьютер, и потому в программировании на момент написания диплома разбирался как свинья в апельсинах).
-4
«Вы нам не подходите». Человек, учащийся на ИТ и не смогший за 3 года (!) набрать из бу/списанного барахла минимально рабочий инструмент — с ним что-то явно не то.
+7
Дипломная работа и не должна быть какой-то прорывной и инновационной. Это просто обычная инженерная задача, которая демонстрирует, что вы выучились на обычного инженера и способны с ней справиться.
+3

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

+2
Некоторое новшество свойственно всему, что делает инженер, потому что иначе его задача решается закупкой чего-то, что уже ранее было создано.
0
Такой диплом у нас требовали в магистратуре, а в бакалавриате и специалитете всем было до одного места…
+1

У нас тоже требовали. Ну как, скорее делали вид, хотя это и к лучшему.

0

А что делать если что не новшество то легко гуглится? Уже не инженер?

+2

Это не так последних наверное лет 40. Что бы это понять нужно побеседовать со своими профессорами. В лучшем случае можно получить рацуху, но это уровень уже не студента, т. к. требует внедрения. Второй путь более распространённый это диплом как основа кандидатской. Но оба варианта это единицы работ, даже не проценты. Пересчитываются по пальцам.

+2
Студенческие дипломы с рацухой от работающих студентов — это вполне обычное явление. Вот только: качество… пожалуй лучше умолчать, новизна отсутствует как класс, аналоги притянуты за уши, ибо реальной причиной является «насяльника сказала делать так», код… если соблюдают кодстайл, то код уже автоматом отличный. Помимо всего прочего, проект все еще на стадии разработки, а то и проектирования, т.к. всегда найдут более важные задачи для такой полезной трудовой единицы, как студент-дипломник.

Магистерские работы — полностью аналогично, за очень редким исключением.

Диплом как основа кандидатской? Это вообще очень редкий зверь. Тут студентов на магистра затаскивают чуть ли не насильно, ибо большинство понимает, что оно нафиг никому не нужно. Так что таким занимаются обычно те, кто целенаправленно готовится к эмиграции.

PS. Уже лет 7 в ГЭК:)
0
Упс, опечатка. ГАК — которая государственная аттестационная комиссия. Те самые плохие люди, которые валят студентов на защите.
-1

Посевы сохнут, запасы истощаются… Поторопись, Избранный! :D

+1
Вам не кажется, что сама по себе идея — ожидать реальное полезное рацпредложение от студента, который позавчера пришёл на практику и только-только разобрался, в чём состоит работа и задача — это нечто утопическое? Может быть в далекие времена, когда инженеры были редкой уважаемой птицей, могло быть такое, что на практику типа прислали студента и он что-то придумал, до чего вокруг никто не додумался, но сегодня… Очень сомневаюсь.
0
Да собственно ничего утопического. Заочники поголовно работают, многие даже по специальности. Да и среди очников попадаются те, кто работает уже год-два. И если ты не водпресс-манки в мелкой студии, то особых проблем ни с темой, ни с новизной быть уже не должно. Но в реале приносят дипломник в MS Access со справкой о внедрении и лютым говнокодом внутри.

Впрочим мой опыт был еще жестче: пришел на работу за пол года до защиты, получил аппаратуру, ноут и приказ подружить это все. Что получилось, уже проходило по всем критериям новизны и отличия от аналогов, правда на диплом я выбрал еще более амбициозный проект, но это уже совсем другая история.
0
Вот честно — уже 5 лет работаю но у меня даже близко нет идей что можно придумать нового что не будет банальной компиляцией из давно придуманных идей, а то и вовсе аналогом чего то уже сделанного другими в лучшем случае просто с другим сочетанием плюсов и минусов.
Какую нибудь библиотеку — так их уже сотни тысяч на любой вкус и идея в любом случае новизной блистать не будет. Фреймворк — аналогично, да и за ограниченное, довольно небольшое время дальше прототипа особо не уйдешь. Какую нибудь законченную систему — так где тут новизна (если это не разработка какого нибудь альфа-го, но боюсь если мы будем такие требования к студентам предъявлять у нас вузы будут заканчивать единицы на всю страну)
0
А с чего вы взяли, что банальная компиляция из идей, которую еще не реализовали на вашем используемом стеке/фреймворке/CMS/языке, нельзя использовать? Дипломная работа же не научная, у нее критерии новизны намного проще. А если вы придумаете что-то уникально новое в своей сфере, то это уже уровень диссертации будет.

Так что любой проект уровня мелкой вспомогательной либы на гитхабе — это уже вполне достаточно. Проект Скайнета от студента никто не ждет и не требует.
0
Ну так мы обсуждаем текущие требования по которым в принципе и поделие на MS Access/1с сойдет за дипломную работу, либо же гипотетические? И где та граница?
0
Поделие MS Access не блещет даже мнимой новизной, качеством исполнения, полезностью или соответствию законодательству. Но на все есть распоряжение ректора: студентов на дипломе не резать:)
Так что гипотетически большая часть текущих дипломных работы не должна проходить ГАК, от слова вообще. Практически же защищаются даже с синдромом дауна (без шуток, реальный случай), когда не то, что диплом сделать, а даже речь прочитать не может. Но за счет одного дауна учится пара бюджетников, так что рыночная экономика в действии.

Но попадаются и нормальные работы. Даже АРМы с сайтами бывают вполне нормального уровня оформления, где защищают не «я сделал <название из темы>», а фактически отдельные модули, которые пилили или допиливали сами.

А граница проста: студент должен продемонстрировать полученные навыки, но в тоже время не должен делать полную копию чего либо.
0
Как я уже упоминал в этой ветке: любая инженерная работа в какой-то степени содержит новизну, иначе в ней нет смысла. Речь же в данном случае о том, что раньше в дипломе ожидали каких-то значимых рационализаций, на уровне «Иван Петров, пока проходил практику на нашем заводе, внедрил автоматизацию в цеху продольно-поперечного проката, в результате чего выход готовой продукции „на гора“ вырос на 12.4%».
Мне кажется, раньше ситуация была другая: в институте людям давали знания, которых, вероятно, реально не хватало где-то на местах. А сейчас что такого может сделать студент, что реально не сделали люди, у которых он проходит практику и делает дипломную работу? Такое возможно, но маловероятно.
Поэтому хороший диплом, по крайней мере у разработчиков, — это качественное решение нормальной добротной задачи, с подробным описанием и оценкой экономической пользы.
0
Любая выполенная на рабочем месте задача оказывает экономический эффект. Новая либа для работы с CSV — -1 час трудозатрат на работу с этими файлами для каждого разработчика, и т.п. Значимых рацпредложений от студента никто никогда не ждал. Вспомните даже старую поговорку: теперь забудте все, чему вас учили, будем учиться работать.

Потому хороший диплом у разработчика: качественное решение ЛЮБОЙ задачи. А оформление и экономическую пользу все равно заставят допилить во время оформления диплома, было бы что оформлять.:)
0
Потому хороший диплом у разработчика: качественное решение ЛЮБОЙ задачи.

Так об этом и говорю
0
Люблю дебаты, когда у обоих одна и таже точка зрения))
+1
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.» Тут сразу отлетают те, кто сдавал по «не своему» диплому.

Спасибо, пополню свою личную копилку — это и правда отличный вопрос. Кто делал самостоятельно, тот и через 20 лет вспомнит как минимум основное, а кто не сам — того и через пяток лет вопрос уже в полный тупик поставит.
+4
Хм, у меня тема диплома (на самом деле диссертации, но не суть) прямо в CV написана, под пунктом об образовании. Если работа по профилю образования, то это отличное приглашение нанимающего к разговору и вопрос, на который собеседуемый точно знает ответ)
+1
вопрос, на который собеседуемый точно знает ответ)

Вы не представляете, какие кандидаты иногда приходят.

+14
А также сразу отлетают те кто диплом получал лет двадцать назад.
+9
А так же порождает вопрос: зачем меня вообще про диплом спрашивают? Как это к работе относится? )
+2
Я получал свой диплом 17 лет назад, и вкратце о нём спокойно расскажу — то, что ты сам руками полгода пилил, так просто не забывается.
+3
Еще как забывается. Не забывается только если ты после этого больше вообще ничего не делал! Бывает открываешь какой-то класс годичной давности, а там… «Что это за говно? Кто вообще так умудрился?» Смотришь аннотации — а это ты и писал о_О
+1
Наверное, сильно зависит и от человека, и от эмоций. Я вряд ли вспомню бОльшую часть из тонн кода, что я написал за свою жизнь. Но вот свой диплом 20 лет назад я помню очень даже неплохо, и про что, и как софтина работала, и как защищал.
0
Все что я помню про свой диплом — что код был сплошным говнокодом. Ибо прогаммирование я как раз примерно в том году начинал осваивать. Хотя это было в 2014 году. Защитная реакция психики, неприятные воспоминания забываются.
0
Все что я помню про свой диплом — что код был сплошным говнокодом

Скажем так, он вполне соответствовал тому, что обычно пишут студенты. Поэтому в общем-то и не стыдно, и даже внимания на это нет смысла обращать.
0
Тем не менее это последнее что я хотел бы обсуждать на собеседовании. Да и сильно его забыл по этой причине уже.
0
Ну а разве про него вас сейчас, при наличии шестилетнего опыта за спиной, кто-то ещё спрашивает?
+1

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

0

Я уже спустя месяц после сдачи даже не помнил какая тема диплома была) хотя делал всё сам и с интересом.

+6
Двадцатилетие моего диплома ещё не наступило, но уже недалеко. И я его помню. Потому что он был рожден лично и в муках. Детали, конечно, уже не расскажу, но в общих чертах — вообще без проблем.

Я даже помню дипломы пары-тройки однокурсников — у кого темы были мне интересны.
0
Ну а я работал не по диплому, и диплом писался на отвали. (Своё 4 получил)
0
Они отлетают по другой причине — работодатели считают их старыми.
А диплом-то как раз многие в таком возрасте помнят гораздо лучше, если вы понимаете о чем я.

Да, для статистики, моему диплому куда больше 20 лет, и я в состоянии много чего оттуда воспроизвести.
+4

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


То естъ первые года два-три такой вопрос наверное ещё имел смысл, а вот потом уже наверное лучше про более-менее актуальные проекты спрашивать.

+1
Это позволяет лучше понять, что вы сейчас за человек, как-то прощупать социальные скиллы, понять, подходит ли он по духу (если это конечно нужно в вашей компании).
Разговор про диплом — это возможность услышать как будущий сотрудник рассуждает о вещах, не связанных с работой, о том, как он относится к тому, что делал раньше, как относится к вузу, который закончил и так далее.
0
Поясните, отчего попытка объяснить что-то про диплом приводит к минусованию комментария? Просто интересно, что это, какая-то культурная несовместимость?
+8

Процесс написания диплома 20 лет назад позволяет лучше понять, что вы сейчас за человек?

+1
Не процесс написания диплома, а его рассказ о своём дипломе. Или его нежелание рассказывать о своём дипломе. Всё это нормальная беседа, знакомство с человеком, который возможно будет твоим коллегой, что в этом такого?
0
Диплом — это хорошо. Я свой диплом (10 лет назад было) писал примерно неделю, и параллельно взял первый свой «левый» диплом на заказ (это был диплом для студента НГТУ, Новосибирского тех.университета). Писал всё руками, даже картинки нарисовал все в Paint'е попиксельно, антиплагиат работ зашкалил. С тех пор примерно раз в год беру какой-нибудь диплом на заказ, чтобы голова не тупела, и делаю так же хорошо; как для себя. Для интереса ввязываюсь в области, с которыми напрямую не знаком, или пытаюсь закончить в рекордные сроки. Последние несколько штук за день написал с нуля. С таким подходом в любом дипломе каждая строка текста — «родная». Только как это поможет? У меня диплом об образовании почти нигде не спрашивали(а там есть что показать), не то чтобы про мою дипломную работу.
0
Но не сказал бы что это особо поможет работодателю понять какой я сейчас разработчик.

Говорить про это долго и подробно едва ли имеет смысл. А вот просто узнать, помнит ли вообще соискатель про свой диплом — это вполне. Если не помнит — это звоночек. Слишком серьезно на этом зацикливаться не стоит, для найма важны другие вещи, но как фактор отсева в ситуации «прочих равных» — вполне сгодится. То, что человек ничего не может сказать про свой диплом — ни о чём хорошем не говорит.
0
Это скорее мнение об утверждении про «пяток лет», нежели об образовании)
0
Сделал с десяток дипломов на заказ, у всех студентов были пятерки, я всегда уточнял ради интереса. Последняя дипломная подытожила красный диплом заказчику. Один раз только четверка была — знакомый обратился за сутки до сдачи и просто не успел всё выучить, и плавал в материале
0
Как у людей про диплом пригорает, аж минусят. Я свой диплом до сих пор помню и рассказать всё могу. Автоматизация очистных сооружений с написанием софта в ПЛК и визуализацией.
+3
А я помню число Авогадро и валентность хрома. Давайте это тоже спрашивать на собеседованиях.
НЛО прилетело и опубликовало эту надпись здесь
0
Кто не сам, того вопрос поставит в тупик даже сразу после защиты (не говоря уже про вопросы на защите).
А кто сам, то спрашивать надо: что вы сделали не так в своей дипломной работе? Правда с определенного момента ответ будет только один: все.
+2
«Если Вы писали диплом, расскажите о нем.» Тут сразу отлетают те, кто сдавал по «не своему» диплому.

А вам действительно интересно про моделирование распределения выхода на хроматографической колонке, и чем FPLC отличается от HPLC?
+2
На собеседовании было бы интересно послушать, как человек об этом будет рассказывать.
+5
Так и запишем, работодателю ваш диплом нужен для того, чтобы на собеседовании послушать, как интересно вы будете о нем рассказывать.
Видимо больше «хорошему» кандидату рассказать не о чем.
0
Откуда такие выводы? Вроде никто ничего подобного не утверждает.
Диплом, если и нужен работодателю, то только для того, чтобы закрыть нужные требования по лицензиям/тендерам. А на собеседовании — это просто тема для разговора.
+2
«Какая твоя любимая пони?» тоже тема для разговора. Но на собеседовании она будет не очень уместна. Собеседование — это все-таки не беседа в баре с друзьями.
+2
Именно поэтому диплом — вполне нормальная смежная тема, а «любимая пони» — не особо.
0
Ну вот тема моего диплома — адаптивный фильтр Калмана-Бюси. Там чистый матан и к программированию всё это относится крайне отдаленно.
0
Я бы спросил, что это, из какой области (выяснил бы, что вы занимались теорией управления и статистическими методами, а это уже полезные смежные знания для разработчика). Спросил бы, как это можно применить, и была ли какая-то прикладная часть в дипломе (что именно адаптивного, получается, было приделано).

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

И как я уже говорил в другой ветке, если кандидату не хочется об этом рассказывать, видно что ему всё это не нравится — не надо его форсить, просто отметить для себя его нежелание делиться чем-то, что выходит за пределы задачи.
-1
А с какой целью вы все перечисленное хотите выяснить? Область деятельности будущего сотрудника связана со всем этим или просто чтобы было?
И вот эти разговоры из разряда «чтобы было» больше всего раздражают.
Зачем высправшивать человека об особенностях сортировки деревьев, например, если его собеседуют на должность разработчика ПО для микроконтроллеров и ни один здравомыслящий разработчик применит готовое библиотченое решение, а не займется созданием собственного велосипеда с треугольными колесами?
+1
Вот как раз на микроконтроллерах готовых библиотечных решений по балансированным деревьям очень негусто. И впрямую применить что-то из «общепринятого» кода из интернета тоже не получается — API не те, не лезут в мелкий эмбеддед (в применении к чужим реализациям деревьев как раз очень иллюстративно получается: я не видел пока ни одной чужой реализации балансированных деревьев, которая не хочет памяти из кучи).
Да и вообще, как эмбеддер говорю: не надо в эмбеддеде бояться треугольных колес.
-1
Вопрос то в том, нужен этот самый велосипед или нет. Часто ли на микроконтроллере двигателя нужно сортировать деревья? Мне лично подобным заниматься не приходилось.
+1
Именно сортировать — не приходится, так как балансированное дерево уже само по себе сортированное в любой момент времени :)
А если речь идет вообще о применении деревьев в микроконтроллерных проектах — ну, иногда приходится. Я вот сейчас страдаю от того, что в свое время не довел до ума свою пригодную для микроконтроллеров реализацию андерсоновских деревьев, без них приходится думать о производительности в одном критичном модуле, где с деревьями думать было бы не надо. Возможно, даже придется таки доделать эти деревья, там глючил только один краевой случай перебалансировки при удалении.
-1
А в чём проблема перегрузить оператор new, и выделять память для узлов дерева не из кучи, а из отдельного пула? Тогда можно пользоваться реализацией из STL, и никаких велосипедов. Правда, самому мне так делать не доводилось, потому что необходимости не было.
+1
Проблема в том, что этот пул тоже надо создать, и знать заранее его размер (и, скорее всего, отдельно обрабатывать ситуации, когда объект для вставки в дерево есть, а под управляющую структуру памяти в пуле уже нет).
А можно от всего этого bloat-а уйти, если управляющие структуры просто с собой таскать, в стиле структур из линуксового ядра: подструктура в качестве управляющей структуры, и container_of() для получения «прикладного» элемента по указателю на управляющую структуру. Заодно решаются всякие сложности со вставлением одного и того же «прикладного» элемента в несколько разных контейнеров — получается лаконично и запутаться сложно.
+1
А вы попробуйте разговорить интроверта :) Особенно когда сразу видно — человек адски зажат от самого факта собеседования. И только от его любимой темы можно хоть как то перейти к собственно профессиональному разговору. Например, попросить перечислить виды и семейства этих пони и попросить спроектировать структуру данных для хранения описаний. Или интерфейс для сайта по обмену мнениями об оных…
0
Может это со мной что-то не так, но я бы нахрен свалил после пары таких вопросов. Работодателя касаются только мои профессиональные навыки, остальное — это не его дело.

Если собеседующий не может адекватно оценить профессиональные качества по ответу на какой-либо вопрос, то его просто не нужно задавать. Потому что просто игнорировать какую-то информацию крайне сложно, и в итоге на решение собеседующего будет влиять заведомо неадекватная оценка. Так зачем искусственно вносить такие искажения? Я уж молчу, что собеседующий тратит время кандидата подобными вопросами «за жизнь».
0
Профессиональные навыки не работают в офисе сами по себе, они всегда прилагаются к человеку, которому нужно будет общаться с коллегами.
Крайне редко где производственный процесс выстроен и отлажен таким образом, что люди действительно контактируют друг с другом только «профессиональными навыками».
Именно поэтому, как тут уже кто-то отмечал, компании ищут работника, который впишется в корпоративную культуру — и это едва ли не так же важно, как его умение кодить.
В этом смысле, тот факт, что вы бы свалили после таких вопросов — это удачное завершение собеседования с обеих сторон.
НЛО прилетело и опубликовало эту надпись здесь
0

Ого, тоже моделировал этот вопрос, но для сверхкритической хроматографии, бывает же)

0
Какими путями занесло на эти галеры?
У меня в бэкграунде военмед, потом кафедра биохимии биофака ЛГУ. Где-то по дороге цапанул ещё кафедру неорганики педиатрического, отдел биохимии ИЭМ… А переход с любительского Quick Basic на C и плюсы случился в отделе клеточных культур НИИ цитологии. С тех пор так и понеслось, всё дальше и дальше от биохимии, и ближе к кнопкодавству. Ещё в прошлом веке :)
0

У меня путь более прямой) учился на факультете кибернетики в РХТУ и на дипломе начал моделировать диффузию в пористых телах. Потом продолжил тему в кандидатской — вот в качестве интересующего процесса, где была бы и диффузия и адсорбция в сверхкритической среде и в пористом теле взяли сверхкритическую флюидную хроматографию. Научная группа плотно занимается изучением таких вещей, вот и выдали мне расчетный комп с GPU, так что я ещё в 2008 начал писать на CUDA, ещё на релизе 2.3, кажется. На моей кафедре программирование давалось нормально: каждый семестр был один предмет на новом ЯП, так что диплом/кандидатскую писал на С/С++ и питоне — хорошее было время) И задача интересная, и в лаборатории побывал и в целом с людьми хорошими пообщался, про HPLC в том числе)

0
Фигасе что всплывает. У меня Менделеевка вызывает какие-то воспоминания про комплексоны рутения, и первую публикацию (последней фамилией, само собой) в ЖОХ. Давно было :)
-2

Если человек заявил, что имеет законченное во и при этом нет диплома, это наводит на нехорошие мысли.

+2
У меня высшее. Плюс интернатура, ординатура и аспирантура. А диплома не было) И курсовых не было)
+3

А вас слова "интернатура, ординатура" не настораживают? У человека не инженерное высшее. Он, насколько я понимаю, на врача учился (именно оттуда возникают "интернатура, ординатура"). Вот за аспирантуру — не скажу, там можно было и по другой линейке пойти, но там один фиг диплома не будет. В случае успеха там делается и защищается диссертация, а получается степень — к(*)н.

0

Представил:
"А зачётной работой была операция по удалению у (не знаю как у медиков, но предположу вымышленную версию) поросёнка опухоли, примерно в том месте где вы пару минут назад чесали затылок… "
… далее звук падения со стула hr…
:)

0

Не везде дипломная работа — это часть степени. У меня первая израильская, math & CS, двадцатилетней давности, без диплома.

+2
Вот просто даже интересно, а если человек диплом не писал? Ну вот закончил медицинский институт, а потом ушел в другое направление и уже, как минимум, не писал диплом?
0
Ну, у меня два друга вообще без вышки работают программистами, с исключительно ясным и системным мышлением. Такого уровня программистов даже с вышкой надо ещё постараться найти. Один из них написал для других 3 или 4 диплома.
Хотя и им образование было бы не лишним — алмазы требуют огранки.
+4
Хотя и им образование было бы не лишним — алмазы требуют огранки

научится следовать маразматическим требованиям и сдавать зачеты по устаревшим дисциплинам?

p.s. шучу конечно, но как говорится в каждой шутке есть доля…
0
Ну у меня так — я с 4го курса ушёл от скуки. Написал половине группы дипломы потом, сам так и не получил вышки. Из всей группы программистом работаю я один
0
В конце 90х у студентов ехСССР еще был выбор- пишешь диплом или лишний ГОСэкзамен.
Меня лично до диплома не допустили так как в нашем областном центре не нашлось 3 специалистов для написания рецензии по данному вопросу, а с коллегами из соседних ВУЗов региона наши спец-ы разругались вдрызг.
0
Ваше мнение не понравилось людям, слишком уж вы радикально говорите о тех, кто не может про свой диплом рассказать. Но сути не меняет, я с вами согласен. Вопрос про диплом очень даже хорошо смотрится на собеседовании. Притом, он не только раскрывает собеседуемого, он еще и может кое что рассказать про собеседующего. Был на собесе, где тех. спец. загуглил тему моего диплома, почитал про суть, и некоторое время поддерживал со мной разговор на эту тему. Для меня это хороший знак, компания дает возможность своим спецам подготовиться к собесу, а спецы заинтересованы взять человека c широким кругозором и нормальным образованием
0
Как наличие или отсутствие диплома влияет на текущие навыки в программировании?
Обсуждение посторонних тем на собеседовании само по себе тревожный звоночек. Собеседующий не способен спрашивать по теме, тянет время, говорит о несвязанных с работой вещах… Вероятно и на работе будет пойди не знаю куда, сделай не знаю что…
+2

На собеседовании проверяют не только текущие навыки программирования. Те кандидаты, которые это понимают, при равных навыках программирования имеют преимущество. :)

-1
Побуду в роли капитана.
Если один программировал 1000 часов и 500 часов учил английский, а второй 500 часов программировал и 1000 часов учил английский, то у первого будет лучше навык программирования а у второго лучше будет английский.

Никаких равных навыков не бывает… всегда компромисс
0
Стоит учитывать скорость приобретения навыка в единицу времени.
Один 1000 учил английский и дорос с А1 до В2, второй тоже учил английский 1000 часов, но с А1 дорос только до А2.
Кому-то, чтоб понять новую технологию, надо 100 часов, кому-то 500.
-1
Стоит учитывать скорость приобретения навыка в единицу времени.

Как? В рамках собеседования…
0
А у меня образование — провизор по специальности фармация, и вместа диплома госы. Свои стандарты, диплом только отличникам давали писать. При этом, работаю, начальство довольно.
+1
Лень, нетерпение и самомнение — три главных добродетели программиста. © Ларри Уолл
0
Проектирование плавучей судовой ядерной энергоустановки мощностью 60 МВт.
Поговорим?
+1

Танковый балвычислитель.
Почему бы и не поговорить :)
Обменяемся секретиками.
"Если диплома нет" — как уже сказали, "звоночек" и требует от собеседующего смены алгоритма.
Работал с тремя хорошими программистами ( по делам их судите их): с профильным образованием, со смежным (радиоэлектроника, там программирование преподавали), и без образования (диплом получил потом в филиале вуза, знал больше преподов, но корочки в СНГ очень помогают). Разные бывают пути в профессию, — а вы ждали более оригинального?

0
Это называется «а вы точно не хотите заграницу в ближайшие 5 лет? тогда распишитесь вот тут».
0
Это диплом, студенческий? Какой ВУЗ?
ИМХО, крутовата тема для всего лишь диплома. Даже дисер — и то слишком общо.
Больше похоже на монографию. Или мемуары.
0
Диплом, студенческий, специалиста. СПбГМТУ.
Конечно, уже 6 лет прошло после защиты, но диплом был основательный. Расчёт размеров конструкций: от самого блока до ТВЭЛов; какие хим.элементы будут использоваться как топливо; как реализуются контура; чертежи-чертежи-чертежи…
Скажу так: мало мне не показалось, благо — преподаватель смог заинтересовать и всячески помогал и принимал участие.
Только вот незадача: к разработке ПО — это не имеет никакого отношения. Но если посмотреть с другой стороны, то это показывает то, что если я с этой темой разобрался и смог защитить диплом, то наверное и с веб-проектом условного интернет-магазина я тоже смогу справиться.
0
Собственно вопрос вот в чем: неужели вчерашний студент (пусть даже и с преподавателем) в состоянии спроектировать такой объект? или руководить проектными работами? Мне почему-то кажется, что это роль для ГК с 30летним опытом и коллектива человек в 300. Результат нескольких лет работы в виде чертежей и техдока надо будет везти на… газели хотя бы.
А такого рода диплом — просто дайджест, не больше.

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

В таких ситуациях "дьявол прячется в деталях", и в общем, на мой взгляд, тут есть некоторое пересечение с ИТ, когда сначала "набрасывают" прототип, разделяют на блоки и доводят идею до реального продукта который можно применять, просто у АЭС и т.п. деталей намного больше и технический долг недопустим :)
(В конторе по разработке для АЭС работал, чертежи делал...)

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

А тут — диплом! Вероятно, я чего-то не понимаю.
0
А такого рода диплом — просто дайджест

Это скорее эскизный проект — расчёт параметров, габаритов, общей компоновки, блочной схемы управления и регулирования, прикидочная оценка эффективности — всё это без детализации вплоть до каждой трубки, клапана, электродетали. Нормальная дипломная работа в областях, где своими руками что-то сделать недоступно по цене, поэтому остаётся только считать — это игровая ситуация: воображаем себя Главным Инженером, на вход которого подают ТЗ с требуемыми характеристиками, на выходе получается более-менее технически-обоснованный набросок, как это примерно будет выглядеть и сколько стоить, а скучные детали и производство горы документации отдаём сотрудникам помладше :)

0
Для поиска технических специалистов может и норм вопрос, но скорее похоже на какую-то месть за то что вы писали свой диплом сами. К примеру для продаж я бы искал людей с высшим образованием которые бы ничего не знали о своем дипломе, но при этом помнили цвет глаз секретаря в приемной или ФИО рекрутера который направил их на собеседование.
P.S. Сразу уточню)) учился я ОЧЕНЬ плохо, в дипломе не написал ни строчки — прокрастинация наше все. Пока эту проблему не решил, продвинутся в своем развитие так и не получилось)) Но решил я ее уже после универа, спасибо психологам
0
Практика показывает, что это не совсем работает.

Точнее, на этом вопросе можно сорвать джекпот, потому как если человек действительно начинает увлеченно рассказывать про свой диплом, то это практически стопроцентно хороший специалист…

А вот противоположный вариант не значит практически ничего. Ну вот не захотел человек написать нормального диплома… Что это значит? Да ничего ровным счётом…
0

"Что это значит?"
Вариантов три (если есть во): лень, неумелость, презрение.

0

Самое важное забыли: которые были когда-то. Есть ли сейчас? А чёрт его знает, по этому вопросы вычислить невозможно.

0

Либо адекватный выбор средства для достижения определенной цели. Вам точно нужен специалист который для типовой формочки обратной связи прикрутит туда бота с ИИ для разработки которого попросит оплатить аренду кластера? Просто потому что он увлечен и ему интересно? Диплом может быть реальным увлечением, а может быть просто средством закончить отношения с ВУЗом всех устраивающим способом. Посредственный диплом не говорит вообще ничего. Особенно если вы не в курсе как в этом заведении вообще учат и чему.

0
Ещё есть куча вариантов. Например, родители в этот вуз запихнули, отучился для галочки
0

"умение оптимизировать свой труд и не заниматься бесполезной неоплачиваемой работой"


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


А так работал с 2-3 курса универа. И мне в целом к 5 курсу было уже до фиолетовой лампочки закончу я его или нет по большей части. Приходил туда поспать после ночных смен и сдать лабы. Закончил только потому что уже потраченного времени было жаль и бросать на пол пути не рационально.


Диплом писал на коленке за вечер, ибо знал что какую фигню не напиши его все равно читать никто не будет.

-3

Я буду считать это презрением.
Возможно, Ваш ВУЗ ещё за пару лет до поступления именовался техникумом ( причём не IT ориентации), или это был филиал, открытый в помещении музучилища (к примеру).

+2

Ну вообще то имеет статус НИУ.


Что не отменяет того что диплом это бесполезная никому не нужная работа, за которую не платят. И что вуз не нужен если не собираешься сваливать из РФ (там нужно для галочки что у тебя вышка). А учеба на IT специальность это пустая потеря 5 лет жизни если ты не собираешься заниматься чем то фундаментальным и матаном. И выпускник любого вуза, без опыта реальной работы может рассчитывать только на работу в макдаке. Ну максимум на какаю то бесплатную стажировку по профилю.


P.S. у нас с выпуска самый успешный парень так и не забрал корочку. Ему лень было и она нафиг не нужна уже была ибо к 4 курсу он свою IT компанию открыл.

+1
Чем глубже приходится погружаться в ИТ, тем сильнее потребность в вузовских знаниях. Можно, конечно, учить самостоятельно. Вопрос в том, насколько удачно выйдет.
После вуза, на мой взгляд, проблема не столько в практическом опыте, сколько в опыте работы, как таковой. Потому что опыт программирования никто не мешает получить в пет-проекте, а вот опыт труда за деньги, и соответствующей социализации, вряд ли.
0

Чем больше опыта и чем старше становлюсь. Тем меньше базовых знаний в IT требуется для работы и больше софт скиллов, если ты хочешь расти в ЗП и развиваться. Ибо с опытом тебя с удовольствием ставят на руководящие должности или просто ответственные где нужно разруливать процессы. А как специалистов ставят молоденьких ребят из универа, которые готовы фигачить что угодно за чашку риса и не задавать вопросов.

0
Это далеко не всегда так. У нас например все ведущие технические специалисты люди с возрастом 40+. Что программисты, что инженеры. А процессами местами рулят ребята и девчата до 30, но при этом с образованием вроде «ИТ-менеджемент» или «Бизнес-информатика».
-1

Печально что ещё могу сказать.


Обычная компания с "эффективными менеджерами", которые не понимают и не знают что делают.

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

Ну если их задача обеспечивать свежим кофеем и печенками или сидеть на собраниях то пойдут.


А вот тимлида который ничерта не понимает в IT и в том что его команда делает, спасибо мне не надо.

+1

Отсутствие такой должности в штатном расписании не отменяет что кто то к команде берет на себя эту обязанность.

0
Эта обязанностъ вполне себе может быть распределена между разными людьми. Это конечно не всегда работает идеально, но вполне себе встречается на достаточно приемлемом уровне.
+1
Между вчерашними студентами конечно нет. Но 25-30 лет это уже не вчерашние студенты.
0
Ничего печального. Давно и не мной подмечено — отличный опытный инженер вовсе не обязательно окажется хотя бы неплохим менеджером. Это совершенно разные профессии, требующие разных знаний и наклонностей.
-2

Менеджером да. Я же говорю кофе приносить и инвесторов в жопу целовать сойдут.


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


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

0
Джуны и мидлы за советом по работе, подходят максимум к тимлиду, эт опо сути такой-же инженер. Выше него еще туева хуча менеджеров, чьи обязанности посложнее целования жопы и разноски кофе.
+2
О, ларчик просто открылся. Меня руководящие должности, в плане личного роста, не интересуют. Да и вообще не интересуют, по большому счёту.
-3

А они много кого не интересуют. Но в какой то момент на проекте оказывается что если не ты. То возьмут фиг знает кого и все пойдет через жопу.


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

+1
Так я написал «по большому счёту». Ситуации разные случаются. Главное, что наличие гипотетических перспектив получения руководящей должности не является, для меня, определяющим фактором в плане личного роста.
-1

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


С опытом очень редко получается сидеть в своем мирке и заниматься чем то там не взаимодействуя с людьми. Хотя такие узкие специалисты есть. Но это скорее исключения.

0
Да, право каждого решать, на какие именно обязанности он будет затрачивать своё, путь даже оплачиваемое, время.
Ох, речь не о сидении в своём мирке. Управление банально новая сфера деятельности.
-2

Конечно это право каждого решать.


Но по мне так если специалист с 20 летним стажем скажет что то вроде "Я вижу что мы делаем не оптимально и это работать не будет, но ничего не скажу ибо меня взяли кодить, а не управлять. зато мой алгоритм работает на 0.005 попугая быстрее". То это весьма хреновый специалист. Который просто протирает на работе штаны.


Ибо задача коммерческого IT специалиста сделать продукт, а не бенчмарками мерится. Для этого идите в олимпиадное программирование или в демосцену и т.д.

0
У вас на мой взгляд какое-то очень узкое понимание «управления» в целом и «управления процессами» в частности.
-3

А у вас сильно узкое понимание задач у опытного специалиста. Заточное на чистую теорию и жесткую специализацию. Что нужно для крайне узких областей.


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


Как пример знал одного человека который про novel сети знал все. Вот прям все что не спроси знал. Теперь он никому не нужен.

0
А у вас сильно узкое понимание задач у опытного специалиста. Заточное на чистую теорию и жесткую специализацию. Что нужно для крайне узких областей.

И с чего вы вот это вот вдруг взяли? :)

P.S. Просто представьте себе с другой стороны «опытного менеджера», который вдруг начинает везде лезть и рассказывать программистам как им надо код писать. Ведь его задача тоже «сделать продукт» и ему тоже надо развиваться и не быть «исключительно узким специалистом» :)
0
Специалист действует в рамках своей зоны ответственности. Его мнение имеет в указанных рамках вес. Или, по крайней мере, должно иметь. Вот здесь он обязан высказываться. И, по идее, его мнение должны принять во внимание.

Он может высказаться за рамками зоны ответственности, если ему есть, что сказать, но его могут не послушать. Иногда действительно не слушают. Поэтому здесь проблема не в его молчании, а скорее в спросе на мнение со стороны руководства. Да и процессов в фирме вообще.

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

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

Т.е. должны сложиться определённые условия. Редкий случай человека в определённой ситуации. Отсюда, нельзя делать общий вывод, т.к. подобные ситуации редки и они являются не целями, а постепенно формируются в процессе трудовой деятельности. Нет в них чистого карьерного роста, который можно было бы спрогнозировать.
0
Чем чаще я слышу подобное, тем отчётливее убеждаюсь в том, что стране не следует оплачивать так много бюджетных мест для бесплатного высшего образования.
С одной стороны, слишком много людей не ценят того, что им достаётся бесплатно. С другой стороны, плодятся вузы, не годные ни на что, кроме распила денег и прохождения аттестации.
+1
Проблема не в количестве бюджетных мест, а в неадекватных требования по наличию высшего образования к месту и не к месту. Не будут требовать высшего образования там где его реально не надо — не будут люди так стремиться получить корочку, а будут стремиться получить знания (те, кому они нужны).

Как Вы думаете — нужно ли программистам высшее образование?
И как вы думаете — требуют ли его? )
0
И пункт третий: как вы думаете, какие знания остаются через 1-2-5 лет после выпуска?
PS Искали человека с опытом С/С++, знанием математики и опытом с параллельными вычислениями, нашёлся единственный специалист возрастом в 61год, сидит, переносит пару полезных библиотек на CUDA, ибо или люди математику уже (ещё?) не помнят, или С не знают.
+2
И пункт третий: как вы думаете, какие знания остаются через 1-2-5 лет после выпуска?

Ну по моему опыту если человек что-то один раз понял или хотя бы выучил, то он уже знает что это существует в природе. А во вторых вспомнить это всё через 5-10-15 лет гораздо проще чем выучить с нуля. Ну или как минимум мой мозг именно так работает.

ибо или люди математику уже (ещё?) не помнят, или С не знают.

Или просто не хотят такими вещами заниматься за те деньги что вы им предлагали :)
+2
Как Вы думаете — нужно ли программистам высшее образование?

Это полностью зависит от сферы применения продукта. Там, где велика ответственность и цена ошибки, я считаю, должны работать люди с высшим образованием, потому что это просто показатель определённой инженерной культуры. ПО для транспортных систем, медицинского оборудования, финансовых приложений, оперирующих деньгами и проч. — я бы хотел, чтобы этим занимались люди с достаточной широтой знаний и системным мышлением. А вот всякие веб-сервисы делать или мобильные приложения для заказа кофе, — для этого действительно долго учиться не обязательно.

Вообще, требования по высшему образованию напрямую происходят из законодательства. У тебя, к примеру, не может быть в штате программиста без высшего, ты можешь назвать его только техником. Соответственно, не пройдешь какие-то тендерные условия по софту, не получишь лицензии по безопасности на свои продукты и т.д. Так что очень часто это никакая не прихоть эйчаров, а реальное жёсткое требование бизнеса.
+2
Вообще, требования по высшему образованию напрямую происходят из законодательства. У тебя, к примеру, не может быть в штате программиста без высшего, ты можешь назвать его только техником.

Мне интересно было бы посмотреть где и как конкретно это прописано в законодательстве.
0
Гуглите: «профессиональный стандарт программист», ну в целом про статус профессиональных стандартов.
0
Какой занимательнейщий образчик бюрократии. Спасибо, не знал что такое существует :)

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

Да и… думаете у специалиста с 10, к примеру, годами опыта работы с ВО и у специалиста с 10 годами опыта работы без ВО будет очень разный уровень широты знаний, инженерной культуры и системного мышления (ну пусть опыт работы у них будет примерно одинаковый)?
А 20 лет?

Я не к тому, что бы сказать что ВО не нужно. Я к тому, что бы вы реально задали эти вопросы себе.

То что джуны с ВО скорее всего знают и умеют чуть больше — это вполне возможно. Но… джуны это очень узкая область и их и так и так не будут брать на что то серьёзное ещё очень долго.

ЗЫ: ну, про требования законодательства — это сильно за уши притянуто. Но пусть будет так — это как раз то о чём я и говорил — неадекватное требование к наличию ВО.
0
Я к тому, что бы вы реально задали эти вопросы себе

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

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

Я не прошу людей показать диплом на собеседовании, и у меня не возникнет никаких проблем с образованным человеком без диплома. Мне хочется видеть сотрудника с образованием, диплом — это некий маркер, который, плюс ко всему, нужен для отдела кадров, чтобы соблюсти все придирки ТК. Поэтому в наших вакансиях такое написано.
0
Мне хочется видеть сотрудника с образованием, диплом — это некий маркер, который, плюс ко всему, нужен для отдела кадров, чтобы соблюсти все придирки ТК. Поэтому в наших вакансиях такое написано.
Ну вот поэтому и такая ситуация с ВО. Маркер нужен всем, по делу и без дела — поэтому «маркер» и продают/покупают или отсиживают ради его наличия, а не знаний. И, раз есть спрос — есть и предложение.
=)
Не очень понимаю, зачем пытаться разговаривать со мной так, как будто я студент на семинаре. Я думал на эту тему ещё пятнадцать лет назад, когда был студентом и искал работу, думал и семь лет назад, когда искал сотрудников себе в помощь, думаю и сегодня, когда участвую в найме в нашу компанию.

Прошу прощения, если мой тон вам показался снисходительным или лекторским. Ничего такого не имел в виду )
0

НИУ… Случайно, не МИЭТ?
Без корочек в СНГ тоже непросто. Работал в корпорации, постоянно кадровые чистки по дипломам (понятно, что блатных не затронут, но безродным приходится напрягаться), и по наличию и по соответствию требованиям к занимаемой должности. Та же история с госслужбой. И даже работа в маленькой конторе не всегда спасает: регулярно сканы дипломов прикладываем к заявкам на участие в тендере.
Но если реально по знаниям и навыкам, можно ли их определить по рассказу о дипломе, можно. Иной раз человек критикует свой диплом, что только добавляет ему профессиональных баллов.

+1
Хорошо что я не писал диплом.
Есть еще презрение к навязанной практике обучения — такой работник и в подразделении будет идти наискосок (если не в обратном направлении).

И это прекрасно, потому что он укажет на неэффективности вашего рабочего процесса(если он адекватный, а не примадонна которой всё не нравится).
Если наниматель отбирает кандидата по узкому/широкому набору знаний, востребованному в данной конторе здесь и сейчас, игнорируя его прошлый опыт, то речь идет об одной задаче, а что делать потом, наниматель и сам толком не знает.

Ага и это нормально. Есть планы на год-два-три. Нужны такие то навыки. А что там дальше — не знает НИКТО.
0

Планирую на 40 лет вперёд. Диплом писал сам, хоть и раздолбай в целом.

0

Да какая разница писал или не писал диплом человек с 10-15 годами опыта, если он в остальном устраивает? Для меня в более выигрышной позиции был бы человек, который вместо учёбы в бестолковом вузе по программе 10-ти летней давности пошёл получать знания на работе. Ну, наверное, за исключением физиков-ядерщиков, врачей, пилотов и иных специальностей, где на работе ошибаться нельзя.

+3
причин для неписания диплома при окончании ВУЗа только две: лень или неумность.

эм… а как насчет «в ВУЗе знания были весьма поверхностные, за то к этому моменту уже 5 лет работал по специальности и перерос в тим.лида и совладельца»?

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

Смотря где Вы переросли тимлида и совладельца. Одно дело если в Яндексе, и совсем другое — в ООО "Рога и Копыта".

0
Соискателей с не профильным образованием не рассматриваете то есть?
0

А если не ИТ специальность? Ну гидравлика(не моя но один факультет) к примеру, много будет понятно? А если прочнисты? Нет я бы с удовольствием рассказал про то как на OpenGL + delphi делал визуализацию, как перводил решение с Maple в код на паскале и сделал бы ответвление о том что Паскаль изучал ещё в школе и участвовал в олимпиадах и до сих пор неуютно за нерешённую задачу про шахматы с визуализацией… Но ведь это практически не имеет отношения к тому кем я являюсь сейчас, т.к. за эти годы произошло много событий а люди со временем меняются, но мало того, их воспоминания могут сильно отличаться от того что происходило на самом деле, даже без учёта того, что очень сложно понять рассказывают ли вам то что думают или сильно фильтруют :)

-3
Совершенно с Вами согласен — и про диплом и про «переучиваться всей конторе». Думаю, что читатели «Хабра» со стажем, прекрасно это сознают. А молодежь, которой «сделали диплом» — пусть не обижается.
0
Диплом сильно зависит от уровня учебного заведения и научного руководителя. Я бы например был бы рад написать что-то резонирующее с моим профилем, но МГТУ хотел другого, так что там вода водой на 90% и маленькая утилита под капотом. Зато я могу рассказать темы всех 5 дипломов, которые я делал в голодные студенческие годы для других.

Это я к чему: к сожалению, диплом (поведение в стенах ВУЗ-а) не показатель, пока с образованием беда.
-1
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.»

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

0
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.»


Диплом пишется для того, чтобы пройти босса. Поэтому какой в вашем заведении босс, такой и диплом. Ориентироваться по диплому — это абсолютно неправильно.
(подразумеваются институты/универы в СНГ).
+1
Да и ежу понятно, что если много ходить по собеседованиям, то можно наловчиться их хорошо проходить, даже не имея особого практического опыта. Т.к. вопросы и задачки все однотипные.
+2
в opensource хорошо — можно поглядеть на _результаты_ работы человека до собеседования.
в отдельных случаях можно даже оценить прочие аспекты, типа коммуникабельности, английского и проч.
0
Да, но туда редко кто смотрит. Как-то обсуждали с коллегами этот вопрос. Но, может быть, это и к лучшему: когда я показываю кому-либо свой код, люди обычно демонстрируют поведение из соседней статьи про веб-сервер Actix & community.
+1

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

-1
А ещё — каждая новая порция кода, залитая на открытый GIT или SVN, имеет своего автора. По стилю и качеству авторского кода очень хорошо видно компетенцию, опыт, эстетические предпочтения и даже темперамент его создателя. Специалисты-кадровики из любой крупной фирмы могут легко составить психологический портрет каждого из ведущих разработчиков и либо переманить их у конкурентов, либо демотивировать их каким-либо образом (это не паранойя, а обыденная реальность того мира, в котором мы все пытаемся выжить).

Из данного обсуждения некоторых реалий opensource на форуме одного публичного проекта

P.S. Но это, похоже, не приемлемо для Вашего описанного случая кадровиками. :)
+2
Простите меня, но такие специалисты-кадровики, которые знают и применяют и гит, и психологию в достаточном объеме, встречаются реже именных бриллиантов.
И если компания может позволить себе таких кадровиков — то уж сказать «чувак, вот тебе открытый бланк с требованиями к рабочему месту, зарплата *1.5 -2 от твоей текущей, вот список проектов и задач, где ты будешь полезен, пошли к нам, будешь звездой» компания тем более сможет.
Скажите, вы бы отказались от такого оффера, если задачи и проекты как минимум, не хуже/не скучнее?
-1

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

+5
А сисадмин то тут причём? ДБА такие вопросы нужно задавать. А вот если он (что сисадмин что ДБА) говорит что нужен сетевик для этого, тогда да, печаль беда.
+2
При том, что хотелось бы, чтобы он знал, что за это отвечает не сетевик.
+1
Ну как это при чём? Вы ещё скажите, что сис.админ не должен 1с конфигурацию за пол-часа написать или проводку в автомобиле директора поменять.
0
Конечно должен, ещё юристу бумаги подписать, аудит провести и с секретаршей переспать пока шеф в отпуске.
+1
Ремонтировал на предприятии кран Liebherr в должности сисадмина, потому что мог. Даже премию не дали.
НЛО прилетело и опубликовало эту надпись здесь
-2

Сисадмину нужно знать, что если в приложении используются транзакции с изоляцией, то для MySQL это гарантированно означает InnoDB. А если InnoDB storage никто не чистит, то оно распухнет и выжрет все место на диске.

+6
А вы точно-точно не путаете системного администратора с администратором баз данных?
НЛО прилетело и опубликовало эту надпись здесь
0

Ну, идеальная картина мира-то мне известна.


Только очень часто всякие БД не являются сильно критичными и важными для инфраструктуры и нанимать для них отдельного DBA бизнес не очень хочет. Ну и усугубляет ситуацию распространенный нынче agile-подход где все должны делать всё.


У нас в департаменте, например, зоопарк разных баз различной степени важности — от стандартных MySQL/PostgreSQL до всякой аналитики вроде Clickhouse и вороха NoSQL Mongo/Cassandra/etc. Выделенного DBA нет, да и на мой взгляд не нужен он особо т.к. большинство из этих баз не customer-facing.


Так что зависит от ситуации.

0
Только очень часто всякие БД не являются сильно критичными и важными для инфраструктуры и нанимать для них отдельного DBA бизнес не очень хочет.


Если база данных не является критичной на предприятии, то уж нюансы MySQL, Postgres, MS SQL, Oracle и тем более NoSQL сисадмину знать не обязательно.

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

Вообще говоря, если я вижу контору у которой нет бюджета/желания иметь отдельно сисадмина и отдельно DBA, но при этом у нее таки зоопарк из 4-5 видов баз данных (а сколько самих БД внутри каждого сервера еще отдельный вопрос), то я бы рекомендовал такую контору обходить стороной за километр. Что-то у них там не в порядке с менеджментом.

Даже если предположить что контора была вынуждена весь этот зоопарк установить потому что они используют чьи-то сторонние решения, но тогда и обслуживать все эти чудеса стоит отдать на аутсорс, тем же ребятам кто продавал и обслуживает эти решения. Либо если это типа проверенные годами и отлаженные коробочные решения, то опять же сисадмину не надо разбираться нюансах типа InnoDB vs MyISAM.

agile-подход где все должны делать всё.

Можно ссылочку про то что «agile-подход = все должны делать всё.»?
Как я понимаю agile-подход, это все делают то же самое, только без нормального планирования. То есть кастрированный или обрезанный процесс разработки по части планирования. Но это не значит что девелопер должен поднимать упавший прод, а QA делать код-ревью, а DBA заниматься настройкой сетевых фильтров.
0
Если база данных не является критичной на предприятии, то уж нюансы MySQL, Postgres, MS SQL, Oracle и тем более NoSQL сисадмину знать не обязательно.

Да, сейчас в каждой дырке какой-нибудь SQL начиная от SQLite в каждом телефоне и часах чуть поумнее будильника. Поэтому некртичных баз сильно больше чем тех, от простоя которых будут сразу страдать клиенты или бизнес… Навыков, конечно, никто не требует, но по работе сталкиваться надо и минимальную надежность обеспечить.


Вообще говоря, если я вижу контору у которой нет бюджета/желания иметь отдельно сисадмина и отдельно DBA, но при этом у нее таки зоопарк из 4-5 видов баз данных (а сколько самих БД внутри каждого сервера еще отдельный вопрос)

Я бы не был столь категоричен, у нас большая компания с 20к+ сотрудников, но много департаментов и везде разные порядки и требования. Есть, конечно, отделы которые облизывают исключительно
Oracle т.к. он там не просто так стоит и его простой будет стоить много денег. А есть как у нас, где почти все базы — для служебного пользования.


Можно ссылочку про то что «agile-подход = все должны делать всё.»?

Дело не в том как "в книжке", а в том как менеджмент это у себя в голове видит.


У нас до некоторого времени было так, что от инженеров ожидали компетенций сразу в нескольких сильно разных сферах, но потом пришло осознание что стать экспертом затыкая собой все дыры не получится. Поэтому мы реорганизовались и теперь имеем узкие специализации, но при этом на хорошем уровне умеем все остальное, эдакий T-Shaped

0
у нас большая компания с 20к+ сотрудников,

Но в ИТ департаменте до сих нет понимания что сисадмин и DBA это разные люди и нет бюджета чтобы нанять обоих?
Повторюсь — никому не рекомендую заходить в такую контору.
Дело не в том как «в книжке», а в том как менеджмент это у себя в голове видит.

Туда же. Есть проблемы роста. Когда люди из 90х попали на руководящие роли и контора выросла с пары человек или пары десытков человек до как у вас до 20К если менеджмент не успел вовремя все осознать и переобучиться, то не стоит тратить свое время и силы на то чтобы бороться с ветряными мельницами. Когда я иду в большую контору где работает 20К людей, я ожидаю что это они меня будут чему-то учить чего я никогда не могу и представить в маленьких или средних конторах. Но если я могу прийти и увидеть «детские» ошибки в подходах и менеджменте и внезапно оказываюсь «самым умным в комнате», в этот момент я понимаю что попал и надо срочно искать другое место работы.
. Поэтому мы реорганизовались и теперь имеем узкие специализации,

Вы уж определитесь вы имеете узкие специализации или нет. А то топик начался с того что сисадмин и DBA это должны быть разные люди с разной квалификацией. А вы как бы защищали позицию что нет.
Затем я высказался в том плане что от подобных контор стоит держаться подальше. И вы снова как бы не согласились, ссылаясь на свой опыт и видимо пытаясь сказать что у подобных контор есть некие объективные «оправдания». На мой взгляд у всего на свете есть оправдания, но это не повод тратить пару лет своей жизни на то чтобы впитывать неправильные практики, вместо того чтобы пойти в нормальное место и прокачиваться в том направлении которое реально интересно.

Я же вас лично ни на что не агитирую. Но не вижу как ваши доводы могут повлиять на мою позицию в этом вопросе. В 90-ые было модно, доходно и интересно порой быть эникейщиком. И я тоже все это делал. Но постепенно я увидел как быстро я начинаю проигрывать тем кто выбрал специализацию и пошел прокачиваться в каком-то направлении. Эникейщики по сути нужны тем руководителям которые ничего не понимают в ИТ и у которых мало денег. Тем кто ничего не понимают, но у которых есть деньги — предпочтут грамотного CTO или архитектора и отдел или департамент в подчинении у этого человека. Если же в роли такого CTO оказывается не очень компетентный человек, то, на мой взгляд, именно тогда мы и получаем обсуждаемую ситуацию. Для меня это очевидно. Для вас видимо нет. Но уровень очевидности для меня такой, что я не вижу смысла писать трактаты в комментариях. Это как объяснять «почему колесо катится, а кирпич нет», настолько очевидно, что при попытке объяснить, чувствую себя идиотом или глупцом одновременно.
НЛО прилетело и опубликовало эту надпись здесь
0
Размышляю: в мои обязанности входит подъем ДБ сервера начиная с ОС и заканчивая всякими флагам трассировки, планами обслуживания, бэкапами. В промежутке снимаю статистику по самым ресурсоёмким запросам и пинаю программистов 1с на тему оптимизации… Таки я все-таки админ :-)
0
При том, что постоянно это указывают в резюме. Если бы не указывали — я бы и не спрашивал.
0
Ну да, у меня, например, с бд всё замечательно. Лежит на диске, бекапится, иногда бекапы подключаются для проверки. Хотите узнать про индексы — купите себе ДБА и… ему мозги. Можете прям меня-же(на самом деле нет, в ДБ плаваю), но за те-же деньги. А не за цену эникея.
+1
Если понадобиться — так и будет) Но если человек в резюме прямым текстом указывает, что у него замечательные знания баз данных (тут бесчисленные перечисления продуктов), то я просто обязан узнать насколько, чтобы в случае чего акцентировать его работу на этом. По факту каждый почти админ в резюме пишет про базы данных и хорошо ещё, если это значит бэкапы, подключение, репликацию… Потому, что зачастую «ну там у нас была программа, мы в ней набирали текст и оно в базу летело». Не надо указывать в резюме то, с чем работать не умеешь. Лишняя строчка тут это минус, а не плюс.
+2
Странные вопросы вы своему сисадмину задаете, имхо…
0
Ну дак не я). Человек сам себе задаёт вопрос акцентируя в резюме на этом внимание.
+8
Про то когда валят, могу предположить несколько причин (без сортировки)
  • На самом деле вакансии нет, это бывает когда главе отдела человек не нужен, а глава департамента например думает что нужен. Или HR нужно выполнять KPI по собеседованиям не зависимо от запроса со стороны проекта, или это вакансия нужна чтобы нанять иностранного специалиста, но местной службе занятости, трудовой инспекции и миграционной службе нужно показать что такого специалиста на месте нет.
  • Молодой руководитель с задранным ЧСВ и только учащийся тому как на самом деле нужно использовать авторитет, знания, уважение и вообще софтскиллз, такой может просто так валить на собеседовании
  • Очень часто вывод о том что мы не хотим работать с этим человеком делается по его поведению, внешнему виду и прочим факторам. Многие будут это отрицать, но это действительно часто так работает. И нам нужно отказать. И многие руководители сделают вывод что проще всего завалить и человек будет думать что не подходит по скилам, а не по другим причинам. В современном лицемерном мире не принято говорить что я не хочу с тобой работать потому что ты больно дерзко отвечаешь на вопросы, и я вижу что наше общение не будет продуктивным
  • Кандидат реально не тянет. Когда я собеседовал людей на разработку графдвижка, то собеседования, в основном, поделились на два типа: 1. Люди не понимали зачем я спрашиваю те тонкости которые я спрашивал и думали что я их завалил. 2. Диалог быстро перешёл а обсуждение тонких моментов и граблей со взаимным обменом опытом и шишками и закончился оффером.
+1
В современном лицемерном мире не принято говорить что я не хочу с тобой работать потому что ты больно дерзко отвечаешь на вопросы, и я вижу что наше общение не будет продуктивным

Тут проблема не в лицемерии а банально в трудовой инспекции которая может заинтересоваться чегойто работника не берут не по скиллам а по характеристикам мало имеющих отношения к работе (и нет, всякое «не впишется в команду» насколько знаю для них не аргумент).
Ну и еще некоторые соискатели после отказа по личным качествам такой хайп и вой поднимут на хабре/в твиттере — что репутации компании кирдык придет.
-1
Именно это я и подразумеваю под
В современном лицемерном мире не принято говорить
+1
Лицеме́рие — моральное качество, состоящее в том, что заведомо безнравственным поступкам (совершаемым ради эгоистических интересов, по низменным мотивам и во имя антигуманных целей) приписываются псевдоморальный смысл, возвышенные мотивы и человеколюбивые цели[1].

— Википедия.
Как то не вижу в описанных мной мотивах особо безнравственных поступков, и уж тем более никакие возвышенные мотивы не пытаются себе приписать.
0
По первому пункту. Бывает еще, что человек, который проводит собеседование, хочет свою значимость в компании поднять или значимость своего подразделения. Он заявляет, что ресурсов не хватает, а кандидаты хорошие на вакансию не приходят, при этом всех кандидатов заваливает. И таким образом старается обосновать, например, повышение бюджета на вакансию. Или возможность работать удаленно (и рассмотреть таким образом больше кандидатов). Или возможность привлечь дорогих аутсорсеров. Или еще что-то, в чем он заинтересован.
0

Вы забыли ещё один пункт. Иногда, по резюме кандидата понимаешь, что человек сильно круче тебя практически по всем фронтам и чтобы не ударить в грязь лицом перед начальством, начинаешь такого человека валить. Так сказать возвышаешься через унижение. У меня, конечно, опыт не такой богатый, как у автора статьи, но я тоже с таким сталкивался, причём именно в РБ (было пару собесов в Польшу, Нидерланды, Украину, Россию).

+2

В 90% моих собеседований совершенно не смотрят на мой гитхаб. Их это не волнует. Им интереснее меня про определение ООП спросить.

+1

банальная лень — разбираться в коде на гитхабе требует времени и усилий.
особенно актуально, если соискателей не 2-3.


ИМХО логично "спросить про определение", отсеять нескольких кандидатов, и уже у немногих оставшихся смотреть код.

+13
Если вы абсолютно точно уверены, что проблема не в вас, а в конторе — не стоит даже париться, значит вам туда точно не нужно.
+3
Вот это очень правильная вещь. Собеседование одно одновременно важно для обоих сторон. Будучи кандидатом очень важно в обратную сторону собеседовать компанию. И понимать что часто в тексте вакансии написано совсем не то что есть по факту, и оценивать нужно не те мечты которые нарисовались в голове исходя из вакансии, а то что будет реально встречено, какие отношения в коллективе, кто собеседует, какой офис и т.п.
+21
А то, что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность?

О! Спасибо за отличный вопрос, завтра задам его кандидату.

А если серьёзно, то я уже давно заметил одну странную вещь. Многие мои знакомые (разработчики с опытом по 15 лет) проводят собеседования. Иногда мы обсуждаем, какие вопросы они задают. И оказалось, что они периодически задают то, что узнали буквально вчера совершенно случайно. Т.е. то, без чего они 15 лет прекрасно работали, а через две недели забудут напрочь. При этом искренне удивляются, что кто-то может не ответить на такой элементарный вопрос: «Какой Senior?!!! Он же проффнепригоден!». И это удивление искреннее, у них нет ни желания специально завалить кандидата, ни как-то возвыситься за чужой счёт.

Это мне напоминает один психологический факт. Дети до какого-то возраста не могут понять сказку про Белоснежку. Почему она ест отравленное яблоко? Ведь это известно, что оно отравлено! У них в голове не укладывается то, что у другого человека может быть совершенно другой «контекст», другие знания. Может это как-то связано?
+9
Ну, справедливости ради про сложность поиска можно по названию типа индекса догадаться. А какая собсно еще сложность кроме логарифмической может быть при поиске в сбалансированном дереве?
+1

B-tree — это не только balanced tree, как может показаться.


На самом деле точного ответа автор этой структуры не дал, поэтому существует два распространённых варианта: balanced (широкий класс деревьев, вообще говоря) и block (что гораздо лучше описывает конкретно эти деревья).


Главное, что совсем не binary :)

+1

Но ведь любое B-дерево является идеально сбалансированным вне зависимости от происхождения буквы B.

+1

Сбалансированные деревья всё же куда более широкий класс, чем блочные.

+1

А это и не важно. Если некоторое утверждение справедливо для любого сбалансированного дерева — то оно будет справедливо и для любого блочного.

0
И этим простым утверждением вы доказываете то, что вам пишет оппонент. :)
Раз утверждение верно для множества (сбалансированных деревьев), то оно автоматически верно и для подмножества (блочных деревьев), ну же.
0

Но обратное не верно. Число случайных обращений к диску в произвольном сбалансированном дереве будет куда больше, чем у B-tree, специально для этого спроектированном.

+1

Но оно всё равно будет логарифмическим, а ответа точнее и не требуется.

0

И что? Во-первых, это всё равно будет быстрее полного прохода по таблице. Во-вторых, автор даже асимптотику придумать не сумел.

+1
Поздравляю, в этой ветке комментариев все получают оффер.
0
Получется, что ваши знакомые тоже не в курсе. Так какие вопросы нужно задавать на собеседовании? Задачки на сообразительность типа по лампочкам в вагонах определить не циклический ли поезд? Паттерны проектирования? Или про диплом опять же? (у меня есть знакомый дев опс с 9 классами образования)
0

Гораздо интереснее вопрос, почему Белоснежка жила с семью гномами. Количество переходит в качество? При каком N?)

+3
Ну разбойничать на дороге одной как-то опасно.
А вот с семью краснолюдами сам-то! :-)
+3
О! Спасибо за отличный вопрос, завтра задам его кандидату.

Ну в общем это базовое понимание, которое должно быть у всех кто претендует на худо-бедное знание реляционных БД, они ж не только в постргресе есть, а везде.
Если ты не знаешь как работают наиболее часто используемые индексы, то как ты узнаешь когда они тебе нужны? Будешь звать DBA посмотреть на план каждый раз когда надо написать запрос?

Вот спросить про например GiST индексы в Postgre это было бы другое дело.
0

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


P.S. ИМХО это вполне нормально на собеседовании ответить не на все вопросы.

-1
Ну в общем это базовое понимание

Серьееезно? Это знание даром ненужное, вообще, совсем.

то как ты узнаешь когда они тебе нужны

А у вас есть другие типы индексов? Второй по распространенности это pg_trgm индекс (да, внезапно на GIST но знания о существовании его — достаточно), все остальные еще более ситуационные настолько, что среднему разработчику они нужны будут примерно никогда.

Вот спросить про например GiST индексы в Postgre это было бы другое дело.

А они действительно используются в вашей компании? Не подскажите какими операторами вы используете этот индекс?

PS ну опять адепты алгоритмической сложности в карму набежали) Господа аргументы в студию, с use-case'ами)
0
Серьееезно? Это знание даром ненужное, вообще, совсем.

Да и БД знать не нужно, ORM всё сделает.

GiST это просто пример специфического вопроса конкретно про Postgres. Про Б-деревья можно спросить в контексте любой реляционной БД. Какую кандидат сказал что знает, ту и подставляешь в вопрос.
У нас GiST кстати не используются, я просто мануалы по используемым БД читаю иногда, вдруг есть интересные штуки.

Но заявлять знание БД и не знать индексов — а собственно что он тогда знает?
«Нуу, БД состоит из плоских таблиц?»

В карму вам не лез, у меня коммент-онли аккаунт.
0
Но заявлять знание БД и не знать индексов — а собственно что он тогда знает?
«Нуу, БД состоит из плоских таблиц?»
Не знать про индексы ≠ не знать как устроены индексы.
+3
Возможно в таком случае не стоит заявлять о знании БД. Как максимум заявить — «как-то раз сталкивался в работе».

Потому что знатоков которые мне ответят «Индекс это такая чудо штука которая иногда ускоряет поиск» я могу набирать прямо из детского сада. А студентов, которые курс БД прошли так вообще архитекторами брать.
0
Возможно в таком случае не стоит заявлять о знании БД.

Так можно зайти ну очень далеко, потом идет вопрос о формате WAL, потом page-cach линуха, и так далее. А на самом деле там база, которая дохнет на жалких 100 млн строк на запросах которые писаны левой пяткой и проиндексированны правой.

Потому что знатоков которые мне ответят

Проясните пожалуйста, как устройство индекса может использоваться кем либо кроме собственно разработчика БД.
Ну я вот выше вам задал вопрос, давайте по нему составим интересную беседу?
0
Разработчик создаёт индекс и говорит:
«Быстрее не становится. Даже план не поменялся и индекс не используется. Как же так???»

Вы мне скажете: да он о таком знает.
А я отвечу: да не верю в такое. Разработчик, который знает когда индекс поможет, и когда нет, всё ещё не знает что индекс сделан на основе дерева? Он что ли запомнил по примерам правила работы чёрного ящика, ускоряющего ему запросы?
0
«Быстрее не становится. Даже план не поменялся и индекс не используется. Как же так???»

И вы такой: нуда! тыже не знаешь структуру b-tree, а вот знааал бы!
Он естественно унижен, идет читает, разбирается в алгоритме, проверяет свой индекс, а база ему все равно говорит «seq scan».

всё ещё не знает что индекс сделан на основе дерева

Не надо предположений, просто объясните мне, дурачку, чем это знание ему поможет.

Он что ли запомнил по примерам правила работы чёрного ящика, ускоряющего ему запросы

Огромная часть разработчиков даже на этом уровне не запоминает, вон на битрикс посмотрите.
+1
просто объясните мне, дурачку, чем это знание ему поможет

Не вопрос, приходит менеджер к этому программисту и задает вопросы

1. У нас есть Hadoop кластер, Redis с журналированием изменения раз в минуту и mysql с терабайтной базой, что будем ставить на hdd и что на ssd и почему?

2. Нам нужно создать составной индекс у sql базы в каком порядке нам лучше добавить туда колонки? Нужно ли при наличие составного индекса по колонкам A + B + C, создавать отдельные индексы по колонкам A, B и С или мы просто потратим место на диске?

3. У нас есть множество однотипных запросов, но с производительностью все плохо. Как использовать кластерный индекс в таком случае и почему он сможет нас спасти?

4. Когда и при каких данных нужен разрежённый индекс (ключевое слово SPATIAL в mysql) и почему обычный индекс будет работать хуже?

Да на все эти вопросы можно выучить (или получить эксперементальным путем) ответы и без всякого понимания как база данных работает изнутри, только это будет куда дольше.
+1
Да на все эти вопросы можно выучить (или получить эксперементальным путем) ответы и без всякого понимания как база данных работает изнутри, только это будет куда дольше.

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

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

Понятно что в конторе где все три роли исполняет один и тот же человек — он же и разработчик и менеджер и специалист по БД — ему приходится знать всё выше перечисленое. Но так ли Важна производительность для такой конторы, не является ли это «стрельбой из пушек по воробьям».
+1
Менеджер с такими вопросами это утрированный образ, конечно.

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

Далее, на мой взгляд критическое мышление возможно только если хоть немного понимаешь как все работает под капотом. Помните всякие шутки с введи «format c:» или «sudo rm...»? Вот человека, которые понимает чуть как оно работает внутри намного сложнее обмануть всякими рекламными штуками или ошибочными советами в инете…
+1
Какое у него будет отношение к вам, особенно если он считал вас экспертом по БД?

странная точка зрения

Допустим я начальник подразделения разработки, беру нового сотрудника, который знает больше меня и оптимизирует систему так что она начинает работать быстрее.
И типа чё, давайте меня понизим, а нанятого сотрудника повысим — типа он умнее?

это совершенно разные категории. Если вы в одно лицо запилили огромный сервис, напрямую работаете с владельцем бизнеса, потом берете себе помощника который знает какуюто технологию лучше вас — это блин НОРМАЛЬНО и обычно. А если собственник начинает мерить эффективность персонала такими методами и не понимает что человек который в состоянии спроектировать и запилить большой проект в одно лицо — скорее всего знает хуже узкие технологии чем человек который например 10 лет только dba и работал, то из этой конторы надо бежать

+1
странная точка зрения

Допустим я владелец бизнеса и нанимаю Java/Javascript архитектора и Lead Developer за большие деньги, у которого по CV и тех.интервью огромные опыт и большая экспертиза. Он разрабатывает системы, потом я нанимаю аудиторов, которые выдают заключения, что мой якобы супер специалист не знает банальных Java коллекций и у него в хаш.мапах одни hash коллизии, в вебе одни sql injection'ы и т.п. дыры, а бд не использует тривиальные индексы и нормализации.
Отчего вся система дырявая и дико медленная и из-за его тривиальных ошибок я переплатил намного больше его зарплаты за сервера и теперь проще все написать с нуля чем переделывать.
Вопрос, что я должен сделать как владелец? Дать ему премию?
-1
Я не знаю каков ваш управленческий опыт.
Но обычно владелец не знает и не понимает таких понятий как:
банальных Java коллекций и у него в хаш.мапах одни hash коллизии, в вебе одни sql injection'ы и т.п. дыры, а бд не использует тривиальные индексы и нормализации.

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

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

Так что на уровне бизнеса если ваш Ит менеджер нанял спеца, который за месяц ускорил что-то в 100 раз, надо похвалить и менеджера за такую находку и премировать нового сотрудника, чтобы продолжал в том же духе. А если у вас как у владельца чешутся руки кого-то наказать, ваш бизнес постепенно скатится в яму, потому что люди не любят работать в такой среде. Люди любят чтобы их хвалили. Особенно после улучшений. А вы хотите после улучшений, найти виновного почему раньше было хуже.
+2
Так что на уровне бизнеса если ваш Ит менеджер нанял спеца, который за месяц ускорил что-то в 100 раз, надо похвалить и менеджера за такую находку и премировать нового сотрудника

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

Хороший пример, правда. Беда что вокруг ровно все так и есть и даже еще хуже.

Но вы упускаете нюанс, как раз лид уж точно скоре йвсего не помнит структуру R-tree, B-tree. К тому же лид это уже нее совсем программист, это уже менеджер в том числе.

Вопрос, что я должен сделать как владелец? Дать ему премию?

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

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

Будете ли вы предлагать криворукому автослесарю, загубившему ваш автомобиль, исправить свои ошибки за вменяемое время и дополнительные деньги?
0
Даже у стоматологов есть разделение функций — терапевт, хирург, ортодонт, ортопед, пародонтолог. Если ортопед начинает лечить людей, или терапевт ставить импланты — тогда жди беды. А почему от разработчика в 2020 году ждут многостаночности.
+2
Эка вы радикально.
Без косяков не работает вообще никто, вопрос только в том как справляться с кризисными ситуациями.

И кстати мне переделывали работу по зубам. Хожу дальше.
0
Есть же все-таки разница между просто косяками и косяками, показывающими полную профессональную некомпетентность. Будете ли вы лечится у некомпетентного человека?
0
А вы знаете способ определения?)
Если мне врач ненра я обычно меняю, в пределах клиники.

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

Да, обратится к N экспертам в той же области с консультацией (лучше с рекомендация друзей или хотя какой-то репутацией).

Если условно пять других экспертов не сговариваясь дадут похожий диагноз с тем же списком проблем — вероятно проблема все-таки именно в некомпетенции.
0
Если вы готовы СТОЛЬКО тратить, то цена неверного найма у вас запредельная, следовательно собеседования не должны проводиться в классическом ключе: «лучше не нанять подходящего человека, чем нанять не подходящего». Поскольку в таком случае, вы рискуете спугнуть как раз того кто вам нужен.
0
Сколько столько?

Условно, если мне кажется, что доктор лечит меня плохо, я схожу на консультацию еще к парочке докторов. Если мне кажется, что автослесарь либо некомпетентен, либо обманывает, я отвезу машину еще парочке. Если аудит програмного кода показывает очень большие проблемы, вполне логично обратиться еще к 1-2 экспертам, это будет дешевле неправильного решения или продолжать разрабатывать продукт в неправильном направлении.
+3
Если аудит програмного кода показывает очень большие проблемы, вполне логично обратиться еще к 1-2 экспертам,

и получить 5 совершенно разных мнения, начиная 'всё надо переписать на go сейчас он в тренде, а у вас устаревшая java которая скоро умрет' до 'переходим на 1С' и 'оо, это PHP на нем только лузеры пишут'

ИТ оно такое… миллион мнений и ни одного единственно верного ;)
0
ИТ оно такое… миллион мнений и ни одного единственно верного

Нет, нужно задавать правильные вопросы и привлекать правильных экспертов (в смысле не звать оценивать Java приложение фаната GO).

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

Да, грубые ошибки могут быть из-за низкого бюджета и сжатых сроков, но это понятно, если заставить строителя за полдня сделать ремонт, который должна делать бригада за полгода, очевидно результат будет плохой, что не будет говорить о квалификации работника.
+1
Нет, нужно задавать правильные вопросы и привлекать правильных экспертов

а для этого надо иметь в штате специалиста который может сформулировать правильные вопросы и понять каких экспертов нанять… а кто будет искать такого специалиста… замкнутый круг
0
… и мы плавно возвращаемся к теме рекрутинговых агенств и рекомендаций.
-2
замкнутый круг

На самом деле, все Западные ИТ компании, в которых я работал, основаны либо бывшими программистами, либо как минимум людьми с ИТ образованием и там так или иначе большинство менджеров имело тот или иной ИТ бекграунд (хотя бы ИТ образование), поэтому замкнутого круга тут и не появлялось.
+1
скорее у вас просто узкая выборка чисто ИТ-компаний.
Я работал в компаниях где ИТ хоть и очень важное направление и фактически ядро и основа компании, но фактически это лишь инструмент для выполнения основной ф-ции (обработка данных для финсектора) и соотсветственно весь топ-менеджмент далек от ИТ в принципе
почему собственно в 'кровавом энтерпрайзе' и встречаются всякие кошмарные решения которые не кому чинить или улучшать… ситуация меняется только если туда както случайно попадает человек с современным взглядом… и аудит не помогает (зачастую его никто не заказывает потому что не понимает что фирма может работать лучше)…

По этому кстати в РФ финсектор со стороны ИТ сильно лучше забугорного, поскольку наши не получили легаси в наследство, а с нуля начали писать уже программисты с более современным подходом
+1
еще к парочке докторов.

Вот вы удивитесь, когда 5 докторов дадут 5 разных диагнозов. Я лично такое видел.

будет дешевле неправильного решения

Даже по готовому заключению, на подтверждение, каждому эксперту нужно сколько? Часов 100 в лучшем случае? по 50 баксов в час на два плюс стоимость самого аудита + стоимость простоя + стоимость найма (совокупная) нового сотрудника и его обучение.

А на собеседовании вместо «как бы вы решили вот такие проблемы» вы спрашиваете «сортировку пузырьком» и уменьшаете шанс нанять действительно подходящего вам сотрудника. Отсюда либо еще разок п1 по кругу либо + значительное время простоя.
+2
Вопрос, что я должен сделать как владелец? Дать ему премию?


для начала понять что
— универсальных специалистов не бывает
Архитектор-Лид — не может знать ВСЁ, и он должен работать не в одно лицо, а с командой, где будут узкие специалисты по всем направлениям.
Это блажь — считать что если чел прямо как бог рубит в базах и индексах, то он сможет спроектировать крупную работающую систему которая будет зарабатывать вам деньги, это нереально.
И если вы берете человека который на словах 'господьбог-суперзвезда' — и считаете что он в одно лицо построит вам звезду смерти — блин да это понятно что получится хоть и работающий продукт но построенный из костылей и затычек потому что количество человекочасов превышает человеческие способности
и вы как владелец себе должны по голове постучать и себя лишить премии за то что у вас какието странные ожидания от людей
===
Я работал в конторе где ядро системы было написано одним человеком, дичайшее легаси которое потом поддерживает и переписывает отдел из 5 человек… причем с точки зрения менеджмента это гениальный и практически недостижимый по конкуретноспособности продукт, а с точки зрения разработчика — кошмар и ужас и вообще бывает не верится что оно вообще функционирует… а всё потому что это писал один человек, и фронт и бек и десяток баз начиная от оракла заканчивая кликхаусом и sqlite причем чел осилил в одно лицо даже некое подобие cicd на всё это хозяйство.
Как думаете надо было с позором выгнать этого человека? (он сейчас гдето в США работает) и проклясть его что он паразит за зарплату в 100тыр написал систему которую надо было писать отделом из сеньоров? и она тормозит и жрет ресурсы. помоему тут виновато отсутствие денег, а не конкретные личности и их скиллы
-1
Ну я представил есть 50 человек которые разработали систему, и тут пришел новы сотрудник и полез менять индексы. Сразу вопрос, а кто его вообще допустил до продакшен серверов и кто ему дал задание менять индексы. Вам не приходит в голову что разработчикам может быть запрещено даже знать на каком железе работают продакшен сервера и им запрещено получать информацию с них. И если какой-то сотрудник полезет не в своё дело, будет заниматься индексами вместо своих прямых обязанностей, то он быстро вылетит работы.

Не ну я представил — делаете Вы систему для какого-нибудь Wallmart и тут к Вам приходит владелец бизнеса в говорит; «Выдыхай, Бобер, Выдыхай!»
+1
А теперь представьте, что это не новый сотрудник, а новый СТО или владелец заказал аудит и внезапно оказалось, что 50 человек написали редкую фигню с дырами в безопасности, ужасной архитектурой и производительностью и проще уволить всех и написать все с нуля, потому что тех.лиды/архитекторы были некомпетентны и набрали некомпетентных исполнителей.
Что-то похожее я пару раз в жизне видел, вот именно примерно в таких же размерах команд и, да, помню случай когда команду человек в сто уволили, а проект перезапустили с нуля из-за похожих проблем.
-1
В команде из 50 человек функции каждого достаточно специализированны, требовать скажем от back-end разработчика глубокого знания БД довольно странно. Как там устроены деревья индексов не его вообще проблема. Хорошо если он раньше был full-stack и что-то знает о БД и индексах. А если нет — то и суда нет…
+3
Не ну я представил — делаете Вы систему для какого-нибудь Wallmart и тут к Вам приходит владелец бизнеса в говорит; «Выдыхай, Бобер, Выдыхай!»

Я делал системы для куда более крупных компаний, чем Wallmart и что? Некоторые проблемы доходят и до СТО компаний с миллиардным оборотом (владельцы там обычно акционеры).

Причем это вы перевели разговор о командах на 50 человек (кстати, проект на 50 человек — представляю, а вот за именно команду более 10-15 человек с трудом, при том что у меня десятки лет опыт в многомиллиардных компаниях). Вообще-то речь шла о разработчиках вообще, не объязательно к разрезах команд на миллион человек.

Вам не приходит в голову что разработчикам может быть запрещено даже знать на каком железе работают продакшен сервера и им запрещено получать информацию с них.

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

Хорошо если он раньше был full-stack и что-то знает о БД и индексах

У вас странное понимание о full-stack, фул стек это про связку бека и фронта. Для back-end разработчика знание индексов и БД это скорее необходимый минимум на звание старшего и тем более архитектора/тим.лида и т.п. Весьма нелепо звать DBA для каждой N+1 проблемы с которой он столкнулся при использовании ORM. Не говоря уже о том, что DBA вряд ли полезет копаться в недра ORM бека. Более того нормальный старший back-end разработчик отлично понимать, что такое SQL injection и как их избежать без обращения к специлизированным ребятам.

В команде из 50 человек функции каждого достаточно специализированны

Руководил проектом более чем на 50 человек в многомиллионых корпорациях — не согласен, что такая специализация есть всегда, я бы сказал, что бекэнд разрабочик, не понимающий достаточно хорошо базы данных, вряд ли может считаться достаточно квалифицированным для должности старшего разрабочтика (тем более тим.лида, тех. лида или архитектора). По крайне мере, я знаю далеко не одну очень крупную компанию, где такого разрабочика без знания БД просто не взяли бы на должность старшего разработчика.

глубокого знания БД довольно странно

У вас неправильное понимание глубокого знания БД, глубокое это настройка репликаций, сложных хранимых процедур, двухфазных удаленных транзакций, всяких иерархических запросов с дисплейными функциями и т.п. Как работают, индексы это вообще самые основы основ, примерно как left/rigth join'ы или базовые sql запросы, без знания этого можно говорить, что СУБД вы вообще не знает даже на начальном уровне. ИМХО.
0
У вас неправильное понимание глубокого знания БД

Вы берете две крайности.
Между ними пропасть:
— нюансы оптимизатора
— оконные функции
— аналитические запросы
— CTE
— частичные, функциональные, pg_trgm/ctxcat индекс и тд
— секционирование
— наследование
— итак далее и тому подобное

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

Ну вот мой пример: допустим вам надо повесить индекс, база у вас Postgresql(забудем про пространственные данные сейчас) вариант индекса у вас целый один — b-tree. Осталось решить какие поля и в каком порядке, проанализировав запросы, ну можно еще его частичным сделать.
0
Вроде бы Wallmart — крупнейший работодатель в США. Вы Звезду Смерти делали?
0
Мда… Вы серьезно? В этих темах даже 1сники поверхностно разбираются у которых вообще основная специализация не программирование а больше предметная область и бизнес анализ, и только немного программирования (причем как UI так бека + rest/soap сервисов, так что база для них хоть и важна но далеко не их основная специализация). Как можно называть себя бекенд программистом понимая в базах даже меньше 1сников — не представляю.
0
В большой компании, где есть разделение ролей, разработчик кода вообще не пишет SQL сам. Это не его обязанность и толку что он знает как устроено дереве индекса вообще никакого. Эта информация для него в принципе бесполезна. Если компания маленькая эта информация для разработчика так же избыточна — он же там одновременно выполняет сто ролей, понимание дерева индекса это не про него. Если большая компания от каждого кандидатов требует такой специализированной информации — они просто забивают мозги кандидатам. Ну это лютый бред, пусть выделят одного или двух, может пятерых, кто будет знать как там устроены индексы внутри, и они уже занимаются такими вещами.
-1
В большой компании, где есть разделение ролей, разработчик кода вообще не пишет SQL для сам. Это не его обязанность и толку что он знает как устроено дереве индекса вообще никако

Простите, а какой у вас опыт работы в больших компаниях, чтобы так утверждать за все большие компании?

У вас судя по всему опыт больших компаний прямо противоположенный моему.

Мой опыт разработчика кода:
1. Компания на 10 тыс. разработчиков. Разработка продукта для почти половины мирового телекома. Писали огромные SQL, хранимые процедуры и сложные индексы и оптимизации в Oracle,
2. Разработка продукта для крупнейших рекламных онлайн сетей мира — оптимизация mysql и mongoDb на самом низком уровне,
3. Одна из крупнейших аутсор компаний мира, разработка для крупнейших финансовых компаний в мире — самостоятельная разрабкта базы данных для продуктов, много оптимизации БД,
4. Разработка продукта для одного из крупнейших поисковых систем отелей в мире, оборот около миллиарда — приходилось постоянно оптимизировать индексы и запросы в базу,
5. Разработка продукта для одного из крупнейших стриминговых сайтов мира (в топ30 в alexa rank) — постоянная оптимизация запросов в базу данных и работа с кешами,

Вы все еще утверждаете, что во всех больших компаниях, разработчик вообще не пишет SQL сам?

P.S. Разделение ролей везде было.
0
Ой как я завидую пунктам 1,2. Тоже хотеть.

Правда с таким бекграундом логичней было бы все же postgresql форкать, или не форкать а писать свои индексы и операторы.
0
А потом получаем текущие абстракции, проблемы коммуникации из за непонимания одних специалистов что там на стороне других и прочие проблемы узкой специализации в больших коллективах. Я и не топлю за знание всего и сразу, но как по мне модель I-shape специалиста гораздо более проблемная чем T-shape. Я так вообще планирую к Ш-shape ползти, но, тут признаюсь, уже больше по фану а не из реальной необходимости.
+3
а новый СТО

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

Сразу нахер такого CTO. Пинком прям. Уволить всех это никогда, слышите меня, НИКОГДА, не проще.
+1
Уволить всех — это просто: ставим начальника — идиота с ЧСВ в облаках, который будет обращаться с подчинёнными как стереотипный американский сержант к рекрутам и пишем общее письмо «R&D дураки, секретарше и бухам — премию, остальным — банан, с новым годом, крысы» и вся разработка сама разбежится. Без доп. окладов и по собственному.
Но не понятно, как собрать команду вместо прошлой (слухи-то пойдут, как объяснить потенциальному работнику, почему вся команда разбежалась?) и кто будет в это время выполнять контракты?
0
Вот вы хихикаете, а он РЕАЛЬНО НЕ ПОНИМАЕТ что не так с его подоходом.
Тут недавно аж 3 статьи про «красную корпоративную культуру» написали, думаю, он даже если их прочёл, то не понял.
0
C чего вы взяли, что это мой подход? Или я что-то не понимаю? На данный момент, я работаю обычным старшим разработчиком. Когда я говорил, что менджерам проще уволить, я не говорил, что я одобряю таких менджеров.
Дискуссия вообще была о необходимости разработчику понимать основы БД.
+1
У нас есть Hadoop кластер, Redis с журналированием изменения раз в минуту и mysql с терабайтной базой, что будем ставить на hdd и что на ssd и почему?

Ответ простой: «Извините, вы нам не подходите». Это работа админов.

Как использовать кластерный индекс в таком случае и почему он сможет нас спасти?

Как ни странно неплохой вопрос. Однако, если у вас все настолько плохо то ничто вас не спасет)

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

Или открыть мануал по индексам где все это подробно и кратко описано.
Кроме того, спустя годы это можно просто знать.

На самом деле вопросами лично я впечатлен (хотя на вопрос типо «как» я бы ответил «понятия не имею», для экономии времени). Но беседу я думаю можно было бы составить интересную. Вот только у меня прям сильные сомнения, что такое вообще возможно.
-2
Если у компании так остро стоит вопрос с БД, производительностью и индексами — они просто должны иметь выделенных людей, которые специализированно занимаются только БД. Если они от каждого требуют такой специализации — то они просто забивают мозги своим работникам. Если у них проблем с производительностью на самом деле нет, а они требуют знаний от каждого — значит тем более забивают мозги.

Скорее всего просто компания не может нанять себе нормального узкоспециализированного профессионала по БД, а требует знаний от каждого вновь пришедшего разработчика. Короче свои косяки за счет кандидатов решают. И сразу большой вопрос стоит ли с такой компанией связываться.
-2
Да тут дело в другом, на хабре секта расчетчиков алгоритмической сложности, причем аргументов от них я добиться ни разу так и не смог. Это забавно, учитывая голод на рынке кадров и тот факт, что люди, работающие с базой, SQL не знают.
-2
Ну нужно понимать психологию людей же.

Первое — «Я начальник ты дурак»; это прямо с собеседования начинается. Если не унизить, нельзя будет на зарплату продавить.

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

В России процветает социал-дарвинизм самого низкого пошиба, когда если ты не гений — ты должен даже не бедно жить, а просто тупо умереть. Причём те, кто его продвигает, сами далеко не гении, от того фрустрация и ненависть к обычным людям — не сильно напрягающимся, допускающим ошибки — ещё сильнее, т.к. эти люди «позволяют себе» быть обычными, а такого НЕЛЬЗЯ, они все должны умереть, если они не атланты.

Третье — «Принцеждалки»; ну тут всё просто, вакансия может висеть полгода, год, но её не закроют любым подходящим сотрудником, только тем, кто сразу пишет на доске код без ошибок, знает про круглые люки и работает за 45к (gross).

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

Кстати, забавнейший парадокс.
С одной стороны так как качество не важно — можно было бы набрать абы кого; и часто именно так и делают, например, устраивают по блату или в госучреждения за копейки с улицы собирают. С другой стороны — но если уж соискатель придёт на вакансию, нельзя его взять, если он не мега-гига-мозг, потому что а как же тогда потешить своё эго?
0
Как раз была недавно статья про красную модель управления)

На самом деле проблема не в том, что вещи типо big o совсем уж бесполезны, а в том, что запредельное количество людей, хнающих всю теорию на зубок, не способны решать практические задачи на хорошем уровне.

Нет безусловной корреляции между знанием сложности алгоритмов и написанием эффективного кода
+1
Ну, если человек знает как, когда и зачем использовать индексы — зачем ему знать знать их алгоритмическую сложность или доскональное устройство? )
+1
Ну прямо 100% доскональное устройство может и не за чем, но вот понимание чем «кластерный индекс отличается от некластерного и чем один лучше другого» или в каком порядке лучше добавить колонки в составной индекс и почему порядок «пол возраст фио» лучше/хуже чем «фио возраст пол» может очень ускорить решения проблем с производительностью.

Вообще, если не понимать как работает та или иная база данных хотя бы в общих чертах можно не понять почему для sql базы данных лучше использовать ssd, а для Hadoop кластера или in-memory базы данных часто вполне можно обойтись и hdd.
-1
Ну прямо 100% доскональное устройство может и не за чем, но вот понимание чем «кластерный индекс отличается от некластерного и чем один лучше другого» или в каком порядке лучше добавить колонки в составной индекс и почему порядок «пол возраст фио» лучше/хуже чем «фио возраст пол» может очень ускорить решения проблем с производительностью.

Ну так ни для чего из этого не надо знать ни алгоритмической сложности, ни даже того что индексы это B-деревья. Достаточно знать когда и что использовать.
Более того, я не помню задачь, которые бы требовали этого знания. Я знаю задачи, которые требуют знания свойств этих индексов и правил по работе с ними. =)

Вообще, если не понимать как работает та или иная база данных хотя бы в общих чертах можно не понять почему для sql базы данных лучше использовать ssd, а для Hadoop кластера или in-memory базы данных часто вполне можно обойтись и hdd.
Тут такое дело… попробуйте предложить задачи, где действительно нужно знать устройство изнутри, а не достаточно знать поведение инструмента там и сям. =)
Обычно это или очень нетипичные случаи и проблемы, которые или решаются обходом (что чаще всего возможно), либо просто неоптимально. (и такое бывает)… но в «рамках бюджета».
Или разработка чего то нового на этих принципах или доработка этих самых механизмов. Что задача совсем для других людей.
+3
ни алгоритмической сложности, ни даже того что индексы это B-деревья. Достаточно знать когда и что использовать.

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

ИМХО, для программиста не очень хорошо быть объязьяной с гранатой, рано или поздно можно условно залить антифриз вместо масла или с удивлением обнаружить, что если на ночь оставить автомобиль с включенными фарами, он почему-то утром не заведется.
+1
Ну кстати зная что индекс это дерево — точно не забудешь что лучше индексы по высокоселективным полям делать, не, это конечно можно и как заклинание для черного ящика запомнить, но все же.
-3
Да и БД знать не нужно, ORM всё сделает.

Передергиваете.

Про Б-деревья можно спросить в контексте любой реляционной БД

Они есть, нормальный ответ?) Меня пугает тенденция спрашивать про то, что человеку не нужно будет ровным счетом никогда.
Мне тоже задавали такие вопросы, если в ответ спросить как это знание используется в работе, станет ну очень интересно.

У меня вот кстати поинтересней вопрос есть и с ним должен быть знаком абсолютно каждый разработчик:
Как выглядит запрос автокомплитера и как он индексируется.

У нас GiST кстати не используются, я просто мануалы по используемым БД читаю иногда, вдруг есть интересные штуки.

То есть, на секундочку, я правильно понял: вы являетесь наглядной иллюстрацией статьи? Спрошу то, что мы не используем, и сам я не знаю?)

UPD О еще один вопросик знаю, тоже очень простой, но полный заблуждений:
у вас есть сервис с ЦА — корпоративные пользователи
Таблица пользователей: account_id, user_id, email, name, is_deleted
Почта является логином, как должен выглядеть по ней индекс?
+1
Ещё раз про GiST. Это просто пример чего-то конкретно связанного с PostgreSQL и редко используемого. А индексы на Б-деревьях есть в каждой реляционной БД.
GiST это не то чего я предлагаю спрашивать, понимаете? Это просто пример очень специфического вопроса конкретно по PostgreSQL по сравнению с тем что есть в каждой БД.
И ещё раз повторюсь: нет, про GiST я у людей не спрашиваю и не собираюсь. Тем более что один фиг не знаю ничего про них кроме их существования.
Донёс мысль?

> Как выглядит запрос автокомплитера и как он индексируется.

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

А про ORM кстати не шутка. Есть у меня знакомый синьор, почти 8 лет опыта, и в БД ни бум-бум. ORM работает и ничего. Ну вот не было у него необходимости писать запросы или смотреть чего там в БД тормозит.
Но как бы он и не претендует на знание БД, поэтому и спроса нет.
-1
Без понятия, я не занимался разработкой IDE или чего-то похожего.

Ну да, и сайтов с формами у вас тоже нет? Поиск по подстроке есть абсолютно везде и всюду.

А про ORM кстати не шутка. Есть у меня знакомый синьор, почти 8 лет опыта, и в БД ни бум-бум. ORM работает и ничего. Ну вот не было у него необходимости писать запросы или смотреть чего там в БД тормозит.

В своей узкой нише и такое возможно.
+1
Просто на правах возгласа из зала: за 20 с хреном лет поиск по подстроке мне ни разу не понадобился :) Ну, насколько могу вспомнить.

Но я знаю, что перебором эту задачу решать не надо (за исключением узких случаев), существуют всякие алгоритмы суффиксных деревьев и т.п., про что я кроме названия (и то очень неуверенно) не знаю ничего. Но я хотя бы знаю, что если будет такая задача — надо пойти и разобраться, а не говорить «ну я же не знаю O-нотации, и в ТЗ не было требования какой-то конкретный алгоритм применить, поэтому я буду делать полным перебором».
0
Просто на правах возгласа из зала: за 20 с хреном лет поиск по подстроке мне ни разу не понадобился :) Ну, насколько могу вспомнить.

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

надо пойти и разобраться

И в большинстве случаев этот разбор оканчивается на like %pattern%, мимо индекса.
Разбираться, кстати, в области поиска не так просто, особенно, скажем, в области поиска нечетких дубликатов: по некой причине информации исчезающе мало.
0
Видимо специфическая у вас область, я не догадываюсь как должны выглядеть интерфейсы без автокомплита.


Да как бы не все занимаются интефейсами.

И в большинстве случаев этот разбор оканчивается на like %pattern%, мимо индекса.


А если к этому пршпилить тертарное дерево…
-1
Да как бы не все занимаются интефейсами.

Зато бОльшая часть занимается таки тем что юзают пользователи) А на беке или фронте это уже не суть важно

А если к этому пршпилить тертарное дерево...

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

Автокомплит в сложных случаях предполагает передачу подстроки в условный Sphinx и невозбранное получение сниппетов и кучу других фишек.
+1
Ретроспективное искажение — называется такое явление. На руководящих должностях часто грешат таковым. Пока не знаю, как выявить — склонен ли человек к этому, до работы с ним. Сам был какое-то время подобным негодяем, о чём сожалею.
0
Просто разработчики с опытом 15 лет надеются что кандидат готовился к собеседованию. Просто если кандидат не знает и к собеседованию не готовился, то велик шанс получить довольно «вальяжного» работника.
+2
А я наоборот как то придерживаюсь мысли что к собеседованиям не нужно готовиться специально. Что реально знаешь на текущий момент — то и показываешь.
0
Это мне напоминает один психологический факт. Дети до какого-то возраста не могут понять сказку про Белоснежку. Почему она ест отравленное яблоко? Ведь это известно, что оно отравлено! У них в голове не укладывается то, что у другого человека может быть совершенно другой «контекст», другие знания. Может это как-то связано?

Вроде как отсутствие «модели разума» (theory of mind) после 4-5 лет один из признаков расстройств аутистического спектра.
+1
Не раз на собесах мне задавали вопросы о вещах, которые не используются в реальных проектах (так собеседующие потом признавались). Т.е. надо было знать некоторые хаки, трюки. Гнать таких собеседующих.
Также, по-моему мнению, не надо задавать вопросов о вещах, которые легко и быстро изучаются. Лучше говорить либо о проектах и опыте, либо о базе. Серьёзно, какова ценность знаний, которые можно получить в течение дня? Как то раз меня спросили, использовал ли я gRPC. На тот момент ещё не использовал, о чём и сказал. Но уже через день работал с ним.
+2
Ставя себя на место собеседующего — про вещи которые не используются в реальных проектах можно говорить для проверки широты кругозора собеседуемого и его интерес к теме. Главное себе отчет отдавать что кругозор собеседуемого может оказаться пусть и широким, но в другую сторону, и тогда обсудить толком не получится.
НЛО прилетело и опубликовало эту надпись здесь
+1
По хорошему со статьёй я согласен. Кроме пункта про тестовые задания. Это конечно очень субъективно и каждый такое должен решать для себя сам, но лично я собеседования с тестовыми заданиями обхожу стороной.
Может это только мне так не везло, но пока наличие тестовых заданий на собеседовании сильно коррелировало с неадекватностью фирмы…
Да и задания по большей части были не то чтобы особо «полезными».
0
Если тестовое задание делается за пару часов, то сделать его может быть быстрее, чем топать на очное собеседование в другой конец города. Да и адекватные работодатели вполне спокойно принимают «чужие» тестовые, если они +- подходят по профилю.
0
Если тестовое задание делается за пару часов, то сделать его может быть быстрее, чем топать на очное собеседование в другой конец города.

Подождите, топаете на другой конец города вы или фирма? Сделанное тестовое задание избавит вас от этого самого топания? То есть для фирмы это может быть и удобно, но я не совсем понимаю что в этом случае выигрывает кандидат.

+4
В общем случае, кандидату надо:
— оторвать задницу
— «привести себя во внешний вид» (умыться, приодеться, накраситься и т.д.)
— добраться до офиса, с запасом а пробки
— подождать, когда пройдёт запас на пробки
— пол часа в стрессовом состоянии разгадывать не смешные загадки
— поговорить за жизнь
— добраться обратно до дома

Дополнительно:
— если это в рабочее время, нет пп. 1 и 2, но надо как-то хитро отпроситься с основной работы
— к разгадыванию загадок надо готовиться, а заучивание наизусть тонны ненужной фигни отнимает немало времени.

Если решением тестового я повышу «конверсию» этой цепочки с 5% до хотя бы 30%, убрав при этом из неё пункт про разгадывание загадок, то 2-3 часа времени работы в комфортной обстановке это вполне окупят.

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

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


Вот только я на моей памяти на тестовых заданиях срезался только первые пару раз когда вообще не был готов к чему-то подобному. И как минимум с тех пор как я стал миддлом(а это было много-много лет назад) причиной по которой из собеседований ничего путного не выходило было либо расхождение в понимании того что считать адекватной зарплатой, либо какие-то личностные несовпадения с будущими коллегами/начальством. И следовательно для меня как кандидата эти самые тестовые задания особой пользы не несут,

+5
На администраторов linux-систем через тестовые задания приходилось искать. Причём ничего фееричного — вот тебе машинка голой… опой в интернет, надо какой-то минимально допустимый уровень защиты сделать (настроить firewall, подумать нужен ли ssh на стандартном порту с паролями — если нет, что-нибудь сделать) и развернуть мини-сайтик (для простоты — допустим, вордпресс).
Не поверите, из 20-25 человек приходивших на собеседование прямо на месте этим занимался только один, остальные брали домой, забывали про firewalld и теряли управление по ssh.
Итого — решило всего два человека. Один который делал всё на месте управление и логично (не всё знал, но быстро гуглил — его и взяли), и ещё один настоящий параноик, который применил кучу знаний и кучу хаков, был крут и неизмеримо превосходил тот уровень (и знаний, и ЗП) который мы искали…
0

Ну я в администрировании линукс-систем не осбо разбираюсь, но вы хотите сказать что без тестового задания адекватность кандидата выяснить невозможно?

+1
Возможно, но дороже. Правильные тестовые хорошо снижают затраты собеседующего. Естественно, как у любого фильтра есть потери потенциально хороших кандидатов. Но если есть поток кандидатов и многие валятся на похожих темах, а собеседования жрут много времени, то стоит включить в тестовое задание темы без освоения которых дальше разговор вести нет смысла. Мои тестовые (если применяю) всего 3-4 простеньких задач на программирование, задаваемые после скайп созвона и до приглашения в офис.
0
Возможно, но дороже. Правильные тестовые хорошо снижают затраты собеседующего.

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


Мои тестовые (если применяю) всего 3-4 простеньких задач на программирование, задаваемые после скайп созвона и до приглашения в офис.

Когда мне в своё время в течении двух недель на трёх собеседованиях предложили написать FizzBuzz мне было сложно воспринимать всё это всерьёз...

+1
Это нормально, каждый ищет так как ему выгоднее. Я же написал что такой метод нужно применять если кандидатов много, т.е. больше чем вы можете качественно отсобеседовать. То есть варианта отсобеседовать все хорошо выглядящие отклики в принципе нет и не предвидится. В таком случае у вас есть несколько вариантов
  • прекратить заниматься вообще всем, кроме собеседований, и при большом потоке вы всё равно всех не успеете отсобеседовать
  • Сильно завысить планку по тексту резюме и приглашать на собеседование только тех кто написали идеальное резюме
  • просто поставить всех в очередь кому-то сказать что вас пригласят на собеседование через две недели, может быть. В результате кто-то откажется, а самые невостребованные на рынке дождутся
  • и собственно работать над сокращением времени затрачиваемого на одного кандидата, пытаясь оценить его не только по резюме, но до полноценного собеседования. И тут я применяю два метода, скайп созвон и тестовое задание. Иногда всё вместе, иногда по отдельности. Да также есть те кто откажутся.

Как видите в описанной ситуации опции сделать всё и на отлично нет. Есть опция достичь лучшего результата за имеющееся время. А так как многие хорошие программисты плохие ораторы и плохие составители резюме, шанс я даю если резюме попадает в категорию приемлемо. Считаю что из 20 резюме предложить тестовое и скайп созвон десяти людям, и потом провести одно-два полноценных собеседований в офисе лучше чем сразу назначить 3-4 полноценных собеседований. Затраты моего времени примерно равны, возможностей проявить себя кандидатам — больше. Такова жизнь.
0
И да, и нет. Оценить насколько человек адекватен в разговоре — легко можно без задания. Оценить насколько он адекватен в решении конкретного круга задач — чуть-чуть сложнее FizzBuzz, но таки имеющих прикладной смысл — бесценно, уж поверьте. Кроме того, при поиске администратора почему-то ссылок на гитхаб, как правило, не дают. Ну и во фразе «мы решили делать ХХХ, потому что УУУ» почти всегда есть некая доля вклада личности в это «мы», которую при разговоре оценить не получится. Остальное вложили его коллеги, которые зачастую продолжают работать на предыдущем месте работы соискателя. Ну и почти всегда есть больше одного способа решить возникающие проблемы, а вот что именно выбрать и почему — только от человека и зависит, а без его реального рукоприкладства это весьма нелегко оценить…

В общем тестовое задание доставалось совершенно не всем. С кем мы сразу точно не смогли бы сработаться по каким-либо причинам мы вежливо отказывали сразу, дабы не тратить их время.
0
Причём ничего фееричного — вот тебе машинка голой… опой в интернет, надо какой-то минимально допустимый уровень защиты сделать (настроить firewall, подумать нужен ли ssh на стандартном порту с паролями — если нет, что-нибудь сделать) и развернуть мини-сайтик (для простоты — допустим, вордпресс)

гхм… адекватность задания сомнительна.
вот у меня есть хостов "голой попой в интернет", и почти нигде нет файрвола.
и на этих хостах есть сайты с >100к посетителей в день, и при этом я ни разу не сталкивался с wordpress, задание "поставить wordpress" загнало бы меня в ступор (не, я бы поставил, конечно, но вот если бы это пришлось делать прямо на собеседовании — это был бы стресс).


P.S. и да, везде ssh на стандартном порту. правда, отключен вход по паролям.

0
Wordpress для примера. Что угодно вообще, лишь бы оно работало на распространённом веб-сервере. А вот конкретно с вами мы, скорее всего, не сработались бы: с точки зрения моей компании, работающий файрволл на сервере, торчащем в интернет — это элементарная цифровая гигиена, как руки помыть. Не обязательно что-то произойдёт, но это лишняя степень защиты (с руками таже история — не обязательно вы немедленно заболеете кишечником, если мыть их не будете).
0

гигиена — это не вешать внутренние сервисы на внешние адреса.


раз вы заговорили про wordpress — для тестового задания на хосте нам нужны ssh, nginx на внешнем интерфейсе, mysql и php-fpm на localhost (честно потратил пару минут чтобы погуглить на чём там wordpress работает).
что из этого мы хотим защитить файрволом и от чего?!?


ИМХО файрвол нужен, если:


  • у нас роутер и нужно ограничить трафик других хостов (которые зачастую админятся не нами);
  • нам таки нужно сделать какой-то сервис доступным из интернета без VPN, но не для всех.

Да, iptables/nftables используются для всяких продвинутых вещей вроде легковесных счётчиков для мониторинга сетевого трафика, или управления шейпером — но это, всё-таки, не файрвол.

0

Недавно где-то рядом была тема про отключенный файрволл, не слушающие на внешних адресах сервисы и IPv6, который внезапно пошёл в массы, а по IPv6 многие "интересные" сервисы слушали "всё"…
Так что firewalld и selinux всё-таки лучше не отключать, а правильно настраивать.
Статьи по настройке linux-серверов, содержащих отключение файрволла и selinux стараюсь обходить стороной.

0

Полезно. Но какой-то давным-давно настроенный пакет, после обновления, может внезапно получить поддержку IPv6, а культура мониторинга изменений может оставлять желать много лучшего… как по мне, лучше все потенциальные дырки будущего закрыть сразу, умелыми руками, так как дальнейшее сопровождение сервера возможно специалистом менее прозорливым.

0
нужен ли ssh на стандартном порту с паролями — если нет, что-нибудь сделать
А что не так с ssh на стандартном порту? Много где встечаю, что ssh переносят на другой порт, но никак не пойму какой в этом смысл.
0
Security through obscurity работает, хоть и считается плохой практикой. Т.е. это не создаёт никаких гарантий, но если вы посмотрите в логах количество попыток произвести вход на ssh открытый на 22 порту и на другом то вы увидите кратное снижение количества атак. Да, по хорошему нужно закрыть авторизацию по паролю и использовать только ключи, но не всегда это реализуемо. Но снижение потока попыток входа таки снижает шанс проникновения. Подчеркну снижает а не исключает.
0

да на самом деле и во входе по паролям ничего особо страшного нет, достаточно не использовать короткие/словарные пароли.

0

Любой пользователь может сменить себе пароль на словарный. С ключами такое не пройдёт, в этом смысл.

0

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

0

перенос ssh на другой порт снижает количество попыток, увеличивает время до первой попытки, но как правило не влияет на качество попыток. то есть, если идет перебор по словарю (а сейчас еще и идет по графику с обходом стандартных правил fail2ban), то нормальный пароль (разный на каждый сервер и пользователя) дает достаточную защиту.
сертификаты где-то интересней, но несколько не такие гибкие (не всегда удобно использовать сертификаты)
ну и вполне можно натолкнуться на сеть, где запрещен исходящий трафик на нестандартные порты. просто на всякий случай.


ну и мое любимое неудобство — вспоминать, какой же там порт для ssh. и если он не отвечает — это ssh-server лег или я порт не тот пишу?


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

-5
Добавлю еще табу от себя:
1) На собеседовании больше двух человек. Значит ребята не умеют проводить собеседования. Ваше внимание будет рассеяно и может появится дурацкое чувство «один против троих». Также это косвенно говорит о том, что компания не в состоянии организовать две-три отдельных встречи с кандидатом. Представьте, как у них плохо с организацией более сложных вещей!

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

3) Техническое собеседование по скайпу. Вам работать с людьми, а вы их даже не видели. Просите тогда собеседоваться в слаке, чтобы другой рукой можно было кушать, чтоб «время не терять».

4) Не пришлось писать код. Автор уже рассказал, но я повторюсь, это же капец как важно.

5) Какие-то проблемы с проведением собеседования в нерабочее время или его назначение через неделю. Если провести аналогию со свиданиями, то кажется, что вами не особо заинтересовались. Скорее всего проблема в вас, вы это осознаете и не понимаете, почему вы молча не можете просто перестать друг другу звонить и писать. Бывало, мне через неделю перезванивали, предлагали еще через неделю придти на собеседование. То есть в сумме через две недели после первоначального созвона. Bruh.

6) Вопросы о желаемой зарплате до технического собеседования. Вы еще не поняли, что, как и с кем будете делать, а вас спрашивают, сколько вы за это хотите. На самом деле, это hr-уловка, чтобы вам меньше платить, но для 2020 прием довольно грязный, косвенно это говорит о том, что компания неприличная.
+8
Техническое собеседование по скайпу.

А с этим-то какие проблемы? Это норма жизни для распределенных контор. И для «видеть» есть вёбка — вот если вас контора просит собеседоваться без вебки, то это повод насторожиться.
+5
Не понял вас насчет 6го пункта, вы предлагаете сначала проходить тех собеседование, а потом только называть зарплату, которую вы хотите получать? На мой вкус лучше сразу договориться на берегу, чем пройти собеседование и потом выяснить, что у компании в принципе нет такого бюджета на вашу зп. Да, я думаю, большинство кандидатов всегда держит в голове фиксированную сумму, у них нет такого «ой тут у вас все под винду — накиньте как десяточку к зп» или «ой, вы макбук даете, ну десяточку я вам скину тогда». В чем опять же смысл выяснения зарплаты до того, как вы узнаете что за работа? Только зря потраченное время в случае, если работодатель не готов вам платить желаемую зп.
+4
Я бы накидывал 25% к требованию зп после уточнения на собеседовании, что удалённой работы нет и невозможно.
Потому что 2-3 часа в день ради перемещения тушки в офис — это тоже работа. Тяжёлая и опасная из-за повышенных эпидемических рисков, требующая компенсации на ежедневные траты (иногда включающие в себя повышенную цену на еду из-за невозможности приготовить дома обед).
0
Наличие или отсутствие remote можно уточнить и без собеседования.
0
большинство кандидатов всегда держит в голове фиксированную сумму

Держит, конечно. Но во-первых могут быть факторы, которые на решение повлияют:
— есть еще одно предложение, но с более интересными задачами и той же суммой — «накиньте десяточку»;
— все нравится, но оказалось что до офиса нужно на электричке ехать дальше и дольше, чем вы рассчитывали;
— есть гарантии в регулярной индексации / повышении зарплаты за успешные успехи;
Не все смогут назвав цифру предварительно, «поторговаться» после выяснения важных деталей, не описанных в вакансии. Поэтому страшно называть сумму заранее. Я уж не буду упоминать про «а вдруг я приду к ним синьором, а денег на самом деле попрошу столько, сколько они платят даже джуниорам, буду как лох».

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

у компании в принципе нет такого бюджета на вашу зп

Тогда компании стоило бы какую-то вилку или ориентировочную зарплату указать, не?
+1
«Минимум я хочу столько, но точно мы обсудим после технического собеседования».
Не собираюсь поддерживать подход «просто хочу найти работу, где бы мне платили минималку». С таким подходом вы всегда будете мало зарабатывать.
0
«Я готов разговаривать о сумме от… рублей. Конкретная сумма зависит от списка доп. обязанностей и бонусов (скидки на фитнес, ДМС, стоимости еды в около офиса, удалённая работа, плавающий график и прочие кофемашины в офисе)» — по-моему, это достаточно прямо и честно.
Забавно, что в некоторых случаях при озвучке пункта «от» люди извиняются и уходят со словами «не, мы столько не выбьем». Уважаемые, однако, здравствуйте, это же у меня было написано в резюме, неужели никто их не читает?
0
неужели никто их не читает?

А вы что думаете, что читают? У кого-то есть время читать сотни однотипных резюме? Мельком пробегают по списку скиллов и готово.
+2
То есть потратить 2 минуты на чтение пунктов «скиллы и технологии» и «зп» — нельзя, а час названивать, что спросить «А вы имели дело с фреймворком х / занимались ли у?» — есть?
Мне непонятна такая логика.
0
Уважаемые, однако, здравствуйте, это же у меня было написано в резюме, неужели никто их не читает?

А ещё многие пишут в резюме завышенную зарплату чтобы не надоедали рекрутёры, а ещё некоторые (как в комментарии выше) пишут свою текущую + 25%. И ещё много других вариантов. Так что в любом случае лучше уточнить этот момент.

+2
Вы шутите?!
Нет, серьёзно, люди выходят на рынок труда и делают так, чтоб им не звонили рекрутёры??
Теперь я не понимаю обе стороны.
0

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


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


Но если мне рекрутёры ещё и звонить на телефон будут – это будет чересчур.

+2
Потому что не везде его можно «закрыть». LinkedIn, МойКруг и прочие места всегда держут ваш профиль, и максимум, что вы можете изменить это значение переключателя сверху «ищу работу / рассматриваю предложения / не ищу работу».
И всегда будут люди, которые даже будут вам писать, даже если у вас будет стоять «не ищу работу». Ну, потому что так дешевле. Да, именно дешевле. Дешевле отспамить всем, у кого навыки совпали, вдруг кто-нибудь да отзовется.
0

На меня как-то рекрутеры вышли по аккаунту на StackOverflow. О каких вообще закрытых резюме идёт речь, если там иногда не просто "холодные звонки", а "звонки абсолютного нуля"?

0
А у меня, допустим, нет цели чтобы звонили всегда. Мне важно понять, где грань, когда интерес к моему балансу «навыки/$$$» начнет снижаться. Такое маркетинговое исследование :)
0

А если у вас вообще нет свежего резюме в открытом доступе? А вам регулярно пишут и звонят :) и задают этот дурацкий вопрос про з.п… ну не знаю я за сколько соглашусь работать, а вдруг вы мне предложите 30 часовую неделю, да ещё и по удалёнке ??? :).
Вот скажите сразу "мы рассчитываем на 10 уе склоняемся к 8 но если не найдём готовы к 1.2 а за больше нам и не надо, почему это так сложно? Ведь это бюджет нанимателя...

+1

Это называется пассивный поиск работы. Тебя все устраивает на текущем месте и собеседования каждый день проходить смысла нет.


Но если предложат что то крутое по ЗП куда выше рынка, то можно и подумать.

+4

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


Ваше внимание будет рассеяно и может появится дурацкое чувство «один против троих».

Должна ли компания подстраиваться под психологические особенности каждого кандидата, еще ничего о нем не зная, кроме резюме, вот в чем вопрос? :) А если для вас это действительно настолько важно — попросите при организации собеседования больше 2-х не собираться. ;)


Также это косвенно говорит о том, что компания не в состоянии организовать две-три отдельных встречи с кандидатом.

А зачем, если всё можно решить за одну, и это будет куда быстрее для всех задействованных сторон? Оно вам надо? А компании?


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

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


Вам работать с людьми, а вы их даже не видели.

Заканчивается 2-я декада 21 века. Я две трети персонала компании, с которым постоянно работаю, видел пару раз по видеоконференции, а во многих компаниях этот процент еще и повыше. :)

-9
Я понимаю, что для кандидата важен в первую очередь он сам, но и вторую сторону все же имеет смысл оценивать адекватно, а не с точки зрения, что вы — центр вселенной, а остальные должны подстраиваться.

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

Допустим, собеседование назначено на 10 утра, нач. отдела и техдир. Вы в 9 выезжаете из дома, в 9.37 техдиру звонит генеральный и просит зайти по срочному вопросу на полчасика.

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

Действительно ли нормальный, вменяемый кандидат не переживет, если «опоздавший» техдир задаст вопрос, который второй человек уже задавал?

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

Заканчивается 2-я декада 21 века. Я две трети персонала компании, с которым постоянно работаю, видел пару раз по видеоконференции, а во многих компаниях этот процент еще и повыше. :)

Зачем вы говорите о своих недостатках?
+9

Подитожим:


  1. Вы считаете возможным придумать некую картину мира, спроецировать ее на совершенно незнакомого вам человека, и на основаниии вашей собственной проекции обвинить его в том, что у него "отсутствует понимание".
  2. Вы совершенно не представляете себе работу менеджмента, особенно — топ-менеджмента, но считаете возможным со своей высоты делать выводы о профпригодности/непригодности.
  3. Вы считаете "недостатком" либо наличие в природе территориально распределенных компаний, где между офисами могут быть тысячи километров, либо нежелание тратить такими компаниями деньги на авиаперелеты руководства с целью собеседования людей на низовые позиции.

Мне в принципе всё понятно, в том числе и о "токсичности", спасибо за беседу, мы вам перезвоним. :)

+1
В яндексе совсем не гуманная система собеседований. Вся эта мутная тягомотина с десятком собеседований, растянутых чуть ли не на месяц, и кучей людей, каждый из которых тебя может отфутболить по каким-то своим личным заморочкам — она, как я думаю очень много годных специалистов отбраковывает.
Общался со многими довольно крутыми ребятами — часто слышал историю о том как человек ходил-ходил на собеседования в Яндекс, решал все эти задачки, потом ему предлагали какой-либо вкусный оффер в другую фирму и когда он уже какое-то время работал на новом месте — ему приходило приглашение побеседовать с Финальным Боссом на собеседовании в Яндекс.

Хотя, возможно, это специально сделано так что-бы отсеивать всех кроме студентов, с кучей времени на хождение по собесам, не знаю. С другой стороны — а нафига тогда приглашать, если брать не собираетесь.
0
очень много годных специалистов отбраковывает.
Для компании типа Яндекс «false positive» на порядок менее приятен, чем «false negative». Учитывая то количество кандидатов, которые есть у этих компаний, отфутболивание десятков годных специалистов — правильная тактика. Лучше отфутболить 10 годных, чем принять одного негодного.
0
Прямо-таки много кандидатов?
Как-то это звучит как пресловутое «толпа за забором». У меня что-то нет ощущения переизбытка специалистов на рынке IT. Где-бы не работал — найм дополнительных людей всегда был большой головной болью для руководства.
+1
Так «специалистов», а не «желающих поработать в Яндексе».
-1
а что такого особо-особенного в Яндексе что он прям страдает от «плохого» кандидата? я чето не особо вижу обалденного качества их продуктов да и немного наслышан об их внутренней кухне… ничем особым они не отличаются
+1
Все компании страдают от плохих отрудников. Но некоторые компании имют возможность выбирать из более широкого пула кандидатов.
+1
Как человек немало походивший по собеседованиям имею на этот счет свое сложившееся мнение.

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

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

Да, постоянно приходящие/уходящие люди тоже мешают и сбивают с настроя.

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

Но это так, рабочие моменты, с этим как-то можно еще жить. Хуже всего когда беседа проходит в режиме:
— Что вы знаете про /редко используемая заморочка, которую мало кто держит в «оперативной памяти» и о необходимости знания которой перед собеседованием даже не упоминалось/.
— /Короткий рассказ из того что вспомнил с налета/
— Ну собственно все понятно, если у вас, коллеги вопросов нет, то я все… (демонстративно собирает вещи)
На этом месте как-то сразу думаешь — и нахрена я перся в другой конец города, ждал пока тут все соберутся, обсуждал с ХР всякую ерунду.
+5
Техническое собеседование по скайпу.

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

Если работа предстоит в офисе, а вы там ни разу не были и людей не видели, то можно просто перед принятием оффера сказать — всё круто, оффер мне нравится, можно я к вам офис загляну посмотрю что у вас как? Мне пока никто не отказывал.
-3
Вопросы о желаемой зарплате до технического собеседования


Однажды увидела в описании вакансии одной очень известной российской IT-компании требование указать желаемый размер зарплаты в сопроводительном письме. Я чуть не поперхнулась от возмущения
0

А можно спросить в чём проблема? Я достаточно часто так делаю и сообой проблемы в этом не вижу...

0
Мне кажется, если между соискателем и работодателем на собеседовании случается химия, то последний готов будет платить первому столько, сколько тот попросит. Узнав же в сопроводительном письме, сколько кандидат хочет денег, HR может отказать на этом основании на самом деле классному кандидату. То есть работодатель сужает поиск, и в итоге найдет либо джуниора, либо сотрудника с синдромом самозванца. Но это мое мнение
+2

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


И я в таких ситуациях обычно просто указываю вилку с относительно большим разбросом.

+3
«Химия» это один взгляд на процесс, но ещё есть бюджет, и чаще чем реже собеседующий имеет очень ограниченное влияние на него.
Я вот без проблем называю сумму «от Х». Потому что если даже её нет в бюджете, то не хочется тратить время на разговоры, время вещь ценная.

Но вообще процесс переговоров зависит от страны и прочее. Где-то обсуждение идёт только после.
0
Сегодня в крутых магазинах происходит ровно то же самое: На вопрос о цене продавец уклоняется от прямого ответа но зато нахваливает товар, дает потрогать, пощупать, все что угодно, чтобы только приболтать вас на данный товар. Когда в конце концов вам озвучивают цену со скидкой в 50-80%, вы просто выпадаете в осадок. Ну а ежели случается «химия», то вы уходите с пустым банковским акаунтом в лучшем случае, или выплачиваете кредит в худшем. Забавно, что такие прожжёные продажники уже вошли в ИТ, но ничего личного, бизнес есть бизнес)
+2
Работаю в одной из IT компаний в штатах с офисами по всему миру. И не во всем с вами согласен:
1) На собеседовании больше двух человек.

К собеседованиям тут подходят серьезно и системно. Чтобы начать проводить интервью, нужно пройти тренинг и калибровку. Второй человек на собеседовании нужен как раз для этого (он либо «тренер», либо «студент»). Вам бы хотелось, чтобы вас оценивал человек, не имеющий опыт в интервью?

2) Вам пришлось рассказывать что-то о себе дважды

Для кандидата обычно проводится 5-7 интервью (часто в один день). Вполне вероятно, что вас спросят о чем-то дважды, и ничей вины в этом нет — просто так может складываться диалог.

3) Техническое собеседование по скайпу

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

4) Не пришлось писать код

В общем-то тут я согласен. Правда, мы не требуем глубоких знаний языка программирования. Кандидат может выбрать любой, какой ему нравится. А для whiteboard interview можно использовать и псевдокод.

5) Какие-то проблемы с проведением собеседования в нерабочее время или его назначение через неделю.

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

6) Вопросы о желаемой зарплате до технического собеседования

Честно говоря, я не особо такое встречал в западных компаниях. Но если вас спросят, то я порекомендовал сказать либо range (e.g. "$200-250k"), а лучше что-то в духе «уверен, что мы сможем договориться»
0
Я как-то в своё время задал похожий вопрос своему коллеге, который отвечал за собеседования на нашей фирме. Он ответил что-то вроде: «можно всё что угодно, но выпендрёжников я не люблю» :)
0
Идрис можно?

Можно, если вы уверенно его знаете и сможете объяснить как это работает. Главное помнить, что чем больше времени вы потратите на объяснения, тем меньше оставляете времени на все остальное.
Один из кандидатов пытался решить задачу на Haskell, и у него не получилось решить даже базовую часть.
0
На таком, который будет понятен интервьюеру. Ваша цель — не блеснуть знаниями языка, а показать, что вы умеете думать. Если хотите выпендриться, то рискуете быть непонятым.
0

Я немножко в другом смысле спрашивал. Надо объяснять на уровне «вот эта строка делает вот это» или вплоть до метатеории языка?


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

0
Стоит ли оценивать сантехника по тому, как он владеет гаечным ключом, или плотника по тому, как быстро он забивает гвозди? Так же, Software Engineer — это не про умение кодить. Поэтому не важно каким инструментом ты решаешь задачу — если ты понимаешь принципы и можешь размышлять, находить решения, понимать их достоинства и недостатки, то освоить нужный язык программирования не составит труда.
К тому же, если вас уже пригласили на собеседование и вы прошли скрининг, то ваш бэграунд работодателя вполне устраивает.
0
Проводил собеседование. Нужно было поддерживать адское легаси на Delphi 7 и 1С (но версия 1С была свежее, чем версия Delphi), но c кандидатами за предлагаемую зарплату было туго. Начали убирать требования: опыт работы сначала сократили, потом убрали совсем; высшее образование съехало на средне-специальное, а потом и на неоконченное; наконец, выкинули требования знания каких-либо конкретных ЯПов. Осталось лишь «уметь программировать». Ага.
Тестовое задание — три задачки уровня 7-го класса лицея с углубленным изучением информатики, не более того, я разрешал решать при мне на любом ЯПе из тех, что есть на рабочем ПК или из тех, что есть на ноуте собеседуемого. Разрешал гуглить, пользоваться документацией, делать что угодно, кроме поиска готового решения или использования абилки «спроси друга».
Один из кандидатов, кто пришел на собеседование, пришел со своим ноутом. Спросил, можно ли написать решение на Ruby. Написал, объяснил пару мест в коде (я в Руби не умею, потому задавал вопросы). Получил работу. Всему необходимому человек дообучался уже работая.
0
Порядок инженера-программиста в муниципальном предприятии (от третьей до первой категории, в зависимости от стажа).
Это примерно на треть меньше, чем позиция джуниора в крупной айти-компании.
0

Вакансии на delphi это нечто… Когда искал работу в прошлый раз (до скачка курса 2014) публикуемые были ~100 сейчас ~100-110… При этом где-то помнится хотели чтобы свой dataset набросали :)

0
При этом где-то помнится хотели чтобы свой dataset набросали :)

Ну, простой датасет с заглушками большинства методов — это не бог весть какая сложная задача, минут на полчаса. Тем более что программисту Delphi иногда приходится это делать, когда надо подцепить живые данные из какой-то экзотической фигни.
0

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

+2

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

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

И если тестовое задание, это не реальная работа с проекта, то скорее всего её решение очень просто нагуглить и переработать.
И о качестве кода ничего не говорит(так как человек может писать в нестандартной для себя манере, в которой в проекте никогда писать не будет). Тестовое вполне может написать другой человек в конце концов.

Так что лучшее тестовое это оплачиваемая реальная задача с проекта. Но опять же, при желании она говнокодера джуниора с позиции сеньора не отсеет. Была на хабре статья как индусы так устраивались)
+5
Я придумал, как мне кажется, довольно оригинальную альтернативу тестовому заданию.

Вместо теста на написание кода я предлагаю человеку задание на чтение кода.
У меня есть специально написанный для этих целей веб-скрипт, близкий к реальной жизни — легаси, плохой стиль: в одном файле верстка, логика и sql. Всё помещается на страничке A4, распечатанное с подсветкой синтаксиса.

Задача человека состоит в том, чтобы прочитать код, предположить, что именно должен делать этот скрипт, постараться определить, почему он работает неправильно. Затем он ещё может найти уязвимости, которые туда добавлены, найти баги попроще, рассказать о том, как всё это правильнее рефакторить и т.д. — тема для обсуждения неисчерпаемая.
+2
Да, это отличный вариант, сталкивался когда предлагали найти ошибки в коде строчек на 20 — нашёл на одну больше чем ожидали )
+1
Кстати, у нас в компании есть что-то похожее. Кандидату предлагается сделать Code Review кода (есть варианты для нескольких языков программирования). Это довольно интересный тип интервью, поскольку позволяет оценить:
1. Насколько ты умеешь находить баги
2. Насколько ты имеешь представления о Design Patterns, OOP, SOLID, etc.
3. Soft skills и в какой степени ты можешь быть ментором.
+2
Моя первая реакция на такое предложение была бы «дайте ваши соглашения по коду и пол часа на ознакомление» — как можно проводить ревью без понимания внутренних соглашениий по коду?
0
Так может цель такого задания это проверить как настроен ваш внутренний компас и насколько он близок к тому что у себя желает видеть фирма.
0
У опытных инженеров этот компас более-менее совпадает. А вот по стилю общения можно много что сказать — хочешь ты с этим человеком работать или нет. В интернете много ресурсов о том, как лучше это делать, например:
Reviews should be concise and written in neutral language. Critique the code, not the author. When something is unclear, ask for clarification rather than assuming ignorance. Avoid possessive pronouns, in particular in conjunction with evaluations: “my code worked before your change”, “your method has a bug”, etc. Avoid absolute judgements: “this can never work”, “the result is always wrong”.
Try to differentiate between suggestions (e.g., “Suggestion: extract method to improve legibility”), required changes (e.g., “Add Override”), and points that need discussion or clarification (e.g., “Is this really the correct behavior? If so, please add a comment explaining the logic.”). Consider providing links or pointers to in-depth explanations of a problem.

0

Это же дополнительный повод обсудить, почему вы считаете что поведение оператора + вероятнее всего перепределено в другой части кода :)

0
Вы так думаете, что у нас все дураки сидят, и ничего не понимают? У нас есть style guide, а соглашения определяются на уровне команды. Ни то, ни другое на интервью не оценивается.
0
И если тестовое задание, это не реальная работа с проекта, то скорее всего её решение очень просто нагуглить и переработать

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

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

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

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

Самый хороший метод — это реально послушать про проекты человека. Что и как делал. Но требует хороший квалификации у рекрутера и времени.
0
Самый хороший метод — это реально послушать про проекты человека

тестовое задание этого не отменяет, но то как человек пишет код увидеть надо
+4
> Откуда берут тестовые задачи? Из интернета и решения там же.

Это тестовое задание курильщика берётся из интернета. Тестовое задание нормального человека берётся из реально встретившейся на работе задачи. Берём задачу, которую мы только что решили, выбрасываем оттуда всё лишнее, упрощаем по максимуму контекст, и выдаём со словами «нам интересно посмотреть, как вы будете это решать, какие методы использовать, какие допущения примете». А потом на эту тему ещё и поговорить.
0
Обычно тестовые используют только на большой аудитории.
То есть от 10-20 человек и больше. И каждому отдельное тестовое никто не будет делать новое(а если не делать новое, то возвращаемся в пункт — есть в инете). Есть даже теория, что тестовые используют только чтобы выявить терпеливых и неуверенных в себе. То есть оставить тех на ком можно будет ездить потом. Не все так используют, но из-за встречавшихся таких случаях я отбрасываю фирмы с тестовыми задачами дольше часа сразу.

Вашим методом вполне можно обойтись и без тестового, а поговорить по коду человека в его репозиториях. Так и больше пользы для программиста рекрутера. Заодно можно понять что новое добавит с собой человек в проект, какой свой бэкграунд. А это очень важно.
+1
Я работаю программистом 19 лет, но у меня нет ни единой строчки кода ни в одном публичном репозитории.
0
Для разговора можно и свой не публичный показать или доступ дать. Про публичность я не говорил. Если нет возможности в репозитории показать, то можно на своем ноутбуке какой нибудь свой проект. Просто это точнее покажет код человека, чем тестовое задание.
+1
Не все делают нерабочие проекты (соответственно, и показать их нигде нельзя).
Видимо комментарий был именно об этом.
0

Значит, у тех, у кого строчки кода таки есть, будет преимущество перед вами, только и всего.

0
Воля ваша, но по мне это тоже подход курильщика. Искать под фонарём, в смысле.
0

Почему ж под фонарем? У человека есть готовый код, видно, как он его разрабатывал и как он думал. Это имхо лучше, чем тз.

0
Откуда берут тестовые задачи? Из интернета и решения там же.


Из личного опыта и текущего проекта.
0
Что, все помнить? Он не станет читать к собесу про ACID и CAP, как студент к экзамену.

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

При этом:
1. Экзамен составляет и проводит не профессиональный преподаватель.
2. Экзамен имеет произвольную сложность (обычно более высокую по сравнению с вузом, поскольку работодатель компенсирует для себя более высокие риски от неудачного найма).
3. Вопросы для экзамена могут заимствоваться от собеседований на более престижные рабочие места с упусканием очевидного факта, что целевая аудитория может банально не захотеть проходить сложную лестницу испытаний ради шарашкиной конторы.

Поэтому на таком экзамене могут спрашивать ВСЁ. Любую дичь. Почему люки круглые? Сколько уровней у модели OSI? Есть ли у вас родственники за границей? А вы можете скачать анкету на восемь листов, заполнить её от руки, расписаться и закачать обратно?

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

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

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

Святая правда.
Странно, что так мало людей это понимают (или, по меньшей мере, озвучивают).
+2
Это лучше смотреть, конечно :) Silicon Valley 1 сезон, в перерыве презентации на TechCrunch Эрлих ляпнул что-то типа: «Мы выиграем, даже если для этого мне придется спуститься в зал и подр@чить там каждому», ну и по-приколу стали рассчитывать время, которое для этого потребуется и в какой-то момент (на картинке), Гилфойла осенило, что если др@чить в две руки, то будет в два раза быстрее :) Вобщем, все эти рассуждения привели к улучшению алгоритма их программы :)
+4
Ну в принципе нормально же всё получилось?

Приходишь на собеседование, и если спрашивают только что-то своё и по теории, не пытаясь узнать и проверить прошлый опыт в контексте своих задач, то всё ж ок -> не моя контора, хорошего вам настроения, пока!

Или автор просто высказал неявно требование, что все конторы должны быть зрелыми, как и и их сотрудники и процессы? Так лучше забыть про это требование к миру, и жизнь станет лучше и веселее сию же минуту! :)
0
Чаще бывает даже так, что зависит не от конторы, а от команды в которую вы попадете. Или переходя к частному: от людей которые пришли вас собеседовать. Поэтому попадите вы в другой проект или даже поставьте собеседование в другой день и к вам придут другие люди на встречу. Так что очень не удобно получится, если у вас появилось желание работать в крупной кампании, вам откажут, а hr сохранит вас в истории как «не компетентного специалиста».
+1
Ну, за все компании говорить не берусь.
Но всё же вижу явное противоречие.

Если компания крупная, и HR клеймит кандидата на основании результата одного интервью от конкретной команды, которая единолично к тому же принимает решение о кандидате, то что это тогда за крупная компания? Очевидно же отсутствие процесса, адекватного размеру компании. Такие «крупные компании» лучше обходить стороной, раз рынок позволяет — ведь они объединят в одном месиве все минусы мелких и крупных компаний.

В крупной компании HR сначала сделает своё интервью, потом уже будет предлагать потенциального кандидата разным командам, кому нужны кандидаты. Ну или наоборот, но это не суть важно. Важно, что мнение одной команды не сделает профиль кандидата «невъездным».
+1
Также можно добавить что нормальные конторы дают аргументированный отказ, то есть после ответа становиться понятно каких знаний не хватает и что надо «подтянуть» чтобы устроиться в желаемую компанию.
0
Обычно это надо специально у них спрашивать, и то редко кто ответит. По моему опыту пачки собеседований полгода назад, просто какую-то реакцию хотя бы просто «да» или «нет» и то дают хорошо если половина контор. Вторая половина не звонит и не пишет — им не до того, надо других кандидатов собеседовать.
+6
Многие опытные программисты имеют мнение что они не доверили бы разработку самому себе из прошлого, у которого на 1 год опыта меньше.

И на сегодняшний день, часто все их критерии — то что они выучили нового за прошедший год.

Я для себя осознал что собеседования в русскоязычных странах — это тест на культурную совместимость. Более того, зная название компании (или бэкграунд её сотрудников) — можно на 90% быть уверенным о критериях отбора. Т.е. в условном Киевском люксофте могут спросить о разности контейнеров, а в условном Московском яндексе спросят о разновидностях куч и алгоритмах над ними. А в условном «стартап инкубаторе» попросят посмотреть на ваши аккаунты на гитхабе и стаковерфлов. В условной кажуалгеймкомпани, попросят за вечер наклепать шахматы с клиент-сервером.

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

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

А ЗНАТЬ И ПОМНИТЬ некоторые виды алгоритмов — это примерно как помнить, каким именно способом в лабах измеряли коэффициент силы трения в твоем справочнике о характеристиках подшипников.
+6
Хороший технический интервюьер ещё более редкий зверь, чем хороший программист. Потому-что во-первых, этому нигде не учат, а во-вторых, потому-что требует редко встречающихся в одном человеке скиллов — коммуникативность и техническая грамотность.
В большинстве случаев, такие люди довольно успешны в карьере и их время стоит дорого. Использовать это время для собеседований могут позволить не многие компании.

В итоге, в основном интервьюированием занимаются либо коммуникалы без технических знаний, либо техспецы без навыков коммуникации. И те и другие вынуждены прибегать к шаблонным наборам вопросов. Поэтому будьте снисходительны — людей заставляют делать несвойственную работу. Неудивительно, что она не очень получается.
0
Вот мне интересно, когда до компаний дойдет, что для них, вообще-то важно, кто у них работает? По одному и тому же ценнику можно нанять людей, очень существенно различающихся уровнем — и это различие выльется в сэкономленные или продолбанные месяцы работы, сотни тысяч заработанных или потерянных долларов и кучу сохраненных или сожженных нервных клеток.
-2
Тут я должен также патетически воскликнуть — «когда же до программистов дойдёт, что компаниям не так уж важно кто у них работает». На самом деле, конечно же разница есть, но для большинства компаний не на столько большая, чтобы сильно вкладываться в процесс приёма программстов.
0
Вы верите, что я один и тот же проект могу сделать за два месяца, а могу — за шесть, и разница будет только в том, что в первом случае, я однажды в поезде потратил три часа на листание Фаулера? А вот оно так, и в обоих случаях срок покажется всем нормальным и адекватным. А ведь я не один в проекте и каждый месяц я отбираю из копилочки господина собственника кругленькую сумму.
0
А ведь я не один в проекте
— а вот это ключевое в данном случае. Вы не один и кто-то прочитал Фаулера, а кто-то что-то другое. Совсем не надо, чтобы все читали всё. Ну а если в команде не происходит обсуждения текущих задач, то тут уж точно качество программистов никак на результат работы не повлияет — она всё равно окажется провальной. Вот и получается, что качество каждого конкретного члена команды не так уж сильно влияет на результат. Поэтому и не настолько важно кто работает.
Конечно бывают высокотехнологичные проекты, но это не массово.
+1
Разные люди читают разное — согласен. Но из этого не следует, что «компаниям не так уж важно кто у них работает». Напротив, из этого следует, что процесс собеседования выходит еще более сложным: ведь нужно подобрать команду, каждый из членов которой будет своими сильными сторонами компенсировать слабые стороны коллег. Для проведения собеседования необходим человек, понимающий свою команду и проекты, а также обладающий навыками проведения собеседования — как методическими, так и «мягкими». Этому надо учиться, читая книги, обсуждая методики и их применимость к вашей ситуации и практикуясь под надзором старших коллег.

Ну или понадеяться на авось и на то, что раз в команде 10 человек, компенсация произойдет сама собой, [sarcasm]«по закону больших чисел»[/sarcasm].
-3
Я вот согласен с предыдущим комментом. Если вы способны сделать проект за 2 месяца которые раньше делались за 6, то логичнее с позиции нанимающего(если компания большая) в штат вас не брать. Вы будете отличаться от коллектива, и возникнут трения, у всех будет куча проблем(например чем вас занять на оставшиеся 4 месяца). С собственника вы ничего не отбираете, зарплату вам все равно платить в любом случае
0
Мне кажется, проблема «чем вас занять на оставшиеся 4 месяца» появляется не так уж часто.
-2
Ну это все равно головная боль для менеджера. Ну т.е. посудите сами — если вас собеседуют коллеги, то им нафиг не нужен человек, который будет все делать быстрее их. Для менеджера это с первого взгляда хорошо, но вы же не один, т.е. если вы будете выделяться, это приведет к нездоровым отношениям в коллективе, что вообще катастрофа для него(которая несравнима с небольшим ускорением разработки)
+1
Ну т.е. посудите сами — если вас собеседуют коллеги, то им нафиг не нужен человек, который будет все делать быстрее их.

Почему? До тех пор пока кто-то не пытается использовать это как повод для понижения моей зарплаты, то у меня с этим проблем нет. А если кто-то такое начнёт, то проблема в этом человеке, а не в быстро работающем.

0
Я честно говоря вообще ни разу не слышал о понижении зарплаты(ну кроме в период кризиса). Обычно бюджет выделяют на отдел, далее эту сумму менеджер распределяет(это если плановые повышения)
Ну т.е. посудите сами — вы собеседуете людей(на зп аналогичную вашей), один повыше вас уровнем, другой пониже. Для вас более логичным взять пониже(предварительно задав вопросы о сортировках списка, чтобы к вам никто не прикопался). Ибо взяв повыше вы получаете материальные риски(бюджет уйдет не вам), и моральные(все сложные и интерестные задачи будут уходить не вам). Ну или вам вообще все равно на знания, смотрите чтобы на обед было ходить веселее. Это конечно вариант когда идет работа только за зарплату, если есть большие премии от результата(например консалтинг), тогда конечно не так. Но с премиями другая проблема — вы не наймете никого высокого уровня(или будет очень сложно найти того кто согласится на такое)
+2

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


Если человек работает быстрее, то это совсем не значит что он вдруг получит более интересные задачи. Скорее он получит более срочные, но не факт что они будут интереснее.
А то что "бюджет уйдёт не мне", так я если честно не совсем понимаю что это вообще за бюджет и куда он там должен уходить. У меня есть зарплата, которая в моём понимании соотвествует моим способностям. Если кто-то при прочих равных работает быстрее, то вполне себе логично что ему будут платить больше. Но я не вижу почему это должно быть проблемой...

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

Да как же не нужен? Нужен! Я у него поучиться смогу, например. Ну или спихнуть ему свою работу, если я ушлый и ленивый.
-4
ну это не логично.
по поводу поучиться — т.е. вы собеседуете человека на такую же зарплату как у себя и планируете у него поучиться. Это значит что вам как бы платят больше рынка и взяв этого человека ваш менеджер это увидит. О повышении можно будет забыть
Спихивать работу тоже странно — логичной все же выглядит стратегия замыкать все на себя, тогда вы будете более незаменимы
Но это опять же работает если платят только зарплату вне зависимости от результата
0
Ну почему же «замыкать на себя»? Если вы будете замыкать все на себя, разумнячий менеджер, начитавшийся про bus factor, быстро это пресечет. Незаменимый сотрудник в сегодняшних реалиях делает кучу всего и с радостью всех всему учит, при этом оставаясь незаменимым просто потому что объемы и разнообразие того, что он делает, слишком велики. Ну а про повышение, о котором можно забыть — я никогда в них особо и не верил, первые лет десять карьеры лучшее повышение — это переход в другую компанию.
0
За 4.5 года на своем первом месте работы зарплата выросла в 3.5 раза и еще планировала расти. С должностями аналогично. Причем я даже не просил, оно само, и по зарплате честно говорил что меня и текущая устраивает (примерно после того как в 2 с копейками раза от начальной выросла).
А вот то что смена работы поможет покопать в ширину и набраться нового опыта — согласен.
+1
логичной все же выглядит стратегия замыкать все на себя, тогда вы будете более незаменимы
«логичность» не так уж универсальна — она сильно от системы ценностей зависит. В вашей логичности главная ценность — деньги. Вы боитесь, что повышение пройдёт мимо вас, что вы окажетесь недостаточно незаменимы и потеряете зарплату.
В моей системе ценностей другие приоритеты. Я свою любознательность ценю больше, чем деньги. Мне неинтересно заниматься одним куском кода долго. Я с удовольствием спихну уже готовый кусок для поддержки кому-нибудь ещё. И также с удовольствием пообщаюсь с коллегой если он сможет сообщить мне что-то новое.
-2
Согласен. Но если так как вы написали вы же наверное не будете спрашивать глупые вопросы о алгоритмах не относящихся к вашему проекту. Но большинство все же воспринимают работу как обычную рутину, поэтому и возникает то что написал автор
+3
вы же наверное не будете спрашивать глупые вопросы о алгоритмах не относящихся к вашему проекту
Вопросы об алгоритмах, которые появляются на интервью это не какие-то специальные знания, это таблица умножения. Не знаю никого, кто на интервью спрашивает что-то серьёзное. Только самые элементарные вещи. Надо отличать квадратичную сложность от логарифмической, уметь обойти граф и понимать, как хэш таблицы работают.
+1
когда до компаний дойдет, что для них, вообще-то важно, кто у них работает

Почему вы считаете себя умнее крупных компаний с миллиардными прибылями?
Не логичнее ли посмотреть с их стороны и наконец-то осознать, что для них, вообще-то, неважно, кто у них работает?
-1
А почему бы и нет? Сегодня у твоей компании миллиардная прибыль, а завтра ты вылетаешь в трубу (привет, условный Кодак).
+3
корпорации вылетают в трубу из-за неадекватности топ-менеджмента и неповоротливости крупных структур. причем почти все истории таких падений похожи друг на друга и ещё связаны с тем то зачастую контору валят свои-же акционеры которым плевать на то как там всё устроено.
==
по этому даже если в конторе работают супер-профи, это не гарантирует от банкротства… потому что пофиг кто там работает не на топ-позициях
-1
У Боинга тоже миллиардные прибыли были, теперь миллионные. Уже не говоря о тех людях, которых не вернуть из-за программной ошибки в 737м.
0
Это вы верно заметили, не забудьте, однако, что все лица, принимающие решения, не потеряли вообще ничего. Вот абсолютно. Даже копеечки. Все, кому нужно было уйти с золотыми парашютами — ушли с ними. Никаких штрафов, ничего не было.

А прибыли что… Ну были миллиардные, стали миллионные, потом опять миллиардными станут. Это мелочи жизни.

Вы вот никак не можете в абстракцию.

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

Я могу только повторит — в реальном мире неважно, кто там работает. Наймут таджиков, наймут китайцев, наймут дрессированную обезьяну, если это будет дешевле и позволит манагеру вот прямо сейчас, а не через двадцать лет, купить новую яхту.
+4
Я, в основном, согласен с автором и часто практикую как раз «поговорить о прошлых проектах». Тем не менее бывает кандидат нравится, рассказывает красиво, в самом конце задаю пройстейший вопрос по SQL просто для проформы, даже самому стыдно трачу всремя уважаемого человека и вдруг… поплыли… да еще как поплыли…
+6
Хуже, если это обнаруживаешь уже во время онбординга.
+1
Тем не менее бывает кандидат нравится, рассказывает красиво, в самом конце задаю пройстейший вопрос по SQL просто для проформы, даже самому стыдно трачу всремя уважаемого человека и вдруг… поплыли… да еще как поплыли…

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


сомневаюсь я чёто что просто по разговору можно не понять что собеседуемый — любитель поговорить.
при условии что собеседуем не на джуна и уж тем более не на миддла

p.s. помню мне вручили на собесе листок a4 и попросили написать какуюто большую штуку… у меня знатно тогда пригорело, поскольку я дословно нифига не помню название какихто методов и их параметры… интервьюверы тогда начали ржать типа «ты без инета и без ide обязан знать это всё!» причем собес был на сеньора…
+2
Я на самом деле тоже сомневался. А потом (когда участвовал в небольшом расширении команды) увидел их вживую — странных людей, которые очень складно рассказывают о прошлых задачах и решениях, но почему-то не пишут код уровня FizzBuzz. Вот реально — не пишут.

Я так до сих пор не понимаю, откуда они такие берутся.
0
которые очень складно рассказывают о прошлых задачах и решениях

но почему-то не пишут код уровня FizzBuzz

так достаточно спросить как бы вы написали такой код, не нужно писать его на бумажке, просто на словах
===
а про откуда такие берутся, собственно тут двоякая ситуация. Я например однажды попал в интересную контору, где общий уровень архитектуры и вообще программинга несколько ниже моего (в абсолют был возведен 'чем проще тем лучше'… вплоть до того что не проверялись ошибки в запросах, не чекалась безопасность, никогда не делался задел под расширение функционала даже если в ТЗ через две задачи от текущей оно тербовалось)… и получилось так что мой опыт рассказанный на собеседовании совершенно не применим и я выглядел как 'чел рассказывает складно, а работу делает неправильно' тупо потому что пишу микросервис с учетом всяких исключительных ситуаций, а на кодревью выпиливают 80% кода со словами 'это никому никогда не нужно, ты странный что так пишешь'
+2
так достаточно спросить как бы вы написали такой код

Ну так кодим-то мы на языке, а не на метаязыке приближенном к естественному. Я могу понять, когда при попытке накодить задачку уровня FizzBuzz на JS на бумажке (но лучше тут хотя бы nodepad кандитату дать, разумеется) кто-то не вспомнит оператор % или будет писать var вместо let/const, или переберёт массив банальным for, а не через reduce(). Это вообще не важно, важно — чтоб кандидат продемонстрировал самую базу того, чем он вообще-то будет на работе заниматься.

А вот когда словами поговорить — сколько угодно, а перейти в термины языка программирования — никак, то таких на работу брать как-то очень боязно. На работе-то на должностях software developer с IDE надо не русским языком говорить.
+1
интервьюверы тогда начали ржать типа «ты без инета и без ide обязан знать это всё!» причем собес был на сеньора…

Причём забери у них самих интернет и ide и тоже ничего написать не смогут. Тоже на таких пару раз попадал...

+1
По-моему, листочек А4 или доска — это самое лучшее во время собесов. Хуже когда дают какую-то Web IDE и тесты — и надо сразу написать, чтобы тесты проходили. На листочке если ты забыл какой-то метод, то сразу можно прощупать, а не кретин ли проверяющий (как вышло в вашем случае), и если кретин — то сразу покинуть этот цирк.
0
Тем не менее бывает кандидат нравится, рассказывает красиво, в самом конце задаю пройстейший вопрос по SQL просто для проформы, даже самому стыдно трачу всремя уважаемого человека и вдруг… поплыли


О, у меня так было, вот в точности, как вы рассказываете.

Отлично побеседовали, потом мне задали вопрос, про CASE, и я ведь как раз его постоянно использовал на предыдущей работе, обрадовался, щас как расскажу, но просто тупанул и забыл, «поплыли поплыли». Не перезвонили, конечно.

И ведь, что характерно, в моих реальных задачах ничего не изменилось. Я как до этого его использовал, так и после его использую.

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

А там где я сейчас работаю, все довольны, потому что такого вопроса мне не задали, а на практике я всё делаю как надо.
НЛО прилетело и опубликовало эту надпись здесь
-2
Ага, а бывает и наоборот. Тебе дают задание, на которое сам собеседующий не может дать правильный ответ. Ну вот из недавнего, дают мне задачку «если число делится на 3, то вывести foo; если на 5, то buzz; если на 3 и 5, то foobuzz». Ну пишу эти примитивные условия подряд.
— Неправильно!
— Почему?
— А если 15?
— Ну тогда сработают все три условия.
— Ну вот и неправильно. Должно только последнее.
— Это ещё почему? Вот условие задачи. Код полностью ему соответствует. А уж что там подразумевал составитель задачи… Пишите тогда «если делится на 3, но не на 5»… Мы же всё-таки о программировании говорим. Дисциплине со строжайшей формальной логикой. Можно сколько угодно рассуждать о синтаксических особенностях, проблемах типизации и соответствующих трудностях поиска ошибок. Но если ведущий программист ставит тебе изначально некорректную задачу — то запаритесь потом такие ошибки искать.
+1
Я как-то устраивался, если не путаю в яндекс. Мне там дали задачку, уже не помню подробностей, нужно было вычислить что-то на основе массива данных. Я посидел, подумал, выдал ответ, задачка решалась тривиально, практически в одно действие. Парень, «на той стороне» сильно расстроился, сказал что придумывал ее несколько дней и ожидал что решать ее будут более сложным способом (дальше обговорили как он это видел), а мое простое решение он проглядел.
Правда все равно меня там прокатили… Но это уже совершенно другая история…
+3

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


Это из той же серии, что и союз "ИЛИ", который может означать как "OR", так и "XOR". Программист должен такие подвохи чувствовать и не стесняться переспрашивать в случае подозрений на некорректность задания.

+3
Про речь вам уже сказали, что никто не говорит «исключающее или».
Во-вторых вы сейчас понтуетесь тем что не поняли задачу.
Переводить втупую одни инструкции в другие это задача компилятора. Ошибка «я не подумал и не понял» простительна джуну, мидлы и сениоры должны не инструкции выполнять, а понимать что нужно сделать и зачем. И уточнить все возможные corner case, о которых заказчик задачи мог и не подумать.

Стыд!
-1
Чушь собачья! Если вы хотите взвалить на меня все эти функции вангования — платите тогда мне ставку топ-менеджера. Или что, вы по каждой поставленной вам задаче открываете диспут с менеджментом?
Задачу я понял. Задача довольно простая и сформулирована вполне ясно. То, что формулирующий вкладывал в неё иной смысл — проблемы формулирующего. Или это нормальная практика — взваливать на подчинённых ответственность за собственные ошибки? Ну тогда нам точно не по пути! А то пообмажутся некомпетентным менеджментом, а крайний всегда программист.
И к слову. Главное, чему меня научили в курсе школьной программы математики — это отвечать исключительно на поставленный вопрос к задаче. Додумывать, ходить вокруг да около конкретного ответа — это всё ошибки. Поэтому если вопрос к задаче подразумевает какие-то сложные выкладки, но сформулирован так, что требуется довольно простой однозначный ответ — этот ответ и надо давать. У меня были как раз подобные случаи — апелляция всё расставляла по своим местам.
Учитесь формулировать задачи, а не искать старого слепого болгарского программиста женского пола.
+2
А это действительно зависит от того на какую позицию вы устраиваетесь. Если на джуна, то конечно подобное «вангование» от вас ожидать не стоит. От миддла на мой взгляд уже можно ожидать, но не то чтобы обязательно. А вот если сениор в такой ситуации не задумался о том что формулировка может быть понята двояко и не уточнил что точно имеется ввиду, то я бы сказал что к нам на фирму такого человека скорее всего сениором бы не взяли…
-2
А тут двоякая позиция. Если мы говорим о должности «системного архитектора» — это такой звоночек. Что в случае косяков менеджмента, уважаемый, крайним будете вы.
Что уточнение задачи далеко не всегда возможно.
И вот эта превалирующая позиция, что работодатель предстаёт эдаким барином. Что это вы прежде всего нуждаетесь в работе, а не он в сотруднике. Я давно уже плюнул на подобную «концепцию». И если меня что-то не устраивает на этапе собеседования (в том числе и расхождение во взглядах на то, какие функции я должен исполнять по умолчанию) — то, конечно, разбегаемся.
+1
Ну как бы чёткой классификации «джун-миддл-сениор» не существует, тут я с вами соглашусь.
Но я бы сказал что в фирмах где мне приходилось работать от сениора уже ожидалось немного больше чем просто писать код. В том числе и подобные вещи.
-1
Т.е. ожидалось что разработчик станет помесью Ванги и Нострадамуса с телепатическими способностями?
+1
Ну как минимум что он подумает о том имеет ли поставленная ему задача какой-то смысл и нет ли где как минимум явных логических неувязок.
+1
Что в случае косяков менеджмента, уважаемый, крайним будете вы.
Что уточнение задачи далеко не всегда возможно.

Что значит "не всегда возможно"? Вы же вообще ее не уточняли, просто интерпретировали по-своему, и ваша интерпретация не совпала с интерпретацией человека, который вам задачу ставил.


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

-3
Вот кол, вот мочало… Почему-то все начинают вставать на позицию работодателя и прикрывать неумение формулировать задачи «проверкой на умение думать». Попасться на такую примитивную проверку может разве что школьник. И никакая это не проверка была. А косячное условие. Я прекрасно понимал какой ответ подразумевается, но сознательно сделал упор на некорректности условия.
А все эти «мы ожидаем от соискателя...» что он будет вести бухучёт, заниматься охраной офисных помещений и т.п. Оставьте.
Ещё раз — прекратите прикрывать собственные косяки «а это мы так тебя проверяли».
+1
Это вы похоже не понимаете что на собеседовании при приёме на работу программистом правильность решения тестовой задачи оченъ редко бывает единственным фактором на который смотрят. И я бы даже сказал что часто это скорее вторично.