Здравствуйте, mogadanez, Вы писали:
M>Здравствуйте, Baiker, Вы писали:
B>>Если HR не стоеросовый долбоклюй, вопрос должен быть конкретным: "Расскажите о своих прошлых проектах и их самых интересных/трудных местах", а не "расскажи о себе".
M>если человек до таких формулировок будет докапываться на этапе собеседования — то и в работе он будет тот еще душнила — отказано
Будешь "отказывать", когда усы вырастут А пока что первый признак тупого задрота — это вот как раз этот паршивый слэнг из "кринж", "душнила" и т.п.
Если угодно, то компьютер — это и есть самый точный инструмент, в нём нет места тупарям, которые "эй, гыгы, сделай мне вот так!". Только ТОЧНЫЕ формулировки дадут правильный результат. Если ты этого не понимаешь — вон из профессии.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Baiker, Вы писали:
B>>Я ж грю: ты много спрашиваешь сантехника про резьбу? Ты просто вызвал, показал проблему — он её решил. На крайняк обсудил цвет краников. А развлекать задротов викториной — извини, ищи клоунов в зеркале.
N>А он тебе подключил унитаз к горячей воде, а раковину к канализации. N>А вот на вопрос о размере резьбы ответит. N>А ещё все стыки потекут через полгода, потому что изолировать он их не умеет.
N>И вот для следующего ты как минимум захочешь рекомендации. А то и будешь проверять, чем и как он собирается заматывать стыки.
Это маловероятная вещь, как правило специалист с опытом 10+ лет УЖЕ считай "высший класс".
Но суть моего замечания не к тому, как докопаться к нанимаемому, а как ПРАВИЛЬНО, без пошлых игр в синтаксис и подкапотные тонкости, определить, стоит ли брать такого работника.
Собственно, тем и отличается ИНЖЕНЕР от кодера — инженер смотрит на задачу глобально, большими блоками, с перспективой развития. Ну а кодер — тот да, будет долго прищуриваться, знаешь ли ты сколько микросекунд работает StringBuilder супротив "" + "".
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Baiker, Вы писали: B>>Алгоритмы — согласен, с "крепкая" — настаиваю на крепости.
IT>Тогда нужно давать определение "крепости"
Легко. Сложная задача — это любая "глобальная" задача, бизнес-продукт, где вообще нет разницы, на чём ты её пишешь (Склад, Банк, бухгалтерия, автоматизация продажи билетов и т.п.). Если это позиция сеньора, он должен нарисовать, как он в целом видит решение, затем спуститься чуть ниже и позадавать (или послушать!) каверзные вопросы. А что если интернет отключен? А что если сервер упал? Как сделать ID независимым? Как управлять складом на другом континенте? Как и где нужно защитить данные?
Рассуждения над такими задачами и показывает, куда человек готов расти (или уже вырос). А умеет ли он "изменить один символ, чтобы программа заработала" — это вот туда, к джунам.
Здравствуйте, Baiker, Вы писали:
IT>>Тогда нужно давать определение "крепости"
B>Рассуждения над такими задачами и показывает, куда человек готов расти (или уже вырос). А умеет ли он "изменить один символ, чтобы программа заработала" — это вот туда, к джунам.
У меня таких синьёров, умеющих рассуждать, каждый месяц на интервью — пучок. Даёшь ему простейшую задачу где нужно именно "изменить один символ, чтобы программа заработала" и надо же какой конфуз
Я ещё раз настаиваю — программист должен уметь программировать, а не рассказывать о том как он умеет программировать. Следовательно на интервью программист должен программировать, а не рассказывать об этом.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Да и нанимать "чела на синхронизацию" — это тоже не понятно о чём. У вас что, есть позиция, где нужно по 8 часов в день 5 дней в неделю не покладая рук всё подряд синхронизировать?
Это ты не уловил фишку. Человек должен выбираться как породистый щенок — "на перспективу". Если чел рассуждает как настоящий инженер, мне похрен, делал он обмен данными или нет — я знаю, что он РЕШИТ эту задачу.
Собственно, специалист до седых мудей ПОСТОЯННО сталкивается с новыми задачами — ничего страшного в этом нет, главное — чтобы он думал инженерно, думал о перспективе. Многие неизвестные мне задачи решались буквально одним часом гугло/чтения.
Здравствуйте, IT, Вы писали:
IT>Я ещё раз настаиваю — программист должен уметь программировать, а не рассказывать о том как он умеет программировать.
Я понимаю, что ты имеешь ввиду, но ... ты как раз спускаешься к примитивам, которые осваиваются буквально за час. Ну неужели чел с 5 годами стажа не напишет тебе программу?! Тут важно совсем другое: умение смотреть НАД задачей! Этому (теоретически) и должны были учить нас в школе: не заучивать, а находить методы и решения, получать информацию. Ты СЕЙЧАС хочешь решить задачу — написать какой-нть сервер для отчётов. Ну он и напишет тебе! Однопоточный, с дедлоками, с распухшей базой и нелокализуемый кусок г-на. Он же так уже делал! А если бы ты заранее спросил, как-чё он собирается делать, ты бы сразу увидел — чел плавает по деталям, не видя общего.
Ладно, это всё рассуждения в воздухе. Кратко, моя позиция проста: если 5-10 лет опыта есть — чела УЖЕ можно не доё___ывать своими языковыми/библиотечными шарадами. А вот порассуждать об инженерных решениях — надо непременно.
Здравствуйте, Baiker, Вы писали:
IT>>Да и нанимать "чела на синхронизацию" — это тоже не понятно о чём. У вас что, есть позиция, где нужно по 8 часов в день 5 дней в неделю не покладая рук всё подряд синхронизировать?
B>Это ты не уловил фишку. Человек должен выбираться как породистый щенок — "на перспективу". Если чел рассуждает как настоящий инженер, мне похрен, делал он обмен данными или нет — я знаю, что он РЕШИТ эту задачу. B>Собственно, специалист до седых мудей ПОСТОЯННО сталкивается с новыми задачами — ничего страшного в этом нет, главное — чтобы он думал инженерно, думал о перспективе. Многие неизвестные мне задачи решались буквально одним часом гугло/чтения.
Это всё очевидно. Спасибо, кэп. Ты после того как тебе всё это расскажут всё-таки дай человеку возможность покодить. Узнаешь о нём много нового.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Это всё очевидно. Спасибо, кэп. Ты после того как тебе всё это расскажут всё-таки дай человеку возможность покодить. Узнаешь о нём много нового.
А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.
B> в нём нет места тупарям, которые "эй, гыгы, сделай мне вот так!". Только ТОЧНЫЕ формулировки дадут правильный результат. Если ты этого не понимаешь — вон из профессии.
Здравствуйте, Baiker, Вы писали:
B>А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.
Сразу фсат. У тебя денег хватит оплатить моё время?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Baiker, Вы писали:
B> Я понимаю, что ты имеешь ввиду, но ... ты как раз спускаешься к примитивам, которые осваиваются буквально за час ... Кратко, моя позиция проста: если 5-10 лет опыта есть — чела УЖЕ можно не доё___ывать своими языковыми/библиотечными шарадами. А вот порассуждать об инженерных решениях — надо непременно.
Обсуждать можно, но нужно иметь ввиду, что тырыньдеть — не мешки таскать. Доводилось видеть самых разных рассуждальщиков, которые "осваивают буквально за час" любые темы и могут болтать о них не переставая. А вот простейший код написать без всяких инженерных решений — проблема.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Baiker, Вы писали:
N>>А он тебе подключил унитаз к горячей воде, а раковину к канализации. N>>А вот на вопрос о размере резьбы ответит. N>>А ещё все стыки потекут через полгода, потому что изолировать он их не умеет.
N>>И вот для следующего ты как минимум захочешь рекомендации. А то и будешь проверять, чем и как он собирается заматывать стыки.
B>Это маловероятная вещь, как правило специалист с опытом 10+ лет УЖЕ считай "высший класс".
Только не в IT. Здесь нормально, что у двух таких 10-летних один за это время научился всему от запускать S/360 без диска и до веб-сайта на jQuery, а второй ничего кроме, например, Spring Boot не умеет.
Один мой коллега с 1999-го сидит на своей теме и никуда не дёргается — ему и так хорошо.
B>Но суть моего замечания не к тому, как докопаться к нанимаемому, а как ПРАВИЛЬНО, без пошлых игр в синтаксис и подкапотные тонкости, определить, стоит ли брать такого работника.
А для этого надо определить, что он в принципе умеет (а не что в резюмэээ написано).
B>Собственно, тем и отличается ИНЖЕНЕР от кодера — инженер смотрит на задачу глобально, большими блоками, с перспективой развития. Ну а кодер — тот да, будет долго прищуриваться, знаешь ли ты сколько микросекунд работает StringBuilder супротив "" + "".
А без разнообразного опыта инженерный кругозор не включится.
Образование частично помогает, но только для старта.
Здравствуйте, Baiker, Вы писали: B>Будешь "отказывать", когда усы вырастут ]
мои усы давно седые
и с сединой пришло больше понимания "противоположной" стороны ( работодателей )
и что кандидаты часто с реальными закидонами ( а также то что я и сам был таким )
и что софт скилы/отсутствие токсичности не менее важно чем основные скилы
B>А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.
Из моей практики, не стоит даже начинать делать задачку.
Пока ее делаешь, прилетают 2-3 более интересных оффера, потому лучши придти домой и отдохнуть.
B>Я ж грю: ты много спрашиваешь сантехника про резьбу? Ты просто вызвал, показал проблему — он её решил.
Или не решил. И затопил весь дом говном.
Лучше заранее выяснить, что чел реально умеет.
Все конечно трудно узнать, но хоть что-то.
Если про резьбу не знает, ну его нафиг.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, Baiker, Вы писали:
B>Здравствуйте, vaa, Вы писали:
vaa>>экзамены же есть у MS, Oracle и т.д. vaa>>тоже самое что и везде. Сдаешь — получаешь серт. vaa>>Они вроде котируются.
B>Уже написал в первом же сообщении — не читал?
ну вот ты хороший? тогда сдай экзамен по шарпу базовый желательно без подготовки.
А вообше правильный это который не кодит. Пример — БГ.
Я о том, что стоит использовать первую же возможность рассказать о себе как о решателе проблем, с которыми не справляются другие. Если это так, конечно.
Если твой выбор в этой ситуации — "сразу забирать шляпу и идти домой" — ну ОК. Понимаешь, что даже девушку впечатлить своим рассказом не сможешь. (Хотя для большинства это гораздо легче, чем впечатлить профи.)
B>Контакты — ну такое себе... КТО и как может понять твой "гениальный код", если его даже в глаза не видел?? (это я про твоих "близких к топ-менеджменту") Как раз программист может оценить чужой код, насколько тот "хорош".
Гениальность — в скорости работы и качестве (беспроблемности эксплуатации) решений и в быстроте их разработки. Если ты действительно был на голову выше остальных в этом, но начальство тебя не замечало — ну, значит оно было реально далеко от этих задач. Не повезло. Слишком крупная компания, возможно, была, или слишком далекого от "чистого IT" профиля.
B>П.3 вообще какая-то идея из мира розовых пони. Вот когда программистов было 10 человек на всю планету, тогда да — их искали. Сейчас их МИЛЛИОНЫ, никто тебя при таком "предложении" искать не будет. Кроме мафии и налоговой.
Если мы всё ещё о профи высшего класса — их явно не миллионы. Если выделиться из этой миллионной массы — трудная задача для профи, то вряд ли можно говорить о его высшем классе. Можно быть лучше 80% или даже 90% программистов, но это еще не высший класс. Ну, может быть, первый. Успехов!
А пока что первый признак тупого задрота — это вот как раз этот паршивый слэнг из "кринж", "душнила" и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
