Comments 231
Периодически прохожу собеседования для саморазвития. Так вот, самые сложные вопросы обсуждаю с тех-лидом. В этом плане все хорошо.
Но как только дело доходит до лайв-кодинга или правок не совершенного кода в режиме онлайн - полный провал. На последнем собеседовании не смог хитро массив отсортировать, просто сидел, смотрел в монитор. В итоге отказался от продолжения мучений.
Думаю что стрессовые методы собеседований подходят не всем.
случайно как-то в зуме, когда шаришь экран, попробовал Annotations - там можно рисовать как на доске! и обнаружил что мне жутко как нравится рисовать алгоритмы и структуры вместо лайвкодить - стрелочки, квадратики, как UML - sequence diagrams, structure, use cases - вот это вот всё.
Не знаю как с этим в других программах (я наверно буду там шарить там простую рисовалку и рисовать это всё в ней), но в общем рекомендую попробовать (особенно когда ступор в "рассказать словами\кодом") - показать рисунком.
Надо попробовать, и я уверен что на графике с легкостью всю структуру алгоритма нарисую. А потом можно по этому графику и код написать.
Рисование алгоритмов - этот навык еще из ВУЗа остался, к тому же эти графики и на экзаменах рисовались, в стрессовых ситуациях, так что отличная идея.
Спасибо за подсказку.
Потому что собеседовать тоже надо уметь. И понимать, что любой кандидат испытывает стресс, а его заставляют в такой обстановке решать не понятные задачи.
Интересно, если бы хирургов, собеседовали на операциях, сколько бы пациентов пострадало?
Так что, считаю, на собеседованиях давать кодить это бред. Совсем другое дело, просто поговорить по техническим темам.
Вот все говорит, то кандидаты не справляются. А может наоборот, работодаль не умеет собеседовать и не знает чего он хоачет и кого он ищет?
Поскольку код, написанный на собеседовании, в продакшн не идёт вообще никогда
Один из моих друзей как-то раз устроился в компанию по разработке известного импортозаместительного дистрибутива для одной большой страны. В качестве тестового задания нужно было написать небольшую скрипт-обёртку для сборки пакетов под весьма популярный дистрибутив, что было с лёгкостью исполнено.
Оказалось что единой билд-системы у них нет, и каждый на своём рабочем месте фактически занимается допиливанием своего собственного тестового задания, но уже с целью собирать релизные пакеты.
Надеюсь, это лишь плод больного воображения моего товарища - ну не может же такого быть, правда?..
Этот код был написан прямо на собесе в режиме лайвкодинга, за 15 минут?
Обычно тестовое задание - совсем другое дело. Оно хоть и крупнее чем литкод, зато можно спокойно потупить вечер, потом собраться с мыслями, сделать, отослать с припиской, что управился за 2 часа.
Не в режиме лайвкодинга, но качество там действительно уровня "написал за полчаса".
Меня несколько больше смущает не качество отдельной тулзы в этой истории, а то что у каждого свой "наколеночный ad-hoc" делающий схожие вещи, и организаторов всего этого процесса ничуть не смущают риски такого write-many подхода. Некоторые из рисков (баги скриптов, человеческий фактор, и т.д.) таки "выстреливали" и приносили убытки предприятию.
Потому что собеседовать тоже надо уметь. И понимать, что любой кандидат
испытывает стресс, а его заставляют в такой обстановке решать не
понятные задачи.
Было дело и понимали, и по задаче подсказывали, и впечатление приятное оставалось, а задача мной зафейлена. Как вариант, просто не требовать обязательного решения задачи, а рассматривать по совокупности: опыт, решение задачи, тех. вопросы, софт скилы.
Проблема в том, что люди очень любят врать, или хотя бы переоценивать себя на собеседованиях. И в резюме и на словах у человека все прекрасно, куча технологий и якобы опыта в проектах. Но закодить простую задачку типа разворота массива он внезапно не может.
Один раз взял такого, но чуда не случилось - в реальной работе он точно так же кодить не умел, и на любые задачи сложнее чем "по совету со стековерфлоу переложить данные из коллекции в коллекцию" впадал в ступор.
Так что увы, хотя бы простейший кодинг на собеседовании - необходимый фильтр для отбраковки тех, кто в принципе не может в программирование.
Согласен. Буквально на этой неделе был такой чел. Красиво рассказал про сложные задачи на последней работе, но облажался на простейшем лайвкодинговом паззле (который, что самое смешное, был абсолютно по той же теме, что и рассказанное кандидатом).
А, какой пазл?
А то может быть вы просили написать реализацию для очень быстрого перебора и поиска всех вхождений для матч3
На js, написать функцию глубокого копирования объекта. С доп. условием - внутри есть циклические и иные ссылки между элементами, то есть объект - не дерево. Это единственный лайвкодинг у нас на собесе. Обычно без доп.условия справляются, но последний чел не смог.
А как бы вы восприняли решение изначальной задачи как
const deepClone = x => JSON.parse(JSON.stringify(x))?
Прекрасный способ, кстати. Пока в границы применимости проходит.
Если подглядеть на MDN кстати то такое же решение подходит и для циклических ссылок. ИСЧХ насколько я смотрел бенчмарки он и про скорости не особо хуже ручного обхода, а иногда и быстрее.
На циклических ссылках разваливается. На произвольных (не циклических) работает, но неправильно.
Почему разваливается?
const getCircularReplacer = () => {
const seen = new WeakSet();
return (key, value) => {
if (typeof value === "object" && value !== null) {
if (seen.has(value)) {
return; // можно что-то более умное возвращать
}
seen.add(value);
}
return value;
};
};
const x = {}
const y = {}
x.y = y
y.x = x
JSON.stringify(x, getCircularReplacer()); // "{\"y\":{}}"
Но закодить простую задачку типа разворота массива он внезапно не может
Гм, простите, а что имеется здесь в виду? Не хватает подробностей. Я бы в ответ на такое тупо в цикле перекладывал значения, даже не уточняя ограничения, буквально чтобы посмотреть на вашу (как интервьюера) реакцию.
На собеседованиях я даю ноутбук с открытой IDE, в которой уже есть "скелет" программы. В котором есть заполнение массива и вывод результата в консоль, остается только вставить код в пустую функцию, который делает то что надо.
Ну и по факту да, там просто в цикле надо переложить элементы, меняя первые с последними. Но даже такая тривиальная задачка достаточно эффективно отфильтровывает примерно треть кандидатов на позицию джуна.
Вот все говорит, то кандидаты не справляются. А может наоборот, работодаль не умеет собеседовать и не знает чего он хоачет и кого он ищет?
Бывает и так, и так. Я, как человек, много раз побывавший с обеих сторон стола на собеседовании, могу сказать своё мнение: в целом нет ничего страшного в том, что кандидат испытывает стресс, и может растеряться и что-то там забыть. Собеседующий, если он опытный, это определит, и поддержит, поможет разобраться. Если он не опытный, ну, самое плохое, что с ними может произойти — они не возьмут этого специалиста на работу, а возьмут какого-то другого, а этот специалист в свою очередь пойдёт работать в какую-то другую компанию, где его лучше поймут. Разве это такая уж проблема?
А что касается самого стресса… ну да, бывает. И у меня бывал в начале. Но стараться убегать от стресса, это плохая практика, как по мне. Испытывая стресс в первый раз, во второй раз будет легче, в третий ещё легче, в пятый его вообще не будет. А если его избегать, тогда всю жизнь будешь бояться, обкладываться подушками и закапываться в песок.
"ну, самое плохое, что с ними может произойти — они не возьмут этого специалиста на работу, а возьмут какого-то другого, а этот специалист в свою очередь пойдёт работать в какую-то другую компанию, где его лучше поймут. Разве это такая уж проблема?"
Оплачиваемые люди за счет компании упускают возможность решить проблему. Человек, нуждающийся в работе, пойдет на другое собеседование, будет терять время.
Разве это такая уж проблема?
А в какую сумму проблема? При оплете в 375 рублей в час, проблема на 375 рублей ровно, или около 5$. Просмотр еще одного кандидата к N кандидатам просмотренным. Для самих кандидатов собеседования часто как развлечение, даже не собираясь менять работу многие проходят собеседования.
Давайте посчитаем
Поскольку на собесах обычно сидят сеньоры и обычно вдвоем, а у них зарплата около 300К в месяц на руки, то мы получаем (300 000/180)*2 = ~3300 р/ч на руки или 5000р расходов чистыми, включая накладные. И это мы еще закинули в накладные расходы на сидящего на собеседовании HR, ожидание опоздавшего (как всегда) кандидата, выписывание пропуска, обсуждение результатов собеседования и т.п.
А теперь вспоминаем, что сеньор приносит прибыль (иначе зачем он нужен), это раз, и их на рынке найти трудно, это два. Поэтому я бы оценил одно собеседование для компании в 7-10К руб. В принципе - тоже не очень много, на фоне общих расходов компании, но все же жалко и их
Потому все и предпочитают ложноотрицательные результаты ложноположительним. Да, неприятно, но кто б рассказал, как сделать лучше.
Оплачиваемые люди за счет компании упускают возможность решить проблему
Если компания пускает на самотек процесс найма, когда собеседующие, как коршуны, набрасываются на кандидата, а присутствующий на компании HR боится/ленится дать собеседующим обратную связь - компания/отдел сама себе злобный Буратино и процесс найма затягивается до бесконечности. При том, что время на собеседования прибавляется к рабочему времени собеседующих, поскольку текущих задач никто не снимал.
Человек, нуждающийся в работе, пойдет на другое собеседование, будет терять время
Пусть лучше потеряет еще десяток часов на другие собеседования, чем полгода-год жизни на работу в окружении агрессивных коллег и руководства.
Потенциальный гений вполне может впасть в ступор на собесе, особенно когда на него налетает стая собеседующих. Статья то как раз об этом.
А в спокойной обстановке он вполне может выдавать свой гениальный код.
Я не знаю как решить эту проблему, просто констатирую факт.
Возможно HRу стоит лучше покопать отзывы с предыдущих мест работы, гитхаб и т.п.
Оплачиваемые люди за счет компании упускают возможность решить проблему. Человек, нуждающийся в работе, пойдет на другое собеседование, будет терять время.
Собеседование — это такая штука, в которой стоимость ошибки «не взять подходящего кандидата» и «не устроиться в подходящую компанию» несоизмеримо ниже, чем стоимость ошибки «взять неподходящего кандидата» и «устроиться в неподходящую компанию». Поэтому это действительно не проблема. И оплачиваемые люди тратят своё рабочее время в рамках ожидаемого бюджета, и соискатель в общем случае также ищет работу, заранее ожидая, что он потратит на общение какую-то часть своего времени, а не устроится с первого же звонка.
Вы же, например, когда хотите купить себе какой-нибудь гаджет, не тыкаете пальцем в первый попавшийся на витрине ближайшего магазина, а тратите определённое время на выбор, сравнение характеристик и т.д., хотя оно тоже может быть конвертировано в какой-то денежный эквивалент? Собеседование — это то же самое, для обеих сторон.
> Бывает и так, и так. Я, как человек, много раз побывавший ...
вполне соответствует моему опыту тоже, полезный комментарий, замечу также что с опытом приходит понимание как мало " собеседующих" на самом деле умеют это хорошо делать
Интересно, если бы хирургов, собеседовали на операциях, сколько бы пациентов пострадало?
У хирургов есть сертификация. Получение сертификата это сложный квест, где требуется и подтверждение образования, и опыта, и отзывы с предыдущих мест работы. В сертификатах указываются конкретные действия, которые может совершать его владельц. Сертификат периодически нужно подтверждать, иначе он протухает.
Для айти такой вариант тоже местами используется. Но это все муторно и дорого. Поэтому в общей массе работодатели обходятся собесами и тестовыми задачками.
Может и бред. Не считаю себя стрессоустойчивым, но единственный раз когда был лайв-кодинг прошёл нормально и даже мысли не путались. Но бывало что и обсуждение по результатам проверки тестового задания не очень проходило, ибо такие грубияны попадались что уже и ответить ничего не мог. Хотя, казалось бы, надо лишь пояснить ход мыслей почему именно так сделал.
Если ещё раз попадётся лайв-кодинг, то только порадуюсь лишней возможности оценить адекватность нанимающих.
Тоже не люблю лайв-кодинг, также заваливал их из-за ерунды, через час открывал задачу и сходу писал решение уже без собеседующего. Да и вообще забыть можно хоть что на собеседовании и не дай бог пожаловаться где-то, сразу же набежит толпа топ-сеньоров, которая скажет с надрывом: "Как? Вы забыли про инкапсуляцию? Это же АЗЫ!11 Вам надо дворником быть" И это, несмотря на то, что у человека 20 лет опыта с большим набором технологий. Всё равно самозванец :)
Ну если забыл про инкапсуляцию и не смог доходчиво объяснить, что она в данном случае не особо то и нужна, то может за эти 20 лет опыта кандидат так ничему и не научился?
А вот и топ-сеньёр набежал.
У вас какие-то взаимоисключающие вещи написаны. Если он забыл, то значит научился, но просто забыл. А если ничему не научился, то и забывать ему бы было нечего.
Представьте две гипотетические ситуации:
Кандидат забыл что такое инкапсуляция
Да, это азы и это надо знать. Если кандидат не знает, что это такое, то ему не по пути с ООП.
Кандидат знает что такое инкапсуляция, но во время лайвкодинга "забыл" ее применить. Скажем, сделал все поля класса публичными и не стал создавать конструктор. Ему указали на эту проблему.
Кандидат может возразить, что лайвкодинг - это стрессовая ситуация, предполагающая быстрое решение здесь и сейчас. Поэтому он(а) решил(а) пренебречь инкапсуляцией в пользу скорости выполнения задания. На работе он(а) конечно же бы так не поступал(а). Или это вообще был DTO и там инкапсуляция и инварианты не нужны и интервьюер уже попутал(а).
Вы путаете "забыл" и "не знал", ещё раз пишу, это взаимоисключающие состояния, а вы их приравняли друг к другу.
Да, это азы и это надо знать. Если кандидат не знает, что это такое, то ему не по пути с ООП.
ООП, к слову, это не серебряная пуля, и в большинстве случаев задачи можно эффективно решать и без него.
Тут вообще сложно. Про 20 лет, конечно, это чёт слишком. Возьмём просто человека с несколькими годами опыта. Бывает сложно сформулировать понятия - инкапсуляция или интерфейс. Но ты их значешь. Допустим инкапсуляция это сокрытие данных или что то ещё? У меня такие заминки с хэшмапой, когда объясняю что это массив из связанного списка. Потом спрашивают как (каким образом) в этот массив залетают данные, как вычисляются индексы и тут начинается реально ерунда, так как я не могу это нормально объяснить. Ты знаешь какие то узкие веши когда расширяется мапа, или методы итератора в коллекциях, или вон тот метод в том классе в той теме, но тебя об этом не спросят если завалил "простые вещи". Так что как то тоже не люблю деление на простые и сложные вопросы. Как то мне лучше знать, для меня простой вопрос может быть сложным, а сложный - простым. Тут не всё однозначно.
Нет. Если человек не может дать определение, он не до конца (или вовсе) не понимает, что он делает. И пример с хешмапой это только подтверждает.
Ясно понятно. Тогда назовите нативную функцию, которая вычисляет хэшкод, как она считается? Каким образом выбираются индексы из массива хэшмапы? И не надо про простейшие вещи, типа сколько по умолчанию ёмкость хэшмапы - 16. Или про ёмкостный (capacity) фактор - он равен 0.75. Расскажите и вообще легально ли с такими вопросами вгрызаться на уровне простого миддла.
Да. Все используют хэш таблицы чуть ли не каждый день, и надо знать и самому уметь ее написать. Там, массив, остаток от деления и два вида разрешения коллизий, причем можно знать любой один. Это что, невозможное знание?
Это просто лень изучать свои инструменты. Я сам только спустя 5 лет с начала карьеры разобрался с хэшмапой. Потому что лень было. Зато когда разобрался - поразился красоте инженерной мысли.
И теперь нет ощущения магии в этом, понимаешь, что всякие индексы БД на тех же алгоритмах работают и понимаешь как они это делают, что могут, а чего не могут.
А кстати хэш индексы тоже есть, в том же постгресе. В реальной жизни hash и B-Tree применяются совместно, то есть для вычисления значений B-Tree индекса все равно применяются хэши.
B-tree это упрощенное 2-3 дерево, в нем нет хэшей. Так что да, BST и hash maps это две сильно разных структуры.
Это закопано где-то в этих файлах
Вставка в BTree дерево
https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtinsert.c
Всякие вспомогательные функции которые делают реальные операции
https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtutils.c
Собственно стартовый код дерева
https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtree.c
Кстати, мне довольно часто такой вопрос попадался во время последнего рейда по собеседованиям. Я интересовался когда то, как оно все устроено, но с тех пор много времени прошло и поскольку в реальной жизни мне писать собственные хешмапы не приходилось, то и как оно реализуется вспоминается очень туго, в основном на уровне ключевых слов. На кой черт это спрашивают, для меня до сих пор загадка. Ну буду я заучивать это перед каждым собеседованием, это же маразм какой-то. Работу с регистрами процессора используют тоже каждый день, давайте их тоже требовать знать, как оно там под капотом на ассемблере.
Нужно это чтоб понимать как оно работает и, например, не написать случайно перебор содержимого с квадратичной сложностью или там не класть в нее объекты у которых hashCode/equals контракт нарушен. Или же тут ситация сложнее и есть непонимание чем хэштаблица от массива отличается?
во-первых - вы сейчас очень языкоспецифическую штуку затронули. Не во всех языках так же сделано.
во-вторых - в отличие от знания хешмапы, знание что есть "hashCode/equals контракт" - гораааздо полезнее ( например, из классических приколов - про то как вычисляются hashCode/equals для URL )
Это натягивание совы на глобус. Чтобы не написать случайно перебор содержимого с квадритичной слжоностью или там не класть в нее объекты у которых hashCode/equals контракт нарушен нужно знать как не написать случайно перебор содержимого с квадритичной слжоностью или когда там не класть в нее объекты у которых hashCode/equals контракт нарушен. И этого достаточно. Это и спрашивайте на собеседовании. Если вам это нужно на работе. Хешмапу то писать зачем? Логика, чтобы ездить на автомобиле нужно уметь собрать и разобрать его до последнего винтика - это оверинжениринг в чистом виде.
Я не спрашиваю. Но у нормального разработчика не составит труда показать, как он умеет писать код для реализации простой задачи. Если кто-то считает эту задачу очень сложной, то я не знаю, можно в таксисты пойти.
Нет, ваше мнение ошибочно, есть сотни примеров от разработчиков, которые заваливали собеседования на подобных задачах, а вы их все в таксисты записали. И меня в том числе.
Ничего личного. Я полностью уверен что если вы пишите программы, то вы правда сможете написать хэшмапку, особенно если дома, для себя и без стресса. Вы же знаете, то там массив, хэш, остаток от деления и коллизии разрешаются обычно связанным списком. Вот скажите, что, правда не сможете? Если нет, то как на работе код пишете?
Так никто не спорит, что смогу, нужно только предварительно вспомнить всю эту теорию. Я вот сейчас помню да, что там О(1) колизии, остаток от деления и т.п. А собрать воедино не могу. Хотя раньше изучал этот вопрос и лет 5 назад на собеседовании даже писал. Посколько мне это не требуется на работе, то мозг от лишней информации и избавляется. Так он устроен. То есть, чтобы пройти такое собеседование мне надо предварительно вспомнитью всю эту теорию, а еще лучше попробовать попрактиковаться, потому что теория это одно, а практика, да еще на собеседовании совсем другое. И после того как я пройду собеседование снова благополучно забыть, потому что по работе не требуется хешмапы писать, достаточно знания алгоритмической сложности. То есть да, смогу, вопрос, зачем?
Правда в то же время я вижу что некоторые программисты не умеют писать код от слова вообще, но этот феномен я совсем не понимаю.
Приветсвую,
Я пишу под WinApi, COM, парсю сайты, немного графики OpenGl - ни разу не рбаотал с hasmmap, к сожалению даже не знаю, что это такое.
Если меня подобное спросят на собесе - вообще ничего нее смолгу ответить.
Правильно ли будет применить Вашу фразу по поводу таксистов - "Если кто-то считает эту задачу очень сложной, то я не знаю, можно в таксисты пойти. " - и ко мне в том числе ? :(
Ну да, этого достаточно чтоб написать свою хэшмапку, не правда ли?
хммм, а как часто вы пишете свои хешмапки? Когда в последний писали на работе свою хешмапу ?
Ну не на работе, но недавно писал k-nearest neighbor на хэш-таблицах для многомерных векторов, а что? Хотите сказать, что знание что в хэш таблицах используется оператор MOD это слишком сложно и совершенно бесполезно?
А знание как оно внутри у разных коллекций устроено использую каждый день на работе.
вы действительно используете знание "как оно внутри устроено", а не "асимптотическую сложность операции вставки\поиска\удаления" ?
Уважаю!
Знание сложности не всегда достаточно даже для тривиальных оценок. Скажем, какой big-O у "for(key : map.keys()) print(map[key])" и почему?
это всё зависит от мапы, но конечно перебор по коллекции два раза - "это пять" :)
во-вторых, недавно встретил табличку "если 1 операция занимает 1нс, сколько потратится времени при разных сложностях алгоритмов", так там для N=10 то даже алгоритм со сложностью n^n работает 10с, что конечно очень долго, но дождаться можно. Для алгоритмов сложности n^3 можно брать коллекции в 1000 элементов, и жить можно. На практике - это значит, что если у автора сего кода несложный UI - то никто из бизнеса даже не почешется, чтобы улучшать.
Да, все верно. И для хэшмапки самый плохой случай для этого кода будет O(n^2), что будет отличным сюрпризом если там несколько миллионов элементов. Не зная как это устроено будет сложно сказать какого черта все встало ) Так же будет сложнее сказать RB или AVL дерево для вот именно для этого плохого перебора будет лучше.
ну, их можно написать и без оператора mod (например - наложив ограничение на хеш).
просто нечасто по работе такое надо, и обычно за такую интересную задачу борются сразу несколько синьоров (если конечно у вас отделе больше одного синьора)
я уже писал, но повторю :
в отличие от знания хешмапы, знание что есть "hashCode/equals контракт" (и что многие структуры коллекций используют не указатель на объект, а вычисление хеша от содержимого объекта) - гораааздо полезнее ( например, из классических приколов - про то как вычисляются hashCode/equals для URL )
думаю въедливые собеседующие могут не остановится на остатке от деления. Опять же вопрос открытый вы не ответили. Нативная функция вычисления хэш-кода - какая она? Она написана на С и закрыта модификатором native.
Допустим инкапсуляция это сокрытие данных или что то ещё?
инкапсуляция это не совсем сокрытие данных. Тут как раз и заключается тонкий момент - Инкапсуляция (англ. encapsulation, от лат. in capsula) — в информатике размещение в одном компоненте данных и методов, которые с ними работают.
И уже как следствие, инкапсуляция как раз обеспечивает сокрытие, но не наоборот - сокрытие это не есть инкапсуляция.
и далее продолжаю цитировать википедию
В сообществе C++ или Java принято рассматривать инкапсуляцию без сокрытия как неполноценную. Однако, некоторые языки (например, Smalltalk, Python) реализуют инкапсуляцию, но не предусматривают возможности сокрытия в принципе. Другие (Standard ML, OCaml) жёстко разделяют эти понятия как ортогональные и предоставляют их в семантически различном виде (см. сокрытие в языке модулей ML).
https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)
С каких пор хэшмап стал связным списком? Это ассоциативный контейнер. А как его реализует конкретный Фреймворк - дело десятое.
Детали реализации конкретно stl ной мапы - больше похоже на зубрежку, чем на понимание паттерна и как он должен работать в Qt, stl и любом другом фреймворке.
А вы не рассматривали вариант, что не "забыл", а интуитивно не использовал там где не нужно? И даже не задумывался о том, нужно или нет, а сразу готовый паттерн сформировал в голове на основе своего опыта.
Ну тогда этот человек на уточняющий вопрос "а почему нет инкапсуляции" моментально ответит, что "здесь оно не надо". Я про то что "знал, но забыл" - это брехня. Не знал никогда
не брехня. У меня такое было только на 5 раз вспомнил то что уже учил/знал. Первые 2-3 раза когда спросят любой вопрос можно забыть. А на вопрос про "здесь оно не надо" обязательно спросят "почему оно не надо". Так что вы думаете только кандидаты могут мухлевать, а как память работает и далеко не все всё сразу могут вспомнить - забываете.
О! Прям на любимую мозоль...
Забавно, что топ-сеньоры очень часто в мантре "инкапсуляция, полиморфизм, наследование" под инкапсуляцией подразумевают сокрытие (а это даже в учебниках пишут) -- и это слегка немного выбешивает очень сильно.
Инкапсуляция - разве не сокрытие данных? вот я помню, что что-то ещё, но не помню что... На пальцах могу объяснить, что это когда в классе скрывают данные от других классов и вообще закрывают от "сайд эффектов", что бы не было наследования.. Вот примерно так могу объяснить не заглядывая в определение. И кстати прочитанное определение не гарантирует что я его запомню. Если только произнесу раз десять то запомню, а так бывает, что уже вроде знаешь определение - но не можешь сказать так как забыл.
Да откройте же википедию - там все доходчиво объяснено https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)
Инкапсуляция (англ. encapsulation, от лат. in capsula) — в информатике размещение в одном компоненте данных и методов, которые с ними работают. В реализации большинства языков программирования (C++, C#, Java и другие), обеспечивает механизм сокрытия, позволяющий разграничивать доступ к различным компонентам программы.
Инкапсуляция зачастую рассматривается как понятие, присущее исключительно объектно-ориентированному программированию (ООП), но в действительности обширно встречается и в других (см. подтипизация на записях и полиморфизм записей и вариантов). В ООП инкапсуляция тесно связана с принципом абстракции данных (не путать с абстрактными типами данных, реализации которых предоставляют возможность инкапсуляции, но имеют иную природу). Это, в частности, влечёт за собой различия в терминологии в разных источниках. В сообществе C++ или Java принято рассматривать инкапсуляцию без сокрытия как неполноценную. Однако, некоторые языки (например, Smalltalk, Python) реализуют инкапсуляцию, но не предусматривают возможности сокрытия в принципе. Другие (Standard ML, OCaml) жёстко разделяют эти понятия как ортогональные и предоставляют их в семантически различном виде (см. сокрытие в языке модулей ML).
Вот именно. Сокрытие не есть инкапсуляция. Сокрытие это сайдэффект в некоторых языках для разделения интерфейса и реализации.
Но в учебниках пишут другое и описывают инкапсуляцию как сокрытие в чистом виде (public, protected, private).
Но в учебниках пишут другое и описывают инкапсуляцию как сокрытие в чистом виде (public, protected, private)
Да, про это и говорится что в C++, Java, C# и пр. инкапсуляция без сокрытия это мол неполноценная инкапсуляция, но в данном случае сокрытие - это просто деталь реализации, артефакт языков так сказать. В общем инкапсуляция концептуальное понятие, а сокрытие это детали реализации.
В том же Golang - вы внутри модуля делаете структуру, в которую помещаете все нужные поля и реализуете для нее какие-то методы, в том числе методы разных интерфейсов - это есть инкапсуляция. Но внутри того же модуля вы не сможете другим его членам запретить использовать все приватные свойства этой структуры, т. е. в данном случае есть инкапсуляция но нет сокрытия данных
Я за фразу "вам надо дворником" сходу отвечу "слышь дядя, а тебе надо сварщиком в коммуналку, где сосед заземлил электрокамин на батарею а в подвале потекло и тебе срезать надо. и вот стоишь ты такой с фортуной, наступает момент истины и тут ты понимаешь что на трубе слева 370 вольт а справа - 90, и тебя █ботоком смертельно убъёт если ты за неё руками возьмёшься. дворником, ищьчё придумал, баклан. щезни с темы, не беси меня". Как говорится, "не просите меня пояснить за мой ластхит, и я не попрошу вас пояснить за мой пинг". Как там это они называют? а, "не стрессоустойчивый".
Ну как по мне, на такое радоваться надо что я так, словами. ласково. А не бутылкой по голове. Некоторым людям было бы полезно испытать опыт макания их прекрасного светлого личика в непроницаемую темноту главного предмета санузла. С небес спуститься, если в метафорах понятнее.
Показывать в онлайн режиме разработку даже примитивного кода очень сложно. По крайней мере, у меня был один такой опыт. Забывается всё подчистую. Хотя, за несколько минут до этого, спокойно писал код в разы сложнее и на том же языке, но без демонстрации.
В коде, как и в человеческой речи, достаточный объем "вводных и выводных фраз". "К примеру, если рассмотреть ситуацию с с Вашей стороны, что бы решить поставленную Вами задачу... " и т.д. Я еще совсем ничего не сказал, но беседа то идет и Вам кажется что я норм собеседник, заинтересован в Вашей задаче и поддерживаю разговор, а другой вон вообще замолчал т.к. у него еще нет решения (так и у меня еще нет) и сказать ему нечего.
Так и в коде, надо написать область описания переменных, интерфейс, типовой обработчик результата - это все уйдет в прод практически неизменным и это же и хороший стиль.
Само же решение же будет в ядре этого. Однако вот эта деятельность по написанию вводной обертки возможно снизит эмоциональную атаку, веренет в привычное русло да и даже если не поможет решить задачу, просто покажет что код эстетически красивый, что само по себе очень хорошо. Может и не прокатит, но в любом случае это лучше чем ничего.
+++ Лайв кодинг - лютый стресс
Но как только дело доходит до лайв-кодингаТут как раз понятно, как эту проблему решать — набивать руку и много писать кода. Потом будет на автомате получаться, собеседующий если что подскажет (с ним надо всё время поддерживать диалог).
Намного сложнее soft skill interview, где задают вопросы типа «расскажите о ситуации, где вы изменили процессы на работе через инновации или упрощение, и ваша фирма получила кучу профита». И где собеседующий ожидает ответа в формате STAR. Для этого нужно заранее перед интервью вспоминать все свои ситуации и стараться натянуть их на возможные вопросы, но это сложно сделать на новый вопрос, а во время стресса вообще придумать адаптацию ещё сложнее, и у интервьювера может сложиться впечатление, что не такой уж вы были полезный сотрудник для предыдущей компании.
Такой скилл нередко сформирован ранними этапами жизни и взрослому человеку намного сложнее его набить, чем полумеханический кодинг.
«расскажите о ситуации, где вы изменили процессы на работе через инновации или упрощение, и ваша фирма получила кучу профита»
... и другой маркетинг буллшит
Когда мне нравится проект - то пишу код и думаю, сколько пользы он принесет. А когда я пишу код для финансистов каких-нить, то у меня только мысли о пятнице. Он может принесет им прибыль, а может и не принесет - это все забота ПМа.
Я могу конечно на интервью рассказывать истории про то, как мой про супер код (с инновациями, рефакторингом, BDD и бохатым UI) месяц добирался до клиентов - потому что проходил сначала черз ДБА, потом через ДевОпсов продакшена, а потом через РискДепартамент....
А когда я пишу код для финансистов каких-нить, то у меня только мысли о пятницеПро это придётся промолчать, иначе не пройдёте интервью. Нужно им доказать, что вы будете гореть проектом, и такие откровенности этому совсем не помогают.
истории про то, как мой про супер код (с инновациями, рефакторингом, BDD и бохатым UI) месяц добирался до клиентовВот как раз и нужно рассказать, что вы сделали для того, чтобы такого впредь не случалось (и желательно со счастливым концом).
Я думаю сейчас нанять консультанта по карьере, чтобы улучшить свои навыки прохождения вот этого всего.
Есть парижское кабаре, кто называются Crazy Horse. Процесс отбора туда - рост, вес, объем груди. Все должно быть не больше, не меньше установленного стандарта. Тенденция современных собеседований начинает всё больше напоминать этот отбор. Не важно какой у тебя был прошлый опыт и насколько сложные системы ты поддерживал и вытаскивал из глубокого легаси... Вот не можешь онлайн за 20 минут решить публично задачку с Leetcode - значит не программист )
Дело не только в стрессе или магическом умении прохождения собеседования. Есть условно говоря 2 типа программистов: те кто быстро херачат и мало думают и те кто долго думают, медленно делают. Хорошую команду можно собрать из обоих групп, некоторые компании специально выделяют быструю команду которая делает работающий MVP и тестирует разные теории. Вторая медленная команда отрабатывает уже проверенные теории, они делают полноценный анализ моделей, потоков, потребностей, прорабатывают архитектуру, выстраивают процессы разработки и жизненного цикла, и т.д. По сути это реализация подхода: Make it work, Make it right, Make it fast
По опыту первая группа больше любит хакатоны и лайвкодинг в стиле Google. Люди из второй группы более глубоко могут описать проект и принятые решения. Стресс при этом больше влияет не на конкретный этап, а на реакцию в незнакомой ситуации, поэтому чем больше знаешь, тем меньше неожиданностей может быть на интервью ;)
Не важно какой у тебя был прошлый опыт и насколько сложные системы ты
поддерживал и вытаскивал из глубокого легаси... Вот не можешь онлайн за
20 минут решить публично задачку с Leetcode - значит не программист )
В больших компаниях это не от хорошей жизни. Если не вводить трудно подделываемых критериев приёма на работу, то 2/3 сотрудников будут наниматься потому что они с кем-то из сениоров или тимлидов вместе служили / бухали / ходили в один гей-клуб. В фаангах по пять разных ревьюеров не на пустом месте.
В свою бытность работы в одном хорошо известном банке я там видел несколько весьма посредственных разработчиков, кажется они Jir'у поддерживали. Про одного из них я точно знал, что он работал, потому что его забыли уволить в течение испытательного срока, а ещё пара его коллег были не лучше. Они могли по нескольку недель делать вид, что занимаются какой-нибудь фигней, которая делается за полчаса, читая при этом книжку / сидя в интернете. И таких людей много. А с появление массовой удалёнки такая работа и вовсе стала желанной даже для хороших разрабов с изрядной долей цинизма. Бёрешь такую работу второй / третей и тратя пору часов в неделю на кивание в зуме и имеешь + 50% к зарплате.
В общем любите литкод и живые собеседования — это последние рубеж, отделяющий вас от миллионов красиво брешущих джунов, вайтишников и просто нелюбителей неприкасаемых.
А каким образом литкод исключает любителей двух часов на кивание в зуме? По моему он как раз вероятность и повышает.
Да и то, что книжки читают это в плюс.
Так никто не мешает циничному, но хорошему разработчику поднатаскаться на литкод задачах, а потом точно также устроиться на вторую-третью работу, чтобы ничего не делать.
Это даже еще проще будет, если везде собеседования одинаковые и везде требуют литкод задачи, то задача хорошо пройти собеседования упрощается.
"задачку с Leetcode" - принципиально против лайвкодингов, в которых нужно знать ещё и алгоритмы сложнее использования хеш-таблицы. Но при этом готов топить за live-coding как таковой.
По опыту проведения собеседований пришёл к выводу, что задроты с литкода не интересны, и лучше давать вообще "менеджерскую" задачу, чтоб кандидат сам уточнил, что от него хотят. Заодно этот навык нельзя "задрочить" как алгоритмические задачи.
Например: "заказчик хочет, чтоб мы сделали генератор номеров автомобилей. Сделай, а". Звучит просто, и каждый разраб может её сделать. Но то, как эту задачу иногда решают, может порой удивить или расстроить.
Реально гений.
Пожалуйста, не бросайтесь такими фразами. Программист, который вроде как умеет решать вроде бы сложные задачи - не гений. Возможно, он талантливый. И это уже довольно редкое явление. Гениальный программист - это тот, чьи действия настолько продвинут индустрию, что не потребуется объяснений, почему он гений. И уж точно у него не будет проблем с прохождением собеседований.
Про социальную адаптацию ничего не написано. Может, он душа компании и мировой парень, которого все любят, ас командной работы. Ну, не оратор, так что теперь.
Точно. "Бизнесу" нужна предсказуемость посредственностей но результаты гениев. Этот неразрешимый конфликт приводит ко многим, широкоизвестным гримасам современного найма.
Не дай бог, соискатель умнее его. Для него это больно.
Странно слышать, учитывая, что "покупаются" мозги.
А почему ему больно?
Когда я волнуюсь, у меня пальцы не попадают по кнопкам на клавиатуре. От чего начинаю еще больше волноваться. Это как с заиканием. Поэтому ненавижу лайвкодинг. Код на бумажке - это вообще признак процветающего маразма в компании, если мне предложить такое - сразу вежливо попрощаюсь. Мне есть что показать и что рассказать, и если кому-то это не интересно - мне становится взаимно неинтересно. Пока что мои принципы меня ни разу не подводили.
Видно, что в голове куча мыслей и абстрактных концепций. Но выразить словами толком не получается.
А кодом получится? Я сам иногда говорю транслируя код в русский язык, не очень чисто, но понимаемо.
Но проблема даже в другом.
А понятным и легко читаемым сторонним разработчиком кодом? Если у него в голове каша, что у него в коде?
А документацию написать? "Not my obligation"?
И должен ли такой "программист" проходить собеседование, если он не проходит по всем требованиям, кроме одного - знать как писать код?
А документацию написать? "Not my obligation"?
Так написание документации к коду - довольно формальное занятие. А что-то более литературное( и лицом к пользователю ) - извините, тут есть технические писатели.
Если у него в голове каша, что у него в коде?
Так каша то потому, что не можешь выразить словами то, что происходит в голове. Кодом выразить проблем нет.
И должен ли такой "программист" проходить собеседование, если он не
проходит по всем требованиям, кроме одного - знать как писать код?
Так стоп, знать как писать и что писать - это и есть основная цель. К тому же в спокойной обстановке всё заметно лучше, чем при публичном выступлении
Даже тут всегда есть фактор дедлайна.
знать как писать и что писать - это и есть основная цель
А вот тут сильно холиварный вопрос.
И должен ли такой "программист" проходить собеседование, если он не проходит по всем требованиям, кроме одного - знать как писать код?
вы там точно программистов набираете, а не лидов - тимлидов, техлидов ?
знать как писать и что писать - это круг обязанностей специалиста, коммуницировать с людьми и управлять проектом - это немного другой круг обязанностей. Меня конечно радуют попытки переложить его с менеджеров на программистов, но вы там обозначайте тогда вакансию корректно, а не просто "программист".
Тимлидов со стороны берут не от хорошей жизни, только когда внутри команды нет ни одного подходящего кандидата. А откуда они возьмутся, когда для программиста простой разговор с человеком уже стресс.
дело в том, что если у кого-то и лидерские и программистские качества развиты - то я обеими руками ЗА, чтобы таких людей нанимать (а потом растить внутри команды - хоть до ПМов).
Но мне тут рассказывают, что надо всем программистам быть еще немножечко и тимлидами, а если у человека таких склонностей нет - то таких на собесах брать нельзя, ибо общение! и софт-скиллы!
А что-то более литературное( и лицом к пользователю ) — извините, тут есть технические писатели.
Не пользовательскую документацию. А документацию для наследника твоего кода.
Так каша то потому, что не можешь выразить словами то, что происходит в голове. Кодом выразить проблем нет.
И нас всех в индустрии за подобных подход про умение писать документацию надо больно бить. Тупому компу, значит, словами объяснить что-то сложное можем. А значительно менее тупому человеку так же словами — уже почему то нет.
А значительно менее тупому человеку так же словами — уже почему то нет.
Человеческие языки значительно более многозначные и неточные. Не просто так существует почти отдельный "юридический" язык, который непривычному человеку понимать достаточно сложно. Я частенько спотыкаюсь о попытку подобрать наиболее точно подходящее для передачи нужного смысла слово. В языках программирования набор встроенных "слов" сильно меньше.
Ещё забавнее выходит, когда нужное слово можешь вспомнить только на каком-нибудь другом языке( например, помнишь его на английском, но нужно-то русское слово, причём достаточно точно передающее смысл, чтобы не пришлось потом ещё минуту тратить на уточнения )
Самое забавное, что описание, скажем, функции - это по сути краткий(сжатый) перевод компьютерного языка в человеческий. А программист - это знаток компьютерного и вроде как сам должен уметь перевести :)
о, про "быть знатоком и уметь перевести", напомнило классика: https://mislitel.info/quote-946879
Тупому компу, значит, словами объяснить что-то сложное можем. А значительно менее тупому человеку так же словами — уже почему то нет.
Тупому компу никто ничего не объясняет - ему просто дают четкие инструкции как и что делать и связи между этими инструкциями.
Во-вторых, если это не просто менее тупой человек,а профильный специалист, то хорошо написанный код гораздо лучше документации, ибо код - не устаревает, а документация "как обычно" - не полна, устарела или недоступна (хорошо, когда все хорошо умеют писать на каком-то одном языке. А если например немецкий я умею только читать?).
Единственная документация, которая пишется человеком и при этом не устаревает при изменениях в коде - это тех. задание. Сами понимаете - в здоровых фирмах его пишут НЕ программисты.
то хорошо написанный код гораздо лучше документации
Только когда какому-нибудь фреймворку обучают, не сразу в его код посылают, а все-таки используют книжки, примеры, объяснения словами и видео итд итп.
Считать, что тот код, который не фреймоворк, а прямо в приложении чем-то легче в изучении — это как то очень оптимистично.
Только когда какому-нибудь фреймворку обучают, не сразу в его код посылают, а все-таки используют книжки, примеры, объяснения словами и видео итд итп.
что-что? вы когда пишете про "книжки" - это про книжки без кода?
или "примеры" - это НЕ примеры кода ?
а "объяснения на видео" - там наверно в ютубчике всё на словах да на пальцах обучается, ни строчки кода, да?
Хорошо, когда вам дают задачу "вот фреймворк, вот ТЗ, сделай задачу с нуля"... Подавляющее количество задач - это как раз "есть код, он работает\не работает, там нужно еще фиксить баг\добавить фичу\прочая", поэтому смотришь уже существующий код и стараешься писать свой рядом - как можно понятнее для себя в будущем (или следующего, кто встретит твой код).
(и заметьте, после этого - у вас потенциально устаревшая документация, которую еще надо будет найти и поправить отдельно, если она была создана вручную. Поэтому я и люблю автогенераторы документации)
что-что? вы когда пишете про "книжки" - это про книжки без кода?
Нет, это про книжки, где написано (с примерами, разумеется), как используя существующий код (фреймворка) сделать то, что хочется. И в которых написано, какие вообще готовые кубики тут у нас имеются. Ну вот вроде таких, что тут живут. И бесчисленные статьи разного качества про него же. Хотя почему бы просто не скачать его и не научиться пользоваться ну вот просто по коду всех этих библиотек. Нет, потом ты в него полезешь, но вот сразу с этого кода начинать, никуда больше на заглядывая - это какое-то очень злобное предложение.
Соответственно, в идеале для этого вот нашего мелкого Legacy на н-ное количество сотен тысяч строк кода должна существовать книжка, где написано, как, используя то что тут у нас уже понаписано, сделать то что хочется.
поэтому смотришь уже существующий код и стараешься писать свой рядом - как можно понятнее для себя в будущем (или следующего, кто встретит твой код).
О да, смотришь и видишь, что одно и то же по смыслу действие делается в десяти разных местах шестью разными способоми при помощи четырех разных библиотек. Причем про два из них тебе говорят 'не надо так, это устаревшие варианты, просто их выпилить некогда'. И о том, что они устаревшие - сам, просто глядя на код, никогда не догадаешься.
А почему так? А потому что на очередной итерации предыщего 'идеологически правильного' способа просто не нашли или не осилили (документации-то по использованию нет) им воспользоваться и решили изобрести велосипед и/или сделать заново.
Поэтому я и люблю автогенераторы документации
Снова показывая пальцем в сторону документации Spring-а. Я вот что-то не верю, что такое можно чисто автогенератором сделать.
я про например вот такую документацию
не переживайте - любой "новый и современный код" написанный сейчас через пару лет будет "устаревшим вариантом". Любые книжки выпущенные сейчас с конкретными фреймворками - устареют через 5 лет (или даже раньше).
Во-вторых - всегда можно написать код плохо. С этим я не спорю и не спорил.
вот кстати мне в документациях Оракла для SQL (PL\SQL) их тамошние формы Бекуса-Науэра нравятся поболее иных документаций,написанных маркетологами ...
Я регулярно слышу, что в мире Оракла не все гладко, но чтобы там документацию писали маркетологи, такого я никогда даже представить не мог :)
я регулярно общаюсь текстом, но чтобы так извращали мои реплики, такого я никогда даже представить не мог :)
1) зачем вам документация про внутреннее устройство индексов ? вы хотите в них что-то внутри поменять ?
2) отличие разных уровней транзакции не описывается БНФ.
И вообще - при помощи БНФ не описываются различия (это как "какими красками нарисовать до-мажор?"), но вы можете прочитать их БНФ в той библиотеке, которую используете, чтобы их потом правильно написать у себя в коде.
PS: надеюсь вы ещё помните свое оригинальное утверждение:
освоить фреймворк только по reference это то же самое что выучить язык программирование только по формам Бекуса-Наура.
характеристики сложности - это все же не внутреннее устройство, а нормальное внешнее описание.
То что вы пишете про "правильный код" - это когда уже фреймворк усвоен.
Для его изучения и\или выучивания языка программирования спокойно можно использовать БНФ. Понятно, что потом можно начать смотреть "а что там под капотом" - исходники boost или std для сишников или java.util.concurrent для джавистов и т.д. Но это уже все потом.
для того тимлид предназначен, а не просто за "он тут давно уже работает", чтобы уметь переложить простыми словами техническое знание (для ПМов, ПродактОунеров, воспитателей детского сада и т.д.) и ровно в том объеме, который нужен для решения задач команды.
Если же именно код плохой - то понятно, что нет смысла таких писателей держать.
Через пару лет этот человек станет тимлидом, а затем пойдет дальше по карьерной лестнице?
Или навсегда останется на этой должности, даже не сумев выстроить взаимодействие в команде?
В голове как раз всё кристально и очевидно ясно.
Как только это из понимания сказать словами - вот где закавыка. Непонятно даже - откуда лучше начать рассказывать? С этапов старта и загрузки приложения? Или лучше с первого экрана для пользователя ? Или с базовых интерфейсов иерархии АПИ? Или все-таки с конфигурации по умолчанию? хммм....
PS: И про документацию - если это не комментарии в коде, из которых автогенерируется документация, то да, это "Not my obligation" - этим технические писатели занимаются. Да, я тоже могу это написать, но у меня это будет такого же качества как и сделанные мной же (а не дизайнерами) UI-мокапы - это будет в виде "сделано роботами для роботов".
" И он очень связан с остальной работой"
ээ...а как именно? (ну кроме как "не получишь остальную работу, если не пройдешь собес")
А какой именно навык очень связан с работой? Решение задачек про круглые люки, или, может, написание кода на бумажке? Ну если в вашей компании такое - повседневность, то хорошо, что я работаю не в вашей компании.
Я бы не назвал это "полной неустойчивостью к стрессу". Собеседование - довольно специфичный стресс, где нужно доказывать, что ты не верблюд некоторому количеству людей, которых ты видишь впервые. И с работой такой стресс связан достаточно отдалённо. По работе я вообще новых людей не встречаю - мне норм. А на собеседованиях всё валится из рук и писать начинаю как первокурсник. Особенно если кто-то сидит над душой.
Позже я понял, что тут был где-то такой же случай: если проблемы в личном общении, можно организовать работу, но даже с непосредственным работодателем надо общаться особым образом, может, через выделенного человека.
Прохождение собеседования, да, тут усложняется. Ой не каждая фирма готова работать с таким…
Люди попроще используют телеграм скрипты которые помогают уменьшить рутину общения. Но это уже тут не причем.
Послушайте, HR это ещё та фигня. Там где они есть у них точно такое стремление изображать свою работу как у чиновников - отчётность, бумажки. У них есть негласная норма по отсеиванию кандидатов, если свои внутрикастовые представления о том, каким должен быть кандидат и т.д Я многих и программистов знал, и ещё моя мама в советские времена программистом и я их помню их отдел НИИ, и её описание: там самые неуверенные, с блуждающими глазами люди были первыми во всём отделе. А там где есть HR, даже на склад не возьмут без знакомства, потому что .. отчётность у них. Чем больше кандидатов просеили - тем круче их "работа". Ещё с каким-нибудь психологическим образованием, какой-будь "тренер" -это вообще беда.
А там где есть HR, даже на склад не возьмут без знакомства
Вот это ничего себе. Я, оказывается, безработный.
Не, ну возьмут. Минимум после 10 собеседований. Пару знакомых уходило на шабашки, надоело ходить по собеседованиям и ждать когда "мы вам перезвоним". У этих товарищей HR, даже когда мест нет, есть тактика помещать объявы. И там по сути на место грузчика рассказывают что нужно образование, мотивация, стремление к карьерному росту и подобный развод. На деле им никто в данный момент вообще не нужен. А когда реально нужны работники, узнать можно только по каналам знакомых, тогда уже берут если не всех, то многих. Так что знакомство не в плане "работа по блату", а просто нужна информация в данной сфере.
Гы, я тоже, только по знакомым. Зато я очень важную подробность вспомнил. Как мой школьный товарищ, пусть это уже давно было, до кризиса 14 года, меня как-то огорошил "А я работаю на фирму ***. " С такой радостью, я подумал какое же счастье, погуглил, оказалась какая-то фирма-склад канцелярских товаров. Но с подобными понтами я знаком. В 2004 году я был связан с сисадминством одной фирмы по продажам сотовых, тогда на них был бум, прям как сейчас на джунов. И вечерам тамошним менегерам устраивали нечто вроде партсобраний, о том какая у них великая фирма, карьерная перспектива и пр. бред. И делали это HR, они же тренеры по продажам. Вверхом этого бреда было когда в салоне ввели рэп-музыку, в которой речитативом повторялось название фирмы. Потом этих тренеров попёрли и они перешли в банки, видимо, на склады , а теперь вот их услуги востребованы на отсеве джунов-тимлидеров-мидлов. Нет, ну есть у меня знакомые среди программистов, сверстники под 40 - "ведущие специалисты", но они этот жаргон при мне никогда не употребляли (может возрастное?!), сто пудов опять эти тренеры-мотиваторы, новоявленные парторги нашли новое применение.
Вау, мне очень тяжело проходить интервью целого класса, - "с задачками"
Но я не могу согласиться с текстом статьи
Во-первых, тезис "собеседование это отдельный навык", - мало связан с навыками коммуникации, лидерства и тп.
Да, собеседование это общение, но разработчиков оценивают по неким, пускай эфемерным, но стандартам. Вам не обязательно иметь навыки коммуникации, чтобы пройти большинство интервью. Скорее умение противостоять стрессам и хорошо заученные ответы.
Некоторые разработчики не способны связать слова в устной речи, но при этом остаются высочайшими профессионалами.
Во-вторых, навык коммуникации - ключевой для разработчика, претендующего на звание"высочайшего профессионала", ибо профессиональная разработка, - командная разработка.
За пределами собеседования важно, чтобы человек нашел свое место в компании.
Прежде всего это важно для самого специалиста
Во-вторых, навык коммуникации - ключевой для разработчика, претендующего на звание"высочайшего профессионала", ибо профессиональная разработка, - командная разработка.
вы наверно хотели написать "претендующего на звание "тимлида""? Потому что общение с людьми, которые тебе достались по работе, - это не совсем про программирование, а уже немного управление персоналом
нет, ни куда я не иду и никого не отвлекаю словами через рот. Я спокойно пишу в джиру "недостаточно данных, дайте сценарий\скриншот" и т.д. и отправляю тикет обратно на автора.
После чего автор тикета добавляет когда ему\ей удобно это вот всё.
да, я мысли формулирую и выражаю в каком-то виде, но это все происходит в формальном виде - я не общаюсь с людьми и не управляю их действиями (мотивация, контроль, критика, поощрение и т.д.).
И тем более - не словами через рот.
я не общаюсь с людьми
Обще́ние — сложный многоплановый процесс установления и развития контактов между людьми (межличностное общение) (...), порождаемый потребностями совместной деятельности и включающий в себя как минимум три различных процесса: коммуникацию (обмен информацией), интеракцию (обмен действиями) и социальную перцепцию (восприятие и понимание партнера). Вне общения невозможна человеческая деятельность.
This.
мотивация, контроль, ..., поощрение и т.д
Это менеджерские функции, которые требуют навыков конструктивного общения, но ими не являются. Мимо.
критика
Код-ревью — это критика. Вы можете провести код-ревью?
еще раз - там нет межличностного общения. Есть недостатки описания, я на них указываю.
Код-ревью — это критика. Вы можете провести код-ревью?
это не критика людей. Это описание замеченных мной возможных недостатков предложенного решения.
Я регулярно делаю код-ревью, но я думаю что не все, чей код я комментировал скажут "он умеет делать код-ревью" (если конкретнее, то я знаю как минимум 1 человека, которому не нравится мой код-ревью его кода. Но похоже это взаимно - его код-ревью моего кода не нравится мне :) )
У вас заголовок статьи конфликтует с тремя последними абзцами.
Я тот программист, который никогда не пройдёт собеседование. Но я прекрасно знаю про это своё свойство, поэтому перед собеседованиями я сначала читаю всё подряд, из разряда "что могут спросить", просто чтобы освежить речевые обороты и наименования в голове, а затем устраиваюсь на 3-5 трешовых собеседований в компании, в которых я никогда не буду работать (как правило это галеры), но которые сильно прессуют на собеседованиях, чтобы закалиться и немного расшевелить разговорную речь.
После этого можно смело идти собеседоваться в компанию мечты.
---
Не так давно, на собеседовании на позицию Senior Javascript Developer, ребята меня спрашивали из чего состоит IP-адрес и какие бывают классы сетей. Вот ради таких ребят, я их хожу на трешак всякий.
Классы сетей это же 2 курс университета, причём у нас специальность не связана с сетями (но связана с IT вообщем). Так что не буду вас огорчать, но это обычно теория, которую знает студент теортик, а потом забывает. Для этого вообще не нужно никакого опыта.
Так и я о том же. Конечно же когда-то я знал про классы сетей, не смотря на то, что не учился в университете. Но потом это успешно забылось и вопрос меня застал врасплох.
В подобных этому случаях, даже если я бы прошёл интревью, работать я бы к такому работодателю не пошёл. Если они так проводят интервью, то можно себе представить, что у них творится в компании.
плюсую если бы мог :) мне вот после того как прошёл техническое отказали на менеджерском "недостаточно мотивирован". Ну вообще ппц отмашки. Хорошо ребята программисты поддержали, но отдел кадров с их HR отдельная песня (ладно хотя бы техническое собеседование не пройти, но менеджерское ПОСЛЕ технического - дурдом). Такие компании лучше обходить, даже с учётом того, что я не самый профессиональный программист
Уже не проходят. Шина, кольцо, звезда - все типы сетей времен коаксиала вымерли и остались гибридные сети, которые не классифицируются по типу соединения между устройствами и "хабом"
Есть кто разбирается в тестах EPSO? Что проверяет verbal, numerical и abstract reasoning в стрессовых условиях? Явно не шаблонное поведение же.
Любопытная статейка, но я бы исправил заголовок на что-то среднее между существующим и " некоторые рекрутнры никогда не найдут хорошего программиста". Истина, как всегда, где-то рядом
Спасибо за статью! Попали прямо в душу. Я уже давно понял что стресс тестирование не для меня. Кидаю ссылку на гитхаб и предлагаю ещё сделать тестовое задание, дома в спокойной обстановке. Если не соглашались - значит не моя компания!
Я думал, один такой)
Лайв кодинг не могу, сижу смотрю в монитор, а в голове будто бы какой-то блок.
Иногда доходило до смешного, оценивали как junior+
Да и в целом в общении не слишком, активен что ли. Некоторые собеседующие, ожидающие от меня инициативы, потом оценивали меня как якобы малоопытного.
И это при наличии 15 летнего опыта, наличию собственного успешного проекта, где я применил достаточно нетривиальные решения, вроде самописного быстрого хранилища под файлы (и, как выяснилось, в крупных стартапах а-ля TopFace придумали аналогичное). Про осталые нереализованные идеи, которые я придумал и описал ещё до того, как они появились и стали мейнстримом (Dropbox, GeForce Now), но не реализовал, т.к. не имел финансов, я вообще молчу. Наверное, будь я общительнее, сейчас бы стоял у истоков какого нибудь крупного сервиса...
25 лет в IT. Любой собес - это лотерея и вообще я там регулярно тупняков ловлю. Вот не мое это - "а, давайте код на доске/notepad напишем за 20 минут". Почему за 20? Почему на доске? А какую проблему мы пытаемся решить этим кодом? А эту боль-печаль точно нельзя решить по другому и лучше? И это... а мы точно первопроходцы и нет готовой либы, которая сделает лучше, чем я тут вам за 20 минут навелосипедю?
К таким фейлам отношусь спокойно. Ну ребята в этой команде пол дня решают типовые задачи с литкода в чужом нотепаде, строго в рамках ТЗ и с таймером. А я так не умею. Хех. :( Пойду лучше обычными и привычными делами позанимаюсь.
Я вообще не верю в банальные технические собеседования, а собеседования - моё любимое хобби. Завалил 99%. И меня выбирали без этого треша, и сам выбираю по другим критериям. Ошибка выжившего. :)
Имхо, есть ещё один очень неоднозначный момент: а есть ли смысл так рисковать и нанимать такого программиста?
Приходит на собеседование Миша, код пишет на собеседовании криво, описывает свои действия с трудом, социальные навыки не очень хорошие. Попытки что-то ещё вытащить обламываются.
И приходит Вася, код на собеседовании пишет лучше, описывает то, что делает, и зачем, общаться с ним легко и приятно, вытягивать клещами ничего не надо.
И надо выбирать между ними. Но вот, неловкий момент, Миша часто просит не меньше Васи. И получается, что нанимающему специалисту требуется решить, почему ему надо нанять плохо показавшего себя Мишу, а не Васю. Дефицит кадров пока не настолько сильный, чтобы на соебеседование в адекватную компанию пришёл только Миша. Когда так будет (или там, где это уже происходит), надо будет учиться оценивать Миш (ведь не все из них плохо себя показывают, но хорошо кодят, кто-то ещё и кодит плохо). Когда дефицит закончится, и каждый сможет позволить себе выбирать специалиста, Мише будет ещё тяжелее.
извините за нескромные вопросы, но
какой у вас опыт проведения собеседований? (можно округляя до лет и до десятков кандидатов)
как давно вы собеседовали кого-то в последний раз?
это хорошо! что скажете - быстро вакансии заполняются? Велика ли текучка?
а я давно уже никого не собеседую. Вообще моё ИМХО, после 5 лет найма людей - если хочет человек учиться и не дурак - всему можно научить и переучить и найти в итоге применение в проекте. Любому, хоть экстраверту, хоть социопату, хоть зануде. Для этого иногда потребуются усилия тимлида и ПМа, но это всё возможно, и знания фреймворков уже вторичны. А не хочет учиться (или хочет выучить фреймворк один раз и всё) - то увы.
(Или если менеджмент в позе "мы набираем только синьоров" или "нужно набирать таких чтобы их неучить, а чтобы сразу вджобывали" - то не только найм стагнировать начинает, а и команды начинают "голосовать ногами")
тоже верно. В этом отношении показателен тред вверху про хеш-таблицы и сложность (куда даже 0xd34df00d не утерпел покомментировать, что я считаю признаком успешности флейма ) - там бы пиво, закусон и было бы трендежа на весь вечер - а кто какие структуры видел\писал в практике программирования, для чего и почему.
(про текучку и вакансии вы так и не ответили, но не буду настаивать - это действительно больное место :D )
то что вы пишете - перекливается с https://habr.com/ru/company/itsumma/blog/597561/comments/#comment_23870055 т.е. "уж лучше ложноотрицательный, чем ложноположительный".
я не против такого подхода, в нем ничего удивительного. Вот только в моей практике (ака "ошибка выжившего" :) ), это обычно как раз про тех, у кого коммуникативные умения развитее чем квалификационные - плодят техдолг и баги в архитектуре, а потом поливают грязью (и не только в интернете). Возможно, конечно, в вашей практике наоборот - это делают молчуны с заиками а не говоруны...
Миш, которые не могут развернуть список на собеседовании, 99 не смогут его развернуть никак и никогда.
Это неправда и заблуждение. Попытка считать всех ниже себя, любимого. Этакий самообман. :-) Ну или HR-ы совсем мусорный трафик к вам гонят.
Поясню: пару недель назад на собесе надо было вывести порядок импортов библиотек. Втупил. Не решил вообще. Совсем. Собес завален. Тупой? Тупой. Ну и ладно. Cходил на ежедневный стендап, пообщался с коллегами по текучке. Поревьювил чужое, повыкатывал свое, позакрывал/подвигал таски.
Выдалась минутка - вернулся к задаче. Ба! Да, это же деревья с рекурсией. Гы. 10 минут и код готов. Ответ сходится. Скопировал код в туда, где интервью было. Думаете интервьювер вернулся посмотреть ради любопытства? Неа. Я ж тупой,- откуда там что возьмется. ;-)
И так процентов 80 интервью. С работой вообще проблем нет, если что. Не ищу - сама находит.
Не знаю где там у вас стресс. Сидишь тут такой на удалёнке, света белого не видишь... И тут девы вызванивают, предлагают поговорить. Так что ж не поговорить? Язычок потренировать, да заодно узнать что в индустрии творится. И то хлебушек. Я всегда соглашаюсь.
По поводу "живого кодинга". Хоть я и испытываю одинаковые с прочими комментаторами проблемы (как-то не смог написать "пузырёк", хотя во время обучения писал его неоднократно, а после собеса вечером написал за 5 мин, включая тестирование на нескольких наборах), считаю эту часть важной и нужной. А описанная проблема решается тренировкой, как собственно и остальные проблемы собесов.
Если вы нанимаете джуна/стажёра без опыта, пожалуйста, не мучайте его всякой теорией. Помните, что до этого он целый год (на своих курсах) только и делал что решал задачи. Так и поставьте его в привычные условия - давайте задачи от самой простой (переверни массив или реши квадратное уравнение) и далее к более сложным. Так выявить его уровень.
Если чел тупит, начните разбирать с ним первую задачу:
так, определи массив;
заполни его данными;
как пройти по массиву?
до какого индекса надо идти?
.......
Задача - расслабить мальчега и включить его в работу. Ну а если и это не помогает - тогда уж можно прощаться.
С помидорами сложнее, вертеть массивы ими не надо. Ну, давайте задачи по уровню:
вот тема, как будешь решать?
а если данных 100500/мсек?
а если 100500 пользователей одновременно?
нарисуй иерархию классов;
какую СУБД предложишь и почему?
В идеале потратить время собеса на создание болванки будущей системы. Или взять уже готовую болванку и обсудить что там хорошо/плохо. Реализовать один-два класса из этой болванки. И т.д.
В результате, через некоторое время вы будете нанимать людей более осознанно, а люди будут тренить именно практические навыки, а размахивание руками в воздухе и трёп по общим вопросам.
В наше время источники стресса изменились — дедлайны, ипотека, собеседования. Но физиологическая реакция осталась такой же, как была 60 000 лет назад, в момент появления хомо сапиенса на нашей планете.
"ПОЧЕМУ СТУДЕНТ ПОТЕЕТ НА ЭКЗАМЕНЕ". ОТРЫВОК ИЗ РОМАНА ВЛАДИМИРА САВЧЕНКО «ОТКРЫТИЕ СЕБЯ» (1967 Г.)
Лекция профессора В.А.Андросиашвили по курсу «Физиология человека».
— Темой сегодняшней лекции будет: почему студент потеет на экзамене? Тихо, товарищи! Рекомендую конспектировать — материал по программе… Итак, рассмотрим физиологические аспекты ситуации, которую всем присутствующим приходилось переживать. Идет экзамен. Студент посредством разнообразных сокращений легких, гортани, языка и губ производит колебания воздуха — отвечает по билету. Зрительные анализаторы его контролируют правильность ответа по записям на листке и по кивкам экзаменатора. Наметим рефлекторную цепь: исполнительный аппарат Второй Сигнальной Системы произносит фразу — зрительные органы воспринимают подкрепляющий раздражитель, кивок — сигнал передается в мозг и поддерживает возбуждение нервных клеток в нужном участке коры. Новая фраза — кивок… и так далее. Этому нередко сопутствует вторичная рефлекторная реакция: студент жестикулирует, что делает его ответ особенно убедительным.
Одновременно сами собой безотказно и ненапряженно действуют безусловнорефлекторные цепи. Трапециевидная и широкие мышцы спины поддерживают корпус студента в положении прямосидения — столь же свойственном нам, как нашим предкам положение прямохождения. Грудные и межреберные мышцы обеспечивают ритмичное дыхание. Прочие мышцы напряжены ровно настолько, чтобы противодействовать всемирному тяготению. Мерно сокращается сердце, вегетативные нервы притормозили пищеварительные процессы, чтобы не отвлекать студента… все в порядке.
Но вот через барабанные перепонки и основные мембраны ушей студент воспринимает новый звуковой раздражитель: экзаменатор задал вопрос. Мне никогда не надоедает любоваться всем дальнейшим — и, уверяю вас, в этом любовании нет никакого садизма. Просто приятно видеть, как быстро, четко, учитывая весь миллионнолетний опыт жизни предков, откликается нервная система на малейший сигнал опасности.
Смотрите: новые колебания воздуха вызывают перво-наперво торможение прежней условнорефлекторной деятельности — студент замолкает, часто на полуслове. Тем временем сигналы от слуховых клеток проникают в продолговатый мозг, возбуждают нервные клетки задних буеров четверохолмия, которые командуют безусловным рефлексом настороживания: студент поворачивает голову к зазвучавшему экзаменатору! Одновременно сигналы звукового раздражителя ответвляются в промежуточный мозг, а оттуда — в височные доли коры больших полушарий, где начинается поспешный смысловой анализ данных сотрясений воздуха.
Хочу обратить ваше внимание на высокую целесообразность такого расположения участков анализа звуков в коре мозга — рядом с ушами. Эволюция естественным образом учла, что звук в воздухе распространяется очень медленно: какие-то триста метров в секунду, почти соизмеримо с движением сигналов по нервным волокнам. А ведь звук может быть шорохом подкрадывающегося тигра, шипением змеи или — в наше время — шумом выскочившей из-за угла машины. Нельзя терять даже доли секунды на передачу сигналов в мозгу!
Но в данном случае студент осознал не шорох тигра, а заданный спокойным вежливым голосом вопрос. Цхэ, некоторые, возможно, предпочли бы тигра! Полагаю, вам не надо объяснять, что вопрос на экзамене воспринимается как сигнал опасности. Ведь опасность в широком смысле слова — это препятствие на пути к поставленной цели. В наше благоустроенное время сравнительно редки опасности, которые препятствуют основным целям живого: сохранению жизни и здоровья, продолжению рода, утолению голода и жажды.
Поэтому на первое место выступают опасности второго порядка: сохранение достоинства, уважения к себе, стипендии, возможности учиться и впоследствии заняться интересной работой и прочее… Итак, безусловнорефлекторная реакция на опасность студенту удалась блестяще. Посмотрим, как он отразит ее.
На лекциях по биохимии вас знакомили с замечательным свойством рибонуклеиновой кислоты, которая содержится во всех клетках мозга — перестраивать под воздействием электрических нервных сигналов последовательное расположение своих радикалов: тимина, урацила, цитозина и гуанина. Эти радикалы — буквы нашей памяти: их сочетаниями мы записываем в коре мозга любую информацию…
Стало быть, картина такая: осмысленный в височных участках коры вопрос вызывает возбуждение нервных клеток, которые ведают в мозгу студента отвлеченными знаниями. В коре возникают слабые ответные импульсы в окрестных участках: «Ага, что-то об этом читал!» Вот возбуждение концентрируется в самом обнадеживающем участке коры, захватывает его, и — о ужас! — там с помощью тимина, урацила, цитозина и гуанина в длинных молекулах рибонуклеиновой кислоты записано бог знает что: «Леша, бросай конспекты, нам четвертого не хватает!» Тихо, товарищи, не отвлекайтесь.
И тогда в мозгу начинается тихая паника — или, выражаясь менее образно, тотальная иррадиация возбуждения. Нервные импульсы будоражат участки логического анализа (может быть, удастся сообразить!), клетки зрительной памяти (может быть, видел такое?). Обостряются зрение, слух, обоняние. Студент с необычайной четкостью видит чернильное пятно на краю стола, кипу зачеток, слышит шелест листьев за окном, чьи-то шаги в коридоре и даже приглушенный шепот: «Братцы, Алешка горит…» Но все это не то.
И возбуждение охватывает все новые и новые участки коры — опасность, опасность! — разливается на двигательные центры в передней извилине, проникает в средний мозг, в продолговатый мозг, наконец, в спинной мозг… И здесь я хочу отвлечься от драматической ситуации, чтобы воспеть этот мягкий серо-белый вырост длиной в полметра, пронизывающий наши позвонки до самой поясницы, — спинной мозг.
Спинной мозг… О, мы глубоко заблуждаемся, когда считаем, что он является лишь промежуточной инстанцией между головным мозгом и нервами тела, что он находится в подчинении головного мозга и сам способен управлять лишь несложными рефлексами естественных отправлений! Это еще как сказать: кто кому подчиняется, кто кем управляет! Спинной мозг является более почтенным, древним образованием, чем головной.
Он выручал человека еще в те времена, когда у него не было достаточно развитой головы, когда он, собственно, не был еще человеком. Наш спинной мозг хранит память о палеозое, когда наши отдаленные предки — ящеры — бродили, ползали и летали среди гигантских папоротников; о кайнозое, времени возникновения первых обезьян. В нем отобраны и сохранены проверенные миллионами лет борьбы за существование нервные связи и рефлексы. Спинной мозг, если хотите, наш внутренний очаг разумного консерватизма.
Что говорить, в наше время этот старик, который умеет реагировать на сложные раздражения современной действительности лишь с двух позиций: сохранения жизни и продолжения рода, — не может выручать нас повсеместно, как в мезозойскую эру. Но он еще влияет — на многое влияет! Берусь, например, показать, что часто именно он определяет наши литературные и кинематографические вкусы. Что? Нет, спинной мозг не знает письменности и не располагает специальными рефлексами для просмотра фильмов. Но скажите мне: почему мы часто отдаем предпочтение детективным картинам и романам, как бы скверно они ни были поставлены или написаны?
Почему весьма многие уважают любовные истории: от анекдотов и сплетен до «Декамерона», читаемого выборочно? Интересно? А почему интересно? Да потому что накрепко записанные в спинном мозгу инстинкты самосохранения и продолжения рода заставляют нас накапливать знания — отчего помереть можно? — чтобы при случае спастись. Как и почему получается счастливая, завершающаяся в наследниках любовь? Как и отчего она разрушается? — чтобы самому не оплошать.
И неважно, что такого опасного случая в вашей благоустроенной жизни никогда не будет; и неважно, что любовь состоялась и наследников хоть отбавляй! — спинной мозг знай гнет свою линию… Я не пытаюсь, подобно литературным критикам, зашельмоватъ такие устремления читателей и зрителей, как низменные. Нет, почему же? Это здоровые устремления, естественные устремления, полнокровные устремления. Если коровы когда-нибудь в процессе своей естественной эволюции научатся читать, они тоже начнут именно с детективов и любовных историй.
Но вернемся к студенту, головной мозг которого спасовал перед вопросом экзаменатора. «Эх, молодо-зелено», - как бы говорит спинной мозг своему коллеге, восприняв панический сигнал возбуждения, и начинает действовать. Прежде всего, он направляет сигналы по мотоневронам всего тела: мышцы напрягаются в состоянии готовности. Первичные источники мышечной энергии: аденозинтрифосфорная кислота и креатинфосфат разлагаются в волокнах соответственно на аденозиндифосфорную кислоту и креатин с отщеплением фосфорной кислоты и выделением первых порций тепла…
И снова хочу обратить ваше внимание на биологическую целесообразность повышения мышечного тонуса. Ведь опасность в древнем смысле требовала быстрых, энергичных движений: отпрыгнуть, ударить, пригнуться, влезть на дерево. А поскольку пока неясно, в какую сторону надо отпрыгнуть или нанести удар, то в готовность приводятся все мышцы.
Одновременно с мышцами возбуждается вегетативная нервная система, начинает командовать всей кухней обмена веществ в организме. Ее сигналы достигают надпочечника, он выбрасывает в кровь адреналин, который возбуждает все и вся. Печень и селезенка, подобно губкам, выжимают в сосуды несколько литров запасной крови. Расширяются сосуды мышц, легких, мозга. Чаще стучит сердце, перекачивая во все органы тела кровь и вместе с ней — кислород и глюкозу… Спинной мозг и вегетативные нервы готовят организм студента к тяжелой, свирепой, длительной борьбе не на жизнь, а на смерть!
Но экзаменатора нельзя оглушить дубиной или хоть мраморной чернильницей. Убежать от него тоже нельзя. Не удовлетворит экзаменатора, даже если преисполненный мышечной энергией студент вместо ответа выжмет на краю стола стойку на кистях… Поэтому вся скрытая бурная деятельность организма студента завершается бесполезным сгоранием глюкозы в мышцах и выделением тепла.
Терморецепторы различных участков тела посылают в спинной и головной мозг тревожные сигналы о перегреве — и мозг отвечает на них единственно возможной командой: расширить сосуды кожи! Теплоноситель — кровь устремляется к кожным покровам (побочно это вызывает у студента рефлекс покраснения ланит), начинает прогревать воздух между телом и одеждой. Открываются потовые железы, чтобы хоть испарением влаги помочь студенту. Рефлекторная цепь, возбужденная вопросом экзаменатора, наконец, замкнулась!
Я полагаю, что выводы из рассказанного как относительно роли знаний в правильной регуляции человеческого организма в нашей сложной современной среде, так и о роли их в регуляции студенческого организма на предстоящей сессии вы сделаете сами…
Человеку свойственно меняться. Он может быть "интровертом" или "ассоциальным человеком", но это не приговор, а черта характера, которая образовалась в следствии долгих определённых поощряющих подобную реакцию событий. Если человек всю жизнь ложиться спать поздно и встаёт поздно, то его мозг перестроится, а человек станет совой, и это даже не обсуждается. Другой вопрос: можно ли сову сделать жаворонком? Такой же ответ: если условия будут на стороне подобных изменений. Да, возможно, это приведёт к выгоранием, ведь человек будет вне зоны комфорта. Однако человек приспосабливается ко всему, и рано или поздно зона комфорта перекочует в сторону становления жаворонка, опять же, чтобы человек не убил себя своим дискомфортом, который ведёт к черезвычайному стрессу, а значит большому кол во проблем с физиологией и психикой человека. Так что человек, который "не рождён для собеседований" после нескольких попыток их сдать и моральной перестройки себя в экстроверта обязательно привыкнет
Все-такиобеседование это отдельный навык. В начале года искал работу. Первые собеседования давались тяжело, волновался, долго вспоминал, чтобы ответить. Потом стало проще - вопросы ожидаемые, волноваться стал меньше. Мне кажется, тем кто закончил недавно ВУЗ легче, еще не забылся навык сдачи экзаменов.Сам никогда не отличался красноречием и стрессоустойчивостью, но ко всему можно приспособиться. От волнения мозги отказывают, но не до нуля же, не надо преувеличивать. Работу в итоге нашел, еще и выбирал куда пойти.
Это всё конечно круто, интересно и очевидно, но есть же много других направлений в IT, разработка это далеко не конец (я бы назвал это началом всех начал и скорее всего сейчас многие со мной не согласятся и это их право, но задавали ли Вы когда-нибудь себе простой вопрос «почему так просто?» через месяц обучения и когда у Вас в арсенале уже огромные возможности, я давно уже понял, что это всё не так уж и трудно, если Вам действительно интересно и Вам есть чем заняться, а Вы не припёрлись сюда только ради бабла без идей и плана или вообще с небольшим отвращением или страхом от обычных букв, тут нет ничего страшного, что могло бы на пару недель поставить в тупик, практически всему есть логическое объяснение), если не получается пройти собеседование — передохните, если время позволяет, попробуйте отойти от разработки и заняться другими делами, которые не требуют собеседования, но которые требуют вовлечённости и осторожности, попробуйте заняться делами, которые требуют от Вас тысячи прочитанных статей и много знаний, либо попробуйте провести самому себе несколько трудных собеседований, есть также метод утёнка, его лучше не стоит обходить стороной, не стоит всем портить настроение на собеседовании и идти туда только для того, чтобы стать «скилловее», лучше займитесь собой и готовьтесь, у Вас для этого есть мысли в голове, которые появляются там постоянно, научитесь собирать их, использовать как закрытое собеседование и всё то, что я уже описал. Работайте над собой, повышайте свою самооценку, старайтесь как можно чаще общаться с людьми разного возраста, попытайтесь общаться на неизвестном языке, будьте просто в обществе, но при этом меняйтесь.
Да уж, если у человека жена беременная дома, с маленьким ребёнком, ипотека, ему по зарез нужна работа, конечно у него будет стресс на собеседовании. С личными особенностями конечно можно работать, но этот путь преодоления себя, не для всех и не нужен всем. Работа должна приносить радость творчества и удовлетворение от решённых сложных задач, а не хронический стресс.
Некоторые разработчики никогда не пройдут собеседование