LINUX.ORG.RU
ФорумTalks

Про собеседования на вайтборде

 


3

2

Наткнулся на забавный пост Бугаенко, который обиделся на рекрутеров Амазона на тему рисования алгоритмов на вайтборде.

Вот тут можно посмотреть сумму срачей со ссылками:
https://jug.ru/2017/02/bugayenko-recruiters/

Вот про сам вайтборд - это интересно! Я не использовал ручку с бумагой уже лет, наверное, десять. Если нужно вести конспект живой речи, обычно это делается с ноутбуком, в котором открыт софт для Mind Mapping (типа Mindjet MindManager - там удобные хоткеи и вообще). Если надо нарисовать диаграмму - то она рисуется мышкой в Визио (или чем-то получше типа Magicdraw UML, если на него есть деньги). Если нужно нарисовать график, то это точно будет эксель и кальк, но никак не тетрадка в клетку.

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

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

Также вайтбордом полностью игнорируются типичные практики формирования этих мыслей. Например, я года два (в общей сложности) использовал PHP, но не знаю в точности его синтаксиса. Да и что там знать, он за всё это время поменялся несколько раз. Когда я пишу, подсознание автоматически мониторит подсказки от IDE и выхлоп компилятора, и в режиме test driven development выдает результирующий код. Проще перезапустить тесты и увидеть косяк, чем разбираться в нем с помощью своего мозга. Таким образом ноутбук с компилятором и IDE становятся частью мышления, самых базовых низкоуровневых рефлексов. Ты не думаешь как дышать и моргать. Ты не думаешь, когда нажимаешь кнопку «перезапустить тесты» или корректируешь подчеркнутое красным. Оно происходит само, совершенно отдельно от твоего сознания.

Что происходит, когда у тебя внезапно исчезает воздух? Случается паника, острая необходимость найти источник воздуха, совершенная неспособность что-либо делать без дальнейшего поступления воздуха. Точно такая же аника случается, если забрать у человека нормальную IDE типа Эклипсы и заставить писать код в vim или notepad.exe. Если вообще забрать ноут и заставить чертить рисунки на доске - то пиши пропало.

По сути, на собеседовании человека лишают основного его средства выражения мыслей (ноутбука), и заставляют писать какой-то немыслимой херней. Что же в этом плане могло пойти не так?
Людям, которые любят вайтборды, возьмете меня рекрутером? Только что придумал несколько забавных испытаний для соискателей:
а) Написание кода под водой, ногами на песке.
б) Написание кода под бутиратом.
в) Написание кода под ЛСД. Десять стандартных доз.
г) Написание кода на эстонском языке, сделав вид что это Java, и что в окружающем мире не выполняется транзитивность.
д) Написание кода кровью на обоях. Представляя себя Есениным. Сложность в том, что Есенин не умел кодить.
е) Методично избивать соискателя каждый раз, когда в голове забрезжит идея. Не давать глазам сфокусироваться.

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

ж) ну и на вайтборде рисовать, как же это можно забыть

★★★★☆
Ответ на: комментарий от stevejobs

Все течет, все меняется. Когда-то телефоном звонилку называли :-)
Вообще я с тобой «согласен», но реальность диктует свои определения. Пойди посмотри вакансии девопсов, удивишься. Ну или можешь спрятаться в скорлупе в своем мирке...

Jetty ★★★★★
()
Ответ на: комментарий от Miguel

Ну ладно, challenge accepted, доберусь до компа, попробую в одной строчке уместить, чтобы пробелы сохраняло)

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от stevejobs

не знаю на чем ты пишешь

да на всем что под руку попадается, в т.ч. на жабе.

waker ★★★★★
()
Ответ на: комментарий от stevejobs

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

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

waker ★★★★★
()
Ответ на: комментарий от waker

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от Jetty

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

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

превращение инженера-разработчика в опса - это регресс

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

ну это ты хватил

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

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

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

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

waker ★★★★★
()
Ответ на: комментарий от stevejobs

Всё равно не соглашусь.

