Комментарии 714
Статья так и не отаетила на вопрос из заголовка :(
А по сути, лично я догадывался, что не все наниматели качественно нанимают, об этом же было море статей здесь.
думаю, в заголовке, речь об изоляции транзакций.
Так автор и не знает. В этом суть.
еще не забывайте, что некоторые ищут человека на бюджет, скажем (для простоты понимания) 100т. И приходит такой крутой спец, чье резюме выкраили из колуаров оффлайн баз хантинговые агенства. Знает язык с экосистемой, как он работает под капотом (много кто от нечего делать в исходниках лазит?), на все вопросы дает исчерпывающие ответы, идеальный кандидат. Но хочет 150. Или приходит такой вхожденец в айти. На собеседовании мычит, на что-то отвечает, о чем-то слышал, знает синтаксис языка. И хочет всего 70. Ну и что, что потом переделывать за ним все и тратить время на ревью — зато дешевле и в бюджет влезаем. Так что берем его. А там научится (нет).
Isolation — как правило, но в зависимости от контекста может быть и Intrusion, или еще чем-то.
Почему на хабре так много статьей с кликбейтными названиями и водой внутри, так и должно быть?)
Почему на хабре так много статьей с кликбейтными названиями и водой внутри, так и должно быть?)
Я за прошлый год проходил собеседования в несколько компаний и везде один и те же вопросы: какие паттерны программирования вы знаете, какие типы индексов существуют, как вы ищете затык в производительности, какая функция быстрее работает — эта или эта, и так далее.
Да, я много чего в своей работе использовал, для немалой части из этого я не знаю даже названия, но знаю, что оно лучше подходит в данной ситуации. А если есть проблема, для которой я не знаю сходу решения — всегда можно изучить вопрос и найти это решение.
Только одно собеседование кардинально выделялось из общей массы, разговор шел тет-а-тет с техдиром, он распросил с какими технологиями я работал, а потом мы разговаривали про различные проблемы на их проекте и на моих прошлых проектах, и как эти проблемы решались или можно решить. Это был увлекательный полуторачасовой разговор, после которого мне предложили работу с хорошей зарплатой.
Да, я много чего в своей работе использовал, для немалой части из этого я не знаю даже названия, но знаю, что оно лучше подходит в данной ситуации. А если есть проблема, для которой я не знаю сходу решения — всегда можно изучить вопрос и найти это решение.
Только одно собеседование кардинально выделялось из общей массы, разговор шел тет-а-тет с техдиром, он распросил с какими технологиями я работал, а потом мы разговаривали про различные проблемы на их проекте и на моих прошлых проектах, и как эти проблемы решались или можно решить. Это был увлекательный полуторачасовой разговор, после которого мне предложили работу с хорошей зарплатой.
Всегда спрашивал кандидатов, что они делали раньше, как они могут об этом рассказать. Исходил из пословицы: «Кто ясно мыслит — тот ясно излагает».
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.» Тут сразу отлетают те, кто сдавал по «не своему» диплому. От таких людей в производстве (тех же программ) проку немного — ведь причин для неписания диплома при окончании ВУЗа только две: лень или неумность. Есть еще презрение к навязанной практике обучения — такой работник и в подразделении будет идти наискосок (если не в обратном направлении).
Если наниматель отбирает кандидата по узкому/широкому набору знаний, востребованному в данной конторе здесь и сейчас, игнорируя его прошлый опыт, то речь идет об одной задаче, а что делать потом, наниматель и сам толком не знает.
А ведь потом придется переучиваться всей конторе :)
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.» Тут сразу отлетают те, кто сдавал по «не своему» диплому. От таких людей в производстве (тех же программ) проку немного — ведь причин для неписания диплома при окончании ВУЗа только две: лень или неумность. Есть еще презрение к навязанной практике обучения — такой работник и в подразделении будет идти наискосок (если не в обратном направлении).
Если наниматель отбирает кандидата по узкому/широкому набору знаний, востребованному в данной конторе здесь и сейчас, игнорируя его прошлый опыт, то речь идет об одной задаче, а что делать потом, наниматель и сам толком не знает.
А ведь потом придется переучиваться всей конторе :)
Мне бы про свой диплом было банально стыдно рассказывать) Убогое поделие на 1с которое 1сник с опытом сваяет за пару-тройку вечеров, да еще и текст диплома на 90% из воды)))
Мой диплом тоже «поделие», которое опытный программер сейчас сваяет, даже не заметив. Но это из-за развития технологий — в тот момент, когда оно писалось — там это было как минимум задачкой на подумать, даже для опытного спеца.
Дипломная работа и не должна быть какой-то прорывной и инновационной. Это просто обычная инженерная задача, которая демонстрирует, что вы выучились на обычного инженера и способны с ней справиться.
Всегда считал, что в дипломе должно быть новшество, в нём даже такой раздел есть, где пишешь, что нового было придумано.
Это же студент пишет, там ВСЕ для него новое.
Некоторое новшество свойственно всему, что делает инженер, потому что иначе его задача решается закупкой чего-то, что уже ранее было создано.
Такой диплом у нас требовали в магистратуре, а в бакалавриате и специалитете всем было до одного места…
А что делать если что не новшество то легко гуглится? Уже не инженер?
Это не так последних наверное лет 40. Что бы это понять нужно побеседовать со своими профессорами. В лучшем случае можно получить рацуху, но это уровень уже не студента, т. к. требует внедрения. Второй путь более распространённый это диплом как основа кандидатской. Но оба варианта это единицы работ, даже не проценты. Пересчитываются по пальцам.
Студенческие дипломы с рацухой от работающих студентов — это вполне обычное явление. Вот только: качество… пожалуй лучше умолчать, новизна отсутствует как класс, аналоги притянуты за уши, ибо реальной причиной является «насяльника сказала делать так», код… если соблюдают кодстайл, то код уже автоматом отличный. Помимо всего прочего, проект все еще на стадии разработки, а то и проектирования, т.к. всегда найдут более важные задачи для такой полезной трудовой единицы, как студент-дипломник.
Магистерские работы — полностью аналогично, за очень редким исключением.
Диплом как основа кандидатской? Это вообще очень редкий зверь. Тут студентов на магистра затаскивают чуть ли не насильно, ибо большинство понимает, что оно нафиг никому не нужно. Так что таким занимаются обычно те, кто целенаправленно готовится к эмиграции.
PS. Уже лет 7 в ГЭК:)
Магистерские работы — полностью аналогично, за очень редким исключением.
Диплом как основа кандидатской? Это вообще очень редкий зверь. Тут студентов на магистра затаскивают чуть ли не насильно, ибо большинство понимает, что оно нафиг никому не нужно. Так что таким занимаются обычно те, кто целенаправленно готовится к эмиграции.
PS. Уже лет 7 в ГЭК:)
ГЭК?
Вам не кажется, что сама по себе идея — ожидать реальное полезное рацпредложение от студента, который позавчера пришёл на практику и только-только разобрался, в чём состоит работа и задача — это нечто утопическое? Может быть в далекие времена, когда инженеры были редкой уважаемой птицей, могло быть такое, что на практику типа прислали студента и он что-то придумал, до чего вокруг никто не додумался, но сегодня… Очень сомневаюсь.
Да собственно ничего утопического. Заочники поголовно работают, многие даже по специальности. Да и среди очников попадаются те, кто работает уже год-два. И если ты не водпресс-манки в мелкой студии, то особых проблем ни с темой, ни с новизной быть уже не должно. Но в реале приносят дипломник в MS Access со справкой о внедрении и лютым говнокодом внутри.
Впрочим мой опыт был еще жестче: пришел на работу за пол года до защиты, получил аппаратуру, ноут и приказ подружить это все. Что получилось, уже проходило по всем критериям новизны и отличия от аналогов, правда на диплом я выбрал еще более амбициозный проект, но это уже совсем другая история.
Впрочим мой опыт был еще жестче: пришел на работу за пол года до защиты, получил аппаратуру, ноут и приказ подружить это все. Что получилось, уже проходило по всем критериям новизны и отличия от аналогов, правда на диплом я выбрал еще более амбициозный проект, но это уже совсем другая история.
Вот честно — уже 5 лет работаю но у меня даже близко нет идей что можно придумать нового что не будет банальной компиляцией из давно придуманных идей, а то и вовсе аналогом чего то уже сделанного другими в лучшем случае просто с другим сочетанием плюсов и минусов.
Какую нибудь библиотеку — так их уже сотни тысяч на любой вкус и идея в любом случае новизной блистать не будет. Фреймворк — аналогично, да и за ограниченное, довольно небольшое время дальше прототипа особо не уйдешь. Какую нибудь законченную систему — так где тут новизна (если это не разработка какого нибудь альфа-го, но боюсь если мы будем такие требования к студентам предъявлять у нас вузы будут заканчивать единицы на всю страну)
Какую нибудь библиотеку — так их уже сотни тысяч на любой вкус и идея в любом случае новизной блистать не будет. Фреймворк — аналогично, да и за ограниченное, довольно небольшое время дальше прототипа особо не уйдешь. Какую нибудь законченную систему — так где тут новизна (если это не разработка какого нибудь альфа-го, но боюсь если мы будем такие требования к студентам предъявлять у нас вузы будут заканчивать единицы на всю страну)
А с чего вы взяли, что банальная компиляция из идей, которую еще не реализовали на вашем используемом стеке/фреймворке/CMS/языке, нельзя использовать? Дипломная работа же не научная, у нее критерии новизны намного проще. А если вы придумаете что-то уникально новое в своей сфере, то это уже уровень диссертации будет.
Так что любой проект уровня мелкой вспомогательной либы на гитхабе — это уже вполне достаточно. Проект Скайнета от студента никто не ждет и не требует.
Так что любой проект уровня мелкой вспомогательной либы на гитхабе — это уже вполне достаточно. Проект Скайнета от студента никто не ждет и не требует.
Ну так мы обсуждаем текущие требования по которым в принципе и поделие на MS Access/1с сойдет за дипломную работу, либо же гипотетические? И где та граница?
Поделие MS Access не блещет даже мнимой новизной, качеством исполнения, полезностью или соответствию законодательству. Но на все есть распоряжение ректора: студентов на дипломе не резать:)
Так что гипотетически большая часть текущих дипломных работы не должна проходить ГАК, от слова вообще. Практически же защищаются даже с синдромом дауна (без шуток, реальный случай), когда не то, что диплом сделать, а даже речь прочитать не может. Но за счет одного дауна учится пара бюджетников, так что рыночная экономика в действии.
Но попадаются и нормальные работы. Даже АРМы с сайтами бывают вполне нормального уровня оформления, где защищают не «я сделал <название из темы>», а фактически отдельные модули, которые пилили или допиливали сами.
А граница проста: студент должен продемонстрировать полученные навыки, но в тоже время не должен делать полную копию чего либо.
Так что гипотетически большая часть текущих дипломных работы не должна проходить ГАК, от слова вообще. Практически же защищаются даже с синдромом дауна (без шуток, реальный случай), когда не то, что диплом сделать, а даже речь прочитать не может. Но за счет одного дауна учится пара бюджетников, так что рыночная экономика в действии.
Но попадаются и нормальные работы. Даже АРМы с сайтами бывают вполне нормального уровня оформления, где защищают не «я сделал <название из темы>», а фактически отдельные модули, которые пилили или допиливали сами.
А граница проста: студент должен продемонстрировать полученные навыки, но в тоже время не должен делать полную копию чего либо.
Как я уже упоминал в этой ветке: любая инженерная работа в какой-то степени содержит новизну, иначе в ней нет смысла. Речь же в данном случае о том, что раньше в дипломе ожидали каких-то значимых рационализаций, на уровне «Иван Петров, пока проходил практику на нашем заводе, внедрил автоматизацию в цеху продольно-поперечного проката, в результате чего выход готовой продукции „на гора“ вырос на 12.4%».
Мне кажется, раньше ситуация была другая: в институте людям давали знания, которых, вероятно, реально не хватало где-то на местах. А сейчас что такого может сделать студент, что реально не сделали люди, у которых он проходит практику и делает дипломную работу? Такое возможно, но маловероятно.
Поэтому хороший диплом, по крайней мере у разработчиков, — это качественное решение нормальной добротной задачи, с подробным описанием и оценкой экономической пользы.
Мне кажется, раньше ситуация была другая: в институте людям давали знания, которых, вероятно, реально не хватало где-то на местах. А сейчас что такого может сделать студент, что реально не сделали люди, у которых он проходит практику и делает дипломную работу? Такое возможно, но маловероятно.
Поэтому хороший диплом, по крайней мере у разработчиков, — это качественное решение нормальной добротной задачи, с подробным описанием и оценкой экономической пользы.
Любая выполенная на рабочем месте задача оказывает экономический эффект. Новая либа для работы с CSV — -1 час трудозатрат на работу с этими файлами для каждого разработчика, и т.п. Значимых рацпредложений от студента никто никогда не ждал. Вспомните даже старую поговорку: теперь забудте все, чему вас учили, будем учиться работать.
Потому хороший диплом у разработчика: качественное решение ЛЮБОЙ задачи. А оформление и экономическую пользу все равно заставят допилить во время оформления диплома, было бы что оформлять.:)
Потому хороший диплом у разработчика: качественное решение ЛЮБОЙ задачи. А оформление и экономическую пользу все равно заставят допилить во время оформления диплома, было бы что оформлять.:)
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.» Тут сразу отлетают те, кто сдавал по «не своему» диплому.
Спасибо, пополню свою личную копилку — это и правда отличный вопрос. Кто делал самостоятельно, тот и через 20 лет вспомнит как минимум основное, а кто не сам — того и через пяток лет вопрос уже в полный тупик поставит.
Хм, у меня тема диплома (на самом деле диссертации, но не суть) прямо в CV написана, под пунктом об образовании. Если работа по профилю образования, то это отличное приглашение нанимающего к разговору и вопрос, на который собеседуемый точно знает ответ)
А также сразу отлетают те кто диплом получал лет двадцать назад.
А так же порождает вопрос: зачем меня вообще про диплом спрашивают? Как это к работе относится? )
Я получал свой диплом 17 лет назад, и вкратце о нём спокойно расскажу — то, что ты сам руками полгода пилил, так просто не забывается.
Еще как забывается. Не забывается только если ты после этого больше вообще ничего не делал! Бывает открываешь какой-то класс годичной давности, а там… «Что это за говно? Кто вообще так умудрился?» Смотришь аннотации — а это ты и писал о_О
Наверное, сильно зависит и от человека, и от эмоций. Я вряд ли вспомню бОльшую часть из тонн кода, что я написал за свою жизнь. Но вот свой диплом 20 лет назад я помню очень даже неплохо, и про что, и как софтина работала, и как защищал.
Все что я помню про свой диплом — что код был сплошным говнокодом. Ибо прогаммирование я как раз примерно в том году начинал осваивать. Хотя это было в 2014 году. Защитная реакция психики, неприятные воспоминания забываются.
НЛО прилетело и опубликовало эту надпись здесь
Я уже спустя месяц после сдачи даже не помнил какая тема диплома была) хотя делал всё сам и с интересом.
Двадцатилетие моего диплома ещё не наступило, но уже недалеко. И я его помню. Потому что он был рожден лично и в муках. Детали, конечно, уже не расскажу, но в общих чертах — вообще без проблем.
Я даже помню дипломы пары-тройки однокурсников — у кого темы были мне интересны.
Я даже помню дипломы пары-тройки однокурсников — у кого темы были мне интересны.
Их ещё раньше отсеют. По возрасту.
Они отлетают по другой причине — работодатели считают их старыми.
А диплом-то как раз многие в таком возрасте помнят гораздо лучше, если вы понимаете о чем я.
Да, для статистики, моему диплому куда больше 20 лет, и я в состоянии много чего оттуда воспроизвести.
А диплом-то как раз многие в таком возрасте помнят гораздо лучше, если вы понимаете о чем я.
Да, для статистики, моему диплому куда больше 20 лет, и я в состоянии много чего оттуда воспроизвести.
Ну двадцать лет ещё не совсем прошло, но свой диплом я помню. И поговoрить о нём могу с удовольствием. Но не сказал бы что это особо поможет работодателю понять какой я сейчас разработчик.
То естъ первые года два-три такой вопрос наверное ещё имел смысл, а вот потом уже наверное лучше про более-менее актуальные проекты спрашивать.
Это позволяет лучше понять, что вы сейчас за человек, как-то прощупать социальные скиллы, понять, подходит ли он по духу (если это конечно нужно в вашей компании).
Разговор про диплом — это возможность услышать как будущий сотрудник рассуждает о вещах, не связанных с работой, о том, как он относится к тому, что делал раньше, как относится к вузу, который закончил и так далее.
Разговор про диплом — это возможность услышать как будущий сотрудник рассуждает о вещах, не связанных с работой, о том, как он относится к тому, что делал раньше, как относится к вузу, который закончил и так далее.
Поясните, отчего попытка объяснить что-то про диплом приводит к минусованию комментария? Просто интересно, что это, какая-то культурная несовместимость?
Процесс написания диплома 20 лет назад позволяет лучше понять, что вы сейчас за человек?
Диплом — это хорошо. Я свой диплом (10 лет назад было) писал примерно неделю, и параллельно взял первый свой «левый» диплом на заказ (это был диплом для студента НГТУ, Новосибирского тех.университета). Писал всё руками, даже картинки нарисовал все в Paint'е попиксельно, антиплагиат работ зашкалил. С тех пор примерно раз в год беру какой-нибудь диплом на заказ, чтобы голова не тупела, и делаю так же хорошо; как для себя. Для интереса ввязываюсь в области, с которыми напрямую не знаком, или пытаюсь закончить в рекордные сроки. Последние несколько штук за день написал с нуля. С таким подходом в любом дипломе каждая строка текста — «родная». Только как это поможет? У меня диплом об образовании почти нигде не спрашивали(а там есть что показать), не то чтобы про мою дипломную работу.
Но не сказал бы что это особо поможет работодателю понять какой я сейчас разработчик.
Говорить про это долго и подробно едва ли имеет смысл. А вот просто узнать, помнит ли вообще соискатель про свой диплом — это вполне. Если не помнит — это звоночек. Слишком серьезно на этом зацикливаться не стоит, для найма важны другие вещи, но как фактор отсева в ситуации «прочих равных» — вполне сгодится. То, что человек ничего не может сказать про свой диплом — ни о чём хорошем не говорит.
Кто делал не сам, тех прямо на защите в тупик ставят.
Вы слишком оптимистичного мнения о нашем образовании.
Сделал с десяток дипломов на заказ, у всех студентов были пятерки, я всегда уточнял ради интереса. Последняя дипломная подытожила красный диплом заказчику. Один раз только четверка была — знакомый обратился за сутки до сдачи и просто не успел всё выучить, и плавал в материале
Как у людей про диплом пригорает, аж минусят. Я свой диплом до сих пор помню и рассказать всё могу. Автоматизация очистных сооружений с написанием софта в ПЛК и визуализацией.
НЛО прилетело и опубликовало эту надпись здесь
Кто не сам, того вопрос поставит в тупик даже сразу после защиты (не говоря уже про вопросы на защите).
А кто сам, то спрашивать надо: что вы сделали не так в своей дипломной работе? Правда с определенного момента ответ будет только один: все.
А кто сам, то спрашивать надо: что вы сделали не так в своей дипломной работе? Правда с определенного момента ответ будет только один: все.
НЛО прилетело и опубликовало эту надпись здесь
На собеседовании было бы интересно послушать, как человек об этом будет рассказывать.
Так и запишем, работодателю ваш диплом нужен для того, чтобы на собеседовании послушать, как интересно вы будете о нем рассказывать.
Видимо больше «хорошему» кандидату рассказать не о чем.
Видимо больше «хорошему» кандидату рассказать не о чем.
Откуда такие выводы? Вроде никто ничего подобного не утверждает.
Диплом, если и нужен работодателю, то только для того, чтобы закрыть нужные требования по лицензиям/тендерам. А на собеседовании — это просто тема для разговора.
Диплом, если и нужен работодателю, то только для того, чтобы закрыть нужные требования по лицензиям/тендерам. А на собеседовании — это просто тема для разговора.
«Какая твоя любимая пони?» тоже тема для разговора. Но на собеседовании она будет не очень уместна. Собеседование — это все-таки не беседа в баре с друзьями.
Именно поэтому диплом — вполне нормальная смежная тема, а «любимая пони» — не особо.
Ну вот тема моего диплома — адаптивный фильтр Калмана-Бюси. Там чистый матан и к программированию всё это относится крайне отдаленно.
Я бы спросил, что это, из какой области (выяснил бы, что вы занимались теорией управления и статистическими методами, а это уже полезные смежные знания для разработчика). Спросил бы, как это можно применить, и была ли какая-то прикладная часть в дипломе (что именно адаптивного, получается, было приделано).
Это своего рода обмен ролями, потому что вы пробуете пообщаться на территории, где кандидат чувствует себя увереннее и комфортнее, потому что почти наверняка знает об этой теме гораздо больше, чем собеседующий.
И как я уже говорил в другой ветке, если кандидату не хочется об этом рассказывать, видно что ему всё это не нравится — не надо его форсить, просто отметить для себя его нежелание делиться чем-то, что выходит за пределы задачи.
Это своего рода обмен ролями, потому что вы пробуете пообщаться на территории, где кандидат чувствует себя увереннее и комфортнее, потому что почти наверняка знает об этой теме гораздо больше, чем собеседующий.
И как я уже говорил в другой ветке, если кандидату не хочется об этом рассказывать, видно что ему всё это не нравится — не надо его форсить, просто отметить для себя его нежелание делиться чем-то, что выходит за пределы задачи.
А с какой целью вы все перечисленное хотите выяснить? Область деятельности будущего сотрудника связана со всем этим или просто чтобы было?
И вот эти разговоры из разряда «чтобы было» больше всего раздражают.
Зачем высправшивать человека об особенностях сортировки деревьев, например, если его собеседуют на должность разработчика ПО для микроконтроллеров и ни один здравомыслящий разработчик применит готовое библиотченое решение, а не займется созданием собственного велосипеда с треугольными колесами?
И вот эти разговоры из разряда «чтобы было» больше всего раздражают.
Зачем высправшивать человека об особенностях сортировки деревьев, например, если его собеседуют на должность разработчика ПО для микроконтроллеров и ни один здравомыслящий разработчик применит готовое библиотченое решение, а не займется созданием собственного велосипеда с треугольными колесами?
Вот как раз на микроконтроллерах готовых библиотечных решений по балансированным деревьям очень негусто. И впрямую применить что-то из «общепринятого» кода из интернета тоже не получается — API не те, не лезут в мелкий эмбеддед (в применении к чужим реализациям деревьев как раз очень иллюстративно получается: я не видел пока ни одной чужой реализации балансированных деревьев, которая не хочет памяти из кучи).
Да и вообще, как эмбеддер говорю: не надо в эмбеддеде бояться треугольных колес.
Да и вообще, как эмбеддер говорю: не надо в эмбеддеде бояться треугольных колес.
Вопрос то в том, нужен этот самый велосипед или нет. Часто ли на микроконтроллере двигателя нужно сортировать деревья? Мне лично подобным заниматься не приходилось.
Именно сортировать — не приходится, так как балансированное дерево уже само по себе сортированное в любой момент времени :)
А если речь идет вообще о применении деревьев в микроконтроллерных проектах — ну, иногда приходится. Я вот сейчас страдаю от того, что в свое время не довел до ума свою пригодную для микроконтроллеров реализацию андерсоновских деревьев, без них приходится думать о производительности в одном критичном модуле, где с деревьями думать было бы не надо. Возможно, даже придется таки доделать эти деревья, там глючил только один краевой случай перебалансировки при удалении.
А если речь идет вообще о применении деревьев в микроконтроллерных проектах — ну, иногда приходится. Я вот сейчас страдаю от того, что в свое время не довел до ума свою пригодную для микроконтроллеров реализацию андерсоновских деревьев, без них приходится думать о производительности в одном критичном модуле, где с деревьями думать было бы не надо. Возможно, даже придется таки доделать эти деревья, там глючил только один краевой случай перебалансировки при удалении.
А в чём проблема перегрузить оператор new, и выделять память для узлов дерева не из кучи, а из отдельного пула? Тогда можно пользоваться реализацией из STL, и никаких велосипедов. Правда, самому мне так делать не доводилось, потому что необходимости не было.
Проблема в том, что этот пул тоже надо создать, и знать заранее его размер (и, скорее всего, отдельно обрабатывать ситуации, когда объект для вставки в дерево есть, а под управляющую структуру памяти в пуле уже нет).
А можно от всего этого bloat-а уйти, если управляющие структуры просто с собой таскать, в стиле структур из линуксового ядра: подструктура в качестве управляющей структуры, и container_of() для получения «прикладного» элемента по указателю на управляющую структуру. Заодно решаются всякие сложности со вставлением одного и того же «прикладного» элемента в несколько разных контейнеров — получается лаконично и запутаться сложно.
А можно от всего этого bloat-а уйти, если управляющие структуры просто с собой таскать, в стиле структур из линуксового ядра: подструктура в качестве управляющей структуры, и container_of() для получения «прикладного» элемента по указателю на управляющую структуру. Заодно решаются всякие сложности со вставлением одного и того же «прикладного» элемента в несколько разных контейнеров — получается лаконично и запутаться сложно.
А вы попробуйте разговорить интроверта :) Особенно когда сразу видно — человек адски зажат от самого факта собеседования. И только от его любимой темы можно хоть как то перейти к собственно профессиональному разговору. Например, попросить перечислить виды и семейства этих пони и попросить спроектировать структуру данных для хранения описаний. Или интерфейс для сайта по обмену мнениями об оных…
Может это со мной что-то не так, но я бы нахрен свалил после пары таких вопросов. Работодателя касаются только мои профессиональные навыки, остальное — это не его дело.
Если собеседующий не может адекватно оценить профессиональные качества по ответу на какой-либо вопрос, то его просто не нужно задавать. Потому что просто игнорировать какую-то информацию крайне сложно, и в итоге на решение собеседующего будет влиять заведомо неадекватная оценка. Так зачем искусственно вносить такие искажения? Я уж молчу, что собеседующий тратит время кандидата подобными вопросами «за жизнь».
Если собеседующий не может адекватно оценить профессиональные качества по ответу на какой-либо вопрос, то его просто не нужно задавать. Потому что просто игнорировать какую-то информацию крайне сложно, и в итоге на решение собеседующего будет влиять заведомо неадекватная оценка. Так зачем искусственно вносить такие искажения? Я уж молчу, что собеседующий тратит время кандидата подобными вопросами «за жизнь».
Профессиональные навыки не работают в офисе сами по себе, они всегда прилагаются к человеку, которому нужно будет общаться с коллегами.
Крайне редко где производственный процесс выстроен и отлажен таким образом, что люди действительно контактируют друг с другом только «профессиональными навыками».
Именно поэтому, как тут уже кто-то отмечал, компании ищут работника, который впишется в корпоративную культуру — и это едва ли не так же важно, как его умение кодить.
В этом смысле, тот факт, что вы бы свалили после таких вопросов — это удачное завершение собеседования с обеих сторон.
Крайне редко где производственный процесс выстроен и отлажен таким образом, что люди действительно контактируют друг с другом только «профессиональными навыками».
Именно поэтому, как тут уже кто-то отмечал, компании ищут работника, который впишется в корпоративную культуру — и это едва ли не так же важно, как его умение кодить.
В этом смысле, тот факт, что вы бы свалили после таких вопросов — это удачное завершение собеседования с обеих сторон.
НЛО прилетело и опубликовало эту надпись здесь
Ого, тоже моделировал этот вопрос, но для сверхкритической хроматографии, бывает же)
НЛО прилетело и опубликовало эту надпись здесь
У меня путь более прямой) учился на факультете кибернетики в РХТУ и на дипломе начал моделировать диффузию в пористых телах. Потом продолжил тему в кандидатской — вот в качестве интересующего процесса, где была бы и диффузия и адсорбция в сверхкритической среде и в пористом теле взяли сверхкритическую флюидную хроматографию. Научная группа плотно занимается изучением таких вещей, вот и выдали мне расчетный комп с GPU, так что я ещё в 2008 начал писать на CUDA, ещё на релизе 2.3, кажется. На моей кафедре программирование давалось нормально: каждый семестр был один предмет на новом ЯП, так что диплом/кандидатскую писал на С/С++ и питоне — хорошее было время) И задача интересная, и в лаборатории побывал и в целом с людьми хорошими пообщался, про HPLC в том числе)
А если диплома нет?
Если человек заявил, что имеет законченное во и при этом нет диплома, это наводит на нехорошие мысли.
У меня высшее. Плюс интернатура, ординатура и аспирантура. А диплома не было) И курсовых не было)
Как так?
А вас слова "интернатура, ординатура" не настораживают? У человека не инженерное высшее. Он, насколько я понимаю, на врача учился (именно оттуда возникают "интернатура, ординатура"). Вот за аспирантуру — не скажу, там можно было и по другой линейке пойти, но там один фиг диплома не будет. В случае успеха там делается и защищается диссертация, а получается степень — к(*)н.
У врачей нет всего этого)
Представил:
"А зачётной работой была операция по удалению у (не знаю как у медиков, но предположу вымышленную версию) поросёнка опухоли, примерно в том месте где вы пару минут назад чесали затылок… "
… далее звук падения со стула hr…
:)
Не везде дипломная работа — это часть степени. У меня первая израильская, math & CS, двадцатилетней давности, без диплома.
Вот просто даже интересно, а если человек диплом не писал? Ну вот закончил медицинский институт, а потом ушел в другое направление и уже, как минимум, не писал диплом?
Ну, у меня два друга вообще без вышки работают программистами, с исключительно ясным и системным мышлением. Такого уровня программистов даже с вышкой надо ещё постараться найти. Один из них написал для других 3 или 4 диплома.
Хотя и им образование было бы не лишним — алмазы требуют огранки.
Хотя и им образование было бы не лишним — алмазы требуют огранки.
Хотя и им образование было бы не лишним — алмазы требуют огранки
научится следовать маразматическим требованиям и сдавать зачеты по устаревшим дисциплинам?
p.s. шучу конечно, но как говорится в каждой шутке есть доля…
Ну у меня так — я с 4го курса ушёл от скуки. Написал половине группы дипломы потом, сам так и не получил вышки. Из всей группы программистом работаю я один
Огранки — «оквадрачивания»? :)
Тогда послушать насколько интересно они об этом расскажут
В конце 90х у студентов ехСССР еще был выбор- пишешь диплом или лишний ГОСэкзамен.
Меня лично до диплома не допустили так как в нашем областном центре не нашлось 3 специалистов для написания рецензии по данному вопросу, а с коллегами из соседних ВУЗов региона наши спец-ы разругались вдрызг.
Меня лично до диплома не допустили так как в нашем областном центре не нашлось 3 специалистов для написания рецензии по данному вопросу, а с коллегами из соседних ВУЗов региона наши спец-ы разругались вдрызг.
Ваше мнение не понравилось людям, слишком уж вы радикально говорите о тех, кто не может про свой диплом рассказать. Но сути не меняет, я с вами согласен. Вопрос про диплом очень даже хорошо смотрится на собеседовании. Притом, он не только раскрывает собеседуемого, он еще и может кое что рассказать про собеседующего. Был на собесе, где тех. спец. загуглил тему моего диплома, почитал про суть, и некоторое время поддерживал со мной разговор на эту тему. Для меня это хороший знак, компания дает возможность своим спецам подготовиться к собесу, а спецы заинтересованы взять человека c широким кругозором и нормальным образованием
НЛО прилетело и опубликовало эту надпись здесь
А у меня образование — провизор по специальности фармация, и вместа диплома госы. Свои стандарты, диплом только отличникам давали писать. При этом, работаю, начальство довольно.
Лень, нетерпение и самомнение — три главных добродетели программиста. © Ларри Уолл
Проектирование плавучей судовой ядерной энергоустановки мощностью 60 МВт.
Поговорим?
Поговорим?
Танковый балвычислитель.
Почему бы и не поговорить :)
Обменяемся секретиками.
"Если диплома нет" — как уже сказали, "звоночек" и требует от собеседующего смены алгоритма.
Работал с тремя хорошими программистами ( по делам их судите их): с профильным образованием, со смежным (радиоэлектроника, там программирование преподавали), и без образования (диплом получил потом в филиале вуза, знал больше преподов, но корочки в СНГ очень помогают). Разные бывают пути в профессию, — а вы ждали более оригинального?
Это диплом, студенческий? Какой ВУЗ?
ИМХО, крутовата тема для всего лишь диплома. Даже дисер — и то слишком общо.
Больше похоже на монографию. Или мемуары.
ИМХО, крутовата тема для всего лишь диплома. Даже дисер — и то слишком общо.
Больше похоже на монографию. Или мемуары.
Диплом, студенческий, специалиста. СПбГМТУ.
Конечно, уже 6 лет прошло после защиты, но диплом был основательный. Расчёт размеров конструкций: от самого блока до ТВЭЛов; какие хим.элементы будут использоваться как топливо; как реализуются контура; чертежи-чертежи-чертежи…
Скажу так: мало мне не показалось, благо — преподаватель смог заинтересовать и всячески помогал и принимал участие.
Только вот незадача: к разработке ПО — это не имеет никакого отношения. Но если посмотреть с другой стороны, то это показывает то, что если я с этой темой разобрался и смог защитить диплом, то наверное и с веб-проектом условного интернет-магазина я тоже смогу справиться.
Конечно, уже 6 лет прошло после защиты, но диплом был основательный. Расчёт размеров конструкций: от самого блока до ТВЭЛов; какие хим.элементы будут использоваться как топливо; как реализуются контура; чертежи-чертежи-чертежи…
Скажу так: мало мне не показалось, благо — преподаватель смог заинтересовать и всячески помогал и принимал участие.
Только вот незадача: к разработке ПО — это не имеет никакого отношения. Но если посмотреть с другой стороны, то это показывает то, что если я с этой темой разобрался и смог защитить диплом, то наверное и с веб-проектом условного интернет-магазина я тоже смогу справиться.
Собственно вопрос вот в чем: неужели вчерашний студент (пусть даже и с преподавателем) в состоянии спроектировать такой объект? или руководить проектными работами? Мне почему-то кажется, что это роль для ГК с 30летним опытом и коллектива человек в 300. Результат нескольких лет работы в виде чертежей и техдока надо будет везти на… газели хотя бы.
А такого рода диплом — просто дайджест, не больше.
Просто есличо — я тоже, бывает, нанимаю, и нередко спрашиваю про диплом, поскольку с детства интересуюсь разными техническими штуками. Опытом работы на заводах тоже живо интересуюсь.
И (говорю вообще, не о вас конкретно) это сразу большой минус, если человек не понимает реального значения своего диплома.
А такого рода диплом — просто дайджест, не больше.
Просто есличо — я тоже, бывает, нанимаю, и нередко спрашиваю про диплом, поскольку с детства интересуюсь разными техническими штуками. Опытом работы на заводах тоже живо интересуюсь.
И (говорю вообще, не о вас конкретно) это сразу большой минус, если человек не понимает реального значения своего диплома.
В таких ситуациях "дьявол прячется в деталях", и в общем, на мой взгляд, тут есть некоторое пересечение с ИТ, когда сначала "набрасывают" прототип, разделяют на блоки и доводят идею до реального продукта который можно применять, просто у АЭС и т.п. деталей намного больше и технический долг недопустим :)
(В конторе по разработке для АЭС работал, чертежи делал...)
Ну, хоть я и совсем не из этих тем, но миллион лет назад участвовал в одном хозрасчетном проекте с тегами радиационная, АЭС, система, контроль, безопасность. И еще довольно неплохо помню, сколько народу было задействовано там, а ведь это очень маленький кусочек целого проекта. Более того — необязательный: к тому моменту та конкретная АЭСка уже не один год успешно работала. Просто бесконтрольно :-) ну, точнее, контроль был неавтоматическим.
А тут — диплом! Вероятно, я чего-то не понимаю.
А тут — диплом! Вероятно, я чего-то не понимаю.
А такого рода диплом — просто дайджест
Это скорее эскизный проект — расчёт параметров, габаритов, общей компоновки, блочной схемы управления и регулирования, прикидочная оценка эффективности — всё это без детализации вплоть до каждой трубки, клапана, электродетали. Нормальная дипломная работа в областях, где своими руками что-то сделать недоступно по цене, поэтому остаётся только считать — это игровая ситуация: воображаем себя Главным Инженером, на вход которого подают ТЗ с требуемыми характеристиками, на выходе получается более-менее технически-обоснованный набросок, как это примерно будет выглядеть и сколько стоить, а скучные детали и производство горы документации отдаём сотрудникам помладше :)
А почему ядерной, а не атомной?
Для поиска технических специалистов может и норм вопрос, но скорее похоже на какую-то месть за то что вы писали свой диплом сами. К примеру для продаж я бы искал людей с высшим образованием которые бы ничего не знали о своем дипломе, но при этом помнили цвет глаз секретаря в приемной или ФИО рекрутера который направил их на собеседование.
P.S. Сразу уточню)) учился я ОЧЕНЬ плохо, в дипломе не написал ни строчки — прокрастинация наше все. Пока эту проблему не решил, продвинутся в своем развитие так и не получилось)) Но решил я ее уже после универа, спасибо психологам
P.S. Сразу уточню)) учился я ОЧЕНЬ плохо, в дипломе не написал ни строчки — прокрастинация наше все. Пока эту проблему не решил, продвинутся в своем развитие так и не получилось)) Но решил я ее уже после универа, спасибо психологам
Практика показывает, что это не совсем работает.
Точнее, на этом вопросе можно сорвать джекпот, потому как если человек действительно начинает увлеченно рассказывать про свой диплом, то это практически стопроцентно хороший специалист…
А вот противоположный вариант не значит практически ничего. Ну вот не захотел человек написать нормального диплома… Что это значит? Да ничего ровным счётом…
Точнее, на этом вопросе можно сорвать джекпот, потому как если человек действительно начинает увлеченно рассказывать про свой диплом, то это практически стопроцентно хороший специалист…
А вот противоположный вариант не значит практически ничего. Ну вот не захотел человек написать нормального диплома… Что это значит? Да ничего ровным счётом…
"Что это значит?"
Вариантов три (если есть во): лень, неумелость, презрение.
Самое важное забыли: которые были когда-то. Есть ли сейчас? А чёрт его знает, по этому вопросы вычислить невозможно.
Либо адекватный выбор средства для достижения определенной цели. Вам точно нужен специалист который для типовой формочки обратной связи прикрутит туда бота с ИИ для разработки которого попросит оплатить аренду кластера? Просто потому что он увлечен и ему интересно? Диплом может быть реальным увлечением, а может быть просто средством закончить отношения с ВУЗом всех устраивающим способом. Посредственный диплом не говорит вообще ничего. Особенно если вы не в курсе как в этом заведении вообще учат и чему.
Ещё есть куча вариантов. Например, родители в этот вуз запихнули, отучился для галочки
НЛО прилетело и опубликовало эту надпись здесь
Я буду считать это презрением.
Возможно, Ваш ВУЗ ещё за пару лет до поступления именовался техникумом ( причём не IT ориентации), или это был филиал, открытый в помещении музучилища (к примеру).
НЛО прилетело и опубликовало эту надпись здесь
Чем глубже приходится погружаться в ИТ, тем сильнее потребность в вузовских знаниях. Можно, конечно, учить самостоятельно. Вопрос в том, насколько удачно выйдет.
После вуза, на мой взгляд, проблема не столько в практическом опыте, сколько в опыте работы, как таковой. Потому что опыт программирования никто не мешает получить в пет-проекте, а вот опыт труда за деньги, и соответствующей социализации, вряд ли.
После вуза, на мой взгляд, проблема не столько в практическом опыте, сколько в опыте работы, как таковой. Потому что опыт программирования никто не мешает получить в пет-проекте, а вот опыт труда за деньги, и соответствующей социализации, вряд ли.
НЛО прилетело и опубликовало эту надпись здесь
Это далеко не всегда так. У нас например все ведущие технические специалисты люди с возрастом 40+. Что программисты, что инженеры. А процессами местами рулят ребята и девчата до 30, но при этом с образованием вроде «ИТ-менеджемент» или «Бизнес-информатика».
НЛО прилетело и опубликовало эту надпись здесь
Ничего печального я в этом не вижу. Вполне себе нормальные менеджеры и нормально делают свою работу. Я бы скорее всего делал её хуже и однозначно с гораздо меньшим удовольствием.
Ничего печального. Давно и не мной подмечено — отличный опытный инженер вовсе не обязательно окажется хотя бы неплохим менеджером. Это совершенно разные профессии, требующие разных знаний и наклонностей.
О, ларчик просто открылся. Меня руководящие должности, в плане личного роста, не интересуют. Да и вообще не интересуют, по большому счёту.
НЛО прилетело и опубликовало эту надпись здесь
Так я написал «по большому счёту». Ситуации разные случаются. Главное, что наличие гипотетических перспектив получения руководящей должности не является, для меня, определяющим фактором в плане личного роста.
НЛО прилетело и опубликовало эту надпись здесь
Да, право каждого решать, на какие именно обязанности он будет затрачивать своё, путь даже оплачиваемое, время.
Ох, речь не о сидении в своём мирке. Управление банально новая сфера деятельности.
Ох, речь не о сидении в своём мирке. Управление банально новая сфера деятельности.
НЛО прилетело и опубликовало эту надпись здесь
У вас на мой взгляд какое-то очень узкое понимание «управления» в целом и «управления процессами» в частности.
НЛО прилетело и опубликовало эту надпись здесь
А у вас сильно узкое понимание задач у опытного специалиста. Заточное на чистую теорию и жесткую специализацию. Что нужно для крайне узких областей.
И с чего вы вот это вот вдруг взяли? :)
P.S. Просто представьте себе с другой стороны «опытного менеджера», который вдруг начинает везде лезть и рассказывать программистам как им надо код писать. Ведь его задача тоже «сделать продукт» и ему тоже надо развиваться и не быть «исключительно узким специалистом» :)
Специалист действует в рамках своей зоны ответственности. Его мнение имеет в указанных рамках вес. Или, по крайней мере, должно иметь. Вот здесь он обязан высказываться. И, по идее, его мнение должны принять во внимание.
Он может высказаться за рамками зоны ответственности, если ему есть, что сказать, но его могут не послушать. Иногда действительно не слушают. Поэтому здесь проблема не в его молчании, а скорее в спросе на мнение со стороны руководства. Да и процессов в фирме вообще.
Да, будучи руководителем, он имеет право высказываться и его должны выслушать по поводу того, что, будь он на старом месте, могли раньше проигнорировать. Вина ли его, если он не боролся за место ради цели быть услышанным? Нет, так я не думаю.
Да, если человек болеет за дело, он, возможно постарается всеми силами, и средствами, добиться цели быть услышанным, в том числе за счёт другой должности. Но, на мой взгляд, не каждый случай представляет такой интерес, чтобы отказаться от профессионального роста ради достижений в реализации проектов.
Т.е. должны сложиться определённые условия. Редкий случай человека в определённой ситуации. Отсюда, нельзя делать общий вывод, т.к. подобные ситуации редки и они являются не целями, а постепенно формируются в процессе трудовой деятельности. Нет в них чистого карьерного роста, который можно было бы спрогнозировать.
Он может высказаться за рамками зоны ответственности, если ему есть, что сказать, но его могут не послушать. Иногда действительно не слушают. Поэтому здесь проблема не в его молчании, а скорее в спросе на мнение со стороны руководства. Да и процессов в фирме вообще.
Да, будучи руководителем, он имеет право высказываться и его должны выслушать по поводу того, что, будь он на старом месте, могли раньше проигнорировать. Вина ли его, если он не боролся за место ради цели быть услышанным? Нет, так я не думаю.
Да, если человек болеет за дело, он, возможно постарается всеми силами, и средствами, добиться цели быть услышанным, в том числе за счёт другой должности. Но, на мой взгляд, не каждый случай представляет такой интерес, чтобы отказаться от профессионального роста ради достижений в реализации проектов.
Т.е. должны сложиться определённые условия. Редкий случай человека в определённой ситуации. Отсюда, нельзя делать общий вывод, т.к. подобные ситуации редки и они являются не целями, а постепенно формируются в процессе трудовой деятельности. Нет в них чистого карьерного роста, который можно было бы спрогнозировать.
Это если вы растете как менеджер, а не как специалист.
Чем чаще я слышу подобное, тем отчётливее убеждаюсь в том, что стране не следует оплачивать так много бюджетных мест для бесплатного высшего образования.
С одной стороны, слишком много людей не ценят того, что им достаётся бесплатно. С другой стороны, плодятся вузы, не годные ни на что, кроме распила денег и прохождения аттестации.
С одной стороны, слишком много людей не ценят того, что им достаётся бесплатно. С другой стороны, плодятся вузы, не годные ни на что, кроме распила денег и прохождения аттестации.
Проблема не в количестве бюджетных мест, а в неадекватных требования по наличию высшего образования к месту и не к месту. Не будут требовать высшего образования там где его реально не надо — не будут люди так стремиться получить корочку, а будут стремиться получить знания (те, кому они нужны).
Как Вы думаете — нужно ли программистам высшее образование?
И как вы думаете — требуют ли его? )
Как Вы думаете — нужно ли программистам высшее образование?
И как вы думаете — требуют ли его? )
И пункт третий: как вы думаете, какие знания остаются через 1-2-5 лет после выпуска?
PS Искали человека с опытом С/С++, знанием математики и опытом с параллельными вычислениями, нашёлся единственный специалист возрастом в 61год, сидит, переносит пару полезных библиотек на CUDA, ибо или люди математику уже (ещё?) не помнят, или С не знают.
PS Искали человека с опытом С/С++, знанием математики и опытом с параллельными вычислениями, нашёлся единственный специалист возрастом в 61год, сидит, переносит пару полезных библиотек на CUDA, ибо или люди математику уже (ещё?) не помнят, или С не знают.
И пункт третий: как вы думаете, какие знания остаются через 1-2-5 лет после выпуска?
Ну по моему опыту если человек что-то один раз понял или хотя бы выучил, то он уже знает что это существует в природе. А во вторых вспомнить это всё через 5-10-15 лет гораздо проще чем выучить с нуля. Ну или как минимум мой мозг именно так работает.
ибо или люди математику уже (ещё?) не помнят, или С не знают.
Или просто не хотят такими вещами заниматься за те деньги что вы им предлагали :)
Как Вы думаете — нужно ли программистам высшее образование?
Это полностью зависит от сферы применения продукта. Там, где велика ответственность и цена ошибки, я считаю, должны работать люди с высшим образованием, потому что это просто показатель определённой инженерной культуры. ПО для транспортных систем, медицинского оборудования, финансовых приложений, оперирующих деньгами и проч. — я бы хотел, чтобы этим занимались люди с достаточной широтой знаний и системным мышлением. А вот всякие веб-сервисы делать или мобильные приложения для заказа кофе, — для этого действительно долго учиться не обязательно.
Вообще, требования по высшему образованию напрямую происходят из законодательства. У тебя, к примеру, не может быть в штате программиста без высшего, ты можешь назвать его только техником. Соответственно, не пройдешь какие-то тендерные условия по софту, не получишь лицензии по безопасности на свои продукты и т.д. Так что очень часто это никакая не прихоть эйчаров, а реальное жёсткое требование бизнеса.
Вообще, требования по высшему образованию напрямую происходят из законодательства. У тебя, к примеру, не может быть в штате программиста без высшего, ты можешь назвать его только техником.
Мне интересно было бы посмотреть где и как конкретно это прописано в законодательстве.
Гуглите: «профессиональный стандарт программист», ну в целом про статус профессиональных стандартов.
Это полностью зависит от сферы применения продукта. Там, где велика ответственность и цена ошибки, я считаю, должны работать люди с высшим образованием, потому что это просто показатель определённой инженерной культуры. ПО для транспортных систем, медицинского оборудования, финансовых приложений, оперирующих деньгами и проч. — я бы хотел, чтобы этим занимались люди с достаточной широтой знаний и системным мышлением. А вот всякие веб-сервисы делать или мобильные приложения для заказа кофе, — для этого действительно долго учиться не обязательно.Может, достаточно что бы на этих должностях были люди с широкими знаниями и системным мышлением и инженерной культурой?
А ещё лучше — знаниями и опытом?
Да и… думаете у специалиста с 10, к примеру, годами опыта работы с ВО и у специалиста с 10 годами опыта работы без ВО будет очень разный уровень широты знаний, инженерной культуры и системного мышления (ну пусть опыт работы у них будет примерно одинаковый)?
А 20 лет?
Я не к тому, что бы сказать что ВО не нужно. Я к тому, что бы вы реально задали эти вопросы себе.
То что джуны с ВО скорее всего знают и умеют чуть больше — это вполне возможно. Но… джуны это очень узкая область и их и так и так не будут брать на что то серьёзное ещё очень долго.
ЗЫ: ну, про требования законодательства — это сильно за уши притянуто. Но пусть будет так — это как раз то о чём я и говорил — неадекватное требование к наличию ВО.
Я к тому, что бы вы реально задали эти вопросы себе
Не очень понимаю, зачем пытаться разговаривать со мной так, как будто я студент на семинаре. Я думал на эту тему ещё пятнадцать лет назад, когда был студентом и искал работу, думал и семь лет назад, когда искал сотрудников себе в помощь, думаю и сегодня, когда участвую в найме в нашу компанию.
Да, я считаю, что при равном опыте работы специалист с ВО в среднем будет иметь более высокий уровень инженерной культуры и системного мышления. При этом, очевидно, что все люди уникальны, и существует немало прекрасных, ответственных, опытных разработчиков без высшего образования, и также существует масса дармоедов с дипломом.
Я не прошу людей показать диплом на собеседовании, и у меня не возникнет никаких проблем с образованным человеком без диплома. Мне хочется видеть сотрудника с образованием, диплом — это некий маркер, который, плюс ко всему, нужен для отдела кадров, чтобы соблюсти все придирки ТК. Поэтому в наших вакансиях такое написано.
Мне хочется видеть сотрудника с образованием, диплом — это некий маркер, который, плюс ко всему, нужен для отдела кадров, чтобы соблюсти все придирки ТК. Поэтому в наших вакансиях такое написано.Ну вот поэтому и такая ситуация с ВО. Маркер нужен всем, по делу и без дела — поэтому «маркер» и продают/покупают или отсиживают ради его наличия, а не знаний. И, раз есть спрос — есть и предложение.
=)
Не очень понимаю, зачем пытаться разговаривать со мной так, как будто я студент на семинаре. Я думал на эту тему ещё пятнадцать лет назад, когда был студентом и искал работу, думал и семь лет назад, когда искал сотрудников себе в помощь, думаю и сегодня, когда участвую в найме в нашу компанию.
Прошу прощения, если мой тон вам показался снисходительным или лекторским. Ничего такого не имел в виду )
НИУ… Случайно, не МИЭТ?
Без корочек в СНГ тоже непросто. Работал в корпорации, постоянно кадровые чистки по дипломам (понятно, что блатных не затронут, но безродным приходится напрягаться), и по наличию и по соответствию требованиям к занимаемой должности. Та же история с госслужбой. И даже работа в маленькой конторе не всегда спасает: регулярно сканы дипломов прикладываем к заявкам на участие в тендере.
Но если реально по знаниям и навыкам, можно ли их определить по рассказу о дипломе, можно. Иной раз человек критикует свой диплом, что только добавляет ему профессиональных баллов.
Хорошо что я не писал диплом.
И это прекрасно, потому что он укажет на неэффективности вашего рабочего процесса(если он адекватный, а не примадонна которой всё не нравится).
Ага и это нормально. Есть планы на год-два-три. Нужны такие то навыки. А что там дальше — не знает НИКТО.
Есть еще презрение к навязанной практике обучения — такой работник и в подразделении будет идти наискосок (если не в обратном направлении).
И это прекрасно, потому что он укажет на неэффективности вашего рабочего процесса(если он адекватный, а не примадонна которой всё не нравится).
Если наниматель отбирает кандидата по узкому/широкому набору знаний, востребованному в данной конторе здесь и сейчас, игнорируя его прошлый опыт, то речь идет об одной задаче, а что делать потом, наниматель и сам толком не знает.
Ага и это нормально. Есть планы на год-два-три. Нужны такие то навыки. А что там дальше — не знает НИКТО.
Да какая разница писал или не писал диплом человек с 10-15 годами опыта, если он в остальном устраивает? Для меня в более выигрышной позиции был бы человек, который вместо учёбы в бестолковом вузе по программе 10-ти летней давности пошёл получать знания на работе. Ну, наверное, за исключением физиков-ядерщиков, врачей, пилотов и иных специальностей, где на работе ошибаться нельзя.
причин для неписания диплома при окончании ВУЗа только две: лень или неумность.
эм… а как насчет «в ВУЗе знания были весьма поверхностные, за то к этому моменту уже 5 лет работал по специальности и перерос в тим.лида и совладельца»?
это можно, конечно, под «презрение к навязанной практике обучения» записать, но чую вы еще мнооого вариантов отсекли и вполне толковых специалистов на рынке где и без того не всегда просто найти достойных кандидатов
Соискателей с не профильным образованием не рассматриваете то есть?
А если не ИТ специальность? Ну гидравлика(не моя но один факультет) к примеру, много будет понятно? А если прочнисты? Нет я бы с удовольствием рассказал про то как на OpenGL + delphi делал визуализацию, как перводил решение с Maple в код на паскале и сделал бы ответвление о том что Паскаль изучал ещё в школе и участвовал в олимпиадах и до сих пор неуютно за нерешённую задачу про шахматы с визуализацией… Но ведь это практически не имеет отношения к тому кем я являюсь сейчас, т.к. за эти годы произошло много событий а люди со временем меняются, но мало того, их воспоминания могут сильно отличаться от того что происходило на самом деле, даже без учёта того, что очень сложно понять рассказывают ли вам то что думают или сильно фильтруют :)
Совершенно с Вами согласен — и про диплом и про «переучиваться всей конторе». Думаю, что читатели «Хабра» со стажем, прекрасно это сознают. А молодежь, которой «сделали диплом» — пусть не обижается.
Диплом сильно зависит от уровня учебного заведения и научного руководителя. Я бы например был бы рад написать что-то резонирующее с моим профилем, но МГТУ хотел другого, так что там вода водой на 90% и маленькая утилита под капотом. Зато я могу рассказать темы всех 5 дипломов, которые я делал в голодные студенческие годы для других.
Это я к чему: к сожалению, диплом (поведение в стенах ВУЗ-а) не показатель, пока с образованием беда.
Это я к чему: к сожалению, диплом (поведение в стенах ВУЗ-а) не показатель, пока с образованием беда.
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.»
Интересно, что вы делаете с людьми, тема диплома которых вам вообще ни о чем не говорит.
И убойный вопрос: «Если Вы писали диплом, расскажите о нем.»
Диплом пишется для того, чтобы пройти босса. Поэтому какой в вашем заведении босс, такой и диплом. Ориентироваться по диплому — это абсолютно неправильно.
(подразумеваются институты/универы в СНГ).
Да и ежу понятно, что если много ходить по собеседованиям, то можно наловчиться их хорошо проходить, даже не имея особого практического опыта. Т.к. вопросы и задачки все однотипные.
в opensource хорошо — можно поглядеть на _результаты_ работы человека до собеседования.
в отдельных случаях можно даже оценить прочие аспекты, типа коммуникабельности, английского и проч.
в отдельных случаях можно даже оценить прочие аспекты, типа коммуникабельности, английского и проч.
А ещё — каждая новая порция кода, залитая на открытый GIT или SVN, имеет своего автора. По стилю и качеству авторского кода очень хорошо видно компетенцию, опыт, эстетические предпочтения и даже темперамент его создателя. Специалисты-кадровики из любой крупной фирмы могут легко составить психологический портрет каждого из ведущих разработчиков и либо переманить их у конкурентов, либо демотивировать их каким-либо образом (это не паранойя, а обыденная реальность того мира, в котором мы все пытаемся выжить).
Из данного обсуждения некоторых реалий opensource на форуме одного публичного проекта
P.S. Но это, похоже, не приемлемо для Вашего описанного случая кадровиками. :)
Простите меня, но такие специалисты-кадровики, которые знают и применяют и гит, и психологию в достаточном объеме, встречаются реже именных бриллиантов.
И если компания может позволить себе таких кадровиков — то уж сказать «чувак, вот тебе открытый бланк с требованиями к рабочему месту, зарплата *1.5 -2 от твоей текущей, вот список проектов и задач, где ты будешь полезен, пошли к нам, будешь звездой» компания тем более сможет.
Скажите, вы бы отказались от такого оффера, если задачи и проекты как минимум, не хуже/не скучнее?
И если компания может позволить себе таких кадровиков — то уж сказать «чувак, вот тебе открытый бланк с требованиями к рабочему месту, зарплата *1.5 -2 от твоей текущей, вот список проектов и задач, где ты будешь полезен, пошли к нам, будешь звездой» компания тем более сможет.
Скажите, вы бы отказались от такого оффера, если задачи и проекты как минимум, не хуже/не скучнее?
В реальности когда сисадмин вам пишет что с бд у него всё замечательно… ты спрашиваешь че такое эйсид и зачем нужны индексы, а он говорит "что? а для этого есть сетевик"… хочется выбить лицензию на убийства.
А сисадмин то тут причём? ДБА такие вопросы нужно задавать. А вот если он (что сисадмин что ДБА) говорит что нужен сетевик для этого, тогда да, печаль беда.
При том, что хотелось бы, чтобы он знал, что за это отвечает не сетевик.
Ну как это при чём? Вы ещё скажите, что сис.админ не должен 1с конфигурацию за пол-часа написать или проводку в автомобиле директора поменять.
Сисадмину нужно знать, что если в приложении используются транзакции с изоляцией, то для MySQL это гарантированно означает InnoDB. А если InnoDB storage никто не чистит, то оно распухнет и выжрет все место на диске.
А вы точно-точно не путаете системного администратора с администратором баз данных?
В наших неидеальных реалиях это часто один и тот же субъект...
подтверждаю
НЛО прилетело и опубликовало эту надпись здесь
Ну, идеальная картина мира-то мне известна.
Только очень часто всякие БД не являются сильно критичными и важными для инфраструктуры и нанимать для них отдельного DBA бизнес не очень хочет. Ну и усугубляет ситуацию распространенный нынче agile-подход где все должны делать всё.
У нас в департаменте, например, зоопарк разных баз различной степени важности — от стандартных MySQL/PostgreSQL до всякой аналитики вроде Clickhouse и вороха NoSQL Mongo/Cassandra/etc. Выделенного DBA нет, да и на мой взгляд не нужен он особо т.к. большинство из этих баз не customer-facing.
Так что зависит от ситуации.
Только очень часто всякие БД не являются сильно критичными и важными для инфраструктуры и нанимать для них отдельного DBA бизнес не очень хочет.
Если база данных не является критичной на предприятии, то уж нюансы MySQL, Postgres, MS SQL, Oracle и тем более NoSQL сисадмину знать не обязательно.
То есть для себя он конечно может копать и поднастраивать, но чтобы работодатель вот прямо требовал или ожидал при приеме на работу такие навыки по обслуживанию зоопарка, это уже за гранью добра и зла.
Вообще говоря, если я вижу контору у которой нет бюджета/желания иметь отдельно сисадмина и отдельно DBA, но при этом у нее таки зоопарк из 4-5 видов баз данных (а сколько самих БД внутри каждого сервера еще отдельный вопрос), то я бы рекомендовал такую контору обходить стороной за километр. Что-то у них там не в порядке с менеджментом.
Даже если предположить что контора была вынуждена весь этот зоопарк установить потому что они используют чьи-то сторонние решения, но тогда и обслуживать все эти чудеса стоит отдать на аутсорс, тем же ребятам кто продавал и обслуживает эти решения. Либо если это типа проверенные годами и отлаженные коробочные решения, то опять же сисадмину не надо разбираться нюансах типа InnoDB vs MyISAM.
agile-подход где все должны делать всё.
Можно ссылочку про то что «agile-подход = все должны делать всё.»?
Как я понимаю agile-подход, это все делают то же самое, только без нормального планирования. То есть кастрированный или обрезанный процесс разработки по части планирования. Но это не значит что девелопер должен поднимать упавший прод, а QA делать код-ревью, а DBA заниматься настройкой сетевых фильтров.
Если база данных не является критичной на предприятии, то уж нюансы MySQL, Postgres, MS SQL, Oracle и тем более NoSQL сисадмину знать не обязательно.
Да, сейчас в каждой дырке какой-нибудь SQL начиная от SQLite в каждом телефоне и часах чуть поумнее будильника. Поэтому некртичных баз сильно больше чем тех, от простоя которых будут сразу страдать клиенты или бизнес… Навыков, конечно, никто не требует, но по работе сталкиваться надо и минимальную надежность обеспечить.
Вообще говоря, если я вижу контору у которой нет бюджета/желания иметь отдельно сисадмина и отдельно DBA, но при этом у нее таки зоопарк из 4-5 видов баз данных (а сколько самих БД внутри каждого сервера еще отдельный вопрос)
Я бы не был столь категоричен, у нас большая компания с 20к+ сотрудников, но много департаментов и везде разные порядки и требования. Есть, конечно, отделы которые облизывают исключительно
Oracle т.к. он там не просто так стоит и его простой будет стоить много денег. А есть как у нас, где почти все базы — для служебного пользования.
Можно ссылочку про то что «agile-подход = все должны делать всё.»?
Дело не в том как "в книжке", а в том как менеджмент это у себя в голове видит.
У нас до некоторого времени было так, что от инженеров ожидали компетенций сразу в нескольких сильно разных сферах, но потом пришло осознание что стать экспертом затыкая собой все дыры не получится. Поэтому мы реорганизовались и теперь имеем узкие специализации, но при этом на хорошем уровне умеем все остальное, эдакий T-Shaped
у нас большая компания с 20к+ сотрудников,
Но в ИТ департаменте до сих нет понимания что сисадмин и DBA это разные люди и нет бюджета чтобы нанять обоих?
Повторюсь — никому не рекомендую заходить в такую контору.
Дело не в том как «в книжке», а в том как менеджмент это у себя в голове видит.
Туда же. Есть проблемы роста. Когда люди из 90х попали на руководящие роли и контора выросла с пары человек или пары десытков человек до как у вас до 20К если менеджмент не успел вовремя все осознать и переобучиться, то не стоит тратить свое время и силы на то чтобы бороться с ветряными мельницами. Когда я иду в большую контору где работает 20К людей, я ожидаю что это они меня будут чему-то учить чего я никогда не могу и представить в маленьких или средних конторах. Но если я могу прийти и увидеть «детские» ошибки в подходах и менеджменте и внезапно оказываюсь «самым умным в комнате», в этот момент я понимаю что попал и надо срочно искать другое место работы.
. Поэтому мы реорганизовались и теперь имеем узкие специализации,
Вы уж определитесь вы имеете узкие специализации или нет. А то топик начался с того что сисадмин и DBA это должны быть разные люди с разной квалификацией. А вы как бы защищали позицию что нет.
Затем я высказался в том плане что от подобных контор стоит держаться подальше. И вы снова как бы не согласились, ссылаясь на свой опыт и видимо пытаясь сказать что у подобных контор есть некие объективные «оправдания». На мой взгляд у всего на свете есть оправдания, но это не повод тратить пару лет своей жизни на то чтобы впитывать неправильные практики, вместо того чтобы пойти в нормальное место и прокачиваться в том направлении которое реально интересно.
Я же вас лично ни на что не агитирую. Но не вижу как ваши доводы могут повлиять на мою позицию в этом вопросе. В 90-ые было модно, доходно и интересно порой быть эникейщиком. И я тоже все это делал. Но постепенно я увидел как быстро я начинаю проигрывать тем кто выбрал специализацию и пошел прокачиваться в каком-то направлении. Эникейщики по сути нужны тем руководителям которые ничего не понимают в ИТ и у которых мало денег. Тем кто ничего не понимают, но у которых есть деньги — предпочтут грамотного CTO или архитектора и отдел или департамент в подчинении у этого человека. Если же в роли такого CTO оказывается не очень компетентный человек, то, на мой взгляд, именно тогда мы и получаем обсуждаемую ситуацию. Для меня это очевидно. Для вас видимо нет. Но уровень очевидности для меня такой, что я не вижу смысла писать трактаты в комментариях. Это как объяснять «почему колесо катится, а кирпич нет», настолько очевидно, что при попытке объяснить, чувствую себя идиотом или глупцом одновременно.
DBA — администратор, а не архитектор. Очень разные роли =)
При том, что постоянно это указывают в резюме. Если бы не указывали — я бы и не спрашивал.
Ну да, у меня, например, с бд всё замечательно. Лежит на диске, бекапится, иногда бекапы подключаются для проверки. Хотите узнать про индексы — купите себе ДБА и… ему мозги. Можете прям меня-же(на самом деле нет, в ДБ плаваю), но за те-же деньги. А не за цену эникея.
Если понадобиться — так и будет) Но если человек в резюме прямым текстом указывает, что у него замечательные знания баз данных (тут бесчисленные перечисления продуктов), то я просто обязан узнать насколько, чтобы в случае чего акцентировать его работу на этом. По факту каждый почти админ в резюме пишет про базы данных и хорошо ещё, если это значит бэкапы, подключение, репликацию… Потому, что зачастую «ну там у нас была программа, мы в ней набирали текст и оно в базу летело». Не надо указывать в резюме то, с чем работать не умеешь. Лишняя строчка тут это минус, а не плюс.
Странные вопросы вы своему сисадмину задаете, имхо…
Про то когда валят, могу предположить несколько причин (без сортировки)
- На самом деле вакансии нет, это бывает когда главе отдела человек не нужен, а глава департамента например думает что нужен. Или HR нужно выполнять KPI по собеседованиям не зависимо от запроса со стороны проекта, или это вакансия нужна чтобы нанять иностранного специалиста, но местной службе занятости, трудовой инспекции и миграционной службе нужно показать что такого специалиста на месте нет.
- Молодой руководитель с задранным ЧСВ и только учащийся тому как на самом деле нужно использовать авторитет, знания, уважение и вообще софтскиллз, такой может просто так валить на собеседовании
- Очень часто вывод о том что мы не хотим работать с этим человеком делается по его поведению, внешнему виду и прочим факторам. Многие будут это отрицать, но это действительно часто так работает. И нам нужно отказать. И многие руководители сделают вывод что проще всего завалить и человек будет думать что не подходит по скилам, а не по другим причинам. В современном лицемерном мире не принято говорить что я не хочу с тобой работать потому что ты больно дерзко отвечаешь на вопросы, и я вижу что наше общение не будет продуктивным
- Кандидат реально не тянет. Когда я собеседовал людей на разработку графдвижка, то собеседования, в основном, поделились на два типа: 1. Люди не понимали зачем я спрашиваю те тонкости которые я спрашивал и думали что я их завалил. 2. Диалог быстро перешёл а обсуждение тонких моментов и граблей со взаимным обменом опытом и шишками и закончился оффером.
В современном лицемерном мире не принято говорить что я не хочу с тобой работать потому что ты больно дерзко отвечаешь на вопросы, и я вижу что наше общение не будет продуктивным
Тут проблема не в лицемерии а банально в трудовой инспекции которая может заинтересоваться чегойто работника не берут не по скиллам а по характеристикам мало имеющих отношения к работе (и нет, всякое «не впишется в команду» насколько знаю для них не аргумент).
Ну и еще некоторые соискатели после отказа по личным качествам такой хайп и вой поднимут на хабре/в твиттере — что репутации компании кирдык придет.
Именно это я и подразумеваю под
В современном лицемерном мире не принято говорить
Лицеме́рие — моральное качество, состоящее в том, что заведомо безнравственным поступкам (совершаемым ради эгоистических интересов, по низменным мотивам и во имя антигуманных целей) приписываются псевдоморальный смысл, возвышенные мотивы и человеколюбивые цели[1].
— Википедия.
Как то не вижу в описанных мной мотивах особо безнравственных поступков, и уж тем более никакие возвышенные мотивы не пытаются себе приписать.
По первому пункту. Бывает еще, что человек, который проводит собеседование, хочет свою значимость в компании поднять или значимость своего подразделения. Он заявляет, что ресурсов не хватает, а кандидаты хорошие на вакансию не приходят, при этом всех кандидатов заваливает. И таким образом старается обосновать, например, повышение бюджета на вакансию. Или возможность работать удаленно (и рассмотреть таким образом больше кандидатов). Или возможность привлечь дорогих аутсорсеров. Или еще что-то, в чем он заинтересован.
Вы забыли ещё один пункт. Иногда, по резюме кандидата понимаешь, что человек сильно круче тебя практически по всем фронтам и чтобы не ударить в грязь лицом перед начальством, начинаешь такого человека валить. Так сказать возвышаешься через унижение. У меня, конечно, опыт не такой богатый, как у автора статьи, но я тоже с таким сталкивался, причём именно в РБ (было пару собесов в Польшу, Нидерланды, Украину, Россию).
В 90% моих собеседований совершенно не смотрят на мой гитхаб. Их это не волнует. Им интереснее меня про определение ООП спросить.
НЛО прилетело и опубликовало эту надпись здесь
Вот это очень правильная вещь. Собеседование одно одновременно важно для обоих сторон. Будучи кандидатом очень важно в обратную сторону собеседовать компанию. И понимать что часто в тексте вакансии написано совсем не то что есть по факту, и оценивать нужно не те мечты которые нарисовались в голове исходя из вакансии, а то что будет реально встречено, какие отношения в коллективе, кто собеседует, какой офис и т.п.
А то, что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность?
О! Спасибо за отличный вопрос, завтра задам его кандидату.
А если серьёзно, то я уже давно заметил одну странную вещь. Многие мои знакомые (разработчики с опытом по 15 лет) проводят собеседования. Иногда мы обсуждаем, какие вопросы они задают. И оказалось, что они периодически задают то, что узнали буквально вчера совершенно случайно. Т.е. то, без чего они 15 лет прекрасно работали, а через две недели забудут напрочь. При этом искренне удивляются, что кто-то может не ответить на такой элементарный вопрос: «Какой Senior?!!! Он же проффнепригоден!». И это удивление искреннее, у них нет ни желания специально завалить кандидата, ни как-то возвыситься за чужой счёт.
Это мне напоминает один психологический факт. Дети до какого-то возраста не могут понять сказку про Белоснежку. Почему она ест отравленное яблоко? Ведь это известно, что оно отравлено! У них в голове не укладывается то, что у другого человека может быть совершенно другой «контекст», другие знания. Может это как-то связано?
Вероятно, инфантильность это беда нашего общества.
Ну, справедливости ради про сложность поиска можно по названию типа индекса догадаться. А какая собсно еще сложность кроме логарифмической может быть при поиске в сбалансированном дереве?
B-tree — это не только balanced tree, как может показаться.
На самом деле точного ответа автор этой структуры не дал, поэтому существует два распространённых варианта: balanced (широкий класс деревьев, вообще говоря) и block (что гораздо лучше описывает конкретно эти деревья).
Главное, что совсем не binary :)
Но ведь любое B-дерево является идеально сбалансированным вне зависимости от происхождения буквы B.
Сбалансированные деревья всё же куда более широкий класс, чем блочные.
А это и не важно. Если некоторое утверждение справедливо для любого сбалансированного дерева — то оно будет справедливо и для любого блочного.
И этим простым утверждением вы доказываете то, что вам пишет оппонент. :)
Раз утверждение верно для множества (сбалансированных деревьев), то оно автоматически верно и для подмножества (блочных деревьев), ну же.
Раз утверждение верно для множества (сбалансированных деревьев), то оно автоматически верно и для подмножества (блочных деревьев), ну же.
Получется, что ваши знакомые тоже не в курсе. Так какие вопросы нужно задавать на собеседовании? Задачки на сообразительность типа по лампочкам в вагонах определить не циклический ли поезд? Паттерны проектирования? Или про диплом опять же? (у меня есть знакомый дев опс с 9 классами образования)
Гораздо интереснее вопрос, почему Белоснежка жила с семью гномами. Количество переходит в качество? При каком N?)
НЛО прилетело и опубликовало эту надпись здесь
именно чтобы написать это и пришёл в комментарии.
другое дело, что не всем нужно писать что-то связанное с БД, или таблицы очень небольшие, но раз заявляется знакомство с SQL — вопрос вполне уместный.
P.S. ИМХО это вполне нормально на собеседовании ответить не на все вопросы.
Ну в общем это базовое понимание
Серьееезно? Это знание даром ненужное, вообще, совсем.
то как ты узнаешь когда они тебе нужны
А у вас есть другие типы индексов? Второй по распространенности это pg_trgm индекс (да, внезапно на GIST но знания о существовании его — достаточно), все остальные еще более ситуационные настолько, что среднему разработчику они нужны будут примерно никогда.
Вот спросить про например GiST индексы в Postgre это было бы другое дело.
А они действительно используются в вашей компании? Не подскажите какими операторами вы используете этот индекс?
PS ну опять адепты алгоритмической сложности в карму набежали) Господа аргументы в студию, с use-case'ами)
НЛО прилетело и опубликовало эту надпись здесь
Но заявлять знание БД и не знать индексов — а собственно что он тогда знает?Не знать про индексы ≠ не знать как устроены индексы.
«Нуу, БД состоит из плоских таблиц?»
НЛО прилетело и опубликовало эту надпись здесь
Так вам шашечки или ехать?
Возможно в таком случае не стоит заявлять о знании БД.
Так можно зайти ну очень далеко, потом идет вопрос о формате WAL, потом page-cach линуха, и так далее. А на самом деле там база, которая дохнет на жалких 100 млн строк на запросах которые писаны левой пяткой и проиндексированны правой.
Потому что знатоков которые мне ответят
Проясните пожалуйста, как устройство индекса может использоваться кем либо кроме собственно разработчика БД.
Ну я вот выше вам задал вопрос, давайте по нему составим интересную беседу?
НЛО прилетело и опубликовало эту надпись здесь
«Быстрее не становится. Даже план не поменялся и индекс не используется. Как же так???»
И вы такой: нуда! тыже не знаешь структуру b-tree, а вот знааал бы!
Он естественно унижен, идет читает, разбирается в алгоритме, проверяет свой индекс, а база ему все равно говорит «seq scan».
всё ещё не знает что индекс сделан на основе дерева
Не надо предположений, просто объясните мне, дурачку, чем это знание ему поможет.
Он что ли запомнил по примерам правила работы чёрного ящика, ускоряющего ему запросы
Огромная часть разработчиков даже на этом уровне не запоминает, вон на битрикс посмотрите.
просто объясните мне, дурачку, чем это знание ему поможет
Не вопрос, приходит менеджер к этому программисту и задает вопросы
1. У нас есть Hadoop кластер, Redis с журналированием изменения раз в минуту и mysql с терабайтной базой, что будем ставить на hdd и что на ssd и почему?
2. Нам нужно создать составной индекс у sql базы в каком порядке нам лучше добавить туда колонки? Нужно ли при наличие составного индекса по колонкам A + B + C, создавать отдельные индексы по колонкам A, B и С или мы просто потратим место на диске?
3. У нас есть множество однотипных запросов, но с производительностью все плохо. Как использовать кластерный индекс в таком случае и почему он сможет нас спасти?
4. Когда и при каких данных нужен разрежённый индекс (ключевое слово SPATIAL в mysql) и почему обычный индекс будет работать хуже?
Да на все эти вопросы можно выучить (или получить эксперементальным путем) ответы и без всякого понимания как база данных работает изнутри, только это будет куда дольше.
Да на все эти вопросы можно выучить (или получить эксперементальным путем) ответы и без всякого понимания как база данных работает изнутри, только это будет куда дольше.
я бы не стал противопоставлять теорию и практику, нужно И то, И другое.
А Вам не кажется что менеджер такими вопросами вообще не владеет, потом не факт что он находится в той же стране и прийти ему будет затруднительно, а сам сервак вообще находится в третьей стране и за него отвечают совсем другие люди.
Понятно что в конторе где все три роли исполняет один и тот же человек — он же и разработчик и менеджер и специалист по БД — ему приходится знать всё выше перечисленое. Но так ли Важна производительность для такой конторы, не является ли это «стрельбой из пушек по воробьям».
Понятно что в конторе где все три роли исполняет один и тот же человек — он же и разработчик и менеджер и специалист по БД — ему приходится знать всё выше перечисленое. Но так ли Важна производительность для такой конторы, не является ли это «стрельбой из пушек по воробьям».
Менеджер с такими вопросами это утрированный образ, конечно.
Ну представьте, вы разработали систему, решали все проблемы с производительностью покупкой новых серверов, а потом пришел новый сотрудник и за полдня ускорил работу приложения в тысячу раз, просто прописав правильные индексы и владелец бизнеса внезапно понял, что потратил кучу денег на десятки и сотни серверов, которые нафиг были не нужны. Какое у него будет отношение к вам, особенно если он считал вас экспертом по БД?
Далее, на мой взгляд критическое мышление возможно только если хоть немного понимаешь как все работает под капотом. Помните всякие шутки с введи «format c:» или «sudo rm...»? Вот человека, которые понимает чуть как оно работает внутри намного сложнее обмануть всякими рекламными штуками или ошибочными советами в инете…
Ну представьте, вы разработали систему, решали все проблемы с производительностью покупкой новых серверов, а потом пришел новый сотрудник и за полдня ускорил работу приложения в тысячу раз, просто прописав правильные индексы и владелец бизнеса внезапно понял, что потратил кучу денег на десятки и сотни серверов, которые нафиг были не нужны. Какое у него будет отношение к вам, особенно если он считал вас экспертом по БД?
Далее, на мой взгляд критическое мышление возможно только если хоть немного понимаешь как все работает под капотом. Помните всякие шутки с введи «format c:» или «sudo rm...»? Вот человека, которые понимает чуть как оно работает внутри намного сложнее обмануть всякими рекламными штуками или ошибочными советами в инете…
Какое у него будет отношение к вам, особенно если он считал вас экспертом по БД?
странная точка зрения
Допустим я начальник подразделения разработки, беру нового сотрудника, который знает больше меня и оптимизирует систему так что она начинает работать быстрее.
И типа чё, давайте меня понизим, а нанятого сотрудника повысим — типа он умнее?
это совершенно разные категории. Если вы в одно лицо запилили огромный сервис, напрямую работаете с владельцем бизнеса, потом берете себе помощника который знает какуюто технологию лучше вас — это блин НОРМАЛЬНО и обычно. А если собственник начинает мерить эффективность персонала такими методами и не понимает что человек который в состоянии спроектировать и запилить большой проект в одно лицо — скорее всего знает хуже узкие технологии чем человек который например 10 лет только dba и работал, то из этой конторы надо бежать
странная точка зрения
Допустим я владелец бизнеса и нанимаю Java/Javascript архитектора и Lead Developer за большие деньги, у которого по CV и тех.интервью огромные опыт и большая экспертиза. Он разрабатывает системы, потом я нанимаю аудиторов, которые выдают заключения, что мой якобы супер специалист не знает банальных Java коллекций и у него в хаш.мапах одни hash коллизии, в вебе одни sql injection'ы и т.п. дыры, а бд не использует тривиальные индексы и нормализации.
Отчего вся система дырявая и дико медленная и из-за его тривиальных ошибок я переплатил намного больше его зарплаты за сервера и теперь проще все написать с нуля чем переделывать.
Вопрос, что я должен сделать как владелец? Дать ему премию?
Я не знаю каков ваш управленческий опыт.
Но обычно владелец не знает и не понимает таких понятий как:
И аудиторы никогда не указывают на персоналии и вообще. Я никогда не слышал о таком техническом аудите. Причин у технического долга могут быть десятки разных и самый распространенный это всегда лимитированный бюджет.
Вы никогда не знаете что именно проще. Сколько бы ошибок не было сделано, вы никогда не знаете какие из них сделаны из-за некомпетентности, а какие с намерением подправить в будущем, а какие просто потому что вы как хозяин требовали поскорее внедрить какую-то фичу или кто-то латал упавший прод или бухгалтерия требовала срочно восстановить систему потому что им отчет сдавать, и кто-то подставил костыль. И костылей бывает миллион и никакой аудит это не вычислит и не даст реально объективную оценку.
Так что на уровне бизнеса если ваш Ит менеджер нанял спеца, который за месяц ускорил что-то в 100 раз, надо похвалить и менеджера за такую находку и премировать нового сотрудника, чтобы продолжал в том же духе. А если у вас как у владельца чешутся руки кого-то наказать, ваш бизнес постепенно скатится в яму, потому что люди не любят работать в такой среде. Люди любят чтобы их хвалили. Особенно после улучшений. А вы хотите после улучшений, найти виновного почему раньше было хуже.
Но обычно владелец не знает и не понимает таких понятий как:
банальных Java коллекций и у него в хаш.мапах одни hash коллизии, в вебе одни sql injection'ы и т.п. дыры, а бд не использует тривиальные индексы и нормализации.
И аудиторы никогда не указывают на персоналии и вообще. Я никогда не слышал о таком техническом аудите. Причин у технического долга могут быть десятки разных и самый распространенный это всегда лимитированный бюджет.
Отчего вся система дырявая и дико медленная и из-за его тривиальных ошибок я переплатил намного больше его зарплаты за сервера и теперь проще все написать с нуля чем переделывать.
Вы никогда не знаете что именно проще. Сколько бы ошибок не было сделано, вы никогда не знаете какие из них сделаны из-за некомпетентности, а какие с намерением подправить в будущем, а какие просто потому что вы как хозяин требовали поскорее внедрить какую-то фичу или кто-то латал упавший прод или бухгалтерия требовала срочно восстановить систему потому что им отчет сдавать, и кто-то подставил костыль. И костылей бывает миллион и никакой аудит это не вычислит и не даст реально объективную оценку.
Так что на уровне бизнеса если ваш Ит менеджер нанял спеца, который за месяц ускорил что-то в 100 раз, надо похвалить и менеджера за такую находку и премировать нового сотрудника, чтобы продолжал в том же духе. А если у вас как у владельца чешутся руки кого-то наказать, ваш бизнес постепенно скатится в яму, потому что люди не любят работать в такой среде. Люди любят чтобы их хвалили. Особенно после улучшений. А вы хотите после улучшений, найти виновного почему раньше было хуже.
Отчего вся система дырявая и дико медленная и из-за его тривиальных ошибок я переплатил намного больше его зарплаты за сервера и теперь проще все написать с нуля чем переделывать.
Хороший пример, правда. Беда что вокруг ровно все так и есть и даже еще хуже.
Но вы упускаете нюанс, как раз лид уж точно скоре йвсего не помнит структуру R-tree, B-tree. К тому же лид это уже нее совсем программист, это уже менеджер в том числе.
Вопрос, что я должен сделать как владелец? Дать ему премию?
Прийти к нему с заключением «аудиторов» и спросить может ли он поправить за вменяемое время. Аудиторы, знаете ли, сгущать краски любят.
Прийти к нему с заключением «аудиторов» и спросить может ли он поправить за вменяемое время.
Заменим программиста на дантиста. Будете ли вы ходить дальше к стоматологу с просьбой поправить (за отдельные деньги), если вам станет понятно, что он некомпетентен и удалил несколько здоровых зубов и не вылечил больных?
Будете ли вы предлагать криворукому автослесарю, загубившему ваш автомобиль, исправить свои ошибки за вменяемое время и дополнительные деньги?
Даже у стоматологов есть разделение функций — терапевт, хирург, ортодонт, ортопед, пародонтолог. Если ортопед начинает лечить людей, или терапевт ставить импланты — тогда жди беды. А почему от разработчика в 2020 году ждут многостаночности.
Эка вы радикально.
Без косяков не работает вообще никто, вопрос только в том как справляться с кризисными ситуациями.
И кстати мне переделывали работу по зубам. Хожу дальше.
Без косяков не работает вообще никто, вопрос только в том как справляться с кризисными ситуациями.
И кстати мне переделывали работу по зубам. Хожу дальше.
Есть же все-таки разница между просто косяками и косяками, показывающими полную профессональную некомпетентность. Будете ли вы лечится у некомпетентного человека?
А вы знаете способ определения?)
Если мне врач ненра я обычно меняю, в пределах клиники.
А вообще с чего вы решили что «отчет», «аудиторов» может показать полную профнепригодность. Я вам по вполне рабочей системе могу такое написать, что у вас шевелиться волосы будут даже там где их нет.
Если мне врач ненра я обычно меняю, в пределах клиники.
А вообще с чего вы решили что «отчет», «аудиторов» может показать полную профнепригодность. Я вам по вполне рабочей системе могу такое написать, что у вас шевелиться волосы будут даже там где их нет.
А вы знаете способ определения?)
Да, обратится к N экспертам в той же области с консультацией (лучше с рекомендация друзей или хотя какой-то репутацией).
Если условно пять других экспертов не сговариваясь дадут похожий диагноз с тем же списком проблем — вероятно проблема все-таки именно в некомпетенции.
Если вы готовы СТОЛЬКО тратить, то цена неверного найма у вас запредельная, следовательно собеседования не должны проводиться в классическом ключе: «лучше не нанять подходящего человека, чем нанять не подходящего». Поскольку в таком случае, вы рискуете спугнуть как раз того кто вам нужен.
Сколько столько?
Условно, если мне кажется, что доктор лечит меня плохо, я схожу на консультацию еще к парочке докторов. Если мне кажется, что автослесарь либо некомпетентен, либо обманывает, я отвезу машину еще парочке. Если аудит програмного кода показывает очень большие проблемы, вполне логично обратиться еще к 1-2 экспертам, это будет дешевле неправильного решения или продолжать разрабатывать продукт в неправильном направлении.
Условно, если мне кажется, что доктор лечит меня плохо, я схожу на консультацию еще к парочке докторов. Если мне кажется, что автослесарь либо некомпетентен, либо обманывает, я отвезу машину еще парочке. Если аудит програмного кода показывает очень большие проблемы, вполне логично обратиться еще к 1-2 экспертам, это будет дешевле неправильного решения или продолжать разрабатывать продукт в неправильном направлении.
Если аудит програмного кода показывает очень большие проблемы, вполне логично обратиться еще к 1-2 экспертам,
и получить 5 совершенно разных мнения, начиная 'всё надо переписать на go сейчас он в тренде, а у вас устаревшая java которая скоро умрет' до 'переходим на 1С' и 'оо, это PHP на нем только лузеры пишут'
ИТ оно такое… миллион мнений и ни одного единственно верного ;)
ИТ оно такое… миллион мнений и ни одного единственно верного
Нет, нужно задавать правильные вопросы и привлекать правильных экспертов (в смысле не звать оценивать Java приложение фаната GO).
Низкая квалификация программиста и явные грубые ошибки достаточно легко оцениваются, примерно как низкая квалификация и грубые ошибки строителей.
Да, грубые ошибки могут быть из-за низкого бюджета и сжатых сроков, но это понятно, если заставить строителя за полдня сделать ремонт, который должна делать бригада за полгода, очевидно результат будет плохой, что не будет говорить о квалификации работника.
Нет, нужно задавать правильные вопросы и привлекать правильных экспертов
а для этого надо иметь в штате специалиста который может сформулировать правильные вопросы и понять каких экспертов нанять… а кто будет искать такого специалиста… замкнутый круг
… и мы плавно возвращаемся к теме рекрутинговых агенств и рекомендаций.
замкнутый круг
На самом деле, все Западные ИТ компании, в которых я работал, основаны либо бывшими программистами, либо как минимум людьми с ИТ образованием и там так или иначе большинство менджеров имело тот или иной ИТ бекграунд (хотя бы ИТ образование), поэтому замкнутого круга тут и не появлялось.
скорее у вас просто узкая выборка чисто ИТ-компаний.
Я работал в компаниях где ИТ хоть и очень важное направление и фактически ядро и основа компании, но фактически это лишь инструмент для выполнения основной ф-ции (обработка данных для финсектора) и соотсветственно весь топ-менеджмент далек от ИТ в принципе
почему собственно в 'кровавом энтерпрайзе' и встречаются всякие кошмарные решения которые не кому чинить или улучшать… ситуация меняется только если туда както случайно попадает человек с современным взглядом… и аудит не помогает (зачастую его никто не заказывает потому что не понимает что фирма может работать лучше)…
По этому кстати в РФ финсектор со стороны ИТ сильно лучше забугорного, поскольку наши не получили легаси в наследство, а с нуля начали писать уже программисты с более современным подходом
Я работал в компаниях где ИТ хоть и очень важное направление и фактически ядро и основа компании, но фактически это лишь инструмент для выполнения основной ф-ции (обработка данных для финсектора) и соотсветственно весь топ-менеджмент далек от ИТ в принципе
почему собственно в 'кровавом энтерпрайзе' и встречаются всякие кошмарные решения которые не кому чинить или улучшать… ситуация меняется только если туда както случайно попадает человек с современным взглядом… и аудит не помогает (зачастую его никто не заказывает потому что не понимает что фирма может работать лучше)…
По этому кстати в РФ финсектор со стороны ИТ сильно лучше забугорного, поскольку наши не получили легаси в наследство, а с нуля начали писать уже программисты с более современным подходом
еще к парочке докторов.
Вот вы удивитесь, когда 5 докторов дадут 5 разных диагнозов. Я лично такое видел.
будет дешевле неправильного решения
Даже по готовому заключению, на подтверждение, каждому эксперту нужно сколько? Часов 100 в лучшем случае? по 50 баксов в час на два плюс стоимость самого аудита + стоимость простоя + стоимость найма (совокупная) нового сотрудника и его обучение.
А на собеседовании вместо «как бы вы решили вот такие проблемы» вы спрашиваете «сортировку пузырьком» и уменьшаете шанс нанять действительно подходящего вам сотрудника. Отсюда либо еще разок п1 по кругу либо + значительное время простоя.
Вопрос, что я должен сделать как владелец? Дать ему премию?
для начала понять что
— универсальных специалистов не бывает
Архитектор-Лид — не может знать ВСЁ, и он должен работать не в одно лицо, а с командой, где будут узкие специалисты по всем направлениям.
Это блажь — считать что если чел прямо как бог рубит в базах и индексах, то он сможет спроектировать крупную работающую систему которая будет зарабатывать вам деньги, это нереально.
И если вы берете человека который на словах 'господьбог-суперзвезда' — и считаете что он в одно лицо построит вам звезду смерти — блин да это понятно что получится хоть и работающий продукт но построенный из костылей и затычек потому что количество человекочасов превышает человеческие способности
и вы как владелец себе должны по голове постучать и себя лишить премии за то что у вас какието странные ожидания от людей
===
Я работал в конторе где ядро системы было написано одним человеком, дичайшее легаси которое потом поддерживает и переписывает отдел из 5 человек… причем с точки зрения менеджмента это гениальный и практически недостижимый по конкуретноспособности продукт, а с точки зрения разработчика — кошмар и ужас и вообще бывает не верится что оно вообще функционирует… а всё потому что это писал один человек, и фронт и бек и десяток баз начиная от оракла заканчивая кликхаусом и sqlite причем чел осилил в одно лицо даже некое подобие cicd на всё это хозяйство.
Как думаете надо было с позором выгнать этого человека? (он сейчас гдето в США работает) и проклясть его что он паразит за зарплату в 100тыр написал систему которую надо было писать отделом из сеньоров? и она тормозит и жрет ресурсы. помоему тут виновато отсутствие денег, а не конкретные личности и их скиллы
Ну я представил есть 50 человек которые разработали систему, и тут пришел новы сотрудник и полез менять индексы. Сразу вопрос, а кто его вообще допустил до продакшен серверов и кто ему дал задание менять индексы. Вам не приходит в голову что разработчикам может быть запрещено даже знать на каком железе работают продакшен сервера и им запрещено получать информацию с них. И если какой-то сотрудник полезет не в своё дело, будет заниматься индексами вместо своих прямых обязанностей, то он быстро вылетит работы.
Не ну я представил — делаете Вы систему для какого-нибудь Wallmart и тут к Вам приходит владелец бизнеса в говорит; «Выдыхай, Бобер, Выдыхай!»
Не ну я представил — делаете Вы систему для какого-нибудь Wallmart и тут к Вам приходит владелец бизнеса в говорит; «Выдыхай, Бобер, Выдыхай!»
А теперь представьте, что это не новый сотрудник, а новый СТО или владелец заказал аудит и внезапно оказалось, что 50 человек написали редкую фигню с дырами в безопасности, ужасной архитектурой и производительностью и проще уволить всех и написать все с нуля, потому что тех.лиды/архитекторы были некомпетентны и набрали некомпетентных исполнителей.
Что-то похожее я пару раз в жизне видел, вот именно примерно в таких же размерах команд и, да, помню случай когда команду человек в сто уволили, а проект перезапустили с нуля из-за похожих проблем.
Что-то похожее я пару раз в жизне видел, вот именно примерно в таких же размерах команд и, да, помню случай когда команду человек в сто уволили, а проект перезапустили с нуля из-за похожих проблем.
В команде из 50 человек функции каждого достаточно специализированны, требовать скажем от back-end разработчика глубокого знания БД довольно странно. Как там устроены деревья индексов не его вообще проблема. Хорошо если он раньше был full-stack и что-то знает о БД и индексах. А если нет — то и суда нет…
Не ну я представил — делаете Вы систему для какого-нибудь 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 запросы, без знания этого можно говорить, что СУБД вы вообще не знает даже на начальном уровне. ИМХО.
У вас неправильное понимание глубокого знания БД
Вы берете две крайности.
Между ними пропасть:
— нюансы оптимизатора
— оконные функции
— аналитические запросы
— CTE
— частичные, функциональные, pg_trgm/ctxcat индекс и тд
— секционирование
— наследование
— итак далее и тому подобное
И вы же понимаете, что все знать нельзя, можно помнить что и в какой ситуации и этого достаточно.
Ну вот мой пример: допустим вам надо повесить индекс, база у вас Postgresql(забудем про пространственные данные сейчас) вариант индекса у вас целый один — b-tree. Осталось решить какие поля и в каком порядке, проанализировав запросы, ну можно еще его частичным сделать.
Вроде бы Wallmart — крупнейший работодатель в США. Вы Звезду Смерти делали?
Мда… Вы серьезно? В этих темах даже 1сники поверхностно разбираются у которых вообще основная специализация не программирование а больше предметная область и бизнес анализ, и только немного программирования (причем как UI так бека + rest/soap сервисов, так что база для них хоть и важна но далеко не их основная специализация). Как можно называть себя бекенд программистом понимая в базах даже меньше 1сников — не представляю.
В большой компании, где есть разделение ролей, разработчик кода вообще не пишет SQL сам. Это не его обязанность и толку что он знает как устроено дереве индекса вообще никакого. Эта информация для него в принципе бесполезна. Если компания маленькая эта информация для разработчика так же избыточна — он же там одновременно выполняет сто ролей, понимание дерева индекса это не про него. Если большая компания от каждого кандидатов требует такой специализированной информации — они просто забивают мозги кандидатам. Ну это лютый бред, пусть выделят одного или двух, может пятерых, кто будет знать как там устроены индексы внутри, и они уже занимаются такими вещами.
В большой компании, где есть разделение ролей, разработчик кода вообще не пишет SQL для сам. Это не его обязанность и толку что он знает как устроено дереве индекса вообще никако
Простите, а какой у вас опыт работы в больших компаниях, чтобы так утверждать за все большие компании?
У вас судя по всему опыт больших компаний прямо противоположенный моему.
Мой опыт разработчика кода:
1. Компания на 10 тыс. разработчиков. Разработка продукта для почти половины мирового телекома. Писали огромные SQL, хранимые процедуры и сложные индексы и оптимизации в Oracle,
2. Разработка продукта для крупнейших рекламных онлайн сетей мира — оптимизация mysql и mongoDb на самом низком уровне,
3. Одна из крупнейших аутсор компаний мира, разработка для крупнейших финансовых компаний в мире — самостоятельная разрабкта базы данных для продуктов, много оптимизации БД,
4. Разработка продукта для одного из крупнейших поисковых систем отелей в мире, оборот около миллиарда — приходилось постоянно оптимизировать индексы и запросы в базу,
5. Разработка продукта для одного из крупнейших стриминговых сайтов мира (в топ30 в alexa rank) — постоянная оптимизация запросов в базу данных и работа с кешами,
Вы все еще утверждаете, что во всех больших компаниях, разработчик вообще не пишет SQL сам?
P.S. Разделение ролей везде было.
А потом получаем текущие абстракции, проблемы коммуникации из за непонимания одних специалистов что там на стороне других и прочие проблемы узкой специализации в больших коллективах. Я и не топлю за знание всего и сразу, но как по мне модель I-shape специалиста гораздо более проблемная чем T-shape. Я так вообще планирую к Ш-shape ползти, но, тут признаюсь, уже больше по фану а не из реальной необходимости.
а новый СТО
И вы совершенно точно знаете меньше своих сотрудников в совокупности, это нормально.
проще уволить всех
Сразу нахер такого CTO. Пинком прям. Уволить всех это никогда, слышите меня, НИКОГДА, не проще.
Уволить всех — это просто: ставим начальника — идиота с ЧСВ в облаках, который будет обращаться с подчинёнными как стереотипный американский сержант к рекрутам и пишем общее письмо «R&D дураки, секретарше и бухам — премию, остальным — банан, с новым годом, крысы» и вся разработка сама разбежится. Без доп. окладов и по собственному.
Но не понятно, как собрать команду вместо прошлой (слухи-то пойдут, как объяснить потенциальному работнику, почему вся команда разбежалась?) и кто будет в это время выполнять контракты?
Но не понятно, как собрать команду вместо прошлой (слухи-то пойдут, как объяснить потенциальному работнику, почему вся команда разбежалась?) и кто будет в это время выполнять контракты?
У нас есть Hadoop кластер, Redis с журналированием изменения раз в минуту и mysql с терабайтной базой, что будем ставить на hdd и что на ssd и почему?
Ответ простой: «Извините, вы нам не подходите». Это работа админов.
Как использовать кластерный индекс в таком случае и почему он сможет нас спасти?
Как ни странно неплохой вопрос. Однако, если у вас все настолько плохо то ничто вас не спасет)
Да на все эти вопросы можно выучить (или получить эксперементальным путем) ответы и без всякого понимания как база данных работает изнутри, только это будет куда дольше.
Или открыть мануал по индексам где все это подробно и кратко описано.
Кроме того, спустя годы это можно просто знать.
На самом деле вопросами лично я впечатлен (хотя на вопрос типо «как» я бы ответил «понятия не имею», для экономии времени). Но беседу я думаю можно было бы составить интересную. Вот только у меня прям сильные сомнения, что такое вообще возможно.
Если у компании так остро стоит вопрос с БД, производительностью и индексами — они просто должны иметь выделенных людей, которые специализированно занимаются только БД. Если они от каждого требуют такой специализации — то они просто забивают мозги своим работникам. Если у них проблем с производительностью на самом деле нет, а они требуют знаний от каждого — значит тем более забивают мозги.
Скорее всего просто компания не может нанять себе нормального узкоспециализированного профессионала по БД, а требует знаний от каждого вновь пришедшего разработчика. Короче свои косяки за счет кандидатов решают. И сразу большой вопрос стоит ли с такой компанией связываться.
Скорее всего просто компания не может нанять себе нормального узкоспециализированного профессионала по БД, а требует знаний от каждого вновь пришедшего разработчика. Короче свои косяки за счет кандидатов решают. И сразу большой вопрос стоит ли с такой компанией связываться.
Да тут дело в другом, на хабре секта расчетчиков алгоритмической сложности, причем аргументов от них я добиться ни разу так и не смог. Это забавно, учитывая голод на рынке кадров и тот факт, что люди, работающие с базой, SQL не знают.
Ну нужно понимать психологию людей же.
Первое — «Я начальник ты дурак»; это прямо с собеседования начинается. Если не унизить, нельзя будет на зарплату продавить.
Второе — «Может им ещё и печеньки покупать»; если компания не «современная модная молодёжная», то людей реально корёжит от того, что обычный человек может что-то получать, не выпрыгивая из штанов от натуги.
В России процветает социал-дарвинизм самого низкого пошиба, когда если ты не гений — ты должен даже не бедно жить, а просто тупо умереть. Причём те, кто его продвигает, сами далеко не гении, от того фрустрация и ненависть к обычным людям — не сильно напрягающимся, допускающим ошибки — ещё сильнее, т.к. эти люди «позволяют себе» быть обычными, а такого НЕЛЬЗЯ, они все должны умереть, если они не атланты.
Третье — «Принцеждалки»; ну тут всё просто, вакансия может висеть полгода, год, но её не закроют любым подходящим сотрудником, только тем, кто сразу пишет на доске код без ошибок, знает про круглые люки и работает за 45к (gross).
Всё это работает исключительно благодаря тому, что процентов 90 денег на рынке идут не из труда людей. То есть труд людей нужен, но он не принципиален: продажа идёт либо картельно, либо за бюджетные деньги, либо всё вместе, в этом смысле качество продукта или скорость его поставки не важны, так что можно проявлять любое самодурство.
Кстати, забавнейший парадокс.
С одной стороны так как качество не важно — можно было бы набрать абы кого; и часто именно так и делают, например, устраивают по блату или в госучреждения за копейки с улицы собирают. С другой стороны — но если уж соискатель придёт на вакансию, нельзя его взять, если он не мега-гига-мозг, потому что а как же тогда потешить своё эго?
Первое — «Я начальник ты дурак»; это прямо с собеседования начинается. Если не унизить, нельзя будет на зарплату продавить.
Второе — «Может им ещё и печеньки покупать»; если компания не «современная модная молодёжная», то людей реально корёжит от того, что обычный человек может что-то получать, не выпрыгивая из штанов от натуги.
В России процветает социал-дарвинизм самого низкого пошиба, когда если ты не гений — ты должен даже не бедно жить, а просто тупо умереть. Причём те, кто его продвигает, сами далеко не гении, от того фрустрация и ненависть к обычным людям — не сильно напрягающимся, допускающим ошибки — ещё сильнее, т.к. эти люди «позволяют себе» быть обычными, а такого НЕЛЬЗЯ, они все должны умереть, если они не атланты.
Третье — «Принцеждалки»; ну тут всё просто, вакансия может висеть полгода, год, но её не закроют любым подходящим сотрудником, только тем, кто сразу пишет на доске код без ошибок, знает про круглые люки и работает за 45к (gross).
Всё это работает исключительно благодаря тому, что процентов 90 денег на рынке идут не из труда людей. То есть труд людей нужен, но он не принципиален: продажа идёт либо картельно, либо за бюджетные деньги, либо всё вместе, в этом смысле качество продукта или скорость его поставки не важны, так что можно проявлять любое самодурство.
Кстати, забавнейший парадокс.
С одной стороны так как качество не важно — можно было бы набрать абы кого; и часто именно так и делают, например, устраивают по блату или в госучреждения за копейки с улицы собирают. С другой стороны — но если уж соискатель придёт на вакансию, нельзя его взять, если он не мега-гига-мозг, потому что а как же тогда потешить своё эго?
Как раз была недавно статья про красную модель управления)
На самом деле проблема не в том, что вещи типо big o совсем уж бесполезны, а в том, что запредельное количество людей, хнающих всю теорию на зубок, не способны решать практические задачи на хорошем уровне.
Нет безусловной корреляции между знанием сложности алгоритмов и написанием эффективного кода
На самом деле проблема не в том, что вещи типо big o совсем уж бесполезны, а в том, что запредельное количество людей, хнающих всю теорию на зубок, не способны решать практические задачи на хорошем уровне.
Нет безусловной корреляции между знанием сложности алгоритмов и написанием эффективного кода
Ну, если человек знает как, когда и зачем использовать индексы — зачем ему знать знать их алгоритмическую сложность или доскональное устройство? )
Ну прямо 100% доскональное устройство может и не за чем, но вот понимание чем «кластерный индекс отличается от некластерного и чем один лучше другого» или в каком порядке лучше добавить колонки в составной индекс и почему порядок «пол возраст фио» лучше/хуже чем «фио возраст пол» может очень ускорить решения проблем с производительностью.
Вообще, если не понимать как работает та или иная база данных хотя бы в общих чертах можно не понять почему для sql базы данных лучше использовать ssd, а для Hadoop кластера или in-memory базы данных часто вполне можно обойтись и hdd.
Вообще, если не понимать как работает та или иная база данных хотя бы в общих чертах можно не понять почему для sql базы данных лучше использовать ssd, а для Hadoop кластера или in-memory базы данных часто вполне можно обойтись и hdd.
Ну прямо 100% доскональное устройство может и не за чем, но вот понимание чем «кластерный индекс отличается от некластерного и чем один лучше другого» или в каком порядке лучше добавить колонки в составной индекс и почему порядок «пол возраст фио» лучше/хуже чем «фио возраст пол» может очень ускорить решения проблем с производительностью.
Ну так ни для чего из этого не надо знать ни алгоритмической сложности, ни даже того что индексы это B-деревья. Достаточно знать когда и что использовать.
Более того, я не помню задачь, которые бы требовали этого знания. Я знаю задачи, которые требуют знания свойств этих индексов и правил по работе с ними. =)
Вообще, если не понимать как работает та или иная база данных хотя бы в общих чертах можно не понять почему для sql базы данных лучше использовать ssd, а для Hadoop кластера или in-memory базы данных часто вполне можно обойтись и hdd.Тут такое дело… попробуйте предложить задачи, где действительно нужно знать устройство изнутри, а не достаточно знать поведение инструмента там и сям. =)
Обычно это или очень нетипичные случаи и проблемы, которые или решаются обходом (что чаще всего возможно), либо просто неоптимально. (и такое бывает)… но в «рамках бюджета».
Или разработка чего то нового на этих принципах или доработка этих самых механизмов. Что задача совсем для других людей.
ни алгоритмической сложности, ни даже того что индексы это B-деревья. Достаточно знать когда и что использовать.
С одной стороны, да, чаще всего не нужно. С другой, получается такая класическая блондинка на автомобиле, которая выучила, что дизель лучше в ее автомобиль не лить, но слабо представляется зачем нужен скажем аккамулятор и чем антифриз отличается от масла.
ИМХО, для программиста не очень хорошо быть объязьяной с гранатой, рано или поздно можно условно залить антифриз вместо масла или с удивлением обнаружить, что если на ночь оставить автомобиль с включенными фарами, он почему-то утром не заведется.
Ну кстати зная что индекс это дерево — точно не забудешь что лучше индексы по высокоселективным полям делать, не, это конечно можно и как заклинание для черного ящика запомнить, но все же.
Да и БД знать не нужно, ORM всё сделает.
Передергиваете.
Про Б-деревья можно спросить в контексте любой реляционной БД
Они есть, нормальный ответ?) Меня пугает тенденция спрашивать про то, что человеку не нужно будет ровным счетом никогда.
Мне тоже задавали такие вопросы, если в ответ спросить как это знание используется в работе, станет ну очень интересно.
У меня вот кстати поинтересней вопрос есть и с ним должен быть знаком абсолютно каждый разработчик:
Как выглядит запрос автокомплитера и как он индексируется.
У нас GiST кстати не используются, я просто мануалы по используемым БД читаю иногда, вдруг есть интересные штуки.
То есть, на секундочку, я правильно понял: вы являетесь наглядной иллюстрацией статьи? Спрошу то, что мы не используем, и сам я не знаю?)
UPD О еще один вопросик знаю, тоже очень простой, но полный заблуждений:
у вас есть сервис с ЦА — корпоративные пользователи
Таблица пользователей: account_id, user_id, email, name, is_deleted
Почта является логином, как должен выглядеть по ней индекс?
НЛО прилетело и опубликовало эту надпись здесь
Без понятия, я не занимался разработкой IDE или чего-то похожего.
Ну да, и сайтов с формами у вас тоже нет? Поиск по подстроке есть абсолютно везде и всюду.
А про ORM кстати не шутка. Есть у меня знакомый синьор, почти 8 лет опыта, и в БД ни бум-бум. ORM работает и ничего. Ну вот не было у него необходимости писать запросы или смотреть чего там в БД тормозит.
В своей узкой нише и такое возможно.
Просто на правах возгласа из зала: за 20 с хреном лет поиск по подстроке мне ни разу не понадобился :) Ну, насколько могу вспомнить.
Но я знаю, что перебором эту задачу решать не надо (за исключением узких случаев), существуют всякие алгоритмы суффиксных деревьев и т.п., про что я кроме названия (и то очень неуверенно) не знаю ничего. Но я хотя бы знаю, что если будет такая задача — надо пойти и разобраться, а не говорить «ну я же не знаю O-нотации, и в ТЗ не было требования какой-то конкретный алгоритм применить, поэтому я буду делать полным перебором».
Но я знаю, что перебором эту задачу решать не надо (за исключением узких случаев), существуют всякие алгоритмы суффиксных деревьев и т.п., про что я кроме названия (и то очень неуверенно) не знаю ничего. Но я хотя бы знаю, что если будет такая задача — надо пойти и разобраться, а не говорить «ну я же не знаю O-нотации, и в ТЗ не было требования какой-то конкретный алгоритм применить, поэтому я буду делать полным перебором».
Просто на правах возгласа из зала: за 20 с хреном лет поиск по подстроке мне ни разу не понадобился :) Ну, насколько могу вспомнить.
Видимо специфическая у вас область, я не догадываюсь как должны выглядеть интерфейсы без автокомплита.
надо пойти и разобраться
И в большинстве случаев этот разбор оканчивается на like %pattern%, мимо индекса.
Разбираться, кстати, в области поиска не так просто, особенно, скажем, в области поиска нечетких дубликатов: по некой причине информации исчезающе мало.
НЛО прилетело и опубликовало эту надпись здесь
Да как бы не все занимаются интефейсами.
Зато бОльшая часть занимается таки тем что юзают пользователи) А на беке или фронте это уже не суть важно
А если к этому пршпилить тертарное дерево...
Ну начнем с того что человек не ищет вхождение с любой позиции, а только с начала слова, так что на самом деле патерн должен выглядеть иначе, а значит regexp. А дальше таки да, возможно, вот только с пришпиливанием на уровне бд могут быть проблемы.
не догадываюсь как должны выглядеть интерфейсы без автокомплита
Автокомплит в сложных случаях предполагает передачу подстроки в условный Sphinx и невозбранное получение сниппетов и кучу других фишек.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, это скорее «проклятие знания», чем «ретроспективное искажение»/«послезнание».
Просто разработчики с опытом 15 лет надеются что кандидат готовился к собеседованию. Просто если кандидат не знает и к собеседованию не готовился, то велик шанс получить довольно «вальяжного» работника.
Это мне напоминает один психологический факт. Дети до какого-то возраста не могут понять сказку про Белоснежку. Почему она ест отравленное яблоко? Ведь это известно, что оно отравлено! У них в голове не укладывается то, что у другого человека может быть совершенно другой «контекст», другие знания. Может это как-то связано?
Вроде как отсутствие «модели разума» (theory of mind) после 4-5 лет один из признаков расстройств аутистического спектра.
Не раз на собесах мне задавали вопросы о вещах, которые не используются в реальных проектах (так собеседующие потом признавались). Т.е. надо было знать некоторые хаки, трюки. Гнать таких собеседующих.
Также, по-моему мнению, не надо задавать вопросов о вещах, которые легко и быстро изучаются. Лучше говорить либо о проектах и опыте, либо о базе. Серьёзно, какова ценность знаний, которые можно получить в течение дня? Как то раз меня спросили, использовал ли я gRPC. На тот момент ещё не использовал, о чём и сказал. Но уже через день работал с ним.
Также, по-моему мнению, не надо задавать вопросов о вещах, которые легко и быстро изучаются. Лучше говорить либо о проектах и опыте, либо о базе. Серьёзно, какова ценность знаний, которые можно получить в течение дня? Как то раз меня спросили, использовал ли я gRPC. На тот момент ещё не использовал, о чём и сказал. Но уже через день работал с ним.
Ставя себя на место собеседующего — про вещи которые не используются в реальных проектах можно говорить для проверки широты кругозора собеседуемого и его интерес к теме. Главное себе отчет отдавать что кругозор собеседуемого может оказаться пусть и широким, но в другую сторону, и тогда обсудить толком не получится.
НЛО прилетело и опубликовало эту надпись здесь
По хорошему со статьёй я согласен. Кроме пункта про тестовые задания. Это конечно очень субъективно и каждый такое должен решать для себя сам, но лично я собеседования с тестовыми заданиями обхожу стороной.
Может это только мне так не везло, но пока наличие тестовых заданий на собеседовании сильно коррелировало с неадекватностью фирмы…
Да и задания по большей части были не то чтобы особо «полезными».
Может это только мне так не везло, но пока наличие тестовых заданий на собеседовании сильно коррелировало с неадекватностью фирмы…
Да и задания по большей части были не то чтобы особо «полезными».
Если тестовое задание делается за пару часов, то сделать его может быть быстрее, чем топать на очное собеседование в другой конец города. Да и адекватные работодатели вполне спокойно принимают «чужие» тестовые, если они +- подходят по профилю.
Если тестовое задание делается за пару часов, то сделать его может быть быстрее, чем топать на очное собеседование в другой конец города.
Подождите, топаете на другой конец города вы или фирма? Сделанное тестовое задание избавит вас от этого самого топания? То есть для фирмы это может быть и удобно, но я не совсем понимаю что в этом случае выигрывает кандидат.
В общем случае, кандидату надо:
— оторвать задницу
— «привести себя во внешний вид» (умыться, приодеться, накраситься и т.д.)
— добраться до офиса, с запасом а пробки
— подождать, когда пройдёт запас на пробки
— пол часа в стрессовом состоянии разгадывать не смешные загадки
— поговорить за жизнь
— добраться обратно до дома
Дополнительно:
— если это в рабочее время, нет пп. 1 и 2, но надо как-то хитро отпроситься с основной работы
— к разгадыванию загадок надо готовиться, а заучивание наизусть тонны ненужной фигни отнимает немало времени.
Если решением тестового я повышу «конверсию» этой цепочки с 5% до хотя бы 30%, убрав при этом из неё пункт про разгадывание загадок, то 2-3 часа времени работы в комфортной обстановке это вполне окупят.
Если это первый этап отбора в большую контору, то может и пары дней не жалко будет, потому что там времени уходит ещё больше, а конверсия меньше.
— оторвать задницу
— «привести себя во внешний вид» (умыться, приодеться, накраситься и т.д.)
— добраться до офиса, с запасом а пробки
— подождать, когда пройдёт запас на пробки
— пол часа в стрессовом состоянии разгадывать не смешные загадки
— поговорить за жизнь
— добраться обратно до дома
Дополнительно:
— если это в рабочее время, нет пп. 1 и 2, но надо как-то хитро отпроситься с основной работы
— к разгадыванию загадок надо готовиться, а заучивание наизусть тонны ненужной фигни отнимает немало времени.
Если решением тестового я повышу «конверсию» этой цепочки с 5% до хотя бы 30%, убрав при этом из неё пункт про разгадывание загадок, то 2-3 часа времени работы в комфортной обстановке это вполне окупят.
Если это первый этап отбора в большую контору, то может и пары дней не жалко будет, потому что там времени уходит ещё больше, а конверсия меньше.
Ок, вы ишодите из того что если человек срежется на тестовом задании, то ему никуда ехать не надо и тем самым он экономит себе время.
Вот только я на моей памяти на тестовых заданиях срезался только первые пару раз когда вообще не был готов к чему-то подобному. И как минимум с тех пор как я стал миддлом(а это было много-много лет назад) причиной по которой из собеседований ничего путного не выходило было либо расхождение в понимании того что считать адекватной зарплатой, либо какие-то личностные несовпадения с будущими коллегами/начальством. И следовательно для меня как кандидата эти самые тестовые задания особой пользы не несут,
На администраторов linux-систем через тестовые задания приходилось искать. Причём ничего фееричного — вот тебе машинка голой… опой в интернет, надо какой-то минимально допустимый уровень защиты сделать (настроить firewall, подумать нужен ли ssh на стандартном порту с паролями — если нет, что-нибудь сделать) и развернуть мини-сайтик (для простоты — допустим, вордпресс).
Не поверите, из 20-25 человек приходивших на собеседование прямо на месте этим занимался только один, остальные брали домой, забывали про firewalld и теряли управление по ssh.
Итого — решило всего два человека. Один который делал всё на месте управление и логично (не всё знал, но быстро гуглил — его и взяли), и ещё один настоящий параноик, который применил кучу знаний и кучу хаков, был крут и неизмеримо превосходил тот уровень (и знаний, и ЗП) который мы искали…
Не поверите, из 20-25 человек приходивших на собеседование прямо на месте этим занимался только один, остальные брали домой, забывали про firewalld и теряли управление по ssh.
Итого — решило всего два человека. Один который делал всё на месте управление и логично (не всё знал, но быстро гуглил — его и взяли), и ещё один настоящий параноик, который применил кучу знаний и кучу хаков, был крут и неизмеримо превосходил тот уровень (и знаний, и ЗП) который мы искали…
Ну я в администрировании линукс-систем не осбо разбираюсь, но вы хотите сказать что без тестового задания адекватность кандидата выяснить невозможно?
Возможно, но дороже. Правильные тестовые хорошо снижают затраты собеседующего. Естественно, как у любого фильтра есть потери потенциально хороших кандидатов. Но если есть поток кандидатов и многие валятся на похожих темах, а собеседования жрут много времени, то стоит включить в тестовое задание темы без освоения которых дальше разговор вести нет смысла. Мои тестовые (если применяю) всего 3-4 простеньких задач на программирование, задаваемые после скайп созвона и до приглашения в офис.
Возможно, но дороже. Правильные тестовые хорошо снижают затраты собеседующего.
Но всё это увеличивает "затраты собеседуемого". И если учитывать что есть куча фирм без подобных глупостей, то при прочих равных я в такую фирму на собеседование скорее всего не пойду.
Мои тестовые (если применяю) всего 3-4 простеньких задач на программирование, задаваемые после скайп созвона и до приглашения в офис.
Когда мне в своё время в течении двух недель на трёх собеседованиях предложили написать FizzBuzz мне было сложно воспринимать всё это всерьёз...
Это нормально, каждый ищет так как ему выгоднее. Я же написал что такой метод нужно применять если кандидатов много, т.е. больше чем вы можете качественно отсобеседовать. То есть варианта отсобеседовать все хорошо выглядящие отклики в принципе нет и не предвидится. В таком случае у вас есть несколько вариантов
Как видите в описанной ситуации опции сделать всё и на отлично нет. Есть опция достичь лучшего результата за имеющееся время. А так как многие хорошие программисты плохие ораторы и плохие составители резюме, шанс я даю если резюме попадает в категорию приемлемо. Считаю что из 20 резюме предложить тестовое и скайп созвон десяти людям, и потом провести одно-два полноценных собеседований в офисе лучше чем сразу назначить 3-4 полноценных собеседований. Затраты моего времени примерно равны, возможностей проявить себя кандидатам — больше. Такова жизнь.
- прекратить заниматься вообще всем, кроме собеседований, и при большом потоке вы всё равно всех не успеете отсобеседовать
- Сильно завысить планку по тексту резюме и приглашать на собеседование только тех кто написали идеальное резюме
- просто поставить всех в очередь кому-то сказать что вас пригласят на собеседование через две недели, может быть. В результате кто-то откажется, а самые невостребованные на рынке дождутся
- и собственно работать над сокращением времени затрачиваемого на одного кандидата, пытаясь оценить его не только по резюме, но до полноценного собеседования. И тут я применяю два метода, скайп созвон и тестовое задание. Иногда всё вместе, иногда по отдельности. Да также есть те кто откажутся.
Как видите в описанной ситуации опции сделать всё и на отлично нет. Есть опция достичь лучшего результата за имеющееся время. А так как многие хорошие программисты плохие ораторы и плохие составители резюме, шанс я даю если резюме попадает в категорию приемлемо. Считаю что из 20 резюме предложить тестовое и скайп созвон десяти людям, и потом провести одно-два полноценных собеседований в офисе лучше чем сразу назначить 3-4 полноценных собеседований. Затраты моего времени примерно равны, возможностей проявить себя кандидатам — больше. Такова жизнь.
И да, и нет. Оценить насколько человек адекватен в разговоре — легко можно без задания. Оценить насколько он адекватен в решении конкретного круга задач — чуть-чуть сложнее FizzBuzz, но таки имеющих прикладной смысл — бесценно, уж поверьте. Кроме того, при поиске администратора почему-то ссылок на гитхаб, как правило, не дают. Ну и во фразе «мы решили делать ХХХ, потому что УУУ» почти всегда есть некая доля вклада личности в это «мы», которую при разговоре оценить не получится. Остальное вложили его коллеги, которые зачастую продолжают работать на предыдущем месте работы соискателя. Ну и почти всегда есть больше одного способа решить возникающие проблемы, а вот что именно выбрать и почему — только от человека и зависит, а без его реального рукоприкладства это весьма нелегко оценить…
В общем тестовое задание доставалось совершенно не всем. С кем мы сразу точно не смогли бы сработаться по каким-либо причинам мы вежливо отказывали сразу, дабы не тратить их время.
В общем тестовое задание доставалось совершенно не всем. С кем мы сразу точно не смогли бы сработаться по каким-либо причинам мы вежливо отказывали сразу, дабы не тратить их время.
Причём ничего фееричного — вот тебе машинка голой… опой в интернет, надо какой-то минимально допустимый уровень защиты сделать (настроить firewall, подумать нужен ли ssh на стандартном порту с паролями — если нет, что-нибудь сделать) и развернуть мини-сайтик (для простоты — допустим, вордпресс)
гхм… адекватность задания сомнительна.
вот у меня есть хостов "голой попой в интернет", и почти нигде нет файрвола.
и на этих хостах есть сайты с >100к посетителей в день, и при этом я ни разу не сталкивался с wordpress, задание "поставить wordpress" загнало бы меня в ступор (не, я бы поставил, конечно, но вот если бы это пришлось делать прямо на собеседовании — это был бы стресс).
P.S. и да, везде ssh на стандартном порту. правда, отключен вход по паролям.
Wordpress для примера. Что угодно вообще, лишь бы оно работало на распространённом веб-сервере. А вот конкретно с вами мы, скорее всего, не сработались бы: с точки зрения моей компании, работающий файрволл на сервере, торчащем в интернет — это элементарная цифровая гигиена, как руки помыть. Не обязательно что-то произойдёт, но это лишняя степень защиты (с руками таже история — не обязательно вы немедленно заболеете кишечником, если мыть их не будете).
гигиена — это не вешать внутренние сервисы на внешние адреса.
раз вы заговорили про wordpress — для тестового задания на хосте нам нужны ssh, nginx на внешнем интерфейсе, mysql и php-fpm на localhost (честно потратил пару минут чтобы погуглить на чём там wordpress работает).
что из этого мы хотим защитить файрволом и от чего?!?
ИМХО файрвол нужен, если:
- у нас роутер и нужно ограничить трафик других хостов (которые зачастую админятся не нами);
- нам таки нужно сделать какой-то сервис доступным из интернета без VPN, но не для всех.
Да, iptables/nftables используются для всяких продвинутых вещей вроде легковесных счётчиков для мониторинга сетевого трафика, или управления шейпером — но это, всё-таки, не файрвол.
Недавно где-то рядом была тема про отключенный файрволл, не слушающие на внешних адресах сервисы и IPv6, который внезапно пошёл в массы, а по IPv6 многие "интересные" сервисы слушали "всё"…
Так что firewalld и selinux всё-таки лучше не отключать, а правильно настраивать.
Статьи по настройке linux-серверов, содержащих отключение файрволла и selinux стараюсь обходить стороной.
А использовать netstat -nlp для контроля немодно?
Полезно. Но какой-то давным-давно настроенный пакет, после обновления, может внезапно получить поддержку IPv6, а культура мониторинга изменений может оставлять желать много лучшего… как по мне, лучше все потенциальные дырки будущего закрыть сразу, умелыми руками, так как дальнейшее сопровождение сервера возможно специалистом менее прозорливым.
нужен ли ssh на стандартном порту с паролями — если нет, что-нибудь сделатьА что не так с ssh на стандартном порту? Много где встечаю, что ssh переносят на другой порт, но никак не пойму какой в этом смысл.
Security through obscurity работает, хоть и считается плохой практикой. Т.е. это не создаёт никаких гарантий, но если вы посмотрите в логах количество попыток произвести вход на ssh открытый на 22 порту и на другом то вы увидите кратное снижение количества атак. Да, по хорошему нужно закрыть авторизацию по паролю и использовать только ключи, но не всегда это реализуемо. Но снижение потока попыток входа таки снижает шанс проникновения. Подчеркну снижает а не исключает.
да на самом деле и во входе по паролям ничего особо страшного нет, достаточно не использовать короткие/словарные пароли.
перенос ssh на другой порт снижает количество попыток, увеличивает время до первой попытки, но как правило не влияет на качество попыток. то есть, если идет перебор по словарю (а сейчас еще и идет по графику с обходом стандартных правил fail2ban), то нормальный пароль (разный на каждый сервер и пользователя) дает достаточную защиту.
сертификаты где-то интересней, но несколько не такие гибкие (не всегда удобно использовать сертификаты)
ну и вполне можно натолкнуться на сеть, где запрещен исходящий трафик на нестандартные порты. просто на всякий случай.
ну и мое любимое неудобство — вспоминать, какой же там порт для ssh. и если он не отвечает — это ssh-server лег или я порт не тот пишу?
к слову — на собеседовании пытались меня убедить, что я не прав — ну не было у меня логов, подтверждающих, что меня "ломали" несколько лет подряд и не смогли. и это не я так защищаюсь, это так ломают
Добавлю еще табу от себя:
1) На собеседовании больше двух человек. Значит ребята не умеют проводить собеседования. Ваше внимание будет рассеяно и может появится дурацкое чувство «один против троих». Также это косвенно говорит о том, что компания не в состоянии организовать две-три отдельных встречи с кандидатом. Представьте, как у них плохо с организацией более сложных вещей!
2) Вам пришлось рассказывать что-то о себе дважды. Частично пересекается с первым пунктом, часто это из-за того, что кто-то опоздал и не выслушал часть истории. Взрослые люди не могут придти вдвоем на встречу вовремя, вы хотите с такими работать?
3) Техническое собеседование по скайпу. Вам работать с людьми, а вы их даже не видели. Просите тогда собеседоваться в слаке, чтобы другой рукой можно было кушать, чтоб «время не терять».
4) Не пришлось писать код. Автор уже рассказал, но я повторюсь, это же капец как важно.
5) Какие-то проблемы с проведением собеседования в нерабочее время или его назначение через неделю. Если провести аналогию со свиданиями, то кажется, что вами не особо заинтересовались. Скорее всего проблема в вас, вы это осознаете и не понимаете, почему вы молча не можете просто перестать друг другу звонить и писать. Бывало, мне через неделю перезванивали, предлагали еще через неделю придти на собеседование. То есть в сумме через две недели после первоначального созвона. Bruh.
6) Вопросы о желаемой зарплате до технического собеседования. Вы еще не поняли, что, как и с кем будете делать, а вас спрашивают, сколько вы за это хотите. На самом деле, это hr-уловка, чтобы вам меньше платить, но для 2020 прием довольно грязный, косвенно это говорит о том, что компания неприличная.
1) На собеседовании больше двух человек. Значит ребята не умеют проводить собеседования. Ваше внимание будет рассеяно и может появится дурацкое чувство «один против троих». Также это косвенно говорит о том, что компания не в состоянии организовать две-три отдельных встречи с кандидатом. Представьте, как у них плохо с организацией более сложных вещей!
2) Вам пришлось рассказывать что-то о себе дважды. Частично пересекается с первым пунктом, часто это из-за того, что кто-то опоздал и не выслушал часть истории. Взрослые люди не могут придти вдвоем на встречу вовремя, вы хотите с такими работать?
3) Техническое собеседование по скайпу. Вам работать с людьми, а вы их даже не видели. Просите тогда собеседоваться в слаке, чтобы другой рукой можно было кушать, чтоб «время не терять».
4) Не пришлось писать код. Автор уже рассказал, но я повторюсь, это же капец как важно.
5) Какие-то проблемы с проведением собеседования в нерабочее время или его назначение через неделю. Если провести аналогию со свиданиями, то кажется, что вами не особо заинтересовались. Скорее всего проблема в вас, вы это осознаете и не понимаете, почему вы молча не можете просто перестать друг другу звонить и писать. Бывало, мне через неделю перезванивали, предлагали еще через неделю придти на собеседование. То есть в сумме через две недели после первоначального созвона. Bruh.
6) Вопросы о желаемой зарплате до технического собеседования. Вы еще не поняли, что, как и с кем будете делать, а вас спрашивают, сколько вы за это хотите. На самом деле, это hr-уловка, чтобы вам меньше платить, но для 2020 прием довольно грязный, косвенно это говорит о том, что компания неприличная.
Техническое собеседование по скайпу.
А с этим-то какие проблемы? Это норма жизни для распределенных контор. И для «видеть» есть вёбка — вот если вас контора просит собеседоваться без вебки, то это повод насторожиться.
Не понял вас насчет 6го пункта, вы предлагаете сначала проходить тех собеседование, а потом только называть зарплату, которую вы хотите получать? На мой вкус лучше сразу договориться на берегу, чем пройти собеседование и потом выяснить, что у компании в принципе нет такого бюджета на вашу зп. Да, я думаю, большинство кандидатов всегда держит в голове фиксированную сумму, у них нет такого «ой тут у вас все под винду — накиньте как десяточку к зп» или «ой, вы макбук даете, ну десяточку я вам скину тогда». В чем опять же смысл выяснения зарплаты до того, как вы узнаете что за работа? Только зря потраченное время в случае, если работодатель не готов вам платить желаемую зп.
Я бы накидывал 25% к требованию зп после уточнения на собеседовании, что удалённой работы нет и невозможно.
Потому что 2-3 часа в день ради перемещения тушки в офис — это тоже работа. Тяжёлая и опасная из-за повышенных эпидемических рисков, требующая компенсации на ежедневные траты (иногда включающие в себя повышенную цену на еду из-за невозможности приготовить дома обед).
Потому что 2-3 часа в день ради перемещения тушки в офис — это тоже работа. Тяжёлая и опасная из-за повышенных эпидемических рисков, требующая компенсации на ежедневные траты (иногда включающие в себя повышенную цену на еду из-за невозможности приготовить дома обед).
большинство кандидатов всегда держит в голове фиксированную сумму
Держит, конечно. Но во-первых могут быть факторы, которые на решение повлияют:
— есть еще одно предложение, но с более интересными задачами и той же суммой — «накиньте десяточку»;
— все нравится, но оказалось что до офиса нужно на электричке ехать дальше и дольше, чем вы рассчитывали;
— есть гарантии в регулярной индексации / повышении зарплаты за успешные успехи;
Не все смогут назвав цифру предварительно, «поторговаться» после выяснения важных деталей, не описанных в вакансии. Поэтому страшно называть сумму заранее. Я уж не буду упоминать про «а вдруг я приду к ним синьором, а денег на самом деле попрошу столько, сколько они платят даже джуниорам, буду как лох».
К тому же сумма которую «хотите получать», может по-разному формироваться. Для кого-то это «ипотека + алименты + покушать + два раза в год в отпуск», кому-то «каждый день в бар и чтобы перед пацанами не стыдно».
у компании в принципе нет такого бюджета на вашу зп
Тогда компании стоило бы какую-то вилку или ориентировочную зарплату указать, не?
«Минимум я хочу столько, но точно мы обсудим после технического собеседования».
Не собираюсь поддерживать подход «просто хочу найти работу, где бы мне платили минималку». С таким подходом вы всегда будете мало зарабатывать.
Не собираюсь поддерживать подход «просто хочу найти работу, где бы мне платили минималку». С таким подходом вы всегда будете мало зарабатывать.
«Я готов разговаривать о сумме от… рублей. Конкретная сумма зависит от списка доп. обязанностей и бонусов (скидки на фитнес, ДМС, стоимости еды в около офиса, удалённая работа, плавающий график и прочие кофемашины в офисе)» — по-моему, это достаточно прямо и честно.
Забавно, что в некоторых случаях при озвучке пункта «от» люди извиняются и уходят со словами «не, мы столько не выбьем». Уважаемые, однако, здравствуйте, это же у меня было написано в резюме, неужели никто их не читает?
Забавно, что в некоторых случаях при озвучке пункта «от» люди извиняются и уходят со словами «не, мы столько не выбьем». Уважаемые, однако, здравствуйте, это же у меня было написано в резюме, неужели никто их не читает?
неужели никто их не читает?
А вы что думаете, что читают? У кого-то есть время читать сотни однотипных резюме? Мельком пробегают по списку скиллов и готово.
Уважаемые, однако, здравствуйте, это же у меня было написано в резюме, неужели никто их не читает?
А ещё многие пишут в резюме завышенную зарплату чтобы не надоедали рекрутёры, а ещё некоторые (как в комментарии выше) пишут свою текущую + 25%. И ещё много других вариантов. Так что в любом случае лучше уточнить этот момент.
Вы шутите?!
Нет, серьёзно, люди выходят на рынок труда и делают так, чтоб им не звонили рекрутёры??
Теперь я не понимаю обе стороны.
Нет, серьёзно, люди выходят на рынок труда и делают так, чтоб им не звонили рекрутёры??
Теперь я не понимаю обе стороны.
Ну, у меня такая проблема. Та фирма, на которою я сейчас работаю, меня почти полностью устраивает, да и переходить в другое место я не собираюсь, как минимум, год.
Однако мне с завидной регулярностью на почту пишут рекрутёры, хотя у меня на всех сервисах поиска работы типа хедхантера, моего круга, линкедина и прочих стоит, что работу не особенно ищу. Но тем кто пишет на почту – я раз-два в месяц отвечаю, мол, спасибо, но работа не нужна. ЧСХ, пишут голые вакансии, без указания компании и зарплатной вилки. Я так понимаю, это уже идёт холодная рассылка по внутренним базам рекрутёров.
Но если мне рекрутёры ещё и звонить на телефон будут – это будет чересчур.
Почему тогда не закрыть резюме? о_О
Потому что не везде его можно «закрыть». LinkedIn, МойКруг и прочие места всегда держут ваш профиль, и максимум, что вы можете изменить это значение переключателя сверху «ищу работу / рассматриваю предложения / не ищу работу».
И всегда будут люди, которые даже будут вам писать, даже если у вас будет стоять «не ищу работу». Ну, потому что так дешевле. Да, именно дешевле. Дешевле отспамить всем, у кого навыки совпали, вдруг кто-нибудь да отзовется.
И всегда будут люди, которые даже будут вам писать, даже если у вас будет стоять «не ищу работу». Ну, потому что так дешевле. Да, именно дешевле. Дешевле отспамить всем, у кого навыки совпали, вдруг кто-нибудь да отзовется.
А вдруг предложат работу мечты… Невероятно но вдруг?
На меня как-то рекрутеры вышли по аккаунту на StackOverflow. О каких вообще закрытых резюме идёт речь, если там иногда не просто "холодные звонки", а "звонки абсолютного нуля"?
А у меня, допустим, нет цели чтобы звонили всегда. Мне важно понять, где грань, когда интерес к моему балансу «навыки/$$$» начнет снижаться. Такое маркетинговое исследование :)
А если у вас вообще нет свежего резюме в открытом доступе? А вам регулярно пишут и звонят :) и задают этот дурацкий вопрос про з.п… ну не знаю я за сколько соглашусь работать, а вдруг вы мне предложите 30 часовую неделю, да ещё и по удалёнке ??? :).
Вот скажите сразу "мы рассчитываем на 10 уе склоняемся к 8 но если не найдём готовы к 1.2 а за больше нам и не надо, почему это так сложно? Ведь это бюджет нанимателя...
НЛО прилетело и опубликовало эту надпись здесь
Я понимаю, что для кандидата важен в первую очередь он сам, но и вторую сторону все же имеет смысл оценивать адекватно, а не с точки зрения, что вы — центр вселенной, а остальные должны подстраиваться.
Ваше внимание будет рассеяно и может появится дурацкое чувство «один против троих».
Должна ли компания подстраиваться под психологические особенности каждого кандидата, еще ничего о нем не зная, кроме резюме, вот в чем вопрос? :) А если для вас это действительно настолько важно — попросите при организации собеседования больше 2-х не собираться. ;)
Также это косвенно говорит о том, что компания не в состоянии организовать две-три отдельных встречи с кандидатом.
А зачем, если всё можно решить за одну, и это будет куда быстрее для всех задействованных сторон? Оно вам надо? А компании?
часто это из-за того, что кто-то опоздал и не выслушал часть истории. Взрослые люди не могут придти вдвоем на встречу вовремя, вы хотите с такими работать?
Допустим, собеседование назначено на 10 утра, нач. отдела и техдир. Вы в 9 выезжаете из дома, в 9.37 техдиру звонит генеральный и просит зайти по срочному вопросу на полчасика. Должна ли компания отменить собеседование, чтобы у кандидата, не дай бог, не сложилось представления, что они не взрослые люди? Действительно ли нормальный, вменяемый кандидат не переживет, если "опоздавший" техдир задаст вопрос, который второй человек уже задавал?
Вам работать с людьми, а вы их даже не видели.
Заканчивается 2-я декада 21 века. Я две трети персонала компании, с которым постоянно работаю, видел пару раз по видеоконференции, а во многих компаниях этот процент еще и повыше. :)
Я понимаю, что для кандидата важен в первую очередь он сам, но и вторую сторону все же имеет смысл оценивать адекватно, а не с точки зрения, что вы — центр вселенной, а остальные должны подстраиваться.
Уже повеяло токсичностью. Мне не особо интересно, кем именно вы меня считаете.
Я был в нормальных компаниях, где собеседования проходя поэтапно, и на каждой встрече вы встречаетесь с одним человеком. В том же яндексе так, и в яндексе — охуенно, а практически во всех российских компаниях — хуже.
У вас отсутствует понимание, как бывает хорошо, поэтому да, в вашей картине мира три часа впятером обсуждать с кандидатом где он родился, учился и работал — норма и вы «экономите» время.
Допустим, собеседование назначено на 10 утра, нач. отдела и техдир. Вы в 9 выезжаете из дома, в 9.37 техдиру звонит генеральный и просит зайти по срочному вопросу на полчасика.
Это говорит только о том, что организация — говно, работающее в двух состояниях «нефиг делать/завал». Опять же, если вы не работали где-то лучше, где есть планирование, например, то вам просто не понять.
Действительно ли нормальный, вменяемый кандидат не переживет, если «опоздавший» техдир задаст вопрос, который второй человек уже задавал?
Да. Вменяемый кандидат сразу понимает что управленческий состав профнепригоден и ему нечего делать у этих ребят.
Заканчивается 2-я декада 21 века. Я две трети персонала компании, с которым постоянно работаю, видел пару раз по видеоконференции, а во многих компаниях этот процент еще и повыше. :)
Зачем вы говорите о своих недостатках?
Подитожим:
- Вы считаете возможным придумать некую картину мира, спроецировать ее на совершенно незнакомого вам человека, и на основаниии вашей собственной проекции обвинить его в том, что у него "отсутствует понимание".
- Вы совершенно не представляете себе работу менеджмента, особенно — топ-менеджмента, но считаете возможным со своей высоты делать выводы о профпригодности/непригодности.
- Вы считаете "недостатком" либо наличие в природе территориально распределенных компаний, где между офисами могут быть тысячи километров, либо нежелание тратить такими компаниями деньги на авиаперелеты руководства с целью собеседования людей на низовые позиции.
Мне в принципе всё понятно, в том числе и о "токсичности", спасибо за беседу, мы вам перезвоним. :)
В яндексе совсем не гуманная система собеседований. Вся эта мутная тягомотина с десятком собеседований, растянутых чуть ли не на месяц, и кучей людей, каждый из которых тебя может отфутболить по каким-то своим личным заморочкам — она, как я думаю очень много годных специалистов отбраковывает.
Общался со многими довольно крутыми ребятами — часто слышал историю о том как человек ходил-ходил на собеседования в Яндекс, решал все эти задачки, потом ему предлагали какой-либо вкусный оффер в другую фирму и когда он уже какое-то время работал на новом месте — ему приходило приглашение побеседовать с Финальным Боссом на собеседовании в Яндекс.
Хотя, возможно, это специально сделано так что-бы отсеивать всех кроме студентов, с кучей времени на хождение по собесам, не знаю. С другой стороны — а нафига тогда приглашать, если брать не собираетесь.
Общался со многими довольно крутыми ребятами — часто слышал историю о том как человек ходил-ходил на собеседования в Яндекс, решал все эти задачки, потом ему предлагали какой-либо вкусный оффер в другую фирму и когда он уже какое-то время работал на новом месте — ему приходило приглашение побеседовать с Финальным Боссом на собеседовании в Яндекс.
Хотя, возможно, это специально сделано так что-бы отсеивать всех кроме студентов, с кучей времени на хождение по собесам, не знаю. С другой стороны — а нафига тогда приглашать, если брать не собираетесь.
очень много годных специалистов отбраковывает.Для компании типа Яндекс «false positive» на порядок менее приятен, чем «false negative». Учитывая то количество кандидатов, которые есть у этих компаний, отфутболивание десятков годных специалистов — правильная тактика. Лучше отфутболить 10 годных, чем принять одного негодного.
Прямо-таки много кандидатов?
Как-то это звучит как пресловутое «толпа за забором». У меня что-то нет ощущения переизбытка специалистов на рынке IT. Где-бы не работал — найм дополнительных людей всегда был большой головной болью для руководства.
Как-то это звучит как пресловутое «толпа за забором». У меня что-то нет ощущения переизбытка специалистов на рынке IT. Где-бы не работал — найм дополнительных людей всегда был большой головной болью для руководства.
а что такого особо-особенного в Яндексе что он прям страдает от «плохого» кандидата? я чето не особо вижу обалденного качества их продуктов да и немного наслышан об их внутренней кухне… ничем особым они не отличаются
Как человек немало походивший по собеседованиям имею на этот счет свое сложившееся мнение.
Нет проблемы в том что на интервью пришло несколько человек, кроме некоторого психологического давления на кандидата. Как ни крути это получается положение в котором ты один против всех. Они на одной стороне, друг-друга знают и их интересы примерно совпадают. Если собеседование организовано толково, то это сглаживается тем что оно становится просто беседой, иначе все быстро начинает походить на заседание Инквизиции или допрос в Гестапо.
Что сильно раздражает в таком формате — когда народ приходит с ноутбуками, утыкается в них и чем-то там занимается, не слушая. Что еще больше раздражает, когда такой «отсутствующий» начинает задавать вопросы, которые проговаривались буквально пару минут назад, что показывает что он просто не слушал.
Да, постоянно приходящие/уходящие люди тоже мешают и сбивают с настроя.
Еще что не люблю — вопросы, которые демонстрируют то что резюме не было человеком прочитано даже бегло по диагонали.
Но это так, рабочие моменты, с этим как-то можно еще жить. Хуже всего когда беседа проходит в режиме:
— Что вы знаете про /редко используемая заморочка, которую мало кто держит в «оперативной памяти» и о необходимости знания которой перед собеседованием даже не упоминалось/.
— /Короткий рассказ из того что вспомнил с налета/
— Ну собственно все понятно, если у вас, коллеги вопросов нет, то я все… (демонстративно собирает вещи)
На этом месте как-то сразу думаешь — и нахрена я перся в другой конец города, ждал пока тут все соберутся, обсуждал с ХР всякую ерунду.
Нет проблемы в том что на интервью пришло несколько человек, кроме некоторого психологического давления на кандидата. Как ни крути это получается положение в котором ты один против всех. Они на одной стороне, друг-друга знают и их интересы примерно совпадают. Если собеседование организовано толково, то это сглаживается тем что оно становится просто беседой, иначе все быстро начинает походить на заседание Инквизиции или допрос в Гестапо.
Что сильно раздражает в таком формате — когда народ приходит с ноутбуками, утыкается в них и чем-то там занимается, не слушая. Что еще больше раздражает, когда такой «отсутствующий» начинает задавать вопросы, которые проговаривались буквально пару минут назад, что показывает что он просто не слушал.
Да, постоянно приходящие/уходящие люди тоже мешают и сбивают с настроя.
Еще что не люблю — вопросы, которые демонстрируют то что резюме не было человеком прочитано даже бегло по диагонали.
Но это так, рабочие моменты, с этим как-то можно еще жить. Хуже всего когда беседа проходит в режиме:
— Что вы знаете про /редко используемая заморочка, которую мало кто держит в «оперативной памяти» и о необходимости знания которой перед собеседованием даже не упоминалось/.
— /Короткий рассказ из того что вспомнил с налета/
— Ну собственно все понятно, если у вас, коллеги вопросов нет, то я все… (демонстративно собирает вещи)
На этом месте как-то сразу думаешь — и нахрена я перся в другой конец города, ждал пока тут все соберутся, обсуждал с ХР всякую ерунду.
НЛО прилетело и опубликовало эту надпись здесь
Вопросы о желаемой зарплате до технического собеседования
Однажды увидела в описании вакансии одной очень известной российской IT-компании требование указать желаемый размер зарплаты в сопроводительном письме. Я чуть не поперхнулась от возмущения
А можно спросить в чём проблема? Я достаточно часто так делаю и сообой проблемы в этом не вижу...
Мне кажется, если между соискателем и работодателем на собеседовании случается химия, то последний готов будет платить первому столько, сколько тот попросит. Узнав же в сопроводительном письме, сколько кандидат хочет денег, HR может отказать на этом основании на самом деле классному кандидату. То есть работодатель сужает поиск, и в итоге найдет либо джуниора, либо сотрудника с синдромом самозванца. Но это мое мнение
Ну с одной стороны конечно ситуация кoторую вы описываете не исключена, но на мой взгляд не особо вероятна. С другой стороны вы может потратить кучу времени на собеседование и потом выяснить что вас всё равно не возьмут так как фирма не может или не хочет платить вам желаемую зарплату.
И я в таких ситуациях обычно просто указываю вилку с относительно большим разбросом.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я как-то в своё время задал похожий вопрос своему коллеге, который отвечал за собеседования на нашей фирме. Он ответил что-то вроде: «можно всё что угодно, но выпендрёжников я не люблю» :)
НЛО прилетело и опубликовало эту надпись здесь
Проводил собеседование. Нужно было поддерживать адское легаси на Delphi 7 и 1С (но версия 1С была свежее, чем версия Delphi), но c кандидатами за предлагаемую зарплату было туго. Начали убирать требования: опыт работы сначала сократили, потом убрали совсем; высшее образование съехало на средне-специальное, а потом и на неоконченное; наконец, выкинули требования знания каких-либо конкретных ЯПов. Осталось лишь «уметь программировать». Ага.
Тестовое задание — три задачки уровня 7-го класса лицея с углубленным изучением информатики, не более того, я разрешал решать при мне на любом ЯПе из тех, что есть на рабочем ПК или из тех, что есть на ноуте собеседуемого. Разрешал гуглить, пользоваться документацией, делать что угодно, кроме поиска готового решения или использования абилки «спроси друга».
Один из кандидатов, кто пришел на собеседование, пришел со своим ноутом. Спросил, можно ли написать решение на Ruby. Написал, объяснил пару мест в коде (я в Руби не умею, потому задавал вопросы). Получил работу. Всему необходимому человек дообучался уже работая.
Тестовое задание — три задачки уровня 7-го класса лицея с углубленным изучением информатики, не более того, я разрешал решать при мне на любом ЯПе из тех, что есть на рабочем ПК или из тех, что есть на ноуте собеседуемого. Разрешал гуглить, пользоваться документацией, делать что угодно, кроме поиска готового решения или использования абилки «спроси друга».
Один из кандидатов, кто пришел на собеседование, пришел со своим ноутом. Спросил, можно ли написать решение на Ruby. Написал, объяснил пару мест в коде (я в Руби не умею, потому задавал вопросы). Получил работу. Всему необходимому человек дообучался уже работая.
А какой порядок ЗП был, если не секрет?
Вакансии на delphi это нечто… Когда искал работу в прошлый раз (до скачка курса 2014) публикуемые были ~100 сейчас ~100-110… При этом где-то помнится хотели чтобы свой dataset набросали :)
При этом где-то помнится хотели чтобы свой dataset набросали :)
Ну, простой датасет с заглушками большинства методов — это не бог весть какая сложная задача, минут на полчаса. Тем более что программисту Delphi иногда приходится это делать, когда надо подцепить живые данные из какой-то экзотической фигни.
Вчера пришла вакансия на Delphi на 300к.
=)
PS: ну да, я сам в шоке.
=)
PS: ну да, я сам в шоке.
Как-то был на собеседовании (там нужен был firebird), несколько лет назад, вроде как по тех. части всё было хорошо, но по деньгам хотел всего 120 (и да мне было удобно место заинтересовал проект) и это был минимум на который я был готов, на что мне сказали что то вроде "ну вот на вакансию по js мы ещё можем такую сумму выделить но не на эту" ...
Ну это нормально, они разработчики вероятность, что они компетентны для проведения собеседований она весьма не велика. Как правильно отметили они замкнуты на своём контексте и берут его как шаблон разработчика а далее простой и тупой алгоритм перебора, мозг ведь довольно ленивая штука потому для большинства вникать в ваш опыт банально лень. Сколько было этого клише с гугла, решение «умных задачек», и ничего о вменяемости подхода даже не пытались думать.
Да, проблема весьма актуальная, и мне тоже кажется что западные компании поадекватнее и это выглядит логичным учитывая проблемы нашего общества.
И после всего этого идиотизма все ноют про дефицит кадров на рынке — дефицит в головах, а не на рынке — нанимать научитесь!
Касательно тестовых заданий — у нас же неадекваты с обеих сторон, много девелоперов отказываются их делать не вникая — «я мол сеньёр-помидор, мне ли тестовые делать, да я много лет говнокожу и бабло гребу». Такой подход можно понять если тестовое задание это реальная работа с проекта, но без оплаты — такое похоже на мошенничество, эдакий бесплатный аутсорс фрилансерам, ну или если у человека гора кода в опенсорсе — бери смотри. Но в остальных случая, если тебя нанимают не смотря на код, то это выглядит подозрительно, значит им наплевать, а следовательно будет много говнокода.
Причём тестовое нужно не только работодателю, но и работнику — по нему же сразу видно контору, мне как-то присылали задание которое для годится для джуниоров — проверить что они вообще умеют прогать, я его не стал делать — там никак не показать свои способности писать нормальный код, а тут прислали тестовое, которое просто прекрасно, сразу видно что люди понимают как искать девелоперов прикладного уровня — сделал и люди зовут работать.
И после всего этого идиотизма все ноют про дефицит кадров на рынке — дефицит в головах, а не на рынке — нанимать научитесь!
Касательно тестовых заданий — у нас же неадекваты с обеих сторон, много девелоперов отказываются их делать не вникая — «я мол сеньёр-помидор, мне ли тестовые делать, да я много лет говнокожу и бабло гребу». Такой подход можно понять если тестовое задание это реальная работа с проекта, но без оплаты — такое похоже на мошенничество, эдакий бесплатный аутсорс фрилансерам, ну или если у человека гора кода в опенсорсе — бери смотри. Но в остальных случая, если тебя нанимают не смотря на код, то это выглядит подозрительно, значит им наплевать, а следовательно будет много говнокода.
Причём тестовое нужно не только работодателю, но и работнику — по нему же сразу видно контору, мне как-то присылали задание которое для годится для джуниоров — проверить что они вообще умеют прогать, я его не стал делать — там никак не показать свои способности писать нормальный код, а тут прислали тестовое, которое просто прекрасно, сразу видно что люди понимают как искать девелоперов прикладного уровня — сделал и люди зовут работать.
Большинству бизнеса нужен говнокод и поскорее.
Сейчас правда нужен говнокод весь в тестах, а они уже хотя бы правильную компоновку требуют от кода и хотя бы SOLID.
И если тестовое задание, это не реальная работа с проекта, то скорее всего её решение очень просто нагуглить и переработать.
И о качестве кода ничего не говорит(так как человек может писать в нестандартной для себя манере, в которой в проекте никогда писать не будет). Тестовое вполне может написать другой человек в конце концов.
Так что лучшее тестовое это оплачиваемая реальная задача с проекта. Но опять же, при желании она говнокодера джуниора с позиции сеньора не отсеет. Была на хабре статья как индусы так устраивались)
Сейчас правда нужен говнокод весь в тестах, а они уже хотя бы правильную компоновку требуют от кода и хотя бы SOLID.
И если тестовое задание, это не реальная работа с проекта, то скорее всего её решение очень просто нагуглить и переработать.
И о качестве кода ничего не говорит(так как человек может писать в нестандартной для себя манере, в которой в проекте никогда писать не будет). Тестовое вполне может написать другой человек в конце концов.
Так что лучшее тестовое это оплачиваемая реальная задача с проекта. Но опять же, при желании она говнокодера джуниора с позиции сеньора не отсеет. Была на хабре статья как индусы так устраивались)
Я придумал, как мне кажется, довольно оригинальную альтернативу тестовому заданию.
Вместо теста на написание кода я предлагаю человеку задание на чтение кода.
У меня есть специально написанный для этих целей веб-скрипт, близкий к реальной жизни — легаси, плохой стиль: в одном файле верстка, логика и sql. Всё помещается на страничке A4, распечатанное с подсветкой синтаксиса.
Задача человека состоит в том, чтобы прочитать код, предположить, что именно должен делать этот скрипт, постараться определить, почему он работает неправильно. Затем он ещё может найти уязвимости, которые туда добавлены, найти баги попроще, рассказать о том, как всё это правильнее рефакторить и т.д. — тема для обсуждения неисчерпаемая.
Вместо теста на написание кода я предлагаю человеку задание на чтение кода.
У меня есть специально написанный для этих целей веб-скрипт, близкий к реальной жизни — легаси, плохой стиль: в одном файле верстка, логика и sql. Всё помещается на страничке A4, распечатанное с подсветкой синтаксиса.
Задача человека состоит в том, чтобы прочитать код, предположить, что именно должен делать этот скрипт, постараться определить, почему он работает неправильно. Затем он ещё может найти уязвимости, которые туда добавлены, найти баги попроще, рассказать о том, как всё это правильнее рефакторить и т.д. — тема для обсуждения неисчерпаемая.
Да, это отличный вариант, сталкивался когда предлагали найти ошибки в коде строчек на 20 — нашёл на одну больше чем ожидали )
НЛО прилетело и опубликовало эту надпись здесь
Моя первая реакция на такое предложение была бы «дайте ваши соглашения по коду и пол часа на ознакомление» — как можно проводить ревью без понимания внутренних соглашениий по коду?
Так может цель такого задания это проверить как настроен ваш внутренний компас и насколько он близок к тому что у себя желает видеть фирма.
Это же дополнительный повод обсудить, почему вы считаете что поведение оператора + вероятнее всего перепределено в другой части кода :)
НЛО прилетело и опубликовало эту надпись здесь
И если тестовое задание, это не реальная работа с проекта, то скорее всего её решение очень просто нагуглить и переработать
Хорошее тестовое задание выглядит как реальная работа, но не является ей т.е. оно должно быть упрощено чтобы не походить на бесплатную работу, но при этом позволять показать свои способности.
Понятно что давать задание на реализацию алгоритма сортировки смысла нет.
человек может писать в нестандартной для себя манере, в которой в проекте никогда писать не будет
«может» быть что угодно, человек может сойти с ума сразу после написания идеального решения тестового задания и миллион иных вариантоа можно придумать, так что это не аргумент.
Так что лучшее тестовое это оплачиваемая реальная задача с проекта.
в теории да, на практике больше нюансов по затрачиваемому времени, реальная задача требует вхождения в контекст проекта, это требует больше времени (в первую очередь на коммуникацию) с обеих сторон.
Откуда берут тестовые задачи? Из интернета и решения там же.
Ну или придумали пару сами, дали выполнить паре людей, те на гите в открытую выдали им решение, это решение через пару дней доступно и другим.
Понятно что хорошие программисты в целом не мухлюют обычно. И так нормальную работу вполне можно найти. А плохие программисты и мошенники легко пройдут тестовое и подготовятся к собеседованию. Итого тестовое отсеивает тех кто будет хорошо работать.(зачем делать тестовое, когда рядом берут без тестового). И не отсеивает тех кто будет плохо писать код.
Можно было бы предлагать посмотреть и поменять код прямо на собеседовании. Но большинство лучших программистов в стрессовой обстановке работает гораздо хуже, чем в спокойной. И опять отсеются хорошие, останутся натренировавшиеся.
Самый хороший метод — это реально послушать про проекты человека. Что и как делал. Но требует хороший квалификации у рекрутера и времени.
Ну или придумали пару сами, дали выполнить паре людей, те на гите в открытую выдали им решение, это решение через пару дней доступно и другим.
Понятно что хорошие программисты в целом не мухлюют обычно. И так нормальную работу вполне можно найти. А плохие программисты и мошенники легко пройдут тестовое и подготовятся к собеседованию. Итого тестовое отсеивает тех кто будет хорошо работать.(зачем делать тестовое, когда рядом берут без тестового). И не отсеивает тех кто будет плохо писать код.
Можно было бы предлагать посмотреть и поменять код прямо на собеседовании. Но большинство лучших программистов в стрессовой обстановке работает гораздо хуже, чем в спокойной. И опять отсеются хорошие, останутся натренировавшиеся.
Самый хороший метод — это реально послушать про проекты человека. Что и как делал. Но требует хороший квалификации у рекрутера и времени.
Самый хороший метод — это реально послушать про проекты человека
тестовое задание этого не отменяет, но то как человек пишет код увидеть надо
> Откуда берут тестовые задачи? Из интернета и решения там же.
Это тестовое задание курильщика берётся из интернета. Тестовое задание нормального человека берётся из реально встретившейся на работе задачи. Берём задачу, которую мы только что решили, выбрасываем оттуда всё лишнее, упрощаем по максимуму контекст, и выдаём со словами «нам интересно посмотреть, как вы будете это решать, какие методы использовать, какие допущения примете». А потом на эту тему ещё и поговорить.
Это тестовое задание курильщика берётся из интернета. Тестовое задание нормального человека берётся из реально встретившейся на работе задачи. Берём задачу, которую мы только что решили, выбрасываем оттуда всё лишнее, упрощаем по максимуму контекст, и выдаём со словами «нам интересно посмотреть, как вы будете это решать, какие методы использовать, какие допущения примете». А потом на эту тему ещё и поговорить.
Обычно тестовые используют только на большой аудитории.
То есть от 10-20 человек и больше. И каждому отдельное тестовое никто не будет делать новое(а если не делать новое, то возвращаемся в пункт — есть в инете). Есть даже теория, что тестовые используют только чтобы выявить терпеливых и неуверенных в себе. То есть оставить тех на ком можно будет ездить потом. Не все так используют, но из-за встречавшихся таких случаях я отбрасываю фирмы с тестовыми задачами дольше часа сразу.
Вашим методом вполне можно обойтись и без тестового, а поговорить по коду человека в его репозиториях. Так и больше пользы для программиста рекрутера. Заодно можно понять что новое добавит с собой человек в проект, какой свой бэкграунд. А это очень важно.
То есть от 10-20 человек и больше. И каждому отдельное тестовое никто не будет делать новое(а если не делать новое, то возвращаемся в пункт — есть в инете). Есть даже теория, что тестовые используют только чтобы выявить терпеливых и неуверенных в себе. То есть оставить тех на ком можно будет ездить потом. Не все так используют, но из-за встречавшихся таких случаях я отбрасываю фирмы с тестовыми задачами дольше часа сразу.
Вашим методом вполне можно обойтись и без тестового, а поговорить по коду человека в его репозиториях. Так и больше пользы для программиста рекрутера. Заодно можно понять что новое добавит с собой человек в проект, какой свой бэкграунд. А это очень важно.
Я работаю программистом 19 лет, но у меня нет ни единой строчки кода ни в одном публичном репозитории.
Для разговора можно и свой не публичный показать или доступ дать. Про публичность я не говорил. Если нет возможности в репозитории показать, то можно на своем ноутбуке какой нибудь свой проект. Просто это точнее покажет код человека, чем тестовое задание.
НЛО прилетело и опубликовало эту надпись здесь
Откуда берут тестовые задачи? Из интернета и решения там же.
Из личного опыта и текущего проекта.
Что, все помнить? Он не станет читать к собесу про ACID и CAP, как студент к экзамену.
Но собеседование по сути и есть экзамен в условиях, когда централизированной системе образования не доверяют. Наличие красного диплома может быть необходимым условием, но не достаточным. Или не быть.
При этом:
1. Экзамен составляет и проводит не профессиональный преподаватель.
2. Экзамен имеет произвольную сложность (обычно более высокую по сравнению с вузом, поскольку работодатель компенсирует для себя более высокие риски от неудачного найма).
3. Вопросы для экзамена могут заимствоваться от собеседований на более престижные рабочие места с упусканием очевидного факта, что целевая аудитория может банально не захотеть проходить сложную лестницу испытаний ради шарашкиной конторы.
Поэтому на таком экзамене могут спрашивать ВСЁ. Любую дичь. Почему люки круглые? Сколько уровней у модели OSI? Есть ли у вас родственники за границей? А вы можете скачать анкету на восемь листов, заполнить её от руки, расписаться и закачать обратно?
Хотя, конечно, прогресс не стоит на месте и в наши дни можно наткнуться на вежливых эйчаров, которые пишут на почту и согласовывают время созвона вместо того, чтобы решительно ворваться в промежуток между телемаркингом и предложением взять кредит.
Не поверите: ремоут может быть продуктивнее работы в офисе. За счет того, что уходят все эти дерганья и отвлекания.
Учитывая массовое неприятие ремоута, напрашивается гипотеза, что собеседование в заметное число фирм имеет цель не получить прибыль от работника, а нанять прислугу в богатый дом (и повысить тем самым собственный престиж). Отсюда вытекает идея, что слуги должны присутствовать в доме физически и быть достаточно сервильны, чтобы приказы господ хоть как-то выполнялись. Поэтому мысль об удалённой работе для компаний с таким менталитетом так же смехотворна, как предложение remote job для собаки или кота. К счастью, в наше просвещённое время до домовладельцев доходит истина о том, что разные виды живности делают разные вещи, поэтому давать молоко, таскать тяжести или стеречь двор программистов обычно не заставляют.
Учитывая массовое неприятие ремоута, напрашивается гипотеза, что собеседование в заметное число фирм имеет цель не получить прибыль от работника, а нанять прислугу в богатый дом (и повысить тем самым собственный престиж)
Святая правда.
Странно, что так мало людей это понимают (или, по меньшей мере, озвучивают).
Требуются пояснения по картинке )))
Это лучше смотреть, конечно :) Silicon Valley 1 сезон, в перерыве презентации на TechCrunch Эрлих ляпнул что-то типа: «Мы выиграем, даже если для этого мне придется спуститься в зал и подр@чить там каждому», ну и по-приколу стали рассчитывать время, которое для этого потребуется и в какой-то момент (на картинке), Гилфойла осенило, что если др@чить в две руки, то будет в два раза быстрее :) Вобщем, все эти рассуждения привели к улучшению алгоритма их программы :)
НЛО прилетело и опубликовало эту надпись здесь
Чаще бывает даже так, что зависит не от конторы, а от команды в которую вы попадете. Или переходя к частному: от людей которые пришли вас собеседовать. Поэтому попадите вы в другой проект или даже поставьте собеседование в другой день и к вам придут другие люди на встречу. Так что очень не удобно получится, если у вас появилось желание работать в крупной кампании, вам откажут, а hr сохранит вас в истории как «не компетентного специалиста».
Также можно добавить что нормальные конторы дают аргументированный отказ, то есть после ответа становиться понятно каких знаний не хватает и что надо «подтянуть» чтобы устроиться в желаемую компанию.
Да это вообще исключительно редко встречается.
Обычно это надо специально у них спрашивать, и то редко кто ответит. По моему опыту пачки собеседований полгода назад, просто какую-то реакцию хотя бы просто «да» или «нет» и то дают хорошо если половина контор. Вторая половина не звонит и не пишет — им не до того, надо других кандидатов собеседовать.
НЛО прилетело и опубликовало эту надпись здесь
Это кадр из сериала "Силиконовая долина".
Многие опытные программисты имеют мнение что они не доверили бы разработку самому себе из прошлого, у которого на 1 год опыта меньше.
И на сегодняшний день, часто все их критерии — то что они выучили нового за прошедший год.
Я для себя осознал что собеседования в русскоязычных странах — это тест на культурную совместимость. Более того, зная название компании (или бэкграунд её сотрудников) — можно на 90% быть уверенным о критериях отбора. Т.е. в условном Киевском люксофте могут спросить о разности контейнеров, а в условном Московском яндексе спросят о разновидностях куч и алгоритмах над ними. А в условном «стартап инкубаторе» попросят посмотреть на ваши аккаунты на гитхабе и стаковерфлов. В условной кажуалгеймкомпани, попросят за вечер наклепать шахматы с клиент-сервером.
При этом кластеры этих специалистов редко смешиваются, из-за непонимания и недоверия друг к другу.
И на сегодняшний день, часто все их критерии — то что они выучили нового за прошедший год.
Я для себя осознал что собеседования в русскоязычных странах — это тест на культурную совместимость. Более того, зная название компании (или бэкграунд её сотрудников) — можно на 90% быть уверенным о критериях отбора. Т.е. в условном Киевском люксофте могут спросить о разности контейнеров, а в условном Московском яндексе спросят о разновидностях куч и алгоритмах над ними. А в условном «стартап инкубаторе» попросят посмотреть на ваши аккаунты на гитхабе и стаковерфлов. В условной кажуалгеймкомпани, попросят за вечер наклепать шахматы с клиент-сервером.
При этом кластеры этих специалистов редко смешиваются, из-за непонимания и недоверия друг к другу.
Кажется, парень высказал кусочек чего-то очень важного.
Вот если сравнивать построение ПО с механикой. Знать, что индексы существуют — это как знать, что существует ременная передача или там шестеренки — и что с их помощью можно преобразовать вертикальное вращательное движение в горизонтальное, а также поменять крутящий момент.
А ЗНАТЬ И ПОМНИТЬ некоторые виды алгоритмов — это примерно как помнить, каким именно способом в лабах измеряли коэффициент силы трения в твоем справочнике о характеристиках подшипников.
Вот если сравнивать построение ПО с механикой. Знать, что индексы существуют — это как знать, что существует ременная передача или там шестеренки — и что с их помощью можно преобразовать вертикальное вращательное движение в горизонтальное, а также поменять крутящий момент.
А ЗНАТЬ И ПОМНИТЬ некоторые виды алгоритмов — это примерно как помнить, каким именно способом в лабах измеряли коэффициент силы трения в твоем справочнике о характеристиках подшипников.
Хороший технический интервюьер ещё более редкий зверь, чем хороший программист. Потому-что во-первых, этому нигде не учат, а во-вторых, потому-что требует редко встречающихся в одном человеке скиллов — коммуникативность и техническая грамотность.
В большинстве случаев, такие люди довольно успешны в карьере и их время стоит дорого. Использовать это время для собеседований могут позволить не многие компании.
В итоге, в основном интервьюированием занимаются либо коммуникалы без технических знаний, либо техспецы без навыков коммуникации. И те и другие вынуждены прибегать к шаблонным наборам вопросов. Поэтому будьте снисходительны — людей заставляют делать несвойственную работу. Неудивительно, что она не очень получается.
В большинстве случаев, такие люди довольно успешны в карьере и их время стоит дорого. Использовать это время для собеседований могут позволить не многие компании.
В итоге, в основном интервьюированием занимаются либо коммуникалы без технических знаний, либо техспецы без навыков коммуникации. И те и другие вынуждены прибегать к шаблонным наборам вопросов. Поэтому будьте снисходительны — людей заставляют делать несвойственную работу. Неудивительно, что она не очень получается.
Вот мне интересно, когда до компаний дойдет, что для них, вообще-то важно, кто у них работает? По одному и тому же ценнику можно нанять людей, очень существенно различающихся уровнем — и это различие выльется в сэкономленные или продолбанные месяцы работы, сотни тысяч заработанных или потерянных долларов и кучу сохраненных или сожженных нервных клеток.
Тут я должен также патетически воскликнуть — «когда же до программистов дойдёт, что компаниям не так уж важно кто у них работает». На самом деле, конечно же разница есть, но для большинства компаний не на столько большая, чтобы сильно вкладываться в процесс приёма программстов.
Вы верите, что я один и тот же проект могу сделать за два месяца, а могу — за шесть, и разница будет только в том, что в первом случае, я однажды в поезде потратил три часа на листание Фаулера? А вот оно так, и в обоих случаях срок покажется всем нормальным и адекватным. А ведь я не один в проекте и каждый месяц я отбираю из копилочки господина собственника кругленькую сумму.
А ведь я не один в проекте— а вот это ключевое в данном случае. Вы не один и кто-то прочитал Фаулера, а кто-то что-то другое. Совсем не надо, чтобы все читали всё. Ну а если в команде не происходит обсуждения текущих задач, то тут уж точно качество программистов никак на результат работы не повлияет — она всё равно окажется провальной. Вот и получается, что качество каждого конкретного члена команды не так уж сильно влияет на результат. Поэтому и не настолько важно кто работает.
Конечно бывают высокотехнологичные проекты, но это не массово.
Разные люди читают разное — согласен. Но из этого не следует, что «компаниям не так уж важно кто у них работает». Напротив, из этого следует, что процесс собеседования выходит еще более сложным: ведь нужно подобрать команду, каждый из членов которой будет своими сильными сторонами компенсировать слабые стороны коллег. Для проведения собеседования необходим человек, понимающий свою команду и проекты, а также обладающий навыками проведения собеседования — как методическими, так и «мягкими». Этому надо учиться, читая книги, обсуждая методики и их применимость к вашей ситуации и практикуясь под надзором старших коллег.
Ну или понадеяться на авось и на то, что раз в команде 10 человек, компенсация произойдет сама собой, [sarcasm]«по закону больших чисел»[/sarcasm].
Ну или понадеяться на авось и на то, что раз в команде 10 человек, компенсация произойдет сама собой, [sarcasm]«по закону больших чисел»[/sarcasm].
Я вот согласен с предыдущим комментом. Если вы способны сделать проект за 2 месяца которые раньше делались за 6, то логичнее с позиции нанимающего(если компания большая) в штат вас не брать. Вы будете отличаться от коллектива, и возникнут трения, у всех будет куча проблем(например чем вас занять на оставшиеся 4 месяца). С собственника вы ничего не отбираете, зарплату вам все равно платить в любом случае
Мне кажется, проблема «чем вас занять на оставшиеся 4 месяца» появляется не так уж часто.
Ну это все равно головная боль для менеджера. Ну т.е. посудите сами — если вас собеседуют коллеги, то им нафиг не нужен человек, который будет все делать быстрее их. Для менеджера это с первого взгляда хорошо, но вы же не один, т.е. если вы будете выделяться, это приведет к нездоровым отношениям в коллективе, что вообще катастрофа для него(которая несравнима с небольшим ускорением разработки)
Ну т.е. посудите сами — если вас собеседуют коллеги, то им нафиг не нужен человек, который будет все делать быстрее их.
Почему? До тех пор пока кто-то не пытается использовать это как повод для понижения моей зарплаты, то у меня с этим проблем нет. А если кто-то такое начнёт, то проблема в этом человеке, а не в быстро работающем.
Я честно говоря вообще ни разу не слышал о понижении зарплаты(ну кроме в период кризиса). Обычно бюджет выделяют на отдел, далее эту сумму менеджер распределяет(это если плановые повышения)
Ну т.е. посудите сами — вы собеседуете людей(на зп аналогичную вашей), один повыше вас уровнем, другой пониже. Для вас более логичным взять пониже(предварительно задав вопросы о сортировках списка, чтобы к вам никто не прикопался). Ибо взяв повыше вы получаете материальные риски(бюджет уйдет не вам), и моральные(все сложные и интерестные задачи будут уходить не вам). Ну или вам вообще все равно на знания, смотрите чтобы на обед было ходить веселее. Это конечно вариант когда идет работа только за зарплату, если есть большие премии от результата(например консалтинг), тогда конечно не так. Но с премиями другая проблема — вы не наймете никого высокого уровня(или будет очень сложно найти того кто согласится на такое)
Ну т.е. посудите сами — вы собеседуете людей(на зп аналогичную вашей), один повыше вас уровнем, другой пониже. Для вас более логичным взять пониже(предварительно задав вопросы о сортировках списка, чтобы к вам никто не прикопался). Ибо взяв повыше вы получаете материальные риски(бюджет уйдет не вам), и моральные(все сложные и интерестные задачи будут уходить не вам). Ну или вам вообще все равно на знания, смотрите чтобы на обед было ходить веселее. Это конечно вариант когда идет работа только за зарплату, если есть большие премии от результата(например консалтинг), тогда конечно не так. Но с премиями другая проблема — вы не наймете никого высокого уровня(или будет очень сложно найти того кто согласится на такое)
Я если честно даже не знаю как вам ответить чтобы стало понятно. Просто там где у вас написано "логично", то для меня оно ну вот совсем не логично.
Если человек работает быстрее, то это совсем не значит что он вдруг получит более интересные задачи. Скорее он получит более срочные, но не факт что они будут интереснее.
А то что "бюджет уйдёт не мне", так я если честно не совсем понимаю что это вообще за бюджет и куда он там должен уходить. У меня есть зарплата, которая в моём понимании соотвествует моим способностям. Если кто-то при прочих равных работает быстрее, то вполне себе логично что ему будут платить больше. Но я не вижу почему это должно быть проблемой...
если вас собеседуют коллеги, то им нафиг не нужен человек, который будет все делать быстрее их.
Да как же не нужен? Нужен! Я у него поучиться смогу, например. Ну или спихнуть ему свою работу, если я ушлый и ленивый.
ну это не логично.
по поводу поучиться — т.е. вы собеседуете человека на такую же зарплату как у себя и планируете у него поучиться. Это значит что вам как бы платят больше рынка и взяв этого человека ваш менеджер это увидит. О повышении можно будет забыть
Спихивать работу тоже странно — логичной все же выглядит стратегия замыкать все на себя, тогда вы будете более незаменимы
Но это опять же работает если платят только зарплату вне зависимости от результата
по поводу поучиться — т.е. вы собеседуете человека на такую же зарплату как у себя и планируете у него поучиться. Это значит что вам как бы платят больше рынка и взяв этого человека ваш менеджер это увидит. О повышении можно будет забыть
Спихивать работу тоже странно — логичной все же выглядит стратегия замыкать все на себя, тогда вы будете более незаменимы
Но это опять же работает если платят только зарплату вне зависимости от результата
Ну почему же «замыкать на себя»? Если вы будете замыкать все на себя, разумнячий менеджер, начитавшийся про bus factor, быстро это пресечет. Незаменимый сотрудник в сегодняшних реалиях делает кучу всего и с радостью всех всему учит, при этом оставаясь незаменимым просто потому что объемы и разнообразие того, что он делает, слишком велики. Ну а про повышение, о котором можно забыть — я никогда в них особо и не верил, первые лет десять карьеры лучшее повышение — это переход в другую компанию.
За 4.5 года на своем первом месте работы зарплата выросла в 3.5 раза и еще планировала расти. С должностями аналогично. Причем я даже не просил, оно само, и по зарплате честно говорил что меня и текущая устраивает (примерно после того как в 2 с копейками раза от начальной выросла).
А вот то что смена работы поможет покопать в ширину и набраться нового опыта — согласен.
А вот то что смена работы поможет покопать в ширину и набраться нового опыта — согласен.
логичной все же выглядит стратегия замыкать все на себя, тогда вы будете более незаменимы«логичность» не так уж универсальна — она сильно от системы ценностей зависит. В вашей логичности главная ценность — деньги. Вы боитесь, что повышение пройдёт мимо вас, что вы окажетесь недостаточно незаменимы и потеряете зарплату.
В моей системе ценностей другие приоритеты. Я свою любознательность ценю больше, чем деньги. Мне неинтересно заниматься одним куском кода долго. Я с удовольствием спихну уже готовый кусок для поддержки кому-нибудь ещё. И также с удовольствием пообщаюсь с коллегой если он сможет сообщить мне что-то новое.
Согласен. Но если так как вы написали вы же наверное не будете спрашивать глупые вопросы о алгоритмах не относящихся к вашему проекту. Но большинство все же воспринимают работу как обычную рутину, поэтому и возникает то что написал автор
вы же наверное не будете спрашивать глупые вопросы о алгоритмах не относящихся к вашему проектуВопросы об алгоритмах, которые появляются на интервью это не какие-то специальные знания, это таблица умножения. Не знаю никого, кто на интервью спрашивает что-то серьёзное. Только самые элементарные вещи. Надо отличать квадратичную сложность от логарифмической, уметь обойти граф и понимать, как хэш таблицы работают.
когда до компаний дойдет, что для них, вообще-то важно, кто у них работает
Почему вы считаете себя умнее крупных компаний с миллиардными прибылями?
Не логичнее ли посмотреть с их стороны и наконец-то осознать, что для них, вообще-то, неважно, кто у них работает?
А почему бы и нет? Сегодня у твоей компании миллиардная прибыль, а завтра ты вылетаешь в трубу (привет, условный Кодак).
корпорации вылетают в трубу из-за неадекватности топ-менеджмента и неповоротливости крупных структур. причем почти все истории таких падений похожи друг на друга и ещё связаны с тем то зачастую контору валят свои-же акционеры которым плевать на то как там всё устроено.
==
по этому даже если в конторе работают супер-профи, это не гарантирует от банкротства… потому что пофиг кто там работает не на топ-позициях
==
по этому даже если в конторе работают супер-профи, это не гарантирует от банкротства… потому что пофиг кто там работает не на топ-позициях
У Боинга тоже миллиардные прибыли были, теперь миллионные. Уже не говоря о тех людях, которых не вернуть из-за программной ошибки в 737м.
Это вы верно заметили, не забудьте, однако, что все лица, принимающие решения, не потеряли вообще ничего. Вот абсолютно. Даже копеечки. Все, кому нужно было уйти с золотыми парашютами — ушли с ними. Никаких штрафов, ничего не было.
А прибыли что… Ну были миллиардные, стали миллионные, потом опять миллиардными станут. Это мелочи жизни.
Вы вот никак не можете в абстракцию.
Кстати, я очень часто встречаюсь с тем, что жалобы типа «Когда до компаний дойдёт, что им важно, кто у них работает» и «Когда до женщин дойдёт, что я такой умный и воспитанный лучше гопника» высказываются одними и теми же людьми. Погружёнными в программирование больше, чем в реальный мир.
Я могу только повторит — в реальном мире неважно, кто там работает. Наймут таджиков, наймут китайцев, наймут дрессированную обезьяну, если это будет дешевле и позволит манагеру вот прямо сейчас, а не через двадцать лет, купить новую яхту.
А прибыли что… Ну были миллиардные, стали миллионные, потом опять миллиардными станут. Это мелочи жизни.
Вы вот никак не можете в абстракцию.
Кстати, я очень часто встречаюсь с тем, что жалобы типа «Когда до компаний дойдёт, что им важно, кто у них работает» и «Когда до женщин дойдёт, что я такой умный и воспитанный лучше гопника» высказываются одними и теми же людьми. Погружёнными в программирование больше, чем в реальный мир.
Я могу только повторит — в реальном мире неважно, кто там работает. Наймут таджиков, наймут китайцев, наймут дрессированную обезьяну, если это будет дешевле и позволит манагеру вот прямо сейчас, а не через двадцать лет, купить новую яхту.
Я, в основном, согласен с автором и часто практикую как раз «поговорить о прошлых проектах». Тем не менее бывает кандидат нравится, рассказывает красиво, в самом конце задаю пройстейший вопрос по SQL просто для проформы, даже самому стыдно трачу всремя уважаемого человека и вдруг… поплыли… да еще как поплыли…
Кстати да, трындеть — не мешки ворочать.
Хуже, если это обнаруживаешь уже во время онбординга.
Тем не менее бывает кандидат нравится, рассказывает красиво, в самом конце задаю пройстейший вопрос по SQL просто для проформы, даже самому стыдно трачу всремя уважаемого человека и вдруг… поплыли… да еще как поплыли…
Поэтому код всё-таки на собеседовании писать надо. Не на всё собеседование, а на треть-четверть максимум. С уровнем сложности конечно же самым примитивным, ничего другое не влезет по времени. Но уже и это позволяет отсеять чистокровных любителей поговорить о программировании.
Но уже и это позволяет отсеять чистокровных любителей поговорить о программировании
сомневаюсь я чёто что просто по разговору можно не понять что собеседуемый — любитель поговорить.
при условии что собеседуем не на джуна и уж тем более не на миддла
p.s. помню мне вручили на собесе листок a4 и попросили написать какуюто большую штуку… у меня знатно тогда пригорело, поскольку я дословно нифига не помню название какихто методов и их параметры… интервьюверы тогда начали ржать типа «ты без инета и без ide обязан знать это всё!» причем собес был на сеньора…
Я на самом деле тоже сомневался. А потом (когда участвовал в небольшом расширении команды) увидел их вживую — странных людей, которые очень складно рассказывают о прошлых задачах и решениях, но почему-то не пишут код уровня FizzBuzz. Вот реально — не пишут.
Я так до сих пор не понимаю, откуда они такие берутся.
Я так до сих пор не понимаю, откуда они такие берутся.
которые очень складно рассказывают о прошлых задачах и решениях
но почему-то не пишут код уровня FizzBuzz
так достаточно спросить как бы вы написали такой код, не нужно писать его на бумажке, просто на словах
===
а про откуда такие берутся, собственно тут двоякая ситуация. Я например однажды попал в интересную контору, где общий уровень архитектуры и вообще программинга несколько ниже моего (в абсолют был возведен 'чем проще тем лучше'… вплоть до того что не проверялись ошибки в запросах, не чекалась безопасность, никогда не делался задел под расширение функционала даже если в ТЗ через две задачи от текущей оно тербовалось)… и получилось так что мой опыт рассказанный на собеседовании совершенно не применим и я выглядел как 'чел рассказывает складно, а работу делает неправильно' тупо потому что пишу микросервис с учетом всяких исключительных ситуаций, а на кодревью выпиливают 80% кода со словами 'это никому никогда не нужно, ты странный что так пишешь'
так достаточно спросить как бы вы написали такой код
Ну так кодим-то мы на языке, а не на метаязыке приближенном к естественному. Я могу понять, когда при попытке накодить задачку уровня FizzBuzz на JS на бумажке (но лучше тут хотя бы nodepad кандитату дать, разумеется) кто-то не вспомнит оператор % или будет писать var вместо let/const, или переберёт массив банальным for, а не через reduce(). Это вообще не важно, важно — чтоб кандидат продемонстрировал самую базу того, чем он вообще-то будет на работе заниматься.
А вот когда словами поговорить — сколько угодно, а перейти в термины языка программирования — никак, то таких на работу брать как-то очень боязно. На работе-то на должностях software developer с IDE надо не русским языком говорить.
интервьюверы тогда начали ржать типа «ты без инета и без ide обязан знать это всё!» причем собес был на сеньора…
Причём забери у них самих интернет и ide и тоже ничего написать не смогут. Тоже на таких пару раз попадал...
По-моему, листочек А4 или доска — это самое лучшее во время собесов. Хуже когда дают какую-то Web IDE и тесты — и надо сразу написать, чтобы тесты проходили. На листочке если ты забыл какой-то метод, то сразу можно прощупать, а не кретин ли проверяющий (как вышло в вашем случае), и если кретин — то сразу покинуть этот цирк.
Тем не менее бывает кандидат нравится, рассказывает красиво, в самом конце задаю пройстейший вопрос по SQL просто для проформы, даже самому стыдно трачу всремя уважаемого человека и вдруг… поплыли
О, у меня так было, вот в точности, как вы рассказываете.
Отлично побеседовали, потом мне задали вопрос, про CASE, и я ведь как раз его постоянно использовал на предыдущей работе, обрадовался, щас как расскажу, но просто тупанул и забыл, «поплыли поплыли». Не перезвонили, конечно.
И ведь, что характерно, в моих реальных задачах ничего не изменилось. Я как до этого его использовал, так и после его использую.
Но вот теперь для того собеседователя я не уважаемый человек, а мошенник какой-то, слава богу, что они избежали моего найма, радуется он до сих пор наверное!
А там где я сейчас работаю, все довольны, потому что такого вопроса мне не задали, а на практике я всё делаю как надо.
Ага, а бывает и наоборот. Тебе дают задание, на которое сам собеседующий не может дать правильный ответ. Ну вот из недавнего, дают мне задачку «если число делится на 3, то вывести foo; если на 5, то buzz; если на 3 и 5, то foobuzz». Ну пишу эти примитивные условия подряд.
— Неправильно!
— Почему?
— А если 15?
— Ну тогда сработают все три условия.
— Ну вот и неправильно. Должно только последнее.
— Это ещё почему? Вот условие задачи. Код полностью ему соответствует. А уж что там подразумевал составитель задачи… Пишите тогда «если делится на 3, но не на 5»… Мы же всё-таки о программировании говорим. Дисциплине со строжайшей формальной логикой. Можно сколько угодно рассуждать о синтаксических особенностях, проблемах типизации и соответствующих трудностях поиска ошибок. Но если ведущий программист ставит тебе изначально некорректную задачу — то запаритесь потом такие ошибки искать.
— Неправильно!
— Почему?
— А если 15?
— Ну тогда сработают все три условия.
— Ну вот и неправильно. Должно только последнее.
— Это ещё почему? Вот условие задачи. Код полностью ему соответствует. А уж что там подразумевал составитель задачи… Пишите тогда «если делится на 3, но не на 5»… Мы же всё-таки о программировании говорим. Дисциплине со строжайшей формальной логикой. Можно сколько угодно рассуждать о синтаксических особенностях, проблемах типизации и соответствующих трудностях поиска ошибок. Но если ведущий программист ставит тебе изначально некорректную задачу — то запаритесь потом такие ошибки искать.
Я как-то устраивался, если не путаю в яндекс. Мне там дали задачку, уже не помню подробностей, нужно было вычислить что-то на основе массива данных. Я посидел, подумал, выдал ответ, задачка решалась тривиально, практически в одно действие. Парень, «на той стороне» сильно расстроился, сказал что придумывал ее несколько дней и ожидал что решать ее будут более сложным способом (дальше обговорили как он это видел), а мое простое решение он проглядел.
Правда все равно меня там прокатили… Но это уже совершенно другая история…
Правда все равно меня там прокатили… Но это уже совершенно другая история…
Есть такая особенность передачи логических правил в речи: если из условия B следует условие A, но они описаны в общей куче — то подразумевается что условие B является исключением из A.
Это из той же серии, что и союз "ИЛИ", который может означать как "OR", так и "XOR". Программист должен такие подвохи чувствовать и не стесняться переспрашивать в случае подозрений на некорректность задания.
НЛО прилетело и опубликовало эту надпись здесь
Чушь собачья! Если вы хотите взвалить на меня все эти функции вангования — платите тогда мне ставку топ-менеджера. Или что, вы по каждой поставленной вам задаче открываете диспут с менеджментом?
Задачу я понял. Задача довольно простая и сформулирована вполне ясно. То, что формулирующий вкладывал в неё иной смысл — проблемы формулирующего. Или это нормальная практика — взваливать на подчинённых ответственность за собственные ошибки? Ну тогда нам точно не по пути! А то пообмажутся некомпетентным менеджментом, а крайний всегда программист.
И к слову. Главное, чему меня научили в курсе школьной программы математики — это отвечать исключительно на поставленный вопрос к задаче. Додумывать, ходить вокруг да около конкретного ответа — это всё ошибки. Поэтому если вопрос к задаче подразумевает какие-то сложные выкладки, но сформулирован так, что требуется довольно простой однозначный ответ — этот ответ и надо давать. У меня были как раз подобные случаи — апелляция всё расставляла по своим местам.
Учитесь формулировать задачи, а не искать старого слепого болгарского программиста женского пола.
Задачу я понял. Задача довольно простая и сформулирована вполне ясно. То, что формулирующий вкладывал в неё иной смысл — проблемы формулирующего. Или это нормальная практика — взваливать на подчинённых ответственность за собственные ошибки? Ну тогда нам точно не по пути! А то пообмажутся некомпетентным менеджментом, а крайний всегда программист.
И к слову. Главное, чему меня научили в курсе школьной программы математики — это отвечать исключительно на поставленный вопрос к задаче. Додумывать, ходить вокруг да около конкретного ответа — это всё ошибки. Поэтому если вопрос к задаче подразумевает какие-то сложные выкладки, но сформулирован так, что требуется довольно простой однозначный ответ — этот ответ и надо давать. У меня были как раз подобные случаи — апелляция всё расставляла по своим местам.
Учитесь формулировать задачи, а не искать старого слепого болгарского программиста женского пола.
А это действительно зависит от того на какую позицию вы устраиваетесь. Если на джуна, то конечно подобное «вангование» от вас ожидать не стоит. От миддла на мой взгляд уже можно ожидать, но не то чтобы обязательно. А вот если сениор в такой ситуации не задумался о том что формулировка может быть понята двояко и не уточнил что точно имеется ввиду, то я бы сказал что к нам на фирму такого человека скорее всего сениором бы не взяли…
А тут двоякая позиция. Если мы говорим о должности «системного архитектора» — это такой звоночек. Что в случае косяков менеджмента, уважаемый, крайним будете вы.
Что уточнение задачи далеко не всегда возможно.
И вот эта превалирующая позиция, что работодатель предстаёт эдаким барином. Что это вы прежде всего нуждаетесь в работе, а не он в сотруднике. Я давно уже плюнул на подобную «концепцию». И если меня что-то не устраивает на этапе собеседования (в том числе и расхождение во взглядах на то, какие функции я должен исполнять по умолчанию) — то, конечно, разбегаемся.
Что уточнение задачи далеко не всегда возможно.
И вот эта превалирующая позиция, что работодатель предстаёт эдаким барином. Что это вы прежде всего нуждаетесь в работе, а не он в сотруднике. Я давно уже плюнул на подобную «концепцию». И если меня что-то не устраивает на этапе собеседования (в том числе и расхождение во взглядах на то, какие функции я должен исполнять по умолчанию) — то, конечно, разбегаемся.
Ну как бы чёткой классификации «джун-миддл-сениор» не существует, тут я с вами соглашусь.
Но я бы сказал что в фирмах где мне приходилось работать от сениора уже ожидалось немного больше чем просто писать код. В том числе и подобные вещи.
Но я бы сказал что в фирмах где мне приходилось работать от сениора уже ожидалось немного больше чем просто писать код. В том числе и подобные вещи.
Что в случае косяков менеджмента, уважаемый, крайним будете вы.
Что уточнение задачи далеко не всегда возможно.
Что значит "не всегда возможно"? Вы же вообще ее не уточняли, просто интерпретировали по-своему, и ваша интерпретация не совпала с интерпретацией человека, который вам задачу ставил.
В принципе это тоже может быть своего рода проверкой — я не вижу никакой проблемы, если на собеседовании намеренно ставят задачу с некорректными или неполными условиями, ожидая, что отвечающий сначала уточнит, и только потом будет тратить время на решение. Потому что выше определенного уровня действительно гораздо нужнее умение думать, а не умение кодить.
Вот кол, вот мочало… Почему-то все начинают вставать на позицию работодателя и прикрывать неумение формулировать задачи «проверкой на умение думать». Попасться на такую примитивную проверку может разве что школьник. И никакая это не проверка была. А косячное условие. Я прекрасно понимал какой ответ подразумевается, но сознательно сделал упор на некорректности условия.
А все эти «мы ожидаем от соискателя...» что он будет вести бухучёт, заниматься охраной офисных помещений и т.п. Оставьте.
Ещё раз — прекратите прикрывать собственные косяки «а это мы так тебя проверяли».
А все эти «мы ожидаем от соискателя...» что он будет вести бухучёт, заниматься охраной офисных помещений и т.п. Оставьте.
Ещё раз — прекратите прикрывать собственные косяки «а это мы так тебя проверяли».
Главное, чему меня научили в курсе школьной программы математики — это отвечать исключительно на поставленный вопрос к задаче. Додумывать, ходить вокруг да около конкретного ответа — это всё ошибки.
Что же, кажется наконец-то настало время забыть чему вас учили в школе...
Ну снобизм убирайте.
Наоборот. Я уже слишком стар для всего этого дерьма.
Когда-то да, я тоже ванговал, пытался предусмотреть все возможные варианты, закладывал «запас прочности», защиту от дурака и т.п. А потом… надоело. Это всё впустую. Этого не видят и не ценят. Зачем? Успокаивать свой перфекционизм? Я даже больше скажу — это просто неуважение к собственному труду.
Так что теперь я отношусь к таким вещам проще — «в должностной инструкции что-то есть на этот счёт? нет? свободны!»
Наоборот. Я уже слишком стар для всего этого дерьма.
Когда-то да, я тоже ванговал, пытался предусмотреть все возможные варианты, закладывал «запас прочности», защиту от дурака и т.п. А потом… надоело. Это всё впустую. Этого не видят и не ценят. Зачем? Успокаивать свой перфекционизм? Я даже больше скажу — это просто неуважение к собственному труду.
Так что теперь я отношусь к таким вещам проще — «в должностной инструкции что-то есть на этот счёт? нет? свободны!»
НЛО прилетело и опубликовало эту надпись здесь
Так это классический fizzbuzz, и вы в него угодили со всего разбегу.
Если писать эти примитивные условия подряд — то там не надо трёх условий. Достаточно первых двух. А fizzbuzz получается сам собой, когда первые два условия выводят его половинки.
Если писать эти примитивные условия подряд — то там не надо трёх условий. Достаточно первых двух. А fizzbuzz получается сам собой, когда первые два условия выводят его половинки.
Да ну бросьте. А если там не fizz будет, а протокол запуска стратегических ракет?
Ну и само собой не получится — вывод будет в разных строках. А чтобы слепить в одну — надо городить велосипед (конкатенацию).
Ну и само собой не получится — вывод будет в разных строках. А чтобы слепить в одну — надо городить велосипед (конкатенацию).
НЛО прилетело и опубликовало эту надпись здесь
Зачем конкатенацию??
if (i%3 == 0) {
System.out.print("fizz");
}
if (i%5 == 0) {
System.out.print("buzz");
}
System.out.println("");
Навскидку не вспомните — что за вопрос?
Как-то провалил собеседование на таком вопросе, ответил "наоборот" (прокручивая в голове это был момент отказа), причём я не оговорился, просто реально переклинило(я точно помню что подумал и ответил осознанно), и по дороге домой до меня дошло… На пару дней просто выдернули из жизни (не мог понять как так, всё же когда своя родная голова подводит это неприятно) и до сих пор не могу понять как так… :) Просто из личного опыта, задачи с использованием ответа приходится решать по нескольку раз в неделю...
Так по тому что рассказывает вопросы задавать надо. А не уши развешивать :)
Тебя будут спрашивать про сортировку красно-черных деревьев, про методы стандартной библиотеки, которые используются раз в приблизительно никогда. Но код… В самом деле, зачем смотреть код человека, главная работа которого будет заключаться в том, чтобы его писать?
Про это говорить вроде как НЕ ПРИНЯТО, странно что вы затронули эту тему.
Я тоже в своей статье написал, что я на все собеседования привозил свои программы, предлагал посмотреть, но никто ни разу не захотел. И на это в комментариях практически никак не отреагировали. «Слепая зона». Много писали про призвание и т.д., а про то, что никто не смотрит то, что ты делал раньше, при постоянной пропаганде на эту тему — не обсуждается.
Потому что пропаганда не работает. Если код на гитхабе кто-то ещё посмотрит (но таких — исчезающе малое количество), то код привезённый с собой будет смотреть практически никто. Потому что в код — надо вникнуть, поизучать задачу, а уже потом как-то оценивать. Да такой человек почти всё время интервью на просмотр кода потратит!..
А то, что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность?
Вот это, к слову вполне адекватный вопрос. Ведь он проверяет, а понимает ли человек вообще что он делает и как это будет работать в зависимости от объёма данных. Если ваше приложение будет подвисать потому что вы что-то делаете за квадратичное время, а не за логарифм, будет печально.
Практически всегда достаточно знать, какая структура данных и/или алгоритм под капотом что бы оценить сложность хотя бы примерно (если там комплексных и сложный подход, например).
Я практически не касался PostgreSQL да и баз данных, но я вижу B-tree и для меня этого уже достаточно чтобы ответить (хотя бы с точки зрения теории). Не знаете что за структура данных (а такое может быть), попросите её описать. После этого, можно вывести сложность операций.
Если ваше приложение будет подвисать потому что вы что-то делаете за квадратичное время, а не за логарифм, будет печально.
Насколько я знаю, в postgres не бывает индексов с поиском за квадратичное время (потому, что такое время у просто nested loop, и на кой нам вообще тогда такой индекс?). Кроме того, не думаю, что там есть индексы с хуже чем nlog n поиском.
Следовательно, конкретно в процитированном отрывке есть более простое правило — предпочитать индексирование его отсутствию, а с асимптотикой разбираться когда действительно припрёт. Причём действительно припирает сейчас не настолько много компаний, чтобы незнание асимптотики единственного индекса единственной СУБД означало автоматическую профнепригодность.
Сравнение сложностей было просто для примера.
Другой пример, если вы не знаете за какое время отработает вставка или поиск в ассоциативном контейнере, то как вы можете решить что использовать? А может быть вообще какой-нибудь контейнер с плоской реализацией выбрать, а будет ли там ощутимая разница по скорости/памяти на наших наборах данных, а если набор изменится? Вот примерно такие вопросы возникают в голове у программиста, на мой взгляд.
а будет ли там ощутимая разница по скорости/памяти на наших наборах данных, а если набор изменится
А вот на последний вопрос тут вообще пытаться отвечать бессмысленно. Эти наборы всегда изменяются, и "оптимизировать" здесь что-то, кроме внешнего API контейнера (чтобы его в случае чего было можно поменять на другой и не трогать больше ни одной строки кода), есть преждевременная оптимизация. Даже больше, зачастую и изначальный набор данных известен только очень приблизительно, потому извращаться с какой-то экзотикой заранее, если точно не известен ещё сценарий использования, — равносильно увеличению фактора грузовика. Лучше взять что-то стандартное и, опять же, обточить внешние связи остального кода с контейнером так, чтобы смену реализации заметили только пользователи, и только по ускорению работы приложения.
Это ровно та же идея, кстати, по которой стараются работать многие СУБД с встроенной оптимизацией запросов — когда вы, как правило, не знаете, что именно там за контейнер был применён при ответе на запрос, и насколько от похож на trie.
Кроме того, не думаю, что там есть индексы с хуже чем nlog n поиском.
А как же битовые карты?
Nested loop это способ соединения, это, в общем не про доступ к строкам.
Nl это (простейший случай) когда вы к каждой записи ищете соответствии в присоединяемой таблице. NL может работать как по индексу так и фулл сканом и скип сканом по составному индексу и ещё несколькими способами в зависимости от бд.
Индекс в подобных вопросах, как правило, рассматривается с точки зрения объединений, особенно раз там уже вылезло квадратичное время. И моё правило буравчика в этих вопросах всегда в том, что если у запроса время приближено итерации по продукту обоих коллекций (а именно это и показывает квадрат в асимптотике), то этот индекс там не нужен, или даже вреден, так как мешает оптимизатору воспользоваться другим индексом.
Если точнее, в вопросе про B-tree не было, было просто про сложность индексов в PostgreSQL. Конечно, можно было догадаться, что там B-tree (а чего там еще может быть?), но когда идет третий час собеседования…
Ну, там что угодно может быть в теории… Вот почему не скип-лист например можете ответить, а в чём разница между ним и B-tree будет, а почему бы его не использовать для индексов, сложности-то там одинаковые номинально? На эти вопросы не надо отвечать здесь и сейчас, это я в тему "а что там ещё может быть?".
Касательно оправданности этого вопроса для рядового программиста, который использует PostgreSQL я ничего сказать не могу. Тут недавно статья про фрезеровщика была, вот может быть если это программист-фрезеровщик (извиняюсь за эти ярлыки, но определение довольно-таки ёмкое), тогда ему это знать не нужно и пользы он из этого не извлечёт.
Ну а вспомнить и правда не всё можно. Не помните точно, просто предложите свои рассуждения.
Спасибо за вопрос, я подумаю, как будет время :)
Вот почему не скип-лист например можете ответить, а в чём разница между ним и B-tree будет, а почему бы его не использовать для индексов, сложности-то там одинаковые номинально? На эти вопросы не надо отвечать здесь и сейчас, это я в тему «а что там ещё может быть?»
Это довольно просто. B-tree в отличие от большинства других структур данных с логарифмическим поиском в худшем случае хранит кучу данных в одной ноде. То есть это дерево ветвиться гораздо быстрее многих других деревьев. У обычного бинарного дерева поиска или скип листа или чегото подобного будет log2 операций обращения к hdd, а у B-tree может быть log512 например. Это критически важно когда надо работать с hdd. У hdd очень маленький штраф за считывание подряд идущего куска данных, но очень большой штраф за навигацию магнитной головки. Перестройка (запись) тоже у B-дерева быстрее на hdd, по тем же причинам.
В оперативе B-деревья не используют, потому что для операции вставки поиска надо сделать много действий. Ассимптотика будет той же что и у аналогов, но константа хуже.
В оперативе — используют. Потому что менеджмент памяти улучшается, он такой же блочный и переиспользует пасять блоками, последовательный доступ проца к этой памяти так же оптимизирован, все как с hdd. Да, есть и эффективные avl и rtree, но это скорее ближе к специфике данных, чем про производительность. Теоретические рассуждения про асимптотическую сложность алгоритмов в сферическом вакууме следует выжигать каленым железом (из более менее опытных разрабов).
Интересно, если знания не важны, то почему бы тогда не нанять сторожа дядю Васю — он ведь наверное тоже гуглить умеет.
Автор видимо считает, что он единственный инженер на свете.
Однако, кроме кандидатов с 11 годами опыта, не ответившими ни на один вопрос, есть ещё и кандидаты с 11 годами опыта, ответившие на все вопросы.
В целом, я считаю что нужны общие вопросы, проясняющие кругозор, и вопросы на проверку честности. Если кандидат пишет: DB-архитектор, но при этом ничего не знает про нормализацию, то это прям выглядит очень подозрительно — значит самообразование на нуле.
Автор видимо считает, что он единственный инженер на свете.
Однако, кроме кандидатов с 11 годами опыта, не ответившими ни на один вопрос, есть ещё и кандидаты с 11 годами опыта, ответившие на все вопросы.
В целом, я считаю что нужны общие вопросы, проясняющие кругозор, и вопросы на проверку честности. Если кандидат пишет: DB-архитектор, но при этом ничего не знает про нормализацию, то это прям выглядит очень подозрительно — значит самообразование на нуле.
почему бы тогда не нанять сторожа дядю Васю — он ведь наверное тоже гуглить умеет
А вы попробуйте. Потом расскажете нам об успехах, и о том, действительно ли сторож дядя Вася умеет гуглить.
Однако, кроме кандидатов с 11 годами опыта, не ответившими ни на один вопрос, есть ещё и кандидаты с 11 годами опыта, ответившие на все вопросы.
Тут вопрос-то не в этом, а в другом: будут ли кандидаты с 11 годами опыта, ответившие на все вопросы кодить лучше и быстрее кандидатов с 11 годами опыта, не ответившими на вопросы? И если да, то почему именно они будут кодить лучше и быстрее?
Тут вопрос-то не в этом, а в другом: будут ли кандидаты с 11 годами опыта, ответившие на все вопросы кодить лучше и быстрее кандидатов с 11 годами опыта, не ответившими на вопросы? И если да, то почему именно они будут кодить лучше и быстрее?
Будут.
Потому что кандидаты, освоившие «матан», знают что гуглить. И, более того, им, чаще всего, это не требуется. Они глубже понимают суть проблем, принципиальные trade-off-ы и пр. (к примеру, знание CAP сразу ограничивает пространство поиска возможного решения). Они не изобретают велосипеды и меньше подвержены массовым заблуждениям и карго культам.
Скажем, необязательно заучивать производительность B-деревьев, достаточно представлять как они устроены, а производительность можно вывести самому.
Чтобы понять разницу, достаточно посмотреть на работу профессионального переводчика, который специально и систематически заучивал язык, по сравнению с переводом дилетанта, оснащённого большим и толстым словарём. Как бы быстро он не листал словарь, качество и скорость будут несопоставимы
Потому что кандидаты, освоившие «матан», знают что гуглить.
Но у вас нет кандидатов освоивших, и кандидатов не освоивших. У вас есть кандидаты, ответившие на вопросы, и кандидаты, не ответившие. Это совершенно не одно и то же, и мне непонятно, почему вы от вопросов лихо перешли к прекрасности кандидатов.
Весь остальной текст вашего тезиса — это выводы из ложной предпосылки, и плохая аналогия, выведенная из этой же предпосылки. «И вышывать умею… и на машинке...»
если кандидат не может «без гугла» оценить сложность поиска по b-tree — («знать» чтобы ответить за 1.5 секунды не обязательно) то наверняка у него будут проблемы с тем чтобы в гугле отсеивать «левые» ответы/советы от нормальных.
Это не порядок аргументов функции в PHP 4.2 — это фундаментально.
Это не порядок аргументов функции в PHP 4.2 — это фундаментально.
Больше повальных обобщений богу повальных обобщений.
Если что, ваш тезис мне напоминает что-то в духе «если человек не может карбюратор перебрать, то он какой-то неумеха, неудачник, и вообще наверное лох по жизни, фу таким быть». Ваше «если» вообще никак не связано с «то», поскольку вы даже не потрудились сузить области до хотя бы как-то с натяжечкой относящихся друг к другу. ДевОпс у вас тоже лох и неудачник, если не знает, чё там с b-tree?
Если что, ваш тезис мне напоминает что-то в духе «если человек не может карбюратор перебрать, то он какой-то неумеха, неудачник, и вообще наверное лох по жизни, фу таким быть». Ваше «если» вообще никак не связано с «то», поскольку вы даже не потрудились сузить области до хотя бы как-то с натяжечкой относящихся друг к другу. ДевОпс у вас тоже лох и неудачник, если не знает, чё там с b-tree?
Меньше размышлений неправильных дьяволу деталей огульных.
Если у вас наверное есть какое-то объяснение почему кандидат хорошего уровня не может провести оценку сложности операции с довольно простой структурой данных — было бы интересно послушать.
У меня только такие: не может оценить сложность в принципе/не знает что это такое; не способен размышлять (сейчас, или в принципе — вопрос). По одному вопросу конечно однозначный вывод делать нельзя, может просто локально «затупил», но если это система — то нам не по пути.
Вся информация которая нужна для оценки «на столе», загуглить тут можно только ответ, а он без понимания особо не нужен.
Если у вас наверное есть какое-то объяснение почему кандидат хорошего уровня не может провести оценку сложности операции с довольно простой структурой данных — было бы интересно послушать.
У меня только такие: не может оценить сложность в принципе/не знает что это такое; не способен размышлять (сейчас, или в принципе — вопрос). По одному вопросу конечно однозначный вывод делать нельзя, может просто локально «затупил», но если это система — то нам не по пути.
Вся информация которая нужна для оценки «на столе», загуглить тут можно только ответ, а он без понимания особо не нужен.
Если у вас наверное есть какое-то объяснение почему кандидат хорошего уровня не может провести оценку сложности операции с довольно простой структурой данных
Ну вот вы почему не можете карбюратор пересобрать (или можете)? Или, там, печь сложить (или можете)?
Типичные попытки обосновать точку зрения, подобную вашей — начинаются откуда-то с «я считаю это знание безусловно фундаментальным и важным для всех кандидатов». В большом количестве случаев — это не так; хотя я безусловно допускаю, что в отдельных конкретных случаях вопросы про бинарные деревья будут более, чем уместны, и тесно связаны с позицией.
Второй момент — это связывание «хорошего уровня» кандидата с подобными попытками выяснить, что он помнит в местячковых и частных случаях. В то время как «хороший уровень», по моим наблюдениям, наоборот, связан с какой-то востребованной частностью и углублением специализации, нежели охватом всего, о чем интервьюеру вздумается спросить. Проще говоря, если сеньёра сишника с опытом хайлоада будет более-менее уместно спросить про бинарные деревья, то сеньёра веб-программиста — гораздо менее уместно (специфика структур хранения данных касается его гораздо меньше).
А пример объяснения почему оценить сложность не смог принципиально отличных от моих есть или нет?
(достаточно одного чтобы доказать что есть, сейчас все сообщение можно свести к «не верю!»)
(достаточно одного чтобы доказать что есть, сейчас все сообщение можно свести к «не верю!»)
А пример объяснения почему оценить сложность не смог принципиально отличных от моих есть или нет?
Разумеется есть. Самый простой и самый вероятный же — кандидату а) нафиг не впёрлись ваши бинарные деревья; б) он недостаточно тренирован в том, чтоб вывести их «на салфетке» за время, отведенное для этого на собеседовании.
а) b-tree — это не бинарное дерево (но к делу это не относится)
б) т.е. не может из достаточных данных вывести ответ (а это звоночек) т.к. тут «вывод» занимает 1-2 минуты максимум (вместе с поговорить) — если есть понимание как это в принципе делается. Так что именно «недостаточно тренирован делать выводы и моделировать ситуацию даже не очень сложную, но в голове».
б) т.е. не может из достаточных данных вывести ответ (а это звоночек) т.к. тут «вывод» занимает 1-2 минуты максимум (вместе с поговорить) — если есть понимание как это в принципе делается. Так что именно «недостаточно тренирован делать выводы и моделировать ситуацию даже не очень сложную, но в голове».
т.к. тут «вывод» занимает 1-2 минуты максимум
И вы конечно же можете обосновать, почему именно 1-2 минуты.
конечно, если вы знаете как устроена структура данных, то дальше идут вопросы которые вы задаете сами себе:
1. сколько и каких операций нужно чтобы найти элемент в дереве на 100 000 элементов
2. как изменится эта оценка если элементов станет в 2 раза больше? А в 10?
=
и если человек знает что там может быть (константа, экспонента, корень, логарифм...) — то ответ готов.
Метод универсален для любых структур данных.
1. сколько и каких операций нужно чтобы найти элемент в дереве на 100 000 элементов
2. как изменится эта оценка если элементов станет в 2 раза больше? А в 10?
=
и если человек знает что там может быть (константа, экспонента, корень, логарифм...) — то ответ готов.
Метод универсален для любых структур данных.
конечно, если вы знаете как устроена структура данных
Самый простой и самый вероятный же — кандидату а) нафиг не впёрлись ваши b-tree;
не, если на вопрос «что там в индексе» ответ есть — B-tree — мы предполагаем что человек не просто слово выучил.
Если ответа нет — это несколько другая ситуация. Незнание тут — не приговор, и мы обычно продолжаем вопросом — а чтобы там могло быть и смотрим варианты с плюсами и минусами. Иногда это даже полезнее.
Если ответа нет — это несколько другая ситуация. Незнание тут — не приговор, и мы обычно продолжаем вопросом — а чтобы там могло быть и смотрим варианты с плюсами и минусами. Иногда это даже полезнее.
другой вопрос что если он не знал что там внутри b-tree — то тут понятно что без гугла дальше не уедем, но я, например, предлагаю придумать варианты и обсудить их плюсы и минусы.
Это куда полезнее чем «знаю-не знаю», ибо как раз вот это дает очень мало представления о том что будет дальше.
Ну и немного цифр, у тех кого мы берем на работу с таким «подходом» % прохождения испытательного срока больше 80% (скорее ближе к 90). Как минимум корреляция — очень хорошая.
Это куда полезнее чем «знаю-не знаю», ибо как раз вот это дает очень мало представления о том что будет дальше.
Ну и немного цифр, у тех кого мы берем на работу с таким «подходом» % прохождения испытательного срока больше 80% (скорее ближе к 90). Как минимум корреляция — очень хорошая.
другой вопрос что если он не знал что там внутри b-tree — то тут понятно что без гугла дальше не уедем, но я, например, предлагаю придумать варианты и обсудить их плюсы и минусы.
Если это нужно в работе на ту позицию, на которую вы собеседуете — это замечательно. Если нет — это «опять очередной интервьюер, считающий, что он и его контора тут сами себе гугл».
Это куда полезнее чем «знаю-не знаю», ибо как раз вот это дает очень мало представления о том что будет дальше.
А еще куда полезнее — говорить в таком же ключе о реальных задачах, а не о бинарных деревьях просто потому, что вам нравится о них поговорить.
Ну и немного цифр, у тех кого мы берем на работу с таким «подходом» % прохождения испытательного срока больше 80% (скорее ближе к 90). Как минимум корреляция — очень хорошая.
Обратная корреляция между количеством пиратов и глобальной средней температурой — тоже очень хорошая.
Если это нужно в работе на ту позицию, на которую вы собеседуете — это замечательно. Если нет — это «опять очередной интервьюер, считающий, что он и его контора тут сами себе гугл».— нужно ли оценивать трудоемкость вставки в b-tree index в pgSQL на CentOS по пятницам? — нет не нужно.
Уметь быстро оценивать трудоемкость решения — постоянно.
А еще куда полезнее — говорить в таком же ключе о реальных задачах, а не о бинарных деревьях просто потому, что вам нравится о них поговорить.Решение реальной задачи — до которого мы добираемся если есть смысл, занимает 30-60 минут. Я не готов тратить столько времени человека если особых надежд на то что все пройдет хорошо нет.
Уметь быстро оценивать трудоемкость решения — постоянно.
Вы это не проверяете.
Я не готов тратить столько времени человека если особых надежд на то что все пройдет хорошо нет.
И почему у вас нет особых надежд?
Потому что если в простой ситуации не смог придумать решение, то в на порядок более сложной скорее наверняка не сможет.
ЗЫ. не стоит путать неспособность придумать, с отсутствием решения в памяти. Это принципиальное отличие.
ЗЫ. не стоит путать неспособность придумать, с отсутствием решения в памяти. Это принципиальное отличие.
Ну вы же понимаете что в обсуждаемой ситуации «просто» и «сложно» это очень субъективно. Если подобными вещами занимается регулярно, то это просто. Если последний раз он об этом вспоминал в универе, то на порядок сложнее. А деревья это не то с чем ежедневно сталкивается абсолютно любой айтишник.
в этом то и прелесть этого примера, не нужно спец. знаний чтобы решить (приблизительно) эту задачу.
Пусть даже не точно.
Отсутствие «книжного» ответа — это отличный повод посмотреть как кандидат ищет решение незнакомой задачи, а не достает из памяти/гугла как в анекдоте (https://lol-sus.livejournal.com/1308476.html)
Пусть даже не точно.
Отсутствие «книжного» ответа — это отличный повод посмотреть как кандидат ищет решение незнакомой задачи, а не достает из памяти/гугла как в анекдоте (https://lol-sus.livejournal.com/1308476.html)
Потому что если в простой ситуации не смог придумать решение, то в на порядок более сложной скорее наверняка не сможет.
Вы не проверяете навык «оценка трудоемкости решений». Вы проверяете один сугубо частный случай этой оценки трудоемкости, и затем пытаетесь неумно обобщать.
Это именно то, о чём я выше писал. Не можешь карбюратор пересобрать — значит лох по жизни. Без вариантов. Не смог за минуту умножить 4575678 * 547 — значит умножения не знаешь. И так далее.
ДевОпс у вас тоже лох и неудачник, если не знает, чё там с b-tree?DevOps это, если что, методология, а не человек.
Ну и блин, если у человека есть хоть какие-то знания о структурах данных, то сам факт наличия слова tree в названии структуры даёт ему сделать очень хорошую догадку о сложности поиска в этой структуре.
Ну и блин, если у человека есть хоть какие-то знания о структурах данных, то сам факт наличия слова tree в названии структуры даёт ему сделать очень хорошую догадку о сложности поиска в этой структуре.
Если он держит в голове знания о big O на типичных алгоритмах — да. Вот только далеко не всем это хоть сколько-нибудь нужно держать в голове.
Сложность поиска в сбалансированных деревьях не требуется знать. Она получается совершенно тривиальным способом за секунды в уме просто исходя из устройства этого дерева. Если человек не может её получить, то он вообще понятия не имеет о структурах данных. Это же ну совсем азы.
Это же ну совсем азы.
Еще один.
Если знания списков еще можно подписать под «совсем азы» (но на самом деле тем, кто пишет софт совсем практически на уровне железа — списки не впились), то сбалансированные деревья — нет.
чтобы собирать «визитки на WP» почти наверняка верно, но это далеко не все работы =)
Я выше несколько раз сказал, что если вам в работе надо деревья и big O, то поспрашивать и поговорить про это — очень хорошо.
А когда работа предполагает те самые «визитки на WP» или графику, или какое-нибудь там формошлёпство фабричным методом, то спрашивать про деревья потому, что по чьему-то там особому мнению «это должны знать все» — серьезная проблема для конторы.
А когда работа предполагает те самые «визитки на WP» или графику, или какое-нибудь там формошлёпство фабричным методом, то спрашивать про деревья потому, что по чьему-то там особому мнению «это должны знать все» — серьезная проблема для конторы.
Не факт что именно деревья будут нужны, но Big O — точно пригодится. И если речь про собеседование мидл+ специалиста в «стартапики» — то там куда больше вероятности увидеть вопросы про деревья и на «найти решение которого нет готового» — на своем месте.
А если на конвеер — то там по-моему вообще выбирать не приходится, одна рука есть? по ФТП файлик залить можешь? — вы приняты.
А если на конвеер — то там по-моему вообще выбирать не приходится, одна рука есть? по ФТП файлик залить можешь? — вы приняты.
Big O — точно пригодится
Вполне возможно, и да, про это можно поговорить. Про big O, а не «а какая там сложность в b-tree».
И если речь про собеседование мидл+ специалиста в «стартапики»
Не знаю, какие у вас «стартапики», но как раз небольшие конторы сейчас в среднем более адекватны больших. Потому что в условиях кадрового голода и невозможности залить проблемы деньгами они вынуждены обращать внимание на процесс найма и не допускать туда совсем неадекватных собеседующих, а иначе они просто рискуют никого не найти, или, что еще хуже, найти профессионального проходителя собеседований.
Вполне возможно, и да, про это можно поговорить. Про big O, а не «а какая там сложность в b-tree».
так как может быть знание big O без самых важных примеров?
А это самый важный пример? А можно мне список по убыванию важности, а заодно информацию о том, кто этот список вывел, и почему именно так?
вот вам пример списка:
- O(n) — линейный перебор;
- O(n²) — связывание двух таблиц не по индексу (если с ориентацией на БД);
- O(log(n)) — поиск по сбалансированному дереву;
- O(1) — поиск по хэш-таблице (с некоторыми оговорками).
мне не нужно «самый важны» — мне нужно «достаточно хороший». Но если дадите жменьку «более лучших» (можно без обоснования) — то с удовольствием ознакомлюсь.
Вполне возможно, и да, про это можно поговорить. Про big O, а не «а какая там сложность в b-tree».На мой взгляд слишком широкий вопрос сначла дает ухже результат чем частный случай и потом поднятие выше по абстракциям.
+ опять таки экономит время, нет смысла слушать главу из учебника если ее приложение вызывает вопросы.
Не знаю, какие у вас «стартапики», но как раз небольшие конторы сейчас в среднем более адекватны больших.— у нас «стартапиком» называют что-то хотябы с претензией на технологичность.
Остальным (без бабла и/или инетресного проекта) — приходится брать все что осталось.
Серьезно? Графика без знания структур данных??? Да это же одна из самых требовательных к ресурсам область. Там О-большое на О-большом сидит и О-большим погоняет.
М, а у вас «графика» — это обязательно «тридэ» и прочие миллионы полигонов и терабайты текстур? Вопросов к вашему кругозору не имею.
Мммм а для вас 2d и отсутствие полигонов/текстур — это рисовать простые кружочки/прямоугольнички на канвасе? Ну я тогда тоже вопросов более не имею.
Рисовать прямоугольнички на канвасе — это тоже называется «графика». Более того, в определенных слоях кровавого энтерпрайза — это та самая графика, которая нужна буквально всем. Кружочки (и их сектора) и прямоугольнички, да. Впрочем, и более сложные случаи там тоже есть. И именно по поводу более сложных случаев иногда и становится нужно загуглить подходящие структуры данных.
Да и более того, рисовать кружочки и прямоугольнички в браузере можно не только на канвасе, и если я будут собеседовать кандидата на рисование графиков и подобной чешуи — я его, например, обязательно спрошу о том, как вообще в браузере можно рисовать, и какие у каждого способа сильные и слабые стороны. Потому что это будет реально важно для такой позиции. А что там с b-деревьями — не будет.
Да и более того, рисовать кружочки и прямоугольнички в браузере можно не только на канвасе, и если я будут собеседовать кандидата на рисование графиков и подобной чешуи — я его, например, обязательно спрошу о том, как вообще в браузере можно рисовать, и какие у каждого способа сильные и слабые стороны. Потому что это будет реально важно для такой позиции. А что там с b-деревьями — не будет.
Ну блин, уж на что 1сников обычно опускают морально, но вспоминая прошлую работу и я будучи 1сником бы ответил и большинство моих бывших коллег (тоже 1сники). Просто представляя как деревья устроены, да на вскидку, да, без констант. Да, я уже не смогу так из головы с ходу прикинуть сколько проблем принесет перебалансировка при записи в таблицу с таким индексом и уж точно ее если и напишу то в муках и криво. Но блин всего лишь асимптотику простого случая тут оценить нужно.
И да, мы там именно формошлепством и занимались.
Да даже сейчас занимаюсь тем же формошлепством под андроид, у нас в приложении даже базы нет ибо данные кешировать нет смысла.
И да, мы там именно формошлепством и занимались.
Да даже сейчас занимаюсь тем же формошлепством под андроид, у нас в приложении даже базы нет ибо данные кешировать нет смысла.
Да ну ладно, в любом хоть сколько-нибудь приличном курсе по структурам данных гарантированно будет 4 базовых структуры: массивы, связные списки, двоичные деревья, хеш-таблицы.
Я могу понять, что человек действительно знал алгоритмы, но забыл что такое АВЛ-дерево, могу представить человека забывшего что такое открытая адресация, могу даже представить человека забывшего как работают хеш-таблицы. Но забыть структуру двоичных деревьев — это выше моего понимания.
Я могу понять, что человек действительно знал алгоритмы, но забыл что такое АВЛ-дерево, могу представить человека забывшего что такое открытая адресация, могу даже представить человека забывшего как работают хеш-таблицы. Но забыть структуру двоичных деревьев — это выше моего понимания.
Да ну ладно, в любом хоть сколько-нибудь приличном курсе по структурам данных гарантированно будет 4 базовых структуры
Ну разумеется, а кто не был на «любом хоть сколько-нибудь приличном курсе по структурам данных» — тот и не человек вообще.
Но забыть структуру двоичных деревьев — это выше моего понимания.
Лично я никогда её и не помнил, например. Равно как и хеш-таблицы, и много других интересных вещей, которые я гуглю каждый раз (примерно раз лет в пять), как мне это становится нужно на практике, и потом опять забываю через несколько месяцев. Всё остальное время о тех же хеш-таблицах я знаю то, что они существуют и что у них get() быстрее O(N) в ущерб скорости set(). Всё остальное о хеш-таблицах меня не волнует, для этого есть гугл.
Знания о множестве структур данных нужны далеко не всем программистам, и множество того, что нафиг не нужно — для разных областей будет заметно разным.
Лично я никогда её и не помнил, например. Равно как и хеш-таблицы, и много других интересных вещей, которые я гуглю каждый раз (примерно раз лет в пять), как мне это становится нужно на практике, и потом опять забываю через несколько месяцев.Вам серьезно раз в 5 лет возникает необходимость иметь структуру данных в которой производится поиск элемента и в которой есть хоть сколь-нибудь значимое кол-во элементов?
Нет, раз в 5 лет мне нужно знать об этой структуре что-то большее, чем «оно быстро работает на поиск».
Вам даже никогда не было любопытно как оно под капотом устроено?
Массив тоже работает «быстро» на поиск. Иногда даже при полном переборе. А еще у структур данных есть такой великолепный параметр как занимаемая ими память. А еще некоторые структуры данных могут быть быстрыми на поиск, но медленными на модификацию и наоборот. Но право же, кому это интересно?
Но право же, кому это интересно?
Тем, кто это использует на практике, очевидно.
А, ну да, как я мог забыть, мы же говорим про разработчиков, а они никогда-никогда не задумываются о производительности своих программ. Виноват. Постараюсь больше не забывать.
Просто дело в том, что вы обобщаете ваш опыт на всё-всё программирование, и из-за этого с каждым комментарием садитесь в лужу. Быстродействие в вебе, например — это вопрос знания пары вещей, ни одна из которых не связана со структурами данных и big O; структуры данных и big О — на третьем месте.
Итого если я буду говорить с кандидатом на роль фронтэндера о быстродействии — я скорее всего не дойду до структур данных, потому что время уйдет на обсуждение куда более важных вещей.
Итого если я буду говорить с кандидатом на роль фронтэндера о быстродействии — я скорее всего не дойду до структур данных, потому что время уйдет на обсуждение куда более важных вещей.
Вы знаете, у меня несколько иное мнение о том, кто тут сидит в луже. Но давайте уже заканчивать это обсуждение, а то мы опасно близко подходим к черте после которой пойдут прямые оскорбления.
Вы знаете, у меня несколько иное мнение о том, кто тут сидит в луже.
Скажем так, у меня сейчас есть достаточно серьезные основания полагать, что о веб-разработке вы не имеете практически никакого представления; отсюда же вы не имеете представления о том, что тут важно, а что неочень. И именно поэтому вы с повальными обобщениями пролетели сильно мимо. А это только веб-разработка, есть и более другие области с не менее интересной спецификой, совсем не укладывающейся в картину мира абстрактного среднего явиста/сишника/итп с узким кругозором.
Вы удивитесь какому количеству программистов никогда не приходилось даже задумываться над этими вопросами.
Мы живем в мире, в котором мобильные приложения пишутся на js крутящемся в webview, редакторы делают на базе электрона, а браузер выполняет роль операционной системы. Вполне возможно, что именно из-за того что мы мало задумываемся о таких вопросах мы такой мир и получили.
То есть я правильно понимаю что в идеальном с вашей точки зрения мире ничего этого быть не должно? Ни мобильных приложений, ни js, ни webview, ни всего остального? :)
К js, webview и мобильным приложениям по отдельности у меня никаких претензий нет, это замечательные технологии. А меня претензии к тому когда это всё вместе соединяется. Точнее даже не к самому соединению, а к тому насколько оно широко распространено.
К js, webview и мобильным приложениям по отдельности у меня никаких претензий нет, это замечательные технологии.
Но они же ведь тоже далеко не идеальны.
А меня претензии к тому когда это всё вместе соединяется.
Ну в общем-то вам на это уже ответили, но попробую ещё немного уточнить. Вы похоже исходите из того что эти вещи можно было сделать хорошо, а можно было плохо. И кто-то решил что лучше он сделает их плохо.
А если варианты были «сделать плохо» и «не сделать вообще»?
Но они же ведь тоже далеко не идеальныНу я не делю мир на идеальное/неидеальное. Мир имеет разные степени неидеальности. Некоторые вещи больше, некоторые меньше.
А если варианты были «сделать плохо» и «не сделать вообще»?
Ой да ладно, бесплатный телеграм смог сделать нативный клиент, а у платного слака вот прям стоит выбор либо голодать, либо делать на электроне.
Как я уже сказал основная проблема вовсе не в связке, а в том, как она расползлась. Я убежден, что в большинстве случаев не стоял выбор «сделать плохо» и «не сделать вообще». Возможно я и не прав, я все-таки не держал свечку у разработчиков slack, vs code, etc.
Ой да ладно, бесплатный телеграм смог сделать нативный клиент,
Даже если телеграм и бесплатный совсем не значит что он не приносит дохода и что делался он забесплатно.
Я убежден, что в большинстве случаев не стоял выбор «сделать плохо» и «не сделать вообще».
А мне как то кажется что всегда есть «быстро, дёшево, качественно» и обычно «быстро» и «дёшево» имеют гораздо меньшую свободу.
Мобильные приложения на js+webview — лучше не надо. Их и на пк то нежелательно, а мобилки они слабенькие.
Если уж нужна кроссплатформа — можно флаттер взять. Как раз вчера закончил читать кусочек инфы о dartvm, и то что я прочел меня лично вполне порадовало. Правда еще стоит вопрос какой вариант под андроид используется и будет в будущем использоваться для десктопа, но даже если не как на ios, aot, а jit (хотя судя по тому что нашел на гитхабе флаттера на андроид тоже aot, для jit судя по всему использовался бы вариант jitRelease а не release) — на статически типизированном языке можно делать более смелые и надежные предположения и генерировать более оптимальный машинный код.
Не говоря уж о заметно прокачанном механизме рендеринга во флаттере в сравнении с рендерингом в браузере.
Если уж нужна кроссплатформа — можно флаттер взять. Как раз вчера закончил читать кусочек инфы о dartvm, и то что я прочел меня лично вполне порадовало. Правда еще стоит вопрос какой вариант под андроид используется и будет в будущем использоваться для десктопа, но даже если не как на ios, aot, а jit (хотя судя по тому что нашел на гитхабе флаттера на андроид тоже aot, для jit судя по всему использовался бы вариант jitRelease а не release) — на статически типизированном языке можно делать более смелые и надежные предположения и генерировать более оптимальный машинный код.
Не говоря уж о заметно прокачанном механизме рендеринга во флаттере в сравнении с рендерингом в браузере.
Вполне возможно, что именно из-за того что мы мало задумываемся о таких вопросах мы такой мир и получили.
Такой мир мы получили потому, что мы хотим какой угодно софт забесплатно против офигенно эффективного софта за заоблачные деньги.
Неэффективный софт пишется исключительно потому, что из «качественно, дешево, быстро» в подавляющем большинстве софта всегда выбрасывается именно первое. Даже там, где этого не следовало бы делать (см. боинги).
Такой мир мы получили потому, что мы хотим какой угодно софт забесплатно против офигенно эффективного софта за заоблачные деньги.Ну это не совсем верное утверждение. Тот же стим прекрасно показывает, что люди готовы платить деньги за удобный продукт/сервис. Научиться бы только предсказывать что именно сделает продукт/сервис удобным.
Вы это сейчас серьёзно? Да стим же ужасно кривой и забагованный. Но зато куча дешёвых игр по скидкам :)
Ну это не совсем верное утверждение. Тот же стим прекрасно показывает, что люди готовы платить деньги за удобный продукт/сервис.
Вы серьезно? Стим резко удешевил игры (особенно для российского рынка, но и в целом), а не наоборот.
И я даже стесняюсь спросить, а сколько вы денег заплатили именно за стим?
Вы серьезно? Стим резко удешевил игры (особенно для российского рынка, но и в целом), а не наоборотДело не в цене. Дело в том, что многие люди, которые между опциями «купить диск» и «скачать с торрентов бесплатно» выбирали первую опцию стали выбирать опцию «купить в стим» вместо торрентов.
И я даже стесняюсь спросить, а сколько вы денег заплатили именно за стим?Глупый вопрос. Очевидно что напрямую я за стим не платил.
Дело не в цене. Дело в том, что многие люди, которые между опциями «купить диск» и «скачать с торрентов бесплатно» выбирали первую опцию стали выбирать опцию «купить в стим» вместо торрентов.
Именно в ней. Цена стала достаточно низкой, чтоб люди прекратили тратить своё время на добывание игр с торрентов (что как минимум требует определенных знаний, времени, и очень большого количества траффика, т.к. с торрентов придётся регулярно перекачивать по мере выхода патчей и обновлений).
Глупый вопрос. Очевидно что напрямую я за стим не платил.
Вот именно. И поэтому вы имеете бесплатный стим, который (стим-клиент) по сути представляет собой тот самый electron app, сделанный тогда, когда это еще не было модно. Разница в том, что обертка над cef у стима своя, выстраданная (и тоже страшно глючная и жрущая ресурсы как не в себя), а не electron.
Стим — это как раз нагляднейший пример того, чего именно можно добиться максимально быстро и дешево сбацанным софтом.
Ну хз, диски они имеют свойство портиться, привод нужен, ну их. Лучше спиратить. А стим более менее нормально работает, не нужно париться о сохранениях, социальный сервис, рекомендации, и еще куча всего. Даже при том что я последний раз игру какую либо запускал наверно месяца полтора назад — регулярно что то покупаю.
Вам серьезно раз в 5 лет возникает необходимость иметь структуру данных в которой производится поиск элемента и в которой есть хоть сколь-нибудь значимое кол-во элементов?
Вы не поверите, но да.
Да ладно курсы. Я вон курсов по структурам данных не проходил просто википедию читал. Сверху еще добавил пару книжек «Теоретический минимум по CS» и «грокаем алгоритмы» но про базовые структуры они мне ничего нового не рассказывали, все это есть на википедии.
Напоминает собеседование в одну известную компанию, когда довольно плотно спрашивали про свойство arguments, хотя при этом экзаменатор сам признался, что использовал его пару раз и это было 1,5 года назад. Хотя были и положительные моменты, например, при первом скайп-собеседовании завалил теорию почти полностью, но за счет того, что нужно было решать задачи и писать код смог пройти это собеседование. Кажется, что все эти задачи зависят не только от компании, но и от собеседующего. А далеко не у всех собеседующих есть четкое понимание того, что обязательно должен знать и уметь разработчик, а что не обязательно.
НЛО прилетело и опубликовало эту надпись здесь
2. Либо человек выучил, так как готовился к собеседованию, внимателен к мелочам, плюс ему в карму.
Если человек что-то учит специально к собеседованию, то это может говорить только об одном: ему настолько нужна работа (конкретно ваша или работа вообще). Будет ли он от этого потом лучше работать — вопрос открытый.
Здесь, как говорится, палка о двух концах. С одной стороны — разработчик думает, что вопросы, найти ответ на которые — дело 5 минут, не заслуживают того, чтобы засорять ими память. С другой — работодателю нужно как-то понять, разбирается ли человек в теме. А как это сделать, если он сам не разбирается? Вот он и идёт по пути наименьшего сопротивления и подбирает на собеседование именно те вопросы, «найти ответ на которые — дело 5 минут».
И, конечно, если работодатель смотрит на багаж знаний, а не на умения, то, с таким подходом, он получит сотрудников — носителей зазубренной информации, а не сотрудников, способных решать практические задачи.
И, конечно, если работодатель смотрит на багаж знаний, а не на умения, то, с таким подходом, он получит сотрудников — носителей зазубренной информации, а не сотрудников, способных решать практические задачи.
Ну так в трех компаниях сидят те кто в кодинге ничего не понимают, и их основная цель склонить человека работать за бесплатно, так сказать на работу ходить ради коллектива, а не ради денег.
Одну проблему собеседований я наблюдал буквально пару дней назад.
Подходит один руководитель (первые звенья) к другому (технически подкованному) и возникает между ними такой вот диалог:
— Там кандидат пришёл, поможешь по собеседовать?
— Да, конечно.
— Ок, через 10 минут подходи в переговорку.
Т.е. понимаете, приходит кандидат, а его в общем-то никто не ждёт, выдёргивают кого-то прям с рабочего место и зовут собеседовать. Я конечно само собеседование не видел, может там и было всё по красоте, но что-то сильно я в этом сомневаюсь. Просто приходилось самому собеседовать других людей, на мой взгляд это довольно сложная задача, к которой нужно готовиться, особенно если не занимаешься этим постоянно. Вот и рождаются вопросы про сложность алгоритмов и про интересную особенность о который вы сами только вчера узнали. Это в лучшем случае, в худшем (меня так валили пару раз, примеры из жизни, не выдумка) начинают задавать вопросы по специфике их собственных процессов «Не знаете как товар оприходуется и сколько это записей в БД порождает? Жаль, вы нам не подходите.»
Подходит один руководитель (первые звенья) к другому (технически подкованному) и возникает между ними такой вот диалог:
— Там кандидат пришёл, поможешь по собеседовать?
— Да, конечно.
— Ок, через 10 минут подходи в переговорку.
Т.е. понимаете, приходит кандидат, а его в общем-то никто не ждёт, выдёргивают кого-то прям с рабочего место и зовут собеседовать. Я конечно само собеседование не видел, может там и было всё по красоте, но что-то сильно я в этом сомневаюсь. Просто приходилось самому собеседовать других людей, на мой взгляд это довольно сложная задача, к которой нужно готовиться, особенно если не занимаешься этим постоянно. Вот и рождаются вопросы про сложность алгоритмов и про интересную особенность о который вы сами только вчера узнали. Это в лучшем случае, в худшем (меня так валили пару раз, примеры из жизни, не выдумка) начинают задавать вопросы по специфике их собственных процессов «Не знаете как товар оприходуется и сколько это записей в БД порождает? Жаль, вы нам не подходите.»
Ради справедливости, я лично пытался подготовиться, чтобы провести собеседование, но ничего такого у меня не получалось. Единственное что получилось — создать идеи и направления для задавания вопросов. Но повторения вопросов могут быть чреваты тем, что люди начнут «сдавать» вопросы агентам, а те — кандидатам. Или в интернете разместят.
Пока только и мы сами и от друзей слышал, что удобнее всего просто провести беседу. В нашем направлении из каких-то импровизированных вопросов и обсуждений можно получить какое-то представление о человеке. Пусть не быстро, пусть не идеально.
Но насчет запланированности, согласен, собеседование должно быть зарезервировано в календаре. Но тут все зависит от организованности, люди разные.
Пока только и мы сами и от друзей слышал, что удобнее всего просто провести беседу. В нашем направлении из каких-то импровизированных вопросов и обсуждений можно получить какое-то представление о человеке. Пусть не быстро, пусть не идеально.
Но насчет запланированности, согласен, собеседование должно быть зарезервировано в календаре. Но тут все зависит от организованности, люди разные.
А я и не утверждаю, что подготовка — это заготовка вопросов. Не знаю как Вам, а мне нужно подготовиться к беседе, чтобы она прошла интересно и конструктивно, мы ж не сорта пива обсуждать будем в конце концов, из беседы нужно извлечь хоть какую-то пользу кроме, о, чувак тоже ИПУ любит, класс, берём!
Я не имел ввиду, что Вы это сказали. Я имел ввиду, что это то, что я себе придумал.
Ясно, что должности разные и т.п. В нашем случае нам нужно много опыта и поэтому копать легче по ходу дела, подглядывая в примерный список направлений.
Наверное, самое сложное — это искать на интерна или на начального уровня программиста, тогда опыт уже проверить не получится и нужно понять сможет ли человек обучиться. Не знаю…
Ясно, что должности разные и т.п. В нашем случае нам нужно много опыта и поэтому копать легче по ходу дела, подглядывая в примерный список направлений.
Наверное, самое сложное — это искать на интерна или на начального уровня программиста, тогда опыт уже проверить не получится и нужно понять сможет ли человек обучиться. Не знаю…
PR'ы в репы Facebook, Microsoft, Mozilla,
А можете показать эти PR? Все, что я вижу у вас на гитхабе — это открытые issues в перечисленные репы, а не pull requests.
Справедливости ради, человек мог закрыть PR и удалить форк, нет?
Т. е. пурфов нет.
Ну дык я ж не говорю, что это так (и даже не испытываю симпатий к автору или восторгов по поводу статьи, скорее наоборот). Просто к тому, что сама по себе ситуация, кажется, не говорит о том, что он лжёт.
github.com/microsoft/react-native-code-push/pull/866
github.com/mozilla/DeepSpeech/pull/1102
github.com/facebook/react-native/pull/6392
github.com/facebook/react-native/pull/6272
Не то, чтобы это какие-то большие PRы. Фиксы багов, на которые лично натыкался.
github.com/mozilla/DeepSpeech/pull/1102
github.com/facebook/react-native/pull/6392
github.com/facebook/react-native/pull/6272
Не то, чтобы это какие-то большие PRы. Фиксы багов, на которые лично натыкался.
Обрезаем проект и сажаем кандидата на собеседовании решать задачу, которая примерно напоминает то, с чем ему придется работать по началу. И смотреть уже как справляется, как решает, что спрашивает при этом. Довольно хорошо показывает что это у нас за кандидат, и что можно будет ожидать.
А «очень интересные» логические задачки на собеседовании? На сколько они имеют смысл?
Есть места где можно посмотреть и задачки и решения. В том числе здесь, на хабре, периодически выходят посты с вариантами. Тогда зачем это всё?
Вот допустим я разработчик с большим востребованным опытом, фейлю всю пачку таких задачек. Что потом?
Есть места где можно посмотреть и задачки и решения. В том числе здесь, на хабре, периодически выходят посты с вариантами. Тогда зачем это всё?
Вот допустим я разработчик с большим востребованным опытом, фейлю всю пачку таких задачек. Что потом?
Я в Англии полгода искал первую работу. Много думал и учился на ошибках. В статье звучит очень похоже на мой опыт, что интересно. Но я не только на разработчика искал, а разные (не сильно люблю чистую разработку, сильно скучно почему-то). Например, думал, что правда и самокритика помогает, оказалось, что нужно очень аккуратно и минимально это все использовать.
Прикольно, позвонил в гугл, они спросили по сортировке (я был не готов) и про sticky bit был вопрос, я как-то очень редко его меняю и на секунду не смог вспомнить все подробности. В общем, на первом самом этапе мне сказали до свидания. Но я туда и не рвался, не сильно умные люди там будут просто пол подметать, мне кажется.
Но еще я понял, что полгода стоило того, потому что с вменяемыми людьми моего же уровня можно провести интересную беседу на собеседовании, я бы даже сказал больше обмен мнениями. И работать потом в этой компании достаточно комфортно.
Опять же, наверное универсальных совсем советов нет, но подстроиться под систему придется. Выучить эти сортировки проблемы нет, я это тоже сделал, когда понял, что спрашивают. Про большие компании есть список их вопросов в Интернете. Например, у Амазона есть обязательные серии вопросов, которые они задают. Например, «возьмете ли риск, когда будете релиз выкладывать». Правильный ответ должен быть… «нет». Я не вижу как бы в подглядывании вопросов какую-то нечестность, потому что другие кандидаты это сделают тоже, да и некоторые из вопросов — просто формальность.
Что интересно, все последние работы мне казались на первый взгляд не интересными и я планировал устроиться, но медленно что-то еще искать. Но оказывалось, что было интересно на самом деле. Или может это мой подход к тому, что «кто-то должен же это сделать из нас всех»…
В любом случае, я лично не нашел какого-то рецепта как лучше подготовиться к собеседованию (кроме как вспомнить про сортировку, что несложно). Но понял, что лучше подольше поискать, чем пытаться угодить. Но у меня сложное резюме и широкий профиль, так что мой случай может быть далек от общего.
Прикольно, позвонил в гугл, они спросили по сортировке (я был не готов) и про sticky bit был вопрос, я как-то очень редко его меняю и на секунду не смог вспомнить все подробности. В общем, на первом самом этапе мне сказали до свидания. Но я туда и не рвался, не сильно умные люди там будут просто пол подметать, мне кажется.
Но еще я понял, что полгода стоило того, потому что с вменяемыми людьми моего же уровня можно провести интересную беседу на собеседовании, я бы даже сказал больше обмен мнениями. И работать потом в этой компании достаточно комфортно.
Опять же, наверное универсальных совсем советов нет, но подстроиться под систему придется. Выучить эти сортировки проблемы нет, я это тоже сделал, когда понял, что спрашивают. Про большие компании есть список их вопросов в Интернете. Например, у Амазона есть обязательные серии вопросов, которые они задают. Например, «возьмете ли риск, когда будете релиз выкладывать». Правильный ответ должен быть… «нет». Я не вижу как бы в подглядывании вопросов какую-то нечестность, потому что другие кандидаты это сделают тоже, да и некоторые из вопросов — просто формальность.
Что интересно, все последние работы мне казались на первый взгляд не интересными и я планировал устроиться, но медленно что-то еще искать. Но оказывалось, что было интересно на самом деле. Или может это мой подход к тому, что «кто-то должен же это сделать из нас всех»…
В любом случае, я лично не нашел какого-то рецепта как лучше подготовиться к собеседованию (кроме как вспомнить про сортировку, что несложно). Но понял, что лучше подольше поискать, чем пытаться угодить. Но у меня сложное резюме и широкий профиль, так что мой случай может быть далек от общего.
Я думаю, что основная проблема в том, что часто в вакансии описание вроде «нужен разработчик, платим деньгами, технологии такие-то — в итоге плюс-минус стандартный набор, который может зависеть от компетентности HR/рекрутера и старания того, к кому в команду ищется новый человек. При этом, есть два фундаментально противоположных типа людей, которым будет некомфортно на „не той“ позиции, и попадание на собеседование на „не ту“ позицию как раз и вызывает подобный дискомфорт.
(Пока что мы опустим случаи, когда HR/собеседующий разработчик/вся компания дурные – да, такое случается, но это не единственный возможный случай возникновения подобных фрустраций)
В англоговорящем коммьюнити есть два разных слова – Developer и Engineer, которые как раз и означают упомянутые выше два разных типа людей
Engineer – это человек с фундаментальными знаниями, часто с формальным образованием в области computer science либо чрезвычайно любопытный и жадный до глубинного понимания происходящего. Такого человека хотят в технологические компании – FAANG, вендоры софта и прочие; технологические стартапы (моднейшие эйаи, машин лёрнинги и иже с ними). Как раз в такие компании нужен человек, который отлично знает CS и его на собеседованиях спросят про CAP/ACID/деревья и прочее; вчерашнего выпускника вполне можно попросить написать сортировку.
Developer – человек в основном с практическими знаниями. Образование – обычно техническое (часто не-гуманитарий тоже подходит – знаю врача и химика – разработчиков). Такого человека хотят в не-технологические компании и стартапы – в общем, куда угодно, где есть разработка, но важна скорее не инновационность, а надежность и предсказуемость. Нет смысла на собеседовании спрашивать про фундаментальные вещи – они все вшиты в инструменты, которыми он пользуется; скорее важно узнать уровень владения инструментами.
Казалось бы – если все так просто, то почему возникают проблемы? Самая первая и очевидная причина – тупое копирование без ответа на вопрос „а почему там так?“ Гугл спрашивает про люки? Ну так и мы спросим, и вот уже где-то в головах селится маленькая приятная мысль „берем практики у лучших!“ Отсюда же и все аджайлы там, где нужен вотерфолл (да, так бывает), перфоманс ревью которые ни на что не влияют и прочие „модные“ вещи.
Еще одна вещь находится уже на уровне межличностных отношений. В принципе, если вы идете на собеседование на какую-то позицию, вы понимаете, что кроме вас есть еще N людей которые на нее претендуют. И часть этих людей владеет теми же навыками что и вы, плюс-минус на таком же уровне. И если вакансия хорошая – то здесь уже работодатель может выбирать. И кроме технических навыков есть вопросы вида „а что это за человек? насколько на него можно полагаться? не уйдет ли он через два месяца? есть ли о чем с ним поговорить?“. И за непонятными на первый взгляд вопросами может крыться просто попытка получше вас узнать. „Как работает https handshake“ = „2 месяца назад на хабре в топе была статья, я ее прочитал, интересно, читал ли ее он“. „Какая сложность у поиска по БД с B-tree индексом“ – „а сталкивался ли он с ситуациями, когда нужен был хитрый не дефолтный индекс“. И от того, ответите вы на этот вопрос „нет“ или „точно не помню, кажется вот так, а кстати у меня была задача похожей тематики и я решал ее вот так“ – зависит многое.
Мораль? Довольно простая – если уж компании делают начальный фильтр при поиске – делайте так же, и не стесняйтесь спрашивать. „Что вам важнее во мне – доскональное знание устройства инструментов или умение ими пользоваться?“ – и вы уже сразу отсекли для себя варианты, где вы бы потратили время на собеседование. „У вас четкие процессы и роли или задачи выбираются по принципу “кто может сделать» – и вы сразу отделили стартап-культуру от кровавого энтерпрайза. «Что вы именно вы хотите от тестового задания» – и тут уже можете предложить кучу вариантов – показать github, накидать в виде диаграммы прямо на собеседовании, или же сказать – «а дайте мне нормальную задачу на неделю, контекст, я его сделаю, вы поймете намного больше обо мне чем за 4-8 часовое задание, но я попрошу за него Х денег». Если вы задаете вопросы – это хороший способ выделиться (в том случае если вы именно тот кто нужен компании) либо сразу отсечь варианты.
Всем удачи!
(Пока что мы опустим случаи, когда HR/собеседующий разработчик/вся компания дурные – да, такое случается, но это не единственный возможный случай возникновения подобных фрустраций)
В англоговорящем коммьюнити есть два разных слова – Developer и Engineer, которые как раз и означают упомянутые выше два разных типа людей
Engineer – это человек с фундаментальными знаниями, часто с формальным образованием в области computer science либо чрезвычайно любопытный и жадный до глубинного понимания происходящего. Такого человека хотят в технологические компании – FAANG, вендоры софта и прочие; технологические стартапы (моднейшие эйаи, машин лёрнинги и иже с ними). Как раз в такие компании нужен человек, который отлично знает CS и его на собеседованиях спросят про CAP/ACID/деревья и прочее; вчерашнего выпускника вполне можно попросить написать сортировку.
Developer – человек в основном с практическими знаниями. Образование – обычно техническое (часто не-гуманитарий тоже подходит – знаю врача и химика – разработчиков). Такого человека хотят в не-технологические компании и стартапы – в общем, куда угодно, где есть разработка, но важна скорее не инновационность, а надежность и предсказуемость. Нет смысла на собеседовании спрашивать про фундаментальные вещи – они все вшиты в инструменты, которыми он пользуется; скорее важно узнать уровень владения инструментами.
Казалось бы – если все так просто, то почему возникают проблемы? Самая первая и очевидная причина – тупое копирование без ответа на вопрос „а почему там так?“ Гугл спрашивает про люки? Ну так и мы спросим, и вот уже где-то в головах селится маленькая приятная мысль „берем практики у лучших!“ Отсюда же и все аджайлы там, где нужен вотерфолл (да, так бывает), перфоманс ревью которые ни на что не влияют и прочие „модные“ вещи.
Еще одна вещь находится уже на уровне межличностных отношений. В принципе, если вы идете на собеседование на какую-то позицию, вы понимаете, что кроме вас есть еще N людей которые на нее претендуют. И часть этих людей владеет теми же навыками что и вы, плюс-минус на таком же уровне. И если вакансия хорошая – то здесь уже работодатель может выбирать. И кроме технических навыков есть вопросы вида „а что это за человек? насколько на него можно полагаться? не уйдет ли он через два месяца? есть ли о чем с ним поговорить?“. И за непонятными на первый взгляд вопросами может крыться просто попытка получше вас узнать. „Как работает https handshake“ = „2 месяца назад на хабре в топе была статья, я ее прочитал, интересно, читал ли ее он“. „Какая сложность у поиска по БД с B-tree индексом“ – „а сталкивался ли он с ситуациями, когда нужен был хитрый не дефолтный индекс“. И от того, ответите вы на этот вопрос „нет“ или „точно не помню, кажется вот так, а кстати у меня была задача похожей тематики и я решал ее вот так“ – зависит многое.
Мораль? Довольно простая – если уж компании делают начальный фильтр при поиске – делайте так же, и не стесняйтесь спрашивать. „Что вам важнее во мне – доскональное знание устройства инструментов или умение ими пользоваться?“ – и вы уже сразу отсекли для себя варианты, где вы бы потратили время на собеседование. „У вас четкие процессы и роли или задачи выбираются по принципу “кто может сделать» – и вы сразу отделили стартап-культуру от кровавого энтерпрайза. «Что вы именно вы хотите от тестового задания» – и тут уже можете предложить кучу вариантов – показать github, накидать в виде диаграммы прямо на собеседовании, или же сказать – «а дайте мне нормальную задачу на неделю, контекст, я его сделаю, вы поймете намного больше обо мне чем за 4-8 часовое задание, но я попрошу за него Х денег». Если вы задаете вопросы – это хороший способ выделиться (в том случае если вы именно тот кто нужен компании) либо сразу отсечь варианты.
Всем удачи!
Проблема что как правило этого спросить не у кого. Если нанимают значит дела идут хорошо, вам об этом и скажут, что все очень круто, у нас самые лучшие процессы и прочее. У Бугаенко есть хорошая статья по этому поводу — www.yegor256.com/2017/02/21/say-no-to-google-recruiters.html
НЛО прилетело и опубликовало эту надпись здесь
Я живу в «англоязычном коммьюнити» и описываемого вами разделения на инженеров и разработчиков не замечал. Названия могут быть разные: architect, developer, specialist, engineer, programmer, consultant, а суть, по сути, одна и та же.
Возможно, речь о какой-то конкретной стране, там где я живу это не так.
Возможно, речь о какой-то конкретной стране, там где я живу это не так.
Мне кажется, все зависит от компании. У некоторых как-то формируются внутренние команды постепенно и потом уже никто не меняет должности. Иногда доходит до смешного, что команда называется так, а делают практически совсем не то.
Например, видел кто-то искал UNIX engineer. На самом деле системный администратор нужен для Линукса, просто у них так давно сложилось название.
Например, видел кто-то искал UNIX engineer. На самом деле системный администратор нужен для Линукса, просто у них так давно сложилось название.
Никогда такого не было и вот опять!
Как раз сейчас в поиске.
Общался с представителями одной крупной российской компании. Собеседование на час. Примерно полчаса я слушал рассказ про компанию, и задавал вопросы, оставшееся время я решал в блокнотике задачку олимпиадного класса. Решил. Правда без особого воодушевления, скажу честно. Через неделю пришел фидбек (что само по себе уже круто для наших фирм), мол не подхожу т.к. не понравилось как я решил задачу… Охренеть, сказать по правде — я в шоке, опыт участия в куче проектов, знание всяких там разных заморочек, это фигня — главное умение за полчаса накарябать в блокноте алгоритм решения оторванной от реальности задачки из олимпиадного сборника.
Общался с представителями одной крупной российской компании. Собеседование на час. Примерно полчаса я слушал рассказ про компанию, и задавал вопросы, оставшееся время я решал в блокнотике задачку олимпиадного класса. Решил. Правда без особого воодушевления, скажу честно. Через неделю пришел фидбек (что само по себе уже круто для наших фирм), мол не подхожу т.к. не понравилось как я решил задачу… Охренеть, сказать по правде — я в шоке, опыт участия в куче проектов, знание всяких там разных заморочек, это фигня — главное умение за полчаса накарябать в блокноте алгоритм решения оторванной от реальности задачки из олимпиадного сборника.
Ну это значит что вы не готовились, а они хотели чтобы человек готовился. Т.е. потратив полгода вечерами на выполнение всяких олимпиадных заданий(относительно бесполезных в реальном мире) и устроившись в итоге, вы будете крайне лояльны к компании и не будете замечать внутреннего треша. А придя с наскоку с вашим опытом, можете потенциально мутить воду
Точно буду лояльнее?
Если я угроблю пол года на бесполезные задачи, потом приду в компанию — а там треш, бардак и феерия тараканов с салютом — я буду ещё более разочарован.
Если я угроблю пол года на бесполезные задачи, потом приду в компанию — а там треш, бардак и феерия тараканов с салютом — я буду ещё более разочарован.
Почему разочарован — все во первых относительно, а во вторых вы будете счастливы(счастье возникает когда преодолеваются трудности), т.е. будете все видеть в розовом свете
Нет, они проверяют вас на вменяемость.
Вот, смотрите пример: Во многих странах надо собирать мусор раздельно. При этом неважно то, что очень часто раздельно собранный мусор в конечном итоге попадает в общий бак и потом его так и захоранивают или уже промышленно повторно перебирают.
Вот собираете вы раздельно мусор — вы вменяемы (да ещё есть и график вывоза — пластмасса в третий четверг чётного месяца, а бумага через два дня, но только по чётным числам, исключая понедельника).
А то что ваш раздельно собранный вами мусор попадает в общий бак — это "внутренний треш", но это неважно для определения вашей вменяемости
Вот, смотрите пример: Во многих странах надо собирать мусор раздельно. При этом неважно то, что очень часто раздельно собранный мусор в конечном итоге попадает в общий бак и потом его так и захоранивают или уже промышленно повторно перебирают.
Вот собираете вы раздельно мусор — вы вменяемы (да ещё есть и график вывоза — пластмасса в третий четверг чётного месяца, а бумага через два дня, но только по чётным числам, исключая понедельника).
А то что ваш раздельно собранный вами мусор попадает в общий бак — это "внутренний треш", но это неважно для определения вашей вменяемости
При этом неважно то, что очень часто раздельно собранный мусор в конечном итоге попадает в общий бак
Не правда, как раз жителям тех стран, где действительно почти все сортируют мусор раздельно, очень даже это важно.
это «внутренний треш», но это неважно для определения вашей вменяемости
Вообще-то, настоящие вменяемые граждане в Западной стране, если узнают о таком треше, дойдут до администрации и заставят её дать по шапке уборщикам. Модель «мы видим как рабочие кладут асфальт в лужу, но промолчим» это не про развитые страны Запада.
Нет, они проверяют вас на вменяемость.
Я бы сказал, что без реальной цели (хобби, место в гугле, большой приз на Олимпиаде) угробить несколько лет жизни, чтобы научится решать олимпиадные задачи высшей сложности — это как раз не очень вменяемое решение.
У меня, кстати, похожее было. На собеседовании долго обсуждали солид, java 8 (на тот момент самый топчик был), многопоточность, всякие разные прикольные вещи, и я воодушевленный после оффера вышел на работу — а там царство криво написанного легаси, какими-то студентами в махровом году, которое бывало просто не работало даже в критичных местах, причем тот самый тимлид, с которым так интересно было общаться, работал там уже несколько лет, и списать весь этот адЪ и ИзраилЪ на предшественника не мог.
Ну, может быть оно и хорошо, не спорю, треша мне не надо, я его и так насмотрелся уже.
устроившись в итоге, вы будете крайне лояльны к компании и не будете замечать внутреннего треша
Зависит от компании. Если крупные аутсорс компании собеседуют не в проект а вообще в компанию то им сложно понимать что спрашивать кандидатов. Вот и получаются вопросы на разные темы потому что может пригодиться. Не то что бы это правильно но мне кажется логично.
Техсобеседования обычно проводят такие же разработчики. Намного проще сравнивать кандидатов задавая им одни и те же вопросы, как раз что-то наподобие ACID и сортировок. О проектах конечно здорово разговаривать, но затратно по времени, куда проще за час пописать вместе код, поспрашивать основы основ в алгоритмах и десять минут поговорить о проектах. Неотвеченный вопрос про ACID совершенно не означает проваленного собеседования, но тот кто ответит имеет приоритет.
Что такое I в ACID
I — изолированность, то есть другие параллельные транзакции не должны оказывать влияние на результат данной.
А знаете, какие этапы в https-handshake? Я знал когда-то, забыл — не надо. Но мне хватило 5 минут, чтобы открыть гугл и вспомнить, когда настраивал A+ рейтинг в nginx пару лет назад. И знаете что? Сейчас я опять не помню.
А вообще, как-то у одного нобелевского лауреата попросили разъяснить сложную формулу, то он ответил, что не помнит этой формулы. Тогда у него спросили, как он решает задачи, не зная формул, и он ответил: «ну, я не помню многих формул, но я помню, где лежат справочники с этими формулами, и на каких страницах мне надо искать».
По личному опыту посещения собеседований, сложилось впечатление деления, грубого, на два типа вакансий. Первый тип, когда ищут подходящего человека. Именно с таким типажом, набором знаний и вообще подходом, который устраивает. Вы не можете быть ни хуже ни круче, чем требуется. Они могут долго искать. Другой тип подразумевает потребность в человеке на вакансии. И там смотрят, насколько кандидат способен решать задачи. Берут лучшего из пришедших.
Первый тип вакансий висит годами. Второй закрывают быстро.
Ещё сложилось впечатление, что иногда первый тип шифруют под вторым. Закрывая его через определённый промежуток времени и опять открывая чуть позже. Например, в зависимости от жирности на кандидатов месяца.
Естественно, есть ещё варианты исследовательских собеседований, уже упомянутых KPI кадровиков и тому подобных, но они непосредственно к паре вакансия-кандидат отношения не имеют.
Лично я к вопросам уже давно отношусь в глубине души толерантно. Хотят люди так? Пусть. Их песочница. В конце концов, я ищу одну работу. Бывает, конечно, утомляет, но в остальном — пусть.
Так-то, на мой взгляд, когда человек работает в своей области более-менее длительное время, кухня всяческих косяков, подходов, лени уже известна и видно, куда кандидат тянет. Есть, впрочем, вариант, что действительно всё-таки видят и потому заваливают, а у меня создаётся превратное впечатление о их слепоте. С другой стороны, спрашивал у некоторых и они действительно не имеют представления о людях своей профессии. Обладают только фактическими знаниями, навыками, а в остальном «я ничего не понимаю». Они не готовы что-либо систематизировать за рамками своих непосредственных обязанностей.
Первый тип вакансий висит годами. Второй закрывают быстро.
Ещё сложилось впечатление, что иногда первый тип шифруют под вторым. Закрывая его через определённый промежуток времени и опять открывая чуть позже. Например, в зависимости от жирности на кандидатов месяца.
Естественно, есть ещё варианты исследовательских собеседований, уже упомянутых KPI кадровиков и тому подобных, но они непосредственно к паре вакансия-кандидат отношения не имеют.
Лично я к вопросам уже давно отношусь в глубине души толерантно. Хотят люди так? Пусть. Их песочница. В конце концов, я ищу одну работу. Бывает, конечно, утомляет, но в остальном — пусть.
Так-то, на мой взгляд, когда человек работает в своей области более-менее длительное время, кухня всяческих косяков, подходов, лени уже известна и видно, куда кандидат тянет. Есть, впрочем, вариант, что действительно всё-таки видят и потому заваливают, а у меня создаётся превратное впечатление о их слепоте. С другой стороны, спрашивал у некоторых и они действительно не имеют представления о людях своей профессии. Обладают только фактическими знаниями, навыками, а в остальном «я ничего не понимаю». Они не готовы что-либо систематизировать за рамками своих непосредственных обязанностей.
это вы еще в Фейсбук и Гугл не собеседовались
С другой стороны, Вы же тоже на них смотрите, неправда ли? В Akveo вы нашли единомышленников, способных разговаривать с вами на одном языке. Это тоже дорогого стоит.
В разработке 11 лет.
Писал на 13 языках (без учета всяких html, css, bash, sql)
Не очень понимаю, чем автор здесь пытается хвалиться — если ты мастер на все руки, это значит, что ты «везде по чуть-чуть», а больше всего ценятся крутые специалисты в узкой области.
Стать крутым в 13 языках физически невозможно.
Так можно всю жизнь писать на одном языке и не стать крутым. А «не крутой специалист», имеющий обширные знания, всё-таки, лучше, чем «не крутой специалист» в узкой области.
а больше всего ценятся крутые специалисты в узкой области.
ну можно стать тимлидом или выше, там как раз более ценится знания 13 языков чтобы рулить фронтом-беком-базой-девопсами и понимать что вообще происходит...(и как по мне это поинтереснее чем в узкой сфере мариноваться)
Можно быть крутым в трёх языках и как-то знать ещё десять. За 11 лет как раз можно на это прокачаться.
Валят бывает чтоб цену сбить. Меня лично пару раз руководители просили поднажать на кандидата, чтоб чувак поубавил аппетиты и охотнее согласился на меньшее, видя что на заявленное он «не тянет». Не знаю как это могло сработать, но «они менеджеры и им виднее».
Согласен с автором на все 100%.
Практика и еще раз практика. Тоже считаю, что главное это не академические знания, хотя основные принципы и практики конечно надо знать. Главное, наверное, научиться копать, часто интуитивно. Уметь не опускать руки.
Тоже не могу вспомнить про конкретные детали своего диплома. Тоже не помню содержимого кучи своих проектов, хотя прекрасно помню в общих чертах, для чего это, и насколько эффективно получилось реализовать. Видимо всё наименее используемое в последнее время вымещается из головы за ненадобностью, остается только полезное и понадобившееся, эдакая сортировка жизненным опытом.
Всегда интересно, что надо сделать, и не интересно на каком языке или фреймворке, потому как освоить в принципе не сложно, и обычно много документации и примеров.
Практика и еще раз практика. Тоже считаю, что главное это не академические знания, хотя основные принципы и практики конечно надо знать. Главное, наверное, научиться копать, часто интуитивно. Уметь не опускать руки.
Тоже не могу вспомнить про конкретные детали своего диплома. Тоже не помню содержимого кучи своих проектов, хотя прекрасно помню в общих чертах, для чего это, и насколько эффективно получилось реализовать. Видимо всё наименее используемое в последнее время вымещается из головы за ненадобностью, остается только полезное и понадобившееся, эдакая сортировка жизненным опытом.
Всегда интересно, что надо сделать, и не интересно на каком языке или фреймворке, потому как освоить в принципе не сложно, и обычно много документации и примеров.
Я немного не соглашусь. Тут не академические знания, а вполне практические вещи. И с этим ребята, которые меня собеседовали, явно сталкивались. Но, когда ты с чем-то долгое время не работал — это просто выветривается из головы. И вот собеседующий сталкивался с этим вчера, а ты — три года назад. Суть в том, что эти вещи — не rocket sciense, и очень быстро восстанавливаются, но ответа от тебя хотят прямо здесь и сейчас.
Помню, был у меня опыт работы с заказчиком в разных часовых поясах. Мы России (по московскому времени), а заказчик в Нью-Йорке — идеальная была работа! я был проджектом в команде мобильных разработчиков. Мы пашем, пока заказчик еще спит, а вместо доброго утра отправляем готовый билд с правками и хотелками, которые он вчера отправил.
Я в Канаде, босс в Швейцарии. Есть примерно три часа, когда мы можем общаться. Я раньше вставал в четыре утра, чтобы быть доступным, но мне сказали — не сходи с ума. Теперь график вполне комфортный, хотя я всё равно встаю рано. Встаю, читаю слак, отвечаю на вопросы и принимаю ц/у. Потом спокойно работаю сколько надо и пушу фиксы на гитхаб. Когда я сплю, они обновляют скрипты и проверяют в деле. К тому моменту, как я просыпаюсь, уже готовы новые жалобы и предложения.
Умение проходить собесы и умение работать слабо пересекаются в большинстве случаев. Нужно качать и то и то. Потому что это вряд ли изменится. Один в один читал статью 5 лет назад.
Проблема многих контор в том, что они не знают до конца какой человек им нужен. Отсюда все эти крайне неэффективные собеседования и люди нанятые не на свое место. И хорошо, если от таких людей удается быстро избавиться или они сами уходят
Нормальная статья была, почти без нытья как обычно бывает в таких опусах, пока не оказалось что ACID и CAP не нужны. А как же проблема именования и инвалидации кэша?
Ну что вы, все знания нужны и важны. Просто каждому знанию свое место и время. Я лишь написал, что разработчик с действительной большим опытом не будет тратить время (которого у него и так не много) на чтение абстрактной теории, чтобы блеснуть на собеседовании. Ну какой в этом смысл? При этом он прекрасно может знать и работать с транзакциями разных видов, и на практике (что важнее) понимать, что происходит.
Мне вот непонятно, как можно не понимать, что сложность поиска в дереве логарифмическая. Это, конечно, абстрактная теория, но на уровне таблицы умножения в программировании. Следующее после понимания о том, что сортировка пузырьком квадратична. Если программиист не знает об этом, то я бы считал, что с алгоритмами он не знаком вообще.
Несомненно не всем кодерам нужны базовые знания алгоритмов — есть очень много задач, в которых ни одного if написать не придётся. Но я бы сказал, что в большинстве случаев они желательны. И для меня это очень-очень жирный минус при рассмотрении кандидата. Программист без знания алгоритмов очень негибок — даже если прямо сейчас на рассматриваемой позиции они и не нужны, то весьма вероятно, что завтра появятся задачи, где базовое понимание необходимо и тогда этот работник станет лишней головной болью.
Несомненно не всем кодерам нужны базовые знания алгоритмов — есть очень много задач, в которых ни одного if написать не придётся. Но я бы сказал, что в большинстве случаев они желательны. И для меня это очень-очень жирный минус при рассмотрении кандидата. Программист без знания алгоритмов очень негибок — даже если прямо сейчас на рассматриваемой позиции они и не нужны, то весьма вероятно, что завтра появятся задачи, где базовое понимание необходимо и тогда этот работник станет лишней головной болью.
А то, что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность? Я вчера узнал, вот теперь и вы.а не в PostgreSQL? =)
А если серьезно — ну ладно не помнить (хотя такое забывать — странно), но быстро прикинуть зная что такое B-tree и как принципиально работает индекс еще и озвучив процесс прикидывания интервьюеру — добавит очков.
Собеседование это не квиз (ну по крайней мере не должно быть), и там куда менее полезны мгновенные ответы «потому что я готовился», чем демонстрация того как эти ответы ищутся.
Я могу только за Канаду сказать, но здесь, если ты хотя бы крепкий миддл, то найм на работу выглядит не так. Отбиваешься от рекрутёров постоянно, даже если в линкдин явно написано — работу не ищу. Если дал согласие рассмотреть позицию, то собес проходит как дружеская беседа, чтобы убедиться, что ты тот, за кого выдаёшь и не мудак. Бывает и вайтборд, и сортировка пузырьком, но это скорее чтобы посмотреть умение общаться и рассуждать. А уж таких, как автор, просто за ручку будут приводить на фирму, и следить, чтоб не обидели.
«Валить» на собеседовании могут по разным причинам:
1) Интервьюер «считал» психологический портрет соискателя в первую минуту знакомства, и считает, что он не подходит по соображениям психологической совместимости и личных качеств. Часто обосновать отказ, завалив соискателя на технических вопросах, проще, чем обосновать коллегам эту самую несовместимость, когда собеседуют технари а не психологи.
2) Соискатель заранее оценен как скорее всего неподходящий по квалификации или специализации по резюме, но поскольку он изъявил желание — с ним беседуют в надежде, что он всё же покажет нужные качества.
3) Кто-то хочет, чтобы вакансия досталась его протеже.
4) Соискатель проявил себя как человек, который не горит желанием «педалить», а привык руководить, и хочет поскорее пробиться в руководители — это может угрожать положению интервьюера.
Во всех этих случаях интервьюер не станет вникать в написанный соискателем код до тех пор, пока обстоятельства, мотивирующие его заваливать соискателя не исчезнут.
Впрочем, вопросы, на которые соискатель скорее всего не ответит — ещё не признак желания завалить. Я всегда задаю некоторый диапазон вопросов — от тех, на которые этот человек должен знать ответ, до тех, на которые он скорее всего ответа не знает, а если всё же знает — задаю вопросы ещё сложнее. Это помогает оценить квалификацию и кругозор, и ответы приносят немало сюрпризов и в ту и в другую сторону. А анализ кода, написанного соискателем, — это очень полезно, и я всегда прошу прислать код до собеседования, чтобы определиться с уровнем разработчика и построить собеседование. Но это требует времени — в коде нужно найти скользкие места, чтобы поговорить о них на собеседовании, и определить таким образом, действительно ли именно этот человек этот код написал.
1) Интервьюер «считал» психологический портрет соискателя в первую минуту знакомства, и считает, что он не подходит по соображениям психологической совместимости и личных качеств. Часто обосновать отказ, завалив соискателя на технических вопросах, проще, чем обосновать коллегам эту самую несовместимость, когда собеседуют технари а не психологи.
2) Соискатель заранее оценен как скорее всего неподходящий по квалификации или специализации по резюме, но поскольку он изъявил желание — с ним беседуют в надежде, что он всё же покажет нужные качества.
3) Кто-то хочет, чтобы вакансия досталась его протеже.
4) Соискатель проявил себя как человек, который не горит желанием «педалить», а привык руководить, и хочет поскорее пробиться в руководители — это может угрожать положению интервьюера.
Во всех этих случаях интервьюер не станет вникать в написанный соискателем код до тех пор, пока обстоятельства, мотивирующие его заваливать соискателя не исчезнут.
Впрочем, вопросы, на которые соискатель скорее всего не ответит — ещё не признак желания завалить. Я всегда задаю некоторый диапазон вопросов — от тех, на которые этот человек должен знать ответ, до тех, на которые он скорее всего ответа не знает, а если всё же знает — задаю вопросы ещё сложнее. Это помогает оценить квалификацию и кругозор, и ответы приносят немало сюрпризов и в ту и в другую сторону. А анализ кода, написанного соискателем, — это очень полезно, и я всегда прошу прислать код до собеседования, чтобы определиться с уровнем разработчика и построить собеседование. Но это требует времени — в коде нужно найти скользкие места, чтобы поговорить о них на собеседовании, и определить таким образом, действительно ли именно этот человек этот код написал.
А что на что вы смотрите в коде, если не секрет? Т.е. понятно, что треш-угар в коде — сразу нет. Но вот код… Обычный такой. У человека, который не коммитит активно в пет-проект, может быть под рукой совершенно невыразительный код. Как тогда?
Понятно, что вопрошающий часто проецирует свою ситуацию. У меня есть, чем гордиться в портфолио, и проблем на интервью с этим нет. Но вот когда просят показать код, я всегда теряюсь. Потому что показать я могу либо код, который написан 7-10 лет назад, либо тысячи мелких экспериментов в духе "а как работает эта либа?". Я бы не хотел, чтоб меня оценивали ни по первому, ни по второму :-)
Кроме явно непрофессионального кода встречается отсутствие желания сделать код понятным для прочтения, иногда даже прослеживается желание запутать, бывает очень неоптимальный код. Также смотрю на организацию кода и организацию взаимодействия процессов. В принципе присылать код не обязательно, но тогда будет больше вопросов, а для не очень опытных программистов — тестовое задание, и чем меньше опыта — тем объёмнее задание.
Почему-то почти у всех тут два заблуждения:
- собеседуемый может быть взят только если ответил на все вопросы;
- не надо задавать те вопросы, ответы на которые могут не понадобиться в работе.
Цель собеседования — узнать что-то о человеке за короткое время. Настолько хорошо, насколько это возможно (понятное дело, что в ограниченное время многого не получится).
Беседы на разные темы помогают понять насколько адекватный человек перед нами, чем он интересуется, в чём силён, etc. И отсутствие ответа на какой-то отдельный вопрос зачастую не говорит ничего плохого о человеке, это всего лишь небольшой штришок в общей картине (хотя, конечно, зависит от вопроса и от позиции, на которую претендует человек).
Относительно недавно побывала по обе стороны баррикад. Для себя сделала выводы, что собеседование -это не ответ на вопрос насколько человек плохой или хороший специалист, а насколько он подходит под потребности на проекте и впишется в команду. Не воспринимайте это лично. Иногда нужен не тот, кто может быстро разобраться, а у кого есть конкретный опыт. Не всегда бывает у компании возможность дать даже очень толковому кандидату время освоиться в технологии. С другой стороны, сейчас все-таки в большинстве случаев собеседуют люди из команды, если у Вас сразу не сложился конструктивный технический диалог, то вряд ли он сложится в дальнейшем. Ну и «лучше не взять хорошего кандидата, чем взять плохого» и « пошёл бы я пить пиво с ним» — уже наверное классические принципы найма :)
Иногда нужен не тот, кто может быстро разобраться, а у кого есть конкретный опыт.
Да, но когда на собеседовании спрашивают про сбалансированные деревья или алгоритмы сортировки — почему-то можно быть на 99.9% уверенным, что им не нужен человек с конкретным опытом в деревьях и сортировках.
За последние 4 года я провел около 300+ интервью. Зачастую на собеседовании нужно идти от обратного. Просто поставить себе цель не «Проверить скилы человека под позицию» а «Оценить уровень». Надо начинать с простых вопросов. Интервью — это стресс для кандидата.
Я обожаю спрашивать самые простые задачи, но они должны быть показательными.
Пример: «Посчитать уникальное количество символов в строке. „AABB“ = 2, „ABBA“ = 2, „AAAA“ = 1»
Почему задача показательная? Потому что ее можно решить множеством способов, но чистых будет мало. Большинство (да да 80%), решают данную задачу через «Map» и это странно. Ну да ладно.
Не надо сразу давать вопросы уровня Nightmare. Очень приятно поговорить про базовый уровень, типа сложность коллекций и так далее.
Вам необходимо нащупать тот уровень, где кандидат начинает плавать в вопросах.
Почему это хорошо? Допустим у вас стоит задача найти Senior, а кандидат идет как Intermediate. Возможно в вашей компании есть открытая позиция. Да и зачастую выгоднее взять смышленого Inter`а чем зазнавшегося Senior`a
Ах да, по возможности давайте отзыв о кандидате ему лично. За последние 5 минут, сказать где у него были недочеты и что ему нужно улучшить. «Извини дорогой Джонни, в нашем проекте необходимы знания в А Б В — фреймворках, а ты плохо в них разбираешься. Давай ка ты почитаешь книги от А.Я. Клешня И.Я Клешня, и попробуешь через полгода» — таким образом человек будет знать, в каких областях ему нужно улучшить знания.
Я обожаю спрашивать самые простые задачи, но они должны быть показательными.
Пример: «Посчитать уникальное количество символов в строке. „AABB“ = 2, „ABBA“ = 2, „AAAA“ = 1»
Почему задача показательная? Потому что ее можно решить множеством способов, но чистых будет мало. Большинство (да да 80%), решают данную задачу через «Map» и это странно. Ну да ладно.
Не надо сразу давать вопросы уровня Nightmare. Очень приятно поговорить про базовый уровень, типа сложность коллекций и так далее.
Вам необходимо нащупать тот уровень, где кандидат начинает плавать в вопросах.
Почему это хорошо? Допустим у вас стоит задача найти Senior, а кандидат идет как Intermediate. Возможно в вашей компании есть открытая позиция. Да и зачастую выгоднее взять смышленого Inter`а чем зазнавшегося Senior`a
Ах да, по возможности давайте отзыв о кандидате ему лично. За последние 5 минут, сказать где у него были недочеты и что ему нужно улучшить. «Извини дорогой Джонни, в нашем проекте необходимы знания в А Б В — фреймворках, а ты плохо в них разбираешься. Давай ка ты почитаешь книги от А.Я. Клешня И.Я Клешня, и попробуешь через полгода» — таким образом человек будет знать, в каких областях ему нужно улучшить знания.
НЛО прилетело и опубликовало эту надпись здесь
Зачастую на собеседовании нужно идти от обратного. Просто поставить себе цель не «Проверить скилы человека под позицию» а «Оценить уровень».
На мой взгляд это заведомо неэффективный подход. Вам не «уровень» нужен, а вполне определенную работу работать — ergo, вы тратите лишние силы и время на выяснение того, что на самом деле не так уж и важно. Другое дело, что требования к позиции должны быть определены. «Нужен сеньёр в языке Z» — это не требования, а сферическая в вакууме чушь.
НЛО прилетело и опубликовало эту надпись здесь
Я прошел около 15 собеседований, и в 13 из них мне предложили работу.
Если спрашивать наводящие вопросы, и слушать как человек излагает свои мысли, как отвечает на вопросы. То станет понятно знает ли он это или нет. А устраивать экзамен на собеседовании это глупость.
Вопросы должны быть достаточно понятными без внутренних жаргонов.
Уточнить почему он использовал тот или иной подход. Ни в коем случае не брюзжать по поводу говнокода или прочего.
Если спрашивать наводящие вопросы, и слушать как человек излагает свои мысли, как отвечает на вопросы. То станет понятно знает ли он это или нет. А устраивать экзамен на собеседовании это глупость.
Вопросы должны быть достаточно понятными без внутренних жаргонов.
Уточнить почему он использовал тот или иной подход. Ни в коем случае не брюзжать по поводу говнокода или прочего.
что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность
Вы о чем вообще. Естественно, это надо знать, как индексы устроены в любой СУБД.
чем помнить, как использовать стримы в nodejs. Со стримами хороший разработчик разберется по доке на раз-два
Вот стримы — это как раз пример плохого вопроса. Потому что у них отвратительный дизайн (от безысходности в основном, не хватало у языка в те времена выразительной мощи, да и сейчас тоже не очень с обработкой потоков по сравнению с Эрлангом, например), особенно про backpressure там ад.
хороший узкий специалист будет знать много разных нюансов
Нет, много разных нюансов будет знать хороший специалист.
А сейчас постарайтесь забыть как можно скорее!
Конан Дойл ошибся, когда писал эту сцену. Мозг работает не как компьютерная память, а ровно наоборот: тем больше помнишь/знаешь, тем легче/больше можешь узнать/запомнить нового.
Но забавно то, что большинство из этих компаний искало фуллстек разработчика. И хотели глубоких знаний во всем. Вот прямо сейчас.
И правильно делали. Только они не «хотели», они пытались проверить широту кругозора aka готовность копать до корней.
Было пару собесов в западные компании. И там акцент был на то, что ты знаешь и умеешь, а не попытках подловить на незнании. Или это мне так повезло/не повезло?
Повезло. И никто не пытается подловить на незнании. Интервью — тяжелая и неприятная работа. Интервьюеру нет никакого смысла терять время попусту. Обычно либо сразу видно, что человек «тянет», либо видно, что «не тянет» на данную роль (представьте, что вас оценивают по перцентилям в конце: «Вася P30, мы ему откажем, а вот Петя P95, надо срочно брать»). И таких интервью по 3-4 шт в неделю годами.
Пофигу на прошлые проекты
Примерно правда. Во-первых, резюме перед интервью мало кто читает (да и не нужно это, только предубежденность появляется). Оценивают чистый опыт того, что происходит на самом интервью (45 мин или час) и сравнивают ощущения этого опыта с ощущениями опыта с другими людьми. Все.
У меня для вас непрошеный совет, если позволите. Откройте свой код 5-летней давности. Потом 3-летней давности. Потом годичной давности. Он вам нравится? Если нравится годичной давности, это еще ок. Но если нравится 3-летней или тем более 5-летней… тогда плохие новости.
Спасибо, отличный комментарий! Но почти со всем не согласен)
На минуточку, моя основная специализация — мобильная разработка. Это я к тому, что я не занимаюсь проектированием моделей БД каждый день, хотя время от времени и пишу бекэнды.
Итак, такой день настает. Мой алгоритм. Я набрасываю на бумажке структуры данных приложения и их связи. Еще я знаю, что:
1. Чтобы оптимизировать поиск по часто используемым полям нужны индексы
2. Индексы бывают разных типов (и в каждой бд набор разный)
С БД по каким-то критериям я уже определился. Пусть будет тот же PostgreSQL (хотя я обычно использую mongodb). Дальше:
1. Гугл «postgresql index types»
2. офф дока PostgreSQL www.postgresql.org/docs/current/indexes-types.html
3. 5 мин — пару дней (в зависимости от сложности) — и я уже очень хорошо разбираюсь в теме. И заметьте, эти знания актуальны, а не то, что я запомнил 5 лет назад про индексы в PostgreSQL старой версии.
4. Применяю на практике
5. Успешно забываю до следующего раза
Есть области, которые нахрапом не возьмешь: тот же ML, низкоуровневый рендеринг на мобильных телефонах, сложный процессинг звука. Но я туда и не лезу (только чуть-чуть в ML, но не по работе). Понадобится — найду хорошего узкого специалиста. А будет очень крутой проект, на год, допустим — сам разберусь. Это будет не быстро, но в это время я все равно буду приносить пользу проекту: в любом случае будет какой-то бек, фронт или мобильное приложение.
Вот вы знаете, почему может на работать zIndex в React Native на iOS? Я знаю. Но это не значит, что я хороший специалист, а вы нет. Это значит только, что я натыкался на эти грабли, а вы нет. У каждого свой набор граблей. И чем уже специализация разработчика — тем по большему числу граблей технологии он уже успел походить. И дело не в самих граблях (они будут всегда, идеальных технологий нету), а в умении с этими граблями справляться.
Современные исследования показывают, что мозг может хранить колоссальный объем информации. Так почему же мы не помним всё-всё, с чем сталкивались? Например, лицо официанта в кафе 17 июля 2003 года. Зачем эволюция добавила механизм забывания? Может дело не только в объеме пустого места? Задумайтесь на досуге.
Как знание шагов OAuth покажет готовность копать до корней? Было бы 5-10 минут на ответ — я бы сам придумал какой-то похожий протокол, зная, для чего он нужен. Но вопросы были в формате блица от трех разных людей. Глупо.
То есть вы считаете, что посмотреть проекты разработчика, посмотреть его код, посмотреть статьи и комментарии на технических ресурсах — это предубежденность? Я называю это познакомиться с человеком. А не за час в стрессовой обстановке пытаться из него что-то выжать.
Мне может не нравиться код, который я написал пару месяцев назад. Я постоянно развиваю и улучшаю архитектуру, которую использую в своих проектах, использую более совершенные технологии. Стиль кода меняется не так сильно, но тоже не остается статичным. Например, теперь я использую больше функциональщины, не ставлю ";" после выражений в JS, UPPER_CASE константы стали CamelCase и т.д.
Вы о чем вообще. Естественно, это надо знать, как индексы устроены в любой СУБД.
На минуточку, моя основная специализация — мобильная разработка. Это я к тому, что я не занимаюсь проектированием моделей БД каждый день, хотя время от времени и пишу бекэнды.
Итак, такой день настает. Мой алгоритм. Я набрасываю на бумажке структуры данных приложения и их связи. Еще я знаю, что:
1. Чтобы оптимизировать поиск по часто используемым полям нужны индексы
2. Индексы бывают разных типов (и в каждой бд набор разный)
С БД по каким-то критериям я уже определился. Пусть будет тот же PostgreSQL (хотя я обычно использую mongodb). Дальше:
1. Гугл «postgresql index types»
2. офф дока PostgreSQL www.postgresql.org/docs/current/indexes-types.html
3. 5 мин — пару дней (в зависимости от сложности) — и я уже очень хорошо разбираюсь в теме. И заметьте, эти знания актуальны, а не то, что я запомнил 5 лет назад про индексы в PostgreSQL старой версии.
4. Применяю на практике
5. Успешно забываю до следующего раза
Есть области, которые нахрапом не возьмешь: тот же ML, низкоуровневый рендеринг на мобильных телефонах, сложный процессинг звука. Но я туда и не лезу (только чуть-чуть в ML, но не по работе). Понадобится — найду хорошего узкого специалиста. А будет очень крутой проект, на год, допустим — сам разберусь. Это будет не быстро, но в это время я все равно буду приносить пользу проекту: в любом случае будет какой-то бек, фронт или мобильное приложение.
хороший узкий специалист будет знать много разных нюансов
Нет, много разных нюансов будет знать хороший специалист.
Вот вы знаете, почему может на работать zIndex в React Native на iOS? Я знаю. Но это не значит, что я хороший специалист, а вы нет. Это значит только, что я натыкался на эти грабли, а вы нет. У каждого свой набор граблей. И чем уже специализация разработчика — тем по большему числу граблей технологии он уже успел походить. И дело не в самих граблях (они будут всегда, идеальных технологий нету), а в умении с этими граблями справляться.
Мозг работает не как компьютерная память, а ровно наоборот: тем больше помнишь/знаешь, тем легче/больше можешь узнать/запомнить нового.
Современные исследования показывают, что мозг может хранить колоссальный объем информации. Так почему же мы не помним всё-всё, с чем сталкивались? Например, лицо официанта в кафе 17 июля 2003 года. Зачем эволюция добавила механизм забывания? Может дело не только в объеме пустого места? Задумайтесь на досуге.
Только они не «хотели», они пытались проверить широту кругозора aka готовность копать до корней.
Как знание шагов OAuth покажет готовность копать до корней? Было бы 5-10 минут на ответ — я бы сам придумал какой-то похожий протокол, зная, для чего он нужен. Но вопросы были в формате блица от трех разных людей. Глупо.
да и не нужно это, только предубежденность появляется
То есть вы считаете, что посмотреть проекты разработчика, посмотреть его код, посмотреть статьи и комментарии на технических ресурсах — это предубежденность? Я называю это познакомиться с человеком. А не за час в стрессовой обстановке пытаться из него что-то выжать.
Он вам нравится?
Мне может не нравиться код, который я написал пару месяцев назад. Я постоянно развиваю и улучшаю архитектуру, которую использую в своих проектах, использую более совершенные технологии. Стиль кода меняется не так сильно, но тоже не остается статичным. Например, теперь я использую больше функциональщины, не ставлю ";" после выражений в JS, UPPER_CASE константы стали CamelCase и т.д.
На этапе скрининга (а вы были на скрининге, скорее всего — даже если это было онсайт-интервью) принимается решение, проходит человек на следующий этап по сравнению с другими кандидатами или не проходит. На следующем этапе уже имеет смысл смотреть резюме и проекты, да.
Я обычно смотрю гитхаб-аккаунт в момент принятия решения, приглашать ли человека на скрининг или не приглашать. Но при этом обращаю внимание не на архитектуру, а на общее качество/аккуратность кода скорее. Потому что в 90% случаев код, увы, оказывается плохим (так рынок устроен, из 10 входящих резюме только одно оказывается хоть со сколько-нибудь внятными примерами кода). На архитектуру тут смотреть смысла нет, и так отсев большой.
Если на интервью человек понравился, это обычно бывает в стиле «наконец то!!! мы нашли!!! аааа, надо срочно брать, как сделать так, чтобы он не успел к кому-то еще уйти!!!». И зачем же тут смотреть проекты/архитектуру, еще более отдаляя данное событие?
Поэтому проекты и не смотрят. И ваши отсутствующие точки с запятой и CamelCase константы являются скорее негативным сигналом при том 5-минутом просмотре гитхаба, который в лучшем случае предшествует скринингу (используйте Prettier, это уже стандарт).
Понимаете, то, что вы описали, оно же не просто так. Это следствие наводненности рынка низкоквалифицированными кадрами.
Но это не значит, что я хороший специалист, а вы нет. Это значит только, что я натыкался на эти грабли, а вы нет
Так вот собеседующий и пытается найти общее подмножество этих граблей, что непонятного-то? Если оно совсем мало — то или интересы не сходятся, или собеседуемый некомпетентен.
И именно про это я писал выше — нет ничего плохого, если собеседуемого спросили о чём-то, чего он не знает. Вот если все вопросы о том, чего он не знает — тогда да, или собеседуемый не подходит, или собеседующий неадекватен.
Нытьё какого-то челика и пиар лодки куда его взяли, рили. Немного правды в этом есть, но реалии таковы, что если ты хочешь в условный гугол — ты будешь учиться крутить деревья на борде
Но момент в том, что все конторы из этого списка для читателя из соседней России звучат как одинаковые нонеймы, а не как Гугол или любой из оставшихся FAAN
Ой, вы меня раскусили. Я обиделся на те три компании и в качестве мести написал это пост. По невнимательности забыл только их упомянуть. А весь текст о том, как надо и не надо нанимать опытного разработчика — для отвлечения внимания. В лодку я не пошел работать. Но они мне заплатили, чтобы я упомянул название компании в статье.
А что вам мешает в ходе собеседования сказать: "Извините, вы мне не подходите" и уйти?
Извиняюсь, а вы с каакой планеты? Сколька там часов в сутки?
У автора сотни проектов за 13 лет… сотни… чтож это за проекты такие?
По моему 20 летнему опыту, самый мало-малый проект забирает пол года жизни. По серьезней 1-3 года на 3-4 человека. И это при том что ни один из таких даже не тянет на биг-дата.
У автора сотни проектов за 13 лет… сотни… чтож это за проекты такие?
По моему 20 летнему опыту, самый мало-малый проект забирает пол года жизни. По серьезней 1-3 года на 3-4 человека. И это при том что ни один из таких даже не тянет на биг-дата.
У автора сотни проектов за 13 лет… сотни… чтож это за проекты такие?
Не сотни, в статье полсотни проектов (то есть 50). 13 лет * 12 месяцев / 50 = 3.12 месяца за проект.
Если автор учитывал пет.проекты, студенческие проекты, раздельно считал приложение для бека/мобайла/фронта, проекты во фрилансе и т.п. то может получится и куда больше.
Плюс во фрилансе или аутсорсе легко бывает множество коротких проектов от нескольких недель до нескольких месяцев.
P.S. По-моему 25-летнему опыту* :), ИТ проекты бывают очень-очень разными и не стоит переносить свой опыт на любую разработку.
* — если считать первые некоммерческие хобби проекты в программировании
Соглашусь с автором: когда мозг нагружаешь всё новой и новой информацией, он начинает работать как оперативная память — загружать нужную инфу с гугла(читай — с диска), а после память высвобождается под следующие задачи. Так происходит с многосторонне развитыми людьми.
А может кто новичку пояснить, что такое этот ACID и CAP?
Немного оффтоп, но все же.
У западных компаний (говорю за NL, т.к. живу там) есть другая проблема, сталкивался уже трижды на собесах на Sr Scala developer, причем у меня на одной только скале 5+ лет production experience, плюс еще сколько-то там на других языках до этого. Дают тестовое сразу либо в ответ на application, либо после introduction interview.
Делал одно такое, 3(!) полные user-story, дали дедлайн сколько надо, в итоге заняло неделю времени по вечерам и все выходные (написать нормальный чистый код, тесты, etc). Подвыгорел знатно за время разработки. Но до оффера дошло в итоге. Сами интервью да, никто не валит, а тестовое является как бы поводом для разговора.
По сути статьи полностью согласен, я сам постоянно забываю детали OAuth2, в чем там отличия всяких индексов и тому подобное, и спрашивать это на собесах у себя избегаю. Whiteboard алгоритмы идут туда же. Куда интереснее посмотреть-послушать ход мыслей кандидата в pair programming на каком-нибудь небольшом участке кода (возможно даже из самого проекта). Еще неплохой вариант вместе прикинуть архитектуру простенького приложения.
У западных компаний (говорю за NL, т.к. живу там) есть другая проблема, сталкивался уже трижды на собесах на Sr Scala developer, причем у меня на одной только скале 5+ лет production experience, плюс еще сколько-то там на других языках до этого. Дают тестовое сразу либо в ответ на application, либо после introduction interview.
Делал одно такое, 3(!) полные user-story, дали дедлайн сколько надо, в итоге заняло неделю времени по вечерам и все выходные (написать нормальный чистый код, тесты, etc). Подвыгорел знатно за время разработки. Но до оффера дошло в итоге. Сами интервью да, никто не валит, а тестовое является как бы поводом для разговора.
По сути статьи полностью согласен, я сам постоянно забываю детали OAuth2, в чем там отличия всяких индексов и тому подобное, и спрашивать это на собесах у себя избегаю. Whiteboard алгоритмы идут туда же. Куда интереснее посмотреть-послушать ход мыслей кандидата в pair programming на каком-нибудь небольшом участке кода (возможно даже из самого проекта). Еще неплохой вариант вместе прикинуть архитектуру простенького приложения.
Спрашивать на собеседование «что такое I в ACID» — это идиотизм, или гуглоидиотизм. (С)
Это конечно надо знать, но кому и где? — Правильно! — студенту на экзамене. И всё!
У соискателя с годами практической(!) работы за спиной и десятками проектов, спрашивать про алгоритмы, деревья и «что такое I в ACID» — это идиотизм, ибо это всё равно что каждый раз спрашивать вас типа:
Или вот пример гугл-собеседования на «крышки для люков»:
Пример — когда надо использовать null
Вот вопрос чтобы завалить так уж завалить:
Как применить прошедшее время при просьбе сделать что-то сейчас.
Спасибо. Мы вам позвонИм (или позвОним). (С)
P.S.
Это конечно надо знать, но кому и где? — Правильно! — Только и только сдавая ЕГЭ, а не на собеседовании при приёме на работу!
Это конечно надо знать, но кому и где? — Правильно! — студенту на экзамене. И всё!
У соискателя с годами практической(!) работы за спиной и десятками проектов, спрашивать про алгоритмы, деревья и «что такое I в ACID» — это идиотизм, ибо это всё равно что каждый раз спрашивать вас типа:
После шипящих пишется — ё, если есть чередование с е:
Чёрный (чернь), жёлтый (желтеть), шёлк (шелкопряд), чёрточка (черта)…
Назовите слова исключения!
Правило написания «не» с глаголами имеет много исключений, также связанных с невозможностью лексического отрыва (первой или единственной) приставки от корня слова:
Приведите примеры этих исключений и дайте определение лексического отрыва.
Или вот пример гугл-собеседования на «крышки для люков»:
Попробуйте внятно объяснить, какая разница между «выпить чай» и «выпить чаю»; какая разница между «тут» и «здесь»; почему действие в прошлом можно выразить словами «раньше», «давно», «давеча», «недавно», «намедни» и десятком других и почему в определённых ситуациях их можно заменить друг на друга?
Пример — когда надо использовать null
Почему «ничего» может обозначать не только «ничего», но и «нормально», «хорошо», «отлично», а также «всё в порядке» и «не стоит извинений».
Вот вопрос чтобы завалить так уж завалить:
Как точно назвать наклонение с частицей «бы», когда она выражает в разных ситуациях и условие, и просьбу, и желание, и мечтательность, и необходимость, и предположение, и предложение, и сожаление?
Как применить прошедшее время при просьбе сделать что-то сейчас.
Спойлер
«Быстро ушёл отсюда!»
Краткие формы страдательных причастий прошедшего времени пишутся с одним н или с двумя?
Спасибо. Мы вам позвонИм (или позвОним). (С)
P.S.
Это конечно надо знать, но кому и где? — Правильно! — Только и только сдавая ЕГЭ, а не на собеседовании при приёме на работу!
Ммм… Ну вот честно, я в этой сфере не работал, но думаю примерно так проходят собеседования на должности редакторов на хорошие позиции. Ну либо на еще какие должности с работой с текстом плотно связанные. Более того, я уверен там вопросы еще и хлеще встречаются.
но думаю примерно так проходят собеседования на должности редакторов на хорошие позиции.
Вряд ли. Гуглеидиотизм — это перенос «творческого конкурса» в АйТи. (С)
Раньше люди как попадали в программисты? — Правильно, через распределение на последнем курсе.
В 90-е как? — Меня спросили, — Clipper знаешь? Можешь написать валютный опердень обменного пункта валют?
Могу, — ответил я, — и меня взяли писать именно то что и спрашивали — программу на Clipper и именно валютный опердень обменного пункта валют.
А потом пришёл 21 век и Гугл перенёс из цирка в АйТи «творческий конкурс», изменив его суть.
В цирке то как — приходишь и приносишь своих собачек и показываешь. Тебя берут или не берут, но если берут, то слонов тренировать ты не будешь.
В балете то как — приходишь и крутишь фуэте. Тебя берут или не берут, но если берут, то петь в хоре ты не будешь.
На радио то как — приходишь на конкурс дикторов и читаешь текст. Тебя берут или не берут, но если берут, то танцевать ты не будешь.
А как в АйТи по версии Гугла — приходишь на собеседование и тебя (новичка или уже 10 лет в АйТи проработавшего) спрашивают по деревьям, сортировке и прочему и если берут, то ни деревьями ни сортировкой ты занимать не будешь.
Гугло-собеседование — это перенос творческого конкурса из цирка в АйТи.
И этот гуглоидиотизм есть порождение 21 века. (С) И оно оказалось заразно.
Абсолютно согласен с мнением. В современном мире лучше придерживаться информационной диеты и употреблять именно то, что тебе нужно сегодня. Чтобы не случилось потом информационного ожирения — когда ты весишь много, но мало двигаешься и проблемы со здоровьем.
На Хабре отфильтрованная общей адекватностью сообщества информация. Поэтому соответсвует концепции «диеты»
Ну красавчик же, заодно и пропиарился… :D
Навык прохожения интерьвю — это отдельный навык.
Приходится его тренировать.
Приходится его тренировать.
Не везде это было, но встречалось. Интересно, это у нас менталитет такой? Задоминировать и показать свою крутость?
Вот тоже ощутил это на себе — в далеком 2009 году, когда понял, что надо искать новую работу и походил по по собеседованиям.
не могли бы дать совет тому, кто не хочет работать на дядю и смотрит в сторону фриланса? почему Вы решили проходить интервью в конторы после 5 лет фриланса?
Стабильность
в статье написано «хороших проектов у тебя на год вперед»
стабильность чего?
стабильность чего?
Всего:
рабочий график — пн-пт 9:17
зарплата — каждый мес одна и та же сумма падает на счет
больничные
отпуск — раз в год спокойно отдыхаешь, а тебе за это платят
каждый день одни и теже коллеги и начальство плюс-минус
одни и те же задачи плюс-минус, зачастую один и тот же проект(технология) годами
Кому нравится стабильность — выбирает работу по найму.
Быть фрилансером — звучит гордо, но по всем перечисленным пунктам постоянные скАчки то вверх, то вниз. И многих эти качели напрягают. Не говоря уже о том, что часто и заработок меньше при бОльших нагрузках.
рабочий график — пн-пт 9:17
зарплата — каждый мес одна и та же сумма падает на счет
больничные
отпуск — раз в год спокойно отдыхаешь, а тебе за это платят
каждый день одни и теже коллеги и начальство плюс-минус
одни и те же задачи плюс-минус, зачастую один и тот же проект(технология) годами
Кому нравится стабильность — выбирает работу по найму.
Быть фрилансером — звучит гордо, но по всем перечисленным пунктам постоянные скАчки то вверх, то вниз. И многих эти качели напрягают. Не говоря уже о том, что часто и заработок меньше при бОльших нагрузках.
Заглянул в статью, чтобы вспомнить что такое I в ACID, но не тут то было )
Ловко!
Ловко!
Нельзя взять и просто принять на работу devops/sysadmin/anykey который наизусть не знает все по модели OSI, по всем протоколам и всем портам наизусть! Спасибо, автор! Читал и плакал!
Что такое I в ACID или вы нам не подходите