Комментарии 1581
Как js разраба раздражает что даже на senior позицию присутствует обязательный вопрос «что такое замыкание?»
К сожалению, хоть вы и понимаете, как работают замыкания, но не поняли их главного назначения — это не «самовызывающиеся функции», это — объекты (функции первого порядка), которые замыкают в себе некоторый контекст, который в зависимости от языка может содержать в себе определенный набор переменных и областей.
То, что вы можете реализовать статическую переменную, опираясь на эти свойства, учитывая при этом все особенности JS/TS/.NET, говорит о вас как о хорошем разработчике, способном видеть архитектурные концепции за простым кодом, что как раз и вызывает восторг у знающих коллег.
И еще — нет, не придется, потому что обычно находятся более элегантные решения, чем использование статических переменных.
в этом моменте.
Или это как в квантовой механике — самовызов — функция считается одновременно вызванной и нет до тех пор пока программист не скомпилирует код?
Я конечно, понимаю, .Net имеет свою терминологию, возможно, это что-то из специфического, но ни в руби, ни в пхп, ни в яве, и даже в C# я такого зверя не встречал, будьте добры пояснить за вашу Senior терминологию.
Очевидно, функция которая сама себя вызывает, т.е. рекурсивная ;). (на самом деле, наверное, module pattern)
(function () {
}());
Вообще это называется iife (immediately-invoked function expression) :)
Это видимо какой-то особый .net нейминг, с теорией программирования не связанный.
Ну или кто-то сеньор только своей голове, а не в реальности, тут не совсем понятно.
Ирония всего происходящего в том, что самозванец, называющий себя «Senior full stack developer», кричит о том, что «хватит подозревать разрабов в самозванстве».
Для меня это звучит как «Платите мне сеньорские за знания слабого миддла». Это просто смешно.
По ссылкам реальные люди говорят это реальное, может быть сленговое, название. Или, типа, редкий сленг = самозванец?
Кстати, если изучите кто пользуется этим термином, поймете, что среди них не так уж много профессионалов, что говорит о том, в каких кругах это слово распространено.
2018 год, а многие всё ещё верят выхлопу гуглтранслейта. Чтобы не быть голословным: по partitioning нет ни правильного «секционирование», ни «партиционирования» от людей не знакомых с теорией.
Соглашусь, что «немедленно вызываемые» передают суть, а «самовызываемые» намекают на непонимание происходящего в коде.
imho, все-таки есть минимально необходимый уровень знаний матчасти. Математик может не использовать таблицу умножения, занимаясь тензорной математикой, но ответить сколько будет 2*2, кмк обязан.
Все мы люди и модет на небольшое время "забыть" от волнений или по другим причинам даже 2*2. Думаю почти все сталкивались когда понимаешь о чем речь, но слова забываются.
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
А решается это все просто, нужно чтобы собеседование проводили или несколько людей с разных проектов, или несколько технических интервью, тогда будет более менее честная оценка
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
И в некоторых случаях будет прав.
Два раза натыкался на проблемы при найме сотрудников на наукоемкие позиции. Приняли сотрудника, а потом от него постоянные (обоснованные!) жалобы на неграмотную постановку задач и на то, что его никто не понимает (и это тоже правда). А у других сотрудников — мысли «а этот человек вообще занимается чем-то полезным?». Т.е. не могут отличить от самозванца.
Если берешь overqualified специалиста, обязательно вдобавок к тому, что написано в вакансии, проверяй преподавательские навыки и думай, как будешь проверять и оценивать его работу. Если не можешь проверить и нет денег на одновременный найм двух кандидатов — вакансия невалидна.
Преподаватель видела, что я в принципе разбирался в теме, но переволновался. Попросила нарисовать какой-то график, нарисовал. Спросила, что больше: 1/4 или 1/2(1/4 у меня было больше). Тут до меня дошло, она посмеялась и поставила 4))
Отлично — это знание, ставшее отсутствием ошибок. Причём неважны причины тут… хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Без ошибок.
Если мне на заводе инженер напортачит, я что — буду смотреть на то, что он в принципе всё знает?..
Тут экзаменатор как раз поступил очень корректно.
хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Здесь ничего не смущает?
Я сам находился в таком качестве (причём и на месте сдающего, и принимающего).
Экзаменатор формирует очередь пересдачи (самому себе, как правило), и не хочет туда включать сдающего. Он уже оценил его уровень, и оценивает на 4-е (и я его понимаю). Сдающий понимает, знает предмет, но допускает ошибки, и довольно глупые. Успеет ли он до пересдачи справится с причинами, приведшими к ошибке? Не знаю, тут уже рядом сидеть нужно. Но там ещё за тобой народ, потому здесь и сейчас — 4-ка.
Уровень, условия включения на пересдачу «спускаются свыше». Деканатом, как правило. И эта очередь да, зависит от оценки. Ибо только её обычно и видит деканат в реестре. Если 4-шников включать в списки на пересдачу, будет уже беседа деканата с экзаменатором. С какого ты его на пересдачу-то?! У него же «хорошо».
Ибо время экзаменатора — принадлежит не ему.
Он должен обосновать требование пересдачи перед контролирующим органом (деканатом).
Но ученик может возразить.
Это его право.
Как правило, экзаменатор на требование «да не нужна мне 4-ка без пересдачи!» пожимает плечами, и ставит оценку, которая автоматом направляет на пересдачу (там, где я учился, хотя бы 3-ка нужна, чтобы не разбираться потом с деканатом).
Никаких проблем в 99,9999% случаев.
Потому что эта оценка до пересдачи уже ничего не значит.
Подготовишься на отлично — получишь отлично.
Люди ошибаются, всегда и постоянно, и ничего ты с этим не поделаешь.
Если мне на заводе инженер напортачит
Если у вас на заводе инженера работают в постоянном стрессе сравнимым с экзаменами в ВУЗе, то у меня плохие новости для вашего бизнеса)
Мило. За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал. Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен.
Собственно, именно потому за неё платят деньги.
За свой экзамен (его можно сравнить скорее с интеллектуальным удовольствием) — платите вы.
За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал.
А у меня наоборот. Тоже много лет опыта, несколько стран (> двух), несколько компаний, разные сферы бизнеса и т.д. и т.п… Везде работа была комфортной и не стрессовой, хоть иногда и весьма интеллектуально сложной.
Я писал о требовании психологической устойчивости. Это сильно разные понятия.
Психологическая устойчивость — это готовность успешно справляться со стрессом, но не сам он.
Меня вообще удивляют эти высказывания, что на экзамене — стресс. Я к своим экзаменам в университете даже не готовился ни разу! И закончил с красным дипломом, кстати. Если вы учитесь, не спустя рукава, и учёба вам в радость, то экзамен — это просто один из способов пообщаться с экзаменатором, продемонстрировав ему (подтвердить) свои знания.
Что тут стрессового?
Я, конечно, понимаю, что может мне так повезло с университетом, но может, как раз если для вас экзамен — стресс, то вы не там, или не на того учитесь?..
А последующая работа — это уже ответственность.
И не перед собой, и вашей дальнейшей судьбой (не нужно переоценивать свою персону), а уже перед другими и за других.
Которой нет, не должно быть на экзамене.
Инженеры, которые у меня работают — отвечают за бизнес, большие деньги. Некоторые — за безопасность других людей.
Сравнивать это с экзаменом, где решается только твоя судьба (причём с возможностью пересдачи) — неадекватно, имхо.
А последующая работа — это уже ответственность.
И не перед собой, и вашей дальнейшей судьбой (не нужно переоценивать свою персону), а уже перед другими и за других.
Не поймут Вас, увы. Хотя написано-то все очень правильно. Хотя для меня экзамен все же был стрессом, толика эгоизма — это нормально :)
Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен
Интересно, кем же вы работаете?)
Я инженер-программист, мне моя работа приносить удовлетворение и не только материальное, а часто даже радость, когда получается красиво решить задачу. И уж конечно не приносит стресс.
Я просто уверен, что инженер в состоянии стресса, кроме костыля ничего не может придумать. И вообще, в моей профессии если ты довел дело до стресса (в большинстве случаев это банальный срыв сроков), то ты свою работу делаешь плохо.
Я писал, ещё раз, о требовании психологической устойчивости, требуемое в работе в степени, несравнимой с такой простой вещью — как экзамен (если вы учитесь нормально, конечно).
Я тоже раньше был программистом, теперь архитектор, и руководитель проектов, но область в принципе понимаю.
Моя работа не стрессовая, но иногда, изредка — бывает такой.
И требования к психологической устойчивости (не сам стресс, но готовность справится с оным) тут определяет несравненно большее, чем то, что решается на экзамене.
На рабочих профессиях — все еще проще в плане отношения к результатам труда. Даже врачи в массе не переживают о качестве своего лечения и размере «персонального кладбища», конечно хорошие врачи — переживают.
Но если брать обобщение — то человек переживает в ключевых точках. Например в точке оценивания, как-то прием на работу или экзамен, или ожидание отзывы с прошлой работы. А между этих точек — фаза расслабления, «меня уже взяли, можно и расслабится».
Так-что вы не правы. Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целом. А речь идет о людях, которым диплом важен, и оценка важна, они верят что это повлияет на их последующую жизнь. И стресс от экзамена — выше стресса от первого собеседования на очень желанную работу. Ведь работу можно и другую найти, а экзамен он один.
Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целомЯ не придавал в обучении важности оценкам, это так. Хотя по результатам обучения и был в череде лучших потока.
А после, некоторое время будучи преподавателем, понял окончательно, что оценка — это больше для учителя, а не ученика.
Не нужно путать, смешивать результат обучения, и его формализованную оценку.
Мне вообще, судя по обсуждению, как-то повезло, для меня университет был одной большой радостью, безо всякой примеси даже возможности стресса.
Последующая работа у меня также — не стресс (ну, изредка, но бывает и такое).
А всего лишь постоянная готовность к оному.
Ответственность. Перед другими, и за других.
Которой неоткуда взяться на экзамене, где ты — только сам за себя (если не считать третьими лицами родных, которым это тоже важно).
И тогда возникает закономерный вопрос — может, если для тех, у кого учёба (или экзамен) была стрессом — может у них как раз что-то неправильно было?..
Относительно ответственности — все то-же самое и в университете. Если провалишь универ, то не найдешь хорошую работу, не сможешь обеспечить будущих детей, и вся жизнь пойдет под откос и по пути «неудачников», коих вокруг полно и среди молодых и среди взрослых.
Тут скорее вопрос исключительно в моменте перехода от «беззаботного детства» к «ответственному взрослению». У вас этот переход случился на работе, на работе вы стали ощущать ответственность перед другими и за других. У меня он случился около 8го класса и я ходил и испытывал постоянный стресс от кучи негативных вариантов исходов моей жизни, думал о том кем я хочу быть, кем работать, и как при этом обеспечить будущую семью, и где жить, и стоит ли мигрировать или нет. Другими словами — нас (людей) напрягают ВОЗМОЖНЫЕ факапы (та самая готовность к стрессу). Но начинают они нас напрягать внезапно, в какой-то момент жизни. После этого момента, ты начинаешь «парится за все». И чем меньше остается «возможностей обосраться», тем меньше этих переживаний. Т.е. окончив нормально универ — перестаешь переживать что ты дебил. Женивщись — что ты не женишься. Родив детей — что забудешь их родить. И стресс с возрастом снижается, т.к. цена ошибки падает. В юношестве мне казалось что провалив первую сессию, я не смогу получить красный диплом, и моя жизни станет в 5 раз сложнее и не предсказуемей. Сейчас мне кажется что в случае провала проекта, я через неделю найду новую работу.
Ну или вы просто ощущали себя в безопасности от «плохого диплома». И такое бывает, например родители гарантируют помощь. Или есть примеры саксес стори с плохим дипломом, которые есть силы повторить. У меня не было ни того, ни другого.
Уже позже это и переросло в «не люби себя таким, какой есть — сегодня лучше чем вчера, завтра лучше, чем сегодня».
Но и вас я так же прекрасно понимаю — у людей опыт разный (и это хорошо ведь).
Экзамены в ВУЗ-е вы считаете стрессом по сравнению с работой?!Это достаточно известный факт между прочим. Экзамены и собеседования — типовой сценарий в исследованиях поведения человека в стрессовой ситуации, это наиболее известные, легко воспроизводимые и универсальные ситуации. Ключевое слово здесь — универсальные. Практически для любого человека экзамен — сильный стресс. Если лично для вас не так — значит вы либо сильно выделяетесь, что конечно возможно и я искренне за вас рад, либо не осознаете до конца что такое стресс. Я могу попытаться найти исследования на эту тему если интересно.
Не очень верная аналогия, но если в боксёрском поединке спортсмен А победил спортсмена Б, то это означает, что спортсмен Б слабее. Даже если на тренировках он показывал отличные результаты и был всеобщим фаворитом.
По мне реальная работа это бОльший стресс и напряжение нежели экзамен. И если даже на экзамене в голове пусто, образно говоря, то уж извините.
Да и знание таблицы умножения это не зубрёжка, а элементарные навыки счёта. В пределах 100, замечу. По мне странно, что то, что наши дедушки-бабушки-родители знали и успешно учили в 7 лет, вдруг оказывается недоступно выпускнику вуза (ну не верю я в истории про гениальных математиков/инженеров/программистов, которые не могут умножить 5 на 5).
Конкретно в этом случае… если на самом деле так сказал, мог быть 5 поставить, с минусом) Или другое задание дать.
По мне реальная работа это бОльший стресс
Меняйте работу, а то умрете молодым.
Ну он походу неправильно решил задачу. То есть "все ок но такая обидная ошибка, заказчик рвет и мечет в итоге тт, ну сам понимаешь в таких условиях — никакой премии".
Если ко мне так руководитель подойдет, то уверяю, что у него возникнет желание извиниться передо мною.
А почему вы думаете, что навык переговоров исключительно приобретенный и не зависит от врожденных возможностей?
Я ни слова не сказал о том, переговорный навык приобретенный или врожденный. Не надо говорить то, чего нет в словах других людей. ОК?
Да. Люди разные. Но мир такой какой он есть и надо либо играть по его правилам, либо сам виноват! Мы же не приходим в футбол и не говорим «А я вот хочу клюшкой играть».
Мне тоже, если что, даются переговоры в чем-либо и с кем-либо и как следствие из-за этого прокрастинурую над задачами, где надо переговорить. Но! Абсолютно не важно что у меня это врожденное или не своейственное мне иногда надо просто взять и сделать! И точка!
Мое мнение — нет. Воспитанием должны заниматься одни, а обучением — другие.
Есть 2 типа руководителей:
1. Мудак. Который считает, что раз он\она начальник, то все должны слушаться и такие люди как правило живут по принципу «Есть мое мнение и неправильное». Но тут уже к работнику вопрос, нахера он себя так низко ценит работая под таким руководством
2. Адекватный. Это человек знающий что нужно бизнесу и как решаются задачи. Этот человек действует профессионально и свое мнение учитывает исключительно в рамках рабочего процесса.
С первым типом я не работаю. Сразу ищу другого работодателю. А второму всегда можно пояснить какую пользу приносишь. Что сделано. Что делается. Как делается и как эффективно делается. Поясняется, что нихера непонравилось то что руководитель допустил по отношению ко мне.
Адекватный всегда поймет что к чему и извинится. Более того он подобной ситуации посторается недопустить. Максимумум что от таких людей можно услышать «Ты допустил ошибку. Она влечет за собою… Это выражается в потерю… рублей и возможностей… ». Если подобное слышишь в свой адрес, то обижаться не стоит. Не продуктивно
четверку без права пересдачи»
Если бы ученику нужен был бы красный диплом, он бы сказал «Ставьте два. Буду пересдавать»
?!
Вроде, только в МедВУЗе невозможно получить Красный Диплом имея хоть одну пятёрку.
Кроме того, студент идущий на красный диплом, где-то на пятом курсе, может пересдать несколько предметов улучшив по ним оценки.
За что ненавидить? Глупые обиды какие-то.
Преподаватели разными способами (наводящими вопросами и др.) подсказывает, но так получилось что это не помогло. В результате человек получил 4, но навсегда запомнил.
В системе тестирования или у другого преподавателя, нет решения = нет положительного результата, на пересдачу. Так лучше?
Должно быть, писавший эту авионику тоже психовал, из-за распухшего ЧСВ, когда ему указывали на совершённые ошибки.
А относительно ЧСВ и Ф-16 — если система создания ПО уязвима к ЧСП одного из членов команды — то она явно подобрана не правильно. Там где от софта зависят жизни людей — там человеческий фактор должен быть сведен к минимуму.
Тут другое — человек не знал на твердую 5, а зыбкая 5 из рук ускользнула.
А какой урок это ему дало для реальной жизни? Что любой самодур может ему испортить жизнь только потому, что он не умеет завязывать галстук?) Тут есть здравое зерно. Но такой опыт он может получить от кого угодно. Преподаватели, а тем более в ВУЗах должны учить своих учеников чему-то все-таки большему, не так ли?
А какой урок это ему дало для реальной жизни?
Очень даже замечательный урок — любой факап является факапом, вне зависимости от того, насколько, казалось бы, незначительна ошибка.
Интересно, а не ломает ли психику, факт, что в послешкольной жизни твои оценки никому не нужны?
Советую почитать (всем лайкнувшим в т.ч.) про «право на ошибку» и его влияние на не зрелую психику, тема хорошо изученная.
Человек — студент, какая незрелая психика? Хватит уже этого инфантилизма. Он к реальной работе готовится, к ответственности, а не в детский сад пришел.
Лично мне понадобилось 25.
Я в начале 90-х поступал уже зная кем я хочу стать и чем заниматься по окончании ВУЗа.
Я в начале 90-х поступал уже зная кем я хочу стать и чем заниматься по окончании ВУЗа.
Из моих знакомых те, кто работает по первой вышке — исключения.
Все больше вторая вышка стала призванием.
Или вообще вышка и профессия не связаны.
А в вузы все поступали просто от армии откосить в основном, так как ни проф.
Ну так и следовало бы их всех отчислить.
Человек зреет после 30.
Кое-кто 2 тысячи лет назад уже и учение свое создал, и проповедовал по всей стране, и раскрутился, так что власти испугались, и был казнен всего-то в 33 года.
И в те времена это не было особо удивительным (удивительным является только степень распространенности его учения и как оно прошло через тысячелетия). Мужчина тогда считался мужчиной в 15.
А современные люди — какое там учение, они, оказывается, после 30 дозревают еще (как вино, что ли)
P.S.:
А если серьезно — то да, современные люди более инфантильны (можно почитать про особенности поколения Y).
Но раз на раз не приходится. Всех грести под одну гребенку — некорректно.
У меня есть знакомые: одна уехала из родительского дома в 15 лет учиться и с тех пор живет самостоятельно, обеспечивает родителей; другая уехала в 18 и родители вообще не помогали и не помогают (у них конфликт), моталась по съемным квартирам, как-то зарабатывала сама; другая в 40 лет сидит на шее у родителей, не работала и не работает (здорова, с вышкой), полагаю, и не будет (родители не олигархи, обычные).
А так — как-то несерьезно сравнивать чисто биологическое взросление из древности (мужчина и сейчас в 15 может и детей заделать, и по физическим габаритам не кардинально отличается от взрослого) и более сложное социальное и профессиональное взросление. Вроде как Моцарт прославившийся еще подростком как композитор и тогда считался гением и скорее исключением, чем правилом, а в основном реального профессионально зрелыми люди и тогда становились после 20 (учебу никто не отменял же), думаю, часто сильно после.
А если вы не хотите грести под одну гребенку — зачем вы идете за дипломом государственного образца? Ведь это фактически и есть гребенка, учащийся ее добровольно выбрал, а потом начинается «я особенный». Особенный — не иди в универ, сам себе диплом выпиши, какие проблемы :)
Человек зреет после 30. Задолго после первой работы, первой жены и первого ребенка. А студенты — дети.
Кек, ну тогда пускай учится до 35 а потом уже работу ищет что ли?
Зачем безответственный незрелый человек на работе нужон и кому?
Конечно каждый ученик — личность и выполняет задание не как другой. И вы могли-бы подумать что 5 это 100% идеальное знание предмета в стиле Бетмена, но это не так. 5 это примерно 80% и более усвоения материалов и навыков.
На практике обычно 5 обозначает — «ученик понял суть предмета и его принципы», а не стал матерым специализстом за пол года с набитой рукой. Например на вопрос «чем прямое преобразование Фурье отличается от обратного», отличник ответит «Прямое преобразует сигнал в спектр, а обратное по спектру восстанавливает сигнал.» А хорошист начнет цитировать определение сначала первого, потом второго. Т.е. хорошист запомнил, выполнил все что нужно было, но ни чего не понял, «вы хотели чтоб я это знал — я знаю». А троечник как хорошист, но не смог все запомнить. НО это грубо и мое мнение, министерство расписывает лучше.
хорошист запомнил, выполнил все что нужно было, но ни чего не понялЧестно говоря на мой взгляд это какой-то мутный хорошист. Но таки да, это тоже мое, вполне вероятно неверное мнение. Я действительно считаю что 5 — это прям как Бетмен. Просто на мой взгляд сейчас оценки в целом воспринимаются слегка странно. Что-то типа двойка это не «плохо», а просто отсутствие знаний, тройка — ну где то-там что-то есть, четверка — половину материала выучил. Все остальное — пять. На мой вкус при этом пятерка несколько обесценивается. Хотя конечно все зависит от конкретных мест, и это также мое субъективное мнение.
Те кто хотят найти юного Бетмена — те смотрят на вне дипломные титулы, всякие участия в олимпиадах, хакатонах и прочем. Задача обычного образования — давать обычных специалистов, не брильянты и не Бетмены, просто обычных нормальных инженеров.
Посему для меня 4 — это как плевок в лицо и факт профнепригодности. Осилить элементарную программу стандартного государственного курса — не сложно. И т.к. я учился по собственному желанию, сам выбирал направление и ВУЗ — для меня было очень важно пройти обучение полноценно. Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
А насчет 2 — ну в университете это значит что ты идешь в армию. А вот 3 — это считает нормальная оценка для «стоящих в очереди за дипломом». Посему получить 3 это ваще жутко стыдно для меня, это как напиться по молодости и попасть в таком состоянии в телевизор, и потом всю жизнь тебя будет так вспоминать при каждом трудоустройстве (при условии что диплом смотрят).
Кстати в локальных контора — на дипломы у нас смотрят и на ту его часть где есть оценки. Но только у молодых специалистов, потому уже опыт, портфолио и так далее. А вот первые несколько лет — банально больше не почем судить человека. Даже если он отлично прошел собеседование и написал тестовое — это не полное покрытие важных качеств личности. Нужно же понимать насколько он стабилен. Проработает ли он год или месяц или пока ты его не уволишь? Будет ли он легко осваивать новые технологии или будет жестко навязывать привычные себе и сопротивляться всему остальному?
Из рассказов про иностранные ВУЗы — там важность оценок намного выше. Там получается соревновательный принцип везде. Т.е. программа не фиксированная, есть разные преподаватели по каждому предмету, и разные предметы на выбор. И если ты хочешь попасть к лучшим преподам и на самые интересные курсы — у тебя должен быть высоких бал за прошлый семестр. В итоге если отличник и старается — то он реально учился в Гарварде, а если троечник, то ходя в тот же Гарвард — учился у всяких аспирантов, и ни чем не лучше «местного колледжа».
Если брать всякие курсы и сертификаты — то там два состояния — сдал или не сдал, дали или не дали. Фактически 2 и 5. А что такое 4? Пол сертификата? Полу специалист?
Если брать политику бесплатного и платного образования. Если у тебя бал 4.75 и выше — тебя госво поощряет гривной. Если у тебя бал 4 и выше — то ты имеешь право получить образование бесплатно. А если ниже 4 — это значит что фактически государство считает что с тебя не будет ни какого толку, ты бесполезно тратишь свое время на этой специальности, но ты имеешь право — плати деньги и ходи. Вопрос насколько этично продавать дипломы, а выдавать дипломы тем у кого средний бал даже 4.0 — это фактически продать бумажку, «не специалисту», которому это дело не интересно и который знаний не имеет. Я считаю — не этично, кто-то считает что это либерально и финансово выгодно, троечники — содержат отличников.
5 это значит — годный студент фактически, интересуется предметом, интересуется учебой.
На практике у каждого преподавателя свое мнение о семантике оценок и его надо просто принимать. У меня например у преподавателя по матану было мнение из разряда канонического "на 5 знает господь бог, на 4 — я, а вы — на все остальное", с-но иногда никто из потока не мог сдать с первого раза хотя бы на 3 :)
0xd34df00d Единичные оценки — не важны для анализа. По ним систему не построишь. Не вы первый, не вы последний, вступивший в конфликт с преподом. Думаю все это понимают.
ApeCoder я вроде так и написал. Оценивать нужно не знание фактов, и преподы оценивают не знание фактов. На одном экзамене у меня было вообще так. Я пришел тянуть билет, препод взял методичку(которую я не видел до этого), открыл на рандомной странице, показал схему ака ПИД регулятор, но звеньев было больше. Тыкнул в один из них и спрашивает — зачем он здесь. Я ответил буквально в 7 слов — получил 5 и ушел. Хотя мне рассказывали что он жутко валит и так далее. На самом деле ему было плевать на точность заученных определений, а «большинство» этого не понимало. Они старались вызубрить как можно точнее.
Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
Это подразумевает, что оцениваетя именно понимание, а не знание кучи фактов, и информацию можно получить только прослушав какой-то курс в университете.
Им обоим ставить отлично?
Именно так, если преподаватель уверен что и тот и другой знают предмет на отлично. А это у нас в «Дано». А если вдруг препод засомневался, просто посадил бы «затупившего»на 5-10 минут собраться с мыслями. Тот бы успокоился и ответил, или не ответил если он действительно не знает. Вот и все.
В вузе уже обычно относительно взрослые и понимающие, чего они хотят, люди.
В российском-то, т.е. сразу после школы? Ну-ну.
Я когда 18 лет назад писал «олимпиадную» как бы предварительно вступительную работу по математике в МГУ решил 5 задач из 6ти.
В одной чуток налажал. Сложная стереометрия, я рассмотрел 3 случая из 4х. 4ый вырожден, но я не написал об этом. Ок. Минус.
Но другая задача… До сих пор обидно. Две страницы вычислений и в конце:
… = 8+6 = 10
Ответ: 10
И минус за задачу. 3 за работу — не прошел. Правильный ответ был 14.
Так что пришлось поступать летом.
PS. Еще. Более эпичесский фейл. Сдавал ГосЭкзамен. Где то в ходе одного доп. вопроса нарисовал касательную и доответил на вопрос. А экзаменатор такой: «Ну, хорошо. Это вы знаете. Давайте напоследок выведете мне уравнение касательной и закончим на этом.».
Я такой радостный — 5 за Гос уже у меня, что там эта касательная, я ее в 10 классе мог вывести. И… ступор. Не выводится. Так порисовал — не выводится.
Эдак попробовал — фигня получается(я ж помню формулу!).
Результат — 4 по госу из-за этой касательной. Вышел — все вывелось устно.
Сейчас такое было бы плюсом с точкой.
Даже не знаю как к этому относиться.
Хотя… если одновременно усложнить задачи, то думаю и норм.
Не все можно вывести. А забывать могут все, причем понимание есть, а слов нет судя и по случаю с Савватеевым. Это нормально.
Я в лекциях Савватеева наблюдал момент, когда по ходу лекции он забыл формулу нахождения корней квадратного уравнения (а это д.ф.-м.н. между прочим). Он слегка смутился, но тут же ее вывел и доказал.
Я вы часом не помните название? Может, сохранили ссылку, буду весьма признателен.
На самом деле пример не совсем честный, т.к. вывод формулы корней квадратного уравнения — не какой-то особый, это техника, которая очень много где применяется. Если бы вопрос был какой-то специфичный, он бы вполне мог и залипнуть. Например, я сомневаюсь, что можно так быстро оп! и вывести формулы Кардано, если их не помнить или не помнить соответствующую базу (например прям как раз недельку назад теорию Галуа повторил, кек).
(offtop 25 минут на редактирование комментария; видно я что-то пропустил, но это круто).
Для формулы кардано не нужна теория Галуа.
Не нужна, но если вы накануне повторяли теорию Галуа, то, скорее всего, сможете сами получить вывод формул Кардано, не зная его наперед.
В Википедии вывод достаточно простой и специфических знаний не требует.
Открытие сейфа тоже не требует специфических знаний — это ведь не сложно, влево-вправо крутить :)
Смысл в том что в случае формул Кардано вывод не строится на использовании каких-то известных и общеприменимых методов, он выглядит как: "сделаем хитрое преобразование, потом еще одно, потом хитрую замену, и еще хитрое преобразования — и получим формулу!".
И вот эти преобразования взять неоткуда, они не являются типовыми. Именно по этой причине они и появились на несколько тысяч лет позже, чем формулы для квадратных :)
на небольшое время «забыть»
Я не очень представляю, как Senior JS разработчик может забыть, что такое замыкание)
По себе сужу, у меня опыта в программировании больше 20 лет и, но скажем, над определением переменной я вполне могу задуматься. А дальше зависит от того, чего хочет собеседующий, если его устроит объяснение на пальцах расскажу, в этот момент может всплыть какое нибудь определение которое я на заре карьеры мельком прочитал, если же вопрошающий явно пытается меня на чём то подловить… диалога не получится.
В отрасли достаточно товарищей с хорошо подвешенным языком, которые умеют отвечать на неожиданные вопросы, и не умеют работать. И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
Я бы сказал, при прочих равных, это слабый знак, если человек решил тестовое задание, ответил на много вопросов, и слился на одном, этот вопрос не должен быть последним.
Опять вы впадаете в крайность. Зачем?
И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
Если человек решил тестовое задание без наблюдения и слился на элементарном вопросе, то с высокой вероятностью его делал кто-то другой. Весомая причина дальше испытывать собеседуемого на других базовых вопросах.
С таким не сталкивался. Впрочем, есть же испытательный срок, и по крайней мере у нас решение о найме принимается коллегиально.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
Разница есть, по моему скромному опыту, выполнение задач в хорошем качестве и то, насколько хорошо у человека подвешен язык коррелирует слабо. Может конечно, нужно джедаем найма быть, но по мне проверить человека «в бою» надёжнее.
есть же испытательный срок
А если у вас уже есть на примете несколько человек без таких сомнительных историй? Нельзя всех взять вне штата, а потом устраивать чемпионат на вылетание.
выполнение задач в хорошем качестве и то, насколько хорошо у человека подвешен язык коррелирует слабо
Если у человека есть знания, но нет возможности это выразить, то как он с командой общаться будет? С заказчиком?
А если кандидат говорливый, то проверить его как раз проще. Хорошие говоруны, кмк, проходят из-за недостатков интервьюера.
Нельзя всех взять вне штата, а потом устраивать чемпионат на вылетание.
В комментарии ниже этот момент затронул.
Если у человека есть знания, но нет возможности это выразить, то как он с командой общаться будет? С заказчиком?
Вопервых сам человек привыкает, потом команда тоже к человеку привыкает. Заказчик, конечно, не виноват, но это вопрос уже к руководству фирмы, а не к работнику.
А если кандидат говорливый, то проверить его как раз проще. Хорошие говоруны, кмк, проходят из-за недостатков интервьюера.
Мой хороший друг в таких случаях обычно отвечает, что все мы немного лошади. В том смысле, что никто не идеален.
Можно спорить о подходах к интервью. Думаю что подход, когда человека на интервью спецом заваливают, имеет право на жизнь. Например при найме в какой нибудь отдел продаж. В случае с программистами работающими с прикладными задачами, думаю он не тех людей пропустит.
Может конечно, нужно джедаем найма быть, но по мне проверить человека «в бою» надёжнее.
Надёжнее, но намного дороже в случае его неуспеха.
А дальше каждая компания для себя решает, какую цену она готова доплатить за сокращение false negatives при найме.
Разница между прибавит и убавит существенная. Т.к. при очередном раунде найма, мы второго пригласим.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
Но именно прибавит тому кто ответил, а не убавит баллов у второго.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
А тут мы упираемся в эффект Даннинга — Крюгера. Особенно если проведение интервью это не основная работа, а то, что приходится делать время от времени.
Мне кажется, мы с вами примерно про одно говорим.
но не знать назубок его академического определения
Зачем вы говорите об академическом определении? Зачем вы возводите в абсолют мои слова? Я нигде не говорил об определении. Я говорил вообще о понятии. Вы можете представить, что человек забыл, что такое переменная? Не забыл ее определение, а вообще забыл, что такое переменная. Вы ему говорите слово «переменная», а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
> а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
Например он недавно из института и привык к преподавателям, которые требуют определение в соответствии «с тем самым учебником».
Вопрос в дальнейшей реакции вас, как интервьюера.
Несогласным хочу напомнить, что влияние контекста достаточно известная вещь в психологии, а человеческое мышление работает на ассоциациях, и без соответствующих ассоциаций можно не сразу вспомнить то, что нужно.
А Senior мог на предыдущей работе называть это исключительно словом "closure", и потому в данный момент слово "замыкание" у него ассоциируется в первую очередь с электричеством, и он может замяться на какое-то время, вспоминая правильное значение.
На мой взгляд есть 2 категории людей, с хорошей памятью на определения и с плохой, так вот у меня куча знакомых из первой категории и они просто не способны понять как это — забыть то что "учил", они распостраняют свой личный опыт на всех окружающих без права поставить его под сомнение. Но у другой части обычно есть приемущество (возможно вынужденное изза плохой памяти) в части логики.
Возможно были во второй, возможно не были. Чтобы понять нужен опыт, если вы сегодня можете выучить стих наизусть за час а завтра только помнить о чём он в общих чертах, то это одно, если вы не помните его один раз прочитав — это другое.
p.s. у меня ребёнок пример фантастической (по моим меркам) памяти, ему один-два раза читаешь стих на пару страниц, и он без проблем его рассказывает через день :)
Для меня вы из категории не понимающих как такое возможно.
Уточню, когда вам говорят а расскажите про "название" вы просто не помните про что оно :)
p.s. и да уточнить не проблема, проблема в том что вторая сторона делает однозначный вывод руководствуясь своим опытом и верой в то что если не может сходу ответить то не знает.
проблема в том что вторая сторона делает однозначный вывод руководствуясь своим опытом и верой
А вы, как первая сторона, на чем основывались, делая этот вывод?
Уточню, когда вам говорят а расскажите про «название» вы просто не помните про что оно :)
Тут нюанс же есть, в направлении вопроса. Спрашивают же не «как называется вот эта красная лопата по-научному», а «как выглядит пожарная лопата».
«Не вспомнить» простительно для первого варианта. Человек отлично пользуется пожарной лопатой, но чутка подзабыл, что ее положено называть «пожарной», тупо забыл слово — ничего страшного, главное, что пользоваться умеет.
А во втором варианте… Кхм, это не «подзабыл слово», а просто «не может с ходу вспомнить, как оно выглядит». Вот это тревожный звоночек же.
Как бы, вспомните правильный термин, подходящий под определение — это да, вопросы не для собеседования, а, скорее, для кроссворда. А вот «объясните термин» — вроде, норм.
И еще, мне кажется что если вы волнуетесь на собеседованиях, то вам еще рано называться senior :)
Если ситуация повторилась не один раз, да еще и подряд, то возможно надо что-то в консерватории поправить.
У меня в «трудовой» есть запись о том что меня уволили во время испытательного срока. И ничего страшного в этом не вижу. С радостью рассказываю какие работодатели бывают чудаки.
Таки да. Всегда путал по номерам законы Ньютона...
В какой-то мере виновато школьное образование, когда в большинстве случаев «отличником» будет тот, кто тупо запоминает дату битвы при Бородино, или вызубрит наизусть стих Пушкина, без понимания что там за настроения были в Европе при Наполеоне и что за личность была у Александра Сергеевича. Культ карго во всей красе.
Думаю, если бы вы более внятно изложили свою мысль (развернули, чем вам так понравился коммент и почему, а не просто тыкнули +1), то вас бы не минусовали.
В школе я сначала жутко разочаровалась в истории. Моя мама историк и она мне всегда очень интересно умела рассказывать про взаимосвязи событий (а даты она сама плохо запоминает), про исторических личностей. Я ожидала от школы чего-то в этом духе, но мы просто переписывали параграф в таблички. С моим представлением о том, что историю нельзя упихнуть в эти таблички, было тяжко. В старших классах плюнула на таблички и сдавала вместо них эссе. Учительница пару раз писала замечания, но в целом была довольна тем, что как раз понимание есть, поощряла доклады, рефераты и эссе, в которых видно, что ученики думали головой, а не переписывали учебник или википедию.
А вот в университете опять все свелось к заучиванию дат, а мой реферат про народное ополчение 1812 года (с использованием источников из архивов, с чем вряд ли на факультете ИТ кто-то сильно заморачивался) был жутко раскритикован за то, что я не упомянула в нем кого-то из партизан, хотя это вообще разные вещи. А экзамен свелся к распечатке методички для кафедры.
Но в принципе согласен. Знание того, какая именно полубригада штурмовала южные флеши в 8 утра 26 августа — информация для массового обучения лишняя. Важно что в этом бою сражалась буржуазная армия объединенной Европы с феодальной армией РИ и что в его итоге понесла поражение (стратегическое, а не тактическое). И то, что не смотря на поражение в войне буржуазная идея спустя 200 лет цветет и пахнет.
Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта
Замыкание — это такой базис, что более подходящий пример, что 2×2 — это термин «умножение». Может ли математик забыть термин «умножение»? Для этого необходимо зубрить?
Может ли математик забыть термин «умножение»
А программист?
Для математика аналогом «замыкания», скорее, будут термины: «поле», «кольцо» и т.д.
А если спросить у Senior-математика. Он должен знать ответ на этот вопрос? Или тоже может забыть?
этом не задумываясь применяя эти свойства на практике.
Помнить формулировку из учебника и уметь применять — не одно и тоже.
senior-математик знает об этой простой операции столько
Так какой ответ вы ожидаете от человека, который пришел на собеседование на позицию «senior-математик»?
Вы ожидаете, что он расскажет, что такое умножение, расскажет свойства, поля, кольца и все остальное?
Или ожидаете, что он скажет в духе автора статьи: «ну чо вы прицепились с определениями? я может и пользовался, но термин такой забыл»
Возможно не стоит ожидать такого развернутого ответа на такой вопрос, но однозначно стоит ожидать его в случае наводящих вопросов в стиле «а всегда ли существует обратный элемент?».
«Забыл точное слово» — это не вспомнить термин «коммутативность», и это может произойти от волнения и пофиг вообще чего. Не ответить «что такое коммутативность» для «сеньор-математика» непозволительно.
Только если умножение коммутативно в этой структуре.
Вы можете перестать подозревать меня в самозванстве и начать лучше собеседовать? Я senior-алгебраист, а вы у меня определения базовых терминов (о которых я уже забыл) спрашиваете.
x*0 = x*(1-1) = x — x = 0
Алгебраист гарантированно должен. Любитель теорий типов, наверное, тоже. Матстатистик совершенно не обязан.
Но вы же согласны, что ни один из них на вопрос «что такое коммутативность» не может сказать «да я все это знаю, только слово подзабыл»?)
Я утверждаю, что степень «элементарности» и «фундаментальности» терминов «умножение» для математики и «замыкание» для программирования различается на порядок. Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно. Заниматься математикой без умножения и знания этого термина — нельзя.
А вы мне возражаете так, будто я сказал, что это вещи одного порядка, но обе — не важны. Предлагаю вам внимательнее читать аргументацию прежде чем выдвигать абсурдные контр-аргументы на то, чего ваш оппонент не утверждал.
Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно.
Но только не на «сеньорской» должности.
habr.com/company/oleg-bunin/blog/424393/#comment_19174213Можете, пожалуйста, пояснить про проблемы?
0xd34df00d
Полнота по Тьюрингу не является чем-то заведомо хорошим. Например, полные по Тьюрингу системы типов имеют очевидные проблемы.
И привести пример полной по Тьюрингу системы типов (не очень себе представляю, что это по отношению к типам).
Хотя, на самом деле, «замыкание» — это всего-навсего частный (пусть и иллюстративный) пример. А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
Да и, собственно, как таковой сеньор, все же, должен знать хотя бы парочку языков, иметь опыт применения и некоторую экспертизу в сравнении. В конце концов, язык программирования — всего лишь инструмент. Мне, почему то, кажется, что сеньора, настоящего сеньора, отличает, в том числе, и умение выбрать наиболее подходящий под задачу инструмент.
Сеньор должен знать практики, паттерны, какие-то концепции за пределами устаканившихся в его экосистеме вещей, вероятно. Наработка практик в узкой специализации — это вопрос опыта, доступный миддлу. Мне кажется, что сеньор от миддла должен отличаться, например, знанием, в каких случаях от этих самых «лучших практик» можно отойти. Иначе чем он от миддла отличается?
А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
В контексте беседы целиком обсуждается а) может ли C#-сеньор не знать о виртуальном наследовании, б) может ли JS-сеньор не знать о замыканиях. Ни то, ни другое, произвольными отдельными специфическими терминами в контексте обсуждения считаться не может. Ну вот никак.
Но для этого мне нужно услышать аргументацию, чего конкретно принципиально не может сделать senior developerНе может быть senior developer.
произвольных отдельных специфических терминов.Раз за разом вы уводите в вообще другую степь.
производительность senior developerПроизводительность — единственное качество, необходимое для Senior Developer?
незнание произвольных отдельных специфических терминов.Вот тут самая главная ошибка. Не «незнание произвольных отдельных специфических терминов». А «незнание базовых концепций языка». Вот представьте, что C++ Senior Programmer забыл термин «Компиляция». Подумаешь, какой-то специфический термин. Или Java Senior Programmer забыл термин «Garbage Collector». Знание произвольных отдельных специфических терминов не нужно для senior-программиста!
Суть не в том, сможет ли сферический senior в вакууме, который не знает этих терминов выдавать результат такого же качества, как и программисты, которые знают эти термины.
Суть в том, что если на собеседование приходит человек, который утверждает, что он senior-программер, а на деле не слышал о основных концепциях его языка — возникает обоснованное сомнение в его чесности.
И таких определений в вашей голове — тысячи и десятки тысяч.
То есть у Senior C++ программиста при слове «компиляция» сразу вспоминается тысячи определений кроме того, что связано с его языком?
А Вы можете подробно рассказать как прошел ваш день ровно 5 лет и 4 месяца назад?
А вы можете сказать, кто был четвертой женщиной Александра Македонского? Хотите продолжить играть в игру «придумай глупую аналогию, которая не относится к теме»?
Дальше, Гипертимезия — вообще не в кассу, мы ведь не спрашиваем у человека, что он делал 5 лет назад. И Жамевю — тоже не в кассу. Даже дежавю встречает слишком редко (как много человек испытывают чувство дежавю именно на собеседовании? и я про настоящее дежавю, а не псевдодежавю похожих ситуаций, когда просто много собеседований сливается в одно). Так вот — Жамевю встречается еще значительно реже.
«На кончике языка» — тоже не в тему. Слово вспоминать не надо, его тебе называют. К примеру, «Компиляция». Вот и все «на кончике языка» уже не подходит.
Сколько вам нужно привести ссылок, чтоб донести простую мысль — иногда у людей из головы вылетает самое очевидное?
Ну, очевидно, больше нуля ссылок по теме. А то я тоже могу так накидать. Первая, вторая, третья. Видите, сколько я вам уже ссылок накидал, которые доказывают, что вы — неправы?
Хотя пару часов назад это определение от зубов само отскакивало
Та при чем здесь определение? Никогда никогда не требует книжного определения, не впадайте в крайности. Если у человека есть понимание, то он не забудет слово. Проблемы на экзаменах именно из-за зазубривания. Простите, но человек, который называется сеньйором я который не понимает, а зазубривает определения базовых терминов — не нужен команде
Чего уж говорить о том, что человек может знать, но редко использует ибо банально ему это конкретно было в явном виде не нужно (не про компиляцию, а про пример из статьи).
Для Senior JS Developer незнание понятия «Замыкание» недопустимо. По моему мнению, как и незнание понятия virtual для Senior C#-девелопера. Увы, я в этом языке далеко не senior, но я так считаю.
Надёжно помнят это не те, кто зазубривает, а те, кто это всё своими руками прощупал, осознал, проанализировал, покрутил в разных вариантах и в мозг положил в рабочий арсенал. То есть хорошие программисты.
Хороший программист — это в первую очередь тот, кто все это благополучно забудет, если не использовал сколько-нибудь продолжительное время. Допустим, замыкания в принципе — они теперь везде, тут забыть сложно, но к чему помнить особенности того, как в js работает this в замыканиях, если уже год на js не пишешь? Да ни к чему, это не знания — это мусор. А мусор надо убирать.
На мой взгляд это ошибочное утверждение, вы можете понять как работает, но не связать название с механизмом.
что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта
Нет, она называется уравнением Пауссона. Закон Бойля-Мариотта описывает изобарный процесс. Пара минут Гугла;)
Так вот термин — это факт, который ни с чем не связан, это просто название, которое нельзя «вывести», его можно только запомнить. Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта.
Вот тут стоит признать, что вопрос был «что такое <термин>», а не «каким термином называется вот это». И вот тут ситуация начинает играть другими красками. Не «как называется формула, описывающая термодинамический процесс и т.д.», а «в чем суть закона Бойля-Мариотта». Разные несколько вопросы, не правда ли?
а «в чем суть закона Бойля-Мариотта». Разные несколько вопросы, не правда ли?
Да одно и то же, можно прекрасно помнить закон и уметь его применять, но при этом в упор не помнить, что он Бойля-Мариотта. Любой человек, который матфак окончил, знает на подкорке кучу всяких лемм/теорем из первого курса матана, на уровне формулировки фактов и даже доказательства вам накидает. Но сомневаюсь, что вспомнит хотя бы для половины названия, или саму формулировку по названию. Вот если вы скажите о чем там в общем, другое дело.
Поди со стороны разгляди.
Но. Представьте себя работодателем, и к вам раз за разом идут претенденты не выдерживающие затем испытательный срок.
А это ваши расходы и вы не меценат. Когда лопнет ваше терпение? И какие чудеса вы начнете творить на собеседованиях?
На разборе эту задачу мне засчитали как полностью решённую, потому что знать наизусть все константы — это не цель этих контрольных. Главное — умение решать задачи. А если подставить верное значение константы, то и ответ становился верным.
Мораль: да, надо смотреть со стороны. Если «не знание» — это повод что-то не делать, то это — плохо. В противном случеае, «не знание» чего-то очень *конкретного* не означанет не знание предмета/задачи.
Эйнштейн был музыкантом ;)
Длина резонатора камертона чуть меньше 20см, это четверть длины волны при частоте 440гц, длина волны чуть меньше 0.8м, скорость звука чуть меньше ~350м/с, ему бы даже смотреть не пришлось :)
Ну не может сеньор не знатьЭта фраза выглядит вполне правдивой в её тяжкой непреклонности, если бы не одно но. Что значит "не знать"?
В моём понимании не знать чего-то, например не знать как, допустим, варить железо, это если человека оставить одного в комнате со сварочным аппаратом и заготовкой, хоть через час хоть через день он не сможет её сварить, хоть убей. А если и сможет, то очень криво и непрочно. Проще говоря: не справится с задачей. Он не готов к трудоустройству на должность
А если автора оставить одного с чужим кодом в котором есть ключевое слово virtual и попросить код модифицировать согласно таске, он справится или нет? Я думаю ему и дня не понадобится, да что там, и часа. Даже если он запамятовал, 20-гуглинг с чтением коммента на стэковерфлоу заставит его хлопнуть по лбу «ах да, я же встречался с этим» и приступить к решению задачи. Думаю 20 секунд рабочего времени для начальника этого разработчика не такая уж большая цена за незнание?
Так ли сурово можно продолжать считать такого разработчика непригодным к работе сеньор сварщика кода?
Даже если он запамятовал, 20-гуглинг с чтением коммента на стэковерфлоу заставит его хлопнуть по лбу «ах да, я же встречался с этим» и приступить к решению задачи.
Если разработчик не вспомнил сам вполне себе базовую механику языка, вероятно, он именно «встречался» с этим, и уж точно не использует эту механику на регулярной основе. А это, при наличии уже существующего, вероятно, достаточно большого проекта, где виртуальное наследование во все поля применяется, кхм… ну, чревато, как бы. Вопрос именно что не в том, знаете ли вы этот термин, а в том, что, имей вы практику применения (а она реально важнее знания терминологии), вы бы вряд ли забыли, что означает вполне себе конкретное ключевое слово в языке.
В общем и целом, ваше «а вот virtual я не помню» говорит, с очень большой долей вероятности, о том, что лично вы его не применяете. С учетом специфики существующего кода вместо сеньор-разработчика, который будет выполнять поставленные задачи, вполне можно получить саботера, который будет вместо работы убеждать джунов/миддлов в том, что «виртуальное наследование — зло», и «за композицией будущее». Ну, либо человека с сеньорской зарплатой и отдачей на уровне миддла…
Вы же, предположительно, еще и в команде работать будете. Сеньоров, обычно, в вакуум не берут. Вам же еще и коммуникативные навыки понадобятся. Да и предполагается, что рядом могут сидеть миддлы или, простихоспади, джуны, которые за советом, в случае чего, пойдут, вероятно, к сеньору. Так ведь? Придет вот эдакий джун к вам-сеньору, и скажет, я тут виртуальное наследование намутил, а что-то не работает, помоги разобраться. А ты сидишь, эдакий сеньор-
А в цепочке обсуждения до поста, да и в исходной публикации описана ситуация, когда весь такой крутой «сеньор» ответил на «стопицот» коварных вопросов хамоватого собеседователя, а на вопрос «что такое virtual» ответить не смог, т.к. он «позабыл слово» и «вообще наследование зло, а в компании ничего не понимают». В итоге, типа, «крутого профессионала» отсеяли на собеседовании просто потому, что он «подзабыл слово».
Ну ведь чушь же. Человек просто сам завалил собес, перевернул с ног на голову, и теперь пришел пожаловаться на «некомпетентность собеседующего».
но даже для миддла не объяснить смысл этой механики на собеседовании
Ну не об этом же разговор. Разговор о том, что человек не связал слово "виртуал" с известной ему механикой.
Чтобы "не объяснить смысл механики" надо чтобы обе стороны поняли, про какую именно механику задан вопрос.
Прямо из статьи:
Senior full-stack .NET Developer
Что такое virtual?
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
надо чтобы обе стороны поняли, про какую именно механику задан вопрос
Вы искренне считаете, что на собеседовании по C# есть место двум разным пониманиям базового синтаксиса одного и того же языка? Т.е. собеседующий подразумевает, мол virtual void methodName(), а собеседующийся настолько заметался в выборе возможных для контекста беседы толкованиях virtual, что аж ни одного сформулировать не смог?
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Гражданин упирает на то, что не использует наследование.
Он же, вроде, по специфике «сеньорства» не только писать код должен, но еще и читать. При этом не только свой — на то он и сеньор. А ключевые слова языка для него — алфавит. Вы же не станере брать ликтором человека, который «отлично весь алфавит помнит, а вот букву Ы подзабыл, но она не нужна, он все равно ее не использует».
Гражданин, претендующий на позицию сеньора в ООП-языке имеет право не использовать наследование, да.
Погодите, погодите! А интерфейсы он тоже не использует? Ведь вызов реализованного метода интерфейса — он тоже виртуальный.
Тут стоить отметить что хоть и не по моей это специальности, но в первых двух вариантах я бы скорее всего правильно связал понятие со смыслом, а вот в последнем была бы вероятность что затупил бы.
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Не совсем. Человек в нестандартной ситуации, когда внимание отвлекается различными психологическими и информационными факторами, за отведенные ему несколько секунд не связал слово, произнесенное вслух звуками "виртуал", с известной ему механикой, которой он редко пользуется. Не успел выбрать из всего набора существующих в C# механик ассоциацию с переопределением метода. То, что он знаком с наследованием, следует из правильного ответа на вопрос "что такое protected internal".
Такими вопросами можно проверить только быстроту ассоциаций. Чтобы проверить умение пользоваться, надо дать задачу или попросить привести пример. Если на вопрос "Приведите пример переопределения метода в наследнике" человек напишет код со словом "virtual", значит он знает, зачем оно нужно, даже если его нет в вопросе.
Если на вопрос «Приведите пример переопределения метода в наследнике» человек напишет код со словом «virtual», значит он знает, зачем оно нужно, даже если его нет в вопросе.
Возьмём для примера C++. А если он переопределит метод без слова virtual, будет ли это значить, что он его не знает/не умеет использовать?
Зачем брать C++, если разговор про C#, и пример будет на нем? Давайте тогда PHP возьмем, там на virtual вообще ошибка синтаксиса будет.
Хорошо, пусть будет C#. Вам это уйти от вопроса всё равно не позволит.
Сам вопрос:
А если он переопределит метод без слов virtual/override, будет ли это значить, что он их не знает/не умеет использовать?
А я и не позиционирую себя как 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++-программиста тоже бы не взял :(
В C# метод в производном классе может иметь то же имя, что и метод в базовом классе. Можно задать способ взаимодействия методов, воспользовавшись ключевыми словами new и override. Модификатор override разворачивает метод базового класса, а модификатор new скрывает его. В примере в этой теме показана эта разница.
Русскоязычный MSDN — та еще помойка с машинным переводом.
Что значит «разворачивание» метода? Он как бы в базовом классе был свернут, а в производном его развернули? А можно ли метод развернуть два раза? Должен ли он быть для этого дважды свернут?
Мне этот термин тоже не нравится. В плюсах всегда использовали понятие «замещает», как нам завещал Страуструп (специально удостоверился в спец. издании C++ programming language) от override. Собственно в шарпах также обычно говорим.
Я вот на всякий случай сходил и проверил — gist.github.com/retran/9f4dc4c359d8e91d163e2452a642863c
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Если вы ещё до сих пор не поняли, что произошла терминологическая путаница, то извиняюсь, но вы глупы :(
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Ещё раз я знаю и использую и new и virtual/override. И да, я не считаю это переопределением, я считаю это extends (а кто догадался вообще extends перевести как переопределить?).
Я, конечно, глупее вас, и первый раз слышу, чтобы extends употреблялось по отношению к методам в контексте наследования (и не extension method'ам, которые вообще про другое), а не классам.
UPD Я вот сейчас погуглил, нашел такую формулировку только в одной единственной статье про C# в MSDN.
Если вас интересует официальная терминология по C#, то она из шарповой документации, вы же сами ссылку на неё приводили. Откуда они придумали extends/расширяет и почему не взяли override/замещает — это к ним вопрос.
Собственно, new, вроде как, про hide метода, а не про extend. ...
И полностью с вами соглашусь.
Так как первый раз в живую слышу, что кто-то вместо замещения метода(в С++) и расширения метода (в C#) говорил об этом как общее «переопределение». Уж, со сколькими людьми общался, и за пределами рабочего коллектива (за последние 2 месяца почти 40 людей только на интервью посмотрел), все как и обычное «скрытие», да и виртуальное замещение в плюсах называют просто «переопределил». А тут на тебе…
Просто я про то говорю, что раз уж даже мне, человеку весьма постороннему, навскидку видна разница между 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» отличается. Иначе какой вы сеньор?
А приводить ссылку на статью, из которой я уже приводил цитату — это очень оригинально.
В следующий раз, прежде чем переходить на личности, потрудитесь изучить обсуждаемый вопрос. Если PHP-шник знает о C# больше вас, это повод подтянуть свои знания.
Ну как бы я пока не вижу, чтобы вы знали, что-то больше меня. Вижу, что мы говорили об одном и том же разными русскими терминами. Что для меня «переопределена» это когда функция просто переопределена (без разницы с замещением или со скрытием), а для вас этот же термин значит только тот случай, когда она замещена (от override).
И почему вообще повод? Я себя в шарпах даже джуном не считаю, я всё-таки плюсовик :) Когда есть время и возможность я и без повода что-нибудь на шарпах изучаю.
public new void MethodName() {}
Собственно, про то, видимо, и вопрос был, чем переопределение виртуального метода от перекрытия в наследнике отличается.
То, что он знаком с наследованием, следует из правильного ответа на вопрос «что такое protected internal».
А знание модификаторов доступа к членам класса, простите, каким образом свидетельствует о том, что человек знаком с понятием «наследование»?
Доступ к защищенному элементу может быть получен из соответствующего класса, а также экземплярами производных классов.
каким образом свидетельствует о том, что человек знаком с понятием «наследование»?
Из этого определения следует, что человек наслышан о понятии «наследование»
Наслышан — По слухам хорошо знаком с кем-чем-нибудь
Давайте не будем играть словами. protected связан с наследованием, это факт. Тем более что мы не знаем, насколько развернутым был ответ автора.
объяснить почему он так считает
А ему кто-то такой вопрос задавал? Автор сам пишет, что считает его более важным.
В том и дело, что такие вопросы как в статье на самом деле не показывают умение пользоваться.
Тем более что мы не знаем, насколько развернутым был ответ автора.
В том то и дело, что мы не знаем, насколько развернутым был ответ автора, можем только предполагать, что он что-то связное ответил (и где гарантия, что он не ответил заученной формулировкой с MSDN).
Что мы знаем (со слов самого автора), это то, что он «посыпался» на вопросе «Что такое virtual».
Т.е. в сухом остатке автор не смог ответить на вопрос, что такое virtual, в чем сам и признается. А это — неиллюзорный повод предположить, что в вопросе наследования автор плавает, что автоматически делает его слабым кандидатом на сеньорскую позицию.
И да, существуют программисты которые этого не знают и не понимают.
А когда на senior-позицию приходят полные нули, что делать? Знакомый фронтендер периодически собеседует людей на позицию senior-ов. Люди говорят/пишут, что у них 3-5-10 лет опыта, но они не знают концепции замыканий.
ИМХО, это очень хороший вопрос, чтобы быстро отсеять всяких неадекватов, при условии, что он задаётся не HR, и не ради самоутверждения.
К тому же, это ещё и хороший вопрос для отсеивания неадекватных работодателей: если после моего ответа начинают просить что-то там реализовать на бумажке, то начинаю задумываться, а надо ли мне тут работать.
Безусловно, когда человек занимался чем-то совсем другим, а потом меняет сферу деятельности, незнание некоторых вещей можно простить. Например, сейчас многие переходят во фронт из бэка (по крайней мере, часто собеседовал таких людей). В таком случае можно забить на неумение верстать, или незнание, например, особенностей работы промисов. Я в таких случаях просто задаю другие вопросы. В конце концов, есть есть фундамент, особенностям js обучаешься быстро.
Но когда люди вроде как много лет именно во фронтенде (и заявляют об этом чуть ли не с гордостью), и у них спрашиваешь про банальные замыкания, а они не могут ответить, то это печально.
На счет промисов — тут есть конечно нюансы, ввиду синхронности js, но мое отношение к промисам также негативное (работу кончено не пойдет искать, но прослушает двухчасовую беседу о том, как разбивать задачи на минимальные составляющие для обеспечения стабильности и прозрачности работы кода).
Но саму возможность использования промисов, в каких-то непонятных, внеземных проектах, я конечно не отрицаю. Как по мне, промисы в js придумал какой-то редкий м....., который ранее работал в глубоком бэкенде, на c++, с функциями асинхронного вызова и обработки данных без потоков, через медиаторы, в самих кодах классов.
Сидел он значит, изучал фронтенд (новое для себя дело) и встал в ступор — а почему нельзя в js через те же медиаторы и обертки событий, как было в классах на c++, обойти синхронность языка? Давай-ка я напишу это, чтобы и здесь реализовать мнимо-неблокируемый интерфейс, и назову всё это дело промисом!
А нужно-ли это во фронте?, или это создаст для работы кода еще больше проблем? — эт. дело десятое, главное мы из JS теперь сделаем крутой язык, приближающийся к бэку!
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
Т.е. в Вашем проекте на js нельзя писать на js? В нем же все функции образуют замыкания.
Теперь же бэкэнд вырос и избавился от этой шняги и такие вот горе-профи (аааа жесть просто) теперь пытаются впихнуть это старье во фронт энд, и всё по той же причине, чтобы также как и тогда в бэкэнде, обойти ограничения синхронности языка.
Но вот беда, работа кода в бэкэнде и работа его во фронтэнде, подчиняются абсолютно разным правилам и проходят очень-очень разные этапы проверок и допусков. И понятное дело, что обмен данными между мнимо-асинхронными функциями, во фронтэнде, просто теряет свой смысл из-за его слишком большой задержки (проверка ядром системы, проверка браузером, проверка анти-вирусом и прочими сторонними наблюдателями в системе).
Не пытайтесь писать на фронтэнде то, что нельзя на нем писать, притащив в него устаревшие технологии из бэкэнда! Хотите работу приложения как в бэкэнде, да млина, — пишите на бэкэнде, а фронтэнд подгружайте в виде интерфейса только, а не для работы и вычислений (не умеете так? слишком сложно для вас? — учитесь, или заказывайте у тех, кто может, но не пытайтесь городить шнягу убогую на том, на чем её не следует городить).
Тоже самое тут про 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))
Попробуйте его для начала просто переделать без промисов и замыканий. А мы посмеемся.
Весь 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) и вызывай — даже это будет в разищи быстрее и лучше, чем вызывать этот промис тормознутый и проблеммный.
Но нет, этот чудо-программер, будет бить себя пяткой в грудь, убивать машину юзеру, но не снизойдет до изучения чего-либо, а просто будет читать таких же супер-пупер профи.
запуск таймера опроса промиса для получения состояния исполнения
Ваши сообщения — это какой-то сборник анекдотов. Откуда вы взяли, что существует какой-то таймер опроса?
Кстати, приведенный вами код не работает.
На счет не работает — откуда мне знать, что вы там вызываете своими объектами.
Запишите обработчик для проверки так, чтобы узнать в консоли работает или нет:
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
— вполне себе.
функцию определенную в глобальном объекте
Тут вы крайне странно сформулировали.
Там не все так просто, как кажется на первый взгляд. Вот к примеру, вы говорите «пока не выйдет на функцию определенную в глобальном объекте. А в глобальном объекте есть свойство 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 и становится ли такой вообще (или обрабатывается как исключение) в документации я не нашел(
Суть ошибки замыкания в JS, что в нем нет типизированного вызова и обращения к свойствам объекта и к просто переменным. Сам интерпретатор решает к чему именно вы обращаетесь.
Вот вы указали базовый пример из справочника, и тут именно наглядно видно это. В момент, когда вы создали глобальный объект var myFunc = makeFunc… отработала внутренняя функция displayName создав замыкание и глобальный объект myFunc получил свойство name (в обычном языке myFunc->name).
Всё, функции makeFunc и displayName отработали, и все их внутренние переменные должны быть очищены, это везде так (и в JS это тоже так).
Но, в js, (так, как все функции являются объектами — гвоздь им в голову сразу и по шляпку) когда вы снова, после окончания работы функций пытаетесь обратиться к переменной name, интерпретатор, не имея типизации обращения, видит, что такое свойство есть у ныне существующего глобального объекта myFunc, а значит, вы, скорее-всего, к нему обращаетесь — он вам и возвращает это свойство этого объекта, и складывается впечатление, что якобы существует сама переменная name в памяти, после окончания работы функций.
Вот именно это и является проблемой — можно так дозамыкаться, что ПК пользователя просто перестанет отвечать на запросы. А также черт его знает в каком месте у вас нахлестнутся имена свойств объектов после замыкания и имена глобальных переменных, что приведет просто к разрыву башки при отладке такого кода. Вот поэтому, я жестко караю любого, за любую попытку этого х… кода в js, кто сознательно пытается использовать этот баг в js.
И именно поэтому, каждый раз когда новая команда разработчиков (и не важно, номральная-ли команда, или команда чудо-разрабО) приходят к клиенту, чтобы расширить (или исправить) код, который был написан до этого такими вот чудо-разрабами, нет никакого шанса разобрать этот дивный код. Поэтому, всегда все начинают писать всё с нуля. Клиент, которому попадаются такие чудо-разрабы, постоянно попадает на деньги и на время, и из-за этого у него складывается негативное впечатление о работе отрасли программирования в целом. И всё это из-за таких вот чудо-программеров, как b00taNik, которые считают себя программистами.
Вот мой код и код таких как я, сможет прийти и продолжить, или изменить, любая новая команда у клиента (и не важно нормальная ли команда, или команда чудо-разрабов). Им потребуется минимальное время, чтобы понять структуру кода и начать его исправлять, или дополнять. Никаких неявных петель и ловушек вроде таких вот чудо-замыканий, они не получат в моем коде, я даже никогда не делаю дубли в именовании явно-объявляемых переменных внутри функций, не говоря уже о том, чтобы произошел нахлест в глобальной области видимости.
А что касается кода — начните с того, что вы обещали показать код без замыканий и работающий. Где он в итоге то?
На курсы — запишитесь при любом университете технической направленности (а то я как закончил Универ радиотехнический по направлению автоматизация и управление, так и программирую после этого и учусь не в википедии, а по документации к языкам и аппаратным комплексам).
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
А теперь вопрос супер-пупер программисту википедийному, eH001 — определена где? Внутри функции какой то? ИЛи на глобальном уровне вне окружения функций?
Жесть, и вот такое чудо-разрабо, программистом работает, жесть просто — где работаете? Надо вашему нанимателю линк скинуть на ваши комменты здесь, чтобы он понял кто у него работает.
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
Не могли бы вы сослаться на книгу, где вы это услышали, раз википедия не источник, хотелось бы тоже ознакомиться с данным кладезем мудрости? Кроме того, даже если по вашему определению, console откуда берется, не из глобального ли контекста?
Ну а то, что вы учились программировать по документации к устройствам — ну так и заметно, что ваши познания в программировании недалеко от примеров из методичек :)
Понятия не имею, какие познания у вашего оппонента — для меня фронт и js страшные тёмные места, в которые я не суюсь, ибо квалификации не хватает, но у него прямо в комментарии написано, откуда он цитирует:
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
И затем первый же запрос в яндекс «mozilla closure» выводит нас на нужный сайт, где именно так и написано определение.
Спасибо за разьяснение данного момента, все ясно.
Прямо оттуда:
функции в JavaScript формируют так называемые замыкания
И именно об этом говорит b00taNik, а SemaIVVV продолжает стоять на том, что это только у неучей, а его функции в его Javascripte никаких замыканий не формируют.
fetch всего лишь обертка для XMLHTTPRequest, чтобы такие неумехи, как вы писали меньше букв, не понимая технологии запроса данных. Если вы не понимаете, как написать XMLHTTPRequest запрос с if else (и при необходимости, заюзать catch), как в вашем fetch-е — просто идите на курсы базовые по программированию что-ли.
если условный фетч, который принимает колбек:
function helloLog(x) {
console.log(x.json().hello);
}
fetch("https://www.mocky.io/v2/5185415ba171ea3a00704eed", helloLog);
Не очень хороший пример, тут не так велика разница. Вот если надо композить асинхронные действия — тут уже становится печальнее все эти helloLog-и писать :)
если условный фетч, который принимает колбек:
Каждый раз, читая такое, сначала утираю кровавые слёзы из глаз, а потом вспоминаю нетленное:
Классен Днепр при клёвой погоде, когда, кочевряжась и выпендриваясь, пилит он сквозь леса и горы клёвые воды свои. Вылупишь зенки свои, откроешь варежку — и с катушек. Редкая птица дочешет до середины Днепра, а если дочешет — так гикнется, что копыта отбросит.
А в современном JS уже есть символы и хотят ввести приватные поля.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет и никогда не программировал на языках с ООП, либо это сознательно, старая собака уже испытывает проблемы с новыми трюками.
Комментарии — это, пожалуй, самое отвратительное, что можно было придумать для выражения данной концепции. Поддержка такого кода будет адом. Если же очень нужно открыть поле наружу, но запретить публичное использование (эмуляция семантики protected-доступа из нормальных языков) — используют пре-/постфиксы для имени поля, что будет однозначной подсказкой даже в клиентском коде.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет
То есть вы настаиваете на важности модификатора private, полностью игнорируя отсутствие иногда даже более важного модификатора protected и рассуждаете о «с головой в песок»?
Опытные программисты или используют JSDoc, где есть оба модификатора или уже давно ушли в TypeScript. А «инкапсуляция через замыкания» — не более, чем костыль для новичков.
Похоже я проспал революцию, раз не вижу в сокрытии (особенно через замыкание) никакой пользы, но вижу кучу минусов. Не расскажите нам про эти преимущества?
reinterpret_cast<int*>(Foo*)
. «Это же держится на соглашениях для С++-программистов!»Если же использовать особенности конкретных реализаций, то это вновь волшебство, а не C++, потому что даже минорное обновление любого компонента компилятора может вам разломать все в самых неожиданных местах, и про котел в аду там выше не зря написано.
Чем "структура из Си" отличается от класса без виртуальных функций? Насколько я знаю, extern "C" влияет только не функции и переменные, но не на структуры.
Да и с теми же виртуальными функциями все не так сложно. Да, смещение первого поля будет implementation-spicific, но подразумеваемое поведение компилятора можно проверить тестами, по типу таких: assert(reinterpret_cast<intptr_t>(&Foo::x) == sizeof(void*));
PS про котел в аду в целом согласен — вот только, в моем понимании, нарушителей соглашения по именованию приватных полей в javascript ждет соседний котел :-)
Разница в том, где именно происходит проверка на то, что правила доступа не нарушаются, и в C++ она не происходит, потому что вы об этом просите явно очень заметной конструкцией (в Rust таковые еще заметнее), а в JS у вас и соглашение в голове, и проверка его там же, и найти таковые нарушения grep'ом просто так не получится.
А не подскажите название компании, где вы работаете? Ну чтобы сразу игнорировать предложения работы оттуда)
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
Вы понимаете, что, наверное, невозможно написать JS-код не создавая замыканий? Если вы умеете — научите меня, пожалуйста. Мне очень интересно
И то в новой nodejs уже ввели нативную подержку мультипоточности. Вам бы самому новую работу найти не помешало. :)
А когда на senior-позицию приходят полные нули, что делать? Знакомый фронтендер периодически собеседует людей на позицию senior-ов. Люди говорят/пишут, что у них 3-5-10 лет опыта, но они не знают концепции замыканий.
Программирую еще с прошлого века.
Смотрю все пишут про какие-то умные замыкания. Не знаю этого термина.
Думаю, ну наверное некая умная концепция, может, буду использовать, пригодится. Надо почитать что это.
Читаю.
Ага. Использую, не зная как оно называется, уже лет 20 или поболее даже, оказывается.
Почему? Нас учили разным математическим моделям, а вовсе не тому как что называется в синтаксисе языка.
Внимание, вопрос:
Являюсь ли я недостойным должности сеньора, если 10 последних лет как проектирую highload-решения, которые держат высокие нагрузки на смешном железе?
Охренел (25 лет за баранкой этого пылесоса, а не слышал). Почитал. Охренел второй раз — концепция понятна, но мне а) за те самые 25 лет мне не требовалась ни разу, б) можно гораздо понятнее объяснить в терминах низкого уровня (как известно, C — это по большому счёту надстройка над ассемблером/машинными кодами, на которых я с детства работал).
Есть отличная фраза — «Иногда 10 лет опыта — это один год, повторенный 10 раз».
В твоём случае это было 25 раз, только и всего.
В твоём случае
Не подскажете, когда мы с Вами на брудершафт пили? А то я запамятовал.
Повторяю: концепция мне знакома, но никогда не возникало необходимости её с кему-то обуждать, соответственно узнать её "официальное" название — тоже; фразы "вон та вот х… рень" вполне хватало.
Было бы любопытно ознакомиться.
What Every Programmer Should Know About
Floating-Point Arithmetic
Держите и не благодарите. Когда это знаешь, то иногда получаешь х10 производительности, просто переставив порядок операций. С плавающей точкой аналогично — иногда, решая нелинейные уравнения, результат надо нормализовать по заданному эпсилону, чтобы случайно не взять sqrt(-1e-18), когда должен быть sqrt(0), и не получить nan во всех последующих результатах.
Программист не может не знать, что такое замыкание.
То есть, по-вашему какой-нибудь крутой знаток ассемблера — «не программист», потому что он такое не использует и потому не знает?!
Как раз знаток ассемблера должен замыкания знать намного лучше остальных. Ему ведь их на ассемблере реализовывать, а не просто пользоваться.
Ну вот когда вы пишете кодогенератор для компилятора, то вам надо знать, как реализовываются замыкания.
Может он чем то другим занимается?
P.S. при упоминании ассемблера мы, несколько, отошли от JS.
При чем тут транспиляторы js? Сейчас замыкания есть практически в любом ЯП и знание того, как устроены замыкания — это примерно то же самое, что знание того, как устроены функциональные вызовы.
Но я всегда думал, что ассемблер-разработчикам, гораздо ближе hard нежели высокоуровневые языки программирования.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
за те самые 25 лет мне не требовалась ни разу
Ну бывает. Опыт-то он у всех разный. Например, в C++ и в Java такого фактически нет.
Я вот до знакомства с питоном тоже не знал что это и не использовал. В питоне же, изучая исходники библиотек, столкнулся — там это используется в написании декораторов. В js же вообще повсеместно (особенно раньше), в силу специфики языка.
Но вообще, до знакомства с тем же питоном я и о других вещах, вроде генераторов или метапрограммирования, тоже не знал. Так что полезно иногда изучать разные языки, так как многие из паттернов, подходов и концепций, почти отсутствующих в одном языке, в другом могут быть чуть ли не основным подходом.
А откуда они там берутся, в этом use? Уж не из родительского ли скоупа?
Кстати, в языке c++ реализованы оба механизма.
for ($i = 0; $i < 10; $i++) {
$button->onclick = function () use ($i) {
echo $i;
};
}
То есть это не замыкание на родительский скоуп, а именно захват переменных в свой, при чем именно во время создания функции. Но я могу ошибаться, т.к. на php не писал с 5.3
То есть доступа в родительский скоуп (сообстно замыкания) во время работы функции нету, просто в локальной области видимости есть дополнительные переменные
В JS и C# есть доступ к скоупу вне функций.
А в php клонируется или переменная, или ссылка на область памяти с ней.
for ($i = 0; $i < 10; $i++) {
anotherFunction( &$i );
}
Тут ведь нет замыкания? Вот тот пример ближе к этому.
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, хотя по факту это таки практически один в один замыкание.
Я часто спрашиваю на собеседованиях чем по сути является метод .bind(). Это и есть мой скрытый вопрос про замыкание.
Но ведь бинд в js как раз не замыкание возвращает, лол. Т.к. в "просто замыканиях" this связывается динамически.
Пусть автор не сдается, собеседование это всего лишь этап.
Во-вторых, ответ на вопрос «что такое замыкание» может отлично показать и психотип человека, и общую его базу. Это важно. Также в ответе прозвучат разные слова, за которые можно зацепиться. Вопросы на собеседовании — это всего лишь крючки, основное смысл — это как раз разговор о том, о чём вы будете говорить в своих ответах.
Ну и в целом не понимаю, почему у вас (в смысле у тебя и у ТС) бомбит. Если вы считаете, что подобные вопросы на собеседовании есть показатель того, что компания вам не подходит — ну так хорошо же, что вы сразу это понимаете. Лучше ведь на первом собеседовании увидеть, что вам с компанией не по пути, а не через полгода работы.
Во-первых, когда вы сами начнёте нанимать людей в нормальную контору, то увидите, как много непонятно кого пытаются правдами и неправдами попасть к вам. И если вы не знаете другого способа отсеивать фуфло, то вы тоже будете задавать тупые вопросы.
Статья о том, что таким способом наиболее эффективно отсеиваются как раз лучшие разработчики. А вот фуфло и так дорогу найдет, не замыканиями, так другими фокусами.
Статья о том, что таким способом наиболее эффективно отсеиваются как раз лучшие разработчики.Никаких доказательств данного тезиса в статье нет. Нет оснований полагать, что данные вопросы станут проблемой для лучших разработчиков. То, что они стали проблемой для автора никак не может быть без особых причин экстраполировано на лучших разработчиков.
От вопросов —
var a = b = 3
трясет дико, вообще против таких присваиваний и использую standard стиль кода, но зачем-то должен знать, хотя в вакансии явно указано ES6.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
Речь не идет о доскональном знании алгоритмов 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);
});
}
Так в том-то и дело, что он общеизвестный для программистов на любом языке, где есть замыкания и изменяемые переменные. И нет, версии зависит цикл foreach, а цикл for работает одинаково во всех версиях языка.
Вроде это известный прикол
Именно! А в JS оно еще и встречается в десятки раз чаще. А теперь представьте, что Senior C# Developer понятия не имеет об этой особенности
А у меня вопрос, а зачем такое писать на c#?
И ещё, знатокам на засыпку, а если (про версии, и особенности реализации) представим ситуацию когда ядро исполняющие поток цикла после третьей итерации остановится(перегрев) а в этот момент придёт событие на третью кнопку, то есть гарантия что в будущей версии виртуальной машины результат будет 5?
Это вопрос не на знание API, а на понимание замыканий и проблем которые могут быть с ними связаны. Решений этой проблемы можно придумать множество, и знать API тут не нужно. Хотя, конечно же, со знанием API всегда проще.
Ну в принципе да, хотя в тот момент у меня в голове мысли были про работу event-loop-а и как это работает.
Не слишком удачный пример, хотя он видимо становится классикой на собеседованиях по фронт-энду.
Я ни разу такую конструкцию не использовал, поэтому у меня глаза на лоб полезли после запуска)))
Не по .NET, а про JS, но я помню у нас был баг связанный как раз с этой особенностью.
называется браузер на 2м экране
тем более для вспомнить определение
Я как-то собеседовал одного соискателя — он такой «э… м… дайте подумать» и стук клавиш в фоне. Даже вебкамера не нужна, всё слышно.
Гугл ему всё равно не помог, т.к. на «открытых» вопросах валятся.
А работать потом можно и со стуком :)
Почему выгонят? Вы не гуглите во время работы?
Второй вариант почему мне приходится так поступать — это как раз неправильное собеседование и странный работодатель. Но и здесь непонятно зачем туда идти и как потом там работать.
Поэтому не вижу смысла в подобном подходе вообще.
Через неделю-две эти операторы станут для вас часто используемыми, вот и все.
Точно так же как вы разберетесь со специфическими особенностями архитектуры текущего проекта, узнаете какие-то нетривиальные вещи из предметной области, привыкните к принятым в команде гайдлайнам и т.д..
Прочесть апи оператора, да хоть десятка — не такая уж проблема, большая проблема — не уметь этого делать. А еще большая — спрашивать даже не загуглив.)
Потому, что раз мне приходится вот так поступать во время собеседования, значит я профнепригоден. И это выяснится очень быстро.
Мне вот во время работы постоянно так поступать приходится. Если принять, что собеседование проверяет рабочие навыки, то, с-но, придется и во время собеседования.
Скрывать приходится в двух случаях — если профнепригоден соискатель или если профнепригоден человек, проводящий собеседование.
В обоих этих случаях нет смысла стремиться на эту работу. В первом случае выгонят, во втором быстро уйдете сами.
Эх, знакомая история. Мне тоже такие попадались. Один еще по русски говорил не очень хорошо. Когда он мало стучал по клавиатуре, то от него приходили довольно развернутые ответы. Я их сразу копипастил в поисковик, по первой ссылке получал источник, откуда он их скопипастил.
В ответ на очередной вопрос он долго стучал по клавиатуре, видимо, не мог найти подходящий ответ, и ответил в итоге вот так:
Собеседование длилось очень не долго, но этот кандидат мне запомнился особенно.
А вообще да, очень мало кто умеет нормально собеседовать. Или определяют «на глазок», или совершенно нерелевантные вопросы.
В последнее время заметил, что большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами. Это всякие Яндексы навязывают тенденцию того, что человек, который умеет хорошо программировать, то он должен без труда решать простецкие житейские задачи на листке.
Зато если этому дяде сказать, что надо по-быстрому написать Backend на коленке с простым Rest-методом, который будет общаться через ORM с БД и брать оттуда первую строчку, позволив ему пользоваться Гуглом, он накидает Backend за 15 минут и еще сверху расскажет, какие проблемы есть, например, в Hibernate с пагинацией и как её поправить.
Тут всё сугубо индивидуально и риск найти самозванца есть всегда. Нужно задавать правильные вопросы и смотреть по ситуации.
P.S. Задания типа reverse() или кастомный стек — это походу классика уже наверное) Я не против заданий, но это не всегда является прямым показателем знаний.
Строки в большинстве случаев у нас иммутабельные — это уже заставляет нас какой то промежуточный объект вводить (библиотечный или свой) который бы содержал строку в массиве. А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок… Из за чего если работать просто с массивом байт, и, возможно, даже с массивом символов, можно словить проблем…
Я не знаю, какой будет пример элементарной задачи в вашей области, мне строки казались достаточно универсальным примером, но я мог отстать от жизни.
Это считай базовый функционал любой стандартной либы в большинстве языков.
Как меня это характеризует?
Задача «Перевернуть 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) но зато с потерей оперативки и чуть более долгой загрузкой строки в память.
В реальности в отличии от собеседования задачи существуют в контексте и часто уточнения не нужны, потому что понятно что за задача, откуда она взялась и как должна работать.
Собеседование же максимлаьно абстрактное, не задавать вопросов предполагая некоторое дефолтное поведение — вполне норм. Если собеседующему не понравятся ваши допущения, он уточнит.
Таким образом чаще всего уточнения не нужны ни в реальной работе ни на собеседовании.
Уж слишком просто все на первый взгляд.
Множество «программистов» не может fizzbuzz написать.
Какие уж тут строки и массивы(OMG!)
На питоне правильный ответ на такой вопрос: s[::-1], и это называется знать свои инструменты. Не стоит отвергать очевидное решение потому что оно очевидно.
Правда я не Software engineer и там может быть свой мир, но отбрасывать очевидные решения по причине простоты думаю что все равно не стоит.
В материалах по подготовке к собеседованиям это часто упоминается.
str.split('').reverse().join('')
.Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект (+ ещё reverse массива этих временных объектов).
На это можно возразить, что преждевременная оптимизация – корень всех зол и всё в таком духе, но это тоже вопрос довольно спорный, т.к. в плане выбора подходящих алгоритмов и структур данных, обычно проще сразу делать «нормально».
Соответственно, если человек отдаёт себе отчёт в побочных эффектах такого кода, и написал просто потому что это удобный однострочник, то всё хорошо. А вот если нет – то это пойдёт в минус, а не в плюс.
Если в JS это хороший способ (например, более эффективный вариант является слишком громоздким или эта конструкция как-то оптимизируется или что-нибудь в таком духе) – мой комментарий можно игнорировать. Как я уже сказал, я с JS не очень дружу)
«А вы бы применили такое решение в production?».
Именно такое решение и применяю.
Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект
Не больше, чем, если вы напишете всё это вручную. По сути, вам придется делать всё то же самое, строки ведь иммутабельные
Так что — да, это в продакшене широко применяется.
Тем более, что код на JS в половине случаев выполняется на клиенте, у которого вполне есть ресурсы
Извините, я понимаю, что это решение, судя по ответам, действительно в большинстве случаев приемлемо, но просто не могу удержаться) В итоге имеем то, что имеем)
Пример утрированный, конечно, но я хотел показать, что операция может стоить для вас очень много, а для пользователя не стоить ничего. Вот именно это я имел в виду, говоря, что клиента нагружать можно больше, чем сервер.
Ну и вообще-то все обычные десктопные приложения замечательно работают на мощностях клиентов, так было всегда, и всем это ок. А вот если попробуете например сделать редактор изображений и реализуете всю графику на сервере, будет интересно посмотреть на его мощности и сколько это будет стоить.
console.log([..."123456789"].reduce((a,c)=>c+a));
К ней надо относится как к абстрактной сущности, которая умеет отдавать длину, и читать/писать символы под индексу. А уж что там внутри — пофиг вообще.
Вас же просят строку перевернуть, а не массив байт изображающих чары в неведомой кодировке.
Они превращаются в какую-то угадайку о том, что хотел сказать интервьювер.
По-моему, в таком случае правильно задавать дополнительные вопросы и характр этих вопросов очень хорошо показывает на каком уровне человек решает задачу
— Как бы ты реализовал вот такую систему? (описание требуемой функциональности)
— (описываю возможную реализацию)
— Хорошо, а как бы ты её реализовал на кластере?
— А зачем её реализовывать на кластере? Чего мы пытаемся этим достичь?
— Эээ… Не важно, просто поступило требование реализовать её на кластере.
— Окей, пусть одна нода выполняет вышеописанную реализацию, остальные пусть простаивают.
— Эээ… Ну окей.
В других проектах было и так, что притаскивали криво написанный FSD, я начинал задавать вопросы что бы понять что на самом деле стоит за его весьма туманными формулировками. Мне отвечали на «от*бись»: типа делай как хочешь, но чтобы было по FSD и работало, а потом начинались наезды из серии, что раз я задаю так много вопросов, то я плохой разработчик. Ну и конечно прибавлялись снова требования стать телепатом. Потому что моя реализация естественно расходилась с задумкой аналитика.
Короче каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад. Вот на это и нужно проверять человека на собеседовании ;-)
каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад
А разве это не должен делать его начальник?
Или его начальник ни зачто не отвечает, в том числе и за действия своих подчинённых?
Косяк подчинённых = косяк начальника в качестве руководителя.
Первый должен будет найти собственно конец строки.
Формулировка задачи — написать функцию, переворачивающую null-terminated строку, используя минимум памяти. Символы однобайтовые.
Переворот таким циклом, как вы написали — совершенно нормальное решение.
Но — справляются с задачей 25-30% собеседуемых.
Сумма составляется так: примерно 10% пишут правильный код, 10-15% почти правильный или правильный после наводящих вопросов. 5% не понимают, что такое «используя минимум памяти», но строчку переворачивают.
А половина испытуемых даже не могут написать функцию C на бумажке, любую.
Из тех, кто не справляется — говорят все обычно идеально. В итоге мы стали сначала давать задачу, а потом общаться, т.к. жалко времени.
Тем, кто справляется, даем табличку с кодировками символов UTF-8 и просим теперь на тех же условиях перевернуть строчку, состоящую из символов UTF-8. На самом деле, это простая получается задачка. Если человек затрудняется, просим решить дома и написать нам. Из всех собеседований только 1 или 2 человека предложили решение.
Писать код на C на бумажке будет только мазохист. Чтобы красиво выводить курлявые скобочки пером — это нужно годами не вылезать с собеседований. Жить там. Белый же человек посмотрев на свои каракули вздрогнет, извинится за потраченное время и тихонечко уйдет.
Не проблема, если попросите ноутбук — вам его дадут. Но там 10 строк, стоит ли?
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Если что, то простив задач на собеседовании в принципе, и считаю, что нужно уметь обходиться без оных.
Знаете, это мое собеседование, я набираю человека в команду и мне с ним работать. Я не хочу потом работать за него, вместо него. Поэтому я задаю вопросы, которые считаю нужным. Если человек правда считает, что перевернуть строчку на языке C — задачка "со своей поляны", обижается, борется со мной или убегает — наверное я его не возьму. В конце концов, в работе бывают всякие моменты и надо адекватно реагировать. Но я вам могу сказать, что таких не встречал на собеседованиях.
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Обычно есть некоторое количество кандидатов из которых надо выбрать, и вакансия, на которую надо принять человека. После собеседования N кандидатов примерно понятен их уровень и выбирается уже из них. Если на задачке совсем все заваливаются она просто не достигает своей цели — подсказать кого выбрать из пула. Соответственно задача калибруется.
А вот интересно, люди, дающие задачки на собеседованиях, сами готовы задачки подобные решать?
Я ходил на собеседования к очень крутым ребятам. Иногда меня даже выбивали в зону, где я ощущал себя некомфортно в плане знаний. И это было круто — ты реально общаешься с крутым технарем и вам есть о чем поговорить и ты сам узнаешь свои слабые стороны.
На последнем собеседовании меня гоняли по архитектуре. Ну начиналось все с классики, когда дают пример, ты используешь наследование, а потом контр-пример, который делает наследование неактуальным и ты используешь композицию, потом тебя ставят в еще более неудобное положение, а ты ищешь из него выход.
И всё это на белой доске маркером. В такие моменты ты просто общаешься с прогерами, делишься опытом, рассказываешь, как ты в реальной жизни стыкался с этими проблемами и как их решал.
Про это кстати недавно наткнулся на интересное решение этой проблемы: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/. Для кого-то может и очевидная штука, а я вот был крайне удивлен.
Мсье знает толк в извращениях! Нет, такого не было. Но вот раз человек использовал 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
...```
А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок…
Ну, раз пошла такая пьянка пошёл разговор о внутреннем устройстве кодировок, то помните, что Вы сами напросились.
А еще лучше, уже на вопросе
Должен ли я предусмотреть защиту от атаки через подмену букв со сходными начертаниями (например, турецкой I)?
Переключился на эту тему и узнал, как бы он это реализовывал
Если только речь не идёт о копировании файла самого в себя (это тоже интересный вопрос...)
Ну или здесь, тоже ведь отличная тема!
Не хочу отклоняться от темы, но мне кажется, что такое поведение создаст серьёзную дырку в безопасности. Особенно в случае если файловая система, на которую мы копируем файл, поддерживает произвольные атрибуты (прямо или косвенно).
Интересное замечание про шифрование и сжатие. Я бы с удовольствием послушал, как он бы решал эту проблему.
В итоге и сам, может, чего новое узнал и оценил уровень знаний человека и собес совершенно нестандартный и интересный.
Тебе нужен специалист, который шарит в необходимых технологиях и у него проекты есть, и вроде понимание как это должно работать, какие есть проблемы — экспертиза одним словом. И ты ему не даш шанс из-за того, что он на бумажке не может код написать?))
Недавно книгу одну читал, что люди очень любят производить оценку по себе. Все что тебе кажется очень легким, очевидным и простым, для другого может оказаться не так тревиально. Поэтому, если уж человек не совсем идиот и я вижу энтузиазм, желание работать и развиваться, то почему бы не дать шанс? Ааа, он же кодить на бумаге не может… Что ж, будем искать человека который может...
Суть в том, что есть куча людей, которые как замечено ниже не понимают что такое переменная и цикл.
А зачем такие люди идут на собеседование на должность программиста, на что они рассчитывают? Работать-то придется все равно. Странно получается, я никогда не работал в должности программиста, хотя и написал пару простеньких программ на C++/Qt5 (вроде калькулятора и маленького оракл клиента отправляющего заранее написанные запросы из конфиг файла с пользовательскими параметрами в базу и вывод результата в человекопонятном виде), но я не суюсь на собеседования потому что понимаю, что этого мало даже для джуниора, а приходят люди не знающие что такое цикл?!
Суть же не в том чтобы сразу написать идеальное решение, а представить ход мыслей и сколь-нибудь разумное решение, в котором смочь увидеть проблемы (возможно с подсказкой) и предложить решени
Вот быстро и с ошибками — видел. Особенно интересно, когда такой человек работает в ночь, а ты утром приходишь и все поломано в разных местах) Правда человек за ночь делает то, что я делал в среднем за неделю, но отлавливать и чинить… В общем, есть специфика)
В собеседованиях так или иначе большая доля везения.
Это не так. На собеседования в крупную компанию нужно готовиться
Нужно готовиться или нет — это зависит от ваших знаний/бэкграунда. Суть в том, что вам надо показать, как вы справляетесь с новой задачей, а не как рассказываете заученное решение. Поэтому желательно задавать задачу, которая по крайней мере не входит во всякие «топ вопросы для интервью».
Так требуют или не требуют? Вы определитесь, а то по второму кругу спорить начнем.
Т.е. для вас существует только концептуально неправильное решение и идеальное решение.
Вот видите, вы продолжаете настаивать на моей некомпетентности основываясь на часовом тесте
Я не «настаиваю», а только предполагаю вашу некомпетентность в рамках интервью. Я не пытаюсь ничего сказать об эффективности интервью в оценке ваших компетенций.
Почему же ее не смогли определить мои работадатели за 20 лет?
Так откуда мне знать, может вы эти 20 лет на 1С программировали? Вы же не пытаетесь со своими 20 годами опыта непонятно в какой области устроиться, например, адвокатом или хирургом?
Вы утверждаете что навык «писать код быстро без ошибок» — нужен только на собеседовании.
«Писать быстро без ошибок» — это утопия. Очень даже весомый кусок времени занимает не собственно написание, а отладка.
Индустрия не молода, так что статистики полным-полно.
Например:
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
Кстати, это значит что интервьюер внимательно проревьюил ваш код — причем моментально, и нашел там вырожденный случай
Ну нет же, интервьюер знает эту задачу и приготовил вырожденные случаи, и знает на что смотреть. У него время на подготовку было бесконечно и никакого давления, в отличие от.
В 99% случаев тормоза не имеют отношения к моей программе — в реальных проектах тормоза в СУБД, сети и пр. внешних факторах.
Просто «в вакууме» оптимизация алгоритма (логарифм/квадратичный и т.п.) сама по себе толку дает мало.
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
Почему вы решили, что ваш случай и статистика верны для всех?
А почему вы решили, что статистика иная?
Тут все верно. Но далеко не все пишут CRUD приложения.
Львиная доля программистов пишет вовсе не библиотеки сортировки.
Большинство пишет именно прикладные проекты, где нужен ввод-вывод (сеть, диски — где и находится основная часть тормозов). Даже, казалось бы, такие далекие от СУБД ребята как game developer, и те в подавляющем большинстве своем не пишут сами движков (где была бы полезна эта оптимизация «логарифм/квадратичный») и тормоза у них значительно зависят не столько от правильного цикла, сколько от грамотной работы с движком, что лежит за пределами их кода.
А что писали лично вы за последние 10 лет? Учебные/студенческие работы/курсовые/дипломные если не считать.
Представьте, что этот движок кому-то надо писать. Да, львиная доля этим не занимается. Да, большинство будет писать прикладные проекты. Но если нужен программист в ядро — при чем тут львиная доля?
Программистов, понимающих «логарифм» или «квадратичная» — вполне себе хватает. Будет кому написать.
Другое дело, что подавляющее большинство прикладники.
Да, это все прикладные проекты, активно использующие субд.
Что и требовалось доказать. И вы тоже прикладник.
Я вот к чему: вы слишком серьезно относитесь к вещам, которые нужны только одному из 1000.
Слишком требовательны к подавляющему большинству по части тех знаний, которые им не факт что и пригодятся когда либо.
Я вот к чему: вы слишком серьезно относитесь к вещам, которые нужны только одному из 1000.
Давайте проведем связь многие (программисты) ко многим (незначительным вещам) и окажется, что несерьезно к ним относиться нельзя. А как различить грань между слишком и не слишком?!
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
В субд те же индексы (хеши и двоичные деревья) и hash и merge joins и nested loops — т.е. надо понимать как все работает и сообразить какая o(f(n)) там будет.
сообразить какая o(f(n)) там будет.
План запроса меняется автоматически в зависимости от статистики, то есть на разном объеме данных/разном содержимом может быть по разному.
Низкоуровневые знания, в которых не учтена статистика данных — тут слабый помощник. Ибо все ваши микрооптимизации могут быть в любой момент пересмотрены СУБД.
Гораздо полезнее предоставить СУБД правильные индексы — а дальше она сама разберется.
Ну а как влияют merge joins, nested loops — вы будете прекрасно понимать безо всяких o() на уровне интуиции уже после пары месяцев интенсивного написания/оптимизации запросов.
Примерно столько времени понадобилось одному из джунов (не самому таланливому в программировании), которого я натаскивал. Причем большую часть времени он сам учился. Я только советы общего характера давал типа «разбить запрос на отдельные части и посмотреть». После пары месяцев интенсива от такие стал оптимальные запросы писать — закачаешься.
Вспомните происхождение SQL — изначально он придуман вовсе не для программистов, а для менеджеров, чтобы сами себе отчеты строили, не отвлекая программистов.
План запроса меняется автоматически в зависимости от статистики, то есть на разном объеме данных/разном содержимом может быть по разному.
Совершенно верно. Чтобы спроектировать структуру данных в общем случае надо представлять примерную ожидаемую статистику и как работает оптимизатор
Примерно столько времени понадобилось одному из джунов (не самому таланливому в программировании), которого я натаскивал.
Вопрос, помогло бы ему если бы он уже знал как рассуждать о производительности быстрее и лучше оптимизировать или нет. Мне кажется, в принципе в массах культура формального рассуждения весьма хреноватая и многим было бы полезно научиться не только интуитивно научиться каким-то приемам но и знать почему так и какие ограничения и т.д. И мочь передать это днание другим
Чтобы спроектировать структуру данных в общем случае надо представлять примерную ожидаемую статистику и как работает оптимизатор
По мне так не нужно все это. Алгоритм прост. Для РСУБД будет таким:
Сначала нормализуем.
Потому там где тормозит — денормализуем.
Стадию денормализации — можно сделать сразу, с опытом приходит понимание этого и без пробных запусков в эксплуатацию.
Расставляем индексы для отборов.
Не забываем про кэши за пределами СУБД.
Все оптимизации выполняем по мере необходимости.
Вообще сомневаюсь что знания как работает оптимизатор чем то поможет написать существенно более выдающуюся по производительности структуру БД в сопоставимые сроки, чем предыдущий алгоритм.
Было бы очень интересно послушать от вас цепочку рассуждений. Как именно вы строите базу данных, исходя из понимания работы оптимизатора.
Потом там где тормозит — денормализуем.
Вам надо либо спроектировать нагрузочный тест чтобы получить "там, где тормозит" либо это будет тратить время людей, которые буду жаловаться на тормоза пока это не исправят.
Если у вас быстрый цикл обратной связи, то хорошо. Если у вас БД на атомной подводной лодке на которую можно накатить патч раз в полгода, то плохо.
Было бы очень интересно послушать от вас цепочку рассуждений.
Ничего волшебного. Просто надо либо запоминать свойства индекса либо вывести их из знания его внутренней структуры. Второе не потребует циклов обратной связи. Например если есть запрос выбирающий по полям соединенных таблиц, то отдельное их индексирование ускорит меньше чем индексирование по паре, соответственно деномализация тут может помочь (и так далее).
вы будете прекрасно понимать безо всяких o() на уровне интуиции уже после пары месяцев интенсивного написания/оптимизации запросов.
Так и появляются code-monkey, которые принимают решение интуицией, а не знанием и здравым смыслом.
Так и появляются code-monkey, которые принимают решение интуицией, а не знанием и здравым смыслом.
Вы путаете интуицию и парапсихологию, видимо.
Интуиция — это те же знания, полученные на основании того же предшествующего опыта. Только эти знания уже глубоко укоренились в разуме.
Отличие в том, что для использования знаний явных нам нужно воспроизводить всю цепочку рассуждений, а для интуиции эта цепочка уже не требуется.
В истории с тем велосипедом самое интересное то, что человек потом на обычном ездить разучился.
Причем замечания выглядели следующим образом: мне давали набор входных данных для проверки, я хлопал себя по лбу и лез исправлять код.
А в промышленном программировании вы также поступаете? Выпускаете код, а когда прибегает пользователь с ошибкой из-за неучтённого случая, хлопаете себя по лбу и лезете исправлять код?
Но это стоит сделать перед тем, как сообщить о завершении написания кода.
Почему же тогда никто их не обнаруживает прогоняя код в голове до коммита?
Почему же никто. Как раз в вашем случае, интервьюер легко смог в голове оттестировать ваш код и указать на проблемы.
Скорее всего это означает то, что ошибки были достаточно очевидны (мы ведь не предполагаем, что интервьюер — суперкомпьютер).
Ну и более того, интервьюер посчитал эти ошибки серьезными. Хотя оценка серьёзности может, конечно, отличаться.
А в промышленном программировании вы также поступаете? Выпускаете код, а когда прибегает пользователь с ошибкой из-за неучтённого случая, хлопаете себя по лбу и лезете исправлять код?
А при чем тут он?
Вы что, сами не видите какого огромное количество сырых продуктов выпускают на рынок? Ко всем им лично он имеет отношение?
Если речь не идет о выпуске миллионными тиражами, когда перепрошить потом дорого…
Если речь не идет о крайне дорогом исходе при одной-единственной ошибке…
То да, как правило, да, программы содержат кучи ошибок.
Заказчику/работодателю важнее снижение дорогущей себестоимости разработки, даже если возрастает риск ошибки.
Нет цели — «сделать безошибочно любой ценой».
У ошибки есть цена, у разработки с дополнительным тщательным тестированием есть цена. Заказчик выбирает между ними.
Более того, даже не всегда в деньгах дело.
Чаще более важный фактор — время разработки.
Как бы все было просто, если бы соискатели действительно могли знать, в чем суть до начала собеседования. Никакой информацией о типе задач, сложности, времени на выполнение, приоритете теории и архитектуры над типовыми задачами или "сути" у соискателя нет до момента собеседования. ( в вакансиях никто ничего не пишет )
Бывает и так, что сходу знаешь решение с идеальным O(N), но не помнишь порядок аргументов в одной из функций, а гуглить нельзя, спросить нельзя, рассказать нельзя — сиди и создавай неловкую паузу.
но не помнишь порядок аргументов в одной из функций, а гуглить нельзя,
В адекватных конторах это обычно не проблема. Я на одном собеседовании просто сказал, что вот не помню порядок аргументов и точное название стандартного метода. Собеседователь сказал, что это вообще неважно, итак на псевдокоде пишем. Никаких проблем не было.
Да, вот просто взять и посчитать, сколько слов содержится в стринге.Просто взять и посчитать, говорите? Я бы не хотел работать с вами, если вы всё делаете «на отвали» — так же, как ставите задачи. Потому что «Иван, завари чай» — это три слова. А «завари иван-чай» — это два слова. Дьявол кроется в деталях.
Это подколка на тему того, что дефис может быть как частью слова, так и разделителем слов. И без словаря нельзя один случай отличить от другого.
дефис может быть как частью слова, так и разделителем слов
Это где дефис является разделителем?
Вот прямо из Википедии: ковёр-самолёт, монах-аскет, Волга-матушка, Москва-река, Иван-дурак, Соловей-разбойник, сторож-старик…
Одним словом два разных члена предложения не могут быть никак.
Из собственно грамматических критериев выделения слова известностью в отечественной лингвистике пользуется критерий цельнооформленности А. И. Смирницкого. Согласно этому критерию сочетание морфем признается одним словом, если грамматическое оформление при помощи соответствующей служебной морфемы получает все сочетание в целом, а не каждый из его членов. Например, иван-чай — это одно слово, так как при склонении все сочетание в целом оформляется одной флексией: иван-чая, иван-чаю, а не *ивана-чая, *ивану-чаю.
В противном случае, когда каждый член сочетания получает свое оформление, — это называется раздельнооформленностью — сочетание признается двумя словами. Например, город-герой — это два слова, ср. города-героя, городу-герою и т. д.
В.Б. Касевич «Элементы общей лингвистики»
Разделяют через тире, а дефисом переносят. Чушь полнейшая, но так уж исторически сложилось.
А почему чушь? Семантически же это разные случаи?
Опять же, хоть кто-то, кроме профессиональных типографов/верстальщиков, набирая текст, пользуется тремя различными символами? Я, к примеру, везде ставлю минус: и как минус, и как тире, и как дефис. Лишняя головная боль только, их порядковые номера в юникоде запоминать.
а по факту человек не может написать простую считалку слов
Сло́во — одна из основных структурных единиц языка, которая служит для именования предметов, их качеств и характеристик, их взаимодействий, а также именования мнимых и отвлечённых понятий, создаваемых человеческим воображением.
Что-то мне кажется тут без сильного ИИ и бигдата не обойтись:)
На собственном опыте убедился, что легко могу войти в ступор, когда резко посреди беседы просят перевернуть биты в int32.
Я не сторонник циничного подхода, что, дескать, если отсеяли, что не повезло тебе, чувак. Но всегда приходится исходить из того, что реализуемо на практике. Человек, впавший в глубокий ступор, внешне не отличим от человека, который ничего не знает и не умеет. Я стараюсь всегда смягчать стресс, предлагать альтернативные вопросы, если на каком-то зависли, но, наверное, остается возможность что кто-то может отсеяться несправедливо.
а) Тех, у кого нет знакомых среди сотрудников
б) Тех, кто не работал в OpenSource
в) Тех, кто не писал статей
А у нас совершенно нет причин этих людей отсеивать.
Просто нужно читать резюме ДО собеседования и, если там указаны ссылки на проекты или статьи, то ознакомиться с ними, чтобы заранее составить первое впечатление о человеке(к вопросу о гибкости — первое впечатление не всегда верно, поэтому надо уметь абстрагироваться от первой оценки, если что-то пошло не так). И затем на собеседовании отклониться от своего дефолтного плана, да может задать пару вопросов из проекта\статьи человека. Это даст куда больший отклик о человеке, чем «возможность проявить себя» в виде задачи, которую нужно написать на листочке. И, вдобавок к лучшему отклику, ещё наиболее приятное впечатление останется у человека о компании, в которой интервьюеры, наконец-то, снизошли и хотя бы поинтересовались бекграундом человека, который был указан в резюме. Даже в случае отказа впечатление с хорошей вероятностью будет лучше.
Однако у этого подхода есть один минус — время.
Помимо времени на собеседование ещё нужно уделить определённое время на чтение и изучение кандидата. Это может занять 5-20 минут в оптимальном случае. А в случае, если из 10 кандидатов 3 оказались с таким «бекграундом», то времени нужно затратить 5-20 минут на КАЖДОГО из них, что в случае большой текучки и кандидатов может оказаться расточительно.
А в случае одной вакансии и тех же 10 кандидатов, как по-мне, можно уделить этому время. Если не на проекты, на изучение которых может уйти достаточно много времени, то хотя бы на чтение статей, которые написал и указал кандидат.
Но… зачем? Зачем тратить своё драгоценное время на каких-то кандидатов, верно? ;)
p.s. посыл не конкретно к OYTIS, а в целом к интервьюерам любого толка. Проводить интервью — это не легкая затея и к этому делу нужно готовиться, а не просто плыть по течению.
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 я просто не буду реализовывать- слишком сложно для тестового задания.
Я к тому, что C# строка может содержать UTF-8 символы, но любые попытки работать с ними стандартными средствами (вроде того же reverse) развалят её: https://ideone.com/vRT9OG
И что такое «UTF-8 символ»?
То, что называется UTF-8 code point.
UTF-8 при том, что это по сути единственная кодировка переменной длины, используемая на практике.
В UTF-16 есть суррогатные пары. Почитайте википедию
Во-вторых, для любого «символа» можно однозначно определить чем он является — одиночным символом, первым суррогатом пары или вторым.
Способность к программированию — не субъективно ли это?
А чего тут субъективного? Есть способность писать код — напиши. Не смог — нет способности писать код.
большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами
Про бумажку, вроде, речи не шло, впрочем, я искренне не понимаю в чем проблема написать код на бумажке. В чем?
позволив ему пользоваться Гуглом, он накидает Backend за 15 минут
Да, таких cut-n-paste "дяденек" пол-Индии. Если вам нужны "индусы", то нет проблем — набирайте таких. Очевидно, автору обсуждаемого комментария нужны более другие разработчики.
Я не против заданий, но это не всегда является прямым показателем знаний.
А ни кто и не рассматривает это прямым показателем знаний. Это фильтр. И это ОЧЕНЬ эффективный фильтр.
Да, ладно, это уже какие-то совсем смешные придирки. Почеркал, переписал заново, написал сбоку, пририсовал стрелочку :). Это же все в непосредственном режиме происходит, собеседователь видет что происходит. Проверяется ведь не чистописание кода, а способность к программированию. В конце-концов, в таких случаях не дают же задачи написать реализацию поискового движка гугла, там что-нибудь простое. Говорят, иногда предлагают за компьютером такое проделать, но я как раз за компьютером бы сильнее растерялся — возможно незнакомая иде, окружение, клавиатура. От волнения пальцы не по тем кнопкам попадают (был такой опыт) — ужос, короче. По мне, так лучше на бумажке. Несмотря на то, что кроме собеседований я код на бумажке 30 лет назад последний раз писал (а потом набивал его на перфокарты!). Вообще, на бумажке на собеседованиях приходилось самое большое 5-7 строчек написать. Чаще код на собеседованиях писал во время скайп/телефонных собеседований в какой-нибудь веб-среде, предоставляемой собеседователем. Что-то вроде гугло-доксов. Там можно и исправлять и строчки вставлять и задачки уже не на 5 строк бывали, а аж на целых 10! :)
Проблема собеседующих в том, что нередко они хотят найти человека сильно круче, чем им реально надо.
Проблема собеседуемых в том, что они почему-то думают, что если они научились решать конкретные задачи в конкретной области, то они программисты in general и все должны их хотеть.
Есть онлайн и не-онлайн генераторы, которые переворачивают атоматически
ʚ — например этот символ latin small letter closed open e (U+029A)
ʎ — очевидно, лямбда
итп
о, норм так… щас поисследуем…
выглядит вот так без «хитрой кодировки»:
д??????? у?????? т??????.?? О????????????? н????????????????????????? и????????????????????????? ??????????????????????????? и???????????????????????????????????????? д??????????????? у???????????????? т??????????????????????????????!????????????????????????? ????????????????????????Z???????????????????????????????????????A????????????????????????????L?????????????????????????????????G????????????????O?????????????????!??????????????????????????
str.split('').reverse().join('')
но я почему то уверен что подобная функция возможно есть в других языках, да я понимаю что можно запустить цикл, что собственно тут и есть
так я к чему, не все и не всегда должны знать(помнить) бональные решения ибо такие решения очень редко используются в продакшине
на очном собеседовании демонстрировали полную неспособность к программированию.
В "Pragmatic Programmer" для этого есть прекрасный термин – Programming by coincidence.
Как говорится, «в противостоянии искусственного интеллекта и естественного идиота побеждает последний».
Если реализовать строку как двусвязный список котором есть указатель на первый, последний элемент и булево значение для определение направления реверса.
А в узле списка храним значение(тут можно уточнить кодировку и т.д.) и указатели a,b на соседние елементы.
Правда если алгоритм используется один раз то нет выигрыша, т.к. нужно перевести строку из «стандартной» реализации в «новую» структуру данных. Но если такая задача встречается много раз для каждой строки (и строки большие), то сэкономил вам кучу денег на серверном времени))
Помню однажды, я услышал такой вопрос «из списка»:
что быстрее Python или PHP
я чисто из вежливости конечно решил уточнить версию PHP например, версию Python или реализацию, в общем что-то, что могло бы мне дать повод не считать этот вопрос совершенно дурацким, мягко говоря.
Но вышло так, что HR с гордостью мне сообщил, что у нее без всяких там моих уточнений, её коллеги программисты написали совершенно однозначный ответ — Python.
Мне как бы было все равно совершенно, даже хотелось потроллить, но от дальнейшего технического интервью я сразу отказался.
Таким образом один вопрос из списка, сэкономил кучу времени мне, им, и очевидно для меня, рассказал мне об этой компании, и потенциальных коллегах, у которых видимо глубокий внутренний диссонанс.
— Расскажите мне о контракте между hashCode() и equals().
— (Начинаю рассказывать чего, да как).
— Нет, вы не поняли. Расскажите как это написано в JLS.
— То что вам рассказываю это разве не то?
— Нет. В JLS описано не так.
(проехали пару вопросов)
— Расскажите про уровни изолированности в JDBC.
— (Рассказываю, провожу аналогии с MS SQL и ORACLE).
— Я что-то вас не поняла. Вы там что, гуглите?
Меня после этого просто дико бомбануло. Компания не без имени, знакомые лестно отзываются о ней, но на собеседованиях выкидывают такие вот номера — вопросы по бумажке. После этого все желание продолжать диалог просто пропало.
Проблема автора на самом деле актуальная — изначально задоминировать респондента, чтобы доказать его никчёмность. Однако, после этого они еще кидают офферы, тем самым, произведя оценку твоих знаний, выставляют ценник. Прекрасно понимаю автора, что по морали такое сильно бьет, но ты держись. Не все компании такие вокруг. Остынь и снова можно попробовать.
Я что-то вас не поняла. Вы там что, гуглите?
ААААА! Меня аж встряхнуло от этих строк — когда на собеседовании по скайпу накидывал по Liskov Principe (soLid) и мне сказали «Вы там читаете в Гугле?» и даже речь заплетаться стала у меня :)
Мой друг хорошо помнил практически все операнды и функции того же C++, но при этом у него было всё печально с логикой.
Вопрос такой: кто из нас двоих лучше как разработчик?
Да, в те далёкие времена мы с другом писали то, что не могли написать больше никто из нашей группы.
Я и сейчас не факт что без ошибок с первого раза напишу простейший цикл, но это и не нужно, я ведь знаю, что мне нужно написать, а как это написать знают поисковые системы.
Спорный момент кто из вас лучше. Для одного работодателя, как писал выше автор, твой друг бы был идеальным кандидатом. Для другого работодателя, который тестирует логическими задачами аля «Есть 2 яйца, на каком этаже разобьется» и умение справиться с поставленной задачей быстро, ты бы показал себя с более сильной стороны. Но итог один — каждый специалист (если он действительно специалист) найдет своё место под солнцем.
Какого мнения придерживаюсь я?
Гугл — это инструмент, которое может тебе дать неправильное решение. Почему? А потому что ты загуглил проблему, открыл первую же ссылку на StackOverflow и скопировал решение. Добавило ли это тебе экспертизы? Нет, а это плохо. Надо стараться разбирать те типовые проблемы, с которыми ты сталкиваешься и хотя бы поверхностно изучать внутренности языка, чтобы совсем уж лохом не казаться, когда будешь собеседоваться.
Если компания «зазвездилась» до топов это доходит до маразма: начало 2015 года, одной сами знаете какой компании надо сделать тензорный процессор не хуже гугла для поиска по картинкам, ищут FPGA разработчика-схемотехника, меня забраковали потому что я знаю только C++11 а вот C++14 уже нет т.к. не смог ответить на их «очень простой технический вопрос». Естественно по самой простой конструкции уровня сложности не сеньёра а code-monkey. Кое как до них с городского дозвонился, в итоге сказали:«Вы вообще не разработчик, пожалуйста не звоните, ваш мобильный внесён в блек лист». Естественно каких либо верилогов и языков описания таймингов они в требования не внесли и не проверяли на тех собеседовании.
Приезжаешь в другую страну и встречаешь такие же портянки технологий, но появляется одна «мелочь» которая гласит «любое из» (いずれの). И работа находится сразу же, и проекты поинтереснее, и никто не ожидает что один человек за пол года тензорный процессор на десятки петафлопов свояет, и зарплата (в пересчёте на местные расходы) повыше «зазвездившихся» даже в предприятиях типа «болото». И даже есть и время и оплаченная возможность отдохнуть и погонять на ардуинке нейросети в реалтайме.
им очень не понравилось то что я не очень хорошо питон знаю, а то что я не смог ответить по новому ключевому слову из С++14 вообще просто повесили трубку без объяснения причин, вот и начал вызванивать «что это было? и почему тех собеседование и 5 минут не продлилось?».
и почему тех собеседование и 5 минут не продлилось?
Может, им за час нужно было с десятью поговорить. Они применили формальный фильтр. Интересно, что у них есть «чёрный список». :)
Может, вы не поняли, о чем вас вообще спрашивали, и проблема в этом?
Да и нежелание хоть как то фильтровать самозванцев это разве не есть достаточное доказательство проф непригодности соответствующих специалистов?
Спасибо тебе хабравчанин. Давно читал статью про распределенные БД и там было описание функции повзоляющей быстро определить относится ли число к множеству. Я не запомнил название, но теперь то я ее добавлю во вкладки.
Если использовать вашу аналогию, то представьте, что вы ищете элитную квартиру, и две трети предложений которые вам пытатся продать по цене элитного жилья — это малосемейки в разваливающихся бараках. Поэтому если вы заходите в обшарпанную прихожую в которой десятилетиями не было ремонта, дальше смотреть не имеет смысла.
Ну, если продолжать эту аналогию полностью, то тут проблема возникает, когда не смотрят реальную прихожую (реальную работу), а спрашивают по телефону, куда там вешается одежда. И если продавец назвал ключевое слово «вешалка-плечики», значит считается, что квартира, возможно, элитная (туда приходят люди в тяжёлых шубах). А если не назвал, то «мы вам перезвоним».
То есть, как бы, корреляция-то есть, но не совсем работающая.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
У вас переменная уже extern const, оптимизировать ее компилятор уже не будет, потому что она в другом translation unit, и положить ее в регистр если и получится, то только при LTO.
Имеет полное право хранить её в регистре между вызовами внешних функций, т.е. записывать в память не все её изменения, а только последнее перед вызовом.
С volatile — обязан записывать в память каждое изменение.
Я не про то, что не знаю, зачем оно так, а про то, для чего может понадобится именно extern const volatile, а обычного extern const не хватит, и ничего кроме многопоточной программы и регистров в голову не приходит. В одном потоке переменная (обычная, не отображенная на регистр) из другого юнита меняться не может, т.к. это нарушает инварианты.
Или, как вариант, это может быть extern const volatile-переменная. Писать в нее можно, но не в этом модуле.
Если программа однопоточная — volatile не нужен, только портит оптимизатору жизнь. Если многопоточная — его недостаточно, от гонок по данным так и не избавились.
Т.е. если там заведомо не регистры, то зачем?
Про железо: по молодости был у меня товарищ, который наизусть знал все параметры разных 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 минут с отчаяния начал набрасывать примеры — оборудование вышло из строя на аппаратном уровне...., неправильная обработка протоколов маршрутизации, падение производительности — ответы — нет, это все не к нам… а что же к вам? нет ответа, нет вообще. так и разошлись.
Первый уровень — оперативная поддержка. Это обеспечение бесперебойной работы систем и решение проблем только по инструкции. Есть инструкция как решить проблему, значит она решается. Если инструкции нет, то передается дальше. Как правило, первый уровень реализует поддержку по принципу 365/7/24.
Второй уровень решает несложные нетривиальные проблемы, не требующие серьезного анализа и разработки. Например на этом уровне может сделаться несложный data fix или может быть сделан какой-то быстрый workaround. Здесь уже как правило не идет речь о поддержке 365/7/24. Как только стукает 18 или 19 часов все разбегаются по домам. Но если задача важная, то могут и решать сверхурочно.
А вот третий уровень, это непосредственно разработка и решение проблем, требующих серьезного анализа. Почти все о чем вы написали действительно не его профиль. Потому что все перечисленные проблемы решает первая и вторая линия поддержки. А он занимается другим: разработкой новых фитч по запросу пользователей, баги в софте ковыряет (если это вендор ПО или интегратор) и пр.
Я закрываю скайп и, конечно, тут же вспоминаю, что за virtual.
Наверняка у многих такое бывало на собеседовании. Но, когда беседа закончена, то уже «нещитово».
Маленький лайфхак: можно записать суть вопроса одним словом на бумажке и предложить продолжить разговор.
Неизбежно возникнет пауза (например, когда собеседующий будет мысль формулировать) и ваш на секунду освободившийся мозг вытолкнет найденную в архивах информацию.
Так уж наш мозг работает.
И нет я не заканчивал интервью после первого не верного ответа — ну бывает, человек забыл. Но как можно забыть то, без чего невозможно работать с конкретной технологией, которая указана в резюме?
Я несколько раз уже помогал искать людей в команду, по сути каждый раз это заканчивалось «берем первого, который не врет, за наши деньги». Подавляющее большинство — лгуны и самозванцы. Врут про все, про национальность (один китаец говорил что он украинец, ни знал ни русского ни украинского, не мог назвать город где живет, использовал гугл транслейт), про занятость на других проектах (подается на фулл тайм, оказывает то студент то работает в офисе и ищет подработку), про скилы (в резюме создавал дамбу Гувера — на практике подавал ключи строителю), про личность исполнителя (проходит собес один человек, а работает потом другой, который ни чего не помнит и ниже скилами), про вредные привычки (а оказывается запойный алкоголик).
Короче да, вы правы, центральная идея — не взять самозванца. Но персонаж, который вам попался, явно перегнул палку, с такими критериями (чтоб от зубов отскакивало) он скорее всего найдет или ни кого, или самозванцев другого типа. Такие тоже попадались — все знают, работать не умеют, от слова совсем. Т.е. только по шаблону добавлять однотипные фичи или чинить мелкие баги.
А самое плохое — что нет возможности ни как на это влиять, отзывы ставишь только после работы. И это легко накручивается, работой самого на себя под разными именами. Тесты онлайн так-же легко накручиваются и проходятся. В итоге это армия самозванцев — бродит в поисках жертвы и не имеет ни каких механизмов естественного сокращения численности. Процент не врущих на собесах — падает. И все опять сводится к «порукам», просят посоветовать кого-то, с кем работал.
А вам не стоит бояться ходить на собесы, ну провалили одно, не устроились к тирану-топу-заучке, который бы не дал вам ни чего проектировать или делать, давил бы вас и самоутверждался. Хорошо же? Собеседование это двоякий процесс. Соискатель так-же тестирует работодателя, и сможет ли он с ним работать. И вот кстати очень редко самозванцы что-либо спрашивают относительно будущего места работы, им все пофигу, им все по плечу, они ко всему привыкнут. В то время как норм специалисты зачастую чувствительны даже к стилю кода, методологии и т.д.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
П.С. А был такой, что вообще ответы копипастил из гугла, прямо в наглую.
Вот и выходит — нужна вебка, нужно сразу просить писать код, нужно задавать вопросы «на самозванца» и включать психолога.
А тебе отказывают без какого-либо объяснения причин.
Пойдете писать подобное задание еще раз в следующую компанию «нам лень потратить на вас свое время но мы ждем от вас что вы потратите на нас не менее дня работы»?
При этом мотивация для отбраковки работы ведь тоже может быть произвольной. Идиот точно так же будет искать там к чему придраться — и успешно найдет.
Уж лучше устные вопросы. Честно. Тут хотя бы есть обратная связь.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
Я бы на такое заявление заметил, что поведение рекрутера, который по поверхностным вопросам делает выводы в место ведения диалога, больше похоже на психологическую травму подростка.
А вот из личного опыта:
Как то зашел у меня разговор с рекрутером о написании драйвера. Разговор свелся к тому что его представление об этом процессе подразумевает упоминание некоторых специфик. На мой вопрос «каких?», он спросил меня «что такое intellisense?». С мыслью о том, какое отношение intellisense имеет к процессу написания драйвера, я ответил «Понятия не имею». Сами понимаете какая ситуация получилась. Тем не менее, мне обещали выслать тестовое задание, которое я так и не получил.
Мне также приходилось иметь дела с подбором персонала в свою команду, и тут должен заметить тест тесту рознь. Поскольку, когда через неделю к тебе приходит человек, завалившийся на этапе установки IDE это тоже показатель. А с другой стороны я бы не прочь иметь у себя в подчинении или напарника, умеющего лихо находить применения интернет материалам в работе. Поскольку для меня даже такой кандидат был роскошью. Тех же, которые подходили полностью не проходили по легальному положению дел. То без гражданства то еще что. В общем всякое может быть.
Сениоры часто вырастают в совсем другой класс специалистов, которые решают более высокоуровневые проблемы, а не институтские задачи. И потому таких денег и стоят, так как опыт позволяет эти проблемы решать, в отличие от juniorов, которые расскажут, что такое виртуальный метод, но ни черта не поймут, почему лежит система. И нет, она лежит не из-за виртуальных методов.
Шаг вправо шаг влево — и нихрена они уже не понимают. Смутно вспоминают чего-то, но реализовать уже не могут. Здорово конечно когда находится такой спец вот конкретно на ту задачу которая есть у тебя. Но для 99% задач такой спец не годится а под оставшиеся 1% часто проще нанять кого-то попроще но кого не понадобится 3 года искать потому что таких спецов всего двое на всю Москву.
Толковый же джун он может сейчас чего-то и не знать, но он всему научится. Беспроигрышный вариант в среднесрочной перспективе
Работю с Unreal Engine.
У меня тут статья есть про то как делать анимации через Sequencer. Так я её на днях использовал, чтобы вспоминить ка кделать анимации в Unreal Engine.
Или вот настройка анимаций персонажей, год назад был проект в котором делали очень сложные анимации и я досканально с ним поработал.
А тут открыл редактор и даже вспомнить не мог как что делается, пришлось в доки лезть.
Причина проста — я не аниматор и работаю с анимациями далеко не каждый день.
Но если я иду на сеньора — такие вещи я должен знать. И я их знаю… но не помню.
Стоило, возможно, раньше прервать общение. Или до собеседования предупредить о том, что на листике не решаете, а если надо будет писать код, то уточнить заранее, в каких условиях это предполагается: свой ноут или чужой, будет доступ в интернет или нет, предполагаемое время на код.
Обычно, если не отвечают мне на эти вопросы или лукавят, со собеседование переходит в категорию стресс-интервью и мой ценник увеличивается — я могу и в таких условиях работать, но это дороже.
Убей не помню. Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего. Интервью, естественно, кончается.Тяжелый лайф хак: как только понимаешь, что какую лажу выкидывают собеседеры заявляешь, что предлагаешь прекратить собеседование прямо сейчас чтобы не терять своего времени (или ты понял что компания находится в стадии хаоса, или мало понимает свои цели, или еще что-нибудь такое веселое на твой взгляд). Гордость, свечение и высокомерие собеседера быстро испаряются. Я так делал всего один раз, когда мне заявили, что переработка будет учитываться (не оплачиваться!) только если я буду работать до часу ночи. Собеседера от моей оценки и предложения немножко трусило.
Джун — должен рассказать о virtual и о переопределении при наследовании
Мидл — должен к этому всему добавить хорошие use cases, и вспомнить о abstract/sealed.
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики.
abstract/sealed — да уж, джун не потянет…
виртуальных вызовах на структурах — хм, в чем отличие я не в кусре.
Ни алгоритмы ни паттерны не отличают джуна от синера, а только опыт работы с инструментами, библиотеками, фреймворками, архитектурами и опыт общения с коллегами / заказчиками.
Странно, а что джун этого не может знать?
abstract/sealed — да уж, джун не потянет…
Конечно может, но это от него не требуется.
Знания того как работают виртуальные вызовы это и есть «опыт работы с инструментами». Рантайм это инструмент.
Конечно может, но это от него не требуется.Джун читает книгу о языке, и в той книге всё написано, как он может не знать?
как работают виртуальные вызовыэто в книге по с++ написано, и в книгах по другим языкам.
Или почитав книгу о таких вещах, я сразу перестал быть джуном?
А если бы я не знал этого, то я не синьер? В работе мне эти знания ни разу не пригодились. А если бы задача про это стояла, я бы как нибудь через гугл вышел и на решение и на знание.
А если бы я не знал этого, то я не синьер?
Очень-очень сомнительный сеньор.
В работе мне эти знания ни разу не пригодились.
Значит такая работа была.
Работы были разные и хорошие и всякие.
А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
Ну то есть, вам тоже это ни разу не понадобилось, так?
#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
От незадача! Как так?! :(
В вашем тесте сравнивается не виртуальность/невиртуальность но инлайн/неинлайн. Это уже немного о другом.
Я про случаи, где добавление/удаление словa «virtual» меняет семантику и результат выполнения кода.
а виртуального вызова нет, компилятор всё заинлайнил.
Ну вот именно, там вызов невиртуальный. А был бы виртуальный — и заинлайнить бы не вышло :)
То есть заинлайнить можно тогда, когда компилятор может заменить виртуальный вызов обычным, что уже отдельная оптимизация (и после нее не обязательно будет следовать инлайнинг).
http://ithare.com/c-performance-common-wisdoms-and-common-wisdoms/
Он есть. Но не он решает.
Виртуальные вызовы конечно же заметно медленнее прямых.
Но ваш тест абсолютно некорректен.
Если бы вы скомпилировали без оптимизаций, я бы сказал что это нечестный бенчмарк, т.к. в продакшене всегда включают -O2.
Но, судя по результатам, вы таки включили O2. И компилятор не только заинлайнил вызовы, но и векторизовал их.
>> А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
> Любая работа, где необходимо хоть примерно представлять, насколько виртуальный вызов дороже невиртуального, почему так происходит и как этого избежать.
Допустим, оппонент не знает как устроена таблица виртуальных методов. Это конечно печально. Рассказать, как она устроена — сам бог велел. В противном случае зачем задавать такой вопрос? Опять же «Бросая камушки в воду смотри на круги расходящиеся дабы не стало это занятие пустой тратой времени».
Но вот выводы — чем это грозит а тем более с точки зрения производительности системы — я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
Напротив, это совсем не повод замыкаться в своем невежестве. Нужно читать умные книжки про оптимизацию, не стесняться лезть «под капот», развиваться шаг за шагом. Это показатель опыта, а не: «Я 15 лет хреначу CRUD'ы интернет-магазинов и делаю это быстрее всех, поэтому сеньор».
В .NET, на виртуальных методах будет проверка на нулевой указатель, а в некоторых случаях еще и копирования объекта в стеке перед каждым вызовом. А если объект, к примеру, толстый, то туши свет.
По поводу джунов и книг. Есть разница между «прочитать в книге» и «понять как оно работает». У джуна эти знания как влетят, так и вылетят. А потом на собеседовании он не вспомнит нужное слово или не сможет описать суть.
Есть классификации программистов, которая мне лично нравится:
Джун — тот кто решает простые проблемы сложным путем.
Мидл — тот кто решает простые проблемы простым путем, сложные сложным.
Сеньер — тот кто решает сложные проблемы простым путем.
Вот я и интересуюсь что это за работы. Какой спрос, какая плата. Я ни разу не дебажил ничего связанного с VMT.
Если не писать квадратичные алгоритмы и использовать кэши, то в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Конечно игры и 3D могут требовать иной подход, но спрос на подобное, в процентах ИМХО ничтожен.
в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Типичное бизнес-приложение балансирует на грани «дешево, юзеры еще не жалуются, что из-за тормозов невозможно работать» и «нужно бы виртуалке больше оперативки накинуть». Ибо фичи нужно пилить, некогда рефакторинг, да еще и тестировать потом…
Вы как будто анекдот не помните...
В институте на разных курсах задают вопрос: сколько будет 2 умножить на 2?
Первокурсник: (бодро) 4!
Второкурсник: (достаёт таблицу умножения, смотрит) 4!
Третьекурсник: (достаёт таблицу логарифмов, смотрит, считает) 4!
Четверокурсник: (достаёт логарифмическую линейку, щёлкает пару секунд) с удвлетворительной точностью — 4!
Пятикурсник: Да что я вам, слон — все константы наизусть помнить?!
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики
Знал как устроена VMT еще в школьные годы. То есть это до джуна.
Затем забыл за ненадобностью.
Сеньор даже на уровне паттернов работает уже на уровне уровне автоматизма, а вы про какие-то байтики спрашивайте.
Если этот сеньор будет разрабатывать компилятор — то знание VMT будет ему крайне нужно.
Иначе — зачем?
Приведите конкретный кейс, пожалуйста.
Что такое virtual?
Бам!
Слово вам как раз сказали, вы забыли связь слова с его значением. Это уже не так невинно звучит.
Понимаю, что заклинить может (надосып, переработка, бодун...) кого угодно, но зачем за столь очевидный косяк переводить стрелки на интервьюера? Вопрос достаточно очевидный и это совсем «не пыльный угол» сишарпа.
Проблема как раз в том, что я начинаю размышлять так же, как вы, и сам себя определяю как самозванца.
Каким образом это является проблемой?
class object : object
{ }
Мои шестеренки сразу заклинило, я с трудом выдавил «нет» и на вопрос «а как сделать, чтобы можно было?» я не ответил, потому что не мог понять, что от меня вообще хотят и зачем это надо. А собеседующий всего лишь хотел услышать, что я знаю как работать с префиксом @:
class @object : object
{ }
Если не ошибаюсь, есть специальный веб-сервис для таких «переворотов»
В мире столько вещей которые любопытно изучать — жизни не хватит. Тут не про воротить нос, а про целесообразность. Дело не в новом, а в выгодном.
новое — не всегда интересное. область моих интересов в it, например, как правило работодателю не нужна. а нужны реакты, редуксы и прочии нахайпованные go
github.com/aeroflotsrc/webapp
Интересная штука. Почему все работодатели боятся нанять «самозванца», но при этом не боятся отдавать заказ подрядчикам? И ведь собеседований с ними не проводят же.
При том, что на моём опыте подрядчики даже с известным именем могут совершить такие лютые факапы, что даже отдел самозванцев на сможет с ними сравниться.
При этом они еще регулярно нанимают самозванцев — профессиональных проходильщиков собеседований.
Наверное потому, что подрядчика легче сменить, чем наёмного работника по ТК)
Так есть же испытательный срок. Ну или вначале вообще можно временный договор заключать. И по ГПХ можно работать. Много всяких вариантов.
Я сам провел не один десяток собеседований, и мне кажется, что научился это делать не совсем плохо. Так вот, я сам на собеседование с тестом на бумажке просто не пойду: постараюсь выяснить регламент заранее и если там подразумевается нечто подобное — сразу откажусь. Я готов притащить ноут, показывать свой код, рассказывать о своих проектах и говорить на любые профессиональные темы. Готов выполнить тестовое задание адекватного объема. Но от этого тупняка с бумажками у меня глаз дергается. Думаю что если боевой разработчик, проводящий техническое интервью, не способен разглядеть самозванца через пару-тройку общих вопросов — то грош ему цена и место в детском саду.
По-моему, у боевых разработчиков часто нет времени на проведение интервью :)
А случаи, когда в одном человеке есть и глубокие тех. знания, и хорошие soft skills, и правильный настрой не заваливать и самоутверждаться — крайне редки.
По-моему, у боевых разработчиков часто нет времени на проведение интервью :)
Ну в разных местах команды формируются по разным принципам: в бодишопах действительно, все будут заняты и не смогут далеко отойти от капельницы с глюкозой. А в проектных командах людям бывает не все-равно с кем идти в бой, поэтому они сами очень заинтересованы и находят время. Но, тем не менее, редко кто может правильно поговорить. С обеих сторон =)
Проблема в том, что бумажка вам не скажет о уровне разработчика ВООБЩЕ НИЧЕГО. Только реальный код реальных проектов и общая инженерная философия человека. По моему опыту, люди блестяще проходившие бумажные тесты часто оказывались полнейшими мудаками в работе, и напротив, люди сомневающиеся и робкие показывали себя как офигительные и весьма ценные специалисты, ко мнению которых стоит прислушиваться всегда.
«бумажка вам не скажет о уровне разработчика ВООБЩЕ НИЧЕГО»
Она скажет:
1) об умении сначала думать, потом делать и делать аккуратно
2) писать не очень сложный код без ошибок
3) придумывать алгоритмы для сформулированных задач в ограниченное время
4) о знании базового синтаксиса языка без Google и SO. Например, сколько раз я уже видел кандидатов, которые путают названия контейнеров в STL и их методов, по ним сразу видно, что hands on опыта с ними они не имеют. Разработчик, который не помнит, что в вектор добавляет метод push_back — это очень интересно, конечно :)
Я вовсе не предлагаю использовать бумажку (В значении coding interview) как единственный способ проведения собеседования и не утверждаю, что это единственный способ проверять skills. Но это достаточно действенный способ, который имеет распределение успехов, по которому можно неплохо пытаться определяться уровень в том числе. Скажем, вы даете написать 3-4 алгоритма разной сложности (подразумеваю, что речь идет о позиции, что где алгоритмы являются критичным навыком), далее можно построить распределение, по которому будет видно, что большинство справляется с 1-2 задачами с разной чистотой выполнения оных и далее все идет по убыванию. Действительно редкие специалисты способны закодить все 4, не допустив или почти не допустив ошибок. Если в вашей работе почти каждый код — это алгоритм, то такая проверка уже, на самом деле, многое скажет о том, что вы можете ожидать, наняв человека. Между «писать код на бумажке» и «писать код на ноутбуке» с моей точки зрения разницы не очень много, т.к., например, лично я почти не даю на собеседованиях реально технически сложных для кодирования задач, которые без клавиатуры делаются просто напросто долго, но некоторые этим злоупотребляют.
Вы пытаетесь применять редукционистский подход к очень сложной хаотической системе, включающей кучу аспектов, которые вы не видите и не хотите учитывать: факторы среды, эмоциональный и социальный бэкграунд, нюансы специализации и конкретного опыта… Таким образом, математически можно обосновать почему ваше итоговое распределение будет принимать формы, весьма далекие от реального положения вещей (см. теорию хаоса). Ваш список рассыпется полностью и уже на этапе добавления в систему факторов психологической реакции на тесты. Ваш метод с бумажкой — это иллюзия контроля в чистом виде, банальный способ переложить ответственность на примитивную методологию.
весьма далекие от реального положения вещей (см. теорию хаоса)
Ну и какое же реальное положение вещей, просветите пожалуйста? :)
банальный способ переложить ответственность на примитивную методологию
Ну а ваша то методология какая? Демонстрировать написанный код? Хорошо, а если ваш код не покрывает тех случаев, которые бы я хотел увидеть? Готовы дописать ваш код прямо на собеседовании? :) Ведь это будет сложнее, чем начать сначала на абстрактной задаче. Дальше: где гарантия того, что этот код написан самостоятельно и что он написан в приемлемые сроки? Где гарантия, что этот код вообще правильный? Итд.
Так вот, я сам на собеседование с тестом на бумажке просто не пойду: постараюсь выяснить регламент заранее и если там подразумевается нечто подобное — сразу откажусь. Я готов притащить ноут, показывать свой код, рассказывать о своих проектах и говорить на любые профессиональные темы. Готов выполнить тестовое задание адекватного объема. Но от этого тупняка с бумажками у меня глаз дергается
Хочу точно такое же, но много ли компаний сейчас разделяют ваш подход? Можно ли как-то распространить такую практику чтоб в мире стало поменьше говнособеседователей и побольше адекватных?
Позвольте немного рассказать как обычно идет процесс найма, возможно у вас отпадут некоторые вопросы.
Первый этап. На нем нужно узнать что кандидат проходит минимальные требования. Потому что тратить полтора часа рабочего времени на то чтобы понять что мы друг другу не подходим — это много. Поэтому обычно его проводит HR. Тут есть несколько вариантов: просто посмотреть резюме, дать тестовое, дать небольшой опросник. Я лично считаю что достаточно посмотреть резюме, но вариант с опросником тоже хорош, так как он дает темы для общения на втором этапе собеседования.
Второй этап. Здесь уместно провести личное общение с теми, с кем непосредственно будет работать кандидат. Задача собеседующего понять, будет ли комфортно вместе работать. Тут несколько аспектов: опыт, технические знания, личностные качества, потенциал развития, насколько хорошо кандидат вольется в коллектив. И да, если это скайп, то желательно с видео. Очень полезно видеть реакцию человека. Самый простой путь, на мой взгляд, сначала послушать человека о его опыте, идеях и вообще все что ему интересно рассказать. Это и расслабляет кандидата, и в то же время дает 90% всего что вы хотите знать, и дает темы для технических вопросов. Затем перейти к техническим вопросам, может порешать какие-то задачи, дабы просто послушать ход мыслей собеседуемого. Обязательно нужно рассказать про свой проект, чем придется заниматься кандидату, какие у него перспективы и ответить на вопросы.
Третий этап. Общение с начальством, HR о условиях, деньгах и все такое.
Озвучьте блин проблему, я скажу как ее решить.
Может мне тогда тоже начать сыпать вопросами нонстоп?
А как же. Это нормально, когда и кандидат спрашивает, что его интересует, и про процессы, и про задачи, и даже просит рабочие места и другую инфраструктуру (комнаты отдыха, кухню, туалеты) показать. Меня один кандидат однажды больше часа выспрашивал разные детали, хотя перед этим я его больше получаса сам рассказывал про компанию в общем и про разработку в частности.
*Тоном экзаменатора*
— Два монитора конечно же на рабочем месте?
— Столешница толщиной не менее 2 см?
*как будто обращаюсь к двоечнику*
— Ну CO2 то хотя бы контролируется?
— А говорили солидная компания...
Вот примерно так это бы выглядело зеркально, ибо как раз так оно и происходит со стороны работодателя: не относящиеся к делу случайные вопросы в таком тоне, что аж руки вытереть потом хочется.
— Здравстуйте, вы ээ (читая резюме и анкету) ага Вячеслав, да точно
— Вы я вижу с PHP работаете, о а что такое __autoload
— Как незнаете? базовые же вещи!
— Ой а я вижу вы еще postgreSQL работаете? Расскажите как работает файловый кеш линукса. Ну как зачем, у нас серьезная производительность!
— О а гит! Вы же должны знать команды. Как не работали?
По мне выглядит одинаково. Со стороны соискателя даже поадекватней будет. Я это вот все слышал раз 20 как минимум в разных вариациях, с менторским тоном и взглядом как на говно, и я буду продолжать говорить «не знаю», потому как либо у нас таки случиться интересный диалог либо «вы мне не подходите».
Я даже объясню почему. Тот же автолоадер, когда он мне понадобился я взял из какого то фрейма, переписал под свои реалии, подключил и забыл. Я помню свой код почти построчно, но помню я почему и как он работает а не названия функций.
Систему контроля версий я лично не использую, оно мне не надо, когда нужно я открываю документацию настраиваю и забываю.
Если при использовании бд вы упираетесь в производительность диска, и при этом база и wal и журнал фс у вас лежат на разных дисках, то вы делаете чтото сильно не так. И не надо смотреть на меня как на идиота, исключение — серьезные объемы данных, и нет 100 млн записей это не тот случай.
Я с удовольствием пообщаюсь с коллегой, я всегда рад, правда. В режиме доброжелательного диалога, на тему любимых и нелюбимых штук например. С обоснованием естественно. Но такое случается крайне редко.
Систему контроля версий я лично не использую, оно мне не надо, когда нужно я открываю документацию настраиваю и забываю.
Это не характеризует вас как сколько-нибудь хорошего разработчика. Скорее как пафосного дилетанта.
Это не характеризует вас как сколько-нибудь хорошего разработчика. Скорее как пафосного дилетанта.
Ну вот о чем и речь собственно. Откуда столько токсичности? Где пафос то? Откуда выводы о дилетанстве. Будьте добры аргументов накидать.
Когда заказчику нужно я ее цепляю в IDE и веду согласно требованиям. Зачем мне лично система контроля версий?
Вы, я так понял, выступаете наглядным примером к тому о чем я говорю? У вас получилось. Сделали выводы, вынесли вердикт, плюнули в душу, ни на один вопрос не ответили. Оппонента спросить или подискутировать? Да нахрен оно надо, правда?)
Вы утверждаете, что а) имеете опыт разработки в команде, б) команде СКВ не нужны.
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».
А ведь не дурак был коллега, просто тоже знал о рабочем инструменте комманды полдесятка комманд, и не имел ни малейшего желания узнать чуть больше.
Не вы ли там говорили, что предпочитаете инструменты, где отстрелить ногу нельзя? Тогда зачем сами даете заряженный пистолет ребенку?
Но если поднять бэкап вайпнутого гита, то не потеряется совсем ничего, на то оно и распределенное. И чтобы поднять бэкап, в общем случае, не надо даже сервер трогать.
Да что там говорить, гит и бэкапить-то не надо, в общем-то, для обычной неспешной разработки.
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
Это не вечный холивор, это стандартная практика.
«Стандатная практика» — это применяемый вами метод. Холивор — это о выборе метода. Разные категории, через «не» не противопоставляются.
Ну потому что пушить в мастер вообще может лишь один аккаунт,
На этом можно и закончить. Это абсолютно нереалистичное ограничение для моей команды.
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
Абсолютно верно — для ряда задач лучше ограниченный андроид.
Посмотрите хотя бы на ядро линукса. Большой проект. Лет 20 уже на гите. И до сих пор ни разу никто не накосячил по-крупному. Вы же не думаете, надеюсь, что это от непогрешимости линукс-разрабов?
И не рассказывайте мне, пожалуйста, что существует какая-то СКВ, которая не позволяет при наличии полного доступа к серверу убить репозиторий.
всем в голову
Простите, это как, если доступ к изменениям общей ветки только через пул-реквесты и код-ревью?
На этом действительно можно закончить.
Это всё-равно, что нанять в качестве водителя человека, который пришел на собеседование пьяным, а потом жалеть, что современные машины слишком часто попадают в аварии, с лошадьми было лучше
Из «админского»…
Сисадмины делятся на 2 категории:
1. Те, которые еще не делают бэкапов.
2. Те, которые уже делают.
Не забываем про:
3. те, кто уже проверяют, что из бэкапа можно восстановиться
А вы, очевидно, просто любитель, которому до сих пор нужны версии, код ревью, рефакторинг и прочие любительские техники, недостойные настоящих программистов!
Ноут к тому же прям совсем не мое. Я люблю удобное кресло, хороший монитор, музычку или сериал фоном и самое главное удобная клава 8)
что вы зашли куда-то в тупик, и хочется вернуть всё взад и начать сначала?
В тупик? как правило нет. Как только дорастает до определенного уровня то начинаю серьезно переделывать. Иногда с нуля.
И СКВ освобождают от этакой скованности в экспериментах, вызванной страхом, что вернуться назад не получится.
Вот как раз такого страха не бывало
Но это именно командная разработка, поэтому просто к слову о разных ситуациях.
В соло-разработке и пет-проектах 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 лет без СКВ, то он к этому привыкает, и все варианты, которые бы использование СКВ предполагали — отсекаются на подсознательном уровне. И в итоге потом "никогда не приходило в голову, зачем это может понадобиться, фигня какая-то".
Тут главное в том, что это, по факту, ничего не стоит.
git init написал, сделал первый коммит, поправил gitignore и все (меньше 5 минут в совокупности). Может, потом оно не понадобится особо — так 5 минут и не жалко ведь.
Но почему то что ни просят доработать, какой продукт не возьми, везде какой-то бред происходит.
А вам не приходило в голову, что «если третий муж бьет по роже, то виновата рожа»? Может вас в этот мир просто не берут, потому что вы на этот мир смотрите свысока, или, возможно даже, вообще не понимаете как там что работает? Это я так, food for thought
А вам не приходило в голову, что «если третий муж бьет по роже, то виновата рожа»?
Ну во первых причем тут рожа, если например врубаешь slow_query_log и он за 5 минут заполняется сотней разных запросов?
А во вторых, согласитесь: если третий муж бьет по роже, то все таки третий муж мудак.
Может вас в этот мир просто не берут
Если он где то и есть то явно не в веб разработке. Или не в этом городе. Хотя опыт общения с крупными сервисами намекает…
вообще не понимаете как там что работает
Как правило, тривиально, на самом деле
Программист, сегодня отказывающийся от СКВ — это как бухгалтер, отказывающийся от ЭВМ, мол «мне на бумаге и счетах норм, я так привыкла. Зачем мне лично ваш компьютер?»
Поймите меня првильно, не понта ради а понимания для.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии. Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Ну, во-первых, те кто вас критикует выше, говорят о командной разработке.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии.
Тут два момента. Я стараюсь, и с каждым годом все лучше. Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались. Ну и KISS.
Второй момент я просто помню все что написал. Могу забыть номер дома и день рождения супруги, но помню весь год за 15 лет.
Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Благодарю. Я подумаю над этим. Пока не приходилось.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Я понимаю вашу точку зрения, но. поскольку СКВ при командной разарботке — стандарт отрасли, стоит настаивать на его использовании независимо от мнения заказчика. Это вопрос профессиональной этики — не идти на поводу у клиента, если он заказывает откровенное г-но.
Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались.
Разумеется, это трезвый подход. Но каждую строчку не прокомментируешь, а подчас приходится добавлять какие-то граничные случаи или что-то подобное, назначение чего неочевидно. С коммитами хотя бы видно, в рамках какой задачи внесено то или иное изменение.
Это важно и для другого — допустим, вы применили в каком-то проекте решение специфической проблемы, но не помните в точности всего решения (допустим, оно объемное и/или разнесено по модулям, дописано частями в разное время и т.д.). Из СКВ мы можем извлечь diff'ами эти блоки и посмотреть на решение в целом.
Если вашим кодом кто-то пользуется кроме вас, надо держать как минимум две ветки — грязную dev для разработки и чистую для внешнего мира — вы же не будете напрямую править то, что есть у клиента? Если будете, и что-то сломается, надо будет срочно откатывать назад и т.д.
Это вопрос профессиональной этики — не идти на поводу у клиента, если он заказывает откровенное г-но.
Касаемо продуктов я всегда стараюсь так делать, но касаемо прочего, в тч инфрастуктуры… знаете я устал. Очень часто консультирую по инфрастуктуре как сторонний консультант и как CTO и практически всегда хозяива бизнеса предпочитают покласть на все и въехать в пенек побольше.
Я очень люблю возиться с БД и раньше часто брал заказы на оптимизацию/аудит, но перестал, потому как список рекомендаций не выполеняется никогда, говнокода становиться только больше и заказчик вовзращается с практически мертвым сервером, получая барьерные цены.
Первые 100 раз было еще хотя бы смешно. А теперь я лучше посижу и сделаю еще что нить работающее в десятки раз быстрее аналогов, но для себя, чем снова буду убеждать сделать правильно.
Если система собирается не на коленке, а централизовано, с сохранением версии, 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-виртуалок, на которых продукт крутится, не в абсолютной точности соответствует конфигурации девелоперских машин. Как уже отмечали ниже — обычно виной системные библиотеки. Например, девелоперу в работе нужен какой-то продукт, его инсталляция притащила с собой тучу библиотек (зачастую непонятно почему), которые продукт прозрачно подхватил. Стали запускать на виртуалке — продукт падает ввиду отсутствия библиотек (и при этом не говорит, каких).
Работодатель не хочет платить вам за изучение инструмента, являющегося стандартом в отрасли.
Для изучения гита на уровне комфортной работы достаточно часа-двух, о чем вы вообще, ну?
А если он при этом еще и утверждает, что «имеет богатый опыт командной разработки». И за весь «богатый опыт» тоже 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. Он не знает (что, по сути, в случае с гитом не страшно), но решил скрыть этот факт от вас, солгав на собеседовании (а это уже сильно хуже).
И вот тут, честно говоря, совершенно не важно, обиделся соискатель, или просто врет. В обоих вариантах он не подходит.
Хотите другой пример? Менее общий. Я ровно так же могу сказать «понятия не имею» по токностям работы журнала упреждающей записи postgresql, типам индексов и алогритмам объединений. И если случается нормальная беседа то:
1. Конечно вобщих чертах я знаю как работает WAL, но даже помнить о его существовании разработчику в общем то незачем
2.
— Как правило используется b-tree и только.
— hash индекс, за исключением случаев, когда создается самой базой, применять не стоило, во всяком случае до последнего времени, он порождал больше проблем, чем решал. Да и собственно быстрее он может быть только при поиске точного совпадения.
— GIST довольно редко используется, если вы не работаете с геоданными и интервалами
— GIN необходим если вы ищете частичное вхождение. В принципе gin_trgm_ops это то, что должен использовать вообще каждый если у вас есть поиск по справочникам.
— BRIN даже рассматривать не стоит если у вас не стоит задачи экономии дискового пространства.
UPD:
совсем забыл SP-GIST но я лично так и не придумал кудаб его приспособить, если не работать с геометрией.
Как видите, можно годами работать с postgresql и использовать только b-tree и этого в принципе достаточно. По идее это все таки работа архитектора бд, ибо за исключением построения триграмм (которым нужно возносить молитвы (хотя если у вас малый объем данных или нет частичного поиска, то необязательно)) все остальное важно когда есть большой объем данных и серьезная нагрузка.
Неплохо бы конечно помнить что у пг есть функциональные индексы, штука прям читерная, но фунция должна быть immutable.
Ну а алгоритмы объединения за пределами explain вам вообще помнить незачем, а внутри уже все очевидно. Да и названия у них говорящие. Перечислять по памяти, даже если кто помнит, бессмысленно, потому как еще важен объем данных, объем оперативной памяти, сложность запросов, актуальность статистики таблицы итд
Итого в общем случае, backend-разработчику нужно знать о том что индексы есть. Писать читаемые параметризованные запросы и радоваться жизни. В вебе я все чаще вижу бред, вроде фукнций в условии, без построения индекса по ней (а Mysql вроде и не умеет), искоренение такого куда более важно, за это нужно бить топором по пальцам.
Любой навык можно получить за конечное время, вопрос в том, что у бизнеса этого времени как правило нет. Не джуна на обучение нанимаем вроде.
Ок. Но адекватный работодатель будет проверять другое. А если окажется, что соискатель подходит, но не знает git, то просто попросит прочитать «git basic howto» перед началом работы.
С одной стороны да. С другой, если на гит завязано много чего, то может и не подойти. Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Хех, если система настолько сложная и custom'ная, то где этому соискатель научится — дома на пет-проектах?
Так что да, человек уже знает про гит, остается только ему дать информацию, что «вон ту штуку которую ты знаешь мы еще используем таким образом, а эту — таким». Это драматически уменьшает время на интеграцию в новый проект.
а в том, как вы это делаете.
Зы теперь я с еще бОльшим упорством буду говорить «не знаю» )
Ну вот это больше всего характеризует вас как конфликтного человека с несколько завышенным самомнением. Не берем.
Я как то работал в маленьком офисе где вентиляции нет. Сначала не очень понятно было почему когда выходишь покурить в глазах светлеен не порядок, а потом когда все под вечер вырубаться начали — дошло. Работал так же рядом с химзаводом, незнаю есть ли связь, но сидел я рядом с открытым окном и в какой-то момент просто аж на стол падал. Думал не высыпался, но выходил, садился за руль, и по пути начинал себя подрячком чуять без намека на желание спать.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Я вот даже если понял, что кандидата буду сливать, никогда не прекращаю интервью сразу, конечно часть вопросов уже долгих пропускаю, но о компании рассказываю по полной. Т.е. установка такая, что кандидат, даже если нам не подошёл, должен уйти довольный.
это форма экзамена
В таком случае, вероятно, студенты, вызубрившие справочник — лучшие программисты?
Я кстати напомню, что даже гугл признал, что понятия не имеет как правильно собеседовать. Где то встречал даже статью об околонулевой корреляции успешного собеседования с качеством работы сотрудника.
Но вот честно, на внезапный вопрос что такое virtual, я наверно даже через минуту не отвечу правильным определением. А это значит провал собеседования. Это значит что любой джуниор сразу после универа будет выглядеть круче меня… на собеседованиях.
И да — теперь, пока за мной не будет стоять мой код, на собес я не пойду.
Можете раскрыть мысль?
Опять-же, вы согласитесь писать тестовое бесплатно в течении недели? И как вы докажите что код, ваш?
Вы не подумайте, я и сам не очень толстокорый. Просто не вижу другого выхода. Для себя нашел решение — не работать на русскоязычных начальников и заказчиков, вообще. Англоязычные более вежливые, менее напористые, менее авторитарные, они готовы уступать и разговаривать. А русскоязычные вечно строят армейскую дисциплину. Ну или мне так везло. Ну и кстати, я самозванцев не оскорблял, говорил «мы подумаем и если что свяжемся с вами». Не думаю что у них после собеседований были эмоциональные проблемы.
Бизнес почему-то безумно боится самозванцев
Потому что один не опытный спец способен загубить при некоторых условиях бизнес на корню, если бизнес сильно зависим от ИТ.
Я как-то по молодости убил БД, копию не сделал.
После этого предприятие сильно скатилось вниз две недели восстанавливая базу и практически не работая, потом еще пару месяцев работая не шатко не валку. Конкуренты не дремали в это время.
Предприятие так и не поднялось до былого уровня.
В вашем случае вина делится долями между вами и теми, кто вам доверял. Это нормально, что за свою беспечность владелец бизнеса платит из своего же кармана.
Строго говоря, с точки зрения бизнеса вы вообще не виноваты, если у вас не было злого умысла.
Я как-то по молодости убил БД, копию не сделал.
Девопса/сис.админа на предприятии не было? Туда им и дорога.
Девопса/сис.админа на предприятии не было? Туда им и дорога
Ну дык я ими всеми и был.
А выделенный сис.админ — это очень круто. Вы представляете себе что такое малый бизнес?
У нас в студии из 2х разработчиков был отдельный сис. админ т.к. время обоих разработчиков стоит несоизмеримо дороже времени сис. админа.
Junior, который в первый день работы удалил базу данных с production
Так это вопрос разграничения доступа. Именно поэтому логично иметь некую тестовую БД, хотя бы просто копию. И новобранцев отправлять на неё, никакой боевой БД.
А бекапы у вас не делались?
Что такое virtual?Вот тоже в тупике от этого вопроса. Столько всякого мозг сразу вспомнил, что даже не знаю что бы выбрал.
Ну, в целом, да. Наследование работает и без 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();
А где именно в вашем примере полиморфизм?
А где именно в вашем примере полиморфизм?
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 — однозначно полиморфный, ведь он ведет себя по разному, в зависимости от того, к какому подтипу относится объект.
Допустим, у меня два разных класса (не в общей иерархии, просто два разных класса). У каждого из них есть метод foo, определен он по-разному. У объекта одного класса вызвали — результат один, у объекта другого класса — результат другой. Следует ли из этого, что метод foo — полиморфный? Если нет, то почему?
Допустим, у меня два разных класса (не в общей иерархии, просто два разных класса)
Так это не в общей. А тут общая иерархия и метод предка. Классический полиморфизм в ООП понимании, не забудьте про соблюдение LSP.
У каждого из них есть метод foo, определен он по-разному. У объекта одного класса вызвали — результат один, у объекта другого класса — результат другой. Следует ли из этого, что метод foo — полиморфный? Если нет, то почему?
Давайте более конкретный пример, хорошо? Вот есть классы Array, HashMap, Tree. В иерархию не входят. В каждом есть функция map(), интерфейс один. Полиморфная ли это функция?
Так это не в общей. А тут общая иерархия и метод предка.
То есть, полиморфизма нет, но вот я добавляю общего предка (при этом поведение программы никак не меняется) и полиморфизм появляется? Но как же это так, ведь выше рассуждения как раз о том, что полиморфизм определяется как раз по поведению, а остальное все — черный ящик?
Полиморфная ли это функция?
Следуя моей логике — безусловно, нет, точно так же как не являются полиморфными ф-и из примеров выше. Следуя вашей — безусловно, да.
Следуя моей логике — безусловно, нет, точно так же как не являются полиморфными ф-и из примеров выше.
Посмотрите хотя бы в Википедии, что такое полиморфизм.
Я-то знаю, и не только из википедии.
Полиморфизм в обсуждаемом контексте = позднее связывание.
Естественно, у этого термина есть и другие значения, но не стоит подменять понятия.
Это, кстати, легко доказать, вот есть такая штука, что три ключевых концепции ООП — это инкапсуляция, наследование и полиморфизм. Но наследование и полиморфизм подтипов (если подтипы номинальные) — это одно и то же. Следовательно, либо упоминаемый тут принцип полиморфизма — это не наследование (то есть не полиморфизм подтипов), либо у нас второй принцип совпадает с третьим. Вы какой вариант предпочитаете?
Так никто не спорит, что полиморфизм есть. Просто он в методе NonPublic, а не в методе NonVirtual.
Полиморфизм — это способность функции обрабатывать данные разных типов. Этой способностью обладают оба метода.
Это замечательно что вы прочитали статью из википедии, но мы тут обсуждаем совсем не этот полиморфизм.
В частности, согласно этому определению полиморфизмом являются перегрузки методов (ad-hoc полиморфизм типичный), однако на практике перегрузку полиморфизмом никто не называет.
В данном случае здесь не надо путать математическую модель (о чем и речь в случае subtyping-полиморфизм, и это никак вообще не связано с наследованием) и механизм позднего связывания (что подразумевается под полиморфизмом в контексте ООП и связано с наследованием напрямую).
Так вот. В обсуждаемом коде функция 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, сами А прекрасно наследуются и соответствующие ф-и полиморфны, все в порядке.
Где? Я не вижу в примерах создания подтипа.
Эта конструкция собственно и объявляет структуру/класс подтипом другого типа. По спецификации языка. С чем вы тут пытаетесь спорить — ума не приложу.
сами А прекрасно наследуются
А я где-то утверждал, что не наследуются? Наследование и полиморфизм — оргогональные понятия.
и соответствующие ф-и полиморфны, все в порядке.
Не знаю, о каких "соответствующийх функциях" вы говорите (надеюсь не съехали на позднее связывание?), но если я не могу вместо одного типа где угодно подставить его подтип, то полиморфизмом подтипов тут и не пахнет.
Эта конструкция собственно и объявляет структуру/класс подтипом другого типа.
Я не понимаю, с чего вы это взяли.
По спецификации языка.
Ну там неправильно написано. Демонстрируемое в примерах поведение этому не соответствует. Либо под "подтипом" подразумевается что-то другое. Нигде это значение не ведет себя как подтип, оно просто ведет себя как соответствующее поле, то есть выполняется неявная конверсия. И неявная конверсия — это не подтипирование. Неявная конверсия и подтипирование ведут себя по-разному, и эту разницу можно пронаблюдать.
А я где-то утверждал, что не наследуются?
То, что наследуются — утверждал я, а вы это оспаривали. Если вы оспаривали мое утверждение — с-но, утверждали нечто обратное, разве нет?
Наследование и полиморфизм — оргогональные понятия.
Мы же уже выяснили, что наследование и полиморфизм подтипов — это одно и то же, как понятие может быть ортогонально само себе? Невозможно реализовать наследование без полиморфизма подтипов и наоборот.
Не знаю, о каких "соответствующийх функциях"
Я говорю о любых ф-ях, которые принимают А (они же могут принимать и любой подтип А, то есть полиморфизм подтипов есть).
но если я не могу вместо одного типа где угодно подставить его подтип, то полиморфизмом подтипов тут и не пахнет.
Но вы можете.
Вывод достаточно очевиден — если на собеседовании было некомфортно, то в самой компании вряд ли будет лучше — будете иметь дело с такими же самодовольными чуваками, просто потом они будут ставить такие же бессмысленные задачи.
Самодовольство человечка, проводившего собеседование говорит только о том, что они на поиск сеньора отрядили начальника или зам-начальника, и им важно не облажаться с самозванцем.
А чем выше должность в вакансии, тем выше риски. Бывает, что ищут замдиректора, там вообще сливай воду — туши свет, говорить умеют все, работать — один на тысячу.
Бывают соискатели, которые берут код своего тимлида и выдают за свой, например, выкладывают на Гитхаб.
Поэтому и актуален и вайтбординг, и опрос по базовым вещам. Такова реальность.
К вайтбордингу легко подготовиться, прорешивая задачки с LeetCode, например.
Может быть подкинете мне мне какую-нибудь «домашку». Хочу сделать что-нибудь реальное. Работающее. Нужное. Заодно, изучу новое для себя. Испытаю свои силы. Стану лучше соображать.
А? Пожалуйста!
И знаете, ситуация точь в точь такая же.
Был в одной компании, такое знаковое собеседование, побеседовал с старшим админом (искал сменный график, а это в основном тп), простой мужик, простые вопросы, спокойная беседа, и вдруг вваливается ЭТО… кашляя, задыхаясь, чихая во все стороны — начальник ИТ отдела!
Первый вопрос — какая команда в цискаре нужна для вот этого (уже не помню сути).
мысли путаются, ладошки потеют, последний раз кошака мацал год назад — не помню.
Итог — с гордым видом рассказывает мне пошагово от и до как мацать кошку… и похуй что в мои обязанности даже близко не будут стоять блохастые. Давай, дасвидания.
И почти всегда всё в таком же духе, реально как в школе…
p.s. а ещё все очень сильно удивляются, что на моём текущем месте работы очень редки форс-мажоры. всё исправно и стабильно работает, и нет ацких «юзверей». и хер им докажешь, что грамотно отстроенные системы и регулярный контроль решают, и что людей можно выдрессировать не «сувать в принтер скрепки»…
только у меня не бомбит как у тс, у меня депрессия =)
Сколько народу набрал в своё время, вообще о таких опасениях не задумывался.
Приходит человек, спрашиваешь опыт — сразу задаёшь любой вопрос из деталей рассказанного, сразу видна правда или ложь. Приходят зелёные, но хотят работать — через год-два они заткнут многих "сеньоров".
Мне реально хватало 15 минут чтобы понять — брать человека или нет. Набирали конвейером. Ни разу не пожалел.
Самые адекватные компании — это где либо HR не участвует в отборе и нет рекрутеров, либо же где реально клёвые ребята на этих местах — сами бывшие технари.
P.S. Один раз мне отказали в интервью, т.к. в списке скиллов не было Ajax, но был JS и React.
Мне тоже доводится частенько собеседовать самых разных людей на позиции SE. Я вижу, чем люди занимались. Я знаю, чем им предстоит заниматься. На основе этого я прикидываю, о чем следует поговорить с человеком, чтобы понять _как_ он работал. У моего работодателя есть возможность выбирать между кандидатами, и будь я проклят, если я ей не воспользуюсь.
Т.е. лучше я перестрахуюсь и не возьму пять отличных инженеров, чем случайно возьму одного. Знаете, как идеология гугловых собеседований — ни в коем случае не уменьшать планку уровня уже имеющихся разработчиков, потому что в итоге это приведет к деградации УровняТМ.
Вернемся к тому, _как_ человек работал свои 5, 10, 15 лет стажа. У собеседовающих же нету информации по результатом внутреннего эвалюэйшена по сотруднику в каждом его месте работы. Он мог выполнять несложные задачи, которые давал ему лид, а мог драться и спорить по поводу целесообразности и того, как делать каждую задачу. Мог шлепать по одному и тому же принципу однотипные сайты/сервисы/приложения/etc. А мог постоянно изучать новые техники и подходы к проектированию, анализу и разработке. Мог использовать остальные компоненты системы (ОС, компилятор, соседние сервисы, либы) как блекбоксы, а мог ковыряться в кишках, понимать внутреннее устройство и под каким соусом эти компоненты лучше всего готовить.
Не бомбите. Не горите. Просто либо вам не повезло, либо работодатель и правда искал не вас. На одном сотруднике и на одном работодателе свет клином не сошелся. Благо, мы в IT, можем себе позволить :)
В маленьких компаниях, не претендующих на единорогов, собеседования проводятся по-другому, например. Куда более по-свойски.
Понимаете, спрос-предложение — это и для рынка вакансий и рабочей силы справедливо. Если спроса на отличных спецов, которые не могут знать стандарты языка наизусть, нет — то это уже проблема спецов будет подстроиться под рынок. А не проблема рынка подстроиться под спецов.
Опять тот же гугл. Все знают, что там вайтбординг. Все знают, что там алгоритмы, которые в работе никогда не встретятся. Все знают, насколько там, казалось бы, несуразное интервью. И все равно идут и специально (!!!) готовятся именно к этому интервью.
Если работодатель достаточно хорош и знаменит — ему простят его причуды. Если работник достаточно хорош и знаменит — ему простят незнание чего-либо. А все остальные следуют Невидимой Руке Рынка(ТМ)
Если не сошлись его вопросы и ваши ответы — значит вы друг другу не подходите, очень просто.
Как-то дочитал "Как сдвинуть гору Фудзи" до задачи «как бы вы спроектировали интерфейс видеомагнитофона» — чуть-чуть понял, почему продукты Microsoft немного особенные.
И уже не важно, что я на самом деле стараюсь избегать классического наследования, предпочитая ему композицию, и проектирую свои классы и системы таким образом, чтобы от них не требовалось делать наследников.
Почему так?
Об этом часто пишут в книгах, например Design Patterns
Я уже наблюдаю другую крайность, когда некоторые "гении" полностью отказываются от наследования. Полностью! И кидают в тебя кучу интерфейсов, которые нужно реализовать.
Как говорится, заставь дурака Богу молиться, он и лоб расшибет.
Я не те книги возможно читаю.
Но меня тоже иногда тревожит, когда например, абстрактный класс сенсор имеет наследников на 3-4 уровня. Подобное на проде я бы и сам побоялся сделать.
Но в целом да, более гибко, по обстоятельствам короче.
Ой все эти "гибко и масштабируется" настолько сферический конь в вакууме. У меня на практике выходило так что хорошо спроектированный и написанный код никто масштабировать и гнуть не собирается. а когда таки придет время то там будет проще переписать. А почему? А потому что в хорошем коде уже все продумано и реализованно с учетом возможных изменений требований на ближайшую перспективу. и два там так напроектированно что только сеньеров туда пускать. а то первый джун превратит всю стройную архитектуру в кусок очень сложного навоза.
И какая разница что пишут в книжках про паттерны проектирования. Мы тут сейчас комментируем претендента на должность сеньера. который забыл про virtual… Ну не верю я в это. можно забыть про что то редкое или необязательное. но виртуал я не зная языка скажу что это про наследование, динамический полиморфизм и позднее связывание речь идёт.
Мне кинули предложение — Senior full-stack .NET Developer, удаленно, крутой проект, куча денег. В списке требований хренова гора не связанных между собой вещей из мира .net и js/ts. Выглядит так, будто просто свалили в кучу все, что нагуглили за 10 минут — причем мало понимая, что именно.
Тревожно, но ничего.
Конец немного предсказуем:
Ну привет. Я только что с собеса, и у меня бомбит. Сколько не пишут на Хабре, как правильно собеседовать — лучше не становится.
Странно было ожидать чего-то другого...
Потом приходит и спрашивает то же самое у вас. Это все мы, товарищи, мы и есть такие разрабы. Многие из нас не подходят к вопросам собеседования с прагматических позиций.
В этом месяце меня в Билайн собеседовали. Тоже была куча вопросов по синтаксису и ни одного программисткого вопроса. Я бы не смог оценить человека по таким вопросам-ответам за 10 минут. В Билайне смогли и отказали. Видимо из-за недостаточной квалификации :D
PS 10+ лет опыта на тяжёлых проектах в основном зарубежом.
Но зачем такое собеседование… — оно ведь не показательно.
Отсеить совсем уж бестолковых людей. Там, как правило, сильно тонких тонкостей не спрашивают, поэтому опытный программист пройдет его в любом случае.
знает 'все' конструкции языка
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Смотря какой язык.
ВСЕ конструкции легендарного PL/1 — мало кто знал.
![image](https://habrastorage.org/getpro/habr/comment_images/4ad/3d9/73f/4ad3d973f2f1dd054d32d25e841a52aa.jpg)
Учитывая, как некоторые языки (не буду указывать пальцем) пухнут от версии к версии из-за синтаксического сахара, у меня закладывается смутного подозрение, что многие профессионалы, каждый день использующие этот язык на практике, могут и не знать абсолютно все его конструкции.
некоторые языки (не буду указывать пальцем) пухнут от версии к версии из-за синтаксического сахара, у меня закладывается смутного подозрение, что многие профессионалы… могут и не знать абсолютно все его конструкции.
Практика показывает, что на собеседованиях (как и сам бизнес) не особо гонятся за трендовыми штучками. Но интерес к развитию своих инструментов — это тоже показатель, имхо. Часто через «сравнения» и «перспективы» на собеседованиях развиваются дискуссии, где в милой беседе можно достаточно глубоко копать человеку в голову. При подготовке стоит это учитывать.
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Не соглашусь. Это нужно знать джунам, так как сосуд пока полностью пустой, и неплохо было бы его хоть чем-то наполнить. Спустя 10-15-20 лет у вас уже нет места в сосуде и чтобы туда залить что-то еще, оттуда должно вытечь что-то другое.
Поэтому юные программисты умеют писать красивый код и помнят все конструкции по памяти (одного ЯП), а старожилы (часто знающие от 4 ЯП) не код пишут, а создают программное обеспечение, фактически создают готовое решение!
Спустя 10-15-20 лет у вас уже нет места в сосуде и чтобы туда залить что-то еще, оттуда должно вытечь что-то другое.
Если откинуть романтизацию опыта «исчисляемого годами», это звучит как возрастные проблемы с обучаемостью (если «вытекает»), серьезно. Не встречал действительно крутых профессионалов, у которых наблюдались бы провалы в памяти по поводу базовых конструкций основного языка.
Зато часто встречаются люди, которые годами пишут одинаковые приложения с помощью одинаковых подходов и напрочь забывают о существовании альтернатив. Это годы застоя, а не опыт.
Поэтому юные программисты умеют писать красивый код
Потому что они не умеют читать некрасивый код. С опытом причуды оформления становятся менее значимыми и болезненными. Но это уже совсем другая история.
Вы никогда не задумывались почему Запад аутсорсит только кодеров, а не идейных вдохновителей. Почему нужны только дешевые рабы на галеры?
Нет, дело не в нашем опыте, знаниях и уникальности. Все дело в цене!
А у вас не возникал вопрос, кто же все таки все те люди, которые придумывают для крутого софта алгоритмы/подходы/идеи/паттерны и т.д.? И почему они все только на Западе. А еще очень интересно сколько лет этим людям? Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Так в какой же момент вашего времени произошел перекос, когда вы можете утверждать, что знаете ЯП лучше, чем его создатель? Маркером будет какой показатель? То что вы помните какие-то конструкции, а он уже нет?
В тысячный раз повторюсь, программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT. Многим даже и код никакой писать не нужно, для этого они аутсорсят нас за еду!
почему Запад аутсорсит только кодеров, а не идейных вдохновителей.
При чем здесь Запад и топ-менеджмент вообще? R&D-отделов крупных вендоров и в СНГ хватает, например.
Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT.
Дядьки эти, как правило, код не пишут, а руководят проектами и теми, кто пишет (теми самыми сеньорами-миддлами-джуниорами простопрограммистами).
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
Ха, не удержались, кинули какашкой. А что можно почитать от такого крутого специалиста, как вы? Уж вы-то точно не формошлепер. И у вас такой богатый опыт в комментариях. Хочу у вас чему-то научиться. Ведь это же нормальное желание? Поделитесь своими статьями, можно даже заминусованными.
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Конечно может быть, как и инженер, как и архитектор, также как и врач и т.д.
Но если немного порассуждать, то возникает вопрос, а зачем люди шли в такие тяжелые сферы, долго обучались в университетах и много лет практиковались, что бы быть бестолковыми?
Зачем им все это? Зачем такие усилия, чтобы спустить их на безделие и стать бестолковыми? Разве нет более простых, гуманитарных специальностей, где можно быть бестолковым вполне комфортно и не напряжно?
А я скажу, почему витает в воздухе дух того, что взрослые люди бестолковые, а молодые дарования — гении.
Все просто. 20-30 лет назад программирование только зарождалось, и те кто в него приходили, делали это не из-за денег или престижа. А из-за жажды новых технологий и прогресса. Подавляющее большинство таких людей, если не все, заканчивали технические университеты с профильными факультетами: автоматизированные системы/кибернетика/робототехника/схемотехника и т.д. Такие люди прошли весь свой путь до сегодняшнего дня с нуля. А некоторые еще и помнят, как нашкрябать простой контроллер в машинных кодах!
И теперь вернемся к нашему времени. Молодые и талантливые дарования, которые считают, что образование/университеты/опыт взрослых людей все это полная шляпа и отстой, быстро изучают по «супер курсам» и роликам из Ютюб какой-то ЯП высокого уровня. Выпендриваются друг перед другом знанием классов/методов и т.д. тем самым пытаясь поднять свое ЧСВ. А как работает комп, что такое шина данных/управления и т.д. знать вообще никому на фиг не нужно. Не царское это дело. Можно взять какой-нибудь фреймворк/CMS и просто шлепать типовые задачи — УРА, профит!
А все те, кто говорят, что уровень знаний таких талантов около нуля, и что ЯП вообще в разработке стоит на последнем месте, то те ламеры, старые и бестолковые пердуны, которые не развиваются ни в чем и максимум что помнят — это какой-нибудь Фортран или Кабол. Короче стандартная подмена понятий.
Именно по этому толковый преподаватель в ВУЗе натянет на экзамене любое юное дарование, которое все знает и умеет.
И такая ситуация не только в ИТ. Она везде.
Именно по этому многие компании (часто Зарубежные) ищут разработчиков за 30-50 лет. Так как золотая молодежь, которая все знает и умеет, и которой насрать на бизнес заказчика, реально уже многих зае… ала.
И если просмотреть реальный успех в ИТ людей по возрастной рамке, то окажется, что он приходит часто после 40 лет, и почти никогда, сразу после 20.
А так как на хабре в подавляющем большинстве сидит молодежь, чьи реальные имена скрыты, у которых нет своих публикаций/сайтов/блогов/опенсорс и т.д., то при таких комментариях или статьях у них реально пригорает, так как бьет по их самолюбию. И какая бы статья не была полезной/важной/правдивой ее обязательно обосрут и заминусят. Что, в свою очередь, никак не принизит опыт/знания/интеллект автора, и уж тем более не возвысит комментаторов, кидающихся фикалиями.
Надеюсь, я смог развернуто ответить на ваш вопрос?
20-30 лет назад программирование только зарождалось, и те кто в него приходили, делали это не из-за денег или престижа.
Да ты че?
Лет 25 назад мой преподаватель рассказывала о том, как именно программирование уже вовсю применялось на примере огромного завода, на котором она работала в 1970-х. То есть почти 50 лет назад. А один из старейших ныне еще применяемых языков программирования для бизнес-приложений, а вовсе не для научных целей — Cobol — был создан в 1959 году. Применяется до сих пор по той причине, что еще тогда были написаны горы программного кода.
Я не говорю про программирование в мире. Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
А можете назвать, пожалуйста, этот современный, на те года, советский завод, где во всю применялось программирование, чего, кстати?
АвтоВАЗ
Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
А что, в наше время, абсолютно все должно делаться в Виртуалии?
Очевидно, что такие предприятия ведут свою деятельность в реальном, а не виртуальном мире, что не может не радовать. Едим-то мы вполне материальные вещи.
Мне уже плохо. Честное слово, при одном упоминание все поплыло перед глазами
Это сейчас. Все же полвека минуло.
А на момент основания в 1966 году — АвтоВАЗ был вполне себе технологически совершенным, в том числе и по меркам всего мира. И ВЦ на АвтоВАЗе был весьма и весьма хорош.
А так да — например, некоторые мои преподаватели по ряду предметов в ВУЗе принимали непосредственное участие в роботизации ВАЗа, приводили конкретные примеры.
Мой отец разрабатывал АИС для сервисных центров АвтоВАЗа в 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-ые сидели на хабре и друг в друга кидали помидорами, у кого комп больше или код длиннее )))
Ну положим, в 50-е они все больше лично друг с другом общались.
Потом да, перешло на удаленку — еще до эпохи интернета, срачи уже были — были и BBS и Фидо.
Не встречал действительно крутых профессионалов, у которых наблюдались бы провалы в памяти по поводу базовых конструкций основного языка.
Понятия не имею как называются паттерны, которые я использую в том или ином случае.
Да и вообще никогда не имел понятия — в мое время их не зубрили.
Для того чтобы делать дело — названия этих вещей не нужны в принципе.
я этого и не знал никогда. Могу догадаться из контекста вопроса или посмотреть в Гугле.
Ничуть не мешает программировать и на качество кода не влияет — нескромно: мало кто из моих бывших однокурсников программирует лучше меня.
Ничуть не мешает программировать и на качество кода не влияет
Чтение литературы, общение с другими программистами происходит легче, когда есть некоторый общий свод терминов-профессионализмов. Если вы завтра начнете, скажем, цикл называть «потоковращателем», то на вашем коде это вряд ли отразится, но сорвать этим какой-нибудь технический митинг вполне реально.
мало кто из моих бывших однокурсников программирует лучше меня.
Если вы не из именитого мирового вуза, то вообще не удивили)
Не потому, что вы, а потому что мотивация людей идти в вузы.
Чтение литературы… происходит легче, когда есть некоторый общий свод терминов-профессионализмов.
Безусловно так.
Но вопрос то в другом — терминологию, которая у джунов/трейни отскакивает от зубов, ибо зубрили совсем недавно — сеньор может уже забыть. Конечное качество его работы все равно будет намного выше и безо всякой терминологии.
общение с другими программистами происходит легче, когда есть некоторый общий свод терминов-профессионализмов.
Гораздо больше терминов из конкретной предметной области.
А вышеупомянутый 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.
1) Экономия моего и его времени.
Вам не составит труда ответить на пару простых вопросов, вы же профессионал.
Труда не составит, но незачем.
Я уже давно не смотрю на вирусы компьютеры знакомых только потому, что «тыж программист».
Серьезно, я даже джунов на собеседовании никогда не гонял на базовые знаний по virtual, static и singleton.
Мне всегда интересно узнать как человек оценивать с технической точки зрения выполненные им в других фирмах проекты (для студентов спрашиваю про курсовые/дипломные/пет-проекты).
Джунам давал задачу спроектировать в РСУБД модель.
Имхо это лучше характеризует «софтверного инженера», чем знание правильных названий синтаксических конструкций.
Языки программирования… довольно быстро можно выучить очередной язык программирования.
Имхо, только начинающие переоценивают знание языка программирования. Полагаю потому, что пока это наилучшее их достижение в ИТ, на которое потрачено много времени, отчего бы не похвастать знаниям.
Однако ничего такого волшебного в знании языка программирования нет. Ну примерно как слесарь тащился бы от того, что знает чем отличается рожковый ключ от накидного, а тот от головки.
То есть в кругу непрограммистов или студентов-айтишников ты может и полубог, раз хорошо знаешь язык программирования. Но по сравнению с другими твоими коллегами — знание языка программирования это ничего особенного. Ну такое же знание, как и знание чем отличается клик левой кнопкой мыши от клика правой кнопки мыши.
А вот то как человек понимает, к примеру, потенциальные узкие места в программе — что тормозит чаще всего именно ввод-вывод и т.п… — это реально полезные знания «софтверного инженера».
Ну и я не беру экстремальные случаи вроде плюсов, и близких к ним по сложности с UB и подобным.
Труда не составит, но незачем.
Сэкономите время интервьюеру. Напоминаю, что вашу трудовую никто еще не видел. Собеседуемый кандидат вполне может оказаться амбициозным начинающим.
Собеседуемый кандидат вполне может оказаться амбициозным начинающим.
Не может.
Я выше расписал свою методу собеседования:
Беседа о реальных проектах. Какие там плюсы минусы в тех или иных решениях.
За первую минуту, человек без опыта сольется.
Более того, я наблюдал как собеседуют кандидатов менее опытные коллеги. Они действительно практикуют так как вы и описали — гоняют по тем вещам, что зубрили недавно в ВУЗе. Потому как это пока единственное, что они могут проверить у кандидатов.
Если мне зададут вопрос про что то типа полиморфизм — я просто попрошу (спокойным уверенным голосом, это важно), чтобы меня собеседовал старший разработчик. Всегда проканывало.
Я выше расписал свою методу собеседования: Беседа о реальных проектах.
Вы исходите из того, что перед нами честный и благородный человек, с настоящим опытом. А если это хитрый засранец, то вы его минут 20 будете выводить на чистую воду, продираясь через витиеватые потоки сознания. Вдоволь намучившись, в итоге прицепитесь к какой-нибудь мелочи, вроде virtual, которую никак не может не знать опытный человек (только уже по вашему мнению), чтобы просто получить повод прекратить эти мучения. Бам! У нас новая нытливая статья на хабре)
Ведь мы тут читали мнение только одной стороны, в реальности все может быть немного иначе…
А если это хитрый засранец, то вы его минут 20 будете выводить на чистую воду
Возможно вы правы, возможно первые подозрения у меня возникнут аж через целых 2 минуты.
Ловите лайв-хак: беседу с кандидатом на вакансию нужно направлять в русло нужно вам. Для выяснения квалификации беседовать нужно по тем аспектам проектов кандидата на вакансию, в которых человек, проводящий собеседование, сам хорошо разбирается.
20 минут слушать, когда человек пургу гонет — да, такое бывает. Серьезно, бывает. Ради эстетического удовольствия, чтобы потом поржать с коллегами. Я еще иногда, когда вижу такого кандидата, приглашаю коллегу-другого послушать. Не этично конечно, но все мы люди, всем хочется заряда хорошего настроения на рабочий день.
Еще раз: «спец» не может вспомнить одну из основных синтаксических конструкций своего языка, название которой ему назвали. Он не смог сказать для чего она нужна.
Нет. Человек не смог вспомнить связь слова "виртуал" с конкретным механизмом работы. Он знает, для чего нужен этот механизм.
И вопрос был "Что такое виртуал?", то есть какой механизм обозначает это слово, а не о том, для чего нужен этот механизм.
Если человек заявляет, что он может программировать на некотором языке, то со связями слов с семантикой быть не должно. Иначе это прекрасный теоретик, может даже архитектор, но никак не программист.
Это показывает, что человек не преподаватель только и всего.
Скорее как раз, что терминология «от зубов отскакивает» и есть необходимое (не достаточное) условие хорошего чистого теоретика.
Архитекторы программных систем, не являющиеся программистами? Это фантастика. Такие вообще существуют? Сколько таких видели?
Архитекторы программных систем, не являющиеся программистами? Это фантастика. Такие вообще существуют? Сколько таких видели?
Под «являться» я подразумеваю уклон в практику (т.е. именно пишет код, а не только пулл-реквесты смотрит в перерывах между митингами), которая не позволяет забыть синтаксис основного языка.
Скажем так, я редко встречаю конторы, где есть настоящий dedicated-архитектор (у которого должность в трудовой так называется, а не просто тимлид, тянущий еще одну лямку).
Это показывает, что у человека очень слабая память. Можно забыть само слово, но не его значение
Кто то говорит про «забыть значение»?
Перечитайте статью, перечитайте комментарии — везде написано про «забыть термин, забыть название».
Проблема в другом — а как вы простым способом сможете обсудить понятие, если нет названия.
Я вас понимаю, вам не хочется заморачиваться, хочется сказать одно слово — услышать его развернутый ответ — и сразу понять подходит человек вам или нет.
Но так не бывает — отобрать хорошего кандидата, это большой труд. Это именно что собеседование. От слова «беседа».
Перечитайте статью, перечитайте комментарии — везде написано про «забыть термин, забыть название».
Перечитал статью. ТСу назвали термин, он не смог рассказать о его значении.
Или Вы хотите сказать, что в повседневной речи Вы повсюду говорите «ЭВМ» вместо «компьютер»?
Скажем так, я редко встречаю конторы, где есть настоящий dedicated-архитектор (у которого должность в трудовой так называется, а не просто тимлид, тянущий еще одну лямку).
Разумеется.
Потому что любой программист сам себе архитектор на своем участке работы. Это особенность профессии — одно из привлекательнейших мест профессии, всегда есть место творчеству.
Ну а суперсложные системы, где требуется прямо таки выделенный архитектор — большая редкость.
В настоящее время наблюдается как раз переход к большей самостоятельности разработчиков, в большей их полноценности, к большей комплексности (тот же DevOps). Разделение работы архитектора по всей вертикали разработчиков — снижает нагрузку на главного архитектора.
Нынче выделенный архитектор — это такая экзотика, что было бы интересно услышать от вас описание конкретных проектов с выделенными архитекторами, в которых вы лично принимали участие.
Вы в курсе, что человек мыслит образами, а не словами? Именно поэтому чтобы читать документацию на английском не надо заново учиться программированию. Выражения "цикл for" или "for loop" связаны с одним образом. У человека есть понятие N, которое по-разному называется на разных языках.
А еще есть такая штука как фокус внимания. И если в конкретной ситуации нейрон с нужным понятием дает сигнал меньше чем другой, на него внимание может не перейти, или перейти не сразу. Именно поэтому при неравномерном шуме сложно сосредоточиться, резкие изменения отвлекают внимание, а при монотонном шуме проще.
А еще это ассоциация обратная той, которую хотят проверить. Умение пользоваться механизмом означает, что у человека о нем есть представление, и при подходящей ситуации он напишет нужное ключевое слово. Ситуация — механизм — слово. А вы таким вопросом проверяете обратную ассоциацию слово — механизм, причем за короткое время в нестандартной ситуации (когда внимание направлено на многие другие факторы), и почему-то делаете вывод, что долгое время обратной ассоциации означает отсутствие прямой. В некоторых комментариях правильно пишут — если человек замялся, надо просто пояснить что вы имеете в виду, задать дополнительные вопросы.
При этом в работе такая ситуация вообще ни на что не влияет. Витает человек мыслями в низкоуровневом баге, подходит к нему человек по другому вопросу "Там надо виртуал сделать — Что за виртуал? — Ну чтобы метод переопределить — А-а, да, это подойдет".
Вы в курсе, что человек мыслит образами, а не словами?
Вы примерные рисунки компилируете или все же текст, ограниченных некоторыми синтаксическими правилами?
подходит к нему человек по другому вопросу «Там надо виртуал сделать — Что за виртуал? — Ну чтобы метод переопределить — А-а, да, это подойдет».
А если он слово «метод» забудет? Или «переопределить»?
Вы примерные рисунки компилируете или все же текст, ограниченных некоторыми синтаксическими правилами?
Вы думаете, текст в голове как-то по-другому обрабатывается? И у вас же претензия к тому, что человек якобы не знает, как этот текст работает. А механизм работы в этом строгом тексте не описан. К чему тогда этот вопрос?
А если он слово «метод» забудет? Или «переопределить»?
А если он на полминуты забудет слово "метод" или "переопределить", то будет ровно то же самое. "Напиши виртуал вон там". К чему эти передергивания? А если он их на собеседовании вспомнит, а на работе забудет?
Вы думаете, текст в голове как-то по-другому обрабатывается?
У меня есть ассоциация со словом virtual, которая связывает его со значением. Я могу забыть слово, но встретив его от меня уже не ускользнет смысл.
А если он на полминуты забудет слово «метод» или «переопределить», то будет ровно то же самое.
Непройденное интервью, ошарашенный джуниор, насмешки коллег.
К чему эти передергивания?
Почему передергивания? Если у некоторых сеньоров случаются провалы в памяти, то вероятность, что они вдруг забудут что-то важное помимо ключевого слова — ненулевая.
Я могу забыть слово, но встретив его от меня уже не ускользнет смысл
А все, кто в конкретной ситуации ведет себя не так как вы, значит не специалисты.
Оффлайн: Записки старого виртуала
Мобайл переходит в виртуал?
Правильный ли смысл подсказывает вам ваша ассоциация?
Непройденное интервью, ошарашенный джуниор, насмешки коллег.
Ну конечно, необоснованными высказываниями можно доказать что угодно. С такой логикой у интервьюера можно много кого завалить на интервью.
Если у некоторых сеньоров случаются провалы в памяти, то вероятность, что они вдруг забудут что-то важное помимо ключевого слова — ненулевая.
Это не провал в памяти, а особенность работы нейронов. Ключевое слово не важно само по себе, важно как работает то, что оно означает. Вероятность что-то забыть, важное или нет, ненулевая у подавляющего большинства людей. Поэтому передергивание.
Правильный ли смысл подсказывает вам ваша ассоциация?
Ассоциаций несколько, разумеется, но под контекст подходит одно.
необоснованными высказываниями можно доказать что угодно.
Нельзя.
Но у нас есть чистосердечное признание: на интервью необходимого вспомнить не удалось, ни сразу, ни за 30 секунд, ни за остальные минуты.
Это не провал в памяти, а особенность работы нейронов.
Это тоже особенность работы нейронов.
Ассоциаций несколько, разумеется, но под контекст подходит одно.
Ага, уже контекст появился. Идем дальше. То есть если контекст слишком общий, то правильная ассоциация может не появиться за короткое время. Нет, объяснение "контекст задан темой интервью" не подходит, так же как и "контекст указанных статей — ресурс для программистов, значит слово 'виртуал' должно ассоциироваться с языком программирования".
Вообще, все ваши "а если" можно проверить простым способом — а именно, уточнить контекст вопроса. Вот если бы интервьюер уточнил как-нибудь типа "атрибут метода такой, для чего он нужен?", а автор статьи не ответил, тогда да, можно было бы говорить, что автор понял что имеется в виду, но не знает зачем оно нужно.
на интервью необходимого вспомнить не удалось, ни сразу, ни за 30 секунд, ни за остальные минуты.
Так не было остальных минут. "Интервью, естественно, кончается. Я закрываю скайп и, конечно, тут же вспоминаю, что за virtual.". А "сразу" было, "тут же" это синоним "сразу".
уточнить контекст вопроса. Вот если бы интервьюер уточнил как-нибудь типа «атрибут метода такой, для чего он нужен?»
Это уже подсказка, а не контекст. А насчет контекста, заданного тематикой обсуждения — все так. Перед этим был как минимум один вопрос о ключевых словах.
Так не было остальных минут.
Наверное, стоило держать свечку, чтобы иметь такую уверенность. Я там не присутствовал и спорить с вами не стану.
Ага, уже контекст появился.
А он, простите, куда-то пропадал? Мы же обсуждаем именно собеседование, именно на сеньора, именно в программировании, на вполне определенном ООП-языке.
Вот этих «если контекст слишком общий» в этой ситуации быть не может, разговор идет о вполне конкретном языке программирования и его семантике. Было бы странно предположить, что на собеседовании по C# слово virtual означает что-то из области форумных альтер-это или чего-то еще далекого от программирования. Если человек начинает на собеседовании на позицию программиста искать значения в своих глубоких познаниях по философии или истории, видимо, ему надо поработать над умением следовать контексту или, возможно, обратиться к психологу для борьбы с рассеянным вниманием или какими-то другими когнитивными расстройствами.
Вот если бы интервьюер уточнил как-нибудь типа «атрибут метода такой, для чего он нужен?»
Вот эти уточнения «ну этот virtual, который атрибут метода, знаешь, такой, который перед void обычно пишется»… Кхм… Детский сад, честное слово. Еще со студентами пойму, когда сильно хочется на экзамене за уши вытянуть. Но при собеседовании человека с опытом в языке, претендующего на позицию сеньор-разработчика, настоящего профессионала в профессии.
Не, вы это сейчас серьезно? Реально?
серьезно? Реально?
Серьезно и реально. Это особенность работы нейронов, и в указанных условиях такая реакция может быть. Да и тут в комментариях есть примеры.
Если передергивать, то конечно детский сад. А уточнение вопросов это нормальный рабочий процесс. "Не знает" и "не успел вспомнить" это разные вещи, как бы вам ни хотелось думать иначе. Если вы хотите узнать реальное положение дел, вы уточните вопрос, не хотите, дело ваше, только не надо потом удивляться результатам проверки за несколько секунд)
Давайте подумаем. Контекстное восприятие — это про то, что человек может одни и те же слова воспринимать по разному в различных контекстах. Бессмысленный сам по себе текст «по мановению волшебной палочки» превращается во вполне понятный при задании контекста, а, находясь в одном контексте, человек может не воспринять оторванные от контекста слова. О чем это нам говорит в контексте собеседования по 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»
Вместо этого «сеньор» выбирает ответ «да это для джунов, я вообще не обязан этого знать, я проектирую мегасложные системы и ваще».
Нет, нет, и нет. Это ваши домыслы.
Для этого по скайпу и собеседуют, чтобы в блокнотик не подглядывал.
Открыть скайп и рядом блокнот, скроллить мышкой.
А кто сказал, что дальше сложных вопросов не планируется? Мне вот кажется нормальным задать 2-3 тупеньких вопроса на «знание базы», чтобы по-быстрому отсеять реальных «самозванцев»
Так в том и дело, что не проверяют ваши вопросы "знание базы", не проверяют умение пользоваться, а потому не отсеивают реальных самозванцев. Самозванец заучит определения и пройдет эти вопросы. Где тут экономия времени? Если его должны отсеять сложные вопросы, почему бы тогда их сразу не задать?
Да суть в общем-то не в этом, а в неправильном выводе. В указанной ситуации неответ не означает незнание, и ситуация "не ответил, но знает" возможна. А вы пытаетесь доказать, что это не так. Если не хотите рисковать и у вас за дверью толпа специалистов высокого уровня, ваше право. А кто не может долго найти хорошего специалиста, тот задумается.
Нет, нет, и нет. Это ваши домыслы.
Перечитайте статью, что ли. Там в вину собеседующим даже отсутствие веб-камеры у соискателя ставится, а также то, что дешевой веб-камеры не оказалось в магазине по соседству.
Самозванец заучит определения и пройдет эти вопросы.
По крайне мере, самозванец, который даже заучить определения не озаботился, на этом этапе отсеется.
Если его должны отсеять сложные вопросы, почему бы тогда их сразу не задать?
Потому что, например, постановка действительно сложного вопроса может занять больше времени, чем «блиц» по 3 вопросам на знание базовых терминов.
Да суть в общем-то не в этом, а в неправильном выводе. В указанной ситуации неответ не означает незнание, и ситуация «не ответил, но знает» возможна.
Стоп. Давайте разберемся, что вы вообще предлагаете…
Вот у вас собеседование. Вы задает вопросы, соискатель на них отвечает. По ответам на вопросы вы должны составить начальное представление о знаниях соискателя.
Вы задаете вопрос, соискатель отвечает — окей, будем считать, что знает.
Вы задаете еще один. Соискатель не отвечает. Предположим, что «знает, но забыл»?
И как оценивать? Брать, в смысле, всех? А то они волнуются на собеседовании, что уж судить строго! Они же говорят, что знают. Просто забыли! А на работу выйдут и сразу вспомнят! И все-все-все будет хорошо, и в небе взойдет радуга, и код будет писаться сам, и вообще наступит всеобщее процветание.
Вам это так видится?
А вы пытаетесь доказать, что это не так. Если не хотите рисковать и у вас за дверью толпа специалистов высокого уровня, ваше право. А кто не может долго найти хорошего специалиста, тот задумается.
Я не пытаюсь доказать, что какие-то «факапы» невозможны. Я пытаюсь сказать, что слюни на тему «меня не взяли, это несправедливо» — абсолютно левая чушь. Если ты действительно специалист уровня сеньора — пофиг тебе на то, что тебя здесь забрили. У тебя работодатели в очередь стоят, сеньоры — дефицит. А если ты бегаешь по конторам, и везде собесы проваливаешь, сидишь без работы и плачешься… Так может, просто планочку понизить. Может, не тянешь на сеньора, просто? Попробуй на миддла пособеседоваться.
Давайте разберемся, что вы вообще предлагаете…
И как оценивать?
Как оценивать, я уже несколько раз написал.
Я предлагаю не делать вывод, что если человек замялся, значит не знает, задавать дополнительные вопросы, если так случилось, и не задавать вопросы, указанные в статье, по причине несоответствия целям проверки.
А также предлагаю не преувеличивать и не делать на основе этого далеко идущих выводов.
"абсолютно левая чушь" "плачешься" "планочку понизить" "может, не тянешь"
Или может собеседования такие, что не показывают правильную картину.
А учитывая ваше эмоциональное отношение к людям, квалификацию которых вы не знаете наверняка, "топище" из статьи уже не выглядит преувеличением.
Я предлагаю не делать вывод, что если человек замялся, значит не знает, задавать дополнительные вопросы, если так случилось
Ну, т.е., все таки:
— Что такое virtual?
молчание…
— Ну, который «виртуальное наследование».
молчание…
— Ну, когда class ClassA: virtual ClassB — это вот что означает?
молчание…
— Подзабыл? Какая печалька! Ты не расстраивайся, подумай полчасика, мы подождем! Мы же только для того и работаем, чтобы тебе приятно было!
… делает вид глубокой задумчивости в течение 30 минут…
— Окей, намекну, про «проблему ромба» когда-нибудь слышал?
молчит…
— Множественное наследование (шёпотом).
пожимает плечами…
— Ну скажи хоть «множественное наследование — зло!»
— Ну ладно, множественное наследование — зло.
— Ну вот и молодец, вот и ладушки! Ты принят на 300 тысяч в месяц. Нет, на 450!!! Какая радость!
Вот так это должно быть?
Или может собеседования такие, что не показывают правильную картину.
Может, и такие. Но ничего лучше не придумали пока что. Сюсюканье с разработчиком, который настолько звезда, что не озаботился даже все базовые механики языка изучить — ещё худший выход.
Вот так это должно быть?
Нет. Сколько раз мне надо написать? Вместо первого вопроса будет вопрос «Приведите пример переопределения метода в наследнике». И всё. Вы же это хотите проверить, а не знание определений наизусть.
Если вы настаиваете на первом вопросе, то будет так:
— Что такое virtual?
— Э, ну…
— Атрибут метода такой, зачем его пишут?
— А, это чтобы можно было переопределить метод в наследнике.
Не надо давать подсказки ответа, надо удостовериться, что человек понял вопрос.
Ну считайте, что вместо "э, ну" вопрос "это из какой области?". Сути это не меняет, такое уточнение не означает, что человек не умеет переопределять методы. Вы правильно говорите, но обычно люди какое-то время пытаются вспомнить, знакомое же слово, а за это время становится понятно, что человек по какой-то причине замялся. Просто это не повод сразу прекращать собеседование.
Если он не пытается разобраться в заданном вопросе, а говорит «я не знаю» или, что еще хуже, отвечает «да я такой крутой разраб, хренли вы у меня такую тривиальщину спрашиваете»… Кхм, такой сеньор в команде не нужен, вне зависимости от его скилла непосредственно в кодинге.
Понимание задачи из формально-нечеткой постановки и уточнение нюансов, равно как и декомпозиция задачи, четкая формальная формулировка/постановка, «перевод» на язык, доступный для каждого джуна — его прямая обязанность.
Если он не может сам попросить переформулировать недопонятый вопрос, задать уточняющий вопрос или относительно вежливо указать на неточность формулировки — грош цена ему как сеньору. Писать формально корректный код должен миддл, там соискателю и место.
Я тоже на всякий случай повторю. Я спорю с тем, что 'не ответил сразу на вопрос "что такое N" означает "не умеет использовать то, что обозначает слово N"'. На любую позицию.
У нас есть собеседование на высокооплачиваемую должность. В собеседовании две стороны-участника (соискатель и собеседующий), у каждой их которых свои цели. У соискателя — доказать свою профпригодность и получить работу. У собеседующего — отсечь профнепригодных соискателей и принять (по возможности, на испытательный срок) на работу соискателя, показавшегося профпригодным на основании содержания собеседования (да, экспресс-тест, но ничего не поделаешь, время собеседующего тоже стоит денег).
В нашей ситуации соискатель завалил собеседование, не вспомнив с ходу ключевую механику языка. Для сеньора такая ситуация — повод стыдливо помолчать в тряпочку, а не нести свое негодование на Хабр.
Да, для миддла ситуация могла бы быть и помягче. Для джуна… Кхм, джун — это изначально человек, которого берут с намерением «научить», т.е. там вообще нужно проверять собственно адекватность индивида и базовую способность воспринимать речь на слух и в письменном виде. Для сеньора, простите, не должно быть поблажек. Высокая зарплата = высокий порог вхождения, и никаких «сюсюканий».
А «в отрыве от ситуации», «в абстрактном понимании» и много еще ничего не значащих слов — спор беспредметен. То, что человек не отвечает на простой вопрос может означать, например, что он русский язык не знает, или глух на оба уха, или просто уснул — это вот тот набор вариантов, который можно упомянуть в споре, но который не имеет никакого отношения к ситуации.
Сениор это не тот, кто знает все ключевые слова, а тот, кто умеет применять то, что ими обозначается. Он зачастую знает несколько языков, может разобраться в новом языке и применить нужные механизмы для решения задачи, посмотрев нужные ключевые слова в документации. И в первую очередь это относится к full-stack разработчикам.
Нет тут никакой проблемы «не переключил контекст». Его спросили одно ключевое слово из языка, потом еще одно, затем третье — все три из одного и того же языка. Если бы после 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 месяцев узнаете результат. Т.е. вы положили ручку, сдали листочек — все, тестирование пройдено, этап завершен, за результатами приходите позже.
«Тест пройден успешно» — немного другой контекст, но если «пройден» — однозначное указание на успешность завершения, зачем слово «успешно»?
Собеседование пройдено… Кхм, вы поговорили, вам обещали перезвонить. Это «пройдено» или еще «не пройдено»? Это удача или провал? По вашей логике, пройдено оно тогда и только тогда, когда в вашей трудовой книжке появляется отметка о принятии на работу. А до этого времени… Все еще идёт, что ли?
Самозванец заучит определения и пройдет эти вопросы.
По крайне мере, самозванец, который даже заучить определения не озаботился, на этом этапе отсеется.
Тут ещё плюс, что отсеиваются не только истинные ленивые самозванцы (которые знаю, что вроде и не дотягивают до сениора, но вдруг прокатит), но и те кто не готовится не из-за лени, а из-за уверенности своей супер-крутости (за те 2 года, что я проработал после окончания университета я уже столько сделал/столько_знаю/столько_умею). Эти вторые вроде никого и не обманывают, он реально верит, что он
Собственно, чего греха таить, сам себя в свое время «пупом» считал. Прошло с годами…
Тут ещё плюс, что отсеиваются не только истинные ленивые самозванцы (которые знаю, что вроде и не дотягивают до сениора, но вдруг прокатит), но и те кто не готовится не из-за лени, а из-за уверенности своей супер-крутости
А я, например, считаю, что подготовка к собеседованию — четкий и явный обман работодателя. По-этому нельзя к ним готовиться, если не хочешь быть обманщиком.
Так перед синьором и стоит задача архитектуры, и паттерны проектирования — её часть. Это и есть сама абстракция, выше синтаксических тонкостей языка.
Какие базовые паттерны применять, на какие классы делить проект да какие будут там отдельные интерфейсы и т.п. — должен уже миддл нормально соображать. Да и у талантливого джуна это зачастую получается приемлимо.
Перед сеньором по части архитектуры стоят задачи более общего уровня, чем банальное «реализовать ли здесь синглтоном».
Я например сейчас раздумываю насчет того на какие куски порезать нашу проектируемую систему по функционалу, чтобы репликация между серверами не снижала производительность.
У вас нет системного архитектора в конторе?
Я и есть.
P.S.:
джун, миддл, сеньор — это про уровень квалификации.
а системный архитектор — это про функционал, про должность.
данные понятия — вообще параллельны, они о разном. (кроме того факта, что архитектор как правило сеньор).
Но вы не пишите код, верно?
Пишу. Мне это нравится.
Даже основывал 4 фирмы (2 с партнерами, 2 сам). Но когда доходит до того, что нужно менеджером быть, а не разработчиком — завязывал. Не нравится мне это — не писать код лично.
Вы намекаете на настоятельную необходимость выделенного архитектора в любом произвольном проекте?
Нет, это не так.
Выделенный архитектор нужен только в огромных проектах. Проектирование и создание кода одним человеком — вполне сочетается даже в группах программистов и в 50 человек (а это огромная сила, очень серьезные вещи куда как меньшим числом созданы).
Архитектор вовсе не продумывает все до последнего класса в системе. Свои куски разработчики вполне способны продумать сами.
У меня на придумки по архитектуре уходит процентов 10-40 рабочего времени в неделю.
А расскажите, пожалуйста, что такое структурная и мнемоническая типизация? Ни разу не встречал таких понятий, любопытно стало.
Недавно у меня был характерный случай, когда Nominal typing проявил свои отрицательные качества. Суть: есть два класса, определенные во внешней библиотеке, имеющие одинаковую семантику, одинаковые поля (по крайней мере, в той части, которая меня интересовала), даже называются одинаково, но находятся в разных пространствах имен. И мне нужно конвертировать сущности любого их этих классов в мой собственный класс и обратно, по возможности с минимумом дублирования кода. Интерфейса общего нет, предка общего нет, копипасту плодить очень не хочется… Выручил как раз подход в стиле Structural typing — метод принимает dynamic и обращается к нужным свойствам, выполняет конвертацию. Чтобы не выстрелить себе в ногу, методы с dynamic-ами сделал приватными, а публичными сделал обертки со строгой типизацией.
{x:Int, y:Int}— это и есть тип.
{x:Int, y:Int, z:Int}` — его субтип всегда, в любых условиях. Из недостатков — сложности с рантайм-проверками типов, более тормозной тайпчекинг, ну и отношения сабтайпинга задаёте не вы, поэтому могут случайно оказаться связанными два семантически несвязанных типа.
Проблемы с вариантностью еще забыли, ведь в любом нормальном языке рекорды должны быть мутабельными.
Nominal
Я из контекста понял, что под "мнемонической" подразумевалось nominal, но это правда где-то есть такой перевод?
Ну, у всех такие собеседования были, и у меня. Не расстраивайтесь. У меня был период, когда нужно было каждую неделю нанимать. Пришлось сделать опросник по темам c#, sql, english, ООП и др. Когда человек запинался на первом блоке вопросов, то переходили сразу на другой. Из-за огромного потока людей, видимо, часть собеседуемых воспринимало наши вопросы как академические. Ну, не всегда есть возможность «поговорить по душам».
Не знаю, как на собеседовании (не проводил), но когда приходит студент и просит научного руководства, то через 3-5 минут разговора мне уже понятен уровень будущей ВКР. И скажем, не от большого опыта руководства это, а от того, что сразу видно зачем человеку это надо (если для галочки, то я сразу рекомендую найти другого научрука). Интересно, что мое мнение не всегда сходиться с мнением студента и в итоге получается недоделанная работа.
Если сформулировать коротко: здесь на собеседовании пытаются найти что-то, что вы не знаете, там — что-то, что вы знаете хорошо.
В точку!
Как Вы отнесетесь к человеку, который при знакомстве захочет проверить, не карманник ли Вы, на том основании, что его недавно обокрали?
Дам ему проверить. Почему надо на это оскорбляться?
На самом деле расстраиваться из за такого собеседования не стоит. Любое собеседование является обоюдным. Надо радоваться когда человек с которым ты будешь работать сразу показывает свое лицо. Было бы гораздо хуже если бы взяли на такую работу, а потом показали бы свое лицо. Не знать что такое virtual для ведущего разработчика, это, конечно, плохо. Но еще хуже если собеседующий радуется и не может даже скрыть своей радости по этому поводу. Думаю стоит порадоваться что провалили это собеседование.
Пару месяцев назад получил письмо от одной компании, я туда честно говоря не собирался, но так было красиво все расписано… В общем мне тоже вдруг показалось что будет разговор с умным человеком, и я клюнул. Мне сразу же прислали тестовое задание, и это тоже мне понравилось, простой и эффективный способ фильтрации нулевого уровня, задание не сложное, но и не совсем тривиальное, значит потом будет еще интереснее. Короче, поехали.
Просят реализовать некоторый алгоритм с максимальной эффективностью и ограничениями на память, особенно просят учесть все пограничные случаи. Дается на все девять часов.
За первый час написал базовую реализацию, еще час потратил на выявление этих самых пограничных случаев (и нашел таки парочку), потом час отдохнул (времени еще впереди немеряно), еще на раз все проверил, написал детальные комментарии, написал и прогнал несколько юнит тестов. Потом осенило как можно улучшить, переписал и снова все протестировал. Несколько часов пролетели незамено и вот, за десять минут до конца, я отправляю код и собираюсь выпить наконец чаю… Не успел — ответ пришел через 20 секунд. «Ваш код содержит потенциально опасные места в пограничных случаях и не может быть принят»
Вот я дурак, ну разумеется никто мой код читать и не собирался, это статический анализатор. Но это не такой уж сложный алгоритм и я абсолютно уверен что все сделал верно. А вот и одно из возможных проблемных мест — адресация массива по индексу без проверки выхода за праницы. Но позвольте, из предыдущих трех строк кода очевидно следует что индекс в данном случае всегда остается в нужных рамках, а вот и комментарий где прямо это все обьясняется. Но возможно я слишком многого хочу от анализатора?
Оставшиеся десять минут потратил на то чтобы убедиться — подстроиться под требования конечно можно, но тогда будет банальный спагетти-код, за который я бы и браться не стал, ибо скучно. А зачем было спрашивается просить максимальную эффективность? И разве трудно было прогнать все эти пограничные тесты (как я и сделал для себя) и проверить что все работает?
Я понимаю конечно что компания в своем праве, но все равно, ощущение что в тебя плюнули остается надолго. Ну а я им в ответ желаю набрать именно тех разработчиков, которые с блеском пройдут этот тест).
Очень странно. Если вы не пользовались этим оператором, раз у вас этим затруднение, то у вас слабое представление о ООП, и значит потерян целый пласт девелопмента и дальше действительно не о чем спрашивать.
В ряде организаций вполне могут спросить как это имплементировано в компиляторе и что такое виртуальные таблицы — и поверьте — это отнюдь не праздный вопрос.
По крайней мере в Bloomberg меня об этом спрашивали и я знаю зачем это нужно.
Я тоже так сразу и подумал, но судя по стилю текста, общим описаниям и т.д. автор вполне адекватен, значит дело в чем-то другом, включая банальный ступор или интерференцию синтаксиса языков. Нормально, если человек не знает синтаксис fixed или unchecked, но не знать virtual он не может, скорее просто забыл в мандраже слово или не понял вопрос. И вполне он может знать и про работу vtbl, просто надо сбавить обороты и разобраться, что происходит. В этом и посыл статьи. Гораздо легче сразу завернуть кандидата, чем подумать.
е важно, что я помню поведение virtual и его назначение, не помню только само слово. Что я регулярно разрабатываю с использованием четырёх языков программирования, и не могу помнить досконально все их самые пыльные углы.
Всё написано вами правильно, и мысли в точности как мои, написанные 2 года назад =)
Я так не считаю, Бог не тот кто управляет. Бог то — кто пишет код.
Я полностью согласен с автором и целиком разделяю его переживания.
Но переживать не стоит, пока не сменится идеология подхода в разработке ПО в целом по РФ.
Думать и предвидеть — вот хороший скилл.
К сожалению, все менее и менее востребованный…
Все чаще вижу, что создатели процессов стараются задачу «думать» переложить на целую кучу людей. О том, «зачем», должен думать продакт, о том, «как» — архитектор и системный аналитик, о том «когда, и кем» — проджект, а программист = интерпретатор тз в код. Как будто, те, кто так поступает, считают, что умение писать код одновременно понижает остальные скиллы.
Просто писать код должны мартышки. И многие работодатели хотят нанять именно мартышек, хотя декларируют совсем другое. Такова реальность.
И уже не важно, что я на самом деле стараюсь избегать классического наследования
«стараюсь избегать» следует понимать, как «не использую совсем»?
Ну в книжке я тоже прочесть мог бы
А без книжки? :) Ну да, я загуглил по быстрому «is-a наследование», чтобы лишний раз убедиться, что ничего не путаю. Но я это знал и не забывал.
Был у вас в реальной жизни такой пример?
Например, сейчас пишу слот-машину… Базовый автомат содержит один барабан, который крутится 3 раза (эмулируя 3 барабана, т.е. на всех барабанах одинаковые вероятности), я хочу сделать 3 различных барабана + немного кастомизировать размеры ставок. В принципе, я уже написал формально работающую слот-машину, расширив SlotMachine классом WildCherry, и получив 2 работающих автомата.
PS Позволю себе сделать предположении, что вы начнете задавать вопросы в духе «а, что если?» — сразу говорю, это не ко мне :) Пример из реальной жизни и моего пет-проекта, написанный с целью изучения математики.
На интервью у вас возможно и не будет гугла. Но именно потому теоритические знания и зазубривания определений смысла не имеют (имхо), кроме того после книжного определения дальше говорить не о чем. Если же вы практически его применили и обдумали сценарий — то это можно с вами обсудить, как с будущим коллегой, заодно убедившись что с вами можно нормально общаться по техническим вопросам.
> Например, сейчас пишу слот-машину… Базовый автомат содержит один барабан,
> который крутится 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 вопросов по каждой теме, с голосовалками за вопросы «хороший/полезный или пыль»…
Ну т.е. харе писать как вас плохо отсобесили, давайте писать «как надо собесить».
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?
я же сказал "любым способом".
вариант с remove_if был только один раз.
и нет цели "засчитать" есть цель понять каков уровень у кандидата. имеет ли смысл сразу переходить на более высокий уровень или стоит поспрашивать. если не использовал итераторы в решении то я и так спросить про них могу без задачи.
если давно не работал и не помнит стл это уже звоночек (мне таки нужен стл). но пускай решит в терминах известного ему инструмента — скорее как успокаивающий фактор.
но я могу себе это позволить — у нас широкий спектр вакансий и если я вижу, что на сеньера он не тянет, но кандидат толковый могу предложить позицию пороще в том числе в команде помладше.
теперь, пока за мной не будет стоять мой код, на собес я не пойду
Такой подход очень сильно ограничивает вас.
На мой взгляд правильный вывод должен быть другой. Да, собеседование зачастую — это дурацкая игра. Поэтому и готовиться надо как к игре. За неделю до собеседование погуглите «top c# interview questions» (или какие другие технологии вы используете). Зазубрите ответы на бессмысленные вопросы, типа, сколько поколений в сборщике мусора, список из 10 отличий структуры от класса, расшифровки аббревиатур (SOLID, например), 3 главных слова про ООП, разновидности полиморфизма и т.д. Это никак не изменит ваши реальные качества как разработчика, только в глазах собеседующего. Разве что где ещё сможете блеснуть фразой: «это же ad hoc полиморфизм/утиная типизация!».
И ещё интересный момент на собеседованиях — это задачки. Иногда знакомые рассказывают, какие задачки они задают зачастую в весьма посредственные компании. Я в них довольно неплох, но понимаю, что с нуля за час даже в спокойной обстановке дома решение не осилю. Знакомые утверждают, что таким образом они проверяют умение мыслить. Но почему-то не понимают, что лучше всего умение мыслить продемонстрирует человек, который уже эту задачку заранее знает. Поэтому на собеседовании надо играть. Даже если вы знаете ответ и решение, сделайте вид, что усиленно думаете, задавайте больше уточняющих вопросов, спрашивайте, что лучше оптимизировать (использование памяти или сложность, а может и размер кода).
И ещё. Не навешивайте ярлыки сразу. А в конце собеседования, если ярлык всё-таки прилип, осознайте, что с пафосными напыщенными идиотами лучше не работать. К счастью рынок труда сейчас это позволяет.
Сам лично с таким сталкивался.
Причем не только в сфере программирования а вообще в сфере IT (администрирование, сетевики и т.д.).
Ничего страшного не случилось, нет так нет — смотрите другую вакансию.
Хорошо, что компаний много, не сростется с одной, попробуйте с остальными.В крупных городах. Например я планирую переходить в андроид, и я знаю всего 3 компании в городе в которых могут взять андроид разраба. И то в одной очень вряд ли новичка в технологии возьмут. В реале скорее всего больше — но это те что я нашел. И не надо заводить шарманку про переезд в нерезиновую.
И не надо заводить шарманку про переезд в нерезиновую.
А про удалёнку и фриланс?
Как-то сделал замечания старшему разработчику (старшему из двух), что статика не кешируется, и банер в 500кб грузится на каждой странице ( интернет тогда был гораздо хуже чем сейчас), в итоге он что-то наговорил диру, и меня уволили. И такие гниды могут потом собеседовать.
Иногда собеседования не проходил (не перезванивали), но вопросы и задания были адекватными, а иногда нет. Но уже давно не бомбит, просто в жизни есть ***** и они встречаются не только на дороге. Принять сей факт и жить дальше. (Дальше ходить на собеседования)
На вакансия может реально откликнуться несколько человек, и кто-то может показаться работодателю лучше, и он сделает выбор в его пользу, и то что вас не выбрали, не означает автоматом, что вас собеседовал ******(Ваше слово)! Человек идет на собеседование, как правило с целью его пройти, а не для пополнения списка числа своих собеседований.
И тут нужно «ПОКАЗАТЬСЯ» лучше других. И зная что на собеседованиях бывают теоретические вопросы, можно эту теорию и освежись, ведь это поможет выполнению цели (цели пройти собеседование). Если что-то считаете оправданным для достижения цели, то делайте это.
Код сортировки пузырьковой
Он разобрать не смог с листа.
Ему давали в детстве мало
Кнута.
Чтобы разговоров не было — начинал разработчиком в 1991 году, начинал с pl/1 и rexx, в 97 году работал под solaris/sun os (ingres, tcl/tk) закончил разработчиком в районе 2008 года (delphi), решив, что асучник/системный администратор/ремонтник спокойнее, ликвиднее и легче.
Но снижая риск найма самозванцев, компании снижают шанс найма хороших разработчиков.
Лично я не вижу в этом проблемы. Я исхожу из того, что при поиске сотрудников компании, в сухом остатке, ищут людей, которые, по мнению компании, будут ей полезны. А иначе нет смысла нанимать человека, если ты от его найма никакой пользы для себя не получишь. Той компании, собеседование в которой описал автор, его услуги не нужны. Ну, не нужны, так не нужны, полагаю, автор уже давно нашел десять других компаний, кому они нужны. Так что, проблемы нет.
Лично я всегда сразу спрашиваю о тестовом задании. Собственно, за мое время поиска работы я их переделал уже тонну. По мне, тестовое задание — это лучший способ для соискателя показать свои возможности, а для работодателя понять, нужен ему такой человек или нет. Наверное, есть такие люди, которые нужны всем, а потому первая же компания, в которую он напишет, возьмет его на работу. Я, например, к таким не отношусь, а потому из множества компаний, кому писал я, мои услуги оказались привлекательными только для одной. Ну, а остальные сочли, что я для них пользы не принесу. По-моему, это вполне естественная ситуация.
А выкидывание в outer space вакансии в надежде найти стоящего кандидата — это, в первую очередь, жадность работодателя, т.к. найденному спецу по связям платить сходу придется очень много.
Так что развивайте вашу network контактов, а не бездумно шлите резюмехи на все вакансии в открытом доступе.
Ваще, синьоров нанимают немножко не так, на самом деле. В основном — через нетворкинг (Маня знает Сашу, а вот Саша знает отличного синьора Артема). Все идет в нормальных конторах через связи, знакомства (в хорошем смысле этого слова).
Не все крутые программеры — являются эсктравертами, любящими туссовки и общение.
Многие — даже очень наоборот, и именно потому круты — потому что вместо того, чтобы звиздеть
Но я согласен, вопросы совершенно тупые и не к месту.)
Зачем ждал вопросы?)
Ахахах :)
Либо этому конкретному человеку, который через вашу вебку (этого пассажа рассказа не понял, извините — вебка у вас, а себя показывает он) хотел показать себя лузерам, требовалось на чем-то каждого подловить, чтобы доказать что-то себе и окружающим (и тогда ничего не сделаешь, у него цель не нанять, а самоутвердиться), либо цель была найти грамотного и мыслящего, но тогда вам надо было разговор переводить в другую плоскость: «Что такое N — Смешно, мне это точно знакомо, но не могу вспомнить формулировку. Нервничаю, наверное, у вас такая компания известная и т.д. А можно вопросы более практические, вы же не преподавателя ищете со знанием формулировок, а мой код скажет обо мне куда больше?»
Причем этот вопрос ответит и на варианты выше: если ему интересен работник, то, кроме мелкого минуса за незнание, вы получите жирный плюс за работу мозга.
И вот на вакансию стоит отзываться, когда просто готовы провести разговор обычным человеческим языком. Судя по тексту, это у вас вполне получится, просто в этот раз вам самому не понравился собеседник — это, кстати, приличный звоночек вообще туда не идти, если потенциальный более грамотный коллега воспринимается так негативно.
но тогда вам надо было разговор переводить в другую плоскость:
Надо было самому начать задавать вопросы. "У вас тут в описании вакансии написано, что требуется технология Х, но она же не входит в основной стек? откуда взялось это требование? зачем именно нужно Х? В каком контексте мне придется работать с Х? Ах, в контексте Y? Ну тогда у меня есть релевантный опыт вида Z, перейдем к следующему требованию...".
А игра в одни ворота заведомо проигрышная, в конце концов соискателю тоже нужно узнать, с чем и как он работать будет, и с его точки зрения все эти вопросы про виртуал — трата времени.
«Когда пришло время делать доклад по этому предмету, я для начала изобразил очертание кошки и принялся называть различные мускулы.
Другие студенты в аудитории перебили меня: «Мы знаем все это!»
— О, вы знаете? Тогда не удивительно, что я могу догнать вас так быстро после четырех лет занятий биологией. — Они тратили все свое время на запоминание ерунды вроде этой, когда это можно было бы посмотреть за 15 минут. »
Но мне также не совсем понятно, как можно было забыть суть ключевого слова virtual, простейшая зацепка — виртуальная реальность, замещение реальности. То есть виртуальный метод — замещаемый. И вообще, когда говорят virtual, имеют в виду всякого рода замещение. И до этого можно догадаться, будучи знакомым с программированием только поверхностно. И из этого вспомнить суть кейворда.
Поэтому да, на месте HR я бы подумал, стоит ли брать человека, который не то, чтобы не помнит, а не смог сообразить. Соответственно, не сообразивший человек с большой вероятностью будет гуглить там, где не надо, и с языками (естественными) у него не очень, то есть именно что — есть основания полагать, что перед HR — самозванец.
Другая история была бы, я думаю, если бы Вы начали думать вслух и, конечно, по ходу всё-таки сообразили бы, как тот вышеупомянутый профессор. Мастерство ведь не пропьёшь, Вы умный человек, это ясно видно по тексту. И вот это был бы блеск. С точки зрения HR, как и любого другого человека.
Вы просто растерялись. Бывает. Именно что переволновались перед собесом. Вакансия понравилась. И по этой же причине бомбануло…
Soft skills определяет результат работы иногда больше, чем навык программирования. Особенно, если это команда, и код пишут вместе.
Например — что такое ДНС/как она (служба) работает/можете подробно описать резолвинг имени www.example.com/можете описать как происходит загрузка linux от момента нажатия кнопки питания до момента… И вы не поверите, 90% сеньоров не могли ответить. А некоторые с большим возмущением начинали говорить — а что это за вопросы и зачем мне это знать? Если что я загуглю за 5 минут.
С одной стороны в чем то они правы, а с другой — если ты сеньор и у тебя 10+ опыта работы, как ты можешь не знать и не уметь объяснить работу ДНС? Для меня это загадка.
Естественно я никогда не прекращал собеседования, если кандидат не знал или не мог ответить, но осадок оставался. Но если я видел, что человек просто волнуется и у него вылетело из головы, у самого тоже бывало такое, особенно когда проходил собеседования на англ-ком языке с иностранными заказчиками, то всегда задавал наводящие вопросы или небольшие подсказки. Если человек реально знал, но просто забыл, то как правило это помогало. Были конечно исключения, когда человек не знал, но благодаря подсказкам выстраивал правильные предположения, но это исключение из правил. Всего один или два человека попались таких из ~40.
И если в итоге было два более менее равных кандидата, но первый условно смог объяснить работу ДНС, то я рекомендовал первого.
Тоже «вальнули» на virtual однажды…
И такие собеседования 9 из 10, такое ощущение, что ты пришёл на экзамен в университете…
Никого не оправдывая, но если этот человек, пусть и раздутый, но, возможно, заинтересованный — понял бы, что вы не от того, что «самозванец» не знаете, а от того, что вы используете совершенно другой подход в решении задачи?
Собеседование должно было носить формальный характер(поэтому назначили человека слабо разбирающегося в вопросе, возможно сынка боса), например висит вакансия, но руководство не совсем понимает нужна ли она им. Но на всякий случай (а вдруг попадётся суперспециалист), вакансию мониторят и собеседуют.
А что касается программирования: Если собрать всю доступную на данный момент информацию по программированию и разным описанным подходам и приёмам то получиться большой файл. Этот файл нужно будет ежеминутно/ежечасно пополнять. Представить себе человека (не киборга) который сможет этот файл обрабатывать я не могу. Сознательная часть мозга по моему мнению, вообще не очень хорошо хранит информацию. Поэтому имеем аналог кэша как на PC, загружаем только то что нужно для работы, актуальное в «оперативке», старое потихоньку забываем. Термины могут мозгом по умолчанию считаться не очень важной информацией…
Подобные статьи и часть комментариев напоминают мне стенания всяких боди-позитив и прочих snowflakes об их ОБВМ и о том, что их никто не любит такими, какие они есть, и которым проще ныть на форумах, чем элементарно привести себя в порядок и начать бегать по утрам.
Все мы считаем себя сеньорами достойными Гугла, но реальность она несколько иная, мягко говоря.
Если вы не major contributor в какой-нибудь популярный open source проект, не работали в условном Гугле, не побеждали в top coder, и вас специально не хантят, то реальность такова, что для работодателя вы — никто. И до тех пор пока у вас за поясом не будет чего-нибудь из вышеперечисленного, будьте готовы каждый раз доказывать, что вы не верблюд.
И выручите уже, бл*ть, эти алгоритмы и структуры данных. Если сеньор за 5/10/15 лет не удосужился взять какую-нибудь Elements of Programming Interviews in Java и потратить три месяца по вечерам, чтобы не тупить при встрече с древовидной структурой, то что-то с этим сеньором не так.
Ну и, наконец, неспособность вспомнить virtual в три часа ночи с бодуна в грозу, для сеньора таки залёт.
Типовая ситуация, к сожалению. Изменить сторону, которая вас нанимает вы наверное вряд ли сможете. Можете лишь изменится сами. Вариантов много. Можно научится навыкам собеседования и перехватывать инициативу. Можно сделать так, чтобы за вами охотились. Я не думаю, что в 80% случаев вы сможете убедить HR менеджера дать вам тестовое задание, если это не принято. Нафиг ей/ему напрягаться.
1. Не спрашивайте про основы ООП и вообще синтаксис ЯП. Вы не столько проверите знание соискателя, сколько покажите свою некомпетентность. Вы спросите, а как же отсеять лгунов? Все просто, давайте предположим, что перед нами действительно честный сениор. А значит это не просто человек, который знает синтаксис ЯП — это в первую очередь специалист, который умеет самостоятельно решать задачи любого уровня сложности! И сможет решить эти задачи на любом ЯП, даже на том, которого в глаза не видел. Отсюда переходим к п.2
2. Опытный специалист работал с разными проектами и выполнял нетривиальные задачи. Вот и начните его спрашивать, какие сложные задачи он выполнял, в чем была сложность и как он это решал. Пусть человек плавает в своих водах опыта и знаний. А не в ваших, о которых он ничего не знает. Если вы не понимаете о чем начинает рассказывать специалист, если вы впервые слышите о таких решениях и подходах, значит собеседовать таких специалистов — это не ваш уровень. Предположим, что это ваш уровень, тогда переходим к п.3
3. Исходя из ответов п.2 вы можете задавать уточняющие вопросы: а какая была нагрузка на проект, а как вы с ней справлялись (уточнение про кэширование, шардинг, репликации, оптимизации запросов и т.д.), а как организовывали быстрый отклик при тяжелых операциях (вебсокеты, потоки, слушателиб очереди и т.д.)
4. Если человек вас пытался дурачить, то вы это тут же поймете. Если нет, то вы узнаете что хотите и может и сами немного прокачаетесь.
5. Если нужен реально хороший специалист, то знание ЯП вторично! Это джунам нужен ЯП, как старт в профессию. Спецы же высокого уровня должны строить алгоритмы, архитектуру, находить разные подходы к нетривиальным задачам.
6. Если вы на позицию сениора ищите исключительно послушного кодера — то ваш бизнес уже проиграл, просто вы еще этого не знаете.
Вот и начните его спрашивать, какие сложные задачи он выполнял, в чем была сложность и как он это решал.
Вообще странный вопрос, к слову. Сложная задача — это задача, которая далеко выходит за пределы компетенции исполнителя (то есть исполнитель не может решить задачу в приемлемые сроки с приемлемым качеством). Любую другую задачу, согласитесь, не имеет смысла считать сложной, это уже будут задачи простые. Или обычные.
Но если такие задачи специалисту дают — это факап менеджмента, такого в норме быть не должно.
Вообще странный вопрос, к слову. Сложная задача — это задача, которая далеко выходит за пределы компетенции исполнителя (то есть исполнитель не может решить задачу в приемлемые сроки с приемлемым качеством). Любую другую задачу, согласитесь, не имеет смысла считать сложной, это уже будут задачи простые. Или обычные.
Но если такие задачи специалисту дают — это факап менеджмента, такого в норме быть не должно.
))) И тут мы приходим к понятию декомпозиции, к алгоритму поиска эффективного решения для того, чтобы вообще найти подход к тому, как начать решать эту проблему/задачу. Ведь программирование — это не просто написание кода! Это, наверняка, даже не десятая часть в разработке ПО.
Просто произошла дикая подмена понятий! Ведь если мы взглянем на вики определение программиста, то увидим:
Программи́ст — специалист, занимающийся непосредственной разработкой программного обеспечения для различного рода вычислительно-операционных систем.
То есть программист должен решать ЛЮБЫЕ проблемы для достижения цели. А что происходит в реальности?! Тот кто знает синтаксис ЯП и основы ООП, уже считается программистом. А вот и нет! Это не программист, а эрудит, заучивший справочник.
Отсюда и куча проблем, недопонимание и прочие глупости на проектах.
Полностью согласна. Что знание терминологии нужно спрашивать на уровень Джуна. На остальные- опыт и примеры кода. Ибо если человек не первый год программирует, то он уже это всё знает.
П.С. Все более или менее нормальные места, куда я попадал, спрашивали о том, как бы я решал конкретную бизнес задачу заказчика. А все говноконторы, которые были мной посланы, постоянно спрашивали про синтаксис, джоин двух табличек на бумажке и прочую блевотину. Первые платили зарплаты по три штуки, вторые начинали ныть про свой бюджет в тысячу, ну максимум полторы. Разница, как говорится, на лицо.
А представьте себе переключаться постоянно с одного бэкендевого ЯП на другой?
Да, но здесь собеседование на конкретный язык. Если ты подзабыл детали именно этой платформы из-за частого переключения, то это твоя задача — освежить свои знания по этой платформе.
он слету будет послан на три буквы, вместе со своей говноконторой.
На ваше место просто возьмут другого человека, более адекватного в общении с тем же опытом работы. Вы не уникальны.
Первые платили зарплаты по три штуки, вторые начинали ныть про свой бюджет в тысячу, ну максимум полторы. Разница, как говорится, на лицо.
Скорее конторы с малым бюджетом не могут себе позволить взять человека, который не будет отрабатывать свою зарплату, поэтому и проверяют тщательнее — у них риски больше.
Да, но здесь собеседование на конкретный язык.
Я вот пришел в одну контору, как пыхер, а через месяц работы руководство подумало и решило, а ну эту пыху нах, переписываем все на питон. И чо? Что делать в таком случае? Толку от вакансии на конкретный язык?
На ваше место просто возьмут другого человека, более адекватного в общении с тем же опытом работы. Вы не уникальны.
Что там будет дальше мне уже не интересно. Я еще никогда не сидел без работы.
Вы не уникальны.
Каждый толковый специалист по своему уникален. И именно их постоянно и не хватает. А вот всяких «молодых и динамично развивающихся» говноконтор пруд пруди. Я уже про такие писал: cleverman.org/post/problemy-pri-roste-it-kompanii
Скорее конторы с малым бюджетом не могут себе позволить взять человека, который не будет отрабатывать свою зарплату, поэтому и проверяют тщательнее — у них риски больше.
В таких конторах тимлидом является джун со смешной зарплатой. Зато крутой лычкой на рукаве. И когда приходит собеседоваться в такую контору толковый специалист, то у такого тимлида пукан разрывает на части.
И поэтому не особо рву себе пятую точку. Это тут многие пытаются друг другу доказать свою крутизну, смешными способами. А я уже все доказал, в первую очередь самому себе.
Отлично, значит вы просто разойдетесь с таким потенциальным работодателем и никто не уйдет обиженным.
Я вот пришел в одну контору, как пыхер, а через месяц работы руководство подумало и решило, а ну эту пыху нах, переписываем все на питон. И чо? Что делать в таком случае? Толку от вакансии на конкретный язык?
А я пришел в одну контору и девять лет мы пишем основную часть продукта на одном языке. Есть одни проекты, где каждый год что-то переделывается, есть другие.
Что там будет дальше мне уже не интересно. Я еще никогда не сидел без работы.
Поверьте, и они плакать не будут. Не сошлись во взглядах и до свидания. К чему все ваши посылы про «говноконторы»? Вы намеренно стараетесь принизить их относительно своего, согласно своим же суждениям, уровня? Это выглядит как психологическая защита вида «не очень-то и хотелось».
Каждый толковый специалист по своему уникален.
Здесь слишком широкий простор для манипуляций словом «толковый», поэтому пропускаю.
В таких конторах тимлидом является джун со смешной зарплатой. Зато крутой лычкой на рукаве. И когда приходит собеседоваться в такую контору толковый специалист, то у такого тимлида пукан разрывает на части.
Вполне допускаю. Но равно допскаю, что на деле кандидат — надутый индюк и слишком высокого о себе мнения. Мол, я 30 лет
Разошлись и всё — они при своем, кандидат — при своем. Кандидат пойдет в соседнюю контору, где не будут проверять базовые знания, эта контора — наймет следующего человека, который не будет попусту гнуть пальцы.
Лично для меня показателем профессионализма является тот факт, что у программиста есть свои личные проекты, личные наработки, может свой блог, статьи и аналитика на разные темы, может быть опенсорс решения. А когда многие бьют себя пяткой в грудь о своем профессионализме, но вот к сожалению показать вообще нечего не могут, даже пусть и не очень удачных решений или хоть какой статьи, пусть сухой и не супер интересной, да хоть что-нибудь, вот тогда меня начинает одолевать тоска и уныние. А так, конечно, везде сплошь одни гении, которые всех остальных считают ламерами.
Но лично я бы девять лет в одном проекте на одном ЯП в одной и той же конторе, покончил бы с собой
Это очень сильно зависит от конкретной конторы. Проект очень большой, у него много частей и работать приходится с разным. вот сейчас пришлось изучать JS/React потому что и фронтэндом занимаемся, и еще ряд других языков, плюс свой собственный скриптовый язык для бизнес-логики, движок которого тоже мы разрабатывали и т.д. Но я говорю про основной язык. А остальное — да, изучается по ходу.
Но еще и суть в том, что реально толковые ребята любыми усилиями пытаются вырваться из такой ситуации, и пытаются создать и раскрутить свои проекты. И некоторым это удается
Здесь опять же слово «толковый» значит всё и ничего одновременно. Есть предприимчивые люди, есть просто специалисты своего дела.
И тогда они уже совсем другими глазами взирают на этот чудо рынок в отечественных реалиях
Ну, у нас рынок американский — в среднем очень консервативный, но не суть.
А когда многие бьют себя пяткой в грудь о своем профессионализме, но вот к сожалению показать вообще нечего не могут
Иногда сложно показывать проприетарный код. Вот сейчас хочу написать небольшую статью сюда об одном трюке и то лишь потому, что это решение было вторым по совокупности параметров и потому в работу не пошло. А первое так и остается закрытым.
А так, конечно, везде сплошь одни гении, которые всех остальных считают ламерами.
причем с обеих сторон — как среди кандидатов, так и среди нанимателей. Спорить на самом деле не о чем, как не о чем в общем-то и жаловаться — ну не подошла ТСу контора по параметрам отбора, так и шут с ним — сколько работы вокруг, за всю жизнь не переделаешь.
В таких конторах тимлидом является джун со смешной зарплатой.
В чем можно быть уверенным — в том, что отбор персонала (в том числе и первичный) проводят будущие коллеги.
А не HR, которые по бумажке по списку требований подбирают и считают, что JS и ES — это разные вещи.
Я вот пришел в одну контору, как пыхер, а через месяц работы руководство подумало и решило, а ну эту пыху нах, переписываем все на питон. И чо? Что делать в таком случае? Толку от вакансии на конкретный язык?
И че? Сразу всех прежних PHPшников уволили и приняли новых Pythonистов?
Вам здоров повезло поучиться за счет работодателя, расширить свой кругозор — да еще и за чужие деньги.
Что там было с экономической целесообразностью для конторы — не ваше дело, если не вы владелец. Хотя, если вы себя считаете достаточно компетентным специалистом — было бы замечательно, если бы вы подошли к руководству и объяснили вопросы рентабельности такого перехода. Собственно Вас только потому и наняли, что специалист в вашей сфере именно вы — зарплату вам платят именно за то что вы используете ваши технические знания во благо конторы.
Неоднократно отговаривал руководство от технически и экономически неэффективных выборов технологий.
В чем можно быть уверенным — в том, что отбор персонала (в том числе и первичный) проводят будущие коллеги.
Тут нужно очень четко определиться, что кому нужно. Если, к примеру, вам, нужно всего лишь попасть в компанию и получить средства к существованию, тогда да. Нужно все зазубрить, заискивающе заглядывать в
Кто что ищет, не больше не меньше.
В таких конторах тимлидом является джун со смешной зарплатой. Зато крутой лычкой на рукаве. И когда приходит собеседоваться в такую контору толковый специалист, то у такого тимлида пукан разрывает на части
По мне так — это все разные конторы.
Не очень представляю — как так вчера был тимлидом джун, а завтра руководство уже осознало, что им нужен спец и поручили джуну собеседовать спеца, чей оклад будет в 3 раза выше.
Если руководство осознало, что их сотрудник слишком слаб — то будут искать нового в обход старого сотрудника.
Тут нужно очень четко определиться, что кому нужно. Если, к примеру, вам, нужно всего лишь попасть в компанию и получить средства к существованию, тогда да. Нужно все зазубрить, заискивающе заглядывать в жоп… в глаза собеседующему, ловить каждое его слово, как благословение божье и т.д. Но если же вы хотите найти то место, где в вас реально будут нуждаться, как специалиста, им очень важен ваш опыт, знания и их собираются использовать на максимум, вам дадут сферу ответственности и широкие полномочия, то вы точно не будете на собеседованиях пресмыкаться и делать вид, что вас спрашивают именно то, что должны.
Если контора нуждается в спеце — то сие означает вполне определенный уровень собеседования.
Если контора нуждается в джуне — то такого может и джун пособеседовать.
Если контора нуждается в спеце, но не может обеспечить нормальное собеседование — это проблема конторы, а не нанимаемого.
Только сдается мне, что вы сгущаете краски:
За последние 20 лет, что я собеседуюсь — ровно один раз встречался на собеседовании «джун-тимлида, у которого пукан порвало». Прикольно, через пару лет он уже ко мне приходил собеседоваться…
Если, к примеру, вам, нужно всего лишь попасть в компанию и получить средства к существованию, тогда да. Нужно все зазубрить, заискивающе заглядывать в жоп… в глаза собеседующему, ловить каждое его слово, как благословение божье и т.д.
Вы уж определитесь — спец вы или джун
Джунов сейчас перебор — да, можно и позаискивать. Конкуренция-с очень велика.
Если вы спец — то на вас самого охотятся хэдхантеры.
Как говорил отец Фейнмана:
"«Видишь эту птицу?» — спрашивал он сына. — Это певчая птица Спенсера. Ну так вот, по-итальянски это Чутто Лапиттида. По-португальски: Бом да Пейда. По-китайски: Чунь-лонь-та, а по-японски: Катано Текеда. Ты можешь знать название этой птицы на всех языках мира, но, когда ты закончишь перечислять эти названия, ты ничего не будешь знать о самой птице. Ты будешь знать лишь о людях, которые живут в разных местах, и о том, как они ее называют. " -вот примерно того же стоят все академические определения.
Для себя я уже давно решил следующую весчь. Если со мной начинают собеседовать, я говорю стоп чуваки. Дайте мне небольшую задачку, на день-три, желательно связанную с предстоящей работой. Поглядите как я её решу, увидите стиль моего мышления, стиль написания кода, тогда и поговорим. Если мне говорят что мол у нас такие принципы, я отвечаю что у меня свои принципы, и очевидно мы друг другу не подходим. Но очень часто соглашаются.
По рассказанной Вами истории считаю что Вам повезло. Попали бы в проект, говна с такими манагерами хлебали бы половниками. Лучше от такого счастья держаться подальше.
Тут сошлась и животрепещущая тема, и достойный автор, которого можно поднять на щиты (не как в финале «Спартака»).
Но подозревать разрабов в самозванстве — никак не «хватит», ведь именно для этого, в том числе, и проводятся собеседования — чтобы подозревать в тебе самозванца и дилетанта. Это для кого-то унизительно, это чревато ошибками, а у нас у разрабов отношение к ошибкам профессионально нетерпимое, но тут тот случай, когда придётся забить на баги и пройти мимо. Иначе, по административной логике, мне кажется, если к нам с вами прислушаются, станет ХУЖЕ. Перепоручат всё эйчарам, как в сеттинге вот этого рассказика: habr.com/post/417431
Таки да, вполне возможно, крутая контора прошляпила крутого спеца.
Ну, бывает.
Или верно что-то из домыслов предыдущих комментаторов относительно компании, вакансии (её реального значения) или ЛПР. Или не верно ничего. А просто автор статьи действительно им не подходит. Некоторая вероятность, что он overqualified, и ещё меньшая — но, простите уж, не нулевая — что он underqualified.
Кстати, Ваша реакция вопросы на «память и зубрёжку» на собесе — неплохой такой звоночек.
На самом деле, вопрос, «лучше всё помнить или лучше понимать любой вопрос? Можно ли хорошо разбираться в вопросе, если не зубрить?» — в науке, не говоря уже о программировании, ещё не решён однозначно. В экономической науке есть подход Густава Шмоллера и… этого… ученика, забыл фамилию — который «перешмоллерил самого Шмоллера», например…
Если человек открыто бесится, что ему задали вопрос на начётническую память — не обязательно человек не умный, не понимающий, но… человек трудный.
ИТ тут не причем. Девы тут не причем.
Представьте, что на собеседование шофера начнут по ПДД гонять? будет тоже самое, люди с 30-летним опытом и водителя и механика завалятся на мелочах.
Тоже самое.
начнут по ПДД гонять
— На какой сигнал светофора вы обычно проезжаете перекрёсток?
— Оппа… язобыл.
1) Вне перекрестка, трамвайный путь пересекает полосу движения. Трамвай выезжает из депло. Должны ли вы уступить дорогу?
2) Транспортные средства, на которых производится обучение езде, должны иметь опознвательные знаки («У»), за исключением каких транспортных средств?
3) На каких дорогах запрещена буксировка во время гололедицы?
4) Кстати, какая максимальная скорость разрешена при буксировке?
Если вы думаете, что в ПДД сложно найти вопросы, которыми легко завалить опытного водителя, то просто полистайте ПДД.
1) Рельсовый транспорт имеет преимущество перед не рельсовым. Нужно уступить.
2) Никаких исключений.
3) Какая именно буксировка? На гибкой сцепке или на жесткой? По моему на любой дороге запрещена во время гололеда.
4) Хороший вопрос )) Они постоянно в ПДД меняют всякие скоростные ограничения, хрен поймешь. И опять у меня уточнение про гибкую и жесткую сцепку. На первую ставлю до 40 км/ч, на вторую до 60 км/ч
Когда в 96 году в первый раз сдавал на права, то вождение прошел, а на правилах засыпался. Через две недели была пересдача правил. При чем ПДД знал неплохо. Но когда увидел вопросы в билетах, я просто прозрел. Картинки полное говно, все нечетко и противоречиво. Даже отлично зная ПДД хрен сдашь. На пересдачу я поступил по другому. Я тупо выучил все билеты наизусть. Сдал за минуту, сразу 10 из десяти.
Но как по мне — это огромная тупость. Заучивание идиотских ситуаций ничего не дает в реальности. Плюс коррупцию неплохо подпитывает.
Но это еще все фигня. Я когда сдавал экзамен в министерстве «Охоты и рыбалки» на получение охотничьего билета, то мне попался вопрос: сколько яиц приносит дрозд? Вот это я тогда на жопу и сел. Как это поможет при охоте и рыбалке я ХЗ. В итоге дал денег, абсолютно все так проходят: нужно купить их тупую книжку и дать денег.
2) Неверно. Исключения — мотоциклы
3) Верно.
4) Неверно. Просто 50 км/час.
Суть в том и заключается, что на ИТ собеседованиях у программистов сейчас часто спрашивают именно подобные штуки, которые не нужно заучивать наизусть, ибо такие вещи всегда можно нагуглить за секунду. Гораздо важнее, чтобы человек умел программировать и адекватно относиться к работе. Но вся статья о том, что встречаются идиотские интервью.
Суть в том и заключается, что на ИТ собеседованиях у программистов сейчас часто спрашивают именно подобные штуки, которые не нужно заучивать наизусть, ибо такие вещи всегда можно нагуглить за секунду. Гораздо важнее, чтобы человек умел программировать и адекватно относиться к работе.
Полностью поддерживаю.
А сам я недавно искал работу и удивлялся почему на каждом интервью в начале спрашивают чем отличается интерфейс от класса, рекрутер мне потом и поведал, что практически на любую вакансию разработчика есть десяток претендентов с красивыми резюме, и такими вопросами можно их отсеять и съэкономить время.
+не «не знаю», а «не помню».
Тут недавно был перевод и у автора бомбило с убогости софта и окружающей действительности. Может все это от сениоров которые не знают virtual и отлично справляются с работой?
Это от требований бизнеса сделать все еще вчера и дешево, а требования бизнеса — от реалий в экономике и конкуренции.
Если тебе нужно срочно заткнуть дыру — то не до красивых абстракций.
В статье по Вашей ссылке — больше про целеполагание, я так понимаю, причём, стратегическое, а не про virtual.
Впрочем, ТС, Якiй ти в чорта лыцарь, коли голою… далее по тексту.)
Наверное, многие самонадеянные крутые спецы в сложных областях любят такое.
И — нет, не буду пенять им ограниченным временем собеседования или впечатлением интеллектуального снобизма и вербальной агрессии.
Я просто предлагаю коллегам подумать в общем, какие вопросы они бы задали, чтобы в ответ не началась притча, агада либо вообще кадиш и помимо общего приятного впечатления о человеке и его пытливости можно было бы определить, сработаетесь ли, в рамках жёстко заданных подходов. Притча ещё тем плоха, что не у всех у нас прокачаны литературные и ораторские способности. А если ещё поверх смущения (для того, чтобы видеть смущение, и понадобился видеочат) — то те способности, что есть, делите на 10 и сравнивайте с «левелом босса».
Человек который не может ответить на этот вопрос скорее всего не в курсе про полиморфизм и не сможет правильно его применять. Это уровень джуна, увы.
Прохождение собеседований — это отдельный навык, и он не сильно коррелирует с твоими реальными знаниями как работать. Его также надо время от времени тренировать, проходя собеседования.
что за «сеньйоры» пошли…
как можно не знать что есть virtual?
Не "не знать", а "не помнить", что очень просто, если последний раз, когда писал на сях, был в универе. Реальная жизнь требует от меня знания совсем других языков.
Что ты хотел
Чудны дела твои, господи — в наше время признаком мужественности считалась безукоризненная вежливость в любой ситуации, а теперь — маты-перематы...
_Просто_ забей на м***ков и ищи тех, кому «очень-очень надо фичи, а не вот эти ваши программистские заумства» (бизнес, ну и ЛПР в бизнесе особенно надо искать). Приходи к ним даже не с кодом, а с понятными демками по _ихней_ тематике (специально «ихней» написал, чтобы «раздаржитель» хорошо запомнился :))
В итоге и доход твой вырастет в разы (x2 — самое малое) и уважуха тебе будет и общение на собраниях с руководством по бизнесу и «по теме» напрямую (а деньги они оттуда — из бизнеса, а не от virtual и «заумных очкариков») и слушать тебя (как проявишь себя конечно) будут ну _очень_ внимательно.
Моя история (кому-то надеюсь добавит оптимизма):
Как-то так вышло, что в самый неподходящий момент (мы с женой в отпуске в Таиланде, денег потрачено уйма, а осталось соответственно мало) проект «внезапно» закрылся (я вообще по email узнал) по независящим от меня бизнес-причинам (хотя я долго ходил и капал на мозги руководству, что «так не прокатит с т.з. бизнеса и даже тупо математически вот тут и вот тут экономика не сойдётся», типа что надо по другому — не послушали, ну и в результате «утёрлись» все, а не только я).
И пошёл я по привычке пособеседоваться в пару местных контор.
Ёмаё, я и не знал, что в мире столько задр***ов-очкариков, которым важно «пройти по строке, перевернуть там слова каждое отдельно внутри строки, но при этом использовать только 2 (два) указателя для жёсткой экономии RAM» (я в микроконтроллерах stm8 так не экономил даже!) — и всё это за 10 минут на бумажке написать. (если что это не стандартное «строку перевернуть», просто пустив указатель бежать обратно)
Я правда потом сталкивался с этими неадекватами на одном форуме, где они предлагали «хакатон под наше железо, но вы код пишите без него, а самым успешным мы даже дадим разок прошить попробовать». Компанию называть не буду, тем более она известная и хэдофис думаю у них адекватный — это «местячковые» боссы «дуркуют» тут :)
Ещё в одной конторе мне в качестве «тестового задания» пытались втюхать нехилый такой НИОКР на неделю не меньше (связано с ультразвуком и его распространением. в принципе при словах «Сколково» мне надо было сразу послать их лесом, а не вести диалог — сам виноват :)))
В итоге я пошёл увольняться «в никуда», причём родные кадровички расставались со мной как-то легко и это добавляло мне грусти и печали.
В результате я пошёл «к главному на окончательную подпись» и тут… он встретил меня (хотя я его мало знал — видел в коридорах пару раз) чуть ли не как родного: «Саш, привет! Что-то это у тебя? (взял листок, аккуратно сложил вчетверо). А ты это… серьёзно? причины?»
Ну тут я сказал, что типа проект закрылся, мне наш главный сказал, что финансирования нет и всем надо искать работу.
На что он округлил глаза, позвонил кадровичкам и убедительно попросил «ошибок впредь не допускать, пожалуйста, ну хотя бы человека спрашивать причины!», ну и рассказал, что оказывается намечается крупный проект и народ наоборот днём с огнём ищут, а мои скилы крайне там бы пригодились, особенно C++, QNX и т.д. В общем я «как в сказку попал», причём потом выяснилось, что да, не обманули — было и интересно и з/п норм и мир повидал ещё разок нахаляву (командировки-с).
Жизненный урок: НЕ слушать **упое «местячковое» начальство и тем более не вести с м***ками диалоги — выходить на «боссов» (ЛПР), чем раньше тем лучше! (хорошо что у меня хоть и случайно но так и вышло)
Ну а далее друзья сделали так же (но не в этой стране) и меня позвали с ними работать.
Сейчас работаю напрямую с заказчиками (прямее некуда), в офис переться не надо, глупости ничьи слушать не надо, если с чем-то не согласен или есть идеи — велкам, всё обсуждаемо (главное чётко разъяснить и обосновать).
Выводы: выходить на ЛПР, выходить на «бизнес», выходить на _заинтересованных_ лиц, не «умничать», а предлагать и объяснять это без надменности АйТишной доступным языком бенефиты от того или иного решения.
P.S. Очень надеюсь, что мои наблюдения и выводы помогут людям, попавшим в ситуацию как у меня (см. «многабукаф» выше) и как у автора статьи.
Хоть мне и скоро 40, но пишу тут простым «пацанским» языком — нафиг вот весь этот пафос, надо называть вещи своими именами.
«Улыбайтесь! Ведь все самые большие глупости в мире совершаются именно с серьёзным выражением лица!» (с) х/ф «Тот самый Мюнхаузен»
есть знания теоретические, и есть практическая производительность. Один разработчик сделает за месяц условно 100 юнитов, а другой 20. Один въезжает в проект за неделю, а другому надо месяц потратить. И т.д.
Собеседования в основном выявляют что-то там по теории, поэтому выхлоп от них не очень. Написать тестовое задание и потом объяснить решение — это уже получше, но тоже не дает всей полноты картины. Для сокращения времени набора идеально было бы брать на одну позицию три или более кандидата на испытательный срок и потом оставлять на постоянную лучшего. Несколько жестко к отсеиваемым, но у нас же капитализм…
юниты? это деньги такие? :)
для бизнеса пофиг сколько там юнитов кто делает. для бизнеса важен _результат_: деньги — в кассе.
а пиши хоть на C++, хоть на BASIC, хоть вообще на китайском иероглифами.
кто-то в задачу въезжает за неделю, делает всё добросовестно, но делает «не то». а кто-то думает месяц, приходит к боссу и говорит: так не надо. надо вот так. вот презентация и демка, вот — отзывы, вот — промахи конкурентов, сравните — всё сами поймёте.
важно не _правильно_ делать дела, а делать _правильные_ дела.
сейчас всем интересующимся так и говорю: «каюсь. 10 лет притворялся что знаю C++ (а также Java, а точнее Android, а также другие языки и технологии), вот список проектов где я притворялся — можете позвонить им, спросить про меня. мне им звонить стыдно — могут обратно позвать, а 2-й раз врать как-то уж совсем некрасиво :)»
Первое — собеседование это не только про технические навыки, но и про то, как вы вольетесь в команду. Причем не факт, что вливание в команду менее важно. Кандидат должен просто богоподобным разработчиком, чтобы можно было закрывать глаза на его отвратительные софт-скиллс. Мне такие, к сожалению, пока не попадались, поэтому глаза закрывать повода нет. По вашим фразам, цитирую, «Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего.», у меня складывается ощущение, что общаться с Вами собеседующему при дальнейшей работе, возможно, было бы непросто. Возможно, он это почувствовал в какие-то моменты, а потому задавал вопросы с большим усердством, чтобы точно убедиться адекватный ли вы в общении человек. Быть может, ему показалось, что не очень.
Второй момент — по технической части. Лично я не очень представляю, как можно забыть, что такое virtual (не по определению, а не суметь даже своими словами рассказать для чего и почему используется). Топить бы я за это не стал, но звоночек был бы. Да и представьте себя на месте собеседующего. Ему каким-то образом надо понять технический уровень кандидата. Вариантов для этого не так много:
— либо смотреть тестовое задание (их мало кто любит вообще делать, особенно из хороших разработчиков),
— либо смотреть ответы на небольшие предсобеседовательные вопросы (мы у себя сейчас практикуем такой подход),
— либо расспрашивать подробности о предыдущем проекте (он не всегда может быть релевантным, да и как правило подробностей особых не выудишь, а если и выудишь — то без взгляда на код не всегда интервьюер можно легко погрузиться в описание проекта и задать правильные вопросы),
— либо банально задавать вопросы по чек-листу (то с чем Вы и столкнулись)
— либо давать маленькую практическую задачку (тоже часто не связанную с реальностью, т.к. задача побольше, из реальной практики, с учетом стресса, который испытывает собеседуемый во время интервью, почти наверняка не сможет быть хорошим фильтром)
Чаще всего все эти варианты в той или иной степени комбинируются. Это позволяет отсеивать люто неподходящих кандидатов (таких подавляющее большинство). При этом конечно же в фильтр иногда могут не проходить и действительно хорошие профессионалы, но, как уже упоминалось многократно предыдущими комментаторами, — гораздо важнее не взять на работу очень плохого кандидата, чем пропустить одного хорошого. Главное держать баланс.
Третье — я, например, при беседе, если чувствую, что кандидат совсем не подходит на заявляемую должность, пытаюсь прощупать те темы, в которых он более-менее хорош, чтобы, возможно, предложить ему позицию пониже. Быть может, по каким-то предыдущим вопросам, Ваш интервьюер тоже это понял, и просто прощупывал подойдете ли Вы на другую позицию?
КМК, большинство собеседующих (исходя из моей практики прохождения собеседований и со стороны претендента) — это все-таки совершенно адекватные люди, без желания кого-то завалить, а уж тем более «расплываться от гордости», «светиться» и т.д. Просто есть вполне конкретные цели от собеседования, конкретные требования к кандидатам, и Вы в данный момент их не удовлетворили.
Также как и они Вас. Это же хорошо, что все хорошо закончилось, и Вам не пришлось работать на нелюбимой работе.
По вашим фразам, цитирую, «Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего.», у меня складывается ощущение, что общаться с Вами собеседующему при дальнейшей работе, возможно, было бы непросто
Полагаю все дело в этом:
Я только что с собеса, и у меня бомбит.
Просто написано не на холодную голову.
Поскольку у нас с вами больше половины времени уходит на отладку, а не на перебор инструментов и имплементацию — можно потратить некоторое время на уточнение деталей ответа на вопрос: «какие ОШИБКИ допускают люди с технологией (...)?» «Какие НЕПРАВИЛЬНЫЕ ПОДХОДЫ ты знаешь к...?»
Однако такие вопросы ни сколько не дают понять о том как человек умеет работать, его логике, опыте, обучении, принятии решений и творческом конструировании. Но все же отличных программистов без знания теории не бывает — и если он в обоих этих аспектах выступил на отлично — то что и думать «true senior!».
Но! Кандидат все таки приходит устраиваться на «работу», работа — то есть практика и возможность обучаться/адаптироваться к тонкостям конкретной организации — тут несоизмеримо боле важна чем знание что такое virtual…
А с чего вы взяли, что вы вообще синьор? Давайте введём определения:
Джун — тот, кому нужно помочь с решением.
Мидл — тот, кто найдёт решение самостоятельно.
Синьор — тот, кто знает все способы решения задачи и может объяснить их преимущества и недостатки.
Вы сами признались, что избегаете наследования, поэтому не помните такую немаловажную при наследовании идиому, как "виртуальный метод". Это уровень Милда — решать все задачи одним знакомым способом.
Так что да, вы оказались самозванцем, и вас вывели на чистую воду одним простым вопросом. Это не повод бомбить. Это повод подумать над тем, как перейти на качественно новый уровень. Вы уже достигли уровня, когда самостоятельно можете решить даже сложную задачу. Пришла пора расширять кругозор и углублять понимание идиом. Готовьтесь всё чаще отвечать не на вопрос "Как?", а на вопрос "Почему так?". А для этого нужно быть хорошо знакомыми даже с теми вещами, которые не используете. И постоянно проводить ревизию своих знаний, так как мир программирования меняется очень быстро. То, что вчера считалось анти-паттерном сегодня в тренде. А что вчера считалось единственно возможным — сегодня анти-паттерн.
Проходила собеседование на мидла. Повторила что такое ООП, паттерны. Что нового появилось в PHP 7. До этого меня об этом спрашивали. И как говорится я не 1 и не 2 год программирую. Но вот вопрос меня поставил в ступор — назовите все типы данных. И в голове почему то вплыла инфа в новых поддерживаемых типах при объявлении переменных. Начала перечислять самые простые. Сходу сказала не все, даже массивы не назвала. Но это не из-за того что не знала. А просто не ожидала такого вопроса. Да и собеседующих было 3. Волнение никуда неденешь.
Помню один случай с далекой-далекой знакомой, проходила на бренд-менеджера в одной крупной компании из пищевой промышленности. На собеседовании ей показали ролики с рекламой их продукта — один ролик с милой семьей, во втором главный герой — горилла. Ей предложили выбрать какой больше нравится. Она выбрала ролик с семьей и как-то обосновала. В итоге после собеседования ей отказали обосновав тем, что она им «по духу не подходит». Ну а через месяц уже везде можно было видеть рекламную компанию как раз с гориллой. ))
Хотя до такого надеюсь не дойдет.
Просто это обычная ситуация для упомянутых мной сфер, где субъективный взгляд играет намного большую роль, а всякие там сертификаты «супер-мега финансиста» заменяют наличие здравого смысла. И надеюсь, что в ИТ индустрии все таки до этого не дойдет.
Хм… вообще, там вроде сарказм был (по крайней мере, я очень на это надеюсь). Какой им смысл нанимать человека (пусть он хоть супер-профессионал), если у него видение продукта и его бренда противоположное команде? Он же и дальше будет пропихивать сопливые ролики с милой семьей, если всей остальной команде это не надо, то постоянно будут одни конфликты.
Если вам отказали на собеседовании – это не обязательно значит, что вы плохой специалист. Это значит, что вы не подходите в эту команду. Поэтому я даже не представляю, зачем по этому поводу столько рефлексировать.
В данной статье я увидел некоторое сходство данных случаев (описанных в статье и с которыми я встречался), или скорее присутствуют некие тенденции по сближению.
проходила на бренд-менеджера в одной крупной компании из пищевой промышленности. На собеседовании ей показали ролики с рекламой их продукта
просто она заведомо не проходила.
стресс-интервью на бренд-менеджера или, там, датамайнера — плавали, знаем.
Вместо эпиграфа: Представьте себе, как Товальдс проходит собеседование в Майкрософт… или в 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.
Вот есть у нас 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-ступенчатой; но гуглятся и более изощрённые системы.
принципы SOLID или подробности работы сборщика мусора в вашем ЯП
По поводу заучивания SOLID соглашусь, оно вполне интуицией/наработанной практикой заменяется… Но вот про «подробности работы сборщика мусора в вашем ЯП». А кто, простите, если не сеньор, должен понимать, как оно действительно работает? Есть множество программистов, способных написать код, соответствующий определенным критериям «корректности», но они миддлами называются. А вот когда «все предельно корректно», но почему-то все равно тормозит — тут миддл не решит, тут сеньор и нужен. А он уже разбирается «так, мол, и так, вот тут сборщик мусора нагрузили, если переделать через чутка хитрозаверченную попу, будет тормозить меньше, в пределах таких-то показателей».
Джун — это программист без опыта, который пока еще не умеет гарантированно генерировать формально правильный код. Он неизбежно с опытом должен мутировать в миддла (или пойти «на мороз» по хорошему) — в человека, который может самостоятельно генерировать формально-корректный код. И есть «сеньор», гарантии превращения в которого из миддла никто не дает. Сеньор — это такая штука, которая способна разобраться, почему формально-корректный код работает не так, как предполагалось.
Или у вас какие-то другие понятия о «сеньорстве»?
В Go передача параметра по указателю — вещь достаточно опасная. У него сборщик мусора шустрый, но достаточно простенький, и лишний раз нагружать малыша не рекомендуется. В определенных комбинациях мы можете а) нарваться на аллокацию в куче, б) просадить производительность на сборке мусора. Из экспериментов: структуры данных размером 250-300 байт и меньше лучше отдавать по значению — так будет реально быстрее. Но при этом стоит помнить, что стек не резиновый.
В Java той же несколько сборщиков мусора, и надо понимать, какой из них и как скажется на производительности.
C++ вообще имеет смысл использовать для ручного управления памятью, т.е. надо знать, как с ней работать.
Думаю, миллион нюансов можно найти.
1. Люди которые заточены исключительно на теоретических аспектах. И не особо умеют сами что-то придумать.
2. Люди которые могут сами придумать, что-то новое, но теорию знают не полностью.
3. Творческие люди которые знают теорию и используют её с толком. (такое объединение 1 и 2)
Тут основная проблема такая:
Разработчиков типа 1 очень много, 2 поменьше и 3 совсем мало, единицы.
Работодатели ищут 1 и 3. Но 3 уже работают в Яндексах, Контаках и других интересных местах.
А суть в том, что теоретик (1), никогда не станет крутым разработчиком (3), в то время как думающие программисты (2) вполне могут стать (3). Но (2) гнобят, и им сложно стать (3). Такой замкнутый круг.
А вот Вы, в отличие от опытного автора, имеющего пруфы своей ценности для бизнеса и для задач отдела, уже строите аргумент примерно как «но я же разработчик, а не зубрила. Почему во мне должны увидеть разработчика? Потому что я не зубрила».
Я никого не троллю и никого не стараюсь дискредитировать, тем более, Вы тян.
Но если позволить себе роскошь ничего не утверждать… вот есть такая вещь, как нечёткая логика… и осторожно замечу себе под нос, что вот это — простите, маркер:
Это очень обидно, ведь программист работает с интернетом
Скажем так. Будь я интервьюером, я бы как минимум задал Вам наводящий вопрос: «а когда, Вы считаете, пора обращаться к коллегам и помощникам из интернета за решением своей задачи?»
гораздо важнее видеть систему в целом
ну, и ещё один наводящий вопрос. Что Вы понимаете под «видеть систему в целом»?
Вы, наверное, все спеки 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 не работаю уже больше года) и получил пищу для размышления.
Для себя с удовольствием отмутил, что на эти вопросы я ответы знаю, разве что в MutexSlim смысла не вижу, проще уж спинлоки использовать. Хотя вот про отличие транзкций не ответил бы ибо с постгресом не работал. Про изоляции кстати долго не мог заучить, пока на практике не понадобилось разрешать дедлоки (из-за повышения shared_lock до unique). В одной конторе было целое тестовое задание на это, очень мозги прочистило. Можете тоже повторить: есть таблица с пользователями. И мы делаем в АПИ метод RevertSex который меняет в базе булку IsMale. В запросе приходит фамилия пользователя — ищем пользователя по фамилии, меняем пол (считаем, что фамилия уникальна) на противоположенный.
Так вот, если запустить этот пример для десятка пользователей (разных) в разных потоках, то выполнение начнет тупить и очень долго всё будет отрабатывать. Задача — сделать так, чтобы отрабатывало быстро.
Как по мне, задача прям замечательная.
async void
Вопрос — а зачем они используют они говорили? Я бы сказал, что это костыль для winform/wpf, где мы можем для обработчика только fire&forget использовать.
К сожалению, на хабре в последнее время часто стали появляться подобные статьи, где люди бьют себя пяткой в грудь и кричат, что в них не разглядели талант. Я так понимаю, управленческого опыта никакого нет, в базовых понятия плаваете… Что тогда можете предложить из того, что должен знать сеньор? Отлиное понимание процессов и методологий? Планирование? Надеюсь.
Уверен, что описание процесса собеседования сильно искажено и автор сначала неуверенно отвечал на вопросы об азах языка, а потом и вовсе впал в ступор. Прямо как в том анекдоте:
-Он меня топил-топил, а я выплыл
-Я его тянул-тянул — еле вытянул
Если не знаете, что такое virtual, то и не сможете ответить на вопрос чем virtual отличается от abstract — а ведь всё это базовые вещи, без которых архитектору никуда.
Базовая вещь — это полиморфизм подтипов (sub-typing polymorphism), да и тот не во всех языках и не всегда широко используется. Где-то предпочитают утиную типизацию (duck typing) вместо. А virtual и abstract, это всего лишь модификаторы в определённых языках.
Согласно определению Юдковского рациональное мышление — это мышление по Байесу. То есть корректная переоценка уверенности в гипотезе (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%. Кто-то может перепроверить арифметику?
Хватит подозревать разрабов в самозванстве. Научитесь лучше собеседовать