Я вот регулярно встречаю обе стороны: разработчиков приложений и разработчиков платформы для управления приложениями, или даже платформы для разработки приложений (дженкинс-фермы, ci-as-a-service и т.п.).

Но проблема в том, что и те, и те - на самом деле узкоспециализированные разработчики, которые создают свой продукт. А людей, которые собирают вместе первое со вторым, и которые наполняют ci-as-a-service собственно содержанием, всегда не хватает. В лучше случае это разработчик-сеньор с одной из сторон, который это делает в свободное от работы время спустя рукава.

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

alpha ★★★★★
()
Ответ на: комментарий от waker

Чувак, в джаве почти всегда используются одни и те же контейнеры: ArrayList, HashMap, если сильно припечет ConcurrentHashMap, TreeSet какой-нибудь (хотя я не припомню, когда использовал за последние полгода сеты вне Hibernate), и прочие баяны. Какая разница, какие характеристики у Тимсорта, если у тебя всё равно нет никакого выбора, и ты _будешь_ использовать его и только его? Нет никакого выбора, понимаешь. Есть стандарты и ты следуешь этим стандартам, слегка сходя и с прямой линии только в 0.1% случаев. А в случае этой наиредчайшей ситуации можно потратить день на вдумчивое гугление и решение проблемы, не тот случай, когда стоит экономить время.

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Чувак, в джаве почти всегда используются одни и те же контейнеры: ArrayList, HashMap

ну вот как ты определяешь, что из этих двух использовать?

а еще пособеседуй каких-нибудль рубистов. У них глаза на лоб полезут, если ты спросишь, как устроены контейнеры.

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

waker ★★★★★
()
Ответ на: комментарий от waker

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

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

bitfroster ★★
()
Ответ на: комментарий от bitfroster

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

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от waker

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

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

ты же вроде на C++ пишешь. Помойму у вас точно так же есть культура глубинных знаний всяких STL, бустов, qt и прочего. Чот сомневаюсь, что человек, который может выдержать собеседование на C++ синьера имеет время, чтобы нрастолько же глубоко надрочить еще и джаву

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

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

Fixed.

Miguel ★★★★★
()
Ответ на: комментарий от stevejobs

ты же вроде на C++ пишешь.

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

Помойму у вас точно так же есть культура глубинных знаний всяких STL, бустов, qt и прочего.

нет. технологии изучаются по мере необходимости. когда мне надо было писать под Qt3 лет 8 назад — я изучил его на нужном уровне. сейчас конечно уже давно все забыл. зачем засорять голову всем этим ненужным мусором? в конторе, где я работаю, не используют STL/boost/Qt. я вообще никогда не сталкивался с boost. кстати, если бы мне предложили работу с применением boost - я бы отказался. я вообще C++ не люблю, и стараюсь избегать.

Чот сомневаюсь, что человек, который может выдержать собеседование на C++ синьера имеет время, чтобы нрастолько же глубоко надрочить еще и джаву

у меня на последнем собеседовании, за вычетом предметной области, спрашивали C, C++, C#, perl, алгоритмы и линейную алгебру.

на предпоследнем спрашивали C, C++, C#, x86 asm, алгоритмы, линейную алгебру. когда оказалось что я не знаю C#, получилось что собеседование я завалил, но мне сразу предложили другую позицию, которая для меня даже была намного интереснее :)

в среднем, думаю, я изучаю 1 новый язык в год.

постоянно использую C, ObjC, C#, javascript, java, perl, bash, несколько разных DSL / скриптовых языков.

не вижу никакой проблемы с этим.

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

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)

Проходил 9 собеседований, чтобы попасть в Амазон. 6 из них были в офисе в Сиэтле, на вайтборде, естественно. Программист в первую очередь должен уметь думать и выражать свои мысли. А если разработчик писать код может только в IDE, то у меня для него плохие новости.

slmgc
()
Ответ на: комментарий от stevejobs

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

WerNA ★★★★★
()
Последнее исправление: WerNA (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.