Comments 1581
Сильно.
Как js разраба раздражает что даже на senior позицию присутствует обязательный вопрос «что такое замыкание?»
Как js разраба раздражает что даже на senior позицию присутствует обязательный вопрос «что такое замыкание?»
И просят реализовать приватную статическую переменную с его помощью.
И все равно 80% заваливаются на данном вопросе.
Я вот как .net разработчик, не так давно начал применять js/ts в разработке. У меня уже был сахар для этого. Я конечно знаю, как это реализовать, но только потому, что сумасшедшие фронтендеры в необъяснимом в восторге от этой реализации, что мне ни раз и показывали. Понимаю ли я, как работают замыкания? Чёрт, да, я отлично это понимаю. Придёт ли мне в голову, что для реализации приватной статической переменной мне понадобиться фигачить самовызывающуюся функцию? Придёт, но не за минуту.
— Чёрт, да, я отлично это понимаю.
К сожалению, хоть вы и понимаете, как работают замыкания, но не поняли их главного назначения — это не «самовызывающиеся функции», это — объекты (функции первого порядка), которые замыкают в себе некоторый контекст, который в зависимости от языка может содержать в себе определенный набор переменных и областей.
То, что вы можете реализовать статическую переменную, опираясь на эти свойства, учитывая при этом все особенности JS/TS/.NET, говорит о вас как о хорошем разработчике, способном видеть архитектурные концепции за простым кодом, что как раз и вызывает восторг у знающих коллег.
И еще — нет, не придется, потому что обычно находятся более элегантные решения, чем использование статических переменных.
К сожалению, хоть вы и понимаете, как работают замыкания, но не поняли их главного назначения — это не «самовызывающиеся функции», это — объекты (функции первого порядка), которые замыкают в себе некоторый контекст, который в зависимости от языка может содержать в себе определенный набор переменных и областей.
То, что вы можете реализовать статическую переменную, опираясь на эти свойства, учитывая при этом все особенности JS/TS/.NET, говорит о вас как о хорошем разработчике, способном видеть архитектурные концепции за простым кодом, что как раз и вызывает восторг у знающих коллег.
И еще — нет, не придется, потому что обычно находятся более элегантные решения, чем использование статических переменных.
Где я сказал, что замыкания — самовызывающиеся функции?
— что для реализации приватной статической переменной мне понадобиться фигачить самовызывающуюся функцию
в этом моменте.
в этом моменте.
Тут я говорю, что самовызывающаяся функция нужна для реализации приватной статической переменной. Я нигде не говорю, что замыкания — это самовызывающиеся функции
Ну если уж пошло за буквоедство, то я тоже нигде не указываю, что это именно вы сказали. Кроме того, что это за термин такой — «самовызывающиеся функции» — что это за зверь? Типо сидишь себе и тут — хряк — откуда ни возьмись — функция вызвалась, сама по себе.
Или это как в квантовой механике — самовызов — функция считается одновременно вызванной и нет до тех пор пока программист не скомпилирует код?
Я конечно, понимаю, .Net имеет свою терминологию, возможно, это что-то из специфического, но ни в руби, ни в пхп, ни в яве, и даже в C# я такого зверя не встречал, будьте добры пояснить за вашу Senior терминологию.
Или это как в квантовой механике — самовызов — функция считается одновременно вызванной и нет до тех пор пока программист не скомпилирует код?
Я конечно, понимаю, .Net имеет свою терминологию, возможно, это что-то из специфического, но ни в руби, ни в пхп, ни в яве, и даже в C# я такого зверя не встречал, будьте добры пояснить за вашу Senior терминологию.
Очевидно, функция которая сама себя вызывает, т.е. рекурсивная ;). (на самом деле, наверное, module pattern)
(function () {
}());
Вообще это называется iife (immediately-invoked function expression) :)
Вызов анонимной функции? И что же тут «самовызывающего», если вы сами ее вызвали, написав () в конце?
Это видимо какой-то особый .net нейминг, с теорией программирования не связанный.
Ну или кто-то сеньор только своей голове, а не в реальности, тут не совсем понятно.
Это видимо какой-то особый .net нейминг, с теорией программирования не связанный.
Ну или кто-то сеньор только своей голове, а не в реальности, тут не совсем понятно.
Это не ".net нейминг", а устоявшийся перевод термина IIFE (immediately-invoked function expression).
Гугл транслейт почему-то переводит это как «немедленно вызываемые», что куда ближе к правде, чем «самовызываемые» (self-invoked).
Ирония всего происходящего в том, что самозванец, называющий себя «Senior full stack developer», кричит о том, что «хватит подозревать разрабов в самозванстве».
Для меня это звучит как «Платите мне сеньорские за знания слабого миддла». Это просто смешно.
Ирония всего происходящего в том, что самозванец, называющий себя «Senior full stack developer», кричит о том, что «хватит подозревать разрабов в самозванстве».
Для меня это звучит как «Платите мне сеньорские за знания слабого миддла». Это просто смешно.
Гугл, самовызывающаяся функция, About 1,600 results.
По ссылкам реальные люди говорят это реальное, может быть сленговое, название. Или, типа, редкий сленг = самозванец?
По ссылкам реальные люди говорят это реальное, может быть сленговое, название. Или, типа, редкий сленг = самозванец?
Гугл, «немедленно вызываемая функция javascript» — 30 тысяч результатов. Может у вас есть еще вопросы к гуглу?
И что это доказывает? Вы утверждали что так никто не говорит, я показал что так говорят. Про то что более популярно а что более правильно разговора не было, я в этом вашем js ни в зуб ногой и такие разговоры вести не компетентен.
Это показывает, что даже академический термин в разы популярней вашего терминологического изобретения. И я не удивлен, что в интернете нашлось еще полторы тысячи человек, использующих слова, сути которых они не понимают.
Кстати, если изучите кто пользуется этим термином, поймете, что среди них не так уж много профессионалов, что говорит о том, в каких кругах это слово распространено.
Кстати, если изучите кто пользуется этим термином, поймете, что среди них не так уж много профессионалов, что говорит о том, в каких кругах это слово распространено.
2018 год, а многие всё ещё верят выхлопу гуглтранслейта. Чтобы не быть голословным: по partitioning нет ни правильного «секционирование», ни «партиционирования» от людей не знакомых с теорией.
Соглашусь, что «немедленно вызываемые» передают суть, а «самовызываемые» намекают на непонимание происходящего в коде.
Я предлагаю отныне их называть «функции-самозванцы» ибо это короче чем «самовызываемые», так же неправильно и позволяет закольцевать тему в мире метафор.
Похоже, я мешаю вам лупить вооброжаемого противника)
понадобитЬся… типичная гиковская грамотность, увы. Только об этом шла речь.
Конечно. Вот я не понял даже смысла этой просьбы. Что такое, вообще, «статическая переменная»? Это что-то из Си?
UFO just landed and posted this here
В Си (и в плюсах) слово static означает три разные вещи — внутри функции, внутри структуры/класса, и на внешнем уровне. Какой из этих трёх смыслов вкладывается в понятие «статической переменной»?
imho, все-таки есть минимально необходимый уровень знаний матчасти. Математик может не использовать таблицу умножения, занимаясь тензорной математикой, но ответить сколько будет 2*2, кмк обязан.
Все мы люди и модет на небольшое время "забыть" от волнений или по другим причинам даже 2*2. Думаю почти все сталкивались когда понимаешь о чем речь, но слова забываются.
Не должно такого быть. Если тот же математик что-то забывает, то он должен уметь это вывести. А если он забывает аксиоматику, то какой он тогда математик? Я в лекциях Савватеева наблюдал момент, когда по ходу лекции он забыл формулу нахождения корней квадратного уравнения (а это д.ф.-м.н. между прочим). Он слегка смутился, но тут же ее вывел и доказал.
оно не должно случатся, но а если случается в этом нет ничего страшного.
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
Для предотвращения подобных ситуаций, хорошо бы чтобы наймом сотрудников занималась сторонняя HR компания имеющая при этом штат технических специалистов, которые будут проводить беспристрастную оценку уровня знаний соискателя… Но видимо это пока только мечты(
Зачем вообще об этом мечтать? Люди не роботы, и человек может что-то знать, но совершенно не подходить под конкретную команду и\или проект. Собеседование это не экзамен и не соревнования по вольной борьбе, это поиск подходящего человека в команду. Если в команде все используют наследование и много виртуальных методов, а человек не помнит это слово и возможно (как он и сам признался) не любит наследование и избегает его, то зачем его брать в команду? Тут же конфликт подходов на лицо, будет борьба за неформальное лидерство и постоянные конфликты на этой почве. Потом кто-то да уволится.
Отчасти согласен, но иногда в команду требуется лид, который априори должен быть сильнее всех имеющихся членов команды (иногда даже вместе взятых), и естественно в большинстве случаев, команда не утвердит никого из действительно подходящих кандидатур, в особенности если команда на основную массу состоит из говнокодеров… как быть тогда, видимо извечный вопрос…
Было дело, я работал над проектом, писал бек на шарпе, а нужен был фронт на пхп, да с общением с WCF да через https. Тот человек что писал фронт, особой прытью не обладал, да и сайт был простой, он проблему решить не мог, я поискал готовые решения — их не оказалось. Вроде как все есть — но либа не работает, и нужно было найти хорошего ПХПшника, допилить либу. Приходилось собеседовать по сути обладая знаниями джуна в пхп, сина. Я так и спрашивал в конце собеседования — как решить эту задачу, каждый бил себя в грудь и говорил — да элементарно! Ни чего сложного! По началу я злился, начал думать что они все самозванцы… Но проблему нужно решать и человека искать… Начала давать час на раздумья. Если через час я слышал все то-же «да это элементарно» и ни какой конкретики — то прощался.
Такие компании к сожалению только добавляют гемора всем, в Новосибирске есть такое агнество, так вот два раза попробовал с ними работать, и чет как то стороной теперь подобные конторы обхожу, у них задача продать разработчика компании.
А решается это все просто, нужно чтобы собеседование проводили или несколько людей с разных проектов, или несколько технических интервью, тогда будет более менее честная оценка
А решается это все просто, нужно чтобы собеседование проводили или несколько людей с разных проектов, или несколько технических интервью, тогда будет более менее честная оценка
HR-специалисты зачастую и не особо понимают чем занимается компания и какие работники нужны. Это при том, что сам отдел находятся «внутри», а работники за соседней дверью. А с вашим предложением вообще полный атас будет. Да и подобные идеи уже давно реализованы кадровыми агентствами, чья функция свелась к простому «иди туда-то и спроси того-то».
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
И в некоторых случаях будет прав.
Два раза натыкался на проблемы при найме сотрудников на наукоемкие позиции. Приняли сотрудника, а потом от него постоянные (обоснованные!) жалобы на неграмотную постановку задач и на то, что его никто не понимает (и это тоже правда). А у других сотрудников — мысли «а этот человек вообще занимается чем-то полезным?». Т.е. не могут отличить от самозванца.
Если берешь overqualified специалиста, обязательно вдобавок к тому, что написано в вакансии, проверяй преподавательские навыки и думай, как будешь проверять и оценивать его работу. Если не можешь проверить и нет денег на одновременный найм двух кандидатов — вакансия невалидна.
должно ли случаТСя, что программисты, кроме 100500 языков и технологий выучат, наконец, родной язык?
Немного про волнение: то на экзамене в вузе, преподаватель по терверу понял мою ошибку, когда я ее еще не осознавал. Задавал много наводящих вопросов, и в конце концов попросил меня нарисовать на оси две точки 1 и 1,5. Посмотрев на мой рисунок, он сказал: «вы знаете мой предмет на отлично, но впредь, чтобы вы знали, что 1,5 больше 1, я поставлю вам четверку без права пересдачи» и выставил меня в коридор.
O_o, нифига себе. У меня было похожее, только на экзамене по цифровой обработке сигналов.
Преподаватель видела, что я в принципе разбирался в теме, но переволновался. Попросила нарисовать какой-то график, нарисовал. Спросила, что больше: 1/4 или 1/2(1/4 у меня было больше). Тут до меня дошло, она посмеялась и поставила 4))
Преподаватель видела, что я в принципе разбирался в теме, но переволновался. Попросила нарисовать какой-то график, нарисовал. Спросила, что больше: 1/4 или 1/2(1/4 у меня было больше). Тут до меня дошло, она посмеялась и поставила 4))
Таких преподов обычно ненавидят. И правильно делаю, учитель должен мотивировать ученика, а не наоборот.
А разве он его не мотивировал? Он признал, что ученик действительно с мозгами и шарит в предмете. Признание это и есть уважение. Какая хрен разница какая оценка? Если бы ученику нужен был бы красный диплом, он бы сказал «Ставьте два. Буду пересдавать» и проблемы в этом нет. Препод все сделал грамотно!
Смотивировал? Чувака который знал его предмет на отлично поставил четыре без права пересдачи? На что он его смотивировал, из окна выйти? Это, вполне, если чувак интроверт, шел на красный диплом и т.п
Нет понятия «Без права пересдачи». Вот ни одного случая не припомню, когда человеку реально запретили пересдавать. Вот ни одного! Чтобы не говорил преподаватель и какой бы ядовитой слюной он не брызгал, но пересдача будет, если студент этого хочет. Просто надо сидеть не в позе «Мне препод запретил, значит дело труба». А надо поднимать мягкое место и пробовать другие способы решения проблемы «Начну с похода к декану, может он поможет, а потом буду думать, что дальше».
На отлично человек не знал.
Отлично — это знание, ставшее отсутствием ошибок. Причём неважны причины тут… хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Без ошибок.
Если мне на заводе инженер напортачит, я что — буду смотреть на то, что он в принципе всё знает?..
Тут экзаменатор как раз поступил очень корректно.
Отлично — это знание, ставшее отсутствием ошибок. Причём неважны причины тут… хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Без ошибок.
Если мне на заводе инженер напортачит, я что — буду смотреть на то, что он в принципе всё знает?..
Тут экзаменатор как раз поступил очень корректно.
хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Здесь ничего не смущает?
Ничего тут нет противоречащего. Потому что это уже организационный вопрос.
Я сам находился в таком качестве (причём и на месте сдающего, и принимающего).
Экзаменатор формирует очередь пересдачи (самому себе, как правило), и не хочет туда включать сдающего. Он уже оценил его уровень, и оценивает на 4-е (и я его понимаю). Сдающий понимает, знает предмет, но допускает ошибки, и довольно глупые. Успеет ли он до пересдачи справится с причинами, приведшими к ошибке? Не знаю, тут уже рядом сидеть нужно. Но там ещё за тобой народ, потому здесь и сейчас — 4-ка.
Уровень, условия включения на пересдачу «спускаются свыше». Деканатом, как правило. И эта очередь да, зависит от оценки. Ибо только её обычно и видит деканат в реестре. Если 4-шников включать в списки на пересдачу, будет уже беседа деканата с экзаменатором. С какого ты его на пересдачу-то?! У него же «хорошо».
Ибо время экзаменатора — принадлежит не ему.
Он должен обосновать требование пересдачи перед контролирующим органом (деканатом).
Но ученик может возразить.
Это его право.
Как правило, экзаменатор на требование «да не нужна мне 4-ка без пересдачи!» пожимает плечами, и ставит оценку, которая автоматом направляет на пересдачу (там, где я учился, хотя бы 3-ка нужна, чтобы не разбираться потом с деканатом).
Никаких проблем в 99,9999% случаев.
Потому что эта оценка до пересдачи уже ничего не значит.
Подготовишься на отлично — получишь отлично.
Я сам находился в таком качестве (причём и на месте сдающего, и принимающего).
Экзаменатор формирует очередь пересдачи (самому себе, как правило), и не хочет туда включать сдающего. Он уже оценил его уровень, и оценивает на 4-е (и я его понимаю). Сдающий понимает, знает предмет, но допускает ошибки, и довольно глупые. Успеет ли он до пересдачи справится с причинами, приведшими к ошибке? Не знаю, тут уже рядом сидеть нужно. Но там ещё за тобой народ, потому здесь и сейчас — 4-ка.
Уровень, условия включения на пересдачу «спускаются свыше». Деканатом, как правило. И эта очередь да, зависит от оценки. Ибо только её обычно и видит деканат в реестре. Если 4-шников включать в списки на пересдачу, будет уже беседа деканата с экзаменатором. С какого ты его на пересдачу-то?! У него же «хорошо».
Ибо время экзаменатора — принадлежит не ему.
Он должен обосновать требование пересдачи перед контролирующим органом (деканатом).
Но ученик может возразить.
Это его право.
Как правило, экзаменатор на требование «да не нужна мне 4-ка без пересдачи!» пожимает плечами, и ставит оценку, которая автоматом направляет на пересдачу (там, где я учился, хотя бы 3-ка нужна, чтобы не разбираться потом с деканатом).
Никаких проблем в 99,9999% случаев.
Потому что эта оценка до пересдачи уже ничего не значит.
Подготовишься на отлично — получишь отлично.
Сейчас есть такая штука, как ФЗ «Об образовании в Российской Федерации». Они подзаконные акты чётко говорят, что в случае «неуд'а» в течении календарного года есть право 2 раза пересдать экзамен. При этом финальная пересдача предполагает сдавать уже комиссии. Если оценка выше, то тут для пересдачи необходимо согласие преподавателя. В случае, когда он упрётся и не захочет принимать, то только тогда в дело может вступить зав.каф. или декан, чтобы или назначить другого, более лояльного преподавателя (ну или чтобы принять пересдачу самому). НО! Преподаватель формально может и не отказываться от пересдачи, чтобы собственноручно «похоронить» надежды студента на «отлично» в стиле: «я же говорил, что выше 4 ты не получишь». Хотя такое встречается реже.
Вы тоже из тех, у кого на отлично знает бог а на 4 препод? Или из тех, у которых железные нервы, а потому и у всех остальных должно быть?
Люди ошибаются, всегда и постоянно, и ничего ты с этим не поделаешь.
Люди ошибаются, всегда и постоянно, и ничего ты с этим не поделаешь.
Если мне на заводе инженер напортачит
Если у вас на заводе инженера работают в постоянном стрессе сравнимым с экзаменами в ВУЗе, то у меня плохие новости для вашего бизнеса)
Экзамены в ВУЗ-е вы считаете стрессом по сравнению с работой?!
Мило. За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал. Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен.
Собственно, именно потому за неё платят деньги.
За свой экзамен (его можно сравнить скорее с интеллектуальным удовольствием) — платите вы.
Мило. За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал. Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен.
Собственно, именно потому за неё платят деньги.
За свой экзамен (его можно сравнить скорее с интеллектуальным удовольствием) — платите вы.
Работа работе рознь. Вам платят за устойчивость к стрессам. Кто-то (я в том числе) предпочитает получать деньги за квалифицированное решение задач бизнеса в комфортных условиях.
А у меня наоборот. Тоже много лет опыта, несколько стран (> двух), несколько компаний, разные сферы бизнеса и т.д. и т.п… Везде работа была комфортной и не стрессовой, хоть иногда и весьма интеллектуально сложной.
За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал.
А у меня наоборот. Тоже много лет опыта, несколько стран (> двух), несколько компаний, разные сферы бизнеса и т.д. и т.п… Везде работа была комфортной и не стрессовой, хоть иногда и весьма интеллектуально сложной.
Я не говорил, что платят за стресс.
Я писал о требовании психологической устойчивости. Это сильно разные понятия.
Психологическая устойчивость — это готовность успешно справляться со стрессом, но не сам он.
Меня вообще удивляют эти высказывания, что на экзамене — стресс. Я к своим экзаменам в университете даже не готовился ни разу! И закончил с красным дипломом, кстати. Если вы учитесь, не спустя рукава, и учёба вам в радость, то экзамен — это просто один из способов пообщаться с экзаменатором, продемонстрировав ему (подтвердить) свои знания.
Что тут стрессового?
Я, конечно, понимаю, что может мне так повезло с университетом, но может, как раз если для вас экзамен — стресс, то вы не там, или не на того учитесь?..
А последующая работа — это уже ответственность.
И не перед собой, и вашей дальнейшей судьбой (не нужно переоценивать свою персону), а уже перед другими и за других.
Которой нет, не должно быть на экзамене.
Инженеры, которые у меня работают — отвечают за бизнес, большие деньги. Некоторые — за безопасность других людей.
Сравнивать это с экзаменом, где решается только твоя судьба (причём с возможностью пересдачи) — неадекватно, имхо.
Я писал о требовании психологической устойчивости. Это сильно разные понятия.
Психологическая устойчивость — это готовность успешно справляться со стрессом, но не сам он.
Меня вообще удивляют эти высказывания, что на экзамене — стресс. Я к своим экзаменам в университете даже не готовился ни разу! И закончил с красным дипломом, кстати. Если вы учитесь, не спустя рукава, и учёба вам в радость, то экзамен — это просто один из способов пообщаться с экзаменатором, продемонстрировав ему (подтвердить) свои знания.
Что тут стрессового?
Я, конечно, понимаю, что может мне так повезло с университетом, но может, как раз если для вас экзамен — стресс, то вы не там, или не на того учитесь?..
А последующая работа — это уже ответственность.
И не перед собой, и вашей дальнейшей судьбой (не нужно переоценивать свою персону), а уже перед другими и за других.
Которой нет, не должно быть на экзамене.
Инженеры, которые у меня работают — отвечают за бизнес, большие деньги. Некоторые — за безопасность других людей.
Сравнивать это с экзаменом, где решается только твоя судьба (причём с возможностью пересдачи) — неадекватно, имхо.
Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен
Интересно, кем же вы работаете?)
Я инженер-программист, мне моя работа приносить удовлетворение и не только материальное, а часто даже радость, когда получается красиво решить задачу. И уж конечно не приносит стресс.
Я просто уверен, что инженер в состоянии стресса, кроме костыля ничего не может придумать. И вообще, в моей профессии если ты довел дело до стресса (в большинстве случаев это банальный срыв сроков), то ты свою работу делаешь плохо.
Я выше написал подробнее.
Я писал, ещё раз, о требовании психологической устойчивости, требуемое в работе в степени, несравнимой с такой простой вещью — как экзамен (если вы учитесь нормально, конечно).
Я тоже раньше был программистом, теперь архитектор, и руководитель проектов, но область в принципе понимаю.
Моя работа не стрессовая, но иногда, изредка — бывает такой.
И требования к психологической устойчивости (не сам стресс, но готовность справится с оным) тут определяет несравненно большее, чем то, что решается на экзамене.
Я писал, ещё раз, о требовании психологической устойчивости, требуемое в работе в степени, несравнимой с такой простой вещью — как экзамен (если вы учитесь нормально, конечно).
Я тоже раньше был программистом, теперь архитектор, и руководитель проектов, но область в принципе понимаю.
Моя работа не стрессовая, но иногда, изредка — бывает такой.
И требования к психологической устойчивости (не сам стресс, но готовность справится с оным) тут определяет несравненно большее, чем то, что решается на экзамене.
Если брать ИТ сектор, то большинство вообще не испытывает стресса от работы, даже от срыва сроков. Даже шутка есть. Большинство проектов заканчиваются провалом. Большинство проектов превышает сроки и бюджет. Всегда остаются баги, которые находит клиент. После 5 лет в индустрии это понимает почти каждый и парится перестает совершенно.
На рабочих профессиях — все еще проще в плане отношения к результатам труда. Даже врачи в массе не переживают о качестве своего лечения и размере «персонального кладбища», конечно хорошие врачи — переживают.
Но если брать обобщение — то человек переживает в ключевых точках. Например в точке оценивания, как-то прием на работу или экзамен, или ожидание отзывы с прошлой работы. А между этих точек — фаза расслабления, «меня уже взяли, можно и расслабится».
Так-что вы не правы. Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целом. А речь идет о людях, которым диплом важен, и оценка важна, они верят что это повлияет на их последующую жизнь. И стресс от экзамена — выше стресса от первого собеседования на очень желанную работу. Ведь работу можно и другую найти, а экзамен он один.
На рабочих профессиях — все еще проще в плане отношения к результатам труда. Даже врачи в массе не переживают о качестве своего лечения и размере «персонального кладбища», конечно хорошие врачи — переживают.
Но если брать обобщение — то человек переживает в ключевых точках. Например в точке оценивания, как-то прием на работу или экзамен, или ожидание отзывы с прошлой работы. А между этих точек — фаза расслабления, «меня уже взяли, можно и расслабится».
Так-что вы не правы. Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целом. А речь идет о людях, которым диплом важен, и оценка важна, они верят что это повлияет на их последующую жизнь. И стресс от экзамена — выше стресса от первого собеседования на очень желанную работу. Ведь работу можно и другую найти, а экзамен он один.
Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целомЯ не придавал в обучении важности оценкам, это так. Хотя по результатам обучения и был в череде лучших потока.
А после, некоторое время будучи преподавателем, понял окончательно, что оценка — это больше для учителя, а не ученика.
Не нужно путать, смешивать результат обучения, и его формализованную оценку.
Мне вообще, судя по обсуждению, как-то повезло, для меня университет был одной большой радостью, безо всякой примеси даже возможности стресса.
Последующая работа у меня также — не стресс (ну, изредка, но бывает и такое).
А всего лишь постоянная готовность к оному.
Ответственность. Перед другими, и за других.
Которой неоткуда взяться на экзамене, где ты — только сам за себя (если не считать третьими лицами родных, которым это тоже важно).
И тогда возникает закономерный вопрос — может, если для тех, у кого учёба (или экзамен) была стрессом — может у них как раз что-то неправильно было?..
За других говорить не могу, лишь за себя. Учеба мне была в кайф и работа то-же, как и вам. При этом стрессы бывали и в учебе и на работе, и готовность к ним так-же есть. Стресс и радость не противоречат друг другу, скорее даже они почти всегда ходят рядом с друг другом. Там где нет и намека на стресс обычно, все безразлично, возникает скука, и ни какой радости.
Относительно ответственности — все то-же самое и в университете. Если провалишь универ, то не найдешь хорошую работу, не сможешь обеспечить будущих детей, и вся жизнь пойдет под откос и по пути «неудачников», коих вокруг полно и среди молодых и среди взрослых.
Тут скорее вопрос исключительно в моменте перехода от «беззаботного детства» к «ответственному взрослению». У вас этот переход случился на работе, на работе вы стали ощущать ответственность перед другими и за других. У меня он случился около 8го класса и я ходил и испытывал постоянный стресс от кучи негативных вариантов исходов моей жизни, думал о том кем я хочу быть, кем работать, и как при этом обеспечить будущую семью, и где жить, и стоит ли мигрировать или нет. Другими словами — нас (людей) напрягают ВОЗМОЖНЫЕ факапы (та самая готовность к стрессу). Но начинают они нас напрягать внезапно, в какой-то момент жизни. После этого момента, ты начинаешь «парится за все». И чем меньше остается «возможностей обосраться», тем меньше этих переживаний. Т.е. окончив нормально универ — перестаешь переживать что ты дебил. Женивщись — что ты не женишься. Родив детей — что забудешь их родить. И стресс с возрастом снижается, т.к. цена ошибки падает. В юношестве мне казалось что провалив первую сессию, я не смогу получить красный диплом, и моя жизни станет в 5 раз сложнее и не предсказуемей. Сейчас мне кажется что в случае провала проекта, я через неделю найду новую работу.
Ну или вы просто ощущали себя в безопасности от «плохого диплома». И такое бывает, например родители гарантируют помощь. Или есть примеры саксес стори с плохим дипломом, которые есть силы повторить. У меня не было ни того, ни другого.
Относительно ответственности — все то-же самое и в университете. Если провалишь универ, то не найдешь хорошую работу, не сможешь обеспечить будущих детей, и вся жизнь пойдет под откос и по пути «неудачников», коих вокруг полно и среди молодых и среди взрослых.
Тут скорее вопрос исключительно в моменте перехода от «беззаботного детства» к «ответственному взрослению». У вас этот переход случился на работе, на работе вы стали ощущать ответственность перед другими и за других. У меня он случился около 8го класса и я ходил и испытывал постоянный стресс от кучи негативных вариантов исходов моей жизни, думал о том кем я хочу быть, кем работать, и как при этом обеспечить будущую семью, и где жить, и стоит ли мигрировать или нет. Другими словами — нас (людей) напрягают ВОЗМОЖНЫЕ факапы (та самая готовность к стрессу). Но начинают они нас напрягать внезапно, в какой-то момент жизни. После этого момента, ты начинаешь «парится за все». И чем меньше остается «возможностей обосраться», тем меньше этих переживаний. Т.е. окончив нормально универ — перестаешь переживать что ты дебил. Женивщись — что ты не женишься. Родив детей — что забудешь их родить. И стресс с возрастом снижается, т.к. цена ошибки падает. В юношестве мне казалось что провалив первую сессию, я не смогу получить красный диплом, и моя жизни станет в 5 раз сложнее и не предсказуемей. Сейчас мне кажется что в случае провала проекта, я через неделю найду новую работу.
Ну или вы просто ощущали себя в безопасности от «плохого диплома». И такое бывает, например родители гарантируют помощь. Или есть примеры саксес стори с плохим дипломом, которые есть силы повторить. У меня не было ни того, ни другого.
UFO just landed and posted this here
А я понимаю и вас, и u010602 — у меня страхи были один-в-один, и, как ни странно, именно на них я и выехал в «люди», не спился, не с курился (всякими веществами). Мои же страхи дали мне силы осваивать абсолютно не знакомые мне области.
Уже позже это и переросло в «не люби себя таким, какой есть — сегодня лучше чем вчера, завтра лучше, чем сегодня».
Но и вас я так же прекрасно понимаю — у людей опыт разный (и это хорошо ведь).
Уже позже это и переросло в «не люби себя таким, какой есть — сегодня лучше чем вчера, завтра лучше, чем сегодня».
Но и вас я так же прекрасно понимаю — у людей опыт разный (и это хорошо ведь).
Экзамены в ВУЗ-е вы считаете стрессом по сравнению с работой?!Это достаточно известный факт между прочим. Экзамены и собеседования — типовой сценарий в исследованиях поведения человека в стрессовой ситуации, это наиболее известные, легко воспроизводимые и универсальные ситуации. Ключевое слово здесь — универсальные. Практически для любого человека экзамен — сильный стресс. Если лично для вас не так — значит вы либо сильно выделяетесь, что конечно возможно и я искренне за вас рад, либо не осознаете до конца что такое стресс. Я могу попытаться найти исследования на эту тему если интересно.
Знание «на отлично» предполагает отсутствие ошибок, тем более детских. А именно такая была насколько я понял, про вероятность равной 1,5.
Не очень верная аналогия, но если в боксёрском поединке спортсмен А победил спортсмена Б, то это означает, что спортсмен Б слабее. Даже если на тренировках он показывал отличные результаты и был всеобщим фаворитом.
Не очень верная аналогия, но если в боксёрском поединке спортсмен А победил спортсмена Б, то это означает, что спортсмен Б слабее. Даже если на тренировках он показывал отличные результаты и был всеобщим фаворитом.
Вот именно что неверная аналогия. Мы не про спорт, а про будущих инженеров. А им не обязательно в стрессовой ситуации рассказывать наизусть таблицу умножения. А то что человек знал предмет на отлично, прямо следует из обсуждаемого поста.
Давайте приведу другую. Выходит ученик рассказывать стишок и ни слова не произносит. Получает двойку. Приходят родители, мол как же так, дома он отлично рассказывал. Вполне вероятно, но что из этого следует? Что знание ученика настолько непрочное, что исчезает вне «тепличных условий», когда это знание нужно применить он не может этого сделать.
По мне реальная работа это бОльший стресс и напряжение нежели экзамен. И если даже на экзамене в голове пусто, образно говоря, то уж извините.
Да и знание таблицы умножения это не зубрёжка, а элементарные навыки счёта. В пределах 100, замечу. По мне странно, что то, что наши дедушки-бабушки-родители знали и успешно учили в 7 лет, вдруг оказывается недоступно выпускнику вуза (ну не верю я в истории про гениальных математиков/инженеров/программистов, которые не могут умножить 5 на 5).
Конкретно в этом случае… если на самом деле так сказал, мог быть 5 поставить, с минусом) Или другое задание дать.
По мне реальная работа это бОльший стресс и напряжение нежели экзамен. И если даже на экзамене в голове пусто, образно говоря, то уж извините.
Да и знание таблицы умножения это не зубрёжка, а элементарные навыки счёта. В пределах 100, замечу. По мне странно, что то, что наши дедушки-бабушки-родители знали и успешно учили в 7 лет, вдруг оказывается недоступно выпускнику вуза (ну не верю я в истории про гениальных математиков/инженеров/программистов, которые не могут умножить 5 на 5).
Конкретно в этом случае… если на самом деле так сказал, мог быть 5 поставить, с минусом) Или другое задание дать.
UFO just landed and posted this here
Ну он походу неправильно решил задачу. То есть "все ок но такая обидная ошибка, заказчик рвет и мечет в итоге тт, ну сам понимаешь в таких условиях — никакой премии".
А навыки переговоров у чувака есть? Навык «Уметь дать сдачи» всегда был полезным!
Если ко мне так руководитель подойдет, то уверяю, что у него возникнет желание извиниться передо мною.
Если ко мне так руководитель подойдет, то уверяю, что у него возникнет желание извиниться передо мною.
А почему вы думаете, что навык переговоров исключительно приобретенный и не зависит от врожденных возможностей? Некоторым так-же сложно вести переговоры, как другим решать матан. Размышлять в стиле «вот слабак! я бы на его месте зарешал!» не продуктивно. Люди все разные, у всех есть слабости, не все слабости можно превозмочь, не все навыки можно приобрести. Некоторые навыки так-же сложно приобрести — как подрасти на 10 см усилием воли. И мы(как человечество) хотим создать условия комфортные для большинства, а не только для бетменов, что-бы каждый человек, не смотря на свои недостатки, могу раскрыть свои сильные стороны. Задачи выведения супер-солдата без недостатков — не стоит. Попытки были — можете почитать, чем они закончились.
А почему вы думаете, что навык переговоров исключительно приобретенный и не зависит от врожденных возможностей?
Я ни слова не сказал о том, переговорный навык приобретенный или врожденный. Не надо говорить то, чего нет в словах других людей. ОК?
Да. Люди разные. Но мир такой какой он есть и надо либо играть по его правилам, либо сам виноват! Мы же не приходим в футбол и не говорим «А я вот хочу клюшкой играть».
Мне тоже, если что, даются переговоры в чем-либо и с кем-либо и как следствие из-за этого прокрастинурую над задачами, где надо переговорить. Но! Абсолютно не важно что у меня это врожденное или не своейственное мне иногда надо просто взять и сделать! И точка!
Иногда да, а иногда можно пойти и сделать хоккей с клюшкой. Итого, кто будет насмехаться над новым, не таким как все и тд — будут называть шовинистом. Современный мир борется с шовинизмом и пытается снизить важность навыка социализации. Сделать общение эмоционально проще и доступнее для некоторых людей. Вы же оправдываете преподавателя в стиле «молодец! проучил, показал что мир жестокое место!» А вы не думаете, может готовя детей к жестокости мира, мы делаем мир более жестоким, чем он может быть? Т.е. где грань между подготовкой, и созданием обиды на всю жизнь, которую потом человек будет выражать в агрессию над следующим поколением? Как с дедовщиной — есть части где она есть, а есть части где ее нет. И когда она есть, новый призыв пройдя через унижения, решает что потом они должны вернуть баланс, и унизить следующих. И это затягивает. Такие циклы бывают как продуктивные, так и нет. Уверен преподавателя то-же так кто-то проучил, и он решил нести это дальше в массы. Но насколько он успешен что-бы нести свои психоустановки в массы? Кто дал ему право, не только учить, но и воспитывать? Проф пригоден ли он для этого?
Мое мнение — нет. Воспитанием должны заниматься одни, а обучением — другие.
Мое мнение — нет. Воспитанием должны заниматься одни, а обучением — другие.
UFO just landed and posted this here
А причем тут хамство?
Есть 2 типа руководителей:
1. Мудак. Который считает, что раз он\она начальник, то все должны слушаться и такие люди как правило живут по принципу «Есть мое мнение и неправильное». Но тут уже к работнику вопрос, нахера он себя так низко ценит работая под таким руководством
2. Адекватный. Это человек знающий что нужно бизнесу и как решаются задачи. Этот человек действует профессионально и свое мнение учитывает исключительно в рамках рабочего процесса.
С первым типом я не работаю. Сразу ищу другого работодателю. А второму всегда можно пояснить какую пользу приносишь. Что сделано. Что делается. Как делается и как эффективно делается. Поясняется, что нихера непонравилось то что руководитель допустил по отношению ко мне.
Адекватный всегда поймет что к чему и извинится. Более того он подобной ситуации посторается недопустить. Максимумум что от таких людей можно услышать «Ты допустил ошибку. Она влечет за собою… Это выражается в потерю… рублей и возможностей… ». Если подобное слышишь в свой адрес, то обижаться не стоит. Не продуктивно
Есть 2 типа руководителей:
1. Мудак. Который считает, что раз он\она начальник, то все должны слушаться и такие люди как правило живут по принципу «Есть мое мнение и неправильное». Но тут уже к работнику вопрос, нахера он себя так низко ценит работая под таким руководством
2. Адекватный. Это человек знающий что нужно бизнесу и как решаются задачи. Этот человек действует профессионально и свое мнение учитывает исключительно в рамках рабочего процесса.
С первым типом я не работаю. Сразу ищу другого работодателю. А второму всегда можно пояснить какую пользу приносишь. Что сделано. Что делается. Как делается и как эффективно делается. Поясняется, что нихера непонравилось то что руководитель допустил по отношению ко мне.
Адекватный всегда поймет что к чему и извинится. Более того он подобной ситуации посторается недопустить. Максимумум что от таких людей можно услышать «Ты допустил ошибку. Она влечет за собою… Это выражается в потерю… рублей и возможностей… ». Если подобное слышишь в свой адрес, то обижаться не стоит. Не продуктивно
UFO just landed and posted this here
Но надо учитывать, что есть ещё 10 промеждуточных стадий между м** и адекватным. А также принимать во внимание, что и адекватные иногда встатют не с той ноги, а м**** «по жинзи» может оказаться компетентным в конкретном вопросе по собиранию бычков и подробно объяснить свою позицию.
Если ошибка человека вылилась в потери и тд — то начальнику стоит бить себя в лоб. Ибо выстраивание процессов так, чтобы ошибка одного человека не рушила бизнес — его прямая обязанность.
четверку без права пересдачи»
Если бы ученику нужен был бы красный диплом, он бы сказал «Ставьте два. Буду пересдавать»
?!
Вроде, только в МедВУЗе невозможно получить Красный Диплом имея хоть одну пятёрку.
Кроме того, студент идущий на красный диплом, где-то на пятом курсе, может пересдать несколько предметов улучшив по ним оценки.
За что ненавидить? Глупые обиды какие-то.
Преподаватели разными способами (наводящими вопросами и др.) подсказывает, но так получилось что это не помогло. В результате человек получил 4, но навсегда запомнил.
В системе тестирования или у другого преподавателя, нет решения = нет положительного результата, на пересдачу. Так лучше?
Да лучше, или 2 или 5. 4 это унизительно, я бы психанул.
Вспоминается история с израильским F-16 перевернувшимся при полёте над Мёртвым морем из-за того, что высота стала отрицательной.
Должно быть, писавший эту авионику тоже психовал, из-за распухшего ЧСВ, когда ему указывали на совершённые ошибки.
Должно быть, писавший эту авионику тоже психовал, из-за распухшего ЧСВ, когда ему указывали на совершённые ошибки.
Я бы психанул не из-за ошибки, ошибки нужно исправлять. Здесь же в истории было явное наказание «без права пересдачи». Вопрос в стиле «что мне теперь ставить вам 4?» вызвал бы у меня достаточно стресса, что-бы я это запомнил на всю жизнь. Я считаю поступок преподавателя — чрезмерно жестоким.
А относительно ЧСВ и Ф-16 — если система создания ПО уязвима к ЧСП одного из членов команды — то она явно подобрана не правильно. Там где от софта зависят жизни людей — там человеческий фактор должен быть сведен к минимуму.
А относительно ЧСВ и Ф-16 — если система создания ПО уязвима к ЧСП одного из членов команды — то она явно подобрана не правильно. Там где от софта зависят жизни людей — там человеческий фактор должен быть сведен к минимуму.
Программисты не пишут авионику в одно лицо… Хотя я недолго в этой сфере проработал, но у нас шансов налажать практически не было. Программисты всего лишь реализовывали логику, очень подробно описанную инженерами, причем все разбито на мелкие модули. А потом другие люди покрывали каждый модуль юнит-тестами на 100%. В таком проекте один псих ничего не поломает.
Так никакой проблемы — просишь 2 и на пересдачу. Или потом требуешь пересдачи у другого/комиссии.
Тут другое — человек не знал на твердую 5, а зыбкая 5 из рук ускользнула.
Тут другое — человек не знал на твердую 5, а зыбкая 5 из рук ускользнула.
Оценка — это мера знаний ученика, а не понтов преподавателя. Если препод уверен, что его ученик знает предмет на отлично, он должен ставить отлично. Что дала эта четверка ученику? Он на всю жизнь запомнил что 2*2=4, он это и так знал. Что у другого преподавателя из-за особенностей своей памяти, он тоже может столкнуться с тем же, не факт, другой преподаватель может быть более вменяем.
А какой урок это ему дало для реальной жизни? Что любой самодур может ему испортить жизнь только потому, что он не умеет завязывать галстук?) Тут есть здравое зерно. Но такой опыт он может получить от кого угодно. Преподаватели, а тем более в ВУЗах должны учить своих учеников чему-то все-таки большему, не так ли?
А какой урок это ему дало для реальной жизни? Что любой самодур может ему испортить жизнь только потому, что он не умеет завязывать галстук?) Тут есть здравое зерно. Но такой опыт он может получить от кого угодно. Преподаватели, а тем более в ВУЗах должны учить своих учеников чему-то все-таки большему, не так ли?
А какой урок это ему дало для реальной жизни?
Очень даже замечательный урок — любой факап является факапом, вне зависимости от того, насколько, казалось бы, незначительна ошибка.
Советую почитать (всем лайкнувшим в т.ч.) про «право на ошибку» и его влияние на не зрелую психику, тема хорошо изученная. Если коротко — сильно жесткое наказание за ошибки убивает желание вообще что-либо делать. Получаем на выходе человека без амбиций.
Я решительно не понимаю с какого перепуга оценка 4 — сильно жесткое наказание за ошибку.
А это когда родители за четверку наказывают хуже, чем за убийство. Сталкивался я с такими людьми — могут и суицид из-за четверки сделать.
С тех пор как 5 стало наградой. За нею гонятся, и обижаются если ее не получают.
Интересно, а не ломает ли психику, факт, что в послешкольной жизни твои оценки никому не нужны?
Интересно, а не ломает ли психику, факт, что в послешкольной жизни твои оценки никому не нужны?
Советую почитать (всем лайкнувшим в т.ч.) про «право на ошибку» и его влияние на не зрелую психику, тема хорошо изученная.
Человек — студент, какая незрелая психика? Хватит уже этого инфантилизма. Он к реальной работе готовится, к ответственности, а не в детский сад пришел.
Скажу лично за себя — в моем окружении (и я сам) — лет до 20 никто не знал кто что и зачем будет в будущем делать. А в вузы все поступали просто от армии откосить в основном, так как ни проф. ориентации, ни мозгов своих ни у кого не было.
До 20? Да это отличный расклад :)
Лично мне понадобилось 25.
Лично мне понадобилось 25.
Сколько вам лет?
Я в начале 90-х поступал уже зная кем я хочу стать и чем заниматься по окончании ВУЗа.
Я в начале 90-х поступал уже зная кем я хочу стать и чем заниматься по окончании ВУЗа.
А в вузы все поступали просто от армии откосить в основном, так как ни проф.
Ну так и следовало бы их всех отчислить.
Человек зреет после 30. Задолго после первой работы, первой жены и первого ребенка. А студенты — дети. Хотя конечно это так не воспринимается — когда тебе меньше 30, а уж тем более меньше 25. Мои дети в 3 года уже говорят что они взрослые :)
Человек зреет после 30.
Кое-кто 2 тысячи лет назад уже и учение свое создал, и проповедовал по всей стране, и раскрутился, так что власти испугались, и был казнен всего-то в 33 года.
И в те времена это не было особо удивительным (удивительным является только степень распространенности его учения и как оно прошло через тысячелетия). Мужчина тогда считался мужчиной в 15.
А современные люди — какое там учение, они, оказывается, после 30 дозревают еще (как вино, что ли)
P.S.:
А если серьезно — то да, современные люди более инфантильны (можно почитать про особенности поколения Y).
Но раз на раз не приходится. Всех грести под одну гребенку — некорректно.
У меня есть знакомые: одна уехала из родительского дома в 15 лет учиться и с тех пор живет самостоятельно, обеспечивает родителей; другая уехала в 18 и родители вообще не помогали и не помогают (у них конфликт), моталась по съемным квартирам, как-то зарабатывала сама; другая в 40 лет сидит на шее у родителей, не работала и не работает (здорова, с вышкой), полагаю, и не будет (родители не олигархи, обычные).
И вот уже 2 тысячи лет вся европа расплачивается за его незрелые действия)
По поводу Христа есть стандартный ответ что Илья Муромец в 33 впервые с печи поднялся.
А так — как-то несерьезно сравнивать чисто биологическое взросление из древности (мужчина и сейчас в 15 может и детей заделать, и по физическим габаритам не кардинально отличается от взрослого) и более сложное социальное и профессиональное взросление. Вроде как Моцарт прославившийся еще подростком как композитор и тогда считался гением и скорее исключением, чем правилом, а в основном реального профессионально зрелыми люди и тогда становились после 20 (учебу никто не отменял же), думаю, часто сильно после.
А так — как-то несерьезно сравнивать чисто биологическое взросление из древности (мужчина и сейчас в 15 может и детей заделать, и по физическим габаритам не кардинально отличается от взрослого) и более сложное социальное и профессиональное взросление. Вроде как Моцарт прославившийся еще подростком как композитор и тогда считался гением и скорее исключением, чем правилом, а в основном реального профессионально зрелыми люди и тогда становились после 20 (учебу никто не отменял же), думаю, часто сильно после.
Зрение зрению рознь. Самостоятельность — не зрелость. Один из факторов — но не единственный. Еще например эмоциональная стабильность. Эти ваши зрелые того времени воевали, убивали и изменяли. Да так часто — что им нужен был злостный бог карающий то за онанизм, то за злые мысли.
А если вы не хотите грести под одну гребенку — зачем вы идете за дипломом государственного образца? Ведь это фактически и есть гребенка, учащийся ее добровольно выбрал, а потом начинается «я особенный». Особенный — не иди в универ, сам себе диплом выпиши, какие проблемы :)
А если вы не хотите грести под одну гребенку — зачем вы идете за дипломом государственного образца? Ведь это фактически и есть гребенка, учащийся ее добровольно выбрал, а потом начинается «я особенный». Особенный — не иди в универ, сам себе диплом выпиши, какие проблемы :)
Человек зреет после 30. Задолго после первой работы, первой жены и первого ребенка. А студенты — дети.
Кек, ну тогда пускай учится до 35 а потом уже работу ищет что ли?
Зачем безответственный незрелый человек на работе нужон и кому?
Ну почему любой, вон на ракете «Протон» кто-то поставил датчик вверх ногами… а, ну да…
Ну как бы это оценка не только знаний ученика, но и способности их применять. Вот в конкретном случае ученик не смог, не важно, от волнения, просто запамятовал, а другой смог. Им обоим ставить отлично? Но они же на разном уровне справились с задачей.
Ну так и система оценивания не 1000 бальная, и оценку ставят не за «выполнение задания», задача экзамена выявить итоговый уровень знаний и умений ученика в конце курса. На лабораторке вполне нормально ставить 4 за такую ошибку. А экзамен это инструмент преподавателя, похожий на собеседование. Задача преподавателя разделить учеников на 5 категорий. Каждая категория детально описана в рекомендациях министерства образования, ведь диплом у нас государственного образца, а не образца «Ивана Федоровича»?
Конечно каждый ученик — личность и выполняет задание не как другой. И вы могли-бы подумать что 5 это 100% идеальное знание предмета в стиле Бетмена, но это не так. 5 это примерно 80% и более усвоения материалов и навыков.
На практике обычно 5 обозначает — «ученик понял суть предмета и его принципы», а не стал матерым специализстом за пол года с набитой рукой. Например на вопрос «чем прямое преобразование Фурье отличается от обратного», отличник ответит «Прямое преобразует сигнал в спектр, а обратное по спектру восстанавливает сигнал.» А хорошист начнет цитировать определение сначала первого, потом второго. Т.е. хорошист запомнил, выполнил все что нужно было, но ни чего не понял, «вы хотели чтоб я это знал — я знаю». А троечник как хорошист, но не смог все запомнить. НО это грубо и мое мнение, министерство расписывает лучше.
Конечно каждый ученик — личность и выполняет задание не как другой. И вы могли-бы подумать что 5 это 100% идеальное знание предмета в стиле Бетмена, но это не так. 5 это примерно 80% и более усвоения материалов и навыков.
На практике обычно 5 обозначает — «ученик понял суть предмета и его принципы», а не стал матерым специализстом за пол года с набитой рукой. Например на вопрос «чем прямое преобразование Фурье отличается от обратного», отличник ответит «Прямое преобразует сигнал в спектр, а обратное по спектру восстанавливает сигнал.» А хорошист начнет цитировать определение сначала первого, потом второго. Т.е. хорошист запомнил, выполнил все что нужно было, но ни чего не понял, «вы хотели чтоб я это знал — я знаю». А троечник как хорошист, но не смог все запомнить. НО это грубо и мое мнение, министерство расписывает лучше.
хорошист запомнил, выполнил все что нужно было, но ни чего не понялЧестно говоря на мой взгляд это какой-то мутный хорошист. Но таки да, это тоже мое, вполне вероятно неверное мнение. Я действительно считаю что 5 — это прям как Бетмен. Просто на мой взгляд сейчас оценки в целом воспринимаются слегка странно. Что-то типа двойка это не «плохо», а просто отсутствие знаний, тройка — ну где то-там что-то есть, четверка — половину материала выучил. Все остальное — пять. На мой вкус при этом пятерка несколько обесценивается. Хотя конечно все зависит от конкретных мест, и это также мое субъективное мнение.
Конечно обесценивается, но так и мотивация учащихся падает и их способности. 5 это значит — годный студент фактически, интересуется предметом, интересуется учебой. Если у человека 4 и 5 в дипломе — то он нормальный и адекватный, можно брать. Если везде одни 4 — ну значит он прилежный болван, делает что говорят, в суть не вникает. Если значительное количество 3 по профильным предметам и при этом есть и 5 и 4, значит эмоционально не стабильный, не дисциплинированный и своенравный. Может работать шикарно месяц, потом месяц бухать или прокрастинировать. А через год пошлет всех матом, скажет у вас технологии скучные\не правильные — я ушел.
Те кто хотят найти юного Бетмена — те смотрят на вне дипломные титулы, всякие участия в олимпиадах, хакатонах и прочем. Задача обычного образования — давать обычных специалистов, не брильянты и не Бетмены, просто обычных нормальных инженеров.
Посему для меня 4 — это как плевок в лицо и факт профнепригодности. Осилить элементарную программу стандартного государственного курса — не сложно. И т.к. я учился по собственному желанию, сам выбирал направление и ВУЗ — для меня было очень важно пройти обучение полноценно. Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
А насчет 2 — ну в университете это значит что ты идешь в армию. А вот 3 — это считает нормальная оценка для «стоящих в очереди за дипломом». Посему получить 3 это ваще жутко стыдно для меня, это как напиться по молодости и попасть в таком состоянии в телевизор, и потом всю жизнь тебя будет так вспоминать при каждом трудоустройстве (при условии что диплом смотрят).
Кстати в локальных контора — на дипломы у нас смотрят и на ту его часть где есть оценки. Но только у молодых специалистов, потому уже опыт, портфолио и так далее. А вот первые несколько лет — банально больше не почем судить человека. Даже если он отлично прошел собеседование и написал тестовое — это не полное покрытие важных качеств личности. Нужно же понимать насколько он стабилен. Проработает ли он год или месяц или пока ты его не уволишь? Будет ли он легко осваивать новые технологии или будет жестко навязывать привычные себе и сопротивляться всему остальному?
Из рассказов про иностранные ВУЗы — там важность оценок намного выше. Там получается соревновательный принцип везде. Т.е. программа не фиксированная, есть разные преподаватели по каждому предмету, и разные предметы на выбор. И если ты хочешь попасть к лучшим преподам и на самые интересные курсы — у тебя должен быть высоких бал за прошлый семестр. В итоге если отличник и старается — то он реально учился в Гарварде, а если троечник, то ходя в тот же Гарвард — учился у всяких аспирантов, и ни чем не лучше «местного колледжа».
Если брать всякие курсы и сертификаты — то там два состояния — сдал или не сдал, дали или не дали. Фактически 2 и 5. А что такое 4? Пол сертификата? Полу специалист?
Если брать политику бесплатного и платного образования. Если у тебя бал 4.75 и выше — тебя госво поощряет гривной. Если у тебя бал 4 и выше — то ты имеешь право получить образование бесплатно. А если ниже 4 — это значит что фактически государство считает что с тебя не будет ни какого толку, ты бесполезно тратишь свое время на этой специальности, но ты имеешь право — плати деньги и ходи. Вопрос насколько этично продавать дипломы, а выдавать дипломы тем у кого средний бал даже 4.0 — это фактически продать бумажку, «не специалисту», которому это дело не интересно и который знаний не имеет. Я считаю — не этично, кто-то считает что это либерально и финансово выгодно, троечники — содержат отличников.
Те кто хотят найти юного Бетмена — те смотрят на вне дипломные титулы, всякие участия в олимпиадах, хакатонах и прочем. Задача обычного образования — давать обычных специалистов, не брильянты и не Бетмены, просто обычных нормальных инженеров.
Посему для меня 4 — это как плевок в лицо и факт профнепригодности. Осилить элементарную программу стандартного государственного курса — не сложно. И т.к. я учился по собственному желанию, сам выбирал направление и ВУЗ — для меня было очень важно пройти обучение полноценно. Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
А насчет 2 — ну в университете это значит что ты идешь в армию. А вот 3 — это считает нормальная оценка для «стоящих в очереди за дипломом». Посему получить 3 это ваще жутко стыдно для меня, это как напиться по молодости и попасть в таком состоянии в телевизор, и потом всю жизнь тебя будет так вспоминать при каждом трудоустройстве (при условии что диплом смотрят).
Кстати в локальных контора — на дипломы у нас смотрят и на ту его часть где есть оценки. Но только у молодых специалистов, потому уже опыт, портфолио и так далее. А вот первые несколько лет — банально больше не почем судить человека. Даже если он отлично прошел собеседование и написал тестовое — это не полное покрытие важных качеств личности. Нужно же понимать насколько он стабилен. Проработает ли он год или месяц или пока ты его не уволишь? Будет ли он легко осваивать новые технологии или будет жестко навязывать привычные себе и сопротивляться всему остальному?
Из рассказов про иностранные ВУЗы — там важность оценок намного выше. Там получается соревновательный принцип везде. Т.е. программа не фиксированная, есть разные преподаватели по каждому предмету, и разные предметы на выбор. И если ты хочешь попасть к лучшим преподам и на самые интересные курсы — у тебя должен быть высоких бал за прошлый семестр. В итоге если отличник и старается — то он реально учился в Гарварде, а если троечник, то ходя в тот же Гарвард — учился у всяких аспирантов, и ни чем не лучше «местного колледжа».
Если брать всякие курсы и сертификаты — то там два состояния — сдал или не сдал, дали или не дали. Фактически 2 и 5. А что такое 4? Пол сертификата? Полу специалист?
Если брать политику бесплатного и платного образования. Если у тебя бал 4.75 и выше — тебя госво поощряет гривной. Если у тебя бал 4 и выше — то ты имеешь право получить образование бесплатно. А если ниже 4 — это значит что фактически государство считает что с тебя не будет ни какого толку, ты бесполезно тратишь свое время на этой специальности, но ты имеешь право — плати деньги и ходи. Вопрос насколько этично продавать дипломы, а выдавать дипломы тем у кого средний бал даже 4.0 — это фактически продать бумажку, «не специалисту», которому это дело не интересно и который знаний не имеет. Я считаю — не этично, кто-то считает что это либерально и финансово выгодно, троечники — содержат отличников.
UFO just landed and posted this here
+1, на первом, оно же текущее, месте работы вкладыш с оценками вообще не спрашивали. Больше того, я его даже не забирал. Хотя признаюсь честно — там, особенно на первых курсах когда связался с «плохой» компанией да и не было своего компьютера (а соответственно и навыков использования как и знаний в профильных дисциплинах), просто куча трояков. Самый обидный по какой то математике, предмет знал и спокойно мог сдать на отлично, благо математику всегда любил, но из за просроченного курсача по экономике удалось попасть только на пересдачу где мне и еще одному гаврику поставили трояки за то что помогли жалюзи повесить. И да, это даже по меркам моего города был далеко не самый топовый вуз)
Я показывал один раз, когда устраивался на завод, но там брали всех подряд. После этого работал только программистом, а диплом вообще по другой специальности, поэтому не показывал его больше никому.
5 это значит — годный студент фактически, интересуется предметом, интересуется учебой.
На практике у каждого преподавателя свое мнение о семантике оценок и его надо просто принимать. У меня например у преподавателя по матану было мнение из разряда канонического "на 5 знает господь бог, на 4 — я, а вы — на все остальное", с-но иногда никто из потока не мог сдать с первого раза хотя бы на 3 :)
Бывает, и это плохо. Есть стандарт и ему нужно соответствовать и ученику и преподавателю. Если преподаватель хочет, он может открыть свой «кружок» и унижать там учеников, за их деньги.
0xd34df00d Единичные оценки — не важны для анализа. По ним систему не построишь. Не вы первый, не вы последний, вступивший в конфликт с преподом. Думаю все это понимают.
ApeCoder я вроде так и написал. Оценивать нужно не знание фактов, и преподы оценивают не знание фактов. На одном экзамене у меня было вообще так. Я пришел тянуть билет, препод взял методичку(которую я не видел до этого), открыл на рандомной странице, показал схему ака ПИД регулятор, но звеньев было больше. Тыкнул в один из них и спрашивает — зачем он здесь. Я ответил буквально в 7 слов — получил 5 и ушел. Хотя мне рассказывали что он жутко валит и так далее. На самом деле ему было плевать на точность заученных определений, а «большинство» этого не понимало. Они старались вызубрить как можно точнее.
0xd34df00d Единичные оценки — не важны для анализа. По ним систему не построишь. Не вы первый, не вы последний, вступивший в конфликт с преподом. Думаю все это понимают.
ApeCoder я вроде так и написал. Оценивать нужно не знание фактов, и преподы оценивают не знание фактов. На одном экзамене у меня было вообще так. Я пришел тянуть билет, препод взял методичку(которую я не видел до этого), открыл на рандомной странице, показал схему ака ПИД регулятор, но звеньев было больше. Тыкнул в один из них и спрашивает — зачем он здесь. Я ответил буквально в 7 слов — получил 5 и ушел. Хотя мне рассказывали что он жутко валит и так далее. На самом деле ему было плевать на точность заученных определений, а «большинство» этого не понимало. Они старались вызубрить как можно точнее.
UFO just landed and posted this here
UFO just landed and posted this here
Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
Это подразумевает, что оцениваетя именно понимание, а не знание кучи фактов, и информацию можно получить только прослушав какой-то курс в университете.
Им обоим ставить отлично?
Именно так, если преподаватель уверен что и тот и другой знают предмет на отлично. А это у нас в «Дано». А если вдруг препод засомневался, просто посадил бы «затупившего»на 5-10 минут собраться с мыслями. Тот бы успокоился и ответил, или не ответил если он действительно не знает. Вот и все.
Вот смотивировал, в сложных расчётах не забывать, что 1/2 больше 1/4. В физике народ вот постоянно палиться на том, что результат в 10 раз больше или меньше. Казалось бы небольшая ошибка, а на самом деле можно такой расчёт отправить в помойку, если он на порядок расходится. И рассчитать «на глазок» с ошибкой 10-20%.
UFO just landed and posted this here
В вузе уже обычно относительно взрослые и понимающие, чего они хотят, люди.
В российском-то, т.е. сразу после школы? Ну-ну.
UFO just landed and posted this here
Ну так «в абстрактном российском вузе» и «в Физтехе» — это две очень большие разницы.
Личность становится зрелой — пожив жизнь. Пройдя определенные этапы, и семейные и бытовые и рабочие. Т.е. это тупо зависит от времени жизни. И не нужно путать интеллект и самоконтроль — со зрелостью личности. Личность становится зрелой примерно к тому времени, когда разрешено баллотироваться на президента. И то не всегда! Яркий пример очень одаренного, но не зрелого, человека показан в фильме «Good Will Hunting», и там как раз аналог Физтеха.
Это да. Бывает.
Я когда 18 лет назад писал «олимпиадную» как бы предварительно вступительную работу по математике в МГУ решил 5 задач из 6ти.
В одной чуток налажал. Сложная стереометрия, я рассмотрел 3 случая из 4х. 4ый вырожден, но я не написал об этом. Ок. Минус.
Но другая задача… До сих пор обидно. Две страницы вычислений и в конце:
… = 8+6 = 10
Ответ: 10
И минус за задачу. 3 за работу — не прошел. Правильный ответ был 14.
Так что пришлось поступать летом.
PS. Еще. Более эпичесский фейл. Сдавал ГосЭкзамен. Где то в ходе одного доп. вопроса нарисовал касательную и доответил на вопрос. А экзаменатор такой: «Ну, хорошо. Это вы знаете. Давайте напоследок выведете мне уравнение касательной и закончим на этом.».
Я такой радостный — 5 за Гос уже у меня, что там эта касательная, я ее в 10 классе мог вывести. И… ступор. Не выводится. Так порисовал — не выводится.
Эдак попробовал — фигня получается(я ж помню формулу!).
Результат — 4 по госу из-за этой касательной. Вышел — все вывелось устно.
Я когда 18 лет назад писал «олимпиадную» как бы предварительно вступительную работу по математике в МГУ решил 5 задач из 6ти.
В одной чуток налажал. Сложная стереометрия, я рассмотрел 3 случая из 4х. 4ый вырожден, но я не написал об этом. Ок. Минус.
Но другая задача… До сих пор обидно. Две страницы вычислений и в конце:
… = 8+6 = 10
Ответ: 10
И минус за задачу. 3 за работу — не прошел. Правильный ответ был 14.
Так что пришлось поступать летом.
PS. Еще. Более эпичесский фейл. Сдавал ГосЭкзамен. Где то в ходе одного доп. вопроса нарисовал касательную и доответил на вопрос. А экзаменатор такой: «Ну, хорошо. Это вы знаете. Давайте напоследок выведете мне уравнение касательной и закончим на этом.».
Я такой радостный — 5 за Гос уже у меня, что там эта касательная, я ее в 10 классе мог вывести. И… ступор. Не выводится. Так порисовал — не выводится.
Эдак попробовал — фигня получается(я ж помню формулу!).
Результат — 4 по госу из-за этой касательной. Вышел — все вывелось устно.
На самом деле сейчас в наших вузах активизировалась дискуссия против устных экзаменов, как раз примерно по таким причинам.
Сейчас в МГУ арифметические ошибки трактуются в пользу абитуриента.
Сейчас такое было бы плюсом с точкой.
Сейчас такое было бы плюсом с точкой.
Да? Даже на МехМат\физмат\ВМиК?
Даже не знаю как к этому относиться.
Хотя… если одновременно усложнить задачи, то думаю и норм.
Даже не знаю как к этому относиться.
Хотя… если одновременно усложнить задачи, то думаю и норм.
А зачем делать из студента калькулятор? Ладно, на физических факультетах это может и важно, но на математическом уже в первый месяц начинаются темы где арифметика в принципе практически не нужна и чем дальше, тем больше. У нас на матмехе в СПбГУ большинство преподов арифметические ошибки замечало, но на оценку они не влияли в 99 случаях из 100. Это даже не было поводом задать доп вопрос, разве что студента потролить, да и то не всегда.
Не все можно вывести. А забывать могут все, причем понимание есть, а слов нет судя и по случаю с Савватеевым. Это нормально.
UFO just landed and posted this here
А теперь представь, что времени вывести и доказать нет. И д.ф.-м.н выглядит профаном
Я в лекциях Савватеева наблюдал момент, когда по ходу лекции он забыл формулу нахождения корней квадратного уравнения (а это д.ф.-м.н. между прочим). Он слегка смутился, но тут же ее вывел и доказал.
Я вы часом не помните название? Может, сохранили ссылку, буду весьма признателен.
Так на вскидку не скажу. Насколько помню это было в одной из лекций 100 уроков математики.
На самом деле пример не совсем честный, т.к. вывод формулы корней квадратного уравнения — не какой-то особый, это техника, которая очень много где применяется. Если бы вопрос был какой-то специфичный, он бы вполне мог и залипнуть. Например, я сомневаюсь, что можно так быстро оп! и вывести формулы Кардано, если их не помнить или не помнить соответствующую базу (например прям как раз недельку назад теорию Галуа повторил, кек).
Я этим примером лишь проиллюстрировал, что незнание некоторых фактов компенсируется знанием некоторых принципов. Но, если ты не знаешь принципов в той области, в которой как бы сеньор, то тут уже ничто не поможет. Конечно судить о человеке по одному неверному ответу минимум глупо. Но. Я сам довольно много собеседовал людей, приходящих на сеньорские позиции, с огромным стажем (судя по резюме), но при этом не способных внятно ответить на базовые вопросы, которые должен знать любой джун. Может все дело в перегретом рынке предложений и завышенной самооценке отдельных представителей профессии?
Есть вероятность что данный сеньор уже давно не трогал вещи которые должен знать тот же джун на зубок. Например когда ты поставленные задачи решаешь уже на автомате и в принципе уже не задумываешься о способе решения, т.к. у тебя уже наработанная практика и все ушло на уровень рефлексов. А тут на собеседовании ты включаешь голову (у тебя же стресс) и у рефлексы благополучно задавливаются.
Кмк, перед собеседованием можно было бы и потрогать. В конце концов, уж если цель продать свое время подороже (в хорошем смысле), то уж товар надо представить как можно лучше. В самом начале у меня тоже были мягкие фильтры, но, когда я стал терять по полдня на разные собеседования «сеньоров», фильтры ужесточились практически автоматом — сперва ответы на листочке и, если порог пройден, то личная беседа.
(offtop 25 минут на редактирование комментария; видно я что-то пропустил, но это круто).
(offtop 25 минут на редактирование комментария; видно я что-то пропустил, но это круто).
Для формулы кардано не нужна теория Галуа. В Википедии вывод достаточно простой и специфических знаний не требует. Но просто так без подготовки вывести, да, трудно.
Для формулы кардано не нужна теория Галуа.
Не нужна, но если вы накануне повторяли теорию Галуа, то, скорее всего, сможете сами получить вывод формул Кардано, не зная его наперед.
В Википедии вывод достаточно простой и специфических знаний не требует.
Открытие сейфа тоже не требует специфических знаний — это ведь не сложно, влево-вправо крутить :)
Смысл в том что в случае формул Кардано вывод не строится на использовании каких-то известных и общеприменимых методов, он выглядит как: "сделаем хитрое преобразование, потом еще одно, потом хитрую замену, и еще хитрое преобразования — и получим формулу!".
И вот эти преобразования взять неоткуда, они не являются типовыми. Именно по этой причине они и появились на несколько тысяч лет позже, чем формулы для квадратных :)
Но как математик ты можешь например сходу не ответить сколько существует суръекций между множествами. Я думаю подобных вопросов можно много накидать.
программирование — не математика.
Да, похоже учителем математики в школу Савватеева бы после такого не взяли.
UFO just landed and posted this here
на небольшое время «забыть»
Я не очень представляю, как Senior JS разработчик может забыть, что такое замыкание)
А какие проблемы грамотно пользоваться инструментом, но не знать назубок его академического определения?
По себе сужу, у меня опыта в программировании больше 20 лет и, но скажем, над определением переменной я вполне могу задуматься. А дальше зависит от того, чего хочет собеседующий, если его устроит объяснение на пальцах расскажу, в этот момент может всплыть какое нибудь определение которое я на заре карьеры мельком прочитал, если же вопрошающий явно пытается меня на чём то подловить… диалога не получится.
По себе сужу, у меня опыта в программировании больше 20 лет и, но скажем, над определением переменной я вполне могу задуматься. А дальше зависит от того, чего хочет собеседующий, если его устроит объяснение на пальцах расскажу, в этот момент может всплыть какое нибудь определение которое я на заре карьеры мельком прочитал, если же вопрошающий явно пытается меня на чём то подловить… диалога не получится.
«Академическое определение» требуют примерно нигде (ибо канона нет, какой такой букварь цитировать?), но если человек на понятийном уровне не может слов подобрать и ему требуется лезть в какие-то там чертоги сознания (гугол), чтобы вспомнить достаточно активно используемые фичи языка — это дурной знак. Дутых сеньоров в наше время тоже достаточно.
Я бы сказал, при прочих равных, это слабый знак, если человек решил тестовое задание, ответил на много вопросов, и слился на одном, этот вопрос не должен быть последним.
В отрасли достаточно товарищей с хорошо подвешенным языком, которые умеют отвечать на неожиданные вопросы, и не умеют работать. И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
В отрасли достаточно товарищей с хорошо подвешенным языком, которые умеют отвечать на неожиданные вопросы, и не умеют работать. И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
Я бы сказал, при прочих равных, это слабый знак, если человек решил тестовое задание, ответил на много вопросов, и слился на одном, этот вопрос не должен быть последним.
Опять вы впадаете в крайность. Зачем?
Если человек решил тестовое задание без наблюдения и слился на элементарном вопросе, то с высокой вероятностью его делал кто-то другой. Весомая причина дальше испытывать собеседуемого на других базовых вопросах.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
Если человек решил тестовое задание без наблюдения и слился на элементарном вопросе, то с высокой вероятностью его делал кто-то другой. Весомая причина дальше испытывать собеседуемого на других базовых вопросах.
С таким не сталкивался. Впрочем, есть же испытательный срок, и по крайней мере у нас решение о найме принимается коллегиально.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
Разница есть, по моему скромному опыту, выполнение задач в хорошем качестве и то, насколько хорошо у человека подвешен язык коррелирует слабо. Может конечно, нужно джедаем найма быть, но по мне проверить человека «в бою» надёжнее.
есть же испытательный срок
А если у вас уже есть на примете несколько человек без таких сомнительных историй? Нельзя всех взять вне штата, а потом устраивать чемпионат на вылетание.
выполнение задач в хорошем качестве и то, насколько хорошо у человека подвешен язык коррелирует слабо
Если у человека есть знания, но нет возможности это выразить, то как он с командой общаться будет? С заказчиком?
А если кандидат говорливый, то проверить его как раз проще. Хорошие говоруны, кмк, проходят из-за недостатков интервьюера.
Нельзя всех взять вне штата, а потом устраивать чемпионат на вылетание.
В комментарии ниже этот момент затронул.
Если у человека есть знания, но нет возможности это выразить, то как он с командой общаться будет? С заказчиком?
Вопервых сам человек привыкает, потом команда тоже к человеку привыкает. Заказчик, конечно, не виноват, но это вопрос уже к руководству фирмы, а не к работнику.
А если кандидат говорливый, то проверить его как раз проще. Хорошие говоруны, кмк, проходят из-за недостатков интервьюера.
Мой хороший друг в таких случаях обычно отвечает, что все мы немного лошади. В том смысле, что никто не идеален.
Можно спорить о подходах к интервью. Думаю что подход, когда человека на интервью спецом заваливают, имеет право на жизнь. Например при найме в какой нибудь отдел продаж. В случае с программистами работающими с прикладными задачами, думаю он не тех людей пропустит.
Может конечно, нужно джедаем найма быть, но по мне проверить человека «в бою» надёжнее.
Надёжнее, но намного дороже в случае его неуспеха.
А дальше каждая компания для себя решает, какую цену она готова доплатить за сокращение false negatives при найме.
У меня, конечно, есть лукавство. Если есть два кандидата, которые в целом одинаково проходят интервью, то быстрый из развёрнутый ответ на такой вопрос прибавит ответившему баллов. Но именно прибавит тому кто ответил, а убавит баллов у второго.
Разница между прибавит и убавит существенная. Т.к. при очередном раунде найма, мы второго пригласим.
Разница между прибавит и убавит существенная. Т.к. при очередном раунде найма, мы второго пригласим.
Может кандидат просто быстрее соображает? Уж убавить ему это никак не должно.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
Вижу у меня «не» потерялось. Предложение должно звучать так:
А тут мы упираемся в эффект Даннинга — Крюгера. Особенно если проведение интервью это не основная работа, а то, что приходится делать время от времени.
Мне кажется, мы с вами примерно про одно говорим.
Но именно прибавит тому кто ответил, а не убавит баллов у второго.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
А тут мы упираемся в эффект Даннинга — Крюгера. Особенно если проведение интервью это не основная работа, а то, что приходится делать время от времени.
Мне кажется, мы с вами примерно про одно говорим.
но не знать назубок его академического определения
Зачем вы говорите об академическом определении? Зачем вы возводите в абсолют мои слова? Я нигде не говорил об определении. Я говорил вообще о понятии. Вы можете представить, что человек забыл, что такое переменная? Не забыл ее определение, а вообще забыл, что такое переменная. Вы ему говорите слово «переменная», а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
Значит я вас не так понял. Вы же допускаете, что тот, кого вы собеседуете тоже может вас не так понять?
> а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
Например он недавно из института и привык к преподавателям, которые требуют определение в соответствии «с тем самым учебником».
Вопрос в дальнейшей реакции вас, как интервьюера.
> а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
Например он недавно из института и привык к преподавателям, которые требуют определение в соответствии «с тем самым учебником».
Вопрос в дальнейшей реакции вас, как интервьюера.
Например, у него проблемы с электропроводкой в квартире, и он весь вечер перед собеседованием пытался разобраться, почему выключатель не работает. Скажут ему «замыкание», и он будет вспоминать, что же там такого есть в JavaScript, что можно сравнить с неправильным соединением проводов.
<зануда мод>Ну почему же сразу неправильным? В замыкании проводов как таковом ничего неправильного нет — это нормальная практика. А в словосочетании «короткое замыкание» про «неправильность» та часть, которая «короткое»</зануда мод>
Несогласным хочу напомнить, что влияние контекста достаточно известная вещь в психологии, а человеческое мышление работает на ассоциациях, и без соответствующих ассоциаций можно не сразу вспомнить то, что нужно.
А Senior мог на предыдущей работе называть это исключительно словом "closure", и потому в данный момент слово "замыкание" у него ассоциируется в первую очередь с электричеством, и он может замяться на какое-то время, вспоминая правильное значение.
Я с 1991 года программирую, я не могу себе представить ситуации, чтобы я не смог сказать, что такое замыкание. Ну или virtual (хотя я уже лет десять не писал на языках, где это есть). Я допускаю, что могут быть случаи разные, но это такая дикая редкость, что шанс с такой ситуацией столкнуться мизерно мал.
На мой взгляд есть 2 категории людей, с хорошей памятью на определения и с плохой, так вот у меня куча знакомых из первой категории и они просто не способны понять как это — забыть то что "учил", они распостраняют свой личный опыт на всех окружающих без права поставить его под сомнение. Но у другой части обычно есть приемущество (возможно вынужденное изза плохой памяти) в части логики.
Был во второй категории, но сейчас скорее в средней. Просто понял что неправильно запоминал все это. Хотя может все эти замыкания и прочие термины запоминаются потому что выглядят интересно и часто мелькают в описаниях технологий/статьях?
Возможно были во второй, возможно не были. Чтобы понять нужен опыт, если вы сегодня можете выучить стих наизусть за час а завтра только помнить о чём он в общих чертах, то это одно, если вы не помните его один раз прочитав — это другое.
p.s. у меня ребёнок пример фантастической (по моим меркам) памяти, ему один-два раза читаешь стих на пару страниц, и он без проблем его рассказывает через день :)
Да, я действительно скорее не про способности а про отношение к запоминанию. Раньше считал что это вообще смысла не имеет, сейчас считаю немного по другому.
Определение, так-то, не стих, где 2 слова местами поменял, и ритм сломался. Определение можно сходу из головы наговорить, если понимаешь, что определяешь. Правда для этого уже надо качать умение сходу наговаривать из головы, а не зажиматься.
Для меня вы из категории не понимающих как такое возможно.
Уточню, когда вам говорят а расскажите про "название" вы просто не помните про что оно :)
p.s. и да уточнить не проблема, проблема в том что вторая сторона делает однозначный вывод руководствуясь своим опытом и верой в то что если не может сходу ответить то не знает.
проблема в том что вторая сторона делает однозначный вывод руководствуясь своим опытом и верой
А вы, как первая сторона, на чем основывались, делая этот вывод?
Уточню, когда вам говорят а расскажите про «название» вы просто не помните про что оно :)
Тут нюанс же есть, в направлении вопроса. Спрашивают же не «как называется вот эта красная лопата по-научному», а «как выглядит пожарная лопата».
«Не вспомнить» простительно для первого варианта. Человек отлично пользуется пожарной лопатой, но чутка подзабыл, что ее положено называть «пожарной», тупо забыл слово — ничего страшного, главное, что пользоваться умеет.
А во втором варианте… Кхм, это не «подзабыл слово», а просто «не может с ходу вспомнить, как оно выглядит». Вот это тревожный звоночек же.
Как бы, вспомните правильный термин, подходящий под определение — это да, вопросы не для собеседования, а, скорее, для кроссворда. А вот «объясните термин» — вроде, норм.
UFO just landed and posted this here
А зачем запоминать определения дословно? При наличии понимания о чем речь определение можно сочинить на ходу используя ту самую логику в которой есть преимущество.
Глупо отрицать что существуют интервьюэры пытающиеся почесать свое ЧСВ на собеседованиях. Но надо помнить что собеседование процесс двухсторонний. Если вы видите что компания вам не подходит, скажите спасибо, за то что они об этом честно рассказали и двигайтесь дальше. Хуже когда на собеседовании врут про то что будет скрам и передовые технологии, а после выхода на работу оказывается что везде code-and-fix на фреймворке который уже вышел из поддержки, но для этого и дален испытательный срок. Он, как и собеседование, тоже работает в обе стороны.
И еще, мне кажется что если вы волнуетесь на собеседованиях, то вам еще рано называться senior :)
И еще, мне кажется что если вы волнуетесь на собеседованиях, то вам еще рано называться senior :)
Насчет собеседования согласен, а вот в случае увольнения работника после испытательного срока у следующего работодателя могут возникнуть вопросы, а если таких увольнений несколько то нужно быть весьма убедительным, чтобы обратить эту ситуацию в свою пользу. У меня в трудовой есть запись что я проработал в фирме чуть более года, на двух собеседованиях про этот момент спрашивали, хотя и мельком.
Если могут возникнуть вопросы, то нужно иметь на них ответы.
Если ситуация повторилась не один раз, да еще и подряд, то возможно надо что-то в консерватории поправить.
У меня в «трудовой» есть запись о том что меня уволили во время испытательного срока. И ничего страшного в этом не вижу. С радостью рассказываю какие работодатели бывают чудаки.
Если ситуация повторилась не один раз, да еще и подряд, то возможно надо что-то в консерватории поправить.
У меня в «трудовой» есть запись о том что меня уволили во время испытательного срока. И ничего страшного в этом не вижу. С радостью рассказываю какие работодатели бывают чудаки.
в какой системе счисления?)
Проблема с аргументами от аналогий в том, что аналогия должна быть корректной, то есть принципальные моменты в ситуации и ее аналогии должны совпадать, а противоречия должны отсутствовать. Так вот термин — это факт, который ни с чем не связан, это просто название, которое нельзя «вывести», его можно только запомнить. Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта. Человек может прекрасно понимать математику, физику, программирование, свободно владеть инструментарием, но именно из-за этого не помнить какой-то терминологический момент, которым никогда не пользуется. А надежно помнят все эти термины только те, кто либо зубрит, либо просто вчера из учебного заведения, либо учат этому, либо вот такие собеседователи, которые делают из терминологии фетиш и святыню. У разработчиков экономического и бухгалтерского софта точно также спрашивают план счетов. И тоже аргумент «это должно от зубов отскакивать». Нет, не должно. Это, как раз, именно то, что можно всегда «подсмотреть». А должно оно «отскакивать от зубов» тогда, когда человеку кроме фактической памяти работодателю предложить нечего.
Таки да. Всегда путал по номерам законы Ньютона...
Плюсану мануально, так как по-другому не могу. Для меня все эти вопросы на «память» — полный бред. Этак скоро начнут собеседовать как-то так: «Какого числа, какого месяца и какого года Страуструп придумал C++? Аааа, не знаешь! Ну так говно ты, а не C++ разработчик».
В какой-то мере виновато школьное образование, когда в большинстве случаев «отличником» будет тот, кто тупо запоминает дату битвы при Бородино, или вызубрит наизусть стих Пушкина, без понимания что там за настроения были в Европе при Наполеоне и что за личность была у Александра Сергеевича. Культ карго во всей красе.
В какой-то мере виновато школьное образование, когда в большинстве случаев «отличником» будет тот, кто тупо запоминает дату битвы при Бородино, или вызубрит наизусть стих Пушкина, без понимания что там за настроения были в Европе при Наполеоне и что за личность была у Александра Сергеевича. Культ карго во всей красе.
UFO just landed and posted this here
UFO just landed and posted this here
Потому что никому не интересно что бы вы сделали если бы у вас была карма. Ограничения отрицательной кармы вообще-то задумывались как наказание, а не как индульгенция на оставление мусора.
Думаю, если бы вы более внятно изложили свою мысль (развернули, чем вам так понравился коммент и почему, а не просто тыкнули +1), то вас бы не минусовали.
Это как очень стого и серьёзно спрашивать детишек день, месяц и год октябрьской революции, отмены крепостного права, взятия Бастилии, начала и конца 1 и 2 мировых, не донеся до них в течение года даже наличия у этих событий связей, причин и следствий.
Я сам через это прошёл: в школе ненавидел историю, потому что она сводилась к зубрёжке имён и дат; и только после вуза понял, что у исторических событий, оказывается, есть причины, следствия и взаимосвязи, а не только хронологическая последовательность.
Все сильно от учителей и преподавателей зависит. У меня школа и вуз оставили ровно противоположные впечатления.
В школе я сначала жутко разочаровалась в истории. Моя мама историк и она мне всегда очень интересно умела рассказывать про взаимосвязи событий (а даты она сама плохо запоминает), про исторических личностей. Я ожидала от школы чего-то в этом духе, но мы просто переписывали параграф в таблички. С моим представлением о том, что историю нельзя упихнуть в эти таблички, было тяжко. В старших классах плюнула на таблички и сдавала вместо них эссе. Учительница пару раз писала замечания, но в целом была довольна тем, что как раз понимание есть, поощряла доклады, рефераты и эссе, в которых видно, что ученики думали головой, а не переписывали учебник или википедию.
А вот в университете опять все свелось к заучиванию дат, а мой реферат про народное ополчение 1812 года (с использованием источников из архивов, с чем вряд ли на факультете ИТ кто-то сильно заморачивался) был жутко раскритикован за то, что я не упомянула в нем кого-то из партизан, хотя это вообще разные вещи. А экзамен свелся к распечатке методички для кафедры.
В школе я сначала жутко разочаровалась в истории. Моя мама историк и она мне всегда очень интересно умела рассказывать про взаимосвязи событий (а даты она сама плохо запоминает), про исторических личностей. Я ожидала от школы чего-то в этом духе, но мы просто переписывали параграф в таблички. С моим представлением о том, что историю нельзя упихнуть в эти таблички, было тяжко. В старших классах плюнула на таблички и сдавала вместо них эссе. Учительница пару раз писала замечания, но в целом была довольна тем, что как раз понимание есть, поощряла доклады, рефераты и эссе, в которых видно, что ученики думали головой, а не переписывали учебник или википедию.
А вот в университете опять все свелось к заучиванию дат, а мой реферат про народное ополчение 1812 года (с использованием источников из архивов, с чем вряд ли на факультете ИТ кто-то сильно заморачивался) был жутко раскритикован за то, что я не упомянула в нем кого-то из партизан, хотя это вообще разные вещи. А экзамен свелся к распечатке методички для кафедры.
Ну год и месяц октябрьской революции помнить надо (день ИМХО не обязательно), чтобы в ноябре не смотреть «парад в честь парада 7.11.1941». По крайней мере в нашей стране, по крайней мере ближайшие лет 100.
Но в принципе согласен. Знание того, какая именно полубригада штурмовала южные флеши в 8 утра 26 августа — информация для массового обучения лишняя. Важно что в этом бою сражалась буржуазная армия объединенной Европы с феодальной армией РИ и что в его итоге понесла поражение (стратегическое, а не тактическое). И то, что не смотря на поражение в войне буржуазная идея спустя 200 лет цветет и пахнет.
Но в принципе согласен. Знание того, какая именно полубригада штурмовала южные флеши в 8 утра 26 августа — информация для массового обучения лишняя. Важно что в этом бою сражалась буржуазная армия объединенной Европы с феодальной армией РИ и что в его итоге понесла поражение (стратегическое, а не тактическое). И то, что не смотря на поражение в войне буржуазная идея спустя 200 лет цветет и пахнет.
Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта
Замыкание — это такой базис, что более подходящий пример, что 2×2 — это термин «умножение». Может ли математик забыть термин «умножение»? Для этого необходимо зубрить?
Может ли математик забыть термин «умножение»
А программист?
Для математика аналогом «замыкания», скорее, будут термины: «поле», «кольцо» и т.д.
А что, если сеньор всю жизнь читал статьи про кложур и рекуршен, а замыкание – это термин из электротехники?
Ок. Какие свойства умножения Вы знаете? Хотя бы своими словами. Чур не копипастом из вики.
Я не математик же ж) Сходу вспомнил два — от перестановки множителей результат не меняется и при умножении любого числа на ноль получится ноль.
А если спросить у Senior-математика. Он должен знать ответ на этот вопрос? Или тоже может забыть?
А если спросить у Senior-математика. Он должен знать ответ на этот вопрос? Или тоже может забыть?
Я к тому, что тоже вроде примитив, но senior-математик знает об этой простой операции столько, что может проболтать всё собеседование (как раз упоминавшиеся поля, кольца и свойства умножения на них). А может сказать, «ну эта, а чего про него рассказывать», при
этом не задумываясь применяя эти свойства на практике.
Помнить формулировку из учебника и уметь применять — не одно и тоже.
этом не задумываясь применяя эти свойства на практике.
Помнить формулировку из учебника и уметь применять — не одно и тоже.
senior-математик знает об этой простой операции столько
Так какой ответ вы ожидаете от человека, который пришел на собеседование на позицию «senior-математик»?
Вы ожидаете, что он расскажет, что такое умножение, расскажет свойства, поля, кольца и все остальное?
Или ожидаете, что он скажет в духе автора статьи: «ну чо вы прицепились с определениями? я может и пользовался, но термин такой забыл»
Чуть ниже найдете ответ 0xd34df00d.
Возможно не стоит ожидать такого развернутого ответа на такой вопрос, но однозначно стоит ожидать его в случае наводящих вопросов в стиле «а всегда ли существует обратный элемент?».
Возможно не стоит ожидать такого развернутого ответа на такой вопрос, но однозначно стоит ожидать его в случае наводящих вопросов в стиле «а всегда ли существует обратный элемент?».
Вот с ходу, относительно предыдущего поста. TheShock с ходу сказал «от перестановки множителей результат не меняется». Вот тут человек, это совершенно очевидно, отлично умеет применять, но не помнит термин «коммутативность». При этом есть очень ненулевая вероятность услышать эту же формулировку в ответ на «Что такое коммутативность в умножении».
«Забыл точное слово» — это не вспомнить термин «коммутативность», и это может произойти от волнения и пофиг вообще чего. Не ответить «что такое коммутативность» для «сеньор-математика» непозволительно.
«Забыл точное слово» — это не вспомнить термин «коммутативность», и это может произойти от волнения и пофиг вообще чего. Не ответить «что такое коммутативность» для «сеньор-математика» непозволительно.
UFO just landed and posted this here
Только если умножение коммутативно в этой структуре.
Вы можете перестать подозревать меня в самозванстве и начать лучше собеседовать? Я senior-алгебраист, а вы у меня определения базовых терминов (о которых я уже забыл) спрашиваете.
Это следует из дистрибутивного закона и обратимости сложения.
x*0 = x*(1-1) = x — x = 0
x*0 = x*(1-1) = x — x = 0
Алгебраист гарантированно должен. Любитель теорий типов, наверное, тоже. Матстатистик совершенно не обязан.
Но вы же согласны, что ни один из них на вопрос «что такое коммутативность» не может сказать «да я все это знаю, только слово подзабыл»?)
Да ну, без знания термина для концепции замыкания нельзя программировать, как нельзя вообще заниматься математикой без того, чтобы знать, что такое умножение? Не выдумывайте. Еще одна некорректная аналогия.
Я не верю, что senior-математик может сказать «я забыл, что такое умножение», точно так же, как я не верю, что senior-javascript-developer может сказать «я забыл, что такое замыкание»
Вы какой-то абсурд сейчас написали.
Я утверждаю, что степень «элементарности» и «фундаментальности» терминов «умножение» для математики и «замыкание» для программирования различается на порядок. Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно. Заниматься математикой без умножения и знания этого термина — нельзя.
А вы мне возражаете так, будто я сказал, что это вещи одного порядка, но обе — не важны. Предлагаю вам внимательнее читать аргументацию прежде чем выдвигать абсурдные контр-аргументы на то, чего ваш оппонент не утверждал.
Я утверждаю, что степень «элементарности» и «фундаментальности» терминов «умножение» для математики и «замыкание» для программирования различается на порядок. Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно. Заниматься математикой без умножения и знания этого термина — нельзя.
А вы мне возражаете так, будто я сказал, что это вещи одного порядка, но обе — не важны. Предлагаю вам внимательнее читать аргументацию прежде чем выдвигать абсурдные контр-аргументы на то, чего ваш оппонент не утверждал.
Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно.
Но только не на «сеньорской» должности.
UFO just landed and posted this here
В контексте JS никогда не было норм без понимания замыкания.
habr.com/company/oleg-bunin/blog/424393/#comment_19174213Можете, пожалуйста, пояснить про проблемы?
0xd34df00d
Полнота по Тьюрингу не является чем-то заведомо хорошим. Например, полные по Тьюрингу системы типов имеют очевидные проблемы.
И привести пример полной по Тьюрингу системы типов (не очень себе представляю, что это по отношению к типам).
Предположим, я готов с вами согласиться именно в плане утверждения о сеньорской должности. Но для этого мне нужно услышать аргументацию, чего конкретно принципиально не может сделать senior developer, не зная этого термина.
Хотя, на самом деле, «замыкание» — это всего-навсего частный (пусть и иллюстративный) пример. А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
Хотя, на самом деле, «замыкание» — это всего-навсего частный (пусть и иллюстративный) пример. А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
Скажем так, даже если сеньор — узкоспециализированный специалист в языке, в котором замыкания, например, не имеют широкого применения, знать, что это за механика лучше, чем не знать.
Да и, собственно, как таковой сеньор, все же, должен знать хотя бы парочку языков, иметь опыт применения и некоторую экспертизу в сравнении. В конце концов, язык программирования — всего лишь инструмент. Мне, почему то, кажется, что сеньора, настоящего сеньора, отличает, в том числе, и умение выбрать наиболее подходящий под задачу инструмент.
Сеньор должен знать практики, паттерны, какие-то концепции за пределами устаканившихся в его экосистеме вещей, вероятно. Наработка практик в узкой специализации — это вопрос опыта, доступный миддлу. Мне кажется, что сеньор от миддла должен отличаться, например, знанием, в каких случаях от этих самых «лучших практик» можно отойти. Иначе чем он от миддла отличается?
В контексте беседы целиком обсуждается а) может ли C#-сеньор не знать о виртуальном наследовании, б) может ли JS-сеньор не знать о замыканиях. Ни то, ни другое, произвольными отдельными специфическими терминами в контексте обсуждения считаться не может. Ну вот никак.
Да и, собственно, как таковой сеньор, все же, должен знать хотя бы парочку языков, иметь опыт применения и некоторую экспертизу в сравнении. В конце концов, язык программирования — всего лишь инструмент. Мне, почему то, кажется, что сеньора, настоящего сеньора, отличает, в том числе, и умение выбрать наиболее подходящий под задачу инструмент.
Сеньор должен знать практики, паттерны, какие-то концепции за пределами устаканившихся в его экосистеме вещей, вероятно. Наработка практик в узкой специализации — это вопрос опыта, доступный миддлу. Мне кажется, что сеньор от миддла должен отличаться, например, знанием, в каких случаях от этих самых «лучших практик» можно отойти. Иначе чем он от миддла отличается?
А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
В контексте беседы целиком обсуждается а) может ли C#-сеньор не знать о виртуальном наследовании, б) может ли JS-сеньор не знать о замыканиях. Ни то, ни другое, произвольными отдельными специфическими терминами в контексте обсуждения считаться не может. Ну вот никак.
Но для этого мне нужно услышать аргументацию, чего конкретно принципиально не может сделать senior developerНе может быть senior developer.
произвольных отдельных специфических терминов.Раз за разом вы уводите в вообще другую степь.
производительность senior developerПроизводительность — единственное качество, необходимое для Senior Developer?
незнание произвольных отдельных специфических терминов.Вот тут самая главная ошибка. Не «незнание произвольных отдельных специфических терминов». А «незнание базовых концепций языка». Вот представьте, что C++ Senior Programmer забыл термин «Компиляция». Подумаешь, какой-то специфический термин. Или Java Senior Programmer забыл термин «Garbage Collector». Знание произвольных отдельных специфических терминов не нужно для senior-программиста!
Суть не в том, сможет ли сферический senior в вакууме, который не знает этих терминов выдавать результат такого же качества, как и программисты, которые знают эти термины.
Суть в том, что если на собеседование приходит человек, который утверждает, что он senior-программер, а на деле не слышал о основных концепциях его языка — возникает обоснованное сомнение в его чесности.
UFO just landed and posted this here
Ну под «забыл» имеется ввиду «забыл, что значит этот термин». Вот говоришь ему «компиляция», а он не может понять о чем ты
UFO just landed and posted this here
И таких определений в вашей голове — тысячи и десятки тысяч.
То есть у Senior C++ программиста при слове «компиляция» сразу вспоминается тысячи определений кроме того, что связано с его языком?
UFO just landed and posted this here
А Вы можете подробно рассказать как прошел ваш день ровно 5 лет и 4 месяца назад?
А вы можете сказать, кто был четвертой женщиной Александра Македонского? Хотите продолжить играть в игру «придумай глупую аналогию, которая не относится к теме»?
Дальше, Гипертимезия — вообще не в кассу, мы ведь не спрашиваем у человека, что он делал 5 лет назад. И Жамевю — тоже не в кассу. Даже дежавю встречает слишком редко (как много человек испытывают чувство дежавю именно на собеседовании? и я про настоящее дежавю, а не псевдодежавю похожих ситуаций, когда просто много собеседований сливается в одно). Так вот — Жамевю встречается еще значительно реже.
«На кончике языка» — тоже не в тему. Слово вспоминать не надо, его тебе называют. К примеру, «Компиляция». Вот и все «на кончике языка» уже не подходит.
Сколько вам нужно привести ссылок, чтоб донести простую мысль — иногда у людей из головы вылетает самое очевидное?
Ну, очевидно, больше нуля ссылок по теме. А то я тоже могу так накидать. Первая, вторая, третья. Видите, сколько я вам уже ссылок накидал, которые доказывают, что вы — неправы?
Хотя пару часов назад это определение от зубов само отскакивало
Та при чем здесь определение? Никогда никогда не требует книжного определения, не впадайте в крайности. Если у человека есть понимание, то он не забудет слово. Проблемы на экзаменах именно из-за зазубривания. Простите, но человек, который называется сеньйором я который не понимает, а зазубривает определения базовых терминов — не нужен команде
Чего уж говорить о том, что человек может знать, но редко использует ибо банально ему это конкретно было в явном виде не нужно (не про компиляцию, а про пример из статьи).
Для Senior JS Developer незнание понятия «Замыкание» недопустимо. По моему мнению, как и незнание понятия virtual для Senior C#-девелопера. Увы, я в этом языке далеко не senior, но я так считаю.
Вы же сейчас приведете пример успешного математика, не знающего, что такое умножение?
Забавно, что два человека одинаково поленились понять мою аргументацию и выдвинули одинаково абсурдные контр-аргументы. Ответил выше.
Надёжно помнят это не те, кто зазубривает, а те, кто это всё своими руками прощупал, осознал, проанализировал, покрутил в разных вариантах и в мозг положил в рабочий арсенал. То есть хорошие программисты. Вопрос в том, действительно ли на ту позицию был нужен такой вот хороший программист, или достаточно было бы обычного.
Надёжно помнят это не те, кто зазубривает, а те, кто это всё своими руками прощупал, осознал, проанализировал, покрутил в разных вариантах и в мозг положил в рабочий арсенал. То есть хорошие программисты.
Хороший программист — это в первую очередь тот, кто все это благополучно забудет, если не использовал сколько-нибудь продолжительное время. Допустим, замыкания в принципе — они теперь везде, тут забыть сложно, но к чему помнить особенности того, как в js работает this в замыканиях, если уже год на js не пишешь? Да ни к чему, это не знания — это мусор. А мусор надо убирать.
На мой взгляд это ошибочное утверждение, вы можете понять как работает, но не связать название с механизмом.
Понимаете ли какое дело, к программисту нельзя предъявлять таких же требований как скажем к слесарю. Ибо у него область компетенции порой просто необъятна. Взять последний мой проект. Железка — на верилоге. Тесты — на яве. Клиентская библиотека — на С++. Морда лица всего этого безобразия — джаваскрипт в броузере. Плюс схематика и разводка для железке делалась в eagle. И этот проект ещё далеко не самый сложный, на пару месяцев! И программёр я далеко не уникальный, так, крепкий сеньёр, не более. И всё перечисленное мне пришлось «пощупать руками» в ходе одного проекта… Не мудрено, что если меня будут спрашивать о каких-то пыльных углах какого-то из этих инструментов, я поплыву как нерадивый студент. Но если мне надо будет в этом разобраться, сделаю это очень быстро. Самый умный начальник, которого я в жизни знал, любил говорить так (за точность цитаты не ручаюсь, ибо было это 18 лет назад, но смысл сохранен) — «Мне не нужны те кто всё знает, ибо всё знать невозможно. Мне нужен тот, который ничего не знает, но дай ему задачу, через неделю принесёт пусть грубое, но решение».
Как бы вы выбирали, какого кандидата принять на работу если надо закрыть вакансию?
А так бы и выбирал, как мой самый умный начальник, респектище и уважуха ему во веки веков, аминь. Дал бы совершенно практическую задачку. Связанную с будущей работой, хотя и элементарную. И поглядел бы как чел справится. Впрочем есть вариант. Дать в качестве задачки полную херню и ахению, однако требующую серьёзной разработки своего собственного алгоритма. Поскольку задачка полная херня и ахения, в тырнетах чел решения явно не найдёт. Тем интересней будет ЧТО он придумает… Один раз мне такое попадалось. Во избежание косвенной рекламы, опущу подробности.
UFO just landed and posted this here
что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта
Нет, она называется уравнением Пауссона. Закон Бойля-Мариотта описывает изобарный процесс. Пара минут Гугла;)
Проблема в том, что много вещей невозможно «подсмотреть» если не знать как они хоть приблизительно называются.
Так вот термин — это факт, который ни с чем не связан, это просто название, которое нельзя «вывести», его можно только запомнить. Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта.
Вот тут стоит признать, что вопрос был «что такое <термин>», а не «каким термином называется вот это». И вот тут ситуация начинает играть другими красками. Не «как называется формула, описывающая термодинамический процесс и т.д.», а «в чем суть закона Бойля-Мариотта». Разные несколько вопросы, не правда ли?
а «в чем суть закона Бойля-Мариотта». Разные несколько вопросы, не правда ли?
Да одно и то же, можно прекрасно помнить закон и уметь его применять, но при этом в упор не помнить, что он Бойля-Мариотта. Любой человек, который матфак окончил, знает на подкорке кучу всяких лемм/теорем из первого курса матана, на уровне формулировки фактов и даже доказательства вам накидает. Но сомневаюсь, что вспомнит хотя бы для половины названия, или саму формулировку по названию. Вот если вы скажите о чем там в общем, другое дело.
Плюсануть, к сожалению, не могу, но у вас один из самых толковых комментариев! Я учился дважды, но последний раз это было уже почти 12 лет назад, а первый 21. Я программирую с 1992 года. Многие определения я помню еще, но далеко не все. Можно еще в С++ спрашивать с какой версии в лямбдах происходит захват *this? Или с какого билда VS 2017 intellisense будет корректно отображать Structured bindings. Но это нужно только для ЧСВ. Кому надо это быстро нагуглят. Скажу честно, но меня ни разу не собеседовали по терминам или алгоритмам, и я, кстати, тоже! Какие-то определения можно спрашивать вчерашнего студента, у которого может не быть портфолио, но не сеньера…
Как говорил мой препод 25 лет назад — зачем мне помнить определения/константы, если у меня есть справочник, в котором это всё написано? Мне надо знать КАК это работает.
А так же это очень хорошая отмазка на любое незнание.
Поди со стороны разгляди.
Поди со стороны разгляди.
Есть только один способ выяснить что человек знает в какой-то области — заставить его сделать нужное. Дайте человеку тестовую задачу и посмотрите как он её решит. А потом ещё есть и испытательный срок. Я видел дофига людей точно оперирующих определениями (выучили, благо список вопросов и ответов в интернете на любой вкус), но нихрена не понимающих о чём вообще они говорят.
Когда я ещё учился в школе в 10 классе, мы писали «контрольные» работы, которые засчитывались в определённом ВУЗе (договор был). В одной из задач по физике я забыл значание константы Больцмана. Я «решил» задачу и в качестве ответа вписал формулу, в которой фигурировала эта константа. И дописал «ответ не получен, так как преподаватель отказался сообщить значение константы».
На разборе эту задачу мне засчитали как полностью решённую, потому что знать наизусть все константы — это не цель этих контрольных. Главное — умение решать задачи. А если подставить верное значение константы, то и ответ становился верным.
Мораль: да, надо смотреть со стороны. Если «не знание» — это повод что-то не делать, то это — плохо. В противном случеае, «не знание» чего-то очень *конкретного* не означанет не знание предмета/задачи.
На разборе эту задачу мне засчитали как полностью решённую, потому что знать наизусть все константы — это не цель этих контрольных. Главное — умение решать задачи. А если подставить верное значение константы, то и ответ становился верным.
Мораль: да, надо смотреть со стороны. Если «не знание» — это повод что-то не делать, то это — плохо. В противном случеае, «не знание» чего-то очень *конкретного* не означанет не знание предмета/задачи.
Эйнштейн как-то сказал что он намеренно забыл скорость звука тк может найти её в любом справочнике.
Среди программистов чаще встречается «я не теоретик, я практик, мне все равно как оно называется, уж я-то все сделаю как надо». И это очень тревожный звоночек со стороны нанимателя. Нет, конечно сделает. Кто же спорит. Вот только хотелось бы поменьше костылей в проекте, больше общеиспользуемых решений и поменьше костылей…
От балды легче… ибо тензорный анализ напрягает умы упругих программистов.
Он может и забыть сколько будет 71x34. А третьекласник, владеющих искусством быстрого счёта его обгонит.
Нормальный вопрос. Ну не может сеньор не знать что такое замыкание или virtual. И не важно какой религии он придерживается, такие вещи просто невозможно не знать. Если не сеньор, то кто же тогда?
UFO just landed and posted this here
Ну не может сеньор не знатьЭта фраза выглядит вполне правдивой в её тяжкой непреклонности, если бы не одно но. Что значит "не знать"?
В моём понимании не знать чего-то, например не знать как, допустим, варить железо, это если человека оставить одного в комнате со сварочным аппаратом и заготовкой, хоть через час хоть через день он не сможет её сварить, хоть убей. А если и сможет, то очень криво и непрочно. Проще говоря: не справится с задачей. Он не готов к трудоустройству на должность
А если автора оставить одного с чужим кодом в котором есть ключевое слово virtual и попросить код модифицировать согласно таске, он справится или нет? Я думаю ему и дня не понадобится, да что там, и часа. Даже если он запамятовал, 20-гуглинг с чтением коммента на стэковерфлоу заставит его хлопнуть по лбу «ах да, я же встречался с этим» и приступить к решению задачи. Думаю 20 секунд рабочего времени для начальника этого разработчика не такая уж большая цена за незнание?
Так ли сурово можно продолжать считать такого разработчика непригодным к работе сеньор сварщика кода?
Ну, мне вот кажется, что с virtual вы немного лукавите.
Если разработчик не вспомнил сам вполне себе базовую механику языка, вероятно, он именно «встречался» с этим, и уж точно не использует эту механику на регулярной основе. А это, при наличии уже существующего, вероятно, достаточно большого проекта, где виртуальное наследование во все поля применяется, кхм… ну, чревато, как бы. Вопрос именно что не в том, знаете ли вы этот термин, а в том, что, имей вы практику применения (а она реально важнее знания терминологии), вы бы вряд ли забыли, что означает вполне себе конкретное ключевое слово в языке.
В общем и целом, ваше «а вот virtual я не помню» говорит, с очень большой долей вероятности, о том, что лично вы его не применяете. С учетом специфики существующего кода вместо сеньор-разработчика, который будет выполнять поставленные задачи, вполне можно получить саботера, который будет вместо работы убеждать джунов/миддлов в том, что «виртуальное наследование — зло», и «за композицией будущее». Ну, либо человека с сеньорской зарплатой и отдачей на уровне миддла…
Даже если он запамятовал, 20-гуглинг с чтением коммента на стэковерфлоу заставит его хлопнуть по лбу «ах да, я же встречался с этим» и приступить к решению задачи.
Если разработчик не вспомнил сам вполне себе базовую механику языка, вероятно, он именно «встречался» с этим, и уж точно не использует эту механику на регулярной основе. А это, при наличии уже существующего, вероятно, достаточно большого проекта, где виртуальное наследование во все поля применяется, кхм… ну, чревато, как бы. Вопрос именно что не в том, знаете ли вы этот термин, а в том, что, имей вы практику применения (а она реально важнее знания терминологии), вы бы вряд ли забыли, что означает вполне себе конкретное ключевое слово в языке.
В общем и целом, ваше «а вот virtual я не помню» говорит, с очень большой долей вероятности, о том, что лично вы его не применяете. С учетом специфики существующего кода вместо сеньор-разработчика, который будет выполнять поставленные задачи, вполне можно получить саботера, который будет вместо работы убеждать джунов/миддлов в том, что «виртуальное наследование — зло», и «за композицией будущее». Ну, либо человека с сеньорской зарплатой и отдачей на уровне миддла…
Вот вы тут поучаете, а что такое «виртуальное наследование»? В С++ это особое наследование, со своей семантикой. И гуглить нужно в направлениие «Multiple inheritance» & «diamond of death»
UFO just landed and posted this here
В своей жизни сталкивался всего несколько раз: один раз это было в году 96-98, тогда писали на Borland С++ и там была заморочка с наследованием от TObject, еще раз относительно недавно, когда делал code review для проекта, и это было меньшее из зол при уходе от void* на все что можно. Было еще пару раз, но уже и не вспомню. А вообще я не фанат виртуального наследования.
Дорогой мой человек, вот и я же ровно о том же! Если человек, собеседующийся на позицию сеньора на С++, он должен знать, что такое «виртуальное наследование». Это базовая вещь языка, часть спецификации. И «я слово забыл» — хреновая отмазка. Вы вот прямо говорите «В С++ это особое наследование, со своей семантикой». Вот если вас при собеседовании на позицию сеньора спросят, как называется «особое наследование, со своей семантикой в С++», а вы сходу не вспомните слово «виртуальное» — это нормально, это просто слово подзабыл, вы красавец, а тот, кто собеседует — клинический кретин. Однако когда вас (опять же, помним, что вы на сеньора собеседуетесь) просят объяснить на пальцах, что такое виртуальное наследование, а вы «забыли формулировку» — брать вас на работу не стоит.
Вы же, предположительно, еще и в команде работать будете. Сеньоров, обычно, в вакуум не берут. Вам же еще и коммуникативные навыки понадобятся. Да и предполагается, что рядом могут сидеть миддлы или, простихоспади, джуны, которые за советом, в случае чего, пойдут, вероятно, к сеньору. Так ведь? Придет вот эдакий джун к вам-сеньору, и скажет, я тут виртуальное наследование намутил, а что-то не работает, помоги разобраться. А ты сидишь, эдакий сеньор-помидор, и ни слова не понимаешь в том, что тебе джун говорит, у тебя там своя личная устоявшаяся терминология. Ну и нафига ты такой красивый нужен?
Вы же, предположительно, еще и в команде работать будете. Сеньоров, обычно, в вакуум не берут. Вам же еще и коммуникативные навыки понадобятся. Да и предполагается, что рядом могут сидеть миддлы или, простихоспади, джуны, которые за советом, в случае чего, пойдут, вероятно, к сеньору. Так ведь? Придет вот эдакий джун к вам-сеньору, и скажет, я тут виртуальное наследование намутил, а что-то не работает, помоги разобраться. А ты сидишь, эдакий сеньор-
Может я не совсем понял о чем речь… Для меня определение — это то что написано в «книжке». А вот если человек претендует на сеньера С++ и не знает таких вещей (хотя бы своими словами), то это не очень хорошо. Может мне по жизни везло, но мне не очень часто приходилось отвечать на вопросы: что такое класс. Или чем класс отличается от объекта. Восновном, если и был разговор по языку, то какие-то редко используемые вещи, ну или что-то не совсем очевидное. Если бы меня спросили такие вопросы, то я бы ответил, но в такой фирме работать не стал…
Собственно, и я говорю о том, что человек, претендующий на позицию сеньора в C++ не может не ответить на вопрос, что такое «virtual». И нет никакой приемлемой отмазки, почему он на собеседовании не смог своими словами дать описание этой механики. Собственно, для джуна еще как-то может «прокатить», но даже для миддла не объяснить смысл этой механики на собеседовании — признак того, что и на «крепкого миддла» точно не тянет.
А в цепочке обсуждения до поста, да и в исходной публикации описана ситуация, когда весь такой крутой «сеньор» ответил на «стопицот» коварных вопросов хамоватого собеседователя, а на вопрос «что такое virtual» ответить не смог, т.к. он «позабыл слово» и «вообще наследование зло, а в компании ничего не понимают». В итоге, типа, «крутого профессионала» отсеяли на собеседовании просто потому, что он «подзабыл слово».
Ну ведь чушь же. Человек просто сам завалил собес, перевернул с ног на голову, и теперь пришел пожаловаться на «некомпетентность собеседующего».
А в цепочке обсуждения до поста, да и в исходной публикации описана ситуация, когда весь такой крутой «сеньор» ответил на «стопицот» коварных вопросов хамоватого собеседователя, а на вопрос «что такое virtual» ответить не смог, т.к. он «позабыл слово» и «вообще наследование зло, а в компании ничего не понимают». В итоге, типа, «крутого профессионала» отсеяли на собеседовании просто потому, что он «подзабыл слово».
Ну ведь чушь же. Человек просто сам завалил собес, перевернул с ног на голову, и теперь пришел пожаловаться на «некомпетентность собеседующего».
но даже для миддла не объяснить смысл этой механики на собеседовании
Ну не об этом же разговор. Разговор о том, что человек не связал слово "виртуал" с известной ему механикой.
Чтобы "не объяснить смысл механики" надо чтобы обе стороны поняли, про какую именно механику задан вопрос.
Погодите-погодите.
Прямо из статьи:
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Вы искренне считаете, что на собеседовании по C# есть место двум разным пониманиям базового синтаксиса одного и того же языка? Т.е. собеседующий подразумевает, мол virtual void methodName(), а собеседующийся настолько заметался в выборе возможных для контекста беседы толкованиях virtual, что аж ни одного сформулировать не смог?
Прямо из статьи:
Senior full-stack .NET Developer
Что такое virtual?
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
надо чтобы обе стороны поняли, про какую именно механику задан вопрос
Вы искренне считаете, что на собеседовании по C# есть место двум разным пониманиям базового синтаксиса одного и того же языка? Т.е. собеседующий подразумевает, мол virtual void methodName(), а собеседующийся настолько заметался в выборе возможных для контекста беседы толкованиях virtual, что аж ни одного сформулировать не смог?
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Гражданин упирает на то, что не использует наследование.
Гражданин, претендующий на позицию сеньора в ООП-языке имеет право не использовать наследование, да. Но право указанного гражданина не знать/не помнить, что это такое — позвольте поставить под сомнение.
Он же, вроде, по специфике «сеньорства» не только писать код должен, но еще и читать. При этом не только свой — на то он и сеньор. А ключевые слова языка для него — алфавит. Вы же не станере брать ликтором человека, который «отлично весь алфавит помнит, а вот букву Ы подзабыл, но она не нужна, он все равно ее не использует».
Он же, вроде, по специфике «сеньорства» не только писать код должен, но еще и читать. При этом не только свой — на то он и сеньор. А ключевые слова языка для него — алфавит. Вы же не станере брать ликтором человека, который «отлично весь алфавит помнит, а вот букву Ы подзабыл, но она не нужна, он все равно ее не использует».
Я с вами полностью согласен. Просто уточнил.
Гражданин, претендующий на позицию сеньора в ООП-языке имеет право не использовать наследование, да.
Погодите, погодите! А интерфейсы он тоже не использует? Ведь вызов реализованного метода интерфейса — он тоже виртуальный.
Но слово virtual же не пишется в таком случае? :-)
А при чем тут наследование?
Вот кстати мне лично интересно как вопрос задан был. Например спросили про «ключевое слово виртуал», или просто виртуал или же виртуал?
Тут стоить отметить что хоть и не по моей это специальности, но в первых двух вариантах я бы скорее всего правильно связал понятие со смыслом, а вот в последнем была бы вероятность что затупил бы.
Тут стоить отметить что хоть и не по моей это специальности, но в первых двух вариантах я бы скорее всего правильно связал понятие со смыслом, а вот в последнем была бы вероятность что затупил бы.
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Не совсем. Человек в нестандартной ситуации, когда внимание отвлекается различными психологическими и информационными факторами, за отведенные ему несколько секунд не связал слово, произнесенное вслух звуками "виртуал", с известной ему механикой, которой он редко пользуется. Не успел выбрать из всего набора существующих в C# механик ассоциацию с переопределением метода. То, что он знаком с наследованием, следует из правильного ответа на вопрос "что такое protected internal".
Такими вопросами можно проверить только быстроту ассоциаций. Чтобы проверить умение пользоваться, надо дать задачу или попросить привести пример. Если на вопрос "Приведите пример переопределения метода в наследнике" человек напишет код со словом "virtual", значит он знает, зачем оно нужно, даже если его нет в вопросе.
Если на вопрос «Приведите пример переопределения метода в наследнике» человек напишет код со словом «virtual», значит он знает, зачем оно нужно, даже если его нет в вопросе.
Возьмём для примера C++. А если он переопределит метод без слова virtual, будет ли это значить, что он его не знает/не умеет использовать?
Зачем брать C++, если разговор про C#, и пример будет на нем? Давайте тогда PHP возьмем, там на virtual вообще ошибка синтаксиса будет.
Я C++ взял, так как думаю, что больше людей его понимают.
Хорошо, пусть будет C#. Вам это уйти от вопроса всё равно не позволит.
Сам вопрос:
А если он переопределит метод без слов virtual/override, будет ли это значить, что он их не знает/не умеет использовать?
Хорошо, пусть будет C#. Вам это уйти от вопроса всё равно не позволит.
Сам вопрос:
А если он переопределит метод без слов virtual/override, будет ли это значить, что он их не знает/не умеет использовать?
Насколько я знаю, в C# нельзя переопределить метод в наследнике, если в родителе он не объявлен как virtual.
Я, конечно, извиняюсь, но Вас бы на должность C# сениора (да что там, даже мидла), я бы не взял :(
А я и не позиционирую себя как C# разработчик, даже как джуниор.
Извиняться не надо, надо приводить аргументы. Но если вы имеете в виду такую программу:
class A {
public int f() { return 1; }
}
class B: A {
public int f() { return 2; }
}то она выдает предупреждение
warning CS0108: "B.f()" скрывает наследуемый член "A.f()"
и работает не так, как с переопределением.
Извиняться не надо, надо приводить аргументы.
Аргумент то простой: вы не знаете, что функцию можно переопределить в наследнике и без virtual. И про ключевое слово new тоже даже не слышали, раз уж вопрос про предупреждение встал.
и работает не так, как с переопределением.
Для вас переопределение — это обязательно когда virtual? Если так, то я бы тогда вас и на вакансию C++-программиста тоже бы не взял :(
А я бы не взял вас. Потому что переопределение и сокрытие методов — это два сильно разных механизма и смешивать их нельзя ну вот совсем никак.
А вот это уже вопрос терминологии пошёл. В оригинале да, термины extend и hide. Но в русском переопределить не часто говорят в смысле extend. Чаще и в том и в другом, особенно в плюсах. Кстати, русскоязычный MSDN переводит их как разворачивание и скрытие.
В C# метод в производном классе может иметь то же имя, что и метод в базовом классе. Можно задать способ взаимодействия методов, воспользовавшись ключевыми словами new и override. Модификатор override разворачивает метод базового класса, а модификатор new скрывает его. В примере в этой теме показана эта разница.
Русскоязычный MSDN — та еще помойка с машинным переводом.
Однако в конкретно указанном случае virtual/override и new — действительно разные механизмы.
Кстати, конкретно в этой статье, откуда я привёл цитату нет обычной пометки, что это машинный перевод. Да и сам текст высокого качества, что указывает на ручной человеческий перевод. Так что всё дело в привычке скорее всего.
Процитированный вами фрагмент я бы не понял если бы не знал о чем он и не видел перевода на английский.
Что значит «разворачивание» метода? Он как бы в базовом классе был свернут, а в производном его развернули? А можно ли метод развернуть два раза? Должен ли он быть для этого дважды свернут?
Что значит «разворачивание» метода? Он как бы в базовом классе был свернут, а в производном его развернули? А можно ли метод развернуть два раза? Должен ли он быть для этого дважды свернут?
Можно ведь открыть студию и убедиться, что поведение принципиально разное, а не показывать всем свою необразованность? А потом пойти и почитать почему оно разное.
Я вот на всякий случай сходил и проверил — gist.github.com/retran/9f4dc4c359d8e91d163e2452a642863c
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Я вот на всякий случай сходил и проверил — gist.github.com/retran/9f4dc4c359d8e91d163e2452a642863c
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Я и без вас уже N лет знаю, что поведение разное. Зачем вы мне это говорите? Что вы хотите этим показать.
Если вы ещё до сих пор не поняли, что произошла терминологическая путаница, то извиняюсь, но вы глупы :(
Ещё раз я знаю и использую и new и virtual/override. И да, я не считаю это переопределением, я считаю это extends (а кто догадался вообще extends перевести как переопределить?).
Если вы ещё до сих пор не поняли, что произошла терминологическая путаница, то извиняюсь, но вы глупы :(
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Ещё раз я знаю и использую и new и virtual/override. И да, я не считаю это переопределением, я считаю это extends (а кто догадался вообще extends перевести как переопределить?).
А можно источники вашей терминологии посмотреть?
Я, конечно, глупее вас, и первый раз слышу, чтобы extends употреблялось по отношению к методам в контексте наследования (и не extension method'ам, которые вообще про другое), а не классам.
UPD Я вот сейчас погуглил, нашел такую формулировку только в одной единственной статье про C# в MSDN.
Я, конечно, глупее вас, и первый раз слышу, чтобы extends употреблялось по отношению к методам в контексте наследования (и не extension method'ам, которые вообще про другое), а не классам.
UPD Я вот сейчас погуглил, нашел такую формулировку только в одной единственной статье про C# в MSDN.
Если вас интересует именно моя терминология, то я называю это «замещать» от override, как мы всегда называем это в плюсах и «скрывать» от hide (ну и «переопределить» (переопределить с замещением, переопределить со скрытием) применительно к обоим). Вроде как это общепринятые обозначения, других и не слышал никогда (если не считать «оверрайдит»). Если вам прямо нужен источник-источник, вот только что в другом комментарии отвечал, что так (override/замещает) написано в канонах C++ (C++ Programming language), пусть тогда это и будет источником.
Если вас интересует официальная терминология по C#, то она из шарповой документации, вы же сами ссылку на неё приводили. Откуда они придумали extends/расширяет и почему не взяли override/замещает — это к ним вопрос.
Если вас интересует официальная терминология по C#, то она из шарповой документации, вы же сами ссылку на неё приводили. Откуда они придумали extends/расширяет и почему не взяли override/замещает — это к ним вопрос.
Господа, чтобы не замусоривать далее топик, я извиняюсь, что хотел «подколоть» уважаемого michael_vostrikov на тему того, что мне (будем считать что) показалось, что он не знает про hides. К сожалению, будем считать, что из-за терминологической путаницы, мы друг друга просто не поняли. И предлагаю дальше эту тему не развивать.
Собственно, new, вроде как, про перекрытие метода, а не про переопределение. Поведение будет разное. И, собственно, эти нюансы сеньор должен знать. Т.е. без знания того, что такое virtual/override, new (в контексте метода) и в чем разница на должность сеньора претендовать нельзя.
Давайте, что бы не было путаницы, скажем так:
Собственно, new, вроде как, про hide метода, а не про extend. ...
И полностью с вами соглашусь.
Так как первый раз в живую слышу, что кто-то вместо замещения метода(в С++) и расширения метода (в C#) говорил об этом как общее «переопределение». Уж, со сколькими людьми общался, и за пределами рабочего коллектива (за последние 2 месяца почти 40 людей только на интервью посмотрел), все как и обычное «скрытие», да и виртуальное замещение в плюсах называют просто «переопределил». А тут на тебе…
Собственно, new, вроде как, про hide метода, а не про extend. ...
И полностью с вами соглашусь.
Так как первый раз в живую слышу, что кто-то вместо замещения метода(в С++) и расширения метода (в C#) говорил об этом как общее «переопределение». Уж, со сколькими людьми общался, и за пределами рабочего коллектива (за последние 2 месяца почти 40 людей только на интервью посмотрел), все как и обычное «скрытие», да и виртуальное замещение в плюсах называют просто «переопределил». А тут на тебе…
Ну, собственно, тут мы до «нюансов принятой в экосистеме терминологии» дошли уже. Тем более не вижу смысла спорить о формулировках, т.к. ни синьором, ни даже миддлом в C# не являюсь.
Просто я про то говорю, что раз уж даже мне, человеку весьма постороннему, навскидку видна разница между virtual/override и new, может ли человек, претендующий на «сеньорство» в области «забыть» или «затрудниться ответить». Вот и мне кажется, что нет.
Просто я про то говорю, что раз уж даже мне, человеку весьма постороннему, навскидку видна разница между virtual/override и new, может ли человек, претендующий на «сеньорство» в области «забыть» или «затрудниться ответить». Вот и мне кажется, что нет.
Собственно, new, вроде как, про перекрытие метода, а не про переопределение.
Помню, как запутался в коде cms, в управлении плагинами. Методы были определены под именами: renew, refresh, reload, update… Там даже синьоры путались )
Аргумент то простой: вы не знаете, что функцию можно переопределить в наследнике и без virtual.
Это не аргумент, а необоснованное утверждение. Аргументом был бы приведенный вами пример такого переопределения.
Я знаю, что понятие "переопределение" в языке C# имеет вполне конкретное значение и задает вполне конкретное поведение кода, касающегося реализаций в родителе и в наследнике, и это поведение отличается от скрытия. Вы не сможете добиться, чтобы код без virtual во всех случаях работал точно так же, как с virtual.
Здесь описаны отличия, прочитайте и обратите внимание на примеры:
Knowing When to Use Override and New Keywords
Отличия переопределения метода от перекрытия
В следующий раз, прежде чем переходить на личности, потрудитесь изучить обсуждаемый вопрос. Если PHP-шник знает о C# больше вас, это повод подтянуть свои знания.
Вы не сможете добиться, чтобы код без virtual во всех случаях работал точно так же, как с virtual.
В том и вопрос, что вы должны знать, чем поведение «кода без virtual» от поведения «кода с virtual» отличается. Иначе какой вы сеньор?
Ну а я знаю, что «Я знаю, что понятие extends (а кто догадался вообще extends перевести как переопределить?) в языке C# имеет вполне конкретное значение и задает вполне конкретное поведение кода, касающегося реализаций в родителе и в наследнике, и это поведение отличается от скрытия (или перекрытия, как qrKot это называет?) hides.»
А приводить ссылку на статью, из которой я уже приводил цитату — это очень оригинально.
Ну как бы я пока не вижу, чтобы вы знали, что-то больше меня. Вижу, что мы говорили об одном и том же разными русскими терминами. Что для меня «переопределена» это когда функция просто переопределена (без разницы с замещением или со скрытием), а для вас этот же термин значит только тот случай, когда она замещена (от override).
И почему вообще повод? Я себя в шарпах даже джуном не считаю, я всё-таки плюсовик :) Когда есть время и возможность я и без повода что-нибудь на шарпах изучаю.
А приводить ссылку на статью, из которой я уже приводил цитату — это очень оригинально.
В следующий раз, прежде чем переходить на личности, потрудитесь изучить обсуждаемый вопрос. Если PHP-шник знает о C# больше вас, это повод подтянуть свои знания.
Ну как бы я пока не вижу, чтобы вы знали, что-то больше меня. Вижу, что мы говорили об одном и том же разными русскими терминами. Что для меня «переопределена» это когда функция просто переопределена (без разницы с замещением или со скрытием), а для вас этот же термин значит только тот случай, когда она замещена (от override).
И почему вообще повод? Я себя в шарпах даже джуном не считаю, я всё-таки плюсовик :) Когда есть время и возможность я и без повода что-нибудь на шарпах изучаю.
Перекрыть, вроде, можно.
public new void MethodName() {}
Собственно, про то, видимо, и вопрос был, чем переопределение виртуального метода от перекрытия в наследнике отличается.
public new void MethodName() {}
Собственно, про то, видимо, и вопрос был, чем переопределение виртуального метода от перекрытия в наследнике отличается.
То, что он знаком с наследованием, следует из правильного ответа на вопрос «что такое protected internal».
А знание модификаторов доступа к членам класса, простите, каким образом свидетельствует о том, что человек знаком с понятием «наследование»?
Доступ к защищенному элементу может быть получен из соответствующего класса, а также экземплярами производных классов.
Из этого определения следует, что человек наслышан о понятии «наследование». Мы же предполагаем, что человек уровня сеньора сможет не только сказать «наследование — зло», но и обосновать свою позицию, объяснить почему он так считает. А тут получается, что познания человека о наследовании заканчиваются на моменте «я слышал, что есть такая штука, но где-то в интернете читал, что так делать нехорошо». Странная позиция для соискателя на вакансию сеньора, вы не находите?
каким образом свидетельствует о том, что человек знаком с понятием «наследование»?
Из этого определения следует, что человек наслышан о понятии «наследование»
Наслышан — По слухам хорошо знаком с кем-чем-нибудь
Давайте не будем играть словами. protected связан с наследованием, это факт. Тем более что мы не знаем, насколько развернутым был ответ автора.
объяснить почему он так считает
А ему кто-то такой вопрос задавал? Автор сам пишет, что считает его более важным.
В том и дело, что такие вопросы как в статье на самом деле не показывают умение пользоваться.
Тем более что мы не знаем, насколько развернутым был ответ автора.
В том то и дело, что мы не знаем, насколько развернутым был ответ автора, можем только предполагать, что он что-то связное ответил (и где гарантия, что он не ответил заученной формулировкой с MSDN).
Что мы знаем (со слов самого автора), это то, что он «посыпался» на вопросе «Что такое virtual».
Т.е. в сухом остатке автор не смог ответить на вопрос, что такое virtual, в чем сам и признается. А это — неиллюзорный повод предположить, что в вопросе наследования автор плавает, что автоматически делает его слабым кандидатом на сеньорскую позицию.
UFO just landed and posted this here
Для того чтобы за 20 секунд понять что означает ключевое слово virtual, надо знать как работает динамический полиморфизм. Понимать чем отличается статический тип переменной и класс объекта на который она ссылается.
И да, существуют программисты которые этого не знают и не понимают.
И да, существуют программисты которые этого не знают и не понимают.
А когда на senior-позицию приходят полные нули, что делать? Знакомый фронтендер периодически собеседует людей на позицию senior-ов. Люди говорят/пишут, что у них 3-5-10 лет опыта, но они не знают концепции замыканий.
ИМХО, это очень хороший вопрос, чтобы быстро отсеять всяких неадекватов, при условии, что он задаётся не HR, и не ради самоутверждения.
К тому же, это ещё и хороший вопрос для отсеивания неадекватных работодателей: если после моего ответа начинают просить что-то там реализовать на бумажке, то начинаю задумываться, а надо ли мне тут работать.
Ну, к слову, нужно уточнять про какие технологии речь идет. Например в нашем отделе (1с, многие код пишут уже по 5 лет, и по меркам 1с неплохой код и действительно крупные проекты) — когда я коллегам в чатик скинул свой краткий обзор плюшек дарта и флаттера — единственная реакция которой я добился (хотел заинтересовать, может кто со мной бы начал дома на них что то изучать и пилить) — это: что ты там написал? Что за замыкания? Что за вывод типов? Все. При этом, как я уже выше писал, в своей сфере мы считаемся пусть не топовой компанией, но не хухры-мухры.
Безусловно, когда человек занимался чем-то совсем другим, а потом меняет сферу деятельности, незнание некоторых вещей можно простить. Например, сейчас многие переходят во фронт из бэка (по крайней мере, часто собеседовал таких людей). В таком случае можно забить на неумение верстать, или незнание, например, особенностей работы промисов. Я в таких случаях просто задаю другие вопросы. В конце концов, есть есть фундамент, особенностям js обучаешься быстро.
Но когда люди вроде как много лет именно во фронтенде (и заявляют об этом чуть ли не с гордостью), и у них спрашиваешь про банальные замыкания, а они не могут ответить, то это печально.
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
На счет промисов — тут есть конечно нюансы, ввиду синхронности js, но мое отношение к промисам также негативное (работу кончено не пойдет искать, но прослушает двухчасовую беседу о том, как разбивать задачи на минимальные составляющие для обеспечения стабильности и прозрачности работы кода).
Но саму возможность использования промисов, в каких-то непонятных, внеземных проектах, я конечно не отрицаю. Как по мне, промисы в js придумал какой-то редкий м....., который ранее работал в глубоком бэкенде, на c++, с функциями асинхронного вызова и обработки данных без потоков, через медиаторы, в самих кодах классов.
Сидел он значит, изучал фронтенд (новое для себя дело) и встал в ступор — а почему нельзя в js через те же медиаторы и обертки событий, как было в классах на c++, обойти синхронность языка? Давай-ка я напишу это, чтобы и здесь реализовать мнимо-неблокируемый интерфейс, и назову всё это дело промисом!
А нужно-ли это во фронте?, или это создаст для работы кода еще больше проблем? — эт. дело десятое, главное мы из JS теперь сделаем крутой язык, приближающийся к бэку!
На счет промисов — тут есть конечно нюансы, ввиду синхронности js, но мое отношение к промисам также негативное (работу кончено не пойдет искать, но прослушает двухчасовую беседу о том, как разбивать задачи на минимальные составляющие для обеспечения стабильности и прозрачности работы кода).
Но саму возможность использования промисов, в каких-то непонятных, внеземных проектах, я конечно не отрицаю. Как по мне, промисы в js придумал какой-то редкий м....., который ранее работал в глубоком бэкенде, на c++, с функциями асинхронного вызова и обработки данных без потоков, через медиаторы, в самих кодах классов.
Сидел он значит, изучал фронтенд (новое для себя дело) и встал в ступор — а почему нельзя в js через те же медиаторы и обертки событий, как было в классах на c++, обойти синхронность языка? Давай-ка я напишу это, чтобы и здесь реализовать мнимо-неблокируемый интерфейс, и назову всё это дело промисом!
А нужно-ли это во фронте?, или это создаст для работы кода еще больше проблем? — эт. дело десятое, главное мы из JS теперь сделаем крутой язык, приближающийся к бэку!
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
Т.е. в Вашем проекте на js нельзя писать на js? В нем же все функции образуют замыкания.
Просто когда все живут в 2018, этот человек живет в 1999, где он крутой программист, знающий что замыкания кушают память в нетскейп навигаторе.
В прошлом? В ПРОШЛОМ? ааа, жесть! Вы вообще хотя бы слегка представляете себе, как работает стек вызова всего вашего «будущего»? Какие системные функции затрагиваются при вызове ваших технологий? Какие проверки и со стороны каких процессов идут во фронтэнде? Всё это ваше «будущее», это устаревшая технология бэкэнда (80-ые по-моему годы, ну может девяностые – 5-я, или 6-я студия короче от майкрософта). Именно тогда бэкэнд языки были еще такими ущербными и там также приходилось применять обертки событий (EventLoop как тут кто-то в комментах писал, думая, что это круто — товарищ, это не круто, это смерть твоему проекту в продакте, если ты нагрузишь стек событиями и будешь ждать их окончания, не контролируя саму среду в которой выполняется твой код [браузер в данном случае]).
Теперь же бэкэнд вырос и избавился от этой шняги и такие вот горе-профи (аааа жесть просто) теперь пытаются впихнуть это старье во фронт энд, и всё по той же причине, чтобы также как и тогда в бэкэнде, обойти ограничения синхронности языка.
Но вот беда, работа кода в бэкэнде и работа его во фронтэнде, подчиняются абсолютно разным правилам и проходят очень-очень разные этапы проверок и допусков. И понятное дело, что обмен данными между мнимо-асинхронными функциями, во фронтэнде, просто теряет свой смысл из-за его слишком большой задержки (проверка ядром системы, проверка браузером, проверка анти-вирусом и прочими сторонними наблюдателями в системе).
Не пытайтесь писать на фронтэнде то, что нельзя на нем писать, притащив в него устаревшие технологии из бэкэнда! Хотите работу приложения как в бэкэнде, да млина, — пишите на бэкэнде, а фронтэнд подгружайте в виде интерфейса только, а не для работы и вычислений (не умеете так? слишком сложно для вас? — учитесь, или заказывайте у тех, кто может, но не пытайтесь городить шнягу убогую на том, на чем её не следует городить).
Тоже самое тут про virtual dom кто-то писал в комментах, ну и у самого автора поста это как раз-таки вызвало бурю негатива — и да, я полностью его поддерживаю в этом. Бла-бла-бла Senior… — не знаешь вирутал? не, не сениор. А вот собеседующий сам в курсе, что даже не junior, а первый месяц изучающий любой язык джуниор, уже знает и всегда использует только виртуал дом? 10-20 лет назад, любой, кто начинал попытку использования в своем бэкэнде web интерфейса (подгрузив объект webbrowser, или создав из своей программы экземпляры штатного веббраузера системы) тут же, при первом опыте внедрения большого потока данных в реальный дом, сталкивается с тем, что без виртуал, его код не будет работать. Ибо, подвесив свой ПК таким обращением в реальный дом, он начинает анализировать, что же произошло и находит причину, что работа с прямым дом, контролируемым всеми и вся, так нагружает и тормозит пк — что работа с ним просто не реальна.
И он тут же изобретает свой виртуал дом и обрабатывает его штатными регэкспами в памяти, выгружая в файлы готовые куски кода, если их слишком много для работы из памяти напрямую, а затем уже использует эти куски в своем веб интерфейсе. О чудо, спустя 20 лет, кто-то изобрел то же самое и назвал это virtual dom — и это да, это важно, это только для senior-ов технология, только они в курсе, как это и для чего :( аааа, жесть просто, не хватает уже эмоций на таких вот чудо-профи — куда катится мир программирования? Что, никто больше не хочет думать? Все читают каких-то ущербных чудо-разрабов, чтобы самим стать такими же ущербными и писать всякую чушь к месту и нет? Кто-то читает вообще спецификации самих языков? Спецификации ОС и аппаратной части ПК? Чтобы понимать, как работает тот, или иной метод в реальности?
Ладно, хватит лирики, тут на хабре я читал только от пары человек статьи, которые объясняли, как работает на низком уровне та, или иная функция языка, или препроцессора (в зависимости от того, что освещал автор). Это были переводы статей конечно, но сам факт, что человек правильно перевел такие статьи, дает мне право считать, что он также понимает, как работает то, что он переводит. Все остальные тут, смотрю, даже близко не представляют, как работает их чудо-супер-пупер технология замыканий, промисов и прочая чушь, в реальности и какие порождает процессы на низком уровне.
Все, кто тут отписался, считая себя суепр-профи знатоком, давайте эксперимент — скидывайте код, где вы считаете уместным замыкание, промис и т.д. Я переделываю его в свой код без всей этой чуши, и мы вставляем его в тело реальной страницы, нагруженной эффектами движения, графикой и прочим. Запускаем циклично тест этой (этих функций) и пишем видео с экрана работы этой страницы во время выполнения наших кодов, активно взаимодействуя с элементами страницы (скрлим, наводим мышь на элементы, выделяем текст, кликаем правой кнопкой мыши — в общем делаем все то, что делает пользователь на странице, просто не открывая новых вкладок).
По окончании работы теста, сохраняем данные использования памяти, CPU, GPU, время работы кодов (ну и выкладываем видео на общее обозрение, как ведет себя страница в браузере пока работает ваш и мой код — оба типа у каждого на ПК, чтобы было видно, как работает разный код на одном и том же ПК).
Вот тогда, мы и будем уже более детально обсуждать чудо-супер-пупер технологии на реальном примере, а не на сферическом коне в вакууме.
Теперь же бэкэнд вырос и избавился от этой шняги и такие вот горе-профи (аааа жесть просто) теперь пытаются впихнуть это старье во фронт энд, и всё по той же причине, чтобы также как и тогда в бэкэнде, обойти ограничения синхронности языка.
Но вот беда, работа кода в бэкэнде и работа его во фронтэнде, подчиняются абсолютно разным правилам и проходят очень-очень разные этапы проверок и допусков. И понятное дело, что обмен данными между мнимо-асинхронными функциями, во фронтэнде, просто теряет свой смысл из-за его слишком большой задержки (проверка ядром системы, проверка браузером, проверка анти-вирусом и прочими сторонними наблюдателями в системе).
Не пытайтесь писать на фронтэнде то, что нельзя на нем писать, притащив в него устаревшие технологии из бэкэнда! Хотите работу приложения как в бэкэнде, да млина, — пишите на бэкэнде, а фронтэнд подгружайте в виде интерфейса только, а не для работы и вычислений (не умеете так? слишком сложно для вас? — учитесь, или заказывайте у тех, кто может, но не пытайтесь городить шнягу убогую на том, на чем её не следует городить).
Тоже самое тут про virtual dom кто-то писал в комментах, ну и у самого автора поста это как раз-таки вызвало бурю негатива — и да, я полностью его поддерживаю в этом. Бла-бла-бла Senior… — не знаешь вирутал? не, не сениор. А вот собеседующий сам в курсе, что даже не junior, а первый месяц изучающий любой язык джуниор, уже знает и всегда использует только виртуал дом? 10-20 лет назад, любой, кто начинал попытку использования в своем бэкэнде web интерфейса (подгрузив объект webbrowser, или создав из своей программы экземпляры штатного веббраузера системы) тут же, при первом опыте внедрения большого потока данных в реальный дом, сталкивается с тем, что без виртуал, его код не будет работать. Ибо, подвесив свой ПК таким обращением в реальный дом, он начинает анализировать, что же произошло и находит причину, что работа с прямым дом, контролируемым всеми и вся, так нагружает и тормозит пк — что работа с ним просто не реальна.
И он тут же изобретает свой виртуал дом и обрабатывает его штатными регэкспами в памяти, выгружая в файлы готовые куски кода, если их слишком много для работы из памяти напрямую, а затем уже использует эти куски в своем веб интерфейсе. О чудо, спустя 20 лет, кто-то изобрел то же самое и назвал это virtual dom — и это да, это важно, это только для senior-ов технология, только они в курсе, как это и для чего :( аааа, жесть просто, не хватает уже эмоций на таких вот чудо-профи — куда катится мир программирования? Что, никто больше не хочет думать? Все читают каких-то ущербных чудо-разрабов, чтобы самим стать такими же ущербными и писать всякую чушь к месту и нет? Кто-то читает вообще спецификации самих языков? Спецификации ОС и аппаратной части ПК? Чтобы понимать, как работает тот, или иной метод в реальности?
Ладно, хватит лирики, тут на хабре я читал только от пары человек статьи, которые объясняли, как работает на низком уровне та, или иная функция языка, или препроцессора (в зависимости от того, что освещал автор). Это были переводы статей конечно, но сам факт, что человек правильно перевел такие статьи, дает мне право считать, что он также понимает, как работает то, что он переводит. Все остальные тут, смотрю, даже близко не представляют, как работает их чудо-супер-пупер технология замыканий, промисов и прочая чушь, в реальности и какие порождает процессы на низком уровне.
Все, кто тут отписался, считая себя суепр-профи знатоком, давайте эксперимент — скидывайте код, где вы считаете уместным замыкание, промис и т.д. Я переделываю его в свой код без всей этой чуши, и мы вставляем его в тело реальной страницы, нагруженной эффектами движения, графикой и прочим. Запускаем циклично тест этой (этих функций) и пишем видео с экрана работы этой страницы во время выполнения наших кодов, активно взаимодействуя с элементами страницы (скрлим, наводим мышь на элементы, выделяем текст, кликаем правой кнопкой мыши — в общем делаем все то, что делает пользователь на странице, просто не открывая новых вкладок).
По окончании работы теста, сохраняем данные использования памяти, CPU, GPU, время работы кодов (ну и выкладываем видео на общее обозрение, как ведет себя страница в браузере пока работает ваш и мой код — оба типа у каждого на ПК, чтобы было видно, как работает разный код на одном и том же ПК).
Вот тогда, мы и будем уже более детально обсуждать чудо-супер-пупер технологии на реальном примере, а не на сферическом коне в вакууме.
Вот вам код:
fetch("https://www.mocky.io/v2/5185415ba171ea3a00704eed")
.then(x => x.json())
.then(x => console.log(x.hello))Попробуйте его для начала просто переделать без промисов и замыканий. А мы посмеемся.
UFO just landed and posted this here
А цикл-то откуда возьмется? :-)
UFO just landed and posted this here
Да что ты будешь делать. Вот что вы читаете? Какой цикл вы где видите? Вы спецификацию xmlhttprequest читали вообще?
Весь fetch этого чудо-автора ниже джуниора, это регистрация промиса, резервирование состояний, объявление функций response и reject, запуск таймера опроса промиса для получения состояния исполнения, и, только затем, исполнение ТОГО ЖЕ КОДА ОТ xmlhttprequest:
То есть, такой вот чудо-разраб, который начитался таких же чудо-разрабов придумавших fetch, чтобы не писать код обработки XMLHTTPRequest, взял и на ровном месте в 3 раза увеличил нагрузку на ПК юзера, просто так, чтобы не писать пару лишних строк.
Ну, я могу понять, любишь ты короткие записи, напиши просто функцию обертку тогда, чтобы её вызывать вместо кода самого XMLHTTPRequest, и обзови там её myfetch(respose, reject) и вызывай — даже это будет в разищи быстрее и лучше, чем вызывать этот промис тормознутый и проблеммный.
Но нет, этот чудо-программер, будет бить себя пяткой в грудь, убивать машину юзеру, но не снизойдет до изучения чего-либо, а просто будет читать таких же супер-пупер профи.
Весь fetch этого чудо-автора ниже джуниора, это регистрация промиса, резервирование состояний, объявление функций response и reject, запуск таймера опроса промиса для получения состояния исполнения, и, только затем, исполнение ТОГО ЖЕ КОДА ОТ xmlhttprequest:
function eH001(){
if (this.status == 200)(x => x.json());
(x => console.log(x.hello));
}
var XH001 = new XMLHttpRequest();
XH001.onload = eH001;
XH001.open('GET', 'https://www.mocky.io/v2/5185415ba171ea3a00704eed');
XH001.send();
То есть, такой вот чудо-разраб, который начитался таких же чудо-разрабов придумавших fetch, чтобы не писать код обработки XMLHTTPRequest, взял и на ровном месте в 3 раза увеличил нагрузку на ПК юзера, просто так, чтобы не писать пару лишних строк.
Ну, я могу понять, любишь ты короткие записи, напиши просто функцию обертку тогда, чтобы её вызывать вместо кода самого XMLHTTPRequest, и обзови там её myfetch(respose, reject) и вызывай — даже это будет в разищи быстрее и лучше, чем вызывать этот промис тормознутый и проблеммный.
Но нет, этот чудо-программер, будет бить себя пяткой в грудь, убивать машину юзеру, но не снизойдет до изучения чего-либо, а просто будет читать таких же супер-пупер профи.
запуск таймера опроса промиса для получения состояния исполнения
Ваши сообщения — это какой-то сборник анекдотов. Откуда вы взяли, что существует какой-то таймер опроса?
Кстати, приведенный вами код не работает.
Кроме того, что он не работает так еще и замыкания использует, поэтому придется SemaIVVV искать новую работу не у себя в проекте.
Пожалейте человека, сам себя уволил публично на хабре, а ему за шаред хостинг за 300 рублей оплачивать, придется же на ватрушках в столовке экономить.
Пожалейте человека, сам себя уволил публично на хабре, а ему за шаред хостинг за 300 рублей оплачивать, придется же на ватрушках в столовке экономить.
На счет таймеров — еще раз повторю, учите матчасть, или на курсы идите (я вас бесплатно образовываю, написав вам что делает ваш fetch в в вашем коде).
На счет не работает — откуда мне знать, что вы там вызываете своими объектами.
Запишите обработчик для проверки так, чтобы узнать в консоли работает или нет:
>@b00taNik Кроме того, что он не работает так еще и замыкания использует,
Вы тоже не пишите больше, а идите учиться на курсы начальные — также ниже джуниора левел, который в принципе не знает что такое замыкания. (вам тоже бесплатный урок — назначение события, либо передача имени функции аргументом [без скобок], это не замыкание. Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием в JS и что позволяет сохранять состояния переменных. В моем же коде, нет никаких замыканий, и в обработчике, this будет всем, на что в любой из функций повесят этот обработчик, и, как вы не извращайтесь, но он никогда не сохранит состояние предыдущего вызова если его вызвали повторно. Учите матчасть, поднимитесь до джуниора хотя бы. И не смешите народ и не позорьтесь — не пишите чушь больше здесь.
На счет не работает — откуда мне знать, что вы там вызываете своими объектами.
Запишите обработчик для проверки так, чтобы узнать в консоли работает или нет:
function eH001(){
if (this.status == 200){console.log('OK!')}else{console.log('NO!');}
}>@b00taNik Кроме того, что он не работает так еще и замыкания использует,
Вы тоже не пишите больше, а идите учиться на курсы начальные — также ниже джуниора левел, который в принципе не знает что такое замыкания. (вам тоже бесплатный урок — назначение события, либо передача имени функции аргументом [без скобок], это не замыкание. Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием в JS и что позволяет сохранять состояния переменных. В моем же коде, нет никаких замыканий, и в обработчике, this будет всем, на что в любой из функций повесят этот обработчик, и, как вы не извращайтесь, но он никогда не сохранит состояние предыдущего вызова если его вызвали повторно. Учите матчасть, поднимитесь до джуниора хотя бы. И не смешите народ и не позорьтесь — не пишите чушь больше здесь.
И это пишет якобы сеньор :-) Вроде бы стандартное API, доступное во всех современных браузерах — но нет, "откуда мне знать, что вы там вызываете своими объектами".
Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием
А вот википедия, например, считает что замыкание — это функция первого порядка (т.е. функция-объект, как, eH001), и которая использует внешние переменные, не являющиеся ее параметрами (как this.status, например).
Может посоветуете курсы, где бы я мог познать схожую с вами мудрость, а то как отучился на ВТ в 2008, так и работаю программистом, все некогда на курсы для джуниоров сходить.
PS: код не работает, потому что он синтаксически некорректно составлен, да и x не определен, если бы вы хоть немного понимали в JS, до вас бы это дошло.
this не замкнут, это неявный параметр функции. А вот console — вполне себе.
Кстати, я на счет этого не уверен. Глобальные переменные тоже через замыкание поставляются или для этого есть отдельный механизм?
UFO just landed and posted this here
На таком обывательском уровне и я могу рассказать. Меня интересует, если ли какая-то особая обработка global переменной. То есть больше инфы, чем прочитать одну поверхностную (хоть и хорошую) статью на javascript.ru
Тут вы крайне странно сформулировали.
Там не все так просто, как кажется на первый взгляд. Вот к примеру, вы говорите «пока не выйдет на функцию определенную в глобальном объекте. А в глобальном объекте есть свойство console». Так вот как именно это работает? Тут уже надо знать про BindingObject и все такое. Я вот не был уверен, что глобальный объект является частью этой цепочки скоупов до того, как специально залез в спецификацию и посмотрел (так вполне могла быть отдельная (иная) обработка глобального объекта). И, на самом деле, есть определенныё исключения.
К примеру есть уникальный Lexical Environment, который называется «The Global Environment». И, иногда, особая работа с ним. Например, в спецификации есть прямые исключения:
Более того, необходимо понимать такую важную вещь:
К сожалению я смог найти в спецификации, в какой момент присваивается для шапки цепочки Global Environment. Единственное, где это присутствует — это в пункте «15.3.2.1 new Function»:
В какой именно момент в начале цепочки становится Global Environment и становится ли такой вообще (или обрабатывается как исключение) в документации я не нашел(
функцию определенную в глобальном объекте
Тут вы крайне странно сформулировали.
Там не все так просто, как кажется на первый взгляд. Вот к примеру, вы говорите «пока не выйдет на функцию определенную в глобальном объекте. А в глобальном объекте есть свойство console». Так вот как именно это работает? Тут уже надо знать про BindingObject и все такое. Я вот не был уверен, что глобальный объект является частью этой цепочки скоупов до того, как специально залез в спецификацию и посмотрел (так вполне могла быть отдельная (иная) обработка глобального объекта). И, на самом деле, есть определенныё исключения.
К примеру есть уникальный Lexical Environment, который называется «The Global Environment». И, иногда, особая работа с ним. Например, в спецификации есть прямые исключения:
Else if env is the environment record component of the global environment then
Более того, необходимо понимать такую важную вещь:
Lexical Environments and Environment Record values are purely specification mechanisms and need not correspond to any specific artefact of an ECMAScript implementation.
К сожалению я смог найти в спецификации, в какой момент присваивается для шапки цепочки Global Environment. Единственное, где это присутствует — это в пункте «15.3.2.1 new Function»:
Pass in the Global Environment as the Scope parameter and strict as the Strict flag..
В какой именно момент в начале цепочки становится Global Environment и становится ли такой вообще (или обрабатывается как исключение) в документации я не нашел(
UFO just landed and posted this here
Да тут дело даже не в иллюстрациях, а в понимании самого процесса замыкания в JS. Многие просто не понимают, что из себя представляет само замыкание в JS. В остальных языках — там всё это совсем по другому, и ясно и понятно. А в JS это баг изначально, и его не стали исправлять, а так и оставили, типа фишка языка. И вот теперь, кто-то додумывается использовать этот баг.
Суть ошибки замыкания в JS, что в нем нет типизированного вызова и обращения к свойствам объекта и к просто переменным. Сам интерпретатор решает к чему именно вы обращаетесь.
Вот вы указали базовый пример из справочника, и тут именно наглядно видно это. В момент, когда вы создали глобальный объект var myFunc = makeFunc… отработала внутренняя функция displayName создав замыкание и глобальный объект myFunc получил свойство name (в обычном языке myFunc->name).
Всё, функции makeFunc и displayName отработали, и все их внутренние переменные должны быть очищены, это везде так (и в JS это тоже так).
Но, в js, (так, как все функции являются объектами — гвоздь им в голову сразу и по шляпку) когда вы снова, после окончания работы функций пытаетесь обратиться к переменной name, интерпретатор, не имея типизации обращения, видит, что такое свойство есть у ныне существующего глобального объекта myFunc, а значит, вы, скорее-всего, к нему обращаетесь — он вам и возвращает это свойство этого объекта, и складывается впечатление, что якобы существует сама переменная name в памяти, после окончания работы функций.
Вот именно это и является проблемой — можно так дозамыкаться, что ПК пользователя просто перестанет отвечать на запросы. А также черт его знает в каком месте у вас нахлестнутся имена свойств объектов после замыкания и имена глобальных переменных, что приведет просто к разрыву башки при отладке такого кода. Вот поэтому, я жестко караю любого, за любую попытку этого х… кода в js, кто сознательно пытается использовать этот баг в js.
И именно поэтому, каждый раз когда новая команда разработчиков (и не важно, номральная-ли команда, или команда чудо-разрабО) приходят к клиенту, чтобы расширить (или исправить) код, который был написан до этого такими вот чудо-разрабами, нет никакого шанса разобрать этот дивный код. Поэтому, всегда все начинают писать всё с нуля. Клиент, которому попадаются такие чудо-разрабы, постоянно попадает на деньги и на время, и из-за этого у него складывается негативное впечатление о работе отрасли программирования в целом. И всё это из-за таких вот чудо-программеров, как b00taNik, которые считают себя программистами.
Вот мой код и код таких как я, сможет прийти и продолжить, или изменить, любая новая команда у клиента (и не важно нормальная ли команда, или команда чудо-разрабов). Им потребуется минимальное время, чтобы понять структуру кода и начать его исправлять, или дополнять. Никаких неявных петель и ловушек вроде таких вот чудо-замыканий, они не получат в моем коде, я даже никогда не делаю дубли в именовании явно-объявляемых переменных внутри функций, не говоря уже о том, чтобы произошел нахлест в глобальной области видимости.
Суть ошибки замыкания в JS, что в нем нет типизированного вызова и обращения к свойствам объекта и к просто переменным. Сам интерпретатор решает к чему именно вы обращаетесь.
Вот вы указали базовый пример из справочника, и тут именно наглядно видно это. В момент, когда вы создали глобальный объект var myFunc = makeFunc… отработала внутренняя функция displayName создав замыкание и глобальный объект myFunc получил свойство name (в обычном языке myFunc->name).
Всё, функции makeFunc и displayName отработали, и все их внутренние переменные должны быть очищены, это везде так (и в JS это тоже так).
Но, в js, (так, как все функции являются объектами — гвоздь им в голову сразу и по шляпку) когда вы снова, после окончания работы функций пытаетесь обратиться к переменной name, интерпретатор, не имея типизации обращения, видит, что такое свойство есть у ныне существующего глобального объекта myFunc, а значит, вы, скорее-всего, к нему обращаетесь — он вам и возвращает это свойство этого объекта, и складывается впечатление, что якобы существует сама переменная name в памяти, после окончания работы функций.
Вот именно это и является проблемой — можно так дозамыкаться, что ПК пользователя просто перестанет отвечать на запросы. А также черт его знает в каком месте у вас нахлестнутся имена свойств объектов после замыкания и имена глобальных переменных, что приведет просто к разрыву башки при отладке такого кода. Вот поэтому, я жестко караю любого, за любую попытку этого х… кода в js, кто сознательно пытается использовать этот баг в js.
И именно поэтому, каждый раз когда новая команда разработчиков (и не важно, номральная-ли команда, или команда чудо-разрабО) приходят к клиенту, чтобы расширить (или исправить) код, который был написан до этого такими вот чудо-разрабами, нет никакого шанса разобрать этот дивный код. Поэтому, всегда все начинают писать всё с нуля. Клиент, которому попадаются такие чудо-разрабы, постоянно попадает на деньги и на время, и из-за этого у него складывается негативное впечатление о работе отрасли программирования в целом. И всё это из-за таких вот чудо-программеров, как b00taNik, которые считают себя программистами.
Вот мой код и код таких как я, сможет прийти и продолжить, или изменить, любая новая команда у клиента (и не важно нормальная ли команда, или команда чудо-разрабов). Им потребуется минимальное время, чтобы понять структуру кода и начать его исправлять, или дополнять. Никаких неявных петель и ловушек вроде таких вот чудо-замыканий, они не получат в моем коде, я даже никогда не делаю дубли в именовании явно-объявляемых переменных внутри функций, не говоря уже о том, чтобы произошел нахлест в глобальной области видимости.
Главная ваша претензия к замыканиям в JS это то, что имена переменных могут пересекаться с другими областями видимости, а вам как программисту не хватит мозгов чтобы понять как этого избежать? Вы это серьезно?
А что касается кода — начните с того, что вы обещали показать код без замыканий и работающий. Где он в итоге то?
А что касается кода — начните с того, что вы обещали показать код без замыканий и работающий. Где он в итоге то?
UFO just landed and posted this here
UFO just landed and posted this here
Ну че, поздравляю вашего работадателя с наймом программиста, учившигося в википедии (мое сочувствие ему) :)
На курсы — запишитесь при любом университете технической направленности (а то я как закончил Универ радиотехнический по направлению автоматизация и управление, так и программирую после этого и учусь не в википедии, а по документации к языкам и аппаратным комплексам).
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
А теперь вопрос супер-пупер программисту википедийному, eH001 — определена где? Внутри функции какой то? ИЛи на глобальном уровне вне окружения функций?
Жесть, и вот такое чудо-разрабо, программистом работает, жесть просто — где работаете? Надо вашему нанимателю линк скинуть на ваши комменты здесь, чтобы он понял кто у него работает.
На курсы — запишитесь при любом университете технической направленности (а то я как закончил Универ радиотехнический по направлению автоматизация и управление, так и программирую после этого и учусь не в википедии, а по документации к языкам и аппаратным комплексам).
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
А теперь вопрос супер-пупер программисту википедийному, eH001 — определена где? Внутри функции какой то? ИЛи на глобальном уровне вне окружения функций?
Жесть, и вот такое чудо-разрабо, программистом работает, жесть просто — где работаете? Надо вашему нанимателю линк скинуть на ваши комменты здесь, чтобы он понял кто у него работает.
Можете себя не утруждать, я уже скинул — уже ржем над вами всем офисом второй день — особенно с ваших познаний во фронтенде.
Не могли бы вы сослаться на книгу, где вы это услышали, раз википедия не источник, хотелось бы тоже ознакомиться с данным кладезем мудрости? Кроме того, даже если по вашему определению, console откуда берется, не из глобального ли контекста?
Ну а то, что вы учились программировать по документации к устройствам — ну так и заметно, что ваши познания в программировании недалеко от примеров из методичек :)
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
Не могли бы вы сослаться на книгу, где вы это услышали, раз википедия не источник, хотелось бы тоже ознакомиться с данным кладезем мудрости? Кроме того, даже если по вашему определению, console откуда берется, не из глобального ли контекста?
Ну а то, что вы учились программировать по документации к устройствам — ну так и заметно, что ваши познания в программировании недалеко от примеров из методичек :)
Вы бы внимательнее, что-ли, читали.
Понятия не имею, какие познания у вашего оппонента — для меня фронт и js страшные тёмные места, в которые я не суюсь, ибо квалификации не хватает, но у него прямо в комментарии написано, откуда он цитирует:
И затем первый же запрос в яндекс «mozilla closure» выводит нас на нужный сайт, где именно так и написано определение.
Понятия не имею, какие познания у вашего оппонента — для меня фронт и js страшные тёмные места, в которые я не суюсь, ибо квалификации не хватает, но у него прямо в комментарии написано, откуда он цитирует:
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
И затем первый же запрос в яндекс «mozilla closure» выводит нас на нужный сайт, где именно так и написано определение.
Т.е. человек мне приводит описание реализации замыканий в фаерфоксе, и выдает это за академическое определение.
Спасибо за разьяснение данного момента, все ясно.
Спасибо за разьяснение данного момента, все ясно.
Собственно, больше склонен верить г-ну b00taNik, и именно потому, что сходил по ссылке — источнику знаний SemaIVVV.
Прямо оттуда:
И именно об этом говорит b00taNik, а SemaIVVV продолжает стоять на том, что это только у неучей, а его функции в его Javascripte никаких замыканий не формируют.
Прямо оттуда:
функции в JavaScript формируют так называемые замыкания
И именно об этом говорит b00taNik, а SemaIVVV продолжает стоять на том, что это только у неучей, а его функции в его Javascripte никаких замыканий не формируют.
UFO just landed and posted this here
Код с циклом не заблокирует разве поток, что приведёт к заморозке всего интерфейса? Насколько я помню, xmlhttprequest всегда юзали вместе с коллбеком onLoad, который всегда был и асинхронный, и с замыканиями. Прошу поправить если не прав
Не выставляйте себя клоуном — и не пишите больше сюда. Вы просто новичок и ниже джуниора.
fetch всего лишь обертка для XMLHTTPRequest, чтобы такие неумехи, как вы писали меньше букв, не понимая технологии запроса данных. Если вы не понимаете, как написать XMLHTTPRequest запрос с if else (и при необходимости, заюзать catch), как в вашем fetch-е — просто идите на курсы базовые по программированию что-ли.
fetch всего лишь обертка для XMLHTTPRequest, чтобы такие неумехи, как вы писали меньше букв, не понимая технологии запроса данных. Если вы не понимаете, как написать XMLHTTPRequest запрос с if else (и при необходимости, заюзать catch), как в вашем fetch-е — просто идите на курсы базовые по программированию что-ли.
если условный фетч, который принимает колбек:
function helloLog(x) {
console.log(x.json().hello);
}
fetch("https://www.mocky.io/v2/5185415ba171ea3a00704eed", helloLog);Не очень хороший пример, тут не так велика разница. Вот если надо композить асинхронные действия — тут уже становится печальнее все эти helloLog-и писать :)
если условный фетч, который принимает колбек:
Каждый раз, читая такое, сначала утираю кровавые слёзы из глаз, а потом вспоминаю нетленное:
Классен Днепр при клёвой погоде, когда, кочевряжась и выпендриваясь, пилит он сквозь леса и горы клёвые воды свои. Вылупишь зенки свои, откроешь варежку — и с катушек. Редкая птица дочешет до середины Днепра, а если дочешет — так гикнется, что копыта отбросит.
Я понимаю вашу боль. У меня ощущение, что большая часть молодых разработчиков обучается по stackoverflow, а не по книгам. В итоге смотришь в task manager, а там приложение Upwork стабильно съедает 30-40% CPU. И это чат + трекер времени! С каких пор трекер времени требует столько ресурсов? Это если умножить на количество пользователей Upwork, то можно посчитать, сколько электроэнергии/угля сжигается от лени разработчиков писать эффективный код. Видимо, для получения меньшего числа в массиве сначала сортируется весь массив, потом берется первый элемент, не иначе.
Не ёрничайте, всем понятно что речь идет о замыканиях внутри старшей функции для попытки сделать приватными переменные, или сохранить значения переменных (хотя мне сложно понять для чего через ж… замыкания это пытаются делать).
UFO just landed and posted this here
Инкапсуляция состояния без замыканий?
Вот это как раз без проблем. Ни в одном языке программирования не существует способа полностью спрятать приватные поля от программиста, всегда все держится на соглашениях вида «обращаться к чужим полям через рефлексию нехорошо». В старом JS такое соглашение просто расширяется до «обращаться к полям про которые в комментарии написано что оно приватное нехорошо».
А в современном JS уже есть символы и хотят ввести приватные поля.
А в современном JS уже есть символы и хотят ввести приватные поля.
В старом JS традиционально настоящие приватные поля проще всего делаются через замыкания. Это позволяет контролировать корректность обращения к ним с помощью самого интерпретатора.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет и никогда не программировал на языках с ООП, либо это сознательно, старая собака уже испытывает проблемы с новыми трюками.
Комментарии — это, пожалуй, самое отвратительное, что можно было придумать для выражения данной концепции. Поддержка такого кода будет адом. Если же очень нужно открыть поле наружу, но запретить публичное использование (эмуляция семантики protected-доступа из нормальных языков) — используют пре-/постфиксы для имени поля, что будет однозначной подсказкой даже в клиентском коде.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет и никогда не программировал на языках с ООП, либо это сознательно, старая собака уже испытывает проблемы с новыми трюками.
Комментарии — это, пожалуй, самое отвратительное, что можно было придумать для выражения данной концепции. Поддержка такого кода будет адом. Если же очень нужно открыть поле наружу, но запретить публичное использование (эмуляция семантики protected-доступа из нормальных языков) — используют пре-/постфиксы для имени поля, что будет однозначной подсказкой даже в клиентском коде.
Тем не менее, инкапсуляция без замыканий все еще возможна, даже если большинство ее делает через замыкания.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет
То есть вы настаиваете на важности модификатора private, полностью игнорируя отсутствие иногда даже более важного модификатора protected и рассуждаете о «с головой в песок»?
Опытные программисты или используют JSDoc, где есть оба модификатора или уже давно ушли в TypeScript. А «инкапсуляция через замыкания» — не более, чем костыль для новичков.
Похоже я проспал революцию, раз не вижу в сокрытии (особенно через замыкание) никакой пользы, но вижу кучу минусов. Не расскажите нам про эти преимущества?
Сдается мне, что вы желаете похоливарить) В этом не поддержу, но ссылку на википедию оставлю на случай, если «нам» не ограничивается вами.
UFO just landed and posted this here
Вангую аргументы про
reinterpret_cast<int*>(Foo*). «Это же держится на соглашениях для С++-программистов!»UFO just landed and posted this here
Нет, это не UB. Ведь по указанному адресу и правда находится int.
Все равно UB, потому что нет в стандарте никаких гарантий на расположение полей, и завтра в этот класс компилятор вдруг напихает каких-нибудь внутренних структур байт на 20, и все развалится. Даже если оно у вас сейчас работает — это волшебство, а не C++.
Не может там не быть никаких гарантий — это бы сделало невозможным передачу структур между модулями на разных языках. Если даже таких гарантий нет в стандарте — они всегда есть в конкретных реализациях.
Ну таковая передача на C++ невозможна по стандарту даже без разных языков. У языка не определен binary interface, и потому передавать приходится либо структуры из C (у которых таковой интерфейс есть), либо использовать сериализацию в промежуточные форматы вроде protobuf.
Если же использовать особенности конкретных реализаций, то это вновь волшебство, а не C++, потому что даже минорное обновление любого компонента компилятора может вам разломать все в самых неожиданных местах, и про котел в аду там выше не зря написано.
Если же использовать особенности конкретных реализаций, то это вновь волшебство, а не C++, потому что даже минорное обновление любого компонента компилятора может вам разломать все в самых неожиданных местах, и про котел в аду там выше не зря написано.
Чем "структура из Си" отличается от класса без виртуальных функций? Насколько я знаю, extern "C" влияет только не функции и переменные, но не на структуры.
Да и с теми же виртуальными функциями все не так сложно. Да, смещение первого поля будет implementation-spicific, но подразумеваемое поведение компилятора можно проверить тестами, по типу таких: assert(reinterpret_cast<intptr_t>(&Foo::x) == sizeof(void*));
PS про котел в аду в целом согласен — вот только, в моем понимании, нарушителей соглашения по именованию приватных полей в javascript ждет соседний котел :-)
UFO just landed and posted this here
Отличается тем, что у нее размещение определено, выравнивание определено, и делать его по другому без явного на то указания компилятор не имеет права, и потому макросы вроде OFFSET_OF() и CR() до сих пор отлично работают. У класса (хоть с виртуальными функциями, хоть без) размещение не определено, точнее определяется реализацией, т.е. никто не мешает начать, к примеру, все поля тегировать (т.е. перед каждым полем вставить еще по полю с тегом), сам класс тегировать (вставить ему GUID вначале, чтобы за размещением экземпляров в памяти потом следить), и все это останется в рамках C++ (т.е. код на C++ работать не перестанет), а у вас либо reinterpret_cast вернет непонятно что, либо все завалится еще на ассертах.
Разница в том, где именно происходит проверка на то, что правила доступа не нарушаются, и в C++ она не происходит, потому что вы об этом просите явно очень заметной конструкцией (в Rust таковые еще заметнее), а в JS у вас и соглашение в голове, и проверка его там же, и найти таковые нарушения grep'ом просто так не получится.
Разница в том, где именно происходит проверка на то, что правила доступа не нарушаются, и в C++ она не происходит, потому что вы об этом просите явно очень заметной конструкцией (в Rust таковые еще заметнее), а в JS у вас и соглашение в голове, и проверка его там же, и найти таковые нарушения grep'ом просто так не получится.
UFO just landed and posted this here
А не подскажите название компании, где вы работаете? Ну чтобы сразу игнорировать предложения работы оттуда)
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
Вы понимаете, что, наверное, невозможно написать JS-код не создавая замыканий? Если вы умеете — научите меня, пожалуйста. Мне очень интересно
UFO just landed and posted this here
JS — асинхронный язык кстати. Но однопоточный. Типичный вопрос на собеседовании — почему js асинхронный. Который подразумевает, что вы знаете что такое EventLoop а если знаете, то как можно назвать его синхронным?
И то в новой nodejs уже ввели нативную подержку мультипоточности. Вам бы самому новую работу найти не помешало. :)
И то в новой nodejs уже ввели нативную подержку мультипоточности. Вам бы самому новую работу найти не помешало. :)
Так толсто, что даже тонко
А когда на senior-позицию приходят полные нули, что делать? Знакомый фронтендер периодически собеседует людей на позицию senior-ов. Люди говорят/пишут, что у них 3-5-10 лет опыта, но они не знают концепции замыканий.
Программирую еще с прошлого века.
Смотрю все пишут про какие-то умные замыкания. Не знаю этого термина.
Думаю, ну наверное некая умная концепция, может, буду использовать, пригодится. Надо почитать что это.
Читаю.
Ага. Использую, не зная как оно называется, уже лет 20 или поболее даже, оказывается.
Почему? Нас учили разным математическим моделям, а вовсе не тому как что называется в синтаксисе языка.
Внимание, вопрос:
Являюсь ли я недостойным должности сеньора, если 10 последних лет как проектирую highload-решения, которые держат высокие нагрузки на смешном железе?
Если вам задают этот вопрос — бегите. Этот вопрос означает, что за 5 минут до интервью интервьюер загуглил «что спросить на собеседовании javascript». Во всех проектах, где на интервью меня спрашивали про замыкания, царил бардак и ужас.
UFO just landed and posted this here
Охренел (25 лет за баранкой этого пылесоса, а не слышал). Почитал. Охренел второй раз — концепция понятна, но мне а) за те самые 25 лет мне не требовалась ни разу, б) можно гораздо понятнее объяснить в терминах низкого уровня (как известно, C — это по большому счёту надстройка над ассемблером/машинными кодами, на которых я с детства работал).
Программист не может не знать, что такое замыкание.
Есть отличная фраза — «Иногда 10 лет опыта — это один год, повторенный 10 раз».
В твоём случае это было 25 раз, только и всего.
Есть отличная фраза — «Иногда 10 лет опыта — это один год, повторенный 10 раз».
В твоём случае это было 25 раз, только и всего.
В твоём случае
Не подскажете, когда мы с Вами на брудершафт пили? А то я запамятовал.
Повторяю: концепция мне знакома, но никогда не возникало необходимости её с кему-то обуждать, соответственно узнать её "официальное" название — тоже; фразы "вон та вот х… рень" вполне хватало.
А где-то есть список «Чего не может не знать программист»?
Было бы любопытно ознакомиться.
Было бы любопытно ознакомиться.
What Every Programmer Should Know About Memory
What Every Programmer Should Know About
Floating-Point Arithmetic
Держите и не благодарите. Когда это знаешь, то иногда получаешь х10 производительности, просто переставив порядок операций. С плавающей точкой аналогично — иногда, решая нелинейные уравнения, результат надо нормализовать по заданному эпсилону, чтобы случайно не взять sqrt(-1e-18), когда должен быть sqrt(0), и не получить nan во всех последующих результатах.
What Every Programmer Should Know About
Floating-Point Arithmetic
Держите и не благодарите. Когда это знаешь, то иногда получаешь х10 производительности, просто переставив порядок операций. С плавающей точкой аналогично — иногда, решая нелинейные уравнения, результат надо нормализовать по заданному эпсилону, чтобы случайно не взять sqrt(-1e-18), когда должен быть sqrt(0), и не получить nan во всех последующих результатах.
Программист не может не знать, что такое замыкание.
То есть, по-вашему какой-нибудь крутой знаток ассемблера — «не программист», потому что он такое не использует и потому не знает?!
Как раз знаток ассемблера должен замыкания знать намного лучше остальных. Ему ведь их на ассемблере реализовывать, а не просто пользоваться.
Программисту следует реализовывать приложения, а не замыкания.
Ну вот когда вы пишете кодогенератор для компилятора, то вам надо знать, как реализовываются замыкания.
Вы считаете, что знаток ассемблера обязан знать «замыкание», ибо это обязательно для написания трансляторов для JS?
Может он чем то другим занимается?
P.S. при упоминании ассемблера мы, несколько, отошли от JS.
Может он чем то другим занимается?
P.S. при упоминании ассемблера мы, несколько, отошли от JS.
> ибо это обязательно для написания трансляторов для JS?
При чем тут транспиляторы js? Сейчас замыкания есть практически в любом ЯП и знание того, как устроены замыкания — это примерно то же самое, что знание того, как устроены функциональные вызовы.
При чем тут транспиляторы js? Сейчас замыкания есть практически в любом ЯП и знание того, как устроены замыкания — это примерно то же самое, что знание того, как устроены функциональные вызовы.
Не хотелось бы продолжать, ибо не компетентен.
Но я всегда думал, что ассемблер-разработчикам, гораздо ближе hard нежели высокоуровневые языки программирования.
Но я всегда думал, что ассемблер-разработчикам, гораздо ближе hard нежели высокоуровневые языки программирования.
Поддержу, современным разработчикам на ассемблере писать на них реализацию замыканий не нужно, и уже, скорее всего, не будет нужно.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
Полностью аналогичная ситуация.
за те самые 25 лет мне не требовалась ни разу
Ну бывает. Опыт-то он у всех разный. Например, в C++ и в Java такого фактически нет.
Я вот до знакомства с питоном тоже не знал что это и не использовал. В питоне же, изучая исходники библиотек, столкнулся — там это используется в написании декораторов. В js же вообще повсеместно (особенно раньше), в силу специфики языка.
Но вообще, до знакомства с тем же питоном я и о других вещах, вроде генераторов или метапрограммирования, тоже не знал. Так что полезно иногда изучать разные языки, так как многие из паттернов, подходов и концепций, почти отсутствующих в одном языке, в другом могут быть чуть ли не основным подходом.
Я тоже… Недавно узнал, что это теперь используется в новом PHP, когда пришлось немного адаптировать старый вики-движок. Ну, точнее, это там называется «анонимные функции».
В php вроде, как раз нету замыкания. То есть анонимные функции там, вроде, не замыкаются на родительский скоуп, а все необходимые данные им передаются как особые аргументы через use
А откуда они там берутся, в этом use? Уж не из родительского ли скоупа?
Я точно не знаю, могу ошибаться, как реализовано в PHP, но мне кажется, что там не через замыкание.
Они наследуются из родительской области видимости. Вся разница с тем же js в том, что в js переменные захватываются автоматически по факту использования, а в php список захватываемых переменных указывается вручную.
Кстати, в языке c++ реализованы оба механизма.
Кстати, в языке c++ реализованы оба механизма.
Я думал, что они именно привязываются к функции, как аргументы и такого прикола, как в JS быть не может.
То есть это не замыкание на родительский скоуп, а именно захват переменных в свой, при чем именно во время создания функции. Но я могу ошибаться, т.к. на php не писал с 5.3
То есть доступа в родительский скоуп (сообстно замыкания) во время работы функции нету, просто в локальной области видимости есть дополнительные переменные
for ($i = 0; $i < 10; $i++) {
$button->onclick = function () use ($i) {
echo $i;
};
}То есть это не замыкание на родительский скоуп, а именно захват переменных в свой, при чем именно во время создания функции. Но я могу ошибаться, т.к. на php не писал с 5.3
То есть доступа в родительский скоуп (сообстно замыкания) во время работы функции нету, просто в локальной области видимости есть дополнительные переменные
Да, прикола тут не будет, потому что переменная захватывается по значению. Но если поставить знак & — то она будет захвачена по ссылке со всеми последствиями.
Ну то есть будет захвачена ссылка на переменную. А замыкания на родительский скоуп все-равно не будет?
А что такое, по-вашему, «замыкание на скоуп» и чем оно отличается от замыкания, захватившего переменные этого скоупа?
Ну я представляю приблизительно так.
В JS и C# есть доступ к скоупу вне функций.
А в php клонируется или переменная, или ссылка на область памяти с ней.
В JS и C# есть доступ к скоупу вне функций.
А в php клонируется или переменная, или ссылка на область памяти с ней.
Все еще не вижу отличий.
for ($i = 0; $i < 10; $i++) {
anotherFunction( &$i );
}Тут ведь нет замыкания? Вот тот пример ближе к этому.
Нету. Потому что переменная передана параметром, а не захвачена. А в вашем примере c use она именно что была захвачена.
В PHP замыкания есть, о чем сказано и в мануале: php.net/manual/en/functions.anonymous.php
В PHP можно просто объявить статичную перменную внутри функции, доступную только в ней stackoverflow.com/questions/6188994/static-keyword-inside-function
function doStuff() {
static $cache = null;
if ($cache === null) {
$cache = '%heavy database stuff or something%';
}
// code using $cache
}
Например, <...> в Java такого фактически нет
В Java есть замыкания, вот пример:
public static final String VALUE = "VALUE";
public static Callable<String> myMethod() {
// Или так:
// return () -> VALUE;
return new Callable<String>() {
@Override
public String call() {
return VALUE;
}
};
}Тут и области видимости, и всё остальное соответствующее. До выхода Java 8 их просто сравнительно мало кто писал (причину видно по разнице между кодом в комментарии и вне комментария), да и после Java 8 официальное название этого подходя — capturing lambda, хотя по факту это таки практически один в один замыкание.
Вот как раз сишнику про замыкания знать не обязательно просто потому что в Си их нет, как и в ассемблере. В современном C++ замыкания есть, но сам термин тоже можно не знать, потому что обычно их называют лямбдами.
В современном C++ замыкания есть, но сам термин тоже можно не знать, потому что обычно их называют лямбдами.
Строго говоря, не каждая лябда — замыкание.
GCC давно позволяет делать замыкания
Я часто спрашиваю на собеседованиях чем по сути является метод .bind(). Это и есть мой скрытый вопрос про замыкание.
Разговор был про virtual. А если подойдет прохожий и скажет, что virtual это способ организовать перегрузку функции (методов) в рантайм с помощью таблиц в памяти, из-за ограниченности императивных ЯП?! Вы ему поверите? Да, ни смотря ни на что, они тоже стремятся к полиморфизму. А замыкания это просто поглощение значении переменных из внешней области переменных, которое на разных ЯП может быть по разному?
Пусть автор не сдается, собеседование это всего лишь этап.
Пусть автор не сдается, собеседование это всего лишь этап.
Во-первых, когда вы сами начнёте нанимать людей в нормальную контору, то увидите, как много непонятно кого пытаются правдами и неправдами попасть к вам. И если вы не знаете другого способа отсеивать фуфло, то вы тоже будете задавать тупые вопросы.
Во-вторых, ответ на вопрос «что такое замыкание» может отлично показать и психотип человека, и общую его базу. Это важно. Также в ответе прозвучат разные слова, за которые можно зацепиться. Вопросы на собеседовании — это всего лишь крючки, основное смысл — это как раз разговор о том, о чём вы будете говорить в своих ответах.
Ну и в целом не понимаю, почему у вас (в смысле у тебя и у ТС) бомбит. Если вы считаете, что подобные вопросы на собеседовании есть показатель того, что компания вам не подходит — ну так хорошо же, что вы сразу это понимаете. Лучше ведь на первом собеседовании увидеть, что вам с компанией не по пути, а не через полгода работы.
Во-вторых, ответ на вопрос «что такое замыкание» может отлично показать и психотип человека, и общую его базу. Это важно. Также в ответе прозвучат разные слова, за которые можно зацепиться. Вопросы на собеседовании — это всего лишь крючки, основное смысл — это как раз разговор о том, о чём вы будете говорить в своих ответах.
Ну и в целом не понимаю, почему у вас (в смысле у тебя и у ТС) бомбит. Если вы считаете, что подобные вопросы на собеседовании есть показатель того, что компания вам не подходит — ну так хорошо же, что вы сразу это понимаете. Лучше ведь на первом собеседовании увидеть, что вам с компанией не по пути, а не через полгода работы.
Во-первых, когда вы сами начнёте нанимать людей в нормальную контору, то увидите, как много непонятно кого пытаются правдами и неправдами попасть к вам. И если вы не знаете другого способа отсеивать фуфло, то вы тоже будете задавать тупые вопросы.
Статья о том, что таким способом наиболее эффективно отсеиваются как раз лучшие разработчики. А вот фуфло и так дорогу найдет, не замыканиями, так другими фокусами.
Статья о том, что таким способом наиболее эффективно отсеиваются как раз лучшие разработчики.Никаких доказательств данного тезиса в статье нет. Нет оснований полагать, что данные вопросы станут проблемой для лучших разработчиков. То, что они стали проблемой для автора никак не может быть без особых причин экстраполировано на лучших разработчиков.
Меня больше трясет от банальных зубрильных вопросов про особенности js при работе с var, конструкциями вида (...)(), в современном мире, где я использую только let, const (преимущественно). Я понимаю, что я должен знать что такое замыкание, я знаю что это но хоть убейте не могу рассказать как требуют, но точно знаю как избегать ошибок, связанных с этим.
От вопросов —
От вопросов —
var a = b = 3
Не в тему программирования, но тоже по ИТ. У нас было пару случаев по собеседованию на сис.админа:
1. Человек много всего красивого написал в резюме, в том числе установка CISCO. Угадайте как он их устанавливал? Правильно, брал руками и заталкивал в серверный шкаф.
2. Человек превосходно описал всё чем занимался, какие проекты сделал, свои достижения и прочая. Всё было замечательно до того момента, пока случайно из области бреда не стали спрашивать элементарных вещей про IP адрес, маску, маршрутизацию и прочая.
И на основании этого я делаю вывод, что да — необходимо спрашивать базовые вещи.
Особенно умиляют вопросы синьоров по Java — «а зачем нам знать как работает Garbage Collector?». А потом бегут с криками — нам надо еще 32 Гб ОЗУ — нам не хватает!
1. Человек много всего красивого написал в резюме, в том числе установка CISCO. Угадайте как он их устанавливал? Правильно, брал руками и заталкивал в серверный шкаф.
2. Человек превосходно описал всё чем занимался, какие проекты сделал, свои достижения и прочая. Всё было замечательно до того момента, пока случайно из области бреда не стали спрашивать элементарных вещей про IP адрес, маску, маршрутизацию и прочая.
И на основании этого я делаю вывод, что да — необходимо спрашивать базовые вещи.
Особенно умиляют вопросы синьоров по Java — «а зачем нам знать как работает Garbage Collector?». А потом бегут с криками — нам надо еще 32 Гб ОЗУ — нам не хватает!
Особенно умиляют вопросы синьоров по Java — «а зачем нам знать как работает Garbage Collector?». А потом бегут с криками — нам надо еще 32 Гб ОЗУ — нам не хватает!
А можно кейс, в котором знание алгоритма гц джавы поможет в том случае, когда 32гб не хватает?
Могу глупость ляпнуть, ибо не джавист, но может быть важно знание умеет ли он удалять циклические ссылки.
Он удаляет. Но, согласен, если бы не удалял — это действительно был бы кейз, хорошее замечание :)
Там не важно, циклическая ссылка или нет — если ни один элемент из этого «кольца» не «достижим» из активного кода, то всё кольцо может быть удалено:
www.javarticles.com/2016/09/java-garbage-collector-reachable-and-unreachable-objects.html
www.javarticles.com/2016/09/java-garbage-collector-reachable-and-unreachable-objects.html
Нечто, что не способно удалять циклические ссылки, недостойно называться GC :-)
Конечно.
Речь не идет о доскональном знании алгоритмов gc (они довольно сложны, как Я представляю), а в принципе о том, как выделяется и освобождается память с учетом работы GC, представлять, как работает счетчик ссылок и что высвобождение не мгновенное, что есть проблема циклических ссылок, которая и делает процесс сложным.
При оптимизации по памяти можно определить узкие места, и зная, к примеру, что пересоздание списка в глубоком вложенном цикле — плохая идея, переиспользовать этот список, создав его один раз.
Речь не идет о доскональном знании алгоритмов gc (они довольно сложны, как Я представляю), а в принципе о том, как выделяется и освобождается память с учетом работы GC, представлять, как работает счетчик ссылок и что высвобождение не мгновенное, что есть проблема циклических ссылок, которая и делает процесс сложным.
При оптимизации по памяти можно определить узкие места, и зная, к примеру, что пересоздание списка в глубоком вложенном цикле — плохая идея, переиспользовать этот список, создав его один раз.
Просто вы как-то так неудачно сформулировали, что вроде как знание принципов работы гц позволит впихуть в 32гб невпихуемое в 32гб, что, как мне кажется, ложно.
А то, что можно при должных знаниях затюнить профиль использования памяти и в общем поднять быстродействие приложения за счет этого — это понятно.
При оптимизации по памяти можно определить узкие места, и зная, к примеру, что пересоздание списка в глубоком вложенном цикле — плохая идея, переиспользовать этот список, создав его один раз.
В jvm же есть nursery? Если за его пределы не выйдет, то, в принципе, ничего совсем уж плохого не случится, по идее.
Мне было забавно, когда дали задание на позиции .NET разработчика — Что выведет консоль и правильно ли работает код —
for(var i = 0; i < 10; i++) {
setTimeout(function() {
console.log(i)
}, 100);
}Серьезно?
Я такое каждый день пишу))) (сарказм)
А оказалось что это всего лишь вопрос на знание API JS — Должно быть так —
for(var i = 0; i < 10; i++) {
setTimeout(function(i) {
console.log(i)
}, 100, i);
}Еще и пытались что то вытянуть по поводу IEnumerable, что правда не ясно.
Ожидали Lazy, LazyRef....
И вроде как известная достаточно в Екатеринбурге компания занимающаяся разработкой софта для бухгалтеров.
Вот так вот и бывает)
А оказалось что это всего лишь вопрос на знание API JS — Должно быть так —
Вроде в c# точно так же работает. Вот допустим, у нас есть пять кнопок, что выведется в консоль при клике на третью?
for (var i = 0; i < buttons.Count; i++) {
buttons[i].onClick.AddListener(delegate {
Console.WriteLine(i);
});
}
Вроде это известный прикол. 5. И ещё от версии зависит.
Так в том-то и дело, что он общеизвестный для программистов на любом языке, где есть замыкания и изменяемые переменные. И нет, версии зависит цикл foreach, а цикл for работает одинаково во всех версиях языка.
Вроде это известный прикол
Именно! А в JS оно еще и встречается в десятки раз чаще. А теперь представьте, что Senior C# Developer понятия не имеет об этой особенности
А у меня вопрос, а зачем такое писать на c#?
И ещё, знатокам на засыпку, а если (про версии, и особенности реализации) представим ситуацию когда ядро исполняющие поток цикла после третьей итерации остановится(перегрев) а в этот момент придёт событие на третью кнопку, то есть гарантия что в будущей версии виртуальной машины результат будет 5?
Это вопрос не на знание API, а на понимание замыканий и проблем которые могут быть с ними связаны. Решений этой проблемы можно придумать множество, и знать API тут не нужно. Хотя, конечно же, со знанием API всегда проще.
Не по .NET, а про JS, но я помню у нас был баг связанный как раз с этой особенностью.
У меня было такое, что на позицию js разраба (фронтенд) спрашивали что такое интерфейсы и абстрактные классы с просьбой привести примеры из других языков. Я ответил, но задал встречный вопрос: «А зачем вы задаете такие вопросы js-разработчику?» На что мне ответили в духе «а вдруг мы захотим вас усадить писать бэкенд на Java, а вы не знаете этих терминов». После моей ремарки, что я на Java не писал, писать не планирую, и вообще претендую на роль js-фронтендера, как-то быстро свернули интервью.
Вы и представить себе не можете сколько людей приходят с, казалось бы, солидным опытом, но не могут ответить на элементарные вопросы.
Я пересобеседовал кучу народа на позицию синьора фронтенд. Половина не знает, что такое замыкание. Были и такие, кто не мог ответить чем == от === отличается.
против скайп-интервью есть хороший чит
называется браузер на 2м экране
называется браузер на 2м экране
ну видно же будет как у собеседуемого глаза разъезжаются:-)
Я как-то собеседовал одного соискателя — он такой «э… м… дайте подумать» и стук клавиш в фоне. Даже вебкамера не нужна, всё слышно.
Гугл ему всё равно не помог, т.к. на «открытых» вопросах валятся.
Это был Full Stack Overflow Developer
UFO just landed and posted this here
Это еще фигня, мой знакомый собеседовал паренька азиатской внешности на работе (Сидней). Крутой девелопер оказался, сделали оффер, договорились, что через месяц начинает. Когда начал работать оказалось, что как-то все не так, слабоват по всем фронтам. Только после окончания испытательного срока ребята поняли, что пришел работать совсем другой человек, просто похожий на того, кто был на собеседовании, но было уже поздно.
Кстати да, стук клавиш — это уже притча во языцах. Вывод — надо уметь свайпом на планшете быстро искать, или, чтобы друг в соседней комнате слышал вопросы, гуглил, и в мессенджер с выключеным звуком кидал
Ммм. А работать потом как?
А работать потом можно и со стуком :)
Так выгонят же
Почему выгонят? Вы не гуглите во время работы?
Я вон только в библиотеку бегаю за энциклопедиями по программированию!
Потому, что раз мне приходится вот так поступать во время собеседования, значит я профнепригоден. И это выяснится очень быстро.
Второй вариант почему мне приходится так поступать — это как раз неправильное собеседование и странный работодатель. Но и здесь непонятно зачем туда идти и как потом там работать.
Поэтому не вижу смысла в подобном подходе вообще.
Второй вариант почему мне приходится так поступать — это как раз неправильное собеседование и странный работодатель. Но и здесь непонятно зачем туда идти и как потом там работать.
Поэтому не вижу смысла в подобном подходе вообще.
Навык быстрого поиска правильной информации, по-моему, куда важнее, чем отличное знание редкоиспользуемого оператора. Я вон reduce узнал только на собеседовании, но мне предложили загуглить что это и «может тогда вы решите поставленную задачу» и я решил моментально, как увидел доку к reduce, и получил офер.
То, что для одного — редкоиспользуемый оператор, который можно загуглить, для другого — ежедневно используемый инструмент. Хорошо, если такой «оператор» один, а если их несколько десятков, то как читать и править код?
Через неделю-две эти операторы станут для вас часто используемыми, вот и все.
Точно так же как вы разберетесь со специфическими особенностями архитектуры текущего проекта, узнаете какие-то нетривиальные вещи из предметной области, привыкните к принятым в команде гайдлайнам и т.д..
Как минимум я просто не представляю ситуацию, когда вы меняете работу и на новой все 1-в-1 как на предыдущей, а значит — что то точно будет незнакомо. А если новая предметная область?
Прочесть апи оператора, да хоть десятка — не такая уж проблема, большая проблема — не уметь этого делать. А еще большая — спрашивать даже не загуглив.)
Прочесть апи оператора, да хоть десятка — не такая уж проблема, большая проблема — не уметь этого делать. А еще большая — спрашивать даже не загуглив.)
Потому, что раз мне приходится вот так поступать во время собеседования, значит я профнепригоден. И это выяснится очень быстро.
Мне вот во время работы постоянно так поступать приходится. Если принять, что собеседование проверяет рабочие навыки, то, с-но, придется и во время собеседования.
Если вас собеседует нормальный человек и задает вопрос, ответ на который не считается зазорным загуглить, то вам не придется скрывать от него то, что вы что-то ищете в сети.
Скрывать приходится в двух случаях — если профнепригоден соискатель или если профнепригоден человек, проводящий собеседование.
В обоих этих случаях нет смысла стремиться на эту работу. В первом случае выгонят, во втором быстро уйдете сами.
Скрывать приходится в двух случаях — если профнепригоден соискатель или если профнепригоден человек, проводящий собеседование.
В обоих этих случаях нет смысла стремиться на эту работу. В первом случае выгонят, во втором быстро уйдете сами.
Вообще, я писал с сарказмом. Но если уж восприняли по-серьезному, то на моей памяти реальных случаев, когда программиста выгоняли с работы за незнание вещей, которые спрашивают на собесе, не было вообще. Был 1 случай, когда выгнали за неспособность нормально работать в команде (человек старался увильнуть от работы, и всячески заставить работать других за него, решать проблемы за него, находить причины багов за него — оверхед лида при работе с ним был запредельный). Был 1 случай, когда поменялись ПМ и лид, и выгнали человека, который был реально странным (были проблемы с пониманием коллег, и что от него хотят). И я видел десятки случаев, когда людей отсеивали на этапе телефонного собеседования за неправильный ответ на 1-2 вопроса на знание. Это все объяснимо математически. Отсеять на этапе телефонного собеса == потерять 15 минут своего времени, уже потраченного на собес (по крайней мере, так считает большинство собеседующих), отсеять на этапе испытательного срока == признать свою некомпетентность, как интервьювера (у людей все еще есть предрассудок, что хороший интервьювер не может ошибиться) && потерять дни или недели, потраченные на его обучение && объяснить заказчику, почему вдруг сдвинулись сроки. Поэтому, терпят, дотягивают до нужного уровня, помогают. Если человек, который хитростью прошел собес реально толковый (а чтобы обмануть интервьювера, и при этом не попалится, мозги надо иметь), то, как правило, он все равно достигает необзходимого уровня, и проблема рассасывается сама собой.
Эх, знакомая история. Мне тоже такие попадались. Один еще по русски говорил не очень хорошо. Когда он мало стучал по клавиатуре, то от него приходили довольно развернутые ответы. Я их сразу копипастил в поисковик, по первой ссылке получал источник, откуда он их скопипастил.
В ответ на очередной вопрос он долго стучал по клавиатуре, видимо, не мог найти подходящий ответ, и ответил в итоге вот так:
Собеседование длилось очень не долго, но этот кандидат мне запомнился особенно.
Видно, что салага, опытные используют направленные микрофоны, чтобы посторонние звуки не были слышны))
Там, где я сейчас работаю, проблема самозванцев стояла достаточно остро: около половины кандидатов, выполнивших (якобы сами) тестовое задание, на очном собеседовании демонстрировали полную неспособность к программированию. Решение оказалось неожиданно простым: на первичном техническом интервью (по скайпу) стали просить решить элементарную задачу, типа перевернуть строку. С тех пор проблема исчезла.
А вообще да, очень мало кто умеет нормально собеседовать. Или определяют «на глазок», или совершенно нерелевантные вопросы.
А вообще да, очень мало кто умеет нормально собеседовать. Или определяют «на глазок», или совершенно нерелевантные вопросы.
Способность к программированию — не субъективно ли это?
В последнее время заметил, что большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами. Это всякие Яндексы навязывают тенденцию того, что человек, который умеет хорошо программировать, то он должен без труда решать простецкие житейские задачи на листке.
Зато если этому дяде сказать, что надо по-быстрому написать Backend на коленке с простым Rest-методом, который будет общаться через ORM с БД и брать оттуда первую строчку, позволив ему пользоваться Гуглом, он накидает Backend за 15 минут и еще сверху расскажет, какие проблемы есть, например, в Hibernate с пагинацией и как её поправить.
Тут всё сугубо индивидуально и риск найти самозванца есть всегда. Нужно задавать правильные вопросы и смотреть по ситуации.
P.S. Задания типа reverse() или кастомный стек — это походу классика уже наверное) Я не против заданий, но это не всегда является прямым показателем знаний.
В последнее время заметил, что большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами. Это всякие Яндексы навязывают тенденцию того, что человек, который умеет хорошо программировать, то он должен без труда решать простецкие житейские задачи на листке.
Зато если этому дяде сказать, что надо по-быстрому написать Backend на коленке с простым Rest-методом, который будет общаться через ORM с БД и брать оттуда первую строчку, позволив ему пользоваться Гуглом, он накидает Backend за 15 минут и еще сверху расскажет, какие проблемы есть, например, в Hibernate с пагинацией и как её поправить.
Тут всё сугубо индивидуально и риск найти самозванца есть всегда. Нужно задавать правильные вопросы и смотреть по ситуации.
P.S. Задания типа reverse() или кастомный стек — это походу классика уже наверное) Я не против заданий, но это не всегда является прямым показателем знаний.
Что человек, который каждый день программирует, не сможет в реальном времени написать реверс строки (у нас можно хоть на псевдокоде, мы не требуем, чтобы оно компилировалось) — в это я не очень верю, честно говоря. С «поговорить» у таких кандидатов тоже всегда были проблемы.
Я реверс конечно ни разу не писал, но все таки вы так часто работаете со строками?
Строки в большинстве случаев у нас иммутабельные — это уже заставляет нас какой то промежуточный объект вводить (библиотечный или свой) который бы содержал строку в массиве. А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок… Из за чего если работать просто с массивом байт, и, возможно, даже с массивом символов, можно словить проблем…
Строки в большинстве случаев у нас иммутабельные — это уже заставляет нас какой то промежуточный объект вводить (библиотечный или свой) который бы содержал строку в массиве. А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок… Из за чего если работать просто с массивом байт, и, возможно, даже с массивом символов, можно словить проблем…
У нас специфика предполагает а) достаточно низкоуровневое программирование б) способность решать новые задачи. Поэтому ответ «я не могу перевернуть строку, потому что никогда не работал со строками» — это, наверное, действительно не к нам.
Я не знаю, какой будет пример элементарной задачи в вашей области, мне строки казались достаточно универсальным примером, но я мог отстать от жизни.
Я не знаю, какой будет пример элементарной задачи в вашей области, мне строки казались достаточно универсальным примером, но я мог отстать от жизни.
Хм, ну тогда еще вопрос уточню: используется какая то простая кодировка (размер символа фиксированный, последовательность символов не важна) или одна из кодировок где символы имеют разный размер в байтах и зависят от соседних символов?
Нет, конечно, мы же действительно не нанимаем специалиста по строкам. Если используется эта задача, то всегда уточняется (если возникают вопросы), что имеется в виду zero-terminated ASCII.
UFO just landed and posted this here
Так если не спрашивает — это самым конкретным образом характеризует кандидата
Не знаю про какой язык вы говорите, но если меня просят перевернуть строку не конкретизируя кодировки, тип хранени яи прочее — я исхожу из того, что класс строк умеет отдавать и писать отдельные символы и знает свою длину.
Это считай базовый функционал любой стандартной либы в большинстве языков.
Как меня это характеризует?
Это считай базовый функционал любой стандартной либы в большинстве языков.
Как меня это характеризует?
Гм, могу ошибаться но как минимум в некоторых языках как раз из за разных хитрых кодировок доступ по индексу к символу в худшем случае O(N) может быть.
Хитры кодировки c O(N) — это UTF8 чтоли?
Задача «Перевернуть UTF-8 строку сохраненную в массиве оптимальным способом» звучит совсем не так как «Перевернуть строку». Не находите?
«Перевернуть строку» по умолчанию предполагает абстрактную строку, допущения бессмысленны. Если уточнений нет, значит они не критичны.
Задача «Перевернуть UTF-8 строку сохраненную в массиве оптимальным способом» звучит совсем не так как «Перевернуть строку». Не находите?
«Перевернуть строку» по умолчанию предполагает абстрактную строку, допущения бессмысленны. Если уточнений нет, значит они не критичны.
Исходя из моей практики — я предпочту на всякий случай поуточнять задачу. А то потом у клиента или консультанта который описывал задачу будут вопросы в духе: а этого почему нет? Это же очевидно. А тут не так должно работать. И вообще конкретно этот функционал только в мобильном клиенте должен быть. Зачем вы его в десктопном сделали?
Всё еще не вижу сложности в этой задаче. За миунуту написал как раз решение для любых строк:
fn main() {
let str = "Hello world !";
let reverted: String = str.chars().rev().collect();
println!("{}", reverted);
}Единственное, что я сначала назвал метод revert, но гугл быстренько подсказал, что правильное написание rev. Но я полагаю, на это можно было бы закрыть глаза в любом случае.
Зато тут теперь есть о чем поговорить с кандидатом: какова стоимость разворота итератора, как вообще они работают, map/filter/fold/collect… Разве нет?
Хм, растовый парсер видимо не умеет в UTF8 (между пробелом и знаком восклицания есть символ U+2764). вот на плейграунде: https://play.rust-lang.org/?gist=4e20c472150ea4270906cafe08048ef8&version=stable&mode=debug&edition=2015
Так неважно, какой язык: в нашей с вами работе ( не на собеседовании ) постоянно оказывается, что задача поставлена неполно. И без уточняющих вопросов ее в лучшем случая решить не получится, а в худшем будет потрачено время на решение не той задачи.
Возващаясь же к собеседованию: никто не будет спрашивать у вас, знаете ли вы библиотечную функцию переворота строки, вычисления арккотангенса или преобразования строки в ЗаБоРчИк. Когда дают такой вопрос, желают посмотреть, как вы задачу будете решать. И если вдруг вы знаете готовую функцию для решения этой задачи, что ж, значит вопрос пропал впустую. Датут другой.
Возващаясь же к собеседованию: никто не будет спрашивать у вас, знаете ли вы библиотечную функцию переворота строки, вычисления арккотангенса или преобразования строки в ЗаБоРчИк. Когда дают такой вопрос, желают посмотреть, как вы задачу будете решать. И если вдруг вы знаете готовую функцию для решения этой задачи, что ж, значит вопрос пропал впустую. Датут другой.
В нашщей с вами работе мы знаем над чем работаем.
Если у нас условный UTF-8 и ОЧЕНЬ МНОГО обращений по индексу — у нас будет класс, для работы с UTF-8, в котором под каждый символу будет выделен отдельный буффер и доступ к чару будет по O(1) но зато с потерей оперативки и чуть более долгой загрузкой строки в память.
В реальности в отличии от собеседования задачи существуют в контексте и часто уточнения не нужны, потому что понятно что за задача, откуда она взялась и как должна работать.
Собеседование же максимлаьно абстрактное, не задавать вопросов предполагая некоторое дефолтное поведение — вполне норм. Если собеседующему не понравятся ваши допущения, он уточнит.
Таким образом чаще всего уточнения не нужны ни в реальной работе ни на собеседовании.
Если у нас условный UTF-8 и ОЧЕНЬ МНОГО обращений по индексу — у нас будет класс, для работы с UTF-8, в котором под каждый символу будет выделен отдельный буффер и доступ к чару будет по O(1) но зато с потерей оперативки и чуть более долгой загрузкой строки в память.
В реальности в отличии от собеседования задачи существуют в контексте и часто уточнения не нужны, потому что понятно что за задача, откуда она взялась и как должна работать.
Собеседование же максимлаьно абстрактное, не задавать вопросов предполагая некоторое дефолтное поведение — вполне норм. Если собеседующему не понравятся ваши допущения, он уточнит.
Таким образом чаще всего уточнения не нужны ни в реальной работе ни на собеседовании.
UFO just landed and posted this here
Умение понять условие задачи и объяснить, что решение будет разным для разных строк — один из полезных навыков.
Ну, в таком случае задачка конечно действительно выглядит несложной. Правда в таком случае начинает напрягать вопрос «Где подвох»? Уж слишком просто все на первый взгляд.
Уж слишком просто все на первый взгляд.
Множество «программистов» не может fizzbuzz написать.
Какие уж тут строки и массивы(OMG!)
Наверное я плохой программист — мне пришлось гуглить что такое fizzbuzz.
Писал тут про эту задачу, не помнил как называется, написал fuz buz… Эх)
А ответ в стиле: В цикле +1 на каждом шаге начиная с первого и последнего менять их местами вас не устроит? Зачем вообще лезть в кодировки? Вас ведь задачу решить просят а не программу написать.
Потому что лично я настолько простых задачек просто не ожидал бы и поэтому решил бы, что как многие любят — задачка с хитростью.
Не стоит. 80% людей, которые приходят на собеседование на Синиора не могут решить задачу в простейшем виде. Они даже не могут ответить, что значат слова, написанные в их собственном резюме! Например «что такое Design Patterns» или «чем отличается React от Angular», хотя в резюме написано, что он их оба знает хорошо. Не понимаю, на что она рассчитывают. Что будут смотреть только по резюме, на собеседовании не будет тех специалиста и они смогут получить зп за месяц?
UFO just landed and posted this here
Почему, возможный вариант. Это действительно пример теста на человека, который с кодом дела не имеет в принципе. Не знаю, удивитесь ли вы, но таких много стучится.
UFO just landed and posted this here
Вовсе не плохо на мой взгляд. Это показывает, что человек правильно считывает требования из контекста. К тому же все сейчас работают по Agile, и если где-то требования не уточнили сразу, это поправимо.
UFO just landed and posted this here
На питоне правильный ответ на такой вопрос: s[::-1], и это называется знать свои инструменты. Не стоит отвергать очевидное решение потому что оно очевидно.
Правда я не Software engineer и там может быть свой мир, но отбрасывать очевидные решения по причине простоты думаю что все равно не стоит.
В материалах по подготовке к собеседованиям это часто упоминается.
На JS это выглядит как-то так:
str.split('').reverse().join('').
Вот, кстати, интересно мнение сообщества по поводу такого ответа. Мне напрашивается вопрос: «А вы бы применили такое решение в production?». И вот в зависимости от ответа на этот вопрос уже решать, хороший это вариант ответа или нет.
Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект (+ ещё reverse массива этих временных объектов).
На это можно возразить, что преждевременная оптимизация – корень всех зол и всё в таком духе, но это тоже вопрос довольно спорный, т.к. в плане выбора подходящих алгоритмов и структур данных, обычно проще сразу делать «нормально».
Соответственно, если человек отдаёт себе отчёт в побочных эффектах такого кода, и написал просто потому что это удобный однострочник, то всё хорошо. А вот если нет – то это пойдёт в минус, а не в плюс.
Если в JS это хороший способ (например, более эффективный вариант является слишком громоздким или эта конструкция как-то оптимизируется или что-нибудь в таком духе) – мой комментарий можно игнорировать. Как я уже сказал, я с JS не очень дружу)
Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект (+ ещё reverse массива этих временных объектов).
На это можно возразить, что преждевременная оптимизация – корень всех зол и всё в таком духе, но это тоже вопрос довольно спорный, т.к. в плане выбора подходящих алгоритмов и структур данных, обычно проще сразу делать «нормально».
Соответственно, если человек отдаёт себе отчёт в побочных эффектах такого кода, и написал просто потому что это удобный однострочник, то всё хорошо. А вот если нет – то это пойдёт в минус, а не в плюс.
Если в JS это хороший способ (например, более эффективный вариант является слишком громоздким или эта конструкция как-то оптимизируется или что-нибудь в таком духе) – мой комментарий можно игнорировать. Как я уже сказал, я с JS не очень дружу)
Если на продакшине этот код не создает узких мест ( то есть редко вызывается ) то я бы применил нечто простое зато читаемое. Ну при условии что написать более оптимальный либо дольше пары минут, либо он будет намного менее читаемым.
«А вы бы применили такое решение в production?».
Именно такое решение и применяю.
Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект
Не больше, чем, если вы напишете всё это вручную. По сути, вам придется делать всё то же самое, строки ведь иммутабельные
Помимо сказанного ранее добавлю, что если бы и были мутабельные строки, оптимизировать это почти во всех случаях — что экономить на спичках. Тем более, что код на JS в половине случаев выполняется на клиенте, у которого вполне есть ресурсы (в отличие от сервера, который может быть высоконагружен, и там может хотеться экономить даже на переменных).
Так что — да, это в продакшене широко применяется.
Так что — да, это в продакшене широко применяется.
Тем более, что код на JS в половине случаев выполняется на клиенте, у которого вполне есть ресурсы
Извините, я понимаю, что это решение, судя по ответам, действительно в большинстве случаев приемлемо, но просто не могу удержаться) В итоге имеем то, что имеем)
Если мы реальность берем — я вообще идей не имею кому и зачем могло бы понадобиться строку перевернуть) А так… Я на удивление придерживаюсь мнения противоположного, пользователь должен по минимуму «платить» вычислительными ресурсами, а вот железо на сервере зависит только от того кто сервисом владеет, и он его может масштабировать. Поэтому я терпеть не могу большинство js приложений (в смысле не в браузере, а всякие электроны и подобное) как и некоторые java (память jvm кушает...), но вполне нормально отношусь к такому на сервере)
Давайте представим, что вам для каждого пользователя нужно перевернуть одну строку. Вы можете сделать это на клиенте — для человека это займёт меньше 1 мс! Или же вы можете сделать это на высоконагруженном сервере. Перевернуть строку для 100 000 клиентов скушает пару секунд. Все эти пару секунд сервер (ну или поток, по крайней мере) будет простаивать и не сможет никому отвечать.
Пример утрированный, конечно, но я хотел показать, что операция может стоить для вас очень много, а для пользователя не стоить ничего. Вот именно это я имел в виду, говоря, что клиента нагружать можно больше, чем сервер.
Ну и вообще-то все обычные десктопные приложения замечательно работают на мощностях клиентов, так было всегда, и всем это ок. А вот если попробуете например сделать редактор изображений и реализуете всю графику на сервере, будет интересно посмотреть на его мощности и сколько это будет стоить.
Пример утрированный, конечно, но я хотел показать, что операция может стоить для вас очень много, а для пользователя не стоить ничего. Вот именно это я имел в виду, говоря, что клиента нагружать можно больше, чем сервер.
Ну и вообще-то все обычные десктопные приложения замечательно работают на мощностях клиентов, так было всегда, и всем это ок. А вот если попробуете например сделать редактор изображений и реализуете всю графику на сервере, будет интересно посмотреть на его мощности и сколько это будет стоить.
Понятно что до маразма не нужно доводить, но если есть возможность — то на клиенте лучше оптимизаций побольше на мой взгляд делать. А то потом появляются электроны всякие и подобное из желания вообще не заморачиваться и лепить что попало. Не, понятно что если речь про мелкую строку то оптимизировать смысла нет. А если речь уже про что то существенное? Ну и 50 мс на одну операцию, 50 на другую и привет. И если например есть возможность сделать (за адекватные сроки и без диких хаков усложняющих поддержку) вместо 50мс — 5мс — то это сделать стоит. Потому что пользователь не может взять, и заменить свой ноут на целероне на пк с i9. А вот сервер масштабировать мы можем гораздо проще, поэтому там во многих случаях «на спичках» можно и не экономить (не доводя опять же до маразма).
[...str].reverse().join('') — выглядит короче, работает с сурогатными парами, но не с комбинированными символами.
UFO just landed and posted this here
или так
console.log([..."123456789"].reduce((a,c)=>c+a));Конечно нельзя к строке относится как к однбоайтовой.
К ней надо относится как к абстрактной сущности, которая умеет отдавать длину, и читать/писать символы под индексу. А уж что там внутри — пофиг вообще.
Вас же просят строку перевернуть, а не массив байт изображающих чары в неведомой кодировке.
К ней надо относится как к абстрактной сущности, которая умеет отдавать длину, и читать/писать символы под индексу. А уж что там внутри — пофиг вообще.
Вас же просят строку перевернуть, а не массив байт изображающих чары в неведомой кодировке.
Они превращаются в какую-то угадайку о том, что хотел сказать интервьювер.
По-моему, в таком случае правильно задавать дополнительные вопросы и характр этих вопросов очень хорошо показывает на каком уровне человек решает задачу
UFO just landed and posted this here
В одном из моих недавних собеседований:
— Как бы ты реализовал вот такую систему? (описание требуемой функциональности)
— (описываю возможную реализацию)
— Хорошо, а как бы ты её реализовал на кластере?
— А зачем её реализовывать на кластере? Чего мы пытаемся этим достичь?
— Эээ… Не важно, просто поступило требование реализовать её на кластере.
— Окей, пусть одна нода выполняет вышеописанную реализацию, остальные пусть простаивают.
— Эээ… Ну окей.
— Как бы ты реализовал вот такую систему? (описание требуемой функциональности)
— (описываю возможную реализацию)
— Хорошо, а как бы ты её реализовал на кластере?
— А зачем её реализовывать на кластере? Чего мы пытаемся этим достичь?
— Эээ… Не важно, просто поступило требование реализовать её на кластере.
— Окей, пусть одна нода выполняет вышеописанную реализацию, остальные пусть простаивают.
— Эээ… Ну окей.
Ну как вам сказать… Мне не раз приходил FSD по которому я делал свою реализацию, а потом прибегал аналитик и кричал на меня, что все не так. Хотя все сделано по FSD и работает так как написано в FSD (по секрету скажу, что оказывалось что аналитик просто сделал copy/paste). Потом начинались наезды, что мол если я что-то не понял, то я обязан был задавать вопросы, а не тупо писать код. Т.е. оказывалось, что я должен быть еще и телепатом или уметь читать между строк. Потом наезды начинались и со стороны PM. Который требовал от меня овладеть навыками телепатии.
В других проектах было и так, что притаскивали криво написанный FSD, я начинал задавать вопросы что бы понять что на самом деле стоит за его весьма туманными формулировками. Мне отвечали на «от*бись»: типа делай как хочешь, но чтобы было по FSD и работало, а потом начинались наезды из серии, что раз я задаю так много вопросов, то я плохой разработчик. Ну и конечно прибавлялись снова требования стать телепатом. Потому что моя реализация естественно расходилась с задумкой аналитика.
Короче каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад. Вот на это и нужно проверять человека на собеседовании ;-)
В других проектах было и так, что притаскивали криво написанный FSD, я начинал задавать вопросы что бы понять что на самом деле стоит за его весьма туманными формулировками. Мне отвечали на «от*бись»: типа делай как хочешь, но чтобы было по FSD и работало, а потом начинались наезды из серии, что раз я задаю так много вопросов, то я плохой разработчик. Ну и конечно прибавлялись снова требования стать телепатом. Потому что моя реализация естественно расходилась с задумкой аналитика.
Короче каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад. Вот на это и нужно проверять человека на собеседовании ;-)
каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад
А разве это не должен делать его начальник?
Или его начальник ни зачто не отвечает, в том числе и за действия своих подчинённых?
Косяк подчинённых = косяк начальника в качестве руководителя.
PM свой зад прикрывает. Вот у меня был случай когда работали над проектом где объем работ предполагал наличие как минимум 4-х разработчиков причем не Junior, а работали фактически мы на пару с team lead'ом. Нет, приходили конечно люди, но увидев как все сложно сливались максимум через месяц. Про это не раз говорилось на совещаниях. Но курс был на экономию. В итоге, сроки мы просрали. Крайним сделали team lead'а, вынудив его уволится чтобы сохранить лицо перед заказчиком, а PM пошел на повышение.
Возможно человек англосакс или индус?
Это будет два цикла.
Первый должен будет найти собственно конец строки.
Первый должен будет найти собственно конец строки.
в таком случае, есть вариант с одним циклом, без использования доп. памяти?
По опыту: я провел довольно много (уж не менее 30) собеседований с кандидатам на вакансию программиста C, и мы задавали именно такую задачку на переворот строки.
Формулировка задачи — написать функцию, переворачивающую null-terminated строку, используя минимум памяти. Символы однобайтовые.
Переворот таким циклом, как вы написали — совершенно нормальное решение.
Но — справляются с задачей 25-30% собеседуемых.
Сумма составляется так: примерно 10% пишут правильный код, 10-15% почти правильный или правильный после наводящих вопросов. 5% не понимают, что такое «используя минимум памяти», но строчку переворачивают.
А половина испытуемых даже не могут написать функцию C на бумажке, любую.
Из тех, кто не справляется — говорят все обычно идеально. В итоге мы стали сначала давать задачу, а потом общаться, т.к. жалко времени.
Тем, кто справляется, даем табличку с кодировками символов UTF-8 и просим теперь на тех же условиях перевернуть строчку, состоящую из символов UTF-8. На самом деле, это простая получается задачка. Если человек затрудняется, просим решить дома и написать нам. Из всех собеседований только 1 или 2 человека предложили решение.
Формулировка задачи — написать функцию, переворачивающую null-terminated строку, используя минимум памяти. Символы однобайтовые.
Переворот таким циклом, как вы написали — совершенно нормальное решение.
Но — справляются с задачей 25-30% собеседуемых.
Сумма составляется так: примерно 10% пишут правильный код, 10-15% почти правильный или правильный после наводящих вопросов. 5% не понимают, что такое «используя минимум памяти», но строчку переворачивают.
А половина испытуемых даже не могут написать функцию C на бумажке, любую.
Из тех, кто не справляется — говорят все обычно идеально. В итоге мы стали сначала давать задачу, а потом общаться, т.к. жалко времени.
Тем, кто справляется, даем табличку с кодировками символов UTF-8 и просим теперь на тех же условиях перевернуть строчку, состоящую из символов UTF-8. На самом деле, это простая получается задачка. Если человек затрудняется, просим решить дома и написать нам. Из всех собеседований только 1 или 2 человека предложили решение.
> А половина испытуемых даже не могут написать функцию C на бумажке, любую.
Писать код на C на бумажке будет только мазохист. Чтобы красиво выводить курлявые скобочки пером — это нужно годами не вылезать с собеседований. Жить там. Белый же человек посмотрев на свои каракули вздрогнет, извинится за потраченное время и тихонечко уйдет.
Писать код на C на бумажке будет только мазохист. Чтобы красиво выводить курлявые скобочки пером — это нужно годами не вылезать с собеседований. Жить там. Белый же человек посмотрев на свои каракули вздрогнет, извинится за потраченное время и тихонечко уйдет.
Не проблема, если попросите ноутбук — вам его дадут. Но там 10 строк, стоит ли?
Для меня — однозначно да. Даже если одна строка. Мне настолько комфортнее нажимать на кнопки, чем держать в руках ручку, что я просто буду меньше нервничать и, соответственно, больше внимания уделять самому вопросу.
Некоторым людям удобнее визуализировать код на какой-то поверхности, чем в голове. А экран ноутбука более располагает к правкам, чем листок бумаги.
А вот интересно, люди, дающие задачки на собеседованиях, сами готовы задачки подобные решать? «Задачки» даются, видимо, «со своей поляны», которая с некоторой долей вероятности для собеседуемого (любой квалификации) может оказаться «чужой». Однако и собеседуемый ведь может сыграть в эту игру, и тогда уже собеседующий окажется «на чужой поляне».
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Если что, то простив задач на собеседовании в принципе, и считаю, что нужно уметь обходиться без оных.
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Если что, то простив задач на собеседовании в принципе, и считаю, что нужно уметь обходиться без оных.
Знаете, это мое собеседование, я набираю человека в команду и мне с ним работать. Я не хочу потом работать за него, вместо него. Поэтому я задаю вопросы, которые считаю нужным. Если человек правда считает, что перевернуть строчку на языке C — задачка "со своей поляны", обижается, борется со мной или убегает — наверное я его не возьму. В конце концов, в работе бывают всякие моменты и надо адекватно реагировать. Но я вам могу сказать, что таких не встречал на собеседованиях.
Главное чтобы вы потом сами ответ поняли. Вот у меня как-то было собеседование и там товарищ предложил мне задачку просуммировать биты в байтовом массиве. При этом можно использовать любой язык программирования, а алгоритм должен быть максимально быстрым. Ну я использовал ассемблер для Pentium I. Сделал все как надо. В итоге мой алгоритм загружал все ALU процессора и складывал сразу по нескольку бит. Но тот товарищ не поверил мне что такое вообще возможно. Я нарисовал ему схему алгоритма. Рассказал как все работает, но он не поверил все равно. Типа сказал что так не бывает. Такие дела.
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Обычно есть некоторое количество кандидатов из которых надо выбрать, и вакансия, на которую надо принять человека. После собеседования N кандидатов примерно понятен их уровень и выбирается уже из них. Если на задачке совсем все заваливаются она просто не достигает своей цели — подсказать кого выбрать из пула. Соответственно задача калибруется.
А вот интересно, люди, дающие задачки на собеседованиях, сами готовы задачки подобные решать?
Я ходил на собеседования к очень крутым ребятам. Иногда меня даже выбивали в зону, где я ощущал себя некомфортно в плане знаний. И это было круто — ты реально общаешься с крутым технарем и вам есть о чем поговорить и ты сам узнаешь свои слабые стороны.
На последнем собеседовании меня гоняли по архитектуре. Ну начиналось все с классики, когда дают пример, ты используешь наследование, а потом контр-пример, который делает наследование неактуальным и ты используешь композицию, потом тебя ставят в еще более неудобное положение, а ты ищешь из него выход.
И всё это на белой доске маркером. В такие моменты ты просто общаешься с прогерами, делишься опытом, рассказываешь, как ты в реальной жизни стыкался с этими проблемами и как их решал.
Про это кстати недавно наткнулся на интересное решение этой проблемы: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/. Для кого-то может и очевидная штука, а я вот был крайне удивлен.
UFO just landed and posted this here
Мсье знает толк в извращениях! Нет, такого не было. Но вот раз человек использовал alloca для экономии памяти, считая, что эта функция не использует память (в понимаемом им смысле). А ещё раз, на другом тестовом задании, видел использование setjmp/longjmp — вот это было круче всякой рекурсии. Фамилия кандидата была не Ричи, если что.
А насколько часто вам приходится проводить код ревью для реализации функции, которая переворачивает строку с оптимизацией по памяти?
Я не говорю о том, что задача сложная или как-то оценить вас или качество кандидатов. Я пытаюсь понять насколько ваш вопрос имеет отношение к задаче, которую вам поставил бизнес.
Я не говорю о том, что задача сложная или как-то оценить вас или качество кандидатов. Я пытаюсь понять насколько ваш вопрос имеет отношение к задаче, которую вам поставил бизнес.
В принципе, это релевантная задача: мы занимаемся embedded, так что об экономии памяти нужно думать всегда. Но настоящая цель такой задачи — просто отсечь самозванцев, как это было метко подмечено в комментариях ниже.
Вообще "по бизнесу" в моей области можно поговорить о многом, человек не может знать всего, но он может имеет необходимые для работы качества, и мы его сразу возьмём. Поэтому, никаких сложных вопросов по программированию я не задаю, просто хочется знать, может он программировать или нет — для оценки нужности разговора.
Экономия памяти — это хорошо. Но умение решать одну задачу никак не говорит о способности думать об экономии памяти системно. Если вы пользуетесь задачей для первичного фильтра — ок, но как вы копаете дальше в эту тему?
Дальше нужно разговаривать. У нас требуется, в идеале, много разных знаний и опыта. Найти при этом человека, который ещё и действительно системно мыслит -большая удача. Тут уже речь не об отсеивании кандидатов, скорее поиск потенциала роста. Но даже если системное мышление хромает, найти применение в целом хорошему специалисту можно.
Я не знаю, какой будет пример элементарной задачи в вашей области, мне строки казались достаточно универсальным примером,
FizzBuzz же: выведите n строк — k-ая строка должна начинаться с числа k. Потом содержать Fizz, если k делится на 2 и/или Buzz, если k делится на 3:
1
2 Fizz
3 Buzz
4 Fizz
5
6 Fizz Buzz
...```Это уже следующий уровень сложности. Тут надо понимать, что такое «делится на 2», «делится на 3» и «делится на 6» и как эти множества друг с другом соотносятся. А если человек забыл, что такое делимость? Или в реальных проектах работает исключительно с float? Или настолько продвинутый алгебраист, что не может решить, в каком кольце ему эту задачу решать? В общем, со строками как-то спокойнее.
А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок…
Ну, раз пошла такая пьянка пошёл разговор о внутреннем устройстве кодировок, то помните, что Вы сами напросились.
Я б на все такие вопросы отвечал: «как вам удобнее».
А еще лучше, уже на вопросе
Переключился на эту тему и узнал, как бы он это реализовывал
Ну или здесь, тоже ведь отличная тема!
Интересное замечание про шифрование и сжатие. Я бы с удовольствием послушал, как он бы решал эту проблему.
В итоге и сам, может, чего новое узнал и оценил уровень знаний человека и собес совершенно нестандартный и интересный.
А еще лучше, уже на вопросе
Должен ли я предусмотреть защиту от атаки через подмену букв со сходными начертаниями (например, турецкой I)?
Переключился на эту тему и узнал, как бы он это реализовывал
Если только речь не идёт о копировании файла самого в себя (это тоже интересный вопрос...)
Ну или здесь, тоже ведь отличная тема!
Не хочу отклоняться от темы, но мне кажется, что такое поведение создаст серьёзную дырку в безопасности. Особенно в случае если файловая система, на которую мы копируем файл, поддерживает произвольные атрибуты (прямо или косвенно).
Интересное замечание про шифрование и сжатие. Я бы с удовольствием послушал, как он бы решал эту проблему.
В итоге и сам, может, чего новое узнал и оценил уровень знаний человека и собес совершенно нестандартный и интересный.
Я бы в уме поставил + такому человеку за технические навыки, и — за конструктивность и желание сотрудничества (после попытки объяснить явно что от него в целом требуется на собеседовании типа «напишите копирование файлов без учета всех этих тонкостей, а потом расскажите про компромиссы на которые пришлось пойти для скорости написания»)
Тебе нужен специалист, который шарит в необходимых технологиях и у него проекты есть, и вроде понимание как это должно работать, какие есть проблемы — экспертиза одним словом. И ты ему не даш шанс из-за того, что он на бумажке не может код написать?))
Недавно книгу одну читал, что люди очень любят производить оценку по себе. Все что тебе кажется очень легким, очевидным и простым, для другого может оказаться не так тревиально. Поэтому, если уж человек не совсем идиот и я вижу энтузиазм, желание работать и развиваться, то почему бы не дать шанс? Ааа, он же кодить на бумаге не может… Что ж, будем искать человека который может...
Как вы определяете, что такое «не совсем идиот»? Наше определение включает способность решить простую программистскую задачу. Но даже если бы и не включало — из тех «самозванцев», что приходили к нам, не было такого, чтобы человек не мог написать код, но демонстрировал экспертные знания (или хоть какие-то знания) в указанных с резюме технологиях.
UFO just landed and posted this here
UFO just landed and posted this here
Мы добрые, правда =) Это все задачи не для того, чтобы подловить, а чтобы отсеять тех, кто тупо не знает, что такое «переменная», «цикл» и как ими пользоваться.
UFO just landed and posted this here
Суть в том, что есть куча людей, которые как замечено ниже не понимают что такое переменная и цикл.
А зачем такие люди идут на собеседование на должность программиста, на что они рассчитывают? Работать-то придется все равно. Странно получается, я никогда не работал в должности программиста, хотя и написал пару простеньких программ на C++/Qt5 (вроде калькулятора и маленького оракл клиента отправляющего заранее написанные запросы из конфиг файла с пользовательскими параметрами в базу и вывод результата в человекопонятном виде), но я не суюсь на собеседования потому что понимаю, что этого мало даже для джуниора, а приходят люди не знающие что такое цикл?!
Суть же не в том чтобы сразу написать идеальное решение, а представить ход мыслей и сколь-нибудь разумное решение, в котором смочь увидеть проблемы (возможно с подсказкой) и предложить решени
UFO just landed and posted this here
Быстро и без ошибок и я не видел. Видимо, они все в Яндексе трудятся)
Вот быстро и с ошибками — видел. Особенно интересно, когда такой человек работает в ночь, а ты утром приходишь и все поломано в разных местах) Правда человек за ночь делает то, что я делал в среднем за неделю, но отлавливать и чинить… В общем, есть специфика)
Вот быстро и с ошибками — видел. Особенно интересно, когда такой человек работает в ночь, а ты утром приходишь и все поломано в разных местах) Правда человек за ночь делает то, что я делал в среднем за неделю, но отлавливать и чинить… В общем, есть специфика)
можно предположить, что кандидат которого взяли или делал меньше ошибок, или предложил более элегантные решения, или еще как-то был «на одной волне» с интервьюером.
В собеседованиях так или иначе большая доля везения.
В собеседованиях так или иначе большая доля везения.
Ситуации, конечно, разные бывают. Но вы уверены, что дело обстояло именно так, как вам казалось? Т.е. могло же быть что, например, больше 50 процентов решения было подсказано интервьюером или же что вы тратили много времени на концептуально неправильное решение итд? Я обычно пытаюсь помочь канадидату дойти до решения, но это не значит, что любой решивший — это сильный кандидат.
UFO just landed and posted this here
Во-первых, суть в том, что задачу вы и не должны знать. Во-вторых, идеального решения никто не требует, с чего вы такое взяли? В-третьих, это вам кажется, что ни у кого получается. Может быть на самом деле эту задачу без проблем решает на достаточном уровне 70 процентов кандидатов?
UFO just landed and posted this here
Это не так. На собеседования в крупную компанию нужно готовиться
Нужно готовиться или нет — это зависит от ваших знаний/бэкграунда. Суть в том, что вам надо показать, как вы справляетесь с новой задачей, а не как рассказываете заученное решение. Поэтому желательно задавать задачу, которая по крайней мере не входит во всякие «топ вопросы для интервью».
Так требуют или не требуют? Вы определитесь, а то по второму кругу спорить начнем.
Т.е. для вас существует только концептуально неправильное решение и идеальное решение.
Вот видите, вы продолжаете настаивать на моей некомпетентности основываясь на часовом тесте
Я не «настаиваю», а только предполагаю вашу некомпетентность в рамках интервью. Я не пытаюсь ничего сказать об эффективности интервью в оценке ваших компетенций.
Почему же ее не смогли определить мои работадатели за 20 лет?
Так откуда мне знать, может вы эти 20 лет на 1С программировали? Вы же не пытаетесь со своими 20 годами опыта непонятно в какой области устроиться, например, адвокатом или хирургом?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Вы утверждаете что навык «писать код быстро без ошибок» — нужен только на собеседовании.
«Писать быстро без ошибок» — это утопия. Очень даже весомый кусок времени занимает не собственно написание, а отладка.
Индустрия не молода, так что статистики полным-полно.
Например:
1) On average, a developer creates 70 bugs per 1000 lines of code (!)
2) 15 bugs per 1,000 lines of code find their way to the customers
3) Fixing a bug takes 30 times longer than writing a line of code
4) 75% of a developer’s time is spent on debugging (1500 hours a year!)
5) In the US alone, $113B is spent annually on identifying & fixing product defects
coralogix.com/log-analytics-blog/this-is-what-your-developers-are-doing-75-of-the-time-and-this-is-the-cost-you-pay
UFO just landed and posted this here
Кстати, это значит что интервьюер внимательно проревьюил ваш код — причем моментально, и нашел там вырожденный случай
Ну нет же, интервьюер знает эту задачу и приготовил вырожденные случаи, и знает на что смотреть. У него время на подготовку было бесконечно и никакого давления, в отличие от.
Зарабатываю на программировании уже 20 лет.
В 99% случаев тормоза не имеют отношения к моей программе — в реальных проектах тормоза в СУБД, сети и пр. внешних факторах.
Просто «в вакууме» оптимизация алгоритма (логарифм/квадратичный и т.п.) сама по себе толку дает мало.
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
В 99% случаев тормоза не имеют отношения к моей программе — в реальных проектах тормоза в СУБД, сети и пр. внешних факторах.
Просто «в вакууме» оптимизация алгоритма (логарифм/квадратичный и т.п.) сама по себе толку дает мало.
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
UFO just landed and posted this here
Почему вы решили, что ваш случай и статистика верны для всех?
А почему вы решили, что статистика иная?
Тут все верно. Но далеко не все пишут CRUD приложения.
Львиная доля программистов пишет вовсе не библиотеки сортировки.
Большинство пишет именно прикладные проекты, где нужен ввод-вывод (сеть, диски — где и находится основная часть тормозов). Даже, казалось бы, такие далекие от СУБД ребята как game developer, и те в подавляющем большинстве своем не пишут сами движков (где была бы полезна эта оптимизация «логарифм/квадратичный») и тормоза у них значительно зависят не столько от правильного цикла, сколько от грамотной работы с движком, что лежит за пределами их кода.
А что писали лично вы за последние 10 лет? Учебные/студенческие работы/курсовые/дипломные если не считать.
UFO just landed and posted this here
Представьте, что этот движок кому-то надо писать. Да, львиная доля этим не занимается. Да, большинство будет писать прикладные проекты. Но если нужен программист в ядро — при чем тут львиная доля?
Программистов, понимающих «логарифм» или «квадратичная» — вполне себе хватает. Будет кому написать.
Другое дело, что подавляющее большинство прикладники.
Да, это все прикладные проекты, активно использующие субд.
Что и требовалось доказать. И вы тоже прикладник.
Я вот к чему: вы слишком серьезно относитесь к вещам, которые нужны только одному из 1000.
Слишком требовательны к подавляющему большинству по части тех знаний, которые им не факт что и пригодятся когда либо.
Я вот к чему: вы слишком серьезно относитесь к вещам, которые нужны только одному из 1000.
Давайте проведем связь многие (программисты) ко многим (незначительным вещам) и окажется, что несерьезно к ним относиться нельзя. А как различить грань между слишком и не слишком?!
UFO just landed and posted this here
UFO just landed and posted this here
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
В субд те же индексы (хеши и двоичные деревья) и hash и merge joins и nested loops — т.е. надо понимать как все работает и сообразить какая o(f(n)) там будет.
сообразить какая o(f(n)) там будет.
План запроса меняется автоматически в зависимости от статистики, то есть на разном объеме данных/разном содержимом может быть по разному.
Низкоуровневые знания, в которых не учтена статистика данных — тут слабый помощник. Ибо все ваши микрооптимизации могут быть в любой момент пересмотрены СУБД.
Гораздо полезнее предоставить СУБД правильные индексы — а дальше она сама разберется.
Ну а как влияют merge joins, nested loops — вы будете прекрасно понимать безо всяких o() на уровне интуиции уже после пары месяцев интенсивного написания/оптимизации запросов.
Примерно столько времени понадобилось одному из джунов (не самому таланливому в программировании), которого я натаскивал. Причем большую часть времени он сам учился. Я только советы общего характера давал типа «разбить запрос на отдельные части и посмотреть». После пары месяцев интенсива от такие стал оптимальные запросы писать — закачаешься.
Вспомните происхождение SQL — изначально он придуман вовсе не для программистов, а для менеджеров, чтобы сами себе отчеты строили, не отвлекая программистов.
План запроса меняется автоматически в зависимости от статистики, то есть на разном объеме данных/разном содержимом может быть по разному.
Совершенно верно. Чтобы спроектировать структуру данных в общем случае надо представлять примерную ожидаемую статистику и как работает оптимизатор
Примерно столько времени понадобилось одному из джунов (не самому таланливому в программировании), которого я натаскивал.
Вопрос, помогло бы ему если бы он уже знал как рассуждать о производительности быстрее и лучше оптимизировать или нет. Мне кажется, в принципе в массах культура формального рассуждения весьма хреноватая и многим было бы полезно научиться не только интуитивно научиться каким-то приемам но и знать почему так и какие ограничения и т.д. И мочь передать это днание другим
Чтобы спроектировать структуру данных в общем случае надо представлять примерную ожидаемую статистику и как работает оптимизатор
По мне так не нужно все это. Алгоритм прост. Для РСУБД будет таким:
Сначала нормализуем.
Потому там где тормозит — денормализуем.
Стадию денормализации — можно сделать сразу, с опытом приходит понимание этого и без пробных запусков в эксплуатацию.
Расставляем индексы для отборов.
Не забываем про кэши за пределами СУБД.
Все оптимизации выполняем по мере необходимости.
Вообще сомневаюсь что знания как работает оптимизатор чем то поможет написать существенно более выдающуюся по производительности структуру БД в сопоставимые сроки, чем предыдущий алгоритм.
Было бы очень интересно послушать от вас цепочку рассуждений. Как именно вы строите базу данных, исходя из понимания работы оптимизатора.
Потом там где тормозит — денормализуем.
Вам надо либо спроектировать нагрузочный тест чтобы получить "там, где тормозит" либо это будет тратить время людей, которые буду жаловаться на тормоза пока это не исправят.
Если у вас быстрый цикл обратной связи, то хорошо. Если у вас БД на атомной подводной лодке на которую можно накатить патч раз в полгода, то плохо.
Было бы очень интересно послушать от вас цепочку рассуждений.
Ничего волшебного. Просто надо либо запоминать свойства индекса либо вывести их из знания его внутренней структуры. Второе не потребует циклов обратной связи. Например если есть запрос выбирающий по полям соединенных таблиц, то отдельное их индексирование ускорит меньше чем индексирование по паре, соответственно деномализация тут может помочь (и так далее).
вы будете прекрасно понимать безо всяких o() на уровне интуиции уже после пары месяцев интенсивного написания/оптимизации запросов.
Так и появляются code-monkey, которые принимают решение интуицией, а не знанием и здравым смыслом.
Так и появляются code-monkey, которые принимают решение интуицией, а не знанием и здравым смыслом.
Вы путаете интуицию и парапсихологию, видимо.
Интуиция — это те же знания, полученные на основании того же предшествующего опыта. Только эти знания уже глубоко укоренились в разуме.
Отличие в том, что для использования знаний явных нам нужно воспроизводить всю цепочку рассуждений, а для интуиции эта цепочка уже не требуется.
В истории с тем велосипедом самое интересное то, что человек потом на обычном ездить разучился.
UFO just landed and posted this here
Причем замечания выглядели следующим образом: мне давали набор входных данных для проверки, я хлопал себя по лбу и лез исправлять код.
А в промышленном программировании вы также поступаете? Выпускаете код, а когда прибегает пользователь с ошибкой из-за неучтённого случая, хлопаете себя по лбу и лезете исправлять код?
UFO just landed and posted this here
А вы тестировли и отлаживали код на собеседовании перед сдачей его интервьюеру? Или «закоммитили» сразу?
UFO just landed and posted this here
Понятно, что компилировать и отлаживать в голове надо.
Но это стоит сделать перед тем, как сообщить о завершении написания кода.
Но это стоит сделать перед тем, как сообщить о завершении написания кода.
UFO just landed and posted this here
Почему же тогда никто их не обнаруживает прогоняя код в голове до коммита?
Почему же никто. Как раз в вашем случае, интервьюер легко смог в голове оттестировать ваш код и указать на проблемы.
Скорее всего это означает то, что ошибки были достаточно очевидны (мы ведь не предполагаем, что интервьюер — суперкомпьютер).
Ну и более того, интервьюер посчитал эти ошибки серьезными. Хотя оценка серьёзности может, конечно, отличаться.
UFO just landed and posted this here
А в промышленном программировании вы также поступаете? Выпускаете код, а когда прибегает пользователь с ошибкой из-за неучтённого случая, хлопаете себя по лбу и лезете исправлять код?
А при чем тут он?
Вы что, сами не видите какого огромное количество сырых продуктов выпускают на рынок? Ко всем им лично он имеет отношение?
Если речь не идет о выпуске миллионными тиражами, когда перепрошить потом дорого…
Если речь не идет о крайне дорогом исходе при одной-единственной ошибке…
То да, как правило, да, программы содержат кучи ошибок.
Заказчику/работодателю важнее снижение дорогущей себестоимости разработки, даже если возрастает риск ошибки.
Нет цели — «сделать безошибочно любой ценой».
У ошибки есть цена, у разработки с дополнительным тщательным тестированием есть цена. Заказчик выбирает между ними.
Более того, даже не всегда в деньгах дело.
Чаще более важный фактор — время разработки.
Как бы все было просто, если бы соискатели действительно могли знать, в чем суть до начала собеседования. Никакой информацией о типе задач, сложности, времени на выполнение, приоритете теории и архитектуры над типовыми задачами или "сути" у соискателя нет до момента собеседования. ( в вакансиях никто ничего не пишет )
Бывает и так, что сходу знаешь решение с идеальным O(N), но не помнишь порядок аргументов в одной из функций, а гуглить нельзя, спросить нельзя, рассказать нельзя — сиди и создавай неловкую паузу.
UFO just landed and posted this here
но не помнишь порядок аргументов в одной из функций, а гуглить нельзя,
В адекватных конторах это обычно не проблема. Я на одном собеседовании просто сказал, что вот не помню порядок аргументов и точное название стандартного метода. Собеседователь сказал, что это вообще неважно, итак на псевдокоде пишем. Никаких проблем не было.
Да, вот просто взять и посчитать, сколько слов содержится в стринге.Просто взять и посчитать, говорите? Я бы не хотел работать с вами, если вы всё делаете «на отвали» — так же, как ставите задачи. Потому что «Иван, завари чай» — это три слова. А «завари иван-чай» — это два слова. Дьявол кроется в деталях.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Зачем такие сложности на собеседовании? Достаточно проговорить, что да — могут быть такие-то подводные камни, и решить первым попавшимся в голову вариантом/вариантами. Важно ведь мышление. Первое, что пришло мне в голову — посчитать по количеству пробелов. Или сделать .Split(' ').Count(). Это 100% не самые идеальные варианты решения, но идеальные в общем-то и не нужны, хотя может в Яндексе иначе думают.
Это подколка на тему того, что кто-то смог бы посчитать любые не_буквы символами-разделителями слов?
Это подколка на тему того, что дефис может быть как частью слова, так и разделителем слов. И без словаря нельзя один случай отличить от другого.
дефис может быть как частью слова, так и разделителем слов
Это где дефис является разделителем?
Когда ставится между определяемым словом и приложением, например.
Это у человека был намек на то, что в типографии существует аж 5 разных символов для одной-единственной черточки (дефис, минус, короткое тире, тире, дефис-минус), у каждого из которых свое назначение. Разделяют через тире, а дефисом переносят. Чушь полнейшая, но так уж исторически сложилось.
В том-то и фокус, что в русском языке часто бывает что два разных слова пишутся через дефис. Именно через дефис, а не через тире.
А можно пример? Потому что обычно эти два «разных» слова считаются после этого одним словом. «Иван-чай», к примеру, одно слово.
Говорю же: когда дефис ставится между определяемым словом и приложением.
Вот прямо из Википедии: ковёр-самолёт, монах-аскет, Волга-матушка, Москва-река, Иван-дурак, Соловей-разбойник, сторож-старик…
Одним словом два разных члена предложения не могут быть никак.
Вот прямо из Википедии: ковёр-самолёт, монах-аскет, Волга-матушка, Москва-река, Иван-дурак, Соловей-разбойник, сторож-старик…
Одним словом два разных члена предложения не могут быть никак.
Да, действительно.
Из собственно грамматических критериев выделения слова известностью в отечественной лингвистике пользуется критерий цельнооформленности А. И. Смирницкого. Согласно этому критерию сочетание морфем признается одним словом, если грамматическое оформление при помощи соответствующей служебной морфемы получает все сочетание в целом, а не каждый из его членов. Например, иван-чай — это одно слово, так как при склонении все сочетание в целом оформляется одной флексией: иван-чая, иван-чаю, а не *ивана-чая, *ивану-чаю.
В противном случае, когда каждый член сочетания получает свое оформление, — это называется раздельнооформленностью — сочетание признается двумя словами. Например, город-герой — это два слова, ср. города-героя, городу-герою и т. д.
В.Б. Касевич «Элементы общей лингвистики»
Добавлю, что в нерусских языках с определением слова всё ещё сложнее. Буквально только что на Language Log обсуждали, что во вьетнамском просто вообще нет определения слова. В других азиатских языках пробелы между словами необязательны, и делить строку на слова можно только по словарю.
Разделяют через тире, а дефисом переносят. Чушь полнейшая, но так уж исторически сложилось.
А почему чушь? Семантически же это разные случаи?
Потому что по сути это просто черточка, разного размера. Я, к примеру, определяю ее значение из контекста, а не вычисляя размер «ага, 3 миллиметра, значит — дефис».
Опять же, хоть кто-то, кроме профессиональных типографов/верстальщиков, набирая текст, пользуется тремя различными символами? Я, к примеру, везде ставлю минус: и как минус, и как тире, и как дефис. Лишняя головная боль только, их порядковые номера в юникоде запоминать.
Опять же, хоть кто-то, кроме профессиональных типографов/верстальщиков, набирая текст, пользуется тремя различными символами? Я, к примеру, везде ставлю минус: и как минус, и как тире, и как дефис. Лишняя головная боль только, их порядковые номера в юникоде запоминать.
А в каких случаях нужно ставить именно m-dash(длинное тире), а в каких n-dash(короткое тире)?
а по факту человек не может написать простую считалку слов
Сло́во — одна из основных структурных единиц языка, которая служит для именования предметов, их качеств и характеристик, их взаимодействий, а также именования мнимых и отвлечённых понятий, создаваемых человеческим воображением.
Что-то мне кажется тут без сильного ИИ и бигдата не обойтись:)
Не все могут под пристальными взглядами нескольких человек написать даже псевдокод.
На собственном опыте убедился, что легко могу войти в ступор, когда резко посреди беседы просят перевернуть биты в int32.
На собственном опыте убедился, что легко могу войти в ступор, когда резко посреди беседы просят перевернуть биты в int32.
Я не сторонник циничного подхода, что, дескать, если отсеяли, что не повезло тебе, чувак. Но всегда приходится исходить из того, что реализуемо на практике. Человек, впавший в глубокий ступор, внешне не отличим от человека, который ничего не знает и не умеет. Я стараюсь всегда смягчать стресс, предлагать альтернативные вопросы, если на каком-то зависли, но, наверное, остается возможность что кто-то может отсеяться несправедливо.
UFO just landed and posted this here
Это замечательно, когда у человека есть бэкграунд, который можно отследить, но если возводить это в правило, то получается, что мы должны отсеивать
а) Тех, у кого нет знакомых среди сотрудников
б) Тех, кто не работал в OpenSource
в) Тех, кто не писал статей
А у нас совершенно нет причин этих людей отсеивать.
а) Тех, у кого нет знакомых среди сотрудников
б) Тех, кто не работал в OpenSource
в) Тех, кто не писал статей
А у нас совершенно нет причин этих людей отсеивать.
UFO just landed and posted this here
Ну вот лично мне кажется, что лучше дать человеку шанс проявить себя, чем делать его заложником его биографии. Но это во многом вопрос вкуса, я понимаю.
Это всего лишь вопрос гибкости интервьюера. А так же желания, мотивации и свободного времени, разумеется.
Просто нужно читать резюме ДО собеседования и, если там указаны ссылки на проекты или статьи, то ознакомиться с ними, чтобы заранее составить первое впечатление о человеке(к вопросу о гибкости — первое впечатление не всегда верно, поэтому надо уметь абстрагироваться от первой оценки, если что-то пошло не так). И затем на собеседовании отклониться от своего дефолтного плана, да может задать пару вопросов из проекта\статьи человека. Это даст куда больший отклик о человеке, чем «возможность проявить себя» в виде задачи, которую нужно написать на листочке. И, вдобавок к лучшему отклику, ещё наиболее приятное впечатление останется у человека о компании, в которой интервьюеры, наконец-то, снизошли и хотя бы поинтересовались бекграундом человека, который был указан в резюме. Даже в случае отказа впечатление с хорошей вероятностью будет лучше.
Однако у этого подхода есть один минус — время.
Помимо времени на собеседование ещё нужно уделить определённое время на чтение и изучение кандидата. Это может занять 5-20 минут в оптимальном случае. А в случае, если из 10 кандидатов 3 оказались с таким «бекграундом», то времени нужно затратить 5-20 минут на КАЖДОГО из них, что в случае большой текучки и кандидатов может оказаться расточительно.
А в случае одной вакансии и тех же 10 кандидатов, как по-мне, можно уделить этому время. Если не на проекты, на изучение которых может уйти достаточно много времени, то хотя бы на чтение статей, которые написал и указал кандидат.
Но… зачем? Зачем тратить своё драгоценное время на каких-то кандидатов, верно? ;)
p.s. посыл не конкретно к OYTIS, а в целом к интервьюерам любого толка. Проводить интервью — это не легкая затея и к этому делу нужно готовиться, а не просто плыть по течению.
Просто нужно читать резюме ДО собеседования и, если там указаны ссылки на проекты или статьи, то ознакомиться с ними, чтобы заранее составить первое впечатление о человеке(к вопросу о гибкости — первое впечатление не всегда верно, поэтому надо уметь абстрагироваться от первой оценки, если что-то пошло не так). И затем на собеседовании отклониться от своего дефолтного плана, да может задать пару вопросов из проекта\статьи человека. Это даст куда больший отклик о человеке, чем «возможность проявить себя» в виде задачи, которую нужно написать на листочке. И, вдобавок к лучшему отклику, ещё наиболее приятное впечатление останется у человека о компании, в которой интервьюеры, наконец-то, снизошли и хотя бы поинтересовались бекграундом человека, который был указан в резюме. Даже в случае отказа впечатление с хорошей вероятностью будет лучше.
Однако у этого подхода есть один минус — время.
Помимо времени на собеседование ещё нужно уделить определённое время на чтение и изучение кандидата. Это может занять 5-20 минут в оптимальном случае. А в случае, если из 10 кандидатов 3 оказались с таким «бекграундом», то времени нужно затратить 5-20 минут на КАЖДОГО из них, что в случае большой текучки и кандидатов может оказаться расточительно.
А в случае одной вакансии и тех же 10 кандидатов, как по-мне, можно уделить этому время. Если не на проекты, на изучение которых может уйти достаточно много времени, то хотя бы на чтение статей, которые написал и указал кандидат.
Но… зачем? Зачем тратить своё драгоценное время на каких-то кандидатов, верно? ;)
p.s. посыл не конкретно к OYTIS, а в целом к интервьюерам любого толка. Проводить интервью — это не легкая затея и к этому делу нужно готовиться, а не просто плыть по течению.
А какие ограничения? память, скорость, кривой ЯП?
1. если в лоб то выделяется буфер и вставляются значения перебором с конца
2. если экономим память, то читаем хвост и голову и меняем их в цикле
3. string.Buffer.Reverse
1. если в лоб то выделяется буфер и вставляются значения перебором с конца
2. если экономим память, то читаем хвост и голову и меняем их в цикле
3. string.Buffer.Reverse
public static string ReverseString( this string input ) {
var temp = new List<string>();
var e = StringInfo.GetTextElementEnumerator( input );
while ( e.MoveNext() )
temp.Insert( 0, e.GetTextElement() );
return string.Concat( temp.ToArray() );
}Ну как, я прошёл испытание?
string.Concat( "Hello World".Reverse() )Оценил разницу, спасибо
Я лично так и решаю, потому что это полностью подходит под определение "Разверните строку". Если добавят ограничения в стиле "UTF8-строку" я просто откажусь делать, потому что я прекрасно представляю, насколько это трудоемко, и у меня нет соответствующей квалификации.
Это не UTF8 — это UTF16 (т.е. внутреннее представление С#). Если этого не учитывать, то код будет некорректно работать на некоторых языках. (см surrogate pairs)
Еще раз, этот код работать корректно будет во всех случаях только в ASCII чарсетах. Ну и возможно будет еще корреткно работать в UTF16 сценариях. Про UTF8 я уже сказал — в шарпе нет нормальных средств работы с ним. В нешарповом коде это легко делается аналогично, ссылку я чуть выше давал.
На шарпе для UTF8 я просто не буду реализовывать- слишком сложно для тестового задания.
На шарпе для UTF8 я просто не буду реализовывать- слишком сложно для тестового задания.
При чем тут вообще разные кодировки. В С# внутри используется UTF16, все строки в ней. Если строка в другой кодировке — это массив байтов, а не строка. Строка UTF16 может содержать суррогатные пары.
Я к тому, что C# строка может содержать UTF-8 символы, но любые попытки работать с ними стандартными средствами (вроде того же reverse) развалят её: https://ideone.com/vRT9OG
Да при чем тут UTF-8? И что такое «UTF-8 символ»?
UTF-8 при том, что это по сути единственная кодировка переменной длины, используемая на практике. Это обстоятельство делает разворачивание строки сильно сложнее, чем в случае с кодировкой символами фиксированной длины.
То, что называется UTF-8 code point.
И что такое «UTF-8 символ»?
То, что называется UTF-8 code point.
Откуда взялся UTF-8 code point в UTF-16 строке?
UTF-8 при том, что это по сути единственная кодировка переменной длины, используемая на практике.
В UTF-16 есть суррогатные пары. Почитайте википедию
Да, но мы имеем доступ по индексу. Взяли i, взяли len — i. Если второй оказался суррогатной парой, взяли еще один перед ним. Гарантий того, что мы не разобьем символ на части достаточно, чтобы развернуть суррогатные пары в том числе.
Сурогатную пару надо поставить на место одного символа, а один символ на место суррогатной пары
Так это не сложно ведь сделать. Основная проблема UTF-8, из-за которой в нем это не поможет, что взяв i-й байт мы не можем ничего сказать ни про него, ни про окружающие символы.
Во-первых, в C# строки состоят не из байт, а из двухбайтовых «символов».
Во-вторых, для любого «символа» можно однозначно определить чем он является — одиночным символом, первым суррогатом пары или вторым.
Во-вторых, для любого «символа» можно однозначно определить чем он является — одиночным символом, первым суррогатом пары или вторым.
Ну ок, тогда задача не такая сложная. Был не прав. Хотя на собеседовании знать диапазоны UTF-8 вряд ли получится вспомнить.
И все-таки, при чем тут UTF-8? Вам уже пять раз сказали, что строки C# не используют эту кодировку.
Потому что литерал C# строки может содержать эти символы. Я уже показывал пример выше.
Литерал C# строки состоит из символов в той кодировке, в которой написан файл исходного кода. Но это не имеет ни малейшего отношения к тому что происходит в рантайме.
Да я понял в чем моя ошибка, спасибо.
В качестве домашнего задания сделал разворот UTF8 строки. Не скажу, что невозможно, но довольно нетривиально, потратил больше часа.
В качестве домашнего задания сделал разворот UTF8 строки. Не скажу, что невозможно, но довольно нетривиально, потратил больше часа.
s[::-1] подойдёт?
Способность к программированию — не субъективно ли это?
А чего тут субъективного? Есть способность писать код — напиши. Не смог — нет способности писать код.
большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами
Про бумажку, вроде, речи не шло, впрочем, я искренне не понимаю в чем проблема написать код на бумажке. В чем?
позволив ему пользоваться Гуглом, он накидает Backend за 15 минут
Да, таких cut-n-paste "дяденек" пол-Индии. Если вам нужны "индусы", то нет проблем — набирайте таких. Очевидно, автору обсуждаемого комментария нужны более другие разработчики.
Я не против заданий, но это не всегда является прямым показателем знаний.
А ни кто и не рассматривает это прямым показателем знаний. Это фильтр. И это ОЧЕНЬ эффективный фильтр.
Не все пишут код линейно от первого до последнего символа. Некоторые вставляют строки выше уже написанного, редактируют уже написанное, потому что на лету приходит решение сделать немного иначе. На бумажке это затруднительно.
Да, ладно, это уже какие-то совсем смешные придирки. Почеркал, переписал заново, написал сбоку, пририсовал стрелочку :). Это же все в непосредственном режиме происходит, собеседователь видет что происходит. Проверяется ведь не чистописание кода, а способность к программированию. В конце-концов, в таких случаях не дают же задачи написать реализацию поискового движка гугла, там что-нибудь простое. Говорят, иногда предлагают за компьютером такое проделать, но я как раз за компьютером бы сильнее растерялся — возможно незнакомая иде, окружение, клавиатура. От волнения пальцы не по тем кнопкам попадают (был такой опыт) — ужос, короче. По мне, так лучше на бумажке. Несмотря на то, что кроме собеседований я код на бумажке 30 лет назад последний раз писал (а потом набивал его на перфокарты!). Вообще, на бумажке на собеседованиях приходилось самое большое 5-7 строчек написать. Чаще код на собеседованиях писал во время скайп/телефонных собеседований в какой-нибудь веб-среде, предоставляемой собеседователем. Что-то вроде гугло-доксов. Там можно и исправлять и строчки вставлять и задачки уже не на 5 строк бывали, а аж на целых 10! :)
Вот прям с языка сняли
UFO just landed and posted this here
Есть навыки решать конкретные задачи в конкретной области, а есть общая база и умение находить подходы к решению задач. В зависимости от проекта могут быть нужны разные люди.
Проблема собеседующих в том, что нередко они хотят найти человека сильно круче, чем им реально надо.
Проблема собеседуемых в том, что они почему-то думают, что если они научились решать конкретные задачи в конкретной области, то они программисты in general и все должны их хотеть.
Проблема собеседующих в том, что нередко они хотят найти человека сильно круче, чем им реально надо.
Проблема собеседуемых в том, что они почему-то думают, что если они научились решать конкретные задачи в конкретной области, то они программисты in general и все должны их хотеть.
UFO just landed and posted this here
UFO just landed and posted this here
Как он это сделал? Есть unicode символы такие? Oo
Это символы, похожие на перевернутые русские буквы, надерганные из разных наборов unicode.
Есть онлайн и не-онлайн генераторы, которые переворачивают атоматически
ʚ — например этот символ latin small letter closed open e (U+029A)
ʎ — очевидно, лямбда
итп
Есть онлайн и не-онлайн генераторы, которые переворачивают атоматически
ʚ — например этот символ latin small letter closed open e (U+029A)
ʎ — очевидно, лямбда
итп
разрешите докопаться, лямбда пишется в другую сторону — вот так λ. А вот эта ʎ в юникоде описывается как Latin Small Letter Turned Y. Что наводит на мысли, что можно не надёргивать буквы из разных алфавитов, а использовать имеющиеся в юникоде готовые перевёрнутые символы (ну, очевидно это для латиницы, некоторые кириллические символы таки придётся поискать).
Ребята, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не а̦̮̭͖́р̬̰̞х̹͇̲͎͡и̥̪̟̳в̪̕ы͜ ̲̲ спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я̢͓͙ ͙̺͔͖͉̫̻в̗̼̪͖̖̟͖п̢̲̖͎̣̤̹͇о͏л̣̠ͅн̜е͙̙̹̘̘ ̹̤̳͔ͅп̛̹̲͕̟̪̘̝о̭̟̙͚͇н̷̮̲̝̱̫и̤м̥̱̩͓̮̭̹а̙̪̰̞̻̰ͅю,̘͘ ͚̱̘̙̯̀ч̥͙͇͎т̹̹о̢̺̫̜͔̥͍͉ ̢̮̬д҉̟͍̪а̝н̡н͔͇ым͞ ͚с͏̰̣оо̳̪̲͔̰̲̕б̬̦̗̼̱͓̣щ͔е̧̲̗͈̫н̱̻̙́и̭͚ем̛̰ ̳̩в͖͍͕̥͎̻ы͉̣̖͕з̯̝͚̹о̲͎̭̥̯͔в̛̘у̝̟͙̹̲͡ ̙̤д̩̪̻̦о͉̞̫п̣͚͙͎͔͉͡о̸͚̥л̣͎̝͕н̟͖̖̯̘и̲̫̤т͎̥̣͎͕͇͙ел̕ь̱͚͕̯̭̤н̖̩̯̩̘̘̘ы̞̯̟̥͉͈̯͝й͍ͅ ̢̬̝и͍̙͕̮н҉̱̼̫̣͖̖̤т̯̙̻̗̙̹е̷̯͎р̢̺̯̠̻ͅе̸͍͔̼͈̯с̻̟͕̹̰̗͍,̜̪ ̺̲̙͈̘͘н̻о̡͓ ̛х̼̻̭͓о̸͍̞̝̞̹ч̀у̘͍̭͙̯͕̤͘ ̬͈͈̰̘͜ͅс͈̺р̞͍а̟̤͕̜̤з͇̼ͅу̷͎ ҉͖̻̭̟п͓̝̗̥̘͘р̷̻̰̖е҉͎д̝̮̯̠̩̘̠о̞͔͙͘с͢т̡͓̬ͅе͈̖̮͔̘̞̼͢р̘͚̲е͎͙̹̼͍͟ч̟͎ͅь̭̮̤̩͎͢ ̪͉͍͈͚п̱̯̣̦̱̳ы͡т̗̮̞̩̹͘ли̻̖̻͝в̬͍̳̦͕͢ы̭̪̺х͍͇̱̥̖̫̕ͅ ̳̺̺̻ͅ-͈̙̭̗̲ ͔̕с̡̗̝̤ͅт̹͕̺͞ͅо̡̻̼̭͍̘͚͎п̮͕̟͞.͓̲̬̜͢ ̡̖О҉̘͔̫ст̝͖͔̗̘͕͇а̭͓̯͙͎͢ͅл̯̞̳̖͍͚̩̀ь̱̕н̜̭͚ͅͅы̱̠̙̲е̬̫͙͙̣̹̕ ͚̱̜п̫р̰̝̖̪̣о̛̱̪̜̝̥̝с̵̦̖т̧͍͍̩̫ͅо͉̫̠̱ ̨̹̤н̺͈̹̭̹̤̟̀е҉̼͍̦̻ ̯̥͖̗̹н̮͈̭͚̟а̗͎̫̟й̜̣͓͡ͅд͉̭̯̘͍͙͟у̣̙͇̺͞ͅт̙̬̜̦͕͉.̰̙ О̫͓̺̹̘͉̰͑ͯͯ̒͘͘н̸̯͕̤͕̳͎̯̹͍̘̗͇͎͎̯͎̯̂́ͮͤ͆͝͠и̵̛͕̜̗̰̰ͧ̂̈ͬ̐̾̍͌ͥ̽ͨͥͨ̓ͯ̀̿͡ ̧ͦ͂̅͋̊̃ͮ̋ͧͫͩͭ͋̑͌̋̚̚͟͝҉̬̦͚̯̻и́̈́͆̏̆͌͌̇̀ͮͧͩ̆ͫ̈̐͏̛̙̦̮̳̯̯̭̹̭̭͎̩͎͇̰̪̖͘͜͠ͅͅд͉̪̘̳͙̺͉̱͗̍̈́̎̄͢͠у̴̛̣̟͎̞͎̰̩ͫͫͨ̒̀̃̚т̛̯̰͍̲͓̤̣͍͔͇̗̈́̆ͬ̊͋ͨ̐̔̈́͛̋͌͋̾̀̕͝͡!̷̧͚̬͖̜̟ͦ͂͆͐̽̆̽̄͆̑̔͒̏͐̊̈́̓̃ ̶̴̡́̋̓̾̀̆̇̊̑̀̎́͏̦̭͔̯̱͎̮̹Z̧ͯ̓̌̀̔̿̄̐̔̐̆ͬ͂̓ͫ̃ͤ͏̶̨͖̭̥̭͚̱͖̖͖͚̯͍̤̳͉̮͍ͅĄ̷͍̬͍̱̗̤ͤ̾̓̂̍̿͒͋̓ͮ̒͗͂͂ͥͪ̓̍ͯ͘Ḻ̵̸̤̺̳̞̺̹̣̮̦̥͉͔͖ͤͧͫ͒͐̌̈́ͩ͌́ͧ͐̑̃̌͝ͅG͉̙̻̯̿͌̃̿͒̐̓͢͡͝͠ͅO̶̫̪̳̼̬͇̙̪͚ͤ͊ͪ̔ͪ͝͞!̶̱̼̗̥̼̗͎̹͔̬̥̙͎̇̐̒̅̒̉͑̇̏́͟͜
о, круто. теперь реально можно «ср*ть в комментах» :-D
д͉̭̯̘͍͙͟у̣̙͇̺͞ͅт̙̬̜̦͕͉.̰̙ О̫͓̺̹̘͉̰͑ͯͯ̒͘͘н̸̯͕̤͕̳͎̯̹͍̘̗͇͎͎̯͎̯̂́ͮͤ͆͝͠и̵̛͕̜̗̰̰ͧ̂̈ͬ̐̾̍͌ͥ̽ͨͥͨ̓ͯ̀̿͡ ̧ͦ͂̅͋̊̃ͮ̋ͧͫͩͭ͋̑͌̋̚̚͟͝҉̬̦͚̯̻и́̈́͆̏̆͌͌̇̀ͮͧͩ̆ͫ̈̐͏̛̙̦̮̳̯̯̭̹̭̭͎̩͎͇̰̪̖͘͜͠ͅͅд͉̪̘̳͙̺͉̱͗̍̈́̎̄͢͠у̴̛̣̟͎̞͎̰̩ͫͫͨ̒̀̃̚т̛̯̰͍̲͓̤̣͍͔͇̗̈́̆ͬ̊͋ͨ̐̔̈́͛̋͌͋̾̀̕͝͡!̷̧͚̬͖̜̟ͦ͂͆͐̽̆̽̄͆̑̔͒̏͐̊̈́̓̃ ̶̴̡́̋̓̾̀̆̇̊̑̀̎́͏̦̭͔̯̱͎̮̹Z̧ͯ̓̌̀̔̿̄̐̔̐̆ͬ͂̓ͫ̃ͤ͏̶̨͖̭̥̭͚̱͖̖͖͚̯͍̤̳͉̮͍ͅĄ̷͍̬͍̱̗̤ͤ̾̓̂̍̿͒͋̓ͮ̒͗͂͂ͥͪ̓̍ͯ͘Ḻ̵̸̤̺̳̞̺̹̣̮̦̥͉͔͖ͤͧͫ͒͐̌̈́ͩ͌́ͧ͐̑̃̌͝ͅG͉̙̻̯̿͌̃̿͒̐̓͢͡͝͠ͅO̶̫̪̳̼̬͇̙̪͚ͤ͊ͪ̔ͪ͝͞!̶̱̼̗̥̼̗͎̹͔̬̥̙͎̇̐̒̅̒̉͑̇̏́͟͜
о, норм так… щас поисследуем…
выглядит вот так без «хитрой кодировки»:
д??????? у?????? т??????.?? О????????????? н????????????????????????? и????????????????????????? ??????????????????????????? и???????????????????????????????????????? д??????????????? у???????????????? т??????????????????????????????!????????????????????????? ????????????????????????Z???????????????????????????????????????A????????????????????????????L?????????????????????????????????G????????????????O?????????????????!??????????????????????????
о, норм так… щас поисследуем…
выглядит вот так без «хитрой кодировки»:
д??????? у?????? т??????.?? О????????????? н????????????????????????? и????????????????????????? ??????????????????????????? и???????????????????????????????????????? д??????????????? у???????????????? т??????????????????????????????!????????????????????????? ????????????????????????Z???????????????????????????????????????A????????????????????????????L?????????????????????????????????G????????????????O?????????????????!??????????????????????????
zalgo text generator
Если программист сильный, то он может это сделать путем переворачивания собеседующего :)
меня сейчас закидают камнями, я более 10 лет занимаюсь программированием, и вот только сейчас загуглил как это делается в js
но я почему то уверен что подобная функция возможно есть в других языках, да я понимаю что можно запустить цикл, что собственно тут и есть
так я к чему, не все и не всегда должны знать(помнить) бональные решения ибо такие решения очень редко используются в продакшине
str.split('').reverse().join('')но я почему то уверен что подобная функция возможно есть в других языках, да я понимаю что можно запустить цикл, что собственно тут и есть
так я к чему, не все и не всегда должны знать(помнить) бональные решения ибо такие решения очень редко используются в продакшине
на очном собеседовании демонстрировали полную неспособность к программированию.
Если «скосить глаза», то можно разглядеть в этом зайчатки TDD-подхода (=
В "Pragmatic Programmer" для этого есть прекрасный термин – Programming by coincidence.
UFO just landed and posted this here
Угу, а потом в продакшне приходит ситуация, на которую не было написано теста (случается сплошь и рядом — Вы не представляете, КАКИЕ входные данные умудряются подсовывать!) — и Ваша «программа» падает со словами «ой, всё!».
Как говорится, «в противостоянии искусственного интеллекта и естественного идиота побеждает последний».
Как говорится, «в противостоянии искусственного интеллекта и естественного идиота побеждает последний».
На самом деле интересная идея для реализации AI, пишущего программы. А если еще и через тесты прогонять…
Пока курил придумал решение за константное время О(1) и без доп памяти(ну почти).
Если реализовать строку как двусвязный список котором есть указатель на первый, последний элемент и булево значение для определение направления реверса.
А в узле списка храним значение(тут можно уточнить кодировку и т.д.) и указатели a,b на соседние елементы.
Правда если алгоритм используется один раз то нет выигрыша, т.к. нужно перевести строку из «стандартной» реализации в «новую» структуру данных. Но если такая задача встречается много раз для каждой строки (и строки большие), то сэкономил вам кучу денег на серверном времени))
Если реализовать строку как двусвязный список котором есть указатель на первый, последний элемент и булево значение для определение направления реверса.
А в узле списка храним значение(тут можно уточнить кодировку и т.д.) и указатели a,b на соседние елементы.
Правда если алгоритм используется один раз то нет выигрыша, т.к. нужно перевести строку из «стандартной» реализации в «новую» структуру данных. Но если такая задача встречается много раз для каждой строки (и строки большие), то сэкономил вам кучу денег на серверном времени))
Если сеньора собеседуют так-же, как джуна, делать в такой конторе нечего. Им джун нужен, его и возьмут.А как должность называться будет — вторично.
Если вы только начали свой путь в собеседованиях, то вам предстоит еще много открытий. Как правило, первое общение происходит с HR, у которых все вопросы записаны на бумажке. Это первый фильтр вашего резюме. Общаться с ними на профессиональные темы бесполезно, нужно просто правильно ответить. По этому, допустим для JS, нужно как стихи знать определения: Функциональное программирование, Rest API, замыкание, наследование.
Вопросы от HR-а по списку, хороший фильтр в пользу кандидата. Если учесть что вопросы HR-у составляют программисты компании, то после очередного услышанного вопроса, можно сразу прощаться с HR-ом и передать привет несостоявшимся коллегам.
Помню однажды, я услышал такой вопрос «из списка»:
я чисто из вежливости конечно решил уточнить версию PHP например, версию Python или реализацию, в общем что-то, что могло бы мне дать повод не считать этот вопрос совершенно дурацким, мягко говоря.
Но вышло так, что HR с гордостью мне сообщил, что у нее без всяких там моих уточнений, её коллеги программисты написали совершенно однозначный ответ — Python.
Мне как бы было все равно совершенно, даже хотелось потроллить, но от дальнейшего технического интервью я сразу отказался.
Таким образом один вопрос из списка, сэкономил кучу времени мне, им, и очевидно для меня, рассказал мне об этой компании, и потенциальных коллегах, у которых видимо глубокий внутренний диссонанс.
Помню однажды, я услышал такой вопрос «из списка»:
что быстрее Python или PHP
я чисто из вежливости конечно решил уточнить версию PHP например, версию Python или реализацию, в общем что-то, что могло бы мне дать повод не считать этот вопрос совершенно дурацким, мягко говоря.
Но вышло так, что HR с гордостью мне сообщил, что у нее без всяких там моих уточнений, её коллеги программисты написали совершенно однозначный ответ — Python.
Мне как бы было все равно совершенно, даже хотелось потроллить, но от дальнейшего технического интервью я сразу отказался.
Таким образом один вопрос из списка, сэкономил кучу времени мне, им, и очевидно для меня, рассказал мне об этой компании, и потенциальных коллегах, у которых видимо глубокий внутренний диссонанс.
Навсегда запомнил собеседование от HR (!!!) отдела в команду разработки по Skype.
— Расскажите мне о контракте между hashCode() и equals().
— (Начинаю рассказывать чего, да как).
— Нет, вы не поняли. Расскажите как это написано в JLS.
— То что вам рассказываю это разве не то?
— Нет. В JLS описано не так.
(проехали пару вопросов)
— Расскажите про уровни изолированности в JDBC.
— (Рассказываю, провожу аналогии с MS SQL и ORACLE).
— Я что-то вас не поняла. Вы там что, гуглите?
Меня после этого просто дико бомбануло. Компания не без имени, знакомые лестно отзываются о ней, но на собеседованиях выкидывают такие вот номера — вопросы по бумажке. После этого все желание продолжать диалог просто пропало.
Проблема автора на самом деле актуальная — изначально задоминировать респондента, чтобы доказать его никчёмность. Однако, после этого они еще кидают офферы, тем самым, произведя оценку твоих знаний, выставляют ценник. Прекрасно понимаю автора, что по морали такое сильно бьет, но ты держись. Не все компании такие вокруг. Остынь и снова можно попробовать.
— Расскажите мне о контракте между hashCode() и equals().
— (Начинаю рассказывать чего, да как).
— Нет, вы не поняли. Расскажите как это написано в JLS.
— То что вам рассказываю это разве не то?
— Нет. В JLS описано не так.
(проехали пару вопросов)
— Расскажите про уровни изолированности в JDBC.
— (Рассказываю, провожу аналогии с MS SQL и ORACLE).
— Я что-то вас не поняла. Вы там что, гуглите?
Меня после этого просто дико бомбануло. Компания не без имени, знакомые лестно отзываются о ней, но на собеседованиях выкидывают такие вот номера — вопросы по бумажке. После этого все желание продолжать диалог просто пропало.
Проблема автора на самом деле актуальная — изначально задоминировать респондента, чтобы доказать его никчёмность. Однако, после этого они еще кидают офферы, тем самым, произведя оценку твоих знаний, выставляют ценник. Прекрасно понимаю автора, что по морали такое сильно бьет, но ты держись. Не все компании такие вокруг. Остынь и снова можно попробовать.
По поводу «задоминировать респондента» — есть хорошая статья на известном всем сайте) Часто встречаю уловки, описанные в ней )
«Да, гуглю. Кстати, если ваши вопросы гуглятся в течении 10 секунд, не пойти ли вам нахрен с такими вопросами?»
Я что-то вас не поняла. Вы там что, гуглите?
ААААА! Меня аж встряхнуло от этих строк — когда на собеседовании по скайпу накидывал по Liskov Principe (soLid) и мне сказали «Вы там читаете в Гугле?» и даже речь заплетаться стала у меня :)
Ещё со времён технаря я не запоминаю конструкции языка программирования, мне это совсем не нужно. Я просто пишу на естественном языке всю логику, а потом могу её реализовать на любом языке программирования просто гугля нужные мне конструкции выбранного языка.
Мой друг хорошо помнил практически все операнды и функции того же C++, но при этом у него было всё печально с логикой.
Вопрос такой: кто из нас двоих лучше как разработчик?
Да, в те далёкие времена мы с другом писали то, что не могли написать больше никто из нашей группы.
Я и сейчас не факт что без ошибок с первого раза напишу простейший цикл, но это и не нужно, я ведь знаю, что мне нужно написать, а как это написать знают поисковые системы.
Мой друг хорошо помнил практически все операнды и функции того же C++, но при этом у него было всё печально с логикой.
Вопрос такой: кто из нас двоих лучше как разработчик?
Да, в те далёкие времена мы с другом писали то, что не могли написать больше никто из нашей группы.
Я и сейчас не факт что без ошибок с первого раза напишу простейший цикл, но это и не нужно, я ведь знаю, что мне нужно написать, а как это написать знают поисковые системы.
ответ: ни тот, ни другой
Тут еще одна актуальная проблема: «я знаю логику и напишу на любом языке, но изучаю их поверхностно» или «я очень сильный спец в своем языке, но всё что вокруг для меня темный лес».
Спорный момент кто из вас лучше. Для одного работодателя, как писал выше автор, твой друг бы был идеальным кандидатом. Для другого работодателя, который тестирует логическими задачами аля «Есть 2 яйца, на каком этаже разобьется» и умение справиться с поставленной задачей быстро, ты бы показал себя с более сильной стороны. Но итог один — каждый специалист (если он действительно специалист) найдет своё место под солнцем.
Какого мнения придерживаюсь я?
Гугл — это инструмент, которое может тебе дать неправильное решение. Почему? А потому что ты загуглил проблему, открыл первую же ссылку на StackOverflow и скопировал решение. Добавило ли это тебе экспертизы? Нет, а это плохо. Надо стараться разбирать те типовые проблемы, с которыми ты сталкиваешься и хотя бы поверхностно изучать внутренности языка, чтобы совсем уж лохом не казаться, когда будешь собеседоваться.
Спорный момент кто из вас лучше. Для одного работодателя, как писал выше автор, твой друг бы был идеальным кандидатом. Для другого работодателя, который тестирует логическими задачами аля «Есть 2 яйца, на каком этаже разобьется» и умение справиться с поставленной задачей быстро, ты бы показал себя с более сильной стороны. Но итог один — каждый специалист (если он действительно специалист) найдет своё место под солнцем.
Какого мнения придерживаюсь я?
Гугл — это инструмент, которое может тебе дать неправильное решение. Почему? А потому что ты загуглил проблему, открыл первую же ссылку на StackOverflow и скопировал решение. Добавило ли это тебе экспертизы? Нет, а это плохо. Надо стараться разбирать те типовые проблемы, с которыми ты сталкиваешься и хотя бы поверхностно изучать внутренности языка, чтобы совсем уж лохом не казаться, когда будешь собеседоваться.
Я тоже вообще не знаю конструкции даже того языка на котором у меня 90% всего за 20 лет написано. И по этому я вообще в принципе не могу пройти тех собеседование где плювать хотели на мои проекты (как единственное доказательство того что я умею), а им важнее знать что означает «const volatile переменная», а потом метод, а потом ещё чего позаковыристее.
Если компания «зазвездилась» до топов это доходит до маразма: начало 2015 года, одной сами знаете какой компании надо сделать тензорный процессор не хуже гугла для поиска по картинкам, ищут FPGA разработчика-схемотехника, меня забраковали потому что я знаю только C++11 а вот C++14 уже нет т.к. не смог ответить на их «очень простой технический вопрос». Естественно по самой простой конструкции уровня сложности не сеньёра а code-monkey. Кое как до них с городского дозвонился, в итоге сказали:«Вы вообще не разработчик, пожалуйста не звоните, ваш мобильный внесён в блек лист». Естественно каких либо верилогов и языков описания таймингов они в требования не внесли и не проверяли на тех собеседовании.
Приезжаешь в другую страну и встречаешь такие же портянки технологий, но появляется одна «мелочь» которая гласит «любое из» （いずれの）. И работа находится сразу же, и проекты поинтереснее, и никто не ожидает что один человек за пол года тензорный процессор на десятки петафлопов свояет, и зарплата (в пересчёте на местные расходы) повыше «зазвездившихся» даже в предприятиях типа «болото». И даже есть и время и оплаченная возможность отдохнуть и погонять на ардуинке нейросети в реалтайме.
Если компания «зазвездилась» до топов это доходит до маразма: начало 2015 года, одной сами знаете какой компании надо сделать тензорный процессор не хуже гугла для поиска по картинкам, ищут FPGA разработчика-схемотехника, меня забраковали потому что я знаю только C++11 а вот C++14 уже нет т.к. не смог ответить на их «очень простой технический вопрос». Естественно по самой простой конструкции уровня сложности не сеньёра а code-monkey. Кое как до них с городского дозвонился, в итоге сказали:«Вы вообще не разработчик, пожалуйста не звоните, ваш мобильный внесён в блек лист». Естественно каких либо верилогов и языков описания таймингов они в требования не внесли и не проверяли на тех собеседовании.
Приезжаешь в другую страну и встречаешь такие же портянки технологий, но появляется одна «мелочь» которая гласит «любое из» （いずれの）. И работа находится сразу же, и проекты поинтереснее, и никто не ожидает что один человек за пол года тензорный процессор на десятки петафлопов свояет, и зарплата (в пересчёте на местные расходы) повыше «зазвездившихся» даже в предприятиях типа «болото». И даже есть и время и оплаченная возможность отдохнуть и погонять на ардуинке нейросети в реалтайме.
UFO just landed and posted this here
Яндекс,
им очень не понравилось то что я не очень хорошо питон знаю, а то что я не смог ответить по новому ключевому слову из С++14 вообще просто повесили трубку без объяснения причин, вот и начал вызванивать «что это было? и почему тех собеседование и 5 минут не продлилось?».
им очень не понравилось то что я не очень хорошо питон знаю, а то что я не смог ответить по новому ключевому слову из С++14 вообще просто повесили трубку без объяснения причин, вот и начал вызванивать «что это было? и почему тех собеседование и 5 минут не продлилось?».
и почему тех собеседование и 5 минут не продлилось?
Может, им за час нужно было с десятью поговорить. Они применили формальный фильтр. Интересно, что у них есть «чёрный список». :)
Серьёзно, повесили трубку во время собеседования?
В C++14 новых ключевых слов не появлялось. en.cppreference.com/w/cpp/keyword
Может, вы не поняли, о чем вас вообще спрашивали, и проблема в этом?
Может, вы не поняли, о чем вас вообще спрашивали, и проблема в этом?
Предполагаю, у компаний с известным именем немыслимое число соискателей. И такие компании придумывают формальные, и порой нелепые, признаки для отсеивания.
Вы бы купили недвижимость за 5 минут только потому что предложений ещё больше чем соискателей? За которую платить кредит годами и в которой жить всей семьёй? Ладно если денег навалом но она может обрушится или сосед наркоман пырнуть. Поэтому и считаю что экономия времени это очень плохой фильтр, я бы сказал наихудший фильтр отсева.
UFO just landed and posted this here
вот в перегибах и есть все проблемы: я не отрицаю самозванцев и что их много, но и не отрицаю что недойдя до квартиры и даже дома вступают в лужу, или просто на глаза попадается синяя реклама а не жёлтая скажем, разворачиваются и уходят к следующему адресу. Поэтому я не могу утверждать что закидонов соискателей больше чем у работодателей.
Да и нежелание хоть как то фильтровать самозванцев это разве не есть достаточное доказательство проф непригодности соответствующих специалистов?
Да и нежелание хоть как то фильтровать самозванцев это разве не есть достаточное доказательство проф непригодности соответствующих специалистов?
> фильтр блума
Спасибо тебе хабравчанин. Давно читал статью про распределенные БД и там было описание функции повзоляющей быстро определить относится ли число к множеству. Я не запомнил название, но теперь то я ее добавлю во вкладки.
Спасибо тебе хабравчанин. Давно читал статью про распределенные БД и там было описание функции повзоляющей быстро определить относится ли число к множеству. Я не запомнил название, но теперь то я ее добавлю во вкладки.
Если использовать вашу аналогию, то представьте, что вы ищете элитную квартиру, и две трети предложений которые вам пытатся продать по цене элитного жилья — это малосемейки в разваливающихся бараках. Поэтому если вы заходите в обшарпанную прихожую в которой десятилетиями не было ремонта, дальше смотреть не имеет смысла.
Ну, если продолжать эту аналогию полностью, то тут проблема возникает, когда не смотрят реальную прихожую (реальную работу), а спрашивают по телефону, куда там вешается одежда. И если продавец назвал ключевое слово «вешалка-плечики», значит считается, что квартира, возможно, элитная (туда приходят люди в тяжёлых шубах). А если не назвал, то «мы вам перезвоним».
То есть, как бы, корреляция-то есть, но не совсем работающая.
:) очень понравилось слово «свОяет» (вместо свАяет) — возьму на вААружение — буду спрашивать коллег — а вот как же ты, боевой товарищ, вот такое вот свОял?
Не, ну про «const volatile переменная» — это нормальный вопрос, если там системного программиста или эмбедщика искали. Сразу раскрывает опыт (либо горизонт фантазии) соискателя.
А давайте обсудим.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
Или, как вариант, это может быть extern const volatile-переменная. Писать в нее можно, но не в этом модуле.
А volatile ей тогда зачем? В голову приходит только какой-то глобальный объект в многопоточной программе, который можно читать из разных мест, а писать только в одном (либо только хитрым способом). Borrow checker для бедных.
volatile не даст компилятору заоптимизировать эту переменную (например, положив её в регистр). borrow checker тут ни при чем.
У вас переменная уже extern const, оптимизировать ее компилятор уже не будет, потому что она в другом translation unit, и положить ее в регистр если и получится, то только при LTO.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
У вас переменная уже extern const, оптимизировать ее компилятор уже не будет, потому что она в другом translation unit, и положить ее в регистр если и получится, то только при LTO.
Имеет полное право хранить её в регистре между вызовами внешних функций, т.е. записывать в память не все её изменения, а только последнее перед вызовом.
С volatile — обязан записывать в память каждое изменение.
Только не записывать, а читать, потому что записывать мешает const.
Я не про то, что не знаю, зачем оно так, а про то, для чего может понадобится именно extern const volatile, а обычного extern const не хватит, и ничего кроме многопоточной программы и регистров в голову не приходит. В одном потоке переменная (обычная, не отображенная на регистр) из другого юнита меняться не может, т.к. это нарушает инварианты.
Я не про то, что не знаю, зачем оно так, а про то, для чего может понадобится именно extern const volatile, а обычного extern const не хватит, и ничего кроме многопоточной программы и регистров в голову не приходит. В одном потоке переменная (обычная, не отображенная на регистр) из другого юнита меняться не может, т.к. это нарушает инварианты.
Дык выше вы сами написали зачем: «Подойдет указателям на RO-регистры, доступные через MMIO.»
Я про вот этот случай конкретно:
Если программа однопоточная — volatile не нужен, только портит оптимизатору жизнь. Если многопоточная — его недостаточно, от гонок по данным так и не избавились.
Т.е. если там заведомо не регистры, то зачем?
Или, как вариант, это может быть extern const volatile-переменная. Писать в нее можно, но не в этом модуле.
Если программа однопоточная — volatile не нужен, только портит оптимизатору жизнь. Если многопоточная — его недостаточно, от гонок по данным так и не избавились.
Т.е. если там заведомо не регистры, то зачем?
Если не секрет, в какую страну переехали?)
UFO just landed and posted this here
Да вот тоже периодически мучаюсь вопросом — где золотая середина между бессмысленной детализацией сверхмелких знаний и ватной высокоуровневой абстракцией «не грузите меня мелочевкой»…
Про железо: по молодости был у меня товарищ, который наизусть знал все параметры разных BIOS'ов, чипсетов, сигналы IDE и скорости вентиляторов видюх — что, по его мнению, предполагало очевидную предсказуемость успеха сборки компов на заказ… однако после третьего сожженного (частично) комплекта недешевых компонентов как-то стал обращаться ко мне, после 3-4 успешно собранных системников что-то заскучал и бросил это дело;
Про разработку софта: в конце 80-х трое коллег подрядились за разработку узкоспециализированной статистической программки, все трое по книжкам на память знали весь синтаксис PL-1 (в 2-3 диалектах, с различиями в запятых и слэшах), пописывали программки по 10-40 строк — само собой, при доступе к ЕС- (или СМ?) ЭВМ с печатающим устройством, возможностями разделения задач и т.п. выбрали этот инструмент. Меня и ближайшего начальника странноватый энтузиазм слегка насторожил и я начал в остающееся от основных задач время писать на одном из вариантов BASIC на Спектруме, само собой, ни этот ни какой-либо другой диалект я особо и не знал — справочник лежит под рукой и достаточно. Через пару недель «устойчивая» BASIC-версия была готова что было весьма кстати, т.к. «конкуренты» застряли на простом расчете коэффициента корреляции (формирование массивов, извлечение очередных элементов, собственно расчет). Оправдание перед более высоким начальством — PL-1 не позволяет реализовать такие сложные расчеты…
Про собеседование: попросили меня помочь оценить квалификацию специалистов на вакансию, куда могли подойти в том числе и специалисты техподдержки ИТ-инфраструктуры (если уж не совсем интроверты). Из таковых пришло человек 8. 4 — бойкая (что не плохо) молодЕжь вот такого типа www.anekdot.ru/an/an0710/o071025.html#10 (СПЕЦИАЛИСТ ПО ХАБАМ И СВИЧАМ), но особо запомнился титулованный товарищ среднего возраста, который работал в техподдержке 3-го уровня в российском представительстве крупного вендора. 1-ый уровень — это обученные специалисты заказчиков (типа решают проблемы стандартные), 2-ой уровень — сертифицированные специалисты партнеров, ну а 3-й уровень — это уже просто «зубры». Чтобы разговорить товарища и понять чем занимается, 10 минут я упрашивал его рассказать о примерах инцидентов с которым он работает (и документирует решения), потом 20 минут с отчаяния начал набрасывать примеры — оборудование вышло из строя на аппаратном уровне...., неправильная обработка протоколов маршрутизации, падение производительности — ответы — нет, это все не к нам… а что же к вам? нет ответа, нет вообще. так и разошлись.
Про железо: по молодости был у меня товарищ, который наизусть знал все параметры разных BIOS'ов, чипсетов, сигналы IDE и скорости вентиляторов видюх — что, по его мнению, предполагало очевидную предсказуемость успеха сборки компов на заказ… однако после третьего сожженного (частично) комплекта недешевых компонентов как-то стал обращаться ко мне, после 3-4 успешно собранных системников что-то заскучал и бросил это дело;
Про разработку софта: в конце 80-х трое коллег подрядились за разработку узкоспециализированной статистической программки, все трое по книжкам на память знали весь синтаксис PL-1 (в 2-3 диалектах, с различиями в запятых и слэшах), пописывали программки по 10-40 строк — само собой, при доступе к ЕС- (или СМ?) ЭВМ с печатающим устройством, возможностями разделения задач и т.п. выбрали этот инструмент. Меня и ближайшего начальника странноватый энтузиазм слегка насторожил и я начал в остающееся от основных задач время писать на одном из вариантов BASIC на Спектруме, само собой, ни этот ни какой-либо другой диалект я особо и не знал — справочник лежит под рукой и достаточно. Через пару недель «устойчивая» BASIC-версия была готова что было весьма кстати, т.к. «конкуренты» застряли на простом расчете коэффициента корреляции (формирование массивов, извлечение очередных элементов, собственно расчет). Оправдание перед более высоким начальством — PL-1 не позволяет реализовать такие сложные расчеты…
Про собеседование: попросили меня помочь оценить квалификацию специалистов на вакансию, куда могли подойти в том числе и специалисты техподдержки ИТ-инфраструктуры (если уж не совсем интроверты). Из таковых пришло человек 8. 4 — бойкая (что не плохо) молодЕжь вот такого типа www.anekdot.ru/an/an0710/o071025.html#10 (СПЕЦИАЛИСТ ПО ХАБАМ И СВИЧАМ), но особо запомнился титулованный товарищ среднего возраста, который работал в техподдержке 3-го уровня в российском представительстве крупного вендора. 1-ый уровень — это обученные специалисты заказчиков (типа решают проблемы стандартные), 2-ой уровень — сертифицированные специалисты партнеров, ну а 3-й уровень — это уже просто «зубры». Чтобы разговорить товарища и понять чем занимается, 10 минут я упрашивал его рассказать о примерах инцидентов с которым он работает (и документирует решения), потом 20 минут с отчаяния начал набрасывать примеры — оборудование вышло из строя на аппаратном уровне...., неправильная обработка протоколов маршрутизации, падение производительности — ответы — нет, это все не к нам… а что же к вам? нет ответа, нет вообще. так и разошлись.
Не получилось придумать достойную этого мегазубра сложную задачу? :0))
А мне кажется что вы не совсем верно понимаете разделение на уровни поддержки.
Первый уровень — оперативная поддержка. Это обеспечение бесперебойной работы систем и решение проблем только по инструкции. Есть инструкция как решить проблему, значит она решается. Если инструкции нет, то передается дальше. Как правило, первый уровень реализует поддержку по принципу 365/7/24.
Второй уровень решает несложные нетривиальные проблемы, не требующие серьезного анализа и разработки. Например на этом уровне может сделаться несложный data fix или может быть сделан какой-то быстрый workaround. Здесь уже как правило не идет речь о поддержке 365/7/24. Как только стукает 18 или 19 часов все разбегаются по домам. Но если задача важная, то могут и решать сверхурочно.
А вот третий уровень, это непосредственно разработка и решение проблем, требующих серьезного анализа. Почти все о чем вы написали действительно не его профиль. Потому что все перечисленные проблемы решает первая и вторая линия поддержки. А он занимается другим: разработкой новых фитч по запросу пользователей, баги в софте ковыряет (если это вендор ПО или интегратор) и пр.
Первый уровень — оперативная поддержка. Это обеспечение бесперебойной работы систем и решение проблем только по инструкции. Есть инструкция как решить проблему, значит она решается. Если инструкции нет, то передается дальше. Как правило, первый уровень реализует поддержку по принципу 365/7/24.
Второй уровень решает несложные нетривиальные проблемы, не требующие серьезного анализа и разработки. Например на этом уровне может сделаться несложный data fix или может быть сделан какой-то быстрый workaround. Здесь уже как правило не идет речь о поддержке 365/7/24. Как только стукает 18 или 19 часов все разбегаются по домам. Но если задача важная, то могут и решать сверхурочно.
А вот третий уровень, это непосредственно разработка и решение проблем, требующих серьезного анализа. Почти все о чем вы написали действительно не его профиль. Потому что все перечисленные проблемы решает первая и вторая линия поддержки. А он занимается другим: разработкой новых фитч по запросу пользователей, баги в софте ковыряет (если это вендор ПО или интегратор) и пр.
Если вы до сих пор не напишете простейший цикл с первого раза без ошибок, это выглядит как довольно мало опыта.
Я закрываю скайп и, конечно, тут же вспоминаю, что за virtual.
Наверняка у многих такое бывало на собеседовании. Но, когда беседа закончена, то уже «нещитово».
Маленький лайфхак: можно записать суть вопроса одним словом на бумажке и предложить продолжить разговор.
Неизбежно возникнет пауза (например, когда собеседующий будет мысль формулировать) и ваш на секунду освободившийся мозг вытолкнет найденную в архивах информацию.
Так уж наш мозг работает.
У этого явления даже название есть — эффект лестницы ru.wikipedia.org/wiki/%D0%9B%D0%B5%D1%81%D1%82%D0%BD%D0%B8%D1%87%D0%BD%D1%8B%D0%B9_%D1%83%D0%BC
Я сам разработчик, но проводил собеседование в команду в том месяце. Если коротко обобщить мой опыт — «берем первого не самозванца». Дело не в знании virtual, дело в том что можешь написать «синьор», «бест оф зе бест» и так далее — совершенно не важно. Все равно тебе пришлют резюме, и на все твои требования скажут — «знаю поверхностно если что разберусь», так банально делают все. И будут убеждать — я то что вам нужно, у меня огромный опыт, я фокусируюсь на практике и решении бизнес проблем. Потом начинаешь тех интервью, оказывается что человек не знает что такое Диспоуз, и зачем он нужен. Не знает зачем метод SuspendLayout хотя заявляет, что у него опыт 5-10 лет с ВинФормами.
И нет я не заканчивал интервью после первого не верного ответа — ну бывает, человек забыл. Но как можно забыть то, без чего невозможно работать с конкретной технологией, которая указана в резюме?
Я несколько раз уже помогал искать людей в команду, по сути каждый раз это заканчивалось «берем первого, который не врет, за наши деньги». Подавляющее большинство — лгуны и самозванцы. Врут про все, про национальность (один китаец говорил что он украинец, ни знал ни русского ни украинского, не мог назвать город где живет, использовал гугл транслейт), про занятость на других проектах (подается на фулл тайм, оказывает то студент то работает в офисе и ищет подработку), про скилы (в резюме создавал дамбу Гувера — на практике подавал ключи строителю), про личность исполнителя (проходит собес один человек, а работает потом другой, который ни чего не помнит и ниже скилами), про вредные привычки (а оказывается запойный алкоголик).
Короче да, вы правы, центральная идея — не взять самозванца. Но персонаж, который вам попался, явно перегнул палку, с такими критериями (чтоб от зубов отскакивало) он скорее всего найдет или ни кого, или самозванцев другого типа. Такие тоже попадались — все знают, работать не умеют, от слова совсем. Т.е. только по шаблону добавлять однотипные фичи или чинить мелкие баги.
А самое плохое — что нет возможности ни как на это влиять, отзывы ставишь только после работы. И это легко накручивается, работой самого на себя под разными именами. Тесты онлайн так-же легко накручиваются и проходятся. В итоге это армия самозванцев — бродит в поисках жертвы и не имеет ни каких механизмов естественного сокращения численности. Процент не врущих на собесах — падает. И все опять сводится к «порукам», просят посоветовать кого-то, с кем работал.
А вам не стоит бояться ходить на собесы, ну провалили одно, не устроились к тирану-топу-заучке, который бы не дал вам ни чего проектировать или делать, давил бы вас и самоутверждался. Хорошо же? Собеседование это двоякий процесс. Соискатель так-же тестирует работодателя, и сможет ли он с ним работать. И вот кстати очень редко самозванцы что-либо спрашивают относительно будущего места работы, им все пофигу, им все по плечу, они ко всему привыкнут. В то время как норм специалисты зачастую чувствительны даже к стилю кода, методологии и т.д.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
П.С. А был такой, что вообще ответы копипастил из гугла, прямо в наглую.
И нет я не заканчивал интервью после первого не верного ответа — ну бывает, человек забыл. Но как можно забыть то, без чего невозможно работать с конкретной технологией, которая указана в резюме?
Я несколько раз уже помогал искать людей в команду, по сути каждый раз это заканчивалось «берем первого, который не врет, за наши деньги». Подавляющее большинство — лгуны и самозванцы. Врут про все, про национальность (один китаец говорил что он украинец, ни знал ни русского ни украинского, не мог назвать город где живет, использовал гугл транслейт), про занятость на других проектах (подается на фулл тайм, оказывает то студент то работает в офисе и ищет подработку), про скилы (в резюме создавал дамбу Гувера — на практике подавал ключи строителю), про личность исполнителя (проходит собес один человек, а работает потом другой, который ни чего не помнит и ниже скилами), про вредные привычки (а оказывается запойный алкоголик).
Короче да, вы правы, центральная идея — не взять самозванца. Но персонаж, который вам попался, явно перегнул палку, с такими критериями (чтоб от зубов отскакивало) он скорее всего найдет или ни кого, или самозванцев другого типа. Такие тоже попадались — все знают, работать не умеют, от слова совсем. Т.е. только по шаблону добавлять однотипные фичи или чинить мелкие баги.
А самое плохое — что нет возможности ни как на это влиять, отзывы ставишь только после работы. И это легко накручивается, работой самого на себя под разными именами. Тесты онлайн так-же легко накручиваются и проходятся. В итоге это армия самозванцев — бродит в поисках жертвы и не имеет ни каких механизмов естественного сокращения численности. Процент не врущих на собесах — падает. И все опять сводится к «порукам», просят посоветовать кого-то, с кем работал.
А вам не стоит бояться ходить на собесы, ну провалили одно, не устроились к тирану-топу-заучке, который бы не дал вам ни чего проектировать или делать, давил бы вас и самоутверждался. Хорошо же? Собеседование это двоякий процесс. Соискатель так-же тестирует работодателя, и сможет ли он с ним работать. И вот кстати очень редко самозванцы что-либо спрашивают относительно будущего места работы, им все пофигу, им все по плечу, они ко всему привыкнут. В то время как норм специалисты зачастую чувствительны даже к стилю кода, методологии и т.д.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
П.С. А был такой, что вообще ответы копипастил из гугла, прямо в наглую.
Тестовое задание?
Их так-же подделывают, пишет один человек, а собеседуется другой. Бодишопы вообще ад в этом плане, есть один супер разраб, который проходит собеседования, сдает тесты, пишет тестовые задания, а потом вместо него, работают его менее умелые коллеги. Если они сильно лажают — он подключается, разруливает все, может по скайпу поговорить, а потом дает чертей джуну и джун дальше работает под его видом.
Вот и выходит — нужна вебка, нужно сразу просить писать код, нужно задавать вопросы «на самозванца» и включать психолога.
Вот и выходит — нужна вебка, нужно сразу просить писать код, нужно задавать вопросы «на самозванца» и включать психолога.
Так может поспрашивать чувака по его тестовому? Как он его делал, и почему принимал те решения, что принимал. Это как раз то, что он не может забыть, ведь делал тестовое за день перед собесом. И я всё же считаю, что включать психолога нужно, если точно знаешь, что ты умеешь это делать.
Так и делаю, но тестовое какого уровня? Более менее внятное тестовое для технологий текущего проекта это от 40 часов. Бесплатно работать неделю многие хорошие девы не согласятся, а значит надо оплачивать, и абы кому — не хочется.
Мы однажды пробовали такое, человек к нам на 2 недели выходил. В итоге так и не взяли. Собственно, сразу были сомнения, но парень уговорил нас на такую схему — типа покажу вам, как я круто могу. Не показал. И да, так уже накладно по деньгам выходит, да и не многие на такие условия согласятся даже если им предложат оплатить потраченное время.
UFO just landed and posted this here
Бывает и так, что все хотят сениора, а дают ему потом таски типа вёрстки. Что бы сохранить сениора, такую рутину приходится скидывать на джунов.
UFO just landed and posted this here
Если заказчик в итоге доволен, то win-win.
Зависит от точки зрения. Заказчик нанимает человека для выполнения работ, при этом обычно он прямо не обязуется не использовать труд других людей. И дальше он например нанимает себе помощника, или секретаршу, со своих денег, которые ему заплатил заказчик. Ну и какая разница то-ли секретарша ему кофе варит, а он не тратит на это час времени в день, или джун делает для него рутину, а он в это время сфокусирован на другом. Это его деньги и его проблемы.Главное что-бы работа и цена, которые были согласованы — были сделаны. Это вопрос взгляда и вопрос конкретного договора.
С тестовым заданием есть риск, что опытные специалисты не будут его делать, особенно если оно используется как первичный фильтр.
А по-моему это отличный шанс показать как хорошо можешь сделать. Хотя никто не мешает сделать не самому.
Угу. Делаешь такое тестовое задание, ну, пусть даже 1 день.
А тебе отказывают без какого-либо объяснения причин.
Пойдете писать подобное задание еще раз в следующую компанию «нам лень потратить на вас свое время но мы ждем от вас что вы потратите на нас не менее дня работы»?
При этом мотивация для отбраковки работы ведь тоже может быть произвольной. Идиот точно так же будет искать там к чему придраться — и успешно найдет.
Уж лучше устные вопросы. Честно. Тут хотя бы есть обратная связь.
А тебе отказывают без какого-либо объяснения причин.
Пойдете писать подобное задание еще раз в следующую компанию «нам лень потратить на вас свое время но мы ждем от вас что вы потратите на нас не менее дня работы»?
При этом мотивация для отбраковки работы ведь тоже может быть произвольной. Идиот точно так же будет искать там к чему придраться — и успешно найдет.
Уж лучше устные вопросы. Честно. Тут хотя бы есть обратная связь.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
Я бы на такое заявление заметил, что поведение рекрутера, который по поверхностным вопросам делает выводы в место ведения диалога, больше похоже на психологическую травму подростка.
А вот из личного опыта:
Как то зашел у меня разговор с рекрутером о написании драйвера. Разговор свелся к тому что его представление об этом процессе подразумевает упоминание некоторых специфик. На мой вопрос «каких?», он спросил меня «что такое intellisense?». С мыслью о том, какое отношение intellisense имеет к процессу написания драйвера, я ответил «Понятия не имею». Сами понимаете какая ситуация получилась. Тем не менее, мне обещали выслать тестовое задание, которое я так и не получил.
Мне также приходилось иметь дела с подбором персонала в свою команду, и тут должен заметить тест тесту рознь. Поскольку, когда через неделю к тебе приходит человек, завалившийся на этапе установки IDE это тоже показатель. А с другой стороны я бы не прочь иметь у себя в подчинении или напарника, умеющего лихо находить применения интернет материалам в работе. Поскольку для меня даже такой кандидат был роскошью. Тех же, которые подходили полностью не проходили по легальному положению дел. То без гражданства то еще что. В общем всякое может быть.
UFO just landed and posted this here
>Сеньору это не нужно зазубривать, он и так все знает, т.к. пользуется, а если не пользуется, то возникает вопрос — почему?
Сениоры часто вырастают в совсем другой класс специалистов, которые решают более высокоуровневые проблемы, а не институтские задачи. И потому таких денег и стоят, так как опыт позволяет эти проблемы решать, в отличие от juniorов, которые расскажут, что такое виртуальный метод, но ни черта не поймут, почему лежит система. И нет, она лежит не из-за виртуальных методов.
Сениоры часто вырастают в совсем другой класс специалистов, которые решают более высокоуровневые проблемы, а не институтские задачи. И потому таких денег и стоят, так как опыт позволяет эти проблемы решать, в отличие от juniorов, которые расскажут, что такое виртуальный метод, но ни черта не поймут, почему лежит система. И нет, она лежит не из-за виртуальных методов.
Эти «специалисты» потом оказываются заточены на крайне узкий класс задач.
Шаг вправо шаг влево — и нихрена они уже не понимают. Смутно вспоминают чего-то, но реализовать уже не могут. Здорово конечно когда находится такой спец вот конкретно на ту задачу которая есть у тебя. Но для 99% задач такой спец не годится а под оставшиеся 1% часто проще нанять кого-то попроще но кого не понадобится 3 года искать потому что таких спецов всего двое на всю Москву.
Толковый же джун он может сейчас чего-то и не знать, но он всему научится. Беспроигрышный вариант в среднесрочной перспективе
Шаг вправо шаг влево — и нихрена они уже не понимают. Смутно вспоминают чего-то, но реализовать уже не могут. Здорово конечно когда находится такой спец вот конкретно на ту задачу которая есть у тебя. Но для 99% задач такой спец не годится а под оставшиеся 1% часто проще нанять кого-то попроще но кого не понадобится 3 года искать потому что таких спецов всего двое на всю Москву.
Толковый же джун он может сейчас чего-то и не знать, но он всему научится. Беспроигрышный вариант в среднесрочной перспективе
Потому что дохрена задач решают разных?
Работю с Unreal Engine.
У меня тут статья есть про то как делать анимации через Sequencer. Так я её на днях использовал, чтобы вспоминить ка кделать анимации в Unreal Engine.
Или вот настройка анимаций персонажей, год назад был проект в котором делали очень сложные анимации и я досканально с ним поработал.
А тут открыл редактор и даже вспомнить не мог как что делается, пришлось в доки лезть.
Причина проста — я не аниматор и работаю с анимациями далеко не каждый день.
Но если я иду на сеньора — такие вещи я должен знать. И я их знаю… но не помню.
Работю с Unreal Engine.
У меня тут статья есть про то как делать анимации через Sequencer. Так я её на днях использовал, чтобы вспоминить ка кделать анимации в Unreal Engine.
Или вот настройка анимаций персонажей, год назад был проект в котором делали очень сложные анимации и я досканально с ним поработал.
А тут открыл редактор и даже вспомнить не мог как что делается, пришлось в доки лезть.
Причина проста — я не аниматор и работаю с анимациями далеко не каждый день.
Но если я иду на сеньора — такие вещи я должен знать. И я их знаю… но не помню.
Всё что вы должны — это решать задачи соответствующего уровня сложности за адекватное время. В наше время фронт необходимых навыков для серьёзных работ на столько широк, что помнить все детали совершенно невозможно и не нужно. Но отличие сениора от джуна будет в том, что сениор решит задачу с гуглом за час, а джун — и за 2 дня не решит. Потому и спрашивать про какие-то элементы языков, которые раз в месяц используешь смысла никакого нет, есть смысл спрашивать про то, как человек бы решал конкретную проблему. При этом даже не так и важно, решит он её на собеседовании или нет. Интересней сам подход к решению.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Не прав, потому что не выдержали, встали и ушли (это если не упоминать ваши оценочные суждения про людей, которые вас позвали). Вежливость принято давать в кредит.
Стоило, возможно, раньше прервать общение. Или до собеседования предупредить о том, что на листике не решаете, а если надо будет писать код, то уточнить заранее, в каких условиях это предполагается: свой ноут или чужой, будет доступ в интернет или нет, предполагаемое время на код.
Обычно, если не отвечают мне на эти вопросы или лукавят, со собеседование переходит в категорию стресс-интервью и мой ценник увеличивается — я могу и в таких условиях работать, но это дороже.
Увы но такие типы есть и будут, очевидно, что такое собеседование не показатель ваших способностей, не принимайте близко, просто делайте выводы и пытайтесь дальше. Главное самим не стать такими.
Убей не помню. Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего. Интервью, естественно, кончается.Тяжелый лайф хак: как только понимаешь, что какую лажу выкидывают собеседеры заявляешь, что предлагаешь прекратить собеседование прямо сейчас чтобы не терять своего времени (или ты понял что компания находится в стадии хаоса, или мало понимает свои цели, или еще что-нибудь такое веселое на твой взгляд). Гордость, свечение и высокомерие собеседера быстро испаряются. Я так делал всего один раз, когда мне заявили, что переработка будет учитываться (не оплачиваться!) только если я буду работать до часу ночи. Собеседера от моей оценки и предложения немножко трусило.
Очень знакомо, не вспомнил название какой то мелочи, уже не подходишь, а как посмотрел текущие проекты потенциального работодателя, очень обрадовался этому. Выходит если заучил названия, значит что то умеешь. так и живем.
То, что сеньер не знает что такое virtual никого не смутило? Серьезно?
Скорее всего знает, просто он забыл. С наследованием все сталкивались, и многие на интерфейсах ездят.
Вот я тоже не понял. На мой взгляд интервьюер всё правильно сделал.
Сугубо мое личное мнение:
Джун — должен рассказать о virtual и о переопределении при наследовании
Мидл — должен к этому всему добавить хорошие use cases, и вспомнить о abstract/sealed.
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики.
Джун — должен рассказать о virtual и о переопределении при наследовании
Мидл — должен к этому всему добавить хорошие use cases, и вспомнить о abstract/sealed.
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики.
Странно, а что джун этого не может знать?
abstract/sealed — да уж, джун не потянет…
виртуальных вызовах на структурах — хм, в чем отличие я не в кусре.
Ни алгоритмы ни паттерны не отличают джуна от синера, а только опыт работы с инструментами, библиотеками, фреймворками, архитектурами и опыт общения с коллегами / заказчиками.
abstract/sealed — да уж, джун не потянет…
виртуальных вызовах на структурах — хм, в чем отличие я не в кусре.
Ни алгоритмы ни паттерны не отличают джуна от синера, а только опыт работы с инструментами, библиотеками, фреймворками, архитектурами и опыт общения с коллегами / заказчиками.
Странно, а что джун этого не может знать?
abstract/sealed — да уж, джун не потянет…
Конечно может, но это от него не требуется.
Знания того как работают виртуальные вызовы это и есть «опыт работы с инструментами». Рантайм это инструмент.
Конечно может, но это от него не требуется.Джун читает книгу о языке, и в той книге всё написано, как он может не знать?
как работают виртуальные вызовыэто в книге по с++ написано, и в книгах по другим языкам.
Или почитав книгу о таких вещах, я сразу перестал быть джуном?
А если бы я не знал этого, то я не синьер? В работе мне эти знания ни разу не пригодились. А если бы задача про это стояла, я бы как нибудь через гугл вышел и на решение и на знание.
А если бы я не знал этого, то я не синьер?
Очень-очень сомнительный сеньор.
В работе мне эти знания ни разу не пригодились.
Значит такая работа была.
Скорее всего вы придаете значение ерунде.
Работы были разные и хорошие и всякие.
А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
Работы были разные и хорошие и всякие.
А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
Любая работа, где необходимо хоть примерно представлять, насколько виртуальный вызов дороже невиртуального, почему так происходит и как этого избежать.
Практически ни на сколько, даже в циклах.
Ну то есть, вам тоже это ни разу не понадобилось, так?
Ну то есть, вам тоже это ни разу не понадобилось, так?
О каких циклах речь?
Тест за 5 минут
#include <iostream>
#include <cstring>
class IVirtualOp
{
public:
virtual void add() =0;
virtual long get() const =0;
~IVirtualOp() = default;
};
class VirtualAdd : public IVirtualOp
{
public:
void add() override
{
acc++;
}
long get() const override
{
return acc;
}
private:
long acc = 0;
};
class VirtualSub : public IVirtualOp
{
public:
void add() override
{
acc--;
}
long get() const override
{
return acc;
}
private:
long acc = 0;
};
void testNonVirtual(bool sub, long count)
{
long res;
if(sub)
{
VirtualSub o;
for(long i = 0; i < count; ++i)
{
o.add();
}
res = o.get();
}
else
{
VirtualAdd o;
for(long i = 0; i < count; ++i)
{
o.add();
}
res = o.get();
}
std::cout << res;
}
void testVirtual(bool sub, long count)
{
IVirtualOp* o = (sub) ? static_cast<IVirtualOp*>(new VirtualSub())
: static_cast<IVirtualOp*>(new VirtualAdd());
for(long i = 0; i < count; ++i)
{
o->add();
}
std::cout << o->get();
}
int main(int argc, char* argv[])
{
if(argc != 4)
return 0;
long count = atol(argv[3]);
bool useSub = strcmp(argv[2], "sub") == 0;
if(strcmp(argv[1], "n") == 0)
testNonVirtual(useSub, count);
else if(strcmp(argv[1], "v") == 0)
testVirtual(useSub, count);
return 0;
}
$ time ./tst n sub 1000000000
-1000000000
real 0m0,001s
user 0m0,000s
sys 0m0,001s
$ time ./tst v sub 1000000000
-1000000000
real 0m1,580s
user 0m1,577s
sys 0m0,003s
Ну как, ни на сколько, даже в циклах?
$ g++ --version
g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ time ./tst n sub 1000000000
-1000000000
real 0m2.859s
user 0m2.856s
sys 0m0.000s
$ time ./tst v sub 1000000000
-1000000000
real 0m2.916s
user 0m2.912s
sys 0m0.000s
От незадача! Как так?! :(
-O0?
Если бы только -O0. Конечно, сначала это было именно оно. Но достаточно убрать инлайн реализацию чтобы свести все к 1:1.
А часто в реальных проектах релизные сборки собираются с отключенными оптимизациями и запрещенным инлайном?
Далеко не все методы класса реализуются в инлайне, ведь правда? В том числе переопределенные виртуальные.
В вашем тесте сравнивается не виртуальность/невиртуальность но инлайн/неинлайн. Это уже немного о другом.
В вашем тесте сравнивается не виртуальность/невиртуальность но инлайн/неинлайн. Это уже немного о другом.
Ну например виртуальный вызов невозможно заинлайнить, а разницу между инлайн и нет вы сами показали.
UFO just landed and posted this here
Тогда это не будет виртуальный вызов, вот и всё :)
Я про случаи, где добавление/удаление словa «virtual» меняет семантику и результат выполнения кода.
Я про случаи, где добавление/удаление словa «virtual» меняет семантику и результат выполнения кода.
UFO just landed and posted this here
а виртуального вызова нет, компилятор всё заинлайнил.
Ну вот именно, там вызов невиртуальный. А был бы виртуальный — и заинлайнить бы не вышло :)
То есть заинлайнить можно тогда, когда компилятор может заменить виртуальный вызов обычным, что уже отдельная оптимизация (и после нее не обязательно будет следовать инлайнинг).
Ок, неверно сформулировал. Виртулизация в данном случае не дает ничего, потому что можно руками вызывать нужный метод. Виртуализация — это когда мы как раз-таки не знаем конкретный метод, который надо вызывать, потому что он должен определяться динамически. А тут это просто вызов конкретного метода, пусть немного необычным способом. Наверное, я неверно изначально критерии обозначил.
В очень хорошей статье про кост виртуальных вызовов написано:
http://ithare.com/c-performance-common-wisdoms-and-common-wisdoms/
Он есть. Но не он решает.
http://ithare.com/c-performance-common-wisdoms-and-common-wisdoms/
Он есть. Но не он решает.
Виртуальные вызовы конечно же заметно медленнее прямых.
Но ваш тест абсолютно некорректен.
Если бы вы скомпилировали без оптимизаций, я бы сказал что это нечестный бенчмарк, т.к. в продакшене всегда включают -O2.
Но, судя по результатам, вы таки включили O2. И компилятор не только заинлайнил вызовы, но и векторизовал их.
Интересно было бы послушать ваше объяснение на эту тему. Желательно в цифрах с описанием методологии измерения. Применительно к C++. Я не навязываюсь. Но уж если вы затронули эту тему и она проста и тривиальна как три рубля… Не затруднит ли вас?
Бенчмарки на коленке собирать? Затруднит, разумеется. Я не верю, что вы ничего не смогли найти на эту тему самостоятельно.
Я правильно понимаю, что аналогичным образом вы будете аргументировать свои за/против использования виртуальных методов в C++ потенциальному кандидату на собеседовании если его точка зрения разойдется с вашей?
Кандидат будет так же аргументировать незнанием или молчанием? Расскажу ему про vtable, указатель на нее и его разыменование. Но синттесты писать на коленке — это не самое благодарное занятие и если в вашей практике встретится такой интервьюер, то передавайте от меня привет)
Нет уж, паровоз, давай таки по рельсам…
>> А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
> Любая работа, где необходимо хоть примерно представлять, насколько виртуальный вызов дороже невиртуального, почему так происходит и как этого избежать.
Допустим, оппонент не знает как устроена таблица виртуальных методов. Это конечно печально. Рассказать, как она устроена — сам бог велел. В противном случае зачем задавать такой вопрос? Опять же «Бросая камушки в воду смотри на круги расходящиеся дабы не стало это занятие пустой тратой времени».
Но вот выводы — чем это грозит а тем более с точки зрения производительности системы — я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
>> А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
> Любая работа, где необходимо хоть примерно представлять, насколько виртуальный вызов дороже невиртуального, почему так происходит и как этого избежать.
Допустим, оппонент не знает как устроена таблица виртуальных методов. Это конечно печально. Рассказать, как она устроена — сам бог велел. В противном случае зачем задавать такой вопрос? Опять же «Бросая камушки в воду смотри на круги расходящиеся дабы не стало это занятие пустой тратой времени».
Но вот выводы — чем это грозит а тем более с точки зрения производительности системы — я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
Напротив, это совсем не повод замыкаться в своем невежестве. Нужно читать умные книжки про оптимизацию, не стесняться лезть «под капот», развиваться шаг за шагом. Это показатель опыта, а не: «Я 15 лет хреначу CRUD'ы интернет-магазинов и делаю это быстрее всех, поэтому сеньор».
Это у вас в С++ всё инлайнится и «затирается» и на вкус и цвет почти как обычный вызов.
В .NET, на виртуальных методах будет проверка на нулевой указатель, а в некоторых случаях еще и копирования объекта в стеке перед каждым вызовом. А если объект, к примеру, толстый, то туши свет.
В .NET, на виртуальных методах будет проверка на нулевой указатель, а в некоторых случаях еще и копирования объекта в стеке перед каждым вызовом. А если объект, к примеру, толстый, то туши свет.
А вы что-то доказать хотите или предложить?
Почти никому не понадобится вбивать в гугл «как работают виртуальные методы в языке X» т.к. это не «проблема» которую надо решить. Нет проблемы «не работают виртуальные методы» или «я не могу сделать виртуальный вызов». Всё работало, и вам даже не интересно как это работало. А знания из разряда «как оно на самом деле работает» открывают дверь в чудный мир простых решений ака «хаков» и хитрых оптимизаций.
По поводу джунов и книг. Есть разница между «прочитать в книге» и «понять как оно работает». У джуна эти знания как влетят, так и вылетят. А потом на собеседовании он не вспомнит нужное слово или не сможет описать суть.
Есть классификации программистов, которая мне лично нравится:
Джун — тот кто решает простые проблемы сложным путем.
Мидл — тот кто решает простые проблемы простым путем, сложные сложным.
Сеньер — тот кто решает сложные проблемы простым путем.
По поводу джунов и книг. Есть разница между «прочитать в книге» и «понять как оно работает». У джуна эти знания как влетят, так и вылетят. А потом на собеседовании он не вспомнит нужное слово или не сможет описать суть.
Есть классификации программистов, которая мне лично нравится:
Джун — тот кто решает простые проблемы сложным путем.
Мидл — тот кто решает простые проблемы простым путем, сложные сложным.
Сеньер — тот кто решает сложные проблемы простым путем.
UFO just landed and posted this here
Есть у меня сам по себе интерес к подобному, но денег это не приносит.
Вот я и интересуюсь что это за работы. Какой спрос, какая плата. Я ни разу не дебажил ничего связанного с VMT.
Если не писать квадратичные алгоритмы и использовать кэши, то в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Конечно игры и 3D могут требовать иной подход, но спрос на подобное, в процентах ИМХО ничтожен.
Вот я и интересуюсь что это за работы. Какой спрос, какая плата. Я ни разу не дебажил ничего связанного с VMT.
Если не писать квадратичные алгоритмы и использовать кэши, то в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Конечно игры и 3D могут требовать иной подход, но спрос на подобное, в процентах ИМХО ничтожен.
в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Типичное бизнес-приложение балансирует на грани «дешево, юзеры еще не жалуются, что из-за тормозов невозможно работать» и «нужно бы виртуалке больше оперативки накинуть». Ибо фичи нужно пилить, некогда рефакторинг, да еще и тестировать потом…
Вы как будто анекдот не помните...
В институте на разных курсах задают вопрос: сколько будет 2 умножить на 2?
Первокурсник: (бодро) 4!
Второкурсник: (достаёт таблицу умножения, смотрит) 4!
Третьекурсник: (достаёт таблицу логарифмов, смотрит, считает) 4!
Четверокурсник: (достаёт логарифмическую линейку, щёлкает пару секунд) с удвлетворительной точностью — 4!
Пятикурсник: Да что я вам, слон — все константы наизусть помнить?!
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики
Знал как устроена VMT еще в школьные годы. То есть это до джуна.
Затем забыл за ненадобностью.
Сеньор даже на уровне паттернов работает уже на уровне уровне автоматизма, а вы про какие-то байтики спрашивайте.
Если этот сеньор будет разрабатывать компилятор — то знание VMT будет ему крайне нужно.
Иначе — зачем?
Приведите конкретный кейс, пожалуйста.
Я забыл слово. Не поведение, которое оно даёт.
Что такое virtual?
Бам!
Слово вам как раз сказали, вы забыли связь слова с его значением. Это уже не так невинно звучит.
И мгновенно превратился в самозванца, да.
Ну это действительно странно выглядит.
Понимаю, что заклинить может (надосып, переработка, бодун...) кого угодно, но зачем за столь очевидный косяк переводить стрелки на интервьюера? Вопрос достаточно очевидный и это совсем «не пыльный угол» сишарпа.
Понимаю, что заклинить может (надосып, переработка, бодун...) кого угодно, но зачем за столь очевидный косяк переводить стрелки на интервьюера? Вопрос достаточно очевидный и это совсем «не пыльный угол» сишарпа.
Проблема как раз в том, что я начинаю размышлять так же, как вы, и сам себя определяю как самозванца. С другой стороны, у меня есть серьёзные основания быть уверенным в себе. Короче, мне не комфортно, когда мне не предоставляют возможности донести до интервьювера уровень моих знаний и опыта. Возьмут меня или нет на работу — это их дело.
Вся ваша рефлексия должна бы закончиться на результатах анализа, почему ваш интервьюер обрадовался вашей неудаче.
Проблема как раз в том, что я начинаю размышлять так же, как вы, и сам себя определяю как самозванца.
Каким образом это является проблемой?
То, чем вы сейчас занимаетесь — контрпродуктивно. Так или иначе — косяк случился и есть два путя: сделать вид, что все нормально и так сойдет, или постараться больше таких проколов не допускать.
Ну так тут два варианта: либо у вас был ступор, либо вы — fraud. Многие почему-то принимают первое за второе. У меня когда-то спросили можно ли написать
Мои шестеренки сразу заклинило, я с трудом выдавил «нет» и на вопрос «а как сделать, чтобы можно было?» я не ответил, потому что не мог понять, что от меня вообще хотят и зачем это надо. А собеседующий всего лишь хотел услышать, что я знаю как работать с префиксом @:
class object : object
{ }Мои шестеренки сразу заклинило, я с трудом выдавил «нет» и на вопрос «а как сделать, чтобы можно было?» я не ответил, потому что не мог понять, что от меня вообще хотят и зачем это надо. А собеседующий всего лишь хотел услышать, что я знаю как работать с префиксом @:
class @object : object
{ }Не быть вам филологом.
Судя по всему, да.
Если не ошибаюсь, есть специальный веб-сервис для таких «переворотов»
Если не ошибаюсь, есть специальный веб-сервис для таких «переворотов»
Мы даем домашку на неделю. Если человек в теме ему на пару часов, если нет — день-два по вечерам разобраться. Заодно видно, как человек относится к изучению нового.
Если за пару часов я не решу, то зачем мне бесплатно этим заниматься? Ну попалась тема которую мне нужно исследователь что бы решить задачу, но зачем мне тратить свое время, это проблема работодателя — либо учить, либо найти готового. Программисты нарасхват.
Затем, что больше двух часов оно у вас займет как раз потому что для вас будет чем-то новым. Если вы от возможности узнать что-то новое воротите нос, то и зачем вы такой нужны?
Вот именно, если новое, то зачем учить WPF когда на React спрос больше?
В мире столько вещей которые любопытно изучать — жизни не хватит. Тут не про воротить нос, а про целесообразность. Дело не в новом, а в выгодном.
В мире столько вещей которые любопытно изучать — жизни не хватит. Тут не про воротить нос, а про целесообразность. Дело не в новом, а в выгодном.
новое — не всегда интересное. область моих интересов в it, например, как правило работодателю не нужна. а нужны реакты, редуксы и прочии нахайпованные go
Разумеется, это право соискателя — отказаться от задания. Но пока не отказывались.
Я бы назвал это антипаттерном собеседования. На собеседования итак уходит много времени. Если на каждое делать тестовое — уйдут дни. Проверять тестовое тоже нужно время, не проще ли лично поговорить? И что даст понять тестовое задание? Если оно маленькое, то на позициях кроме junior это ничего не даст абсолютно. На позициях выше — у кандидата наверняка найдутся мегабайты кода с примерами. Если вам нужен сильный специалист, готовы ли вы ждать его эту неделю? Если он и правда хорош, есть ненулевая вероятность что за неделю он успеет отсобеседоваться и принять оффер от другой компании.
Тестовое задание может много что сказать о человеке. Например были случаи, когда «сениоры» писали классы, с глобальными переменными, были случаи, когда другие «сениоры» копипастили код со stackoverflow, который содержал ошибки (ну что можно сказать о человеке, который не смог сам реализовать strnstr, когда она ему понадобилась, а после этого ещё и не проверил тот код, что нашёл на просторах интернета). Были случаи, когда код присылали полностью рабочий, но абсолютно не читаемый, что в нём эксперты не могли за полчаса разобраться. Или что код вроде даже читаемый, но абсолютно не структурирован, т.е. в случае необходимости его расширить/дополнить он на 80% пойдёт в мусорку.
UFO just landed and posted this here
Я последнее время прошу прислать часть проблемного/работающего кода и смотрю перед тем как на письмо отвечать. Сразу показывает многое про уровень. В одной конторе транзакционность сделали по дате, а при вопросе — почему не уровне полей (удобнее для людей), даже не поняли о чём речь. Хотя надувались на virtual/object/var и прочую ерунду (это видимо в какой то методичке написали, а потом все copy/paste в мозг переносят).
Это кто кандидатам будет продакшин код высылать? Ни разу про такое не слышал
Про улучшение качества мультфильмов при помощи компьютера тоже никто не слышал 10 лет назад. Я и не требую весь production код.
Но везде люди работают — значит и ошибаются.
github.com/aeroflotsrc/webapp
github.com/aeroflotsrc/webapp
Первое в жизни собеседование на программиста проходило так: спросили, есть ли у меня какой-то код, типа учебного проекта. У меня как раз такой был, его и показал. Попросили добавить туда несколько фич. Что-то смог добавить сам, что-то не смог в силу недостатка знаний, но с парой подсказок таки допилил. Ушло на все собеседование часа 4. В итоге все успешно, приняли на работу. Не верил своему счастью, чувствовал себя самозванцем еще несколько месяцев.
Интересная штука. Почему все работодатели боятся нанять «самозванца», но при этом не боятся отдавать заказ подрядчикам? И ведь собеседований с ними не проводят же.
При том, что на моём опыте подрядчики даже с известным именем могут совершить такие лютые факапы, что даже отдел самозванцев на сможет с ними сравниться.
При этом они еще регулярно нанимают самозванцев — профессиональных проходильщиков собеседований.
Наверное потому, что подрядчика легче сменить, чем наёмного работника по ТК)
Так есть же испытательный срок. Ну или вначале вообще можно временный договор заключать. И по ГПХ можно работать. Много всяких вариантов.
Для подрядчиков есть тендеры и если проект важный, то допускают туда не полных лохов. Требуют наличие сертифицированных специалистов в команде и серьезного портфолио сданных проектов. Могут пообщаться с клиентами подрядчика чтобы узнать их мнение и пр. Это аналог собеседования. Само собой так делают не все, но на крупных проектах где крутятся большие бабки, а заказчик хочет именно качественный результат, это нормально.
От работодателя зависит, некоторые (может мне везло, но не меньше трети) таки проводят собеседования для подрядчиков, причем если сравнивать 3 собеседования как сотрудника подрядчика и 6 как просто соискателя за последний год, именно как сотрудника подрядчика меня гоняли гораздо больше и собеседования были сложнее (я бы даже сказал что там другая проблема была — у меня возник вопрос «нафига было меня собеседовать больше двух часов чтобы в итоге посадить на ЭТО» что во многом подтолкнуло ко второй 6-ке собеседований :) )
О, это я скоро буду наблюдать вживую! У нас новый менеджмент уволил целый отдел удаленщиков и собирается отдать код на аутсорс в США (а те в Индию, как водится — дураки что ли в США код писать?).
Я сам провел не один десяток собеседований, и мне кажется, что научился это делать не совсем плохо. Так вот, я сам на собеседование с тестом на бумажке просто не пойду: постараюсь выяснить регламент заранее и если там подразумевается нечто подобное — сразу откажусь. Я готов притащить ноут, показывать свой код, рассказывать о своих проектах и говорить на любые профессиональные темы. Готов выполнить тестовое задание адекватного объема. Но от этого тупняка с бумажками у меня глаз дергается. Думаю что если боевой разработчик, проводящий техническое интервью, не способен разглядеть самозванца через пару-тройку общих вопросов — то грош ему цена и место в детском саду.
По-моему, у боевых разработчиков часто нет времени на проведение интервью :)
А случаи, когда в одном человеке есть и глубокие тех. знания, и хорошие soft skills, и правильный настрой не заваливать и самоутверждаться — крайне редки.
По-моему, у боевых разработчиков часто нет времени на проведение интервью :)
Ну в разных местах команды формируются по разным принципам: в бодишопах действительно, все будут заняты и не смогут далеко отойти от капельницы с глюкозой. А в проектных командах людям бывает не все-равно с кем идти в бой, поэтому они сами очень заинтересованы и находят время. Но, тем не менее, редко кто может правильно поговорить. С обеих сторон =)
Проблема в том, что кроме категории «самозванец» существует уровень разработчика как таковой. Его часто необходимо определить достаточно точно, на сколько это возможно, конечно. Я бы усилил ваше высказывание и сказал, что именно самозванцев (т.е. абсолютных нулей или близких к ним) часто можно и по резюме определять, остальные отсеиваются на skype интервью. Бумажка вовсе не так плоха, как про нее пишут. Например, сделать reverse строки — это достаточно просто. Если такое сложно написать на бумаге правильно, то скорее всего человек если и действительно занимается программированием, то привык заниматься им в стиле «что-то не работает, поправлю как я вот здесь, авось заработает», «ой, что-то не заработало, наверное, еще нужно поправить вот здесь и вот тут». Кому-то здесь нужны такие специалисты?
Проблема в том, что бумажка вам не скажет о уровне разработчика ВООБЩЕ НИЧЕГО. Только реальный код реальных проектов и общая инженерная философия человека. По моему опыту, люди блестяще проходившие бумажные тесты часто оказывались полнейшими мудаками в работе, и напротив, люди сомневающиеся и робкие показывали себя как офигительные и весьма ценные специалисты, ко мнению которых стоит прислушиваться всегда.
«Оказывались полными мудаками» — это разве про уровень разработчика? Это про общий подход к работе и soft skills. Или что вы имеете в виду?
Она скажет:
1) об умении сначала думать, потом делать и делать аккуратно
2) писать не очень сложный код без ошибок
3) придумывать алгоритмы для сформулированных задач в ограниченное время
4) о знании базового синтаксиса языка без Google и SO. Например, сколько раз я уже видел кандидатов, которые путают названия контейнеров в STL и их методов, по ним сразу видно, что hands on опыта с ними они не имеют. Разработчик, который не помнит, что в вектор добавляет метод push_back — это очень интересно, конечно :)
Я вовсе не предлагаю использовать бумажку (В значении coding interview) как единственный способ проведения собеседования и не утверждаю, что это единственный способ проверять skills. Но это достаточно действенный способ, который имеет распределение успехов, по которому можно неплохо пытаться определяться уровень в том числе. Скажем, вы даете написать 3-4 алгоритма разной сложности (подразумеваю, что речь идет о позиции, что где алгоритмы являются критичным навыком), далее можно построить распределение, по которому будет видно, что большинство справляется с 1-2 задачами с разной чистотой выполнения оных и далее все идет по убыванию. Действительно редкие специалисты способны закодить все 4, не допустив или почти не допустив ошибок. Если в вашей работе почти каждый код — это алгоритм, то такая проверка уже, на самом деле, многое скажет о том, что вы можете ожидать, наняв человека. Между «писать код на бумажке» и «писать код на ноутбуке» с моей точки зрения разницы не очень много, т.к., например, лично я почти не даю на собеседованиях реально технически сложных для кодирования задач, которые без клавиатуры делаются просто напросто долго, но некоторые этим злоупотребляют.
«бумажка вам не скажет о уровне разработчика ВООБЩЕ НИЧЕГО»
Она скажет:
1) об умении сначала думать, потом делать и делать аккуратно
2) писать не очень сложный код без ошибок
3) придумывать алгоритмы для сформулированных задач в ограниченное время
4) о знании базового синтаксиса языка без Google и SO. Например, сколько раз я уже видел кандидатов, которые путают названия контейнеров в STL и их методов, по ним сразу видно, что hands on опыта с ними они не имеют. Разработчик, который не помнит, что в вектор добавляет метод push_back — это очень интересно, конечно :)
Я вовсе не предлагаю использовать бумажку (В значении coding interview) как единственный способ проведения собеседования и не утверждаю, что это единственный способ проверять skills. Но это достаточно действенный способ, который имеет распределение успехов, по которому можно неплохо пытаться определяться уровень в том числе. Скажем, вы даете написать 3-4 алгоритма разной сложности (подразумеваю, что речь идет о позиции, что где алгоритмы являются критичным навыком), далее можно построить распределение, по которому будет видно, что большинство справляется с 1-2 задачами с разной чистотой выполнения оных и далее все идет по убыванию. Действительно редкие специалисты способны закодить все 4, не допустив или почти не допустив ошибок. Если в вашей работе почти каждый код — это алгоритм, то такая проверка уже, на самом деле, многое скажет о том, что вы можете ожидать, наняв человека. Между «писать код на бумажке» и «писать код на ноутбуке» с моей точки зрения разницы не очень много, т.к., например, лично я почти не даю на собеседованиях реально технически сложных для кодирования задач, которые без клавиатуры делаются просто напросто долго, но некоторые этим злоупотребляют.
Вы пытаетесь применять редукционистский подход к очень сложной хаотической системе, включающей кучу аспектов, которые вы не видите и не хотите учитывать: факторы среды, эмоциональный и социальный бэкграунд, нюансы специализации и конкретного опыта… Таким образом, математически можно обосновать почему ваше итоговое распределение будет принимать формы, весьма далекие от реального положения вещей (см. теорию хаоса). Ваш список рассыпется полностью и уже на этапе добавления в систему факторов психологической реакции на тесты. Ваш метод с бумажкой — это иллюзия контроля в чистом виде, банальный способ переложить ответственность на примитивную методологию.
Во-первых, прошу прощения, но собеседование само по себе — это и есть редукционистский и, безусловно, относительный подход: вы пытаетесь за 2-4 часа оценить опыт/навыки человека, который работал, к примеру 10 лет. Тут именно вопрос в том, как именно редуцировать так, чтобы проверять наиболее релевантное. Во-вторых, я снова повторюсь, что провожу собеседования комплексно и оцениваю на нем и в том числе и «нюансы специализации и конкретного опыта». Но если человек, имеющий хотя бы какой-то опыт, который можно считать приличным, не может написать простой код без ошибок на бумаге даже с 3-ей попытки — это, снова повторюсь, говорит о том, что если он и реально что-то разрабатывает (а не просто все наврал в резюме), то его подход к разработке основан на гуглении и бездумном итеративном устранении ошибок методом тыка. Это не тот уровень разработчиков, с которыми я работал когда-либо :)
Ну и какое же реальное положение вещей, просветите пожалуйста? :)
Ну а ваша то методология какая? Демонстрировать написанный код? Хорошо, а если ваш код не покрывает тех случаев, которые бы я хотел увидеть? Готовы дописать ваш код прямо на собеседовании? :) Ведь это будет сложнее, чем начать сначала на абстрактной задаче. Дальше: где гарантия того, что этот код написан самостоятельно и что он написан в приемлемые сроки? Где гарантия, что этот код вообще правильный? Итд.
весьма далекие от реального положения вещей (см. теорию хаоса)
Ну и какое же реальное положение вещей, просветите пожалуйста? :)
банальный способ переложить ответственность на примитивную методологию
Ну а ваша то методология какая? Демонстрировать написанный код? Хорошо, а если ваш код не покрывает тех случаев, которые бы я хотел увидеть? Готовы дописать ваш код прямо на собеседовании? :) Ведь это будет сложнее, чем начать сначала на абстрактной задаче. Дальше: где гарантия того, что этот код написан самостоятельно и что он написан в приемлемые сроки? Где гарантия, что этот код вообще правильный? Итд.
Так вот, я сам на собеседование с тестом на бумажке просто не пойду: постараюсь выяснить регламент заранее и если там подразумевается нечто подобное — сразу откажусь. Я готов притащить ноут, показывать свой код, рассказывать о своих проектах и говорить на любые профессиональные темы. Готов выполнить тестовое задание адекватного объема. Но от этого тупняка с бумажками у меня глаз дергается
Хочу точно такое же, но много ли компаний сейчас разделяют ваш подход? Можно ли как-то распространить такую практику чтоб в мире стало поменьше говнособеседователей и побольше адекватных?
Честно сказать, не рассказать на собеседовании про virtual — это плохой показатель, но не фатальный, конечно. Учитывая волнение.
Позвольте немного рассказать как обычно идет процесс найма, возможно у вас отпадут некоторые вопросы.
Первый этап. На нем нужно узнать что кандидат проходит минимальные требования. Потому что тратить полтора часа рабочего времени на то чтобы понять что мы друг другу не подходим — это много. Поэтому обычно его проводит HR. Тут есть несколько вариантов: просто посмотреть резюме, дать тестовое, дать небольшой опросник. Я лично считаю что достаточно посмотреть резюме, но вариант с опросником тоже хорош, так как он дает темы для общения на втором этапе собеседования.
Второй этап. Здесь уместно провести личное общение с теми, с кем непосредственно будет работать кандидат. Задача собеседующего понять, будет ли комфортно вместе работать. Тут несколько аспектов: опыт, технические знания, личностные качества, потенциал развития, насколько хорошо кандидат вольется в коллектив. И да, если это скайп, то желательно с видео. Очень полезно видеть реакцию человека. Самый простой путь, на мой взгляд, сначала послушать человека о его опыте, идеях и вообще все что ему интересно рассказать. Это и расслабляет кандидата, и в то же время дает 90% всего что вы хотите знать, и дает темы для технических вопросов. Затем перейти к техническим вопросам, может порешать какие-то задачи, дабы просто послушать ход мыслей собеседуемого. Обязательно нужно рассказать про свой проект, чем придется заниматься кандидату, какие у него перспективы и ответить на вопросы.
Третий этап. Общение с начальством, HR о условиях, деньгах и все такое.
Позвольте немного рассказать как обычно идет процесс найма, возможно у вас отпадут некоторые вопросы.
Первый этап. На нем нужно узнать что кандидат проходит минимальные требования. Потому что тратить полтора часа рабочего времени на то чтобы понять что мы друг другу не подходим — это много. Поэтому обычно его проводит HR. Тут есть несколько вариантов: просто посмотреть резюме, дать тестовое, дать небольшой опросник. Я лично считаю что достаточно посмотреть резюме, но вариант с опросником тоже хорош, так как он дает темы для общения на втором этапе собеседования.
Второй этап. Здесь уместно провести личное общение с теми, с кем непосредственно будет работать кандидат. Задача собеседующего понять, будет ли комфортно вместе работать. Тут несколько аспектов: опыт, технические знания, личностные качества, потенциал развития, насколько хорошо кандидат вольется в коллектив. И да, если это скайп, то желательно с видео. Очень полезно видеть реакцию человека. Самый простой путь, на мой взгляд, сначала послушать человека о его опыте, идеях и вообще все что ему интересно рассказать. Это и расслабляет кандидата, и в то же время дает 90% всего что вы хотите знать, и дает темы для технических вопросов. Затем перейти к техническим вопросам, может порешать какие-то задачи, дабы просто послушать ход мыслей собеседуемого. Обязательно нужно рассказать про свой проект, чем придется заниматься кандидату, какие у него перспективы и ответить на вопросы.
Третий этап. Общение с начальством, HR о условиях, деньгах и все такое.
Дело не только в волнении, а в том что каждое гребаное собеседование превращается в экзамен. Может быть вы не в курсе: не только вы выбираете сотрудника, а так же соискатель выбирает место работы. Может мне тогда тоже начать сыпать вопросами нонстоп? А что, в говнокоде ковыряться всю жизнь тоже желания нет.
Озвучьте блин проблему, я скажу как ее решить.
Озвучьте блин проблему, я скажу как ее решить.
Может мне тогда тоже начать сыпать вопросами нонстоп?
А как же. Это нормально, когда и кандидат спрашивает, что его интересует, и про процессы, и про задачи, и даже просит рабочие места и другую инфраструктуру (комнаты отдыха, кухню, туалеты) показать. Меня один кандидат однажды больше часа выспрашивал разные детали, хотя перед этим я его больше получаса сам рассказывал про компанию в общем и про разработку в частности.
*Тоном экзаменатора*
— Два монитора конечно же на рабочем месте?
— Столешница толщиной не менее 2 см?
*как будто обращаюсь к двоечнику*
— Ну CO2 то хотя бы контролируется?
— А говорили солидная компания...
Вот примерно так это бы выглядело зеркально, ибо как раз так оно и происходит со стороны работодателя: не относящиеся к делу случайные вопросы в таком тоне, что аж руки вытереть потом хочется.
— Здравстуйте, вы ээ (читая резюме и анкету) ага Вячеслав, да точно
— Вы я вижу с PHP работаете, о а что такое __autoload
— Как незнаете? базовые же вещи!
— Ой а я вижу вы еще postgreSQL работаете? Расскажите как работает файловый кеш линукса. Ну как зачем, у нас серьезная производительность!
— О а гит! Вы же должны знать команды. Как не работали?
По мне выглядит одинаково. Со стороны соискателя даже поадекватней будет. Я это вот все слышал раз 20 как минимум в разных вариациях, с менторским тоном и взглядом как на говно, и я буду продолжать говорить «не знаю», потому как либо у нас таки случиться интересный диалог либо «вы мне не подходите».
Я даже объясню почему. Тот же автолоадер, когда он мне понадобился я взял из какого то фрейма, переписал под свои реалии, подключил и забыл. Я помню свой код почти построчно, но помню я почему и как он работает а не названия функций.
Систему контроля версий я лично не использую, оно мне не надо, когда нужно я открываю документацию настраиваю и забываю.
Если при использовании бд вы упираетесь в производительность диска, и при этом база и wal и журнал фс у вас лежат на разных дисках, то вы делаете чтото сильно не так. И не надо смотреть на меня как на идиота, исключение — серьезные объемы данных, и нет 100 млн записей это не тот случай.
Я с удовольствием пообщаюсь с коллегой, я всегда рад, правда. В режиме доброжелательного диалога, на тему любимых и нелюбимых штук например. С обоснованием естественно. Но такое случается крайне редко.
Систему контроля версий я лично не использую, оно мне не надо, когда нужно я открываю документацию настраиваю и забываю.
Это не характеризует вас как сколько-нибудь хорошего разработчика. Скорее как пафосного дилетанта.
Это не характеризует вас как сколько-нибудь хорошего разработчика. Скорее как пафосного дилетанта.
Ну вот о чем и речь собственно. Откуда столько токсичности? Где пафос то? Откуда выводы о дилетанстве. Будьте добры аргументов накидать.
Когда заказчику нужно я ее цепляю в IDE и веду согласно требованиям. Зачем мне лично система контроля версий?
Ваше отношение к СКВ говорит о том, что вы а) никогда не работали в команде, б) не способны работать в команде в данный конкретный отрезок времени.
Поздравляю коллега, ошиблись по обоим пунктам. Опять же не вижу аргументации. И еще интересней каково же мое отношение?)
Вы, я так понял, выступаете наглядным примером к тому о чем я говорю? У вас получилось. Сделали выводы, вынесли вердикт, плюнули в душу, ни на один вопрос не ответили. Оппонента спросить или подискутировать? Да нахрен оно надо, правда?)
Вы, я так понял, выступаете наглядным примером к тому о чем я говорю? У вас получилось. Сделали выводы, вынесли вердикт, плюнули в душу, ни на один вопрос не ответили. Оппонента спросить или подискутировать? Да нахрен оно надо, правда?)
Ну, давайте подискутируем.
Вы утверждаете, что а) имеете опыт разработки в команде, б) команде СКВ не нужны.
1. Подскажите, как в вашей команде решается вопрос «сведения» кода нескольких разработчиков в одну кодовую базу.
2. Все разработчики в вашей команде, очевидно, код пишут сразу правильный, безошибочный и оптимальный?
3. Вы делите сборки на тестовые/прод? Из каких исходников вы это собираете? Каким образом вы решаете проблему необходимости быстрого выкатывания патчей на прод в момент, когда вы глубоко «зарылись» в реализацию новой фичи? Срочный патчфикс ждет, пока вы фичу не допилите?
4. Если новая фича не удовлетворила, по каким-то причинам, требованиям заказчика, вы руками вычищаете изменения?
5. Какие «профиты» вы получаете от отказа от систем контроля версий?
6. CI/CD у вас, видимо, не используется? Автоматизация сборки?
7. Вы уверены, что ваши практики лучше общепринятых в разработке? Как вы думаете, что скажет хороший опытный разработчик, который, предположим, к вам на работу устраивается, когда узнает, что внутри вашей организации практики управления кодом, являющиеся стандартом де-факто, не приняты, и у вас своя система правил?
Собственно, наличие СКВ — это всего лишь первый шаг к профессиональной разработке. Вы, пока что, не сделали и его.
Вы утверждаете, что а) имеете опыт разработки в команде, б) команде СКВ не нужны.
1. Подскажите, как в вашей команде решается вопрос «сведения» кода нескольких разработчиков в одну кодовую базу.
2. Все разработчики в вашей команде, очевидно, код пишут сразу правильный, безошибочный и оптимальный?
3. Вы делите сборки на тестовые/прод? Из каких исходников вы это собираете? Каким образом вы решаете проблему необходимости быстрого выкатывания патчей на прод в момент, когда вы глубоко «зарылись» в реализацию новой фичи? Срочный патчфикс ждет, пока вы фичу не допилите?
4. Если новая фича не удовлетворила, по каким-то причинам, требованиям заказчика, вы руками вычищаете изменения?
5. Какие «профиты» вы получаете от отказа от систем контроля версий?
6. CI/CD у вас, видимо, не используется? Автоматизация сборки?
7. Вы уверены, что ваши практики лучше общепринятых в разработке? Как вы думаете, что скажет хороший опытный разработчик, который, предположим, к вам на работу устраивается, когда узнает, что внутри вашей организации практики управления кодом, являющиеся стандартом де-факто, не приняты, и у вас своя система правил?
Собственно, наличие СКВ — это всего лишь первый шаг к профессиональной разработке. Вы, пока что, не сделали и его.
команде СКВ не нужны.
Ни разу этого не сказал.
Я полагаю, что вы меня недопоняли. Я абсолютно не против СКВ, если команде/заказчику это нужно. Но нюансами я голову себе не забиваю, это всего лишь инструмент, к тому же не все используют гит.
Сам же я для своих проектов СКВ не использую, нет в том необходимости. Практически вся кодовая база двигается исключительно в сторону наращивания функционала.
Взаимодействие с другими разработчиками в рамках таких проектов как правило ограничивается разработкой модулей. Но на крайний случай есть репозиторий.
Для собрки написана пачка скриптов. Развертывается силами IDE на мой сервер.
Собственно, наличие СКВ — это всего лишь первый шаг к профессиональной разработке. Вы, пока что, не сделали и его.
Знаете, многовато пафоса в мире, где практически все пишут по принципу «херак херак и в продакшен». Я правда верю, что где то есть мир с тестами, оптимальным кодом и прочими поэтессами. Но почему то что ни просят доработать, какой продукт не возьми, везде какой-то бред происходит.
Я абсолютно не против СКВ, если команде/заказчику это нужно.
Нет никаких «если». Профессиональной команде нужно.
Сам же я для своих проектов СКВ не использую, нет в том необходимости.
Т.е. ваши проекты — это ваши проекты, вы их разрабатываете, и к команде это отношения не имеет? Т.е. вы не работаете в команде?
Практически вся кодовая база двигается исключительно в сторону наращивания функционала.
Из «админского»…
Сисадмины делятся на 2 категории:
1. Те, которые еще не делают бэкапов.
2. Те, которые уже делают.
Так же и у разработчиков с СКВ.
Взаимодействие с другими разработчиками в рамках таких проектов как правило ограничивается разработкой модулей.
Т.е. командной работы над общим проектом нет.
Но на крайний случай есть репозиторий.
А это в каком виде?
Для собрки написана пачка скриптов.
Тоже весьма «характерно».
Развертывается силами IDE на мой сервер.
Фееричный продакш-подход для хайлоад энтерпрайз-приложений.
Знаете, многовато пафоса в мире, где практически все пишут по принципу «херак херак и в продакшен».
Вы судите по себе.
Я правда верю, что где то есть мир с тестами, оптимальным кодом и прочими поэтессами.
Но, очевидно, абсолютно туда не стремитесь.
Но почему то что ни просят доработать, какой продукт не возьми, везде какой-то бред происходит.
Вы просто не сталкивались с серьезными крупными проектами. В них происходящий бред, хотя бы, тестами покрыт, и, в целях «расследования инцидента», можно историю коммитов посмотреть.
Нет никаких «если». Профессиональной команде нужно.
Это не моего ума дело до тех пор пока я не тим лид.
Т.е. ваши проекты — это ваши проекты, вы их разрабатываете, и к команде это отношения не имеет? Т.е. вы не работаете в команде?
Над своими? Я уже описал, что бывает заказываю модули. Вот новый скоро будет уже в команде, размеры там эпические.
Сисадмины делятся на 2 категории:
1. Те, которые еще не делают бэкапов.
2. Те, которые уже делают.
Моя кодовая база существует меня на машине, в архивах релизных версий на файлохранилище, на сервере и в виде инкрементальных бекапов вместе со всей системой.
А это в каком виде?
В виде гит репозитория.
Тоже весьма «характерно».
Характерно что, скрипты собирающие css/js? Не понял в чем суть.
Фееричный продакш-подход для хайлоад энтерпрайз-приложений.
Вы толи читать не умеете, толи как… Есть регламенты у конкретных заказчивков — они соблюдаются. Я вам рассказываю как я делаю у себя. И да кстати ентерпрайз. А хайлоад, я вас умоляю. Яж не яндекс какой нить. Откуда кстати резко у всех вдруг хайлоад?
Вы судите по себе.
Да что вы говорите. Я вижу сколько мне головняков доставлает мегаплан, amocrm и прочие и прочие. К тому же я часто общаюсь вынужденно со всевозмоными веб студиями. Ох да я до утра могу перлы рассказывать.
Но, очевидно, абсолютно туда не стремитесь.
Если туда, это в мир, где мне придеться каждый день вот а таком ключе общаться? Нет не стремлюсь. Я стремлюсь туда где два разработчика могут посидеть за чашечкой и поделиться опытом невзирая на пол/возраст/рассу и прочую хрень вместо унылого тыкания друг друга моськой в свое болото.
Вы просто не сталкивались с серьезными крупными проектами. В них происходящий бред, хотя бы, тестами покрыт, и, в целях «расследования инцидента», можно историю коммитов посмотреть.
Смешная шутка. Особенно про тесты. Я всегда вспоминаю такие фразы когда по 2 месяца доказываю очередному CTO 'крупного проекта' что я не осел. И что характерно ниразу не был не прав пока.
Кстати а примерчик «крупного проекта» можно?
Вот новый скоро будет уже в команде, размеры там эпические.
Критерий «эпических размеров» можно?
Моя кодовая база существует меня на машине, в архивах релизных версий на файлохранилище, на сервере и в виде инкрементальных бекапов вместе со всей системой.
Т.е. вы проблему контроля версий решаете средствами бэкапов. А, ок…
Я вам рассказываю как я делаю у себя.
Красиво перефразированное «у меня все работает», ага.
И да кстати ентерпрайз.
Ручной деплой средствами IDE в прод, простите, энтерпрайз? А кроме локалхост-окружений что-нибудь деплоите?
Я вижу сколько мне головняков доставлает мегаплан, amocrm и прочие и прочие.
И что из этого, простите, относится к категории «системы контроля версий»? С какого перепугу CRM вообще вдруг нарисовались в контексте обсуждения систем контроля версий?
К тому же я часто общаюсь вынужденно со всевозмоными веб студиями. Ох да я до утра могу перлы рассказывать.
А это какое отношение к СКВ имеет?
Смешная шутка. Особенно про тесты.
Ну, т.е. «я не видел проектов с тестами, значит они не нужны» и «я не понимаю, зачем мне системы контроля версий, но я офигенный профессиональный разработчик».
А какой смысл вы, например, вкладываете в термин «профессиональный разработчик»? И особенно в контексте «чем профессиональный разработчик отличается от талантливого энтузиаста»?
Смешная шутка
В каком месте? Как вы отслеживаете изменения и их причины спустя время? Как вы работаете совместно над одним модулем?
Шутка относиться не к СКВ а к сферическим «большим» проектам. Я просто постоянно вижу как крупные сервисы с релизом новой версии ломают работу своих пользователей на дни/недели/месяцы, молчу о багах, которые висят годами.
Причины мне отслеживать не нужно, я просто помню все что написал. А вместе над одним модулем вне регламентов заказчика/работодателя только собираюсь. Отчасти потому что модуля достаточно маленькие и самодостаточные, но время пришло им стать одним большим приложением.
Причины мне отслеживать не нужно, я просто помню все что написал. А вместе над одним модулем вне регламентов заказчика/работодателя только собираюсь. Отчасти потому что модуля достаточно маленькие и самодостаточные, но время пришло им стать одним большим приложением.
Причины мне отслеживать не нужно, я просто помню все что написал.
Не, так не пойдет, это читерство. Мы тут про нормальных людей, а не про обладателей феноменальной памяти.
Причины мне отслеживать не нужно, я просто помню все что написал
Это, конечно, мое личное дело, но я не верю. При постоянной работе, если впроекте миллионы строк, ты уже через неделю забываешь конкретику, переключаясь на другие задачи.
А вместе над одним модулем вне регламентов заказчика/работодателя только собираюсь.
Ну так представьте, что у вас бибилиотечный модуль с «подсобными» функциями. Вы в этот модуль добавляете функцию, а ваш коллега правит или удаляет существующую. Вам надо ваши действия координировать. СКВ это позволяет.
Это, конечно, мое личное дело, но я не верю.
Вы правы и разубеждать мне лениво. Хотя ради проверки себя вот сейчась метнулся в единственное место где у меня есть дебильный комментарий, не используя поиск и окинул взглядом всю функцию на предмет вопросов. Нет, вопросов нет. Писалось лет 9 назад.
//xpath magic
var result = document.evaluate("tbody/tr[not(contains(translate(., '"+search.toUpperCase()+"', '"+search+"'), '"+search+"'))]",
tableObj,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null);
Красиво и лаконично, ведь правда?) Это элегантное, трудночитаемое решение довольно эффективно, но если не помнишь что это быстро понять достаточно сложно.
UPD: блин чето вывернуло блок омерзительно тут 8(
Пока это писал вспомнил что куда то сбежал модуль, расставляющий автоматически ссылки на манер вики, а потом вспомнил еще штук 10 клевых штук который надо бы чуть подпилить наверное, столько лет прошло.
СКВ это позволяет.
Я в курсе. Но опять же это не объясняет ниразу священный ужас который случае когда я говорю что сам СКВ не использую, как и не объясняет почему я наизусть должен помнить синтаксис команд каждой СКВ.
Конечно, рад за вас, и охотно верю, что вы наизусть помните весь свой код… что можно объяснить либо тем, что у вас феноменальная память, либо тем, что вашего кода недостаточно много для того, чтобы вы начали его забывать (ну, либо вы привираете, но тут уж настаивать не буду).
Теперь вспомним, что на собеседованиях, где спрашивают знание гита, вас, предположительно, берут в команду разработки. Состоящую не сплошь из одних уникумов. И для них ценны такие вещи, как история изменений, возможность отката на предыдущие состояния, возможность код-ревью (которое служит не только средством контроля качества кода, но и отличным учебным руководством для «подрастающих профессионалов»).
Но нет, настоящий профессионал выше устоявшегося командного инструментария… Хотя, погодите, может быть, таки не профессионал… Гениальный любитель?
Теперь вспомним, что на собеседованиях, где спрашивают знание гита, вас, предположительно, берут в команду разработки. Состоящую не сплошь из одних уникумов. И для них ценны такие вещи, как история изменений, возможность отката на предыдущие состояния, возможность код-ревью (которое служит не только средством контроля качества кода, но и отличным учебным руководством для «подрастающих профессионалов»).
Но нет, настоящий профессионал выше устоявшегося командного инструментария… Хотя, погодите, может быть, таки не профессионал… Гениальный любитель?
Гениальный любитель?
Да как вам будет угодно. Про команды я уже 10 раз все сказал, повторяться не вижу смысла.
что у вас феноменальная память
На код, еще фильмы хорошие помню практически посекундно. Есть конечно и обратные стороны, например даты не способен помнить хоть скольконибудь долго
Про команды я уже 10 раз все сказал, повторяться не вижу смысла.
Ну да, про команды вы сказали… Что СКВ там не нужны, даже вредны. Даже в качестве примеры amocrm упомянули.
На код, еще фильмы хорошие помню практически посекундно. Есть конечно и обратные стороны, например даты не способен помнить хоть скольконибудь долго
А в вашей команде, простите, все такие уникумы? С настолько идеальной памятью, что СКВ и им не нужны?
Ну да, про команды вы сказали… Что СКВ там не нужны, даже вредны. Даже в качестве примеры amocrm упомянули.
Можно мне цитаткой? А то как то даже забавно, учитывая что в каждом посте у меня написано обратное 8)
Amocrm и мегаплан вам приведены как «большие хайлоад проекты» которые по идее должны быть обожены тестами и все такое, а на практике устраивают такой лютый головняк своим пользователем, что хоть вешайся.
А в вашей команде, простите, все такие уникумы? С настолько идеальной памятью, что СКВ и им не нужны?
Что такое наша команда? В данный момент я разработкой занимаюсь сугубо сольно, а по работе CTO
ЗЫ кстати я вот заметил что вы на бекапы напираете. А не расскажите ка вы бекапите БД, как часто загружаете бекапы для проверки и чем контролируете?
Можно мне цитаткой? А то как то даже забавно, учитывая что в каждом посте у меня написано обратное 8)
Окей, перечитал, прямо такого вы не утверждали. Однако негодование по поводу того, что у вас спросили знание git'а на собеседовании вы проявили. И по поводу того, что без умения пользования СКВ в командной разработке делать нечего вы тоже возмущались.
Amocrm и мегаплан вам приведены как «большие хайлоад проекты»
Обадва ни к хайлоаду, ни к большим проектам отношения, по сути, не имеют.
Что такое наша команда? В данный момент я разработкой занимаюсь сугубо сольно, а по работе CTO
При этом отрицаете, что опыта командной разработки у вас нет. Ну ок.
ЗЫ кстати я вот заметил что вы на бекапы напираете.
Что-то вы неверно заметили. Я «напираю» на то, что использовать средства бекапа в качестве замены СКВ — так себе идея.
А не расскажите ка вы бекапите БД, как часто загружаете бекапы для проверки и чем контролируете?
Отчего же не рассказать, расскажу. Лично я — никак не бекаплю БД, загружаю дампы исключительно в целях тестирования приложеня и никак не контролирую. Я разработчик, не администратор СУБД.
Окей, перечитал, прямо такого вы не утверждали. Однако негодование по поводу того, что у вас спросили знание git'а на собеседовании вы проявили. И по поводу того, что без умения пользования СКВ в командной разработке делать нечего вы тоже возмущались.
Спросили? Нет. Иначе я бы подробно объяснил суть. Но вот когда интервьюер начинается аж захлебываться от ужаса… Причем последний раз речь шла о SVN.
Что-то вы неверно заметили. Я «напираю» на то, что использовать средства бекапа в качестве замены СКВ — так себе идея.
Замены? Зачем? Вы упомянули бекапы, я говорю что сервак один черт бекапиться.
Отчего же не рассказать, расскажу. Лично я — никак не бекаплю БД, загружаю дампы исключительно в целях тестирования приложеня и никак не контролирую. Я разработчик, не администратор СУБД.
Но как же, это же основы! А бд к СКВ у вас чем прибита? Слуушайте, а как у вас дела с параметризованными запросами?)
Но вот когда интервьюер начинается аж захлебываться от ужаса… Причем последний раз речь шла о SVN.
Ну вот ему нужен разработчик с уверенным знанием SVN. Хочет — берет, хочет — захлебывается от ужаса. К чему ваше-то недовольство?
Замены? Зачем? Вы упомянули бекапы, я говорю что сервак один черт бекапиться.
Вы же сказали, что предыдущие версии вашего продукта есть в бекапах, в инкрементальных бекапах, в роллинг-бекапах, в куче других бекапов, а также, если уж совсем все плохо, в бекапах сервера. Ну вот это хреновая система версионирования, честно-честно, и не я один так считаю. Бекапы отдельно, версии отдельно. Разные задачи = разные инструменты.
Но как же, это же основы!
Основы, простите, чего?
А бд к СКВ у вас чем прибита?
Из того, что делал — хранил миграции в СКВ, хранил диффы схемы, юзал ОРМ, умеющие в миграцию. Из того, что делаю сейчас… В 90% случаев с БД не работаю напрямую, чаще мидлварь. Приложения, например, разные бывают.
Слуушайте, а как у вас дела с параметризованными запросами?
У меня — все отлично, а у вас с ними что-то не так?
Ну вот ему нужен разработчик с уверенным знанием SVN. Хочет — берет, хочет — захлебывается от ужаса. К чему ваше-то недовольство?
Адекватный ответ «Вы знаете, нам нужен разработчик с уверенным знанием SVN. Вы бы не могли быстренько изучить, либо вы нам не подходите»
Неадекватный ответ «Как так? Это же базовые вещи! О чем вообще с вами можно разговаривать?»
Бекапы отдельно, версии отдельно.
В моих личных продуктах мне версии безинтересны.
Основы, простите, чего?
Вот о чем примерно и речь.
У меня — все отлично, а у вас с ними что-то не так?
И насколько отлично, используете prepared?
Адекватный ответ «Вы знаете, нам нужен разработчик с уверенным знанием SVN. Вы бы не могли быстренько изучить, либо вы нам не подходите»
Неадекватный ответ «Как так? Это же базовые вещи! О чем вообще с вами можно разговаривать?»
Это собеседование
В моих личных продуктах мне версии безинтересны.
В личных — никто вам не запрещает, и даже осуждать никто не собирается. Но если вы позиционируете себя как профессионального командного разработчика — «будьте добры соответствовать».
И насколько отлично, используете prepared?
prepared sql queries, я так понимаю?
Смотрите, у меня 3 проекта:
1. Основной, за который мне платят деньги. Там не использую, данными рулит другая команда, у меня есть api (версионированное, естественно)
2. В целях поизучать экосистему — вполне себе C# проектик — не использую, т.к. собственно есть entity framework.
3. В целях разовых подработок — немножко вебни, немножко мобильных мелочей, чуточку веб-бекенда. На бэке — Go, там использую. В таких масштабах версионирую базу скриптами миграций, prepared statements, естественно, использую. Но не на всех проектах.
И, как это относится к сути, собственно, вопроса?
Это собеседование, детка! Субьективно вы не понравились потенциальному начальнику, а он лично твердо уверен, что без SVN никуда. Собеседование прошло результативно с обоих сторон: он сэкономил время (не взяв вас на работу), вы тоже (не устроившись в место, которое вам не подходит). В чем причина недовольства?
В том же в чем и у вавторов 100500 таких статей. Нет желания выходить оплеванным.
И, как это относится к сути, собственно, вопроса?
В данном случае — никак.
Ну вот ему нужен разработчик с уверенным знанием SVN.
Субьективно вы не понравились потенциальному начальнику, а он лично твердо уверен, что без SVN никуда. Собеседование прошло результативно с обоих сторон
Ну вот ему нужен разработчик с рыжими волосами. Хочет — берет, хочет — захлебывается от ужаса. К чему ваше-то недовольство? Субьективно вы не понравились потенциальному начальнику, а он лично твердо уверен, что без рыжей шевелюры никуда. Собеседование прошло результативно с обоих сторон: он сэкономил время (не взяв вас на работу), вы тоже (не устроившись в место, которое вам не подходит).
Знаете как это называется?
Ну, например во многих местах (я не про ИТ, хотя и про него возможно) например людей с тату и/или пирсингом предпочитают не брать. Или требуют соблюдать дресскод. Где то слышал и волосы красить заставляют.
Знаете как это называется?
Знаю: «собеседование».
Это называется дискриминация. Я думал про негров написать, но решил что не стоит, и так понятно.
Вот зря про негров не написали, особенно показательный пример. Дискриминация первична. В конце концов, когда сперматозоид оплодотворял яйцеклетку, из который сформировались вы, это было вопиющим воплощением дискриминации по скоростному признаку в отношении тысяч и тысяч других сперматозоидов. А про всеобщее равенство — это вы в книжках читайте. Соответствующие труды должны на полке быть где-то между описанием физиологии розовых единорогов и историческими свидетельствами о выдающихся людях, какавших бабочками.
Собственно, прием на работу как таковой — яркий пример дискриминации по профессиональному признаку.
Собственно, прием на работу как таковой — яркий пример дискриминации по профессиональному признаку.
Умение пользоваться инструментами — объективная потребность, это не дискриминация.
Ага. Дискриминация это «субьективно вы не понравились потенциальному начальнику». Если инструмент используется на работе — то объективная потребность, если он нравится начальнику, но не используется и не планируется — субъективные предпочтения.
Да снимите уже розовые очки. В рамках собеседования невозможно объективно определить уровень кандидата.
Конторе объективно нужен сотрудник, соответствующий набору критериев, определяемый самой организацией. Конторе не нужен «крутой кодер», ей нужен сотрудник, выполняющий поставленные задачи. Тчк.
Прийди ко мне на собеседование Герб Саттер — я его просто не возьму. Я объективно не знаю, чем занять разработчика такого уровня. И мне по барабану, что круче него только горы, если я не могу и не умею применять его навыки. Я просто потрачу его и свое время. Ну и нафейхоа?
Конторе объективно нужен сотрудник, соответствующий набору критериев, определяемый самой организацией. Конторе не нужен «крутой кодер», ей нужен сотрудник, выполняющий поставленные задачи. Тчк.
Прийди ко мне на собеседование Герб Саттер — я его просто не возьму. Я объективно не знаю, чем занять разработчика такого уровня. И мне по барабану, что круче него только горы, если я не могу и не умею применять его навыки. Я просто потрачу его и свое время. Ну и нафейхоа?
Цвет кожи и наличие члена — это объективные различия, это тоже не дискриминация.
Однако негодование по поводу того, что у вас спросили знание git'а на собеседовании вы проявили.
Я думаю, тут следует определиться, что подразумевается под "знанием гита". Ведь, давайте будем честными — 99% кейзов использования гита с лихвой покрывается буквально полудесятком команд. При чем обычно можно даже не знать какие-то специфичные особенности их применения. Принципы работы гита и связанные с этим вещи — тоже знать не надо.
Иногда (раз в месяц-два) требуется что-то специфичное, но это решается обычно десятиминутным гуглением, т.о. инвестировать время в "изучение гита" (или любой другой СКВ) — какая-то глупая затея, тем более что без практики все из головы один черт выветрится.
С-но, если задают вопрос: "ну вы с гитом работали?" — это одно, а если начинают долбить по знанию конкретных команд — я бы счел это странным.
Ведь, давайте будем честными — 99% кейзов использования гита с лихвой покрывается буквально полудесятком команд. При чем обычно можно даже не знать какие-то специфичные особенности их применения.
Ну да, и сложного в запоминании 3-4 ключевых практик при регулярном использовании я ничего не вижу.
Принципы работы гита и связанные с этим вещи — тоже знать не надо.
Вот собственно, базовые принципы лучше все-таки знать. Нормальный разраб, все таки, не для того нанимается на работу, чтобы повторять набор рутинных действий по бумажке, не вдаваясь в детали происходящего. Для этого есть другие, менее высокооплачиваемые должности. «Оператор ЭВМ», например.
т.о. инвестировать время в «изучение гита» (или любой другой СКВ) — какая-то глупая затея, тем более что без практики все из головы один черт выветрится.
А что вы понимаете под изучением гита? Ну и собственно «изучением технологии». Инструкцию прочитал и все, профессионал? Изучение предполагает практику применения, например. Оно тем от зазубривания и отличается.
Т.е. вы либо гит применяете, и тогда вы его «изучили», либо нет — и тогда вы его не изучили. Собственно, реальных часто используемых команд в гите не так и много. Понимание того, как и зачем их применять, приходит значительно дольше, чем запоминание ключевых слов.
С-но, если задают вопрос: «ну вы с гитом работали?» — это одно, а если начинают долбить по знанию конкретных команд — я бы счел это странным.
Ну вот задали соискателю вопрос: «С гитом работали?» Он, естественно, не моргнув глазом: «Канэээшна!». И? Это о чем-то сказало, проверили скилл? Замените в этом вопросе гит на любую другую технологию, и ничего не изменится. Придумайте правдоподобное название несуществующей технологии и спросите об опыте работы с ней в полусотне собеседований. Вот реально половина соискателей будет знакома с технологией, и даже найдется пара-тройка профессионалов с многолетней практикой применения той ереси, что вы придумали пять минут назад.
Ну и как быть? На слово верить? Тут хоть вопрос задан, и соискателю есть на что отвечать. «Я высокоуровневый разработчик, работаю в IDE и, честно говоря, ни разу не сталкивался с необходимостью ручками давать git-команды в консоли. В моей IDE для работы с гитом есть отличнейшие инструменты, вот, например, в диффе веток есть такая прикольная фича — реально удобнее, чем тысяча других инструментов, которые я пробовал. Сами попробуйте, оно реально экономит время на ревью. А если вы хотите о механиках гита поговорить, ну, давайте обсудим гит-флоу, с которым я привык работать, сравним с тем, что принято у вас, возможно, обменяться практиками». Вот это — это тоже ответ на вопрос «что делает команда git rebase и какие параметры в ней допустимы». Причем в ряде случаев хороший, даже лучше, чем список зазубренных команд.
Ну вот задали соискателю вопрос: «С гитом работали?» Он, естественно, не моргнув глазом: «Канэээшна!». И? Это о чем-то сказало, проверили скилл?
Если ответил "да" — значит работал, ведь по умолчанию предполагаем, что интервьюриуемый всегда говорит правду.
Ну и как быть? На слово верить?
Конечно. А как еще?
Вот это — это тоже ответ на вопрос
Ну это замечательно, когда такой ответ принимается, но ведь может и не приниматься.
Несколько лет назад один наш коллега вайпнул нам гит сервер потому что тоже думал что «изучение гита» глупая идея. Не, ну а чо там, думать что-то там, знать как там чо, не пушится — форснем. И зафорсил нам пустую репу вместо основной.
Не смертельная проблема, конечно, но какое-то количество времени потеряли, особенно человек на объекте, которому надо продукт развернуть посреди заводской пустоты, а он вместо этого видит репу с одним коммитом «ааааа test».
А ведь не дурак был коллега, просто тоже знал о рабочем инструменте комманды полдесятка комманд, и не имел ни малейшего желания узнать чуть больше.
Не смертельная проблема, конечно, но какое-то количество времени потеряли, особенно человек на объекте, которому надо продукт развернуть посреди заводской пустоты, а он вместо этого видит репу с одним коммитом «ааааа test».
А ведь не дурак был коллега, просто тоже знал о рабочем инструменте комманды полдесятка комманд, и не имел ни малейшего желания узнать чуть больше.
Вот что-то, а возможность выстрелить себе в ногу всем в голову — то, что от конкретно гита отвращает, право слово. Уж лучше мы по-старинке, с лоховскими централизированными репозиториями, где история не изменяется.
Т.е. вы таки не дочитали мануал до конца…
Разумеется, я всегда читаю в обратном порядке.
Ну тогда вы должны были видеть, что такое pull request. А эта штука в комплекте с код-ревью решает проблему «какой-то… друг… случайно убил репу».
Проблема в том, что тогда должно быть выделено время на мейнтейн вот этого всего. Для маленьких комманд бывает гораздо проще дать всем полный доступ, потому что такие ошибки довольно редки все-таки.
У нас в команде 1 бек (я), 1 фронт и 1 техлид (на несоклько проектов). У нас есть ревью, которое часто помогает найти ошибки/предложить улучшения, которые не тратят время, доезжая до прода. «Проще дать всем полный доступ» звучит как анархия. До добра это не доводит.
Не вы ли там говорили, что предпочитаете инструменты, где отстрелить ногу нельзя? Тогда зачем сами даете заряженный пистолет ребенку?
Не вы ли там говорили, что предпочитаете инструменты, где отстрелить ногу нельзя? Тогда зачем сами даете заряженный пистолет ребенку?
Плюсы с лихвой перекрывают минусы. Например, когда ваш централизированный сервер упадет — а он обязательно упадет в самый неподходящий момент — вы останетесь совсем без истории.
Backup'ы. Какая-то небольшая часть потеряется, не более.
UFO just landed and posted this here
Сделайте protected branch и стрелять не придется. То, что у коллег любой человек мог затереть основную репу говорит только о том, что они не до конца изучили возможности инструмента.
Это вечный холивор, аналогичный таковому с ЯП — одни говорят «ну и что, что язык допускает отстрел ноги, это программист виноват, у нас все работет»; другие топят за «пусть более кондово, зато стабильнее и надежнее». И та и та точка зрения имеет право на жизнь в определенной ситуации. Когда речь идет о потере кодовой базы, я предпочту инструмент, который в принципе не позволяет пользователю серьезно накосячить.
Это не вечный холивор, это стандартная практика. И я за 5 лет работы с гитом ни разу с описанной ситуацией не столкнулся ни в одной из 5 компаний, где мне довелось работать. Ну потому что пушить в мастер вообще может лишь один аккаунт, доступ к которому разблокируется при чрезвычайных ситуациях раз в год. Весь основной флоу через PR, которые абсолютно безопасны. Джун же который пушит в мастер с форсом это вообще что-то из разряда «удалил базу на проде». Вряд ли стоит выбирать СУБД по тому принципу, что там из коробки не даются права на удаление таблиц.
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
Это не вечный холивор, это стандартная практика.
«Стандатная практика» — это применяемый вами метод. Холивор — это о выборе метода. Разные категории, через «не» не противопоставляются.
Ну потому что пушить в мастер вообще может лишь один аккаунт,
На этом можно и закончить. Это абсолютно нереалистичное ограничение для моей команды.
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
Абсолютно верно — для ряда задач лучше ограниченный андроид.
git — это инструмент, который, в зависимости от того, как его используют, либо позволяет серьезно накосячить, либо не позволяет.
Посмотрите хотя бы на ядро линукса. Большой проект. Лет 20 уже на гите. И до сих пор ни разу никто не накосячил по-крупному. Вы же не думаете, надеюсь, что это от непогрешимости линукс-разрабов?
И не рассказывайте мне, пожалуйста, что существует какая-то СКВ, которая не позволяет при наличии полного доступа к серверу убить репозиторий.
Посмотрите хотя бы на ядро линукса. Большой проект. Лет 20 уже на гите. И до сих пор ни разу никто не накосячил по-крупному. Вы же не думаете, надеюсь, что это от непогрешимости линукс-разрабов?
И не рассказывайте мне, пожалуйста, что существует какая-то СКВ, которая не позволяет при наличии полного доступа к серверу убить репозиторий.
То что у нас не было deploy branch'a — да, поленились, отчасти, но еще и потому что так получается быстрее, чем выделять время на обработку пулл-реквестов
всем в голову
Простите, это как, если доступ к изменениям общей ветки только через пул-реквесты и код-ревью?
См. выше. Ревью — трата времени, как и ветки, и разграничения доступа. Ограничения на форс пуш в мастер — «нереалистичные требования для команды».
На этом действительно можно закончить.
На этом действительно можно закончить.
Ну если брать людей, которые не знают, что такое virtual и которые говорят, что пользоваться Гитом — фигня, то для такой команды это будет нереалистичными требованиями. Как и впринципе писать качественный код.
Это всё-равно, что нанять в качестве водителя человека, который пришел на собеседование пьяным, а потом жалеть, что современные машины слишком часто попадают в аварии, с лошадьми было лучше
Это всё-равно, что нанять в качестве водителя человека, который пришел на собеседование пьяным, а потом жалеть, что современные машины слишком часто попадают в аварии, с лошадьми было лучше
Из «админского»…
Сисадмины делятся на 2 категории:
1. Те, которые еще не делают бэкапов.
2. Те, которые уже делают.
Не забываем про:
3. те, кто уже проверяют, что из бэкапа можно восстановиться
UFO just landed and posted this here
У правильных программистов «кодовая база двигается исключительно в сторону наращивания функционала»! Потому что правильный программист пишет все с первого раза, без ошибок, и построенная им архитектура изначально настолько совершенна, что не требует рефакторинга даже в случае наращивания не предусмотренного заранее функционала (очевидно потому, что правильный программист его предусмотрел, на то он и правильный).
А вы, очевидно, просто любитель, которому до сих пор нужны версии, код ревью, рефакторинг и прочие любительские техники, недостойные настоящих программистов!
А вы, очевидно, просто любитель, которому до сих пор нужны версии, код ревью, рефакторинг и прочие любительские техники, недостойные настоящих программистов!
Самообразования ради, а в чем удобство для микропроектов? Только как хранилище?
UFO just landed and posted this here
Благодарю. Специфичные случаи, не довелось.
Ноут к тому же прям совсем не мое. Я люблю удобное кресло, хороший монитор, музычку или сериал фоном и самое главное удобная клава 8)
Ноут к тому же прям совсем не мое. Я люблю удобное кресло, хороший монитор, музычку или сериал фоном и самое главное удобная клава 8)
UFO just landed and posted this here
что вы зашли куда-то в тупик, и хочется вернуть всё взад и начать сначала?
В тупик? как правило нет. Как только дорастает до определенного уровня то начинаю серьезно переделывать. Иногда с нуля.
И СКВ освобождают от этакой скованности в экспериментах, вызванной страхом, что вернуться назад не получится.
Вот как раз такого страха не бывало
То есть у вас никогда не было ситуации, что лучше бы вы код не трогали, и все лучше откатить на момент «до»?
Минут 10 вспоминал, не помню такого в серьезных масштабах. А в мелких даже без СКВ IDE ведет историю изменений.
А у нас было пару раз, что велась разработка в течении пары месяцев и потом хоп, «текущую версию в утиль, откатывайтесь к прошлому релизу».
Но это именно командная разработка, поэтому просто к слову о разных ситуациях.
В соло-разработке и пет-проектах cvs удобен в случаях, когда проект уже функционирует и где-то крутится, да выполняет свою задачу.
Затем может возникнуть желание отрефакторить часть кода и весь этот рефакторинг просто выносится в отдельную ветку, т.к. он может идти не один день.
В чём же выгода? Выгода в том, что, если во время эксплуатации текущей работающей версии возникнет проблема, которая потребует небольших правок в коде, то всё, что потребуется от человека — переключиться на работающую ветку до рефакторинга, внести исправления и передеплоить, а затем продолжить рефакторинг без каких-либо проблем.
По крайней мере, именно в подобном ключе я применяю гит в своих пет-проектах. И так же, как удобное средство делиться своим кодом, т.к. всё, что нужно — запушить изменения в какой-нибудь github/bitbucket/gitlab и скинуть ссылку человеку.
Но это именно командная разработка, поэтому просто к слову о разных ситуациях.
В соло-разработке и пет-проектах cvs удобен в случаях, когда проект уже функционирует и где-то крутится, да выполняет свою задачу.
Затем может возникнуть желание отрефакторить часть кода и весь этот рефакторинг просто выносится в отдельную ветку, т.к. он может идти не один день.
В чём же выгода? Выгода в том, что, если во время эксплуатации текущей работающей версии возникнет проблема, которая потребует небольших правок в коде, то всё, что потребуется от человека — переключиться на работающую ветку до рефакторинга, внести исправления и передеплоить, а затем продолжить рефакторинг без каких-либо проблем.
По крайней мере, именно в подобном ключе я применяю гит в своих пет-проектах. И так же, как удобное средство делиться своим кодом, т.к. всё, что нужно — запушить изменения в какой-нибудь github/bitbucket/gitlab и скинуть ссылку человеку.
А у нас было пару раз, что велась разработка в течении пары месяцев и потом хоп, «текущую версию в утиль, откатывайтесь к прошлому релизу».
Но это именно командная разработка, поэтому просто к слову о разных ситуациях.
Да, целыми модулями, а пару раз весь проект выкидывали к чертям. Поэтому нынче я задаю вопрос «зачем?» до просветления. Оказалось что в 9 случаях из 10 люди не представляют себе ответ на этот вопрос, в какой форме его не задай.
И так же, как удобное средство делиться своим кодом, т.к. всё, что нужно — запушить изменения в какой-нибудь github/bitbucket/gitlab и скинуть ссылку человеку.
На больную мозоль наступили. Я постоянно думаю что надо бы с коллегами поделиться, выложитьв в свободный доступ особо клевые штуки. Но иногда побеждает лень, иногда стыд за не очень красивый код, а иногда жадность(я все же бабульку этим зарабатываю).
Да, целыми модулями, а пару раз весь проект выкидывали к чертям. Поэтому нынче я задаю вопрос «зачем?» до просветления.
В том и дело, что отсутствие СКВ превращает откат в настолько трудоемкий процесс, что вы вынуждены сравнивать затраты на откат с потерями от не-отката. А проблема «решена до нас».
Оказалось что в 9 случаях из 10 люди не представляют себе ответ на этот вопрос, в какой форме его не задай.
Не важно, в какой форме задавать. Есть продукт, который в текущем состоянии имеет регрессии/ведет себя не по спекам/в целом не удовлетворяет требованиям. Была предыдущая версия, которая в целом заказчика устраивала. Заказчик хочет рабочую систему здесь и сейчас, что обсуждать?
Я постоянно думаю что надо бы с коллегами поделиться, выложитьв в свободный доступ особо клевые штуки. Но иногда побеждает лень, иногда стыд за не очень красивый код, а иногда жадность(я все же бабульку этим зарабатываю).
Вы с коллегами по команде кодом не делитесь?
В том и дело, что отсутствие СКВ превращает откат в настолько трудоемкий процесс, что вы вынуждены сравнивать затраты на откат с потерями от не-отката. А проблема «решена до нас»
Есть такое дело.
Заказчик хочет рабочую систему здесь и сейчас, что обсуждать?
Разумность внедрения каких то фич. Очень часто «нам нужен вот такой то отчет», говорю «ок, какие задачи он должен решить?» и уже отчета то не нужно вдруг стало 8)
Естественно если я говорю о случаях когда я лично взаимодействую со своими заказчиками. Создание хорошего продукта это ведь вовсе не клепание всего что попросят.
Вы с коллегами по команде кодом не делитесь?
Это другое.
Это другое.
Делиться кодом с коллегами по команде удобнее в гите. Чесслово, я проверял. Просто попробуйте.
Коллеги, я чесслово в ужасе. Никто не читает на что отвечает?
Само собой разумеется.
Делиться кодом с коллегами по команде удобнее в гите. Чесслово, я проверял.
Само собой разумеется.
Эмм, и вы жмете ctrl+Z в трех десятках файлов которые успели поменять? У меня зачастую бывают такие ситуации, где надо откатить от получаса до пары дней работы. В последнее время все реже, но всё еще бывает.
Работать с гитом кроме того удобно хотя бы потому, что я могу с любого компьютера продолжить работу с того места, где закончил. Не говоря про ветки, где я пробую различные варианты, и если мне вдруг понадобится что-то применить, я не буду вспоминть, что я там навертел, а просто сделаю мерж соответствующей ветки.
Ну просто в качестве примера — вот у меня есть проект: https://github.com/Pzixel/Solidity.Roslyn. Я сделал первую версию, задеплоил. Сделал ветку nethereum, в которой начал добавлять усложенный код. Усложненный код потребовал зависимостей, из-за чего он не собирается на убунте (на котороый работает билд сервер). Я создал соответствующий issue в репозитории той зависимости, которая всё ломает. Пока я жду этого исправления, я понемногу модифицирую master-ветку. В итоге, пока я ждал исправления этого бага, я успел настроить CI, починить несколько багов и немного порефакторить код. При этом я не потерял никаких изменений, даже наоборот, бэкпортировал в мастер часть полезных изменений из nethereum ветки. В итоге я не блокируюсь из-за того, что моя зависимость сломана, т.к. я спокойно живу и редактирую ветку, где этой зависимости нет. Когда они её починят, я смержу соответствующий мастер в эту ветку и всё заработает на новой версии.
Как это делать без СКВ я не представляю. Надо наверное какие-то папочки держать типа "app_main", "app_new". Плюс я работаю как из дома, так и на работе (иногда), и из дома подруги. Как узел синхронизации гит тоже очень даже неплох.
То есть у вас никогда не было ситуации, что лучше бы вы код не трогали, и все лучше откатить на момент «до»?
Если в руках молоток — то все вокруг кажется гвоздями.
Используемые инструменты влияют на ментальную модель, если человек работал 10 лет без СКВ, то он к этому привыкает, и все варианты, которые бы использование СКВ предполагали — отсекаются на подсознательном уровне. И в итоге потом "никогда не приходило в голову, зачем это может понадобиться, фигня какая-то".
Не думаю. Тем более что с скв я работал регулярно. Хотя мысль интересная.
Когда не знаешь о молотке, забиваешь гвозди чем придется. И когда тебе говорят — чувак, смотри молотком удобней и быстрее, ты в ответ рассказываешь что так привык, забивать гвозди ладонью прикольней, не смотря на кровь и боль, а больше одного гвоздя в день забивать все равно не надо, глупости какие.
UFO just landed and posted this here
Тут главное в том, что это, по факту, ничего не стоит.
git init написал, сделал первый коммит, поправил gitignore и все (меньше 5 минут в совокупности). Может, потом оно не понадобится особо — так 5 минут и не жалко ведь.
Тестить фичи в ветках — бесценно.
Но почему то что ни просят доработать, какой продукт не возьми, везде какой-то бред происходит.
А вам не приходило в голову, что «если третий муж бьет по роже, то виновата рожа»? Может вас в этот мир просто не берут, потому что вы на этот мир смотрите свысока, или, возможно даже, вообще не понимаете как там что работает? Это я так, food for thought
А вам не приходило в голову, что «если третий муж бьет по роже, то виновата рожа»?
Ну во первых причем тут рожа, если например врубаешь slow_query_log и он за 5 минут заполняется сотней разных запросов?
А во вторых, согласитесь: если третий муж бьет по роже, то все таки третий муж мудак.
Может вас в этот мир просто не берут
Если он где то и есть то явно не в веб разработке. Или не в этом городе. Хотя опыт общения с крупными сервисами намекает…
вообще не понимаете как там что работает
Как правило, тривиально, на самом деле
Использование СКВ — стандарт отрасли. Если команда не использует СКВ, это значит, что они не могу совместно работать над одними участками кода, заменять друг друга, обозревать код друг друга (последние изменения) и т.д. Это сказывается на производительности и качестве кода.
Программист, сегодня отказывающийся от СКВ — это как бухгалтер, отказывающийся от ЭВМ, мол «мне на бумаге и счетах норм, я так привыкла. Зачем мне лично ваш компьютер?»
Программист, сегодня отказывающийся от СКВ — это как бухгалтер, отказывающийся от ЭВМ, мол «мне на бумаге и счетах норм, я так привыкла. Зачем мне лично ваш компьютер?»
Знаете, коллега, я фразу про скв использую как своего рода флажок. Все начинают сразу поливать жижей но никто толком неспособен объяснить зачем использовать СКВ соло-разработчику.
Поймите меня првильно, не понта ради а понимания для.
Поймите меня првильно, не понта ради а понимания для.
Ну, во-первых, те кто вас критикует выше, говорят о командной разработке.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии. Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии. Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Ну, во-первых, те кто вас критикует выше, говорят о командной разработке.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии.
Тут два момента. Я стараюсь, и с каждым годом все лучше. Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались. Ну и KISS.
Второй момент я просто помню все что написал. Могу забыть номер дома и день рождения супруги, но помню весь год за 15 лет.
Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Благодарю. Я подумаю над этим. Пока не приходилось.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Я понимаю вашу точку зрения, но. поскольку СКВ при командной разарботке — стандарт отрасли, стоит настаивать на его использовании независимо от мнения заказчика. Это вопрос профессиональной этики — не идти на поводу у клиента, если он заказывает откровенное г-но.
Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались.
Разумеется, это трезвый подход. Но каждую строчку не прокомментируешь, а подчас приходится добавлять какие-то граничные случаи или что-то подобное, назначение чего неочевидно. С коммитами хотя бы видно, в рамках какой задачи внесено то или иное изменение.
Это важно и для другого — допустим, вы применили в каком-то проекте решение специфической проблемы, но не помните в точности всего решения (допустим, оно объемное и/или разнесено по модулям, дописано частями в разное время и т.д.). Из СКВ мы можем извлечь diff'ами эти блоки и посмотреть на решение в целом.
Если вашим кодом кто-то пользуется кроме вас, надо держать как минимум две ветки — грязную dev для разработки и чистую для внешнего мира — вы же не будете напрямую править то, что есть у клиента? Если будете, и что-то сломается, надо будет срочно откатывать назад и т.д.
Это вопрос профессиональной этики — не идти на поводу у клиента, если он заказывает откровенное г-но.
Касаемо продуктов я всегда стараюсь так делать, но касаемо прочего, в тч инфрастуктуры… знаете я устал. Очень часто консультирую по инфрастуктуре как сторонний консультант и как CTO и практически всегда хозяива бизнеса предпочитают покласть на все и въехать в пенек побольше.
Я очень люблю возиться с БД и раньше часто брал заказы на оптимизацию/аудит, но перестал, потому как список рекомендаций не выполеняется никогда, говнокода становиться только больше и заказчик вовзращается с практически мертвым сервером, получая барьерные цены.
Первые 100 раз было еще хотя бы смешно. А теперь я лучше посижу и сделаю еще что нить работающее в десятки раз быстрее аналогов, но для себя, чем снова буду убеждать сделать правильно.
Еще практическое применение СКВ (косвенное): отслеживание трудных ошибок.
Если система собирается не на коленке, а централизовано, с сохранением версии, map файлов и build система сблокирована с СКВ, то мы получив пользовательскую ошибку (например, доступ к памяти по некорректному адресу, после чего программа рухнула), получаем стек вызовов перед ошибкой и конкретное место ошибки. Но чтобы понять, где именно она была, нужно иметь snapshot всей кодовой базы, которая использовалась именно для сборки вот этой конкретной версии. А там уже, зная по сути номер строки с ошибкой можно найти точное место в коде.
И это не зависит от того, командная ли разработка или одиночная.
Если система собирается не на коленке, а централизовано, с сохранением версии, map файлов и build система сблокирована с СКВ, то мы получив пользовательскую ошибку (например, доступ к памяти по некорректному адресу, после чего программа рухнула), получаем стек вызовов перед ошибкой и конкретное место ошибки. Но чтобы понять, где именно она была, нужно иметь snapshot всей кодовой базы, которая использовалась именно для сборки вот этой конкретной версии. А там уже, зная по сути номер строки с ошибкой можно найти точное место в коде.
И это не зависит от того, командная ли разработка или одиночная.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Да не заказчик этого требовать должен. СКВ — инструмент команды разработки. А заказчик — он продукт получать должен.
Вот что команда получает — это удобный инструмент.
Допустим, запилили вы новую фичу. Подходит к вам другой разраб и просит показать, как оно работает (вроде, нормальные подход внутри команды кодом делиться). А у вас проект на полсотни тысяч строк. И вы ему начинаете объяснять, где, в каких местах и какие куски кода смотреть. На пальцах. Вместо того, чтобы ткнуть в PR, содержащий конкретную реализацию конкретной фичи.
Тут два момента. Я стараюсь, и с каждым годом все лучше. Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались. Ну и KISS.
Вы стараетесь, но, видимо, всуе. Читаемость — вещь субъективная. И то, что лично вы отлично помните, как что работает в вашей собственной реализации, и где что искать, остальной команде ничего не дает.
Ну, собственно, про миллион наработанных поверх СКВ практик пока писать не будем, можно остановиться на этом. Просто в контексте командной разработки СКВ — «must have» штука, почему я и говорю, что с подходом «СКВ не нужны» ненужным в командной разработке становитесь уже вы.
Да не заказчик этого требовать должен
Стоит читать как работодатель.
Читаемость — вещь субъективная
Нет тут никакой субъективности. $lion->eat($pig); Ясно, кратко, понятно.
«СКВ не нужны» ненужным в командной разработке становитесь уже вы.
Учитывая что несмотря на все указания вы по прежнему не можете указать место где я это сказал разрезе командной работы, я очень рад что мой детектор работает как надо. Так что вопрос кто кому не нужен тут спорный.
Стоит читать как работодатель.
Стоит читать как «работодатель запрещает завести СКВ»?
Нет тут никакой субъективности. $lion->eat($pig); Ясно, кратко, понятно.
Вы вырожденный случай какой-то приводите. Добавьте сотню строчек снизу и столько же сверху — вуаля, уже не настолько читаемо?
К слову, к СКВ вполне можно линтер присобачить, чтобы стандарты кода контролировать, например.
Стоит читать как «работодатель запрещает завести СКВ»?
Стоит читать, если надо — используем.
Вы вырожденный случай какой-то приводите. Добавьте сотню строчек снизу и столько же сверху — вуаля, уже не настолько читаемо?
Это у вас один метод на 200 строк?
KISS
Это у вас один метод на 200 строк?
Это у меня реализация фичи, например, и длиннее может быть, да еще и размазанная по набору исходников.
Метод на 200 строк как раз согласуется с KISS, а вот нарушающее семантику дробление KISS противоречит :)
В данном случае применение KISS будет как: "не стоит выделять код в отдельный метод, если не можешь обосновать, зачем это должно быть сделано".
Поймите меня првильно, не понта ради а понимания для.
Ну вот вам не понта ради, вроде, достаточно весомый аргумент:
Предположим, есть у нас разработчик, одиночка, пишет для себя, хорошо пишет, и «не надо ему эти ваши новомодные СКВ». Да, в общем, пока он один в своем коде варится, и пусть его. Это его проекты, и его право.
А потом этот разработчик решает заняться разработкой «по-взрослому», с «возможностью профессионального роста», приходит в сложившуюся команду и… и смотрит на тот же git, как баран на новые ворота. И изучать его не хочет, а только ходит кругами по конторе и пытается убедить других разработчиков, что СКВ «нинужны» все эти ваши код-ревью, репозитории, системы сборки/деплоя — от лукавого, а на сервера и из IDE проект поразворачивать можно.
Ну либо его «бреют на входе», а он идет на хабр писать, какие работодатели плохие, задают сложные вопросы и каких-то гитов непонятных с него хотят.
что СКВ «нинужны» все эти ваши код-ревью, репозитории, системы сборки/деплоя
В чужой монастырь со своим уставом? Сильно.
Без сборки/деплоя кстати достаточно тяжко.
git, как баран на новые ворота.
Документацию в зубы.
Ну либо его «бреют на входе», а он идет на хабр писать, какие работодатели плохие, задают сложные вопросы и каких-то гитов непонятных с него хотят.
Ну вот если вот так общаются то да, конечно плохие. Я привык от работы получать удовольствие.
Без сборки/деплоя кстати достаточно тяжко
Для собрки написана пачка скриптов. Развертывается силами IDE на мой сервер.
Как эти два ваших высказывания коррелируют? В контексте «вы уж мне поверьте, как опытному в вопросе человеку, без сборки/деплоя тяжко»?
Документацию в зубы.
Работодатель не хочет платить вам за изучение инструмента, являющегося стандартом в отрасли. Он ищет разработчика, который этот инструмент уже знает, и имеет на это полное право.
Ну вот если вот так общаются то да, конечно плохие. Я привык от работы получать удовольствие.
Они не плохие, у них просто есть понимание того, что они хотят.
Как эти два ваших высказывания коррелируют?
А что с ними не так? gulp собирает все красиво, деплой настроен в IDE.
Работодатель не хочет платить вам за изучение инструмента
Такое ощущение что подцепить git к ide это задача уровня постройик коллайдера.
Они не плохие, у них просто есть понимание того, что они хотят.
Да если бы. Тогда бы два профессионала побеседовали по душам, выяснили предпочтения друг друга и разошлись или стали работать вместе.
Последний раз меня позвали вообще просто побеседовать и я так и не понял кого они искали, вроде архитектора РСУБД. Но спектр вопросов был такой, как будто левой рукой нужно администрировать сервера, правой проектировать базу, а ногами еще и заниматься разработкой.
А что с ними не так? gulp собирает все красиво, деплой настроен в IDE.
Локальная сборка на машине девелопера… «У меня все работает» — слышали же?
Доставка средствами IDE… У заказчика может быть другое IDE, например… Заказчик может заходить задеплоить на 500 серверов, например…
Такое ощущение что подцепить git к ide это задача уровня постройик коллайдера.
Ну вот собственно, задачка-то простенькая, и не напряжная. А профиты реально ощутимые. А вы не пользуетесь — это ли не повод подумать, «а почему»?
Да если бы. Тогда бы два профессионала побеседовали по душам, выяснили предпочтения друг друга и разошлись или стали работать вместе.
А если у одного из них уже есть работа, и платят ему, предположительно не за беседы?)))
Последний раз меня позвали вообще просто побеседовать и я так и не понял кого они искали, вроде архитектора РСУБД. Но спектр вопросов был такой, как будто левой рукой нужно администрировать сервера, правой проектировать базу, а ногами еще и заниматься разработкой.
Ну это классика. Только опера немного другая — про «и швец, и жнец, и на дуде игрец, недорого, без смс».
Локальная сборка на машине девелопера… «У меня все работает» — слышали же?
У проекта конфигурация в точности повторяет конфигурацию тестовой машины.
Доставка средствами IDE… У заказчика может быть другое IDE, например… Заказчик может заходить задеплоить на 500 серверов, например…
Значит буде мделать по требованиям заказчика. Проблем то.
Ну вот собственно, задачка-то простенькая, и не напряжная. А профиты реально ощутимые. А вы не пользуетесь — это ли не повод подумать, «а почему»?
Уже обсудили выше.
А если у одного из них уже есть работа, и платят ему, предположительно не за беседы?)))
а) не беседовать
б) вести себя как профессионал
Ну это классика. Только опера немного другая — про «и швец, и жнец, и на дуде игрец, недорого, без смс».
А вы говорите знает что хочет…
И по каждому аспекту обычно вопросы чуть ли от устройства ядра линуха и «это же основы!».
Очень редко можно услышать: вот у нас есть такая задача, под которую нам нужен «название должности», как бы вы могли в этом нам помочь?
У проекта конфигурация в точности повторяет конфигурацию тестовой машины.
Вот это, простите, фикция.
Значит буде мделать по требованиям заказчика. Проблем то.
На выходе получите по отдельному билд/деплой костылю на заказчика. Но ладно, это слабодоказуемо, просто «из практики».
У проекта конфигурация в точности повторяет конфигурацию тестовой машины.
"Свежо предание, но верится с трудом..."
«Свежо предание, но верится с трудом...»
А в чем проблема? php, java, pg в точности версию сопоставить?
А в чем проблема? php, java, pg в точности версию сопоставить?
Кхм, и сесть в лужу на регрессии системной библиотеки, установленном по соседству фреймворке или производительности сискола на другой версии ядра?
«УМВР» — это ровно этот случай.
Не знаю, как там у Вас в теории, а у нас на практике чуть ли не еженедельно имеем геморррой на работе, потому как конфигурация heroku-виртуалок, на которых продукт крутится, не в абсолютной точности соответствует конфигурации девелоперских машин. Как уже отмечали ниже — обычно виной системные библиотеки. Например, девелоперу в работе нужен какой-то продукт, его инсталляция притащила с собой тучу библиотек (зачастую непонятно почему), которые продукт прозрачно подхватил. Стали запускать на виртуалке — продукт падает ввиду отсутствия библиотек (и при этом не говорит, каких).
Работодатель не хочет платить вам за изучение инструмента, являющегося стандартом в отрасли.
Для изучения гита на уровне комфортной работы достаточно часа-двух, о чем вы вообще, ну?
Ну, собственно, если соискатель не нашел пары часов из 30 лет, прошедших перед собеседованием…
А если он при этом еще и утверждает, что «имеет богатый опыт командной разработки». И за весь «богатый опыт» тоже 2 часов не нашел? Или по религиозным соображениям не использует, и предыдущий работодатель, у которого он получал «богатый опыт», заставить не смог.
Или просто, может, врет про «богатый опыт»? Согласитесь, более вероятно. Есть, конечно, целые экосистемы, в которых гит не используется, там свои стандарты — но там и спрашивать, вероятно, стоит о знании местных стандартов.
Но в подавляющем количестве проектов разработки бал правит git, и «иметь богатый опыт разработки в различных командах» и при этом «не иметь опыта работы с гитом»… Такое себе… Либо врет, либо это именно тот случай, когда «10 лет опыта, но каждый из этих лет — первый».
А если он при этом еще и утверждает, что «имеет богатый опыт командной разработки». И за весь «богатый опыт» тоже 2 часов не нашел? Или по религиозным соображениям не использует, и предыдущий работодатель, у которого он получал «богатый опыт», заставить не смог.
Или просто, может, врет про «богатый опыт»? Согласитесь, более вероятно. Есть, конечно, целые экосистемы, в которых гит не используется, там свои стандарты — но там и спрашивать, вероятно, стоит о знании местных стандартов.
Но в подавляющем количестве проектов разработки бал правит git, и «иметь богатый опыт разработки в различных командах» и при этом «не иметь опыта работы с гитом»… Такое себе… Либо врет, либо это именно тот случай, когда «10 лет опыта, но каждый из этих лет — первый».
Серьезно? Несущественные моменты использования заурядного инструмента порождают такие размышления. Да еще с постоянным подозрением во вранье? И почему я могу сходу придумать как поговорить с разработчиком, чтобы развеять свои сомнения а вам так важен синтаксис команд.
Ну чтож: «вы мне не подходите».
Зы теперь я с еще бОльшим упорством буду говорить «не знаю» )
Ну чтож: «вы мне не подходите».
Зы теперь я с еще бОльшим упорством буду говорить «не знаю» )
Смотрите, бывают программисты и бывают разработчики. Программист — это такой человек, который умеет писать код, программировать. А есть разработчик — это человек, который умеет разрабатывать (предположительно, продукт, зачастую в команде, всегда в рамках каких-либо ограничений, налагаемых ТЗ, командной спецификой, стеком, принятыми практиками и экосистемой).
Обадва могут быть как хорошими, так и плохими, при этом прямой зависимости между этими двумя понятиями нет. Умение писать хороший качественный код характеризует вас как хорошего программиста и может считаться плюсом в характеристике вас как разработчика, но никак не может вас характеризовать как разработчика хорошего.
Разработчик, поверх умения кодить собственно, нуждается в навыках коммуникации, навыках самодисциплины и самоконтроля, навыках адекватной оценки задачи, навыках в работе с сопутствующими инструментами и в куче других, не связанных непосредственно с кодированием навыков.
То, что вы можете написать код несколько более качественный, чем условный Василий, делает вас более крутым программистом, но не делает вас автоматически более крутым разработчиком. Если код Василия укладывается в заданные рамки качества, а ваш, хоть и круче, но может оказаться слишком сложным для понимания Василиев в вашей команде — как разработчик этой команды вы хуже Василия. Если же ваш код не обладает избыточной сложностью, и вы оба с Василием «укладываетесь в критерии», но Василий уже знаком с практиками пулл-реквестов, код-ревью, и прочих «скрамов», принятых в команде — он опять лучше вас как разработчик, хоть и уступает вам как программист.
У вас есть четкие критерии существенности моментов использования и незаурядности инструментов? Вот язык программирования, собственно, тоже ведь абсолютно заурядный инструмент. Или нет? Разработка — это просто инженерная практика, в ней нет незаурядных инструментов, а несущественные моменты иногда приводят в, простите за прямоту, жопу.
Вы о чем на собеседовании вообще говорить собираетесь? Собеседующий не хочет вас подловить на знании спецтонкостей особого малоиспользуемого инструмента. Он спрашивает вас про гит, который известен чуть менее чем каждому второму зародышу програмиста в мире, и цель у него — просто понять, использовали ли вы гит на практике. А вы валитесь на завышенной самооценке и отсутствии коммуникативных навыков.
Да не нужен мне синтаксис команд, мне нужно увидеть, что ты ответишь. Высыпал набор определений в том порядке и в той формулировке, как оно описано в википедии — зазубрил, следующий. Объяснил своими словами — ну ок, беседуем, либо крепкий середнячок, либо «перегоревший», но суть понимает, и работать с этим можно. Сказал «я на практике эти вещи обычно делаю через (тут вставить название любимой вами лично хитрозаверченной жопы), поэтому тупо синтаксис в лоб не помню» — окей, выводим на разговор, пытаемся понять, кто перед нами, «ненужный нам фанатик», который будет с пеной у рта доказывать, что его единственный в мире инструмент лучше, или «вдумчивый специалист», с которым можно обсудить детали, прийти к взаимопониманию, и который, в случае надобности, сможет подождать обсуждения практик, и не будет раскачивать лодку.
Ну, а если человек вываливает «да это тривиальщина, я не буду это объяснять», «да я такой крутой специалист, что не обязан знать эти простые вещи» или «да я вам все это выучу быстрее, чем любой из ваших самых крутых спецов» — повод расстаться сразу. Это либо попытка скрыть ложь за агрессией, либо завышенная самооценка соискателя, что, по большому счету, монопенисуально плохо.
Понимаете, дело даже не в «ответил/не ответил», а в том, как вы это делаете.
Обадва могут быть как хорошими, так и плохими, при этом прямой зависимости между этими двумя понятиями нет. Умение писать хороший качественный код характеризует вас как хорошего программиста и может считаться плюсом в характеристике вас как разработчика, но никак не может вас характеризовать как разработчика хорошего.
Разработчик, поверх умения кодить собственно, нуждается в навыках коммуникации, навыках самодисциплины и самоконтроля, навыках адекватной оценки задачи, навыках в работе с сопутствующими инструментами и в куче других, не связанных непосредственно с кодированием навыков.
То, что вы можете написать код несколько более качественный, чем условный Василий, делает вас более крутым программистом, но не делает вас автоматически более крутым разработчиком. Если код Василия укладывается в заданные рамки качества, а ваш, хоть и круче, но может оказаться слишком сложным для понимания Василиев в вашей команде — как разработчик этой команды вы хуже Василия. Если же ваш код не обладает избыточной сложностью, и вы оба с Василием «укладываетесь в критерии», но Василий уже знаком с практиками пулл-реквестов, код-ревью, и прочих «скрамов», принятых в команде — он опять лучше вас как разработчик, хоть и уступает вам как программист.
Несущественные моменты использования заурядного инструмента порождают такие размышления.
У вас есть четкие критерии существенности моментов использования и незаурядности инструментов? Вот язык программирования, собственно, тоже ведь абсолютно заурядный инструмент. Или нет? Разработка — это просто инженерная практика, в ней нет незаурядных инструментов, а несущественные моменты иногда приводят в, простите за прямоту, жопу.
Вы о чем на собеседовании вообще говорить собираетесь? Собеседующий не хочет вас подловить на знании спецтонкостей особого малоиспользуемого инструмента. Он спрашивает вас про гит, который известен чуть менее чем каждому второму зародышу програмиста в мире, и цель у него — просто понять, использовали ли вы гит на практике. А вы валитесь на завышенной самооценке и отсутствии коммуникативных навыков.
И почему я могу сходу придумать как поговорить с разработчиком, чтобы развеять свои сомнения а вам так важен синтаксис команд.
Да не нужен мне синтаксис команд, мне нужно увидеть, что ты ответишь. Высыпал набор определений в том порядке и в той формулировке, как оно описано в википедии — зазубрил, следующий. Объяснил своими словами — ну ок, беседуем, либо крепкий середнячок, либо «перегоревший», но суть понимает, и работать с этим можно. Сказал «я на практике эти вещи обычно делаю через (тут вставить название любимой вами лично хитрозаверченной жопы), поэтому тупо синтаксис в лоб не помню» — окей, выводим на разговор, пытаемся понять, кто перед нами, «ненужный нам фанатик», который будет с пеной у рта доказывать, что его единственный в мире инструмент лучше, или «вдумчивый специалист», с которым можно обсудить детали, прийти к взаимопониманию, и который, в случае надобности, сможет подождать обсуждения практик, и не будет раскачивать лодку.
Ну, а если человек вываливает «да это тривиальщина, я не буду это объяснять», «да я такой крутой специалист, что не обязан знать эти простые вещи» или «да я вам все это выучу быстрее, чем любой из ваших самых крутых спецов» — повод расстаться сразу. Это либо попытка скрыть ложь за агрессией, либо завышенная самооценка соискателя, что, по большому счету, монопенисуально плохо.
Понимаете, дело даже не в «ответил/не ответил», а в том, как вы это делаете.
А вы валитесь на завышенной самооценке и отсутствии коммуникативных навыков.
Я? Нет. Я валюсь на шоке от агрессивности и хамстве коллег по цеху. Знаете, много раз в торговле учил людей обращать конфликт в свою сторону, но там понятен его исток. А вот исток напыщенности и пафоса на интервью мне не очевиден.
Понимаете, дело даже не в «ответил/не ответил», а в том, как вы это делаете.
Именно о том и речь.
Я? Нет. Я валюсь на шоке от агрессивности и хамстве коллег по цеху. Знаете, много раз в торговле учил людей обращать конфликт в свою сторону, но там понятен его исток. А вот исток напыщенности и пафоса на интервью мне не очевиден.
Вы негодуете, что вас спрашивают команды СКВ на интервью, и называете это агрессивностью, напыщенностью и хамством? А, ну… ок…
Именно о том и речь.
А что не так?
Вы негодуете, что вас спрашивают команды СКВ на интервью, и называете это агрессивностью, напыщенностью и хамством? А, ну… ок…
Спрашивать команды СКВ на собеседовании довольно странно. Я всегда работал с СКВ, начиная с VSS и потом ещё с 3мя-4мя разными. С Гитом работаю практически во всех ситуациях только из консольки. Но при этом не помню синтаксис команд. Зачем забивать голову? Есть история консоли для самых частых случаев, есть шпаргалка для более редких, и есть интернет для исключительных. Даже если представить, что попаду за новое рабочее место без интернета, то всё равно можно воспользоваться git help. Нормальный вопрос для собеседования — это спросить, какая модель ветвления использовалась на прошлых проектах. Хотя, по большей части, какая разница? Какая модель принята в организации-работодателе, по такой и будет работать разработчик. По опыту, даже те люди, которые никогда не пользовались СКВ, не имеют никаких трудностей в работе из-за этого. Ну покажет им более опытный сотрудник за 5 минут, что делать. И всё. А спрашивать команды, это примерно как у плотника спросить, какую кнопку нажимать на циркулярной пиле: красную или зелёную.
Спрашивать команды СКВ на собеседовании довольно странно.
Странно, на самом деле, соискателю указывать потенциальному работодателю на то, какие вопросы он имеет право задавать на собеседовании.
Вот реально. У обоих сторон собеседования — свои цели. У соискателя, предположительно, получить работу. У собеседующего — составить оценку того, соответствует ли специалист набору критериев, нужных работодателю.
И вот работодатель хочет проверить, имеет ли соискатель опыт работы с гитом. Ему это, по какой-то причине важно.
Он может спросить «имеете ли вы опыт работы с гитом». Окей, из 100 ответов 99 будут «да, конечно, дважды в день». И все они ничего не скажут о реальном навыке. Нужен, очевидно, вопрос, который сможет хоть как-то в чем-то удостовериться.
Он может составить список каверзных вопросов на проверку всех кейсов, где можно наступить на грабли. Отлично, теперь из 100 соискателей 99 не смогли ответить. О чем это говорит? Опять, ни о чем. Грабли есть везде и сам факт того, что соискатель не наступил «вот на эту конкретную», не свидетельствует о том, что он не пользовался инструментом. Да и не факт, что глубокие познания в специфике работы инструмента работодателю нужны, у него есть устоявшийся workflow, и он просто хочет удостовериться, что соискатель сможет посмотреть на описание принятой механики и начать действовать соответственно.
Остается подмножество простых вопросов, доступных даже неопытным специалистам, которые позавчера прочитали git basic howto. По крайней мере, знание этого базиса позволяет предположить, что соискатель по инструкции воспроизведет воркфлоу.
А дальше — это уже к соискателю вопрос, как он на вопрос реагирует. Если он не помнит конкретного ключевого слова, он ведь может это произнести. Просто взять и через рот произнести что-то вроде «Я это на память не помню, с гитом, как правило через IDE работаю, если хотите, можно обсудить принятые практики или могу нарисовать схему того, как мы с гитом работали в предыдущей команде».
Вот честно, вы же не на экзамене! У вас нет задачи «четко ответить на вопрос» и «если не ответил, о, ужас, меня отчислят и я пойду в армию». Как дети, чесслово!
У вас задача: убедить собеседующего, что вы умеете работать с инструментом (а не как в приколе про обязанности караульного «Услышав лай караульной собаки, передать четко и без изменений»).
Вы можете вкратце рассказать про принцип формирования веток, что-то еще примерно связанное (да-да, как в том анекдоте про «Но если бы у рыбы была шерсть, в ней обязательно завелись блохи. Итак, блоха — насекомое...»), да, блин, хоть гипнозом пользуйтесь, лишь бы собеседующий понял, что вы «в теме шарите».
Нет же, мы же обидчивые высококлассные специалисты, как в нас можно сомневаться? Вот список «разрешенных вопросов», а на остальные мы будем отвечать «конечно, я это знаю, но вам не скажу», говорить «я настолько крут, что выше этого» или будем, как тут некто уже излагал свою позицию «из принципа молчать».
Вы посмотрите, блин, какие мы нежные! Кто-то засомневался в нашей квалификации, а мы ответим им нашим молчаливым презрением или снисходительным отказом.
Да никто, нафиг, вашу квалификацию не проверяет! Невозможно это в рамках собеседования. На собеседовании тот, кто собеседует, составляет мнение о том, подходите ли вы под требования вакансии, ни больше ни меньше.
Странно, на самом деле, соискателю указывать потенциальному работодателю на то, какие вопросы он имеет право задавать на собеседовании.
Я здесь не соискатель, а вы не мой потенциальный работодатель. Поэтому не вижу ничего ненормального в том, чтобы обсудить вопросы с собеседований. В том числе их адекватность.
Остается подмножество простых вопросов, доступных даже неопытным специалистам, которые позавчера прочитали git basic howto. По крайней мере, знание этого базиса позволяет предположить, что соискатель по инструкции воспроизведет воркфлоу.
Ок. Но адекватный работодатель будет проверять другое. А если окажется, что соискатель подходит, но не знает git, то просто попросит прочитать «git basic howto» перед началом работы.
P.S. Как-то вы слишком эмоционально реагируете на моё вполне нейтральное сообщение.
Но адекватный работодатель будет проверять другое.
Абсолютно верно. Адекватный работодатель будет проверять другое: подходите ли вы ему как работник. Ни слова о квалификации или опыте, просто «подходите ли вы».
А если окажется, что соискатель подходит, но не знает git, то просто попросит прочитать «git basic howto» перед началом работы.
Не вижу ничего страшного в том, чтобы навскидку проверить утверждение о том, что соискатель что-то там знает.
Вот у нас есть товарищ, который с еще бОльшим упорством буду говорить «не знаю»
— Вы используете гит?
— Конечно, по три раза в день. (молодец какой).
— А что делает команда git reset?
— Не знаю. (мы помним, он из принципа это говорит, обиделся)
— А git commit?
— Не знаю. (все еще обижен)
— А git init?
— Не знаю (мы помним, он обиженка).
Вы на месте собеседующего какой бы вывод сделали? Что перед вами крутой специалист, который знает, но просто имеет причину не говорить? Или таки что он «несколько приукрасил свой скилл»?
Варианты можно даже поанализировать:
1. Он знает, но он «обиженка».
2. Он не знает (что, по сути, в случае с гитом не страшно), но решил скрыть этот факт от вас, солгав на собеседовании (а это уже сильно хуже).
И вот тут, честно говоря, совершенно не важно, обиделся соискатель, или просто врет. В обоих вариантах он не подходит.
Дело в том, что возможно, у нас просто разные цели. Я ищу комфортное место с интересными задачами а не формошлепную ферму. И когда CTO багровеет, покрывается пятнами и начинает хамить на таких простых моментах, ну… нам не по пути.
Хотите другой пример? Менее общий. Я ровно так же могу сказать «понятия не имею» по токностям работы журнала упреждающей записи postgresql, типам индексов и алогритмам объединений. И если случается нормальная беседа то:
1. Конечно вобщих чертах я знаю как работает WAL, но даже помнить о его существовании разработчику в общем то незачем
2.
— Как правило используется b-tree и только.
— hash индекс, за исключением случаев, когда создается самой базой, применять не стоило, во всяком случае до последнего времени, он порождал больше проблем, чем решал. Да и собственно быстрее он может быть только при поиске точного совпадения.
— GIST довольно редко используется, если вы не работаете с геоданными и интервалами
— GIN необходим если вы ищете частичное вхождение. В принципе gin_trgm_ops это то, что должен использовать вообще каждый если у вас есть поиск по справочникам.
— BRIN даже рассматривать не стоит если у вас не стоит задачи экономии дискового пространства.
UPD:
совсем забыл SP-GIST но я лично так и не придумал кудаб его приспособить, если не работать с геометрией.
Как видите, можно годами работать с postgresql и использовать только b-tree и этого в принципе достаточно. По идее это все таки работа архитектора бд, ибо за исключением построения триграмм (которым нужно возносить молитвы (хотя если у вас малый объем данных или нет частичного поиска, то необязательно)) все остальное важно когда есть большой объем данных и серьезная нагрузка.
Неплохо бы конечно помнить что у пг есть функциональные индексы, штука прям читерная, но фунция должна быть immutable.
Ну а алгоритмы объединения за пределами explain вам вообще помнить незачем, а внутри уже все очевидно. Да и названия у них говорящие. Перечислять по памяти, даже если кто помнит, бессмысленно, потому как еще важен объем данных, объем оперативной памяти, сложность запросов, актуальность статистики таблицы итд
Итого в общем случае, backend-разработчику нужно знать о том что индексы есть. Писать читаемые параметризованные запросы и радоваться жизни. В вебе я все чаще вижу бред, вроде фукнций в условии, без построения индекса по ней (а Mysql вроде и не умеет), искоренение такого куда более важно, за это нужно бить топором по пальцам.
Хотите другой пример? Менее общий. Я ровно так же могу сказать «понятия не имею» по токностям работы журнала упреждающей записи postgresql, типам индексов и алогритмам объединений. И если случается нормальная беседа то:
1. Конечно вобщих чертах я знаю как работает WAL, но даже помнить о его существовании разработчику в общем то незачем
2.
— Как правило используется b-tree и только.
— hash индекс, за исключением случаев, когда создается самой базой, применять не стоило, во всяком случае до последнего времени, он порождал больше проблем, чем решал. Да и собственно быстрее он может быть только при поиске точного совпадения.
— GIST довольно редко используется, если вы не работаете с геоданными и интервалами
— GIN необходим если вы ищете частичное вхождение. В принципе gin_trgm_ops это то, что должен использовать вообще каждый если у вас есть поиск по справочникам.
— BRIN даже рассматривать не стоит если у вас не стоит задачи экономии дискового пространства.
UPD:
совсем забыл SP-GIST но я лично так и не придумал кудаб его приспособить, если не работать с геометрией.
Как видите, можно годами работать с postgresql и использовать только b-tree и этого в принципе достаточно. По идее это все таки работа архитектора бд, ибо за исключением построения триграмм (которым нужно возносить молитвы (хотя если у вас малый объем данных или нет частичного поиска, то необязательно)) все остальное важно когда есть большой объем данных и серьезная нагрузка.
Неплохо бы конечно помнить что у пг есть функциональные индексы, штука прям читерная, но фунция должна быть immutable.
Ну а алгоритмы объединения за пределами explain вам вообще помнить незачем, а внутри уже все очевидно. Да и названия у них говорящие. Перечислять по памяти, даже если кто помнит, бессмысленно, потому как еще важен объем данных, объем оперативной памяти, сложность запросов, актуальность статистики таблицы итд
Итого в общем случае, backend-разработчику нужно знать о том что индексы есть. Писать читаемые параметризованные запросы и радоваться жизни. В вебе я все чаще вижу бред, вроде фукнций в условии, без построения индекса по ней (а Mysql вроде и не умеет), искоренение такого куда более важно, за это нужно бить топором по пальцам.
Просто когда нужно запушить изменения, а человек не знает, что это такое, то время теряется.
Любой навык можно получить за конечное время, вопрос в том, что у бизнеса этого времени как правило нет. Не джуна на обучение нанимаем вроде.
С одной стороны да. С другой, если на гит завязано много чего, то может и не подойти. Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Любой навык можно получить за конечное время, вопрос в том, что у бизнеса этого времени как правило нет. Не джуна на обучение нанимаем вроде.
Ок. Но адекватный работодатель будет проверять другое. А если окажется, что соискатель подходит, но не знает git, то просто попросит прочитать «git basic howto» перед началом работы.
С одной стороны да. С другой, если на гит завязано много чего, то может и не подойти. Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Хех, если система настолько сложная и custom'ная, то где этому соискатель научится — дома на пет-проектах?
Ну, я в пет-проектах вполне теггирование использую, потому что популярные CI движки вроде AppVeyor/Travis/CircleCi/… поддерживают деплой только тегированных сборок. А это весьма удобно для выкладывания своих домашних пакетов в npm/nuget/… предсказуемым образом.
Так что да, человек уже знает про гит, остается только ему дать информацию, что «вон ту штуку которую ты знаешь мы еще используем таким образом, а эту — таким». Это драматически уменьшает время на интеграцию в новый проект.
Так что да, человек уже знает про гит, остается только ему дать информацию, что «вон ту штуку которую ты знаешь мы еще используем таким образом, а эту — таким». Это драматически уменьшает время на интеграцию в новый проект.
позволю себе процитировать и себя и вас
а в том, как вы это делаете.
Зы теперь я с еще бОльшим упорством буду говорить «не знаю» )
Ну вот это больше всего характеризует вас как конфликтного человека с несколько завышенным самомнением. Не берем.
Вот на практике, и про мониторы спрашивали, и про размеры стола (конечно не про толщину, а про длину/ширину). И не поверите, даже про уровень CO один раз спрашивали. У нас в предыдущем офисе даже прибор был, который что-то мерил, помню какие-то циферки показывал ~500-900 вроде. Ну и надо проще относиться к таким вопросам я считаю, если для кого-то это так важно. Как собственно и кандидату надо проще относиться к вопросам, которые для себя считает важным работодатель.
Я когда работал коммерческим у меня был большой стол с толстой столешницей. Особенность в том, что можно стучать, ставить нечто, шатать, облакачивацо а монитор даже не шевелицо. А вот CO на самом деле очень важно, потому как я встречал и не раз офисе где работать невозможно. Даже хуже того, наступает поздний вечер и в офисе начинаешь вырубаться.
Я как то работал в маленьком офисе где вентиляции нет. Сначала не очень понятно было почему когда выходишь покурить в глазах светлеен не порядок, а потом когда все под вечер вырубаться начали — дошло. Работал так же рядом с химзаводом, незнаю есть ли связь, но сидел я рядом с открытым окном и в какой-то момент просто аж на стол падал. Думал не высыпался, но выходил, садился за руль, и по пути начинал себя подрячком чуять без намека на желание спать.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Я как то работал в маленьком офисе где вентиляции нет. Сначала не очень понятно было почему когда выходишь покурить в глазах светлеен не порядок, а потом когда все под вечер вырубаться начали — дошло. Работал так же рядом с химзаводом, незнаю есть ли связь, но сидел я рядом с открытым окном и в какой-то момент просто аж на стол падал. Думал не высыпался, но выходил, садился за руль, и по пути начинал себя подрячком чуять без намека на желание спать.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Я вот даже если понял, что кандидата буду сливать, никогда не прекращаю интервью сразу, конечно часть вопросов уже долгих пропускаю, но о компании рассказываю по полной. Т.е. установка такая, что кандидат, даже если нам не подошёл, должен уйти довольный.
Так собеседование — это форма экзамена. Что удивительного? Работодатель проверяет соискателя, тот проверяет условия работы, работодателя. Это два разных процесса. Сошлись оба в оценке друг друга — контракт заключен.
это форма экзамена
В таком случае, вероятно, студенты, вызубрившие справочник — лучшие программисты?
Я кстати напомню, что даже гугл признал, что понятия не имеет как правильно собеседовать. Где то встречал даже статью об околонулевой корреляции успешного собеседования с качеством работы сотрудника.
мда, вроде и знаю что такое virtual и даже иногда использую в коде.
Но вот честно, на внезапный вопрос что такое virtual, я наверно даже через минуту не отвечу правильным определением. А это значит провал собеседования. Это значит что любой джуниор сразу после универа будет выглядеть круче меня… на собеседованиях.
Но вот честно, на внезапный вопрос что такое virtual, я наверно даже через минуту не отвечу правильным определением. А это значит провал собеседования. Это значит что любой джуниор сразу после универа будет выглядеть круче меня… на собеседованиях.
И да — теперь, пока за мной не будет стоять мой код, на собес я не пойду.
Можете раскрыть мысль?
Тестовое. Я написал код, я могу доказать, что он мой, я точно не самозванец. Если код им показался плохим — собеса и не будет. Зато меня никто не унизит.
У вас логическая ошибка. Если есть желание унизить — что мешает им обговнять ваш код с ног до головы в письме и последней строчкой написать — собеса не будет. Не получится избегать оскорблений, можно только толщину кожи нарастить. Или всю жизнь сидеть в уютной конторе, где не шибко платят не шибко повышают, зато не оскорбляют и не давят. И надеяться что какой-то более толстокорый друг или коллега будет вас за собой тягать в более доходные проекты, и защищать вас от контактов.
Опять-же, вы согласитесь писать тестовое бесплатно в течении недели? И как вы докажите что код, ваш?
Вы не подумайте, я и сам не очень толстокорый. Просто не вижу другого выхода. Для себя нашел решение — не работать на русскоязычных начальников и заказчиков, вообще. Англоязычные более вежливые, менее напористые, менее авторитарные, они готовы уступать и разговаривать. А русскоязычные вечно строят армейскую дисциплину. Ну или мне так везло. Ну и кстати, я самозванцев не оскорблял, говорил «мы подумаем и если что свяжемся с вами». Не думаю что у них после собеседований были эмоциональные проблемы.
Опять-же, вы согласитесь писать тестовое бесплатно в течении недели? И как вы докажите что код, ваш?
Вы не подумайте, я и сам не очень толстокорый. Просто не вижу другого выхода. Для себя нашел решение — не работать на русскоязычных начальников и заказчиков, вообще. Англоязычные более вежливые, менее напористые, менее авторитарные, они готовы уступать и разговаривать. А русскоязычные вечно строят армейскую дисциплину. Ну или мне так везло. Ну и кстати, я самозванцев не оскорблял, говорил «мы подумаем и если что свяжемся с вами». Не думаю что у них после собеседований были эмоциональные проблемы.
Бизнес почему-то безумно боится самозванцев
Потому что один не опытный спец способен загубить при некоторых условиях бизнес на корню, если бизнес сильно зависим от ИТ.
Я как-то по молодости убил БД, копию не сделал.
После этого предприятие сильно скатилось вниз две недели восстанавливая базу и практически не работая, потом еще пару месяцев работая не шатко не валку. Конкуренты не дремали в это время.
Предприятие так и не поднялось до былого уровня.
У руководства любой организации есть обязанность: делегировать полномочия. Причём делегировать полномочия и подойти абы к кому и приказать абы что — не одно и то же.
В вашем случае вина делится долями между вами и теми, кто вам доверял. Это нормально, что за свою беспечность владелец бизнеса платит из своего же кармана.
Строго говоря, с точки зрения бизнеса вы вообще не виноваты, если у вас не было злого умысла.
В вашем случае вина делится долями между вами и теми, кто вам доверял. Это нормально, что за свою беспечность владелец бизнеса платит из своего же кармана.
Строго говоря, с точки зрения бизнеса вы вообще не виноваты, если у вас не было злого умысла.
Я как-то по молодости убил БД, копию не сделал.
Девопса/сис.админа на предприятии не было? Туда им и дорога.
Девопса/сис.админа на предприятии не было? Туда им и дорога
Ну дык я ими всеми и был.
А выделенный сис.админ — это очень круто. Вы представляете себе что такое малый бизнес?
до 150человек, с активами до 400млн. Вы наверно имели ввиду микро-бизнес. Там можно взять приходящего админа как и приходящего бухгалтера. Организационный вопрос.
У нас в студии из 2х разработчиков был отдельный сис. админ т.к. время обоих разработчиков стоит несоизмеримо дороже времени сис. админа.
У нас в студии из 2х разработчиков был отдельный сис. админ т.к. время обоих разработчиков стоит несоизмеримо дороже времени сис. админа.
Вы считаете, что проблема была только в вас? Т.е. что у предприятия не было бэкапов, логов, и всего-всего остального нужного, это нормально?
Junior, который в первый день работы удалил базу данных с production
Junior, который в первый день работы удалил базу данных с production
Так это вопрос разграничения доступа. Именно поэтому логично иметь некую тестовую БД, хотя бы просто копию. И новобранцев отправлять на неё, никакой боевой БД.
А бекапы у вас не делались?
Что такое virtual?Вот тоже в тупике от этого вопроса. Столько всякого мозг сразу вспомнил, что даже не знаю что бы выбрал.
Для чего virtual? Для того что бы базовые классы вели себя как наследующие классы. Как будто бы класс один, а объекты ведут себя по разному, потому что разные реализации наследования/переопределения виртуальных методов.
А, почитал и вспомнил, в C# оно пришло с тем же значеним из С++, на котором я когда-то кодил. Расспрашивая по синтаксису конкретного языка сеньера можно только отпугнуть.
Ну, если virtual реально так же работает как в C++ то вопрос еще имеет право на жизнь. Хуже когда вопрос становится настолько популярным что его пихают куда не поподя как тот же «чем отличается абстрактный класс от интерфейса». И пофиг что собеседуешь ты по C++ (где в принципе нет интерфейсов) или ObjC (где нет абстрактных классов (распространенный вариант «кидать эксепшн при вызове метода» это все-таки костыль-имитация, а не настоящий абстрактный класс), интерфейс строго говоря это просто описание что есть в классе/категории, а то что подразумевается под интерфейсом в вопросе называется протоколом )
Но вопрос был не «для чего», а «что такое». Тут, думаю, и кроется затруднение для нескольких отписавшихся в подобном ключе выше.
Интересно почему минуса. Я что-то неправильное написал?
Ну, в целом, да. Наследование работает и без virtual. Пока вы работаете с экземплярами класса, виртуальные методы вам не нужны, они выхотят на сцену, когда появляются указатели. virtual нужен, чтобы указатель на базовый класс, указывающий на класс-потомок, вызывал методы класса-потомка.
Наследование работает и без virtual.Обратного я и не писал.
virtual нужен, чтобы указатель на базовый класс, указывающий на класс-потомок, вызывал методы класса-потомка.Я написал примерно тоже. Что указатель указывающий на базовый класс, при вызове override методов, будет иметь поведение отличное от поведения базового класса из-за переопределения виртуальных методов классом-наследником.
Я не ставил вам минуса, — не имею такой привычки — поэтому не могу отвечать за тех, кто ставил. Но скажу честно, объяснение
На собеседовании, если бы мне пришло в голову об этом спросить, я бы, наверное, ожидал услышать ключевые слова «указатель» или «ссылка». Впрочем, на собеседовании можно уточнить, конечно, или (еще лучше) попросить набросать пример.
Для того что бы базовые классы вели себя как наследующие классы.вынесло мне мозг. Единственная разумная интерпретация, которую я смог придумать — что вы таким образом описываете обычное наследование.
На собеседовании, если бы мне пришло в голову об этом спросить, я бы, наверное, ожидал услышать ключевые слова «указатель» или «ссылка». Впрочем, на собеседовании можно уточнить, конечно, или (еще лучше) попросить набросать пример.
они выхотят на сцену, когда появляются указатели. virtual нужен, чтобы указатель на базовый класс...
Не совсем точно. Полиморфного поведения можно добиться, даже работая с конкретным классом наследника и невиртуальным API. Конечно, указатели на базовый класс появляются, но неявно. Идею проиллюстрирую на C#. Но на C++ то же самое, называется NVI; может работать просто через стековую переменную наследника, без явных ссылок/указателей.
abstract class Pet
{
public void NonVirtual() { NonPublic(); }
protected abstract void NonPublic();
}
sealed class Cat : Pet
{
protected override void NonPublic() { Console.WriteLine("Meow"); }
}
sealed class Dog : Pet
{
protected override void NonPublic() { Console.WriteLine("Bow!"); }
}
...
Cat cat = new Cat();
cat.NonVirtual();О том и речь. Для полиморфизма не нужен virtual. Virtual нужен только для того варианта полиморфизма, который использует указатели/ссылки на базовый класс.
А где именно в вашем примере полиморфизм?
А где именно в вашем примере полиморфизм?
Cat cat = new Cat();
cat.NonVirtual();
Dog dog = new Dog();
dog.NonVirtual();В обоих случаях вызывается один и тот же невиртуальный метод базового класса Pet.NonVirtual(). Но поведение будет разным, будет напечатано Meow и Bow!
Полиморфизм в методе public void NonVirtual() { NonPublic(); } Его реализация тут состоит из одного вызова, но может кроме этого содержать и какую-то общую для наследников логику. Паттерн Template method.
Полиморфизм в методе public void NonVirtual() { NonPublic(); }
Не-не, погодите. Полиморфизм у вас в методе NonPublic, и он как раз виртуальный. В NonVirtual никакого полиморфизма нетути.
В NonVirtual никакого полиморфизма нетути.
Он полиморфный по поведению, с точки зрения пользователя класса (которому недоступен виртуальный метод NonPublic() напрямую). Он был бы мономорфным, если бы использовал только функционал базового класса и не обращался к виртуальным методам, переопределённым в потомках.
Он полиморфный по поведению
По какому поведению?
с точки зрения пользователя класса
Никакой точки зрения нет. Метод либо объективно полиморфный, либо объективно не полиморфный. NonVirtual() — не полиморфный.
Метод либо объективно полиморфный, либо объективно не полиморфный.
abstract class Pet
{
public void NonPolymorphicNonVirtual()
{
Console.WriteLine("I'm pet");
}
public void PolymorphicNonVirtual()
{
Console.WriteLine($"{Virtual} {Virtual}");
}
protected abstract string Virtual { get; }
}
sealed class Cat : Pet
{
protected override string Virtual => "Meow";
}
sealed class Dog : Pet
{
protected override string Virtual => "Bow!";
}
...
{
Pet pet = new Cat();
pet.NonPolymorphicNonVirtual(); // I'm pet
pet.PolymorphicNonVirtual(); // Meow Meow
}
{
Pet pet = new Dog();
pet.NonPolymorphicNonVirtual(); // I'm pet
pet.PolymorphicNonVirtual(); // Bow! Bow!
}Полиморфизм — это абстракция, а не конкретная реализация. Это люди называют полиморфизмом такое поведение объекта, которое зависит от его подтипа, а не стандарт языка. Если трактовать класс Pet как черный ящик, то метод NonVirtual — однозначно полиморфный, ведь он ведет себя по разному, в зависимости от того, к какому подтипу относится объект.
Если трактовать класс Pet как черный ящик, то метод NonVirtual — однозначно полиморфный, ведь он ведет себя по разному, в зависимости от того, к какому подтипу относится объект.
Допустим, у меня два разных класса (не в общей иерархии, просто два разных класса). У каждого из них есть метод foo, определен он по-разному. У объекта одного класса вызвали — результат один, у объекта другого класса — результат другой. Следует ли из этого, что метод foo — полиморфный? Если нет, то почему?
Но тут-то другой случай. Метод вызывается один и тот же.
Допустим, у меня два разных класса (не в общей иерархии, просто два разных класса)
Так это не в общей. А тут общая иерархия и метод предка. Классический полиморфизм в ООП понимании, не забудьте про соблюдение LSP.
У каждого из них есть метод foo, определен он по-разному. У объекта одного класса вызвали — результат один, у объекта другого класса — результат другой. Следует ли из этого, что метод foo — полиморфный? Если нет, то почему?
Давайте более конкретный пример, хорошо? Вот есть классы Array, HashMap, Tree. В иерархию не входят. В каждом есть функция map(), интерфейс один. Полиморфная ли это функция?
Так это не в общей. А тут общая иерархия и метод предка.
То есть, полиморфизма нет, но вот я добавляю общего предка (при этом поведение программы никак не меняется) и полиморфизм появляется? Но как же это так, ведь выше рассуждения как раз о том, что полиморфизм определяется как раз по поведению, а остальное все — черный ящик?
Полиморфная ли это функция?
Следуя моей логике — безусловно, нет, точно так же как не являются полиморфными ф-и из примеров выше. Следуя вашей — безусловно, да.
Следуя моей логике — безусловно, нет, точно так же как не являются полиморфными ф-и из примеров выше.
Посмотрите хотя бы в Википедии, что такое полиморфизм.
Я-то знаю, и не только из википедии.
Полиморфизм в обсуждаемом контексте = позднее связывание.
Естественно, у этого термина есть и другие значения, но не стоит подменять понятия.
Это, кстати, легко доказать, вот есть такая штука, что три ключевых концепции ООП — это инкапсуляция, наследование и полиморфизм. Но наследование и полиморфизм подтипов (если подтипы номинальные) — это одно и то же. Следовательно, либо упоминаемый тут принцип полиморфизма — это не наследование (то есть не полиморфизм подтипов), либо у нас второй принцип совпадает с третьим. Вы какой вариант предпочитаете?
Это называется compile time polimorphism
this в методе NonVirtual — это тоже как бы переменная. Ее тип — Pet, а тип лежащего внутри объекта — Cat. Вот и полиморфизм.
Так никто не спорит, что полиморфизм есть. Просто он в методе NonPublic, а не в методе NonVirtual.
Полиморфизм — это способность функции обрабатывать данные разных типов. Этой способностью обладают оба метода.
Полиморфизм — это способность функции обрабатывать данные разных типов. Этой способностью обладают оба метода.
Это замечательно что вы прочитали статью из википедии, но мы тут обсуждаем совсем не этот полиморфизм.
В частности, согласно этому определению полиморфизмом являются перегрузки методов (ad-hoc полиморфизм типичный), однако на практике перегрузку полиморфизмом никто не называет.
В данном случае здесь не надо путать математическую модель (о чем и речь в случае subtyping-полиморфизм, и это никак вообще не связано с наследованием) и механизм позднего связывания (что подразумевается под полиморфизмом в контексте ООП и связано с наследованием напрямую).
Полиморфизм в ООП является частным случаем полиморфизма вообще. Я привел общее определение, чтобы показать что полиморфизм является свойством функции относительно ее входных параметров, а не механизмом.
Так вот. В обсуждаемом коде функция NonVirtual является полиморфной, поскольку может принять в качестве нулевого параметра не только объект типа Pet, но и любого наследника Pet.
Так вот. В обсуждаемом коде функция NonVirtual является полиморфной, поскольку может принять в качестве нулевого параметра не только объект типа Pet, но и любого наследника Pet.
Полиморфизм в ООП является частным случаем полиморфизма вообще.
Конечно же, нет! Частным случаем полиморфизма вообще является полиморфизм подтипов. Но полиморфизм подтипов — это просто констатация того факта, что любой метод предка есть у потомка. Он вообще никак не связан с разным поведением, перегрузкой методов в потомке и т.п.., это обычное наследование.
Вы же сейчас пытаетесь просто подменить понятия. О полиморфизме подтипов никто в этой ветке не говорил, забудьте про него вообще. Он не относится к делу.
Нет, полиморфизм подтипов — это констатация того факта, что потомка можно использовать всякий раз когда кто-то просит предка (или указатель на предка в таких языках как С++). К примеру, вот эта функция полиморфна, но не наследуется:
void Foo(Pet pet) {
pet.NonVirtual();
}Нет, полиморфизм подтипов — это констатация того факта, что потомка можно использовать всякий раз когда кто-то просит предка
Именно об этом я вам и говорю, но вы упорно не хотите этого факта понять.
К примеру, вот эта функция полиморфна, но не наследуется:
Прекратите подменять понятия. В смысле полиморфизма подтипов полиморфной является абсолютно любая функция в языке с наследованием. Неполиморфных просто не существует. Например:
class Pet {
public void Foo() {
Console.WriteLine("foo")
}
}тоже вполне полиморфная, ведь вы можете применить ее к любому потомку
Да, вы правы, полифорфной будет почти любая функция («почти» — потому что бывают типы от которых невозможно унаследоваться).
Но это же не означает что «наследование» и «полиморфизм подтипов» — это одно и тоже.
Но это же не означает что «наследование» и «полиморфизм подтипов» — это одно и тоже.
Да, вы правы, полифорфной будет почти любая функция («почти» — потому что бывают типы от которых невозможно унаследоваться).
Да без почти. Все методы любого типа можно вызвать на подтипе, то есть эти методы полиморфны. То, что подтипа может не быть у конкретного типа, полиморфизм не отменяет, предыдущее высказывание для таких типов точно так же остается истинным.
Но это же не означает что «наследование» и «полиморфизм подтипов» — это одно и тоже.
Наследование и полиморфизм подтипов — это эквивалентные вещи по определению. Не бывает наследования без полиморфизма подтипов и не бывает полиморфизма для номинальных подтипов без наследования.
В любом случае это бессмысленный разговор. В контексте ООП под полиморфизмом подразумевается не полиморфизм подтипов, а механизм позднего связывания. И в таком контексте в языке без виртуальных функций полиморфизма в принципе нет. Хотя полиморфизм подтипов — конечно же, есть.
не бывает полиморфизма для номинальных подтипов без наследования
https://dlang.org/spec/class.html#alias-this
Не бывает наследования без полиморфизма подтипов
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
https://dlang.org/spec/class.html#alias-this
Где вы тут нашли подтипирование в том или ином виде? Его нет.
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_sci
ко/контра-вариантность — это когда подтипирование объединяется с параметрическим полиморфизмом, то есть полиморфизм подтипов там гарантированно есть. Вы бы сами в вопросе лучше разобрались и желательно не по википедии, возьмите TaPL почитайте.
Где вы тут нашли подтипирование в том или ином виде?
Алиас позволяет создать подтип без наследования. Посмотрите примеры внимательно.
ко/контра-вариантность — это когда подтипирование объединяется с параметрическим полиморфизмом, то есть полиморфизм подтипов там гарантированно есть.
Полиморфность надтипа в случае контравариантности и полное отсутствие полиморфизма в случае инвариантности.
Алиас позволяет создать подтип без наследования.
Где? Я не вижу в примерах создания подтипа.
Полиморфность надтипа в случае контравариантности и полное отсутствие полиморфизма в случае инвариантности.
Так отсутствие полиморфизма только для T, сами А прекрасно наследуются и соответствующие ф-и полиморфны, все в порядке.
Где? Я не вижу в примерах создания подтипа.
Эта конструкция собственно и объявляет структуру/класс подтипом другого типа. По спецификации языка. С чем вы тут пытаетесь спорить — ума не приложу.
сами А прекрасно наследуются
А я где-то утверждал, что не наследуются? Наследование и полиморфизм — оргогональные понятия.
и соответствующие ф-и полиморфны, все в порядке.
Не знаю, о каких "соответствующийх функциях" вы говорите (надеюсь не съехали на позднее связывание?), но если я не могу вместо одного типа где угодно подставить его подтип, то полиморфизмом подтипов тут и не пахнет.
Эта конструкция собственно и объявляет структуру/класс подтипом другого типа.
Я не понимаю, с чего вы это взяли.
По спецификации языка.
Ну там неправильно написано. Демонстрируемое в примерах поведение этому не соответствует. Либо под "подтипом" подразумевается что-то другое. Нигде это значение не ведет себя как подтип, оно просто ведет себя как соответствующее поле, то есть выполняется неявная конверсия. И неявная конверсия — это не подтипирование. Неявная конверсия и подтипирование ведут себя по-разному, и эту разницу можно пронаблюдать.
А я где-то утверждал, что не наследуются?
То, что наследуются — утверждал я, а вы это оспаривали. Если вы оспаривали мое утверждение — с-но, утверждали нечто обратное, разве нет?
Наследование и полиморфизм — оргогональные понятия.
Мы же уже выяснили, что наследование и полиморфизм подтипов — это одно и то же, как понятие может быть ортогонально само себе? Невозможно реализовать наследование без полиморфизма подтипов и наоборот.
Не знаю, о каких "соответствующийх функциях"
Я говорю о любых ф-ях, которые принимают А (они же могут принимать и любой подтип А, то есть полиморфизм подтипов есть).
но если я не могу вместо одного типа где угодно подставить его подтип, то полиморфизмом подтипов тут и не пахнет.
Но вы можете.
Я немного разбирался в кухне рекрутмента, смотрел какие отзывы народ оставляет у нас в проекте, беседовал с людьми которые устраивались.
Вывод достаточно очевиден — если на собеседовании было некомфортно, то в самой компании вряд ли будет лучше — будете иметь дело с такими же самодовольными чуваками, просто потом они будут ставить такие же бессмысленные задачи.
Вывод достаточно очевиден — если на собеседовании было некомфортно, то в самой компании вряд ли будет лучше — будете иметь дело с такими же самодовольными чуваками, просто потом они будут ставить такие же бессмысленные задачи.
UFO just landed and posted this here
Еще мы постоянно забываем, что HR работает не только с программерами, они пытаются решить задачу «ненайма самозванца» для любой более-менее ответственной должности в компании.
Самодовольство человечка, проводившего собеседование говорит только о том, что они на поиск сеньора отрядили начальника или зам-начальника, и им важно не облажаться с самозванцем.
А чем выше должность в вакансии, тем выше риски. Бывает, что ищут замдиректора, там вообще сливай воду — туши свет, говорить умеют все, работать — один на тысячу.
Самодовольство человечка, проводившего собеседование говорит только о том, что они на поиск сеньора отрядили начальника или зам-начальника, и им важно не облажаться с самозванцем.
А чем выше должность в вакансии, тем выше риски. Бывает, что ищут замдиректора, там вообще сливай воду — туши свет, говорить умеют все, работать — один на тысячу.
Нельзя брать разработчика, ориентируясь только на его код.
Бывают соискатели, которые берут код своего тимлида и выдают за свой, например, выкладывают на Гитхаб.
Поэтому и актуален и вайтбординг, и опрос по базовым вещам. Такова реальность.
К вайтбордингу легко подготовиться, прорешивая задачки с LeetCode, например.
Бывают соискатели, которые берут код своего тимлида и выдают за свой, например, выкладывают на Гитхаб.
Поэтому и актуален и вайтбординг, и опрос по базовым вещам. Такова реальность.
К вайтбордингу легко подготовиться, прорешивая задачки с LeetCode, например.
Ужас! Вот, я. Думаю, что мне делать. Просто так читать книги, да мануалы? Пополнять ряды ничего не умеющих «самозванцев»?… Их (тем, вопросов, сред разработки, библиотек, языков программирования) много. А я один.
Может быть подкинете мне мне какую-нибудь «домашку». Хочу сделать что-нибудь реальное. Работающее. Нужное. Заодно, изучу новое для себя. Испытаю свои силы. Стану лучше соображать.
А? Пожалуйста!
Может быть подкинете мне мне какую-нибудь «домашку». Хочу сделать что-нибудь реальное. Работающее. Нужное. Заодно, изучу новое для себя. Испытаю свои силы. Стану лучше соображать.
А? Пожалуйста!
Вы тут про программирование, а я вот уже с середины лета никак не могу найти работу сисОдмином.
И знаете, ситуация точь в точь такая же.
Был в одной компании, такое знаковое собеседование, побеседовал с старшим админом (искал сменный график, а это в основном тп), простой мужик, простые вопросы, спокойная беседа, и вдруг вваливается ЭТО… кашляя, задыхаясь, чихая во все стороны — начальник ИТ отдела!
Первый вопрос — какая команда в цискаре нужна для вот этого (уже не помню сути).
мысли путаются, ладошки потеют, последний раз кошака мацал год назад — не помню.
Итог — с гордым видом рассказывает мне пошагово от и до как мацать кошку… и похуй что в мои обязанности даже близко не будут стоять блохастые. Давай, дасвидания.
И почти всегда всё в таком же духе, реально как в школе…
p.s. а ещё все очень сильно удивляются, что на моём текущем месте работы очень редки форс-мажоры. всё исправно и стабильно работает, и нет ацких «юзверей». и хер им докажешь, что грамотно отстроенные системы и регулярный контроль решают, и что людей можно выдрессировать не «сувать в принтер скрепки»…
только у меня не бомбит как у тс, у меня депрессия =)
И знаете, ситуация точь в точь такая же.
Был в одной компании, такое знаковое собеседование, побеседовал с старшим админом (искал сменный график, а это в основном тп), простой мужик, простые вопросы, спокойная беседа, и вдруг вваливается ЭТО… кашляя, задыхаясь, чихая во все стороны — начальник ИТ отдела!
Первый вопрос — какая команда в цискаре нужна для вот этого (уже не помню сути).
мысли путаются, ладошки потеют, последний раз кошака мацал год назад — не помню.
Итог — с гордым видом рассказывает мне пошагово от и до как мацать кошку… и похуй что в мои обязанности даже близко не будут стоять блохастые. Давай, дасвидания.
И почти всегда всё в таком же духе, реально как в школе…
p.s. а ещё все очень сильно удивляются, что на моём текущем месте работы очень редки форс-мажоры. всё исправно и стабильно работает, и нет ацких «юзверей». и хер им докажешь, что грамотно отстроенные системы и регулярный контроль решают, и что людей можно выдрессировать не «сувать в принтер скрепки»…
только у меня не бомбит как у тс, у меня депрессия =)
Сколько народу набрал в своё время, вообще о таких опасениях не задумывался.
Приходит человек, спрашиваешь опыт — сразу задаёшь любой вопрос из деталей рассказанного, сразу видна правда или ложь. Приходят зелёные, но хотят работать — через год-два они заткнут многих "сеньоров".
Мне реально хватало 15 минут чтобы понять — брать человека или нет. Набирали конвейером. Ни разу не пожалел.
Самые адекватные компании — это где либо HR не участвует в отборе и нет рекрутеров, либо же где реально клёвые ребята на этих местах — сами бывшие технари.
P.S. Один раз мне отказали в интервью, т.к. в списке скиллов не было Ajax, но был JS и React.
А в чем, собственно, проблема?
Мне тоже доводится частенько собеседовать самых разных людей на позиции SE. Я вижу, чем люди занимались. Я знаю, чем им предстоит заниматься. На основе этого я прикидываю, о чем следует поговорить с человеком, чтобы понять _как_ он работал. У моего работодателя есть возможность выбирать между кандидатами, и будь я проклят, если я ей не воспользуюсь.
Т.е. лучше я перестрахуюсь и не возьму пять отличных инженеров, чем случайно возьму одного. Знаете, как идеология гугловых собеседований — ни в коем случае не уменьшать планку уровня уже имеющихся разработчиков, потому что в итоге это приведет к деградации УровняТМ.
Вернемся к тому, _как_ человек работал свои 5, 10, 15 лет стажа. У собеседовающих же нету информации по результатом внутреннего эвалюэйшена по сотруднику в каждом его месте работы. Он мог выполнять несложные задачи, которые давал ему лид, а мог драться и спорить по поводу целесообразности и того, как делать каждую задачу. Мог шлепать по одному и тому же принципу однотипные сайты/сервисы/приложения/etc. А мог постоянно изучать новые техники и подходы к проектированию, анализу и разработке. Мог использовать остальные компоненты системы (ОС, компилятор, соседние сервисы, либы) как блекбоксы, а мог ковыряться в кишках, понимать внутреннее устройство и под каким соусом эти компоненты лучше всего готовить.
Не бомбите. Не горите. Просто либо вам не повезло, либо работодатель и правда искал не вас. На одном сотруднике и на одном работодателе свет клином не сошелся. Благо, мы в IT, можем себе позволить :)
Мне тоже доводится частенько собеседовать самых разных людей на позиции SE. Я вижу, чем люди занимались. Я знаю, чем им предстоит заниматься. На основе этого я прикидываю, о чем следует поговорить с человеком, чтобы понять _как_ он работал. У моего работодателя есть возможность выбирать между кандидатами, и будь я проклят, если я ей не воспользуюсь.
Т.е. лучше я перестрахуюсь и не возьму пять отличных инженеров, чем случайно возьму одного. Знаете, как идеология гугловых собеседований — ни в коем случае не уменьшать планку уровня уже имеющихся разработчиков, потому что в итоге это приведет к деградации УровняТМ.
Вернемся к тому, _как_ человек работал свои 5, 10, 15 лет стажа. У собеседовающих же нету информации по результатом внутреннего эвалюэйшена по сотруднику в каждом его месте работы. Он мог выполнять несложные задачи, которые давал ему лид, а мог драться и спорить по поводу целесообразности и того, как делать каждую задачу. Мог шлепать по одному и тому же принципу однотипные сайты/сервисы/приложения/etc. А мог постоянно изучать новые техники и подходы к проектированию, анализу и разработке. Мог использовать остальные компоненты системы (ОС, компилятор, соседние сервисы, либы) как блекбоксы, а мог ковыряться в кишках, понимать внутреннее устройство и под каким соусом эти компоненты лучше всего готовить.
Не бомбите. Не горите. Просто либо вам не повезло, либо работодатель и правда искал не вас. На одном сотруднике и на одном работодателе свет клином не сошелся. Благо, мы в IT, можем себе позволить :)
«лучше я перестрахуюсь и не возьму пять отличных инженеров, чем случайно возьму одного». Думаю, посыл автора статьи в том, какие вы меры предпринимаете для того, чтобы производить отсев, и какие вопросы задаете. Вопросы типа тех, о которых он говорит позволят вам отсеить пять отличных инженеров и взять одного профессионального проходимца собеседований.
А мой посыл в том, что у каждого собеседующего есть своя мотивация задавать те вопросы, которые он задает (если собеседующий — сам инженер, конечно, хехе). Если не сошлись его вопросы и ваши ответы — значит вы друг другу не подходите, очень просто.
В маленьких компаниях, не претендующих на единорогов, собеседования проводятся по-другому, например. Куда более по-свойски.
Понимаете, спрос-предложение — это и для рынка вакансий и рабочей силы справедливо. Если спроса на отличных спецов, которые не могут знать стандарты языка наизусть, нет — то это уже проблема спецов будет подстроиться под рынок. А не проблема рынка подстроиться под спецов.
Опять тот же гугл. Все знают, что там вайтбординг. Все знают, что там алгоритмы, которые в работе никогда не встретятся. Все знают, насколько там, казалось бы, несуразное интервью. И все равно идут и специально (!!!) готовятся именно к этому интервью.
Если работодатель достаточно хорош и знаменит — ему простят его причуды. Если работник достаточно хорош и знаменит — ему простят незнание чего-либо. А все остальные следуют Невидимой Руке Рынка(ТМ)
В маленьких компаниях, не претендующих на единорогов, собеседования проводятся по-другому, например. Куда более по-свойски.
Понимаете, спрос-предложение — это и для рынка вакансий и рабочей силы справедливо. Если спроса на отличных спецов, которые не могут знать стандарты языка наизусть, нет — то это уже проблема спецов будет подстроиться под рынок. А не проблема рынка подстроиться под спецов.
Опять тот же гугл. Все знают, что там вайтбординг. Все знают, что там алгоритмы, которые в работе никогда не встретятся. Все знают, насколько там, казалось бы, несуразное интервью. И все равно идут и специально (!!!) готовятся именно к этому интервью.
Если работодатель достаточно хорош и знаменит — ему простят его причуды. Если работник достаточно хорош и знаменит — ему простят незнание чего-либо. А все остальные следуют Невидимой Руке Рынка(ТМ)
Если не сошлись его вопросы и ваши ответы — значит вы друг другу не подходите, очень просто.
Как-то дочитал "Как сдвинуть гору Фудзи" до задачи «как бы вы спроектировали интерфейс видеомагнитофона» — чуть-чуть понял, почему продукты Microsoft немного особенные.
По статье +, но есть вопрос.
Почему так?
И уже не важно, что я на самом деле стараюсь избегать классического наследования, предпочитая ему композицию, и проектирую свои классы и системы таким образом, чтобы от них не требовалось делать наследников.
Почему так?
Потому что как правило, это более гибко и лучше масштабируется.
Об этом часто пишут в книгах, например Design Patterns
Об этом часто пишут в книгах, например Design Patterns
Я уже наблюдаю другую крайность, когда некоторые "гении" полностью отказываются от наследования. Полностью! И кидают в тебя кучу интерфейсов, которые нужно реализовать.
Как говорится, заставь дурака Богу молиться, он и лоб расшибет.
Я в книгах наоборот это редко встречаю («ООАиП» Гради Буч, «ООАиП» Крег Ларман, «Принц. пат. и мет. г.р.» Роберт Мартин, «Чистая архитектура» Роберт Мартин). Выбор между наследованием, ассоциацией, композицей и агрегацией не всегда прост, если в предметной области не сильно разбираешься.
Я не те книги возможно читаю.
Но меня тоже иногда тревожит, когда например, абстрактный класс сенсор имеет наследников на 3-4 уровня. Подобное на проде я бы и сам побоялся сделать.
Но в целом да, более гибко, по обстоятельствам короче.
Я не те книги возможно читаю.
Но меня тоже иногда тревожит, когда например, абстрактный класс сенсор имеет наследников на 3-4 уровня. Подобное на проде я бы и сам побоялся сделать.
Но в целом да, более гибко, по обстоятельствам короче.
Ой все эти "гибко и масштабируется" настолько сферический конь в вакууме. У меня на практике выходило так что хорошо спроектированный и написанный код никто масштабировать и гнуть не собирается. а когда таки придет время то там будет проще переписать. А почему? А потому что в хорошем коде уже все продумано и реализованно с учетом возможных изменений требований на ближайшую перспективу. и два там так напроектированно что только сеньеров туда пускать. а то первый джун превратит всю стройную архитектуру в кусок очень сложного навоза.
И какая разница что пишут в книжках про паттерны проектирования. Мы тут сейчас комментируем претендента на должность сеньера. который забыл про virtual… Ну не верю я в это. можно забыть про что то редкое или необязательное. но виртуал я не зная языка скажу что это про наследование, динамический полиморфизм и позднее связывание речь идёт.
Мне кинули предложение — Senior full-stack .NET Developer, удаленно, крутой проект, куча денег. В списке требований хренова гора не связанных между собой вещей из мира .net и js/ts. Выглядит так, будто просто свалили в кучу все, что нагуглили за 10 минут — причем мало понимая, что именно.
Тревожно, но ничего.
Конец немного предсказуем:
Ну привет. Я только что с собеса, и у меня бомбит. Сколько не пишут на Хабре, как правильно собеседовать — лучше не становится.
Странно было ожидать чего-то другого...
Нет никакого «бизнеса», который что-то хочет. Есть разраб, который неплохо кодит и тут ему дают задание провести собеседование. Он идет в гугл и пишет «вопросы на собеседование .net». Видит вопросы, иногда знает, а иногда нет ответы на них. Узнает что-то новое для себя, повторяет основы, наслаждается жизнью.
Потом приходит и спрашивает то же самое у вас. Это все мы, товарищи, мы и есть такие разрабы. Многие из нас не подходят к вопросам собеседования с прагматических позиций.
Потом приходит и спрашивает то же самое у вас. Это все мы, товарищи, мы и есть такие разрабы. Многие из нас не подходят к вопросам собеседования с прагматических позиций.
Подход «при необходимости я найду это в справочнике» вполне допустим, но на практике есть какая-то грань разумности такого… нигилизма что ли. Не ответить про virtual — это за этой гранью кмк. Чисто субъективно, разумеется.
Хах…
В этом месяце меня в Билайн собеседовали. Тоже была куча вопросов по синтаксису и ни одного программисткого вопроса. Я бы не смог оценить человека по таким вопросам-ответам за 10 минут. В Билайне смогли и отказали. Видимо из-за недостаточной квалификации :D
PS 10+ лет опыта на тяжёлых проектах в основном зарубежом.
В этом месяце меня в Билайн собеседовали. Тоже была куча вопросов по синтаксису и ни одного программисткого вопроса. Я бы не смог оценить человека по таким вопросам-ответам за 10 минут. В Билайне смогли и отказали. Видимо из-за недостаточной квалификации :D
PS 10+ лет опыта на тяжёлых проектах в основном зарубежом.
Может это был первичный собес?) Тот же яндекс любит устраивать по 2-3 технических интервью.
2-3 это вполне сносно. В некоторых компаниях по 5-6.
Ну да, это первичное собеседование было. Но зачем такое собеседование (вопросы по синтаксису) — оно ведь не показательно. Ведь в результате него отсеивается человек, который лучше подготовлен, чем тот кто только-что прочитал какой-нибудь beginners и знает 'все' конструкции языка.
Но зачем такое собеседование… — оно ведь не показательно.
Отсеить совсем уж бестолковых людей. Там, как правило, сильно тонких тонкостей не спрашивают, поэтому опытный программист пройдет его в любом случае.
знает 'все' конструкции языка
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Смотря какой язык.
ВСЕ конструкции легендарного PL/1 — мало кто знал.
Учитывая, как некоторые языки (не буду указывать пальцем) пухнут от версии к версии из-за синтаксического сахара, у меня закладывается смутного подозрение, что многие профессионалы, каждый день использующие этот язык на практике, могут и не знать абсолютно все его конструкции.
Не могу ничего сказать про PL/1.
Практика показывает, что на собеседованиях (как и сам бизнес) не особо гонятся за трендовыми штучками. Но интерес к развитию своих инструментов — это тоже показатель, имхо. Часто через «сравнения» и «перспективы» на собеседованиях развиваются дискуссии, где в милой беседе можно достаточно глубоко копать человеку в голову. При подготовке стоит это учитывать.
некоторые языки (не буду указывать пальцем) пухнут от версии к версии из-за синтаксического сахара, у меня закладывается смутного подозрение, что многие профессионалы… могут и не знать абсолютно все его конструкции.
Практика показывает, что на собеседованиях (как и сам бизнес) не особо гонятся за трендовыми штучками. Но интерес к развитию своих инструментов — это тоже показатель, имхо. Часто через «сравнения» и «перспективы» на собеседованиях развиваются дискуссии, где в милой беседе можно достаточно глубоко копать человеку в голову. При подготовке стоит это учитывать.
Дык по С++ то же самое, вряд ли сам Страуструп все конструкции помнит. Это я на момент 2010 года пишу, с тех пор, я слышал, еще больше всего появилось.
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Не соглашусь. Это нужно знать джунам, так как сосуд пока полностью пустой, и неплохо было бы его хоть чем-то наполнить. Спустя 10-15-20 лет у вас уже нет места в сосуде и чтобы туда залить что-то еще, оттуда должно вытечь что-то другое.
Поэтому юные программисты умеют писать красивый код и помнят все конструкции по памяти (одного ЯП), а старожилы (часто знающие от 4 ЯП) не код пишут, а создают программное обеспечение, фактически создают готовое решение!
Спустя 10-15-20 лет у вас уже нет места в сосуде и чтобы туда залить что-то еще, оттуда должно вытечь что-то другое.
Если откинуть романтизацию опыта «исчисляемого годами», это звучит как возрастные проблемы с обучаемостью (если «вытекает»), серьезно. Не встречал действительно крутых профессионалов, у которых наблюдались бы провалы в памяти по поводу базовых конструкций основного языка.
Зато часто встречаются люди, которые годами пишут одинаковые приложения с помощью одинаковых подходов и напрочь забывают о существовании альтернатив. Это годы застоя, а не опыт.
Поэтому юные программисты умеют писать красивый код
Потому что они не умеют читать некрасивый код. С опытом причуды оформления становятся менее значимыми и болезненными. Но это уже совсем другая история.
Спорим, что я угадаю ваш возраст? ))) Не многим более 20 лет. Угадал?
Вы никогда не задумывались почему Запад аутсорсит только кодеров, а не идейных вдохновителей. Почему нужны только дешевые рабы на галеры?
Нет, дело не в нашем опыте, знаниях и уникальности. Все дело в цене!
А у вас не возникал вопрос, кто же все таки все те люди, которые придумывают для крутого софта алгоритмы/подходы/идеи/паттерны и т.д.? И почему они все только на Западе. А еще очень интересно сколько лет этим людям? Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Так в какой же момент вашего времени произошел перекос, когда вы можете утверждать, что знаете ЯП лучше, чем его создатель? Маркером будет какой показатель? То что вы помните какие-то конструкции, а он уже нет?
В тысячный раз повторюсь, программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT. Многим даже и код никакой писать не нужно, для этого они аутсорсят нас за еду!
Вы никогда не задумывались почему Запад аутсорсит только кодеров, а не идейных вдохновителей. Почему нужны только дешевые рабы на галеры?
Нет, дело не в нашем опыте, знаниях и уникальности. Все дело в цене!
А у вас не возникал вопрос, кто же все таки все те люди, которые придумывают для крутого софта алгоритмы/подходы/идеи/паттерны и т.д.? И почему они все только на Западе. А еще очень интересно сколько лет этим людям? Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Так в какой же момент вашего времени произошел перекос, когда вы можете утверждать, что знаете ЯП лучше, чем его создатель? Маркером будет какой показатель? То что вы помните какие-то конструкции, а он уже нет?
В тысячный раз повторюсь, программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT. Многим даже и код никакой писать не нужно, для этого они аутсорсят нас за еду!
Нет, вы ошиблись.
При чем здесь Запад и топ-менеджмент вообще? R&D-отделов крупных вендоров и в СНГ хватает, например.
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
Дядьки эти, как правило, код не пишут, а руководят проектами и теми, кто пишет (теми самыми сеньорами-миддлами-джуниорами простопрограммистами).
почему Запад аутсорсит только кодеров, а не идейных вдохновителей.
При чем здесь Запад и топ-менеджмент вообще? R&D-отделов крупных вендоров и в СНГ хватает, например.
Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT.
Дядьки эти, как правило, код не пишут, а руководят проектами и теми, кто пишет (теми самыми сеньорами-миддлами-джуниорами простопрограммистами).
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
Ха, не удержались, кинули какашкой. А что можно почитать от такого крутого специалиста, как вы? Уж вы-то точно не формошлепер. И у вас такой богатый опыт в комментариях. Хочу у вас чему-то научиться. Ведь это же нормальное желание? Поделитесь своими статьями, можно даже заминусованными.
Приняли на свой счет? Я понятия не имею о том, какой вы специалист и по этой причине не перехожу на личности с незнакомым человеком в интернете. Писалось не о вас лично, разумеется.
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Конечно может быть, как и инженер, как и архитектор, также как и врач и т.д.
Но если немного порассуждать, то возникает вопрос, а зачем люди шли в такие тяжелые сферы, долго обучались в университетах и много лет практиковались, что бы быть бестолковыми?
Зачем им все это? Зачем такие усилия, чтобы спустить их на безделие и стать бестолковыми? Разве нет более простых, гуманитарных специальностей, где можно быть бестолковым вполне комфортно и не напряжно?
А я скажу, почему витает в воздухе дух того, что взрослые люди бестолковые, а молодые дарования — гении.
Все просто. 20-30 лет назад программирование только зарождалось, и те кто в него приходили, делали это не из-за денег или престижа. А из-за жажды новых технологий и прогресса. Подавляющее большинство таких людей, если не все, заканчивали технические университеты с профильными факультетами: автоматизированные системы/кибернетика/робототехника/схемотехника и т.д. Такие люди прошли весь свой путь до сегодняшнего дня с нуля. А некоторые еще и помнят, как нашкрябать простой контроллер в машинных кодах!
И теперь вернемся к нашему времени. Молодые и талантливые дарования, которые считают, что образование/университеты/опыт взрослых людей все это полная шляпа и отстой, быстро изучают по «супер курсам» и роликам из Ютюб какой-то ЯП высокого уровня. Выпендриваются друг перед другом знанием классов/методов и т.д. тем самым пытаясь поднять свое ЧСВ. А как работает комп, что такое шина данных/управления и т.д. знать вообще никому на фиг не нужно. Не царское это дело. Можно взять какой-нибудь фреймворк/CMS и просто шлепать типовые задачи — УРА, профит!
А все те, кто говорят, что уровень знаний таких талантов около нуля, и что ЯП вообще в разработке стоит на последнем месте, то те ламеры, старые и бестолковые пердуны, которые не развиваются ни в чем и максимум что помнят — это какой-нибудь Фортран или Кабол. Короче стандартная подмена понятий.
Именно по этому толковый преподаватель в ВУЗе натянет на экзамене любое юное дарование, которое все знает и умеет.
И такая ситуация не только в ИТ. Она везде.
Именно по этому многие компании (часто Зарубежные) ищут разработчиков за 30-50 лет. Так как золотая молодежь, которая все знает и умеет, и которой насрать на бизнес заказчика, реально уже многих зае… ала.
И если просмотреть реальный успех в ИТ людей по возрастной рамке, то окажется, что он приходит часто после 40 лет, и почти никогда, сразу после 20.
А так как на хабре в подавляющем большинстве сидит молодежь, чьи реальные имена скрыты, у которых нет своих публикаций/сайтов/блогов/опенсорс и т.д., то при таких комментариях или статьях у них реально пригорает, так как бьет по их самолюбию. И какая бы статья не была полезной/важной/правдивой ее обязательно обосрут и заминусят. Что, в свою очередь, никак не принизит опыт/знания/интеллект автора, и уж тем более не возвысит комментаторов, кидающихся фикалиями.
Надеюсь, я смог развернуто ответить на ваш вопрос?
20-30 лет назад программирование только зарождалось, и те кто в него приходили, делали это не из-за денег или престижа.
Да ты че?
Лет 25 назад мой преподаватель рассказывала о том, как именно программирование уже вовсю применялось на примере огромного завода, на котором она работала в 1970-х. То есть почти 50 лет назад. А один из старейших ныне еще применяемых языков программирования для бизнес-приложений, а вовсе не для научных целей — Cobol — был создан в 1959 году. Применяется до сих пор по той причине, что еще тогда были написаны горы программного кода.
А можете назвать, пожалуйста, этот современный, на те года, советский завод, где во всю применялось программирование, чего, кстати?
Я не говорю про программирование в мире. Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
Я не говорю про программирование в мире. Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
А можете назвать, пожалуйста, этот современный, на те года, советский завод, где во всю применялось программирование, чего, кстати?
АвтоВАЗ
Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
А что, в наше время, абсолютно все должно делаться в Виртуалии?
Очевидно, что такие предприятия ведут свою деятельность в реальном, а не виртуальном мире, что не может не радовать. Едим-то мы вполне материальные вещи.
Мне уже плохо. Честное слово, при одном упоминание все поплыло перед глазами.
Мне уже плохо. Честное слово, при одном упоминание все поплыло перед глазами
Это сейчас. Все же полвека минуло.
А на момент основания в 1966 году — АвтоВАЗ был вполне себе технологически совершенным, в том числе и по меркам всего мира. И ВЦ на АвтоВАЗе был весьма и весьма хорош.
ВАЗ, не АвтоВАЗ. Хотя и АвтоВАЗ тоже, но по контексту, кмк имеется в виду именно завод, не ПО.
А так да — например, некоторые мои преподаватели по ряду предметов в ВУЗе принимали непосредственное участие в роботизации ВАЗа, приводили конкретные примеры.
Мой отец разрабатывал АИС для сервисных центров АвтоВАЗа в 80е.
А так да — например, некоторые мои преподаватели по ряду предметов в ВУЗе принимали непосредственное участие в роботизации ВАЗа, приводили конкретные примеры.
Мой отец разрабатывал АИС для сервисных центров АвтоВАЗа в 80е.
Какая разница, что в мире есть предприятия, которым компьютер нужен постольку-поскольку? Очевидно, что такие предприятия ведут свою деятельность в реальном, а не виртуальном мире, что не может не радовать. Едим-то мы вполне материальные вещи.
С одной стороны вы правы, а с другой ведь софт и придумали для автоматизации и повышения эффективности труда. Был у меня в жизни реальный случай, пару лет назад.
Наняла меня контора, которая занимается бурением и цементированием нефтегазовых скважин, чтобы я подготовил им документацию, для создания софта, который поможет взаимодействовать с кучей отделов, лабораторий и софт для расчета цементирования скважин. Не уже готовое ТЗ для создания софта, а только концепцию и алгоритмы (блок схемы, диаграммы, описание и т.д.).
Так вот, какую проблему я у них увидел. Коммуникация между отделами и лабораториями на каких-то служебных записках, по мылу и по скайпу. Все расчеты для цементирования скважин в экселе!!!
В итоге, при последнем заказе при цементировании скважины, подаваемый в скважину цемент схватился раньше, чем успели произвести технологический процесс. Финансовая потеря составила 2 млн. долларов! Они этот косяк называю «словить козла». Начали искать виновного, чей это косяк, лаборатории, которая неправильный состав рассчитала, отдела инженеров, которые нарушили тех. процесс, производителя (у них свой завод по производству спец. цемента), который нарушил рецептуру. Кто виноват, так и не нашли. И в чем была проблема, тоже не выяснили. Просто попали на капусту.
И вот после такого больного попандоса и пришло понимание, что все же автоматизация и софт нужны.
Да, спасибо. Хотя, я все же считаю, что проблема не в возрастах, а в людях. Хотя современное развитие веба действительно протолкнуло в ИТ много не особо увлеченных сферой людей.
Да, спасибо. Хотя, я все же считаю, что проблема не в возрастах, а в людях. Хотя современное развитие веба действительно протолкнуло в ИТ много не особо увлеченных сферой людей.
Подавляющее большинство подобных ради денег во всех профессиях. Чем ИТ лучше?
Сюрприз — люди работают ради денег. Количество даже казалось бы принципиально увлеченных в ИТ было бы существенно меньше, если бы доходы были как у всех.
Сюрприз — люди работают ради денег.
Вы немного исказили смысл. Работают почти всегда ради денег, да, но конкретный вид занятия люди стараются выбрать по разным признакам, в котором величина оклада — не самый важный фактор.
Количество даже казалось бы принципиально увлеченных в ИТ было бы существенно меньше, если бы доходы были как у всех.
Пирамида Маслоу же. Имея достаточно денег для жизни можно и о высоком подумать.
Пирамида Маслоу же. Имея достаточно денег для жизни можно и о высоком подумать.
Это верно только с точки зрения индивидуума. Это не верно с точки зрения индустрии.
1) Чтобы думать о высоком нужны высокие доходы.
2) Если в индустрии высокие доходы туда ломится куча народа, которому нужны только деньги, а не высокое.
Как вы уже верно писали, бизнесу и не нужно высокое, нужно дешевое и массовое.
20-30 лет назад программирование только зарождалось, и те кто в него приходили, делали это не из-за денег или престижа.
habr.com/company/ua-hosting/blog/413733
Из истории советских ПК
Уже не секрет, что в 1950 -70 годах СССР был одним из мировых лидеров в гонке под названием «разработка и производство компьютерной техники». Первые ЭВМ — МЭСМ, М-1, позднее известная БЭСМ-6 с быстродействием более 1 млн. операций с плавающей запятой в секунду, компактные ЭВМ серии МИР, и многие другие достижения великих умов в «компьютерной» сфере советских времен.
Технологии развивались очень быстро, а потому такие комментарии как «А я и не знал/а, что в Советском Союзе были компьютеры» или «Оказывается, советские компьютеры не были отстоем по сравнению с зарубежными» вызваны лишь банальным незнанием истории развития различных «компьютерных» технологий и вычислительных устройств в СССР. Многим известна истории создания ПК таких мировых зарубежных гигантов как Apple, IBM и т.д., так как информация о них на протяжении не одного десятилетия освещалась и была на слуху. Исторически сложилось мнение, что в СССР кроме того, что не было «секса», так еще и персональные компьютеры появились позже на лет 10 чем в той же Америке. Как и первое так и второе заявление — не более чем миф.
Первые советские интегральные микросхемы с несколькими десятками транзисторов, увидели свет уже в середине 1960 годов, а к середине 1970-х выпускались микропроцессоры, сложные микросхемы, количество транзисторов в них уже измерялось в тысячах. В 1974 году были разработаны первые микро-ЭВМ на основе универсальных микропроцессоров. Секционные процессоры серий К532 и К536 (появившиеся в том же году) позволяли выпускать машины с разрядностью до 16–32 бит. Так появились 16-разрядные микро-ЭВМ. В 1977 году был выпущен аналог Intel 8080 — 8-разрядный процессор К580ИК80. Он то и стал основой для создания целого ряда моделей ПК и микро-ЭВМ. Через два года был разработан первый в мире 16-разрядный однокристальный микро-ЭВМ — К1801ВЕ1. На базе К1801ВЕ1 в 1981 создан К1801ВМ (однокристальный 16-разрядный микропроцессор), система команд которого была похожа на систему команд мини-ЭВМ PDP-11.
Нужно ли пояснять, что компьютеры без программ не нужны, а программы создаются программистами?
И если СССР в 50-70 годы прошлого века изготавливал компьютеры, то еще лет 60 назад программисты уже были?
Конечно были! Мало того, они уже в 50-ые сидели на хабре и друг в друга кидали помидорами, у кого комп больше или код длиннее )))
Аутсорсят все, кроме постановки задачи. А как можно выделять бизнес задачу, сидя в других реалиях? Архитекторы, тимлиды, техлиды, прожект менеджеры — это все так-же на аутсорсе. А у вас попахивает приступом «жидомассонского ложе», опять «нас великих используют за еду», да?
Не встречал действительно крутых профессионалов, у которых наблюдались бы провалы в памяти по поводу базовых конструкций основного языка.
Понятия не имею как называются паттерны, которые я использую в том или ином случае.
Да и вообще никогда не имел понятия — в мое время их не зубрили.
Для того чтобы делать дело — названия этих вещей не нужны в принципе.
Попробуйте не вспомнить, что такое синглтион)
Еще раз:
я этого и не знал никогда. Могу догадаться из контекста вопроса или посмотреть в Гугле.
Ничуть не мешает программировать и на качество кода не влияет — нескромно: мало кто из моих бывших однокурсников программирует лучше меня.
я этого и не знал никогда. Могу догадаться из контекста вопроса или посмотреть в Гугле.
Ничуть не мешает программировать и на качество кода не влияет — нескромно: мало кто из моих бывших однокурсников программирует лучше меня.
Ничуть не мешает программировать и на качество кода не влияет
Чтение литературы, общение с другими программистами происходит легче, когда есть некоторый общий свод терминов-профессионализмов. Если вы завтра начнете, скажем, цикл называть «потоковращателем», то на вашем коде это вряд ли отразится, но сорвать этим какой-нибудь технический митинг вполне реально.
мало кто из моих бывших однокурсников программирует лучше меня.
Если вы не из именитого мирового вуза, то вообще не удивили)
Не потому, что вы, а потому что мотивация людей идти в вузы.
Чтение литературы… происходит легче, когда есть некоторый общий свод терминов-профессионализмов.
Безусловно так.
Но вопрос то в другом — терминологию, которая у джунов/трейни отскакивает от зубов, ибо зубрили совсем недавно — сеньор может уже забыть. Конечное качество его работы все равно будет намного выше и безо всякой терминологии.
общение с другими программистами происходит легче, когда есть некоторый общий свод терминов-профессионализмов.
Гораздо больше терминов из конкретной предметной области.
А вышеупомянутый singleton, ага… прямо представляю как на meeting мы обсуждаем проблему на уровне singleton да замыканий… ну да, конечно.
даже при общении с джунами это не используется.
только что при написании статей об основах программирования или при code review начинающего trainee этот термин и будет использован.
сеньор может уже забыть
Это проблема сеньора. Нет ничего зазорного, чтобы освежать память время от времени. В том числе такими «живительными» походами на интервью.
мы обсуждаем проблему на уровне singleton да замыканий…
Паттерны — это архитектура, вы ее не обсуждаете?
Потом вам дадут джуниора и… пойдет язык узкоспециализированных «хреновинок» и «фиговинок» (=
Это проблема сеньора. Нет ничего зазорного, чтобы освежать память время от времени
В мире, в том числе и в ИТ, есть много интересного помимо этого.
Повторять азбуку — смысла не вижу. Тем более, что речь идет только о названиях, а не о сути вещей.
Сущности вовсю применяются в реальной разработке, а как какая из них называется — кому какое дело.
Паттерны — это архитектура, вы ее не обсуждаете? Потом вам дадут джуниора и… пойдет язык узкоспециализированных «хреновинок» и «фиговинок» (=
В понятиях низкого уровня типа синглтонов???
Те кодеры, которым нужно жевать до такой степени — в обсуждении архитектуры вообще не нужны.
Это проблема сеньора. Нет ничего зазорного, чтобы освежать память время от времени
В вашем представлении сеньор это всего лишь (пусть и очень хороший), но просто «кодер с опытом»? Не-а. Перед сеньором ставят задачи более высокого уровня абстракции, чем где там будет какой класс, а где там static, а где virtual.
Повторять азбуку — смысла не вижу.
Если буквы забываются, то вряд ли будет лишним.
Тем более, что речь идет только о названиях, а не о сути вещей.
Нет же, ТС попросили не название вспомнить, а о значении конкретного ключевого слова. А это уже подсказка в вопросе.
Не представляю даже, как бы сеньор гуглил в случае необходимости: «Ключевое слово виртуальный метод»? «Синтаксис виртуальных методов»?
В понятиях низкого уровня типа синглтонов???
Синглтон — это вполне себе архитектурный паттерн, совсем не низкоуровневый, как и остальные, вроде декораторов, команд и прочих фасадов.
А что же по-вашему архитектура ПО, если не организация и взаимодействие логических блоков?
Нет же, ТС попросили не название вспомнить, а о значении конкретного ключевого слова. А это уже подсказка в вопросе.
Не представляю даже, как бы сеньор гуглил в случае необходимости: «Ключевое слово виртуальный метод»? «Синтаксис виртуальных методов»?
Если собеседуясь «на сеньора» вы получаете такие вот вопросы, а не просьбы рассказать об архитектурах ваших прошлых проектов — можно сразу понять что сеньоров они и не ищут. А используют данный термин всего лишь для манипуляции ЧСВ кандидатов на вакансию.
Вангую — то была обычная галера, перепродающая разработчиков. Не предел мечтаний сеньора. ИМХО, зря он тут так волнуется в статье, что его не взяли.
Последний раз про конкретную технологию (даже не про паттерн, а про тип СУБД, знаком я или нет с ней) меня спрашивали на собеседовании лет 20 назад.
С тех пор на собеседованиях у меня интересовались только тем, могу ли я решить ту или иную конечную задачу, создать определенный конечный продукт, как я предполагаю это сделать (архитектура). А вовсе не то, что называется словом virtual, словом static или словом singleton.
Синглтон — это вполне себе архитектурный паттерн, совсем не низкоуровневый, как и остальные, вроде декораторов, команд и прочих фасадов.
А что же по-вашему архитектура ПО, если не организация и взаимодействие логических блоков?
Повторяю еще и еще раз:
Понятие — да.
Название — нет.
Я не буду давать джуну задание «напиши синглтон».
Задание будет звучать примерно так (возможны вариации, в зависимости от контекста задачи): «все API этой фичи нужно реализовать в одном классе»
Если собеседуясь «на сеньора» вы получаете такие вот вопросы
Перед вами неизвестный человек, трудовую его вы не видели. Есть ненулевая вероятность, что он на самом деле после вузика работает в макдаке и лишь вечерами что-то пытается программировать. Назовите причину, по которой нельзя начать с простых вопросов? Не ограничиваясь ими, разумеется.
Последний раз про конкретную технологию… меня спрашивали ...
Значит, у вас есть талант производить впечатление на интервьюеров или по каким-то другим причинам им не интересно узнавать детали. Ну или вы достаточно редко собеседуетесь.
Понятие — да.
Название — нет.
Речь об общении с другими программистами. Знание понятий вас не освобождает от необходимости обмениваться своими концепциями с другими людьми. Возможно, по тем или иным причинам вам озвучивать это не приходится. Я с моими коллегами обсуждаю это как минимум каждую неделю, не говоря уже о кодревью.
Я не буду давать джуну задание «напиши синглтон».
Вы вполне могли бы сказать на планнинге: «Когда будешь лезть в тот модуль, там поднимается сервис-синглтон XXX, это фасад к жесткому легаси YYY, нужно добавить в него поддержку ZZZ». На треш-языке «понятий» этот текст раздулся бы в несколько раз, как минимум.
Есть ненулевая вероятность, что он на самом деле после вузика работает в макдаке и лишь вечерами что-то пытается программировать. Назовите причину, по которой нельзя начать с простых вопросов?
1) Экономия моего и его времени.
2) Уже озвученная ранее проблема, спец он может быть и хороший, но уже забыть как называются базовые понятия (хотя и уметь их применять)
Сеньора я буду гонять по уже сделанным им проектам, пытаясь понять как он понимает те или иные архитектурные решения.
Работающий после ВУЗа 10 лет в МакДаки — собьётся на мелких деталях «якобы реализованных им проектов» в течение 1-2 минут.
Значит, у вас есть талант производить впечатление на интервьюеров или по каким-то другим причинам им не интересно узнавать детали. Ну или вы достаточно редко собеседуетесь.
То есть «этого не может быть просто потому что этого не может быть»?
В Twitter`e несколько лет назад был каминг-аут опытных разработчиков (там отметились и разработчики из Гугля, автор Rails (тот, что для Ruby) и пр. ребята с опытом), которые признавались, что не смогут пройти собеседование, если их будут спрашивать о простейших вещах (там есть конкретные примеры что именно). Была целая статья на Хабре, может, кто вспомнит и даст ссылку.
Речь об общении с другими программистами. Знание понятий вас не освобождает от необходимости обмениваться своими концепциями с другими людьми.
Я уже ответил на это и привел пример как можно простыми словами донести суть.
Еще раз обращаю ваше внимание — специфические термины из автоматизируемой прикладной области создают куда как больше проблем, чем надуманная проблема с «правильным именованием синглтонов».
Вы вполне могли бы сказать на планнинге: «Когда будешь лезть в тот модуль, там поднимается сервис-синглтон XXX, это фасад к жесткому легаси YYY, нужно добавить в него поддержку ZZZ». На треш-языке «понятий» этот текст раздулся бы в несколько раз, как минимум.
Не забывайте про цели.
Задание должно быть прежде всего понятым, как можно более однозначным.
А не «сформулированным красивыми умными словами, чтобы окружающие преисполнились благоговения перед таким умным перцом».
1) Экономия моего и его времени.
Вам не составит труда ответить на пару простых вопросов, вы же профессионал.
спец он может быть и хороший, но уже забыть как называются базовые понятия
Еще раз: «спец» не может вспомнить одну из основных синтаксических конструкций своего языка, название которой ему назвали. Он не смог сказать для чего она нужна.
В Twitter`e несколько лет назад был каминг-аут опытных разработчиков (там отметились и разработчики из Гугля, автор Rails (тот, что для Ruby) и пр. ребята с опытом)
Если там кто-то из дотнетчиков или джавистов рассказывает, что не понимают устройства виртуальных методов или замыкания — я с удовольствием почитал бы.
специфические термины из автоматизируемой прикладной области создают куда как больше проблем
Из этого не следует, что вы не будете пользоваться абстракциями. Синглтонам напревать, какой товар продает ваш бизнес.
Задание должно быть прежде всего понятым, как можно более однозначным.
Ну так для этого и существуют профессионализмы. А отсутствие деталей — это совсем не лаконичность.
Еще раз: «спец» не может вспомнить одну из основных синтаксических конструкций своего языка, название которой ему назвали
Назвали???
Начиная с определенного момента постоянной практики вырабатывается автоматизм использования понятия.
Это как в начале изучения иностранного языка вы все слова-предложения проговаривайте мысленно перед произнесением (иногда это заметно даже, губы шевелятся), а потом просто начинаете думать на иностранном языке. И, легко поняв суть на иностранном языке, при том вы можете столкнуться с проблемой подобрать подходящее слово для перевода на родной язык.
Да я свои пароли только тактильно помню — могу набрать их на клавиатуре вслепую, но не могу ни записать на бумаге ни произнести вслух.
Начиная с определенного момента постоянной практики вырабатывается автоматизм использования понятия.
Ассоциации рушатся и память стремительно деградирует?
Это как в начале изучения иностранного языка
Языки программирования синтаксически сильно проще языков естественных, да еще и большинство трендовых — си-подобные, что еще больше снижает вероятность внезапно забыть семантику основных ключевые слов.
я свои пароли только тактильно помню — могу набрать их на клавиатуре вслепую, но не могу ни записать на бумаге ни произнести вслух.
Возможно, дело в паролях, но я никогда таким не страдал. Путать — возможно, но не забывать.
Языки программирования синтаксически сильно проще языков естественных, да еще и большинство трендовых — си-подобные, что еще больше снижает вероятность внезапно забыть семантику основных ключевые слов.
Простота языка программирования по сравнению с естественными языками позволяет автоматизму использования выработаться еще быстрее.
Зачем мне знать, что замыкание называется именно замыканием? Я его использовал еще за 20 лет до того, как узнал как оно называется.
Зачем мне знать, что замыкание называется именно замыканием?
Чтобы эффективно общаться с другими.
Зачем мне знать, что замыкание называется именно замыканием?
Чтобы эффективно общаться с другими.
Пописывать статейки или преподавать — да. В реальной работе — нет.
Не представляю чтобы на meeting мы обсуждали проект на уровне — «тут нужно замыкание».
Повторю еще раз:
Только начинающие столь серьезно относятся к недавно зазубренным названиям. Полагаю потому, что им пока что больше нечего обсудить, нет опыта в более общих вещах.
Потому и тестирование описанное в статье под которой мы и беседуем — это тестирование для джуна/трейни. Оно даже миддла уже никак не характеризует.
Оно даже миддла уже никак не характеризует.
Такие вопросы нужны не для того, чтобы определять уровень знаний. Это чекпоинт о том, что с человеком вообще стоит заводить технические беседы о высоком-архитектурном не думая о том, реально он бестолковый или просто слова забыл.
Такие вопросы нужны не для того, чтобы определять уровень знаний. Это чекпоинт о том, что с человеком вообще стоит заводить технические беседы о высоком-архитектурном не думая о том, реально он бестолковый или просто слова забыл.
Бухгалтеру или кассиру вообще запрещено считать в уме. Обязательным является использование калькулятора.
Знания школьника начальных классов разумно начинать проверять с таблицы умножения.
Тут вспомнилась еще проблемка: часть знаний, полученных в ВУЗе у меня в голове русскоязычная, а часть, изученная самостоятельно — англоязычная.
Поэтому я тоже не знаю, что такое «замыкание», хотя знаю, что такое closure.
Поэтому я тоже не знаю, что такое «замыкание», хотя знаю, что такое closure.
1) Экономия моего и его времени.
Вам не составит труда ответить на пару простых вопросов, вы же профессионал.
Труда не составит, но незачем.
Я уже давно не смотрю на вирусы компьютеры знакомых только потому, что «тыж программист».
Серьезно, я даже джунов на собеседовании никогда не гонял на базовые знаний по virtual, static и singleton.
Мне всегда интересно узнать как человек оценивать с технической точки зрения выполненные им в других фирмах проекты (для студентов спрашиваю про курсовые/дипломные/пет-проекты).
Джунам давал задачу спроектировать в РСУБД модель.
Имхо это лучше характеризует «софтверного инженера», чем знание правильных названий синтаксических конструкций.
Языки программирования… довольно быстро можно выучить очередной язык программирования.
Имхо, только начинающие переоценивают знание языка программирования. Полагаю потому, что пока это наилучшее их достижение в ИТ, на которое потрачено много времени, отчего бы не похвастать знаниям.
Однако ничего такого волшебного в знании языка программирования нет. Ну примерно как слесарь тащился бы от того, что знает чем отличается рожковый ключ от накидного, а тот от головки.
То есть в кругу непрограммистов или студентов-айтишников ты может и полубог, раз хорошо знаешь язык программирования. Но по сравнению с другими твоими коллегами — знание языка программирования это ничего особенного. Ну такое же знание, как и знание чем отличается клик левой кнопкой мыши от клика правой кнопки мыши.
А вот то как человек понимает, к примеру, потенциальные узкие места в программе — что тормозит чаще всего именно ввод-вывод и т.п… — это реально полезные знания «софтверного инженера».
И соглашусь и не соглашусь одновременно. С одной стороны да, освоить новый язык высокого уровня (говорю про знакомые парадигмы, пока ни одного функционального не освоил) на базовом уровне — уровень нескольких десятков часов наверно. Освоить новую экосистему, поведение компиляторов/интерпретаторов, рантайма, библиотеки, паттерны, стандартную библиотеку (в т.ч. что там в потрохах структур данных и алгоритмов) и т.п. — может быть очень долгим.
Ну и я не беру экстремальные случаи вроде плюсов, и близких к ним по сложности с UB и подобным.
Ну и я не беру экстремальные случаи вроде плюсов, и близких к ним по сложности с UB и подобным.
Труда не составит, но незачем.
Сэкономите время интервьюеру. Напоминаю, что вашу трудовую никто еще не видел. Собеседуемый кандидат вполне может оказаться амбициозным начинающим.
Собеседуемый кандидат вполне может оказаться амбициозным начинающим.
Не может.
Я выше расписал свою методу собеседования:
Беседа о реальных проектах. Какие там плюсы минусы в тех или иных решениях.
За первую минуту, человек без опыта сольется.
Более того, я наблюдал как собеседуют кандидатов менее опытные коллеги. Они действительно практикуют так как вы и описали — гоняют по тем вещам, что зубрили недавно в ВУЗе. Потому как это пока единственное, что они могут проверить у кандидатов.
Если мне зададут вопрос про что то типа полиморфизм — я просто попрошу (спокойным уверенным голосом, это важно), чтобы меня собеседовал старший разработчик. Всегда проканывало.
Я выше расписал свою методу собеседования: Беседа о реальных проектах.
Вы исходите из того, что перед нами честный и благородный человек, с настоящим опытом. А если это хитрый засранец, то вы его минут 20 будете выводить на чистую воду, продираясь через витиеватые потоки сознания. Вдоволь намучившись, в итоге прицепитесь к какой-нибудь мелочи, вроде virtual, которую никак не может не знать опытный человек (только уже по вашему мнению), чтобы просто получить повод прекратить эти мучения. Бам! У нас новая нытливая статья на хабре)
Ведь мы тут читали мнение только одной стороны, в реальности все может быть немного иначе…
А если это хитрый засранец, то вы его минут 20 будете выводить на чистую воду
Возможно вы правы, возможно первые подозрения у меня возникнут аж через целых 2 минуты.
Ловите лайв-хак: беседу с кандидатом на вакансию нужно направлять в русло нужно вам. Для выяснения квалификации беседовать нужно по тем аспектам проектов кандидата на вакансию, в которых человек, проводящий собеседование, сам хорошо разбирается.
20 минут слушать, когда человек пургу гонет — да, такое бывает. Серьезно, бывает. Ради эстетического удовольствия, чтобы потом поржать с коллегами. Я еще иногда, когда вижу такого кандидата, приглашаю коллегу-другого послушать. Не этично конечно, но все мы люди, всем хочется заряда хорошего настроения на рабочий день.
Еще раз: «спец» не может вспомнить одну из основных синтаксических конструкций своего языка, название которой ему назвали. Он не смог сказать для чего она нужна.
Нет. Человек не смог вспомнить связь слова "виртуал" с конкретным механизмом работы. Он знает, для чего нужен этот механизм.
И вопрос был "Что такое виртуал?", то есть какой механизм обозначает это слово, а не о том, для чего нужен этот механизм.
Если человек заявляет, что он может программировать на некотором языке, то со связями слов с семантикой быть не должно. Иначе это прекрасный теоретик, может даже архитектор, но никак не программист.
Если человек заявляет, что он может программировать на некотором языке, то со связями слов с семантикой быть не должно. Иначе это прекрасный теоретик, может даже архитектор, но никак не программист.
Это показывает, что человек не преподаватель только и всего.
Скорее как раз, что терминология «от зубов отскакивает» и есть необходимое (не достаточное) условие хорошего чистого теоретика.
Архитекторы программных систем, не являющиеся программистами? Это фантастика. Такие вообще существуют? Сколько таких видели?
Это показывает, что у человека очень слабая память. Можно забыть само слово, но не его значение.
Под «являться» я подразумеваю уклон в практику (т.е. именно пишет код, а не только пулл-реквесты смотрит в перерывах между митингами), которая не позволяет забыть синтаксис основного языка.
Скажем так, я редко встречаю конторы, где есть настоящий dedicated-архитектор (у которого должность в трудовой так называется, а не просто тимлид, тянущий еще одну лямку).
Архитекторы программных систем, не являющиеся программистами? Это фантастика. Такие вообще существуют? Сколько таких видели?
Под «являться» я подразумеваю уклон в практику (т.е. именно пишет код, а не только пулл-реквесты смотрит в перерывах между митингами), которая не позволяет забыть синтаксис основного языка.
Скажем так, я редко встречаю конторы, где есть настоящий dedicated-архитектор (у которого должность в трудовой так называется, а не просто тимлид, тянущий еще одну лямку).
Это показывает, что у человека очень слабая память. Можно забыть само слово, но не его значение
Кто то говорит про «забыть значение»?
Перечитайте статью, перечитайте комментарии — везде написано про «забыть термин, забыть название».
Проблема в другом — а как вы простым способом сможете обсудить понятие, если нет названия.
Я вас понимаю, вам не хочется заморачиваться, хочется сказать одно слово — услышать его развернутый ответ — и сразу понять подходит человек вам или нет.
Но так не бывает — отобрать хорошего кандидата, это большой труд. Это именно что собеседование. От слова «беседа».
Перечитайте статью, перечитайте комментарии — везде написано про «забыть термин, забыть название».
Перечитал статью. ТСу назвали термин, он не смог рассказать о его значении.
Я не знаю термина «замыкание» (если только оно не короткое). Я знаю термин «closure».
Или Вы хотите сказать, что в повседневной речи Вы повсюду говорите «ЭВМ» вместо «компьютер»?
Или Вы хотите сказать, что в повседневной речи Вы повсюду говорите «ЭВМ» вместо «компьютер»?
Скажем так, я редко встречаю конторы, где есть настоящий dedicated-архитектор (у которого должность в трудовой так называется, а не просто тимлид, тянущий еще одну лямку).
Разумеется.
Потому что любой программист сам себе архитектор на своем участке работы. Это особенность профессии — одно из привлекательнейших мест профессии, всегда есть место творчеству.
Ну а суперсложные системы, где требуется прямо таки выделенный архитектор — большая редкость.
В настоящее время наблюдается как раз переход к большей самостоятельности разработчиков, в большей их полноценности, к большей комплексности (тот же DevOps). Разделение работы архитектора по всей вертикали разработчиков — снижает нагрузку на главного архитектора.
Нынче выделенный архитектор — это такая экзотика, что было бы интересно услышать от вас описание конкретных проектов с выделенными архитекторами, в которых вы лично принимали участие.
Вы в курсе, что человек мыслит образами, а не словами? Именно поэтому чтобы читать документацию на английском не надо заново учиться программированию. Выражения "цикл for" или "for loop" связаны с одним образом. У человека есть понятие N, которое по-разному называется на разных языках.
А еще есть такая штука как фокус внимания. И если в конкретной ситуации нейрон с нужным понятием дает сигнал меньше чем другой, на него внимание может не перейти, или перейти не сразу. Именно поэтому при неравномерном шуме сложно сосредоточиться, резкие изменения отвлекают внимание, а при монотонном шуме проще.
А еще это ассоциация обратная той, которую хотят проверить. Умение пользоваться механизмом означает, что у человека о нем есть представление, и при подходящей ситуации он напишет нужное ключевое слово. Ситуация — механизм — слово. А вы таким вопросом проверяете обратную ассоциацию слово — механизм, причем за короткое время в нестандартной ситуации (когда внимание направлено на многие другие факторы), и почему-то делаете вывод, что долгое время обратной ассоциации означает отсутствие прямой. В некоторых комментариях правильно пишут — если человек замялся, надо просто пояснить что вы имеете в виду, задать дополнительные вопросы.
При этом в работе такая ситуация вообще ни на что не влияет. Витает человек мыслями в низкоуровневом баге, подходит к нему человек по другому вопросу "Там надо виртуал сделать — Что за виртуал? — Ну чтобы метод переопределить — А-а, да, это подойдет".
Вы в курсе, что человек мыслит образами, а не словами?
Вы примерные рисунки компилируете или все же текст, ограниченных некоторыми синтаксическими правилами?
подходит к нему человек по другому вопросу «Там надо виртуал сделать — Что за виртуал? — Ну чтобы метод переопределить — А-а, да, это подойдет».
А если он слово «метод» забудет? Или «переопределить»?
Вы примерные рисунки компилируете или все же текст, ограниченных некоторыми синтаксическими правилами?
Вы думаете, текст в голове как-то по-другому обрабатывается? И у вас же претензия к тому, что человек якобы не знает, как этот текст работает. А механизм работы в этом строгом тексте не описан. К чему тогда этот вопрос?
А если он слово «метод» забудет? Или «переопределить»?
А если он на полминуты забудет слово "метод" или "переопределить", то будет ровно то же самое. "Напиши виртуал вон там". К чему эти передергивания? А если он их на собеседовании вспомнит, а на работе забудет?
Вы думаете, текст в голове как-то по-другому обрабатывается?
У меня есть ассоциация со словом virtual, которая связывает его со значением. Я могу забыть слово, но встретив его от меня уже не ускользнет смысл.
А если он на полминуты забудет слово «метод» или «переопределить», то будет ровно то же самое.
Непройденное интервью, ошарашенный джуниор, насмешки коллег.
К чему эти передергивания?
Почему передергивания? Если у некоторых сеньоров случаются провалы в памяти, то вероятность, что они вдруг забудут что-то важное помимо ключевого слова — ненулевая.
Я могу забыть слово, но встретив его от меня уже не ускользнет смысл
А все, кто в конкретной ситуации ведет себя не так как вы, значит не специалисты.
Оффлайн: Записки старого виртуала
Мобайл переходит в виртуал?
Правильный ли смысл подсказывает вам ваша ассоциация?
Непройденное интервью, ошарашенный джуниор, насмешки коллег.
Ну конечно, необоснованными высказываниями можно доказать что угодно. С такой логикой у интервьюера можно много кого завалить на интервью.
Если у некоторых сеньоров случаются провалы в памяти, то вероятность, что они вдруг забудут что-то важное помимо ключевого слова — ненулевая.
Это не провал в памяти, а особенность работы нейронов. Ключевое слово не важно само по себе, важно как работает то, что оно означает. Вероятность что-то забыть, важное или нет, ненулевая у подавляющего большинства людей. Поэтому передергивание.
Правильный ли смысл подсказывает вам ваша ассоциация?
Ассоциаций несколько, разумеется, но под контекст подходит одно.
необоснованными высказываниями можно доказать что угодно.
Нельзя.
Но у нас есть чистосердечное признание: на интервью необходимого вспомнить не удалось, ни сразу, ни за 30 секунд, ни за остальные минуты.
Это не провал в памяти, а особенность работы нейронов.
Это тоже особенность работы нейронов.
Ассоциаций несколько, разумеется, но под контекст подходит одно.
Ага, уже контекст появился. Идем дальше. То есть если контекст слишком общий, то правильная ассоциация может не появиться за короткое время. Нет, объяснение "контекст задан темой интервью" не подходит, так же как и "контекст указанных статей — ресурс для программистов, значит слово 'виртуал' должно ассоциироваться с языком программирования".
Вообще, все ваши "а если" можно проверить простым способом — а именно, уточнить контекст вопроса. Вот если бы интервьюер уточнил как-нибудь типа "атрибут метода такой, для чего он нужен?", а автор статьи не ответил, тогда да, можно было бы говорить, что автор понял что имеется в виду, но не знает зачем оно нужно.
на интервью необходимого вспомнить не удалось, ни сразу, ни за 30 секунд, ни за остальные минуты.
Так не было остальных минут. "Интервью, естественно, кончается. Я закрываю скайп и, конечно, тут же вспоминаю, что за virtual.". А "сразу" было, "тут же" это синоним "сразу".
уточнить контекст вопроса. Вот если бы интервьюер уточнил как-нибудь типа «атрибут метода такой, для чего он нужен?»
напомнило
У каждой уважающей себя команды КВН есть номерок, как бестолковый студент в Nый раз приходит сдавать какой-то экзамен, а задолбавшиеся преподаватели чуть ли не в открытую подсказывают, но ему это не особо помогает.
Это уже подсказка, а не контекст. А насчет контекста, заданного тематикой обсуждения — все так. Перед этим был как минимум один вопрос о ключевых словах.
Так не было остальных минут.
Наверное, стоило держать свечку, чтобы иметь такую уверенность. Я там не присутствовал и спорить с вами не стану.
Ага, уже контекст появился.
А он, простите, куда-то пропадал? Мы же обсуждаем именно собеседование, именно на сеньора, именно в программировании, на вполне определенном ООП-языке.
Вот этих «если контекст слишком общий» в этой ситуации быть не может, разговор идет о вполне конкретном языке программирования и его семантике. Было бы странно предположить, что на собеседовании по C# слово virtual означает что-то из области форумных альтер-это или чего-то еще далекого от программирования. Если человек начинает на собеседовании на позицию программиста искать значения в своих глубоких познаниях по философии или истории, видимо, ему надо поработать над умением следовать контексту или, возможно, обратиться к психологу для борьбы с рассеянным вниманием или какими-то другими когнитивными расстройствами.
Вот если бы интервьюер уточнил как-нибудь типа «атрибут метода такой, для чего он нужен?»
Вот эти уточнения «ну этот virtual, который атрибут метода, знаешь, такой, который перед void обычно пишется»… Кхм… Детский сад, честное слово. Еще со студентами пойму, когда сильно хочется на экзамене за уши вытянуть. Но при собеседовании человека с опытом в языке, претендующего на позицию сеньор-разработчика, настоящего профессионала в профессии.
Не, вы это сейчас серьезно? Реально?
серьезно? Реально?
Серьезно и реально. Это особенность работы нейронов, и в указанных условиях такая реакция может быть. Да и тут в комментариях есть примеры.
Если передергивать, то конечно детский сад. А уточнение вопросов это нормальный рабочий процесс. "Не знает" и "не успел вспомнить" это разные вещи, как бы вам ни хотелось думать иначе. Если вы хотите узнать реальное положение дел, вы уточните вопрос, не хотите, дело ваше, только не надо потом удивляться результатам проверки за несколько секунд)
Отличные ссылки вы привели. Про контекстное восприятие и влияние окружения на память.
Давайте подумаем. Контекстное восприятие — это про то, что человек может одни и те же слова воспринимать по разному в различных контекстах. Бессмысленный сам по себе текст «по мановению волшебной палочки» превращается во вполне понятный при задании контекста, а, находясь в одном контексте, человек может не воспринять оторванные от контекста слова. О чем это нам говорит в контексте собеседования по C#?
Да ни о чем! Если бы в контексте разговора про C# человека спросили «а какие еще значения слова virtual вы знаете», а он не смог бы привести ни единого примера — было бы «в точку». Когда вопрос задается в изначальном контексте беседы — вообще не связанные случаи.
А про бедных подопытных подводников… Кхм, выяснилось, что а) в стрессовой ситуации запоминание происходит хуже (мимо — ключевое слово virtual человек, видимо, не в состоянии стресса изучал, т.к. статья не начинается со слов «Я программист-самоучка с огромным стажем, изучать C# начал на войне. Я взахлеб читал труды Саттера и Мейера в окопах, под шквальным огнем артиллерии противника...») б) слова лучше вспоминаются в окружении, где их запомнили (тоже мимо, т.к. собеседование происходило по скайпу, т.е. человек находился примерно там, где изучал. А если наличие скайпа в довесок к окружающей атмосфере его квартиры — это фактор, настолько нарушающий его равновесие, что он теряет «экспертизу», то и возможность работы его в офисе вне собственной квартиры тоже можно поставить под сомнение).
В том то и дело, что это нормальный рабочий процесс. И то, что человек не уточнил, а «не смог ответить» говорит всяко не в его пользу на позицию «сеньора».
Давайте подумаем. Контекстное восприятие — это про то, что человек может одни и те же слова воспринимать по разному в различных контекстах. Бессмысленный сам по себе текст «по мановению волшебной палочки» превращается во вполне понятный при задании контекста, а, находясь в одном контексте, человек может не воспринять оторванные от контекста слова. О чем это нам говорит в контексте собеседования по C#?
Да ни о чем! Если бы в контексте разговора про C# человека спросили «а какие еще значения слова virtual вы знаете», а он не смог бы привести ни единого примера — было бы «в точку». Когда вопрос задается в изначальном контексте беседы — вообще не связанные случаи.
А про бедных подопытных подводников… Кхм, выяснилось, что а) в стрессовой ситуации запоминание происходит хуже (мимо — ключевое слово virtual человек, видимо, не в состоянии стресса изучал, т.к. статья не начинается со слов «Я программист-самоучка с огромным стажем, изучать C# начал на войне. Я взахлеб читал труды Саттера и Мейера в окопах, под шквальным огнем артиллерии противника...») б) слова лучше вспоминаются в окружении, где их запомнили (тоже мимо, т.к. собеседование происходило по скайпу, т.е. человек находился примерно там, где изучал. А если наличие скайпа в довесок к окружающей атмосфере его квартиры — это фактор, настолько нарушающий его равновесие, что он теряет «экспертизу», то и возможность работы его в офисе вне собственной квартиры тоже можно поставить под сомнение).
А уточнение вопросов это нормальный рабочий процесс.
В том то и дело, что это нормальный рабочий процесс. И то, что человек не уточнил, а «не смог ответить» говорит всяко не в его пользу на позицию «сеньора».
А про бедных подопытных подводников… Кхм, выяснилось, что а) в стрессовой ситуации запоминание происходит хуже (мимо)
Эти ссылки — это не аналогии, а информация для размышления о причинах. У примеров по ссылкам и в статье одна причина — механизм работы нейронов. Они показывают, что контекст влияет на уровень реакции нейронов и что в отсутствии достаточного уровня реакции от нужных нейронов может происходить забывание известных фактов. Это не значит, что факты полностью забыты или не были известны никогда, это значит, что конкретно в этой ситуации они не вспомнились.
В статье это и описано: исчез фактор, отвлекающий внимание (закончился разговор) — внимание переключилось на нужную группу нейронов, которая давала меньший уровень реакции.
И то, что человек не уточнил, а «не смог ответить»
Вы же говорили, что уточнения это детский сад, и профессионалы не должны ничего уточнять? Судя по описанному, интервью сразу закончилось, и можно сделать вывод, что даже если бы уточнил "что вы имеете в виду?", то результат был бы то же самый. Собеседующий просто не захотел продолжать разговор.
И я спорю не с тем, что надо знать на позицию Senior C#, я тоже сразу про наследование подумал, а с утверждением "не ответил сразу на такой вопрос — значит не знает как работает и не умеет пользоваться". Есть более вероятные причины неответа, и более подходящие способы проверить знание.
У примеров по ссылкам и в статье одна причина — механизм работы нейронов.
Точно так же можно объяснить и абсолютную профнепригодность. Единственная причина — механизм работы нейронов.
Это не значит, что факты полностью забыты или не были известны никогда, это значит, что конкретно в этой ситуации они не вспомнились.
Это значит, что в определенных (стрессовых) условиях у человека из памяти могут выпадать базовые понятия его экосистемы. Кхм… Вы же понимаете, что дорогостоящий сотрудник — это
И да, собеседование, ровно как и экзамен — лотерея. Механизм далек от идеала, но у него цель такая — отсеять слабых кандидатов за адекватный/приемлемый по затратам срок. Если вы сможете предложить более адекватный путь поиска сотрудника при тех же (или сравнимых, или лучших с точки зрения соотношения цена/качество) ресурсозатратах — да вас на руках носить будут, и денег дадут.
А все эти «да я наследованием не пользовался никогда, и не собираюсь». Хм… Собственно, если про него спрашивают, есть ненулевая вероятность, что оно где-то уже используется, и оно нужно в конкретных кейсах. Как минимум его нужно будет поддерживать или, как минимум, постепенно рефакторить существующую реализацию. А это значит, что соискатель должен сначала понять, что в коде происходит, а уже потом написать «по-правильному». И то, его мнение о «правильности» подхода должно как-то коррелировать с мнением остальных членов команды. А вот эти «я перепишу правильно, и мне плевать, что остальные не понимают, как это работает» — чистой воды производственный саботаж. А позиция «я разраб с опытом, я лучше знаю, как должно быть, а вы тут говно пишете, никуда не годится» на этапе проходжения собеседования — это либо снобизм, либо откровенная глупость собеседуемого. Он еще даже не пришел в монастырь, а устав свой уже продекларировал. Собственно, не вижу ни единой причины, по которой он мог бы подойти в команду.
Вы же говорили, что уточнения это детский сад, и профессионалы не должны ничего уточнять?
Это вы меня с кем-то путаете. Профессионалы могут и должны уточнять детали вопроса. Но это они сами должны задавать уточняющие вопросы, а не ждать, пока собеседующий/вопрошающий начнет подсказки выдавать. Это уже детство.
Есть более вероятные причины неответа, и более подходящие способы проверить знание.
Причины «неответа» автор сам назвал же. «Никогда не пользовался», «забыл» и «считаю гогно-практикой». «И ваще, кто вы такие, чтобы задавать мне такие тупые вопросы». Диагноз — снобизм.
А насчет более подходящих способов проверить знание. В адекватные сроки? Приемлемые с точки зрения стоимости способов? Подскажете?
Я выше писал пример вопроса. "Приведите пример переопределения метода в наследнике". Проверяет ровно то же самое, но задействует ассоциации, более приближенные к реальной работе. Прямые, а не обратные, "взаимосвязь в конкретной ситуации — ключевое слово", а не "ключевое слово в глобальном контексте — взаимосвязь".
Можете продолжать передергивания в стиле "сегодня он играет джаз", только это не приведет вас к правильным выводам. Собеседование с такими вопросами пройдет начинающий, который скопировал из документации определения в блокнотик. Если вас это устраивает, дело ваше.
Понимаете, в чем проблема. В контексте собеседования на позицию сеньора все «мне не понравилась формулировка вопроса» — это из детско-юношеской лиги. Да, можно было сформулировать тысячей и одним более удачным способом, суть вопроса одна «опишите ваше представлении о наследовании». Нужны «более четкие ассоциации»? Я вас умоляю, какие более четкие, чем ключевое слово языка, ассоциации нужны сеньору?
«Сеньор» не до конца понял, про что его спрашивают, про «public virtual void methodName()» или про «class ClassA: virtual ClassB» — ну так пусть он уточнит, его про виртуальное наследование класса спрашивают, или про виртуальные методы. Это про него, как про профессионала больше скажет.
У него есть, как минимум, два правильных ответа: «virtual/override как инструмент переопределения метода в наследуемом классе» и «виртуальное наследование класса, а также проблемы с ним связанные (можно от себя добавить, почему не считаешь это хорошей практикой)».
Вместо этого «сеньор» выбирает ответ «да это для джунов, я вообще не обязан этого знать, я проектирую мегасложные системы и ваще». Простите, дорогой «сеньор», человек, который проектирует системы, называется системный архитектор. Вот для него знание принципов наследования в конкретном языке не является обязательной дисциплиной. А сеньор должен знать все механики языка, даже если не пользуется ими, или считает, что так делать не надо.
Смотрите, есть два «плохих» варианта:
1. Вы отсеяли достойного кандидата.
2. Вы не отсеяли плохого кандидата.
В первом случае вы просто найдете другого, который покажется вам более достойным. Во втором — вы месяц-другой будете платить сеньорскую зарплату слабому разработчику, который еще и достаточно высокого о себе мнения, потом еще месяц-другой будете решать, что с ним делать, и заново искать сотрудника.
Собственно, лишний раз отфильтровать толкового разраба, как правило, сильно дешевле, чем взять вот такой «золотой… колпак» на позицию сеньора.
1. Для этого по скайпу и собеседуют, чтобы в блокнотик не подглядывал.
2. А кто сказал, что дальше сложных вопросов не планируется? Мне вот кажется нормальным задать 2-3 тупеньких вопроса на «знание базы», чтобы по-быстрому отсеять реальных «самозванцев», а потом, с теми, кто остался, перейти к серьезному обсуждению. Кучу времени, собственно, сэкономить может. К тому же такой подход позволит понять, что человек, например, на сеньора не тянет, но при этом — вполне себе миддл, и предложить ему вакансию попроще. Не?
Ну, собственно, мы этого не узнаем, потому что «наш» кандидат просто на 3-м вопросе завалился. Может, просто до «второго уровня» не дошел?
«Сеньор» не до конца понял, про что его спрашивают, про «public virtual void methodName()» или про «class ClassA: virtual ClassB» — ну так пусть он уточнит, его про виртуальное наследование класса спрашивают, или про виртуальные методы. Это про него, как про профессионала больше скажет.
У него есть, как минимум, два правильных ответа: «virtual/override как инструмент переопределения метода в наследуемом классе» и «виртуальное наследование класса, а также проблемы с ним связанные (можно от себя добавить, почему не считаешь это хорошей практикой)».
Вместо этого «сеньор» выбирает ответ «да это для джунов, я вообще не обязан этого знать, я проектирую мегасложные системы и ваще». Простите, дорогой «сеньор», человек, который проектирует системы, называется системный архитектор. Вот для него знание принципов наследования в конкретном языке не является обязательной дисциплиной. А сеньор должен знать все механики языка, даже если не пользуется ими, или считает, что так делать не надо.
не приведет вас к правильным выводам
Смотрите, есть два «плохих» варианта:
1. Вы отсеяли достойного кандидата.
2. Вы не отсеяли плохого кандидата.
В первом случае вы просто найдете другого, который покажется вам более достойным. Во втором — вы месяц-другой будете платить сеньорскую зарплату слабому разработчику, который еще и достаточно высокого о себе мнения, потом еще месяц-другой будете решать, что с ним делать, и заново искать сотрудника.
Собственно, лишний раз отфильтровать толкового разраба, как правило, сильно дешевле, чем взять вот такой «золотой… колпак» на позицию сеньора.
Собеседование с такими вопросами пройдет начинающий, который скопировал из документации определения в блокнотик.
1. Для этого по скайпу и собеседуют, чтобы в блокнотик не подглядывал.
2. А кто сказал, что дальше сложных вопросов не планируется? Мне вот кажется нормальным задать 2-3 тупеньких вопроса на «знание базы», чтобы по-быстрому отсеять реальных «самозванцев», а потом, с теми, кто остался, перейти к серьезному обсуждению. Кучу времени, собственно, сэкономить может. К тому же такой подход позволит понять, что человек, например, на сеньора не тянет, но при этом — вполне себе миддл, и предложить ему вакансию попроще. Не?
Ну, собственно, мы этого не узнаем, потому что «наш» кандидат просто на 3-м вопросе завалился. Может, просто до «второго уровня» не дошел?
"мне не понравилась формулировка вопроса"
«Сеньор» не до конца понял, про что его спрашивают, про «public virtual void methodName()» или про «class ClassA: virtual ClassB»
Вместо этого «сеньор» выбирает ответ «да это для джунов, я вообще не обязан этого знать, я проектирую мегасложные системы и ваще».
Нет, нет, и нет. Это ваши домыслы.
Для этого по скайпу и собеседуют, чтобы в блокнотик не подглядывал.
Открыть скайп и рядом блокнот, скроллить мышкой.
А кто сказал, что дальше сложных вопросов не планируется? Мне вот кажется нормальным задать 2-3 тупеньких вопроса на «знание базы», чтобы по-быстрому отсеять реальных «самозванцев»
Так в том и дело, что не проверяют ваши вопросы "знание базы", не проверяют умение пользоваться, а потому не отсеивают реальных самозванцев. Самозванец заучит определения и пройдет эти вопросы. Где тут экономия времени? Если его должны отсеять сложные вопросы, почему бы тогда их сразу не задать?
Да суть в общем-то не в этом, а в неправильном выводе. В указанной ситуации неответ не означает незнание, и ситуация "не ответил, но знает" возможна. А вы пытаетесь доказать, что это не так. Если не хотите рисковать и у вас за дверью толпа специалистов высокого уровня, ваше право. А кто не может долго найти хорошего специалиста, тот задумается.
Нет, нет, и нет. Это ваши домыслы.
Перечитайте статью, что ли. Там в вину собеседующим даже отсутствие веб-камеры у соискателя ставится, а также то, что дешевой веб-камеры не оказалось в магазине по соседству.
Самозванец заучит определения и пройдет эти вопросы.
По крайне мере, самозванец, который даже заучить определения не озаботился, на этом этапе отсеется.
Если его должны отсеять сложные вопросы, почему бы тогда их сразу не задать?
Потому что, например, постановка действительно сложного вопроса может занять больше времени, чем «блиц» по 3 вопросам на знание базовых терминов.
Да суть в общем-то не в этом, а в неправильном выводе. В указанной ситуации неответ не означает незнание, и ситуация «не ответил, но знает» возможна.
Стоп. Давайте разберемся, что вы вообще предлагаете…
Вот у вас собеседование. Вы задает вопросы, соискатель на них отвечает. По ответам на вопросы вы должны составить начальное представление о знаниях соискателя.
Вы задаете вопрос, соискатель отвечает — окей, будем считать, что знает.
Вы задаете еще один. Соискатель не отвечает. Предположим, что «знает, но забыл»?
И как оценивать? Брать, в смысле, всех? А то они волнуются на собеседовании, что уж судить строго! Они же говорят, что знают. Просто забыли! А на работу выйдут и сразу вспомнят! И все-все-все будет хорошо, и в небе взойдет радуга, и код будет писаться сам, и вообще наступит всеобщее процветание.
Вам это так видится?
А вы пытаетесь доказать, что это не так. Если не хотите рисковать и у вас за дверью толпа специалистов высокого уровня, ваше право. А кто не может долго найти хорошего специалиста, тот задумается.
Я не пытаюсь доказать, что какие-то «факапы» невозможны. Я пытаюсь сказать, что слюни на тему «меня не взяли, это несправедливо» — абсолютно левая чушь. Если ты действительно специалист уровня сеньора — пофиг тебе на то, что тебя здесь забрили. У тебя работодатели в очередь стоят, сеньоры — дефицит. А если ты бегаешь по конторам, и везде собесы проваливаешь, сидишь без работы и плачешься… Так может, просто планочку понизить. Может, не тянешь на сеньора, просто? Попробуй на миддла пособеседоваться.
Давайте разберемся, что вы вообще предлагаете…
И как оценивать?
Как оценивать, я уже несколько раз написал.
Я предлагаю не делать вывод, что если человек замялся, значит не знает, задавать дополнительные вопросы, если так случилось, и не задавать вопросы, указанные в статье, по причине несоответствия целям проверки.
А также предлагаю не преувеличивать и не делать на основе этого далеко идущих выводов.
"абсолютно левая чушь" "плачешься" "планочку понизить" "может, не тянешь"
Или может собеседования такие, что не показывают правильную картину.
А учитывая ваше эмоциональное отношение к людям, квалификацию которых вы не знаете наверняка, "топище" из статьи уже не выглядит преувеличением.
Я предлагаю не делать вывод, что если человек замялся, значит не знает, задавать дополнительные вопросы, если так случилось
Ну, т.е., все таки:
— Что такое virtual?
молчание…
— Ну, который «виртуальное наследование».
молчание…
— Ну, когда class ClassA: virtual ClassB — это вот что означает?
молчание…
— Подзабыл? Какая печалька! Ты не расстраивайся, подумай полчасика, мы подождем! Мы же только для того и работаем, чтобы тебе приятно было!
… делает вид глубокой задумчивости в течение 30 минут…
— Окей, намекну, про «проблему ромба» когда-нибудь слышал?
молчит…
— Множественное наследование (шёпотом).
пожимает плечами…
— Ну скажи хоть «множественное наследование — зло!»
— Ну ладно, множественное наследование — зло.
— Ну вот и молодец, вот и ладушки! Ты принят на 300 тысяч в месяц. Нет, на 450!!! Какая радость!
Вот так это должно быть?
Или может собеседования такие, что не показывают правильную картину.
Может, и такие. Но ничего лучше не придумали пока что. Сюсюканье с разработчиком, который настолько звезда, что не озаботился даже все базовые механики языка изучить — ещё худший выход.
Вот так это должно быть?
Нет. Сколько раз мне надо написать? Вместо первого вопроса будет вопрос «Приведите пример переопределения метода в наследнике». И всё. Вы же это хотите проверить, а не знание определений наизусть.
Если вы настаиваете на первом вопросе, то будет так:
— Что такое virtual?
— Э, ну…
— Атрибут метода такой, зачем его пишут?
— А, это чтобы можно было переопределить метод в наследнике.
Не надо давать подсказки ответа, надо удостовериться, что человек понял вопрос.
Если он, соискатель. не понял вопроса — это его забота переспросить. Не забота собеседующего задуматься «он не знает или не понял? Хз, попробуем натолкнуть». Соискатель — что, инфантил полный, не может уточнить вопрос? Зачем нужны инфантилы?
Ну считайте, что вместо "э, ну" вопрос "это из какой области?". Сути это не меняет, такое уточнение не означает, что человек не умеет переопределять методы. Вы правильно говорите, но обычно люди какое-то время пытаются вспомнить, знакомое же слово, а за это время становится понятно, что человек по какой-то причине замялся. Просто это не повод сразу прекращать собеседование.
Именно реакция человека на минутную заминку и есть самое интересное. Если он что-то подзабыл, недопонял, но пытается уточнить, понять суть проблемы и решить ее — окей, собеседуем дальше.
Если он не пытается разобраться в заданном вопросе, а говорит «я не знаю» или, что еще хуже, отвечает «да я такой крутой разраб, хренли вы у меня такую тривиальщину спрашиваете»… Кхм, такой сеньор в команде не нужен, вне зависимости от его скилла непосредственно в кодинге.
Если он не пытается разобраться в заданном вопросе, а говорит «я не знаю» или, что еще хуже, отвечает «да я такой крутой разраб, хренли вы у меня такую тривиальщину спрашиваете»… Кхм, такой сеньор в команде не нужен, вне зависимости от его скилла непосредственно в кодинге.
Кхм, соискатель пришел собеседоваться на позицию сеньора. На всякий случай повторю: сеньора.
Понимание задачи из формально-нечеткой постановки и уточнение нюансов, равно как и декомпозиция задачи, четкая формальная формулировка/постановка, «перевод» на язык, доступный для каждого джуна — его прямая обязанность.
Если он не может сам попросить переформулировать недопонятый вопрос, задать уточняющий вопрос или относительно вежливо указать на неточность формулировки — грош цена ему как сеньору. Писать формально корректный код должен миддл, там соискателю и место.
Понимание задачи из формально-нечеткой постановки и уточнение нюансов, равно как и декомпозиция задачи, четкая формальная формулировка/постановка, «перевод» на язык, доступный для каждого джуна — его прямая обязанность.
Если он не может сам попросить переформулировать недопонятый вопрос, задать уточняющий вопрос или относительно вежливо указать на неточность формулировки — грош цена ему как сеньору. Писать формально корректный код должен миддл, там соискателю и место.
Я тоже на всякий случай повторю. Я спорю с тем, что 'не ответил сразу на вопрос "что такое N" означает "не умеет использовать то, что обозначает слово N"'. На любую позицию.
А я утверждаю, что причина, по которой соискатель не смог ответить на вопрос, в контексте собеседования на позицию «сеньора» — монопенисуальна.
У нас есть собеседование на высокооплачиваемую должность. В собеседовании две стороны-участника (соискатель и собеседующий), у каждой их которых свои цели. У соискателя — доказать свою профпригодность и получить работу. У собеседующего — отсечь профнепригодных соискателей и принять (по возможности, на испытательный срок) на работу соискателя, показавшегося профпригодным на основании содержания собеседования (да, экспресс-тест, но ничего не поделаешь, время собеседующего тоже стоит денег).
В нашей ситуации соискатель завалил собеседование, не вспомнив с ходу ключевую механику языка. Для сеньора такая ситуация — повод стыдливо помолчать в тряпочку, а не нести свое негодование на Хабр.
Да, для миддла ситуация могла бы быть и помягче. Для джуна… Кхм, джун — это изначально человек, которого берут с намерением «научить», т.е. там вообще нужно проверять собственно адекватность индивида и базовую способность воспринимать речь на слух и в письменном виде. Для сеньора, простите, не должно быть поблажек. Высокая зарплата = высокий порог вхождения, и никаких «сюсюканий».
А «в отрыве от ситуации», «в абстрактном понимании» и много еще ничего не значащих слов — спор беспредметен. То, что человек не отвечает на простой вопрос может означать, например, что он русский язык не знает, или глух на оба уха, или просто уснул — это вот тот набор вариантов, который можно упомянуть в споре, но который не имеет никакого отношения к ситуации.
У нас есть собеседование на высокооплачиваемую должность. В собеседовании две стороны-участника (соискатель и собеседующий), у каждой их которых свои цели. У соискателя — доказать свою профпригодность и получить работу. У собеседующего — отсечь профнепригодных соискателей и принять (по возможности, на испытательный срок) на работу соискателя, показавшегося профпригодным на основании содержания собеседования (да, экспресс-тест, но ничего не поделаешь, время собеседующего тоже стоит денег).
В нашей ситуации соискатель завалил собеседование, не вспомнив с ходу ключевую механику языка. Для сеньора такая ситуация — повод стыдливо помолчать в тряпочку, а не нести свое негодование на Хабр.
Да, для миддла ситуация могла бы быть и помягче. Для джуна… Кхм, джун — это изначально человек, которого берут с намерением «научить», т.е. там вообще нужно проверять собственно адекватность индивида и базовую способность воспринимать речь на слух и в письменном виде. Для сеньора, простите, не должно быть поблажек. Высокая зарплата = высокий порог вхождения, и никаких «сюсюканий».
А «в отрыве от ситуации», «в абстрактном понимании» и много еще ничего не значащих слов — спор беспредметен. То, что человек не отвечает на простой вопрос может означать, например, что он русский язык не знает, или глух на оба уха, или просто уснул — это вот тот набор вариантов, который можно упомянуть в споре, но который не имеет никакого отношения к ситуации.
Сениор это не тот, кто знает все ключевые слова, а тот, кто умеет применять то, что ими обозначается. Он зачастую знает несколько языков, может разобраться в новом языке и применить нужные механизмы для решения задачи, посмотрев нужные ключевые слова в документации. И в первую очередь это относится к full-stack разработчикам.
Хорош «отмазывать» вашего кандидата. Соискатель на позицию Senior full-stack .NET developer в контексте беседы о C# (сначала protected internal, затем in-out, ключевые слова языка C#) не смог вспомнить ключевое слово из того же языка virtual.
Нет тут никакой проблемы «не переключил контекст». Его спросили одно ключевое слово из языка, потом еще одно, затем третье — все три из одного и того же языка. Если бы после protected internal сразу попросили объяснить механизм работы замыканий в JS — он мог бы еще как-то оправдаться. А тут — три последовательных вопроса на одну и ту же тему, в одном и том же контексте.
Просто завалил, тчк.
Нет тут никакой проблемы «не переключил контекст». Его спросили одно ключевое слово из языка, потом еще одно, затем третье — все три из одного и того же языка. Если бы после protected internal сразу попросили объяснить механизм работы замыканий в JS — он мог бы еще как-то оправдаться. А тут — три последовательных вопроса на одну и ту же тему, в одном и том же контексте.
Просто завалил, тчк.
Хорош «отмазывать» вашего кандидата.
Я говорю про общие вещи, а не про конкретного кандидата. Вы видите то, что хотите видеть.
А тут — три последовательных вопроса на одну и ту же тему, в одном и том же контексте.
Контекст это не кирпич со стандартными размерами. Есть глобальный контекст, есть контексты поменьше. Я выше приводил пример названий, в которых есть слово "виртуал". Они находятся на ресурсе, связанном с программированием. Следует ли из этого, что "виртуал" там означает ключевое слово языка программирования? Нет. А теперь вопрос, почему читая название статьи вы не будете думать, что она про ключевое слово? Потому что у вас есть нейроны с другим понятием, которые в данном контексте дают сигнал больше, чем нейроны с понятием наследование. А в другом контексте это могут быть нейроны, отвечающие за внимание, обращенное на собеседника, или за шум вокруг, даже неправильное ударение может сыграть роль, и нужные нейроны дадут меньшую реакцию.
не смог вспомнить ключевое слово из того же языка virtual
Не смог? Не смог. Что из этого следует? Да ничего. Причин много, а собеседующий решил не проверять. А потом такие люди сетуют, что мол разработчиков мало. А потом они же пишут на Хабре, что главное знать базовые принципы и алгоритмы, а не фреймворки и порядок аргументов в функциях. Пишут правильно, а проверяют неправильно.
Просто завалил, тчк.
Во-во, в этом и проблема. Не должно быть так, чтобы собеседование можно было "завалить". Собеседование должно определять реальные умения кандидата и их соответствие задачам. Должно быть так, чтобы его можно было пройти или не пройти. Соответствует — прошел, не соответствует — не прошел. Знание определений и мгновенный ответ без права на ошибку это одно из требований? Значит так и пишите в вакансии.
Соответствует — прошел, не соответствует — не прошел.
Устройство на работу — не экзамен в вузе. Если место одно, а соответствуют десять кандидатов — девять все равно не пройдут. Даже если они действительно крутые спецы.
И нет у интервьюера на этом этапе, задачи определить реальные умения кандидата. У него другая задача — отсеять плохих кандидатов с умеренным количеством ложноположительных и ложноотрицательных результатов.
Описываемый в статье случай вообще до смешного прост — вьюноша 24 лет пошел на вакансию сеньора, и забыл, что такое virtual. Спасибо, мы вам перезвоним.
Устройство на работу — не экзамен в вузе.
Поэтому и не должно быть варианта "завалил собеседование".
У него другая задача — отсеять плохих кандидатов
Ну а как вы определите, плохой кандидат или нет, не определяя реальные умения?
вьюноша 24 лет пошел на вакансию сеньора, и забыл, что такое virtual
Так я говорю не про требования на сеньора C#, а про вывод "не вспомнил за N секунд на собеседовании значит не умеет использовать". Но почему надо сразу говорить "Спасибо, мы вам перезвоним", тем более на фуллстека, где подразумевается несколько языков, мне тоже не очень понятно. Проверить ведь несложно. Вот и получается "мало квалифицированных специалистов", знающие принципы отсеиваются на определениях, зазубрившие определения на практических задачах.
Я выше приводил пример названий, в которых есть слово «виртуал». Они находятся на ресурсе, связанном с программированием. Следует ли из этого, что «виртуал» там означает ключевое слово языка программирования?
Мы, в смысле, обсуждаем собеседование на должность читателя ресурса, связанного с программированием? Есть контекст беседы и он в момент проведения беседы — основной. «Казусы» случаются при «переключении» контекста. Если человек не может оставаться в контексте беседы и на вопрос, заданный в текущем контексте ищет определение в области общих знаний — это повод к врачу обратиться, когнитивные расстройства по большей части лечатся.
А в другом контексте...
При чем тут другой контекст? Находясь в нужном контексте человек не ответил на вопрос, напрямую относящийся к текущему контексту. Это означает, что человек «плавает» именно в текущем контексте, и ничего не говорит о его широких познаниях в других. Собственно, они значения и не имеют, собеседующему важно знать «сильные стороны» соискателя ровно в том контексте, в котором происходит беседа.
Не смог? Не смог. Что из этого следует?
Из этого следует, что он не получил работу. Все, больше ничего не следует.
Причин много, а собеседующий решил не проверять. А потом такие люди сетуют, что мол разработчиков мало. А потом они же пишут на Хабре, что главное знать базовые принципы и алгоритмы, а не фреймворки и порядок аргументов в функциях.
Я вижу, что на хабре пишет соискатель. А именно те, которые его собеседовали, на хабре не пишут. Пишут, очевидно, другие какие-то.
Не должно быть так, чтобы собеседование можно было «завалить».
Ну, тогда один вариант остается. «Пришел? Годен!» Ой, погодите, он же мог опоздать/забыть/не явиться по любой другой причине. Тоже не подходит… Что же делать? Как гарантировать разработчику рабочее место так, чтобы он не мог «зафейлиться»? Как принять его на работу, например, если он из принципа не хочет трудовую книжку показывать? Блин, всего и не учтешь же!
Собеседование должно определять реальные умения кандидата и их соответствие задачам.
А пиво должно быть бесплатным, а на улице должно быть лето круглый год, и… да много еще чего должно. А на практике в контексте ограниченного времени собеседования задача нерешаема.
Можно, конечно, тестовое задание дать… А, нет, и это тоже нельзя, т.к. «да какого хрена я тут буду время тратить на всякую бесполезную чушь без практической пользы». Всем, знаете, не угодишь.
Так что, видимо, только «верить на слово»…
Должно быть так, чтобы его можно было пройти или не пройти.
Так и есть ведь. Нет, даже не так, лучше. Ответил на все вопросы — прошел. Не ответил — все равно прошел, просто на работу не взяли. В чем проблема-то?
Знание определений и мгновенный ответ без права на ошибку это одно из требований? Значит так и пишите в вакансии.
Где там в статье про мгновенный ответ и отказ в праве на ошибку было? Не уточните место?
«Казусы» случаются при «переключении» контекста.
Почему вы так решили? При заданном контексте тоже случаются.
Если человек не может оставаться в контексте беседы
А там был контекст "виртуальные методы"? Нет.
При чем тут другой контекст?
При том что "собеседование" и "работа над задачей" это разные контексты. Вопросы "что такое virtual" и "какое слово написать в C# для переопределения метода" обозначают прямо противоположные ситуации.
Это означает, что человек «плавает» именно в текущем контексте
Нет, не означает. Я приводил ссылки. Можно знать факт, но не вспомнить его в текущем контексте.
Пишут, очевидно, другие какие-то.
Ну вы вот например пишете: "В конце концов, язык программирования — всего лишь инструмент. Сеньор должен знать практики, паттерны"
Ну, тогда один вариант остается. «Пришел? Годен!»
Как можно из фразы "Должно быть так, чтобы его можно было пройти или не пройти" сделать вывод, что остается один вариант "пройти"?
А на практике в контексте ограниченного времени собеседования задача нерешаема.
Я вам неоднократно приводил пример, как можно проверить умение переопределить метод. Что вы там видите нерешаемого?
Можно, конечно, тестовое задание дать… А, нет, и это тоже нельзя. Всем, знаете, не угодишь
А "задать уточняющий вопрос" вам что мешает? У меня в последнее время на собеседованиях спрашивают, согласен ли я выполнить тестовое задание. И я соглашаюсь. Автор вон тоже про него пишет.
Где там в статье про мгновенный ответ и отказ в праве на ошибку было? Не уточните место?
"Интервью, естественно, кончается". Ни других вопросов, ни примеров где это можно применить.
Почему вы так решили? При заданном контексте тоже случаются.
Приведенные вами же ссылки свидетельствуют о том, что «контекстные казусы» возникают именно при переключении контекста. «Выпадание из контекста» по прежнему считается девиацией.
А там был контекст «виртуальные методы»? Нет.
Был контекст «базовые механики С#», т.е. «виртуал — это аккаунт в соцсетях» туда никак не ложится. Вот вообще никак перепутать нельзя было.
Вопросы «что такое virtual» и «какое слово написать в C# для переопределения метода» обозначают прямо противоположные ситуации.
Вот именно. При этом «какое слово написать в C# для переопределения метода» — это именно вопрос на зубрежку, он не корректен, но его никто и не задавал. А вот «что такое virtual» — задавал. И вот тут мы представляем сеньора, который читает чужой код, принесенный автором-джуном, натыкается на слово virtual и нихрена не понимает, что этот код делает. Феерично же, не? Вот такие ситуации и отсекают на входе, и правильно делают.
Как можно из фразы «Должно быть так, чтобы его можно было пройти или не пройти» сделать вывод, что остается один вариант «пройти»?
Вы как-то странно относитесь к понятию «собеседование». Единственный способ его «не пройти» — это не явиться туда вообще. Прохождение собеседования — это процесс такой, иногда приводящий к взаимному культурному обогащению сторон. Результаты могут быть разными, при этом неприем на работу тоже может трактоваться положительно в некоторых ситуациях.
Вопрос именно в вашем отношении и умении извлекать пользу из ситуации. Если вы воспринимаете сам процесс как «получить работу или умереть» — ну, собственно, это ваша личная проблема. «Хороший разработчик сидит без работы» — глупости. Хороший работу имеет. «Бизнес потерял ценного профессионала» — да пофиг, бизнес не заметил, нанял другого. «Свято место», понимаете ли. Если же бизнес реально неадекватен… Ну, как бы, он просто уступил дорогу другому бизнесу, более адекватному. Т.е., опять же, никому хуже не стало.
Я вам неоднократно приводил пример, как можно проверить умение переопределить метод. Что вы там видите нерешаемого?
Да нету на собеседовании такой задачи. Нет задачи «проверить умение переопределить метод», нет задачи «определить уровень профессионализма», нет задачи «установить уровень квалификации» или «дать объективную оценку знаниям». Чушь все это. Собеседует, как правило, ваш будущий потенциальный начальник, и единственная его реальная цель — посмотреть на вас «в живую» и сформировать для себя субъективную оценку, хочет ли он с вами работать и готов ли взять на себя риски, связанные с приемом вас на работу. Остальное — левая чушь и нереализуемо в рамках собеседования.
«Справляетесь» ли вы — вопрос опыта работы с вами, невозможно предсказать, сможете ли вы вписаться в команду, пока вы не побудете внутри коллектива. Поэтому любые попытки дать объективную оценку вас как специалиста на этапе собеседования — очевидная глупость, и цели такой не стоит. Да и оценку какую-то давать — предмет отдельной науки, именуемой «педагогика», желательно с некоторым уровнем экспертизы по психологии. Очевидно, эти две дисциплины совершенно не обязательны для технического специалиста, который вас собеседует.
Соответственно, и решение принимается на уровне «я не хочу с ним работать». И надеяться на что-то иное — наивно, простите за откровенность.
А «задать уточняющий вопрос» вам что мешает? У меня в последнее время на собеседованиях спрашивают, согласен ли я выполнить тестовое задание. И я соглашаюсь. Автор вон тоже про него пишет.
А тут в комментариях пару-тройку раз некоторые не менее опытные разработчики упоминали, что смело шлют на фиг с предложениями тестовых заданий, и они тоже по-своему правы. Теперь осталось, очевидно, понять, как не обидеть обе стороны.
«Интервью, естественно, кончается». Ни других вопросов, ни примеров где это можно применить.
Собственно, если человек сам «не проявляет интереса», не пытается уточнить суть вопроса или найти решение… Ну, как бы, да, кончается. И это вполне естественно, т.к. соискатель не настолько заинтересован в получении должности, чтобы что-либо предпринимать. А что он хотел? Его же не должны уговаривать…
Да и не факт, что не уговаривали. Вы же помните про «Не верь жене, поносящей своего мужа», ага? Или классику «Все лгут»? Вы же на объективность претендуете, так будьте добры выслушать обе стороны, или, хотя бы, не верить на слово во всем одной из них.
Приведенные вами же ссылки свидетельствуют о том, что «контекстные казусы» возникают именно при переключении контекста.
"For example, if someone tries and fails to recollect the memories he had about a vacation he went on, and someone mentions the fact that he hired a classic car during this vacation, this may make him remember all sorts of things from that trip, such as what he ate there, where he went and what books he read."
Человек не помнил, что читал книгу и какую именно. Изменение контекста как раз убрало "казус".
При этом «какое слово написать в C# для переопределения метода» — это именно вопрос на зубрежку
Нет, это именно тот вопрос, который возникает когда надо написать конкретный код. "Надо переопределить метод" это нормальный рабочий контекст. Вопрос проверяет нужную ассоциацию.
И вот тут мы представляем сеньора, который читает чужой код, принесенный автором-джуном, натыкается на слово virtual
Ага, хороший пример. Явно задается контекст "ключевое слово в определении метода". В собеседовании был такой контекст?
Прохождение собеседования — это процесс такой
"Пройти — быть пропущенным, одобренным
Самолет прошёл курс лётных испытаний в ведущем испытательном центре. Перед приёмом на работу необходимо пройти собеседование."
«Хороший разработчик сидит без работы» — глупости. Хороший работу имеет.
В статье описывается проблема, что как раз хороший работу не имеет из-за таких критериев.
нет задачи «определить уровень профессионализма», нет задачи «установить уровень квалификации» или «дать объективную оценку знаниям»
А как же ваши утверждения про то, что "сениор должен это знать"? Это именно критерий определения квалификации.
В том, что нет такой цели, и заключается проблема.
так будьте добры выслушать обе стороны, или, хотя бы, не верить на слово во всем одной из них.
Зачем выслушивать, у меня похожие собеседования были. Может пара штук, и не именно такие, но случалось.
«For example, if someone tries and fails to recollect the memories he had about a vacation he went on, and someone mentions the fact that he hired a classic car during this vacation, this may make him remember all sorts of things from that trip, such as what he ate there, where he went and what books he read.»
Человек не помнил, что читал книгу и какую именно. Изменение контекста как раз убрало «казус».
Очень интересный перевод, смею вас заверить. И если стоит задача «вытянуть за уши», может и получиться. Только разница с экзаменом в школе в том, что в школе экзаменующий имеет цель получить наибольшее количество «сдавших», на собеседовании на сеньора — отсечь наибольшее количество «непрофпригодных».
Нет, это именно тот вопрос, который возникает когда надо написать конкретный код. «Надо переопределить метод» это нормальный рабочий контекст. Вопрос проверяет нужную ассоциацию.
Давайте постараемся вспомнить претензию автора поста. Он не пользуется наследованием, а потому сходу не вспомнил ассоциацию с ключевым слово. При этом он же утверждает, что механику он знает.
Вспомнить механику по ключевому слову — проще, чем вспомнить ключевое слово, которое не используешь, по определению этого термина. Собеседующий в его интересах действовал. Да и в собственных, он же, вроде как, знание механик оценивал, а не эрудицию кандидата. «Назовите ключевое слово, используемое в языка C# для определения множественного наследования» — вопрос прямо так и просится в кроссворд. И практики применения не требует, достаточно термин зазубрить, или, например, иметь широкий кругозор. Рискну предположить, что Вассерман имеет шанс угадать, но это не делает его хорошим .NET-разработчиком.
А как же ваши утверждения про то, что «сениор должен это знать»? Это именно критерий определения квалификации.
В том, что нет такой цели, и заключается проблема.
Каким образом вы собираетесь оценивать квалификацию разработчика по знанию ключевого слова, встречаемого в каждой первой книжке «C# для чайников»? Вы в своем уме? Этот вопрос — один из некоторых формальных вопросов, чтобы отсечь совсем уже неадекватов. Сеньор не ответил? Ну что ж, стыд и позор сеньору, придет на следующий год.
Ага, хороший пример. Явно задается контекст «ключевое слово в определении метода». В собеседовании был такой контекст?
Вопрос первый: «Что такое protected internal»?
Вопрос второй: «Что такое in и out»?
Вопрос третий: «Что такое virtual»?
Хм, а какой был контекст в беседе?
В статье описывается проблема, что как раз хороший работу не имеет из-за таких критериев.
Еще раз повторю. Хороший разработчик — дефицит, он работу имеет. В конце концов, если уж я работу имею, то почему бы ее не найти действительно хорошему разработчику? Вот и автор говорит, что работу нашел, не страдает. Из чего трагедию раздули?
Очень интересный перевод, смею вас заверить.
Заверять не надо, надо аргументы приводить. В данном случае ваш вариант перевода, который должен показать, что я не прав.
Причем здесь экзамен? Вы сделали утверждение, я привел цитату, которая говорит что оно неверное.
Вспомнить механику по ключевому слову — проще, чем вспомнить ключевое слово по определению
Нет. У меня вот в PHP эта механика есть, а слова virtual нет. И даже специального слова для нее нет, она по умолчанию используется.
И да, фуллстек-разработчики как правило думают не ключевыми словами, а механиками, потому что ключевые слова для одних и тех же механик в разных языках разные.
Да и в собственных, он же, вроде как, знание механик оценивал, а не эрудицию кандидата.
Объясните, как вы из описания ситуации "вопрос, который возникает когда надо написать конкретный код" сделали вывод, что этот вопрос задает кто-то посторонний? У вас же никто не его спрашивает, когда вы код пишете.
Этот вопрос возникает у самого человека, который пишет конкретный код. Когда человек знает ответ, срабатывает ассоциация. Собеседующий не должен его задавать, он должен дать пример, который покажет наличие нужной ассоциации.
Этот вопрос — один из некоторых формальных вопросов, чтобы отсечь совсем уже неадекватов.
Ну так в том и проблема, что если не ответил, это не означает, что человек неадекват. А если ответил, не означает, что адекват.
Хм, а какой был контекст в беседе?
А где там 'код, принесенный автором-джуном, содержащий слово virtual'? Контекст более общий, а следовательно, другой. А следовательно, если вы не хотите нанять человека, который будет в такой ситуации так себя вести, то надо дать такую ситуацию и посмотреть, как человек себя ведет. Всё просто же.
В конце концов, если уж я работу имею, то почему бы ее не найти действительно хорошему разработчику?
Потому что по этим критериям он получается не очень хороший разработчик. А работу получают как раз не действительно хорошие разработчики.
Заверять не надо, надо аргументы приводить. В данном случае ваш вариант перевода, который должен показать, что я не прав.
Окей, будем мериться переводами.
Оригинал:
«For example, if someone tries and fails to recollect the memories he had about a vacation he went on, and someone mentions the fact that he hired a classic car during this vacation, this may make him remember all sorts of things from that trip, such as what he ate there, where he went and what books he read.»
Ваше толкование:
Человек не помнил, что читал книгу и какую именно. Изменение контекста как раз убрало «казус».
Мой перевод (навскидку):
Например, если кто-то пытается и неможет восстановить воспоминания о том, как он провел отпуск (поездку в отпуск), и кто-нибудь упоминает тот факт, что он арендовал классическую (винтажную?) машину во время отпуска, это может заставить его вспомнить всё об этой поездке, включая такие вещи, как «что он ел», «куда ездил» и «какие книги читал (видимо, во время отпуска)».
Есть эксперты, способные оценить, чей перевод ближе к первоисточнику? Вы бы хоть в гуглотранслейт текст засунули, что ли…
У меня вот в PHP эта механика есть, а слова virtual нет.
У вас в PHP, может быть, и есть. А может быть, вы просто не совсем поняли суть механики. Беглое гугленье выдает фразу «в языках с поддержкой только одиночного наследования, таких как PHP», что намекает, что множественное наследование в PHP не принято. Или это, может быть, просто другой PHP…
Это не отменяет того факта, что то, «что есть, и чего нет в PHP» — информация, не имеющая никакого отношения к собеседованию на должность Senior .NET Developer. Если человека спрашивают знание механизма C#, а он «затрудняется ответить, т.к. в PHP этого нет»… Ну, как бы, я бы тоже такого «кадра» на работу не взял.
Собеседующий не должен его задавать, он должен дать пример, который покажет наличие нужной ассоциации.
Откуда у вас эта уверенность, что собеседующий вам что-то должен? Собеседующий должен дать субъективную оценку вас как кандидата на основании собеседования… И да, не вам должен, а своему работодателю.
Ну так в том и проблема, что если не ответил, это не означает, что человек неадекват. А если ответил, не означает, что адекват.
И что, вопросы не задавать? Или предложить на листочке написать? Ну окей, он так же не вспомнил ключевое слово virtual, и начал опять плач, но уже на тему «я же в IDE пишу, зачем мне умение писать на листочке». И опять собеседующий не прав, вот как ни посмотри. Ну и нафига напрягаться?
Если он даже смог написать на листочке, это один хрен, по большому счету, ничего не значит. И если не смог, это опять ничего не значит. И если вы попросили его сделать тестовое задание, а он не сделал — не значит. И если сделал — тоже не значит. С вашим подходом все незначительно… жизнь тлен и все вот это.
А где там 'код, принесенный автором-джуном, содержащий слово virtual'? Контекст более общий, а следовательно, другой. А следовательно, если вы не хотите нанять человека, который будет в такой ситуации так себя вести, то надо дать такую ситуацию и посмотреть, как человек себя ведет. Всё просто же.
Вот зачем вы увиливаете. Сформулируйте, все же, какой контекст был в беседе, состоящей из трех вопросов на знание ключевых слов языка C#?
Потому что по этим критериям он получается не очень хороший разработчик.
Ну да, а по личной оценке он очень хороший. Т.е. у нас есть два противоречащих утверждения. 1. Очень хороший разработчик (Обосновано тем, что он так считает). 2. Не очень хороший разработчик (Обосновано тем, что он не смог ответить на вопрос по базовым механикам языка). И какому из этих утверждений нужно верить?
А работу получают как раз не действительно хорошие разработчики.
Вот вы сейчас тысячи хороших и даже талантливых разработчиков, имеющих работу, обидели. Надо Саттеру написать, или Страуструпу, они-то сидят на своих работах и не знают, что они «не очень».
Мой перевод (навскидку): "Например..."
Отлично. Чем он противоречит моему описанию человека из примера? Мы рассматриваем гипотетического человека, который вспоминает про отпуск. Человек не помнил факты про отпуск? Да. Не помнил факт про книгу? Да. Вспомнил когда кто-то другой уточнил контекст? Да.
Беглое гугленье выдает фразу «в языках с поддержкой только одиночного наследования, таких как PHP», что намекает, что множественное наследование в PHP не принято.
Причем здесь множественное наследование? Вы в курсе, что в C# его тоже нет?
Это не отменяет того факта, что то, «что есть, и чего нет в PHP» — информация, не имеющая никакого отношения к собеседованию
Эта информация говорит о том, что ваше утверждение "Вспомнить механику по ключевому слову — проще" неверно.
Откуда у вас эта уверенность, что собеседующий вам что-то должен?
Я исхожу из того, что раз в вакансии указано Senior developer, значит собеседующему важна квалификация этого девелопера. Которая и проверяется вопросами по использованию языка.
И что, вопросы не задавать?
Я уже отвечал на этот вопрос.
С вашим подходом все незначительно…
Как вы из описания "чтобы проверить умение переопределять методы, надо сделать то-то" сделали вывод, что все незначительно? С предлагаемыми вами способами да, получается что все незначительно, раз они не проверяют то что должны.
Вот зачем вы увиливаете.
Почему вы так решили? Вы сами привели пример с кодом джуна, и говорите, что задаваемый вопрос якобы должен отсеять тех, кто в нем не разберется. Так? Значит, в вопросе должен быть код джуна со словом virtual, и надо проверять, понимает ли его кандидат.
Слово virtual применяется в контексте метода, а в беседе был более общий контекст, метода там не было.
А как следует из примера с отпуском, в более общем контексте можно не вспомнить какие-то известные факты.
Ну да, а по личной оценке он очень хороший.
Нет. Мы не знаем, хороший он или нет, потому что вопросы это не проверили.
Вот вы сейчас тысячи хороших и даже талантливых разработчиков, имеющих работу, обидели.
Я не сказал, что кроме не хороших разработчиков работу никто не получает. Просто там, где работают хорошие разработчики, были другие критерии. Не надо говорить за всех.
Отлично. Чем он противоречит моему описанию человека из примера? Мы рассматриваем гипотетического человека, который вспоминает про отпуск. Человек не помнил факты про отпуск? Да. Не помнил факт про книгу? Да.
Тем, например, что вы рассматривали гипотетического человека, который забыл книгу. Про отпуск у вас слова не было.
Вспомнил когда кто-то другой уточнил контекст? Да.
Нет же. Нет там в тексте про уточнение контекста. Ничегошеньки нет. Там про связность воспоминаний, про указание связанной детали, которое влечет за собой восстановление полной картины.
Т.е. вот так:
— А помнишь, Машу, блондинку такую шикарную?
— Не, не помню…
— Ну, позавчера на тусе познакомились!
— Да не помню я никакую Машу!
— Да ты тогда еще из туалета вышел и ширинку застегнуть забыл, и у тебя трусы оттуда торчали, красные, в горошек!
— Ну это помню, а что за Маша-то?
— Ну вот Маша — это та, которая на рояле играла.
— А! Эта Маша! Ну да, шикарная такая блондинка.
И ничего там ни про какое «уточнение контекста» нет.
Эта информация говорит о том, что ваше утверждение «Вспомнить механику по ключевому слову — проще» неверно.
Каким образом тезис «В PHP ключевого слова virtual нет» может вообще что-то говорить о связи механики с ключевыми словами в C#.
Единственное, о чем это говорит, так это о том, что PHP-разработчикам нефиг ходить на собеседования на позицию senior .NET developer.
Как вы из описания «чтобы проверить умение переопределять методы, надо сделать то-то» сделали вывод, что все незначительно?
Вывод я сделал на основании того, что ни один из вариантов, ни мой, ни ваш, не дает объективной оценки со сколько-нибудь приемлемой точностью за приемлемый отрезок времени.
Разница между нами в том, что вы все еще верите, что на собеседовании в принципе возможно объективно определить квалификацию разработчика.
Все, что вы предложили, сводится к этому:
— Мишенька, какой сейчас месяц?
…
— Ну, давай, ян…
— … варь!
— А потом какой? Фев…
— … раль!
— А дальше? Ма…
— … рт.
— Ап…
— … рель.
— Ма…
— … й!
— Вот молодец, давай дальше сам!
— юнь, юль, густ, ябрь, ябрь, ябрь, абрь!
Про отпуск у вас слова не было.
Ну как это не было, у меня там целая цитата в кавычках со словом "vacation". Вы ее даже переводили.
про указание связанной детали, которое влечет за собой восстановление полной картины.
Указание связанной детали это и есть уточнение контекста.
— А помнишь virtual, ключевое слово такое клевое?
— Не, не помню…
— Ну это слово, которое возле метода пишется.
— А, это слово. Ну да, применяется для переопределения метода в наследнике.
Почему вы считаете, что про метод это уточнение контекста, а про Машу нет?
Каким образом тезис может вообще что-то говорить о связи механики с ключевыми словами в C#.
А он и не говорит ничего про C#. О чем он говорит, написано в цитате. Утверждение «Вспомнить механику по ключевому слову — проще» неверно, следовательно, не может использоваться в качестве аргумента.
что ни один из вариантов, ни мой, ни ваш, не дает объективной оценки со сколько-нибудь приемлемой точностью за приемлемый отрезок времени.
Мой дает, так как проверяет то, что мы хотим проверить.
Все, что вы предложили, сводится к этому:
Основы теории аргументации
Внелогические аспекты аргументации.
Логические уловки и ошибки:
…
чрезмерное преувеличение – сведение к абсурду доводов оппонента путем чрезмерного преувеличения с последующим высмеиванием смоделированной аргументации;
…
В реальном процессе аргументации участники нередко не ставят своей целью достижение истины, и для этого пускают в ход уловки, которые этому препятствуют.
Судя по количеству преувеличений я склоняюсь к мысли, что вы тролль, и продолжать разговор не намерен.
Ну как это не было, у меня там целая цитата в кавычках со словом «vacation». Вы ее даже переводили.
В цитате было, но вы читали эту цитату как «про книгу», и до сих пор, вероятно, не понимаете, что там написано.
Указание связанной детали это и есть уточнение контекста.
Да нет же, совершенно разные когнитивные механизмы.
— А помнишь virtual, ключевое слово такое клевое?
— Не, не помню…
— Ну это слово, которое возле метода пишется.
— А, это слово. Ну да, применяется для переопределения метода в наследнике.
Т.е. вот так, по вашему, должны выглядеть собеседования на позицию сеньора?
Почему вы считаете, что про метод это уточнение контекста, а про Машу нет?
Потому что уточнение контекста напрямую относится к теме обсуждения. Красные трусы в горошек к Маше отношения не имеют. Вы, видимо, контекст запоминания с контекстом беседы путаете (опусами про аквалангистов подтверждается). Ну так вот — это разные вещи, которые связаны с разными когнитивными механизмами.
Утверждение «Вспомнить механику по ключевому слову — проще» неверно,
Вот это вы чем обосновали? Вот эта логическая цепочка «В PHP нет ключевого слова virtual, у вас, как у PHPшника слово ассоциаций не вызывает, а значит, в контексте беседы по C# ключевое слово virtual тоже ни о чем не говорит». Вы уникум, по вашей логике не одну докторскую защитить можно по психологии мышления.
Мой дает, так как проверяет то, что мы хотим проверить.
Ваш — это какой? Который «надо задавать наводящие вопросы»? Понимаете, если человек вспомнил термин только со второй попытки с подсказкой — это говорит только о том, что он не смог вспомнить термин сразу без подсказок. Т.е., по-прежнему, ничего не говорит о скилле человека.
Внелогические аспекты аргументации.
В смысле, вы, тот самый человек, который не побрезговал классическим «утоплением» изначальной сути в цепочке бессмысленных высказываний, мне выказываете свое «фи»… цитируя избранные места (с приведением ссылок) из методических материалов для аспирантов РГУФКСиТ (уточню для ясности, «Российского Государственного Университета ФИЗИЧЕСКОЙ КУЛЬТУРЫ, СПОРТА и ТУРИЗМА») за авторством доцента кафедры Культуры и СПОРТА Передельского А. А., выдавая это «многотекста» за неоспоримый аргумент своей правоты.
А вслед за этим классическое гордое «вы тролль, и я выше этого».
Сильно, ага!
Нет. У меня вот в PHP эта механика есть, а слова virtual нет. И даже специального слова для нее нет, она по умолчанию используется.
И да, фуллстек-разработчики как правило думают не ключевыми словами, а механиками, потому что ключевые слова для одних и тех же механик в разных языках разные.
Ну так он же не на PHP Senior Developer собеседовался, а на .Net, где это слово есть, и забыть его смысл как мне кажется просто невозможно. Выше верно написали, это ключевое слово. Может ли филолог забыть букву «Ы» и зачем она нужна?
В зависимости от ситуации, стресса и других факторов — может, ещё как может.
Об этом и речь, случайно забыть и не вспомнить за пару секунд можно любое слово, совершенно любое. Люди умудряются своё имя забыть в разных ситуациях. То самое имя, которое они используют уже на протяжении всей своей жизни, по которому к ним обращаются, скорее всего, не один раз в день. И я сейчас не про провалы в памяти из-за разных болезней.
И просто поэтому такая заминка не должна становиться решающим фактором для составления оценки человека. Слишком субъективная оценка получается, которая с реальностью коррелирует чуть более, чем никак.
Об этом и речь, случайно забыть и не вспомнить за пару секунд можно любое слово, совершенно любое. Люди умудряются своё имя забыть в разных ситуациях. То самое имя, которое они используют уже на протяжении всей своей жизни, по которому к ним обращаются, скорее всего, не один раз в день. И я сейчас не про провалы в памяти из-за разных болезней.
И просто поэтому такая заминка не должна становиться решающим фактором для составления оценки человека. Слишком субъективная оценка получается, которая с реальностью коррелирует чуть более, чем никак.
Об этом и речь, случайно забыть и не вспомнить за пару секунд можно любое слово, совершенно любое. Люди умудряются своё имя забыть в разных ситуациях.
Не могу представить себе взрослого челвоека, забывшего своё имя…
И просто поэтому такая заминка не должна становиться решающим фактором для составления оценки человека.
Не должна. Но если ему дали пару минут, а он не ответил, то закономерно получить отказ.
Не могу представить себе взрослого челвоека, забывшего своё имя…
Скорее всего потому что пытаетесь представить это в отрыве от контекста и ситуации, что-то вроде «шел-шел и забыл, как меня зовут». И, действительно, подобное себе представить крайне сложно.
Не должна. Но если ему дали пару минут, а он не ответил, то закономерно получить отказ.
Один из вариантов решения таких затупов — просто дать время на размышление. Разумно. Другой вариант решения — задать пару наводящих вопросов, о чём тут неоднократно писалось.
Это всё попытки выяснить, действительно ли человек не знает или что-то просто пошло не так.
Но вся эта ветка да споры и сводятся к тому, что кто-то считает, что «не ответил за пару секунд» = «не знает, плохо знает», а кто-то считает, что «не ответил за пару секунд» = «забыл. Возможно знает, возможно нет — нужно проверить ещё», да попутно поднимается вопрос «а может ли сеньёр что-то забыть?»
«Пройти — быть пропущенным, одобренным
Самолет прошёл курс лётных испытаний в ведущем испытательном центре. Перед приёмом на работу необходимо пройти собеседование.»
Смотрите, мы имеем синонимы «сдать, преодолеть», а также «произойти, состояться». Так что разница — в вашей голове, как относитесь, так и проходите.
"Произойти, состояться" имеет другую связь с существительным. Собеседование проходило с 2 до 3. Человек прошел собеседование.
Признайтесь, вы филолог?
А теперь расскажите мне о «другой связи с существительным» в контексте «я прошел медосмотр» и корреляцию этой формулировки со сдачей, преодолением и вообще успешностью мероприятия.
А теперь расскажите мне о «другой связи с существительным» в контексте «я прошел медосмотр» и корреляцию этой формулировки со сдачей, преодолением и вообще успешностью мероприятия.
ТК РФ Статья 213. Медицинские осмотры некоторых категорий работников
Работники, занятые на работах с вредными и (или) опасными условиями труда, а также на работах, связанных с движением транспорта, проходят обязательные предварительные (при поступлении на работу) и периодические медицинские осмотры для определения пригодности этих работников для выполнения поручаемой работы
Блин, ну русский же человек, вроде.
Работники (все, не только здоровые)… проходят (вне зависимости от результата, тупо сам факт завершенности действия)… для определения (ни слова о то, что те, кто признан «не пригодным» не прошел).
Понимаете, проходят. Все проходят. А по результатам одни из них работают дальше, а другие — нет. Нет формулировки «здоровые проходят, а нездоровые не проходят осмотры».
Само понятие — контекстное. По сути означает «принял участие, выполнил набор каких-то действий, процесс завершился, получен какой-то результат». Остальное — вопросы исключительно к тому, что творится в вашей голове.
Сертификацию проходили? Oracle CA, хотя бы. Вы проходите тестирование и в течение 2 месяцев узнаете результат. Т.е. вы положили ручку, сдали листочек — все, тестирование пройдено, этап завершен, за результатами приходите позже.
«Тест пройден успешно» — немного другой контекст, но если «пройден» — однозначное указание на успешность завершения, зачем слово «успешно»?
Собеседование пройдено… Кхм, вы поговорили, вам обещали перезвонить. Это «пройдено» или еще «не пройдено»? Это удача или провал? По вашей логике, пройдено оно тогда и только тогда, когда в вашей трудовой книжке появляется отметка о принятии на работу. А до этого времени… Все еще идёт, что ли?
Работники (все, не только здоровые)… проходят (вне зависимости от результата, тупо сам факт завершенности действия)… для определения (ни слова о то, что те, кто признан «не пригодным» не прошел).
Понимаете, проходят. Все проходят. А по результатам одни из них работают дальше, а другие — нет. Нет формулировки «здоровые проходят, а нездоровые не проходят осмотры».
Само понятие — контекстное. По сути означает «принял участие, выполнил набор каких-то действий, процесс завершился, получен какой-то результат». Остальное — вопросы исключительно к тому, что творится в вашей голове.
Сертификацию проходили? Oracle CA, хотя бы. Вы проходите тестирование и в течение 2 месяцев узнаете результат. Т.е. вы положили ручку, сдали листочек — все, тестирование пройдено, этап завершен, за результатами приходите позже.
«Тест пройден успешно» — немного другой контекст, но если «пройден» — однозначное указание на успешность завершения, зачем слово «успешно»?
Собеседование пройдено… Кхм, вы поговорили, вам обещали перезвонить. Это «пройдено» или еще «не пройдено»? Это удача или провал? По вашей логике, пройдено оно тогда и только тогда, когда в вашей трудовой книжке появляется отметка о принятии на работу. А до этого времени… Все еще идёт, что ли?
Самозванец заучит определения и пройдет эти вопросы.
По крайне мере, самозванец, который даже заучить определения не озаботился, на этом этапе отсеется.
Тут ещё плюс, что отсеиваются не только истинные ленивые самозванцы (которые знаю, что вроде и не дотягивают до сениора, но вдруг прокатит), но и те кто не готовится не из-за лени, а из-за уверенности своей супер-крутости (за те 2 года, что я проработал после окончания университета я уже столько сделал/столько_знаю/столько_умею). Эти вторые вроде никого и не обманывают, он реально верит, что он
Абсолютно согласен. «Пупы земли» могут быть опасны в команде вне зависимости от уровня их скилла.
Собственно, чего греха таить, сам себя в свое время «пупом» считал. Прошло с годами…
Собственно, чего греха таить, сам себя в свое время «пупом» считал. Прошло с годами…
Тут ещё плюс, что отсеиваются не только истинные ленивые самозванцы (которые знаю, что вроде и не дотягивают до сениора, но вдруг прокатит), но и те кто не готовится не из-за лени, а из-за уверенности своей супер-крутости
А я, например, считаю, что подготовка к собеседованию — четкий и явный обман работодателя. По-этому нельзя к ним готовиться, если не хочешь быть обманщиком.
UFO just landed and posted this here
UFO just landed and posted this here
Так перед синьором и стоит задача архитектуры, и паттерны проектирования — её часть. Это и есть сама абстракция, выше синтаксических тонкостей языка.
Какие базовые паттерны применять, на какие классы делить проект да какие будут там отдельные интерфейсы и т.п. — должен уже миддл нормально соображать. Да и у талантливого джуна это зачастую получается приемлимо.
Перед сеньором по части архитектуры стоят задачи более общего уровня, чем банальное «реализовать ли здесь синглтоном».
Я например сейчас раздумываю насчет того на какие куски порезать нашу проектируемую систему по функционалу, чтобы репликация между серверами не снижала производительность.
У вас нет системного архитектора в конторе?
У вас нет системного архитектора в конторе?
Я и есть.
P.S.:
джун, миддл, сеньор — это про уровень квалификации.
а системный архитектор — это про функционал, про должность.
данные понятия — вообще параллельны, они о разном. (кроме того факта, что архитектор как правило сеньор).
Но вы не пишите код, верно?
Но вы не пишите код, верно?
Пишу. Мне это нравится.
Даже основывал 4 фирмы (2 с партнерами, 2 сам). Но когда доходит до того, что нужно менеджером быть, а не разработчиком — завязывал. Не нравится мне это — не писать код лично.
Вы намекаете на настоятельную необходимость выделенного архитектора в любом произвольном проекте?
Нет, это не так.
Выделенный архитектор нужен только в огромных проектах. Проектирование и создание кода одним человеком — вполне сочетается даже в группах программистов и в 50 человек (а это огромная сила, очень серьезные вещи куда как меньшим числом созданы).
Архитектор вовсе не продумывает все до последнего класса в системе. Свои куски разработчики вполне способны продумать сами.
У меня на придумки по архитектуре уходит процентов 10-40 рабочего времени в неделю.
UFO just landed and posted this here
UFO just landed and posted this here
Но паттерны — это не «базовые конструкции языка», как было в цитате. Тут на самом деле «мы это применяли до того, как это стало мейнстримом».
А расскажите, пожалуйста, что такое структурная и мнемоническая типизация? Ни разу не встречал таких понятий, любопытно стало.
UFO just landed and posted this here
Спасибо! Знаю теперь, какой вопрос на следующем собеседовании задать Не был знаком с такой терминологией.
Недавно у меня был характерный случай, когда Nominal typing проявил свои отрицательные качества. Суть: есть два класса, определенные во внешней библиотеке, имеющие одинаковую семантику, одинаковые поля (по крайней мере, в той части, которая меня интересовала), даже называются одинаково, но находятся в разных пространствах имен. И мне нужно конвертировать сущности любого их этих классов в мой собственный класс и обратно, по возможности с минимумом дублирования кода. Интерфейса общего нет, предка общего нет, копипасту плодить очень не хочется… Выручил как раз подход в стиле Structural typing — метод принимает dynamic и обращается к нужным свойствам, выполняет конвертацию. Чтобы не выстрелить себе в ногу, методы с dynamic-ами сделал приватными, а публичными сделал обертки со строгой типизацией.
Недавно у меня был характерный случай, когда Nominal typing проявил свои отрицательные качества. Суть: есть два класса, определенные во внешней библиотеке, имеющие одинаковую семантику, одинаковые поля (по крайней мере, в той части, которая меня интересовала), даже называются одинаково, но находятся в разных пространствах имен. И мне нужно конвертировать сущности любого их этих классов в мой собственный класс и обратно, по возможности с минимумом дублирования кода. Интерфейса общего нет, предка общего нет, копипасту плодить очень не хочется… Выручил как раз подход в стиле Structural typing — метод принимает dynamic и обращается к нужным свойствам, выполняет конвертацию. Чтобы не выстрелить себе в ногу, методы с dynamic-ами сделал приватными, а публичными сделал обертки со строгой типизацией.
{x:Int, y:Int}— это и есть тип.{x:Int, y:Int, z:Int}` — его субтип всегда, в любых условиях. Из недостатков — сложности с рантайм-проверками типов, более тормозной тайпчекинг, ну и отношения сабтайпинга задаёте не вы, поэтому могут случайно оказаться связанными два семантически несвязанных типа.Проблемы с вариантностью еще забыли, ведь в любом нормальном языке рекорды должны быть мутабельными.
Nominal
Я из контекста понял, что под "мнемонической" подразумевалось nominal, но это правда где-то есть такой перевод?
В тайпскрипт еще есть ограничение глубины проверки (т.е. проверяется вниз на N уровней) иначе она может занять бесконечное время для рекурсивных структур данных или типа того. Поэтому там дизайн-там чекинг не гарантирует соответсвие типов в рантайме. Интересно, как в других языках.
Ну, у всех такие собеседования были, и у меня. Не расстраивайтесь. У меня был период, когда нужно было каждую неделю нанимать. Пришлось сделать опросник по темам c#, sql, english, ООП и др. Когда человек запинался на первом блоке вопросов, то переходили сразу на другой. Из-за огромного потока людей, видимо, часть собеседуемых воспринимало наши вопросы как академические. Ну, не всегда есть возможность «поговорить по душам».
А вот как вы думаете верно ли то, что решение брать или не брать принимается в первые 10-15 минут, а дальше идет обдумывание как бы это обосновать?
Не знаю, как на собеседовании (не проводил), но когда приходит студент и просит научного руководства, то через 3-5 минут разговора мне уже понятен уровень будущей ВКР. И скажем, не от большого опыта руководства это, а от того, что сразу видно зачем человеку это надо (если для галочки, то я сразу рекомендую найти другого научрука). Интересно, что мое мнение не всегда сходиться с мнением студента и в итоге получается недоделанная работа.
UFO just landed and posted this here
Если сформулировать коротко: здесь на собеседовании пытаются найти что-то, что вы не знаете, там — что-то, что вы знаете хорошо.
В точку!
Как Вы отнесетесь к человеку, который при знакомстве захочет проверить, не карманник ли Вы, на том основании, что его недавно обокрали?
Дам ему проверить. Почему надо на это оскорбляться?
Особенность не культурная, а экономическая. На западе и близко нет такого хайпа по IT, как в СНГ (потому что «там платят кучубабла») — отсюда и самозванцев меньше.
UFO just landed and posted this here
На самом деле расстраиваться из за такого собеседования не стоит. Любое собеседование является обоюдным. Надо радоваться когда человек с которым ты будешь работать сразу показывает свое лицо. Было бы гораздо хуже если бы взяли на такую работу, а потом показали бы свое лицо. Не знать что такое virtual для ведущего разработчика, это, конечно, плохо. Но еще хуже если собеседующий радуется и не может даже скрыть своей радости по этому поводу. Думаю стоит порадоваться что провалили это собеседование.
Вы тестовых заданий хотите? Вот вам тогда встречная история.
Пару месяцев назад получил письмо от одной компании, я туда честно говоря не собирался, но так было красиво все расписано… В общем мне тоже вдруг показалось что будет разговор с умным человеком, и я клюнул. Мне сразу же прислали тестовое задание, и это тоже мне понравилось, простой и эффективный способ фильтрации нулевого уровня, задание не сложное, но и не совсем тривиальное, значит потом будет еще интереснее. Короче, поехали.
Просят реализовать некоторый алгоритм с максимальной эффективностью и ограничениями на память, особенно просят учесть все пограничные случаи. Дается на все девять часов.
За первый час написал базовую реализацию, еще час потратил на выявление этих самых пограничных случаев (и нашел таки парочку), потом час отдохнул (времени еще впереди немеряно), еще на раз все проверил, написал детальные комментарии, написал и прогнал несколько юнит тестов. Потом осенило как можно улучшить, переписал и снова все протестировал. Несколько часов пролетели незамено и вот, за десять минут до конца, я отправляю код и собираюсь выпить наконец чаю… Не успел — ответ пришел через 20 секунд. «Ваш код содержит потенциально опасные места в пограничных случаях и не может быть принят»
Вот я дурак, ну разумеется никто мой код читать и не собирался, это статический анализатор. Но это не такой уж сложный алгоритм и я абсолютно уверен что все сделал верно. А вот и одно из возможных проблемных мест — адресация массива по индексу без проверки выхода за праницы. Но позвольте, из предыдущих трех строк кода очевидно следует что индекс в данном случае всегда остается в нужных рамках, а вот и комментарий где прямо это все обьясняется. Но возможно я слишком многого хочу от анализатора?
Оставшиеся десять минут потратил на то чтобы убедиться — подстроиться под требования конечно можно, но тогда будет банальный спагетти-код, за который я бы и браться не стал, ибо скучно. А зачем было спрашивается просить максимальную эффективность? И разве трудно было прогнать все эти пограничные тесты (как я и сделал для себя) и проверить что все работает?
Я понимаю конечно что компания в своем праве, но все равно, ощущение что в тебя плюнули остается надолго. Ну а я им в ответ желаю набрать именно тех разработчиков, которые с блеском пройдут этот тест).
Пару месяцев назад получил письмо от одной компании, я туда честно говоря не собирался, но так было красиво все расписано… В общем мне тоже вдруг показалось что будет разговор с умным человеком, и я клюнул. Мне сразу же прислали тестовое задание, и это тоже мне понравилось, простой и эффективный способ фильтрации нулевого уровня, задание не сложное, но и не совсем тривиальное, значит потом будет еще интереснее. Короче, поехали.
Просят реализовать некоторый алгоритм с максимальной эффективностью и ограничениями на память, особенно просят учесть все пограничные случаи. Дается на все девять часов.
За первый час написал базовую реализацию, еще час потратил на выявление этих самых пограничных случаев (и нашел таки парочку), потом час отдохнул (времени еще впереди немеряно), еще на раз все проверил, написал детальные комментарии, написал и прогнал несколько юнит тестов. Потом осенило как можно улучшить, переписал и снова все протестировал. Несколько часов пролетели незамено и вот, за десять минут до конца, я отправляю код и собираюсь выпить наконец чаю… Не успел — ответ пришел через 20 секунд. «Ваш код содержит потенциально опасные места в пограничных случаях и не может быть принят»
Вот я дурак, ну разумеется никто мой код читать и не собирался, это статический анализатор. Но это не такой уж сложный алгоритм и я абсолютно уверен что все сделал верно. А вот и одно из возможных проблемных мест — адресация массива по индексу без проверки выхода за праницы. Но позвольте, из предыдущих трех строк кода очевидно следует что индекс в данном случае всегда остается в нужных рамках, а вот и комментарий где прямо это все обьясняется. Но возможно я слишком многого хочу от анализатора?
Оставшиеся десять минут потратил на то чтобы убедиться — подстроиться под требования конечно можно, но тогда будет банальный спагетти-код, за который я бы и браться не стал, ибо скучно. А зачем было спрашивается просить максимальную эффективность? И разве трудно было прогнать все эти пограничные тесты (как я и сделал для себя) и проверить что все работает?
Я понимаю конечно что компания в своем праве, но все равно, ощущение что в тебя плюнули остается надолго. Ну а я им в ответ желаю набрать именно тех разработчиков, которые с блеском пройдут этот тест).
А что всех так удивляет, что ищут «функцию», а не «человека»? Вы, когда сапожника просите каблук прибить — вам интересно, чтобы он мог это сделать здесь и сейчас или его взгляды на последние новинки модельной обуви, представленной на показах в Милане?
---Убей не помню.
Очень странно. Если вы не пользовались этим оператором, раз у вас этим затруднение, то у вас слабое представление о ООП, и значит потерян целый пласт девелопмента и дальше действительно не о чем спрашивать.
В ряде организаций вполне могут спросить как это имплементировано в компиляторе и что такое виртуальные таблицы — и поверьте — это отнюдь не праздный вопрос.
По крайней мере в Bloomberg меня об этом спрашивали и я знаю зачем это нужно.
Очень странно. Если вы не пользовались этим оператором, раз у вас этим затруднение, то у вас слабое представление о ООП, и значит потерян целый пласт девелопмента и дальше действительно не о чем спрашивать.
В ряде организаций вполне могут спросить как это имплементировано в компиляторе и что такое виртуальные таблицы — и поверьте — это отнюдь не праздный вопрос.
По крайней мере в Bloomberg меня об этом спрашивали и я знаю зачем это нужно.
Я тоже так сразу и подумал, но судя по стилю текста, общим описаниям и т.д. автор вполне адекватен, значит дело в чем-то другом, включая банальный ступор или интерференцию синтаксиса языков. Нормально, если человек не знает синтаксис fixed или unchecked, но не знать virtual он не может, скорее просто забыл в мандраже слово или не понял вопрос. И вполне он может знать и про работу vtbl, просто надо сбавить обороты и разобраться, что происходит. В этом и посыл статьи. Гораздо легче сразу завернуть кандидата, чем подумать.
е важно, что я помню поведение virtual и его назначение, не помню только само слово. Что я регулярно разрабатываю с использованием четырёх языков программирования, и не могу помнить досконально все их самые пыльные углы.
Всё написано вами правильно, и мысли в точности как мои, написанные 2 года назад =)
Знакомая до боли ситуация. У меня есть статья в которой я описывал быстрый рост компании изнутри: cleverman.org/post/problemy-pri-roste-it-kompanii Из нее станет понятно, что в таких «Динамично развивающихся молодых компаниях» очень часто тимлидами или руководителями проекта являются джуны с новыми лычками. Которые, естественно, на собеседовании спрашивают то, что сами только вчера вычитали в справочнике. Это ведь классика.
Один мой очень хороший знакомый и отчасти мой наставник сказал мне такую вещь: — К разработчикам уже давно относятся как к ремесленникам!
Я так не считаю, Бог не тот кто управляет. Бог то — кто пишет код.
Я полностью согласен с автором и целиком разделяю его переживания.
Но переживать не стоит, пока не сменится идеология подхода в разработке ПО в целом по РФ.
Я так не считаю, Бог не тот кто управляет. Бог то — кто пишет код.
Я полностью согласен с автором и целиком разделяю его переживания.
Но переживать не стоит, пока не сменится идеология подхода в разработке ПО в целом по РФ.
Думать и предвидеть — вот хороший скилл.
К сожалению, все менее и менее востребованный…
Все чаще вижу, что создатели процессов стараются задачу «думать» переложить на целую кучу людей. О том, «зачем», должен думать продакт, о том, «как» — архитектор и системный аналитик, о том «когда, и кем» — проджект, а программист = интерпретатор тз в код. Как будто, те, кто так поступает, считают, что умение писать код одновременно понижает остальные скиллы.
На последнем проекте, очень крупный портал недвижимости (работал сениор разрабом), я пришел к тимлиду и говорю, что те алгоритмы которые ты применил не стоит тут использовать. Я с ними проработал более 5 лет в другом проекте и знаю все проблемы, которые обязательно всплывут. Объяснил что, как и почему, все аргументировал. Тем более, что он с этим не работал и решил просто попробовать. В итоге он мне ответил, что меня взяли не думать, а код писать. Около месяца я осмысливал эти слова и просто уволился.
Просто писать код должны мартышки. И многие работодатели хотят нанять именно мартышек, хотя декларируют совсем другое. Такова реальность.
Просто писать код должны мартышки. И многие работодатели хотят нанять именно мартышек, хотя декларируют совсем другое. Такова реальность.
Собеседывают как будто ты будешь писать код для межконентальных ядерных ракет а на деле делают однообразные тривиальные проекты с уже протоптанными решениями и то на выходе получается не всегда стабильно работающий софт или сайт.
Не грейте голову из-за ерунды. Устройство на работу, это процесс. С точки зрения кандидата хорошая метрика, это количество времени, потраченного на общение с конторой.
До вопроса, что такое SOLID дошли? :)
Собеседование в обе стороны идет. Подумайте хотели бы вы с этим топищем каждый день в одном офисе и на одних и тех же проектах работать?
А вы удивляетесь, почему js настолько популярен? Вот он ответ — «Senior full-stack .NET Developer» забыл что такое virtual.
«стараюсь избегать» следует понимать, как «не использую совсем»?
И уже не важно, что я на самом деле стараюсь избегать классического наследования
«стараюсь избегать» следует понимать, как «не использую совсем»?
А можно задать вопрос. В каких случаях вы применяли наследование обоснованно?
Когда явно прослеживается связь «is-a»
Ну в книжке я тоже прочесть мог бы. Был у вас в реальной жизни такой пример?
Ну в книжке я тоже прочесть мог бы
А без книжки? :) Ну да, я загуглил по быстрому «is-a наследование», чтобы лишний раз убедиться, что ничего не путаю. Но я это знал и не забывал.
Был у вас в реальной жизни такой пример?
Например, сейчас пишу слот-машину… Базовый автомат содержит один барабан, который крутится 3 раза (эмулируя 3 барабана, т.е. на всех барабанах одинаковые вероятности), я хочу сделать 3 различных барабана + немного кастомизировать размеры ставок. В принципе, я уже написал формально работающую слот-машину, расширив SlotMachine классом WildCherry, и получив 2 работающих автомата.
PS Позволю себе сделать предположении, что вы начнете задавать вопросы в духе «а, что если?» — сразу говорю, это не ко мне :) Пример из реальной жизни и моего пет-проекта, написанный с целью изучения математики.
> Но я это знал и не забывал.
На интервью у вас возможно и не будет гугла. Но именно потому теоритические знания и зазубривания определений смысла не имеют (имхо), кроме того после книжного определения дальше говорить не о чем. Если же вы практически его применили и обдумали сценарий — то это можно с вами обсудить, как с будущим коллегой, заодно убедившись что с вами можно нормально общаться по техническим вопросам.
> Например, сейчас пишу слот-машину… Базовый автомат содержит один барабан,
> который крутится 3 раза (эмулируя 3 барабана, т.е. на всех барабанах
> одинаковые вероятности), я хочу сделать 3 различных барабана + немного
> кастомизировать размеры ставок.
Я правильно понимаю, что у вас есть базовый автомат, который крутится и автомат, который агрегирует три барабана и вы можете заменять агрегированные барабаны наследниками или у вас есть базовый автомат с тремя барабанами SlotMachine которой наследует WildCherry? На каком уровне наследование?
> «а, что если?»
Я тоже к таким вопросам отношусь с подозрением. Стараюсь их избегать, когда сам собеседую. Во-первых помечтать можно обо всяком. Не факт что в обстановке стресса (хотфикс например) мечтаться будет так же радужно. Интереснее что уже вы сделали с такой обстановке и почему.
На интервью у вас возможно и не будет гугла. Но именно потому теоритические знания и зазубривания определений смысла не имеют (имхо), кроме того после книжного определения дальше говорить не о чем. Если же вы практически его применили и обдумали сценарий — то это можно с вами обсудить, как с будущим коллегой, заодно убедившись что с вами можно нормально общаться по техническим вопросам.
> Например, сейчас пишу слот-машину… Базовый автомат содержит один барабан,
> который крутится 3 раза (эмулируя 3 барабана, т.е. на всех барабанах
> одинаковые вероятности), я хочу сделать 3 различных барабана + немного
> кастомизировать размеры ставок.
Я правильно понимаю, что у вас есть базовый автомат, который крутится и автомат, который агрегирует три барабана и вы можете заменять агрегированные барабаны наследниками или у вас есть базовый автомат с тремя барабанами SlotMachine которой наследует WildCherry? На каком уровне наследование?
> «а, что если?»
Я тоже к таким вопросам отношусь с подозрением. Стараюсь их избегать, когда сам собеседую. Во-первых помечтать можно обо всяком. Не факт что в обстановке стресса (хотфикс например) мечтаться будет так же радужно. Интереснее что уже вы сделали с такой обстановке и почему.
На интервью у вас возможно и не будет гугла. Но именно потому теоритические знания и зазубривания определений смысла не имеют (имхо), кроме того после книжного определения дальше говорить не о чем. Если же вы практически его применили и обдумали сценарий — то это можно с вами обсудить, как с будущим коллегой, заодно убедившись что с вами можно нормально общаться по техническим вопросам.
Зубрить не обязательно, но теорию знать нужно, чтобы при решении задач не основываться на субъективном опыте. Как вы себе представляете специалиста по ai, big data и другим модным словам? 2 варианта:
Он знает теорию, или вся его карьера строилась и продолжает строиться на методе научного тыка.
Вот так поддаешься на умные речи «сеньоров» и периодически смотришь на проделанную им работу за 2-3 месяца — всё чистенько, красиво. Через 2 года обращаешь внимание на код приложения целиком и осознаешь, что это полная жопа (по другому выразиться нельзя): новых фич практически нет, объем кода увеличился в десятки раз, одни и те же задачи решены по нескольку раз, нижние слои абстракции уже никто не использует 100 лет. Спрашиваешь у «сеньора», что за ерунда, а в ответ «вы ничего не понимаете, иначе невозможно. И вообще я рок звезда, без меня вы ничего не сможете». Вот такие сеньоры без теории.
Я правильно понимаю, что у вас есть базовый автомат, который крутится и автомат, который агрегирует три барабана и вы можете заменять агрегированные барабаны наследниками или у вас есть базовый автомат с тремя барабанами SlotMachine которой наследует WildCherry? На каком уровне наследование?
Автоматом я называл саму слот-машину, прошу прощения — я вас запутал.
Визуально представьте простую слот-машину. Кидаешь деньги, нажимаешь на кнопку и на экране начинают крутиться 3 колеса (их я называю барабанами). В базовой слот-машине визуально 3 барабана, в коде SlotMachine — это 1 барабан, который крутится 3 раза. Код WildCherry содержит 3 барабана, которые крутятся по 1 разу.
Код простой (2 класса, не считая хелперы, структуры, тесты), WildCherry расширяет SlotMachine, добавляет метод bet и переопределяет метод run.
Да не принимай ты это так близко к сердцу… Я вот наоборот если и столкнусь где с такой фигнёй на собесе — дико радуюсь, что эта фигня всплыла именно на собесе, а не позже, когда уже подписал НДА, записал в трудовую и т.д. и т.п.
Сам сейчас провожу собеседования время от времени и честно теряюсь — а что у людей то спрашивать? Опять про HashMap? Так ведь половина и этого не знает, сложности алгоритмов, синхронизацию… Был бы рад толковой шпаргалке «как проводить собеседования», можно даже сайт сделать с 100500 вопросов по каждой теме, с голосовалками за вопросы «хороший/полезный или пыль»…
Ну т.е. харе писать как вас плохо отсобесили, давайте писать «как надо собесить».
Сам сейчас провожу собеседования время от времени и честно теряюсь — а что у людей то спрашивать? Опять про HashMap? Так ведь половина и этого не знает, сложности алгоритмов, синхронизацию… Был бы рад толковой шпаргалке «как проводить собеседования», можно даже сайт сделать с 100500 вопросов по каждой теме, с голосовалками за вопросы «хороший/полезный или пыль»…
Ну т.е. харе писать как вас плохо отсобесили, давайте писать «как надо собесить».
Я когда провожу собеседования всегда иду по одному и тому же шаблону:
1) Расскажи о последнем или о любом, на выбор кандидата, проекте. Что, зачем, для кого, какой итог (штатовская аббревиатура CAR Context Action Result)? (работал работу на работе за зарплату — не катит)
2) Что конкретно ТЫ на нем делал? Затрудняешься — тогда расскажи про любой рабочий день вот ты пришел во сколько-то и что дальше было до конца дня? (очень много тех кого научили говорить «мы»)
3) В зависимости от ответов на вопрос 2, 1 и то, что написано в резюме ищу тему, с которой у нас сейчас на проекте затык и прошу рассказать как конкретно это было решено. Например если указана технология — прошу описать для чего, как была использована, как принималось решение и кем. (цель — понять может ли человек привнести что-то новое, идеально если уже прошелся по граблям, по которым мы только собираемся идти, ну или понять может ли впрячься и пахать)
4) В какой форме пришла задача на решение. Какие дальше шаги были произведены для превращения ее в рабочий продукт. (понять в каких процессах привык работать, насколько любит проявлять инициативу — по последнему критерию команды надо всегда стараться балансировать).
Обычно на этом время заканчивается, иногда бывает что приходится в некоторые вопросы углубиться, но в целом становится понятно чем человек занимался и какие перед ним ставились задачи и можно ли его куда-нибудь применить. Иногда бывает, что человек вот уж очень понравился, но у нас его некуда приткнуть — пробую другим отделам посоветовать.
Ну это для людей которые что-то делали когда-то. Со студентами когда приходилось иметь дело — то хорошо если у них есть что рассказать про дипломную или курсовую, хуже если приходится спрашивать по алгоритмам и структурам данных. С ними все что можно проверить это общая соображалка и поверю ли я в их обучаемость.
1) Расскажи о последнем или о любом, на выбор кандидата, проекте. Что, зачем, для кого, какой итог (штатовская аббревиатура CAR Context Action Result)? (работал работу на работе за зарплату — не катит)
2) Что конкретно ТЫ на нем делал? Затрудняешься — тогда расскажи про любой рабочий день вот ты пришел во сколько-то и что дальше было до конца дня? (очень много тех кого научили говорить «мы»)
3) В зависимости от ответов на вопрос 2, 1 и то, что написано в резюме ищу тему, с которой у нас сейчас на проекте затык и прошу рассказать как конкретно это было решено. Например если указана технология — прошу описать для чего, как была использована, как принималось решение и кем. (цель — понять может ли человек привнести что-то новое, идеально если уже прошелся по граблям, по которым мы только собираемся идти, ну или понять может ли впрячься и пахать)
4) В какой форме пришла задача на решение. Какие дальше шаги были произведены для превращения ее в рабочий продукт. (понять в каких процессах привык работать, насколько любит проявлять инициативу — по последнему критерию команды надо всегда стараться балансировать).
Обычно на этом время заканчивается, иногда бывает что приходится в некоторые вопросы углубиться, но в целом становится понятно чем человек занимался и какие перед ним ставились задачи и можно ли его куда-нибудь применить. Иногда бывает, что человек вот уж очень понравился, но у нас его некуда приткнуть — пробую другим отделам посоветовать.
Ну это для людей которые что-то делали когда-то. Со студентами когда приходилось иметь дело — то хорошо если у них есть что рассказать про дипломную или курсовую, хуже если приходится спрашивать по алгоритмам и структурам данных. С ними все что можно проверить это общая соображалка и поверю ли я в их обучаемость.
Что? Какие HashMap и сложность?
У меня на собеседовании первый вопрос: есть список std:list data любым способом удалить из него элементы с четным значением.
С тем, кто хотя бы попытается написать цикл с итератором уже можно пробовать говорить на должность С++ разраба. Увы на это только 10% отвечают...
Причем этот вопрос актуален даже для сеньеров. Там проблема в том, что если пришел действительно стоящий человек то его подобное может оскорбить.
Хотите упростить ваш вопрос, оставив такой же выхлоп? Спросите чем список от массива отличается :). Но насколько эти вопросы помогают с тем, чтобы вам заполнить позицию?
Список не может быть массивом?
"Во валит". На самом деле вопрос с подвохом. Варианты от банального цикла по итераторам до алгоритмов. кто то пытается с наскоку цикл с auto. кого то можно спросить про валидность итераторов после манипуляций с контейнером.
И да помогает. Практика показывает что нормальный программер довольно просто решает такую задачку, чуть раскрепощается и меньше волнуется.
Но все таки основная цель отсеять мусор как можно раньше.
Причем эту задачу я мог бы просить НR задавать перед приглашением. Но я хочу видеть сам: у меня был сотрудник — как программист талантливейший. Но самооценка ниже плинтуса. любой вопрос на собеседовании — волновался и тупил вплоть до таблицы умножения. Но все равно видно делал человек подобное раньше или нет
А так да. дальше уже можно спрашивать и про интрузивные контейнеры и про сложности алгоритмов с подковыками: например когда тупой поиск перебором
в векторе оказываетсяя быстрее поиска по ключу в ассоциативном контейнере.
Несколько вопросов:
1) data.remove_if(...) хоть кто-то из кандидатов предложил?
1.1) если предлагают такое решение или даже через data.erase(std::remove_if(...), data.end()); вы засчитываете такое или просите всё-таки сделать на итераторах?
2) как часто рассказывают о мифической std::erase?
3) если кандидат говорит, что-то типа «давно не работал с STL, в последнее время работаю в основном с YYY» позволяете ли решить задачу в терминах его YYY, например для Qt'шного QLinkedList или для шарпового LinkedList?
1) data.remove_if(...) хоть кто-то из кандидатов предложил?
1.1) если предлагают такое решение или даже через data.erase(std::remove_if(...), data.end()); вы засчитываете такое или просите всё-таки сделать на итераторах?
2) как часто рассказывают о мифической std::erase?
3) если кандидат говорит, что-то типа «давно не работал с STL, в последнее время работаю в основном с YYY» позволяете ли решить задачу в терминах его YYY, например для Qt'шного QLinkedList или для шарпового LinkedList?
я же сказал "любым способом".
вариант с remove_if был только один раз.
и нет цели "засчитать" есть цель понять каков уровень у кандидата. имеет ли смысл сразу переходить на более высокий уровень или стоит поспрашивать. если не использовал итераторы в решении то я и так спросить про них могу без задачи.
если давно не работал и не помнит стл это уже звоночек (мне таки нужен стл). но пускай решит в терминах известного ему инструмента — скорее как успокаивающий фактор.
но я могу себе это позволить — у нас широкий спектр вакансий и если я вижу, что на сеньера он не тянет, но кандидат толковый могу предложить позицию пороще в том числе в команде помладше.
Бывает. Не стоит расстраиваться. Но считаю, что вы сделали неправильный вывод из ситуации:
Такой подход очень сильно ограничивает вас.
На мой взгляд правильный вывод должен быть другой. Да, собеседование зачастую — это дурацкая игра. Поэтому и готовиться надо как к игре. За неделю до собеседование погуглите «top c# interview questions» (или какие другие технологии вы используете). Зазубрите ответы на бессмысленные вопросы, типа, сколько поколений в сборщике мусора, список из 10 отличий структуры от класса, расшифровки аббревиатур (SOLID, например), 3 главных слова про ООП, разновидности полиморфизма и т.д. Это никак не изменит ваши реальные качества как разработчика, только в глазах собеседующего. Разве что где ещё сможете блеснуть фразой: «это же ad hoc полиморфизм/утиная типизация!».
И ещё интересный момент на собеседованиях — это задачки. Иногда знакомые рассказывают, какие задачки они задают зачастую в весьма посредственные компании. Я в них довольно неплох, но понимаю, что с нуля за час даже в спокойной обстановке дома решение не осилю. Знакомые утверждают, что таким образом они проверяют умение мыслить. Но почему-то не понимают, что лучше всего умение мыслить продемонстрирует человек, который уже эту задачку заранее знает. Поэтому на собеседовании надо играть. Даже если вы знаете ответ и решение, сделайте вид, что усиленно думаете, задавайте больше уточняющих вопросов, спрашивайте, что лучше оптимизировать (использование памяти или сложность, а может и размер кода).
И ещё. Не навешивайте ярлыки сразу. А в конце собеседования, если ярлык всё-таки прилип, осознайте, что с пафосными напыщенными идиотами лучше не работать. К счастью рынок труда сейчас это позволяет.
теперь, пока за мной не будет стоять мой код, на собес я не пойду
Такой подход очень сильно ограничивает вас.
На мой взгляд правильный вывод должен быть другой. Да, собеседование зачастую — это дурацкая игра. Поэтому и готовиться надо как к игре. За неделю до собеседование погуглите «top c# interview questions» (или какие другие технологии вы используете). Зазубрите ответы на бессмысленные вопросы, типа, сколько поколений в сборщике мусора, список из 10 отличий структуры от класса, расшифровки аббревиатур (SOLID, например), 3 главных слова про ООП, разновидности полиморфизма и т.д. Это никак не изменит ваши реальные качества как разработчика, только в глазах собеседующего. Разве что где ещё сможете блеснуть фразой: «это же ad hoc полиморфизм/утиная типизация!».
И ещё интересный момент на собеседованиях — это задачки. Иногда знакомые рассказывают, какие задачки они задают зачастую в весьма посредственные компании. Я в них довольно неплох, но понимаю, что с нуля за час даже в спокойной обстановке дома решение не осилю. Знакомые утверждают, что таким образом они проверяют умение мыслить. Но почему-то не понимают, что лучше всего умение мыслить продемонстрирует человек, который уже эту задачку заранее знает. Поэтому на собеседовании надо играть. Даже если вы знаете ответ и решение, сделайте вид, что усиленно думаете, задавайте больше уточняющих вопросов, спрашивайте, что лучше оптимизировать (использование памяти или сложность, а может и размер кода).
И ещё. Не навешивайте ярлыки сразу. А в конце собеседования, если ярлык всё-таки прилип, осознайте, что с пафосными напыщенными идиотами лучше не работать. К счастью рынок труда сейчас это позволяет.
Да это много где так.
Сам лично с таким сталкивался.
Причем не только в сфере программирования а вообще в сфере IT (администрирование, сетевики и т.д.).
Ничего страшного не случилось, нет так нет — смотрите другую вакансию.
Сам лично с таким сталкивался.
Причем не только в сфере программирования а вообще в сфере IT (администрирование, сетевики и т.д.).
Ничего страшного не случилось, нет так нет — смотрите другую вакансию.
Если не подозревать разрабов в самозванстве на собеседовании, то есть риск нанять стадо шимпанзе вместо людей. С другой стороны, паранойя тоже долна иметь границы.
Вы неправильно относитесь к собеседованию. Относитесь к нему как к возможности освежить память, размять мозг и узнать что-то новое, раскрыть свои слабые стороны. А потом уже работать в нужном направлении. Я понимаю, что первичная цель все же — найти работу. Но будьте готовы, что несколько собеседований вы наверняка провалите. Ну вот просто потому, что собеседуемые бывают разные, могут завернуть просто потому, что человек не с той ноги встал сегодня, всякое бывает. Но чем больше собеседований вы проходите, тем проще будут даваться все остальные, с учётом того, что вы будете по пути закрывать свои пробелы в знаниях, учить то, что забыли. Хорошо, что компаний много, не сростется с одной, попробуйте с остальными. И главное, не отчаивайтесь. Относитесь к собеседованию, как к игре. Психологически так намного проще.
Хорошо, что компаний много, не сростется с одной, попробуйте с остальными.В крупных городах. Например я планирую переходить в андроид, и я знаю всего 3 компании в городе в которых могут взять андроид разраба. И то в одной очень вряд ли новичка в технологии возьмут. В реале скорее всего больше — но это те что я нашел. И не надо заводить шарманку про переезд в нерезиновую.
Приведу здесь свой пример. Пользовался фабричными методами, еще когда не знал, что существуют паттерны и, соответственно, как они называются. Просто додумался, что вот так будет удобно. Отсюда два тезиса: нет никакой необходимости знать (помнить) названия и, более того, не всегда есть необходимость знать даже определения. Разработчика характеризует всегда конечный результат в виде продукта, качества кода, взаимодействия с командой и т.д. Каким путем он к этому пришел — никого не должно волновать.
Вопрос кстати интересный. Я раньше такого мнения придерживался но затем немного изменил. Термины важны для коммуникаций (передача знаний, понимание статей на том же хабре, книг).
Это GPU Gems нет необходимости знать. А вот паттерны проектирования и их названия для ООП-разработчика знать совершенно необходимо. Именно для указанного же вами взаимодействия с командой: чтобы один разработчик мог сказать другому "Я применил здесь ФабричныйМетод", и и все было понятно.
Есть конкретные метрики, то же качество взаимодействия с командой. Если эти метрики всех устраивают, то совершенно неважно, за счет чего это достигается. Может человек в двух словах способен описать понятно для всех нужный паттерн, и, если в команде нет снобов, то никому это не мешает. Ну и выучит он их за пару недель, постоянно слыша. Вообще наименьшее, о чем стоит беспокоиться.
С патернами ИМХО вообще все весело, они же не часть языка и не догма, а просто часто используемые и проверенные концепции (кстати, это вроде написано во введении в банде четырех). При есть еще и расхождения что считать синонимами, что отдельными паттернами в разных книгах и документациях, вероятность ответить «неправильно» только потому что интервьюер сторонник другого определения довольно высока.
Извините, но virtual это не название метода которое необязательно знать для его применения. Это ключевое слово показывающее способ наследования метода, на котором собственно строится вообще вся парадигма ООП. Senior не знающий что такое virtual это нонсенс.
Иногда, с вас будут спрашивать теоретические знания, а при этом сами выдавать го***-код.
Как-то сделал замечания старшему разработчику (старшему из двух), что статика не кешируется, и банер в 500кб грузится на каждой странице ( интернет тогда был гораздо хуже чем сейчас), в итоге он что-то наговорил диру, и меня уволили. И такие гниды могут потом собеседовать.
Иногда собеседования не проходил (не перезванивали), но вопросы и задания были адекватными, а иногда нет. Но уже давно не бомбит, просто в жизни есть ***** и они встречаются не только на дороге. Принять сей факт и жить дальше. (Дальше ходить на собеседования)
На вакансия может реально откликнуться несколько человек, и кто-то может показаться работодателю лучше, и он сделает выбор в его пользу, и то что вас не выбрали, не означает автоматом, что вас собеседовал ******(Ваше слово)! Человек идет на собеседование, как правило с целью его пройти, а не для пополнения списка числа своих собеседований.
И тут нужно «ПОКАЗАТЬСЯ» лучше других. И зная что на собеседованиях бывают теоретические вопросы, можно эту теорию и освежись, ведь это поможет выполнению цели (цели пройти собеседование). Если что-то считаете оправданным для достижения цели, то делайте это.
Как-то сделал замечания старшему разработчику (старшему из двух), что статика не кешируется, и банер в 500кб грузится на каждой странице ( интернет тогда был гораздо хуже чем сейчас), в итоге он что-то наговорил диру, и меня уволили. И такие гниды могут потом собеседовать.
Иногда собеседования не проходил (не перезванивали), но вопросы и задания были адекватными, а иногда нет. Но уже давно не бомбит, просто в жизни есть ***** и они встречаются не только на дороге. Принять сей факт и жить дальше. (Дальше ходить на собеседования)
На вакансия может реально откликнуться несколько человек, и кто-то может показаться работодателю лучше, и он сделает выбор в его пользу, и то что вас не выбрали, не означает автоматом, что вас собеседовал ******(Ваше слово)! Человек идет на собеседование, как правило с целью его пройти, а не для пополнения списка числа своих собеседований.
И тут нужно «ПОКАЗАТЬСЯ» лучше других. И зная что на собеседованиях бывают теоретические вопросы, можно эту теорию и освежись, ведь это поможет выполнению цели (цели пройти собеседование). Если что-то считаете оправданным для достижения цели, то делайте это.
Код сортировки пузырьковой
Он разобрать не смог с листа.
Ему давали в детстве мало
Кнута.
Спохватились, ребятки. Вы сами эту профессию выбрали. Это проклятие специалиста во всей своей красе. Да, при текущем раскладе выбирают не обучаемого специалиста, готового обучиться под любую платформу в течение трех месяцев, а готовую функцию/затычку/заглушку под конкретную задачу. И ещё надо быть готовым к тому, что по завершении задачи функция может стать ненужна, кстати. И пойдете вы туда, откуда пришли.
Чтобы разговоров не было — начинал разработчиком в 1991 году, начинал с pl/1 и rexx, в 97 году работал под solaris/sun os (ingres, tcl/tk) закончил разработчиком в районе 2008 года (delphi), решив, что асучник/системный администратор/ремонтник спокойнее, ликвиднее и легче.
Чтобы разговоров не было — начинал разработчиком в 1991 году, начинал с pl/1 и rexx, в 97 году работал под solaris/sun os (ingres, tcl/tk) закончил разработчиком в районе 2008 года (delphi), решив, что асучник/системный администратор/ремонтник спокойнее, ликвиднее и легче.
Но снижая риск найма самозванцев, компании снижают шанс найма хороших разработчиков.
Лично я не вижу в этом проблемы. Я исхожу из того, что при поиске сотрудников компании, в сухом остатке, ищут людей, которые, по мнению компании, будут ей полезны. А иначе нет смысла нанимать человека, если ты от его найма никакой пользы для себя не получишь. Той компании, собеседование в которой описал автор, его услуги не нужны. Ну, не нужны, так не нужны, полагаю, автор уже давно нашел десять других компаний, кому они нужны. Так что, проблемы нет.
Лично я всегда сразу спрашиваю о тестовом задании. Собственно, за мое время поиска работы я их переделал уже тонну. По мне, тестовое задание — это лучший способ для соискателя показать свои возможности, а для работодателя понять, нужен ему такой человек или нет. Наверное, есть такие люди, которые нужны всем, а потому первая же компания, в которую он напишет, возьмет его на работу. Я, например, к таким не отношусь, а потому из множества компаний, кому писал я, мои услуги оказались привлекательными только для одной. Ну, а остальные сочли, что я для них пользы не принесу. По-моему, это вполне естественная ситуация.
Все очень просто. Вы просто «подались» на вакансию, на которую подалось еще 100500 человек. В таких случаях всегда такое. Ваще, синьоров нанимают немножко не так, на самом деле. В основном — через нетворкинг (Маня знает Сашу, а вот Саша знает отличного синьора Артема). Все идет в нормальных конторах через связи, знакомства (в хорошем смысле этого слова).
А выкидывание в outer space вакансии в надежде найти стоящего кандидата — это, в первую очередь, жадность работодателя, т.к. найденному спецу по связям платить сходу придется очень много.
Так что развивайте вашу network контактов, а не бездумно шлите резюмехи на все вакансии в открытом доступе.
А выкидывание в outer space вакансии в надежде найти стоящего кандидата — это, в первую очередь, жадность работодателя, т.к. найденному спецу по связям платить сходу придется очень много.
Так что развивайте вашу network контактов, а не бездумно шлите резюмехи на все вакансии в открытом доступе.
Так он и развивает
Ваще, синьоров нанимают немножко не так, на самом деле. В основном — через нетворкинг (Маня знает Сашу, а вот Саша знает отличного синьора Артема). Все идет в нормальных конторах через связи, знакомства (в хорошем смысле этого слова).
Не все крутые программеры — являются эсктравертами, любящими туссовки и общение.
Многие — даже очень наоборот, и именно потому круты — потому что вместо того, чтобы звиздеть
По мне так всё равно странно что вы не вспомнили virtual. Это как забыть зачем нужен for.
Но я согласен, вопросы совершенно тупые и не к месту.)
Но я согласен, вопросы совершенно тупые и не к месту.)
А почему ты вопросы не задавал?
Зачем ждал вопросы?)
Ахахах :)
Зачем ждал вопросы?)
Ахахах :)
Давно считаю, что собеседование должно базироваться лишь на примере кода и конкретной технической задаче. Ну а автору — не переживать и искать дальше. Всё что не делается — всё к лучшему )
Если вы устраиваетесь на работу через собеседования не по знакомству, примите как факт то, что 80% отказов будет не потому что вы чего-то не знаете, а просто потому, что вы сюда не подходите. По возрасту, по внешнему виду, по характеру и.т.п. Каждый начальник подбирает людей под себя, ориентируясь на собственный опыт. Если у тимлида нет управленческого опыта, он никогда не возьмет человека умнее или старше него. Потому, что не знает как им управлять. И не стоит из-за этого расстраиваться. Сами ищите коллектив в котором вам будет комфортно.
Странно, что разговор (по рассказу) был, как игра в морской бой: "А1 — Мимо вопрос1 — ответил! — вопрос2 — ответил! -вопрос3 — не ответил — То то ж!"
Либо этому конкретному человеку, который через вашу вебку (этого пассажа рассказа не понял, извините — вебка у вас, а себя показывает он) хотел показать себя лузерам, требовалось на чем-то каждого подловить, чтобы доказать что-то себе и окружающим (и тогда ничего не сделаешь, у него цель не нанять, а самоутвердиться), либо цель была найти грамотного и мыслящего, но тогда вам надо было разговор переводить в другую плоскость: «Что такое N — Смешно, мне это точно знакомо, но не могу вспомнить формулировку. Нервничаю, наверное, у вас такая компания известная и т.д. А можно вопросы более практические, вы же не преподавателя ищете со знанием формулировок, а мой код скажет обо мне куда больше?»
Причем этот вопрос ответит и на варианты выше: если ему интересен работник, то, кроме мелкого минуса за незнание, вы получите жирный плюс за работу мозга.
И вот на вакансию стоит отзываться, когда просто готовы провести разговор обычным человеческим языком. Судя по тексту, это у вас вполне получится, просто в этот раз вам самому не понравился собеседник — это, кстати, приличный звоночек вообще туда не идти, если потенциальный более грамотный коллега воспринимается так негативно.
Либо этому конкретному человеку, который через вашу вебку (этого пассажа рассказа не понял, извините — вебка у вас, а себя показывает он) хотел показать себя лузерам, требовалось на чем-то каждого подловить, чтобы доказать что-то себе и окружающим (и тогда ничего не сделаешь, у него цель не нанять, а самоутвердиться), либо цель была найти грамотного и мыслящего, но тогда вам надо было разговор переводить в другую плоскость: «Что такое N — Смешно, мне это точно знакомо, но не могу вспомнить формулировку. Нервничаю, наверное, у вас такая компания известная и т.д. А можно вопросы более практические, вы же не преподавателя ищете со знанием формулировок, а мой код скажет обо мне куда больше?»
Причем этот вопрос ответит и на варианты выше: если ему интересен работник, то, кроме мелкого минуса за незнание, вы получите жирный плюс за работу мозга.
И вот на вакансию стоит отзываться, когда просто готовы провести разговор обычным человеческим языком. Судя по тексту, это у вас вполне получится, просто в этот раз вам самому не понравился собеседник — это, кстати, приличный звоночек вообще туда не идти, если потенциальный более грамотный коллега воспринимается так негативно.
но тогда вам надо было разговор переводить в другую плоскость:
Надо было самому начать задавать вопросы. "У вас тут в описании вакансии написано, что требуется технология Х, но она же не входит в основной стек? откуда взялось это требование? зачем именно нужно Х? В каком контексте мне придется работать с Х? Ах, в контексте Y? Ну тогда у меня есть релевантный опыт вида Z, перейдем к следующему требованию...".
А игра в одни ворота заведомо проигрышная, в конце концов соискателю тоже нужно узнать, с чем и как он работать будет, и с его точки зрения все эти вопросы про виртуал — трата времени.
Приведу цитату известного физика Ричарда Фейнмана из его книги. Он записался на курс для выпускников по биологии и подготовил доклад:
«Когда пришло время делать доклад по этому предмету, я для начала изобразил очертание кошки и принялся называть различные мускулы.
Другие студенты в аудитории перебили меня: «Мы знаем все это!»
— О, вы знаете? Тогда не удивительно, что я могу догнать вас так быстро после четырех лет занятий биологией. — Они тратили все свое время на запоминание ерунды вроде этой, когда это можно было бы посмотреть за 15 минут. »
«Когда пришло время делать доклад по этому предмету, я для начала изобразил очертание кошки и принялся называть различные мускулы.
Другие студенты в аудитории перебили меня: «Мы знаем все это!»
— О, вы знаете? Тогда не удивительно, что я могу догнать вас так быстро после четырех лет занятий биологией. — Они тратили все свое время на запоминание ерунды вроде этой, когда это можно было бы посмотреть за 15 минут. »
Мне вот, честно говоря, не совсем понятно, почему замыкание называется замыканием. Нет, оно понятно, что это функция и всё, что в неё замкнуто, т.е. LexicalEnvironment в случае js, но, действительно, в названии нет зацепок, чтобы быстро вспомнить, что речь идёт о функции, а не о чём-то другом. Поэтому нечаянно можно и забыть термин, прекрасно при этом помня его суть. Иное название помогло бы избежать такого.
Но мне также не совсем понятно, как можно было забыть суть ключевого слова virtual, простейшая зацепка — виртуальная реальность, замещение реальности. То есть виртуальный метод — замещаемый. И вообще, когда говорят virtual, имеют в виду всякого рода замещение. И до этого можно догадаться, будучи знакомым с программированием только поверхностно. И из этого вспомнить суть кейворда.
Поэтому да, на месте HR я бы подумал, стоит ли брать человека, который не то, чтобы не помнит, а не смог сообразить. Соответственно, не сообразивший человек с большой вероятностью будет гуглить там, где не надо, и с языками (естественными) у него не очень, то есть именно что — есть основания полагать, что перед HR — самозванец.
Другая история была бы, я думаю, если бы Вы начали думать вслух и, конечно, по ходу всё-таки сообразили бы, как тот вышеупомянутый профессор. Мастерство ведь не пропьёшь, Вы умный человек, это ясно видно по тексту. И вот это был бы блеск. С точки зрения HR, как и любого другого человека.
Вы просто растерялись. Бывает. Именно что переволновались перед собесом. Вакансия понравилась. И по этой же причине бомбануло…
Но мне также не совсем понятно, как можно было забыть суть ключевого слова virtual, простейшая зацепка — виртуальная реальность, замещение реальности. То есть виртуальный метод — замещаемый. И вообще, когда говорят virtual, имеют в виду всякого рода замещение. И до этого можно догадаться, будучи знакомым с программированием только поверхностно. И из этого вспомнить суть кейворда.
Поэтому да, на месте HR я бы подумал, стоит ли брать человека, который не то, чтобы не помнит, а не смог сообразить. Соответственно, не сообразивший человек с большой вероятностью будет гуглить там, где не надо, и с языками (естественными) у него не очень, то есть именно что — есть основания полагать, что перед HR — самозванец.
Другая история была бы, я думаю, если бы Вы начали думать вслух и, конечно, по ходу всё-таки сообразили бы, как тот вышеупомянутый профессор. Мастерство ведь не пропьёшь, Вы умный человек, это ясно видно по тексту. И вот это был бы блеск. С точки зрения HR, как и любого другого человека.
Вы просто растерялись. Бывает. Именно что переволновались перед собесом. Вакансия понравилась. И по этой же причине бомбануло…
JFYI, В собеседовании проверяются не только навыки. Если тимлид собеседует человека в команду, то он проверяет, сойдутся они характерами, или нет.
Soft skills определяет результат работы иногда больше, чем навык программирования. Особенно, если это команда, и код пишут вместе.
Soft skills определяет результат работы иногда больше, чем навык программирования. Особенно, если это команда, и код пишут вместе.
Даже и не знаю, отчасти согласен с автором, а отчасти нет. Из личного опыта проведения собеседований у меня сложился другой опыт. Проводил собеседования системных администраторов/devops. Возможно у программистов совсем другое дело, тут ничего не могу сказать. И я всегда задавал базовые вопросы, для разминки что ли и для понимания кругозора кандидата.
Например — что такое ДНС/как она (служба) работает/можете подробно описать резолвинг имени www.example.com/можете описать как происходит загрузка linux от момента нажатия кнопки питания до момента… И вы не поверите, 90% сеньоров не могли ответить. А некоторые с большим возмущением начинали говорить — а что это за вопросы и зачем мне это знать? Если что я загуглю за 5 минут.
С одной стороны в чем то они правы, а с другой — если ты сеньор и у тебя 10+ опыта работы, как ты можешь не знать и не уметь объяснить работу ДНС? Для меня это загадка.
Естественно я никогда не прекращал собеседования, если кандидат не знал или не мог ответить, но осадок оставался. Но если я видел, что человек просто волнуется и у него вылетело из головы, у самого тоже бывало такое, особенно когда проходил собеседования на англ-ком языке с иностранными заказчиками, то всегда задавал наводящие вопросы или небольшие подсказки. Если человек реально знал, но просто забыл, то как правило это помогало. Были конечно исключения, когда человек не знал, но благодаря подсказкам выстраивал правильные предположения, но это исключение из правил. Всего один или два человека попались таких из ~40.
И если в итоге было два более менее равных кандидата, но первый условно смог объяснить работу ДНС, то я рекомендовал первого.
Например — что такое ДНС/как она (служба) работает/можете подробно описать резолвинг имени www.example.com/можете описать как происходит загрузка linux от момента нажатия кнопки питания до момента… И вы не поверите, 90% сеньоров не могли ответить. А некоторые с большим возмущением начинали говорить — а что это за вопросы и зачем мне это знать? Если что я загуглю за 5 минут.
С одной стороны в чем то они правы, а с другой — если ты сеньор и у тебя 10+ опыта работы, как ты можешь не знать и не уметь объяснить работу ДНС? Для меня это загадка.
Естественно я никогда не прекращал собеседования, если кандидат не знал или не мог ответить, но осадок оставался. Но если я видел, что человек просто волнуется и у него вылетело из головы, у самого тоже бывало такое, особенно когда проходил собеседования на англ-ком языке с иностранными заказчиками, то всегда задавал наводящие вопросы или небольшие подсказки. Если человек реально знал, но просто забыл, то как правило это помогало. Были конечно исключения, когда человек не знал, но благодаря подсказкам выстраивал правильные предположения, но это исключение из правил. Всего один или два человека попались таких из ~40.
И если в итоге было два более менее равных кандидата, но первый условно смог объяснить работу ДНС, то я рекомендовал первого.
Блин, читаю начало и аж слеза наворачивается…
Тоже «вальнули» на virtual однажды…
И такие собеседования 9 из 10, такое ощущение, что ты пришёл на экзамен в университете…
Тоже «вальнули» на virtual однажды…
И такие собеседования 9 из 10, такое ощущение, что ты пришёл на экзамен в университете…
Сам провожу собеседования регулярно и прохожу тоже. Я боюсь самозванцев, когда приходит человек с лычкой Senior то я ожидаю что него есть некий теоретический бэкграунд. я не говорю что он должен знать все фреймфорки и т.д., но понимать что такое многопоточное программирование и понимать SQL он должен. а много приходило людей которые не понимают этого. и на простой вопрос зачем having они не отвечали.
Может быть я не прав, но в рамках этого интервью разве нельзя было «уточнить» у интервьюера, что такое «Virtual» и объяснить ему причины, по которым для вас этот термин не так важен, даже в рамках этого интервью?
Никого не оправдывая, но если этот человек, пусть и раздутый, но, возможно, заинтересованный — понял бы, что вы не от того, что «самозванец» не знаете, а от того, что вы используете совершенно другой подход в решении задачи?
Никого не оправдывая, но если этот человек, пусть и раздутый, но, возможно, заинтересованный — понял бы, что вы не от того, что «самозванец» не знаете, а от того, что вы используете совершенно другой подход в решении задачи?
По мне так тут следующая ситуация:
Собеседование должно было носить формальный характер(поэтому назначили человека слабо разбирающегося в вопросе, возможно сынка боса), например висит вакансия, но руководство не совсем понимает нужна ли она им. Но на всякий случай (а вдруг попадётся суперспециалист), вакансию мониторят и собеседуют.
А что касается программирования: Если собрать всю доступную на данный момент информацию по программированию и разным описанным подходам и приёмам то получиться большой файл. Этот файл нужно будет ежеминутно/ежечасно пополнять. Представить себе человека (не киборга) который сможет этот файл обрабатывать я не могу. Сознательная часть мозга по моему мнению, вообще не очень хорошо хранит информацию. Поэтому имеем аналог кэша как на PC, загружаем только то что нужно для работы, актуальное в «оперативке», старое потихоньку забываем. Термины могут мозгом по умолчанию считаться не очень важной информацией…
Собеседование должно было носить формальный характер(поэтому назначили человека слабо разбирающегося в вопросе, возможно сынка боса), например висит вакансия, но руководство не совсем понимает нужна ли она им. Но на всякий случай (а вдруг попадётся суперспециалист), вакансию мониторят и собеседуют.
А что касается программирования: Если собрать всю доступную на данный момент информацию по программированию и разным описанным подходам и приёмам то получиться большой файл. Этот файл нужно будет ежеминутно/ежечасно пополнять. Представить себе человека (не киборга) который сможет этот файл обрабатывать я не могу. Сознательная часть мозга по моему мнению, вообще не очень хорошо хранит информацию. Поэтому имеем аналог кэша как на PC, загружаем только то что нужно для работы, актуальное в «оперативке», старое потихоньку забываем. Термины могут мозгом по умолчанию считаться не очень важной информацией…
Тот тип собеседования, которое отсеивает неадекватного (для кандидата, как минимум) работодателя — даже не столько работодателя, сколько конкретный коллектив. Скорее, повод для радости, чем для расстройства, если учесть, что ваш визави мог стать «старшим товарищем» и «наставником», а то и начальником, на постоянной основе.
Подобные статьи и часть комментариев напоминают мне стенания всяких боди-позитив и прочих snowflakes об их ОБВМ и о том, что их никто не любит такими, какие они есть, и которым проще ныть на форумах, чем элементарно привести себя в порядок и начать бегать по утрам.
Все мы считаем себя сеньорами достойными Гугла, но реальность она несколько иная, мягко говоря.
Если вы не major contributor в какой-нибудь популярный open source проект, не работали в условном Гугле, не побеждали в top coder, и вас специально не хантят, то реальность такова, что для работодателя вы — никто. И до тех пор пока у вас за поясом не будет чего-нибудь из вышеперечисленного, будьте готовы каждый раз доказывать, что вы не верблюд.
И выручите уже, бл*ть, эти алгоритмы и структуры данных. Если сеньор за 5/10/15 лет не удосужился взять какую-нибудь Elements of Programming Interviews in Java и потратить три месяца по вечерам, чтобы не тупить при встрече с древовидной структурой, то что-то с этим сеньором не так.
Ну и, наконец, неспособность вспомнить virtual в три часа ночи с бодуна в грозу, для сеньора таки залёт.
И все таки хотелось бы получить ответ: Что такое virtual? Шучу, конечно.
Типовая ситуация, к сожалению. Изменить сторону, которая вас нанимает вы наверное вряд ли сможете. Можете лишь изменится сами. Вариантов много. Можно научится навыкам собеседования и перехватывать инициативу. Можно сделать так, чтобы за вами охотились. Я не думаю, что в 80% случаев вы сможете убедить HR менеджера дать вам тестовое задание, если это не принято. Нафиг ей/ему напрягаться.
Типовая ситуация, к сожалению. Изменить сторону, которая вас нанимает вы наверное вряд ли сможете. Можете лишь изменится сами. Вариантов много. Можно научится навыкам собеседования и перехватывать инициативу. Можно сделать так, чтобы за вами охотились. Я не думаю, что в 80% случаев вы сможете убедить HR менеджера дать вам тестовое задание, если это не принято. Нафиг ей/ему напрягаться.
Некоторые специалисты задают вопрос, как нужно собеседовать, что нужно спрашивать. Могу поделится своими соображениями. Предположим, что вы нанимаете высококвалифицированного специалиста (сениора).
1. Не спрашивайте про основы ООП и вообще синтаксис ЯП. Вы не столько проверите знание соискателя, сколько покажите свою некомпетентность. Вы спросите, а как же отсеять лгунов? Все просто, давайте предположим, что перед нами действительно честный сениор. А значит это не просто человек, который знает синтаксис ЯП — это в первую очередь специалист, который умеет самостоятельно решать задачи любого уровня сложности! И сможет решить эти задачи на любом ЯП, даже на том, которого в глаза не видел. Отсюда переходим к п.2
2. Опытный специалист работал с разными проектами и выполнял нетривиальные задачи. Вот и начните его спрашивать, какие сложные задачи он выполнял, в чем была сложность и как он это решал. Пусть человек плавает в своих водах опыта и знаний. А не в ваших, о которых он ничего не знает. Если вы не понимаете о чем начинает рассказывать специалист, если вы впервые слышите о таких решениях и подходах, значит собеседовать таких специалистов — это не ваш уровень. Предположим, что это ваш уровень, тогда переходим к п.3
3. Исходя из ответов п.2 вы можете задавать уточняющие вопросы: а какая была нагрузка на проект, а как вы с ней справлялись (уточнение про кэширование, шардинг, репликации, оптимизации запросов и т.д.), а как организовывали быстрый отклик при тяжелых операциях (вебсокеты, потоки, слушателиб очереди и т.д.)
4. Если человек вас пытался дурачить, то вы это тут же поймете. Если нет, то вы узнаете что хотите и может и сами немного прокачаетесь.
5. Если нужен реально хороший специалист, то знание ЯП вторично! Это джунам нужен ЯП, как старт в профессию. Спецы же высокого уровня должны строить алгоритмы, архитектуру, находить разные подходы к нетривиальным задачам.
6. Если вы на позицию сениора ищите исключительно послушного кодера — то ваш бизнес уже проиграл, просто вы еще этого не знаете.
1. Не спрашивайте про основы ООП и вообще синтаксис ЯП. Вы не столько проверите знание соискателя, сколько покажите свою некомпетентность. Вы спросите, а как же отсеять лгунов? Все просто, давайте предположим, что перед нами действительно честный сениор. А значит это не просто человек, который знает синтаксис ЯП — это в первую очередь специалист, который умеет самостоятельно решать задачи любого уровня сложности! И сможет решить эти задачи на любом ЯП, даже на том, которого в глаза не видел. Отсюда переходим к п.2
2. Опытный специалист работал с разными проектами и выполнял нетривиальные задачи. Вот и начните его спрашивать, какие сложные задачи он выполнял, в чем была сложность и как он это решал. Пусть человек плавает в своих водах опыта и знаний. А не в ваших, о которых он ничего не знает. Если вы не понимаете о чем начинает рассказывать специалист, если вы впервые слышите о таких решениях и подходах, значит собеседовать таких специалистов — это не ваш уровень. Предположим, что это ваш уровень, тогда переходим к п.3
3. Исходя из ответов п.2 вы можете задавать уточняющие вопросы: а какая была нагрузка на проект, а как вы с ней справлялись (уточнение про кэширование, шардинг, репликации, оптимизации запросов и т.д.), а как организовывали быстрый отклик при тяжелых операциях (вебсокеты, потоки, слушателиб очереди и т.д.)
4. Если человек вас пытался дурачить, то вы это тут же поймете. Если нет, то вы узнаете что хотите и может и сами немного прокачаетесь.
5. Если нужен реально хороший специалист, то знание ЯП вторично! Это джунам нужен ЯП, как старт в профессию. Спецы же высокого уровня должны строить алгоритмы, архитектуру, находить разные подходы к нетривиальным задачам.
6. Если вы на позицию сениора ищите исключительно послушного кодера — то ваш бизнес уже проиграл, просто вы еще этого не знаете.
Вот и начните его спрашивать, какие сложные задачи он выполнял, в чем была сложность и как он это решал.
Вообще странный вопрос, к слову. Сложная задача — это задача, которая далеко выходит за пределы компетенции исполнителя (то есть исполнитель не может решить задачу в приемлемые сроки с приемлемым качеством). Любую другую задачу, согласитесь, не имеет смысла считать сложной, это уже будут задачи простые. Или обычные.
Но если такие задачи специалисту дают — это факап менеджмента, такого в норме быть не должно.
Вообще странный вопрос, к слову. Сложная задача — это задача, которая далеко выходит за пределы компетенции исполнителя (то есть исполнитель не может решить задачу в приемлемые сроки с приемлемым качеством). Любую другую задачу, согласитесь, не имеет смысла считать сложной, это уже будут задачи простые. Или обычные.
Но если такие задачи специалисту дают — это факап менеджмента, такого в норме быть не должно.
))) И тут мы приходим к понятию декомпозиции, к алгоритму поиска эффективного решения для того, чтобы вообще найти подход к тому, как начать решать эту проблему/задачу. Ведь программирование — это не просто написание кода! Это, наверняка, даже не десятая часть в разработке ПО.
Просто произошла дикая подмена понятий! Ведь если мы взглянем на вики определение программиста, то увидим:
Программи́ст — специалист, занимающийся непосредственной разработкой программного обеспечения для различного рода вычислительно-операционных систем.
То есть программист должен решать ЛЮБЫЕ проблемы для достижения цели. А что происходит в реальности?! Тот кто знает синтаксис ЯП и основы ООП, уже считается программистом. А вот и нет! Это не программист, а эрудит, заучивший справочник.
Отсюда и куча проблем, недопонимание и прочие глупости на проектах.
Полностью согласна. Что знание терминологии нужно спрашивать на уровень Джуна. На остальные- опыт и примеры кода. Ибо если человек не первый год программирует, то он уже это всё знает.
Так если знает, то и ответить сможет *trollface*
С большой долей вероятности сможет. Только не будет у вас работать. А если еще и знает себе цену, то тут же прервет собеседование и попрощается. Поэтому тем, кто ищет себе в штат сотрудника, нужно очень хорошо подумать и определится, им реально нужен специалист в команду или они просто потроллить соискателей хотят.
Пожалуйста, никаких проблем. Люди-уникумы, за которыми гоняются, в принципе собеседование проходить не будут. А если он «язвизда» biased, «как вы смеете подозревать меня в незнании такого примитива???!??» то и подавно таких не надо.
Ну по разному в жизни бывает. Могу сказать за себя. Я ВЕБ прогер, часто участвую в разношерстных проектах. Проекты сложные — крупные порталы недвижимости, финансовые аналитические системы, вычислительно-аналитические комплексы и т.д. В итоге мне приходится все это писать на PHP, Python, Ruby, JS, реже Java. Когда я постоянно переключаюсь с бэкенда на фронт и обратно, то очень тяжело настроиться, сосредоточиться и держать внимание на пределе. А представьте себе переключаться постоянно с одного бэкендевого ЯП на другой? Иногда голова от этого отваливаться начинает, так как полностью разный синтаксис, терминология, подходы к разработке и вообще все разное. Возникает вопрос, а что такое основной ЯП? А я не знаю, в зависимости от проекта я могу писать то на одном, то на другом, а часто и на нескольких сразу. И когда мне какой-то «супер спец» по одному ЯП начинает задавать, типа, умные вопросы на знание языка, при чем те вопросы, которые он заранее выписал себе на бумажку долго просматривая мануалы, то у меня ответ сразу простой и вполне очевидный — он слету будет послан на три буквы, вместе со своей говноконторой.
П.С. Все более или менее нормальные места, куда я попадал, спрашивали о том, как бы я решал конкретную бизнес задачу заказчика. А все говноконторы, которые были мной посланы, постоянно спрашивали про синтаксис, джоин двух табличек на бумажке и прочую блевотину. Первые платили зарплаты по три штуки, вторые начинали ныть про свой бюджет в тысячу, ну максимум полторы. Разница, как говорится, на лицо.
П.С. Все более или менее нормальные места, куда я попадал, спрашивали о том, как бы я решал конкретную бизнес задачу заказчика. А все говноконторы, которые были мной посланы, постоянно спрашивали про синтаксис, джоин двух табличек на бумажке и прочую блевотину. Первые платили зарплаты по три штуки, вторые начинали ныть про свой бюджет в тысячу, ну максимум полторы. Разница, как говорится, на лицо.
А представьте себе переключаться постоянно с одного бэкендевого ЯП на другой?
Да, но здесь собеседование на конкретный язык. Если ты подзабыл детали именно этой платформы из-за частого переключения, то это твоя задача — освежить свои знания по этой платформе.
он слету будет послан на три буквы, вместе со своей говноконторой.
На ваше место просто возьмут другого человека, более адекватного в общении с тем же опытом работы. Вы не уникальны.
Первые платили зарплаты по три штуки, вторые начинали ныть про свой бюджет в тысячу, ну максимум полторы. Разница, как говорится, на лицо.
Скорее конторы с малым бюджетом не могут себе позволить взять человека, который не будет отрабатывать свою зарплату, поэтому и проверяют тщательнее — у них риски больше.
Да перестаньте вы. Я не уникален — это факт. Но блин, я считаю что я очень крут. И все же, как личность я уникален. Правда от этих моих слов у многих пригорает. И в доказательство моих слов — это то что я смог заработать благодаря себе на все, что нужно человеку. И поэтому не особо рву себе пятую точку. Это тут многие пытаются друг другу доказать свою крутизну, смешными способами. А я уже все доказал, в первую очередь самому себе.
Я вот пришел в одну контору, как пыхер, а через месяц работы руководство подумало и решило, а ну эту пыху нах, переписываем все на питон. И чо? Что делать в таком случае? Толку от вакансии на конкретный язык?
Что там будет дальше мне уже не интересно. Я еще никогда не сидел без работы.
Каждый толковый специалист по своему уникален. И именно их постоянно и не хватает. А вот всяких «молодых и динамично развивающихся» говноконтор пруд пруди. Я уже про такие писал: cleverman.org/post/problemy-pri-roste-it-kompanii
В таких конторах тимлидом является джун со смешной зарплатой. Зато крутой лычкой на рукаве. И когда приходит собеседоваться в такую контору толковый специалист, то у такого тимлида пукан разрывает на части.
Да, но здесь собеседование на конкретный язык.
Я вот пришел в одну контору, как пыхер, а через месяц работы руководство подумало и решило, а ну эту пыху нах, переписываем все на питон. И чо? Что делать в таком случае? Толку от вакансии на конкретный язык?
На ваше место просто возьмут другого человека, более адекватного в общении с тем же опытом работы. Вы не уникальны.
Что там будет дальше мне уже не интересно. Я еще никогда не сидел без работы.
Вы не уникальны.
Каждый толковый специалист по своему уникален. И именно их постоянно и не хватает. А вот всяких «молодых и динамично развивающихся» говноконтор пруд пруди. Я уже про такие писал: cleverman.org/post/problemy-pri-roste-it-kompanii
Скорее конторы с малым бюджетом не могут себе позволить взять человека, который не будет отрабатывать свою зарплату, поэтому и проверяют тщательнее — у них риски больше.
В таких конторах тимлидом является джун со смешной зарплатой. Зато крутой лычкой на рукаве. И когда приходит собеседоваться в такую контору толковый специалист, то у такого тимлида пукан разрывает на части.
И поэтому не особо рву себе пятую точку. Это тут многие пытаются друг другу доказать свою крутизну, смешными способами. А я уже все доказал, в первую очередь самому себе.
Отлично, значит вы просто разойдетесь с таким потенциальным работодателем и никто не уйдет обиженным.
Я вот пришел в одну контору, как пыхер, а через месяц работы руководство подумало и решило, а ну эту пыху нах, переписываем все на питон. И чо? Что делать в таком случае? Толку от вакансии на конкретный язык?
А я пришел в одну контору и девять лет мы пишем основную часть продукта на одном языке. Есть одни проекты, где каждый год что-то переделывается, есть другие.
Что там будет дальше мне уже не интересно. Я еще никогда не сидел без работы.
Поверьте, и они плакать не будут. Не сошлись во взглядах и до свидания. К чему все ваши посылы про «говноконторы»? Вы намеренно стараетесь принизить их относительно своего, согласно своим же суждениям, уровня? Это выглядит как психологическая защита вида «не очень-то и хотелось».
Каждый толковый специалист по своему уникален.
Здесь слишком широкий простор для манипуляций словом «толковый», поэтому пропускаю.
В таких конторах тимлидом является джун со смешной зарплатой. Зато крутой лычкой на рукаве. И когда приходит собеседоваться в такую контору толковый специалист, то у такого тимлида пукан разрывает на части.
Вполне допускаю. Но равно допскаю, что на деле кандидат — надутый индюк и слишком высокого о себе мнения. Мол, я 30 лет
Разошлись и всё — они при своем, кандидат — при своем. Кандидат пойдет в соседнюю контору, где не будут проверять базовые знания, эта контора — наймет следующего человека, который не будет попусту гнуть пальцы.
В принципе я с вами согласен. Но лично я бы девять лет в одном проекте на одном ЯП в одной и той же конторе, покончил бы с собой. Суть в том, что каждый все равно останется при своем мнении. Но еще и суть в том, что реально толковые ребята любыми усилиями пытаются вырваться из такой ситуации, и пытаются создать и раскрутить свои проекты. И некоторым это удается. И тогда они уже совсем другими глазами взирают на этот чудо рынок в отечественных реалиях. Как бы спорить и не о чем, у каждого свой жизненный и профессиональный опыт, и каждый ищет то, к чему стремится.
Лично для меня показателем профессионализма является тот факт, что у программиста есть свои личные проекты, личные наработки, может свой блог, статьи и аналитика на разные темы, может быть опенсорс решения. А когда многие бьют себя пяткой в грудь о своем профессионализме, но вот к сожалению показать вообще нечего не могут, даже пусть и не очень удачных решений или хоть какой статьи, пусть сухой и не супер интересной, да хоть что-нибудь, вот тогда меня начинает одолевать тоска и уныние. А так, конечно, везде сплошь одни гении, которые всех остальных считают ламерами.
Лично для меня показателем профессионализма является тот факт, что у программиста есть свои личные проекты, личные наработки, может свой блог, статьи и аналитика на разные темы, может быть опенсорс решения. А когда многие бьют себя пяткой в грудь о своем профессионализме, но вот к сожалению показать вообще нечего не могут, даже пусть и не очень удачных решений или хоть какой статьи, пусть сухой и не супер интересной, да хоть что-нибудь, вот тогда меня начинает одолевать тоска и уныние. А так, конечно, везде сплошь одни гении, которые всех остальных считают ламерами.
Но лично я бы девять лет в одном проекте на одном ЯП в одной и той же конторе, покончил бы с собой
Это очень сильно зависит от конкретной конторы. Проект очень большой, у него много частей и работать приходится с разным. вот сейчас пришлось изучать JS/React потому что и фронтэндом занимаемся, и еще ряд других языков, плюс свой собственный скриптовый язык для бизнес-логики, движок которого тоже мы разрабатывали и т.д. Но я говорю про основной язык. А остальное — да, изучается по ходу.
Но еще и суть в том, что реально толковые ребята любыми усилиями пытаются вырваться из такой ситуации, и пытаются создать и раскрутить свои проекты. И некоторым это удается
Здесь опять же слово «толковый» значит всё и ничего одновременно. Есть предприимчивые люди, есть просто специалисты своего дела.
И тогда они уже совсем другими глазами взирают на этот чудо рынок в отечественных реалиях
Ну, у нас рынок американский — в среднем очень консервативный, но не суть.
А когда многие бьют себя пяткой в грудь о своем профессионализме, но вот к сожалению показать вообще нечего не могут
Иногда сложно показывать проприетарный код. Вот сейчас хочу написать небольшую статью сюда об одном трюке и то лишь потому, что это решение было вторым по совокупности параметров и потому в работу не пошло. А первое так и остается закрытым.
А так, конечно, везде сплошь одни гении, которые всех остальных считают ламерами.
причем с обеих сторон — как среди кандидатов, так и среди нанимателей. Спорить на самом деле не о чем, как не о чем в общем-то и жаловаться — ну не подошла ТСу контора по параметрам отбора, так и шут с ним — сколько работы вокруг, за всю жизнь не переделаешь.
UFO just landed and posted this here
В таких конторах тимлидом является джун со смешной зарплатой.
В чем можно быть уверенным — в том, что отбор персонала (в том числе и первичный) проводят будущие коллеги.
А не HR, которые по бумажке по списку требований подбирают и считают, что JS и ES — это разные вещи.
Я вот пришел в одну контору, как пыхер, а через месяц работы руководство подумало и решило, а ну эту пыху нах, переписываем все на питон. И чо? Что делать в таком случае? Толку от вакансии на конкретный язык?
И че? Сразу всех прежних PHPшников уволили и приняли новых Pythonистов?
Вам здоров повезло поучиться за счет работодателя, расширить свой кругозор — да еще и за чужие деньги.
Что там было с экономической целесообразностью для конторы — не ваше дело, если не вы владелец. Хотя, если вы себя считаете достаточно компетентным специалистом — было бы замечательно, если бы вы подошли к руководству и объяснили вопросы рентабельности такого перехода. Собственно Вас только потому и наняли, что специалист в вашей сфере именно вы — зарплату вам платят именно за то что вы используете ваши технические знания во благо конторы.
Неоднократно отговаривал руководство от технически и экономически неэффективных выборов технологий.
В чем можно быть уверенным — в том, что отбор персонала (в том числе и первичный) проводят будущие коллеги.
Тут нужно очень четко определиться, что кому нужно. Если, к примеру, вам, нужно всего лишь попасть в компанию и получить средства к существованию, тогда да. Нужно все зазубрить, заискивающе заглядывать в
Кто что ищет, не больше не меньше.
В таких конторах тимлидом является джун со смешной зарплатой. Зато крутой лычкой на рукаве. И когда приходит собеседоваться в такую контору толковый специалист, то у такого тимлида пукан разрывает на части
По мне так — это все разные конторы.
Не очень представляю — как так вчера был тимлидом джун, а завтра руководство уже осознало, что им нужен спец и поручили джуну собеседовать спеца, чей оклад будет в 3 раза выше.
Если руководство осознало, что их сотрудник слишком слаб — то будут искать нового в обход старого сотрудника.
Тут нужно очень четко определиться, что кому нужно. Если, к примеру, вам, нужно всего лишь попасть в компанию и получить средства к существованию, тогда да. Нужно все зазубрить, заискивающе заглядывать в жоп… в глаза собеседующему, ловить каждое его слово, как благословение божье и т.д. Но если же вы хотите найти то место, где в вас реально будут нуждаться, как специалиста, им очень важен ваш опыт, знания и их собираются использовать на максимум, вам дадут сферу ответственности и широкие полномочия, то вы точно не будете на собеседованиях пресмыкаться и делать вид, что вас спрашивают именно то, что должны.
Если контора нуждается в спеце — то сие означает вполне определенный уровень собеседования.
Если контора нуждается в джуне — то такого может и джун пособеседовать.
Если контора нуждается в спеце, но не может обеспечить нормальное собеседование — это проблема конторы, а не нанимаемого.
Только сдается мне, что вы сгущаете краски:
За последние 20 лет, что я собеседуюсь — ровно один раз встречался на собеседовании «джун-тимлида, у которого пукан порвало». Прикольно, через пару лет он уже ко мне приходил собеседоваться…
Если, к примеру, вам, нужно всего лишь попасть в компанию и получить средства к существованию, тогда да. Нужно все зазубрить, заискивающе заглядывать в жоп… в глаза собеседующему, ловить каждое его слово, как благословение божье и т.д.
Вы уж определитесь — спец вы или джун
Джунов сейчас перебор — да, можно и позаискивать. Конкуренция-с очень велика.
Если вы спец — то на вас самого охотятся хэдхантеры.
Главное проблема в том, что определение вообще ни на 1% не являются знаниями, а являются конвенцией, что люди договорились, что определение будет такое.
Как говорил отец Фейнмана:
"«Видишь эту птицу?» — спрашивал он сына. — Это певчая птица Спенсера. Ну так вот, по-итальянски это Чутто Лапиттида. По-португальски: Бом да Пейда. По-китайски: Чунь-лонь-та, а по-японски: Катано Текеда. Ты можешь знать название этой птицы на всех языках мира, но, когда ты закончишь перечислять эти названия, ты ничего не будешь знать о самой птице. Ты будешь знать лишь о людях, которые живут в разных местах, и о том, как они ее называют. " -вот примерно того же стоят все академические определения.
Как говорил отец Фейнмана:
"«Видишь эту птицу?» — спрашивал он сына. — Это певчая птица Спенсера. Ну так вот, по-итальянски это Чутто Лапиттида. По-португальски: Бом да Пейда. По-китайски: Чунь-лонь-та, а по-японски: Катано Текеда. Ты можешь знать название этой птицы на всех языках мира, но, когда ты закончишь перечислять эти названия, ты ничего не будешь знать о самой птице. Ты будешь знать лишь о людях, которые живут в разных местах, и о том, как они ее называют. " -вот примерно того же стоят все академические определения.
Неистово плюсую! Жаль кармы не хватает чтобы плюсануть в реале :))
Для себя я уже давно решил следующую весчь. Если со мной начинают собеседовать, я говорю стоп чуваки. Дайте мне небольшую задачку, на день-три, желательно связанную с предстоящей работой. Поглядите как я её решу, увидите стиль моего мышления, стиль написания кода, тогда и поговорим. Если мне говорят что мол у нас такие принципы, я отвечаю что у меня свои принципы, и очевидно мы друг другу не подходим. Но очень часто соглашаются.
По рассказанной Вами истории считаю что Вам повезло. Попали бы в проект, говна с такими манагерами хлебали бы половниками. Лучше от такого счастья держаться подальше.
Для себя я уже давно решил следующую весчь. Если со мной начинают собеседовать, я говорю стоп чуваки. Дайте мне небольшую задачку, на день-три, желательно связанную с предстоящей работой. Поглядите как я её решу, увидите стиль моего мышления, стиль написания кода, тогда и поговорим. Если мне говорят что мол у нас такие принципы, я отвечаю что у меня свои принципы, и очевидно мы друг другу не подходим. Но очень часто соглашаются.
По рассказанной Вами истории считаю что Вам повезло. Попали бы в проект, говна с такими манагерами хлебали бы половниками. Лучше от такого счастья держаться подальше.
Автор, порадуйся что ты так быстро понял, что тебе нечего делать именно в этой конторе. Тебя ждут нормальные проекты и нормальные коллеги, которые понимают что именно важно в разработке.
Ого, понакидали комментов… у меня не хватило терпения и запоминалки собственных мыслей, чтобы не прокомментировать до того, как прочёл всё, высказанное до меня, поэтому простите, если кого-то повторяю.
Тут сошлась и животрепещущая тема, и достойный автор, которого можно поднять на щиты (не как в финале «Спартака»).
Но подозревать разрабов в самозванстве — никак не «хватит», ведь именно для этого, в том числе, и проводятся собеседования — чтобы подозревать в тебе самозванца и дилетанта. Это для кого-то унизительно, это чревато ошибками, а у нас у разрабов отношение к ошибкам профессионально нетерпимое, но тут тот случай, когда придётся забить на баги и пройти мимо. Иначе, по административной логике, мне кажется, если к нам с вами прислушаются, станет ХУЖЕ. Перепоручат всё эйчарам, как в сеттинге вот этого рассказика: habr.com/post/417431
Таки да, вполне возможно, крутая контора прошляпила крутого спеца.
Ну, бывает.
Или верно что-то из домыслов предыдущих комментаторов относительно компании, вакансии (её реального значения) или ЛПР. Или не верно ничего. А просто автор статьи действительно им не подходит. Некоторая вероятность, что он overqualified, и ещё меньшая — но, простите уж, не нулевая — что он underqualified.
Кстати, Ваша реакция вопросы на «память и зубрёжку» на собесе — неплохой такой звоночек.
На самом деле, вопрос, «лучше всё помнить или лучше понимать любой вопрос? Можно ли хорошо разбираться в вопросе, если не зубрить?» — в науке, не говоря уже о программировании, ещё не решён однозначно. В экономической науке есть подход Густава Шмоллера и… этого… ученика, забыл фамилию — который «перешмоллерил самого Шмоллера», например…
Если человек открыто бесится, что ему задали вопрос на начётническую память — не обязательно человек не умный, не понимающий, но… человек трудный.
Тут сошлась и животрепещущая тема, и достойный автор, которого можно поднять на щиты (не как в финале «Спартака»).
Но подозревать разрабов в самозванстве — никак не «хватит», ведь именно для этого, в том числе, и проводятся собеседования — чтобы подозревать в тебе самозванца и дилетанта. Это для кого-то унизительно, это чревато ошибками, а у нас у разрабов отношение к ошибкам профессионально нетерпимое, но тут тот случай, когда придётся забить на баги и пройти мимо. Иначе, по административной логике, мне кажется, если к нам с вами прислушаются, станет ХУЖЕ. Перепоручат всё эйчарам, как в сеттинге вот этого рассказика: habr.com/post/417431
Таки да, вполне возможно, крутая контора прошляпила крутого спеца.
Ну, бывает.
Или верно что-то из домыслов предыдущих комментаторов относительно компании, вакансии (её реального значения) или ЛПР. Или не верно ничего. А просто автор статьи действительно им не подходит. Некоторая вероятность, что он overqualified, и ещё меньшая — но, простите уж, не нулевая — что он underqualified.
Кстати, Ваша реакция вопросы на «память и зубрёжку» на собесе — неплохой такой звоночек.
На самом деле, вопрос, «лучше всё помнить или лучше понимать любой вопрос? Можно ли хорошо разбираться в вопросе, если не зубрить?» — в науке, не говоря уже о программировании, ещё не решён однозначно. В экономической науке есть подход Густава Шмоллера и… этого… ученика, забыл фамилию — который «перешмоллерил самого Шмоллера», например…
Если человек открыто бесится, что ему задали вопрос на начётническую память — не обязательно человек не умный, не понимающий, но… человек трудный.
Просто попали на собеседование не к техническому лиду проекта, а к ПМ-у, который в молодости говнокодил, и решил что он лучше знает как проводить техническое собеседование.
ИТ тут не причем. Девы тут не причем.
Представьте, что на собеседование шофера начнут по ПДД гонять? будет тоже самое, люди с 30-летним опытом и водителя и механика завалятся на мелочах.
Тоже самое.
ИТ тут не причем. Девы тут не причем.
Представьте, что на собеседование шофера начнут по ПДД гонять? будет тоже самое, люди с 30-летним опытом и водителя и механика завалятся на мелочах.
Тоже самое.
начнут по ПДД гонять
— На какой сигнал светофора вы обычно проезжаете перекрёсток?
— Оппа… язобыл.
UFO just landed and posted this here
Без гугления, ответьте на парочку вопросов:
1) Вне перекрестка, трамвайный путь пересекает полосу движения. Трамвай выезжает из депло. Должны ли вы уступить дорогу?
2) Транспортные средства, на которых производится обучение езде, должны иметь опознвательные знаки («У»), за исключением каких транспортных средств?
3) На каких дорогах запрещена буксировка во время гололедицы?
4) Кстати, какая максимальная скорость разрешена при буксировке?
Если вы думаете, что в ПДД сложно найти вопросы, которыми легко завалить опытного водителя, то просто полистайте ПДД.
1) Вне перекрестка, трамвайный путь пересекает полосу движения. Трамвай выезжает из депло. Должны ли вы уступить дорогу?
2) Транспортные средства, на которых производится обучение езде, должны иметь опознвательные знаки («У»), за исключением каких транспортных средств?
3) На каких дорогах запрещена буксировка во время гололедицы?
4) Кстати, какая максимальная скорость разрешена при буксировке?
Если вы думаете, что в ПДД сложно найти вопросы, которыми легко завалить опытного водителя, то просто полистайте ПДД.
Могу попытаться, но не факт, что справлюсь (более 20 лет за рулем):
1) Рельсовый транспорт имеет преимущество перед не рельсовым. Нужно уступить.
2) Никаких исключений.
3) Какая именно буксировка? На гибкой сцепке или на жесткой? По моему на любой дороге запрещена во время гололеда.
4) Хороший вопрос )) Они постоянно в ПДД меняют всякие скоростные ограничения, хрен поймешь. И опять у меня уточнение про гибкую и жесткую сцепку. На первую ставлю до 40 км/ч, на вторую до 60 км/ч
Когда в 96 году в первый раз сдавал на права, то вождение прошел, а на правилах засыпался. Через две недели была пересдача правил. При чем ПДД знал неплохо. Но когда увидел вопросы в билетах, я просто прозрел. Картинки полное говно, все нечетко и противоречиво. Даже отлично зная ПДД хрен сдашь. На пересдачу я поступил по другому. Я тупо выучил все билеты наизусть. Сдал за минуту, сразу 10 из десяти.
Но как по мне — это огромная тупость. Заучивание идиотских ситуаций ничего не дает в реальности. Плюс коррупцию неплохо подпитывает.
Но это еще все фигня. Я когда сдавал экзамен в министерстве «Охоты и рыбалки» на получение охотничьего билета, то мне попался вопрос: сколько яиц приносит дрозд? Вот это я тогда на жопу и сел. Как это поможет при охоте и рыбалке я ХЗ. В итоге дал денег, абсолютно все так проходят: нужно купить их тупую книжку и дать денег.
1) Рельсовый транспорт имеет преимущество перед не рельсовым. Нужно уступить.
2) Никаких исключений.
3) Какая именно буксировка? На гибкой сцепке или на жесткой? По моему на любой дороге запрещена во время гололеда.
4) Хороший вопрос )) Они постоянно в ПДД меняют всякие скоростные ограничения, хрен поймешь. И опять у меня уточнение про гибкую и жесткую сцепку. На первую ставлю до 40 км/ч, на вторую до 60 км/ч
Когда в 96 году в первый раз сдавал на права, то вождение прошел, а на правилах засыпался. Через две недели была пересдача правил. При чем ПДД знал неплохо. Но когда увидел вопросы в билетах, я просто прозрел. Картинки полное говно, все нечетко и противоречиво. Даже отлично зная ПДД хрен сдашь. На пересдачу я поступил по другому. Я тупо выучил все билеты наизусть. Сдал за минуту, сразу 10 из десяти.
Но как по мне — это огромная тупость. Заучивание идиотских ситуаций ничего не дает в реальности. Плюс коррупцию неплохо подпитывает.
Но это еще все фигня. Я когда сдавал экзамен в министерстве «Охоты и рыбалки» на получение охотничьего билета, то мне попался вопрос: сколько яиц приносит дрозд? Вот это я тогда на жопу и сел. Как это поможет при охоте и рыбалке я ХЗ. В итоге дал денег, абсолютно все так проходят: нужно купить их тупую книжку и дать денег.
1) Неверно. при выезде из Депо, трамвай преимущества не имеет. Н
2) Неверно. Исключения — мотоциклы
3) Верно.
4) Неверно. Просто 50 км/час.
Суть в том и заключается, что на ИТ собеседованиях у программистов сейчас часто спрашивают именно подобные штуки, которые не нужно заучивать наизусть, ибо такие вещи всегда можно нагуглить за секунду. Гораздо важнее, чтобы человек умел программировать и адекватно относиться к работе. Но вся статья о том, что встречаются идиотские интервью.
2) Неверно. Исключения — мотоциклы
3) Верно.
4) Неверно. Просто 50 км/час.
Суть в том и заключается, что на ИТ собеседованиях у программистов сейчас часто спрашивают именно подобные штуки, которые не нужно заучивать наизусть, ибо такие вещи всегда можно нагуглить за секунду. Гораздо важнее, чтобы человек умел программировать и адекватно относиться к работе. Но вся статья о том, что встречаются идиотские интервью.
Суть в том и заключается, что на ИТ собеседованиях у программистов сейчас часто спрашивают именно подобные штуки, которые не нужно заучивать наизусть, ибо такие вещи всегда можно нагуглить за секунду. Гораздо важнее, чтобы человек умел программировать и адекватно относиться к работе.
Полностью поддерживаю.
Простите, но virtual это именно «проезд на какой сигнал светофора допускается», а не подобные нюансы. Такие нюансы это скорее вопросы из разряда «расскажите про различие между серверным и workstation режимами работы ГЦ», «как устроен hot swap и трамплины на нативные методы в JIT» и прочая дребедень.
Кстати, очень точно подмечено. У меня на позапрошлом проекте был ПМ, который был до этого джун разработчиком. Вначале руководство хотело его уволить, а потом пожалели, мол уже столько лет у нас, давайте сделаем его ПМом. В итоге он еб… ал мозги абсолютно всем разработчиком, рассказывая им какую где функцию нужно применить, где какой алгоритм использовать. Доходило уже до того, что его уже прибить хотели. А руководство при этом все устраивало. А когда стали спецы массово увольняться уже тогда что-то в голове у руководства зашевелилось и они уволили ПМа. Но им уже это не помогло )) Все равно все разбежались.
Проблема с самозванцами есть, не знаю как на российском рынке, а вот в США есть конторы, которые предлагают «обучение», например java, за полгода и за $5000. Туда идут учиться все подряд — «хочу получать зарплату как у программиста». Не знаю про качество обучения, но они кроме знаний дают будущему программисту красивое резюме со списком выполненых проектов и «настоящие» референсы по этим проектам + ещё учат проходить собесы и как правильно отвечать на вопросы по проектам из резюме. Есть пара дальних знакомых, которые таким путём получили работу разработчиков.
А сам я недавно искал работу и удивлялся почему на каждом интервью в начале спрашивают чем отличается интерфейс от класса, рекрутер мне потом и поведал, что практически на любую вакансию разработчика есть десяток претендентов с красивыми резюме, и такими вопросами можно их отсеять и съэкономить время.
А сам я недавно искал работу и удивлялся почему на каждом интервью в начале спрашивают чем отличается интерфейс от класса, рекрутер мне потом и поведал, что практически на любую вакансию разработчика есть десяток претендентов с красивыми резюме, и такими вопросами можно их отсеять и съэкономить время.
Удивляет не бомбящий не по делу автор (не знал/забыл про virtual? а голову ты дома не забыл?! садись — двойка, синьор ты мамкин...), а половина комментариев из серии «братан, и я не знаю, чё эта».
ты забыл добавить:"… и отлично справляюсь с работой".
+не «не знаю», а «не помню».
+не «не знаю», а «не помню».
Тут недавно был перевод и у автора бомбило с убогости софта и окружающей действительности. Может все это от сениоров которые не знают virtual и отлично справляются с работой?
Тут недавно был перевод и у автора бомбило с убогости софта и окружающей действительности. Может все это от сениоров которые не знают virtual и отлично справляются с работой?
Это от требований бизнеса сделать все еще вчера и дешево, а требования бизнеса — от реалий в экономике и конкуренции.
Если тебе нужно срочно заткнуть дыру — то не до красивых абстракций.
Скорее уж, это от контор, которые таких старшИх не берут принципиально. (не факт, что в статье тот случай).
В статье по Вашей ссылке — больше про целеполагание, я так понимаю, причём, стратегическое, а не про virtual.
Впрочем, ТС, Якiй ти в чорта лыцарь, коли голою… далее по тексту.)
В статье по Вашей ссылке — больше про целеполагание, я так понимаю, причём, стратегическое, а не про virtual.
Впрочем, ТС, Якiй ти в чорта лыцарь, коли голою… далее по тексту.)
Вообще, ответы автора статьи в ведомом им на протяжении статьи (в основном) неслучившимся диалоге с работодателем — слегка в стиле еврейской классики: «то есть Вы хотите знать, почему я не могу ответить на Ваш вопрос. Я расскажу, и Вы убедитесь сами...»
Наверное, многие самонадеянные крутые спецы в сложных областях любят такое.
И — нет, не буду пенять им ограниченным временем собеседования или впечатлением интеллектуального снобизма и вербальной агрессии.
Я просто предлагаю коллегам подумать в общем, какие вопросы они бы задали, чтобы в ответ не началась притча, агада либо вообще кадиш и помимо общего приятного впечатления о человеке и его пытливости можно было бы определить, сработаетесь ли, в рамках жёстко заданных подходов. Притча ещё тем плоха, что не у всех у нас прокачаны литературные и ораторские способности. А если ещё поверх смущения (для того, чтобы видеть смущение, и понадобился видеочат) — то те способности, что есть, делите на 10 и сравнивайте с «левелом босса».
Наверное, многие самонадеянные крутые спецы в сложных областях любят такое.
И — нет, не буду пенять им ограниченным временем собеседования или впечатлением интеллектуального снобизма и вербальной агрессии.
Я просто предлагаю коллегам подумать в общем, какие вопросы они бы задали, чтобы в ответ не началась притча, агада либо вообще кадиш и помимо общего приятного впечатления о человеке и его пытливости можно было бы определить, сработаетесь ли, в рамках жёстко заданных подходов. Притча ещё тем плоха, что не у всех у нас прокачаны литературные и ораторские способности. А если ещё поверх смущения (для того, чтобы видеть смущение, и понадобился видеочат) — то те способности, что есть, делите на 10 и сравнивайте с «левелом босса».
Для меня как программиста C++ virtual настолько базовое понятие, что за его не знание не грех отсеять кандидата на позицию обычного программиста, что уж говорить про senior. Неужели в C# virtual не так распространен и важен?
Хрен его знамо… С# я вообще никогда подробно не изучал. На плюсах стараюсь (если придется) писать как можно проще. Чел говорит совсем не о том. Говорит он о том, что действительно сильного разраба отличает не знание какого-то конкретинизма, а понимание базовых принципов. Позволяющее очень быстро получать результаты даже в совсем незнакомой области. И тут я с ним согласен на все 146%
Очень распространен и важен.
Человек который не может ответить на этот вопрос скорее всего не в курсе про полиморфизм и не сможет правильно его применять. Это уровень джуна, увы.
Человек который не может ответить на этот вопрос скорее всего не в курсе про полиморфизм и не сможет правильно его применять. Это уровень джуна, увы.
То же удивило что человек собеседующийся на сеньора не смог ответить про virtual и еще строчит статьи на хабре что его не взяли на работу. За такое не то что миддлов и джунов отсеивать спокойно можно.
Я уже два года ищу работу натыкаясь на такие конторы. Просвета пока не вижу. А вот что таких тем по всюду раз два и обчелся это странно. Только до 10 года можно что то найти.
Автор, не парься :)
Прохождение собеседований — это отдельный навык, и он не сильно коррелирует с твоими реальными знаниями как работать. Его также надо время от времени тренировать, проходя собеседования.
Прохождение собеседований — это отдельный навык, и он не сильно коррелирует с твоими реальными знаниями как работать. Его также надо время от времени тренировать, проходя собеседования.
как можно не знать что есть virtual?
что за «сеньйоры» пошли…
что за «сеньйоры» пошли…
Тоже недавно решил походить по собесам, так, чисто проверить себя. Все тоже самое как у автора, только в живую
UFO just landed and posted this here
UFO just landed and posted this here
Демарилизует очень…
И как там дела у маралов?
UFO just landed and posted this here
Что ты хотел
UFO just landed and posted this here
Как изысканно вежливо! То-то я думаю — почему у Вас карма отрицательная?
UFO just landed and posted this here
Чудны дела твои, господи — в наше время признаком мужественности считалась безукоризненная вежливость в любой ситуации, а теперь — маты-перематы...
«Выстраданный» мной Совет тебе:
_Просто_ забей на м***ков и ищи тех, кому «очень-очень надо фичи, а не вот эти ваши программистские заумства» (бизнес, ну и ЛПР в бизнесе особенно надо искать). Приходи к ним даже не с кодом, а с понятными демками по _ихней_ тематике (специально «ихней» написал, чтобы «раздаржитель» хорошо запомнился :))
В итоге и доход твой вырастет в разы (x2 — самое малое) и уважуха тебе будет и общение на собраниях с руководством по бизнесу и «по теме» напрямую (а деньги они оттуда — из бизнеса, а не от virtual и «заумных очкариков») и слушать тебя (как проявишь себя конечно) будут ну _очень_ внимательно.
Моя история (кому-то надеюсь добавит оптимизма):
Как-то так вышло, что в самый неподходящий момент (мы с женой в отпуске в Таиланде, денег потрачено уйма, а осталось соответственно мало) проект «внезапно» закрылся (я вообще по email узнал) по независящим от меня бизнес-причинам (хотя я долго ходил и капал на мозги руководству, что «так не прокатит с т.з. бизнеса и даже тупо математически вот тут и вот тут экономика не сойдётся», типа что надо по другому — не послушали, ну и в результате «утёрлись» все, а не только я).
И пошёл я по привычке пособеседоваться в пару местных контор.
Ёмаё, я и не знал, что в мире столько задр***ов-очкариков, которым важно «пройти по строке, перевернуть там слова каждое отдельно внутри строки, но при этом использовать только 2 (два) указателя для жёсткой экономии RAM» (я в микроконтроллерах stm8 так не экономил даже!) — и всё это за 10 минут на бумажке написать. (если что это не стандартное «строку перевернуть», просто пустив указатель бежать обратно)
Я правда потом сталкивался с этими неадекватами на одном форуме, где они предлагали «хакатон под наше железо, но вы код пишите без него, а самым успешным мы даже дадим разок прошить попробовать». Компанию называть не буду, тем более она известная и хэдофис думаю у них адекватный — это «местячковые» боссы «дуркуют» тут :)
Ещё в одной конторе мне в качестве «тестового задания» пытались втюхать нехилый такой НИОКР на неделю не меньше (связано с ультразвуком и его распространением. в принципе при словах «Сколково» мне надо было сразу послать их лесом, а не вести диалог — сам виноват :)))
В итоге я пошёл увольняться «в никуда», причём родные кадровички расставались со мной как-то легко и это добавляло мне грусти и печали.
В результате я пошёл «к главному на окончательную подпись» и тут… он встретил меня (хотя я его мало знал — видел в коридорах пару раз) чуть ли не как родного: «Саш, привет! Что-то это у тебя? (взял листок, аккуратно сложил вчетверо). А ты это… серьёзно? причины?»
Ну тут я сказал, что типа проект закрылся, мне наш главный сказал, что финансирования нет и всем надо искать работу.
На что он округлил глаза, позвонил кадровичкам и убедительно попросил «ошибок впредь не допускать, пожалуйста, ну хотя бы человека спрашивать причины!», ну и рассказал, что оказывается намечается крупный проект и народ наоборот днём с огнём ищут, а мои скилы крайне там бы пригодились, особенно C++, QNX и т.д. В общем я «как в сказку попал», причём потом выяснилось, что да, не обманули — было и интересно и з/п норм и мир повидал ещё разок нахаляву (командировки-с).
Жизненный урок: НЕ слушать **упое «местячковое» начальство и тем более не вести с м***ками диалоги — выходить на «боссов» (ЛПР), чем раньше тем лучше! (хорошо что у меня хоть и случайно но так и вышло)
Ну а далее друзья сделали так же (но не в этой стране) и меня позвали с ними работать.
Сейчас работаю напрямую с заказчиками (прямее некуда), в офис переться не надо, глупости ничьи слушать не надо, если с чем-то не согласен или есть идеи — велкам, всё обсуждаемо (главное чётко разъяснить и обосновать).
Выводы: выходить на ЛПР, выходить на «бизнес», выходить на _заинтересованных_ лиц, не «умничать», а предлагать и объяснять это без надменности АйТишной доступным языком бенефиты от того или иного решения.
P.S. Очень надеюсь, что мои наблюдения и выводы помогут людям, попавшим в ситуацию как у меня (см. «многабукаф» выше) и как у автора статьи.
Хоть мне и скоро 40, но пишу тут простым «пацанским» языком — нафиг вот весь этот пафос, надо называть вещи своими именами.
«Улыбайтесь! Ведь все самые большие глупости в мире совершаются именно с серьёзным выражением лица!» (с) х/ф «Тот самый Мюнхаузен»
_Просто_ забей на м***ков и ищи тех, кому «очень-очень надо фичи, а не вот эти ваши программистские заумства» (бизнес, ну и ЛПР в бизнесе особенно надо искать). Приходи к ним даже не с кодом, а с понятными демками по _ихней_ тематике (специально «ихней» написал, чтобы «раздаржитель» хорошо запомнился :))
В итоге и доход твой вырастет в разы (x2 — самое малое) и уважуха тебе будет и общение на собраниях с руководством по бизнесу и «по теме» напрямую (а деньги они оттуда — из бизнеса, а не от virtual и «заумных очкариков») и слушать тебя (как проявишь себя конечно) будут ну _очень_ внимательно.
Моя история (кому-то надеюсь добавит оптимизма):
Как-то так вышло, что в самый неподходящий момент (мы с женой в отпуске в Таиланде, денег потрачено уйма, а осталось соответственно мало) проект «внезапно» закрылся (я вообще по email узнал) по независящим от меня бизнес-причинам (хотя я долго ходил и капал на мозги руководству, что «так не прокатит с т.з. бизнеса и даже тупо математически вот тут и вот тут экономика не сойдётся», типа что надо по другому — не послушали, ну и в результате «утёрлись» все, а не только я).
И пошёл я по привычке пособеседоваться в пару местных контор.
Ёмаё, я и не знал, что в мире столько задр***ов-очкариков, которым важно «пройти по строке, перевернуть там слова каждое отдельно внутри строки, но при этом использовать только 2 (два) указателя для жёсткой экономии RAM» (я в микроконтроллерах stm8 так не экономил даже!) — и всё это за 10 минут на бумажке написать. (если что это не стандартное «строку перевернуть», просто пустив указатель бежать обратно)
Я правда потом сталкивался с этими неадекватами на одном форуме, где они предлагали «хакатон под наше железо, но вы код пишите без него, а самым успешным мы даже дадим разок прошить попробовать». Компанию называть не буду, тем более она известная и хэдофис думаю у них адекватный — это «местячковые» боссы «дуркуют» тут :)
Ещё в одной конторе мне в качестве «тестового задания» пытались втюхать нехилый такой НИОКР на неделю не меньше (связано с ультразвуком и его распространением. в принципе при словах «Сколково» мне надо было сразу послать их лесом, а не вести диалог — сам виноват :)))
В итоге я пошёл увольняться «в никуда», причём родные кадровички расставались со мной как-то легко и это добавляло мне грусти и печали.
В результате я пошёл «к главному на окончательную подпись» и тут… он встретил меня (хотя я его мало знал — видел в коридорах пару раз) чуть ли не как родного: «Саш, привет! Что-то это у тебя? (взял листок, аккуратно сложил вчетверо). А ты это… серьёзно? причины?»
Ну тут я сказал, что типа проект закрылся, мне наш главный сказал, что финансирования нет и всем надо искать работу.
На что он округлил глаза, позвонил кадровичкам и убедительно попросил «ошибок впредь не допускать, пожалуйста, ну хотя бы человека спрашивать причины!», ну и рассказал, что оказывается намечается крупный проект и народ наоборот днём с огнём ищут, а мои скилы крайне там бы пригодились, особенно C++, QNX и т.д. В общем я «как в сказку попал», причём потом выяснилось, что да, не обманули — было и интересно и з/п норм и мир повидал ещё разок нахаляву (командировки-с).
Жизненный урок: НЕ слушать **упое «местячковое» начальство и тем более не вести с м***ками диалоги — выходить на «боссов» (ЛПР), чем раньше тем лучше! (хорошо что у меня хоть и случайно но так и вышло)
Ну а далее друзья сделали так же (но не в этой стране) и меня позвали с ними работать.
Сейчас работаю напрямую с заказчиками (прямее некуда), в офис переться не надо, глупости ничьи слушать не надо, если с чем-то не согласен или есть идеи — велкам, всё обсуждаемо (главное чётко разъяснить и обосновать).
Выводы: выходить на ЛПР, выходить на «бизнес», выходить на _заинтересованных_ лиц, не «умничать», а предлагать и объяснять это без надменности АйТишной доступным языком бенефиты от того или иного решения.
P.S. Очень надеюсь, что мои наблюдения и выводы помогут людям, попавшим в ситуацию как у меня (см. «многабукаф» выше) и как у автора статьи.
Хоть мне и скоро 40, но пишу тут простым «пацанским» языком — нафиг вот весь этот пафос, надо называть вещи своими именами.
«Улыбайтесь! Ведь все самые большие глупости в мире совершаются именно с серьёзным выражением лица!» (с) х/ф «Тот самый Мюнхаузен»
Не так это просто, найти хорошего разработчика. Потому что
есть знания теоретические, и есть практическая производительность. Один разработчик сделает за месяц условно 100 юнитов, а другой 20. Один въезжает в проект за неделю, а другому надо месяц потратить. И т.д.
Собеседования в основном выявляют что-то там по теории, поэтому выхлоп от них не очень. Написать тестовое задание и потом объяснить решение — это уже получше, но тоже не дает всей полноты картины. Для сокращения времени набора идеально было бы брать на одну позицию три или более кандидата на испытательный срок и потом оставлять на постоянную лучшего. Несколько жестко к отсеиваемым, но у нас же капитализм…
есть знания теоретические, и есть практическая производительность. Один разработчик сделает за месяц условно 100 юнитов, а другой 20. Один въезжает в проект за неделю, а другому надо месяц потратить. И т.д.
Собеседования в основном выявляют что-то там по теории, поэтому выхлоп от них не очень. Написать тестовое задание и потом объяснить решение — это уже получше, но тоже не дает всей полноты картины. Для сокращения времени набора идеально было бы брать на одну позицию три или более кандидата на испытательный срок и потом оставлять на постоянную лучшего. Несколько жестко к отсеиваемым, но у нас же капитализм…
> Один разработчик сделает за месяц условно 100 юнитов, а другой 20. Один въезжает в проект за неделю, а другому надо месяц потратить. И т.д.
юниты? это деньги такие? :)
для бизнеса пофиг сколько там юнитов кто делает. для бизнеса важен _результат_: деньги — в кассе.
а пиши хоть на C++, хоть на BASIC, хоть вообще на китайском иероглифами.
кто-то в задачу въезжает за неделю, делает всё добросовестно, но делает «не то». а кто-то думает месяц, приходит к боссу и говорит: так не надо. надо вот так. вот презентация и демка, вот — отзывы, вот — промахи конкурентов, сравните — всё сами поймёте.
важно не _правильно_ делать дела, а делать _правильные_ дела.
юниты? это деньги такие? :)
для бизнеса пофиг сколько там юнитов кто делает. для бизнеса важен _результат_: деньги — в кассе.
а пиши хоть на C++, хоть на BASIC, хоть вообще на китайском иероглифами.
кто-то в задачу въезжает за неделю, делает всё добросовестно, но делает «не то». а кто-то думает месяц, приходит к боссу и говорит: так не надо. надо вот так. вот презентация и демка, вот — отзывы, вот — промахи конкурентов, сравните — всё сами поймёте.
важно не _правильно_ делать дела, а делать _правильные_ дела.
Я тут подумал, что не смог бы пройти собеседование в компанию, в которой работаю, на должность, на которой работаю. Это в том случае, если у нас собеседуют «как везде», т.е. без гугла, чисто вопросами на проверку памяти. Работаю нормально, справляюсь с обязанностями без упрёков. Гугл — великая вещь, внешняя память.
> не смог бы пройти собеседование в компанию, в которой работаю, на должность, на которой работаю.
сейчас всем интересующимся так и говорю: «каюсь. 10 лет притворялся что знаю C++ (а также Java, а точнее Android, а также другие языки и технологии), вот список проектов где я притворялся — можете позвонить им, спросить про меня. мне им звонить стыдно — могут обратно позвать, а 2-й раз врать как-то уж совсем некрасиво :)»
сейчас всем интересующимся так и говорю: «каюсь. 10 лет притворялся что знаю C++ (а также Java, а точнее Android, а также другие языки и технологии), вот список проектов где я притворялся — можете позвонить им, спросить про меня. мне им звонить стыдно — могут обратно позвать, а 2-й раз врать как-то уж совсем некрасиво :)»
Мне тоже время от времени приходится собеседовать разработчиков к нам в команду. Возможно, повторю какие-то мысли из комментаторов выше (прочитал не всех, но многих)…
Первое — собеседование это не только про технические навыки, но и про то, как вы вольетесь в команду. Причем не факт, что вливание в команду менее важно. Кандидат должен просто богоподобным разработчиком, чтобы можно было закрывать глаза на его отвратительные софт-скиллс. Мне такие, к сожалению, пока не попадались, поэтому глаза закрывать повода нет. По вашим фразам, цитирую, «Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего.», у меня складывается ощущение, что общаться с Вами собеседующему при дальнейшей работе, возможно, было бы непросто. Возможно, он это почувствовал в какие-то моменты, а потому задавал вопросы с большим усердством, чтобы точно убедиться адекватный ли вы в общении человек. Быть может, ему показалось, что не очень.
Второй момент — по технической части. Лично я не очень представляю, как можно забыть, что такое virtual (не по определению, а не суметь даже своими словами рассказать для чего и почему используется). Топить бы я за это не стал, но звоночек был бы. Да и представьте себя на месте собеседующего. Ему каким-то образом надо понять технический уровень кандидата. Вариантов для этого не так много:
— либо смотреть тестовое задание (их мало кто любит вообще делать, особенно из хороших разработчиков),
— либо смотреть ответы на небольшие предсобеседовательные вопросы (мы у себя сейчас практикуем такой подход),
— либо расспрашивать подробности о предыдущем проекте (он не всегда может быть релевантным, да и как правило подробностей особых не выудишь, а если и выудишь — то без взгляда на код не всегда интервьюер можно легко погрузиться в описание проекта и задать правильные вопросы),
— либо банально задавать вопросы по чек-листу (то с чем Вы и столкнулись)
— либо давать маленькую практическую задачку (тоже часто не связанную с реальностью, т.к. задача побольше, из реальной практики, с учетом стресса, который испытывает собеседуемый во время интервью, почти наверняка не сможет быть хорошим фильтром)
Чаще всего все эти варианты в той или иной степени комбинируются. Это позволяет отсеивать люто неподходящих кандидатов (таких подавляющее большинство). При этом конечно же в фильтр иногда могут не проходить и действительно хорошие профессионалы, но, как уже упоминалось многократно предыдущими комментаторами, — гораздо важнее не взять на работу очень плохого кандидата, чем пропустить одного хорошого. Главное держать баланс.
Третье — я, например, при беседе, если чувствую, что кандидат совсем не подходит на заявляемую должность, пытаюсь прощупать те темы, в которых он более-менее хорош, чтобы, возможно, предложить ему позицию пониже. Быть может, по каким-то предыдущим вопросам, Ваш интервьюер тоже это понял, и просто прощупывал подойдете ли Вы на другую позицию?
КМК, большинство собеседующих (исходя из моей практики прохождения собеседований и со стороны претендента) — это все-таки совершенно адекватные люди, без желания кого-то завалить, а уж тем более «расплываться от гордости», «светиться» и т.д. Просто есть вполне конкретные цели от собеседования, конкретные требования к кандидатам, и Вы в данный момент их не удовлетворили.
Также как и они Вас. Это же хорошо, что все хорошо закончилось, и Вам не пришлось работать на нелюбимой работе.
Первое — собеседование это не только про технические навыки, но и про то, как вы вольетесь в команду. Причем не факт, что вливание в команду менее важно. Кандидат должен просто богоподобным разработчиком, чтобы можно было закрывать глаза на его отвратительные софт-скиллс. Мне такие, к сожалению, пока не попадались, поэтому глаза закрывать повода нет. По вашим фразам, цитирую, «Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего.», у меня складывается ощущение, что общаться с Вами собеседующему при дальнейшей работе, возможно, было бы непросто. Возможно, он это почувствовал в какие-то моменты, а потому задавал вопросы с большим усердством, чтобы точно убедиться адекватный ли вы в общении человек. Быть может, ему показалось, что не очень.
Второй момент — по технической части. Лично я не очень представляю, как можно забыть, что такое virtual (не по определению, а не суметь даже своими словами рассказать для чего и почему используется). Топить бы я за это не стал, но звоночек был бы. Да и представьте себя на месте собеседующего. Ему каким-то образом надо понять технический уровень кандидата. Вариантов для этого не так много:
— либо смотреть тестовое задание (их мало кто любит вообще делать, особенно из хороших разработчиков),
— либо смотреть ответы на небольшие предсобеседовательные вопросы (мы у себя сейчас практикуем такой подход),
— либо расспрашивать подробности о предыдущем проекте (он не всегда может быть релевантным, да и как правило подробностей особых не выудишь, а если и выудишь — то без взгляда на код не всегда интервьюер можно легко погрузиться в описание проекта и задать правильные вопросы),
— либо банально задавать вопросы по чек-листу (то с чем Вы и столкнулись)
— либо давать маленькую практическую задачку (тоже часто не связанную с реальностью, т.к. задача побольше, из реальной практики, с учетом стресса, который испытывает собеседуемый во время интервью, почти наверняка не сможет быть хорошим фильтром)
Чаще всего все эти варианты в той или иной степени комбинируются. Это позволяет отсеивать люто неподходящих кандидатов (таких подавляющее большинство). При этом конечно же в фильтр иногда могут не проходить и действительно хорошие профессионалы, но, как уже упоминалось многократно предыдущими комментаторами, — гораздо важнее не взять на работу очень плохого кандидата, чем пропустить одного хорошого. Главное держать баланс.
Третье — я, например, при беседе, если чувствую, что кандидат совсем не подходит на заявляемую должность, пытаюсь прощупать те темы, в которых он более-менее хорош, чтобы, возможно, предложить ему позицию пониже. Быть может, по каким-то предыдущим вопросам, Ваш интервьюер тоже это понял, и просто прощупывал подойдете ли Вы на другую позицию?
КМК, большинство собеседующих (исходя из моей практики прохождения собеседований и со стороны претендента) — это все-таки совершенно адекватные люди, без желания кого-то завалить, а уж тем более «расплываться от гордости», «светиться» и т.д. Просто есть вполне конкретные цели от собеседования, конкретные требования к кандидатам, и Вы в данный момент их не удовлетворили.
Также как и они Вас. Это же хорошо, что все хорошо закончилось, и Вам не пришлось работать на нелюбимой работе.
По вашим фразам, цитирую, «Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего.», у меня складывается ощущение, что общаться с Вами собеседующему при дальнейшей работе, возможно, было бы непросто
Полагаю все дело в этом:
Я только что с собеса, и у меня бомбит.
Просто написано не на холодную голову.
В чём автор прав — вопросы должны быть другие.
Поскольку у нас с вами больше половины времени уходит на отладку, а не на перебор инструментов и имплементацию — можно потратить некоторое время на уточнение деталей ответа на вопрос: «какие ОШИБКИ допускают люди с технологией (...)?» «Какие НЕПРАВИЛЬНЫЕ ПОДХОДЫ ты знаешь к...?»
Поскольку у нас с вами больше половины времени уходит на отладку, а не на перебор инструментов и имплементацию — можно потратить некоторое время на уточнение деталей ответа на вопрос: «какие ОШИБКИ допускают люди с технологией (...)?» «Какие НЕПРАВИЛЬНЫЕ ПОДХОДЫ ты знаешь к...?»
Тут все двояко. С одной стороны — такие терминологические вопросики тоже нужны — позволяют быстро узнать знаком ли кандидат с теорией (заметьте, обратное утверждение я не говорю).
Однако такие вопросы ни сколько не дают понять о том как человек умеет работать, его логике, опыте, обучении, принятии решений и творческом конструировании. Но все же отличных программистов без знания теории не бывает — и если он в обоих этих аспектах выступил на отлично — то что и думать «true senior!».
Но! Кандидат все таки приходит устраиваться на «работу», работа — то есть практика и возможность обучаться/адаптироваться к тонкостям конкретной организации — тут несоизмеримо боле важна чем знание что такое virtual…
Однако такие вопросы ни сколько не дают понять о том как человек умеет работать, его логике, опыте, обучении, принятии решений и творческом конструировании. Но все же отличных программистов без знания теории не бывает — и если он в обоих этих аспектах выступил на отлично — то что и думать «true senior!».
Но! Кандидат все таки приходит устраиваться на «работу», работа — то есть практика и возможность обучаться/адаптироваться к тонкостям конкретной организации — тут несоизмеримо боле важна чем знание что такое virtual…
+
А с чего вы взяли, что вы вообще синьор? Давайте введём определения:
Джун — тот, кому нужно помочь с решением.
Мидл — тот, кто найдёт решение самостоятельно.
Синьор — тот, кто знает все способы решения задачи и может объяснить их преимущества и недостатки.
Вы сами признались, что избегаете наследования, поэтому не помните такую немаловажную при наследовании идиому, как "виртуальный метод". Это уровень Милда — решать все задачи одним знакомым способом.
Так что да, вы оказались самозванцем, и вас вывели на чистую воду одним простым вопросом. Это не повод бомбить. Это повод подумать над тем, как перейти на качественно новый уровень. Вы уже достигли уровня, когда самостоятельно можете решить даже сложную задачу. Пришла пора расширять кругозор и углублять понимание идиом. Готовьтесь всё чаще отвечать не на вопрос "Как?", а на вопрос "Почему так?". А для этого нужно быть хорошо знакомыми даже с теми вещами, которые не используете. И постоянно проводить ревизию своих знаний, так как мир программирования меняется очень быстро. То, что вчера считалось анти-паттерном сегодня в тренде. А что вчера считалось единственно возможным — сегодня анти-паттерн.
Проходила собеседование на мидла. Повторила что такое ООП, паттерны. Что нового появилось в PHP 7. До этого меня об этом спрашивали. И как говорится я не 1 и не 2 год программирую. Но вот вопрос меня поставил в ступор — назовите все типы данных. И в голове почему то вплыла инфа в новых поддерживаемых типах при объявлении переменных. Начала перечислять самые простые. Сходу сказала не все, даже массивы не назвала. Но это не из-за того что не знала. А просто не ожидала такого вопроса. Да и собеседующих было 3. Волнение никуда неденешь.
Вставлю свои 5* копеек. Сидел я в своём «нижнеурюпинске» n лет назад и никого не трогал. Лежало у меня резюме на HH. Позвонили мне из налогсервиса. Мол пройдите собеседование. Но предварительно пройдите онлайн тестирование. Позвонили пару раз. Я уже залюбопытничал мол чего это. Два часа убил на прохождение онлайн тестирования. Приехал к ним в офис. И меня посадили как в цирке: я в центре, вокруг меня человек 8 народа, а передо мной холёный дяденька из княжества московского. Как котик: упитанный, проглаженный, сияет. Этот дяденька протягивает мне бумажку с терминами FTP, ODBC и т.д. и давай меня мол «а что такое FTP? А где он используется» и т.д. Я от такого даже дар речи потерял. Да и я признаться никогда особо не заморачивался над тем что бы расшифровки аббревиатур и точные определения заучивать. В общем как то так. Такое вот оно наше отечественное ИТ…
Эх, ИТ сфера на всех парах приближается к таким «традиционным» направлениям как финансы, HR и маркетинг. А жаль…
Помню один случай с далекой-далекой знакомой, проходила на бренд-менеджера в одной крупной компании из пищевой промышленности. На собеседовании ей показали ролики с рекламой их продукта — один ролик с милой семьей, во втором главный герой — горилла. Ей предложили выбрать какой больше нравится. Она выбрала ролик с семьей и как-то обосновала. В итоге после собеседования ей отказали обосновав тем, что она им «по духу не подходит». Ну а через месяц уже везде можно было видеть рекламную компанию как раз с гориллой. ))
Хотя до такого надеюсь не дойдет.
Помню один случай с далекой-далекой знакомой, проходила на бренд-менеджера в одной крупной компании из пищевой промышленности. На собеседовании ей показали ролики с рекламой их продукта — один ролик с милой семьей, во втором главный герой — горилла. Ей предложили выбрать какой больше нравится. Она выбрала ролик с семьей и как-то обосновала. В итоге после собеседования ей отказали обосновав тем, что она им «по духу не подходит». Ну а через месяц уже везде можно было видеть рекламную компанию как раз с гориллой. ))
Хотя до такого надеюсь не дойдет.
UFO just landed and posted this here
Согласен, или по крайней мере оценивать в первую очередь по проф знаниям и другим деловым качествам. А так получается: «Плюрализм мнений? Неее, не слышали.» ))
Просто это обычная ситуация для упомянутых мной сфер, где субъективный взгляд играет намного большую роль, а всякие там сертификаты «супер-мега финансиста» заменяют наличие здравого смысла. И надеюсь, что в ИТ индустрии все таки до этого не дойдет.
Просто это обычная ситуация для упомянутых мной сфер, где субъективный взгляд играет намного большую роль, а всякие там сертификаты «супер-мега финансиста» заменяют наличие здравого смысла. И надеюсь, что в ИТ индустрии все таки до этого не дойдет.
Хм… вообще, там вроде сарказм был (по крайней мере, я очень на это надеюсь). Какой им смысл нанимать человека (пусть он хоть супер-профессионал), если у него видение продукта и его бренда противоположное команде? Он же и дальше будет пропихивать сопливые ролики с милой семьей, если всей остальной команде это не надо, то постоянно будут одни конфликты.
Если вам отказали на собеседовании – это не обязательно значит, что вы плохой специалист. Это значит, что вы не подходите в эту команду. Поэтому я даже не представляю, зачем по этому поводу столько рефлексировать.
Сарказма не уловил, но может быть )) Моя история скорее не о том, что девушку не взяли, а о том что выбор в данном случае (и опять же в схожих «гуманитарных» бизнес направлениях) был во многом субъективен, не с нами значит против нас. Что лучше — веселенькая семейка или забавная горилла — это вопрос открытый и результата никто не знает заранее, сколько там по фокус группам не прогоняй. Супер-профессионал в данном случае должен бы сказать: «Команда выбрала гориллу, я выбрал(а) семейку. Ок, давайте сделаем суперическую гориллу!». Ну или тоже примерно в таком духе, если он является нанимателем. Категоричным быть не совсем хорошо, хотя это мое субъективное мнение.
В данной статье я увидел некоторое сходство данных случаев (описанных в статье и с которыми я встречался), или скорее присутствуют некие тенденции по сближению.
В данной статье я увидел некоторое сходство данных случаев (описанных в статье и с которыми я встречался), или скорее присутствуют некие тенденции по сближению.
проходила на бренд-менеджера в одной крупной компании из пищевой промышленности. На собеседовании ей показали ролики с рекламой их продукта
просто она заведомо не проходила.
стресс-интервью на бренд-менеджера или, там, датамайнера — плавали, знаем.
Вставлю свои 5* копеек.
Вместо эпиграфа: Представьте себе, как Товальдс проходит собеседование в Майкрософт… или в Nvidia …
Сидел я в своём «нижнеурюпинске» n лет назад и никого не трогал. Лежало у меня резюме на HH. Позвонили мне из налогсервиса (позвонили несколько раз и настойчиво) с просьбой пройти собеседование. Но предварительно нужно пройдити онлайн тестирование. Я уже залюбопытничал мол чего это такая настойчивость.
Два часа убил на прохождение онлайн тестирования. Приехал к ним в офис. И меня посадили как в цирке: я в центре, вокруг меня человек 8 народа, а передо мной холёный дяденька из княжества московского. Как котик: упитанный, проглаженный, сияет. Этот дяденька протягивает мне бумажку с терминами FTP, ODBC и т.д. и давай мне вопросы задавать: «а что такое FTP? А где он используется» и т.д. Я от такого даже дар речи потерял. Да и я признаться никогда особо не заморачивался над тем что бы расшифровки аббревиатур и точные определения заучивать. Не поймите неправильно у меня к тому времени уже был солидный бэграунд за плечами и собеседоваться я приехал не на должность первой линии хелпдеска. А тут я почувствовал себя на табуреточке в садике и меня просят стишок про ёлочку рассказать. От такого отношения реально теряется дар речи (у меня).
В общем было в моей жизни пару раз, когда, придя на собеседование я вдруг почувствовал себя крайне некомфортно. С другой стороны, выбор он с двух сторон осуществляется я бы в такую компанию работать просто не пошел. В общем как-то так.
На мой субъективный взгляд наиболее эффективно собеседование можно провести, когда:
1. Говорить комфортно и интервьюеру, и кандидату.
2. Говорить нужно о тех задачах, которые нужно решать на данной работе (кем были мама и папа, сексуальная ориентация, любители вы суши и т.д. не должны волновать работодателя).
3. Предоставить кандидату самому как можно больше рассказать о себе (во всяком случае когда я принимал на работу админов то ни разу не ошибся. Нужно просто послушать что человек и как говорит. Ну и иногда задавать немного каверзные вопросы в шуточной форме. Например, старый добрый холивар Linux vs Windows и прочие глупые провокационные высказывания. Если кандидат ведётся на провокации, то на непредвзятость и взвешенность рассчитывать трудно.).
4. Если вы как работодатель или как работник ощущаете (вот опять этот человеческий субъективизм) что не сработаетесь, то не нужно насиловать себя и на что-то наедятся. Это не ваш работник или не ваша работа.
По поводу 4 пункта было как-то собеседование на должность ИТ директора, где я оценивал кандидата. Парень крайне толковый. Отработал много лет в зарубежной компании. Но он проходил собеседование в компанию где не было и не могло быть какой-то четкой структуры, иерархии и вся внутренняя жизнь была построена на неформальных договорённостях. Я дал отрицательное заключение, но исполнительный директор, начитавшийся очень много умных книжек и будучи зачарованным «крутым» почти зарубежным специалистом принял его несмотря на это. Как итог ИТ директор полностью провалил всю работу в компании. И конечно расстались с взаимными претензиями и обидами. Хотя с самого начала было ясно что «дельфин и русалка» не пара.
В общем и целом, в компании люди работают с людьми и проклятый человеческий субъективизм очень много решает в успешности построения карьеры в той или иной компании. Вы можете быть самой лучшей компанией в мире или самым крутым специалистом в мире (по вашей версии конечно), но не подойти друг другу (такое бывает).
*Поскольку кнопки изменить комментарий я не нашел то просьба модератору удалить или заменить мой предыдущий комент к этому посту. Поскольку он не полный, а следовательно не точный.
Вместо эпиграфа: Представьте себе, как Товальдс проходит собеседование в Майкрософт… или в Nvidia …
Сидел я в своём «нижнеурюпинске» n лет назад и никого не трогал. Лежало у меня резюме на HH. Позвонили мне из налогсервиса (позвонили несколько раз и настойчиво) с просьбой пройти собеседование. Но предварительно нужно пройдити онлайн тестирование. Я уже залюбопытничал мол чего это такая настойчивость.
Два часа убил на прохождение онлайн тестирования. Приехал к ним в офис. И меня посадили как в цирке: я в центре, вокруг меня человек 8 народа, а передо мной холёный дяденька из княжества московского. Как котик: упитанный, проглаженный, сияет. Этот дяденька протягивает мне бумажку с терминами FTP, ODBC и т.д. и давай мне вопросы задавать: «а что такое FTP? А где он используется» и т.д. Я от такого даже дар речи потерял. Да и я признаться никогда особо не заморачивался над тем что бы расшифровки аббревиатур и точные определения заучивать. Не поймите неправильно у меня к тому времени уже был солидный бэграунд за плечами и собеседоваться я приехал не на должность первой линии хелпдеска. А тут я почувствовал себя на табуреточке в садике и меня просят стишок про ёлочку рассказать. От такого отношения реально теряется дар речи (у меня).
В общем было в моей жизни пару раз, когда, придя на собеседование я вдруг почувствовал себя крайне некомфортно. С другой стороны, выбор он с двух сторон осуществляется я бы в такую компанию работать просто не пошел. В общем как-то так.
На мой субъективный взгляд наиболее эффективно собеседование можно провести, когда:
1. Говорить комфортно и интервьюеру, и кандидату.
2. Говорить нужно о тех задачах, которые нужно решать на данной работе (кем были мама и папа, сексуальная ориентация, любители вы суши и т.д. не должны волновать работодателя).
3. Предоставить кандидату самому как можно больше рассказать о себе (во всяком случае когда я принимал на работу админов то ни разу не ошибся. Нужно просто послушать что человек и как говорит. Ну и иногда задавать немного каверзные вопросы в шуточной форме. Например, старый добрый холивар Linux vs Windows и прочие глупые провокационные высказывания. Если кандидат ведётся на провокации, то на непредвзятость и взвешенность рассчитывать трудно.).
4. Если вы как работодатель или как работник ощущаете (вот опять этот человеческий субъективизм) что не сработаетесь, то не нужно насиловать себя и на что-то наедятся. Это не ваш работник или не ваша работа.
По поводу 4 пункта было как-то собеседование на должность ИТ директора, где я оценивал кандидата. Парень крайне толковый. Отработал много лет в зарубежной компании. Но он проходил собеседование в компанию где не было и не могло быть какой-то четкой структуры, иерархии и вся внутренняя жизнь была построена на неформальных договорённостях. Я дал отрицательное заключение, но исполнительный директор, начитавшийся очень много умных книжек и будучи зачарованным «крутым» почти зарубежным специалистом принял его несмотря на это. Как итог ИТ директор полностью провалил всю работу в компании. И конечно расстались с взаимными претензиями и обидами. Хотя с самого начала было ясно что «дельфин и русалка» не пара.
В общем и целом, в компании люди работают с людьми и проклятый человеческий субъективизм очень много решает в успешности построения карьеры в той или иной компании. Вы можете быть самой лучшей компанией в мире или самым крутым специалистом в мире (по вашей версии конечно), но не подойти друг другу (такое бывает).
*Поскольку кнопки изменить комментарий я не нашел то просьба модератору удалить или заменить мой предыдущий комент к этому посту. Поскольку он не полный, а следовательно не точный.
Мне вот что в последнее время непонятно – почему так обесценилось понятие Senior Developer. Вот есть у нас 3 градации – Junior — Middle — Senior, и все… пришел после универа – Junior. Проработал 2 года – Middle. Еще 2 года – Senior. Так, что ли? А дальше что, как отличить одного сеньора от другого, если между ними может быть 20 лет разницы опыта (и я сейчас про нормальный опыт, не будем про 20 раз по одному году).
Тут либо вводить дополнительные ачивки Super-Senior, Mega-Senior, Giga-Senior и т.д., либо просто признать, что Middle – это уже взрослый самостоятельный специалист-профессионал, а звание сеньора надо еще заслужить.
Вот, судя по профилю, автору 24 года. Простите, но мне правда с трудом верится, что это серьезный, умудренный опытом Senior Developer. Либо он гений с феноменальной памятью и когнитивными способностями (тогда как он умудрился virtual-то забыть?), либо я чего-то не понимаю. И потом, дело не только в интеллектуальных способностях, опыт – все-таки такая штука, которая должна настояться. Можно за 20 лет не получить никакого полезного опыта, но нельзя за 1 год получить опыт 20 лет.
Может, давайте все-таки поднимем планку сеньора? А то вот мне 31 год, только с андроидом работаю больше 6 лет, но мне было бы стыдно подойти к Jake Wharton и сказать, что я Senior Android Developer.
Вы сильно усложняете. Почему-то все дерутся за эти долбанные лычки (сениор, мидл и т.д.). А вы знаете вообще откуда это пошло? А какая здесь есть грань между этими лычками? Вся эта возня в очередной раз доказывает, что люди — это неумные, легко внушаемые существа, которыми маркетологи вертят, как хотят. И IT специалисты в этом плане вообще не исключение! Загуглите про корпоративную «культуру», как менеджмент создает из своих сотрудников послушных зомби, и все для того, чтобы минимизировать свои затраты. Но зомби, по ходу, всем довольны, аминь.
Вот есть у нас 3 градации – Junior — Middle — Senior, и все… пришел после универа – Junior. Проработал 2 года – Middle. Еще 2 года – Senior. Так, что ли?
Если тыкают в твои ошибки и стараются подсказать, как нужно делать, то ты Junior.
Если ты тыкаешь в чужие ошибки и указываешь другим, как нужно делать, то ты Middle.
А если ты поднимаешь голову и все понимают, насколько они неправы, определенно Вы Senior.
и я сейчас про нормальный опыт, не будем про 20 раз по одному году
А что вы имеете против этого? Сейчас любое резюме именно так и выглядит с учетом стабильности большинства фирм и хайпа вокруг подобного маразма. Тут и закрытие фирм и сокращение подразделений, или просто встречаешься с таким вот собеседователем и проходишь собеседование, а потом через год понимаешь что зря. Ну, а если вы не представляете, что за год проект можно спокойно сдать, закрыть и быть свободным, это просто ваша личная практика. А по сути не организованная удаленка.
Мне вот что в последнее время непонятно – почему так обесценилось понятие Senior Developer. Вот есть у нас 3 градации – Junior — Middle — Senior, и все… пришел после универа – Junior. Проработал 2 года – Middle. Еще 2 года – Senior. Так, что ли? А дальше что, как отличить одного сеньора от другого
По-видимому, трёхступенчатая градация принята только в РФ и, может быть, ближайшем зарубежьи. Лично я никогда не был ни джуном, ни мидлом, ни синьором. В одной компании, где формальная градация «лычек» вообще была, она была ~7-ступенчатой; но гуглятся и более изощрённые системы.
Говорю по себе: вопросы, которые кажутся странными, встречаются тем чаще, чем больше у вас опыта. Со временем бОльшая часть теории забывается (т.к. на практике отлично заменяется интуицией). Например, если вы 10+ лет успешно проектируете системы, то вряд ли вам что-то даст, если вы всё ещё помните (или выучите, если не знали) принципы SOLID или подробности работы сборщика мусора в вашем ЯП. Но на собеседованиях это часто спрашивают. Такова жизнь. Поэтому, если оно вам нужно, то как говорится, обмани дурака — дай ему то, что он хочет. :)
принципы SOLID или подробности работы сборщика мусора в вашем ЯП
По поводу заучивания SOLID соглашусь, оно вполне интуицией/наработанной практикой заменяется… Но вот про «подробности работы сборщика мусора в вашем ЯП». А кто, простите, если не сеньор, должен понимать, как оно действительно работает? Есть множество программистов, способных написать код, соответствующий определенным критериям «корректности», но они миддлами называются. А вот когда «все предельно корректно», но почему-то все равно тормозит — тут миддл не решит, тут сеньор и нужен. А он уже разбирается «так, мол, и так, вот тут сборщик мусора нагрузили, если переделать через чутка хитрозаверченную попу, будет тормозить меньше, в пределах таких-то показателей».
Джун — это программист без опыта, который пока еще не умеет гарантированно генерировать формально правильный код. Он неизбежно с опытом должен мутировать в миддла (или пойти «на мороз» по хорошему) — в человека, который может самостоятельно генерировать формально-корректный код. И есть «сеньор», гарантии превращения в которого из миддла никто не дает. Сеньор — это такая штука, которая способна разобраться, почему формально-корректный код работает не так, как предполагалось.
Или у вас какие-то другие понятия о «сеньорстве»?
Нет, не другие :) Что касается моего высказывания по поводу сборщика мусора — за много лет разработки на разных языках (в проектах разного калибра), когда я сталкивался с тормозами, то всегда выходило, что GC работает как надо, и знание подробностей просто ничего не даёт. Так что, с моей точки зрения, это, как минимум, не самые нужные сведения. Если у кого-то другой опыт — мне будет интересно об этом узнать.
Не могу сказать, что у меня прямо море опыта (вообще ни разу не сеньор), но навскидку:
В Go передача параметра по указателю — вещь достаточно опасная. У него сборщик мусора шустрый, но достаточно простенький, и лишний раз нагружать малыша не рекомендуется. В определенных комбинациях мы можете а) нарваться на аллокацию в куче, б) просадить производительность на сборке мусора. Из экспериментов: структуры данных размером 250-300 байт и меньше лучше отдавать по значению — так будет реально быстрее. Но при этом стоит помнить, что стек не резиновый.
В Java той же несколько сборщиков мусора, и надо понимать, какой из них и как скажется на производительности.
C++ вообще имеет смысл использовать для ручного управления памятью, т.е. надо знать, как с ней работать.
Думаю, миллион нюансов можно найти.
В Go передача параметра по указателю — вещь достаточно опасная. У него сборщик мусора шустрый, но достаточно простенький, и лишний раз нагружать малыша не рекомендуется. В определенных комбинациях мы можете а) нарваться на аллокацию в куче, б) просадить производительность на сборке мусора. Из экспериментов: структуры данных размером 250-300 байт и меньше лучше отдавать по значению — так будет реально быстрее. Но при этом стоит помнить, что стек не резиновый.
В Java той же несколько сборщиков мусора, и надо понимать, какой из них и как скажется на производительности.
C++ вообще имеет смысл использовать для ручного управления памятью, т.е. надо знать, как с ней работать.
Думаю, миллион нюансов можно найти.
UFO just landed and posted this here
Могу подтвердить, что дело не в разработчиках, и даже не в ИТ, всё намного глубже. И никто (почти) лучше собеседовать не будет в обозримом будущем. Аналогичная ситуация вообще во всех сферах, включая упомянутые выше финансы с экономикой, маркетингом и проч… Да и на производстве похожая картинка. Знаю не понаслышке, так сам десятки раз проходил собеседования и, что важнее для оценки, сам десятки раз собеседовал кандидатов. Обычное собеседование, описанное автором — как-будто костюм или платье покупать собираются… Талия такого размера, в плечах столько-то сантиметров… Результаты потом соответствующие… «К пуговицам претензии есть? Нет.» Никто не хочет брать на себя реальную ответственность, начиная с рекрутёров. Сам же интервью всегда начинал с просьбы рассказать о себе, начиная со школы и далее. То есть пытался понять мотивацию человека, как в целом, так и к работе, круг интересов и т.п. Конкретные знания дело, конечно, хорошее, но их всегда можно расширить, улучшить, добавить и т.п. А вот с личностными качествами так не получится, поэтому с них и нужно начинать… К сожалению ситуация дойдёт и до горилл в ИТ, и далее проскочит. Дна пока не видно…
У меня давно уже сложилось схожее мнение с Автором. Но я пошел немного дальше и выделяю для себя три типа людей-разработчиков.
1. Люди которые заточены исключительно на теоретических аспектах. И не особо умеют сами что-то придумать.
2. Люди которые могут сами придумать, что-то новое, но теорию знают не полностью.
3. Творческие люди которые знают теорию и используют её с толком. (такое объединение 1 и 2)
Тут основная проблема такая:
Разработчиков типа 1 очень много, 2 поменьше и 3 совсем мало, единицы.
Работодатели ищут 1 и 3. Но 3 уже работают в Яндексах, Контаках и других интересных местах.
А суть в том, что теоретик (1), никогда не станет крутым разработчиком (3), в то время как думающие программисты (2) вполне могут стать (3). Но (2) гнобят, и им сложно стать (3). Такой замкнутый круг.
1. Люди которые заточены исключительно на теоретических аспектах. И не особо умеют сами что-то придумать.
2. Люди которые могут сами придумать, что-то новое, но теорию знают не полностью.
3. Творческие люди которые знают теорию и используют её с толком. (такое объединение 1 и 2)
Тут основная проблема такая:
Разработчиков типа 1 очень много, 2 поменьше и 3 совсем мало, единицы.
Работодатели ищут 1 и 3. Но 3 уже работают в Яндексах, Контаках и других интересных местах.
А суть в том, что теоретик (1), никогда не станет крутым разработчиком (3), в то время как думающие программисты (2) вполне могут стать (3). Но (2) гнобят, и им сложно стать (3). Такой замкнутый круг.
UFO just landed and posted this here
О. О чём я говорил: автора ОП удобно и приятно поднимать на щит.
А вот Вы, в отличие от опытного автора, имеющего пруфы своей ценности для бизнеса и для задач отдела, уже строите аргумент примерно как «но я же разработчик, а не зубрила. Почему во мне должны увидеть разработчика? Потому что я не зубрила».
Я никого не троллю и никого не стараюсь дискредитировать, тем более, Вы тян.
Но если позволить себе роскошь ничего не утверждать… вот есть такая вещь, как нечёткая логика… и осторожно замечу себе под нос, что вот это — простите, маркер:
Скажем так. Будь я интервьюером, я бы как минимум задал Вам наводящий вопрос: «а когда, Вы считаете, пора обращаться к коллегам и помощникам из интернета за решением своей задачи?»
ну, и ещё один наводящий вопрос. Что Вы понимаете под «видеть систему в целом»?
А вот Вы, в отличие от опытного автора, имеющего пруфы своей ценности для бизнеса и для задач отдела, уже строите аргумент примерно как «но я же разработчик, а не зубрила. Почему во мне должны увидеть разработчика? Потому что я не зубрила».
Я никого не троллю и никого не стараюсь дискредитировать, тем более, Вы тян.
Но если позволить себе роскошь ничего не утверждать… вот есть такая вещь, как нечёткая логика… и осторожно замечу себе под нос, что вот это — простите, маркер:
Это очень обидно, ведь программист работает с интернетом
Скажем так. Будь я интервьюером, я бы как минимум задал Вам наводящий вопрос: «а когда, Вы считаете, пора обращаться к коллегам и помощникам из интернета за решением своей задачи?»
гораздо важнее видеть систему в целом
ну, и ещё один наводящий вопрос. Что Вы понимаете под «видеть систему в целом»?
UFO just landed and posted this here
Вы, наверное, все спеки 1С в голове держите?
хелп (у 1Ски в нём справочник по встроенному языку) то и дело открыт, но в голове при работе приходится держать МНОГО чего, конечно же.
На сайте Инфостарт.ру сплошь и рядом бывает, что тебе безвозмездно за спасибо предоставляют готовый код под твою задачу, но уважающие себя и коллег разработчики, прежде чем задавать вопрос тому сообществу, вначале пытаются решить проблему сами. По бухгалтерским вопросам, что что-то не проводится или не заполняется в типовой конфигурации, например, там же как правило эффективен поиск по старым темам, но мы же программисты, у нас список FAQ не так обширен по определению. Или готовые решения стоят денег. Ведь разработчик производит интеллектуальную собственность.
обращения к коллеге, который писал этот код
Который код? Новый код, который ждут от Вас? Или Вы не про основную специализацию разработчика, а, например, про специализацию ревьюера?
Полагаться на чужие решения — это если и не однозначно вредная, то однозначно опасная привычка. Будь я ревьюером, у меня бы возникло логичное и вероятное предположение, в рамках которого она становится вредной: «а если программист не может определить неоптимальность подсказанного ему решения?». Вероятность высока даже для грамотного разработчика, потому что если бы задачки и технологии не были бы постоянно новыми, то вместо разраба посадили бы кодогенератор. А Вы к тому же выкидываете на этом основании из головы и «старые» названия.
Ну это вообще переход на личности.
Нет, это реквест Ваших пруфов. Не обвинение. Иллюстрация того, чем мне не нравится построение аргумента интервьюируемым кандидатом по приведённой мною же схеме. И тем более, почему наверняка не понравится собеседующему.
вообще, конечно, придирки к ИНТЕРВЬЮЕРАМ на квалификационном СОБЕСЕДОВАНИИ (а я ведь встал на место такого интервьера) — по каверзной ПОСТАНОВКЕ ВОПРОСОВ — повторяю, ЗЛО. Тем более, что каверзная она, эта постановка, не по каким-то несправедливым критериям подлой дискриминации, а именно, в плане сомнений в квалификации. Ну, запретите интервьюерам-айтишникам, интервьюерам-коллегам, «ставить вопрос так, будто это что-то негативное». можете запретить законодательно. Кончится тем, что собеседовать вас будут одни эйчары. «Зашоренным» потенциальным коллегам есть чем заняться, помимо Вашей тонкой, непредсказуемой, чуждой любой зубрёжки и открытой Интернету гораздо больше них, натуры. Тем более, раз они ищут пополнение, вполне вероятно, штат недоукомплектован.
Расскажу про свой опыт. Меня собеседовани на позицию middle+ в аутсорс-компанию. По моему, в аутсорсы обычно задают сложные, но адекватные вопросы (вещи с которыми сталакивались — иногда, правда, собеседующие могут не до конца разобраться в некоторых вопросах и вещи про которые прочитали в умных блогахи и книжках — тут все понятно).
Вопросы начались с полиморифизма (на которые я хоть кривился, но ответил), типы объектов (valuetype и reference, boxing/unboxing, передача по ссылке и т.д.
Далее пошли реализация async/await, IDisposable, IDisposable в foreach, зачем нужен async void, чем помогает Task.ConfigureAWait(false) — на эти три не ответил, как используется SynchronizationContext (знаю, что такое, но не использовал), обработка исключений в Task, что такое Semaphore, SpinLock, ManualResetEvent/Slim, Mutext/Slim (не ответил), CAS, как работает сборка мусора, и т.д., потом вопросы про ASP.NET — ответил плохо, базы данных (sql server), типы джойнов, изоляции транзакций, индексы (columnstore и rowstore), как работают, чем транзакции postgres отличаются от sql server, fts, и еще много чего. В общем, собеседующие наверное спросили все, что могли вспомнить. Хоть и "топищи", но снисходительно (с моей просьбы) ответили на некоторые свои вопросы (на которые я не ответил). На некоторые вопросы я нес какую-то чушь (вроде пытался горить понятно, но не получалось. Не смотря на потрясение, узнал много новых вещей (о некоторых просто подзабыл, т.к. с .NET не работаю уже больше года) и получил пищу для размышления.
Для middle+ довольно серьезный опрос, видимо компания достаточно суровая.
Для себя с удовольствием отмутил, что на эти вопросы я ответы знаю, разве что в MutexSlim смысла не вижу, проще уж спинлоки использовать. Хотя вот про отличие транзкций не ответил бы ибо с постгресом не работал. Про изоляции кстати долго не мог заучить, пока на практике не понадобилось разрешать дедлоки (из-за повышения shared_lock до unique). В одной конторе было целое тестовое задание на это, очень мозги прочистило. Можете тоже повторить: есть таблица с пользователями. И мы делаем в АПИ метод RevertSex который меняет в базе булку IsMale. В запросе приходит фамилия пользователя — ищем пользователя по фамилии, меняем пол (считаем, что фамилия уникальна) на противоположенный.
Так вот, если запустить этот пример для десятка пользователей (разных) в разных потоках, то выполнение начнет тупить и очень долго всё будет отрабатывать. Задача — сделать так, чтобы отрабатывало быстро.
Как по мне, задача прям замечательная.
Вопрос — а зачем они используют они говорили? Я бы сказал, что это костыль для winform/wpf, где мы можем для обработчика только fire&forget использовать.
Для себя с удовольствием отмутил, что на эти вопросы я ответы знаю, разве что в MutexSlim смысла не вижу, проще уж спинлоки использовать. Хотя вот про отличие транзкций не ответил бы ибо с постгресом не работал. Про изоляции кстати долго не мог заучить, пока на практике не понадобилось разрешать дедлоки (из-за повышения shared_lock до unique). В одной конторе было целое тестовое задание на это, очень мозги прочистило. Можете тоже повторить: есть таблица с пользователями. И мы делаем в АПИ метод RevertSex который меняет в базе булку IsMale. В запросе приходит фамилия пользователя — ищем пользователя по фамилии, меняем пол (считаем, что фамилия уникальна) на противоположенный.
Так вот, если запустить этот пример для десятка пользователей (разных) в разных потоках, то выполнение начнет тупить и очень долго всё будет отрабатывать. Задача — сделать так, чтобы отрабатывало быстро.
Как по мне, задача прям замечательная.
async void
Вопрос — а зачем они используют они говорили? Я бы сказал, что это костыль для winform/wpf, где мы можем для обработчика только fire&forget использовать.
В большинстве компаний одним из требований к позиции Senior является знание архитектуры. Если не знаете, что такое virtual, то и не сможете ответить на вопрос чем virtual отличается от abstract — а ведь всё это базовые вещи, без которых архитектору никуда.
К сожалению, на хабре в последнее время часто стали появляться подобные статьи, где люди бьют себя пяткой в грудь и кричат, что в них не разглядели талант. Я так понимаю, управленческого опыта никакого нет, в базовых понятия плаваете… Что тогда можете предложить из того, что должен знать сеньор? Отлиное понимание процессов и методологий? Планирование? Надеюсь.
Уверен, что описание процесса собеседования сильно искажено и автор сначала неуверенно отвечал на вопросы об азах языка, а потом и вовсе впал в ступор. Прямо как в том анекдоте:
К сожалению, на хабре в последнее время часто стали появляться подобные статьи, где люди бьют себя пяткой в грудь и кричат, что в них не разглядели талант. Я так понимаю, управленческого опыта никакого нет, в базовых понятия плаваете… Что тогда можете предложить из того, что должен знать сеньор? Отлиное понимание процессов и методологий? Планирование? Надеюсь.
Уверен, что описание процесса собеседования сильно искажено и автор сначала неуверенно отвечал на вопросы об азах языка, а потом и вовсе впал в ступор. Прямо как в том анекдоте:
-Он меня топил-топил, а я выплыл
-Я его тянул-тянул — еле вытянул
Если не знаете, что такое virtual, то и не сможете ответить на вопрос чем virtual отличается от abstract — а ведь всё это базовые вещи, без которых архитектору никуда.
Базовая вещь — это полиморфизм подтипов (sub-typing polymorphism), да и тот не во всех языках и не всегда широко используется. Где-то предпочитают утиную типизацию (duck typing) вместо. А virtual и abstract, это всего лишь модификаторы в определённых языках.
По своему опыту знаю, как ранят нелепые и заваленные собеседования :) Сейчас отношусь к ним спокойно — это же просто жизненный опыт и пинок подтянуть теоретическую базу. Спрос на специалистов IT очень высокий, в одной компании тебя выводят на «чистую воду», в другой — понимают, насколько хорош. Каждое место работы и проект делают тебя компетентнее и дороже. Возможно, через пару лет тебя будут рады видеть в этой компании, но уже не потянут твой новый ценник :)
Согласно определению Юдковского рациональное мышление — это мышление по Байесу. То есть корректная переоценка уверенности в гипотезе (hypothesis, H) по мере появления новых свидетельств (evidences, E). Предлагаю сообществу решить задачку на рациональное мышление, кому не лень (это же не собеседование).
Задачка не на память, поэтому в формулировке напомню все нужные арифметичекие формулы, и даже посчитаю часть решения.
Предположим, на данный момент из всех соискателей на данную вакансию нам подходит только каждый пятый. То есть из опыта известно, что из 1000 человек нам подошли бы 200, а 800 не подошли. Это значит, что до начала собеседования наша уверенность в том, что соискатель нам НЕ подходит — сразу 80%. Мы задаём им вопросы-фильтры, по их результатам обновляем эту нашу уверенность и принимаем решение — нанимать ли соискателя.
Возможны четыре варианта: 1) наймём подходящего, 2) не наймём неподходящего, 3) не наймём подходящего, 4) наймём не подходящего. Первые два варианта ок. Третий вариант — ошибка второго рода, ложноотрицательное срабатывания теста — не очень страшен, остаётся ещё 199 подходящих соискателей из исходной тысячи. Четвёртый вариант — ошибка первого рода, ложноположительное срабатывание теста — очень страшен, неподходящих людей тяжело увольнять юридически и организационно; они очень затратны. Наша цель — настроить тест так, чтобы максимально избегать ложноположительных срабатываний пусть даже ценой увеличения ложноотрицательных срабатываний.
В терминах Байеса, наше свидетельство — это ответ соискателя на простой вопрос про virtual. Из опыта нам могут быть известны какие-то распределения. Что, например, даже среди людей, которые нам не подходят, 60% всё-таки осилят вопрос про virtual (480 из 800); а 40% даже этого не смогут (320 из 800). А вот среди людей, которые нам подошли бы, 95% уверенно рассказали бы про эту базовую вещь (190 из 200); а 5% замешкались, растерялись и не нашлись — хоть и толковые (10 из 200).
Вопрос: как нам посчитать P(H|E) — то есть переоценить априорную убеждённость P(H) = 20% в том, что соискатель подходит, в свете поступившего свидетельства E, что про virtual он не ответил? Ожидание того, что толковый человек не ответил бы на простой вопрос мы оцениваем как P(E|H) = 5%. И что бестолковый человек не ответил бы тоже не очень высоко (вопрос-то всё-таки простой) как P(E|¬H) = 40%.
Формула Байеса: P(H|E) = P(E|H) × P(H) / P(E)
Формула полной вероятности: P(E) = P(E|H) × P(H) + P(E|¬H) × P(¬H)
Последняя формула нужна, потому что на практике редко известна P(E) в сыром виде для подстановки в первую формулу, но часто оценивается по кускам.
У меня получился ответ ≈3%, то есть априорную убеждённость P(H) = 20% мы должны понизить до апостериорной P(H|E) ≈ 3%. Кто-то может перепроверить арифметику?
Хватит подозревать разрабов в самозванстве. Научитесь лучше собеседовать