Комментарии 201
Даже экзамены на получение сертификата по Java склонны делать упор на вопросы о синтаксисе и компиляции вместо вопросов о том, насколько хорошо вы умеете программировать и проектировать системы.
Собственно, сертификат по Java по своему подразумеваемому смыслу и не должен зависеть от того, насколько хорошо его обладатель умеет проектировать системы. Другой вопрос, зачем он вообще нужен.
Так с ходу основную востребованность сертификата по языку программирования я усматриваю при замещении позиции, на которой придётся много разбираться с говнокодом предыдущих разработчиков. К проектированию систем это имеет отдалённое отношение.
На собеседовании нельзя вобще рро хороший ты программист или нет. Слбесндование проводят люди, далёкие от подбора кадров. Они не знают как этоделать правильно. Вы можете проверить знание терминологии. Человек с хорошей абстактной памятью легко его пройдёт. Задачку можно не ррешить так же. Человек с улицы вряд ли её решит. Для этого надо быть в курсе. Всё остальное можно проверить только работе над конкретнрй задачей. Способноти вобще не проявляются даже в работе. Только на тудных сложных задочах, которые тебе могут и не дать. Тебя могут считать плохим спецом хотя это не так просто так кто-то так решил изначально а так никто даже не проверял. Нового человека надо или обучать или вводить в курс дела. В зависимости от уровня. Да так было всегда во все времена. Но они почему-то решили что нет. Соьеседования для программиста вибще не голятся как и редюме
Возьмите уже за правило: видите, что собес на самом деле викторина - сворачивайте разговор. Если интервьюеры пошли по пути "и так сойдет", то у них как правило всё идет по пути "и так сойдет". Всем моим интересным проектам предшествовало интересное интервью. Всем всратым проектам, где просто тонешь в рефакторинге, предшествовала викторина.
Не викторина, так еще какая-нибудь идиотская чушь будет. Мне кажется, сейчас ИТ в топе по токсичности собеседований.
я бы сказал скорее по оторванности от жизни (в смысле реальной работы). Но токсичность тоже бывает по опыту, да.
Про оторванность подтверждаю.
Очень слабые или отсутствующие базовые знания о специальности. Очень слабое представление какие бывают разработчики, какие инженеры,какие бывают специалисты в поддержке, чем отличается product owner от product sales manager. Буквально зачитывают требования изложенные в вакансии и смотрят как ответят, это если дело доходит до собеседования.
Где-то местами получше с филд-инженерами.
Не преувеличивайте) Я как-то участвовал в собесе, где был со стороны интервьюеров. Скайп собес. Разработчик оказался где-то в Индии. На заднем фоне ужасный шум, мопеды, рикши носятся, слон прошел даже)) И вот на этом фоне он нам пытался ответить на вопросы, путаясь в словах, определениях и т.п.
Про задачки мы даже не стали заикаться, не в такой обстановке. Интернет ловил задержки, пару раз отваливался. По его словам там частенько такое со связью у них, но на работе не сказывается. Ага, я так и подумал. Но когда речь зашла о пожеланиях, я немного ошалел от хотелок этого разработчика.
Так вот, его уровень был примерно мидл минус, а зп и прочих условий хотел как у сеньора. Как мне потом рассказали, таких очень много встречается. Я не про антураж. А про несоответствие навыков, опыта и желаний. Поэтому и методы и вопросы в собесах порой удивляют или раздражают. Иногда, конечно, бывает глупость и некомпетентность подборщиков, но часто там конкретная стратегия.
Видел тут как-то на хабре ироничный пост с большим кол-вом плюсов про собес в яндексе. Типа "детские" вопросы по алгоритмам и всем подряд (сеньорам разрабам, менеджерам и т.д.). Но догадаться, что большой компании куда важнее получить умных людей, умеющих логически и алгоритмично думать, чем знающих миллион фреймворков и библиотек, но криво-пишуших сеньоров - со стороны трудновато.
Для большой компании куда проще выстроить такую систему, при которой они гарантированно получат нужные им кадры, пропустив через свой "конвейр отбора" и последующего дообучения, чем надеяться на случай, а вдруг сотрудник и вправду хорош. Это надо понимать, чтобы не раздражаться, а потом еще и не разочаровываться. Большая компания - это корпоративная культура, отлаженные бизнес-процессы, стабильность и все такое. Но это фактически завод. А за "ламповой" и чуть ли не семейной атмосферой, за "умными" и интересными вопросами - это вам другие места.
>> "Так вот, его уровень был примерно мидл минус, а зп и прочих условий хотел как у сеньора".
А вы случаем не из тех интервьюеров, которые называют джун / мидл зарплату - сеньорской?
У меня сейчас фулстэк мидл позиция, и я хожу по собеседованиям на 200к+ в российском ИТ.
Регулярно слышу, что я со своими запросами не соответствую 200к, потому что 200к это сеньор :)
И этим людям, которые хотят 200к платить "сеньору", приходит в голову замечательная идея водить собеседуемого вопросами по всем секциям - в том числе по алгоритмам и sql. Для фулстэк позиции.
потому что 200к это сеньор
А какой стек? Потому что для .NET, например, сейчас уже да - 200К это уже сеньор. Про з/п в 300-400К на руки, как пару лет назад, лучше (для настроения и нервов) начинать забывать.
С чем связано такое падение зарплат в .NET?
Да почему же только в .NET. Можно посмотреть на HH вакансии по Java с опытом от 3 до 6 лет (которые, причем, по требованиям вполне на синьора тянут). Больше половины вакансий не дотягивают до 250К. А с чем связано, думаю, все и так знают.
Какие-то крайне прохладные истории. Сейчас AT мидл на Java стеке в финтехе спокойно может просить от 250к+
Не верю, что мидл бэкенды на яве там получпют меньше чем АТ :)
С тем что большая часть работы на серьезных стеках была аутсорсом на запад. Зато продуктовые стеки сейчас вполне неплохо себя чувствуют.
Есть ощущение что период бурного роста зарплат прошел, к сожалению. Да и российское IT в массе не богатеет последние 2 года. Как исключение - повсеместно замещающее ПО типа астры и мойофис, но и там насколько знаю не золотые горы платят. А так 200 мало для опытного разраба конечно уже, с текущей инфляцией и курсом.
нет, я вообще случайно на интервью оказался, т.к. не моя зона ответственности. Я уже с работающими специалистами работал). А просил тот соискатель от 300к рублей, на 250к бы согласен на испытательном сроке. К концу собеседования он "поплыл" от вопросов нашего сеньора, когда вопросы пошли не только про знание языка, паттернов и библиотек, но и про какие-то алгоритмы и немного математики. Кстати, это интересный момент. В моем понимании, сеньор это не столько программист, хорошо знающий свой стек, но еще и человек, имеющий хорошие фундаментальные знания (математика, компьютерные науки) в своем направлении. Пусть даже он хуже помнит какие-то мелочи из синтаксиса, настройки окружения и прочего - их всегда можно подглядеть, но он должен уметь мыслить на уровне выше обычного кода. На уровне вот есть задача - как ее эффективно решить, и только потом уже - выбор инструментов (библиотек) и т.п.
Вопрос справедливости отбора. Вы действительно считаете, что человек который зазубрил функции требуемого стека и алгоритмы будет лучше чем человек, с бОльшим опытом разработки, который быстро найдет и применит нужную информацию? Плюс еще фактор стресса на собеседовании, он по разному на людей влияет . Но тут уже наверное ничего критически с этим не сделать, все равно собеседовать надо. Хотя и тут можно уменьшить фактор стресса средний, например включать режим диалога а не допроса, не писать новый код, а разбирать готовый и т.п.
Вы действительно считаете, что человек который зазубрил функции требуемого стека и алгоритмы будет лучше чем человек, с бОльшим опытом разработки, который быстро найдет и применит нужную информацию?
В какой-то степени (если именно зазубрил весь Reference Manual) - лучше. Потому что он будет сразу из головы писать, а не гуглить/искать, как именно функция называется. Разница в скорости примерно как знать иностранный язык со словарем и без.
Другое дело, что подобные сооброжения в нашей индустрии уже давно, вроде, не учитываются.
Что лучше - разраб, который быстро пишет ахинею, или разраб, который пишет медленно, но хорошо?
Сравнение знания языка программирования со знанием естественным языком тут на хабре уже не в первый раз не любят, но - "кто лучше, писатель естественных текстов, который быстро пишет ахинею или тот, который пишет медленно, но хорошо"
Очевидно же, что лучше тот, который быстро пишет хорошо. Человек может быть сколь угодно умным и хорошо рассуждающим, но если он излагает свои мысли в режиме "знаю язык со словарем" - то лучше бы, наверное, поискать того, кто в словарь пореже заглядывает. Беглость написания результатов труда в каком-то проценте случаев все-таки влияет.
Какое-то нечестное у вас сравнение)) Обычно, кто знает со словарем, часто имеет более широкий кругозор, чем тот, кто знает без словаря. Потому что на то, чтобы знать без словаря надо тратить время на его выучивание. Либо это большой перекос в опыте именно на этой технологии. Хорошо это или плохо, зависит от точки зрения. Работодателю хорошо, но ему же и плохо, т.к. трудно будет найти замену такому знатоку, да и з.п. может быть там неземной. Спецу - по зп может быть хорошо, а еще глубокие знание в нужном стеке - тоже хорошо. Но плохо, если ему придется покинуть гнездышко и искать себе работу где-то еще, это может быть трудновато. Шаг влево, вправо - пропасть. Поэтому ваши сравнения однобоки.
Нормальное сравнение.
Переводчики - слова учат же и потом, как я понимаю, еще и специализируются по областям. И никто на них странно не посмотрит, если они подобной зубрежкой займутся.
Писатели, которые хорошие, говорят, тоже словари родного языка просто читают.
В нашей индустрии - решили, что такое знание 'из головы' в большинстве случаев не очень надо. Но это не говорит о том, что оно преимуществ не дает. Вместе с недостатками, разумеется - на зубрежку Reference Manual-ов время нужно.
Вы действительно считаете, что человек который зазубрил функции требуемого стека и алгоритмы будет лучше чем человек, с бОльшим опытом разработки, который быстро найдет и применит нужную информацию?
К сожалению опыт(а точнее стаж) сам по себе не обязательно что-то означает. Например я знаю достаточно много "вечных миддлов" и даже "вечных джунов". То есть у людей стаж по 10-15 лет, но развитие в какой-то момент прекратилось и уровень знаний и умений "заморозился" на этом уровне. И речь не обязательно о "новых-модных ЯП/фреймворках".
Ну я бы лично предпочел работать с мидлом, который 15лет нормально работал, чем с выскочкой, который вырос в тимлиды и делает ошибки на уровне джуна (не преувеличиваю, буквально вчера был случай с тимлидом чужой команды).
Все очень просто, когда ты 15лет получаешь по шее за ошибки, то учишься их не допускать. А если ты начитался всяких умных словей на хабре и пошел по карьерной лесенке, то не приобрел этот опыт.
Ну я бы лично предпочел работать с мидлом, который 15лет нормально работал, чем с выскочкой, который вырос в тимлиды и делает ошибки на уровне джуна (не преувеличиваю, буквально вчера был случай с тимлидом чужой команды).
Ну так а зачем вы сравниваете миддла с джуном? Кроме того в тимлиды совсем не обязательно берут за технические навыки.
Все очень просто, когда ты 15лет получаешь по шее за ошибки, то учишься их не допускать
Или нет. Например потому что уволить всё равно не могут. Или просто фирма по шее не даёт. Ситуации разные бывают. Люди тоже.
15лет не могут уволить? Такое только в сказочных историях бывает.
Или в фирмах с сильными профсоюзами например.
И потом ошибки они разные бывают. Если не критичные и от человека в сумме всё равно больше пользы чем вреда, то зачем его увольнять?
Это и есть сказочные истории, про какие-то мифические фирмы, где можно 15лет пинать балду и не быть уволенным.
В сумме ложка дерьма портит бочку меда.
Это и есть сказочные истории, про какие-то мифические фирмы, где можно 15лет пинать балду и не быть уволенным.
Я могу вам конкретные фирмы назвать где это работает. Платят не особо. Но и не напрягают.
Платят не особо
Может все дело в этом? Если людям не платить, то пофиг как они работают.
"Не особо" это по сравнению с другими ИТ-конторами. По сравнению с другими профессиями это вполне себе "особо" :)
Ну и как бы каждый решает для себя: хочет он деньги и напряг или без напряга и "не особо".
Проблемы начинаются когда такие вот "без напряга" и со стажем в 15 лет начинают искать новую работу. Попробуй угадай что у тебя за канdидат.
Смешно сравнивать дворника с программистом и говорить про "особо". Все эти ваши конторы, где десятками лет пинают балду за копейки, работодатели в других конторах прекрасно знают.
Смешно сравнивать дворника с программистом и говорить про "особо".
Можно сравнивать с другими инженерами.
Все эти ваши конторы, где десятками лет пинают балду за копейки, работодатели в других конторах прекрасно знают.
Ну вот я лично скорее всего вот прямо все не знаю. Даже в своём городе. Пару-тройку покрупнее знаю и всё. Про другие города или даже страны я вообще молчу.
не преувеличиваю, буквально вчера был случай с тимлидом чужой команды
Это стандартная проблема, очень малая доля тимлидов с опытом имеют уровень синьоров, ибо много времени уходит на менеджмент, внутри команды нередко легче использовать админ ресурс, чем технические аргументы, а выработки совместных решений между командами зачастую требуют политики, а не технических знаний.
Но ожидания у тимлида будут выше, чем у синьора, а потому Вам случай выше, на самом деле, довольно частый.
Сам по себе, нет, никто и не говорит что надо брать "не глядя", чисто за стаж, нужна адекватная беседа ("собеседование" однокоренное слово) про опыт и тип рашаемых задач на предыдущих местах, используемые стеки, вопросы по общим знаниям а не тупой тест на типовые задачки с таймером или заковыристые особенности синтаксиса языка (я приводил реальный пример из моего опыта c=a++++b) . В конце концов есть испытательный срок для реального программирования. Просто какое-то унижение испытываешь местами на собесах, хотя вроде и работать готов и напрячься сильнее чем на текущем месте. А уровень знаний и умений реально морозится если совсем не менять места, ну или хотя бы целиком поменять стек внутри одной компании, что не так-то просто. Стимул в виде смены работы как раз хорошо работает для прокачки опыта, и это не литкод
нужна адекватная беседа
И каждый понимает под этим что-то своё :)
я приводил реальный пример из моего опыта c=a++++b
А оно вообще скомпилируется? Я, просто в C/C++, но в C#, например, лексический анализатор всегда "жадный", поэтому это будет то же самое, что c = ((a++)++)b, что дважды ересь.
скорее не скомпилируется, чем да, и это как бы правильный ответ :) но подозреваю что какие то компиляторы могут пропустить (тут нужно глубже копать и читать стандарт).
Вот, кстати, например, Вы считаете это надо держать в голове реально для опытного разработчика? :)
Вот, кстати, например, Вы считаете это надо держать в голове реально для опытного разработчика? :)
Тут, по-моему, в голове ничего особо держать не надо, просто иметь очень общее представление о том как работают компиляторы. Ну, если нет претензий на большее чем всю жизнь до пенсии контроллы по формам мышью таскать в Дельфи, то, наверное, это и вправду совсем лишнее. Я вот знаю достаточно людей которые вполне успешно этим еще с девяностых занимаются. Получают, в наших краях, правда, по 60-70 К (рублей) в месяц, но, походу, их это вполне устраивает.
Какая-то странная у Вас классификация разработчиков, ну т.е. либо помнить особенности компилятора наизусть, либо формошлепствовать, третьего совсем не дано?
Хотя наверное у каждого своя норма памяти - вот освежил я сейчас знания по этой особенности компилятора, как долго по-вашему, я должен ее помнить до того как снова столкнусь с ней в работе (надеюсь никогда, т.к. кто так пишет - код ревью не пройдет в нормальных компаниях) ? Я лично забуду за пару лет. И приоритеты операторов я обойду скорее скобками лишними либо выносом в отдельную переменную чтоб исключить ошибки и код был более понятен для других "забывших".
Я ошибаюсь или принципы работы компиляторов тут вообще не важны, потому что четыре плюса ни в какое выражение сложиться не могут вообще никак?
поэтому это будет то же самое, что
c = ((a++)++)b, что дважды ересь.
Примерно то же самое в C++. Первый инкремент вернёт r-value, потому второй инкремент уже невозможен. До b дело даже не дойдёт. Всё это выясняется в течении 30 секунд. Зачем брать на себя функции компилятора, и как это определяет уровень разработчика - непонятно.
я приводил реальный пример из моего опыта c=a++++b
Честно говоря, я бы на этот вопрос ответил что-то в стиле — если это рабочий код из вашего приложения, то его нужно пошагово пропустить через дебаггер, чтобы понять, что при этом происходит, а потом переписать так, чтобы мозг не ломался при чтении :)
Точно так же, как корректный ответ на "что делает ++i++" — "это UB, не пишите так".
Могут быть уникальные случаи, когда это часть большого кода, который всеми используется как чёрная коробка, трогать его нельзя, и там всё написано таким образом, потому что автор — верный последователь Кармака и Силвермана. Тогда из вариантов только юнит-тестами обложить и не притрагиваться. А если от меня ожидают, что я это буду понимать интуитивно и сам писать то же самое, то спасибо, мне не туда))
Не преувеличивайте)
Почему вы думаете, что я преувеличиваю? За последние лет 5, примерно 2/3 собеседований мне хотелось закончить как можно скорее и больше не общаться с этими людьми и организациями.
"Так вот, его уровень был примерно мидл минус, а зп и прочих условий хотел как у сеньора."
А почему собственно нет?
Бытующее во многих головах представление о том, что уровень вознаграждения должен зависеть от скилов работника, весьма спорен.
Тут пост же про здравомыслие?
А оно подсказывает, кмк, что вознаграждение по справедливости должно зависеть от вклада в проект. И тут все очень неоднозначно.
Чей вклад на галере больше, лоцмана или гребцов? Зависит от маршрута.
Если у вас реально сложный проект где нужны скилы значительно выше среднего, то да, заслуги синьора неоспоримы. А для очередной штамповки решения уже решены, там грести надо.
его уровень был примерно мидл минус
Блин, я сначала прочитал "мидл индус"
;o)
Лично мне не нравится вопрос про полиморфизм
На самом деле, вопрос, кстати, весьма интересный. Потому что, строго говоря, понятие полиморфизма выходит довольно далеко за рамки интерфейсов и виртуальных методов (как обычно отвечают, хотя и то и другое это всего лишь очень частные случаи).
вирусы изменяющие свой код
Здесь (у джавистов) ожидается очень конкретный ответ, а именно про subtyping полиморфмзм, наследование и overriding методов. Это же буквально вопросы, на которые хотят услышать конкретный ответ и ключевые слова. А если вы начнете рассказывать про параметрический полиморфизм или тайп-классы, то еще и в минус засчитают, мол, ерунду какую-то ответил, не знает про переопрелеление методов и полиморфизм :)
Это как с каким-нибудь REST'ом, где если ты начнешь говорить, что сегодня 95% пересыланий джейсонов по хттп на фронт не является вовсе никаким рестом в изначальном его понимании, то на тебя косо посмотрят.
Поэтому нужно играть в игру и отвечать то, что ждут услышать
Здесь (у джавистов) ожидается очень конкретный ответ
Вот уж не знаю, что там и кем ожидается - я не ясновидящий оракл чтобы это угадывать, поэтому даю правильный (с моей точки зрения) ответ - если кто-то не согласен, то либо мы можем это обсудить, либо пускай он идет лесом. Меня (C#), вот, кстати, однажды прямо в открытую спросили: "Являются ли .NET generics полиморфизмом?". Ответ: Да, являются.
На мой взгляд что такое полиморфизм должен знать Джун и ещё пара людей, книги писать.
Если термин не используется в работе, то он забывается за первые 5-10 лет, как бесполезный.
Полиморфизм это что-то где-то изменилось, возможно в результате наследования, но не факт. Ещё он кажется столп ООП, да?
"Я тут наследовался от класса Н, получилось вот это, и оверайднул то", "Написал пару дженериков под нашу фитчу" норм? Да.
"Я полиморфил класс Н и инкапсулировал в него.." Шта?
Я бы советовал при нормально/хорошем собесе просить ту зп которую вы хотели иначе умножать на 1.5 - 2. На хорошем проекте конечно хочется работать, но можно и говно порефакторить если кто то х2 от изначальной хотелки сыпанёт. Личное мнение не бейте :)
А потом эти люди пишут статьи на Хабре о выгорании))
Выгорать конечно очень не кайфово, иногда приходится вытирать слезы деньгами. Но все же кто бы что ни говорил о высшей цели своей работы или о прекрастности своего проекта когда появляется предложение х2 каждый задумается и это многое говорит о реальных целях всех нас. Рождены что бы комфортно жить а не комфортно работать. А для хорошей жизни как ни крути нужны деньги. Иногда приходиться выбирать (и выгорать) :)
Так потому и х2 надо просить, за каждый месяц работы компенсация месяца отпуска когда выгоришь )
Лично мне не нравится вопрос про полиморфизм, ведь он настолько тесно связан с большинством объектно-ориентированных языков и наследованием, что большинство людей используя его (например, при переопределении или перегрузке метода) даже не думают «О! Это же полиморфизм в действии!».
Вот я бы услышав такой ответ, для себя пометил что полиморфизм Вы понимаете весьма ограниченно.
Так может это все-таки хороший вопрос?
Аналогично, важнее то, чтобы я мог сказать, где нужно использовать наследование, а где полиморфизм, чем формулирование их определений.
Если кандидат не может своими словами дать определение этим понятиям то скорей всего он до конца и не понимает что это такое а работает по наитию и далеко не факт что на практике везде может это грамотно применить.
Однако на многих собеседованиях и многих экзаменах вас, по сути, проверяют, насколько хорошо вы сможете заменить компилятор.
Ну здесь Вы все в кучу собрали. Как работает компилятор Вы как-раз знать обязаны. Во что разворачивается синтаксический сахар, где может быть оверхед на ровном месте, отличаются или не отличаются лямбда-выражения от ссылок на методы, какой сахар имеет стоимость а какой нет и многое другое. Если этого не знать то значит для Вас это магия со всеми вытекающими.
Другое дело что я согласен что вопросы про то где лежит какой метод и какая структура это полный бред. Но другой вопрос, что Вам мешает съехать с темы? Можно миллион ответов придумать от шутки до постановки интервьюера в неудобное положение.
У меня вот другая проблема - сейчас модно давать решать код в онлайн-блокнотах. Учитывая что я пишу в среднем на 4 ЯП то бывает проблемно вообще вспомнить как в конкретной языке называется функция которая что-то делает. На интервью по джава пишешь stream а потом в нем вызываешь методы из Kotlin sequence, а интервьюер хлопая глазами принимает.
Почему бы не открывать IDE и шарить экран для меня до сих пор загадка.
Полиморфизм, полиморфизм... Для кого-то полиморфизм - это свойство программы переписывать свой код, чтобы сигнатурой не светить.
А, ну это как меня однажды на собесе спросили, какой ассемблерный код сгенерирует компилятор Go для инкремента
Тут в принципе можно догадаться, не зная ни ассемблера, ни Go.
Можно догадаться. А можно и не догадаться. Я ваш сраный ассемблер 2 раза в жизни видел на картинках. И нахуя вообще такое спрашивать у разраба на Go?
В принципе понятно, почему вас не взяли)
Человека можно понять. Вы или низкоуровнего сишника, оптимизатора берете, либо кодера бизнес-логики.
В бизнес-приложении никто не будет смотреть на код, генерируемый компилятором и JVM. Эффект для производительности имеет только правильный выбор коллекций, алгоритмов работы с ними, стримами и грамотные sql-запросы.
В целом любой работодатель предпочтет более сообразительного и менее душного кандидата менее сообразительному и более душному. Такова наша жизнь, так сказать.
насчет душного с большой вероятностью наоборот кстати (если брать именно пример с ассемблером на собеседовании на другой язык) :)
Ну такое себе. Обычно, добродушного кандидата берут, когда команда слабая, или надо работать с джунами/практикантами. Когда команда сильная, могут вообще сказать, что тебя ждëт токсичная среда, сынок! Иначе, я просто не понимаю, как будет выглядеть работа в команде профи, где каждое решение оценивается через сто тысяч "почему"?
Работодатель предпочтет менее высокооплачиваемого разработчика при тех-же требованиях к должности. Для разработки приложения с формочками и sql-запросами знание ассемблера не только не нужно, но и вредно. Насчет "душности" - руководству вообще безразлично.
Вы или низкоуровнего сишника, оптимизатора берете, либо кодера бизнес-логики
Иногда фирма хочет и то, и другое, но дает больше денег.
Обычно так проверяют глубину технических знаний, например спрашивают как работает volatile в джава, если знает можно спросить а как это реализовано технически? На уровне железа, рам и процессора. Это не способ завалить кандидата, просто тема для разговора программиста с программистом, сам случайно прочитал где то, встретил коллегу и опа ) это как смол толк на кухне за обедом.
С такими людьми в индустрии, как вы, она скоро придёт к тому, что на собесах на формошлёпа и перегонщика джонсонов будут спрашивать про логические вентили и D-триггеры
Ну вот у меня тоже есть предположение почему вас не взяли. И на мой взгляд к вашему уровнйu знания ассемблера это никакого отношения не имеет :)
А к чему тогда имеет? Говорите напрямую
К использованию ненормативной лексики при общении с незнакомыми людьми.
А мы и не на собесе
А и не важно. Если вы себе позволяете такое или похожие вещи, то для кучи людей/фирм это уже "звоночек".
Ну вот и сдеаноньте меня прямо здесь и сейчас и внесите меня во всевозможные чёрные списки и т.д. А пустые угрозы ваши меня не интересуют
Причём здесь какие-то угрозы?
Если вы на собеседовании ляпнули что-то в этом духе,то это возможно и было причиной. Или например если вы общались так же, как сейчас общаетесь со мной.
На собеседовании я ничего такого не говорю. Если я вижу, что передо мной сидит конч, который просто самоутверждается, я не довожу до срача, зачем мне нервы и время на такого тратить? Всё равно его викторину я не пройду, а если и пройду, то в работе такой человек будет просто невыносим. Я просто говорю: "Простите, слишком душно", и ухожу с говно-собеса
Или вы просто не замечаете что вы "что-то такое" где-то ляпнули.
На собеседовании я ничего такого не говорю
Сколько там процентов информации передается невербально?
Да мне вообще всё равно, сколько. Люди все разные и каждый самостоятельно додумывает, что там ему между строк сказали. Вот я сказал на собесе: "Сорри, не сработаемся, до свидания". Кому-то будет пофиг, а кого-то уже трясёт и он в ярости требует от HR'ов все мои контакты, чтобы нанять спортиков по мою голову за такое космических масштабов оскорбление
Ну это пока з/п на текущей работе устраивает. А как захочется на жирную оплату устроится, тут то ваши манеры вас и выдадут.
Большие деньги - это палка о двух концах. Я за большие (весьма относительно) деньги работал в таком месте, что в какой-то момент понял - или я увольняюсь, или мне придётся посещать психиатра/невролога. Условия труда с деньгами при этом порой не коррелируют вообще никак. Зачастую там, где собес более конченый, платят тоже меньше. Так что стелиться и прогибаться за большие деньги, на мой взгляд, смысла в этой индустрии особо нет
Да и я не смог бы прогнуться, даже если бы захотел. Сегодня на собесе по Go у меня спросили про ассемблер. Завтра спросят ещё какой-нибудь бред, не имеющий прямого отношения к работе. Я в какой-то момент понял, что мне всей жизни не хватит на то, чтобы выучить абсолютно весь набор бессвязных фактов, которые могут попасться на собеседовании в IT
И поугрожал себе и на слабо попробовал и сразу забил. Не выходя из коммента! Вот это я понимаю эффективная беседа. Время - деньги.
Тем более что по закону одной страны это преступление (как и позволение таким комментариям появляться)
Ну да, всем нужны лояльные сотрудники, которые не будут бухтеть и критиковать решения.
Потому что он считает мудацкие вопросы мудацкими и реагирует на них соответствующим образом?
А вдруг это вообще был психологический тест? Проверить, как кандидат себя ведет в ситуации, когда, скорей всего, он не знает ответ на вопрос. :)
Если бы я был способен проходить всякие там стресс-тесты, то я бы пошёл в место поинтереснее, например, во внешнюю разведку, а не целый день сидел и джонсоны перегонял
А разве Вы всегда знаете все ответы на все вопросы на работе? Разве никогда не бывало ситуации, когда в середине совещания приходится говорить: «так, я эту тему не знаю, но мне она важна для …, а потому мне надо Х времени на изучение, иначе я не смогу принять взвешенное решение. Не подскажете, кто может быть лучшим контактом?»
Да не, речь не про стресс-тест. Так можно проверить человека на предмет адекватности (с их точки зрения). Ответит ли честно, что не знает, ведь это не его обычная работа. Или начнет зубы заговаривать, что-то пытаясь ответить и оправдаться по ходу дела. То ли с умным лицом скажет какую-то глупость (а вдруг). Или вообще включит какую-то агрессию на такой неожиданный вопрос. А, может, вообще ответит так, что сразу захочется контракт бежать подписывать (и я не про ответ, а способ / поиск ответа на вопрос). :)
Для отсеивания неадекватов есть HR'ы со своими первичными скринингами. Касательно второго - гении никому не нужны. Нужны те, кто будет просто решать задачи бизнеса. Вспомните кейс разраба Homebrew. Или требование к нему развернуть дерево - это тоже проверка на адекватность? По-моему уже давно все знают, что нет. Все эти литкоды и прочие глупые и бессмысленные вопросы и задачи нужны только для того, чтобы быстро фильтровать гигантский поток кандидатов
Разработчиков на свете просто стало слишком много, гораздо больше, чем миру в принципе нужно. Собесы со временем будут становиться всё более лютыми и неадекватными, пока рынок IT не начнёт охлаждаться. Охлаждаться он начнёт, когда все эти орды фронтендеров, бэкендеров и девопсов начнут бросать свои специальности и перекатываться в другие профессиональные сферы
Спросить "для какого процессора" ?
Рисуют на стене футбольные ворота, а на полу мяч. Говорят забить гол. Что будешь делать?
Ответ: Попроси дать пас
Рисую на стене футбольные ворота, а на полу мяч. Встаю "на ворота", прошу пробить пенальти. Что делать? :)
Рисуют на стене футбольные ворота, а на полу мяч. Говорят забить гол. Что будешь делать?
Ответ: Попроси дать пас
А теперь переходим к вопросам на сеньйора в нашу компанию!
Есть два стула, на одном пики точены, на другом хуи дрочены, на какой сядешь, на какой мать посадишь?
Ответ: Возьму пики точены, срублю хуи дрочены, сам сяду и мать посажу.
зачем?
ps. спросить как ей ответить кратко или все разжевать
если кратко то ассемблер синтаксический сахар над опкодами
если разжевать то ассемблер это синтаксический сахар объединяющий под одной командой несколько опкодов которые будут записаны в код в зависимости от того какие операнды будут применены вместе с ассемблерной командой.
опкоды это набор бит переключающих направление передачу данных/сигнала на на разные участки электронной схемы с возможностью разной реализации к примеру на микросхему счетчик поступает тактовый сигнал и сигнал с данными при переключении тактового сигнала в зависимости от уровня на линии с данными происходит сдвиг предыдущих данных на следующие выходы и запись на выход высокого либо низкого уровня сигнала. в зависимости от выбранной длинны бит команды и полезной информации выбирается нужное количество тактов на соседнем счетчике который подает команду на считывание данных с выходов первого счетчика отвечающих за команду перенаправления данных, они поступают к примеру на логические элементы и, или, не, и-не, или-не и в конечном счете включают к примеру один из переключателей сигнала (тип микросхем) который замыкает выходы данных первого счетчика с узлом схемы куда эти данные нужно передать к примеру в шину или в микросхему защелку(которая хранит данные для считывания и записи), или в узел арифметических операций и так далее и тому подобное.
чтобы в электронной схеме с цифровой передачей данных компенсировать помехи, дребез контактов и другие воздействия(температурный дрейф характеристик электронных компонентов, шум от компонентов и тд.) применяют триггеры Шмитта у которых переключение сигнала между уровнями происходит не при пересечении одного уровня напряжения, а при двух - низкий уровень сигнала частично заходит в область высокого и наоборот - чем больше размер амплитуды сигнала между этими двумя уровнями переключений тем стабильней работа схемы, а чем меньше уровень амплитуды между высоким и низким уровнем сигнала тем быстрее будет происходить переключение схемы.
базовые узлы электронной схемы состоят из активных(полупроводники) и пассивных элементов(индуктивности, емкости, сопротивления) на высоких частотах приходится приходится к примеру длинной дорожек компенсировать/уравнивать скорость прохождения сигнала, также на высоких частотах ток(электроны) движутся по внешней части проводника поэтому применяют вместо одной жилы много мелких для увеличения внешней площади.(в некоторых случаях применяют волноводы)
в полупроводниках в основном применяется электронно дырочная проводимость(один из представителей биполярный транзистор) и управление прохождением сигнала в электрическом поле(один из представителей полевой транзистор); также здесь открытие биполярного транзистора к примеру фотонами(оптопары транзисторные), ложные срабатывания микросхем от радиоактивного излучения, (на счет квантовых схем обращайтесь к физикам - с такими знаниями к Вам смысла устраиваться нет)
микросхемы изготавливаются фотолитографией. на деэлектническую подложку наносят тонкий слой электропроводного вещества (химический - растворы активаторы - к примеру на основе палладия) (можно использовать вакуумное напыление), электролизом осаждают нужный металл, наносят фотополимер далее через трафарет его засвечивают, не отвержденная часть смывается одним составом раствора, потом делают протравы (чтоб получить диэлектрические промежутки), смывают отвержденную часть фотополимера другим составом, наносят фотополимер и засвечивают следующей маской, смывают неотвержденный фотополимер, проводят реакцию к примеру для создания оксидной пленки, проводят смывку, и так далее постепенно наращивают слои, чтоб можно было похвастаться не настоящими нанометрами применяют осаждение других металлов у которых плотность кристаллической решетки больше (осаждая под внешними воздействиями давление, температура и тп.) после завершения изготовления схемы ее устанавливают на подложку корпуса с выводами и приваривают к нужным местам проводки от ножек(к примеру из золота)
и тд.
И правильно спросили, если вы затрудняетесь ответить на такой вопрос это норм, а вот если считаете что знать и понимать как работает и устроен компилируемый язык на котором вы пишите, то возможно вам стоит сменить этот язык в пользу Java, C#, python и т.д.
Так как вашему работодателю, будет не очень весело, когда на сложной задаче, вам придется дебажить код, вы откроете pprof с disam флагом, и не сможете понять, а что там происходит.
Да мне как-то pprof и без disam хватало. И то всего один раз пришлось в принципе использовать профилирование
возможно вам стоит сменить этот язык в пользу Java, C#
Чтобы менять язык на Java или C# для начала надо знать что это тоже компилируемые языки :)
Ага, а еще знать, что они компилируемые достаточно своеобразно и не классически, так как у них под копотом не ASM, а специфичный байт-код, - знать который в принципе не сильно обязательно, - за исполнение которого и привидение к машинному отвечает виртуальная машина ( ака интерпретатор ), он же JVM для Java или .Net для С#. И это особенность сильно отличается от языков с классической компиляцией ( хотя назвать го, классически компилируемым можно с наятжкой из-за его особенностей с asm ), где знать assembler и понимать чего там с билдит компилятор, очень даже нужно, что в Go, что в С++, что в Rust.
И в С# и в Java, что там скомпилировалось и как, знать особо не нужно, так как ООП для того и существует, что бы максимально возможно от этого абстрагировать. Чего не скажешь о процедурщине в Go или Rust например, и в случае первого знать что и как работает на уровне процессора, что во что компилируется и как отрабатывает, желательно, но не обязательно ( да и вопрос на собесе не предполагал, точного ответа, скорее проверял знания на кое-какие особенности языка с asm, хоть и не уверен, так как всякое бывает, но обычно такие вопросы предполагают именно понимание кое-каких особенностей, а не ответ какие именно команды будут скомпилированны ), то во втором обязательно.
Так что мой совет, если человек не хочет во все это погружаться перебираться на Java или С#, как раз обоснованно. Там как раз про перекладывание json и бизнес-логику, а не про понимание того, как оно там все под капотом работает.
у них под копотом не ASM, а специфичный байт-код, - знать который в принципе не сильно обязательно, - за исполнение которого и привидение к машинному отвечает виртуальная машина ( ака интерпретатор ), он же JVM для Java или .Net для С#.
Ок. Спасибо за разъяснение. На Хабре всегда что-то новое узнаешь.
В книжках по оптимизации Java вполне себе разбирается, как компилируется и во что код в class, и как потом этот class компилируется во время JIT-компиляции.
И вполне себе спрашивают, как и каким образом java-код компилируется. Плюс спрашивают про управление памятью в java (а их там несколько).
Не знаю Go, но подозреваю, что в java заморочек больше. И если в "компилируемых" языках вы управляете производительностью напрямую, то в Java очень-очень опосредовательно, что очевидно не проще. А проблем с производительностью в реальных приложениях полно.
В книжках по оптимизации Java вполне себе разбирается, как компилируется и во что код в class, и как потом этот class компилируется во время JIT-компиляции.
Да нет там никакого JIT, сказали же вам эксперты: "aka интерпретатор он же JVM" :)))
Перед тем как что-то перднуть, вы бы узнали для начала что такое JIT, и как устроенна JVM и что такое интерпретатор. И чем интепретируемый язык, отличается от компилируемого.
И да по поводу интерпретатора Java и Jit в нем.
https://en.wikipedia.org/wiki/Java_virtual_machine#Bytecode_interpreter_and_just-in-time_compiler
>> Вот я бы услышав такой ответ, для себя пометил что полиморфизм Вы понимаете весьма ограниченно. Так может это все-таки хороший вопрос?
Читается как "я умный, вы тупые, правильно что вас не взяли".
Если он понимает полиморфизм ограниченно, а вы - нет, то предлагаю разъяснить и ему, и всем вокруг, в чём же суть полиморфизма, прикрепить какие-нибудь примеры почему именно в этом суть, и уже после этого задвигать токсичный комментарий.
Какой смысл от комментария, если он суть есть самодовольство без конкретики?
Я сейчас тоже могу набросать на ваш комментарий, что вы вообще ничего ни в чём не понимаете. Полезный комментарий получится?
Как работает компилятор Вы как-раз знать обязаны.
Я вас умоляю. Какие компиляторы. Посмотрите просто тут на количество статей: "Нужна ли программисту таблица умножения".
Если кандидат не может своими словами дать определение этим понятиям то скорей всего он до конца и не понимает что это такое а работает по наитию и далеко не факт что на практике везде может это грамотно применить.
Знать как правильно называется какая-нибудь хреновина-морковина и уметь правильно её использовать совсем никак не коррелирует между собой. Так же, как и владение терминологией никак не говорит о том, что он умеет пользоваться этим инструментом.
Мне кажется гораздо эффективней беседа типа "У нас проблема тря-ля-ля... Как бы вы её решили?" Но если в описании выше собеседующему можно выдать шпаргалку с правильными ответами по которой он будет проверять кандидата, то во втором случае он сам должен во всём этом разбираться и понимать.
Немного не в тему, но хочется поделиться: Я недавно проходи цикл собеседований, где одним из требованием было тестирование на полиграфе. (впервые за 15 лет с таким столкнулся). Я согласился из чисто любопытства, но в итоге сильно пожалел. Фирмы которые занимаются проведением тестирования абсолютно не умеют обращаться с конфиденциальными данными, специалист по ИБ там даже мимо их офиса не проходил.
Было бы интересно почитать какие там были вопросы.
Ну по моему опыту, этим занимаются классические персонажи, типа Гуп Нии Теплоцентрали и вопросы соответствующие, типа от не баловались ли вы травкой, до не сливали ли информацию конкурентам. Обычно это конторы повернутые на том, что у них что-нибудь украдут. И то-ли действительно крадут, что вызывает вопросы к конторе, то-ли просто начальство такое невротичное. В любом случае начинать работу с полиграфа, это надо расписаться в недоверии ко всему миру в принципе, не рекомендую короче таких.
Про Джаву там спрашивать не будут, они не знают что это такое :)
При этом эти же конторы не способны пройти в своей паранойи на полшага дальше, и подумать о том, что в случае утечки данных, шантажу могут подвергнуться их же сотрудники и второе о чем попросят вымогатели после денег, это украсть данные у компании.
главное, что полиграф - псевдонаучное устройство. И как можно работать с людьми верящими в псевдонауку - вопрос
Вопросы в основном про наркотики, связь с орг. преступностью, азартные игры и вред работодателю. Так в целом ничего выходящего за рамки закона о полиграфологах.
Ну и как тут не завалиться на вопросе о вреде работодателю?
Вопрос в стиле: Наносили ли вы когда либо умышленно вред компании? Потом следует вопрос: о том что вы лично считается вредом для компании? Вообщем многое зависит от вашего личного отношения к тем или иным явлениям.
о том что вы лично считается вредом для компании?
Отказ от участия в тим-билдингах и совещаниях на тему "как я могу улучшить работу компании" (в пятницу вечером после работы, обязательно для всех, включая уборщиц)? ;-)
"что вы лично считается вредом для компании" Полиграфы поумнели, что в таких ответах разбираются? Раньше ответы ограничивались Да/Нет/Незнаю и всё, остальное трудно дешифровать.
Меня спрашивали вопросы вроде: нарушу ли я закон за $100000 и так далее
Ну это хороший признак, что идти туда не надо, мне кажется. Интересно кто это был? Околовоенное что-то?
Околофармацевтическое
Попробую угадать. Лет 10 назад в отрасли был целый сегмент компаний с такими особенностями. Надо было бы пилить CRM для медицинских представителей? И, наверное, компания отечественная?
Название компании начинается и заканчивается на "А"?
Если да, то тоже там был, tl;dr - трактую это все как отсутствия доверия к кандидату, неравноценный заход как бы сверху (тебя могу "допрашивают", а ты их не можешь), "читерский" способ узнать инфу, вместо того, чтобы проявить свою эмпатию.
Там были и не совсем этичные вопросы, типа:
"Вы считаете себя хорошим руководителем"
"Распространяете ли вы сплетни о коллегах"
"Вы пришли в нашу компанию только для того, чтобы получать зарплату?" и т.п.
В отличие от вопросов типа "воровал/состоишь в ОПГ", ответы на вопросы выше отчасти субъективные (мнение о себе, что такое "сплетни") и в целом, мне кажется, не этично со стороны работодателя вообще узнавать их таким образом. Наверное, было бы справедливо посадить их на тот же полиграф и позадавать им свои "неэтичные" вопросы, так будет хотя бы разговор на равных как на интервью =)
Вообще, было противное ощущение, будто это какой-то прямой "хак" твоего мозга, хороший интервьювер может попытаться понять в ходе обычного интервью, какие мотивы кандидата, задавая поведенческие вопросы и смотря на реакцию кандидата. А даже если интервьювер "ошибся" или кандидат умело показал ему "правильную" реакцию, то есть 3 месяца испытательного, когда можно лучше понять, годиться человек или нет.
Как будто у руководства не хватает эмпатии, чтобы понять какой кандидат перед ними в ходе интервью, и человеческого доверия. У них там все, по словам полиграфолога, по кругу на этом тесты полиграфе проходят.
не Тандер случаем? У них это известная практика
Все эти "нановопросы" появляются когда не знают что ещё спросить, а кандидатов как-то отсеивать надо. И если у разработчиков они смещаются в вопросы за 300 из Своей игры, но хотя бы по теме, то у продавцов могут спросить жуткий мрак, не относящийся к делу вообще. Это типа им как-то нарисует "портрет кандидата". Натальная карта в понимании таких Эйчаров, это научная программа.
Ну.. было собеседование в вопросами за 150.. на первый ответил, а потом задал встречный вопрос по подводным камням golang, и видя как поплыл сеньор сказал до свидания, ваша контора мне не интересна.
Как-то многие забывают, что собес - это палка о двух концах.
это вы еще на собеседованиях тестировщиков не были, вот это воистину сфера, где не знают, что спросить
Хороший инженер мыслит абстрактно, на языке проектирования и создания систем, на языке алгоритмов, компонентов и технического проектирования.
Получается, что умение спроектировать систему может перевесить незнание конкретных пакетов, методов или особенностей синтаксиса?
А разработчика нанимают, чтобы он особенности синтаксиса знал? Или все же...?
Проекты систем в мануалах не найти, в отличии от... Пакеты сегодня одни, завтра другие, синтаксис везде разный.
Мой зав.кафедры говорил, (тут не дословно но близко к оригиналу)
"- если математику надо узнать объем детского синего мячика - он вспомнит формулу объема шара и посчитает;
- если это надо физику - он поместит шарик в воду в мерной посуде и измерит объем вытесненной жидкости;
- если это надо инженеру то он - возьмет "справочник объема детских синих мячиков №2" и возьмет цифру оттуда.
Вы инженеры, вы не можете помнить всё и знать все мелочи, это простительно, для этого у вас есть техническая документация, где всегда можно это подсмотреть, гораздо хуже если у вас нет инженерного мышления и общего понимания принципов"
И таки да я с ним согласен, по моему умение спроектировать систему намного важнее знания конкретных пакетов, методов или особенностей синтаксиса, (синтаксис языка программирования учится за неделю, умение выбрать правильные алгоритмы и структуры данных появляется с годами).
Легко. Нельзя объять необъятное, но часто вопросы задают по текущему стеку пакетов. Можно хорошо понять как и что внутри у них..
Отличная, статья. Полностью согласен с автором. Мне не обязательно глядя на код сразу понимать, в чём проблема, ведь есть инструмент, с помощью которого это делается лучше и быстрее. Пример из реальной жизни, допустим вам нужно точно определить расстояние до ближайшего здания, на глаз вы сможете определить примерно, но точно, только с учётом измерительного инструмента.
ровно через 5 лет наступает ежегодный отпуск однако
чувака просто на вшивость проверили и он посыпался ;) что такое полиморфизм вопрос философский... в каком пакете находится List никогда не смотрел, да и вообще он скорее всего ничего толком не смотрел, а писал на чем-то другом и по этому джунские вопросы на понимание не осилил. Хорошо что про блох у рыб рассказывать не начал)))
не выдаст ли он ClassNotFoundException, за меня это делает компилятор
конкретно это за вас кстати компилятор не сделает. Я ж говорю, автор полуграмотный, но бьет пяткой в грудь, в США это нормально, там все себя продают и не стесняются приврать на собеседовании, но когда он на собесе простите обосрался, то вместо того, чтобы подучиться - пошел гневные посты писать. такой он работник значит и инжинер.
в принципе такие вопросы нормальная практика для поиска мышцастого разработчика, потому что порой приходят люди с сертификатами и регалиями, которые трудно проверить, но потом вдруг они сыпятся на тупых вопросах, хотя сам факт подготовки и сдачи (вместе с наличием знаний в голове) должен исключать такую возможность.
Про List и File (в каком пакете) вопросы, конечно, дурацкие, но, по-моему, если человек каждый день пишет код, то сходу на это ответить это абсолютно ноль труда.
ок, сегодня он в в utils, завтра Oracle петух клюнет и он переедет, как было с тем, что пошло в пакет Jakarta. В чем польза этого знания, хоть минимальная? Я то может и помню, как и автор ответил на вопрос. Но если работодатель считает эти знания ценными - это уже звоночек, что что-то у него не так
Да пользы никакой, но подымать кипишь из-за этого и писать обвинительные статьи на Хабре это тоже как-то чересчур. Ну спросили и спросили. У меня тоже частенько - "в чем разница value и reference типов", " в чем разница абстрактного класса и интерфейса" - ну, синьору такие вопросы глуповато задавать (хотя даже на них можно дать ответы, которые выходят за рамки "ожидаемого" "ответа из учебника" - например, обсудить особенности default-ного GetHashCode для value-типов, или бинарной совместимости при изменениях в случае abstract vs interface).
Я ж говорю, автор полуграмотный
Грамотность определяют сделанные в прошлом проекты, а не призёрство в викторине-собесе каких-то чудаков. Онотоле тоже вон призёр, но реально дятел какой-то.
в принципе такие вопросы нормальная практика для поиска мышцастого разработчика,
Только вот в работе грузчика эффективнее жилистый "доходяга", а не накачаенный бо-дибилдер.
Грамотность определяют сделанные в прошлом проекты
ну в какой-то мере тоже (пишу так, потому что ваша учительница по русскому языку не листы считала а количество ошибок), ок и что автор может показать? скорее всего ничего, если он работал в команде, даже если это опенсорс и речь не про nda. Из того что я вижу - грамотные люди знают все эти вещи и строчат не задумываясь и проблемы с ошибками тоже видят быстро. Просто есть база которую надо знать и понимать и знать вы ее будете, если будете делать что-то вдумчиво и осмотрительно. А полялякать в духе "систем дизайн" интервью, что вот у нас база, а вот очередь сообщений, ах какой я крутой инженер больших знаний и навыков на самом деле не надо. Автор на это рассчитывал, но обломался и поднял вой.
а не призёрство в викторине-собесе каких-то чудаков
правда тут есть, т.к. "когда мера становится целью - она перестает быть хорошей мерой".
олько вот в работе грузчика эффективнее жилистый "доходяга", а не накачаенный бо-дибилдер.
не тех вы грузчиков видели) те что таскают диваны и холодильники именно здоровые мужики, иначе спина умрет. а жилистые обычно при магазине, там и обстоятельства жизненные иные и требования грузоподъемности тоже. а бодибилдеры зарабатывают другие деньги и в зале, им до уровня грузчика спускаться не надо.
ок и что автор может показать? скорее всего ничего, если он работал в команде, даже если это опенсорс и речь не про nda.
PR в опенсорс характеризует лучше всех викторин. Ну а если ни того, ни пет-проектов, сплошь и рядом nda - тут уж пусть не обижается.
Из того что я вижу - грамотные люди знают все эти вещи и строчат не задумываясь и проблемы с ошибками тоже видят быстро.
Какие-то видят, какие-то нет. А я вот даже не хочу знать что будет c = a++++b, потому что это за меня сделает компилятор.
Как раз хотел привести пример такелажников, которые участвуют в переездах enterprise оборудования. Там все погловно поуерлифтеры как миннимум хорошего любительского уровня. Или тренеры из заллов.
в общем вы и описываете почему таких вопросов надо сторонится. Живите в своем вымышленном мире, где родословная стандартных классов - очень полезная информация
я даже не ожидал что это настолько хороший фильтр отсева. вы ведь даже прочитать вдумчиво не смогли что я написал и вам как раз не нравится ;) еще раз если человек не знает в каком пакете лежит один из самых используемых классов - значит он джаву видит второй раз в жизни. можно в принципе взять стажером за еду, выхлоп будет равноценный.
есть неплохая книжка "универсальные принципы дизайна", в предисловии написано "знать лучше чем догадываться", поэтому есть вещи которые надо знать, надо знать таблицу умножения, электрик должен точно знать когда его может стукнуть токам а не тыкать мультиметром каждый раз, вам лень, я понимаю, но это все сказывается на вашей работе или косвенно указывает на ваши навыки и мотивацию в принципе. По этому это вполне нормальны вопрос, на вшивость. Автора поймали как дешевку :)
если человек не знает в каком пакете лежит один из самых используемых классов - значит он джаву видит второй раз в жизни. можно в принципе взять стажером за еду, выхлоп будет равноценный
Я 10 лет не помню уже сколько лет пишу List и жму Alt+Enter, Идея сама добавляет import из нужного пакета. Я не помню в каком пакете лежит File или List.
По-вашему выходит что я плохой Java-разработчик. Но я смогу отличить java.util.List от another.lib.List и мое незнание не помешает разобраться в этой ситуации. Так насколько хороша такая оценка?
Грамотность определяют сделанные в прошлом проекты
Эти проекты могут на 146% состоять из матерого говнокода. Из того кода, что лично я написал за 17+ лет на работе вряд ли наберется даже 1% такого, что захотелось бы на людях показывать.
Эти проекты могут на 146% состоять из матерого говнокода.
Ну вот пообщаетесь, выясните это.
А как это выяснить, не видя код?
В целом, вообще непонятно. Спросишь по теории - "не имеет отношение к работе". Дашь какое-нибудь практическое задание - "да во чо, я вам студент какой-то, что ли". Гитхаба посмотреть, естественно, нет - "такому мегаспецу как я некогда гитхабом заниматься". Скоро начнут губы дуть просто за то что на собеседовании вообще что-либо спросили. Ведь все такие Дейкстры и Вирты, что от одного факта появления на собеседовании все должны очешуеть, раскатить красную дорожку с позолоченными кистями, и предложить з/п в стопятьсотмильонов в неделю.
Ещё раз, если кандидату нечего показать, пусть не обижается. Ему придётся устроить викторину и литкод истязание, просто потому что больше ничего не остаётся.
Хотя даже в таких случаях можно побеседовать: вот у нас проблема/задача, как будешь ещё решать. Уже в процессе можно понять что с данным пассажиром вам может просто не по пути. Он может и высококвалифицированный и всё такое, но вас просто не устаивает его видение мира по данным вопросам.
Например, практические задания, не предполагающие написание кода с нуля. Мне нравятся два шаблона:
Вот кусок кода, какие проблемы ты в нем видишь, как бы переписал? В идеале - давать пример реального кода перед рефакторингом (кандидат видит с чем работать; узнаем что-то новое о
себеавторе кода), но можно и очищенный пример с парой добавленных "неправильностей".Вот ТЗ из двух строк на метод, какие тесты ты на него напишешь? Можно увидеть не только насколько кандидат думает о граничных случаях и исключениях, но и общий подход к тестам. Конечно, это подходит если тестам на проекте уделяется много внимания
либо кандидат заявляет что хорош в TDD.
А давайте посчитаем сколько раз каждый из нас использовал слово "полиморфизм" в его реальной работе? Типа "вот я сейчас используя полиморфизм реализую эту фичу".
Я начну. Около 15 лет опыта. Ноль раз. Кто больше?
Серьезно, если собеседование начинается с такого, это значит у них нет нормальных вопросов.
Вопросы про названия пакетов тоже радуют в эпоху IDE.
Я хочу быть строителем, а не молотком?! Молодец!
знаю такой тип строителей, вникать не хотят, снипы не знают (лишняя информация), планы и чертежи не читают (и так понятно, по ходу дела резберутся). они хотят просто делать и побыстрее, могут гвоздь гаечным ключем забить, если под руку попадется или рука не в тот ящик полезет (или плашку паркета обычным молотком, а не прорезиненным, и вообще у них инструмента минимум). потом они еще очень обижаются когда им все недостатки показывают, они ведь делали в поте лица, старались как могли, ну а сколы, трещины и кривости - это все не критично, они так всю жизнь делали и никто особо не цеплялся раньше). в общем просто хотеть недостаточно, надо еще кое что знать. иллюзия наличия знания самая большая проблема и авто из этой категории.
я тут мощно задумался - полиморфизм и наследование - в чем разница друг от друга ?
Ага. В чем разница между желтым и квадратным - тут есть о чем задуматься. :)
Одно вообще никак не связано с другим. Но в некоторых языках полиморфизм реализуется с помощью наследования, чтобы обойти механизм статической типизации.
В принципе, на каком-то уровне рассуждений полиморфизм через наследование можно рассматривать как грязный хак. Только не на любом собеседовании такому ответу обрадуются.
Полиморфизм - хак типизации. Полиморфизм через наследование - хак статической типизации. Наследование - хак модульности.
Полиморфизм и наследование - две разные вещи... к тому в терии полиморфизм ьывает разный. Статический и динамический. Перегрузка функций в Си++ это тоже форма полиморфизма
По сути, любой вопрос, на который можно в течение пяти секунд ответить при помощи Google/ChatGPT — плохой вопрос.
Суть статьи и универсальный принцип по отношению к любым вопросам в целом в свете информационной связности и доступности.
Важно знать что делать чтобы решить задачу и это вопрос стратегии, а как делать это уже вопрос тактики. Если ты не умеешь мыслить стратегиями, ты просто компилятор, иначе ты разработчик. Хороший архитектор ИС это достаточно редкий тип разработчика. Большинство это компиляторы, решающие конкретные тактические задачи. Большинство компаний сферы IT похоже ищут в основном компиляторов, среди которых и идёт отбор. Что то не видно вакансий типа требуется архитектор ИС.
Мне кажется, что в таких статьях и комментах под ними происходит столкновение двух концептуально разных подходов к рекрутингу — "нанять на века" vs "легко пришёл, легко ушёл".
Первое родилось в странах, где трудоустройство преимущественно официальное, а испытательные сроки либо не являются частью законодательства, либо реализованы через такую жопу, что работодатель этим заморачиваться не хочет. Например, если в случае увольнения придётся потом профсоюзу доказывать в суде, что это увольнение было обоснованным.
Ну и конкретно в РФ на это наложилось местное восприятие, что если устроился на работу — то не иначе как на ближайшие двадцать лет, а меньшее и планировать не стоит. Да и жаба как-то душит платить зарплату человеку, который может уйти через месяц. А вдруг следующий будет таким же.
В нашей компании технические собеседования обычно больше напоминают обмен кулстори, перемежающийся вопросами типа "а что вы думаете про useCallback?", "писали ли вы генсервер и в каких обстоятельствах это происходило?", или достаточно убойного "опишите, что происходит с запросом, идущим с фронта на бэк".
В последнем вопросе вообще нет правильного ответа, результат меряется на глаз и идёт сразу в несколько показателей, таких как: реакция на абстрактные вопросы, уровень структурированности мышления кандидата, дополнительные познания в смежных сферах, не указанные в резюме :)
Обмен кулстори и мнениями тоже предназначен больше для того, чтобы понять сразу ряд вещей, не всегда связанных напрямую с программированием, но очень сильно влияющих на результат. Типа склонности к изобретению велосипедов, излишней самоуверенности, абсолютного непонимания языка (английского языка, а не программирования), и т.п.
Но! Тут нужно иметь в виду ещё пару штук.
Во-первых, у нас нет предварительного шага в виде девочки, отсеивающей кандидатов тупыми вопросами типа "кем вы себя видите через пять лет". Техническое собеседование — оно же и социальное, если можно так выразиться. А дальше только разговор с менеджментом о зарплате и условиях в компании, если техническое прошёл.
Во-вторых, если человека наняли, но он стабильно не держит планку, то мы с ним расстаёмся. Это не испытательный срок, просто расстаёмся. Насколько быстро — зависит от размеров и частоты возникающих проблем и взаимонепониманий. В ранней истории компании были люди, которые вообще не понимали, где оказались и как работать. Неоднократно просирали сроки в самом начале, требовали ведения за ручку в коде, не отвечали или максимально неправильно для себя отвечали на прямые вопросы начальства, и т.п.
В-третьих, у нас стартап. Поэтому конкретно в нашем случае важнее, чтобы разработчик был способен взять фичу и сделать её от начала и до конца, а для всего остального есть код ревью, на котором всегда можно спросить, а почему у вас вот тут Enum.map() |> Enum.join() вместо Enum.map_join(), а вот тут в эффекте не отменяется запрос, идущий на сервер. Хотя вообще с частью этих проблем и статические анализаторы кода справляются.
В результате такого подхода в данный момент в компании с точки зрения написания кода вот уже пару лет неизменным составом работает несколько фуллстэков и один весьма крутой фронтенд. Но сколько людей при этом отсеялось с основания — не сосчитать :)
Само по себе программирование не есть цель > цель - конечный продукт результата программирования > стало быть нужно искать кратчайший путь к конечному продукту, который предельно упростит процесс создания программного обеспечения > Следовательно требуется инструмент (среда) программировании в которой будет построен и элегантный рабочий код под аппаратную часть архитектуры со всеми сопутствующими возможностями в его дальнейшей импровизации с автором или без него, > такую возможность может предоставить IDE, логическое ядро которой, все в.с. учитывает и вместе с этим она предоставляет быстрый старт, не столько кодерам (компиляторам) сколько алгоритмистам. Все эти причинно следственные зависимости реализованы во многих профильных промышленных и прикладных пакетах ПО, когда абстракция интерфейса разработчика позволяет автоматизировать построение исходного кода в исходный продукт, посредством скрытой кодогенерации и качество конечного продукта зависит от опыта и знаний работы в IDE профильного специалиста - разработчика (инженер - механик, архитектор, стилист, и т.д.) Подводя черту, решите для себя какой конечный продукт в результате программирования Вам интересен > найти IDE (Читать в.с.) и быть разработчиком. Все остальное VS бла-бла-бла между двумя лагерями. Хотите учить языки, учите китайский, хотите стать разработчиком, ищите и осваивайте инструменты разработки. В результате Вы не пишете многостраничный скрипт, часто повторяющийся в других проектах, вместо этого получаете больше времени на обдумывание и оптимизацию алгоритма и не зависите по времени на поиск вывалившегося из Вашей памяти правильного синтаксиса, грамматики написания процедур, поиск и устранение ошибок кода и т.д. и т.п.
Я разработчик, а не компилятор