Comments 1581
Сильно.
Как js разраба раздражает что даже на senior позицию присутствует обязательный вопрос «что такое замыкание?»
Как js разраба раздражает что даже на senior позицию присутствует обязательный вопрос «что такое замыкание?»
И просят реализовать приватную статическую переменную с его помощью.
И все равно 80% заваливаются на данном вопросе.
Я вот как .net разработчик, не так давно начал применять js/ts в разработке. У меня уже был сахар для этого. Я конечно знаю, как это реализовать, но только потому, что сумасшедшие фронтендеры в необъяснимом в восторге от этой реализации, что мне ни раз и показывали. Понимаю ли я, как работают замыкания? Чёрт, да, я отлично это понимаю. Придёт ли мне в голову, что для реализации приватной статической переменной мне понадобиться фигачить самовызывающуюся функцию? Придёт, но не за минуту.
— Чёрт, да, я отлично это понимаю.
К сожалению, хоть вы и понимаете, как работают замыкания, но не поняли их главного назначения — это не «самовызывающиеся функции», это — объекты (функции первого порядка), которые замыкают в себе некоторый контекст, который в зависимости от языка может содержать в себе определенный набор переменных и областей.
То, что вы можете реализовать статическую переменную, опираясь на эти свойства, учитывая при этом все особенности JS/TS/.NET, говорит о вас как о хорошем разработчике, способном видеть архитектурные концепции за простым кодом, что как раз и вызывает восторг у знающих коллег.
И еще — нет, не придется, потому что обычно находятся более элегантные решения, чем использование статических переменных.
К сожалению, хоть вы и понимаете, как работают замыкания, но не поняли их главного назначения — это не «самовызывающиеся функции», это — объекты (функции первого порядка), которые замыкают в себе некоторый контекст, который в зависимости от языка может содержать в себе определенный набор переменных и областей.
То, что вы можете реализовать статическую переменную, опираясь на эти свойства, учитывая при этом все особенности JS/TS/.NET, говорит о вас как о хорошем разработчике, способном видеть архитектурные концепции за простым кодом, что как раз и вызывает восторг у знающих коллег.
И еще — нет, не придется, потому что обычно находятся более элегантные решения, чем использование статических переменных.
Где я сказал, что замыкания — самовызывающиеся функции?
— что для реализации приватной статической переменной мне понадобиться фигачить самовызывающуюся функцию
в этом моменте.
в этом моменте.
Тут я говорю, что самовызывающаяся функция нужна для реализации приватной статической переменной. Я нигде не говорю, что замыкания — это самовызывающиеся функции
Ну если уж пошло за буквоедство, то я тоже нигде не указываю, что это именно вы сказали. Кроме того, что это за термин такой — «самовызывающиеся функции» — что это за зверь? Типо сидишь себе и тут — хряк — откуда ни возьмись — функция вызвалась, сама по себе.
Или это как в квантовой механике — самовызов — функция считается одновременно вызванной и нет до тех пор пока программист не скомпилирует код?
Я конечно, понимаю, .Net имеет свою терминологию, возможно, это что-то из специфического, но ни в руби, ни в пхп, ни в яве, и даже в C# я такого зверя не встречал, будьте добры пояснить за вашу Senior терминологию.
Или это как в квантовой механике — самовызов — функция считается одновременно вызванной и нет до тех пор пока программист не скомпилирует код?
Я конечно, понимаю, .Net имеет свою терминологию, возможно, это что-то из специфического, но ни в руби, ни в пхп, ни в яве, и даже в C# я такого зверя не встречал, будьте добры пояснить за вашу Senior терминологию.
Очевидно, функция которая сама себя вызывает, т.е. рекурсивная ;). (на самом деле, наверное, module pattern)
(function () {
}());
Вообще это называется iife (immediately-invoked function expression) :)
Вызов анонимной функции? И что же тут «самовызывающего», если вы сами ее вызвали, написав () в конце?
Это видимо какой-то особый .net нейминг, с теорией программирования не связанный.
Ну или кто-то сеньор только своей голове, а не в реальности, тут не совсем понятно.
Это видимо какой-то особый .net нейминг, с теорией программирования не связанный.
Ну или кто-то сеньор только своей голове, а не в реальности, тут не совсем понятно.
Это не ".net нейминг", а устоявшийся перевод термина IIFE (immediately-invoked function expression).
Гугл транслейт почему-то переводит это как «немедленно вызываемые», что куда ближе к правде, чем «самовызываемые» (self-invoked).
Ирония всего происходящего в том, что самозванец, называющий себя «Senior full stack developer», кричит о том, что «хватит подозревать разрабов в самозванстве».
Для меня это звучит как «Платите мне сеньорские за знания слабого миддла». Это просто смешно.
Ирония всего происходящего в том, что самозванец, называющий себя «Senior full stack developer», кричит о том, что «хватит подозревать разрабов в самозванстве».
Для меня это звучит как «Платите мне сеньорские за знания слабого миддла». Это просто смешно.
Гугл, самовызывающаяся функция, About 1,600 results.
По ссылкам реальные люди говорят это реальное, может быть сленговое, название. Или, типа, редкий сленг = самозванец?
По ссылкам реальные люди говорят это реальное, может быть сленговое, название. Или, типа, редкий сленг = самозванец?
Гугл, «немедленно вызываемая функция javascript» — 30 тысяч результатов. Может у вас есть еще вопросы к гуглу?
И что это доказывает? Вы утверждали что так никто не говорит, я показал что так говорят. Про то что более популярно а что более правильно разговора не было, я в этом вашем js ни в зуб ногой и такие разговоры вести не компетентен.
Это показывает, что даже академический термин в разы популярней вашего терминологического изобретения. И я не удивлен, что в интернете нашлось еще полторы тысячи человек, использующих слова, сути которых они не понимают.
Кстати, если изучите кто пользуется этим термином, поймете, что среди них не так уж много профессионалов, что говорит о том, в каких кругах это слово распространено.
Кстати, если изучите кто пользуется этим термином, поймете, что среди них не так уж много профессионалов, что говорит о том, в каких кругах это слово распространено.
2018 год, а многие всё ещё верят выхлопу гуглтранслейта. Чтобы не быть голословным: по partitioning нет ни правильного «секционирование», ни «партиционирования» от людей не знакомых с теорией.
Соглашусь, что «немедленно вызываемые» передают суть, а «самовызываемые» намекают на непонимание происходящего в коде.
Я предлагаю отныне их называть «функции-самозванцы» ибо это короче чем «самовызываемые», так же неправильно и позволяет закольцевать тему в мире метафор.
Похоже, я мешаю вам лупить вооброжаемого противника)
понадобитЬся… типичная гиковская грамотность, увы. Только об этом шла речь.
Конечно. Вот я не понял даже смысла этой просьбы. Что такое, вообще, «статическая переменная»? Это что-то из Си?
В Си (и в плюсах) слово static означает три разные вещи — внутри функции, внутри структуры/класса, и на внешнем уровне. Какой из этих трёх смыслов вкладывается в понятие «статической переменной»?
imho, все-таки есть минимально необходимый уровень знаний матчасти. Математик может не использовать таблицу умножения, занимаясь тензорной математикой, но ответить сколько будет 2*2, кмк обязан.
Все мы люди и модет на небольшое время "забыть" от волнений или по другим причинам даже 2*2. Думаю почти все сталкивались когда понимаешь о чем речь, но слова забываются.
Не должно такого быть. Если тот же математик что-то забывает, то он должен уметь это вывести. А если он забывает аксиоматику, то какой он тогда математик? Я в лекциях Савватеева наблюдал момент, когда по ходу лекции он забыл формулу нахождения корней квадратного уравнения (а это д.ф.-м.н. между прочим). Он слегка смутился, но тут же ее вывел и доказал.
оно не должно случатся, но а если случается в этом нет ничего страшного.
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
Для предотвращения подобных ситуаций, хорошо бы чтобы наймом сотрудников занималась сторонняя HR компания имеющая при этом штат технических специалистов, которые будут проводить беспристрастную оценку уровня знаний соискателя… Но видимо это пока только мечты(
Зачем вообще об этом мечтать? Люди не роботы, и человек может что-то знать, но совершенно не подходить под конкретную команду и\или проект. Собеседование это не экзамен и не соревнования по вольной борьбе, это поиск подходящего человека в команду. Если в команде все используют наследование и много виртуальных методов, а человек не помнит это слово и возможно (как он и сам признался) не любит наследование и избегает его, то зачем его брать в команду? Тут же конфликт подходов на лицо, будет борьба за неформальное лидерство и постоянные конфликты на этой почве. Потом кто-то да уволится.
Отчасти согласен, но иногда в команду требуется лид, который априори должен быть сильнее всех имеющихся членов команды (иногда даже вместе взятых), и естественно в большинстве случаев, команда не утвердит никого из действительно подходящих кандидатур, в особенности если команда на основную массу состоит из говнокодеров… как быть тогда, видимо извечный вопрос…
Было дело, я работал над проектом, писал бек на шарпе, а нужен был фронт на пхп, да с общением с WCF да через https. Тот человек что писал фронт, особой прытью не обладал, да и сайт был простой, он проблему решить не мог, я поискал готовые решения — их не оказалось. Вроде как все есть — но либа не работает, и нужно было найти хорошего ПХПшника, допилить либу. Приходилось собеседовать по сути обладая знаниями джуна в пхп, сина. Я так и спрашивал в конце собеседования — как решить эту задачу, каждый бил себя в грудь и говорил — да элементарно! Ни чего сложного! По началу я злился, начал думать что они все самозванцы… Но проблему нужно решать и человека искать… Начала давать час на раздумья. Если через час я слышал все то-же «да это элементарно» и ни какой конкретики — то прощался.
Такие компании к сожалению только добавляют гемора всем, в Новосибирске есть такое агнество, так вот два раза попробовал с ними работать, и чет как то стороной теперь подобные конторы обхожу, у них задача продать разработчика компании.
А решается это все просто, нужно чтобы собеседование проводили или несколько людей с разных проектов, или несколько технических интервью, тогда будет более менее честная оценка
А решается это все просто, нужно чтобы собеседование проводили или несколько людей с разных проектов, или несколько технических интервью, тогда будет более менее честная оценка
HR-специалисты зачастую и не особо понимают чем занимается компания и какие работники нужны. Это при том, что сам отдел находятся «внутри», а работники за соседней дверью. А с вашим предложением вообще полный атас будет. Да и подобные идеи уже давно реализованы кадровыми агентствами, чья функция свелась к простому «иди туда-то и спроси того-то».
Если у человека есть опыт, и бывает так что опыт человека которого собеседуют выше опыта интервьюера, то да, интервьюер легко скажет что он нам не подходит
И в некоторых случаях будет прав.
Два раза натыкался на проблемы при найме сотрудников на наукоемкие позиции. Приняли сотрудника, а потом от него постоянные (обоснованные!) жалобы на неграмотную постановку задач и на то, что его никто не понимает (и это тоже правда). А у других сотрудников — мысли «а этот человек вообще занимается чем-то полезным?». Т.е. не могут отличить от самозванца.
Если берешь overqualified специалиста, обязательно вдобавок к тому, что написано в вакансии, проверяй преподавательские навыки и думай, как будешь проверять и оценивать его работу. Если не можешь проверить и нет денег на одновременный найм двух кандидатов — вакансия невалидна.
должно ли случаТСя, что программисты, кроме 100500 языков и технологий выучат, наконец, родной язык?
Немного про волнение: то на экзамене в вузе, преподаватель по терверу понял мою ошибку, когда я ее еще не осознавал. Задавал много наводящих вопросов, и в конце концов попросил меня нарисовать на оси две точки 1 и 1,5. Посмотрев на мой рисунок, он сказал: «вы знаете мой предмет на отлично, но впредь, чтобы вы знали, что 1,5 больше 1, я поставлю вам четверку без права пересдачи» и выставил меня в коридор.
O_o, нифига себе. У меня было похожее, только на экзамене по цифровой обработке сигналов.
Преподаватель видела, что я в принципе разбирался в теме, но переволновался. Попросила нарисовать какой-то график, нарисовал. Спросила, что больше: 1/4 или 1/2(1/4 у меня было больше). Тут до меня дошло, она посмеялась и поставила 4))
Преподаватель видела, что я в принципе разбирался в теме, но переволновался. Попросила нарисовать какой-то график, нарисовал. Спросила, что больше: 1/4 или 1/2(1/4 у меня было больше). Тут до меня дошло, она посмеялась и поставила 4))
Таких преподов обычно ненавидят. И правильно делаю, учитель должен мотивировать ученика, а не наоборот.
А разве он его не мотивировал? Он признал, что ученик действительно с мозгами и шарит в предмете. Признание это и есть уважение. Какая хрен разница какая оценка? Если бы ученику нужен был бы красный диплом, он бы сказал «Ставьте два. Буду пересдавать» и проблемы в этом нет. Препод все сделал грамотно!
Смотивировал? Чувака который знал его предмет на отлично поставил четыре без права пересдачи? На что он его смотивировал, из окна выйти? Это, вполне, если чувак интроверт, шел на красный диплом и т.п
Нет понятия «Без права пересдачи». Вот ни одного случая не припомню, когда человеку реально запретили пересдавать. Вот ни одного! Чтобы не говорил преподаватель и какой бы ядовитой слюной он не брызгал, но пересдача будет, если студент этого хочет. Просто надо сидеть не в позе «Мне препод запретил, значит дело труба». А надо поднимать мягкое место и пробовать другие способы решения проблемы «Начну с похода к декану, может он поможет, а потом буду думать, что дальше».
На отлично человек не знал.
Отлично — это знание, ставшее отсутствием ошибок. Причём неважны причины тут… хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Без ошибок.
Если мне на заводе инженер напортачит, я что — буду смотреть на то, что он в принципе всё знает?..
Тут экзаменатор как раз поступил очень корректно.
Отлично — это знание, ставшее отсутствием ошибок. Причём неважны причины тут… хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Без ошибок.
Если мне на заводе инженер напортачит, я что — буду смотреть на то, что он в принципе всё знает?..
Тут экзаменатор как раз поступил очень корректно.
хочешь пересдавать (говори, что оценка 4 без пересдачи тебя не устраивает) — готовься лучше, и пересдавай.
Здесь ничего не смущает?
Ничего тут нет противоречащего. Потому что это уже организационный вопрос.
Я сам находился в таком качестве (причём и на месте сдающего, и принимающего).
Экзаменатор формирует очередь пересдачи (самому себе, как правило), и не хочет туда включать сдающего. Он уже оценил его уровень, и оценивает на 4-е (и я его понимаю). Сдающий понимает, знает предмет, но допускает ошибки, и довольно глупые. Успеет ли он до пересдачи справится с причинами, приведшими к ошибке? Не знаю, тут уже рядом сидеть нужно. Но там ещё за тобой народ, потому здесь и сейчас — 4-ка.
Уровень, условия включения на пересдачу «спускаются свыше». Деканатом, как правило. И эта очередь да, зависит от оценки. Ибо только её обычно и видит деканат в реестре. Если 4-шников включать в списки на пересдачу, будет уже беседа деканата с экзаменатором. С какого ты его на пересдачу-то?! У него же «хорошо».
Ибо время экзаменатора — принадлежит не ему.
Он должен обосновать требование пересдачи перед контролирующим органом (деканатом).
Но ученик может возразить.
Это его право.
Как правило, экзаменатор на требование «да не нужна мне 4-ка без пересдачи!» пожимает плечами, и ставит оценку, которая автоматом направляет на пересдачу (там, где я учился, хотя бы 3-ка нужна, чтобы не разбираться потом с деканатом).
Никаких проблем в 99,9999% случаев.
Потому что эта оценка до пересдачи уже ничего не значит.
Подготовишься на отлично — получишь отлично.
Я сам находился в таком качестве (причём и на месте сдающего, и принимающего).
Экзаменатор формирует очередь пересдачи (самому себе, как правило), и не хочет туда включать сдающего. Он уже оценил его уровень, и оценивает на 4-е (и я его понимаю). Сдающий понимает, знает предмет, но допускает ошибки, и довольно глупые. Успеет ли он до пересдачи справится с причинами, приведшими к ошибке? Не знаю, тут уже рядом сидеть нужно. Но там ещё за тобой народ, потому здесь и сейчас — 4-ка.
Уровень, условия включения на пересдачу «спускаются свыше». Деканатом, как правило. И эта очередь да, зависит от оценки. Ибо только её обычно и видит деканат в реестре. Если 4-шников включать в списки на пересдачу, будет уже беседа деканата с экзаменатором. С какого ты его на пересдачу-то?! У него же «хорошо».
Ибо время экзаменатора — принадлежит не ему.
Он должен обосновать требование пересдачи перед контролирующим органом (деканатом).
Но ученик может возразить.
Это его право.
Как правило, экзаменатор на требование «да не нужна мне 4-ка без пересдачи!» пожимает плечами, и ставит оценку, которая автоматом направляет на пересдачу (там, где я учился, хотя бы 3-ка нужна, чтобы не разбираться потом с деканатом).
Никаких проблем в 99,9999% случаев.
Потому что эта оценка до пересдачи уже ничего не значит.
Подготовишься на отлично — получишь отлично.
Сейчас есть такая штука, как ФЗ «Об образовании в Российской Федерации». Они подзаконные акты чётко говорят, что в случае «неуд'а» в течении календарного года есть право 2 раза пересдать экзамен. При этом финальная пересдача предполагает сдавать уже комиссии. Если оценка выше, то тут для пересдачи необходимо согласие преподавателя. В случае, когда он упрётся и не захочет принимать, то только тогда в дело может вступить зав.каф. или декан, чтобы или назначить другого, более лояльного преподавателя (ну или чтобы принять пересдачу самому). НО! Преподаватель формально может и не отказываться от пересдачи, чтобы собственноручно «похоронить» надежды студента на «отлично» в стиле: «я же говорил, что выше 4 ты не получишь». Хотя такое встречается реже.
Вы тоже из тех, у кого на отлично знает бог а на 4 препод? Или из тех, у которых железные нервы, а потому и у всех остальных должно быть?
Люди ошибаются, всегда и постоянно, и ничего ты с этим не поделаешь.
Люди ошибаются, всегда и постоянно, и ничего ты с этим не поделаешь.
Если мне на заводе инженер напортачит
Если у вас на заводе инженера работают в постоянном стрессе сравнимым с экзаменами в ВУЗе, то у меня плохие новости для вашего бизнеса)
Экзамены в ВУЗ-е вы считаете стрессом по сравнению с работой?!
Мило. За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал. Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен.
Собственно, именно потому за неё платят деньги.
За свой экзамен (его можно сравнить скорее с интеллектуальным удовольствием) — платите вы.
Мило. За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал. Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен.
Собственно, именно потому за неё платят деньги.
За свой экзамен (его можно сравнить скорее с интеллектуальным удовольствием) — платите вы.
Работа работе рознь. Вам платят за устойчивость к стрессам. Кто-то (я в том числе) предпочитает получать деньги за квалифицированное решение задач бизнеса в комфортных условиях.
А у меня наоборот. Тоже много лет опыта, несколько стран (> двух), несколько компаний, разные сферы бизнеса и т.д. и т.п… Везде работа была комфортной и не стрессовой, хоть иногда и весьма интеллектуально сложной.
За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал.
А у меня наоборот. Тоже много лет опыта, несколько стран (> двух), несколько компаний, разные сферы бизнеса и т.д. и т.п… Везде работа была комфортной и не стрессовой, хоть иногда и весьма интеллектуально сложной.
Я не говорил, что платят за стресс.
Я писал о требовании психологической устойчивости. Это сильно разные понятия.
Психологическая устойчивость — это готовность успешно справляться со стрессом, но не сам он.
Меня вообще удивляют эти высказывания, что на экзамене — стресс. Я к своим экзаменам в университете даже не готовился ни разу! И закончил с красным дипломом, кстати. Если вы учитесь, не спустя рукава, и учёба вам в радость, то экзамен — это просто один из способов пообщаться с экзаменатором, продемонстрировав ему (подтвердить) свои знания.
Что тут стрессового?
Я, конечно, понимаю, что может мне так повезло с университетом, но может, как раз если для вас экзамен — стресс, то вы не там, или не на того учитесь?..
А последующая работа — это уже ответственность.
И не перед собой, и вашей дальнейшей судьбой (не нужно переоценивать свою персону), а уже перед другими и за других.
Которой нет, не должно быть на экзамене.
Инженеры, которые у меня работают — отвечают за бизнес, большие деньги. Некоторые — за безопасность других людей.
Сравнивать это с экзаменом, где решается только твоя судьба (причём с возможностью пересдачи) — неадекватно, имхо.
Я писал о требовании психологической устойчивости. Это сильно разные понятия.
Психологическая устойчивость — это готовность успешно справляться со стрессом, но не сам он.
Меня вообще удивляют эти высказывания, что на экзамене — стресс. Я к своим экзаменам в университете даже не готовился ни разу! И закончил с красным дипломом, кстати. Если вы учитесь, не спустя рукава, и учёба вам в радость, то экзамен — это просто один из способов пообщаться с экзаменатором, продемонстрировав ему (подтвердить) свои знания.
Что тут стрессового?
Я, конечно, понимаю, что может мне так повезло с университетом, но может, как раз если для вас экзамен — стресс, то вы не там, или не на того учитесь?..
А последующая работа — это уже ответственность.
И не перед собой, и вашей дальнейшей судьбой (не нужно переоценивать свою персону), а уже перед другими и за других.
Которой нет, не должно быть на экзамене.
Инженеры, которые у меня работают — отвечают за бизнес, большие деньги. Некоторые — за безопасность других людей.
Сравнивать это с экзаменом, где решается только твоя судьба (причём с возможностью пересдачи) — неадекватно, имхо.
Работа (причём повседневная, не считая авралов) намного превосходит по требованиям психологической устойчивости такую простую штуку, как экзамен
Интересно, кем же вы работаете?)
Я инженер-программист, мне моя работа приносить удовлетворение и не только материальное, а часто даже радость, когда получается красиво решить задачу. И уж конечно не приносит стресс.
Я просто уверен, что инженер в состоянии стресса, кроме костыля ничего не может придумать. И вообще, в моей профессии если ты довел дело до стресса (в большинстве случаев это банальный срыв сроков), то ты свою работу делаешь плохо.
Я выше написал подробнее.
Я писал, ещё раз, о требовании психологической устойчивости, требуемое в работе в степени, несравнимой с такой простой вещью — как экзамен (если вы учитесь нормально, конечно).
Я тоже раньше был программистом, теперь архитектор, и руководитель проектов, но область в принципе понимаю.
Моя работа не стрессовая, но иногда, изредка — бывает такой.
И требования к психологической устойчивости (не сам стресс, но готовность справится с оным) тут определяет несравненно большее, чем то, что решается на экзамене.
Я писал, ещё раз, о требовании психологической устойчивости, требуемое в работе в степени, несравнимой с такой простой вещью — как экзамен (если вы учитесь нормально, конечно).
Я тоже раньше был программистом, теперь архитектор, и руководитель проектов, но область в принципе понимаю.
Моя работа не стрессовая, но иногда, изредка — бывает такой.
И требования к психологической устойчивости (не сам стресс, но готовность справится с оным) тут определяет несравненно большее, чем то, что решается на экзамене.
Если брать ИТ сектор, то большинство вообще не испытывает стресса от работы, даже от срыва сроков. Даже шутка есть. Большинство проектов заканчиваются провалом. Большинство проектов превышает сроки и бюджет. Всегда остаются баги, которые находит клиент. После 5 лет в индустрии это понимает почти каждый и парится перестает совершенно.
На рабочих профессиях — все еще проще в плане отношения к результатам труда. Даже врачи в массе не переживают о качестве своего лечения и размере «персонального кладбища», конечно хорошие врачи — переживают.
Но если брать обобщение — то человек переживает в ключевых точках. Например в точке оценивания, как-то прием на работу или экзамен, или ожидание отзывы с прошлой работы. А между этих точек — фаза расслабления, «меня уже взяли, можно и расслабится».
Так-что вы не правы. Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целом. А речь идет о людях, которым диплом важен, и оценка важна, они верят что это повлияет на их последующую жизнь. И стресс от экзамена — выше стресса от первого собеседования на очень желанную работу. Ведь работу можно и другую найти, а экзамен он один.
На рабочих профессиях — все еще проще в плане отношения к результатам труда. Даже врачи в массе не переживают о качестве своего лечения и размере «персонального кладбища», конечно хорошие врачи — переживают.
Но если брать обобщение — то человек переживает в ключевых точках. Например в точке оценивания, как-то прием на работу или экзамен, или ожидание отзывы с прошлой работы. А между этих точек — фаза расслабления, «меня уже взяли, можно и расслабится».
Так-что вы не правы. Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целом. А речь идет о людях, которым диплом важен, и оценка важна, они верят что это повлияет на их последующую жизнь. И стресс от экзамена — выше стресса от первого собеседования на очень желанную работу. Ведь работу можно и другую найти, а экзамен он один.
Если для вас, напряжение от экзаменов было ниже, повседневного напряжения на работе — значит вы не предавали экзаменам важности, возможно и диплому в целомЯ не придавал в обучении важности оценкам, это так. Хотя по результатам обучения и был в череде лучших потока.
А после, некоторое время будучи преподавателем, понял окончательно, что оценка — это больше для учителя, а не ученика.
Не нужно путать, смешивать результат обучения, и его формализованную оценку.
Мне вообще, судя по обсуждению, как-то повезло, для меня университет был одной большой радостью, безо всякой примеси даже возможности стресса.
Последующая работа у меня также — не стресс (ну, изредка, но бывает и такое).
А всего лишь постоянная готовность к оному.
Ответственность. Перед другими, и за других.
Которой неоткуда взяться на экзамене, где ты — только сам за себя (если не считать третьими лицами родных, которым это тоже важно).
И тогда возникает закономерный вопрос — может, если для тех, у кого учёба (или экзамен) была стрессом — может у них как раз что-то неправильно было?..
За других говорить не могу, лишь за себя. Учеба мне была в кайф и работа то-же, как и вам. При этом стрессы бывали и в учебе и на работе, и готовность к ним так-же есть. Стресс и радость не противоречат друг другу, скорее даже они почти всегда ходят рядом с друг другом. Там где нет и намека на стресс обычно, все безразлично, возникает скука, и ни какой радости.
Относительно ответственности — все то-же самое и в университете. Если провалишь универ, то не найдешь хорошую работу, не сможешь обеспечить будущих детей, и вся жизнь пойдет под откос и по пути «неудачников», коих вокруг полно и среди молодых и среди взрослых.
Тут скорее вопрос исключительно в моменте перехода от «беззаботного детства» к «ответственному взрослению». У вас этот переход случился на работе, на работе вы стали ощущать ответственность перед другими и за других. У меня он случился около 8го класса и я ходил и испытывал постоянный стресс от кучи негативных вариантов исходов моей жизни, думал о том кем я хочу быть, кем работать, и как при этом обеспечить будущую семью, и где жить, и стоит ли мигрировать или нет. Другими словами — нас (людей) напрягают ВОЗМОЖНЫЕ факапы (та самая готовность к стрессу). Но начинают они нас напрягать внезапно, в какой-то момент жизни. После этого момента, ты начинаешь «парится за все». И чем меньше остается «возможностей обосраться», тем меньше этих переживаний. Т.е. окончив нормально универ — перестаешь переживать что ты дебил. Женивщись — что ты не женишься. Родив детей — что забудешь их родить. И стресс с возрастом снижается, т.к. цена ошибки падает. В юношестве мне казалось что провалив первую сессию, я не смогу получить красный диплом, и моя жизни станет в 5 раз сложнее и не предсказуемей. Сейчас мне кажется что в случае провала проекта, я через неделю найду новую работу.
Ну или вы просто ощущали себя в безопасности от «плохого диплома». И такое бывает, например родители гарантируют помощь. Или есть примеры саксес стори с плохим дипломом, которые есть силы повторить. У меня не было ни того, ни другого.
Относительно ответственности — все то-же самое и в университете. Если провалишь универ, то не найдешь хорошую работу, не сможешь обеспечить будущих детей, и вся жизнь пойдет под откос и по пути «неудачников», коих вокруг полно и среди молодых и среди взрослых.
Тут скорее вопрос исключительно в моменте перехода от «беззаботного детства» к «ответственному взрослению». У вас этот переход случился на работе, на работе вы стали ощущать ответственность перед другими и за других. У меня он случился около 8го класса и я ходил и испытывал постоянный стресс от кучи негативных вариантов исходов моей жизни, думал о том кем я хочу быть, кем работать, и как при этом обеспечить будущую семью, и где жить, и стоит ли мигрировать или нет. Другими словами — нас (людей) напрягают ВОЗМОЖНЫЕ факапы (та самая готовность к стрессу). Но начинают они нас напрягать внезапно, в какой-то момент жизни. После этого момента, ты начинаешь «парится за все». И чем меньше остается «возможностей обосраться», тем меньше этих переживаний. Т.е. окончив нормально универ — перестаешь переживать что ты дебил. Женивщись — что ты не женишься. Родив детей — что забудешь их родить. И стресс с возрастом снижается, т.к. цена ошибки падает. В юношестве мне казалось что провалив первую сессию, я не смогу получить красный диплом, и моя жизни станет в 5 раз сложнее и не предсказуемей. Сейчас мне кажется что в случае провала проекта, я через неделю найду новую работу.
Ну или вы просто ощущали себя в безопасности от «плохого диплома». И такое бывает, например родители гарантируют помощь. Или есть примеры саксес стори с плохим дипломом, которые есть силы повторить. У меня не было ни того, ни другого.
А я понимаю и вас, и u010602 — у меня страхи были один-в-один, и, как ни странно, именно на них я и выехал в «люди», не спился, не с курился (всякими веществами). Мои же страхи дали мне силы осваивать абсолютно не знакомые мне области.
Уже позже это и переросло в «не люби себя таким, какой есть — сегодня лучше чем вчера, завтра лучше, чем сегодня».
Но и вас я так же прекрасно понимаю — у людей опыт разный (и это хорошо ведь).
Уже позже это и переросло в «не люби себя таким, какой есть — сегодня лучше чем вчера, завтра лучше, чем сегодня».
Но и вас я так же прекрасно понимаю — у людей опыт разный (и это хорошо ведь).
Экзамены в ВУЗ-е вы считаете стрессом по сравнению с работой?!Это достаточно известный факт между прочим. Экзамены и собеседования — типовой сценарий в исследованиях поведения человека в стрессовой ситуации, это наиболее известные, легко воспроизводимые и универсальные ситуации. Ключевое слово здесь — универсальные. Практически для любого человека экзамен — сильный стресс. Если лично для вас не так — значит вы либо сильно выделяетесь, что конечно возможно и я искренне за вас рад, либо не осознаете до конца что такое стресс. Я могу попытаться найти исследования на эту тему если интересно.
Знание «на отлично» предполагает отсутствие ошибок, тем более детских. А именно такая была насколько я понял, про вероятность равной 1,5.
Не очень верная аналогия, но если в боксёрском поединке спортсмен А победил спортсмена Б, то это означает, что спортсмен Б слабее. Даже если на тренировках он показывал отличные результаты и был всеобщим фаворитом.
Не очень верная аналогия, но если в боксёрском поединке спортсмен А победил спортсмена Б, то это означает, что спортсмен Б слабее. Даже если на тренировках он показывал отличные результаты и был всеобщим фаворитом.
Вот именно что неверная аналогия. Мы не про спорт, а про будущих инженеров. А им не обязательно в стрессовой ситуации рассказывать наизусть таблицу умножения. А то что человек знал предмет на отлично, прямо следует из обсуждаемого поста.
Давайте приведу другую. Выходит ученик рассказывать стишок и ни слова не произносит. Получает двойку. Приходят родители, мол как же так, дома он отлично рассказывал. Вполне вероятно, но что из этого следует? Что знание ученика настолько непрочное, что исчезает вне «тепличных условий», когда это знание нужно применить он не может этого сделать.
По мне реальная работа это бОльший стресс и напряжение нежели экзамен. И если даже на экзамене в голове пусто, образно говоря, то уж извините.
Да и знание таблицы умножения это не зубрёжка, а элементарные навыки счёта. В пределах 100, замечу. По мне странно, что то, что наши дедушки-бабушки-родители знали и успешно учили в 7 лет, вдруг оказывается недоступно выпускнику вуза (ну не верю я в истории про гениальных математиков/инженеров/программистов, которые не могут умножить 5 на 5).
Конкретно в этом случае… если на самом деле так сказал, мог быть 5 поставить, с минусом) Или другое задание дать.
По мне реальная работа это бОльший стресс и напряжение нежели экзамен. И если даже на экзамене в голове пусто, образно говоря, то уж извините.
Да и знание таблицы умножения это не зубрёжка, а элементарные навыки счёта. В пределах 100, замечу. По мне странно, что то, что наши дедушки-бабушки-родители знали и успешно учили в 7 лет, вдруг оказывается недоступно выпускнику вуза (ну не верю я в истории про гениальных математиков/инженеров/программистов, которые не могут умножить 5 на 5).
Конкретно в этом случае… если на самом деле так сказал, мог быть 5 поставить, с минусом) Или другое задание дать.
Ну он походу неправильно решил задачу. То есть "все ок но такая обидная ошибка, заказчик рвет и мечет в итоге тт, ну сам понимаешь в таких условиях — никакой премии".
А навыки переговоров у чувака есть? Навык «Уметь дать сдачи» всегда был полезным!
Если ко мне так руководитель подойдет, то уверяю, что у него возникнет желание извиниться передо мною.
Если ко мне так руководитель подойдет, то уверяю, что у него возникнет желание извиниться передо мною.
А почему вы думаете, что навык переговоров исключительно приобретенный и не зависит от врожденных возможностей? Некоторым так-же сложно вести переговоры, как другим решать матан. Размышлять в стиле «вот слабак! я бы на его месте зарешал!» не продуктивно. Люди все разные, у всех есть слабости, не все слабости можно превозмочь, не все навыки можно приобрести. Некоторые навыки так-же сложно приобрести — как подрасти на 10 см усилием воли. И мы(как человечество) хотим создать условия комфортные для большинства, а не только для бетменов, что-бы каждый человек, не смотря на свои недостатки, могу раскрыть свои сильные стороны. Задачи выведения супер-солдата без недостатков — не стоит. Попытки были — можете почитать, чем они закончились.
А почему вы думаете, что навык переговоров исключительно приобретенный и не зависит от врожденных возможностей?
Я ни слова не сказал о том, переговорный навык приобретенный или врожденный. Не надо говорить то, чего нет в словах других людей. ОК?
Да. Люди разные. Но мир такой какой он есть и надо либо играть по его правилам, либо сам виноват! Мы же не приходим в футбол и не говорим «А я вот хочу клюшкой играть».
Мне тоже, если что, даются переговоры в чем-либо и с кем-либо и как следствие из-за этого прокрастинурую над задачами, где надо переговорить. Но! Абсолютно не важно что у меня это врожденное или не своейственное мне иногда надо просто взять и сделать! И точка!
Иногда да, а иногда можно пойти и сделать хоккей с клюшкой. Итого, кто будет насмехаться над новым, не таким как все и тд — будут называть шовинистом. Современный мир борется с шовинизмом и пытается снизить важность навыка социализации. Сделать общение эмоционально проще и доступнее для некоторых людей. Вы же оправдываете преподавателя в стиле «молодец! проучил, показал что мир жестокое место!» А вы не думаете, может готовя детей к жестокости мира, мы делаем мир более жестоким, чем он может быть? Т.е. где грань между подготовкой, и созданием обиды на всю жизнь, которую потом человек будет выражать в агрессию над следующим поколением? Как с дедовщиной — есть части где она есть, а есть части где ее нет. И когда она есть, новый призыв пройдя через унижения, решает что потом они должны вернуть баланс, и унизить следующих. И это затягивает. Такие циклы бывают как продуктивные, так и нет. Уверен преподавателя то-же так кто-то проучил, и он решил нести это дальше в массы. Но насколько он успешен что-бы нести свои психоустановки в массы? Кто дал ему право, не только учить, но и воспитывать? Проф пригоден ли он для этого?
Мое мнение — нет. Воспитанием должны заниматься одни, а обучением — другие.
Мое мнение — нет. Воспитанием должны заниматься одни, а обучением — другие.
А причем тут хамство?
Есть 2 типа руководителей:
1. Мудак. Который считает, что раз он\она начальник, то все должны слушаться и такие люди как правило живут по принципу «Есть мое мнение и неправильное». Но тут уже к работнику вопрос, нахера он себя так низко ценит работая под таким руководством
2. Адекватный. Это человек знающий что нужно бизнесу и как решаются задачи. Этот человек действует профессионально и свое мнение учитывает исключительно в рамках рабочего процесса.
С первым типом я не работаю. Сразу ищу другого работодателю. А второму всегда можно пояснить какую пользу приносишь. Что сделано. Что делается. Как делается и как эффективно делается. Поясняется, что нихера непонравилось то что руководитель допустил по отношению ко мне.
Адекватный всегда поймет что к чему и извинится. Более того он подобной ситуации посторается недопустить. Максимумум что от таких людей можно услышать «Ты допустил ошибку. Она влечет за собою… Это выражается в потерю… рублей и возможностей… ». Если подобное слышишь в свой адрес, то обижаться не стоит. Не продуктивно
Есть 2 типа руководителей:
1. Мудак. Который считает, что раз он\она начальник, то все должны слушаться и такие люди как правило живут по принципу «Есть мое мнение и неправильное». Но тут уже к работнику вопрос, нахера он себя так низко ценит работая под таким руководством
2. Адекватный. Это человек знающий что нужно бизнесу и как решаются задачи. Этот человек действует профессионально и свое мнение учитывает исключительно в рамках рабочего процесса.
С первым типом я не работаю. Сразу ищу другого работодателю. А второму всегда можно пояснить какую пользу приносишь. Что сделано. Что делается. Как делается и как эффективно делается. Поясняется, что нихера непонравилось то что руководитель допустил по отношению ко мне.
Адекватный всегда поймет что к чему и извинится. Более того он подобной ситуации посторается недопустить. Максимумум что от таких людей можно услышать «Ты допустил ошибку. Она влечет за собою… Это выражается в потерю… рублей и возможностей… ». Если подобное слышишь в свой адрес, то обижаться не стоит. Не продуктивно
Но надо учитывать, что есть ещё 10 промеждуточных стадий между м** и адекватным. А также принимать во внимание, что и адекватные иногда встатют не с той ноги, а м**** «по жинзи» может оказаться компетентным в конкретном вопросе по собиранию бычков и подробно объяснить свою позицию.
Если ошибка человека вылилась в потери и тд — то начальнику стоит бить себя в лоб. Ибо выстраивание процессов так, чтобы ошибка одного человека не рушила бизнес — его прямая обязанность.
четверку без права пересдачи»
Если бы ученику нужен был бы красный диплом, он бы сказал «Ставьте два. Буду пересдавать»
?!
Вроде, только в МедВУЗе невозможно получить Красный Диплом имея хоть одну пятёрку.
Кроме того, студент идущий на красный диплом, где-то на пятом курсе, может пересдать несколько предметов улучшив по ним оценки.
За что ненавидить? Глупые обиды какие-то.
Преподаватели разными способами (наводящими вопросами и др.) подсказывает, но так получилось что это не помогло. В результате человек получил 4, но навсегда запомнил.
В системе тестирования или у другого преподавателя, нет решения = нет положительного результата, на пересдачу. Так лучше?
Да лучше, или 2 или 5. 4 это унизительно, я бы психанул.
Вспоминается история с израильским F-16 перевернувшимся при полёте над Мёртвым морем из-за того, что высота стала отрицательной.
Должно быть, писавший эту авионику тоже психовал, из-за распухшего ЧСВ, когда ему указывали на совершённые ошибки.
Должно быть, писавший эту авионику тоже психовал, из-за распухшего ЧСВ, когда ему указывали на совершённые ошибки.
Я бы психанул не из-за ошибки, ошибки нужно исправлять. Здесь же в истории было явное наказание «без права пересдачи». Вопрос в стиле «что мне теперь ставить вам 4?» вызвал бы у меня достаточно стресса, что-бы я это запомнил на всю жизнь. Я считаю поступок преподавателя — чрезмерно жестоким.
А относительно ЧСВ и Ф-16 — если система создания ПО уязвима к ЧСП одного из членов команды — то она явно подобрана не правильно. Там где от софта зависят жизни людей — там человеческий фактор должен быть сведен к минимуму.
А относительно ЧСВ и Ф-16 — если система создания ПО уязвима к ЧСП одного из членов команды — то она явно подобрана не правильно. Там где от софта зависят жизни людей — там человеческий фактор должен быть сведен к минимуму.
Программисты не пишут авионику в одно лицо… Хотя я недолго в этой сфере проработал, но у нас шансов налажать практически не было. Программисты всего лишь реализовывали логику, очень подробно описанную инженерами, причем все разбито на мелкие модули. А потом другие люди покрывали каждый модуль юнит-тестами на 100%. В таком проекте один псих ничего не поломает.
Так никакой проблемы — просишь 2 и на пересдачу. Или потом требуешь пересдачи у другого/комиссии.
Тут другое — человек не знал на твердую 5, а зыбкая 5 из рук ускользнула.
Тут другое — человек не знал на твердую 5, а зыбкая 5 из рук ускользнула.
Оценка — это мера знаний ученика, а не понтов преподавателя. Если препод уверен, что его ученик знает предмет на отлично, он должен ставить отлично. Что дала эта четверка ученику? Он на всю жизнь запомнил что 2*2=4, он это и так знал. Что у другого преподавателя из-за особенностей своей памяти, он тоже может столкнуться с тем же, не факт, другой преподаватель может быть более вменяем.
А какой урок это ему дало для реальной жизни? Что любой самодур может ему испортить жизнь только потому, что он не умеет завязывать галстук?) Тут есть здравое зерно. Но такой опыт он может получить от кого угодно. Преподаватели, а тем более в ВУЗах должны учить своих учеников чему-то все-таки большему, не так ли?
А какой урок это ему дало для реальной жизни? Что любой самодур может ему испортить жизнь только потому, что он не умеет завязывать галстук?) Тут есть здравое зерно. Но такой опыт он может получить от кого угодно. Преподаватели, а тем более в ВУЗах должны учить своих учеников чему-то все-таки большему, не так ли?
А какой урок это ему дало для реальной жизни?
Очень даже замечательный урок — любой факап является факапом, вне зависимости от того, насколько, казалось бы, незначительна ошибка.
Советую почитать (всем лайкнувшим в т.ч.) про «право на ошибку» и его влияние на не зрелую психику, тема хорошо изученная. Если коротко — сильно жесткое наказание за ошибки убивает желание вообще что-либо делать. Получаем на выходе человека без амбиций.
Я решительно не понимаю с какого перепуга оценка 4 — сильно жесткое наказание за ошибку.
А это когда родители за четверку наказывают хуже, чем за убийство. Сталкивался я с такими людьми — могут и суицид из-за четверки сделать.
С тех пор как 5 стало наградой. За нею гонятся, и обижаются если ее не получают.
Интересно, а не ломает ли психику, факт, что в послешкольной жизни твои оценки никому не нужны?
Интересно, а не ломает ли психику, факт, что в послешкольной жизни твои оценки никому не нужны?
Советую почитать (всем лайкнувшим в т.ч.) про «право на ошибку» и его влияние на не зрелую психику, тема хорошо изученная.
Человек — студент, какая незрелая психика? Хватит уже этого инфантилизма. Он к реальной работе готовится, к ответственности, а не в детский сад пришел.
Скажу лично за себя — в моем окружении (и я сам) — лет до 20 никто не знал кто что и зачем будет в будущем делать. А в вузы все поступали просто от армии откосить в основном, так как ни проф. ориентации, ни мозгов своих ни у кого не было.
До 20? Да это отличный расклад :)
Лично мне понадобилось 25.
Лично мне понадобилось 25.
Сколько вам лет?
Я в начале 90-х поступал уже зная кем я хочу стать и чем заниматься по окончании ВУЗа.
Я в начале 90-х поступал уже зная кем я хочу стать и чем заниматься по окончании ВУЗа.
А в вузы все поступали просто от армии откосить в основном, так как ни проф.
Ну так и следовало бы их всех отчислить.
Человек зреет после 30. Задолго после первой работы, первой жены и первого ребенка. А студенты — дети. Хотя конечно это так не воспринимается — когда тебе меньше 30, а уж тем более меньше 25. Мои дети в 3 года уже говорят что они взрослые :)
Человек зреет после 30.
Кое-кто 2 тысячи лет назад уже и учение свое создал, и проповедовал по всей стране, и раскрутился, так что власти испугались, и был казнен всего-то в 33 года.
И в те времена это не было особо удивительным (удивительным является только степень распространенности его учения и как оно прошло через тысячелетия). Мужчина тогда считался мужчиной в 15.
А современные люди — какое там учение, они, оказывается, после 30 дозревают еще (как вино, что ли)
P.S.:
А если серьезно — то да, современные люди более инфантильны (можно почитать про особенности поколения Y).
Но раз на раз не приходится. Всех грести под одну гребенку — некорректно.
У меня есть знакомые: одна уехала из родительского дома в 15 лет учиться и с тех пор живет самостоятельно, обеспечивает родителей; другая уехала в 18 и родители вообще не помогали и не помогают (у них конфликт), моталась по съемным квартирам, как-то зарабатывала сама; другая в 40 лет сидит на шее у родителей, не работала и не работает (здорова, с вышкой), полагаю, и не будет (родители не олигархи, обычные).
И вот уже 2 тысячи лет вся европа расплачивается за его незрелые действия)
По поводу Христа есть стандартный ответ что Илья Муромец в 33 впервые с печи поднялся.
А так — как-то несерьезно сравнивать чисто биологическое взросление из древности (мужчина и сейчас в 15 может и детей заделать, и по физическим габаритам не кардинально отличается от взрослого) и более сложное социальное и профессиональное взросление. Вроде как Моцарт прославившийся еще подростком как композитор и тогда считался гением и скорее исключением, чем правилом, а в основном реального профессионально зрелыми люди и тогда становились после 20 (учебу никто не отменял же), думаю, часто сильно после.
А так — как-то несерьезно сравнивать чисто биологическое взросление из древности (мужчина и сейчас в 15 может и детей заделать, и по физическим габаритам не кардинально отличается от взрослого) и более сложное социальное и профессиональное взросление. Вроде как Моцарт прославившийся еще подростком как композитор и тогда считался гением и скорее исключением, чем правилом, а в основном реального профессионально зрелыми люди и тогда становились после 20 (учебу никто не отменял же), думаю, часто сильно после.
Зрение зрению рознь. Самостоятельность — не зрелость. Один из факторов — но не единственный. Еще например эмоциональная стабильность. Эти ваши зрелые того времени воевали, убивали и изменяли. Да так часто — что им нужен был злостный бог карающий то за онанизм, то за злые мысли.
А если вы не хотите грести под одну гребенку — зачем вы идете за дипломом государственного образца? Ведь это фактически и есть гребенка, учащийся ее добровольно выбрал, а потом начинается «я особенный». Особенный — не иди в универ, сам себе диплом выпиши, какие проблемы :)
А если вы не хотите грести под одну гребенку — зачем вы идете за дипломом государственного образца? Ведь это фактически и есть гребенка, учащийся ее добровольно выбрал, а потом начинается «я особенный». Особенный — не иди в универ, сам себе диплом выпиши, какие проблемы :)
Человек зреет после 30. Задолго после первой работы, первой жены и первого ребенка. А студенты — дети.
Кек, ну тогда пускай учится до 35 а потом уже работу ищет что ли?
Зачем безответственный незрелый человек на работе нужон и кому?
Ну почему любой, вон на ракете «Протон» кто-то поставил датчик вверх ногами… а, ну да…
Ну как бы это оценка не только знаний ученика, но и способности их применять. Вот в конкретном случае ученик не смог, не важно, от волнения, просто запамятовал, а другой смог. Им обоим ставить отлично? Но они же на разном уровне справились с задачей.
Ну так и система оценивания не 1000 бальная, и оценку ставят не за «выполнение задания», задача экзамена выявить итоговый уровень знаний и умений ученика в конце курса. На лабораторке вполне нормально ставить 4 за такую ошибку. А экзамен это инструмент преподавателя, похожий на собеседование. Задача преподавателя разделить учеников на 5 категорий. Каждая категория детально описана в рекомендациях министерства образования, ведь диплом у нас государственного образца, а не образца «Ивана Федоровича»?
Конечно каждый ученик — личность и выполняет задание не как другой. И вы могли-бы подумать что 5 это 100% идеальное знание предмета в стиле Бетмена, но это не так. 5 это примерно 80% и более усвоения материалов и навыков.
На практике обычно 5 обозначает — «ученик понял суть предмета и его принципы», а не стал матерым специализстом за пол года с набитой рукой. Например на вопрос «чем прямое преобразование Фурье отличается от обратного», отличник ответит «Прямое преобразует сигнал в спектр, а обратное по спектру восстанавливает сигнал.» А хорошист начнет цитировать определение сначала первого, потом второго. Т.е. хорошист запомнил, выполнил все что нужно было, но ни чего не понял, «вы хотели чтоб я это знал — я знаю». А троечник как хорошист, но не смог все запомнить. НО это грубо и мое мнение, министерство расписывает лучше.
Конечно каждый ученик — личность и выполняет задание не как другой. И вы могли-бы подумать что 5 это 100% идеальное знание предмета в стиле Бетмена, но это не так. 5 это примерно 80% и более усвоения материалов и навыков.
На практике обычно 5 обозначает — «ученик понял суть предмета и его принципы», а не стал матерым специализстом за пол года с набитой рукой. Например на вопрос «чем прямое преобразование Фурье отличается от обратного», отличник ответит «Прямое преобразует сигнал в спектр, а обратное по спектру восстанавливает сигнал.» А хорошист начнет цитировать определение сначала первого, потом второго. Т.е. хорошист запомнил, выполнил все что нужно было, но ни чего не понял, «вы хотели чтоб я это знал — я знаю». А троечник как хорошист, но не смог все запомнить. НО это грубо и мое мнение, министерство расписывает лучше.
хорошист запомнил, выполнил все что нужно было, но ни чего не понялЧестно говоря на мой взгляд это какой-то мутный хорошист. Но таки да, это тоже мое, вполне вероятно неверное мнение. Я действительно считаю что 5 — это прям как Бетмен. Просто на мой взгляд сейчас оценки в целом воспринимаются слегка странно. Что-то типа двойка это не «плохо», а просто отсутствие знаний, тройка — ну где то-там что-то есть, четверка — половину материала выучил. Все остальное — пять. На мой вкус при этом пятерка несколько обесценивается. Хотя конечно все зависит от конкретных мест, и это также мое субъективное мнение.
Конечно обесценивается, но так и мотивация учащихся падает и их способности. 5 это значит — годный студент фактически, интересуется предметом, интересуется учебой. Если у человека 4 и 5 в дипломе — то он нормальный и адекватный, можно брать. Если везде одни 4 — ну значит он прилежный болван, делает что говорят, в суть не вникает. Если значительное количество 3 по профильным предметам и при этом есть и 5 и 4, значит эмоционально не стабильный, не дисциплинированный и своенравный. Может работать шикарно месяц, потом месяц бухать или прокрастинировать. А через год пошлет всех матом, скажет у вас технологии скучные\не правильные — я ушел.
Те кто хотят найти юного Бетмена — те смотрят на вне дипломные титулы, всякие участия в олимпиадах, хакатонах и прочем. Задача обычного образования — давать обычных специалистов, не брильянты и не Бетмены, просто обычных нормальных инженеров.
Посему для меня 4 — это как плевок в лицо и факт профнепригодности. Осилить элементарную программу стандартного государственного курса — не сложно. И т.к. я учился по собственному желанию, сам выбирал направление и ВУЗ — для меня было очень важно пройти обучение полноценно. Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
А насчет 2 — ну в университете это значит что ты идешь в армию. А вот 3 — это считает нормальная оценка для «стоящих в очереди за дипломом». Посему получить 3 это ваще жутко стыдно для меня, это как напиться по молодости и попасть в таком состоянии в телевизор, и потом всю жизнь тебя будет так вспоминать при каждом трудоустройстве (при условии что диплом смотрят).
Кстати в локальных контора — на дипломы у нас смотрят и на ту его часть где есть оценки. Но только у молодых специалистов, потому уже опыт, портфолио и так далее. А вот первые несколько лет — банально больше не почем судить человека. Даже если он отлично прошел собеседование и написал тестовое — это не полное покрытие важных качеств личности. Нужно же понимать насколько он стабилен. Проработает ли он год или месяц или пока ты его не уволишь? Будет ли он легко осваивать новые технологии или будет жестко навязывать привычные себе и сопротивляться всему остальному?
Из рассказов про иностранные ВУЗы — там важность оценок намного выше. Там получается соревновательный принцип везде. Т.е. программа не фиксированная, есть разные преподаватели по каждому предмету, и разные предметы на выбор. И если ты хочешь попасть к лучшим преподам и на самые интересные курсы — у тебя должен быть высоких бал за прошлый семестр. В итоге если отличник и старается — то он реально учился в Гарварде, а если троечник, то ходя в тот же Гарвард — учился у всяких аспирантов, и ни чем не лучше «местного колледжа».
Если брать всякие курсы и сертификаты — то там два состояния — сдал или не сдал, дали или не дали. Фактически 2 и 5. А что такое 4? Пол сертификата? Полу специалист?
Если брать политику бесплатного и платного образования. Если у тебя бал 4.75 и выше — тебя госво поощряет гривной. Если у тебя бал 4 и выше — то ты имеешь право получить образование бесплатно. А если ниже 4 — это значит что фактически государство считает что с тебя не будет ни какого толку, ты бесполезно тратишь свое время на этой специальности, но ты имеешь право — плати деньги и ходи. Вопрос насколько этично продавать дипломы, а выдавать дипломы тем у кого средний бал даже 4.0 — это фактически продать бумажку, «не специалисту», которому это дело не интересно и который знаний не имеет. Я считаю — не этично, кто-то считает что это либерально и финансово выгодно, троечники — содержат отличников.
Те кто хотят найти юного Бетмена — те смотрят на вне дипломные титулы, всякие участия в олимпиадах, хакатонах и прочем. Задача обычного образования — давать обычных специалистов, не брильянты и не Бетмены, просто обычных нормальных инженеров.
Посему для меня 4 — это как плевок в лицо и факт профнепригодности. Осилить элементарную программу стандартного государственного курса — не сложно. И т.к. я учился по собственному желанию, сам выбирал направление и ВУЗ — для меня было очень важно пройти обучение полноценно. Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
А насчет 2 — ну в университете это значит что ты идешь в армию. А вот 3 — это считает нормальная оценка для «стоящих в очереди за дипломом». Посему получить 3 это ваще жутко стыдно для меня, это как напиться по молодости и попасть в таком состоянии в телевизор, и потом всю жизнь тебя будет так вспоминать при каждом трудоустройстве (при условии что диплом смотрят).
Кстати в локальных контора — на дипломы у нас смотрят и на ту его часть где есть оценки. Но только у молодых специалистов, потому уже опыт, портфолио и так далее. А вот первые несколько лет — банально больше не почем судить человека. Даже если он отлично прошел собеседование и написал тестовое — это не полное покрытие важных качеств личности. Нужно же понимать насколько он стабилен. Проработает ли он год или месяц или пока ты его не уволишь? Будет ли он легко осваивать новые технологии или будет жестко навязывать привычные себе и сопротивляться всему остальному?
Из рассказов про иностранные ВУЗы — там важность оценок намного выше. Там получается соревновательный принцип везде. Т.е. программа не фиксированная, есть разные преподаватели по каждому предмету, и разные предметы на выбор. И если ты хочешь попасть к лучшим преподам и на самые интересные курсы — у тебя должен быть высоких бал за прошлый семестр. В итоге если отличник и старается — то он реально учился в Гарварде, а если троечник, то ходя в тот же Гарвард — учился у всяких аспирантов, и ни чем не лучше «местного колледжа».
Если брать всякие курсы и сертификаты — то там два состояния — сдал или не сдал, дали или не дали. Фактически 2 и 5. А что такое 4? Пол сертификата? Полу специалист?
Если брать политику бесплатного и платного образования. Если у тебя бал 4.75 и выше — тебя госво поощряет гривной. Если у тебя бал 4 и выше — то ты имеешь право получить образование бесплатно. А если ниже 4 — это значит что фактически государство считает что с тебя не будет ни какого толку, ты бесполезно тратишь свое время на этой специальности, но ты имеешь право — плати деньги и ходи. Вопрос насколько этично продавать дипломы, а выдавать дипломы тем у кого средний бал даже 4.0 — это фактически продать бумажку, «не специалисту», которому это дело не интересно и который знаний не имеет. Я считаю — не этично, кто-то считает что это либерально и финансово выгодно, троечники — содержат отличников.
+1, на первом, оно же текущее, месте работы вкладыш с оценками вообще не спрашивали. Больше того, я его даже не забирал. Хотя признаюсь честно — там, особенно на первых курсах когда связался с «плохой» компанией да и не было своего компьютера (а соответственно и навыков использования как и знаний в профильных дисциплинах), просто куча трояков. Самый обидный по какой то математике, предмет знал и спокойно мог сдать на отлично, благо математику всегда любил, но из за просроченного курсача по экономике удалось попасть только на пересдачу где мне и еще одному гаврику поставили трояки за то что помогли жалюзи повесить. И да, это даже по меркам моего города был далеко не самый топовый вуз)
Я показывал один раз, когда устраивался на завод, но там брали всех подряд. После этого работал только программистом, а диплом вообще по другой специальности, поэтому не показывал его больше никому.
5 это значит — годный студент фактически, интересуется предметом, интересуется учебой.
На практике у каждого преподавателя свое мнение о семантике оценок и его надо просто принимать. У меня например у преподавателя по матану было мнение из разряда канонического "на 5 знает господь бог, на 4 — я, а вы — на все остальное", с-но иногда никто из потока не мог сдать с первого раза хотя бы на 3 :)
Бывает, и это плохо. Есть стандарт и ему нужно соответствовать и ученику и преподавателю. Если преподаватель хочет, он может открыть свой «кружок» и унижать там учеников, за их деньги.
0xd34df00d Единичные оценки — не важны для анализа. По ним систему не построишь. Не вы первый, не вы последний, вступивший в конфликт с преподом. Думаю все это понимают.
ApeCoder я вроде так и написал. Оценивать нужно не знание фактов, и преподы оценивают не знание фактов. На одном экзамене у меня было вообще так. Я пришел тянуть билет, препод взял методичку(которую я не видел до этого), открыл на рандомной странице, показал схему ака ПИД регулятор, но звеньев было больше. Тыкнул в один из них и спрашивает — зачем он здесь. Я ответил буквально в 7 слов — получил 5 и ушел. Хотя мне рассказывали что он жутко валит и так далее. На самом деле ему было плевать на точность заученных определений, а «большинство» этого не понимало. Они старались вызубрить как можно точнее.
0xd34df00d Единичные оценки — не важны для анализа. По ним систему не построишь. Не вы первый, не вы последний, вступивший в конфликт с преподом. Думаю все это понимают.
ApeCoder я вроде так и написал. Оценивать нужно не знание фактов, и преподы оценивают не знание фактов. На одном экзамене у меня было вообще так. Я пришел тянуть билет, препод взял методичку(которую я не видел до этого), открыл на рандомной странице, показал схему ака ПИД регулятор, но звеньев было больше. Тыкнул в один из них и спрашивает — зачем он здесь. Я ответил буквально в 7 слов — получил 5 и ушел. Хотя мне рассказывали что он жутко валит и так далее. На самом деле ему было плевать на точность заученных определений, а «большинство» этого не понимало. Они старались вызубрить как можно точнее.
Т.е. если получил 4 — значит предмета не понял, недоработал, упустил время и шанс. И ни когда не нагонишь, потому что статистически маловероятно, что ты будешь получать второе образование по тому-же профилю или повторно посещать тот-же курс.
Это подразумевает, что оцениваетя именно понимание, а не знание кучи фактов, и информацию можно получить только прослушав какой-то курс в университете.
Им обоим ставить отлично?
Именно так, если преподаватель уверен что и тот и другой знают предмет на отлично. А это у нас в «Дано». А если вдруг препод засомневался, просто посадил бы «затупившего»на 5-10 минут собраться с мыслями. Тот бы успокоился и ответил, или не ответил если он действительно не знает. Вот и все.
Вот смотивировал, в сложных расчётах не забывать, что 1/2 больше 1/4. В физике народ вот постоянно палиться на том, что результат в 10 раз больше или меньше. Казалось бы небольшая ошибка, а на самом деле можно такой расчёт отправить в помойку, если он на порядок расходится. И рассчитать «на глазок» с ошибкой 10-20%.
В вузе уже обычно относительно взрослые и понимающие, чего они хотят, люди.
В российском-то, т.е. сразу после школы? Ну-ну.
Ну так «в абстрактном российском вузе» и «в Физтехе» — это две очень большие разницы.
Личность становится зрелой — пожив жизнь. Пройдя определенные этапы, и семейные и бытовые и рабочие. Т.е. это тупо зависит от времени жизни. И не нужно путать интеллект и самоконтроль — со зрелостью личности. Личность становится зрелой примерно к тому времени, когда разрешено баллотироваться на президента. И то не всегда! Яркий пример очень одаренного, но не зрелого, человека показан в фильме «Good Will Hunting», и там как раз аналог Физтеха.
Это да. Бывает.
Я когда 18 лет назад писал «олимпиадную» как бы предварительно вступительную работу по математике в МГУ решил 5 задач из 6ти.
В одной чуток налажал. Сложная стереометрия, я рассмотрел 3 случая из 4х. 4ый вырожден, но я не написал об этом. Ок. Минус.
Но другая задача… До сих пор обидно. Две страницы вычислений и в конце:
… = 8+6 = 10
Ответ: 10
И минус за задачу. 3 за работу — не прошел. Правильный ответ был 14.
Так что пришлось поступать летом.
PS. Еще. Более эпичесский фейл. Сдавал ГосЭкзамен. Где то в ходе одного доп. вопроса нарисовал касательную и доответил на вопрос. А экзаменатор такой: «Ну, хорошо. Это вы знаете. Давайте напоследок выведете мне уравнение касательной и закончим на этом.».
Я такой радостный — 5 за Гос уже у меня, что там эта касательная, я ее в 10 классе мог вывести. И… ступор. Не выводится. Так порисовал — не выводится.
Эдак попробовал — фигня получается(я ж помню формулу!).
Результат — 4 по госу из-за этой касательной. Вышел — все вывелось устно.
Я когда 18 лет назад писал «олимпиадную» как бы предварительно вступительную работу по математике в МГУ решил 5 задач из 6ти.
В одной чуток налажал. Сложная стереометрия, я рассмотрел 3 случая из 4х. 4ый вырожден, но я не написал об этом. Ок. Минус.
Но другая задача… До сих пор обидно. Две страницы вычислений и в конце:
… = 8+6 = 10
Ответ: 10
И минус за задачу. 3 за работу — не прошел. Правильный ответ был 14.
Так что пришлось поступать летом.
PS. Еще. Более эпичесский фейл. Сдавал ГосЭкзамен. Где то в ходе одного доп. вопроса нарисовал касательную и доответил на вопрос. А экзаменатор такой: «Ну, хорошо. Это вы знаете. Давайте напоследок выведете мне уравнение касательной и закончим на этом.».
Я такой радостный — 5 за Гос уже у меня, что там эта касательная, я ее в 10 классе мог вывести. И… ступор. Не выводится. Так порисовал — не выводится.
Эдак попробовал — фигня получается(я ж помню формулу!).
Результат — 4 по госу из-за этой касательной. Вышел — все вывелось устно.
На самом деле сейчас в наших вузах активизировалась дискуссия против устных экзаменов, как раз примерно по таким причинам.
Сейчас в МГУ арифметические ошибки трактуются в пользу абитуриента.
Сейчас такое было бы плюсом с точкой.
Сейчас такое было бы плюсом с точкой.
Да? Даже на МехМат\физмат\ВМиК?
Даже не знаю как к этому относиться.
Хотя… если одновременно усложнить задачи, то думаю и норм.
Даже не знаю как к этому относиться.
Хотя… если одновременно усложнить задачи, то думаю и норм.
А зачем делать из студента калькулятор? Ладно, на физических факультетах это может и важно, но на математическом уже в первый месяц начинаются темы где арифметика в принципе практически не нужна и чем дальше, тем больше. У нас на матмехе в СПбГУ большинство преподов арифметические ошибки замечало, но на оценку они не влияли в 99 случаях из 100. Это даже не было поводом задать доп вопрос, разве что студента потролить, да и то не всегда.
Не все можно вывести. А забывать могут все, причем понимание есть, а слов нет судя и по случаю с Савватеевым. Это нормально.
А теперь представь, что времени вывести и доказать нет. И д.ф.-м.н выглядит профаном
Я в лекциях Савватеева наблюдал момент, когда по ходу лекции он забыл формулу нахождения корней квадратного уравнения (а это д.ф.-м.н. между прочим). Он слегка смутился, но тут же ее вывел и доказал.
Я вы часом не помните название? Может, сохранили ссылку, буду весьма признателен.
Так на вскидку не скажу. Насколько помню это было в одной из лекций 100 уроков математики.
На самом деле пример не совсем честный, т.к. вывод формулы корней квадратного уравнения — не какой-то особый, это техника, которая очень много где применяется. Если бы вопрос был какой-то специфичный, он бы вполне мог и залипнуть. Например, я сомневаюсь, что можно так быстро оп! и вывести формулы Кардано, если их не помнить или не помнить соответствующую базу (например прям как раз недельку назад теорию Галуа повторил, кек).
Я этим примером лишь проиллюстрировал, что незнание некоторых фактов компенсируется знанием некоторых принципов. Но, если ты не знаешь принципов в той области, в которой как бы сеньор, то тут уже ничто не поможет. Конечно судить о человеке по одному неверному ответу минимум глупо. Но. Я сам довольно много собеседовал людей, приходящих на сеньорские позиции, с огромным стажем (судя по резюме), но при этом не способных внятно ответить на базовые вопросы, которые должен знать любой джун. Может все дело в перегретом рынке предложений и завышенной самооценке отдельных представителей профессии?
Есть вероятность что данный сеньор уже давно не трогал вещи которые должен знать тот же джун на зубок. Например когда ты поставленные задачи решаешь уже на автомате и в принципе уже не задумываешься о способе решения, т.к. у тебя уже наработанная практика и все ушло на уровень рефлексов. А тут на собеседовании ты включаешь голову (у тебя же стресс) и у рефлексы благополучно задавливаются.
Кмк, перед собеседованием можно было бы и потрогать. В конце концов, уж если цель продать свое время подороже (в хорошем смысле), то уж товар надо представить как можно лучше. В самом начале у меня тоже были мягкие фильтры, но, когда я стал терять по полдня на разные собеседования «сеньоров», фильтры ужесточились практически автоматом — сперва ответы на листочке и, если порог пройден, то личная беседа.
(offtop 25 минут на редактирование комментария; видно я что-то пропустил, но это круто).
(offtop 25 минут на редактирование комментария; видно я что-то пропустил, но это круто).
Для формулы кардано не нужна теория Галуа. В Википедии вывод достаточно простой и специфических знаний не требует. Но просто так без подготовки вывести, да, трудно.
Для формулы кардано не нужна теория Галуа.
Не нужна, но если вы накануне повторяли теорию Галуа, то, скорее всего, сможете сами получить вывод формул Кардано, не зная его наперед.
В Википедии вывод достаточно простой и специфических знаний не требует.
Открытие сейфа тоже не требует специфических знаний — это ведь не сложно, влево-вправо крутить :)
Смысл в том что в случае формул Кардано вывод не строится на использовании каких-то известных и общеприменимых методов, он выглядит как: "сделаем хитрое преобразование, потом еще одно, потом хитрую замену, и еще хитрое преобразования — и получим формулу!".
И вот эти преобразования взять неоткуда, они не являются типовыми. Именно по этой причине они и появились на несколько тысяч лет позже, чем формулы для квадратных :)
Но как математик ты можешь например сходу не ответить сколько существует суръекций между множествами. Я думаю подобных вопросов можно много накидать.
программирование — не математика.
Да, похоже учителем математики в школу Савватеева бы после такого не взяли.
на небольшое время «забыть»
Я не очень представляю, как Senior JS разработчик может забыть, что такое замыкание)
А какие проблемы грамотно пользоваться инструментом, но не знать назубок его академического определения?
По себе сужу, у меня опыта в программировании больше 20 лет и, но скажем, над определением переменной я вполне могу задуматься. А дальше зависит от того, чего хочет собеседующий, если его устроит объяснение на пальцах расскажу, в этот момент может всплыть какое нибудь определение которое я на заре карьеры мельком прочитал, если же вопрошающий явно пытается меня на чём то подловить… диалога не получится.
По себе сужу, у меня опыта в программировании больше 20 лет и, но скажем, над определением переменной я вполне могу задуматься. А дальше зависит от того, чего хочет собеседующий, если его устроит объяснение на пальцах расскажу, в этот момент может всплыть какое нибудь определение которое я на заре карьеры мельком прочитал, если же вопрошающий явно пытается меня на чём то подловить… диалога не получится.
«Академическое определение» требуют примерно нигде (ибо канона нет, какой такой букварь цитировать?), но если человек на понятийном уровне не может слов подобрать и ему требуется лезть в какие-то там чертоги сознания (гугол), чтобы вспомнить достаточно активно используемые фичи языка — это дурной знак. Дутых сеньоров в наше время тоже достаточно.
Я бы сказал, при прочих равных, это слабый знак, если человек решил тестовое задание, ответил на много вопросов, и слился на одном, этот вопрос не должен быть последним.
В отрасли достаточно товарищей с хорошо подвешенным языком, которые умеют отвечать на неожиданные вопросы, и не умеют работать. И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
В отрасли достаточно товарищей с хорошо подвешенным языком, которые умеют отвечать на неожиданные вопросы, и не умеют работать. И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
Я бы сказал, при прочих равных, это слабый знак, если человек решил тестовое задание, ответил на много вопросов, и слился на одном, этот вопрос не должен быть последним.
Опять вы впадаете в крайность. Зачем?
Если человек решил тестовое задание без наблюдения и слился на элементарном вопросе, то с высокой вероятностью его делал кто-то другой. Весомая причина дальше испытывать собеседуемого на других базовых вопросах.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
И хватает людей разной степени нелюдимости, которые просто решают поставленные задачи.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
Если человек решил тестовое задание без наблюдения и слился на элементарном вопросе, то с высокой вероятностью его делал кто-то другой. Весомая причина дальше испытывать собеседуемого на других базовых вопросах.
С таким не сталкивался. Впрочем, есть же испытательный срок, и по крайней мере у нас решение о найме принимается коллегиально.
Есть разница между выполнением задач и выполнением их в хорошем качестве.
Разница есть, по моему скромному опыту, выполнение задач в хорошем качестве и то, насколько хорошо у человека подвешен язык коррелирует слабо. Может конечно, нужно джедаем найма быть, но по мне проверить человека «в бою» надёжнее.
есть же испытательный срок
А если у вас уже есть на примете несколько человек без таких сомнительных историй? Нельзя всех взять вне штата, а потом устраивать чемпионат на вылетание.
выполнение задач в хорошем качестве и то, насколько хорошо у человека подвешен язык коррелирует слабо
Если у человека есть знания, но нет возможности это выразить, то как он с командой общаться будет? С заказчиком?
А если кандидат говорливый, то проверить его как раз проще. Хорошие говоруны, кмк, проходят из-за недостатков интервьюера.
Нельзя всех взять вне штата, а потом устраивать чемпионат на вылетание.
В комментарии ниже этот момент затронул.
Если у человека есть знания, но нет возможности это выразить, то как он с командой общаться будет? С заказчиком?
Вопервых сам человек привыкает, потом команда тоже к человеку привыкает. Заказчик, конечно, не виноват, но это вопрос уже к руководству фирмы, а не к работнику.
А если кандидат говорливый, то проверить его как раз проще. Хорошие говоруны, кмк, проходят из-за недостатков интервьюера.
Мой хороший друг в таких случаях обычно отвечает, что все мы немного лошади. В том смысле, что никто не идеален.
Можно спорить о подходах к интервью. Думаю что подход, когда человека на интервью спецом заваливают, имеет право на жизнь. Например при найме в какой нибудь отдел продаж. В случае с программистами работающими с прикладными задачами, думаю он не тех людей пропустит.
Может конечно, нужно джедаем найма быть, но по мне проверить человека «в бою» надёжнее.
Надёжнее, но намного дороже в случае его неуспеха.
А дальше каждая компания для себя решает, какую цену она готова доплатить за сокращение false negatives при найме.
У меня, конечно, есть лукавство. Если есть два кандидата, которые в целом одинаково проходят интервью, то быстрый из развёрнутый ответ на такой вопрос прибавит ответившему баллов. Но именно прибавит тому кто ответил, а убавит баллов у второго.
Разница между прибавит и убавит существенная. Т.к. при очередном раунде найма, мы второго пригласим.
Разница между прибавит и убавит существенная. Т.к. при очередном раунде найма, мы второго пригласим.
Может кандидат просто быстрее соображает? Уж убавить ему это никак не должно.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
Вижу у меня «не» потерялось. Предложение должно звучать так:
А тут мы упираемся в эффект Даннинга — Крюгера. Особенно если проведение интервью это не основная работа, а то, что приходится делать время от времени.
Мне кажется, мы с вами примерно про одно говорим.
Но именно прибавит тому кто ответил, а не убавит баллов у второго.
А если интервьюер позволяет оценкам одного человека влиять на другого — это его трудности в профессии. Это тоже непростой скилл, которым нужно уметь владеть.
А тут мы упираемся в эффект Даннинга — Крюгера. Особенно если проведение интервью это не основная работа, а то, что приходится делать время от времени.
Мне кажется, мы с вами примерно про одно говорим.
но не знать назубок его академического определения
Зачем вы говорите об академическом определении? Зачем вы возводите в абсолют мои слова? Я нигде не говорил об определении. Я говорил вообще о понятии. Вы можете представить, что человек забыл, что такое переменная? Не забыл ее определение, а вообще забыл, что такое переменная. Вы ему говорите слово «переменная», а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
Значит я вас не так понял. Вы же допускаете, что тот, кого вы собеседуете тоже может вас не так понять?
> а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
Например он недавно из института и привык к преподавателям, которые требуют определение в соответствии «с тем самым учебником».
Вопрос в дальнейшей реакции вас, как интервьюера.
> а он смотрит на вас как баран на новые ворота и для него это совершенно новое слово
Например он недавно из института и привык к преподавателям, которые требуют определение в соответствии «с тем самым учебником».
Вопрос в дальнейшей реакции вас, как интервьюера.
Например, у него проблемы с электропроводкой в квартире, и он весь вечер перед собеседованием пытался разобраться, почему выключатель не работает. Скажут ему «замыкание», и он будет вспоминать, что же там такого есть в JavaScript, что можно сравнить с неправильным соединением проводов.
<зануда мод>Ну почему же сразу неправильным? В замыкании проводов как таковом ничего неправильного нет — это нормальная практика. А в словосочетании «короткое замыкание» про «неправильность» та часть, которая «короткое»</зануда мод>
Несогласным хочу напомнить, что влияние контекста достаточно известная вещь в психологии, а человеческое мышление работает на ассоциациях, и без соответствующих ассоциаций можно не сразу вспомнить то, что нужно.
А Senior мог на предыдущей работе называть это исключительно словом "closure", и потому в данный момент слово "замыкание" у него ассоциируется в первую очередь с электричеством, и он может замяться на какое-то время, вспоминая правильное значение.
Я с 1991 года программирую, я не могу себе представить ситуации, чтобы я не смог сказать, что такое замыкание. Ну или virtual (хотя я уже лет десять не писал на языках, где это есть). Я допускаю, что могут быть случаи разные, но это такая дикая редкость, что шанс с такой ситуацией столкнуться мизерно мал.
На мой взгляд есть 2 категории людей, с хорошей памятью на определения и с плохой, так вот у меня куча знакомых из первой категории и они просто не способны понять как это — забыть то что "учил", они распостраняют свой личный опыт на всех окружающих без права поставить его под сомнение. Но у другой части обычно есть приемущество (возможно вынужденное изза плохой памяти) в части логики.
Был во второй категории, но сейчас скорее в средней. Просто понял что неправильно запоминал все это. Хотя может все эти замыкания и прочие термины запоминаются потому что выглядят интересно и часто мелькают в описаниях технологий/статьях?
Возможно были во второй, возможно не были. Чтобы понять нужен опыт, если вы сегодня можете выучить стих наизусть за час а завтра только помнить о чём он в общих чертах, то это одно, если вы не помните его один раз прочитав — это другое.
p.s. у меня ребёнок пример фантастической (по моим меркам) памяти, ему один-два раза читаешь стих на пару страниц, и он без проблем его рассказывает через день :)
Да, я действительно скорее не про способности а про отношение к запоминанию. Раньше считал что это вообще смысла не имеет, сейчас считаю немного по другому.
Определение, так-то, не стих, где 2 слова местами поменял, и ритм сломался. Определение можно сходу из головы наговорить, если понимаешь, что определяешь. Правда для этого уже надо качать умение сходу наговаривать из головы, а не зажиматься.
Для меня вы из категории не понимающих как такое возможно.
Уточню, когда вам говорят а расскажите про "название" вы просто не помните про что оно :)
p.s. и да уточнить не проблема, проблема в том что вторая сторона делает однозначный вывод руководствуясь своим опытом и верой в то что если не может сходу ответить то не знает.
проблема в том что вторая сторона делает однозначный вывод руководствуясь своим опытом и верой
А вы, как первая сторона, на чем основывались, делая этот вывод?
Уточню, когда вам говорят а расскажите про «название» вы просто не помните про что оно :)
Тут нюанс же есть, в направлении вопроса. Спрашивают же не «как называется вот эта красная лопата по-научному», а «как выглядит пожарная лопата».
«Не вспомнить» простительно для первого варианта. Человек отлично пользуется пожарной лопатой, но чутка подзабыл, что ее положено называть «пожарной», тупо забыл слово — ничего страшного, главное, что пользоваться умеет.
А во втором варианте… Кхм, это не «подзабыл слово», а просто «не может с ходу вспомнить, как оно выглядит». Вот это тревожный звоночек же.
Как бы, вспомните правильный термин, подходящий под определение — это да, вопросы не для собеседования, а, скорее, для кроссворда. А вот «объясните термин» — вроде, норм.
А зачем запоминать определения дословно? При наличии понимания о чем речь определение можно сочинить на ходу используя ту самую логику в которой есть преимущество.
Глупо отрицать что существуют интервьюэры пытающиеся почесать свое ЧСВ на собеседованиях. Но надо помнить что собеседование процесс двухсторонний. Если вы видите что компания вам не подходит, скажите спасибо, за то что они об этом честно рассказали и двигайтесь дальше. Хуже когда на собеседовании врут про то что будет скрам и передовые технологии, а после выхода на работу оказывается что везде code-and-fix на фреймворке который уже вышел из поддержки, но для этого и дален испытательный срок. Он, как и собеседование, тоже работает в обе стороны.
И еще, мне кажется что если вы волнуетесь на собеседованиях, то вам еще рано называться senior :)
И еще, мне кажется что если вы волнуетесь на собеседованиях, то вам еще рано называться senior :)
Насчет собеседования согласен, а вот в случае увольнения работника после испытательного срока у следующего работодателя могут возникнуть вопросы, а если таких увольнений несколько то нужно быть весьма убедительным, чтобы обратить эту ситуацию в свою пользу. У меня в трудовой есть запись что я проработал в фирме чуть более года, на двух собеседованиях про этот момент спрашивали, хотя и мельком.
Если могут возникнуть вопросы, то нужно иметь на них ответы.
Если ситуация повторилась не один раз, да еще и подряд, то возможно надо что-то в консерватории поправить.
У меня в «трудовой» есть запись о том что меня уволили во время испытательного срока. И ничего страшного в этом не вижу. С радостью рассказываю какие работодатели бывают чудаки.
Если ситуация повторилась не один раз, да еще и подряд, то возможно надо что-то в консерватории поправить.
У меня в «трудовой» есть запись о том что меня уволили во время испытательного срока. И ничего страшного в этом не вижу. С радостью рассказываю какие работодатели бывают чудаки.
в какой системе счисления?)
Проблема с аргументами от аналогий в том, что аналогия должна быть корректной, то есть принципальные моменты в ситуации и ее аналогии должны совпадать, а противоречия должны отсутствовать. Так вот термин — это факт, который ни с чем не связан, это просто название, которое нельзя «вывести», его можно только запомнить. Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта. Человек может прекрасно понимать математику, физику, программирование, свободно владеть инструментарием, но именно из-за этого не помнить какой-то терминологический момент, которым никогда не пользуется. А надежно помнят все эти термины только те, кто либо зубрит, либо просто вчера из учебного заведения, либо учат этому, либо вот такие собеседователи, которые делают из терминологии фетиш и святыню. У разработчиков экономического и бухгалтерского софта точно также спрашивают план счетов. И тоже аргумент «это должно от зубов отскакивать». Нет, не должно. Это, как раз, именно то, что можно всегда «подсмотреть». А должно оно «отскакивать от зубов» тогда, когда человеку кроме фактической памяти работодателю предложить нечего.
Таки да. Всегда путал по номерам законы Ньютона...
Плюсану мануально, так как по-другому не могу. Для меня все эти вопросы на «память» — полный бред. Этак скоро начнут собеседовать как-то так: «Какого числа, какого месяца и какого года Страуструп придумал C++? Аааа, не знаешь! Ну так говно ты, а не C++ разработчик».
В какой-то мере виновато школьное образование, когда в большинстве случаев «отличником» будет тот, кто тупо запоминает дату битвы при Бородино, или вызубрит наизусть стих Пушкина, без понимания что там за настроения были в Европе при Наполеоне и что за личность была у Александра Сергеевича. Культ карго во всей красе.
В какой-то мере виновато школьное образование, когда в большинстве случаев «отличником» будет тот, кто тупо запоминает дату битвы при Бородино, или вызубрит наизусть стих Пушкина, без понимания что там за настроения были в Европе при Наполеоне и что за личность была у Александра Сергеевича. Культ карго во всей красе.
Потому что никому не интересно что бы вы сделали если бы у вас была карма. Ограничения отрицательной кармы вообще-то задумывались как наказание, а не как индульгенция на оставление мусора.
Думаю, если бы вы более внятно изложили свою мысль (развернули, чем вам так понравился коммент и почему, а не просто тыкнули +1), то вас бы не минусовали.
Это как очень стого и серьёзно спрашивать детишек день, месяц и год октябрьской революции, отмены крепостного права, взятия Бастилии, начала и конца 1 и 2 мировых, не донеся до них в течение года даже наличия у этих событий связей, причин и следствий.
Я сам через это прошёл: в школе ненавидел историю, потому что она сводилась к зубрёжке имён и дат; и только после вуза понял, что у исторических событий, оказывается, есть причины, следствия и взаимосвязи, а не только хронологическая последовательность.
Все сильно от учителей и преподавателей зависит. У меня школа и вуз оставили ровно противоположные впечатления.
В школе я сначала жутко разочаровалась в истории. Моя мама историк и она мне всегда очень интересно умела рассказывать про взаимосвязи событий (а даты она сама плохо запоминает), про исторических личностей. Я ожидала от школы чего-то в этом духе, но мы просто переписывали параграф в таблички. С моим представлением о том, что историю нельзя упихнуть в эти таблички, было тяжко. В старших классах плюнула на таблички и сдавала вместо них эссе. Учительница пару раз писала замечания, но в целом была довольна тем, что как раз понимание есть, поощряла доклады, рефераты и эссе, в которых видно, что ученики думали головой, а не переписывали учебник или википедию.
А вот в университете опять все свелось к заучиванию дат, а мой реферат про народное ополчение 1812 года (с использованием источников из архивов, с чем вряд ли на факультете ИТ кто-то сильно заморачивался) был жутко раскритикован за то, что я не упомянула в нем кого-то из партизан, хотя это вообще разные вещи. А экзамен свелся к распечатке методички для кафедры.
В школе я сначала жутко разочаровалась в истории. Моя мама историк и она мне всегда очень интересно умела рассказывать про взаимосвязи событий (а даты она сама плохо запоминает), про исторических личностей. Я ожидала от школы чего-то в этом духе, но мы просто переписывали параграф в таблички. С моим представлением о том, что историю нельзя упихнуть в эти таблички, было тяжко. В старших классах плюнула на таблички и сдавала вместо них эссе. Учительница пару раз писала замечания, но в целом была довольна тем, что как раз понимание есть, поощряла доклады, рефераты и эссе, в которых видно, что ученики думали головой, а не переписывали учебник или википедию.
А вот в университете опять все свелось к заучиванию дат, а мой реферат про народное ополчение 1812 года (с использованием источников из архивов, с чем вряд ли на факультете ИТ кто-то сильно заморачивался) был жутко раскритикован за то, что я не упомянула в нем кого-то из партизан, хотя это вообще разные вещи. А экзамен свелся к распечатке методички для кафедры.
Ну год и месяц октябрьской революции помнить надо (день ИМХО не обязательно), чтобы в ноябре не смотреть «парад в честь парада 7.11.1941». По крайней мере в нашей стране, по крайней мере ближайшие лет 100.
Но в принципе согласен. Знание того, какая именно полубригада штурмовала южные флеши в 8 утра 26 августа — информация для массового обучения лишняя. Важно что в этом бою сражалась буржуазная армия объединенной Европы с феодальной армией РИ и что в его итоге понесла поражение (стратегическое, а не тактическое). И то, что не смотря на поражение в войне буржуазная идея спустя 200 лет цветет и пахнет.
Но в принципе согласен. Знание того, какая именно полубригада штурмовала южные флеши в 8 утра 26 августа — информация для массового обучения лишняя. Важно что в этом бою сражалась буржуазная армия объединенной Европы с феодальной армией РИ и что в его итоге понесла поражение (стратегическое, а не тактическое). И то, что не смотря на поражение в войне буржуазная идея спустя 200 лет цветет и пахнет.
Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта
Замыкание — это такой базис, что более подходящий пример, что 2×2 — это термин «умножение». Может ли математик забыть термин «умножение»? Для этого необходимо зубрить?
Может ли математик забыть термин «умножение»
А программист?
Для математика аналогом «замыкания», скорее, будут термины: «поле», «кольцо» и т.д.
А что, если сеньор всю жизнь читал статьи про кложур и рекуршен, а замыкание – это термин из электротехники?
Ок. Какие свойства умножения Вы знаете? Хотя бы своими словами. Чур не копипастом из вики.
Я не математик же ж) Сходу вспомнил два — от перестановки множителей результат не меняется и при умножении любого числа на ноль получится ноль.
А если спросить у Senior-математика. Он должен знать ответ на этот вопрос? Или тоже может забыть?
А если спросить у Senior-математика. Он должен знать ответ на этот вопрос? Или тоже может забыть?
Я к тому, что тоже вроде примитив, но senior-математик знает об этой простой операции столько, что может проболтать всё собеседование (как раз упоминавшиеся поля, кольца и свойства умножения на них). А может сказать, «ну эта, а чего про него рассказывать», при
этом не задумываясь применяя эти свойства на практике.
Помнить формулировку из учебника и уметь применять — не одно и тоже.
этом не задумываясь применяя эти свойства на практике.
Помнить формулировку из учебника и уметь применять — не одно и тоже.
senior-математик знает об этой простой операции столько
Так какой ответ вы ожидаете от человека, который пришел на собеседование на позицию «senior-математик»?
Вы ожидаете, что он расскажет, что такое умножение, расскажет свойства, поля, кольца и все остальное?
Или ожидаете, что он скажет в духе автора статьи: «ну чо вы прицепились с определениями? я может и пользовался, но термин такой забыл»
Чуть ниже найдете ответ 0xd34df00d.
Возможно не стоит ожидать такого развернутого ответа на такой вопрос, но однозначно стоит ожидать его в случае наводящих вопросов в стиле «а всегда ли существует обратный элемент?».
Возможно не стоит ожидать такого развернутого ответа на такой вопрос, но однозначно стоит ожидать его в случае наводящих вопросов в стиле «а всегда ли существует обратный элемент?».
Вот с ходу, относительно предыдущего поста. TheShock с ходу сказал «от перестановки множителей результат не меняется». Вот тут человек, это совершенно очевидно, отлично умеет применять, но не помнит термин «коммутативность». При этом есть очень ненулевая вероятность услышать эту же формулировку в ответ на «Что такое коммутативность в умножении».
«Забыл точное слово» — это не вспомнить термин «коммутативность», и это может произойти от волнения и пофиг вообще чего. Не ответить «что такое коммутативность» для «сеньор-математика» непозволительно.
«Забыл точное слово» — это не вспомнить термин «коммутативность», и это может произойти от волнения и пофиг вообще чего. Не ответить «что такое коммутативность» для «сеньор-математика» непозволительно.
Только если умножение коммутативно в этой структуре.
Вы можете перестать подозревать меня в самозванстве и начать лучше собеседовать? Я senior-алгебраист, а вы у меня определения базовых терминов (о которых я уже забыл) спрашиваете.
Это следует из дистрибутивного закона и обратимости сложения.
x*0 = x*(1-1) = x — x = 0
x*0 = x*(1-1) = x — x = 0
Алгебраист гарантированно должен. Любитель теорий типов, наверное, тоже. Матстатистик совершенно не обязан.
Но вы же согласны, что ни один из них на вопрос «что такое коммутативность» не может сказать «да я все это знаю, только слово подзабыл»?)
Да ну, без знания термина для концепции замыкания нельзя программировать, как нельзя вообще заниматься математикой без того, чтобы знать, что такое умножение? Не выдумывайте. Еще одна некорректная аналогия.
Я не верю, что senior-математик может сказать «я забыл, что такое умножение», точно так же, как я не верю, что senior-javascript-developer может сказать «я забыл, что такое замыкание»
Вы какой-то абсурд сейчас написали.
Я утверждаю, что степень «элементарности» и «фундаментальности» терминов «умножение» для математики и «замыкание» для программирования различается на порядок. Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно. Заниматься математикой без умножения и знания этого термина — нельзя.
А вы мне возражаете так, будто я сказал, что это вещи одного порядка, но обе — не важны. Предлагаю вам внимательнее читать аргументацию прежде чем выдвигать абсурдные контр-аргументы на то, чего ваш оппонент не утверждал.
Я утверждаю, что степень «элементарности» и «фундаментальности» терминов «умножение» для математики и «замыкание» для программирования различается на порядок. Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно. Заниматься математикой без умножения и знания этого термина — нельзя.
А вы мне возражаете так, будто я сказал, что это вещи одного порядка, но обе — не важны. Предлагаю вам внимательнее читать аргументацию прежде чем выдвигать абсурдные контр-аргументы на то, чего ваш оппонент не утверждал.
Программировать (и даже использовать саму концепцию), не зная термин «замыкание» — можно сколько угодно.
Но только не на «сеньорской» должности.
В контексте JS никогда не было норм без понимания замыкания.
habr.com/company/oleg-bunin/blog/424393/#comment_19174213Можете, пожалуйста, пояснить про проблемы?
0xd34df00d
Полнота по Тьюрингу не является чем-то заведомо хорошим. Например, полные по Тьюрингу системы типов имеют очевидные проблемы.
И привести пример полной по Тьюрингу системы типов (не очень себе представляю, что это по отношению к типам).
Предположим, я готов с вами согласиться именно в плане утверждения о сеньорской должности. Но для этого мне нужно услышать аргументацию, чего конкретно принципиально не может сделать senior developer, не зная этого термина.
Хотя, на самом деле, «замыкание» — это всего-навсего частный (пусть и иллюстративный) пример. А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
Хотя, на самом деле, «замыкание» — это всего-навсего частный (пусть и иллюстративный) пример. А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
Скажем так, даже если сеньор — узкоспециализированный специалист в языке, в котором замыкания, например, не имеют широкого применения, знать, что это за механика лучше, чем не знать.
Да и, собственно, как таковой сеньор, все же, должен знать хотя бы парочку языков, иметь опыт применения и некоторую экспертизу в сравнении. В конце концов, язык программирования — всего лишь инструмент. Мне, почему то, кажется, что сеньора, настоящего сеньора, отличает, в том числе, и умение выбрать наиболее подходящий под задачу инструмент.
Сеньор должен знать практики, паттерны, какие-то концепции за пределами устаканившихся в его экосистеме вещей, вероятно. Наработка практик в узкой специализации — это вопрос опыта, доступный миддлу. Мне кажется, что сеньор от миддла должен отличаться, например, знанием, в каких случаях от этих самых «лучших практик» можно отойти. Иначе чем он от миддла отличается?
В контексте беседы целиком обсуждается а) может ли C#-сеньор не знать о виртуальном наследовании, б) может ли JS-сеньор не знать о замыканиях. Ни то, ни другое, произвольными отдельными специфическими терминами в контексте обсуждения считаться не может. Ну вот никак.
Да и, собственно, как таковой сеньор, все же, должен знать хотя бы парочку языков, иметь опыт применения и некоторую экспертизу в сравнении. В конце концов, язык программирования — всего лишь инструмент. Мне, почему то, кажется, что сеньора, настоящего сеньора, отличает, в том числе, и умение выбрать наиболее подходящий под задачу инструмент.
Сеньор должен знать практики, паттерны, какие-то концепции за пределами устаканившихся в его экосистеме вещей, вероятно. Наработка практик в узкой специализации — это вопрос опыта, доступный миддлу. Мне кажется, что сеньор от миддла должен отличаться, например, знанием, в каких случаях от этих самых «лучших практик» можно отойти. Иначе чем он от миддла отличается?
А речь-то, вообще-то, о том, на сколько влияет на производительность senior developer-а незнание произвольных отдельных специфических терминов.
В контексте беседы целиком обсуждается а) может ли C#-сеньор не знать о виртуальном наследовании, б) может ли JS-сеньор не знать о замыканиях. Ни то, ни другое, произвольными отдельными специфическими терминами в контексте обсуждения считаться не может. Ну вот никак.
Но для этого мне нужно услышать аргументацию, чего конкретно принципиально не может сделать senior developerНе может быть senior developer.
произвольных отдельных специфических терминов.Раз за разом вы уводите в вообще другую степь.
производительность senior developerПроизводительность — единственное качество, необходимое для Senior Developer?
незнание произвольных отдельных специфических терминов.Вот тут самая главная ошибка. Не «незнание произвольных отдельных специфических терминов». А «незнание базовых концепций языка». Вот представьте, что C++ Senior Programmer забыл термин «Компиляция». Подумаешь, какой-то специфический термин. Или Java Senior Programmer забыл термин «Garbage Collector». Знание произвольных отдельных специфических терминов не нужно для senior-программиста!
Суть не в том, сможет ли сферический senior в вакууме, который не знает этих терминов выдавать результат такого же качества, как и программисты, которые знают эти термины.
Суть в том, что если на собеседование приходит человек, который утверждает, что он senior-программер, а на деле не слышал о основных концепциях его языка — возникает обоснованное сомнение в его чесности.
Ну под «забыл» имеется ввиду «забыл, что значит этот термин». Вот говоришь ему «компиляция», а он не может понять о чем ты
И таких определений в вашей голове — тысячи и десятки тысяч.
То есть у Senior C++ программиста при слове «компиляция» сразу вспоминается тысячи определений кроме того, что связано с его языком?
А Вы можете подробно рассказать как прошел ваш день ровно 5 лет и 4 месяца назад?
А вы можете сказать, кто был четвертой женщиной Александра Македонского? Хотите продолжить играть в игру «придумай глупую аналогию, которая не относится к теме»?
Дальше, Гипертимезия — вообще не в кассу, мы ведь не спрашиваем у человека, что он делал 5 лет назад. И Жамевю — тоже не в кассу. Даже дежавю встречает слишком редко (как много человек испытывают чувство дежавю именно на собеседовании? и я про настоящее дежавю, а не псевдодежавю похожих ситуаций, когда просто много собеседований сливается в одно). Так вот — Жамевю встречается еще значительно реже.
«На кончике языка» — тоже не в тему. Слово вспоминать не надо, его тебе называют. К примеру, «Компиляция». Вот и все «на кончике языка» уже не подходит.
Сколько вам нужно привести ссылок, чтоб донести простую мысль — иногда у людей из головы вылетает самое очевидное?
Ну, очевидно, больше нуля ссылок по теме. А то я тоже могу так накидать. Первая, вторая, третья. Видите, сколько я вам уже ссылок накидал, которые доказывают, что вы — неправы?
Хотя пару часов назад это определение от зубов само отскакивало
Та при чем здесь определение? Никогда никогда не требует книжного определения, не впадайте в крайности. Если у человека есть понимание, то он не забудет слово. Проблемы на экзаменах именно из-за зазубривания. Простите, но человек, который называется сеньйором я который не понимает, а зазубривает определения базовых терминов — не нужен команде
Чего уж говорить о том, что человек может знать, но редко использует ибо банально ему это конкретно было в явном виде не нужно (не про компиляцию, а про пример из статьи).
Для Senior JS Developer незнание понятия «Замыкание» недопустимо. По моему мнению, как и незнание понятия virtual для Senior C#-девелопера. Увы, я в этом языке далеко не senior, но я так считаю.
Вы же сейчас приведете пример успешного математика, не знающего, что такое умножение?
Забавно, что два человека одинаково поленились понять мою аргументацию и выдвинули одинаково абсурдные контр-аргументы. Ответил выше.
Надёжно помнят это не те, кто зазубривает, а те, кто это всё своими руками прощупал, осознал, проанализировал, покрутил в разных вариантах и в мозг положил в рабочий арсенал. То есть хорошие программисты. Вопрос в том, действительно ли на ту позицию был нужен такой вот хороший программист, или достаточно было бы обычного.
Надёжно помнят это не те, кто зазубривает, а те, кто это всё своими руками прощупал, осознал, проанализировал, покрутил в разных вариантах и в мозг положил в рабочий арсенал. То есть хорошие программисты.
Хороший программист — это в первую очередь тот, кто все это благополучно забудет, если не использовал сколько-нибудь продолжительное время. Допустим, замыкания в принципе — они теперь везде, тут забыть сложно, но к чему помнить особенности того, как в js работает this в замыканиях, если уже год на js не пишешь? Да ни к чему, это не знания — это мусор. А мусор надо убирать.
На мой взгляд это ошибочное утверждение, вы можете понять как работает, но не связать название с механизмом.
Понимаете ли какое дело, к программисту нельзя предъявлять таких же требований как скажем к слесарю. Ибо у него область компетенции порой просто необъятна. Взять последний мой проект. Железка — на верилоге. Тесты — на яве. Клиентская библиотека — на С++. Морда лица всего этого безобразия — джаваскрипт в броузере. Плюс схематика и разводка для железке делалась в eagle. И этот проект ещё далеко не самый сложный, на пару месяцев! И программёр я далеко не уникальный, так, крепкий сеньёр, не более. И всё перечисленное мне пришлось «пощупать руками» в ходе одного проекта… Не мудрено, что если меня будут спрашивать о каких-то пыльных углах какого-то из этих инструментов, я поплыву как нерадивый студент. Но если мне надо будет в этом разобраться, сделаю это очень быстро. Самый умный начальник, которого я в жизни знал, любил говорить так (за точность цитаты не ручаюсь, ибо было это 18 лет назад, но смысл сохранен) — «Мне не нужны те кто всё знает, ибо всё знать невозможно. Мне нужен тот, который ничего не знает, но дай ему задачу, через неделю принесёт пусть грубое, но решение».
Как бы вы выбирали, какого кандидата принять на работу если надо закрыть вакансию?
А так бы и выбирал, как мой самый умный начальник, респектище и уважуха ему во веки веков, аминь. Дал бы совершенно практическую задачку. Связанную с будущей работой, хотя и элементарную. И поглядел бы как чел справится. Впрочем есть вариант. Дать в качестве задачки полную херню и ахению, однако требующую серьёзной разработки своего собственного алгоритма. Поскольку задачка полная херня и ахения, в тырнетах чел решения явно не найдёт. Тем интересней будет ЧТО он придумает… Один раз мне такое попадалось. Во избежание косвенной рекламы, опущу подробности.
что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта
Нет, она называется уравнением Пауссона. Закон Бойля-Мариотта описывает изобарный процесс. Пара минут Гугла;)
Проблема в том, что много вещей невозможно «подсмотреть» если не знать как они хоть приблизительно называются.
Так вот термин — это факт, который ни с чем не связан, это просто название, которое нельзя «вывести», его можно только запомнить. Это не «сколько будет 2×2», а то, что формула, описывающая термодинамический процесс без обмена теплом со средой, называется законом Бойля-Мариотта.
Вот тут стоит признать, что вопрос был «что такое <термин>», а не «каким термином называется вот это». И вот тут ситуация начинает играть другими красками. Не «как называется формула, описывающая термодинамический процесс и т.д.», а «в чем суть закона Бойля-Мариотта». Разные несколько вопросы, не правда ли?
а «в чем суть закона Бойля-Мариотта». Разные несколько вопросы, не правда ли?
Да одно и то же, можно прекрасно помнить закон и уметь его применять, но при этом в упор не помнить, что он Бойля-Мариотта. Любой человек, который матфак окончил, знает на подкорке кучу всяких лемм/теорем из первого курса матана, на уровне формулировки фактов и даже доказательства вам накидает. Но сомневаюсь, что вспомнит хотя бы для половины названия, или саму формулировку по названию. Вот если вы скажите о чем там в общем, другое дело.
Плюсануть, к сожалению, не могу, но у вас один из самых толковых комментариев! Я учился дважды, но последний раз это было уже почти 12 лет назад, а первый 21. Я программирую с 1992 года. Многие определения я помню еще, но далеко не все. Можно еще в С++ спрашивать с какой версии в лямбдах происходит захват *this? Или с какого билда VS 2017 intellisense будет корректно отображать Structured bindings. Но это нужно только для ЧСВ. Кому надо это быстро нагуглят. Скажу честно, но меня ни разу не собеседовали по терминам или алгоритмам, и я, кстати, тоже! Какие-то определения можно спрашивать вчерашнего студента, у которого может не быть портфолио, но не сеньера…
Как говорил мой препод 25 лет назад — зачем мне помнить определения/константы, если у меня есть справочник, в котором это всё написано? Мне надо знать КАК это работает.
А так же это очень хорошая отмазка на любое незнание.
Поди со стороны разгляди.
Поди со стороны разгляди.
Есть только один способ выяснить что человек знает в какой-то области — заставить его сделать нужное. Дайте человеку тестовую задачу и посмотрите как он её решит. А потом ещё есть и испытательный срок. Я видел дофига людей точно оперирующих определениями (выучили, благо список вопросов и ответов в интернете на любой вкус), но нихрена не понимающих о чём вообще они говорят.
Когда я ещё учился в школе в 10 классе, мы писали «контрольные» работы, которые засчитывались в определённом ВУЗе (договор был). В одной из задач по физике я забыл значание константы Больцмана. Я «решил» задачу и в качестве ответа вписал формулу, в которой фигурировала эта константа. И дописал «ответ не получен, так как преподаватель отказался сообщить значение константы».
На разборе эту задачу мне засчитали как полностью решённую, потому что знать наизусть все константы — это не цель этих контрольных. Главное — умение решать задачи. А если подставить верное значение константы, то и ответ становился верным.
Мораль: да, надо смотреть со стороны. Если «не знание» — это повод что-то не делать, то это — плохо. В противном случеае, «не знание» чего-то очень *конкретного* не означанет не знание предмета/задачи.
На разборе эту задачу мне засчитали как полностью решённую, потому что знать наизусть все константы — это не цель этих контрольных. Главное — умение решать задачи. А если подставить верное значение константы, то и ответ становился верным.
Мораль: да, надо смотреть со стороны. Если «не знание» — это повод что-то не делать, то это — плохо. В противном случеае, «не знание» чего-то очень *конкретного* не означанет не знание предмета/задачи.
Эйнштейн как-то сказал что он намеренно забыл скорость звука тк может найти её в любом справочнике.
Среди программистов чаще встречается «я не теоретик, я практик, мне все равно как оно называется, уж я-то все сделаю как надо». И это очень тревожный звоночек со стороны нанимателя. Нет, конечно сделает. Кто же спорит. Вот только хотелось бы поменьше костылей в проекте, больше общеиспользуемых решений и поменьше костылей…
От балды легче… ибо тензорный анализ напрягает умы упругих программистов.
Он может и забыть сколько будет 71x34. А третьекласник, владеющих искусством быстрого счёта его обгонит.
Нормальный вопрос. Ну не может сеньор не знать что такое замыкание или virtual. И не важно какой религии он придерживается, такие вещи просто невозможно не знать. Если не сеньор, то кто же тогда?
Ну не может сеньор не знатьЭта фраза выглядит вполне правдивой в её тяжкой непреклонности, если бы не одно но. Что значит "не знать"?
В моём понимании не знать чего-то, например не знать как, допустим, варить железо, это если человека оставить одного в комнате со сварочным аппаратом и заготовкой, хоть через час хоть через день он не сможет её сварить, хоть убей. А если и сможет, то очень криво и непрочно. Проще говоря: не справится с задачей. Он не готов к трудоустройству на должность
А если автора оставить одного с чужим кодом в котором есть ключевое слово virtual и попросить код модифицировать согласно таске, он справится или нет? Я думаю ему и дня не понадобится, да что там, и часа. Даже если он запамятовал, 20-гуглинг с чтением коммента на стэковерфлоу заставит его хлопнуть по лбу «ах да, я же встречался с этим» и приступить к решению задачи. Думаю 20 секунд рабочего времени для начальника этого разработчика не такая уж большая цена за незнание?
Так ли сурово можно продолжать считать такого разработчика непригодным к работе сеньор сварщика кода?
Ну, мне вот кажется, что с virtual вы немного лукавите.
Если разработчик не вспомнил сам вполне себе базовую механику языка, вероятно, он именно «встречался» с этим, и уж точно не использует эту механику на регулярной основе. А это, при наличии уже существующего, вероятно, достаточно большого проекта, где виртуальное наследование во все поля применяется, кхм… ну, чревато, как бы. Вопрос именно что не в том, знаете ли вы этот термин, а в том, что, имей вы практику применения (а она реально важнее знания терминологии), вы бы вряд ли забыли, что означает вполне себе конкретное ключевое слово в языке.
В общем и целом, ваше «а вот virtual я не помню» говорит, с очень большой долей вероятности, о том, что лично вы его не применяете. С учетом специфики существующего кода вместо сеньор-разработчика, который будет выполнять поставленные задачи, вполне можно получить саботера, который будет вместо работы убеждать джунов/миддлов в том, что «виртуальное наследование — зло», и «за композицией будущее». Ну, либо человека с сеньорской зарплатой и отдачей на уровне миддла…
Даже если он запамятовал, 20-гуглинг с чтением коммента на стэковерфлоу заставит его хлопнуть по лбу «ах да, я же встречался с этим» и приступить к решению задачи.
Если разработчик не вспомнил сам вполне себе базовую механику языка, вероятно, он именно «встречался» с этим, и уж точно не использует эту механику на регулярной основе. А это, при наличии уже существующего, вероятно, достаточно большого проекта, где виртуальное наследование во все поля применяется, кхм… ну, чревато, как бы. Вопрос именно что не в том, знаете ли вы этот термин, а в том, что, имей вы практику применения (а она реально важнее знания терминологии), вы бы вряд ли забыли, что означает вполне себе конкретное ключевое слово в языке.
В общем и целом, ваше «а вот virtual я не помню» говорит, с очень большой долей вероятности, о том, что лично вы его не применяете. С учетом специфики существующего кода вместо сеньор-разработчика, который будет выполнять поставленные задачи, вполне можно получить саботера, который будет вместо работы убеждать джунов/миддлов в том, что «виртуальное наследование — зло», и «за композицией будущее». Ну, либо человека с сеньорской зарплатой и отдачей на уровне миддла…
Вот вы тут поучаете, а что такое «виртуальное наследование»? В С++ это особое наследование, со своей семантикой. И гуглить нужно в направлениие «Multiple inheritance» & «diamond of death»
В своей жизни сталкивался всего несколько раз: один раз это было в году 96-98, тогда писали на Borland С++ и там была заморочка с наследованием от TObject, еще раз относительно недавно, когда делал code review для проекта, и это было меньшее из зол при уходе от void* на все что можно. Было еще пару раз, но уже и не вспомню. А вообще я не фанат виртуального наследования.
Дорогой мой человек, вот и я же ровно о том же! Если человек, собеседующийся на позицию сеньора на С++, он должен знать, что такое «виртуальное наследование». Это базовая вещь языка, часть спецификации. И «я слово забыл» — хреновая отмазка. Вы вот прямо говорите «В С++ это особое наследование, со своей семантикой». Вот если вас при собеседовании на позицию сеньора спросят, как называется «особое наследование, со своей семантикой в С++», а вы сходу не вспомните слово «виртуальное» — это нормально, это просто слово подзабыл, вы красавец, а тот, кто собеседует — клинический кретин. Однако когда вас (опять же, помним, что вы на сеньора собеседуетесь) просят объяснить на пальцах, что такое виртуальное наследование, а вы «забыли формулировку» — брать вас на работу не стоит.
Вы же, предположительно, еще и в команде работать будете. Сеньоров, обычно, в вакуум не берут. Вам же еще и коммуникативные навыки понадобятся. Да и предполагается, что рядом могут сидеть миддлы или, простихоспади, джуны, которые за советом, в случае чего, пойдут, вероятно, к сеньору. Так ведь? Придет вот эдакий джун к вам-сеньору, и скажет, я тут виртуальное наследование намутил, а что-то не работает, помоги разобраться. А ты сидишь, эдакий сеньор-помидор, и ни слова не понимаешь в том, что тебе джун говорит, у тебя там своя личная устоявшаяся терминология. Ну и нафига ты такой красивый нужен?
Вы же, предположительно, еще и в команде работать будете. Сеньоров, обычно, в вакуум не берут. Вам же еще и коммуникативные навыки понадобятся. Да и предполагается, что рядом могут сидеть миддлы или, простихоспади, джуны, которые за советом, в случае чего, пойдут, вероятно, к сеньору. Так ведь? Придет вот эдакий джун к вам-сеньору, и скажет, я тут виртуальное наследование намутил, а что-то не работает, помоги разобраться. А ты сидишь, эдакий сеньор-
Может я не совсем понял о чем речь… Для меня определение — это то что написано в «книжке». А вот если человек претендует на сеньера С++ и не знает таких вещей (хотя бы своими словами), то это не очень хорошо. Может мне по жизни везло, но мне не очень часто приходилось отвечать на вопросы: что такое класс. Или чем класс отличается от объекта. Восновном, если и был разговор по языку, то какие-то редко используемые вещи, ну или что-то не совсем очевидное. Если бы меня спросили такие вопросы, то я бы ответил, но в такой фирме работать не стал…
Собственно, и я говорю о том, что человек, претендующий на позицию сеньора в C++ не может не ответить на вопрос, что такое «virtual». И нет никакой приемлемой отмазки, почему он на собеседовании не смог своими словами дать описание этой механики. Собственно, для джуна еще как-то может «прокатить», но даже для миддла не объяснить смысл этой механики на собеседовании — признак того, что и на «крепкого миддла» точно не тянет.
А в цепочке обсуждения до поста, да и в исходной публикации описана ситуация, когда весь такой крутой «сеньор» ответил на «стопицот» коварных вопросов хамоватого собеседователя, а на вопрос «что такое virtual» ответить не смог, т.к. он «позабыл слово» и «вообще наследование зло, а в компании ничего не понимают». В итоге, типа, «крутого профессионала» отсеяли на собеседовании просто потому, что он «подзабыл слово».
Ну ведь чушь же. Человек просто сам завалил собес, перевернул с ног на голову, и теперь пришел пожаловаться на «некомпетентность собеседующего».
А в цепочке обсуждения до поста, да и в исходной публикации описана ситуация, когда весь такой крутой «сеньор» ответил на «стопицот» коварных вопросов хамоватого собеседователя, а на вопрос «что такое virtual» ответить не смог, т.к. он «позабыл слово» и «вообще наследование зло, а в компании ничего не понимают». В итоге, типа, «крутого профессионала» отсеяли на собеседовании просто потому, что он «подзабыл слово».
Ну ведь чушь же. Человек просто сам завалил собес, перевернул с ног на голову, и теперь пришел пожаловаться на «некомпетентность собеседующего».
но даже для миддла не объяснить смысл этой механики на собеседовании
Ну не об этом же разговор. Разговор о том, что человек не связал слово "виртуал" с известной ему механикой.
Чтобы "не объяснить смысл механики" надо чтобы обе стороны поняли, про какую именно механику задан вопрос.
Погодите-погодите.
Прямо из статьи:
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Вы искренне считаете, что на собеседовании по C# есть место двум разным пониманиям базового синтаксиса одного и того же языка? Т.е. собеседующий подразумевает, мол virtual void methodName(), а собеседующийся настолько заметался в выборе возможных для контекста беседы толкованиях virtual, что аж ни одного сформулировать не смог?
Прямо из статьи:
Senior full-stack .NET Developer
Что такое virtual?
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
надо чтобы обе стороны поняли, про какую именно механику задан вопрос
Вы искренне считаете, что на собеседовании по C# есть место двум разным пониманиям базового синтаксиса одного и того же языка? Т.е. собеседующий подразумевает, мол virtual void methodName(), а собеседующийся настолько заметался в выборе возможных для контекста беседы толкованиях virtual, что аж ни одного сформулировать не смог?
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Гражданин упирает на то, что не использует наследование.
Гражданин, претендующий на позицию сеньора в ООП-языке имеет право не использовать наследование, да. Но право указанного гражданина не знать/не помнить, что это такое — позвольте поставить под сомнение.
Он же, вроде, по специфике «сеньорства» не только писать код должен, но еще и читать. При этом не только свой — на то он и сеньор. А ключевые слова языка для него — алфавит. Вы же не станере брать ликтором человека, который «отлично весь алфавит помнит, а вот букву Ы подзабыл, но она не нужна, он все равно ее не использует».
Он же, вроде, по специфике «сеньорства» не только писать код должен, но еще и читать. При этом не только свой — на то он и сеньор. А ключевые слова языка для него — алфавит. Вы же не станере брать ликтором человека, который «отлично весь алфавит помнит, а вот букву Ы подзабыл, но она не нужна, он все равно ее не использует».
Я с вами полностью согласен. Просто уточнил.
Гражданин, претендующий на позицию сеньора в ООП-языке имеет право не использовать наследование, да.
Погодите, погодите! А интерфейсы он тоже не использует? Ведь вызов реализованного метода интерфейса — он тоже виртуальный.
Но слово virtual же не пишется в таком случае? :-)
А при чем тут наследование?
Вот кстати мне лично интересно как вопрос задан был. Например спросили про «ключевое слово виртуал», или просто виртуал или же виртуал?
Тут стоить отметить что хоть и не по моей это специальности, но в первых двух вариантах я бы скорее всего правильно связал понятие со смыслом, а вот в последнем была бы вероятность что затупил бы.
Тут стоить отметить что хоть и не по моей это специальности, но в первых двух вариантах я бы скорее всего правильно связал понятие со смыслом, а вот в последнем была бы вероятность что затупил бы.
Т.е. я правильно понял, что человек, собеседующийся на позицию senior с C#, каким-то образом не связал ключевое слово языка «virtual» с «известной ему механикой»?
Не совсем. Человек в нестандартной ситуации, когда внимание отвлекается различными психологическими и информационными факторами, за отведенные ему несколько секунд не связал слово, произнесенное вслух звуками "виртуал", с известной ему механикой, которой он редко пользуется. Не успел выбрать из всего набора существующих в C# механик ассоциацию с переопределением метода. То, что он знаком с наследованием, следует из правильного ответа на вопрос "что такое protected internal".
Такими вопросами можно проверить только быстроту ассоциаций. Чтобы проверить умение пользоваться, надо дать задачу или попросить привести пример. Если на вопрос "Приведите пример переопределения метода в наследнике" человек напишет код со словом "virtual", значит он знает, зачем оно нужно, даже если его нет в вопросе.
Если на вопрос «Приведите пример переопределения метода в наследнике» человек напишет код со словом «virtual», значит он знает, зачем оно нужно, даже если его нет в вопросе.
Возьмём для примера C++. А если он переопределит метод без слова virtual, будет ли это значить, что он его не знает/не умеет использовать?
Зачем брать C++, если разговор про C#, и пример будет на нем? Давайте тогда PHP возьмем, там на virtual вообще ошибка синтаксиса будет.
Я C++ взял, так как думаю, что больше людей его понимают.
Хорошо, пусть будет C#. Вам это уйти от вопроса всё равно не позволит.
Сам вопрос:
А если он переопределит метод без слов virtual/override, будет ли это значить, что он их не знает/не умеет использовать?
Хорошо, пусть будет C#. Вам это уйти от вопроса всё равно не позволит.
Сам вопрос:
А если он переопределит метод без слов virtual/override, будет ли это значить, что он их не знает/не умеет использовать?
Насколько я знаю, в C# нельзя переопределить метод в наследнике, если в родителе он не объявлен как virtual.
Я, конечно, извиняюсь, но Вас бы на должность C# сениора (да что там, даже мидла), я бы не взял :(
А я и не позиционирую себя как C# разработчик, даже как джуниор.
Извиняться не надо, надо приводить аргументы. Но если вы имеете в виду такую программу:
class A {
public int f() { return 1; }
}
class B: A {
public int f() { return 2; }
}то она выдает предупреждение
warning CS0108: "B.f()" скрывает наследуемый член "A.f()"
и работает не так, как с переопределением.
Извиняться не надо, надо приводить аргументы.
Аргумент то простой: вы не знаете, что функцию можно переопределить в наследнике и без virtual. И про ключевое слово new тоже даже не слышали, раз уж вопрос про предупреждение встал.
и работает не так, как с переопределением.
Для вас переопределение — это обязательно когда virtual? Если так, то я бы тогда вас и на вакансию C++-программиста тоже бы не взял :(
А я бы не взял вас. Потому что переопределение и сокрытие методов — это два сильно разных механизма и смешивать их нельзя ну вот совсем никак.
А вот это уже вопрос терминологии пошёл. В оригинале да, термины extend и hide. Но в русском переопределить не часто говорят в смысле extend. Чаще и в том и в другом, особенно в плюсах. Кстати, русскоязычный MSDN переводит их как разворачивание и скрытие.
В C# метод в производном классе может иметь то же имя, что и метод в базовом классе. Можно задать способ взаимодействия методов, воспользовавшись ключевыми словами new и override. Модификатор override разворачивает метод базового класса, а модификатор new скрывает его. В примере в этой теме показана эта разница.
Русскоязычный MSDN — та еще помойка с машинным переводом.
Однако в конкретно указанном случае virtual/override и new — действительно разные механизмы.
Кстати, конкретно в этой статье, откуда я привёл цитату нет обычной пометки, что это машинный перевод. Да и сам текст высокого качества, что указывает на ручной человеческий перевод. Так что всё дело в привычке скорее всего.
Процитированный вами фрагмент я бы не понял если бы не знал о чем он и не видел перевода на английский.
Что значит «разворачивание» метода? Он как бы в базовом классе был свернут, а в производном его развернули? А можно ли метод развернуть два раза? Должен ли он быть для этого дважды свернут?
Что значит «разворачивание» метода? Он как бы в базовом классе был свернут, а в производном его развернули? А можно ли метод развернуть два раза? Должен ли он быть для этого дважды свернут?
Можно ведь открыть студию и убедиться, что поведение принципиально разное, а не показывать всем свою необразованность? А потом пойти и почитать почему оно разное.
Я вот на всякий случай сходил и проверил — gist.github.com/retran/9f4dc4c359d8e91d163e2452a642863c
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Я вот на всякий случай сходил и проверил — gist.github.com/retran/9f4dc4c359d8e91d163e2452a642863c
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Я и без вас уже N лет знаю, что поведение разное. Зачем вы мне это говорите? Что вы хотите этим показать.
Если вы ещё до сих пор не поняли, что произошла терминологическая путаница, то извиняюсь, но вы глупы :(
Ещё раз я знаю и использую и new и virtual/override. И да, я не считаю это переопределением, я считаю это extends (а кто догадался вообще extends перевести как переопределить?).
Если вы ещё до сих пор не поняли, что произошла терминологическая путаница, то извиняюсь, но вы глупы :(
Если вы так пишете код и считаете это переопределением — вас вообще на работу брать нельзя.
Ещё раз я знаю и использую и new и virtual/override. И да, я не считаю это переопределением, я считаю это extends (а кто догадался вообще extends перевести как переопределить?).
А можно источники вашей терминологии посмотреть?
Я, конечно, глупее вас, и первый раз слышу, чтобы extends употреблялось по отношению к методам в контексте наследования (и не extension method'ам, которые вообще про другое), а не классам.
UPD Я вот сейчас погуглил, нашел такую формулировку только в одной единственной статье про C# в MSDN.
Я, конечно, глупее вас, и первый раз слышу, чтобы extends употреблялось по отношению к методам в контексте наследования (и не extension method'ам, которые вообще про другое), а не классам.
UPD Я вот сейчас погуглил, нашел такую формулировку только в одной единственной статье про C# в MSDN.
Если вас интересует именно моя терминология, то я называю это «замещать» от override, как мы всегда называем это в плюсах и «скрывать» от hide (ну и «переопределить» (переопределить с замещением, переопределить со скрытием) применительно к обоим). Вроде как это общепринятые обозначения, других и не слышал никогда (если не считать «оверрайдит»). Если вам прямо нужен источник-источник, вот только что в другом комментарии отвечал, что так (override/замещает) написано в канонах C++ (C++ Programming language), пусть тогда это и будет источником.
Если вас интересует официальная терминология по C#, то она из шарповой документации, вы же сами ссылку на неё приводили. Откуда они придумали extends/расширяет и почему не взяли override/замещает — это к ним вопрос.
Если вас интересует официальная терминология по C#, то она из шарповой документации, вы же сами ссылку на неё приводили. Откуда они придумали extends/расширяет и почему не взяли override/замещает — это к ним вопрос.
Господа, чтобы не замусоривать далее топик, я извиняюсь, что хотел «подколоть» уважаемого michael_vostrikov на тему того, что мне (будем считать что) показалось, что он не знает про hides. К сожалению, будем считать, что из-за терминологической путаницы, мы друг друга просто не поняли. И предлагаю дальше эту тему не развивать.
Собственно, new, вроде как, про перекрытие метода, а не про переопределение. Поведение будет разное. И, собственно, эти нюансы сеньор должен знать. Т.е. без знания того, что такое virtual/override, new (в контексте метода) и в чем разница на должность сеньора претендовать нельзя.
Давайте, что бы не было путаницы, скажем так:
Собственно, new, вроде как, про hide метода, а не про extend. ...
И полностью с вами соглашусь.
Так как первый раз в живую слышу, что кто-то вместо замещения метода(в С++) и расширения метода (в C#) говорил об этом как общее «переопределение». Уж, со сколькими людьми общался, и за пределами рабочего коллектива (за последние 2 месяца почти 40 людей только на интервью посмотрел), все как и обычное «скрытие», да и виртуальное замещение в плюсах называют просто «переопределил». А тут на тебе…
Собственно, new, вроде как, про hide метода, а не про extend. ...
И полностью с вами соглашусь.
Так как первый раз в живую слышу, что кто-то вместо замещения метода(в С++) и расширения метода (в C#) говорил об этом как общее «переопределение». Уж, со сколькими людьми общался, и за пределами рабочего коллектива (за последние 2 месяца почти 40 людей только на интервью посмотрел), все как и обычное «скрытие», да и виртуальное замещение в плюсах называют просто «переопределил». А тут на тебе…
Ну, собственно, тут мы до «нюансов принятой в экосистеме терминологии» дошли уже. Тем более не вижу смысла спорить о формулировках, т.к. ни синьором, ни даже миддлом в C# не являюсь.
Просто я про то говорю, что раз уж даже мне, человеку весьма постороннему, навскидку видна разница между virtual/override и new, может ли человек, претендующий на «сеньорство» в области «забыть» или «затрудниться ответить». Вот и мне кажется, что нет.
Просто я про то говорю, что раз уж даже мне, человеку весьма постороннему, навскидку видна разница между virtual/override и new, может ли человек, претендующий на «сеньорство» в области «забыть» или «затрудниться ответить». Вот и мне кажется, что нет.
Собственно, new, вроде как, про перекрытие метода, а не про переопределение.
Помню, как запутался в коде cms, в управлении плагинами. Методы были определены под именами: renew, refresh, reload, update… Там даже синьоры путались )
Аргумент то простой: вы не знаете, что функцию можно переопределить в наследнике и без virtual.
Это не аргумент, а необоснованное утверждение. Аргументом был бы приведенный вами пример такого переопределения.
Я знаю, что понятие "переопределение" в языке C# имеет вполне конкретное значение и задает вполне конкретное поведение кода, касающегося реализаций в родителе и в наследнике, и это поведение отличается от скрытия. Вы не сможете добиться, чтобы код без virtual во всех случаях работал точно так же, как с virtual.
Здесь описаны отличия, прочитайте и обратите внимание на примеры:
Knowing When to Use Override and New Keywords
Отличия переопределения метода от перекрытия
В следующий раз, прежде чем переходить на личности, потрудитесь изучить обсуждаемый вопрос. Если PHP-шник знает о C# больше вас, это повод подтянуть свои знания.
Вы не сможете добиться, чтобы код без virtual во всех случаях работал точно так же, как с virtual.
В том и вопрос, что вы должны знать, чем поведение «кода без virtual» от поведения «кода с virtual» отличается. Иначе какой вы сеньор?
Ну а я знаю, что «Я знаю, что понятие extends (а кто догадался вообще extends перевести как переопределить?) в языке C# имеет вполне конкретное значение и задает вполне конкретное поведение кода, касающегося реализаций в родителе и в наследнике, и это поведение отличается от скрытия (или перекрытия, как qrKot это называет?) hides.»
А приводить ссылку на статью, из которой я уже приводил цитату — это очень оригинально.
Ну как бы я пока не вижу, чтобы вы знали, что-то больше меня. Вижу, что мы говорили об одном и том же разными русскими терминами. Что для меня «переопределена» это когда функция просто переопределена (без разницы с замещением или со скрытием), а для вас этот же термин значит только тот случай, когда она замещена (от override).
И почему вообще повод? Я себя в шарпах даже джуном не считаю, я всё-таки плюсовик :) Когда есть время и возможность я и без повода что-нибудь на шарпах изучаю.
А приводить ссылку на статью, из которой я уже приводил цитату — это очень оригинально.
В следующий раз, прежде чем переходить на личности, потрудитесь изучить обсуждаемый вопрос. Если PHP-шник знает о C# больше вас, это повод подтянуть свои знания.
Ну как бы я пока не вижу, чтобы вы знали, что-то больше меня. Вижу, что мы говорили об одном и том же разными русскими терминами. Что для меня «переопределена» это когда функция просто переопределена (без разницы с замещением или со скрытием), а для вас этот же термин значит только тот случай, когда она замещена (от override).
И почему вообще повод? Я себя в шарпах даже джуном не считаю, я всё-таки плюсовик :) Когда есть время и возможность я и без повода что-нибудь на шарпах изучаю.
Перекрыть, вроде, можно.
public new void MethodName() {}
Собственно, про то, видимо, и вопрос был, чем переопределение виртуального метода от перекрытия в наследнике отличается.
public new void MethodName() {}
Собственно, про то, видимо, и вопрос был, чем переопределение виртуального метода от перекрытия в наследнике отличается.
То, что он знаком с наследованием, следует из правильного ответа на вопрос «что такое protected internal».
А знание модификаторов доступа к членам класса, простите, каким образом свидетельствует о том, что человек знаком с понятием «наследование»?
Доступ к защищенному элементу может быть получен из соответствующего класса, а также экземплярами производных классов.
Из этого определения следует, что человек наслышан о понятии «наследование». Мы же предполагаем, что человек уровня сеньора сможет не только сказать «наследование — зло», но и обосновать свою позицию, объяснить почему он так считает. А тут получается, что познания человека о наследовании заканчиваются на моменте «я слышал, что есть такая штука, но где-то в интернете читал, что так делать нехорошо». Странная позиция для соискателя на вакансию сеньора, вы не находите?
каким образом свидетельствует о том, что человек знаком с понятием «наследование»?
Из этого определения следует, что человек наслышан о понятии «наследование»
Наслышан — По слухам хорошо знаком с кем-чем-нибудь
Давайте не будем играть словами. protected связан с наследованием, это факт. Тем более что мы не знаем, насколько развернутым был ответ автора.
объяснить почему он так считает
А ему кто-то такой вопрос задавал? Автор сам пишет, что считает его более важным.
В том и дело, что такие вопросы как в статье на самом деле не показывают умение пользоваться.
Тем более что мы не знаем, насколько развернутым был ответ автора.
В том то и дело, что мы не знаем, насколько развернутым был ответ автора, можем только предполагать, что он что-то связное ответил (и где гарантия, что он не ответил заученной формулировкой с MSDN).
Что мы знаем (со слов самого автора), это то, что он «посыпался» на вопросе «Что такое virtual».
Т.е. в сухом остатке автор не смог ответить на вопрос, что такое virtual, в чем сам и признается. А это — неиллюзорный повод предположить, что в вопросе наследования автор плавает, что автоматически делает его слабым кандидатом на сеньорскую позицию.
Для того чтобы за 20 секунд понять что означает ключевое слово virtual, надо знать как работает динамический полиморфизм. Понимать чем отличается статический тип переменной и класс объекта на который она ссылается.
И да, существуют программисты которые этого не знают и не понимают.
И да, существуют программисты которые этого не знают и не понимают.
А когда на senior-позицию приходят полные нули, что делать? Знакомый фронтендер периодически собеседует людей на позицию senior-ов. Люди говорят/пишут, что у них 3-5-10 лет опыта, но они не знают концепции замыканий.
ИМХО, это очень хороший вопрос, чтобы быстро отсеять всяких неадекватов, при условии, что он задаётся не HR, и не ради самоутверждения.
К тому же, это ещё и хороший вопрос для отсеивания неадекватных работодателей: если после моего ответа начинают просить что-то там реализовать на бумажке, то начинаю задумываться, а надо ли мне тут работать.
Ну, к слову, нужно уточнять про какие технологии речь идет. Например в нашем отделе (1с, многие код пишут уже по 5 лет, и по меркам 1с неплохой код и действительно крупные проекты) — когда я коллегам в чатик скинул свой краткий обзор плюшек дарта и флаттера — единственная реакция которой я добился (хотел заинтересовать, может кто со мной бы начал дома на них что то изучать и пилить) — это: что ты там написал? Что за замыкания? Что за вывод типов? Все. При этом, как я уже выше писал, в своей сфере мы считаемся пусть не топовой компанией, но не хухры-мухры.
Безусловно, когда человек занимался чем-то совсем другим, а потом меняет сферу деятельности, незнание некоторых вещей можно простить. Например, сейчас многие переходят во фронт из бэка (по крайней мере, часто собеседовал таких людей). В таком случае можно забить на неумение верстать, или незнание, например, особенностей работы промисов. Я в таких случаях просто задаю другие вопросы. В конце концов, есть есть фундамент, особенностям js обучаешься быстро.
Но когда люди вроде как много лет именно во фронтенде (и заявляют об этом чуть ли не с гордостью), и у них спрашиваешь про банальные замыкания, а они не могут ответить, то это печально.
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
На счет промисов — тут есть конечно нюансы, ввиду синхронности js, но мое отношение к промисам также негативное (работу кончено не пойдет искать, но прослушает двухчасовую беседу о том, как разбивать задачи на минимальные составляющие для обеспечения стабильности и прозрачности работы кода).
Но саму возможность использования промисов, в каких-то непонятных, внеземных проектах, я конечно не отрицаю. Как по мне, промисы в js придумал какой-то редкий м....., который ранее работал в глубоком бэкенде, на c++, с функциями асинхронного вызова и обработки данных без потоков, через медиаторы, в самих кодах классов.
Сидел он значит, изучал фронтенд (новое для себя дело) и встал в ступор — а почему нельзя в js через те же медиаторы и обертки событий, как было в классах на c++, обойти синхронность языка? Давай-ка я напишу это, чтобы и здесь реализовать мнимо-неблокируемый интерфейс, и назову всё это дело промисом!
А нужно-ли это во фронте?, или это создаст для работы кода еще больше проблем? — эт. дело десятое, главное мы из JS теперь сделаем крутой язык, приближающийся к бэку!
На счет промисов — тут есть конечно нюансы, ввиду синхронности js, но мое отношение к промисам также негативное (работу кончено не пойдет искать, но прослушает двухчасовую беседу о том, как разбивать задачи на минимальные составляющие для обеспечения стабильности и прозрачности работы кода).
Но саму возможность использования промисов, в каких-то непонятных, внеземных проектах, я конечно не отрицаю. Как по мне, промисы в js придумал какой-то редкий м....., который ранее работал в глубоком бэкенде, на c++, с функциями асинхронного вызова и обработки данных без потоков, через медиаторы, в самих кодах классов.
Сидел он значит, изучал фронтенд (новое для себя дело) и встал в ступор — а почему нельзя в js через те же медиаторы и обертки событий, как было в классах на c++, обойти синхронность языка? Давай-ка я напишу это, чтобы и здесь реализовать мнимо-неблокируемый интерфейс, и назову всё это дело промисом!
А нужно-ли это во фронте?, или это создаст для работы кода еще больше проблем? — эт. дело десятое, главное мы из JS теперь сделаем крутой язык, приближающийся к бэку!
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
Т.е. в Вашем проекте на js нельзя писать на js? В нем же все функции образуют замыкания.
Просто когда все живут в 2018, этот человек живет в 1999, где он крутой программист, знающий что замыкания кушают память в нетскейп навигаторе.
В прошлом? В ПРОШЛОМ? ааа, жесть! Вы вообще хотя бы слегка представляете себе, как работает стек вызова всего вашего «будущего»? Какие системные функции затрагиваются при вызове ваших технологий? Какие проверки и со стороны каких процессов идут во фронтэнде? Всё это ваше «будущее», это устаревшая технология бэкэнда (80-ые по-моему годы, ну может девяностые – 5-я, или 6-я студия короче от майкрософта). Именно тогда бэкэнд языки были еще такими ущербными и там также приходилось применять обертки событий (EventLoop как тут кто-то в комментах писал, думая, что это круто — товарищ, это не круто, это смерть твоему проекту в продакте, если ты нагрузишь стек событиями и будешь ждать их окончания, не контролируя саму среду в которой выполняется твой код [браузер в данном случае]).
Теперь же бэкэнд вырос и избавился от этой шняги и такие вот горе-профи (аааа жесть просто) теперь пытаются впихнуть это старье во фронт энд, и всё по той же причине, чтобы также как и тогда в бэкэнде, обойти ограничения синхронности языка.
Но вот беда, работа кода в бэкэнде и работа его во фронтэнде, подчиняются абсолютно разным правилам и проходят очень-очень разные этапы проверок и допусков. И понятное дело, что обмен данными между мнимо-асинхронными функциями, во фронтэнде, просто теряет свой смысл из-за его слишком большой задержки (проверка ядром системы, проверка браузером, проверка анти-вирусом и прочими сторонними наблюдателями в системе).
Не пытайтесь писать на фронтэнде то, что нельзя на нем писать, притащив в него устаревшие технологии из бэкэнда! Хотите работу приложения как в бэкэнде, да млина, — пишите на бэкэнде, а фронтэнд подгружайте в виде интерфейса только, а не для работы и вычислений (не умеете так? слишком сложно для вас? — учитесь, или заказывайте у тех, кто может, но не пытайтесь городить шнягу убогую на том, на чем её не следует городить).
Тоже самое тут про virtual dom кто-то писал в комментах, ну и у самого автора поста это как раз-таки вызвало бурю негатива — и да, я полностью его поддерживаю в этом. Бла-бла-бла Senior… — не знаешь вирутал? не, не сениор. А вот собеседующий сам в курсе, что даже не junior, а первый месяц изучающий любой язык джуниор, уже знает и всегда использует только виртуал дом? 10-20 лет назад, любой, кто начинал попытку использования в своем бэкэнде web интерфейса (подгрузив объект webbrowser, или создав из своей программы экземпляры штатного веббраузера системы) тут же, при первом опыте внедрения большого потока данных в реальный дом, сталкивается с тем, что без виртуал, его код не будет работать. Ибо, подвесив свой ПК таким обращением в реальный дом, он начинает анализировать, что же произошло и находит причину, что работа с прямым дом, контролируемым всеми и вся, так нагружает и тормозит пк — что работа с ним просто не реальна.
И он тут же изобретает свой виртуал дом и обрабатывает его штатными регэкспами в памяти, выгружая в файлы готовые куски кода, если их слишком много для работы из памяти напрямую, а затем уже использует эти куски в своем веб интерфейсе. О чудо, спустя 20 лет, кто-то изобрел то же самое и назвал это virtual dom — и это да, это важно, это только для senior-ов технология, только они в курсе, как это и для чего :( аааа, жесть просто, не хватает уже эмоций на таких вот чудо-профи — куда катится мир программирования? Что, никто больше не хочет думать? Все читают каких-то ущербных чудо-разрабов, чтобы самим стать такими же ущербными и писать всякую чушь к месту и нет? Кто-то читает вообще спецификации самих языков? Спецификации ОС и аппаратной части ПК? Чтобы понимать, как работает тот, или иной метод в реальности?
Ладно, хватит лирики, тут на хабре я читал только от пары человек статьи, которые объясняли, как работает на низком уровне та, или иная функция языка, или препроцессора (в зависимости от того, что освещал автор). Это были переводы статей конечно, но сам факт, что человек правильно перевел такие статьи, дает мне право считать, что он также понимает, как работает то, что он переводит. Все остальные тут, смотрю, даже близко не представляют, как работает их чудо-супер-пупер технология замыканий, промисов и прочая чушь, в реальности и какие порождает процессы на низком уровне.
Все, кто тут отписался, считая себя суепр-профи знатоком, давайте эксперимент — скидывайте код, где вы считаете уместным замыкание, промис и т.д. Я переделываю его в свой код без всей этой чуши, и мы вставляем его в тело реальной страницы, нагруженной эффектами движения, графикой и прочим. Запускаем циклично тест этой (этих функций) и пишем видео с экрана работы этой страницы во время выполнения наших кодов, активно взаимодействуя с элементами страницы (скрлим, наводим мышь на элементы, выделяем текст, кликаем правой кнопкой мыши — в общем делаем все то, что делает пользователь на странице, просто не открывая новых вкладок).
По окончании работы теста, сохраняем данные использования памяти, CPU, GPU, время работы кодов (ну и выкладываем видео на общее обозрение, как ведет себя страница в браузере пока работает ваш и мой код — оба типа у каждого на ПК, чтобы было видно, как работает разный код на одном и том же ПК).
Вот тогда, мы и будем уже более детально обсуждать чудо-супер-пупер технологии на реальном примере, а не на сферическом коне в вакууме.
Теперь же бэкэнд вырос и избавился от этой шняги и такие вот горе-профи (аааа жесть просто) теперь пытаются впихнуть это старье во фронт энд, и всё по той же причине, чтобы также как и тогда в бэкэнде, обойти ограничения синхронности языка.
Но вот беда, работа кода в бэкэнде и работа его во фронтэнде, подчиняются абсолютно разным правилам и проходят очень-очень разные этапы проверок и допусков. И понятное дело, что обмен данными между мнимо-асинхронными функциями, во фронтэнде, просто теряет свой смысл из-за его слишком большой задержки (проверка ядром системы, проверка браузером, проверка анти-вирусом и прочими сторонними наблюдателями в системе).
Не пытайтесь писать на фронтэнде то, что нельзя на нем писать, притащив в него устаревшие технологии из бэкэнда! Хотите работу приложения как в бэкэнде, да млина, — пишите на бэкэнде, а фронтэнд подгружайте в виде интерфейса только, а не для работы и вычислений (не умеете так? слишком сложно для вас? — учитесь, или заказывайте у тех, кто может, но не пытайтесь городить шнягу убогую на том, на чем её не следует городить).
Тоже самое тут про virtual dom кто-то писал в комментах, ну и у самого автора поста это как раз-таки вызвало бурю негатива — и да, я полностью его поддерживаю в этом. Бла-бла-бла Senior… — не знаешь вирутал? не, не сениор. А вот собеседующий сам в курсе, что даже не junior, а первый месяц изучающий любой язык джуниор, уже знает и всегда использует только виртуал дом? 10-20 лет назад, любой, кто начинал попытку использования в своем бэкэнде web интерфейса (подгрузив объект webbrowser, или создав из своей программы экземпляры штатного веббраузера системы) тут же, при первом опыте внедрения большого потока данных в реальный дом, сталкивается с тем, что без виртуал, его код не будет работать. Ибо, подвесив свой ПК таким обращением в реальный дом, он начинает анализировать, что же произошло и находит причину, что работа с прямым дом, контролируемым всеми и вся, так нагружает и тормозит пк — что работа с ним просто не реальна.
И он тут же изобретает свой виртуал дом и обрабатывает его штатными регэкспами в памяти, выгружая в файлы готовые куски кода, если их слишком много для работы из памяти напрямую, а затем уже использует эти куски в своем веб интерфейсе. О чудо, спустя 20 лет, кто-то изобрел то же самое и назвал это virtual dom — и это да, это важно, это только для senior-ов технология, только они в курсе, как это и для чего :( аааа, жесть просто, не хватает уже эмоций на таких вот чудо-профи — куда катится мир программирования? Что, никто больше не хочет думать? Все читают каких-то ущербных чудо-разрабов, чтобы самим стать такими же ущербными и писать всякую чушь к месту и нет? Кто-то читает вообще спецификации самих языков? Спецификации ОС и аппаратной части ПК? Чтобы понимать, как работает тот, или иной метод в реальности?
Ладно, хватит лирики, тут на хабре я читал только от пары человек статьи, которые объясняли, как работает на низком уровне та, или иная функция языка, или препроцессора (в зависимости от того, что освещал автор). Это были переводы статей конечно, но сам факт, что человек правильно перевел такие статьи, дает мне право считать, что он также понимает, как работает то, что он переводит. Все остальные тут, смотрю, даже близко не представляют, как работает их чудо-супер-пупер технология замыканий, промисов и прочая чушь, в реальности и какие порождает процессы на низком уровне.
Все, кто тут отписался, считая себя суепр-профи знатоком, давайте эксперимент — скидывайте код, где вы считаете уместным замыкание, промис и т.д. Я переделываю его в свой код без всей этой чуши, и мы вставляем его в тело реальной страницы, нагруженной эффектами движения, графикой и прочим. Запускаем циклично тест этой (этих функций) и пишем видео с экрана работы этой страницы во время выполнения наших кодов, активно взаимодействуя с элементами страницы (скрлим, наводим мышь на элементы, выделяем текст, кликаем правой кнопкой мыши — в общем делаем все то, что делает пользователь на странице, просто не открывая новых вкладок).
По окончании работы теста, сохраняем данные использования памяти, CPU, GPU, время работы кодов (ну и выкладываем видео на общее обозрение, как ведет себя страница в браузере пока работает ваш и мой код — оба типа у каждого на ПК, чтобы было видно, как работает разный код на одном и том же ПК).
Вот тогда, мы и будем уже более детально обсуждать чудо-супер-пупер технологии на реальном примере, а не на сферическом коне в вакууме.
Вот вам код:
fetch("https://www.mocky.io/v2/5185415ba171ea3a00704eed")
.then(x => x.json())
.then(x => console.log(x.hello))Попробуйте его для начала просто переделать без промисов и замыканий. А мы посмеемся.
А цикл-то откуда возьмется? :-)
Да что ты будешь делать. Вот что вы читаете? Какой цикл вы где видите? Вы спецификацию xmlhttprequest читали вообще?
Весь fetch этого чудо-автора ниже джуниора, это регистрация промиса, резервирование состояний, объявление функций response и reject, запуск таймера опроса промиса для получения состояния исполнения, и, только затем, исполнение ТОГО ЖЕ КОДА ОТ xmlhttprequest:
То есть, такой вот чудо-разраб, который начитался таких же чудо-разрабов придумавших fetch, чтобы не писать код обработки XMLHTTPRequest, взял и на ровном месте в 3 раза увеличил нагрузку на ПК юзера, просто так, чтобы не писать пару лишних строк.
Ну, я могу понять, любишь ты короткие записи, напиши просто функцию обертку тогда, чтобы её вызывать вместо кода самого XMLHTTPRequest, и обзови там её myfetch(respose, reject) и вызывай — даже это будет в разищи быстрее и лучше, чем вызывать этот промис тормознутый и проблеммный.
Но нет, этот чудо-программер, будет бить себя пяткой в грудь, убивать машину юзеру, но не снизойдет до изучения чего-либо, а просто будет читать таких же супер-пупер профи.
Весь fetch этого чудо-автора ниже джуниора, это регистрация промиса, резервирование состояний, объявление функций response и reject, запуск таймера опроса промиса для получения состояния исполнения, и, только затем, исполнение ТОГО ЖЕ КОДА ОТ xmlhttprequest:
function eH001(){
if (this.status == 200)(x => x.json());
(x => console.log(x.hello));
}
var XH001 = new XMLHttpRequest();
XH001.onload = eH001;
XH001.open('GET', 'https://www.mocky.io/v2/5185415ba171ea3a00704eed');
XH001.send();
То есть, такой вот чудо-разраб, который начитался таких же чудо-разрабов придумавших fetch, чтобы не писать код обработки XMLHTTPRequest, взял и на ровном месте в 3 раза увеличил нагрузку на ПК юзера, просто так, чтобы не писать пару лишних строк.
Ну, я могу понять, любишь ты короткие записи, напиши просто функцию обертку тогда, чтобы её вызывать вместо кода самого XMLHTTPRequest, и обзови там её myfetch(respose, reject) и вызывай — даже это будет в разищи быстрее и лучше, чем вызывать этот промис тормознутый и проблеммный.
Но нет, этот чудо-программер, будет бить себя пяткой в грудь, убивать машину юзеру, но не снизойдет до изучения чего-либо, а просто будет читать таких же супер-пупер профи.
запуск таймера опроса промиса для получения состояния исполнения
Ваши сообщения — это какой-то сборник анекдотов. Откуда вы взяли, что существует какой-то таймер опроса?
Кстати, приведенный вами код не работает.
Кроме того, что он не работает так еще и замыкания использует, поэтому придется SemaIVVV искать новую работу не у себя в проекте.
Пожалейте человека, сам себя уволил публично на хабре, а ему за шаред хостинг за 300 рублей оплачивать, придется же на ватрушках в столовке экономить.
Пожалейте человека, сам себя уволил публично на хабре, а ему за шаред хостинг за 300 рублей оплачивать, придется же на ватрушках в столовке экономить.
На счет таймеров — еще раз повторю, учите матчасть, или на курсы идите (я вас бесплатно образовываю, написав вам что делает ваш fetch в в вашем коде).
На счет не работает — откуда мне знать, что вы там вызываете своими объектами.
Запишите обработчик для проверки так, чтобы узнать в консоли работает или нет:
>@b00taNik Кроме того, что он не работает так еще и замыкания использует,
Вы тоже не пишите больше, а идите учиться на курсы начальные — также ниже джуниора левел, который в принципе не знает что такое замыкания. (вам тоже бесплатный урок — назначение события, либо передача имени функции аргументом [без скобок], это не замыкание. Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием в JS и что позволяет сохранять состояния переменных. В моем же коде, нет никаких замыканий, и в обработчике, this будет всем, на что в любой из функций повесят этот обработчик, и, как вы не извращайтесь, но он никогда не сохранит состояние предыдущего вызова если его вызвали повторно. Учите матчасть, поднимитесь до джуниора хотя бы. И не смешите народ и не позорьтесь — не пишите чушь больше здесь.
На счет не работает — откуда мне знать, что вы там вызываете своими объектами.
Запишите обработчик для проверки так, чтобы узнать в консоли работает или нет:
function eH001(){
if (this.status == 200){console.log('OK!')}else{console.log('NO!');}
}>@b00taNik Кроме того, что он не работает так еще и замыкания использует,
Вы тоже не пишите больше, а идите учиться на курсы начальные — также ниже джуниора левел, который в принципе не знает что такое замыкания. (вам тоже бесплатный урок — назначение события, либо передача имени функции аргументом [без скобок], это не замыкание. Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием в JS и что позволяет сохранять состояния переменных. В моем же коде, нет никаких замыканий, и в обработчике, this будет всем, на что в любой из функций повесят этот обработчик, и, как вы не извращайтесь, но он никогда не сохранит состояние предыдущего вызова если его вызвали повторно. Учите матчасть, поднимитесь до джуниора хотя бы. И не смешите народ и не позорьтесь — не пишите чушь больше здесь.
И это пишет якобы сеньор :-) Вроде бы стандартное API, доступное во всех современных браузерах — но нет, "откуда мне знать, что вы там вызываете своими объектами".
Явное объявление функции, либо вызов в анонимном варианте [со скобками] внутри другой функции — вот что является замыканием
А вот википедия, например, считает что замыкание — это функция первого порядка (т.е. функция-объект, как, eH001), и которая использует внешние переменные, не являющиеся ее параметрами (как this.status, например).
Может посоветуете курсы, где бы я мог познать схожую с вами мудрость, а то как отучился на ВТ в 2008, так и работаю программистом, все некогда на курсы для джуниоров сходить.
PS: код не работает, потому что он синтаксически некорректно составлен, да и x не определен, если бы вы хоть немного понимали в JS, до вас бы это дошло.
this не замкнут, это неявный параметр функции. А вот console — вполне себе.
Кстати, я на счет этого не уверен. Глобальные переменные тоже через замыкание поставляются или для этого есть отдельный механизм?
На таком обывательском уровне и я могу рассказать. Меня интересует, если ли какая-то особая обработка global переменной. То есть больше инфы, чем прочитать одну поверхностную (хоть и хорошую) статью на javascript.ru
Тут вы крайне странно сформулировали.
Там не все так просто, как кажется на первый взгляд. Вот к примеру, вы говорите «пока не выйдет на функцию определенную в глобальном объекте. А в глобальном объекте есть свойство console». Так вот как именно это работает? Тут уже надо знать про BindingObject и все такое. Я вот не был уверен, что глобальный объект является частью этой цепочки скоупов до того, как специально залез в спецификацию и посмотрел (так вполне могла быть отдельная (иная) обработка глобального объекта). И, на самом деле, есть определенныё исключения.
К примеру есть уникальный Lexical Environment, который называется «The Global Environment». И, иногда, особая работа с ним. Например, в спецификации есть прямые исключения:
Более того, необходимо понимать такую важную вещь:
К сожалению я смог найти в спецификации, в какой момент присваивается для шапки цепочки Global Environment. Единственное, где это присутствует — это в пункте «15.3.2.1 new Function»:
В какой именно момент в начале цепочки становится Global Environment и становится ли такой вообще (или обрабатывается как исключение) в документации я не нашел(
функцию определенную в глобальном объекте
Тут вы крайне странно сформулировали.
Там не все так просто, как кажется на первый взгляд. Вот к примеру, вы говорите «пока не выйдет на функцию определенную в глобальном объекте. А в глобальном объекте есть свойство console». Так вот как именно это работает? Тут уже надо знать про BindingObject и все такое. Я вот не был уверен, что глобальный объект является частью этой цепочки скоупов до того, как специально залез в спецификацию и посмотрел (так вполне могла быть отдельная (иная) обработка глобального объекта). И, на самом деле, есть определенныё исключения.
К примеру есть уникальный Lexical Environment, который называется «The Global Environment». И, иногда, особая работа с ним. Например, в спецификации есть прямые исключения:
Else if env is the environment record component of the global environment then
Более того, необходимо понимать такую важную вещь:
Lexical Environments and Environment Record values are purely specification mechanisms and need not correspond to any specific artefact of an ECMAScript implementation.
К сожалению я смог найти в спецификации, в какой момент присваивается для шапки цепочки Global Environment. Единственное, где это присутствует — это в пункте «15.3.2.1 new Function»:
Pass in the Global Environment as the Scope parameter and strict as the Strict flag..
В какой именно момент в начале цепочки становится Global Environment и становится ли такой вообще (или обрабатывается как исключение) в документации я не нашел(
Да тут дело даже не в иллюстрациях, а в понимании самого процесса замыкания в JS. Многие просто не понимают, что из себя представляет само замыкание в JS. В остальных языках — там всё это совсем по другому, и ясно и понятно. А в JS это баг изначально, и его не стали исправлять, а так и оставили, типа фишка языка. И вот теперь, кто-то додумывается использовать этот баг.
Суть ошибки замыкания в JS, что в нем нет типизированного вызова и обращения к свойствам объекта и к просто переменным. Сам интерпретатор решает к чему именно вы обращаетесь.
Вот вы указали базовый пример из справочника, и тут именно наглядно видно это. В момент, когда вы создали глобальный объект var myFunc = makeFunc… отработала внутренняя функция displayName создав замыкание и глобальный объект myFunc получил свойство name (в обычном языке myFunc->name).
Всё, функции makeFunc и displayName отработали, и все их внутренние переменные должны быть очищены, это везде так (и в JS это тоже так).
Но, в js, (так, как все функции являются объектами — гвоздь им в голову сразу и по шляпку) когда вы снова, после окончания работы функций пытаетесь обратиться к переменной name, интерпретатор, не имея типизации обращения, видит, что такое свойство есть у ныне существующего глобального объекта myFunc, а значит, вы, скорее-всего, к нему обращаетесь — он вам и возвращает это свойство этого объекта, и складывается впечатление, что якобы существует сама переменная name в памяти, после окончания работы функций.
Вот именно это и является проблемой — можно так дозамыкаться, что ПК пользователя просто перестанет отвечать на запросы. А также черт его знает в каком месте у вас нахлестнутся имена свойств объектов после замыкания и имена глобальных переменных, что приведет просто к разрыву башки при отладке такого кода. Вот поэтому, я жестко караю любого, за любую попытку этого х… кода в js, кто сознательно пытается использовать этот баг в js.
И именно поэтому, каждый раз когда новая команда разработчиков (и не важно, номральная-ли команда, или команда чудо-разрабО) приходят к клиенту, чтобы расширить (или исправить) код, который был написан до этого такими вот чудо-разрабами, нет никакого шанса разобрать этот дивный код. Поэтому, всегда все начинают писать всё с нуля. Клиент, которому попадаются такие чудо-разрабы, постоянно попадает на деньги и на время, и из-за этого у него складывается негативное впечатление о работе отрасли программирования в целом. И всё это из-за таких вот чудо-программеров, как b00taNik, которые считают себя программистами.
Вот мой код и код таких как я, сможет прийти и продолжить, или изменить, любая новая команда у клиента (и не важно нормальная ли команда, или команда чудо-разрабов). Им потребуется минимальное время, чтобы понять структуру кода и начать его исправлять, или дополнять. Никаких неявных петель и ловушек вроде таких вот чудо-замыканий, они не получат в моем коде, я даже никогда не делаю дубли в именовании явно-объявляемых переменных внутри функций, не говоря уже о том, чтобы произошел нахлест в глобальной области видимости.
Суть ошибки замыкания в JS, что в нем нет типизированного вызова и обращения к свойствам объекта и к просто переменным. Сам интерпретатор решает к чему именно вы обращаетесь.
Вот вы указали базовый пример из справочника, и тут именно наглядно видно это. В момент, когда вы создали глобальный объект var myFunc = makeFunc… отработала внутренняя функция displayName создав замыкание и глобальный объект myFunc получил свойство name (в обычном языке myFunc->name).
Всё, функции makeFunc и displayName отработали, и все их внутренние переменные должны быть очищены, это везде так (и в JS это тоже так).
Но, в js, (так, как все функции являются объектами — гвоздь им в голову сразу и по шляпку) когда вы снова, после окончания работы функций пытаетесь обратиться к переменной name, интерпретатор, не имея типизации обращения, видит, что такое свойство есть у ныне существующего глобального объекта myFunc, а значит, вы, скорее-всего, к нему обращаетесь — он вам и возвращает это свойство этого объекта, и складывается впечатление, что якобы существует сама переменная name в памяти, после окончания работы функций.
Вот именно это и является проблемой — можно так дозамыкаться, что ПК пользователя просто перестанет отвечать на запросы. А также черт его знает в каком месте у вас нахлестнутся имена свойств объектов после замыкания и имена глобальных переменных, что приведет просто к разрыву башки при отладке такого кода. Вот поэтому, я жестко караю любого, за любую попытку этого х… кода в js, кто сознательно пытается использовать этот баг в js.
И именно поэтому, каждый раз когда новая команда разработчиков (и не важно, номральная-ли команда, или команда чудо-разрабО) приходят к клиенту, чтобы расширить (или исправить) код, который был написан до этого такими вот чудо-разрабами, нет никакого шанса разобрать этот дивный код. Поэтому, всегда все начинают писать всё с нуля. Клиент, которому попадаются такие чудо-разрабы, постоянно попадает на деньги и на время, и из-за этого у него складывается негативное впечатление о работе отрасли программирования в целом. И всё это из-за таких вот чудо-программеров, как b00taNik, которые считают себя программистами.
Вот мой код и код таких как я, сможет прийти и продолжить, или изменить, любая новая команда у клиента (и не важно нормальная ли команда, или команда чудо-разрабов). Им потребуется минимальное время, чтобы понять структуру кода и начать его исправлять, или дополнять. Никаких неявных петель и ловушек вроде таких вот чудо-замыканий, они не получат в моем коде, я даже никогда не делаю дубли в именовании явно-объявляемых переменных внутри функций, не говоря уже о том, чтобы произошел нахлест в глобальной области видимости.
Главная ваша претензия к замыканиям в JS это то, что имена переменных могут пересекаться с другими областями видимости, а вам как программисту не хватит мозгов чтобы понять как этого избежать? Вы это серьезно?
А что касается кода — начните с того, что вы обещали показать код без замыканий и работающий. Где он в итоге то?
А что касается кода — начните с того, что вы обещали показать код без замыканий и работающий. Где он в итоге то?
Ну че, поздравляю вашего работадателя с наймом программиста, учившигося в википедии (мое сочувствие ему) :)
На курсы — запишитесь при любом университете технической направленности (а то я как закончил Универ радиотехнический по направлению автоматизация и управление, так и программирую после этого и учусь не в википедии, а по документации к языкам и аппаратным комплексам).
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
А теперь вопрос супер-пупер программисту википедийному, eH001 — определена где? Внутри функции какой то? ИЛи на глобальном уровне вне окружения функций?
Жесть, и вот такое чудо-разрабо, программистом работает, жесть просто — где работаете? Надо вашему нанимателю линк скинуть на ваши комменты здесь, чтобы он понял кто у него работает.
На курсы — запишитесь при любом университете технической направленности (а то я как закончил Универ радиотехнический по направлению автоматизация и управление, так и программирую после этого и учусь не в википедии, а по документации к языкам и аппаратным комплексам).
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
А теперь вопрос супер-пупер программисту википедийному, eH001 — определена где? Внутри функции какой то? ИЛи на глобальном уровне вне окружения функций?
Жесть, и вот такое чудо-разрабо, программистом работает, жесть просто — где работаете? Надо вашему нанимателю линк скинуть на ваши комменты здесь, чтобы он понял кто у него работает.
Можете себя не утруждать, я уже скинул — уже ржем над вами всем офисом второй день — особенно с ваших познаний во фронтенде.
Не могли бы вы сослаться на книгу, где вы это услышали, раз википедия не источник, хотелось бы тоже ознакомиться с данным кладезем мудрости? Кроме того, даже если по вашему определению, console откуда берется, не из глобального ли контекста?
Ну а то, что вы учились программировать по документации к устройствам — ну так и заметно, что ваши познания в программировании недалеко от примеров из методичек :)
Замыкание — это комбинация функции и лексического окружения, в котором эта функция была определена.
Не могли бы вы сослаться на книгу, где вы это услышали, раз википедия не источник, хотелось бы тоже ознакомиться с данным кладезем мудрости? Кроме того, даже если по вашему определению, console откуда берется, не из глобального ли контекста?
Ну а то, что вы учились программировать по документации к устройствам — ну так и заметно, что ваши познания в программировании недалеко от примеров из методичек :)
Вы бы внимательнее, что-ли, читали.
Понятия не имею, какие познания у вашего оппонента — для меня фронт и js страшные тёмные места, в которые я не суюсь, ибо квалификации не хватает, но у него прямо в комментарии написано, откуда он цитирует:
И затем первый же запрос в яндекс «mozilla closure» выводит нас на нужный сайт, где именно так и написано определение.
Понятия не имею, какие познания у вашего оппонента — для меня фронт и js страшные тёмные места, в которые я не суюсь, ибо квалификации не хватает, но у него прямо в комментарии написано, откуда он цитирует:
И да, не по викепилдии, а по документации языка и разработчиков (мозила):
И затем первый же запрос в яндекс «mozilla closure» выводит нас на нужный сайт, где именно так и написано определение.
Т.е. человек мне приводит описание реализации замыканий в фаерфоксе, и выдает это за академическое определение.
Спасибо за разьяснение данного момента, все ясно.
Спасибо за разьяснение данного момента, все ясно.
Собственно, больше склонен верить г-ну b00taNik, и именно потому, что сходил по ссылке — источнику знаний SemaIVVV.
Прямо оттуда:
И именно об этом говорит b00taNik, а SemaIVVV продолжает стоять на том, что это только у неучей, а его функции в его Javascripte никаких замыканий не формируют.
Прямо оттуда:
функции в JavaScript формируют так называемые замыкания
И именно об этом говорит b00taNik, а SemaIVVV продолжает стоять на том, что это только у неучей, а его функции в его Javascripte никаких замыканий не формируют.
Код с циклом не заблокирует разве поток, что приведёт к заморозке всего интерфейса? Насколько я помню, xmlhttprequest всегда юзали вместе с коллбеком onLoad, который всегда был и асинхронный, и с замыканиями. Прошу поправить если не прав
Не выставляйте себя клоуном — и не пишите больше сюда. Вы просто новичок и ниже джуниора.
fetch всего лишь обертка для XMLHTTPRequest, чтобы такие неумехи, как вы писали меньше букв, не понимая технологии запроса данных. Если вы не понимаете, как написать XMLHTTPRequest запрос с if else (и при необходимости, заюзать catch), как в вашем fetch-е — просто идите на курсы базовые по программированию что-ли.
fetch всего лишь обертка для XMLHTTPRequest, чтобы такие неумехи, как вы писали меньше букв, не понимая технологии запроса данных. Если вы не понимаете, как написать XMLHTTPRequest запрос с if else (и при необходимости, заюзать catch), как в вашем fetch-е — просто идите на курсы базовые по программированию что-ли.
если условный фетч, который принимает колбек:
function helloLog(x) {
console.log(x.json().hello);
}
fetch("https://www.mocky.io/v2/5185415ba171ea3a00704eed", helloLog);Не очень хороший пример, тут не так велика разница. Вот если надо композить асинхронные действия — тут уже становится печальнее все эти helloLog-и писать :)
если условный фетч, который принимает колбек:
Каждый раз, читая такое, сначала утираю кровавые слёзы из глаз, а потом вспоминаю нетленное:
Классен Днепр при клёвой погоде, когда, кочевряжась и выпендриваясь, пилит он сквозь леса и горы клёвые воды свои. Вылупишь зенки свои, откроешь варежку — и с катушек. Редкая птица дочешет до середины Днепра, а если дочешет — так гикнется, что копыта отбросит.
Я понимаю вашу боль. У меня ощущение, что большая часть молодых разработчиков обучается по stackoverflow, а не по книгам. В итоге смотришь в task manager, а там приложение Upwork стабильно съедает 30-40% CPU. И это чат + трекер времени! С каких пор трекер времени требует столько ресурсов? Это если умножить на количество пользователей Upwork, то можно посчитать, сколько электроэнергии/угля сжигается от лени разработчиков писать эффективный код. Видимо, для получения меньшего числа в массиве сначала сортируется весь массив, потом берется первый элемент, не иначе.
Не ёрничайте, всем понятно что речь идет о замыканиях внутри старшей функции для попытки сделать приватными переменные, или сохранить значения переменных (хотя мне сложно понять для чего через ж… замыкания это пытаются делать).
Инкапсуляция состояния без замыканий?
Вот это как раз без проблем. Ни в одном языке программирования не существует способа полностью спрятать приватные поля от программиста, всегда все держится на соглашениях вида «обращаться к чужим полям через рефлексию нехорошо». В старом JS такое соглашение просто расширяется до «обращаться к полям про которые в комментарии написано что оно приватное нехорошо».
А в современном JS уже есть символы и хотят ввести приватные поля.
А в современном JS уже есть символы и хотят ввести приватные поля.
В старом JS традиционально настоящие приватные поля проще всего делаются через замыкания. Это позволяет контролировать корректность обращения к ним с помощью самого интерпретатора.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет и никогда не программировал на языках с ООП, либо это сознательно, старая собака уже испытывает проблемы с новыми трюками.
Комментарии — это, пожалуй, самое отвратительное, что можно было придумать для выражения данной концепции. Поддержка такого кода будет адом. Если же очень нужно открыть поле наружу, но запретить публичное использование (эмуляция семантики protected-доступа из нормальных языков) — используют пре-/постфиксы для имени поля, что будет однозначной подсказкой даже в клиентском коде.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет и никогда не программировал на языках с ООП, либо это сознательно, старая собака уже испытывает проблемы с новыми трюками.
Комментарии — это, пожалуй, самое отвратительное, что можно было придумать для выражения данной концепции. Поддержка такого кода будет адом. Если же очень нужно открыть поле наружу, но запретить публичное использование (эмуляция семантики protected-доступа из нормальных языков) — используют пре-/постфиксы для имени поля, что будет однозначной подсказкой даже в клиентском коде.
Тем не менее, инкапсуляция без замыканий все еще возможна, даже если большинство ее делает через замыкания.
Если программист с большим стажем не может оценить преимущества этого подхода, лично для меня это означает, что человек либо живет с «головой в песок» крайние 15 лет
То есть вы настаиваете на важности модификатора private, полностью игнорируя отсутствие иногда даже более важного модификатора protected и рассуждаете о «с головой в песок»?
Опытные программисты или используют JSDoc, где есть оба модификатора или уже давно ушли в TypeScript. А «инкапсуляция через замыкания» — не более, чем костыль для новичков.
Похоже я проспал революцию, раз не вижу в сокрытии (особенно через замыкание) никакой пользы, но вижу кучу минусов. Не расскажите нам про эти преимущества?
Сдается мне, что вы желаете похоливарить) В этом не поддержу, но ссылку на википедию оставлю на случай, если «нам» не ограничивается вами.
Вангую аргументы про
reinterpret_cast<int*>(Foo*). «Это же держится на соглашениях для С++-программистов!»Нет, это не UB. Ведь по указанному адресу и правда находится int.
Все равно UB, потому что нет в стандарте никаких гарантий на расположение полей, и завтра в этот класс компилятор вдруг напихает каких-нибудь внутренних структур байт на 20, и все развалится. Даже если оно у вас сейчас работает — это волшебство, а не C++.
Не может там не быть никаких гарантий — это бы сделало невозможным передачу структур между модулями на разных языках. Если даже таких гарантий нет в стандарте — они всегда есть в конкретных реализациях.
Ну таковая передача на C++ невозможна по стандарту даже без разных языков. У языка не определен binary interface, и потому передавать приходится либо структуры из C (у которых таковой интерфейс есть), либо использовать сериализацию в промежуточные форматы вроде protobuf.
Если же использовать особенности конкретных реализаций, то это вновь волшебство, а не C++, потому что даже минорное обновление любого компонента компилятора может вам разломать все в самых неожиданных местах, и про котел в аду там выше не зря написано.
Если же использовать особенности конкретных реализаций, то это вновь волшебство, а не C++, потому что даже минорное обновление любого компонента компилятора может вам разломать все в самых неожиданных местах, и про котел в аду там выше не зря написано.
Чем "структура из Си" отличается от класса без виртуальных функций? Насколько я знаю, extern "C" влияет только не функции и переменные, но не на структуры.
Да и с теми же виртуальными функциями все не так сложно. Да, смещение первого поля будет implementation-spicific, но подразумеваемое поведение компилятора можно проверить тестами, по типу таких: assert(reinterpret_cast<intptr_t>(&Foo::x) == sizeof(void*));
PS про котел в аду в целом согласен — вот только, в моем понимании, нарушителей соглашения по именованию приватных полей в javascript ждет соседний котел :-)
Отличается тем, что у нее размещение определено, выравнивание определено, и делать его по другому без явного на то указания компилятор не имеет права, и потому макросы вроде OFFSET_OF() и CR() до сих пор отлично работают. У класса (хоть с виртуальными функциями, хоть без) размещение не определено, точнее определяется реализацией, т.е. никто не мешает начать, к примеру, все поля тегировать (т.е. перед каждым полем вставить еще по полю с тегом), сам класс тегировать (вставить ему GUID вначале, чтобы за размещением экземпляров в памяти потом следить), и все это останется в рамках C++ (т.е. код на C++ работать не перестанет), а у вас либо reinterpret_cast вернет непонятно что, либо все завалится еще на ассертах.
Разница в том, где именно происходит проверка на то, что правила доступа не нарушаются, и в C++ она не происходит, потому что вы об этом просите явно очень заметной конструкцией (в Rust таковые еще заметнее), а в JS у вас и соглашение в голове, и проверка его там же, и найти таковые нарушения grep'ом просто так не получится.
Разница в том, где именно происходит проверка на то, что правила доступа не нарушаются, и в C++ она не происходит, потому что вы об этом просите явно очень заметной конструкцией (в Rust таковые еще заметнее), а в JS у вас и соглашение в голове, и проверка его там же, и найти таковые нарушения grep'ом просто так не получится.
А не подскажите название компании, где вы работаете? Ну чтобы сразу игнорировать предложения работы оттуда)
Если в любом моем проекте, кто-то, хотя бы подумает использовать замыкание — сразу пойдет искать новую работу.
Вы понимаете, что, наверное, невозможно написать JS-код не создавая замыканий? Если вы умеете — научите меня, пожалуйста. Мне очень интересно
JS — асинхронный язык кстати. Но однопоточный. Типичный вопрос на собеседовании — почему js асинхронный. Который подразумевает, что вы знаете что такое EventLoop а если знаете, то как можно назвать его синхронным?
И то в новой nodejs уже ввели нативную подержку мультипоточности. Вам бы самому новую работу найти не помешало. :)
И то в новой nodejs уже ввели нативную подержку мультипоточности. Вам бы самому новую работу найти не помешало. :)
Так толсто, что даже тонко
А когда на senior-позицию приходят полные нули, что делать? Знакомый фронтендер периодически собеседует людей на позицию senior-ов. Люди говорят/пишут, что у них 3-5-10 лет опыта, но они не знают концепции замыканий.
Программирую еще с прошлого века.
Смотрю все пишут про какие-то умные замыкания. Не знаю этого термина.
Думаю, ну наверное некая умная концепция, может, буду использовать, пригодится. Надо почитать что это.
Читаю.
Ага. Использую, не зная как оно называется, уже лет 20 или поболее даже, оказывается.
Почему? Нас учили разным математическим моделям, а вовсе не тому как что называется в синтаксисе языка.
Внимание, вопрос:
Являюсь ли я недостойным должности сеньора, если 10 последних лет как проектирую highload-решения, которые держат высокие нагрузки на смешном железе?
Если вам задают этот вопрос — бегите. Этот вопрос означает, что за 5 минут до интервью интервьюер загуглил «что спросить на собеседовании javascript». Во всех проектах, где на интервью меня спрашивали про замыкания, царил бардак и ужас.
Охренел (25 лет за баранкой этого пылесоса, а не слышал). Почитал. Охренел второй раз — концепция понятна, но мне а) за те самые 25 лет мне не требовалась ни разу, б) можно гораздо понятнее объяснить в терминах низкого уровня (как известно, C — это по большому счёту надстройка над ассемблером/машинными кодами, на которых я с детства работал).
Программист не может не знать, что такое замыкание.
Есть отличная фраза — «Иногда 10 лет опыта — это один год, повторенный 10 раз».
В твоём случае это было 25 раз, только и всего.
Есть отличная фраза — «Иногда 10 лет опыта — это один год, повторенный 10 раз».
В твоём случае это было 25 раз, только и всего.
В твоём случае
Не подскажете, когда мы с Вами на брудершафт пили? А то я запамятовал.
Повторяю: концепция мне знакома, но никогда не возникало необходимости её с кему-то обуждать, соответственно узнать её "официальное" название — тоже; фразы "вон та вот х… рень" вполне хватало.
А где-то есть список «Чего не может не знать программист»?
Было бы любопытно ознакомиться.
Было бы любопытно ознакомиться.
What Every Programmer Should Know About Memory
What Every Programmer Should Know About
Floating-Point Arithmetic
Держите и не благодарите. Когда это знаешь, то иногда получаешь х10 производительности, просто переставив порядок операций. С плавающей точкой аналогично — иногда, решая нелинейные уравнения, результат надо нормализовать по заданному эпсилону, чтобы случайно не взять sqrt(-1e-18), когда должен быть sqrt(0), и не получить nan во всех последующих результатах.
What Every Programmer Should Know About
Floating-Point Arithmetic
Держите и не благодарите. Когда это знаешь, то иногда получаешь х10 производительности, просто переставив порядок операций. С плавающей точкой аналогично — иногда, решая нелинейные уравнения, результат надо нормализовать по заданному эпсилону, чтобы случайно не взять sqrt(-1e-18), когда должен быть sqrt(0), и не получить nan во всех последующих результатах.
Программист не может не знать, что такое замыкание.
То есть, по-вашему какой-нибудь крутой знаток ассемблера — «не программист», потому что он такое не использует и потому не знает?!
Как раз знаток ассемблера должен замыкания знать намного лучше остальных. Ему ведь их на ассемблере реализовывать, а не просто пользоваться.
Программисту следует реализовывать приложения, а не замыкания.
Ну вот когда вы пишете кодогенератор для компилятора, то вам надо знать, как реализовываются замыкания.
Вы считаете, что знаток ассемблера обязан знать «замыкание», ибо это обязательно для написания трансляторов для JS?
Может он чем то другим занимается?
P.S. при упоминании ассемблера мы, несколько, отошли от JS.
Может он чем то другим занимается?
P.S. при упоминании ассемблера мы, несколько, отошли от JS.
> ибо это обязательно для написания трансляторов для JS?
При чем тут транспиляторы js? Сейчас замыкания есть практически в любом ЯП и знание того, как устроены замыкания — это примерно то же самое, что знание того, как устроены функциональные вызовы.
При чем тут транспиляторы js? Сейчас замыкания есть практически в любом ЯП и знание того, как устроены замыкания — это примерно то же самое, что знание того, как устроены функциональные вызовы.
Не хотелось бы продолжать, ибо не компетентен.
Но я всегда думал, что ассемблер-разработчикам, гораздо ближе hard нежели высокоуровневые языки программирования.
Но я всегда думал, что ассемблер-разработчикам, гораздо ближе hard нежели высокоуровневые языки программирования.
Поддержу, современным разработчикам на ассемблере писать на них реализацию замыканий не нужно, и уже, скорее всего, не будет нужно.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
Полностью аналогичная ситуация.
за те самые 25 лет мне не требовалась ни разу
Ну бывает. Опыт-то он у всех разный. Например, в C++ и в Java такого фактически нет.
Я вот до знакомства с питоном тоже не знал что это и не использовал. В питоне же, изучая исходники библиотек, столкнулся — там это используется в написании декораторов. В js же вообще повсеместно (особенно раньше), в силу специфики языка.
Но вообще, до знакомства с тем же питоном я и о других вещах, вроде генераторов или метапрограммирования, тоже не знал. Так что полезно иногда изучать разные языки, так как многие из паттернов, подходов и концепций, почти отсутствующих в одном языке, в другом могут быть чуть ли не основным подходом.
Я тоже… Недавно узнал, что это теперь используется в новом PHP, когда пришлось немного адаптировать старый вики-движок. Ну, точнее, это там называется «анонимные функции».
В php вроде, как раз нету замыкания. То есть анонимные функции там, вроде, не замыкаются на родительский скоуп, а все необходимые данные им передаются как особые аргументы через use
А откуда они там берутся, в этом use? Уж не из родительского ли скоупа?
Я точно не знаю, могу ошибаться, как реализовано в PHP, но мне кажется, что там не через замыкание.
Они наследуются из родительской области видимости. Вся разница с тем же js в том, что в js переменные захватываются автоматически по факту использования, а в php список захватываемых переменных указывается вручную.
Кстати, в языке c++ реализованы оба механизма.
Кстати, в языке c++ реализованы оба механизма.
Я думал, что они именно привязываются к функции, как аргументы и такого прикола, как в JS быть не может.
То есть это не замыкание на родительский скоуп, а именно захват переменных в свой, при чем именно во время создания функции. Но я могу ошибаться, т.к. на php не писал с 5.3
То есть доступа в родительский скоуп (сообстно замыкания) во время работы функции нету, просто в локальной области видимости есть дополнительные переменные
for ($i = 0; $i < 10; $i++) {
$button->onclick = function () use ($i) {
echo $i;
};
}То есть это не замыкание на родительский скоуп, а именно захват переменных в свой, при чем именно во время создания функции. Но я могу ошибаться, т.к. на php не писал с 5.3
То есть доступа в родительский скоуп (сообстно замыкания) во время работы функции нету, просто в локальной области видимости есть дополнительные переменные
Да, прикола тут не будет, потому что переменная захватывается по значению. Но если поставить знак & — то она будет захвачена по ссылке со всеми последствиями.
Ну то есть будет захвачена ссылка на переменную. А замыкания на родительский скоуп все-равно не будет?
А что такое, по-вашему, «замыкание на скоуп» и чем оно отличается от замыкания, захватившего переменные этого скоупа?
Ну я представляю приблизительно так.
В JS и C# есть доступ к скоупу вне функций.
А в php клонируется или переменная, или ссылка на область памяти с ней.
В JS и C# есть доступ к скоупу вне функций.
А в php клонируется или переменная, или ссылка на область памяти с ней.
Все еще не вижу отличий.
for ($i = 0; $i < 10; $i++) {
anotherFunction( &$i );
}Тут ведь нет замыкания? Вот тот пример ближе к этому.
Нету. Потому что переменная передана параметром, а не захвачена. А в вашем примере c use она именно что была захвачена.
В PHP замыкания есть, о чем сказано и в мануале: php.net/manual/en/functions.anonymous.php
В PHP можно просто объявить статичную перменную внутри функции, доступную только в ней stackoverflow.com/questions/6188994/static-keyword-inside-function
function doStuff() {
static $cache = null;
if ($cache === null) {
$cache = '%heavy database stuff or something%';
}
// code using $cache
}
Например, <...> в Java такого фактически нет
В Java есть замыкания, вот пример:
public static final String VALUE = "VALUE";
public static Callable<String> myMethod() {
// Или так:
// return () -> VALUE;
return new Callable<String>() {
@Override
public String call() {
return VALUE;
}
};
}Тут и области видимости, и всё остальное соответствующее. До выхода Java 8 их просто сравнительно мало кто писал (причину видно по разнице между кодом в комментарии и вне комментария), да и после Java 8 официальное название этого подходя — capturing lambda, хотя по факту это таки практически один в один замыкание.
Вот как раз сишнику про замыкания знать не обязательно просто потому что в Си их нет, как и в ассемблере. В современном C++ замыкания есть, но сам термин тоже можно не знать, потому что обычно их называют лямбдами.
В современном C++ замыкания есть, но сам термин тоже можно не знать, потому что обычно их называют лямбдами.
Строго говоря, не каждая лябда — замыкание.
GCC давно позволяет делать замыкания
Я часто спрашиваю на собеседованиях чем по сути является метод .bind(). Это и есть мой скрытый вопрос про замыкание.
Разговор был про virtual. А если подойдет прохожий и скажет, что virtual это способ организовать перегрузку функции (методов) в рантайм с помощью таблиц в памяти, из-за ограниченности императивных ЯП?! Вы ему поверите? Да, ни смотря ни на что, они тоже стремятся к полиморфизму. А замыкания это просто поглощение значении переменных из внешней области переменных, которое на разных ЯП может быть по разному?
Пусть автор не сдается, собеседование это всего лишь этап.
Пусть автор не сдается, собеседование это всего лишь этап.
Во-первых, когда вы сами начнёте нанимать людей в нормальную контору, то увидите, как много непонятно кого пытаются правдами и неправдами попасть к вам. И если вы не знаете другого способа отсеивать фуфло, то вы тоже будете задавать тупые вопросы.
Во-вторых, ответ на вопрос «что такое замыкание» может отлично показать и психотип человека, и общую его базу. Это важно. Также в ответе прозвучат разные слова, за которые можно зацепиться. Вопросы на собеседовании — это всего лишь крючки, основное смысл — это как раз разговор о том, о чём вы будете говорить в своих ответах.
Ну и в целом не понимаю, почему у вас (в смысле у тебя и у ТС) бомбит. Если вы считаете, что подобные вопросы на собеседовании есть показатель того, что компания вам не подходит — ну так хорошо же, что вы сразу это понимаете. Лучше ведь на первом собеседовании увидеть, что вам с компанией не по пути, а не через полгода работы.
Во-вторых, ответ на вопрос «что такое замыкание» может отлично показать и психотип человека, и общую его базу. Это важно. Также в ответе прозвучат разные слова, за которые можно зацепиться. Вопросы на собеседовании — это всего лишь крючки, основное смысл — это как раз разговор о том, о чём вы будете говорить в своих ответах.
Ну и в целом не понимаю, почему у вас (в смысле у тебя и у ТС) бомбит. Если вы считаете, что подобные вопросы на собеседовании есть показатель того, что компания вам не подходит — ну так хорошо же, что вы сразу это понимаете. Лучше ведь на первом собеседовании увидеть, что вам с компанией не по пути, а не через полгода работы.
Во-первых, когда вы сами начнёте нанимать людей в нормальную контору, то увидите, как много непонятно кого пытаются правдами и неправдами попасть к вам. И если вы не знаете другого способа отсеивать фуфло, то вы тоже будете задавать тупые вопросы.
Статья о том, что таким способом наиболее эффективно отсеиваются как раз лучшие разработчики. А вот фуфло и так дорогу найдет, не замыканиями, так другими фокусами.
Статья о том, что таким способом наиболее эффективно отсеиваются как раз лучшие разработчики.Никаких доказательств данного тезиса в статье нет. Нет оснований полагать, что данные вопросы станут проблемой для лучших разработчиков. То, что они стали проблемой для автора никак не может быть без особых причин экстраполировано на лучших разработчиков.
Меня больше трясет от банальных зубрильных вопросов про особенности js при работе с var, конструкциями вида (...)(), в современном мире, где я использую только let, const (преимущественно). Я понимаю, что я должен знать что такое замыкание, я знаю что это но хоть убейте не могу рассказать как требуют, но точно знаю как избегать ошибок, связанных с этим.
От вопросов —
От вопросов —
var a = b = 3
Не в тему программирования, но тоже по ИТ. У нас было пару случаев по собеседованию на сис.админа:
1. Человек много всего красивого написал в резюме, в том числе установка CISCO. Угадайте как он их устанавливал? Правильно, брал руками и заталкивал в серверный шкаф.
2. Человек превосходно описал всё чем занимался, какие проекты сделал, свои достижения и прочая. Всё было замечательно до того момента, пока случайно из области бреда не стали спрашивать элементарных вещей про IP адрес, маску, маршрутизацию и прочая.
И на основании этого я делаю вывод, что да — необходимо спрашивать базовые вещи.
Особенно умиляют вопросы синьоров по Java — «а зачем нам знать как работает Garbage Collector?». А потом бегут с криками — нам надо еще 32 Гб ОЗУ — нам не хватает!
1. Человек много всего красивого написал в резюме, в том числе установка CISCO. Угадайте как он их устанавливал? Правильно, брал руками и заталкивал в серверный шкаф.
2. Человек превосходно описал всё чем занимался, какие проекты сделал, свои достижения и прочая. Всё было замечательно до того момента, пока случайно из области бреда не стали спрашивать элементарных вещей про IP адрес, маску, маршрутизацию и прочая.
И на основании этого я делаю вывод, что да — необходимо спрашивать базовые вещи.
Особенно умиляют вопросы синьоров по Java — «а зачем нам знать как работает Garbage Collector?». А потом бегут с криками — нам надо еще 32 Гб ОЗУ — нам не хватает!
Особенно умиляют вопросы синьоров по Java — «а зачем нам знать как работает Garbage Collector?». А потом бегут с криками — нам надо еще 32 Гб ОЗУ — нам не хватает!
А можно кейс, в котором знание алгоритма гц джавы поможет в том случае, когда 32гб не хватает?
Могу глупость ляпнуть, ибо не джавист, но может быть важно знание умеет ли он удалять циклические ссылки.
Он удаляет. Но, согласен, если бы не удалял — это действительно был бы кейз, хорошее замечание :)
Там не важно, циклическая ссылка или нет — если ни один элемент из этого «кольца» не «достижим» из активного кода, то всё кольцо может быть удалено:
www.javarticles.com/2016/09/java-garbage-collector-reachable-and-unreachable-objects.html
www.javarticles.com/2016/09/java-garbage-collector-reachable-and-unreachable-objects.html
Нечто, что не способно удалять циклические ссылки, недостойно называться GC :-)
Конечно.
Речь не идет о доскональном знании алгоритмов gc (они довольно сложны, как Я представляю), а в принципе о том, как выделяется и освобождается память с учетом работы GC, представлять, как работает счетчик ссылок и что высвобождение не мгновенное, что есть проблема циклических ссылок, которая и делает процесс сложным.
При оптимизации по памяти можно определить узкие места, и зная, к примеру, что пересоздание списка в глубоком вложенном цикле — плохая идея, переиспользовать этот список, создав его один раз.
Речь не идет о доскональном знании алгоритмов gc (они довольно сложны, как Я представляю), а в принципе о том, как выделяется и освобождается память с учетом работы GC, представлять, как работает счетчик ссылок и что высвобождение не мгновенное, что есть проблема циклических ссылок, которая и делает процесс сложным.
При оптимизации по памяти можно определить узкие места, и зная, к примеру, что пересоздание списка в глубоком вложенном цикле — плохая идея, переиспользовать этот список, создав его один раз.
Просто вы как-то так неудачно сформулировали, что вроде как знание принципов работы гц позволит впихуть в 32гб невпихуемое в 32гб, что, как мне кажется, ложно.
А то, что можно при должных знаниях затюнить профиль использования памяти и в общем поднять быстродействие приложения за счет этого — это понятно.
При оптимизации по памяти можно определить узкие места, и зная, к примеру, что пересоздание списка в глубоком вложенном цикле — плохая идея, переиспользовать этот список, создав его один раз.
В jvm же есть nursery? Если за его пределы не выйдет, то, в принципе, ничего совсем уж плохого не случится, по идее.
Мне было забавно, когда дали задание на позиции .NET разработчика — Что выведет консоль и правильно ли работает код —
for(var i = 0; i < 10; i++) {
setTimeout(function() {
console.log(i)
}, 100);
}Серьезно?
Я такое каждый день пишу))) (сарказм)
А оказалось что это всего лишь вопрос на знание API JS — Должно быть так —
for(var i = 0; i < 10; i++) {
setTimeout(function(i) {
console.log(i)
}, 100, i);
}Еще и пытались что то вытянуть по поводу IEnumerable, что правда не ясно.
Ожидали Lazy, LazyRef....
И вроде как известная достаточно в Екатеринбурге компания занимающаяся разработкой софта для бухгалтеров.
Вот так вот и бывает)
А оказалось что это всего лишь вопрос на знание API JS — Должно быть так —
Вроде в c# точно так же работает. Вот допустим, у нас есть пять кнопок, что выведется в консоль при клике на третью?
for (var i = 0; i < buttons.Count; i++) {
buttons[i].onClick.AddListener(delegate {
Console.WriteLine(i);
});
}
Вроде это известный прикол. 5. И ещё от версии зависит.
Так в том-то и дело, что он общеизвестный для программистов на любом языке, где есть замыкания и изменяемые переменные. И нет, версии зависит цикл foreach, а цикл for работает одинаково во всех версиях языка.
Вроде это известный прикол
Именно! А в JS оно еще и встречается в десятки раз чаще. А теперь представьте, что Senior C# Developer понятия не имеет об этой особенности
А у меня вопрос, а зачем такое писать на c#?
И ещё, знатокам на засыпку, а если (про версии, и особенности реализации) представим ситуацию когда ядро исполняющие поток цикла после третьей итерации остановится(перегрев) а в этот момент придёт событие на третью кнопку, то есть гарантия что в будущей версии виртуальной машины результат будет 5?
Это вопрос не на знание API, а на понимание замыканий и проблем которые могут быть с ними связаны. Решений этой проблемы можно придумать множество, и знать API тут не нужно. Хотя, конечно же, со знанием API всегда проще.
Не по .NET, а про JS, но я помню у нас был баг связанный как раз с этой особенностью.
У меня было такое, что на позицию js разраба (фронтенд) спрашивали что такое интерфейсы и абстрактные классы с просьбой привести примеры из других языков. Я ответил, но задал встречный вопрос: «А зачем вы задаете такие вопросы js-разработчику?» На что мне ответили в духе «а вдруг мы захотим вас усадить писать бэкенд на Java, а вы не знаете этих терминов». После моей ремарки, что я на Java не писал, писать не планирую, и вообще претендую на роль js-фронтендера, как-то быстро свернули интервью.
Вы и представить себе не можете сколько людей приходят с, казалось бы, солидным опытом, но не могут ответить на элементарные вопросы.
Я пересобеседовал кучу народа на позицию синьора фронтенд. Половина не знает, что такое замыкание. Были и такие, кто не мог ответить чем == от === отличается.
против скайп-интервью есть хороший чит
называется браузер на 2м экране
называется браузер на 2м экране
ну видно же будет как у собеседуемого глаза разъезжаются:-)
Я как-то собеседовал одного соискателя — он такой «э… м… дайте подумать» и стук клавиш в фоне. Даже вебкамера не нужна, всё слышно.
Гугл ему всё равно не помог, т.к. на «открытых» вопросах валятся.
Это был Full Stack Overflow Developer
Это еще фигня, мой знакомый собеседовал паренька азиатской внешности на работе (Сидней). Крутой девелопер оказался, сделали оффер, договорились, что через месяц начинает. Когда начал работать оказалось, что как-то все не так, слабоват по всем фронтам. Только после окончания испытательного срока ребята поняли, что пришел работать совсем другой человек, просто похожий на того, кто был на собеседовании, но было уже поздно.
Кстати да, стук клавиш — это уже притча во языцах. Вывод — надо уметь свайпом на планшете быстро искать, или, чтобы друг в соседней комнате слышал вопросы, гуглил, и в мессенджер с выключеным звуком кидал
Ммм. А работать потом как?
А работать потом можно и со стуком :)
Так выгонят же
Почему выгонят? Вы не гуглите во время работы?
Я вон только в библиотеку бегаю за энциклопедиями по программированию!
Потому, что раз мне приходится вот так поступать во время собеседования, значит я профнепригоден. И это выяснится очень быстро.
Второй вариант почему мне приходится так поступать — это как раз неправильное собеседование и странный работодатель. Но и здесь непонятно зачем туда идти и как потом там работать.
Поэтому не вижу смысла в подобном подходе вообще.
Второй вариант почему мне приходится так поступать — это как раз неправильное собеседование и странный работодатель. Но и здесь непонятно зачем туда идти и как потом там работать.
Поэтому не вижу смысла в подобном подходе вообще.
Навык быстрого поиска правильной информации, по-моему, куда важнее, чем отличное знание редкоиспользуемого оператора. Я вон reduce узнал только на собеседовании, но мне предложили загуглить что это и «может тогда вы решите поставленную задачу» и я решил моментально, как увидел доку к reduce, и получил офер.
То, что для одного — редкоиспользуемый оператор, который можно загуглить, для другого — ежедневно используемый инструмент. Хорошо, если такой «оператор» один, а если их несколько десятков, то как читать и править код?
Через неделю-две эти операторы станут для вас часто используемыми, вот и все.
Точно так же как вы разберетесь со специфическими особенностями архитектуры текущего проекта, узнаете какие-то нетривиальные вещи из предметной области, привыкните к принятым в команде гайдлайнам и т.д..
Как минимум я просто не представляю ситуацию, когда вы меняете работу и на новой все 1-в-1 как на предыдущей, а значит — что то точно будет незнакомо. А если новая предметная область?
Прочесть апи оператора, да хоть десятка — не такая уж проблема, большая проблема — не уметь этого делать. А еще большая — спрашивать даже не загуглив.)
Прочесть апи оператора, да хоть десятка — не такая уж проблема, большая проблема — не уметь этого делать. А еще большая — спрашивать даже не загуглив.)
Потому, что раз мне приходится вот так поступать во время собеседования, значит я профнепригоден. И это выяснится очень быстро.
Мне вот во время работы постоянно так поступать приходится. Если принять, что собеседование проверяет рабочие навыки, то, с-но, придется и во время собеседования.
Если вас собеседует нормальный человек и задает вопрос, ответ на который не считается зазорным загуглить, то вам не придется скрывать от него то, что вы что-то ищете в сети.
Скрывать приходится в двух случаях — если профнепригоден соискатель или если профнепригоден человек, проводящий собеседование.
В обоих этих случаях нет смысла стремиться на эту работу. В первом случае выгонят, во втором быстро уйдете сами.
Скрывать приходится в двух случаях — если профнепригоден соискатель или если профнепригоден человек, проводящий собеседование.
В обоих этих случаях нет смысла стремиться на эту работу. В первом случае выгонят, во втором быстро уйдете сами.
Вообще, я писал с сарказмом. Но если уж восприняли по-серьезному, то на моей памяти реальных случаев, когда программиста выгоняли с работы за незнание вещей, которые спрашивают на собесе, не было вообще. Был 1 случай, когда выгнали за неспособность нормально работать в команде (человек старался увильнуть от работы, и всячески заставить работать других за него, решать проблемы за него, находить причины багов за него — оверхед лида при работе с ним был запредельный). Был 1 случай, когда поменялись ПМ и лид, и выгнали человека, который был реально странным (были проблемы с пониманием коллег, и что от него хотят). И я видел десятки случаев, когда людей отсеивали на этапе телефонного собеседования за неправильный ответ на 1-2 вопроса на знание. Это все объяснимо математически. Отсеять на этапе телефонного собеса == потерять 15 минут своего времени, уже потраченного на собес (по крайней мере, так считает большинство собеседующих), отсеять на этапе испытательного срока == признать свою некомпетентность, как интервьювера (у людей все еще есть предрассудок, что хороший интервьювер не может ошибиться) && потерять дни или недели, потраченные на его обучение && объяснить заказчику, почему вдруг сдвинулись сроки. Поэтому, терпят, дотягивают до нужного уровня, помогают. Если человек, который хитростью прошел собес реально толковый (а чтобы обмануть интервьювера, и при этом не попалится, мозги надо иметь), то, как правило, он все равно достигает необзходимого уровня, и проблема рассасывается сама собой.
Эх, знакомая история. Мне тоже такие попадались. Один еще по русски говорил не очень хорошо. Когда он мало стучал по клавиатуре, то от него приходили довольно развернутые ответы. Я их сразу копипастил в поисковик, по первой ссылке получал источник, откуда он их скопипастил.
В ответ на очередной вопрос он долго стучал по клавиатуре, видимо, не мог найти подходящий ответ, и ответил в итоге вот так:
Собеседование длилось очень не долго, но этот кандидат мне запомнился особенно.
Видно, что салага, опытные используют направленные микрофоны, чтобы посторонние звуки не были слышны))
Там, где я сейчас работаю, проблема самозванцев стояла достаточно остро: около половины кандидатов, выполнивших (якобы сами) тестовое задание, на очном собеседовании демонстрировали полную неспособность к программированию. Решение оказалось неожиданно простым: на первичном техническом интервью (по скайпу) стали просить решить элементарную задачу, типа перевернуть строку. С тех пор проблема исчезла.
А вообще да, очень мало кто умеет нормально собеседовать. Или определяют «на глазок», или совершенно нерелевантные вопросы.
А вообще да, очень мало кто умеет нормально собеседовать. Или определяют «на глазок», или совершенно нерелевантные вопросы.
Способность к программированию — не субъективно ли это?
В последнее время заметил, что большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами. Это всякие Яндексы навязывают тенденцию того, что человек, который умеет хорошо программировать, то он должен без труда решать простецкие житейские задачи на листке.
Зато если этому дяде сказать, что надо по-быстрому написать Backend на коленке с простым Rest-методом, который будет общаться через ORM с БД и брать оттуда первую строчку, позволив ему пользоваться Гуглом, он накидает Backend за 15 минут и еще сверху расскажет, какие проблемы есть, например, в Hibernate с пагинацией и как её поправить.
Тут всё сугубо индивидуально и риск найти самозванца есть всегда. Нужно задавать правильные вопросы и смотреть по ситуации.
P.S. Задания типа reverse() или кастомный стек — это походу классика уже наверное) Я не против заданий, но это не всегда является прямым показателем знаний.
В последнее время заметил, что большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами. Это всякие Яндексы навязывают тенденцию того, что человек, который умеет хорошо программировать, то он должен без труда решать простецкие житейские задачи на листке.
Зато если этому дяде сказать, что надо по-быстрому написать Backend на коленке с простым Rest-методом, который будет общаться через ORM с БД и брать оттуда первую строчку, позволив ему пользоваться Гуглом, он накидает Backend за 15 минут и еще сверху расскажет, какие проблемы есть, например, в Hibernate с пагинацией и как её поправить.
Тут всё сугубо индивидуально и риск найти самозванца есть всегда. Нужно задавать правильные вопросы и смотреть по ситуации.
P.S. Задания типа reverse() или кастомный стек — это походу классика уже наверное) Я не против заданий, но это не всегда является прямым показателем знаний.
Что человек, который каждый день программирует, не сможет в реальном времени написать реверс строки (у нас можно хоть на псевдокоде, мы не требуем, чтобы оно компилировалось) — в это я не очень верю, честно говоря. С «поговорить» у таких кандидатов тоже всегда были проблемы.
Я реверс конечно ни разу не писал, но все таки вы так часто работаете со строками?
Строки в большинстве случаев у нас иммутабельные — это уже заставляет нас какой то промежуточный объект вводить (библиотечный или свой) который бы содержал строку в массиве. А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок… Из за чего если работать просто с массивом байт, и, возможно, даже с массивом символов, можно словить проблем…
Строки в большинстве случаев у нас иммутабельные — это уже заставляет нас какой то промежуточный объект вводить (библиотечный или свой) который бы содержал строку в массиве. А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок… Из за чего если работать просто с массивом байт, и, возможно, даже с массивом символов, можно словить проблем…
У нас специфика предполагает а) достаточно низкоуровневое программирование б) способность решать новые задачи. Поэтому ответ «я не могу перевернуть строку, потому что никогда не работал со строками» — это, наверное, действительно не к нам.
Я не знаю, какой будет пример элементарной задачи в вашей области, мне строки казались достаточно универсальным примером, но я мог отстать от жизни.
Я не знаю, какой будет пример элементарной задачи в вашей области, мне строки казались достаточно универсальным примером, но я мог отстать от жизни.
Хм, ну тогда еще вопрос уточню: используется какая то простая кодировка (размер символа фиксированный, последовательность символов не важна) или одна из кодировок где символы имеют разный размер в байтах и зависят от соседних символов?
Нет, конечно, мы же действительно не нанимаем специалиста по строкам. Если используется эта задача, то всегда уточняется (если возникают вопросы), что имеется в виду zero-terminated ASCII.
Так если не спрашивает — это самым конкретным образом характеризует кандидата
Не знаю про какой язык вы говорите, но если меня просят перевернуть строку не конкретизируя кодировки, тип хранени яи прочее — я исхожу из того, что класс строк умеет отдавать и писать отдельные символы и знает свою длину.
Это считай базовый функционал любой стандартной либы в большинстве языков.
Как меня это характеризует?
Это считай базовый функционал любой стандартной либы в большинстве языков.
Как меня это характеризует?
Гм, могу ошибаться но как минимум в некоторых языках как раз из за разных хитрых кодировок доступ по индексу к символу в худшем случае O(N) может быть.
Хитры кодировки c O(N) — это UTF8 чтоли?
Задача «Перевернуть UTF-8 строку сохраненную в массиве оптимальным способом» звучит совсем не так как «Перевернуть строку». Не находите?
«Перевернуть строку» по умолчанию предполагает абстрактную строку, допущения бессмысленны. Если уточнений нет, значит они не критичны.
Задача «Перевернуть UTF-8 строку сохраненную в массиве оптимальным способом» звучит совсем не так как «Перевернуть строку». Не находите?
«Перевернуть строку» по умолчанию предполагает абстрактную строку, допущения бессмысленны. Если уточнений нет, значит они не критичны.
Исходя из моей практики — я предпочту на всякий случай поуточнять задачу. А то потом у клиента или консультанта который описывал задачу будут вопросы в духе: а этого почему нет? Это же очевидно. А тут не так должно работать. И вообще конкретно этот функционал только в мобильном клиенте должен быть. Зачем вы его в десктопном сделали?
Всё еще не вижу сложности в этой задаче. За миунуту написал как раз решение для любых строк:
fn main() {
let str = "Hello world !";
let reverted: String = str.chars().rev().collect();
println!("{}", reverted);
}Единственное, что я сначала назвал метод revert, но гугл быстренько подсказал, что правильное написание rev. Но я полагаю, на это можно было бы закрыть глаза в любом случае.
Зато тут теперь есть о чем поговорить с кандидатом: какова стоимость разворота итератора, как вообще они работают, map/filter/fold/collect… Разве нет?
Хм, растовый парсер видимо не умеет в UTF8 (между пробелом и знаком восклицания есть символ U+2764). вот на плейграунде: https://play.rust-lang.org/?gist=4e20c472150ea4270906cafe08048ef8&version=stable&mode=debug&edition=2015
Так неважно, какой язык: в нашей с вами работе ( не на собеседовании ) постоянно оказывается, что задача поставлена неполно. И без уточняющих вопросов ее в лучшем случая решить не получится, а в худшем будет потрачено время на решение не той задачи.
Возващаясь же к собеседованию: никто не будет спрашивать у вас, знаете ли вы библиотечную функцию переворота строки, вычисления арккотангенса или преобразования строки в ЗаБоРчИк. Когда дают такой вопрос, желают посмотреть, как вы задачу будете решать. И если вдруг вы знаете готовую функцию для решения этой задачи, что ж, значит вопрос пропал впустую. Датут другой.
Возващаясь же к собеседованию: никто не будет спрашивать у вас, знаете ли вы библиотечную функцию переворота строки, вычисления арккотангенса или преобразования строки в ЗаБоРчИк. Когда дают такой вопрос, желают посмотреть, как вы задачу будете решать. И если вдруг вы знаете готовую функцию для решения этой задачи, что ж, значит вопрос пропал впустую. Датут другой.
В нашщей с вами работе мы знаем над чем работаем.
Если у нас условный UTF-8 и ОЧЕНЬ МНОГО обращений по индексу — у нас будет класс, для работы с UTF-8, в котором под каждый символу будет выделен отдельный буффер и доступ к чару будет по O(1) но зато с потерей оперативки и чуть более долгой загрузкой строки в память.
В реальности в отличии от собеседования задачи существуют в контексте и часто уточнения не нужны, потому что понятно что за задача, откуда она взялась и как должна работать.
Собеседование же максимлаьно абстрактное, не задавать вопросов предполагая некоторое дефолтное поведение — вполне норм. Если собеседующему не понравятся ваши допущения, он уточнит.
Таким образом чаще всего уточнения не нужны ни в реальной работе ни на собеседовании.
Если у нас условный UTF-8 и ОЧЕНЬ МНОГО обращений по индексу — у нас будет класс, для работы с UTF-8, в котором под каждый символу будет выделен отдельный буффер и доступ к чару будет по O(1) но зато с потерей оперативки и чуть более долгой загрузкой строки в память.
В реальности в отличии от собеседования задачи существуют в контексте и часто уточнения не нужны, потому что понятно что за задача, откуда она взялась и как должна работать.
Собеседование же максимлаьно абстрактное, не задавать вопросов предполагая некоторое дефолтное поведение — вполне норм. Если собеседующему не понравятся ваши допущения, он уточнит.
Таким образом чаще всего уточнения не нужны ни в реальной работе ни на собеседовании.
Умение понять условие задачи и объяснить, что решение будет разным для разных строк — один из полезных навыков.
Ну, в таком случае задачка конечно действительно выглядит несложной. Правда в таком случае начинает напрягать вопрос «Где подвох»? Уж слишком просто все на первый взгляд.
Уж слишком просто все на первый взгляд.
Множество «программистов» не может fizzbuzz написать.
Какие уж тут строки и массивы(OMG!)
Наверное я плохой программист — мне пришлось гуглить что такое fizzbuzz.
Писал тут про эту задачу, не помнил как называется, написал fuz buz… Эх)
Потому что лично я настолько простых задачек просто не ожидал бы и поэтому решил бы, что как многие любят — задачка с хитростью.
Не стоит. 80% людей, которые приходят на собеседование на Синиора не могут решить задачу в простейшем виде. Они даже не могут ответить, что значат слова, написанные в их собственном резюме! Например «что такое Design Patterns» или «чем отличается React от Angular», хотя в резюме написано, что он их оба знает хорошо. Не понимаю, на что она рассчитывают. Что будут смотреть только по резюме, на собеседовании не будет тех специалиста и они смогут получить зп за месяц?
Почему, возможный вариант. Это действительно пример теста на человека, который с кодом дела не имеет в принципе. Не знаю, удивитесь ли вы, но таких много стучится.
Вовсе не плохо на мой взгляд. Это показывает, что человек правильно считывает требования из контекста. К тому же все сейчас работают по Agile, и если где-то требования не уточнили сразу, это поправимо.
На питоне правильный ответ на такой вопрос: s[::-1], и это называется знать свои инструменты. Не стоит отвергать очевидное решение потому что оно очевидно.
Правда я не Software engineer и там может быть свой мир, но отбрасывать очевидные решения по причине простоты думаю что все равно не стоит.
В материалах по подготовке к собеседованиям это часто упоминается.
На JS это выглядит как-то так:
str.split('').reverse().join('').
Вот, кстати, интересно мнение сообщества по поводу такого ответа. Мне напрашивается вопрос: «А вы бы применили такое решение в production?». И вот в зависимости от ответа на этот вопрос уже решать, хороший это вариант ответа или нет.
Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект (+ ещё reverse массива этих временных объектов).
На это можно возразить, что преждевременная оптимизация – корень всех зол и всё в таком духе, но это тоже вопрос довольно спорный, т.к. в плане выбора подходящих алгоритмов и структур данных, обычно проще сразу делать «нормально».
Соответственно, если человек отдаёт себе отчёт в побочных эффектах такого кода, и написал просто потому что это удобный однострочник, то всё хорошо. А вот если нет – то это пойдёт в минус, а не в плюс.
Если в JS это хороший способ (например, более эффективный вариант является слишком громоздким или эта конструкция как-то оптимизируется или что-нибудь в таком духе) – мой комментарий можно игнорировать. Как я уже сказал, я с JS не очень дружу)
Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект (+ ещё reverse массива этих временных объектов).
На это можно возразить, что преждевременная оптимизация – корень всех зол и всё в таком духе, но это тоже вопрос довольно спорный, т.к. в плане выбора подходящих алгоритмов и структур данных, обычно проще сразу делать «нормально».
Соответственно, если человек отдаёт себе отчёт в побочных эффектах такого кода, и написал просто потому что это удобный однострочник, то всё хорошо. А вот если нет – то это пойдёт в минус, а не в плюс.
Если в JS это хороший способ (например, более эффективный вариант является слишком громоздким или эта конструкция как-то оптимизируется или что-нибудь в таком духе) – мой комментарий можно игнорировать. Как я уже сказал, я с JS не очень дружу)
Если на продакшине этот код не создает узких мест ( то есть редко вызывается ) то я бы применил нечто простое зато читаемое. Ну при условии что написать более оптимальный либо дольше пары минут, либо он будет намного менее читаемым.
«А вы бы применили такое решение в production?».
Именно такое решение и применяю.
Поправьте, если я не прав, я в JS не очень разбираюсь, но оно ведь создаёт кучу временных объектов безо всякой нужды, а потом собирает их в другой временный объект
Не больше, чем, если вы напишете всё это вручную. По сути, вам придется делать всё то же самое, строки ведь иммутабельные
Помимо сказанного ранее добавлю, что если бы и были мутабельные строки, оптимизировать это почти во всех случаях — что экономить на спичках. Тем более, что код на JS в половине случаев выполняется на клиенте, у которого вполне есть ресурсы (в отличие от сервера, который может быть высоконагружен, и там может хотеться экономить даже на переменных).
Так что — да, это в продакшене широко применяется.
Так что — да, это в продакшене широко применяется.
Тем более, что код на JS в половине случаев выполняется на клиенте, у которого вполне есть ресурсы
Извините, я понимаю, что это решение, судя по ответам, действительно в большинстве случаев приемлемо, но просто не могу удержаться) В итоге имеем то, что имеем)
Если мы реальность берем — я вообще идей не имею кому и зачем могло бы понадобиться строку перевернуть) А так… Я на удивление придерживаюсь мнения противоположного, пользователь должен по минимуму «платить» вычислительными ресурсами, а вот железо на сервере зависит только от того кто сервисом владеет, и он его может масштабировать. Поэтому я терпеть не могу большинство js приложений (в смысле не в браузере, а всякие электроны и подобное) как и некоторые java (память jvm кушает...), но вполне нормально отношусь к такому на сервере)
Давайте представим, что вам для каждого пользователя нужно перевернуть одну строку. Вы можете сделать это на клиенте — для человека это займёт меньше 1 мс! Или же вы можете сделать это на высоконагруженном сервере. Перевернуть строку для 100 000 клиентов скушает пару секунд. Все эти пару секунд сервер (ну или поток, по крайней мере) будет простаивать и не сможет никому отвечать.
Пример утрированный, конечно, но я хотел показать, что операция может стоить для вас очень много, а для пользователя не стоить ничего. Вот именно это я имел в виду, говоря, что клиента нагружать можно больше, чем сервер.
Ну и вообще-то все обычные десктопные приложения замечательно работают на мощностях клиентов, так было всегда, и всем это ок. А вот если попробуете например сделать редактор изображений и реализуете всю графику на сервере, будет интересно посмотреть на его мощности и сколько это будет стоить.
Пример утрированный, конечно, но я хотел показать, что операция может стоить для вас очень много, а для пользователя не стоить ничего. Вот именно это я имел в виду, говоря, что клиента нагружать можно больше, чем сервер.
Ну и вообще-то все обычные десктопные приложения замечательно работают на мощностях клиентов, так было всегда, и всем это ок. А вот если попробуете например сделать редактор изображений и реализуете всю графику на сервере, будет интересно посмотреть на его мощности и сколько это будет стоить.
Понятно что до маразма не нужно доводить, но если есть возможность — то на клиенте лучше оптимизаций побольше на мой взгляд делать. А то потом появляются электроны всякие и подобное из желания вообще не заморачиваться и лепить что попало. Не, понятно что если речь про мелкую строку то оптимизировать смысла нет. А если речь уже про что то существенное? Ну и 50 мс на одну операцию, 50 на другую и привет. И если например есть возможность сделать (за адекватные сроки и без диких хаков усложняющих поддержку) вместо 50мс — 5мс — то это сделать стоит. Потому что пользователь не может взять, и заменить свой ноут на целероне на пк с i9. А вот сервер масштабировать мы можем гораздо проще, поэтому там во многих случаях «на спичках» можно и не экономить (не доводя опять же до маразма).
[...str].reverse().join('') — выглядит короче, работает с сурогатными парами, но не с комбинированными символами.
или так
console.log([..."123456789"].reduce((a,c)=>c+a));Конечно нельзя к строке относится как к однбоайтовой.
К ней надо относится как к абстрактной сущности, которая умеет отдавать длину, и читать/писать символы под индексу. А уж что там внутри — пофиг вообще.
Вас же просят строку перевернуть, а не массив байт изображающих чары в неведомой кодировке.
К ней надо относится как к абстрактной сущности, которая умеет отдавать длину, и читать/писать символы под индексу. А уж что там внутри — пофиг вообще.
Вас же просят строку перевернуть, а не массив байт изображающих чары в неведомой кодировке.
Они превращаются в какую-то угадайку о том, что хотел сказать интервьювер.
По-моему, в таком случае правильно задавать дополнительные вопросы и характр этих вопросов очень хорошо показывает на каком уровне человек решает задачу
В одном из моих недавних собеседований:
— Как бы ты реализовал вот такую систему? (описание требуемой функциональности)
— (описываю возможную реализацию)
— Хорошо, а как бы ты её реализовал на кластере?
— А зачем её реализовывать на кластере? Чего мы пытаемся этим достичь?
— Эээ… Не важно, просто поступило требование реализовать её на кластере.
— Окей, пусть одна нода выполняет вышеописанную реализацию, остальные пусть простаивают.
— Эээ… Ну окей.
— Как бы ты реализовал вот такую систему? (описание требуемой функциональности)
— (описываю возможную реализацию)
— Хорошо, а как бы ты её реализовал на кластере?
— А зачем её реализовывать на кластере? Чего мы пытаемся этим достичь?
— Эээ… Не важно, просто поступило требование реализовать её на кластере.
— Окей, пусть одна нода выполняет вышеописанную реализацию, остальные пусть простаивают.
— Эээ… Ну окей.
Ну как вам сказать… Мне не раз приходил FSD по которому я делал свою реализацию, а потом прибегал аналитик и кричал на меня, что все не так. Хотя все сделано по FSD и работает так как написано в FSD (по секрету скажу, что оказывалось что аналитик просто сделал copy/paste). Потом начинались наезды, что мол если я что-то не понял, то я обязан был задавать вопросы, а не тупо писать код. Т.е. оказывалось, что я должен быть еще и телепатом или уметь читать между строк. Потом наезды начинались и со стороны PM. Который требовал от меня овладеть навыками телепатии.
В других проектах было и так, что притаскивали криво написанный FSD, я начинал задавать вопросы что бы понять что на самом деле стоит за его весьма туманными формулировками. Мне отвечали на «от*бись»: типа делай как хочешь, но чтобы было по FSD и работало, а потом начинались наезды из серии, что раз я задаю так много вопросов, то я плохой разработчик. Ну и конечно прибавлялись снова требования стать телепатом. Потому что моя реализация естественно расходилась с задумкой аналитика.
Короче каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад. Вот на это и нужно проверять человека на собеседовании ;-)
В других проектах было и так, что притаскивали криво написанный FSD, я начинал задавать вопросы что бы понять что на самом деле стоит за его весьма туманными формулировками. Мне отвечали на «от*бись»: типа делай как хочешь, но чтобы было по FSD и работало, а потом начинались наезды из серии, что раз я задаю так много вопросов, то я плохой разработчик. Ну и конечно прибавлялись снова требования стать телепатом. Потому что моя реализация естественно расходилась с задумкой аналитика.
Короче каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад. Вот на это и нужно проверять человека на собеседовании ;-)
каким бы хорошим ты не был, а все равно тебя сделают крайним. Вывод: самый главный скил разработчика — умение прикрыть свой зад
А разве это не должен делать его начальник?
Или его начальник ни зачто не отвечает, в том числе и за действия своих подчинённых?
Косяк подчинённых = косяк начальника в качестве руководителя.
PM свой зад прикрывает. Вот у меня был случай когда работали над проектом где объем работ предполагал наличие как минимум 4-х разработчиков причем не Junior, а работали фактически мы на пару с team lead'ом. Нет, приходили конечно люди, но увидев как все сложно сливались максимум через месяц. Про это не раз говорилось на совещаниях. Но курс был на экономию. В итоге, сроки мы просрали. Крайним сделали team lead'а, вынудив его уволится чтобы сохранить лицо перед заказчиком, а PM пошел на повышение.
Возможно человек англосакс или индус?
Это будет два цикла.
Первый должен будет найти собственно конец строки.
Первый должен будет найти собственно конец строки.
в таком случае, есть вариант с одним циклом, без использования доп. памяти?
По опыту: я провел довольно много (уж не менее 30) собеседований с кандидатам на вакансию программиста C, и мы задавали именно такую задачку на переворот строки.
Формулировка задачи — написать функцию, переворачивающую null-terminated строку, используя минимум памяти. Символы однобайтовые.
Переворот таким циклом, как вы написали — совершенно нормальное решение.
Но — справляются с задачей 25-30% собеседуемых.
Сумма составляется так: примерно 10% пишут правильный код, 10-15% почти правильный или правильный после наводящих вопросов. 5% не понимают, что такое «используя минимум памяти», но строчку переворачивают.
А половина испытуемых даже не могут написать функцию C на бумажке, любую.
Из тех, кто не справляется — говорят все обычно идеально. В итоге мы стали сначала давать задачу, а потом общаться, т.к. жалко времени.
Тем, кто справляется, даем табличку с кодировками символов UTF-8 и просим теперь на тех же условиях перевернуть строчку, состоящую из символов UTF-8. На самом деле, это простая получается задачка. Если человек затрудняется, просим решить дома и написать нам. Из всех собеседований только 1 или 2 человека предложили решение.
Формулировка задачи — написать функцию, переворачивающую null-terminated строку, используя минимум памяти. Символы однобайтовые.
Переворот таким циклом, как вы написали — совершенно нормальное решение.
Но — справляются с задачей 25-30% собеседуемых.
Сумма составляется так: примерно 10% пишут правильный код, 10-15% почти правильный или правильный после наводящих вопросов. 5% не понимают, что такое «используя минимум памяти», но строчку переворачивают.
А половина испытуемых даже не могут написать функцию C на бумажке, любую.
Из тех, кто не справляется — говорят все обычно идеально. В итоге мы стали сначала давать задачу, а потом общаться, т.к. жалко времени.
Тем, кто справляется, даем табличку с кодировками символов UTF-8 и просим теперь на тех же условиях перевернуть строчку, состоящую из символов UTF-8. На самом деле, это простая получается задачка. Если человек затрудняется, просим решить дома и написать нам. Из всех собеседований только 1 или 2 человека предложили решение.
> А половина испытуемых даже не могут написать функцию C на бумажке, любую.
Писать код на C на бумажке будет только мазохист. Чтобы красиво выводить курлявые скобочки пером — это нужно годами не вылезать с собеседований. Жить там. Белый же человек посмотрев на свои каракули вздрогнет, извинится за потраченное время и тихонечко уйдет.
Писать код на C на бумажке будет только мазохист. Чтобы красиво выводить курлявые скобочки пером — это нужно годами не вылезать с собеседований. Жить там. Белый же человек посмотрев на свои каракули вздрогнет, извинится за потраченное время и тихонечко уйдет.
Не проблема, если попросите ноутбук — вам его дадут. Но там 10 строк, стоит ли?
Для меня — однозначно да. Даже если одна строка. Мне настолько комфортнее нажимать на кнопки, чем держать в руках ручку, что я просто буду меньше нервничать и, соответственно, больше внимания уделять самому вопросу.
Некоторым людям удобнее визуализировать код на какой-то поверхности, чем в голове. А экран ноутбука более располагает к правкам, чем листок бумаги.
А вот интересно, люди, дающие задачки на собеседованиях, сами готовы задачки подобные решать? «Задачки» даются, видимо, «со своей поляны», которая с некоторой долей вероятности для собеседуемого (любой квалификации) может оказаться «чужой». Однако и собеседуемый ведь может сыграть в эту игру, и тогда уже собеседующий окажется «на чужой поляне».
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Если что, то простив задач на собеседовании в принципе, и считаю, что нужно уметь обходиться без оных.
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Если что, то простив задач на собеседовании в принципе, и считаю, что нужно уметь обходиться без оных.
Знаете, это мое собеседование, я набираю человека в команду и мне с ним работать. Я не хочу потом работать за него, вместо него. Поэтому я задаю вопросы, которые считаю нужным. Если человек правда считает, что перевернуть строчку на языке C — задачка "со своей поляны", обижается, борется со мной или убегает — наверное я его не возьму. В конце концов, в работе бывают всякие моменты и надо адекватно реагировать. Но я вам могу сказать, что таких не встречал на собеседованиях.
Главное чтобы вы потом сами ответ поняли. Вот у меня как-то было собеседование и там товарищ предложил мне задачку просуммировать биты в байтовом массиве. При этом можно использовать любой язык программирования, а алгоритм должен быть максимально быстрым. Ну я использовал ассемблер для Pentium I. Сделал все как надо. В итоге мой алгоритм загружал все ALU процессора и складывал сразу по нескольку бит. Но тот товарищ не поверил мне что такое вообще возможно. Я нарисовал ему схему алгоритма. Рассказал как все работает, но он не поверил все равно. Типа сказал что так не бывает. Такие дела.
Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Обычно есть некоторое количество кандидатов из которых надо выбрать, и вакансия, на которую надо принять человека. После собеседования N кандидатов примерно понятен их уровень и выбирается уже из них. Если на задачке совсем все заваливаются она просто не достигает своей цели — подсказать кого выбрать из пула. Соответственно задача калибруется.
А вот интересно, люди, дающие задачки на собеседованиях, сами готовы задачки подобные решать?
Я ходил на собеседования к очень крутым ребятам. Иногда меня даже выбивали в зону, где я ощущал себя некомфортно в плане знаний. И это было круто — ты реально общаешься с крутым технарем и вам есть о чем поговорить и ты сам узнаешь свои слабые стороны.
На последнем собеседовании меня гоняли по архитектуре. Ну начиналось все с классики, когда дают пример, ты используешь наследование, а потом контр-пример, который делает наследование неактуальным и ты используешь композицию, потом тебя ставят в еще более неудобное положение, а ты ищешь из него выход.
И всё это на белой доске маркером. В такие моменты ты просто общаешься с прогерами, делишься опытом, рассказываешь, как ты в реальной жизни стыкался с этими проблемами и как их решал.
Про это кстати недавно наткнулся на интересное решение этой проблемы: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/. Для кого-то может и очевидная штука, а я вот был крайне удивлен.
Мсье знает толк в извращениях! Нет, такого не было. Но вот раз человек использовал alloca для экономии памяти, считая, что эта функция не использует память (в понимаемом им смысле). А ещё раз, на другом тестовом задании, видел использование setjmp/longjmp — вот это было круче всякой рекурсии. Фамилия кандидата была не Ричи, если что.
А насколько часто вам приходится проводить код ревью для реализации функции, которая переворачивает строку с оптимизацией по памяти?
Я не говорю о том, что задача сложная или как-то оценить вас или качество кандидатов. Я пытаюсь понять насколько ваш вопрос имеет отношение к задаче, которую вам поставил бизнес.
Я не говорю о том, что задача сложная или как-то оценить вас или качество кандидатов. Я пытаюсь понять насколько ваш вопрос имеет отношение к задаче, которую вам поставил бизнес.
В принципе, это релевантная задача: мы занимаемся embedded, так что об экономии памяти нужно думать всегда. Но настоящая цель такой задачи — просто отсечь самозванцев, как это было метко подмечено в комментариях ниже.
Вообще "по бизнесу" в моей области можно поговорить о многом, человек не может знать всего, но он может имеет необходимые для работы качества, и мы его сразу возьмём. Поэтому, никаких сложных вопросов по программированию я не задаю, просто хочется знать, может он программировать или нет — для оценки нужности разговора.
Экономия памяти — это хорошо. Но умение решать одну задачу никак не говорит о способности думать об экономии памяти системно. Если вы пользуетесь задачей для первичного фильтра — ок, но как вы копаете дальше в эту тему?
Дальше нужно разговаривать. У нас требуется, в идеале, много разных знаний и опыта. Найти при этом человека, который ещё и действительно системно мыслит -большая удача. Тут уже речь не об отсеивании кандидатов, скорее поиск потенциала роста. Но даже если системное мышление хромает, найти применение в целом хорошему специалисту можно.
Я не знаю, какой будет пример элементарной задачи в вашей области, мне строки казались достаточно универсальным примером,
FizzBuzz же: выведите n строк — k-ая строка должна начинаться с числа k. Потом содержать Fizz, если k делится на 2 и/или Buzz, если k делится на 3:
1
2 Fizz
3 Buzz
4 Fizz
5
6 Fizz Buzz
...```Это уже следующий уровень сложности. Тут надо понимать, что такое «делится на 2», «делится на 3» и «делится на 6» и как эти множества друг с другом соотносятся. А если человек забыл, что такое делимость? Или в реальных проектах работает исключительно с float? Или настолько продвинутый алгебраист, что не может решить, в каком кольце ему эту задачу решать? В общем, со строками как-то спокойнее.
А если вспомнить что далеко не все (да что уж там, как мне кажется мало кто) разбирается во внутреннем устройстве кодировок…
Ну, раз пошла такая пьянка пошёл разговор о внутреннем устройстве кодировок, то помните, что Вы сами напросились.
Я б на все такие вопросы отвечал: «как вам удобнее».
А еще лучше, уже на вопросе
Переключился на эту тему и узнал, как бы он это реализовывал
Ну или здесь, тоже ведь отличная тема!
Интересное замечание про шифрование и сжатие. Я бы с удовольствием послушал, как он бы решал эту проблему.
В итоге и сам, может, чего новое узнал и оценил уровень знаний человека и собес совершенно нестандартный и интересный.
А еще лучше, уже на вопросе
Должен ли я предусмотреть защиту от атаки через подмену букв со сходными начертаниями (например, турецкой I)?
Переключился на эту тему и узнал, как бы он это реализовывал
Если только речь не идёт о копировании файла самого в себя (это тоже интересный вопрос...)
Ну или здесь, тоже ведь отличная тема!
Не хочу отклоняться от темы, но мне кажется, что такое поведение создаст серьёзную дырку в безопасности. Особенно в случае если файловая система, на которую мы копируем файл, поддерживает произвольные атрибуты (прямо или косвенно).
Интересное замечание про шифрование и сжатие. Я бы с удовольствием послушал, как он бы решал эту проблему.
В итоге и сам, может, чего новое узнал и оценил уровень знаний человека и собес совершенно нестандартный и интересный.
Я бы в уме поставил + такому человеку за технические навыки, и — за конструктивность и желание сотрудничества (после попытки объяснить явно что от него в целом требуется на собеседовании типа «напишите копирование файлов без учета всех этих тонкостей, а потом расскажите про компромиссы на которые пришлось пойти для скорости написания»)
Тебе нужен специалист, который шарит в необходимых технологиях и у него проекты есть, и вроде понимание как это должно работать, какие есть проблемы — экспертиза одним словом. И ты ему не даш шанс из-за того, что он на бумажке не может код написать?))
Недавно книгу одну читал, что люди очень любят производить оценку по себе. Все что тебе кажется очень легким, очевидным и простым, для другого может оказаться не так тревиально. Поэтому, если уж человек не совсем идиот и я вижу энтузиазм, желание работать и развиваться, то почему бы не дать шанс? Ааа, он же кодить на бумаге не может… Что ж, будем искать человека который может...
Как вы определяете, что такое «не совсем идиот»? Наше определение включает способность решить простую программистскую задачу. Но даже если бы и не включало — из тех «самозванцев», что приходили к нам, не было такого, чтобы человек не мог написать код, но демонстрировал экспертные знания (или хоть какие-то знания) в указанных с резюме технологиях.
Мы добрые, правда =) Это все задачи не для того, чтобы подловить, а чтобы отсеять тех, кто тупо не знает, что такое «переменная», «цикл» и как ими пользоваться.
Суть в том, что есть куча людей, которые как замечено ниже не понимают что такое переменная и цикл.
А зачем такие люди идут на собеседование на должность программиста, на что они рассчитывают? Работать-то придется все равно. Странно получается, я никогда не работал в должности программиста, хотя и написал пару простеньких программ на C++/Qt5 (вроде калькулятора и маленького оракл клиента отправляющего заранее написанные запросы из конфиг файла с пользовательскими параметрами в базу и вывод результата в человекопонятном виде), но я не суюсь на собеседования потому что понимаю, что этого мало даже для джуниора, а приходят люди не знающие что такое цикл?!
Суть же не в том чтобы сразу написать идеальное решение, а представить ход мыслей и сколь-нибудь разумное решение, в котором смочь увидеть проблемы (возможно с подсказкой) и предложить решени
Быстро и без ошибок и я не видел. Видимо, они все в Яндексе трудятся)
Вот быстро и с ошибками — видел. Особенно интересно, когда такой человек работает в ночь, а ты утром приходишь и все поломано в разных местах) Правда человек за ночь делает то, что я делал в среднем за неделю, но отлавливать и чинить… В общем, есть специфика)
Вот быстро и с ошибками — видел. Особенно интересно, когда такой человек работает в ночь, а ты утром приходишь и все поломано в разных местах) Правда человек за ночь делает то, что я делал в среднем за неделю, но отлавливать и чинить… В общем, есть специфика)
можно предположить, что кандидат которого взяли или делал меньше ошибок, или предложил более элегантные решения, или еще как-то был «на одной волне» с интервьюером.
В собеседованиях так или иначе большая доля везения.
В собеседованиях так или иначе большая доля везения.
Ситуации, конечно, разные бывают. Но вы уверены, что дело обстояло именно так, как вам казалось? Т.е. могло же быть что, например, больше 50 процентов решения было подсказано интервьюером или же что вы тратили много времени на концептуально неправильное решение итд? Я обычно пытаюсь помочь канадидату дойти до решения, но это не значит, что любой решивший — это сильный кандидат.
Во-первых, суть в том, что задачу вы и не должны знать. Во-вторых, идеального решения никто не требует, с чего вы такое взяли? В-третьих, это вам кажется, что ни у кого получается. Может быть на самом деле эту задачу без проблем решает на достаточном уровне 70 процентов кандидатов?
Это не так. На собеседования в крупную компанию нужно готовиться
Нужно готовиться или нет — это зависит от ваших знаний/бэкграунда. Суть в том, что вам надо показать, как вы справляетесь с новой задачей, а не как рассказываете заученное решение. Поэтому желательно задавать задачу, которая по крайней мере не входит во всякие «топ вопросы для интервью».
Так требуют или не требуют? Вы определитесь, а то по второму кругу спорить начнем.
Т.е. для вас существует только концептуально неправильное решение и идеальное решение.
Вот видите, вы продолжаете настаивать на моей некомпетентности основываясь на часовом тесте
Я не «настаиваю», а только предполагаю вашу некомпетентность в рамках интервью. Я не пытаюсь ничего сказать об эффективности интервью в оценке ваших компетенций.
Почему же ее не смогли определить мои работадатели за 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
Кстати, это значит что интервьюер внимательно проревьюил ваш код — причем моментально, и нашел там вырожденный случай
Ну нет же, интервьюер знает эту задачу и приготовил вырожденные случаи, и знает на что смотреть. У него время на подготовку было бесконечно и никакого давления, в отличие от.
Зарабатываю на программировании уже 20 лет.
В 99% случаев тормоза не имеют отношения к моей программе — в реальных проектах тормоза в СУБД, сети и пр. внешних факторах.
Просто «в вакууме» оптимизация алгоритма (логарифм/квадратичный и т.п.) сама по себе толку дает мало.
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
В 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), но не помнишь порядок аргументов в одной из функций, а гуглить нельзя, спросить нельзя, рассказать нельзя — сиди и создавай неловкую паузу.
но не помнишь порядок аргументов в одной из функций, а гуглить нельзя,
В адекватных конторах это обычно не проблема. Я на одном собеседовании просто сказал, что вот не помню порядок аргументов и точное название стандартного метода. Собеседователь сказал, что это вообще неважно, итак на псевдокоде пишем. Никаких проблем не было.
Да, вот просто взять и посчитать, сколько слов содержится в стринге.Просто взять и посчитать, говорите? Я бы не хотел работать с вами, если вы всё делаете «на отвали» — так же, как ставите задачи. Потому что «Иван, завари чай» — это три слова. А «завари иван-чай» — это два слова. Дьявол кроется в деталях.
Зачем такие сложности на собеседовании? Достаточно проговорить, что да — могут быть такие-то подводные камни, и решить первым попавшимся в голову вариантом/вариантами. Важно ведь мышление. Первое, что пришло мне в голову — посчитать по количеству пробелов. Или сделать .Split(' ').Count(). Это 100% не самые идеальные варианты решения, но идеальные в общем-то и не нужны, хотя может в Яндексе иначе думают.
Это подколка на тему того, что кто-то смог бы посчитать любые не_буквы символами-разделителями слов?
Это подколка на тему того, что дефис может быть как частью слова, так и разделителем слов. И без словаря нельзя один случай отличить от другого.
дефис может быть как частью слова, так и разделителем слов
Это где дефис является разделителем?
Когда ставится между определяемым словом и приложением, например.
Это у человека был намек на то, что в типографии существует аж 5 разных символов для одной-единственной черточки (дефис, минус, короткое тире, тире, дефис-минус), у каждого из которых свое назначение. Разделяют через тире, а дефисом переносят. Чушь полнейшая, но так уж исторически сложилось.
В том-то и фокус, что в русском языке часто бывает что два разных слова пишутся через дефис. Именно через дефис, а не через тире.
А можно пример? Потому что обычно эти два «разных» слова считаются после этого одним словом. «Иван-чай», к примеру, одно слово.
Говорю же: когда дефис ставится между определяемым словом и приложением.
Вот прямо из Википедии: ковёр-самолёт, монах-аскет, Волга-матушка, Москва-река, Иван-дурак, Соловей-разбойник, сторож-старик…
Одним словом два разных члена предложения не могут быть никак.
Вот прямо из Википедии: ковёр-самолёт, монах-аскет, Волга-матушка, Москва-река, Иван-дурак, Соловей-разбойник, сторож-старик…
Одним словом два разных члена предложения не могут быть никак.
Да, действительно.
Из собственно грамматических критериев выделения слова известностью в отечественной лингвистике пользуется критерий цельнооформленности А. И. Смирницкого. Согласно этому критерию сочетание морфем признается одним словом, если грамматическое оформление при помощи соответствующей служебной морфемы получает все сочетание в целом, а не каждый из его членов. Например, иван-чай — это одно слово, так как при склонении все сочетание в целом оформляется одной флексией: иван-чая, иван-чаю, а не *ивана-чая, *ивану-чаю.
В противном случае, когда каждый член сочетания получает свое оформление, — это называется раздельнооформленностью — сочетание признается двумя словами. Например, город-герой — это два слова, ср. города-героя, городу-герою и т. д.
В.Б. Касевич «Элементы общей лингвистики»
Добавлю, что в нерусских языках с определением слова всё ещё сложнее. Буквально только что на Language Log обсуждали, что во вьетнамском просто вообще нет определения слова. В других азиатских языках пробелы между словами необязательны, и делить строку на слова можно только по словарю.
Разделяют через тире, а дефисом переносят. Чушь полнейшая, но так уж исторически сложилось.
А почему чушь? Семантически же это разные случаи?
Потому что по сути это просто черточка, разного размера. Я, к примеру, определяю ее значение из контекста, а не вычисляя размер «ага, 3 миллиметра, значит — дефис».
Опять же, хоть кто-то, кроме профессиональных типографов/верстальщиков, набирая текст, пользуется тремя различными символами? Я, к примеру, везде ставлю минус: и как минус, и как тире, и как дефис. Лишняя головная боль только, их порядковые номера в юникоде запоминать.
Опять же, хоть кто-то, кроме профессиональных типографов/верстальщиков, набирая текст, пользуется тремя различными символами? Я, к примеру, везде ставлю минус: и как минус, и как тире, и как дефис. Лишняя головная боль только, их порядковые номера в юникоде запоминать.
А в каких случаях нужно ставить именно m-dash(длинное тире), а в каких n-dash(короткое тире)?
а по факту человек не может написать простую считалку слов
Сло́во — одна из основных структурных единиц языка, которая служит для именования предметов, их качеств и характеристик, их взаимодействий, а также именования мнимых и отвлечённых понятий, создаваемых человеческим воображением.
Что-то мне кажется тут без сильного ИИ и бигдата не обойтись:)
Не все могут под пристальными взглядами нескольких человек написать даже псевдокод.
На собственном опыте убедился, что легко могу войти в ступор, когда резко посреди беседы просят перевернуть биты в int32.
На собственном опыте убедился, что легко могу войти в ступор, когда резко посреди беседы просят перевернуть биты в int32.
Я не сторонник циничного подхода, что, дескать, если отсеяли, что не повезло тебе, чувак. Но всегда приходится исходить из того, что реализуемо на практике. Человек, впавший в глубокий ступор, внешне не отличим от человека, который ничего не знает и не умеет. Я стараюсь всегда смягчать стресс, предлагать альтернативные вопросы, если на каком-то зависли, но, наверное, остается возможность что кто-то может отсеяться несправедливо.
Это замечательно, когда у человека есть бэкграунд, который можно отследить, но если возводить это в правило, то получается, что мы должны отсеивать
а) Тех, у кого нет знакомых среди сотрудников
б) Тех, кто не работал в OpenSource
в) Тех, кто не писал статей
А у нас совершенно нет причин этих людей отсеивать.
а) Тех, у кого нет знакомых среди сотрудников
б) Тех, кто не работал в OpenSource
в) Тех, кто не писал статей
А у нас совершенно нет причин этих людей отсеивать.
Ну вот лично мне кажется, что лучше дать человеку шанс проявить себя, чем делать его заложником его биографии. Но это во многом вопрос вкуса, я понимаю.
Это всего лишь вопрос гибкости интервьюера. А так же желания, мотивации и свободного времени, разумеется.
Просто нужно читать резюме ДО собеседования и, если там указаны ссылки на проекты или статьи, то ознакомиться с ними, чтобы заранее составить первое впечатление о человеке(к вопросу о гибкости — первое впечатление не всегда верно, поэтому надо уметь абстрагироваться от первой оценки, если что-то пошло не так). И затем на собеседовании отклониться от своего дефолтного плана, да может задать пару вопросов из проекта\статьи человека. Это даст куда больший отклик о человеке, чем «возможность проявить себя» в виде задачи, которую нужно написать на листочке. И, вдобавок к лучшему отклику, ещё наиболее приятное впечатление останется у человека о компании, в которой интервьюеры, наконец-то, снизошли и хотя бы поинтересовались бекграундом человека, который был указан в резюме. Даже в случае отказа впечатление с хорошей вероятностью будет лучше.
Однако у этого подхода есть один минус — время.
Помимо времени на собеседование ещё нужно уделить определённое время на чтение и изучение кандидата. Это может занять 5-20 минут в оптимальном случае. А в случае, если из 10 кандидатов 3 оказались с таким «бекграундом», то времени нужно затратить 5-20 минут на КАЖДОГО из них, что в случае большой текучки и кандидатов может оказаться расточительно.
А в случае одной вакансии и тех же 10 кандидатов, как по-мне, можно уделить этому время. Если не на проекты, на изучение которых может уйти достаточно много времени, то хотя бы на чтение статей, которые написал и указал кандидат.
Но… зачем? Зачем тратить своё драгоценное время на каких-то кандидатов, верно? ;)
p.s. посыл не конкретно к OYTIS, а в целом к интервьюерам любого толка. Проводить интервью — это не легкая затея и к этому делу нужно готовиться, а не просто плыть по течению.
Просто нужно читать резюме ДО собеседования и, если там указаны ссылки на проекты или статьи, то ознакомиться с ними, чтобы заранее составить первое впечатление о человеке(к вопросу о гибкости — первое впечатление не всегда верно, поэтому надо уметь абстрагироваться от первой оценки, если что-то пошло не так). И затем на собеседовании отклониться от своего дефолтного плана, да может задать пару вопросов из проекта\статьи человека. Это даст куда больший отклик о человеке, чем «возможность проявить себя» в виде задачи, которую нужно написать на листочке. И, вдобавок к лучшему отклику, ещё наиболее приятное впечатление останется у человека о компании, в которой интервьюеры, наконец-то, снизошли и хотя бы поинтересовались бекграундом человека, который был указан в резюме. Даже в случае отказа впечатление с хорошей вероятностью будет лучше.
Однако у этого подхода есть один минус — время.
Помимо времени на собеседование ещё нужно уделить определённое время на чтение и изучение кандидата. Это может занять 5-20 минут в оптимальном случае. А в случае, если из 10 кандидатов 3 оказались с таким «бекграундом», то времени нужно затратить 5-20 минут на КАЖДОГО из них, что в случае большой текучки и кандидатов может оказаться расточительно.
А в случае одной вакансии и тех же 10 кандидатов, как по-мне, можно уделить этому время. Если не на проекты, на изучение которых может уйти достаточно много времени, то хотя бы на чтение статей, которые написал и указал кандидат.
Но… зачем? Зачем тратить своё драгоценное время на каких-то кандидатов, верно? ;)
p.s. посыл не конкретно к OYTIS, а в целом к интервьюерам любого толка. Проводить интервью — это не легкая затея и к этому делу нужно готовиться, а не просто плыть по течению.
А какие ограничения? память, скорость, кривой ЯП?
1. если в лоб то выделяется буфер и вставляются значения перебором с конца
2. если экономим память, то читаем хвост и голову и меняем их в цикле
3. string.Buffer.Reverse
1. если в лоб то выделяется буфер и вставляются значения перебором с конца
2. если экономим память, то читаем хвост и голову и меняем их в цикле
3. string.Buffer.Reverse
public static string ReverseString( this string input ) {
var temp = new List<string>();
var e = StringInfo.GetTextElementEnumerator( input );
while ( e.MoveNext() )
temp.Insert( 0, e.GetTextElement() );
return string.Concat( temp.ToArray() );
}Ну как, я прошёл испытание?
string.Concat( "Hello World".Reverse() )Оценил разницу, спасибо
Я лично так и решаю, потому что это полностью подходит под определение "Разверните строку". Если добавят ограничения в стиле "UTF8-строку" я просто откажусь делать, потому что я прекрасно представляю, насколько это трудоемко, и у меня нет соответствующей квалификации.
Это не UTF8 — это UTF16 (т.е. внутреннее представление С#). Если этого не учитывать, то код будет некорректно работать на некоторых языках. (см surrogate pairs)
Еще раз, этот код работать корректно будет во всех случаях только в ASCII чарсетах. Ну и возможно будет еще корреткно работать в UTF16 сценариях. Про UTF8 я уже сказал — в шарпе нет нормальных средств работы с ним. В нешарповом коде это легко делается аналогично, ссылку я чуть выше давал.
На шарпе для UTF8 я просто не буду реализовывать- слишком сложно для тестового задания.
На шарпе для UTF8 я просто не буду реализовывать- слишком сложно для тестового задания.
При чем тут вообще разные кодировки. В С# внутри используется UTF16, все строки в ней. Если строка в другой кодировке — это массив байтов, а не строка. Строка UTF16 может содержать суррогатные пары.
Я к тому, что C# строка может содержать UTF-8 символы, но любые попытки работать с ними стандартными средствами (вроде того же reverse) развалят её: https://ideone.com/vRT9OG
Да при чем тут UTF-8? И что такое «UTF-8 символ»?
UTF-8 при том, что это по сути единственная кодировка переменной длины, используемая на практике. Это обстоятельство делает разворачивание строки сильно сложнее, чем в случае с кодировкой символами фиксированной длины.
То, что называется UTF-8 code point.
И что такое «UTF-8 символ»?
То, что называется UTF-8 code point.
Откуда взялся UTF-8 code point в UTF-16 строке?
UTF-8 при том, что это по сути единственная кодировка переменной длины, используемая на практике.
В UTF-16 есть суррогатные пары. Почитайте википедию
Да, но мы имеем доступ по индексу. Взяли i, взяли len — i. Если второй оказался суррогатной парой, взяли еще один перед ним. Гарантий того, что мы не разобьем символ на части достаточно, чтобы развернуть суррогатные пары в том числе.
Сурогатную пару надо поставить на место одного символа, а один символ на место суррогатной пары
Так это не сложно ведь сделать. Основная проблема UTF-8, из-за которой в нем это не поможет, что взяв i-й байт мы не можем ничего сказать ни про него, ни про окружающие символы.
Во-первых, в C# строки состоят не из байт, а из двухбайтовых «символов».
Во-вторых, для любого «символа» можно однозначно определить чем он является — одиночным символом, первым суррогатом пары или вторым.
Во-вторых, для любого «символа» можно однозначно определить чем он является — одиночным символом, первым суррогатом пары или вторым.
Ну ок, тогда задача не такая сложная. Был не прав. Хотя на собеседовании знать диапазоны UTF-8 вряд ли получится вспомнить.
И все-таки, при чем тут UTF-8? Вам уже пять раз сказали, что строки C# не используют эту кодировку.
Потому что литерал C# строки может содержать эти символы. Я уже показывал пример выше.
Литерал C# строки состоит из символов в той кодировке, в которой написан файл исходного кода. Но это не имеет ни малейшего отношения к тому что происходит в рантайме.
Да я понял в чем моя ошибка, спасибо.
В качестве домашнего задания сделал разворот UTF8 строки. Не скажу, что невозможно, но довольно нетривиально, потратил больше часа.
В качестве домашнего задания сделал разворот UTF8 строки. Не скажу, что невозможно, но довольно нетривиально, потратил больше часа.
s[::-1] подойдёт?
Способность к программированию — не субъективно ли это?
А чего тут субъективного? Есть способность писать код — напиши. Не смог — нет способности писать код.
большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами
Про бумажку, вроде, речи не шло, впрочем, я искренне не понимаю в чем проблема написать код на бумажке. В чем?
позволив ему пользоваться Гуглом, он накидает Backend за 15 минут
Да, таких cut-n-paste "дяденек" пол-Индии. Если вам нужны "индусы", то нет проблем — набирайте таких. Очевидно, автору обсуждаемого комментария нужны более другие разработчики.
Я не против заданий, но это не всегда является прямым показателем знаний.
А ни кто и не рассматривает это прямым показателем знаний. Это фильтр. И это ОЧЕНЬ эффективный фильтр.
Не все пишут код линейно от первого до последнего символа. Некоторые вставляют строки выше уже написанного, редактируют уже написанное, потому что на лету приходит решение сделать немного иначе. На бумажке это затруднительно.
Да, ладно, это уже какие-то совсем смешные придирки. Почеркал, переписал заново, написал сбоку, пририсовал стрелочку :). Это же все в непосредственном режиме происходит, собеседователь видет что происходит. Проверяется ведь не чистописание кода, а способность к программированию. В конце-концов, в таких случаях не дают же задачи написать реализацию поискового движка гугла, там что-нибудь простое. Говорят, иногда предлагают за компьютером такое проделать, но я как раз за компьютером бы сильнее растерялся — возможно незнакомая иде, окружение, клавиатура. От волнения пальцы не по тем кнопкам попадают (был такой опыт) — ужос, короче. По мне, так лучше на бумажке. Несмотря на то, что кроме собеседований я код на бумажке 30 лет назад последний раз писал (а потом набивал его на перфокарты!). Вообще, на бумажке на собеседованиях приходилось самое большое 5-7 строчек написать. Чаще код на собеседованиях писал во время скайп/телефонных собеседований в какой-нибудь веб-среде, предоставляемой собеседователем. Что-то вроде гугло-доксов. Там можно и исправлять и строчки вставлять и задачки уже не на 5 строк бывали, а аж на целых 10! :)
Вот прям с языка сняли
Есть навыки решать конкретные задачи в конкретной области, а есть общая база и умение находить подходы к решению задач. В зависимости от проекта могут быть нужны разные люди.
Проблема собеседующих в том, что нередко они хотят найти человека сильно круче, чем им реально надо.
Проблема собеседуемых в том, что они почему-то думают, что если они научились решать конкретные задачи в конкретной области, то они программисты in general и все должны их хотеть.
Проблема собеседующих в том, что нередко они хотят найти человека сильно круче, чем им реально надо.
Проблема собеседуемых в том, что они почему-то думают, что если они научились решать конкретные задачи в конкретной области, то они программисты in general и все должны их хотеть.
Как он это сделал? Есть unicode символы такие? Oo
Это символы, похожие на перевернутые русские буквы, надерганные из разных наборов unicode.
Есть онлайн и не-онлайн генераторы, которые переворачивают атоматически
ʚ — например этот символ latin small letter closed open e (U+029A)
ʎ — очевидно, лямбда
итп
Есть онлайн и не-онлайн генераторы, которые переворачивают атоматически
ʚ — например этот символ latin small letter closed open e (U+029A)
ʎ — очевидно, лямбда
итп
разрешите докопаться, лямбда пишется в другую сторону — вот так λ. А вот эта ʎ в юникоде описывается как Latin Small Letter Turned Y. Что наводит на мысли, что можно не надёргивать буквы из разных алфавитов, а использовать имеющиеся в юникоде готовые перевёрнутые символы (ну, очевидно это для латиницы, некоторые кириллические символы таки придётся поискать).
Ребята, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не а̦̮̭͖́р̬̰̞х̹͇̲͎͡и̥̪̟̳в̪̕ы͜ ̲̲ спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я̢͓͙ ͙̺͔͖͉̫̻в̗̼̪͖̖̟͖п̢̲̖͎̣̤̹͇о͏л̣̠ͅн̜е͙̙̹̘̘ ̹̤̳͔ͅп̛̹̲͕̟̪̘̝о̭̟̙͚͇н̷̮̲̝̱̫и̤м̥̱̩͓̮̭̹а̙̪̰̞̻̰ͅю,̘͘ ͚̱̘̙̯̀ч̥͙͇͎т̹̹о̢̺̫̜͔̥͍͉ ̢̮̬д҉̟͍̪а̝н̡н͔͇ым͞ ͚с͏̰̣оо̳̪̲͔̰̲̕б̬̦̗̼̱͓̣щ͔е̧̲̗͈̫н̱̻̙́и̭͚ем̛̰ ̳̩в͖͍͕̥͎̻ы͉̣̖͕з̯̝͚̹о̲͎̭̥̯͔в̛̘у̝̟͙̹̲͡ ̙̤д̩̪̻̦о͉̞̫п̣͚͙͎͔͉͡о̸͚̥л̣͎̝͕н̟͖̖̯̘и̲̫̤т͎̥̣͎͕͇͙ел̕ь̱͚͕̯̭̤н̖̩̯̩̘̘̘ы̞̯̟̥͉͈̯͝й͍ͅ ̢̬̝и͍̙͕̮н҉̱̼̫̣͖̖̤т̯̙̻̗̙̹е̷̯͎р̢̺̯̠̻ͅе̸͍͔̼͈̯с̻̟͕̹̰̗͍,̜̪ ̺̲̙͈̘͘н̻о̡͓ ̛х̼̻̭͓о̸͍̞̝̞̹ч̀у̘͍̭͙̯͕̤͘ ̬͈͈̰̘͜ͅс͈̺р̞͍а̟̤͕̜̤з͇̼ͅу̷͎ ҉͖̻̭̟п͓̝̗̥̘͘р̷̻̰̖е҉͎д̝̮̯̠̩̘̠о̞͔͙͘с͢т̡͓̬ͅе͈̖̮͔̘̞̼͢р̘͚̲е͎͙̹̼͍͟ч̟͎ͅь̭̮̤̩͎͢ ̪͉͍͈͚п̱̯̣̦̱̳ы͡т̗̮̞̩̹͘ли̻̖̻͝в̬͍̳̦͕͢ы̭̪̺х͍͇̱̥̖̫̕ͅ ̳̺̺̻ͅ-͈̙̭̗̲ ͔̕с̡̗̝̤ͅт̹͕̺͞ͅо̡̻̼̭͍̘͚͎п̮͕̟͞.͓̲̬̜͢ ̡̖О҉̘͔̫ст̝͖͔̗̘͕͇а̭͓̯͙͎͢ͅл̯̞̳̖͍͚̩̀ь̱̕н̜̭͚ͅͅы̱̠̙̲е̬̫͙͙̣̹̕ ͚̱̜п̫р̰̝̖̪̣о̛̱̪̜̝̥̝с̵̦̖т̧͍͍̩̫ͅо͉̫̠̱ ̨̹̤н̺͈̹̭̹̤̟̀е҉̼͍̦̻ ̯̥͖̗̹н̮͈̭͚̟а̗͎̫̟й̜̣͓͡ͅд͉̭̯̘͍͙͟у̣̙͇̺͞ͅт̙̬̜̦͕͉.̰̙ О̫͓̺̹̘͉̰͑ͯͯ̒͘͘н̸̯͕̤͕̳͎̯̹͍̘̗͇͎͎̯͎̯̂́ͮͤ͆͝͠и̵̛͕̜̗̰̰ͧ̂̈ͬ̐̾̍͌ͥ̽ͨͥͨ̓ͯ̀̿͡ ̧ͦ͂̅͋̊̃ͮ̋ͧͫͩͭ͋̑͌̋̚̚͟͝҉̬̦͚̯̻и́̈́͆̏̆͌͌̇̀ͮͧͩ̆ͫ̈̐͏̛̙̦̮̳̯̯̭̹̭̭͎̩͎͇̰̪̖͘͜͠ͅͅд͉̪̘̳͙̺͉̱͗̍̈́̎̄͢͠у̴̛̣̟͎̞͎̰̩ͫͫͨ̒̀̃̚т̛̯̰͍̲͓̤̣͍͔͇̗̈́̆ͬ̊͋ͨ̐̔̈́͛̋͌͋̾̀̕͝͡!̷̧͚̬͖̜̟ͦ͂͆͐̽̆̽̄͆̑̔͒̏͐̊̈́̓̃ ̶̴̡́̋̓̾̀̆̇̊̑̀̎́͏̦̭͔̯̱͎̮̹Z̧ͯ̓̌̀̔̿̄̐̔̐̆ͬ͂̓ͫ̃ͤ͏̶̨͖̭̥̭͚̱͖̖͖͚̯͍̤̳͉̮͍ͅĄ̷͍̬͍̱̗̤ͤ̾̓̂̍̿͒͋̓ͮ̒͗͂͂ͥͪ̓̍ͯ͘Ḻ̵̸̤̺̳̞̺̹̣̮̦̥͉͔͖ͤͧͫ͒͐̌̈́ͩ͌́ͧ͐̑̃̌͝ͅG͉̙̻̯̿͌̃̿͒̐̓͢͡͝͠ͅO̶̫̪̳̼̬͇̙̪͚ͤ͊ͪ̔ͪ͝͞!̶̱̼̗̥̼̗͎̹͔̬̥̙͎̇̐̒̅̒̉͑̇̏́͟͜
о, круто. теперь реально можно «ср*ть в комментах» :-D
д͉̭̯̘͍͙͟у̣̙͇̺͞ͅт̙̬̜̦͕͉.̰̙ О̫͓̺̹̘͉̰͑ͯͯ̒͘͘н̸̯͕̤͕̳͎̯̹͍̘̗͇͎͎̯͎̯̂́ͮͤ͆͝͠и̵̛͕̜̗̰̰ͧ̂̈ͬ̐̾̍͌ͥ̽ͨͥͨ̓ͯ̀̿͡ ̧ͦ͂̅͋̊̃ͮ̋ͧͫͩͭ͋̑͌̋̚̚͟͝҉̬̦͚̯̻и́̈́͆̏̆͌͌̇̀ͮͧͩ̆ͫ̈̐͏̛̙̦̮̳̯̯̭̹̭̭͎̩͎͇̰̪̖͘͜͠ͅͅд͉̪̘̳͙̺͉̱͗̍̈́̎̄͢͠у̴̛̣̟͎̞͎̰̩ͫͫͨ̒̀̃̚т̛̯̰͍̲͓̤̣͍͔͇̗̈́̆ͬ̊͋ͨ̐̔̈́͛̋͌͋̾̀̕͝͡!̷̧͚̬͖̜̟ͦ͂͆͐̽̆̽̄͆̑̔͒̏͐̊̈́̓̃ ̶̴̡́̋̓̾̀̆̇̊̑̀̎́͏̦̭͔̯̱͎̮̹Z̧ͯ̓̌̀̔̿̄̐̔̐̆ͬ͂̓ͫ̃ͤ͏̶̨͖̭̥̭͚̱͖̖͖͚̯͍̤̳͉̮͍ͅĄ̷͍̬͍̱̗̤ͤ̾̓̂̍̿͒͋̓ͮ̒͗͂͂ͥͪ̓̍ͯ͘Ḻ̵̸̤̺̳̞̺̹̣̮̦̥͉͔͖ͤͧͫ͒͐̌̈́ͩ͌́ͧ͐̑̃̌͝ͅG͉̙̻̯̿͌̃̿͒̐̓͢͡͝͠ͅO̶̫̪̳̼̬͇̙̪͚ͤ͊ͪ̔ͪ͝͞!̶̱̼̗̥̼̗͎̹͔̬̥̙͎̇̐̒̅̒̉͑̇̏́͟͜
о, норм так… щас поисследуем…
выглядит вот так без «хитрой кодировки»:
д??????? у?????? т??????.?? О????????????? н????????????????????????? и????????????????????????? ??????????????????????????? и???????????????????????????????????????? д??????????????? у???????????????? т??????????????????????????????!????????????????????????? ????????????????????????Z???????????????????????????????????????A????????????????????????????L?????????????????????????????????G????????????????O?????????????????!??????????????????????????
о, норм так… щас поисследуем…
выглядит вот так без «хитрой кодировки»:
д??????? у?????? т??????.?? О????????????? н????????????????????????? и????????????????????????? ??????????????????????????? и???????????????????????????????????????? д??????????????? у???????????????? т??????????????????????????????!????????????????????????? ????????????????????????Z???????????????????????????????????????A????????????????????????????L?????????????????????????????????G????????????????O?????????????????!??????????????????????????
zalgo text generator
Если программист сильный, то он может это сделать путем переворачивания собеседующего :)
меня сейчас закидают камнями, я более 10 лет занимаюсь программированием, и вот только сейчас загуглил как это делается в js
но я почему то уверен что подобная функция возможно есть в других языках, да я понимаю что можно запустить цикл, что собственно тут и есть
так я к чему, не все и не всегда должны знать(помнить) бональные решения ибо такие решения очень редко используются в продакшине
str.split('').reverse().join('')но я почему то уверен что подобная функция возможно есть в других языках, да я понимаю что можно запустить цикл, что собственно тут и есть
так я к чему, не все и не всегда должны знать(помнить) бональные решения ибо такие решения очень редко используются в продакшине
на очном собеседовании демонстрировали полную неспособность к программированию.
Если «скосить глаза», то можно разглядеть в этом зайчатки TDD-подхода (=
В "Pragmatic Programmer" для этого есть прекрасный термин – Programming by coincidence.
Угу, а потом в продакшне приходит ситуация, на которую не было написано теста (случается сплошь и рядом — Вы не представляете, КАКИЕ входные данные умудряются подсовывать!) — и Ваша «программа» падает со словами «ой, всё!».
Как говорится, «в противостоянии искусственного интеллекта и естественного идиота побеждает последний».
Как говорится, «в противостоянии искусственного интеллекта и естественного идиота побеждает последний».
На самом деле интересная идея для реализации AI, пишущего программы. А если еще и через тесты прогонять…
Пока курил придумал решение за константное время О(1) и без доп памяти(ну почти).
Если реализовать строку как двусвязный список котором есть указатель на первый, последний элемент и булево значение для определение направления реверса.
А в узле списка храним значение(тут можно уточнить кодировку и т.д.) и указатели a,b на соседние елементы.
Правда если алгоритм используется один раз то нет выигрыша, т.к. нужно перевести строку из «стандартной» реализации в «новую» структуру данных. Но если такая задача встречается много раз для каждой строки (и строки большие), то сэкономил вам кучу денег на серверном времени))
Если реализовать строку как двусвязный список котором есть указатель на первый, последний элемент и булево значение для определение направления реверса.
А в узле списка храним значение(тут можно уточнить кодировку и т.д.) и указатели a,b на соседние елементы.
Правда если алгоритм используется один раз то нет выигрыша, т.к. нужно перевести строку из «стандартной» реализации в «новую» структуру данных. Но если такая задача встречается много раз для каждой строки (и строки большие), то сэкономил вам кучу денег на серверном времени))
Если сеньора собеседуют так-же, как джуна, делать в такой конторе нечего. Им джун нужен, его и возьмут.А как должность называться будет — вторично.
Если вы только начали свой путь в собеседованиях, то вам предстоит еще много открытий. Как правило, первое общение происходит с HR, у которых все вопросы записаны на бумажке. Это первый фильтр вашего резюме. Общаться с ними на профессиональные темы бесполезно, нужно просто правильно ответить. По этому, допустим для JS, нужно как стихи знать определения: Функциональное программирование, Rest API, замыкание, наследование.
Вопросы от HR-а по списку, хороший фильтр в пользу кандидата. Если учесть что вопросы HR-у составляют программисты компании, то после очередного услышанного вопроса, можно сразу прощаться с HR-ом и передать привет несостоявшимся коллегам.
Помню однажды, я услышал такой вопрос «из списка»:
я чисто из вежливости конечно решил уточнить версию PHP например, версию Python или реализацию, в общем что-то, что могло бы мне дать повод не считать этот вопрос совершенно дурацким, мягко говоря.
Но вышло так, что HR с гордостью мне сообщил, что у нее без всяких там моих уточнений, её коллеги программисты написали совершенно однозначный ответ — Python.
Мне как бы было все равно совершенно, даже хотелось потроллить, но от дальнейшего технического интервью я сразу отказался.
Таким образом один вопрос из списка, сэкономил кучу времени мне, им, и очевидно для меня, рассказал мне об этой компании, и потенциальных коллегах, у которых видимо глубокий внутренний диссонанс.
Помню однажды, я услышал такой вопрос «из списка»:
что быстрее Python или PHP
я чисто из вежливости конечно решил уточнить версию PHP например, версию Python или реализацию, в общем что-то, что могло бы мне дать повод не считать этот вопрос совершенно дурацким, мягко говоря.
Но вышло так, что HR с гордостью мне сообщил, что у нее без всяких там моих уточнений, её коллеги программисты написали совершенно однозначный ответ — Python.
Мне как бы было все равно совершенно, даже хотелось потроллить, но от дальнейшего технического интервью я сразу отказался.
Таким образом один вопрос из списка, сэкономил кучу времени мне, им, и очевидно для меня, рассказал мне об этой компании, и потенциальных коллегах, у которых видимо глубокий внутренний диссонанс.
Навсегда запомнил собеседование от HR (!!!) отдела в команду разработки по Skype.
— Расскажите мне о контракте между hashCode() и equals().
— (Начинаю рассказывать чего, да как).
— Нет, вы не поняли. Расскажите как это написано в JLS.
— То что вам рассказываю это разве не то?
— Нет. В JLS описано не так.
(проехали пару вопросов)
— Расскажите про уровни изолированности в JDBC.
— (Рассказываю, провожу аналогии с MS SQL и ORACLE).
— Я что-то вас не поняла. Вы там что, гуглите?
Меня после этого просто дико бомбануло. Компания не без имени, знакомые лестно отзываются о ней, но на собеседованиях выкидывают такие вот номера — вопросы по бумажке. После этого все желание продолжать диалог просто пропало.
Проблема автора на самом деле актуальная — изначально задоминировать респондента, чтобы доказать его никчёмность. Однако, после этого они еще кидают офферы, тем самым, произведя оценку твоих знаний, выставляют ценник. Прекрасно понимаю автора, что по морали такое сильно бьет, но ты держись. Не все компании такие вокруг. Остынь и снова можно попробовать.
— Расскажите мне о контракте между hashCode() и equals().
— (Начинаю рассказывать чего, да как).
— Нет, вы не поняли. Расскажите как это написано в JLS.
— То что вам рассказываю это разве не то?
— Нет. В JLS описано не так.
(проехали пару вопросов)
— Расскажите про уровни изолированности в JDBC.
— (Рассказываю, провожу аналогии с MS SQL и ORACLE).
— Я что-то вас не поняла. Вы там что, гуглите?
Меня после этого просто дико бомбануло. Компания не без имени, знакомые лестно отзываются о ней, но на собеседованиях выкидывают такие вот номера — вопросы по бумажке. После этого все желание продолжать диалог просто пропало.
Проблема автора на самом деле актуальная — изначально задоминировать респондента, чтобы доказать его никчёмность. Однако, после этого они еще кидают офферы, тем самым, произведя оценку твоих знаний, выставляют ценник. Прекрасно понимаю автора, что по морали такое сильно бьет, но ты держись. Не все компании такие вокруг. Остынь и снова можно попробовать.
По поводу «задоминировать респондента» — есть хорошая статья на известном всем сайте) Часто встречаю уловки, описанные в ней )
«Да, гуглю. Кстати, если ваши вопросы гуглятся в течении 10 секунд, не пойти ли вам нахрен с такими вопросами?»
Я что-то вас не поняла. Вы там что, гуглите?
ААААА! Меня аж встряхнуло от этих строк — когда на собеседовании по скайпу накидывал по Liskov Principe (soLid) и мне сказали «Вы там читаете в Гугле?» и даже речь заплетаться стала у меня :)
Ещё со времён технаря я не запоминаю конструкции языка программирования, мне это совсем не нужно. Я просто пишу на естественном языке всю логику, а потом могу её реализовать на любом языке программирования просто гугля нужные мне конструкции выбранного языка.
Мой друг хорошо помнил практически все операнды и функции того же C++, но при этом у него было всё печально с логикой.
Вопрос такой: кто из нас двоих лучше как разработчик?
Да, в те далёкие времена мы с другом писали то, что не могли написать больше никто из нашей группы.
Я и сейчас не факт что без ошибок с первого раза напишу простейший цикл, но это и не нужно, я ведь знаю, что мне нужно написать, а как это написать знают поисковые системы.
Мой друг хорошо помнил практически все операнды и функции того же C++, но при этом у него было всё печально с логикой.
Вопрос такой: кто из нас двоих лучше как разработчик?
Да, в те далёкие времена мы с другом писали то, что не могли написать больше никто из нашей группы.
Я и сейчас не факт что без ошибок с первого раза напишу простейший цикл, но это и не нужно, я ведь знаю, что мне нужно написать, а как это написать знают поисковые системы.
ответ: ни тот, ни другой
Тут еще одна актуальная проблема: «я знаю логику и напишу на любом языке, но изучаю их поверхностно» или «я очень сильный спец в своем языке, но всё что вокруг для меня темный лес».
Спорный момент кто из вас лучше. Для одного работодателя, как писал выше автор, твой друг бы был идеальным кандидатом. Для другого работодателя, который тестирует логическими задачами аля «Есть 2 яйца, на каком этаже разобьется» и умение справиться с поставленной задачей быстро, ты бы показал себя с более сильной стороны. Но итог один — каждый специалист (если он действительно специалист) найдет своё место под солнцем.
Какого мнения придерживаюсь я?
Гугл — это инструмент, которое может тебе дать неправильное решение. Почему? А потому что ты загуглил проблему, открыл первую же ссылку на StackOverflow и скопировал решение. Добавило ли это тебе экспертизы? Нет, а это плохо. Надо стараться разбирать те типовые проблемы, с которыми ты сталкиваешься и хотя бы поверхностно изучать внутренности языка, чтобы совсем уж лохом не казаться, когда будешь собеседоваться.
Спорный момент кто из вас лучше. Для одного работодателя, как писал выше автор, твой друг бы был идеальным кандидатом. Для другого работодателя, который тестирует логическими задачами аля «Есть 2 яйца, на каком этаже разобьется» и умение справиться с поставленной задачей быстро, ты бы показал себя с более сильной стороны. Но итог один — каждый специалист (если он действительно специалист) найдет своё место под солнцем.
Какого мнения придерживаюсь я?
Гугл — это инструмент, которое может тебе дать неправильное решение. Почему? А потому что ты загуглил проблему, открыл первую же ссылку на StackOverflow и скопировал решение. Добавило ли это тебе экспертизы? Нет, а это плохо. Надо стараться разбирать те типовые проблемы, с которыми ты сталкиваешься и хотя бы поверхностно изучать внутренности языка, чтобы совсем уж лохом не казаться, когда будешь собеседоваться.
Я тоже вообще не знаю конструкции даже того языка на котором у меня 90% всего за 20 лет написано. И по этому я вообще в принципе не могу пройти тех собеседование где плювать хотели на мои проекты (как единственное доказательство того что я умею), а им важнее знать что означает «const volatile переменная», а потом метод, а потом ещё чего позаковыристее.
Если компания «зазвездилась» до топов это доходит до маразма: начало 2015 года, одной сами знаете какой компании надо сделать тензорный процессор не хуже гугла для поиска по картинкам, ищут FPGA разработчика-схемотехника, меня забраковали потому что я знаю только C++11 а вот C++14 уже нет т.к. не смог ответить на их «очень простой технический вопрос». Естественно по самой простой конструкции уровня сложности не сеньёра а code-monkey. Кое как до них с городского дозвонился, в итоге сказали:«Вы вообще не разработчик, пожалуйста не звоните, ваш мобильный внесён в блек лист». Естественно каких либо верилогов и языков описания таймингов они в требования не внесли и не проверяли на тех собеседовании.
Приезжаешь в другую страну и встречаешь такие же портянки технологий, но появляется одна «мелочь» которая гласит «любое из» （いずれの）. И работа находится сразу же, и проекты поинтереснее, и никто не ожидает что один человек за пол года тензорный процессор на десятки петафлопов свояет, и зарплата (в пересчёте на местные расходы) повыше «зазвездившихся» даже в предприятиях типа «болото». И даже есть и время и оплаченная возможность отдохнуть и погонять на ардуинке нейросети в реалтайме.
Если компания «зазвездилась» до топов это доходит до маразма: начало 2015 года, одной сами знаете какой компании надо сделать тензорный процессор не хуже гугла для поиска по картинкам, ищут FPGA разработчика-схемотехника, меня забраковали потому что я знаю только C++11 а вот C++14 уже нет т.к. не смог ответить на их «очень простой технический вопрос». Естественно по самой простой конструкции уровня сложности не сеньёра а code-monkey. Кое как до них с городского дозвонился, в итоге сказали:«Вы вообще не разработчик, пожалуйста не звоните, ваш мобильный внесён в блек лист». Естественно каких либо верилогов и языков описания таймингов они в требования не внесли и не проверяли на тех собеседовании.
Приезжаешь в другую страну и встречаешь такие же портянки технологий, но появляется одна «мелочь» которая гласит «любое из» （いずれの）. И работа находится сразу же, и проекты поинтереснее, и никто не ожидает что один человек за пол года тензорный процессор на десятки петафлопов свояет, и зарплата (в пересчёте на местные расходы) повыше «зазвездившихся» даже в предприятиях типа «болото». И даже есть и время и оплаченная возможность отдохнуть и погонять на ардуинке нейросети в реалтайме.
Яндекс,
им очень не понравилось то что я не очень хорошо питон знаю, а то что я не смог ответить по новому ключевому слову из С++14 вообще просто повесили трубку без объяснения причин, вот и начал вызванивать «что это было? и почему тех собеседование и 5 минут не продлилось?».
им очень не понравилось то что я не очень хорошо питон знаю, а то что я не смог ответить по новому ключевому слову из С++14 вообще просто повесили трубку без объяснения причин, вот и начал вызванивать «что это было? и почему тех собеседование и 5 минут не продлилось?».
и почему тех собеседование и 5 минут не продлилось?
Может, им за час нужно было с десятью поговорить. Они применили формальный фильтр. Интересно, что у них есть «чёрный список». :)
Серьёзно, повесили трубку во время собеседования?
В C++14 новых ключевых слов не появлялось. en.cppreference.com/w/cpp/keyword
Может, вы не поняли, о чем вас вообще спрашивали, и проблема в этом?
Может, вы не поняли, о чем вас вообще спрашивали, и проблема в этом?
Предполагаю, у компаний с известным именем немыслимое число соискателей. И такие компании придумывают формальные, и порой нелепые, признаки для отсеивания.
Вы бы купили недвижимость за 5 минут только потому что предложений ещё больше чем соискателей? За которую платить кредит годами и в которой жить всей семьёй? Ладно если денег навалом но она может обрушится или сосед наркоман пырнуть. Поэтому и считаю что экономия времени это очень плохой фильтр, я бы сказал наихудший фильтр отсева.
вот в перегибах и есть все проблемы: я не отрицаю самозванцев и что их много, но и не отрицаю что недойдя до квартиры и даже дома вступают в лужу, или просто на глаза попадается синяя реклама а не жёлтая скажем, разворачиваются и уходят к следующему адресу. Поэтому я не могу утверждать что закидонов соискателей больше чем у работодателей.
Да и нежелание хоть как то фильтровать самозванцев это разве не есть достаточное доказательство проф непригодности соответствующих специалистов?
Да и нежелание хоть как то фильтровать самозванцев это разве не есть достаточное доказательство проф непригодности соответствующих специалистов?
> фильтр блума
Спасибо тебе хабравчанин. Давно читал статью про распределенные БД и там было описание функции повзоляющей быстро определить относится ли число к множеству. Я не запомнил название, но теперь то я ее добавлю во вкладки.
Спасибо тебе хабравчанин. Давно читал статью про распределенные БД и там было описание функции повзоляющей быстро определить относится ли число к множеству. Я не запомнил название, но теперь то я ее добавлю во вкладки.
Если использовать вашу аналогию, то представьте, что вы ищете элитную квартиру, и две трети предложений которые вам пытатся продать по цене элитного жилья — это малосемейки в разваливающихся бараках. Поэтому если вы заходите в обшарпанную прихожую в которой десятилетиями не было ремонта, дальше смотреть не имеет смысла.
Ну, если продолжать эту аналогию полностью, то тут проблема возникает, когда не смотрят реальную прихожую (реальную работу), а спрашивают по телефону, куда там вешается одежда. И если продавец назвал ключевое слово «вешалка-плечики», значит считается, что квартира, возможно, элитная (туда приходят люди в тяжёлых шубах). А если не назвал, то «мы вам перезвоним».
То есть, как бы, корреляция-то есть, но не совсем работающая.
:) очень понравилось слово «свОяет» (вместо свАяет) — возьму на вААружение — буду спрашивать коллег — а вот как же ты, боевой товарищ, вот такое вот свОял?
Не, ну про «const volatile переменная» — это нормальный вопрос, если там системного программиста или эмбедщика искали. Сразу раскрывает опыт (либо горизонт фантазии) соискателя.
А давайте обсудим.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
Или, как вариант, это может быть extern const volatile-переменная. Писать в нее можно, но не в этом модуле.
А volatile ей тогда зачем? В голову приходит только какой-то глобальный объект в многопоточной программе, который можно читать из разных мест, а писать только в одном (либо только хитрым способом). Borrow checker для бедных.
volatile не даст компилятору заоптимизировать эту переменную (например, положив её в регистр). borrow checker тут ни при чем.
У вас переменная уже extern const, оптимизировать ее компилятор уже не будет, потому что она в другом translation unit, и положить ее в регистр если и получится, то только при LTO.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
У вас переменная уже extern const, оптимизировать ее компилятор уже не будет, потому что она в другом translation unit, и положить ее в регистр если и получится, то только при LTO.
Имеет полное право хранить её в регистре между вызовами внешних функций, т.е. записывать в память не все её изменения, а только последнее перед вызовом.
С volatile — обязан записывать в память каждое изменение.
Только не записывать, а читать, потому что записывать мешает const.
Я не про то, что не знаю, зачем оно так, а про то, для чего может понадобится именно extern const volatile, а обычного extern const не хватит, и ничего кроме многопоточной программы и регистров в голову не приходит. В одном потоке переменная (обычная, не отображенная на регистр) из другого юнита меняться не может, т.к. это нарушает инварианты.
Я не про то, что не знаю, зачем оно так, а про то, для чего может понадобится именно extern const volatile, а обычного extern const не хватит, и ничего кроме многопоточной программы и регистров в голову не приходит. В одном потоке переменная (обычная, не отображенная на регистр) из другого юнита меняться не может, т.к. это нарушает инварианты.
Дык выше вы сами написали зачем: «Подойдет указателям на RO-регистры, доступные через MMIO.»
Я про вот этот случай конкретно:
Если программа однопоточная — volatile не нужен, только портит оптимизатору жизнь. Если многопоточная — его недостаточно, от гонок по данным так и не избавились.
Т.е. если там заведомо не регистры, то зачем?
Или, как вариант, это может быть extern const volatile-переменная. Писать в нее можно, но не в этом модуле.
Если программа однопоточная — volatile не нужен, только портит оптимизатору жизнь. Если многопоточная — его недостаточно, от гонок по данным так и не избавились.
Т.е. если там заведомо не регистры, то зачем?
Если не секрет, в какую страну переехали?)
Да вот тоже периодически мучаюсь вопросом — где золотая середина между бессмысленной детализацией сверхмелких знаний и ватной высокоуровневой абстракцией «не грузите меня мелочевкой»…
Про железо: по молодости был у меня товарищ, который наизусть знал все параметры разных BIOS'ов, чипсетов, сигналы IDE и скорости вентиляторов видюх — что, по его мнению, предполагало очевидную предсказуемость успеха сборки компов на заказ… однако после третьего сожженного (частично) комплекта недешевых компонентов как-то стал обращаться ко мне, после 3-4 успешно собранных системников что-то заскучал и бросил это дело;
Про разработку софта: в конце 80-х трое коллег подрядились за разработку узкоспециализированной статистической программки, все трое по книжкам на память знали весь синтаксис PL-1 (в 2-3 диалектах, с различиями в запятых и слэшах), пописывали программки по 10-40 строк — само собой, при доступе к ЕС- (или СМ?) ЭВМ с печатающим устройством, возможностями разделения задач и т.п. выбрали этот инструмент. Меня и ближайшего начальника странноватый энтузиазм слегка насторожил и я начал в остающееся от основных задач время писать на одном из вариантов BASIC на Спектруме, само собой, ни этот ни какой-либо другой диалект я особо и не знал — справочник лежит под рукой и достаточно. Через пару недель «устойчивая» BASIC-версия была готова что было весьма кстати, т.к. «конкуренты» застряли на простом расчете коэффициента корреляции (формирование массивов, извлечение очередных элементов, собственно расчет). Оправдание перед более высоким начальством — PL-1 не позволяет реализовать такие сложные расчеты…
Про собеседование: попросили меня помочь оценить квалификацию специалистов на вакансию, куда могли подойти в том числе и специалисты техподдержки ИТ-инфраструктуры (если уж не совсем интроверты). Из таковых пришло человек 8. 4 — бойкая (что не плохо) молодЕжь вот такого типа www.anekdot.ru/an/an0710/o071025.html#10 (СПЕЦИАЛИСТ ПО ХАБАМ И СВИЧАМ), но особо запомнился титулованный товарищ среднего возраста, который работал в техподдержке 3-го уровня в российском представительстве крупного вендора. 1-ый уровень — это обученные специалисты заказчиков (типа решают проблемы стандартные), 2-ой уровень — сертифицированные специалисты партнеров, ну а 3-й уровень — это уже просто «зубры». Чтобы разговорить товарища и понять чем занимается, 10 минут я упрашивал его рассказать о примерах инцидентов с которым он работает (и документирует решения), потом 20 минут с отчаяния начал набрасывать примеры — оборудование вышло из строя на аппаратном уровне...., неправильная обработка протоколов маршрутизации, падение производительности — ответы — нет, это все не к нам… а что же к вам? нет ответа, нет вообще. так и разошлись.
Про железо: по молодости был у меня товарищ, который наизусть знал все параметры разных BIOS'ов, чипсетов, сигналы IDE и скорости вентиляторов видюх — что, по его мнению, предполагало очевидную предсказуемость успеха сборки компов на заказ… однако после третьего сожженного (частично) комплекта недешевых компонентов как-то стал обращаться ко мне, после 3-4 успешно собранных системников что-то заскучал и бросил это дело;
Про разработку софта: в конце 80-х трое коллег подрядились за разработку узкоспециализированной статистической программки, все трое по книжкам на память знали весь синтаксис PL-1 (в 2-3 диалектах, с различиями в запятых и слэшах), пописывали программки по 10-40 строк — само собой, при доступе к ЕС- (или СМ?) ЭВМ с печатающим устройством, возможностями разделения задач и т.п. выбрали этот инструмент. Меня и ближайшего начальника странноватый энтузиазм слегка насторожил и я начал в остающееся от основных задач время писать на одном из вариантов BASIC на Спектруме, само собой, ни этот ни какой-либо другой диалект я особо и не знал — справочник лежит под рукой и достаточно. Через пару недель «устойчивая» BASIC-версия была готова что было весьма кстати, т.к. «конкуренты» застряли на простом расчете коэффициента корреляции (формирование массивов, извлечение очередных элементов, собственно расчет). Оправдание перед более высоким начальством — PL-1 не позволяет реализовать такие сложные расчеты…
Про собеседование: попросили меня помочь оценить квалификацию специалистов на вакансию, куда могли подойти в том числе и специалисты техподдержки ИТ-инфраструктуры (если уж не совсем интроверты). Из таковых пришло человек 8. 4 — бойкая (что не плохо) молодЕжь вот такого типа www.anekdot.ru/an/an0710/o071025.html#10 (СПЕЦИАЛИСТ ПО ХАБАМ И СВИЧАМ), но особо запомнился титулованный товарищ среднего возраста, который работал в техподдержке 3-го уровня в российском представительстве крупного вендора. 1-ый уровень — это обученные специалисты заказчиков (типа решают проблемы стандартные), 2-ой уровень — сертифицированные специалисты партнеров, ну а 3-й уровень — это уже просто «зубры». Чтобы разговорить товарища и понять чем занимается, 10 минут я упрашивал его рассказать о примерах инцидентов с которым он работает (и документирует решения), потом 20 минут с отчаяния начал набрасывать примеры — оборудование вышло из строя на аппаратном уровне...., неправильная обработка протоколов маршрутизации, падение производительности — ответы — нет, это все не к нам… а что же к вам? нет ответа, нет вообще. так и разошлись.
Не получилось придумать достойную этого мегазубра сложную задачу? :0))
А мне кажется что вы не совсем верно понимаете разделение на уровни поддержки.
Первый уровень — оперативная поддержка. Это обеспечение бесперебойной работы систем и решение проблем только по инструкции. Есть инструкция как решить проблему, значит она решается. Если инструкции нет, то передается дальше. Как правило, первый уровень реализует поддержку по принципу 365/7/24.
Второй уровень решает несложные нетривиальные проблемы, не требующие серьезного анализа и разработки. Например на этом уровне может сделаться несложный data fix или может быть сделан какой-то быстрый workaround. Здесь уже как правило не идет речь о поддержке 365/7/24. Как только стукает 18 или 19 часов все разбегаются по домам. Но если задача важная, то могут и решать сверхурочно.
А вот третий уровень, это непосредственно разработка и решение проблем, требующих серьезного анализа. Почти все о чем вы написали действительно не его профиль. Потому что все перечисленные проблемы решает первая и вторая линия поддержки. А он занимается другим: разработкой новых фитч по запросу пользователей, баги в софте ковыряет (если это вендор ПО или интегратор) и пр.
Первый уровень — оперативная поддержка. Это обеспечение бесперебойной работы систем и решение проблем только по инструкции. Есть инструкция как решить проблему, значит она решается. Если инструкции нет, то передается дальше. Как правило, первый уровень реализует поддержку по принципу 365/7/24.
Второй уровень решает несложные нетривиальные проблемы, не требующие серьезного анализа и разработки. Например на этом уровне может сделаться несложный data fix или может быть сделан какой-то быстрый workaround. Здесь уже как правило не идет речь о поддержке 365/7/24. Как только стукает 18 или 19 часов все разбегаются по домам. Но если задача важная, то могут и решать сверхурочно.
А вот третий уровень, это непосредственно разработка и решение проблем, требующих серьезного анализа. Почти все о чем вы написали действительно не его профиль. Потому что все перечисленные проблемы решает первая и вторая линия поддержки. А он занимается другим: разработкой новых фитч по запросу пользователей, баги в софте ковыряет (если это вендор ПО или интегратор) и пр.
Если вы до сих пор не напишете простейший цикл с первого раза без ошибок, это выглядит как довольно мало опыта.
Я закрываю скайп и, конечно, тут же вспоминаю, что за virtual.
Наверняка у многих такое бывало на собеседовании. Но, когда беседа закончена, то уже «нещитово».
Маленький лайфхак: можно записать суть вопроса одним словом на бумажке и предложить продолжить разговор.
Неизбежно возникнет пауза (например, когда собеседующий будет мысль формулировать) и ваш на секунду освободившийся мозг вытолкнет найденную в архивах информацию.
Так уж наш мозг работает.
У этого явления даже название есть — эффект лестницы ru.wikipedia.org/wiki/%D0%9B%D0%B5%D1%81%D1%82%D0%BD%D0%B8%D1%87%D0%BD%D1%8B%D0%B9_%D1%83%D0%BC
Я сам разработчик, но проводил собеседование в команду в том месяце. Если коротко обобщить мой опыт — «берем первого не самозванца». Дело не в знании virtual, дело в том что можешь написать «синьор», «бест оф зе бест» и так далее — совершенно не важно. Все равно тебе пришлют резюме, и на все твои требования скажут — «знаю поверхностно если что разберусь», так банально делают все. И будут убеждать — я то что вам нужно, у меня огромный опыт, я фокусируюсь на практике и решении бизнес проблем. Потом начинаешь тех интервью, оказывается что человек не знает что такое Диспоуз, и зачем он нужен. Не знает зачем метод SuspendLayout хотя заявляет, что у него опыт 5-10 лет с ВинФормами.
И нет я не заканчивал интервью после первого не верного ответа — ну бывает, человек забыл. Но как можно забыть то, без чего невозможно работать с конкретной технологией, которая указана в резюме?
Я несколько раз уже помогал искать людей в команду, по сути каждый раз это заканчивалось «берем первого, который не врет, за наши деньги». Подавляющее большинство — лгуны и самозванцы. Врут про все, про национальность (один китаец говорил что он украинец, ни знал ни русского ни украинского, не мог назвать город где живет, использовал гугл транслейт), про занятость на других проектах (подается на фулл тайм, оказывает то студент то работает в офисе и ищет подработку), про скилы (в резюме создавал дамбу Гувера — на практике подавал ключи строителю), про личность исполнителя (проходит собес один человек, а работает потом другой, который ни чего не помнит и ниже скилами), про вредные привычки (а оказывается запойный алкоголик).
Короче да, вы правы, центральная идея — не взять самозванца. Но персонаж, который вам попался, явно перегнул палку, с такими критериями (чтоб от зубов отскакивало) он скорее всего найдет или ни кого, или самозванцев другого типа. Такие тоже попадались — все знают, работать не умеют, от слова совсем. Т.е. только по шаблону добавлять однотипные фичи или чинить мелкие баги.
А самое плохое — что нет возможности ни как на это влиять, отзывы ставишь только после работы. И это легко накручивается, работой самого на себя под разными именами. Тесты онлайн так-же легко накручиваются и проходятся. В итоге это армия самозванцев — бродит в поисках жертвы и не имеет ни каких механизмов естественного сокращения численности. Процент не врущих на собесах — падает. И все опять сводится к «порукам», просят посоветовать кого-то, с кем работал.
А вам не стоит бояться ходить на собесы, ну провалили одно, не устроились к тирану-топу-заучке, который бы не дал вам ни чего проектировать или делать, давил бы вас и самоутверждался. Хорошо же? Собеседование это двоякий процесс. Соискатель так-же тестирует работодателя, и сможет ли он с ним работать. И вот кстати очень редко самозванцы что-либо спрашивают относительно будущего места работы, им все пофигу, им все по плечу, они ко всему привыкнут. В то время как норм специалисты зачастую чувствительны даже к стилю кода, методологии и т.д.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
П.С. А был такой, что вообще ответы копипастил из гугла, прямо в наглую.
И нет я не заканчивал интервью после первого не верного ответа — ну бывает, человек забыл. Но как можно забыть то, без чего невозможно работать с конкретной технологией, которая указана в резюме?
Я несколько раз уже помогал искать людей в команду, по сути каждый раз это заканчивалось «берем первого, который не врет, за наши деньги». Подавляющее большинство — лгуны и самозванцы. Врут про все, про национальность (один китаец говорил что он украинец, ни знал ни русского ни украинского, не мог назвать город где живет, использовал гугл транслейт), про занятость на других проектах (подается на фулл тайм, оказывает то студент то работает в офисе и ищет подработку), про скилы (в резюме создавал дамбу Гувера — на практике подавал ключи строителю), про личность исполнителя (проходит собес один человек, а работает потом другой, который ни чего не помнит и ниже скилами), про вредные привычки (а оказывается запойный алкоголик).
Короче да, вы правы, центральная идея — не взять самозванца. Но персонаж, который вам попался, явно перегнул палку, с такими критериями (чтоб от зубов отскакивало) он скорее всего найдет или ни кого, или самозванцев другого типа. Такие тоже попадались — все знают, работать не умеют, от слова совсем. Т.е. только по шаблону добавлять однотипные фичи или чинить мелкие баги.
А самое плохое — что нет возможности ни как на это влиять, отзывы ставишь только после работы. И это легко накручивается, работой самого на себя под разными именами. Тесты онлайн так-же легко накручиваются и проходятся. В итоге это армия самозванцев — бродит в поисках жертвы и не имеет ни каких механизмов естественного сокращения численности. Процент не врущих на собесах — падает. И все опять сводится к «порукам», просят посоветовать кого-то, с кем работал.
А вам не стоит бояться ходить на собесы, ну провалили одно, не устроились к тирану-топу-заучке, который бы не дал вам ни чего проектировать или делать, давил бы вас и самоутверждался. Хорошо же? Собеседование это двоякий процесс. Соискатель так-же тестирует работодателя, и сможет ли он с ним работать. И вот кстати очень редко самозванцы что-либо спрашивают относительно будущего места работы, им все пофигу, им все по плечу, они ко всему привыкнут. В то время как норм специалисты зачастую чувствительны даже к стилю кода, методологии и т.д.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
П.С. А был такой, что вообще ответы копипастил из гугла, прямо в наглую.
Тестовое задание?
Их так-же подделывают, пишет один человек, а собеседуется другой. Бодишопы вообще ад в этом плане, есть один супер разраб, который проходит собеседования, сдает тесты, пишет тестовые задания, а потом вместо него, работают его менее умелые коллеги. Если они сильно лажают — он подключается, разруливает все, может по скайпу поговорить, а потом дает чертей джуну и джун дальше работает под его видом.
Вот и выходит — нужна вебка, нужно сразу просить писать код, нужно задавать вопросы «на самозванца» и включать психолога.
Вот и выходит — нужна вебка, нужно сразу просить писать код, нужно задавать вопросы «на самозванца» и включать психолога.
Так может поспрашивать чувака по его тестовому? Как он его делал, и почему принимал те решения, что принимал. Это как раз то, что он не может забыть, ведь делал тестовое за день перед собесом. И я всё же считаю, что включать психолога нужно, если точно знаешь, что ты умеешь это делать.
Так и делаю, но тестовое какого уровня? Более менее внятное тестовое для технологий текущего проекта это от 40 часов. Бесплатно работать неделю многие хорошие девы не согласятся, а значит надо оплачивать, и абы кому — не хочется.
Мы однажды пробовали такое, человек к нам на 2 недели выходил. В итоге так и не взяли. Собственно, сразу были сомнения, но парень уговорил нас на такую схему — типа покажу вам, как я круто могу. Не показал. И да, так уже накладно по деньгам выходит, да и не многие на такие условия согласятся даже если им предложат оплатить потраченное время.
Бывает и так, что все хотят сениора, а дают ему потом таски типа вёрстки. Что бы сохранить сениора, такую рутину приходится скидывать на джунов.
Если заказчик в итоге доволен, то win-win.
Зависит от точки зрения. Заказчик нанимает человека для выполнения работ, при этом обычно он прямо не обязуется не использовать труд других людей. И дальше он например нанимает себе помощника, или секретаршу, со своих денег, которые ему заплатил заказчик. Ну и какая разница то-ли секретарша ему кофе варит, а он не тратит на это час времени в день, или джун делает для него рутину, а он в это время сфокусирован на другом. Это его деньги и его проблемы.Главное что-бы работа и цена, которые были согласованы — были сделаны. Это вопрос взгляда и вопрос конкретного договора.
С тестовым заданием есть риск, что опытные специалисты не будут его делать, особенно если оно используется как первичный фильтр.
А по-моему это отличный шанс показать как хорошо можешь сделать. Хотя никто не мешает сделать не самому.
Угу. Делаешь такое тестовое задание, ну, пусть даже 1 день.
А тебе отказывают без какого-либо объяснения причин.
Пойдете писать подобное задание еще раз в следующую компанию «нам лень потратить на вас свое время но мы ждем от вас что вы потратите на нас не менее дня работы»?
При этом мотивация для отбраковки работы ведь тоже может быть произвольной. Идиот точно так же будет искать там к чему придраться — и успешно найдет.
Уж лучше устные вопросы. Честно. Тут хотя бы есть обратная связь.
А тебе отказывают без какого-либо объяснения причин.
Пойдете писать подобное задание еще раз в следующую компанию «нам лень потратить на вас свое время но мы ждем от вас что вы потратите на нас не менее дня работы»?
При этом мотивация для отбраковки работы ведь тоже может быть произвольной. Идиот точно так же будет искать там к чему придраться — и успешно найдет.
Уж лучше устные вопросы. Честно. Тут хотя бы есть обратная связь.
При всем уважении, ваши переживания выглядят чрезмерно раздутыми. Как подростка, которому отказала первая девушка, да еще и фыркнула при этом. И теперь «я ни когда больше с девушкой не заговорю».
Я бы на такое заявление заметил, что поведение рекрутера, который по поверхностным вопросам делает выводы в место ведения диалога, больше похоже на психологическую травму подростка.
А вот из личного опыта:
Как то зашел у меня разговор с рекрутером о написании драйвера. Разговор свелся к тому что его представление об этом процессе подразумевает упоминание некоторых специфик. На мой вопрос «каких?», он спросил меня «что такое intellisense?». С мыслью о том, какое отношение intellisense имеет к процессу написания драйвера, я ответил «Понятия не имею». Сами понимаете какая ситуация получилась. Тем не менее, мне обещали выслать тестовое задание, которое я так и не получил.
Мне также приходилось иметь дела с подбором персонала в свою команду, и тут должен заметить тест тесту рознь. Поскольку, когда через неделю к тебе приходит человек, завалившийся на этапе установки IDE это тоже показатель. А с другой стороны я бы не прочь иметь у себя в подчинении или напарника, умеющего лихо находить применения интернет материалам в работе. Поскольку для меня даже такой кандидат был роскошью. Тех же, которые подходили полностью не проходили по легальному положению дел. То без гражданства то еще что. В общем всякое может быть.
>Сеньору это не нужно зазубривать, он и так все знает, т.к. пользуется, а если не пользуется, то возникает вопрос — почему?
Сениоры часто вырастают в совсем другой класс специалистов, которые решают более высокоуровневые проблемы, а не институтские задачи. И потому таких денег и стоят, так как опыт позволяет эти проблемы решать, в отличие от juniorов, которые расскажут, что такое виртуальный метод, но ни черта не поймут, почему лежит система. И нет, она лежит не из-за виртуальных методов.
Сениоры часто вырастают в совсем другой класс специалистов, которые решают более высокоуровневые проблемы, а не институтские задачи. И потому таких денег и стоят, так как опыт позволяет эти проблемы решать, в отличие от juniorов, которые расскажут, что такое виртуальный метод, но ни черта не поймут, почему лежит система. И нет, она лежит не из-за виртуальных методов.
Эти «специалисты» потом оказываются заточены на крайне узкий класс задач.
Шаг вправо шаг влево — и нихрена они уже не понимают. Смутно вспоминают чего-то, но реализовать уже не могут. Здорово конечно когда находится такой спец вот конкретно на ту задачу которая есть у тебя. Но для 99% задач такой спец не годится а под оставшиеся 1% часто проще нанять кого-то попроще но кого не понадобится 3 года искать потому что таких спецов всего двое на всю Москву.
Толковый же джун он может сейчас чего-то и не знать, но он всему научится. Беспроигрышный вариант в среднесрочной перспективе
Шаг вправо шаг влево — и нихрена они уже не понимают. Смутно вспоминают чего-то, но реализовать уже не могут. Здорово конечно когда находится такой спец вот конкретно на ту задачу которая есть у тебя. Но для 99% задач такой спец не годится а под оставшиеся 1% часто проще нанять кого-то попроще но кого не понадобится 3 года искать потому что таких спецов всего двое на всю Москву.
Толковый же джун он может сейчас чего-то и не знать, но он всему научится. Беспроигрышный вариант в среднесрочной перспективе
Потому что дохрена задач решают разных?
Работю с Unreal Engine.
У меня тут статья есть про то как делать анимации через Sequencer. Так я её на днях использовал, чтобы вспоминить ка кделать анимации в Unreal Engine.
Или вот настройка анимаций персонажей, год назад был проект в котором делали очень сложные анимации и я досканально с ним поработал.
А тут открыл редактор и даже вспомнить не мог как что делается, пришлось в доки лезть.
Причина проста — я не аниматор и работаю с анимациями далеко не каждый день.
Но если я иду на сеньора — такие вещи я должен знать. И я их знаю… но не помню.
Работю с Unreal Engine.
У меня тут статья есть про то как делать анимации через Sequencer. Так я её на днях использовал, чтобы вспоминить ка кделать анимации в Unreal Engine.
Или вот настройка анимаций персонажей, год назад был проект в котором делали очень сложные анимации и я досканально с ним поработал.
А тут открыл редактор и даже вспомнить не мог как что делается, пришлось в доки лезть.
Причина проста — я не аниматор и работаю с анимациями далеко не каждый день.
Но если я иду на сеньора — такие вещи я должен знать. И я их знаю… но не помню.
Всё что вы должны — это решать задачи соответствующего уровня сложности за адекватное время. В наше время фронт необходимых навыков для серьёзных работ на столько широк, что помнить все детали совершенно невозможно и не нужно. Но отличие сениора от джуна будет в том, что сениор решит задачу с гуглом за час, а джун — и за 2 дня не решит. Потому и спрашивать про какие-то элементы языков, которые раз в месяц используешь смысла никакого нет, есть смысл спрашивать про то, как человек бы решал конкретную проблему. При этом даже не так и важно, решит он её на собеседовании или нет. Интересней сам подход к решению.
Не прав, потому что не выдержали, встали и ушли (это если не упоминать ваши оценочные суждения про людей, которые вас позвали). Вежливость принято давать в кредит.
Стоило, возможно, раньше прервать общение. Или до собеседования предупредить о том, что на листике не решаете, а если надо будет писать код, то уточнить заранее, в каких условиях это предполагается: свой ноут или чужой, будет доступ в интернет или нет, предполагаемое время на код.
Обычно, если не отвечают мне на эти вопросы или лукавят, со собеседование переходит в категорию стресс-интервью и мой ценник увеличивается — я могу и в таких условиях работать, но это дороже.
Увы но такие типы есть и будут, очевидно, что такое собеседование не показатель ваших способностей, не принимайте близко, просто делайте выводы и пытайтесь дальше. Главное самим не стать такими.
Убей не помню. Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего. Интервью, естественно, кончается.Тяжелый лайф хак: как только понимаешь, что какую лажу выкидывают собеседеры заявляешь, что предлагаешь прекратить собеседование прямо сейчас чтобы не терять своего времени (или ты понял что компания находится в стадии хаоса, или мало понимает свои цели, или еще что-нибудь такое веселое на твой взгляд). Гордость, свечение и высокомерие собеседера быстро испаряются. Я так делал всего один раз, когда мне заявили, что переработка будет учитываться (не оплачиваться!) только если я буду работать до часу ночи. Собеседера от моей оценки и предложения немножко трусило.
Очень знакомо, не вспомнил название какой то мелочи, уже не подходишь, а как посмотрел текущие проекты потенциального работодателя, очень обрадовался этому. Выходит если заучил названия, значит что то умеешь. так и живем.
То, что сеньер не знает что такое virtual никого не смутило? Серьезно?
Скорее всего знает, просто он забыл. С наследованием все сталкивались, и многие на интерфейсах ездят.
Вот я тоже не понял. На мой взгляд интервьюер всё правильно сделал.
Сугубо мое личное мнение:
Джун — должен рассказать о virtual и о переопределении при наследовании
Мидл — должен к этому всему добавить хорошие use cases, и вспомнить о abstract/sealed.
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики.
Джун — должен рассказать о virtual и о переопределении при наследовании
Мидл — должен к этому всему добавить хорошие use cases, и вспомнить о abstract/sealed.
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики.
Странно, а что джун этого не может знать?
abstract/sealed — да уж, джун не потянет…
виртуальных вызовах на структурах — хм, в чем отличие я не в кусре.
Ни алгоритмы ни паттерны не отличают джуна от синера, а только опыт работы с инструментами, библиотеками, фреймворками, архитектурами и опыт общения с коллегами / заказчиками.
abstract/sealed — да уж, джун не потянет…
виртуальных вызовах на структурах — хм, в чем отличие я не в кусре.
Ни алгоритмы ни паттерны не отличают джуна от синера, а только опыт работы с инструментами, библиотеками, фреймворками, архитектурами и опыт общения с коллегами / заказчиками.
Странно, а что джун этого не может знать?
abstract/sealed — да уж, джун не потянет…
Конечно может, но это от него не требуется.
Знания того как работают виртуальные вызовы это и есть «опыт работы с инструментами». Рантайм это инструмент.
Конечно может, но это от него не требуется.Джун читает книгу о языке, и в той книге всё написано, как он может не знать?
как работают виртуальные вызовыэто в книге по с++ написано, и в книгах по другим языкам.
Или почитав книгу о таких вещах, я сразу перестал быть джуном?
А если бы я не знал этого, то я не синьер? В работе мне эти знания ни разу не пригодились. А если бы задача про это стояла, я бы как нибудь через гугл вышел и на решение и на знание.
А если бы я не знал этого, то я не синьер?
Очень-очень сомнительный сеньор.
В работе мне эти знания ни разу не пригодились.
Значит такая работа была.
Скорее всего вы придаете значение ерунде.
Работы были разные и хорошие и всякие.
А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
Работы были разные и хорошие и всякие.
А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
Любая работа, где необходимо хоть примерно представлять, насколько виртуальный вызов дороже невиртуального, почему так происходит и как этого избежать.
Практически ни на сколько, даже в циклах.
Ну то есть, вам тоже это ни разу не понадобилось, так?
Ну то есть, вам тоже это ни разу не понадобилось, так?
О каких циклах речь?
Тест за 5 минут
#include <iostream>
#include <cstring>
class IVirtualOp
{
public:
virtual void add() =0;
virtual long get() const =0;
~IVirtualOp() = default;
};
class VirtualAdd : public IVirtualOp
{
public:
void add() override
{
acc++;
}
long get() const override
{
return acc;
}
private:
long acc = 0;
};
class VirtualSub : public IVirtualOp
{
public:
void add() override
{
acc--;
}
long get() const override
{
return acc;
}
private:
long acc = 0;
};
void testNonVirtual(bool sub, long count)
{
long res;
if(sub)
{
VirtualSub o;
for(long i = 0; i < count; ++i)
{
o.add();
}
res = o.get();
}
else
{
VirtualAdd o;
for(long i = 0; i < count; ++i)
{
o.add();
}
res = o.get();
}
std::cout << res;
}
void testVirtual(bool sub, long count)
{
IVirtualOp* o = (sub) ? static_cast<IVirtualOp*>(new VirtualSub())
: static_cast<IVirtualOp*>(new VirtualAdd());
for(long i = 0; i < count; ++i)
{
o->add();
}
std::cout << o->get();
}
int main(int argc, char* argv[])
{
if(argc != 4)
return 0;
long count = atol(argv[3]);
bool useSub = strcmp(argv[2], "sub") == 0;
if(strcmp(argv[1], "n") == 0)
testNonVirtual(useSub, count);
else if(strcmp(argv[1], "v") == 0)
testVirtual(useSub, count);
return 0;
}
$ time ./tst n sub 1000000000
-1000000000
real 0m0,001s
user 0m0,000s
sys 0m0,001s
$ time ./tst v sub 1000000000
-1000000000
real 0m1,580s
user 0m1,577s
sys 0m0,003s
Ну как, ни на сколько, даже в циклах?
$ g++ --version
g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ time ./tst n sub 1000000000
-1000000000
real 0m2.859s
user 0m2.856s
sys 0m0.000s
$ time ./tst v sub 1000000000
-1000000000
real 0m2.916s
user 0m2.912s
sys 0m0.000s
От незадача! Как так?! :(
-O0?
Если бы только -O0. Конечно, сначала это было именно оно. Но достаточно убрать инлайн реализацию чтобы свести все к 1:1.
А часто в реальных проектах релизные сборки собираются с отключенными оптимизациями и запрещенным инлайном?
Далеко не все методы класса реализуются в инлайне, ведь правда? В том числе переопределенные виртуальные.
В вашем тесте сравнивается не виртуальность/невиртуальность но инлайн/неинлайн. Это уже немного о другом.
В вашем тесте сравнивается не виртуальность/невиртуальность но инлайн/неинлайн. Это уже немного о другом.
Ну например виртуальный вызов невозможно заинлайнить, а разницу между инлайн и нет вы сами показали.
Тогда это не будет виртуальный вызов, вот и всё :)
Я про случаи, где добавление/удаление словa «virtual» меняет семантику и результат выполнения кода.
Я про случаи, где добавление/удаление словa «virtual» меняет семантику и результат выполнения кода.
а виртуального вызова нет, компилятор всё заинлайнил.
Ну вот именно, там вызов невиртуальный. А был бы виртуальный — и заинлайнить бы не вышло :)
То есть заинлайнить можно тогда, когда компилятор может заменить виртуальный вызов обычным, что уже отдельная оптимизация (и после нее не обязательно будет следовать инлайнинг).
Ок, неверно сформулировал. Виртулизация в данном случае не дает ничего, потому что можно руками вызывать нужный метод. Виртуализация — это когда мы как раз-таки не знаем конкретный метод, который надо вызывать, потому что он должен определяться динамически. А тут это просто вызов конкретного метода, пусть немного необычным способом. Наверное, я неверно изначально критерии обозначил.
В очень хорошей статье про кост виртуальных вызовов написано:
http://ithare.com/c-performance-common-wisdoms-and-common-wisdoms/
Он есть. Но не он решает.
http://ithare.com/c-performance-common-wisdoms-and-common-wisdoms/
Он есть. Но не он решает.
Виртуальные вызовы конечно же заметно медленнее прямых.
Но ваш тест абсолютно некорректен.
Если бы вы скомпилировали без оптимизаций, я бы сказал что это нечестный бенчмарк, т.к. в продакшене всегда включают -O2.
Но, судя по результатам, вы таки включили O2. И компилятор не только заинлайнил вызовы, но и векторизовал их.
Интересно было бы послушать ваше объяснение на эту тему. Желательно в цифрах с описанием методологии измерения. Применительно к C++. Я не навязываюсь. Но уж если вы затронули эту тему и она проста и тривиальна как три рубля… Не затруднит ли вас?
Бенчмарки на коленке собирать? Затруднит, разумеется. Я не верю, что вы ничего не смогли найти на эту тему самостоятельно.
Я правильно понимаю, что аналогичным образом вы будете аргументировать свои за/против использования виртуальных методов в C++ потенциальному кандидату на собеседовании если его точка зрения разойдется с вашей?
Кандидат будет так же аргументировать незнанием или молчанием? Расскажу ему про vtable, указатель на нее и его разыменование. Но синттесты писать на коленке — это не самое благодарное занятие и если в вашей практике встретится такой интервьюер, то передавайте от меня привет)
Нет уж, паровоз, давай таки по рельсам…
>> А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
> Любая работа, где необходимо хоть примерно представлять, насколько виртуальный вызов дороже невиртуального, почему так происходит и как этого избежать.
Допустим, оппонент не знает как устроена таблица виртуальных методов. Это конечно печально. Рассказать, как она устроена — сам бог велел. В противном случае зачем задавать такой вопрос? Опять же «Бросая камушки в воду смотри на круги расходящиеся дабы не стало это занятие пустой тратой времени».
Но вот выводы — чем это грозит а тем более с точки зрения производительности системы — я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
>> А у вас какая работа была, что бы знать зачем VMT?
Может еще зачем то, кроме любопытства, нужно знать код машинной команды которая вызывает метод используя косвенную адресацию?
> Любая работа, где необходимо хоть примерно представлять, насколько виртуальный вызов дороже невиртуального, почему так происходит и как этого избежать.
Допустим, оппонент не знает как устроена таблица виртуальных методов. Это конечно печально. Рассказать, как она устроена — сам бог велел. В противном случае зачем задавать такой вопрос? Опять же «Бросая камушки в воду смотри на круги расходящиеся дабы не стало это занятие пустой тратой времени».
Но вот выводы — чем это грозит а тем более с точки зрения производительности системы — я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
я бы предложил не лезть в эту мутную реку. В зависимости от контекста все может быть сильно по-разному.
Напротив, это совсем не повод замыкаться в своем невежестве. Нужно читать умные книжки про оптимизацию, не стесняться лезть «под капот», развиваться шаг за шагом. Это показатель опыта, а не: «Я 15 лет хреначу CRUD'ы интернет-магазинов и делаю это быстрее всех, поэтому сеньор».
Это у вас в С++ всё инлайнится и «затирается» и на вкус и цвет почти как обычный вызов.
В .NET, на виртуальных методах будет проверка на нулевой указатель, а в некоторых случаях еще и копирования объекта в стеке перед каждым вызовом. А если объект, к примеру, толстый, то туши свет.
В .NET, на виртуальных методах будет проверка на нулевой указатель, а в некоторых случаях еще и копирования объекта в стеке перед каждым вызовом. А если объект, к примеру, толстый, то туши свет.
А вы что-то доказать хотите или предложить?
Почти никому не понадобится вбивать в гугл «как работают виртуальные методы в языке X» т.к. это не «проблема» которую надо решить. Нет проблемы «не работают виртуальные методы» или «я не могу сделать виртуальный вызов». Всё работало, и вам даже не интересно как это работало. А знания из разряда «как оно на самом деле работает» открывают дверь в чудный мир простых решений ака «хаков» и хитрых оптимизаций.
По поводу джунов и книг. Есть разница между «прочитать в книге» и «понять как оно работает». У джуна эти знания как влетят, так и вылетят. А потом на собеседовании он не вспомнит нужное слово или не сможет описать суть.
Есть классификации программистов, которая мне лично нравится:
Джун — тот кто решает простые проблемы сложным путем.
Мидл — тот кто решает простые проблемы простым путем, сложные сложным.
Сеньер — тот кто решает сложные проблемы простым путем.
По поводу джунов и книг. Есть разница между «прочитать в книге» и «понять как оно работает». У джуна эти знания как влетят, так и вылетят. А потом на собеседовании он не вспомнит нужное слово или не сможет описать суть.
Есть классификации программистов, которая мне лично нравится:
Джун — тот кто решает простые проблемы сложным путем.
Мидл — тот кто решает простые проблемы простым путем, сложные сложным.
Сеньер — тот кто решает сложные проблемы простым путем.
Есть у меня сам по себе интерес к подобному, но денег это не приносит.
Вот я и интересуюсь что это за работы. Какой спрос, какая плата. Я ни разу не дебажил ничего связанного с VMT.
Если не писать квадратичные алгоритмы и использовать кэши, то в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Конечно игры и 3D могут требовать иной подход, но спрос на подобное, в процентах ИМХО ничтожен.
Вот я и интересуюсь что это за работы. Какой спрос, какая плата. Я ни разу не дебажил ничего связанного с VMT.
Если не писать квадратичные алгоритмы и использовать кэши, то в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Конечно игры и 3D могут требовать иной подход, но спрос на подобное, в процентах ИМХО ничтожен.
в типичных бизнес приложениях, которых 99% на рынке, и не надо никаких других оптимизаций.
Типичное бизнес-приложение балансирует на грани «дешево, юзеры еще не жалуются, что из-за тормозов невозможно работать» и «нужно бы виртуалке больше оперативки накинуть». Ибо фичи нужно пилить, некогда рефакторинг, да еще и тестировать потом…
Вы как будто анекдот не помните...
В институте на разных курсах задают вопрос: сколько будет 2 умножить на 2?
Первокурсник: (бодро) 4!
Второкурсник: (достаёт таблицу умножения, смотрит) 4!
Третьекурсник: (достаёт таблицу логарифмов, смотрит, считает) 4!
Четверокурсник: (достаёт логарифмическую линейку, щёлкает пару секунд) с удвлетворительной точностью — 4!
Пятикурсник: Да что я вам, слон — все константы наизусть помнить?!
Сеньер — должен рассказать о виртуальных вызовах на интерфейсах/структурах. И в плюсы ему пойдет знания о том как работает VMT и во что компилируются подобные вызовы, как можно «убрать» боксинг/виртуальный вызов через дженерики
Знал как устроена VMT еще в школьные годы. То есть это до джуна.
Затем забыл за ненадобностью.
Сеньор даже на уровне паттернов работает уже на уровне уровне автоматизма, а вы про какие-то байтики спрашивайте.
Если этот сеньор будет разрабатывать компилятор — то знание VMT будет ему крайне нужно.
Иначе — зачем?
Приведите конкретный кейс, пожалуйста.
Я забыл слово. Не поведение, которое оно даёт.
Что такое virtual?
Бам!
Слово вам как раз сказали, вы забыли связь слова с его значением. Это уже не так невинно звучит.
И мгновенно превратился в самозванца, да.
Ну это действительно странно выглядит.
Понимаю, что заклинить может (надосып, переработка, бодун...) кого угодно, но зачем за столь очевидный косяк переводить стрелки на интервьюера? Вопрос достаточно очевидный и это совсем «не пыльный угол» сишарпа.
Понимаю, что заклинить может (надосып, переработка, бодун...) кого угодно, но зачем за столь очевидный косяк переводить стрелки на интервьюера? Вопрос достаточно очевидный и это совсем «не пыльный угол» сишарпа.
Проблема как раз в том, что я начинаю размышлять так же, как вы, и сам себя определяю как самозванца. С другой стороны, у меня есть серьёзные основания быть уверенным в себе. Короче, мне не комфортно, когда мне не предоставляют возможности донести до интервьювера уровень моих знаний и опыта. Возьмут меня или нет на работу — это их дело.
Вся ваша рефлексия должна бы закончиться на результатах анализа, почему ваш интервьюер обрадовался вашей неудаче.
Проблема как раз в том, что я начинаю размышлять так же, как вы, и сам себя определяю как самозванца.
Каким образом это является проблемой?
То, чем вы сейчас занимаетесь — контрпродуктивно. Так или иначе — косяк случился и есть два путя: сделать вид, что все нормально и так сойдет, или постараться больше таких проколов не допускать.
Ну так тут два варианта: либо у вас был ступор, либо вы — fraud. Многие почему-то принимают первое за второе. У меня когда-то спросили можно ли написать
Мои шестеренки сразу заклинило, я с трудом выдавил «нет» и на вопрос «а как сделать, чтобы можно было?» я не ответил, потому что не мог понять, что от меня вообще хотят и зачем это надо. А собеседующий всего лишь хотел услышать, что я знаю как работать с префиксом @:
class object : object
{ }Мои шестеренки сразу заклинило, я с трудом выдавил «нет» и на вопрос «а как сделать, чтобы можно было?» я не ответил, потому что не мог понять, что от меня вообще хотят и зачем это надо. А собеседующий всего лишь хотел услышать, что я знаю как работать с префиксом @:
class @object : object
{ }Не быть вам филологом.
Судя по всему, да.
Если не ошибаюсь, есть специальный веб-сервис для таких «переворотов»
Если не ошибаюсь, есть специальный веб-сервис для таких «переворотов»
Мы даем домашку на неделю. Если человек в теме ему на пару часов, если нет — день-два по вечерам разобраться. Заодно видно, как человек относится к изучению нового.
Если за пару часов я не решу, то зачем мне бесплатно этим заниматься? Ну попалась тема которую мне нужно исследователь что бы решить задачу, но зачем мне тратить свое время, это проблема работодателя — либо учить, либо найти готового. Программисты нарасхват.
Затем, что больше двух часов оно у вас займет как раз потому что для вас будет чем-то новым. Если вы от возможности узнать что-то новое воротите нос, то и зачем вы такой нужны?
Вот именно, если новое, то зачем учить WPF когда на React спрос больше?
В мире столько вещей которые любопытно изучать — жизни не хватит. Тут не про воротить нос, а про целесообразность. Дело не в новом, а в выгодном.
В мире столько вещей которые любопытно изучать — жизни не хватит. Тут не про воротить нос, а про целесообразность. Дело не в новом, а в выгодном.
новое — не всегда интересное. область моих интересов в it, например, как правило работодателю не нужна. а нужны реакты, редуксы и прочии нахайпованные go
Разумеется, это право соискателя — отказаться от задания. Но пока не отказывались.
Я бы назвал это антипаттерном собеседования. На собеседования итак уходит много времени. Если на каждое делать тестовое — уйдут дни. Проверять тестовое тоже нужно время, не проще ли лично поговорить? И что даст понять тестовое задание? Если оно маленькое, то на позициях кроме junior это ничего не даст абсолютно. На позициях выше — у кандидата наверняка найдутся мегабайты кода с примерами. Если вам нужен сильный специалист, готовы ли вы ждать его эту неделю? Если он и правда хорош, есть ненулевая вероятность что за неделю он успеет отсобеседоваться и принять оффер от другой компании.
Тестовое задание может много что сказать о человеке. Например были случаи, когда «сениоры» писали классы, с глобальными переменными, были случаи, когда другие «сениоры» копипастили код со stackoverflow, который содержал ошибки (ну что можно сказать о человеке, который не смог сам реализовать strnstr, когда она ему понадобилась, а после этого ещё и не проверил тот код, что нашёл на просторах интернета). Были случаи, когда код присылали полностью рабочий, но абсолютно не читаемый, что в нём эксперты не могли за полчаса разобраться. Или что код вроде даже читаемый, но абсолютно не структурирован, т.е. в случае необходимости его расширить/дополнить он на 80% пойдёт в мусорку.
Я последнее время прошу прислать часть проблемного/работающего кода и смотрю перед тем как на письмо отвечать. Сразу показывает многое про уровень. В одной конторе транзакционность сделали по дате, а при вопросе — почему не уровне полей (удобнее для людей), даже не поняли о чём речь. Хотя надувались на virtual/object/var и прочую ерунду (это видимо в какой то методичке написали, а потом все copy/paste в мозг переносят).
Это кто кандидатам будет продакшин код высылать? Ни разу про такое не слышал
Про улучшение качества мультфильмов при помощи компьютера тоже никто не слышал 10 лет назад. Я и не требую весь production код.
Но везде люди работают — значит и ошибаются.
github.com/aeroflotsrc/webapp
github.com/aeroflotsrc/webapp
Первое в жизни собеседование на программиста проходило так: спросили, есть ли у меня какой-то код, типа учебного проекта. У меня как раз такой был, его и показал. Попросили добавить туда несколько фич. Что-то смог добавить сам, что-то не смог в силу недостатка знаний, но с парой подсказок таки допилил. Ушло на все собеседование часа 4. В итоге все успешно, приняли на работу. Не верил своему счастью, чувствовал себя самозванцем еще несколько месяцев.
Интересная штука. Почему все работодатели боятся нанять «самозванца», но при этом не боятся отдавать заказ подрядчикам? И ведь собеседований с ними не проводят же.
При том, что на моём опыте подрядчики даже с известным именем могут совершить такие лютые факапы, что даже отдел самозванцев на сможет с ними сравниться.
При этом они еще регулярно нанимают самозванцев — профессиональных проходильщиков собеседований.
Наверное потому, что подрядчика легче сменить, чем наёмного работника по ТК)
Так есть же испытательный срок. Ну или вначале вообще можно временный договор заключать. И по ГПХ можно работать. Много всяких вариантов.
Для подрядчиков есть тендеры и если проект важный, то допускают туда не полных лохов. Требуют наличие сертифицированных специалистов в команде и серьезного портфолио сданных проектов. Могут пообщаться с клиентами подрядчика чтобы узнать их мнение и пр. Это аналог собеседования. Само собой так делают не все, но на крупных проектах где крутятся большие бабки, а заказчик хочет именно качественный результат, это нормально.
От работодателя зависит, некоторые (может мне везло, но не меньше трети) таки проводят собеседования для подрядчиков, причем если сравнивать 3 собеседования как сотрудника подрядчика и 6 как просто соискателя за последний год, именно как сотрудника подрядчика меня гоняли гораздо больше и собеседования были сложнее (я бы даже сказал что там другая проблема была — у меня возник вопрос «нафига было меня собеседовать больше двух часов чтобы в итоге посадить на ЭТО» что во многом подтолкнуло ко второй 6-ке собеседований :) )
О, это я скоро буду наблюдать вживую! У нас новый менеджмент уволил целый отдел удаленщиков и собирается отдать код на аутсорс в США (а те в Индию, как водится — дураки что ли в США код писать?).
Я сам провел не один десяток собеседований, и мне кажется, что научился это делать не совсем плохо. Так вот, я сам на собеседование с тестом на бумажке просто не пойду: постараюсь выяснить регламент заранее и если там подразумевается нечто подобное — сразу откажусь. Я готов притащить ноут, показывать свой код, рассказывать о своих проектах и говорить на любые профессиональные темы. Готов выполнить тестовое задание адекватного объема. Но от этого тупняка с бумажками у меня глаз дергается. Думаю что если боевой разработчик, проводящий техническое интервью, не способен разглядеть самозванца через пару-тройку общих вопросов — то грош ему цена и место в детском саду.
По-моему, у боевых разработчиков часто нет времени на проведение интервью :)
А случаи, когда в одном человеке есть и глубокие тех. знания, и хорошие soft skills, и правильный настрой не заваливать и самоутверждаться — крайне редки.
По-моему, у боевых разработчиков часто нет времени на проведение интервью :)
Ну в разных местах команды формируются по разным принципам: в бодишопах действительно, все будут заняты и не смогут далеко отойти от капельницы с глюкозой. А в проектных командах людям бывает не все-равно с кем идти в бой, поэтому они сами очень заинтересованы и находят время. Но, тем не менее, редко кто может правильно поговорить. С обеих сторон =)
Проблема в том, что кроме категории «самозванец» существует уровень разработчика как таковой. Его часто необходимо определить достаточно точно, на сколько это возможно, конечно. Я бы усилил ваше высказывание и сказал, что именно самозванцев (т.е. абсолютных нулей или близких к ним) часто можно и по резюме определять, остальные отсеиваются на skype интервью. Бумажка вовсе не так плоха, как про нее пишут. Например, сделать reverse строки — это достаточно просто. Если такое сложно написать на бумаге правильно, то скорее всего человек если и действительно занимается программированием, то привык заниматься им в стиле «что-то не работает, поправлю как я вот здесь, авось заработает», «ой, что-то не заработало, наверное, еще нужно поправить вот здесь и вот тут». Кому-то здесь нужны такие специалисты?
Проблема в том, что бумажка вам не скажет о уровне разработчика ВООБЩЕ НИЧЕГО. Только реальный код реальных проектов и общая инженерная философия человека. По моему опыту, люди блестяще проходившие бумажные тесты часто оказывались полнейшими мудаками в работе, и напротив, люди сомневающиеся и робкие показывали себя как офигительные и весьма ценные специалисты, ко мнению которых стоит прислушиваться всегда.
«Оказывались полными мудаками» — это разве про уровень разработчика? Это про общий подход к работе и soft skills. Или что вы имеете в виду?
Она скажет:
1) об умении сначала думать, потом делать и делать аккуратно
2) писать не очень сложный код без ошибок
3) придумывать алгоритмы для сформулированных задач в ограниченное время
4) о знании базового синтаксиса языка без Google и SO. Например, сколько раз я уже видел кандидатов, которые путают названия контейнеров в STL и их методов, по ним сразу видно, что hands on опыта с ними они не имеют. Разработчик, который не помнит, что в вектор добавляет метод push_back — это очень интересно, конечно :)
Я вовсе не предлагаю использовать бумажку (В значении coding interview) как единственный способ проведения собеседования и не утверждаю, что это единственный способ проверять skills. Но это достаточно действенный способ, который имеет распределение успехов, по которому можно неплохо пытаться определяться уровень в том числе. Скажем, вы даете написать 3-4 алгоритма разной сложности (подразумеваю, что речь идет о позиции, что где алгоритмы являются критичным навыком), далее можно построить распределение, по которому будет видно, что большинство справляется с 1-2 задачами с разной чистотой выполнения оных и далее все идет по убыванию. Действительно редкие специалисты способны закодить все 4, не допустив или почти не допустив ошибок. Если в вашей работе почти каждый код — это алгоритм, то такая проверка уже, на самом деле, многое скажет о том, что вы можете ожидать, наняв человека. Между «писать код на бумажке» и «писать код на ноутбуке» с моей точки зрения разницы не очень много, т.к., например, лично я почти не даю на собеседованиях реально технически сложных для кодирования задач, которые без клавиатуры делаются просто напросто долго, но некоторые этим злоупотребляют.
«бумажка вам не скажет о уровне разработчика ВООБЩЕ НИЧЕГО»
Она скажет:
1) об умении сначала думать, потом делать и делать аккуратно
2) писать не очень сложный код без ошибок
3) придумывать алгоритмы для сформулированных задач в ограниченное время
4) о знании базового синтаксиса языка без Google и SO. Например, сколько раз я уже видел кандидатов, которые путают названия контейнеров в STL и их методов, по ним сразу видно, что hands on опыта с ними они не имеют. Разработчик, который не помнит, что в вектор добавляет метод push_back — это очень интересно, конечно :)
Я вовсе не предлагаю использовать бумажку (В значении coding interview) как единственный способ проведения собеседования и не утверждаю, что это единственный способ проверять skills. Но это достаточно действенный способ, который имеет распределение успехов, по которому можно неплохо пытаться определяться уровень в том числе. Скажем, вы даете написать 3-4 алгоритма разной сложности (подразумеваю, что речь идет о позиции, что где алгоритмы являются критичным навыком), далее можно построить распределение, по которому будет видно, что большинство справляется с 1-2 задачами с разной чистотой выполнения оных и далее все идет по убыванию. Действительно редкие специалисты способны закодить все 4, не допустив или почти не допустив ошибок. Если в вашей работе почти каждый код — это алгоритм, то такая проверка уже, на самом деле, многое скажет о том, что вы можете ожидать, наняв человека. Между «писать код на бумажке» и «писать код на ноутбуке» с моей точки зрения разницы не очень много, т.к., например, лично я почти не даю на собеседованиях реально технически сложных для кодирования задач, которые без клавиатуры делаются просто напросто долго, но некоторые этим злоупотребляют.
Вы пытаетесь применять редукционистский подход к очень сложной хаотической системе, включающей кучу аспектов, которые вы не видите и не хотите учитывать: факторы среды, эмоциональный и социальный бэкграунд, нюансы специализации и конкретного опыта… Таким образом, математически можно обосновать почему ваше итоговое распределение будет принимать формы, весьма далекие от реального положения вещей (см. теорию хаоса). Ваш список рассыпется полностью и уже на этапе добавления в систему факторов психологической реакции на тесты. Ваш метод с бумажкой — это иллюзия контроля в чистом виде, банальный способ переложить ответственность на примитивную методологию.
Во-первых, прошу прощения, но собеседование само по себе — это и есть редукционистский и, безусловно, относительный подход: вы пытаетесь за 2-4 часа оценить опыт/навыки человека, который работал, к примеру 10 лет. Тут именно вопрос в том, как именно редуцировать так, чтобы проверять наиболее релевантное. Во-вторых, я снова повторюсь, что провожу собеседования комплексно и оцениваю на нем и в том числе и «нюансы специализации и конкретного опыта». Но если человек, имеющий хотя бы какой-то опыт, который можно считать приличным, не может написать простой код без ошибок на бумаге даже с 3-ей попытки — это, снова повторюсь, говорит о том, что если он и реально что-то разрабатывает (а не просто все наврал в резюме), то его подход к разработке основан на гуглении и бездумном итеративном устранении ошибок методом тыка. Это не тот уровень разработчиков, с которыми я работал когда-либо :)
Ну и какое же реальное положение вещей, просветите пожалуйста? :)
Ну а ваша то методология какая? Демонстрировать написанный код? Хорошо, а если ваш код не покрывает тех случаев, которые бы я хотел увидеть? Готовы дописать ваш код прямо на собеседовании? :) Ведь это будет сложнее, чем начать сначала на абстрактной задаче. Дальше: где гарантия того, что этот код написан самостоятельно и что он написан в приемлемые сроки? Где гарантия, что этот код вообще правильный? Итд.
весьма далекие от реального положения вещей (см. теорию хаоса)
Ну и какое же реальное положение вещей, просветите пожалуйста? :)
банальный способ переложить ответственность на примитивную методологию
Ну а ваша то методология какая? Демонстрировать написанный код? Хорошо, а если ваш код не покрывает тех случаев, которые бы я хотел увидеть? Готовы дописать ваш код прямо на собеседовании? :) Ведь это будет сложнее, чем начать сначала на абстрактной задаче. Дальше: где гарантия того, что этот код написан самостоятельно и что он написан в приемлемые сроки? Где гарантия, что этот код вообще правильный? Итд.
Так вот, я сам на собеседование с тестом на бумажке просто не пойду: постараюсь выяснить регламент заранее и если там подразумевается нечто подобное — сразу откажусь. Я готов притащить ноут, показывать свой код, рассказывать о своих проектах и говорить на любые профессиональные темы. Готов выполнить тестовое задание адекватного объема. Но от этого тупняка с бумажками у меня глаз дергается
Хочу точно такое же, но много ли компаний сейчас разделяют ваш подход? Можно ли как-то распространить такую практику чтоб в мире стало поменьше говнособеседователей и побольше адекватных?
Честно сказать, не рассказать на собеседовании про virtual — это плохой показатель, но не фатальный, конечно. Учитывая волнение.
Позвольте немного рассказать как обычно идет процесс найма, возможно у вас отпадут некоторые вопросы.
Первый этап. На нем нужно узнать что кандидат проходит минимальные требования. Потому что тратить полтора часа рабочего времени на то чтобы понять что мы друг другу не подходим — это много. Поэтому обычно его проводит HR. Тут есть несколько вариантов: просто посмотреть резюме, дать тестовое, дать небольшой опросник. Я лично считаю что достаточно посмотреть резюме, но вариант с опросником тоже хорош, так как он дает темы для общения на втором этапе собеседования.
Второй этап. Здесь уместно провести личное общение с теми, с кем непосредственно будет работать кандидат. Задача собеседующего понять, будет ли комфортно вместе работать. Тут несколько аспектов: опыт, технические знания, личностные качества, потенциал развития, насколько хорошо кандидат вольется в коллектив. И да, если это скайп, то желательно с видео. Очень полезно видеть реакцию человека. Самый простой путь, на мой взгляд, сначала послушать человека о его опыте, идеях и вообще все что ему интересно рассказать. Это и расслабляет кандидата, и в то же время дает 90% всего что вы хотите знать, и дает темы для технических вопросов. Затем перейти к техническим вопросам, может порешать какие-то задачи, дабы просто послушать ход мыслей собеседуемого. Обязательно нужно рассказать про свой проект, чем придется заниматься кандидату, какие у него перспективы и ответить на вопросы.
Третий этап. Общение с начальством, HR о условиях, деньгах и все такое.
Позвольте немного рассказать как обычно идет процесс найма, возможно у вас отпадут некоторые вопросы.
Первый этап. На нем нужно узнать что кандидат проходит минимальные требования. Потому что тратить полтора часа рабочего времени на то чтобы понять что мы друг другу не подходим — это много. Поэтому обычно его проводит HR. Тут есть несколько вариантов: просто посмотреть резюме, дать тестовое, дать небольшой опросник. Я лично считаю что достаточно посмотреть резюме, но вариант с опросником тоже хорош, так как он дает темы для общения на втором этапе собеседования.
Второй этап. Здесь уместно провести личное общение с теми, с кем непосредственно будет работать кандидат. Задача собеседующего понять, будет ли комфортно вместе работать. Тут несколько аспектов: опыт, технические знания, личностные качества, потенциал развития, насколько хорошо кандидат вольется в коллектив. И да, если это скайп, то желательно с видео. Очень полезно видеть реакцию человека. Самый простой путь, на мой взгляд, сначала послушать человека о его опыте, идеях и вообще все что ему интересно рассказать. Это и расслабляет кандидата, и в то же время дает 90% всего что вы хотите знать, и дает темы для технических вопросов. Затем перейти к техническим вопросам, может порешать какие-то задачи, дабы просто послушать ход мыслей собеседуемого. Обязательно нужно рассказать про свой проект, чем придется заниматься кандидату, какие у него перспективы и ответить на вопросы.
Третий этап. Общение с начальством, HR о условиях, деньгах и все такое.
Дело не только в волнении, а в том что каждое гребаное собеседование превращается в экзамен. Может быть вы не в курсе: не только вы выбираете сотрудника, а так же соискатель выбирает место работы. Может мне тогда тоже начать сыпать вопросами нонстоп? А что, в говнокоде ковыряться всю жизнь тоже желания нет.
Озвучьте блин проблему, я скажу как ее решить.
Озвучьте блин проблему, я скажу как ее решить.
Может мне тогда тоже начать сыпать вопросами нонстоп?
А как же. Это нормально, когда и кандидат спрашивает, что его интересует, и про процессы, и про задачи, и даже просит рабочие места и другую инфраструктуру (комнаты отдыха, кухню, туалеты) показать. Меня один кандидат однажды больше часа выспрашивал разные детали, хотя перед этим я его больше получаса сам рассказывал про компанию в общем и про разработку в частности.
*Тоном экзаменатора*
— Два монитора конечно же на рабочем месте?
— Столешница толщиной не менее 2 см?
*как будто обращаюсь к двоечнику*
— Ну CO2 то хотя бы контролируется?
— А говорили солидная компания...
Вот примерно так это бы выглядело зеркально, ибо как раз так оно и происходит со стороны работодателя: не относящиеся к делу случайные вопросы в таком тоне, что аж руки вытереть потом хочется.
— Здравстуйте, вы ээ (читая резюме и анкету) ага Вячеслав, да точно
— Вы я вижу с PHP работаете, о а что такое __autoload
— Как незнаете? базовые же вещи!
— Ой а я вижу вы еще postgreSQL работаете? Расскажите как работает файловый кеш линукса. Ну как зачем, у нас серьезная производительность!
— О а гит! Вы же должны знать команды. Как не работали?
По мне выглядит одинаково. Со стороны соискателя даже поадекватней будет. Я это вот все слышал раз 20 как минимум в разных вариациях, с менторским тоном и взглядом как на говно, и я буду продолжать говорить «не знаю», потому как либо у нас таки случиться интересный диалог либо «вы мне не подходите».
Я даже объясню почему. Тот же автолоадер, когда он мне понадобился я взял из какого то фрейма, переписал под свои реалии, подключил и забыл. Я помню свой код почти построчно, но помню я почему и как он работает а не названия функций.
Систему контроля версий я лично не использую, оно мне не надо, когда нужно я открываю документацию настраиваю и забываю.
Если при использовании бд вы упираетесь в производительность диска, и при этом база и wal и журнал фс у вас лежат на разных дисках, то вы делаете чтото сильно не так. И не надо смотреть на меня как на идиота, исключение — серьезные объемы данных, и нет 100 млн записей это не тот случай.
Я с удовольствием пообщаюсь с коллегой, я всегда рад, правда. В режиме доброжелательного диалога, на тему любимых и нелюбимых штук например. С обоснованием естественно. Но такое случается крайне редко.
Систему контроля версий я лично не использую, оно мне не надо, когда нужно я открываю документацию настраиваю и забываю.
Это не характеризует вас как сколько-нибудь хорошего разработчика. Скорее как пафосного дилетанта.
Это не характеризует вас как сколько-нибудь хорошего разработчика. Скорее как пафосного дилетанта.
Ну вот о чем и речь собственно. Откуда столько токсичности? Где пафос то? Откуда выводы о дилетанстве. Будьте добры аргументов накидать.
Когда заказчику нужно я ее цепляю в IDE и веду согласно требованиям. Зачем мне лично система контроля версий?
Ваше отношение к СКВ говорит о том, что вы а) никогда не работали в команде, б) не способны работать в команде в данный конкретный отрезок времени.
Поздравляю коллега, ошиблись по обоим пунктам. Опять же не вижу аргументации. И еще интересней каково же мое отношение?)
Вы, я так понял, выступаете наглядным примером к тому о чем я говорю? У вас получилось. Сделали выводы, вынесли вердикт, плюнули в душу, ни на один вопрос не ответили. Оппонента спросить или подискутировать? Да нахрен оно надо, правда?)
Вы, я так понял, выступаете наглядным примером к тому о чем я говорю? У вас получилось. Сделали выводы, вынесли вердикт, плюнули в душу, ни на один вопрос не ответили. Оппонента спросить или подискутировать? Да нахрен оно надо, правда?)
Ну, давайте подискутируем.
Вы утверждаете, что а) имеете опыт разработки в команде, б) команде СКВ не нужны.
1. Подскажите, как в вашей команде решается вопрос «сведения» кода нескольких разработчиков в одну кодовую базу.
2. Все разработчики в вашей команде, очевидно, код пишут сразу правильный, безошибочный и оптимальный?
3. Вы делите сборки на тестовые/прод? Из каких исходников вы это собираете? Каким образом вы решаете проблему необходимости быстрого выкатывания патчей на прод в момент, когда вы глубоко «зарылись» в реализацию новой фичи? Срочный патчфикс ждет, пока вы фичу не допилите?
4. Если новая фича не удовлетворила, по каким-то причинам, требованиям заказчика, вы руками вычищаете изменения?
5. Какие «профиты» вы получаете от отказа от систем контроля версий?
6. CI/CD у вас, видимо, не используется? Автоматизация сборки?
7. Вы уверены, что ваши практики лучше общепринятых в разработке? Как вы думаете, что скажет хороший опытный разработчик, который, предположим, к вам на работу устраивается, когда узнает, что внутри вашей организации практики управления кодом, являющиеся стандартом де-факто, не приняты, и у вас своя система правил?
Собственно, наличие СКВ — это всего лишь первый шаг к профессиональной разработке. Вы, пока что, не сделали и его.
Вы утверждаете, что а) имеете опыт разработки в команде, б) команде СКВ не нужны.
1. Подскажите, как в вашей команде решается вопрос «сведения» кода нескольких разработчиков в одну кодовую базу.
2. Все разработчики в вашей команде, очевидно, код пишут сразу правильный, безошибочный и оптимальный?
3. Вы делите сборки на тестовые/прод? Из каких исходников вы это собираете? Каким образом вы решаете проблему необходимости быстрого выкатывания патчей на прод в момент, когда вы глубоко «зарылись» в реализацию новой фичи? Срочный патчфикс ждет, пока вы фичу не допилите?
4. Если новая фича не удовлетворила, по каким-то причинам, требованиям заказчика, вы руками вычищаете изменения?
5. Какие «профиты» вы получаете от отказа от систем контроля версий?
6. CI/CD у вас, видимо, не используется? Автоматизация сборки?
7. Вы уверены, что ваши практики лучше общепринятых в разработке? Как вы думаете, что скажет хороший опытный разработчик, который, предположим, к вам на работу устраивается, когда узнает, что внутри вашей организации практики управления кодом, являющиеся стандартом де-факто, не приняты, и у вас своя система правил?
Собственно, наличие СКВ — это всего лишь первый шаг к профессиональной разработке. Вы, пока что, не сделали и его.
команде СКВ не нужны.
Ни разу этого не сказал.
Я полагаю, что вы меня недопоняли. Я абсолютно не против СКВ, если команде/заказчику это нужно. Но нюансами я голову себе не забиваю, это всего лишь инструмент, к тому же не все используют гит.
Сам же я для своих проектов СКВ не использую, нет в том необходимости. Практически вся кодовая база двигается исключительно в сторону наращивания функционала.
Взаимодействие с другими разработчиками в рамках таких проектов как правило ограничивается разработкой модулей. Но на крайний случай есть репозиторий.
Для собрки написана пачка скриптов. Развертывается силами IDE на мой сервер.
Собственно, наличие СКВ — это всего лишь первый шаг к профессиональной разработке. Вы, пока что, не сделали и его.
Знаете, многовато пафоса в мире, где практически все пишут по принципу «херак херак и в продакшен». Я правда верю, что где то есть мир с тестами, оптимальным кодом и прочими поэтессами. Но почему то что ни просят доработать, какой продукт не возьми, везде какой-то бред происходит.
Я абсолютно не против СКВ, если команде/заказчику это нужно.
Нет никаких «если». Профессиональной команде нужно.
Сам же я для своих проектов СКВ не использую, нет в том необходимости.
Т.е. ваши проекты — это ваши проекты, вы их разрабатываете, и к команде это отношения не имеет? Т.е. вы не работаете в команде?
Практически вся кодовая база двигается исключительно в сторону наращивания функционала.
Из «админского»…
Сисадмины делятся на 2 категории:
1. Те, которые еще не делают бэкапов.
2. Те, которые уже делают.
Так же и у разработчиков с СКВ.
Взаимодействие с другими разработчиками в рамках таких проектов как правило ограничивается разработкой модулей.
Т.е. командной работы над общим проектом нет.
Но на крайний случай есть репозиторий.
А это в каком виде?
Для собрки написана пачка скриптов.
Тоже весьма «характерно».
Развертывается силами IDE на мой сервер.
Фееричный продакш-подход для хайлоад энтерпрайз-приложений.
Знаете, многовато пафоса в мире, где практически все пишут по принципу «херак херак и в продакшен».
Вы судите по себе.
Я правда верю, что где то есть мир с тестами, оптимальным кодом и прочими поэтессами.
Но, очевидно, абсолютно туда не стремитесь.
Но почему то что ни просят доработать, какой продукт не возьми, везде какой-то бред происходит.
Вы просто не сталкивались с серьезными крупными проектами. В них происходящий бред, хотя бы, тестами покрыт, и, в целях «расследования инцидента», можно историю коммитов посмотреть.
Нет никаких «если». Профессиональной команде нужно.
Это не моего ума дело до тех пор пока я не тим лид.
Т.е. ваши проекты — это ваши проекты, вы их разрабатываете, и к команде это отношения не имеет? Т.е. вы не работаете в команде?
Над своими? Я уже описал, что бывает заказываю модули. Вот новый скоро будет уже в команде, размеры там эпические.
Сисадмины делятся на 2 категории:
1. Те, которые еще не делают бэкапов.
2. Те, которые уже делают.
Моя кодовая база существует меня на машине, в архивах релизных версий на файлохранилище, на сервере и в виде инкрементальных бекапов вместе со всей системой.
А это в каком виде?
В виде гит репозитория.
Тоже весьма «характерно».
Характерно что, скрипты собирающие css/js? Не понял в чем суть.
Фееричный продакш-подход для хайлоад энтерпрайз-приложений.
Вы толи читать не умеете, толи как… Есть регламенты у конкретных заказчивков — они соблюдаются. Я вам рассказываю как я делаю у себя. И да кстати ентерпрайз. А хайлоад, я вас умоляю. Яж не яндекс какой нить. Откуда кстати резко у всех вдруг хайлоад?
Вы судите по себе.
Да что вы говорите. Я вижу сколько мне головняков доставлает мегаплан, amocrm и прочие и прочие. К тому же я часто общаюсь вынужденно со всевозмоными веб студиями. Ох да я до утра могу перлы рассказывать.
Но, очевидно, абсолютно туда не стремитесь.
Если туда, это в мир, где мне придеться каждый день вот а таком ключе общаться? Нет не стремлюсь. Я стремлюсь туда где два разработчика могут посидеть за чашечкой и поделиться опытом невзирая на пол/возраст/рассу и прочую хрень вместо унылого тыкания друг друга моськой в свое болото.
Вы просто не сталкивались с серьезными крупными проектами. В них происходящий бред, хотя бы, тестами покрыт, и, в целях «расследования инцидента», можно историю коммитов посмотреть.
Смешная шутка. Особенно про тесты. Я всегда вспоминаю такие фразы когда по 2 месяца доказываю очередному CTO 'крупного проекта' что я не осел. И что характерно ниразу не был не прав пока.
Кстати а примерчик «крупного проекта» можно?
Вот новый скоро будет уже в команде, размеры там эпические.
Критерий «эпических размеров» можно?
Моя кодовая база существует меня на машине, в архивах релизных версий на файлохранилище, на сервере и в виде инкрементальных бекапов вместе со всей системой.
Т.е. вы проблему контроля версий решаете средствами бэкапов. А, ок…
Я вам рассказываю как я делаю у себя.
Красиво перефразированное «у меня все работает», ага.
И да кстати ентерпрайз.
Ручной деплой средствами IDE в прод, простите, энтерпрайз? А кроме локалхост-окружений что-нибудь деплоите?
Я вижу сколько мне головняков доставлает мегаплан, amocrm и прочие и прочие.
И что из этого, простите, относится к категории «системы контроля версий»? С какого перепугу CRM вообще вдруг нарисовались в контексте обсуждения систем контроля версий?
К тому же я часто общаюсь вынужденно со всевозмоными веб студиями. Ох да я до утра могу перлы рассказывать.
А это какое отношение к СКВ имеет?
Смешная шутка. Особенно про тесты.
Ну, т.е. «я не видел проектов с тестами, значит они не нужны» и «я не понимаю, зачем мне системы контроля версий, но я офигенный профессиональный разработчик».
А какой смысл вы, например, вкладываете в термин «профессиональный разработчик»? И особенно в контексте «чем профессиональный разработчик отличается от талантливого энтузиаста»?
Смешная шутка
В каком месте? Как вы отслеживаете изменения и их причины спустя время? Как вы работаете совместно над одним модулем?
Шутка относиться не к СКВ а к сферическим «большим» проектам. Я просто постоянно вижу как крупные сервисы с релизом новой версии ломают работу своих пользователей на дни/недели/месяцы, молчу о багах, которые висят годами.
Причины мне отслеживать не нужно, я просто помню все что написал. А вместе над одним модулем вне регламентов заказчика/работодателя только собираюсь. Отчасти потому что модуля достаточно маленькие и самодостаточные, но время пришло им стать одним большим приложением.
Причины мне отслеживать не нужно, я просто помню все что написал. А вместе над одним модулем вне регламентов заказчика/работодателя только собираюсь. Отчасти потому что модуля достаточно маленькие и самодостаточные, но время пришло им стать одним большим приложением.
Причины мне отслеживать не нужно, я просто помню все что написал.
Не, так не пойдет, это читерство. Мы тут про нормальных людей, а не про обладателей феноменальной памяти.
Причины мне отслеживать не нужно, я просто помню все что написал
Это, конечно, мое личное дело, но я не верю. При постоянной работе, если впроекте миллионы строк, ты уже через неделю забываешь конкретику, переключаясь на другие задачи.
А вместе над одним модулем вне регламентов заказчика/работодателя только собираюсь.
Ну так представьте, что у вас бибилиотечный модуль с «подсобными» функциями. Вы в этот модуль добавляете функцию, а ваш коллега правит или удаляет существующую. Вам надо ваши действия координировать. СКВ это позволяет.
Это, конечно, мое личное дело, но я не верю.
Вы правы и разубеждать мне лениво. Хотя ради проверки себя вот сейчась метнулся в единственное место где у меня есть дебильный комментарий, не используя поиск и окинул взглядом всю функцию на предмет вопросов. Нет, вопросов нет. Писалось лет 9 назад.
//xpath magic
var result = document.evaluate("tbody/tr[not(contains(translate(., '"+search.toUpperCase()+"', '"+search+"'), '"+search+"'))]",
tableObj,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null);
Красиво и лаконично, ведь правда?) Это элегантное, трудночитаемое решение довольно эффективно, но если не помнишь что это быстро понять достаточно сложно.
UPD: блин чето вывернуло блок омерзительно тут 8(
Пока это писал вспомнил что куда то сбежал модуль, расставляющий автоматически ссылки на манер вики, а потом вспомнил еще штук 10 клевых штук который надо бы чуть подпилить наверное, столько лет прошло.
СКВ это позволяет.
Я в курсе. Но опять же это не объясняет ниразу священный ужас который случае когда я говорю что сам СКВ не использую, как и не объясняет почему я наизусть должен помнить синтаксис команд каждой СКВ.
Конечно, рад за вас, и охотно верю, что вы наизусть помните весь свой код… что можно объяснить либо тем, что у вас феноменальная память, либо тем, что вашего кода недостаточно много для того, чтобы вы начали его забывать (ну, либо вы привираете, но тут уж настаивать не буду).
Теперь вспомним, что на собеседованиях, где спрашивают знание гита, вас, предположительно, берут в команду разработки. Состоящую не сплошь из одних уникумов. И для них ценны такие вещи, как история изменений, возможность отката на предыдущие состояния, возможность код-ревью (которое служит не только средством контроля качества кода, но и отличным учебным руководством для «подрастающих профессионалов»).
Но нет, настоящий профессионал выше устоявшегося командного инструментария… Хотя, погодите, может быть, таки не профессионал… Гениальный любитель?
Теперь вспомним, что на собеседованиях, где спрашивают знание гита, вас, предположительно, берут в команду разработки. Состоящую не сплошь из одних уникумов. И для них ценны такие вещи, как история изменений, возможность отката на предыдущие состояния, возможность код-ревью (которое служит не только средством контроля качества кода, но и отличным учебным руководством для «подрастающих профессионалов»).
Но нет, настоящий профессионал выше устоявшегося командного инструментария… Хотя, погодите, может быть, таки не профессионал… Гениальный любитель?
Гениальный любитель?
Да как вам будет угодно. Про команды я уже 10 раз все сказал, повторяться не вижу смысла.
что у вас феноменальная память
На код, еще фильмы хорошие помню практически посекундно. Есть конечно и обратные стороны, например даты не способен помнить хоть скольконибудь долго
Про команды я уже 10 раз все сказал, повторяться не вижу смысла.
Ну да, про команды вы сказали… Что СКВ там не нужны, даже вредны. Даже в качестве примеры amocrm упомянули.
На код, еще фильмы хорошие помню практически посекундно. Есть конечно и обратные стороны, например даты не способен помнить хоть скольконибудь долго
А в вашей команде, простите, все такие уникумы? С настолько идеальной памятью, что СКВ и им не нужны?
Ну да, про команды вы сказали… Что СКВ там не нужны, даже вредны. Даже в качестве примеры amocrm упомянули.
Можно мне цитаткой? А то как то даже забавно, учитывая что в каждом посте у меня написано обратное 8)
Amocrm и мегаплан вам приведены как «большие хайлоад проекты» которые по идее должны быть обожены тестами и все такое, а на практике устраивают такой лютый головняк своим пользователем, что хоть вешайся.
А в вашей команде, простите, все такие уникумы? С настолько идеальной памятью, что СКВ и им не нужны?
Что такое наша команда? В данный момент я разработкой занимаюсь сугубо сольно, а по работе CTO
ЗЫ кстати я вот заметил что вы на бекапы напираете. А не расскажите ка вы бекапите БД, как часто загружаете бекапы для проверки и чем контролируете?
Можно мне цитаткой? А то как то даже забавно, учитывая что в каждом посте у меня написано обратное 8)
Окей, перечитал, прямо такого вы не утверждали. Однако негодование по поводу того, что у вас спросили знание git'а на собеседовании вы проявили. И по поводу того, что без умения пользования СКВ в командной разработке делать нечего вы тоже возмущались.
Amocrm и мегаплан вам приведены как «большие хайлоад проекты»
Обадва ни к хайлоаду, ни к большим проектам отношения, по сути, не имеют.
Что такое наша команда? В данный момент я разработкой занимаюсь сугубо сольно, а по работе CTO
При этом отрицаете, что опыта командной разработки у вас нет. Ну ок.
ЗЫ кстати я вот заметил что вы на бекапы напираете.
Что-то вы неверно заметили. Я «напираю» на то, что использовать средства бекапа в качестве замены СКВ — так себе идея.
А не расскажите ка вы бекапите БД, как часто загружаете бекапы для проверки и чем контролируете?
Отчего же не рассказать, расскажу. Лично я — никак не бекаплю БД, загружаю дампы исключительно в целях тестирования приложеня и никак не контролирую. Я разработчик, не администратор СУБД.
Окей, перечитал, прямо такого вы не утверждали. Однако негодование по поводу того, что у вас спросили знание git'а на собеседовании вы проявили. И по поводу того, что без умения пользования СКВ в командной разработке делать нечего вы тоже возмущались.
Спросили? Нет. Иначе я бы подробно объяснил суть. Но вот когда интервьюер начинается аж захлебываться от ужаса… Причем последний раз речь шла о SVN.
Что-то вы неверно заметили. Я «напираю» на то, что использовать средства бекапа в качестве замены СКВ — так себе идея.
Замены? Зачем? Вы упомянули бекапы, я говорю что сервак один черт бекапиться.
Отчего же не рассказать, расскажу. Лично я — никак не бекаплю БД, загружаю дампы исключительно в целях тестирования приложеня и никак не контролирую. Я разработчик, не администратор СУБД.
Но как же, это же основы! А бд к СКВ у вас чем прибита? Слуушайте, а как у вас дела с параметризованными запросами?)
Но вот когда интервьюер начинается аж захлебываться от ужаса… Причем последний раз речь шла о SVN.
Ну вот ему нужен разработчик с уверенным знанием SVN. Хочет — берет, хочет — захлебывается от ужаса. К чему ваше-то недовольство?
Замены? Зачем? Вы упомянули бекапы, я говорю что сервак один черт бекапиться.
Вы же сказали, что предыдущие версии вашего продукта есть в бекапах, в инкрементальных бекапах, в роллинг-бекапах, в куче других бекапов, а также, если уж совсем все плохо, в бекапах сервера. Ну вот это хреновая система версионирования, честно-честно, и не я один так считаю. Бекапы отдельно, версии отдельно. Разные задачи = разные инструменты.
Но как же, это же основы!
Основы, простите, чего?
А бд к СКВ у вас чем прибита?
Из того, что делал — хранил миграции в СКВ, хранил диффы схемы, юзал ОРМ, умеющие в миграцию. Из того, что делаю сейчас… В 90% случаев с БД не работаю напрямую, чаще мидлварь. Приложения, например, разные бывают.
Слуушайте, а как у вас дела с параметризованными запросами?
У меня — все отлично, а у вас с ними что-то не так?
Ну вот ему нужен разработчик с уверенным знанием SVN. Хочет — берет, хочет — захлебывается от ужаса. К чему ваше-то недовольство?
Адекватный ответ «Вы знаете, нам нужен разработчик с уверенным знанием SVN. Вы бы не могли быстренько изучить, либо вы нам не подходите»
Неадекватный ответ «Как так? Это же базовые вещи! О чем вообще с вами можно разговаривать?»
Бекапы отдельно, версии отдельно.
В моих личных продуктах мне версии безинтересны.
Основы, простите, чего?
Вот о чем примерно и речь.
У меня — все отлично, а у вас с ними что-то не так?
И насколько отлично, используете prepared?
Адекватный ответ «Вы знаете, нам нужен разработчик с уверенным знанием SVN. Вы бы не могли быстренько изучить, либо вы нам не подходите»
Неадекватный ответ «Как так? Это же базовые вещи! О чем вообще с вами можно разговаривать?»
Это собеседование
В моих личных продуктах мне версии безинтересны.
В личных — никто вам не запрещает, и даже осуждать никто не собирается. Но если вы позиционируете себя как профессионального командного разработчика — «будьте добры соответствовать».
И насколько отлично, используете prepared?
prepared sql queries, я так понимаю?
Смотрите, у меня 3 проекта:
1. Основной, за который мне платят деньги. Там не использую, данными рулит другая команда, у меня есть api (версионированное, естественно)
2. В целях поизучать экосистему — вполне себе C# проектик — не использую, т.к. собственно есть entity framework.
3. В целях разовых подработок — немножко вебни, немножко мобильных мелочей, чуточку веб-бекенда. На бэке — Go, там использую. В таких масштабах версионирую базу скриптами миграций, prepared statements, естественно, использую. Но не на всех проектах.
И, как это относится к сути, собственно, вопроса?
Это собеседование, детка! Субьективно вы не понравились потенциальному начальнику, а он лично твердо уверен, что без SVN никуда. Собеседование прошло результативно с обоих сторон: он сэкономил время (не взяв вас на работу), вы тоже (не устроившись в место, которое вам не подходит). В чем причина недовольства?
В том же в чем и у вавторов 100500 таких статей. Нет желания выходить оплеванным.
И, как это относится к сути, собственно, вопроса?
В данном случае — никак.
Ну вот ему нужен разработчик с уверенным знанием SVN.
Субьективно вы не понравились потенциальному начальнику, а он лично твердо уверен, что без SVN никуда. Собеседование прошло результативно с обоих сторон
Ну вот ему нужен разработчик с рыжими волосами. Хочет — берет, хочет — захлебывается от ужаса. К чему ваше-то недовольство? Субьективно вы не понравились потенциальному начальнику, а он лично твердо уверен, что без рыжей шевелюры никуда. Собеседование прошло результативно с обоих сторон: он сэкономил время (не взяв вас на работу), вы тоже (не устроившись в место, которое вам не подходит).
Знаете как это называется?
Ну, например во многих местах (я не про ИТ, хотя и про него возможно) например людей с тату и/или пирсингом предпочитают не брать. Или требуют соблюдать дресскод. Где то слышал и волосы красить заставляют.
Знаете как это называется?
Знаю: «собеседование».
Это называется дискриминация. Я думал про негров написать, но решил что не стоит, и так понятно.
Вот зря про негров не написали, особенно показательный пример. Дискриминация первична. В конце концов, когда сперматозоид оплодотворял яйцеклетку, из который сформировались вы, это было вопиющим воплощением дискриминации по скоростному признаку в отношении тысяч и тысяч других сперматозоидов. А про всеобщее равенство — это вы в книжках читайте. Соответствующие труды должны на полке быть где-то между описанием физиологии розовых единорогов и историческими свидетельствами о выдающихся людях, какавших бабочками.
Собственно, прием на работу как таковой — яркий пример дискриминации по профессиональному признаку.
Собственно, прием на работу как таковой — яркий пример дискриминации по профессиональному признаку.
Умение пользоваться инструментами — объективная потребность, это не дискриминация.
Ага. Дискриминация это «субьективно вы не понравились потенциальному начальнику». Если инструмент используется на работе — то объективная потребность, если он нравится начальнику, но не используется и не планируется — субъективные предпочтения.
Да снимите уже розовые очки. В рамках собеседования невозможно объективно определить уровень кандидата.
Конторе объективно нужен сотрудник, соответствующий набору критериев, определяемый самой организацией. Конторе не нужен «крутой кодер», ей нужен сотрудник, выполняющий поставленные задачи. Тчк.
Прийди ко мне на собеседование Герб Саттер — я его просто не возьму. Я объективно не знаю, чем занять разработчика такого уровня. И мне по барабану, что круче него только горы, если я не могу и не умею применять его навыки. Я просто потрачу его и свое время. Ну и нафейхоа?
Конторе объективно нужен сотрудник, соответствующий набору критериев, определяемый самой организацией. Конторе не нужен «крутой кодер», ей нужен сотрудник, выполняющий поставленные задачи. Тчк.
Прийди ко мне на собеседование Герб Саттер — я его просто не возьму. Я объективно не знаю, чем занять разработчика такого уровня. И мне по барабану, что круче него только горы, если я не могу и не умею применять его навыки. Я просто потрачу его и свое время. Ну и нафейхоа?
Цвет кожи и наличие члена — это объективные различия, это тоже не дискриминация.
Однако негодование по поводу того, что у вас спросили знание git'а на собеседовании вы проявили.
Я думаю, тут следует определиться, что подразумевается под "знанием гита". Ведь, давайте будем честными — 99% кейзов использования гита с лихвой покрывается буквально полудесятком команд. При чем обычно можно даже не знать какие-то специфичные особенности их применения. Принципы работы гита и связанные с этим вещи — тоже знать не надо.
Иногда (раз в месяц-два) требуется что-то специфичное, но это решается обычно десятиминутным гуглением, т.о. инвестировать время в "изучение гита" (или любой другой СКВ) — какая-то глупая затея, тем более что без практики все из головы один черт выветрится.
С-но, если задают вопрос: "ну вы с гитом работали?" — это одно, а если начинают долбить по знанию конкретных команд — я бы счел это странным.
Ведь, давайте будем честными — 99% кейзов использования гита с лихвой покрывается буквально полудесятком команд. При чем обычно можно даже не знать какие-то специфичные особенности их применения.
Ну да, и сложного в запоминании 3-4 ключевых практик при регулярном использовании я ничего не вижу.
Принципы работы гита и связанные с этим вещи — тоже знать не надо.
Вот собственно, базовые принципы лучше все-таки знать. Нормальный разраб, все таки, не для того нанимается на работу, чтобы повторять набор рутинных действий по бумажке, не вдаваясь в детали происходящего. Для этого есть другие, менее высокооплачиваемые должности. «Оператор ЭВМ», например.
т.о. инвестировать время в «изучение гита» (или любой другой СКВ) — какая-то глупая затея, тем более что без практики все из головы один черт выветрится.
А что вы понимаете под изучением гита? Ну и собственно «изучением технологии». Инструкцию прочитал и все, профессионал? Изучение предполагает практику применения, например. Оно тем от зазубривания и отличается.
Т.е. вы либо гит применяете, и тогда вы его «изучили», либо нет — и тогда вы его не изучили. Собственно, реальных часто используемых команд в гите не так и много. Понимание того, как и зачем их применять, приходит значительно дольше, чем запоминание ключевых слов.
С-но, если задают вопрос: «ну вы с гитом работали?» — это одно, а если начинают долбить по знанию конкретных команд — я бы счел это странным.
Ну вот задали соискателю вопрос: «С гитом работали?» Он, естественно, не моргнув глазом: «Канэээшна!». И? Это о чем-то сказало, проверили скилл? Замените в этом вопросе гит на любую другую технологию, и ничего не изменится. Придумайте правдоподобное название несуществующей технологии и спросите об опыте работы с ней в полусотне собеседований. Вот реально половина соискателей будет знакома с технологией, и даже найдется пара-тройка профессионалов с многолетней практикой применения той ереси, что вы придумали пять минут назад.
Ну и как быть? На слово верить? Тут хоть вопрос задан, и соискателю есть на что отвечать. «Я высокоуровневый разработчик, работаю в IDE и, честно говоря, ни разу не сталкивался с необходимостью ручками давать git-команды в консоли. В моей IDE для работы с гитом есть отличнейшие инструменты, вот, например, в диффе веток есть такая прикольная фича — реально удобнее, чем тысяча других инструментов, которые я пробовал. Сами попробуйте, оно реально экономит время на ревью. А если вы хотите о механиках гита поговорить, ну, давайте обсудим гит-флоу, с которым я привык работать, сравним с тем, что принято у вас, возможно, обменяться практиками». Вот это — это тоже ответ на вопрос «что делает команда git rebase и какие параметры в ней допустимы». Причем в ряде случаев хороший, даже лучше, чем список зазубренных команд.
Ну вот задали соискателю вопрос: «С гитом работали?» Он, естественно, не моргнув глазом: «Канэээшна!». И? Это о чем-то сказало, проверили скилл?
Если ответил "да" — значит работал, ведь по умолчанию предполагаем, что интервьюриуемый всегда говорит правду.
Ну и как быть? На слово верить?
Конечно. А как еще?
Вот это — это тоже ответ на вопрос
Ну это замечательно, когда такой ответ принимается, но ведь может и не приниматься.
Несколько лет назад один наш коллега вайпнул нам гит сервер потому что тоже думал что «изучение гита» глупая идея. Не, ну а чо там, думать что-то там, знать как там чо, не пушится — форснем. И зафорсил нам пустую репу вместо основной.
Не смертельная проблема, конечно, но какое-то количество времени потеряли, особенно человек на объекте, которому надо продукт развернуть посреди заводской пустоты, а он вместо этого видит репу с одним коммитом «ааааа test».
А ведь не дурак был коллега, просто тоже знал о рабочем инструменте комманды полдесятка комманд, и не имел ни малейшего желания узнать чуть больше.
Не смертельная проблема, конечно, но какое-то количество времени потеряли, особенно человек на объекте, которому надо продукт развернуть посреди заводской пустоты, а он вместо этого видит репу с одним коммитом «ааааа test».
А ведь не дурак был коллега, просто тоже знал о рабочем инструменте комманды полдесятка комманд, и не имел ни малейшего желания узнать чуть больше.
Вот что-то, а возможность выстрелить себе в ногу всем в голову — то, что от конкретно гита отвращает, право слово. Уж лучше мы по-старинке, с лоховскими централизированными репозиториями, где история не изменяется.
Т.е. вы таки не дочитали мануал до конца…
Разумеется, я всегда читаю в обратном порядке.
Ну тогда вы должны были видеть, что такое pull request. А эта штука в комплекте с код-ревью решает проблему «какой-то… друг… случайно убил репу».
Проблема в том, что тогда должно быть выделено время на мейнтейн вот этого всего. Для маленьких комманд бывает гораздо проще дать всем полный доступ, потому что такие ошибки довольно редки все-таки.
У нас в команде 1 бек (я), 1 фронт и 1 техлид (на несоклько проектов). У нас есть ревью, которое часто помогает найти ошибки/предложить улучшения, которые не тратят время, доезжая до прода. «Проще дать всем полный доступ» звучит как анархия. До добра это не доводит.
Не вы ли там говорили, что предпочитаете инструменты, где отстрелить ногу нельзя? Тогда зачем сами даете заряженный пистолет ребенку?
Не вы ли там говорили, что предпочитаете инструменты, где отстрелить ногу нельзя? Тогда зачем сами даете заряженный пистолет ребенку?
Плюсы с лихвой перекрывают минусы. Например, когда ваш централизированный сервер упадет — а он обязательно упадет в самый неподходящий момент — вы останетесь совсем без истории.
Backup'ы. Какая-то небольшая часть потеряется, не более.
Сделайте protected branch и стрелять не придется. То, что у коллег любой человек мог затереть основную репу говорит только о том, что они не до конца изучили возможности инструмента.
Это вечный холивор, аналогичный таковому с ЯП — одни говорят «ну и что, что язык допускает отстрел ноги, это программист виноват, у нас все работет»; другие топят за «пусть более кондово, зато стабильнее и надежнее». И та и та точка зрения имеет право на жизнь в определенной ситуации. Когда речь идет о потере кодовой базы, я предпочту инструмент, который в принципе не позволяет пользователю серьезно накосячить.
Это не вечный холивор, это стандартная практика. И я за 5 лет работы с гитом ни разу с описанной ситуацией не столкнулся ни в одной из 5 компаний, где мне довелось работать. Ну потому что пушить в мастер вообще может лишь один аккаунт, доступ к которому разблокируется при чрезвычайных ситуациях раз в год. Весь основной флоу через PR, которые абсолютно безопасны. Джун же который пушит в мастер с форсом это вообще что-то из разряда «удалил базу на проде». Вряд ли стоит выбирать СУБД по тому принципу, что там из коробки не даются права на удаление таблиц.
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
Это не вечный холивор, это стандартная практика.
«Стандатная практика» — это применяемый вами метод. Холивор — это о выборе метода. Разные категории, через «не» не противопоставляются.
Ну потому что пушить в мастер вообще может лишь один аккаунт,
На этом можно и закончить. Это абсолютно нереалистичное ограничение для моей команды.
С тем же успехом можно не пользоваться виндой, «Ведь можно с правами админа всё удалить нафиг. Лучше уж андроид, там из коробки рут отключен».
Абсолютно верно — для ряда задач лучше ограниченный андроид.
git — это инструмент, который, в зависимости от того, как его используют, либо позволяет серьезно накосячить, либо не позволяет.
Посмотрите хотя бы на ядро линукса. Большой проект. Лет 20 уже на гите. И до сих пор ни разу никто не накосячил по-крупному. Вы же не думаете, надеюсь, что это от непогрешимости линукс-разрабов?
И не рассказывайте мне, пожалуйста, что существует какая-то СКВ, которая не позволяет при наличии полного доступа к серверу убить репозиторий.
Посмотрите хотя бы на ядро линукса. Большой проект. Лет 20 уже на гите. И до сих пор ни разу никто не накосячил по-крупному. Вы же не думаете, надеюсь, что это от непогрешимости линукс-разрабов?
И не рассказывайте мне, пожалуйста, что существует какая-то СКВ, которая не позволяет при наличии полного доступа к серверу убить репозиторий.
То что у нас не было deploy branch'a — да, поленились, отчасти, но еще и потому что так получается быстрее, чем выделять время на обработку пулл-реквестов
всем в голову
Простите, это как, если доступ к изменениям общей ветки только через пул-реквесты и код-ревью?
См. выше. Ревью — трата времени, как и ветки, и разграничения доступа. Ограничения на форс пуш в мастер — «нереалистичные требования для команды».
На этом действительно можно закончить.
На этом действительно можно закончить.
Ну если брать людей, которые не знают, что такое virtual и которые говорят, что пользоваться Гитом — фигня, то для такой команды это будет нереалистичными требованиями. Как и впринципе писать качественный код.
Это всё-равно, что нанять в качестве водителя человека, который пришел на собеседование пьяным, а потом жалеть, что современные машины слишком часто попадают в аварии, с лошадьми было лучше
Это всё-равно, что нанять в качестве водителя человека, который пришел на собеседование пьяным, а потом жалеть, что современные машины слишком часто попадают в аварии, с лошадьми было лучше
Из «админского»…
Сисадмины делятся на 2 категории:
1. Те, которые еще не делают бэкапов.
2. Те, которые уже делают.
Не забываем про:
3. те, кто уже проверяют, что из бэкапа можно восстановиться
У правильных программистов «кодовая база двигается исключительно в сторону наращивания функционала»! Потому что правильный программист пишет все с первого раза, без ошибок, и построенная им архитектура изначально настолько совершенна, что не требует рефакторинга даже в случае наращивания не предусмотренного заранее функционала (очевидно потому, что правильный программист его предусмотрел, на то он и правильный).
А вы, очевидно, просто любитель, которому до сих пор нужны версии, код ревью, рефакторинг и прочие любительские техники, недостойные настоящих программистов!
А вы, очевидно, просто любитель, которому до сих пор нужны версии, код ревью, рефакторинг и прочие любительские техники, недостойные настоящих программистов!
Самообразования ради, а в чем удобство для микропроектов? Только как хранилище?
Благодарю. Специфичные случаи, не довелось.
Ноут к тому же прям совсем не мое. Я люблю удобное кресло, хороший монитор, музычку или сериал фоном и самое главное удобная клава 8)
Ноут к тому же прям совсем не мое. Я люблю удобное кресло, хороший монитор, музычку или сериал фоном и самое главное удобная клава 8)
что вы зашли куда-то в тупик, и хочется вернуть всё взад и начать сначала?
В тупик? как правило нет. Как только дорастает до определенного уровня то начинаю серьезно переделывать. Иногда с нуля.
И СКВ освобождают от этакой скованности в экспериментах, вызванной страхом, что вернуться назад не получится.
Вот как раз такого страха не бывало
То есть у вас никогда не было ситуации, что лучше бы вы код не трогали, и все лучше откатить на момент «до»?
Минут 10 вспоминал, не помню такого в серьезных масштабах. А в мелких даже без СКВ IDE ведет историю изменений.
А у нас было пару раз, что велась разработка в течении пары месяцев и потом хоп, «текущую версию в утиль, откатывайтесь к прошлому релизу».
Но это именно командная разработка, поэтому просто к слову о разных ситуациях.
В соло-разработке и пет-проектах cvs удобен в случаях, когда проект уже функционирует и где-то крутится, да выполняет свою задачу.
Затем может возникнуть желание отрефакторить часть кода и весь этот рефакторинг просто выносится в отдельную ветку, т.к. он может идти не один день.
В чём же выгода? Выгода в том, что, если во время эксплуатации текущей работающей версии возникнет проблема, которая потребует небольших правок в коде, то всё, что потребуется от человека — переключиться на работающую ветку до рефакторинга, внести исправления и передеплоить, а затем продолжить рефакторинг без каких-либо проблем.
По крайней мере, именно в подобном ключе я применяю гит в своих пет-проектах. И так же, как удобное средство делиться своим кодом, т.к. всё, что нужно — запушить изменения в какой-нибудь github/bitbucket/gitlab и скинуть ссылку человеку.
Но это именно командная разработка, поэтому просто к слову о разных ситуациях.
В соло-разработке и пет-проектах cvs удобен в случаях, когда проект уже функционирует и где-то крутится, да выполняет свою задачу.
Затем может возникнуть желание отрефакторить часть кода и весь этот рефакторинг просто выносится в отдельную ветку, т.к. он может идти не один день.
В чём же выгода? Выгода в том, что, если во время эксплуатации текущей работающей версии возникнет проблема, которая потребует небольших правок в коде, то всё, что потребуется от человека — переключиться на работающую ветку до рефакторинга, внести исправления и передеплоить, а затем продолжить рефакторинг без каких-либо проблем.
По крайней мере, именно в подобном ключе я применяю гит в своих пет-проектах. И так же, как удобное средство делиться своим кодом, т.к. всё, что нужно — запушить изменения в какой-нибудь github/bitbucket/gitlab и скинуть ссылку человеку.
А у нас было пару раз, что велась разработка в течении пары месяцев и потом хоп, «текущую версию в утиль, откатывайтесь к прошлому релизу».
Но это именно командная разработка, поэтому просто к слову о разных ситуациях.
Да, целыми модулями, а пару раз весь проект выкидывали к чертям. Поэтому нынче я задаю вопрос «зачем?» до просветления. Оказалось что в 9 случаях из 10 люди не представляют себе ответ на этот вопрос, в какой форме его не задай.
И так же, как удобное средство делиться своим кодом, т.к. всё, что нужно — запушить изменения в какой-нибудь github/bitbucket/gitlab и скинуть ссылку человеку.
На больную мозоль наступили. Я постоянно думаю что надо бы с коллегами поделиться, выложитьв в свободный доступ особо клевые штуки. Но иногда побеждает лень, иногда стыд за не очень красивый код, а иногда жадность(я все же бабульку этим зарабатываю).
Да, целыми модулями, а пару раз весь проект выкидывали к чертям. Поэтому нынче я задаю вопрос «зачем?» до просветления.
В том и дело, что отсутствие СКВ превращает откат в настолько трудоемкий процесс, что вы вынуждены сравнивать затраты на откат с потерями от не-отката. А проблема «решена до нас».
Оказалось что в 9 случаях из 10 люди не представляют себе ответ на этот вопрос, в какой форме его не задай.
Не важно, в какой форме задавать. Есть продукт, который в текущем состоянии имеет регрессии/ведет себя не по спекам/в целом не удовлетворяет требованиям. Была предыдущая версия, которая в целом заказчика устраивала. Заказчик хочет рабочую систему здесь и сейчас, что обсуждать?
Я постоянно думаю что надо бы с коллегами поделиться, выложитьв в свободный доступ особо клевые штуки. Но иногда побеждает лень, иногда стыд за не очень красивый код, а иногда жадность(я все же бабульку этим зарабатываю).
Вы с коллегами по команде кодом не делитесь?
В том и дело, что отсутствие СКВ превращает откат в настолько трудоемкий процесс, что вы вынуждены сравнивать затраты на откат с потерями от не-отката. А проблема «решена до нас»
Есть такое дело.
Заказчик хочет рабочую систему здесь и сейчас, что обсуждать?
Разумность внедрения каких то фич. Очень часто «нам нужен вот такой то отчет», говорю «ок, какие задачи он должен решить?» и уже отчета то не нужно вдруг стало 8)
Естественно если я говорю о случаях когда я лично взаимодействую со своими заказчиками. Создание хорошего продукта это ведь вовсе не клепание всего что попросят.
Вы с коллегами по команде кодом не делитесь?
Это другое.
Это другое.
Делиться кодом с коллегами по команде удобнее в гите. Чесслово, я проверял. Просто попробуйте.
Коллеги, я чесслово в ужасе. Никто не читает на что отвечает?
Само собой разумеется.
Делиться кодом с коллегами по команде удобнее в гите. Чесслово, я проверял.
Само собой разумеется.
Эмм, и вы жмете ctrl+Z в трех десятках файлов которые успели поменять? У меня зачастую бывают такие ситуации, где надо откатить от получаса до пары дней работы. В последнее время все реже, но всё еще бывает.
Работать с гитом кроме того удобно хотя бы потому, что я могу с любого компьютера продолжить работу с того места, где закончил. Не говоря про ветки, где я пробую различные варианты, и если мне вдруг понадобится что-то применить, я не буду вспоминть, что я там навертел, а просто сделаю мерж соответствующей ветки.
Ну просто в качестве примера — вот у меня есть проект: https://github.com/Pzixel/Solidity.Roslyn. Я сделал первую версию, задеплоил. Сделал ветку nethereum, в которой начал добавлять усложенный код. Усложненный код потребовал зависимостей, из-за чего он не собирается на убунте (на котороый работает билд сервер). Я создал соответствующий issue в репозитории той зависимости, которая всё ломает. Пока я жду этого исправления, я понемногу модифицирую master-ветку. В итоге, пока я ждал исправления этого бага, я успел настроить CI, починить несколько багов и немного порефакторить код. При этом я не потерял никаких изменений, даже наоборот, бэкпортировал в мастер часть полезных изменений из nethereum ветки. В итоге я не блокируюсь из-за того, что моя зависимость сломана, т.к. я спокойно живу и редактирую ветку, где этой зависимости нет. Когда они её починят, я смержу соответствующий мастер в эту ветку и всё заработает на новой версии.
Как это делать без СКВ я не представляю. Надо наверное какие-то папочки держать типа "app_main", "app_new". Плюс я работаю как из дома, так и на работе (иногда), и из дома подруги. Как узел синхронизации гит тоже очень даже неплох.
То есть у вас никогда не было ситуации, что лучше бы вы код не трогали, и все лучше откатить на момент «до»?
Если в руках молоток — то все вокруг кажется гвоздями.
Используемые инструменты влияют на ментальную модель, если человек работал 10 лет без СКВ, то он к этому привыкает, и все варианты, которые бы использование СКВ предполагали — отсекаются на подсознательном уровне. И в итоге потом "никогда не приходило в голову, зачем это может понадобиться, фигня какая-то".
Не думаю. Тем более что с скв я работал регулярно. Хотя мысль интересная.
Когда не знаешь о молотке, забиваешь гвозди чем придется. И когда тебе говорят — чувак, смотри молотком удобней и быстрее, ты в ответ рассказываешь что так привык, забивать гвозди ладонью прикольней, не смотря на кровь и боль, а больше одного гвоздя в день забивать все равно не надо, глупости какие.
Тут главное в том, что это, по факту, ничего не стоит.
git init написал, сделал первый коммит, поправил gitignore и все (меньше 5 минут в совокупности). Может, потом оно не понадобится особо — так 5 минут и не жалко ведь.
Тестить фичи в ветках — бесценно.
Но почему то что ни просят доработать, какой продукт не возьми, везде какой-то бред происходит.
А вам не приходило в голову, что «если третий муж бьет по роже, то виновата рожа»? Может вас в этот мир просто не берут, потому что вы на этот мир смотрите свысока, или, возможно даже, вообще не понимаете как там что работает? Это я так, food for thought
А вам не приходило в голову, что «если третий муж бьет по роже, то виновата рожа»?
Ну во первых причем тут рожа, если например врубаешь slow_query_log и он за 5 минут заполняется сотней разных запросов?
А во вторых, согласитесь: если третий муж бьет по роже, то все таки третий муж мудак.
Может вас в этот мир просто не берут
Если он где то и есть то явно не в веб разработке. Или не в этом городе. Хотя опыт общения с крупными сервисами намекает…
вообще не понимаете как там что работает
Как правило, тривиально, на самом деле
Использование СКВ — стандарт отрасли. Если команда не использует СКВ, это значит, что они не могу совместно работать над одними участками кода, заменять друг друга, обозревать код друг друга (последние изменения) и т.д. Это сказывается на производительности и качестве кода.
Программист, сегодня отказывающийся от СКВ — это как бухгалтер, отказывающийся от ЭВМ, мол «мне на бумаге и счетах норм, я так привыкла. Зачем мне лично ваш компьютер?»
Программист, сегодня отказывающийся от СКВ — это как бухгалтер, отказывающийся от ЭВМ, мол «мне на бумаге и счетах норм, я так привыкла. Зачем мне лично ваш компьютер?»
Знаете, коллега, я фразу про скв использую как своего рода флажок. Все начинают сразу поливать жижей но никто толком неспособен объяснить зачем использовать СКВ соло-разработчику.
Поймите меня првильно, не понта ради а понимания для.
Поймите меня првильно, не понта ради а понимания для.
Ну, во-первых, те кто вас критикует выше, говорят о командной разработке.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии. Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии. Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Ну, во-первых, те кто вас критикует выше, говорят о командной разработке.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Во-вторых, даже при единоличной разработке СКВ нужна для фиксации изменений, определенных вех, к которым потребуется обратиться спустя время — очень помогают commit комментарии.
Тут два момента. Я стараюсь, и с каждым годом все лучше. Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались. Ну и KISS.
Второй момент я просто помню все что написал. Могу забыть номер дома и день рождения супруги, но помню весь год за 15 лет.
Для отката обратно, к старому решению в конкретном файле (инкрементальный backup имеет слишком большую гранулярность). Для создания побочной ветки для багфикса или более приоритетной feature, если их требуется сделать посреди работы над новым функционалом.
Благодарю. Я подумаю над этим. Пока не приходилось.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Я понимаю вашу точку зрения, но. поскольку СКВ при командной разарботке — стандарт отрасли, стоит настаивать на его использовании независимо от мнения заказчика. Это вопрос профессиональной этики — не идти на поводу у клиента, если он заказывает откровенное г-но.
Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались.
Разумеется, это трезвый подход. Но каждую строчку не прокомментируешь, а подчас приходится добавлять какие-то граничные случаи или что-то подобное, назначение чего неочевидно. С коммитами хотя бы видно, в рамках какой задачи внесено то или иное изменение.
Это важно и для другого — допустим, вы применили в каком-то проекте решение специфической проблемы, но не помните в точности всего решения (допустим, оно объемное и/или разнесено по модулям, дописано частями в разное время и т.д.). Из СКВ мы можем извлечь diff'ами эти блоки и посмотреть на решение в целом.
Если вашим кодом кто-то пользуется кроме вас, надо держать как минимум две ветки — грязную dev для разработки и чистую для внешнего мира — вы же не будете напрямую править то, что есть у клиента? Если будете, и что-то сломается, надо будет срочно откатывать назад и т.д.
Это вопрос профессиональной этики — не идти на поводу у клиента, если он заказывает откровенное г-но.
Касаемо продуктов я всегда стараюсь так делать, но касаемо прочего, в тч инфрастуктуры… знаете я устал. Очень часто консультирую по инфрастуктуре как сторонний консультант и как CTO и практически всегда хозяива бизнеса предпочитают покласть на все и въехать в пенек побольше.
Я очень люблю возиться с БД и раньше часто брал заказы на оптимизацию/аудит, но перестал, потому как список рекомендаций не выполеняется никогда, говнокода становиться только больше и заказчик вовзращается с практически мертвым сервером, получая барьерные цены.
Первые 100 раз было еще хотя бы смешно. А теперь я лучше посижу и сделаю еще что нить работающее в десятки раз быстрее аналогов, но для себя, чем снова буду убеждать сделать правильно.
Еще практическое применение СКВ (косвенное): отслеживание трудных ошибок.
Если система собирается не на коленке, а централизовано, с сохранением версии, map файлов и build система сблокирована с СКВ, то мы получив пользовательскую ошибку (например, доступ к памяти по некорректному адресу, после чего программа рухнула), получаем стек вызовов перед ошибкой и конкретное место ошибки. Но чтобы понять, где именно она была, нужно иметь snapshot всей кодовой базы, которая использовалась именно для сборки вот этой конкретной версии. А там уже, зная по сути номер строки с ошибкой можно найти точное место в коде.
И это не зависит от того, командная ли разработка или одиночная.
Если система собирается не на коленке, а централизовано, с сохранением версии, map файлов и build система сблокирована с СКВ, то мы получив пользовательскую ошибку (например, доступ к памяти по некорректному адресу, после чего программа рухнула), получаем стек вызовов перед ошибкой и конкретное место ошибки. Но чтобы понять, где именно она была, нужно иметь snapshot всей кодовой базы, которая использовалась именно для сборки вот этой конкретной версии. А там уже, зная по сути номер строки с ошибкой можно найти точное место в коде.
И это не зависит от того, командная ли разработка или одиночная.
Поэтому в каждом моем посте было написано, что если заказчик требует — всегда пожалуйста.
Да не заказчик этого требовать должен. СКВ — инструмент команды разработки. А заказчик — он продукт получать должен.
Вот что команда получает — это удобный инструмент.
Допустим, запилили вы новую фичу. Подходит к вам другой разраб и просит показать, как оно работает (вроде, нормальные подход внутри команды кодом делиться). А у вас проект на полсотни тысяч строк. И вы ему начинаете объяснять, где, в каких местах и какие куски кода смотреть. На пальцах. Вместо того, чтобы ткнуть в PR, содержащий конкретную реализацию конкретной фичи.
Тут два момента. Я стараюсь, и с каждым годом все лучше. Чтобы весь мой код читался настолько хорошо, чтобы пояснения и комментарии не требовались. Ну и KISS.
Вы стараетесь, но, видимо, всуе. Читаемость — вещь субъективная. И то, что лично вы отлично помните, как что работает в вашей собственной реализации, и где что искать, остальной команде ничего не дает.
Ну, собственно, про миллион наработанных поверх СКВ практик пока писать не будем, можно остановиться на этом. Просто в контексте командной разработки СКВ — «must have» штука, почему я и говорю, что с подходом «СКВ не нужны» ненужным в командной разработке становитесь уже вы.
Да не заказчик этого требовать должен
Стоит читать как работодатель.
Читаемость — вещь субъективная
Нет тут никакой субъективности. $lion->eat($pig); Ясно, кратко, понятно.
«СКВ не нужны» ненужным в командной разработке становитесь уже вы.
Учитывая что несмотря на все указания вы по прежнему не можете указать место где я это сказал разрезе командной работы, я очень рад что мой детектор работает как надо. Так что вопрос кто кому не нужен тут спорный.
Стоит читать как работодатель.
Стоит читать как «работодатель запрещает завести СКВ»?
Нет тут никакой субъективности. $lion->eat($pig); Ясно, кратко, понятно.
Вы вырожденный случай какой-то приводите. Добавьте сотню строчек снизу и столько же сверху — вуаля, уже не настолько читаемо?
К слову, к СКВ вполне можно линтер присобачить, чтобы стандарты кода контролировать, например.
Стоит читать как «работодатель запрещает завести СКВ»?
Стоит читать, если надо — используем.
Вы вырожденный случай какой-то приводите. Добавьте сотню строчек снизу и столько же сверху — вуаля, уже не настолько читаемо?
Это у вас один метод на 200 строк?
KISS
Это у вас один метод на 200 строк?
Это у меня реализация фичи, например, и длиннее может быть, да еще и размазанная по набору исходников.
Метод на 200 строк как раз согласуется с KISS, а вот нарушающее семантику дробление KISS противоречит :)
В данном случае применение KISS будет как: "не стоит выделять код в отдельный метод, если не можешь обосновать, зачем это должно быть сделано".
Поймите меня првильно, не понта ради а понимания для.
Ну вот вам не понта ради, вроде, достаточно весомый аргумент:
Предположим, есть у нас разработчик, одиночка, пишет для себя, хорошо пишет, и «не надо ему эти ваши новомодные СКВ». Да, в общем, пока он один в своем коде варится, и пусть его. Это его проекты, и его право.
А потом этот разработчик решает заняться разработкой «по-взрослому», с «возможностью профессионального роста», приходит в сложившуюся команду и… и смотрит на тот же git, как баран на новые ворота. И изучать его не хочет, а только ходит кругами по конторе и пытается убедить других разработчиков, что СКВ «нинужны» все эти ваши код-ревью, репозитории, системы сборки/деплоя — от лукавого, а на сервера и из IDE проект поразворачивать можно.
Ну либо его «бреют на входе», а он идет на хабр писать, какие работодатели плохие, задают сложные вопросы и каких-то гитов непонятных с него хотят.
что СКВ «нинужны» все эти ваши код-ревью, репозитории, системы сборки/деплоя
В чужой монастырь со своим уставом? Сильно.
Без сборки/деплоя кстати достаточно тяжко.
git, как баран на новые ворота.
Документацию в зубы.
Ну либо его «бреют на входе», а он идет на хабр писать, какие работодатели плохие, задают сложные вопросы и каких-то гитов непонятных с него хотят.
Ну вот если вот так общаются то да, конечно плохие. Я привык от работы получать удовольствие.
Без сборки/деплоя кстати достаточно тяжко
Для собрки написана пачка скриптов. Развертывается силами IDE на мой сервер.
Как эти два ваших высказывания коррелируют? В контексте «вы уж мне поверьте, как опытному в вопросе человеку, без сборки/деплоя тяжко»?
Документацию в зубы.
Работодатель не хочет платить вам за изучение инструмента, являющегося стандартом в отрасли. Он ищет разработчика, который этот инструмент уже знает, и имеет на это полное право.
Ну вот если вот так общаются то да, конечно плохие. Я привык от работы получать удовольствие.
Они не плохие, у них просто есть понимание того, что они хотят.
Как эти два ваших высказывания коррелируют?
А что с ними не так? gulp собирает все красиво, деплой настроен в IDE.
Работодатель не хочет платить вам за изучение инструмента
Такое ощущение что подцепить git к ide это задача уровня постройик коллайдера.
Они не плохие, у них просто есть понимание того, что они хотят.
Да если бы. Тогда бы два профессионала побеседовали по душам, выяснили предпочтения друг друга и разошлись или стали работать вместе.
Последний раз меня позвали вообще просто побеседовать и я так и не понял кого они искали, вроде архитектора РСУБД. Но спектр вопросов был такой, как будто левой рукой нужно администрировать сервера, правой проектировать базу, а ногами еще и заниматься разработкой.
А что с ними не так? gulp собирает все красиво, деплой настроен в IDE.
Локальная сборка на машине девелопера… «У меня все работает» — слышали же?
Доставка средствами IDE… У заказчика может быть другое IDE, например… Заказчик может заходить задеплоить на 500 серверов, например…
Такое ощущение что подцепить git к ide это задача уровня постройик коллайдера.
Ну вот собственно, задачка-то простенькая, и не напряжная. А профиты реально ощутимые. А вы не пользуетесь — это ли не повод подумать, «а почему»?
Да если бы. Тогда бы два профессионала побеседовали по душам, выяснили предпочтения друг друга и разошлись или стали работать вместе.
А если у одного из них уже есть работа, и платят ему, предположительно не за беседы?)))
Последний раз меня позвали вообще просто побеседовать и я так и не понял кого они искали, вроде архитектора РСУБД. Но спектр вопросов был такой, как будто левой рукой нужно администрировать сервера, правой проектировать базу, а ногами еще и заниматься разработкой.
Ну это классика. Только опера немного другая — про «и швец, и жнец, и на дуде игрец, недорого, без смс».
Локальная сборка на машине девелопера… «У меня все работает» — слышали же?
У проекта конфигурация в точности повторяет конфигурацию тестовой машины.
Доставка средствами IDE… У заказчика может быть другое IDE, например… Заказчик может заходить задеплоить на 500 серверов, например…
Значит буде мделать по требованиям заказчика. Проблем то.
Ну вот собственно, задачка-то простенькая, и не напряжная. А профиты реально ощутимые. А вы не пользуетесь — это ли не повод подумать, «а почему»?
Уже обсудили выше.
А если у одного из них уже есть работа, и платят ему, предположительно не за беседы?)))
а) не беседовать
б) вести себя как профессионал
Ну это классика. Только опера немного другая — про «и швец, и жнец, и на дуде игрец, недорого, без смс».
А вы говорите знает что хочет…
И по каждому аспекту обычно вопросы чуть ли от устройства ядра линуха и «это же основы!».
Очень редко можно услышать: вот у нас есть такая задача, под которую нам нужен «название должности», как бы вы могли в этом нам помочь?
У проекта конфигурация в точности повторяет конфигурацию тестовой машины.
Вот это, простите, фикция.
Значит буде мделать по требованиям заказчика. Проблем то.
На выходе получите по отдельному билд/деплой костылю на заказчика. Но ладно, это слабодоказуемо, просто «из практики».
У проекта конфигурация в точности повторяет конфигурацию тестовой машины.
"Свежо предание, но верится с трудом..."
«Свежо предание, но верится с трудом...»
А в чем проблема? php, java, pg в точности версию сопоставить?
А в чем проблема? php, java, pg в точности версию сопоставить?
Кхм, и сесть в лужу на регрессии системной библиотеки, установленном по соседству фреймворке или производительности сискола на другой версии ядра?
«УМВР» — это ровно этот случай.
Не знаю, как там у Вас в теории, а у нас на практике чуть ли не еженедельно имеем геморррой на работе, потому как конфигурация heroku-виртуалок, на которых продукт крутится, не в абсолютной точности соответствует конфигурации девелоперских машин. Как уже отмечали ниже — обычно виной системные библиотеки. Например, девелоперу в работе нужен какой-то продукт, его инсталляция притащила с собой тучу библиотек (зачастую непонятно почему), которые продукт прозрачно подхватил. Стали запускать на виртуалке — продукт падает ввиду отсутствия библиотек (и при этом не говорит, каких).
Работодатель не хочет платить вам за изучение инструмента, являющегося стандартом в отрасли.
Для изучения гита на уровне комфортной работы достаточно часа-двух, о чем вы вообще, ну?
Ну, собственно, если соискатель не нашел пары часов из 30 лет, прошедших перед собеседованием…
А если он при этом еще и утверждает, что «имеет богатый опыт командной разработки». И за весь «богатый опыт» тоже 2 часов не нашел? Или по религиозным соображениям не использует, и предыдущий работодатель, у которого он получал «богатый опыт», заставить не смог.
Или просто, может, врет про «богатый опыт»? Согласитесь, более вероятно. Есть, конечно, целые экосистемы, в которых гит не используется, там свои стандарты — но там и спрашивать, вероятно, стоит о знании местных стандартов.
Но в подавляющем количестве проектов разработки бал правит git, и «иметь богатый опыт разработки в различных командах» и при этом «не иметь опыта работы с гитом»… Такое себе… Либо врет, либо это именно тот случай, когда «10 лет опыта, но каждый из этих лет — первый».
А если он при этом еще и утверждает, что «имеет богатый опыт командной разработки». И за весь «богатый опыт» тоже 2 часов не нашел? Или по религиозным соображениям не использует, и предыдущий работодатель, у которого он получал «богатый опыт», заставить не смог.
Или просто, может, врет про «богатый опыт»? Согласитесь, более вероятно. Есть, конечно, целые экосистемы, в которых гит не используется, там свои стандарты — но там и спрашивать, вероятно, стоит о знании местных стандартов.
Но в подавляющем количестве проектов разработки бал правит git, и «иметь богатый опыт разработки в различных командах» и при этом «не иметь опыта работы с гитом»… Такое себе… Либо врет, либо это именно тот случай, когда «10 лет опыта, но каждый из этих лет — первый».
Серьезно? Несущественные моменты использования заурядного инструмента порождают такие размышления. Да еще с постоянным подозрением во вранье? И почему я могу сходу придумать как поговорить с разработчиком, чтобы развеять свои сомнения а вам так важен синтаксис команд.
Ну чтож: «вы мне не подходите».
Зы теперь я с еще бОльшим упорством буду говорить «не знаю» )
Ну чтож: «вы мне не подходите».
Зы теперь я с еще бОльшим упорством буду говорить «не знаю» )
Смотрите, бывают программисты и бывают разработчики. Программист — это такой человек, который умеет писать код, программировать. А есть разработчик — это человек, который умеет разрабатывать (предположительно, продукт, зачастую в команде, всегда в рамках каких-либо ограничений, налагаемых ТЗ, командной спецификой, стеком, принятыми практиками и экосистемой).
Обадва могут быть как хорошими, так и плохими, при этом прямой зависимости между этими двумя понятиями нет. Умение писать хороший качественный код характеризует вас как хорошего программиста и может считаться плюсом в характеристике вас как разработчика, но никак не может вас характеризовать как разработчика хорошего.
Разработчик, поверх умения кодить собственно, нуждается в навыках коммуникации, навыках самодисциплины и самоконтроля, навыках адекватной оценки задачи, навыках в работе с сопутствующими инструментами и в куче других, не связанных непосредственно с кодированием навыков.
То, что вы можете написать код несколько более качественный, чем условный Василий, делает вас более крутым программистом, но не делает вас автоматически более крутым разработчиком. Если код Василия укладывается в заданные рамки качества, а ваш, хоть и круче, но может оказаться слишком сложным для понимания Василиев в вашей команде — как разработчик этой команды вы хуже Василия. Если же ваш код не обладает избыточной сложностью, и вы оба с Василием «укладываетесь в критерии», но Василий уже знаком с практиками пулл-реквестов, код-ревью, и прочих «скрамов», принятых в команде — он опять лучше вас как разработчик, хоть и уступает вам как программист.
У вас есть четкие критерии существенности моментов использования и незаурядности инструментов? Вот язык программирования, собственно, тоже ведь абсолютно заурядный инструмент. Или нет? Разработка — это просто инженерная практика, в ней нет незаурядных инструментов, а несущественные моменты иногда приводят в, простите за прямоту, жопу.
Вы о чем на собеседовании вообще говорить собираетесь? Собеседующий не хочет вас подловить на знании спецтонкостей особого малоиспользуемого инструмента. Он спрашивает вас про гит, который известен чуть менее чем каждому второму зародышу програмиста в мире, и цель у него — просто понять, использовали ли вы гит на практике. А вы валитесь на завышенной самооценке и отсутствии коммуникативных навыков.
Да не нужен мне синтаксис команд, мне нужно увидеть, что ты ответишь. Высыпал набор определений в том порядке и в той формулировке, как оно описано в википедии — зазубрил, следующий. Объяснил своими словами — ну ок, беседуем, либо крепкий середнячок, либо «перегоревший», но суть понимает, и работать с этим можно. Сказал «я на практике эти вещи обычно делаю через (тут вставить название любимой вами лично хитрозаверченной жопы), поэтому тупо синтаксис в лоб не помню» — окей, выводим на разговор, пытаемся понять, кто перед нами, «ненужный нам фанатик», который будет с пеной у рта доказывать, что его единственный в мире инструмент лучше, или «вдумчивый специалист», с которым можно обсудить детали, прийти к взаимопониманию, и который, в случае надобности, сможет подождать обсуждения практик, и не будет раскачивать лодку.
Ну, а если человек вываливает «да это тривиальщина, я не буду это объяснять», «да я такой крутой специалист, что не обязан знать эти простые вещи» или «да я вам все это выучу быстрее, чем любой из ваших самых крутых спецов» — повод расстаться сразу. Это либо попытка скрыть ложь за агрессией, либо завышенная самооценка соискателя, что, по большому счету, монопенисуально плохо.
Понимаете, дело даже не в «ответил/не ответил», а в том, как вы это делаете.
Обадва могут быть как хорошими, так и плохими, при этом прямой зависимости между этими двумя понятиями нет. Умение писать хороший качественный код характеризует вас как хорошего программиста и может считаться плюсом в характеристике вас как разработчика, но никак не может вас характеризовать как разработчика хорошего.
Разработчик, поверх умения кодить собственно, нуждается в навыках коммуникации, навыках самодисциплины и самоконтроля, навыках адекватной оценки задачи, навыках в работе с сопутствующими инструментами и в куче других, не связанных непосредственно с кодированием навыков.
То, что вы можете написать код несколько более качественный, чем условный Василий, делает вас более крутым программистом, но не делает вас автоматически более крутым разработчиком. Если код Василия укладывается в заданные рамки качества, а ваш, хоть и круче, но может оказаться слишком сложным для понимания Василиев в вашей команде — как разработчик этой команды вы хуже Василия. Если же ваш код не обладает избыточной сложностью, и вы оба с Василием «укладываетесь в критерии», но Василий уже знаком с практиками пулл-реквестов, код-ревью, и прочих «скрамов», принятых в команде — он опять лучше вас как разработчик, хоть и уступает вам как программист.
Несущественные моменты использования заурядного инструмента порождают такие размышления.
У вас есть четкие критерии существенности моментов использования и незаурядности инструментов? Вот язык программирования, собственно, тоже ведь абсолютно заурядный инструмент. Или нет? Разработка — это просто инженерная практика, в ней нет незаурядных инструментов, а несущественные моменты иногда приводят в, простите за прямоту, жопу.
Вы о чем на собеседовании вообще говорить собираетесь? Собеседующий не хочет вас подловить на знании спецтонкостей особого малоиспользуемого инструмента. Он спрашивает вас про гит, который известен чуть менее чем каждому второму зародышу програмиста в мире, и цель у него — просто понять, использовали ли вы гит на практике. А вы валитесь на завышенной самооценке и отсутствии коммуникативных навыков.
И почему я могу сходу придумать как поговорить с разработчиком, чтобы развеять свои сомнения а вам так важен синтаксис команд.
Да не нужен мне синтаксис команд, мне нужно увидеть, что ты ответишь. Высыпал набор определений в том порядке и в той формулировке, как оно описано в википедии — зазубрил, следующий. Объяснил своими словами — ну ок, беседуем, либо крепкий середнячок, либо «перегоревший», но суть понимает, и работать с этим можно. Сказал «я на практике эти вещи обычно делаю через (тут вставить название любимой вами лично хитрозаверченной жопы), поэтому тупо синтаксис в лоб не помню» — окей, выводим на разговор, пытаемся понять, кто перед нами, «ненужный нам фанатик», который будет с пеной у рта доказывать, что его единственный в мире инструмент лучше, или «вдумчивый специалист», с которым можно обсудить детали, прийти к взаимопониманию, и который, в случае надобности, сможет подождать обсуждения практик, и не будет раскачивать лодку.
Ну, а если человек вываливает «да это тривиальщина, я не буду это объяснять», «да я такой крутой специалист, что не обязан знать эти простые вещи» или «да я вам все это выучу быстрее, чем любой из ваших самых крутых спецов» — повод расстаться сразу. Это либо попытка скрыть ложь за агрессией, либо завышенная самооценка соискателя, что, по большому счету, монопенисуально плохо.
Понимаете, дело даже не в «ответил/не ответил», а в том, как вы это делаете.
А вы валитесь на завышенной самооценке и отсутствии коммуникативных навыков.
Я? Нет. Я валюсь на шоке от агрессивности и хамстве коллег по цеху. Знаете, много раз в торговле учил людей обращать конфликт в свою сторону, но там понятен его исток. А вот исток напыщенности и пафоса на интервью мне не очевиден.
Понимаете, дело даже не в «ответил/не ответил», а в том, как вы это делаете.
Именно о том и речь.
Я? Нет. Я валюсь на шоке от агрессивности и хамстве коллег по цеху. Знаете, много раз в торговле учил людей обращать конфликт в свою сторону, но там понятен его исток. А вот исток напыщенности и пафоса на интервью мне не очевиден.
Вы негодуете, что вас спрашивают команды СКВ на интервью, и называете это агрессивностью, напыщенностью и хамством? А, ну… ок…
Именно о том и речь.
А что не так?
Вы негодуете, что вас спрашивают команды СКВ на интервью, и называете это агрессивностью, напыщенностью и хамством? А, ну… ок…
Спрашивать команды СКВ на собеседовании довольно странно. Я всегда работал с СКВ, начиная с VSS и потом ещё с 3мя-4мя разными. С Гитом работаю практически во всех ситуациях только из консольки. Но при этом не помню синтаксис команд. Зачем забивать голову? Есть история консоли для самых частых случаев, есть шпаргалка для более редких, и есть интернет для исключительных. Даже если представить, что попаду за новое рабочее место без интернета, то всё равно можно воспользоваться git help. Нормальный вопрос для собеседования — это спросить, какая модель ветвления использовалась на прошлых проектах. Хотя, по большей части, какая разница? Какая модель принята в организации-работодателе, по такой и будет работать разработчик. По опыту, даже те люди, которые никогда не пользовались СКВ, не имеют никаких трудностей в работе из-за этого. Ну покажет им более опытный сотрудник за 5 минут, что делать. И всё. А спрашивать команды, это примерно как у плотника спросить, какую кнопку нажимать на циркулярной пиле: красную или зелёную.
Спрашивать команды СКВ на собеседовании довольно странно.
Странно, на самом деле, соискателю указывать потенциальному работодателю на то, какие вопросы он имеет право задавать на собеседовании.
Вот реально. У обоих сторон собеседования — свои цели. У соискателя, предположительно, получить работу. У собеседующего — составить оценку того, соответствует ли специалист набору критериев, нужных работодателю.
И вот работодатель хочет проверить, имеет ли соискатель опыт работы с гитом. Ему это, по какой-то причине важно.
Он может спросить «имеете ли вы опыт работы с гитом». Окей, из 100 ответов 99 будут «да, конечно, дважды в день». И все они ничего не скажут о реальном навыке. Нужен, очевидно, вопрос, который сможет хоть как-то в чем-то удостовериться.
Он может составить список каверзных вопросов на проверку всех кейсов, где можно наступить на грабли. Отлично, теперь из 100 соискателей 99 не смогли ответить. О чем это говорит? Опять, ни о чем. Грабли есть везде и сам факт того, что соискатель не наступил «вот на эту конкретную», не свидетельствует о том, что он не пользовался инструментом. Да и не факт, что глубокие познания в специфике работы инструмента работодателю нужны, у него есть устоявшийся workflow, и он просто хочет удостовериться, что соискатель сможет посмотреть на описание принятой механики и начать действовать соответственно.
Остается подмножество простых вопросов, доступных даже неопытным специалистам, которые позавчера прочитали git basic howto. По крайней мере, знание этого базиса позволяет предположить, что соискатель по инструкции воспроизведет воркфлоу.
А дальше — это уже к соискателю вопрос, как он на вопрос реагирует. Если он не помнит конкретного ключевого слова, он ведь может это произнести. Просто взять и через рот произнести что-то вроде «Я это на память не помню, с гитом, как правило через IDE работаю, если хотите, можно обсудить принятые практики или могу нарисовать схему того, как мы с гитом работали в предыдущей команде».
Вот честно, вы же не на экзамене! У вас нет задачи «четко ответить на вопрос» и «если не ответил, о, ужас, меня отчислят и я пойду в армию». Как дети, чесслово!
У вас задача: убедить собеседующего, что вы умеете работать с инструментом (а не как в приколе про обязанности караульного «Услышав лай караульной собаки, передать четко и без изменений»).
Вы можете вкратце рассказать про принцип формирования веток, что-то еще примерно связанное (да-да, как в том анекдоте про «Но если бы у рыбы была шерсть, в ней обязательно завелись блохи. Итак, блоха — насекомое...»), да, блин, хоть гипнозом пользуйтесь, лишь бы собеседующий понял, что вы «в теме шарите».
Нет же, мы же обидчивые высококлассные специалисты, как в нас можно сомневаться? Вот список «разрешенных вопросов», а на остальные мы будем отвечать «конечно, я это знаю, но вам не скажу», говорить «я настолько крут, что выше этого» или будем, как тут некто уже излагал свою позицию «из принципа молчать».
Вы посмотрите, блин, какие мы нежные! Кто-то засомневался в нашей квалификации, а мы ответим им нашим молчаливым презрением или снисходительным отказом.
Да никто, нафиг, вашу квалификацию не проверяет! Невозможно это в рамках собеседования. На собеседовании тот, кто собеседует, составляет мнение о том, подходите ли вы под требования вакансии, ни больше ни меньше.
Странно, на самом деле, соискателю указывать потенциальному работодателю на то, какие вопросы он имеет право задавать на собеседовании.
Я здесь не соискатель, а вы не мой потенциальный работодатель. Поэтому не вижу ничего ненормального в том, чтобы обсудить вопросы с собеседований. В том числе их адекватность.
Остается подмножество простых вопросов, доступных даже неопытным специалистам, которые позавчера прочитали git basic howto. По крайней мере, знание этого базиса позволяет предположить, что соискатель по инструкции воспроизведет воркфлоу.
Ок. Но адекватный работодатель будет проверять другое. А если окажется, что соискатель подходит, но не знает git, то просто попросит прочитать «git basic howto» перед началом работы.
P.S. Как-то вы слишком эмоционально реагируете на моё вполне нейтральное сообщение.
Но адекватный работодатель будет проверять другое.
Абсолютно верно. Адекватный работодатель будет проверять другое: подходите ли вы ему как работник. Ни слова о квалификации или опыте, просто «подходите ли вы».
А если окажется, что соискатель подходит, но не знает git, то просто попросит прочитать «git basic howto» перед началом работы.
Не вижу ничего страшного в том, чтобы навскидку проверить утверждение о том, что соискатель что-то там знает.
Вот у нас есть товарищ, который с еще бОльшим упорством буду говорить «не знаю»
— Вы используете гит?
— Конечно, по три раза в день. (молодец какой).
— А что делает команда git reset?
— Не знаю. (мы помним, он из принципа это говорит, обиделся)
— А git commit?
— Не знаю. (все еще обижен)
— А git init?
— Не знаю (мы помним, он обиженка).
Вы на месте собеседующего какой бы вывод сделали? Что перед вами крутой специалист, который знает, но просто имеет причину не говорить? Или таки что он «несколько приукрасил свой скилл»?
Варианты можно даже поанализировать:
1. Он знает, но он «обиженка».
2. Он не знает (что, по сути, в случае с гитом не страшно), но решил скрыть этот факт от вас, солгав на собеседовании (а это уже сильно хуже).
И вот тут, честно говоря, совершенно не важно, обиделся соискатель, или просто врет. В обоих вариантах он не подходит.
Дело в том, что возможно, у нас просто разные цели. Я ищу комфортное место с интересными задачами а не формошлепную ферму. И когда CTO багровеет, покрывается пятнами и начинает хамить на таких простых моментах, ну… нам не по пути.
Хотите другой пример? Менее общий. Я ровно так же могу сказать «понятия не имею» по токностям работы журнала упреждающей записи postgresql, типам индексов и алогритмам объединений. И если случается нормальная беседа то:
1. Конечно вобщих чертах я знаю как работает WAL, но даже помнить о его существовании разработчику в общем то незачем
2.
— Как правило используется b-tree и только.
— hash индекс, за исключением случаев, когда создается самой базой, применять не стоило, во всяком случае до последнего времени, он порождал больше проблем, чем решал. Да и собственно быстрее он может быть только при поиске точного совпадения.
— GIST довольно редко используется, если вы не работаете с геоданными и интервалами
— GIN необходим если вы ищете частичное вхождение. В принципе gin_trgm_ops это то, что должен использовать вообще каждый если у вас есть поиск по справочникам.
— BRIN даже рассматривать не стоит если у вас не стоит задачи экономии дискового пространства.
UPD:
совсем забыл SP-GIST но я лично так и не придумал кудаб его приспособить, если не работать с геометрией.
Как видите, можно годами работать с postgresql и использовать только b-tree и этого в принципе достаточно. По идее это все таки работа архитектора бд, ибо за исключением построения триграмм (которым нужно возносить молитвы (хотя если у вас малый объем данных или нет частичного поиска, то необязательно)) все остальное важно когда есть большой объем данных и серьезная нагрузка.
Неплохо бы конечно помнить что у пг есть функциональные индексы, штука прям читерная, но фунция должна быть immutable.
Ну а алгоритмы объединения за пределами explain вам вообще помнить незачем, а внутри уже все очевидно. Да и названия у них говорящие. Перечислять по памяти, даже если кто помнит, бессмысленно, потому как еще важен объем данных, объем оперативной памяти, сложность запросов, актуальность статистики таблицы итд
Итого в общем случае, backend-разработчику нужно знать о том что индексы есть. Писать читаемые параметризованные запросы и радоваться жизни. В вебе я все чаще вижу бред, вроде фукнций в условии, без построения индекса по ней (а Mysql вроде и не умеет), искоренение такого куда более важно, за это нужно бить топором по пальцам.
Хотите другой пример? Менее общий. Я ровно так же могу сказать «понятия не имею» по токностям работы журнала упреждающей записи postgresql, типам индексов и алогритмам объединений. И если случается нормальная беседа то:
1. Конечно вобщих чертах я знаю как работает WAL, но даже помнить о его существовании разработчику в общем то незачем
2.
— Как правило используется b-tree и только.
— hash индекс, за исключением случаев, когда создается самой базой, применять не стоило, во всяком случае до последнего времени, он порождал больше проблем, чем решал. Да и собственно быстрее он может быть только при поиске точного совпадения.
— GIST довольно редко используется, если вы не работаете с геоданными и интервалами
— GIN необходим если вы ищете частичное вхождение. В принципе gin_trgm_ops это то, что должен использовать вообще каждый если у вас есть поиск по справочникам.
— BRIN даже рассматривать не стоит если у вас не стоит задачи экономии дискового пространства.
UPD:
совсем забыл SP-GIST но я лично так и не придумал кудаб его приспособить, если не работать с геометрией.
Как видите, можно годами работать с postgresql и использовать только b-tree и этого в принципе достаточно. По идее это все таки работа архитектора бд, ибо за исключением построения триграмм (которым нужно возносить молитвы (хотя если у вас малый объем данных или нет частичного поиска, то необязательно)) все остальное важно когда есть большой объем данных и серьезная нагрузка.
Неплохо бы конечно помнить что у пг есть функциональные индексы, штука прям читерная, но фунция должна быть immutable.
Ну а алгоритмы объединения за пределами explain вам вообще помнить незачем, а внутри уже все очевидно. Да и названия у них говорящие. Перечислять по памяти, даже если кто помнит, бессмысленно, потому как еще важен объем данных, объем оперативной памяти, сложность запросов, актуальность статистики таблицы итд
Итого в общем случае, backend-разработчику нужно знать о том что индексы есть. Писать читаемые параметризованные запросы и радоваться жизни. В вебе я все чаще вижу бред, вроде фукнций в условии, без построения индекса по ней (а Mysql вроде и не умеет), искоренение такого куда более важно, за это нужно бить топором по пальцам.
Просто когда нужно запушить изменения, а человек не знает, что это такое, то время теряется.
Любой навык можно получить за конечное время, вопрос в том, что у бизнеса этого времени как правило нет. Не джуна на обучение нанимаем вроде.
С одной стороны да. С другой, если на гит завязано много чего, то может и не подойти. Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Любой навык можно получить за конечное время, вопрос в том, что у бизнеса этого времени как правило нет. Не джуна на обучение нанимаем вроде.
Ок. Но адекватный работодатель будет проверять другое. А если окажется, что соискатель подходит, но не знает git, то просто попросит прочитать «git basic howto» перед началом работы.
С одной стороны да. С другой, если на гит завязано много чего, то может и не подойти. Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Например, тегирование веток может запускать процессы CI, именование веток может быть завязано на езду тасок по джире, оповещения в почту/слак менеджерам и так далее… И может оказаться очень дорого обучение человека, который в это всё не умеет.
Хех, если система настолько сложная и custom'ная, то где этому соискатель научится — дома на пет-проектах?
Ну, я в пет-проектах вполне теггирование использую, потому что популярные CI движки вроде AppVeyor/Travis/CircleCi/… поддерживают деплой только тегированных сборок. А это весьма удобно для выкладывания своих домашних пакетов в npm/nuget/… предсказуемым образом.
Так что да, человек уже знает про гит, остается только ему дать информацию, что «вон ту штуку которую ты знаешь мы еще используем таким образом, а эту — таким». Это драматически уменьшает время на интеграцию в новый проект.
Так что да, человек уже знает про гит, остается только ему дать информацию, что «вон ту штуку которую ты знаешь мы еще используем таким образом, а эту — таким». Это драматически уменьшает время на интеграцию в новый проект.
позволю себе процитировать и себя и вас
а в том, как вы это делаете.
Зы теперь я с еще бОльшим упорством буду говорить «не знаю» )
Ну вот это больше всего характеризует вас как конфликтного человека с несколько завышенным самомнением. Не берем.
Вот на практике, и про мониторы спрашивали, и про размеры стола (конечно не про толщину, а про длину/ширину). И не поверите, даже про уровень CO один раз спрашивали. У нас в предыдущем офисе даже прибор был, который что-то мерил, помню какие-то циферки показывал ~500-900 вроде. Ну и надо проще относиться к таким вопросам я считаю, если для кого-то это так важно. Как собственно и кандидату надо проще относиться к вопросам, которые для себя считает важным работодатель.
Я когда работал коммерческим у меня был большой стол с толстой столешницей. Особенность в том, что можно стучать, ставить нечто, шатать, облакачивацо а монитор даже не шевелицо. А вот CO на самом деле очень важно, потому как я встречал и не раз офисе где работать невозможно. Даже хуже того, наступает поздний вечер и в офисе начинаешь вырубаться.
Я как то работал в маленьком офисе где вентиляции нет. Сначала не очень понятно было почему когда выходишь покурить в глазах светлеен не порядок, а потом когда все под вечер вырубаться начали — дошло. Работал так же рядом с химзаводом, незнаю есть ли связь, но сидел я рядом с открытым окном и в какой-то момент просто аж на стол падал. Думал не высыпался, но выходил, садился за руль, и по пути начинал себя подрячком чуять без намека на желание спать.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Я как то работал в маленьком офисе где вентиляции нет. Сначала не очень понятно было почему когда выходишь покурить в глазах светлеен не порядок, а потом когда все под вечер вырубаться начали — дошло. Работал так же рядом с химзаводом, незнаю есть ли связь, но сидел я рядом с открытым окном и в какой-то момент просто аж на стол падал. Думал не высыпался, но выходил, садился за руль, и по пути начинал себя подрячком чуять без намека на желание спать.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Вообще вопросы вопросами, но дело в том как спрашивают. Я за хорошую беседу с взаимным уважением. В конце концов деньги штука вторичная.
Я вот даже если понял, что кандидата буду сливать, никогда не прекращаю интервью сразу, конечно часть вопросов уже долгих пропускаю, но о компании рассказываю по полной. Т.е. установка такая, что кандидат, даже если нам не подошёл, должен уйти довольный.
Так собеседование — это форма экзамена. Что удивительного? Работодатель проверяет соискателя, тот проверяет условия работы, работодателя. Это два разных процесса. Сошлись оба в оценке друг друга — контракт заключен.
это форма экзамена
В таком случае, вероятно, студенты, вызубрившие справочник — лучшие программисты?
Я кстати напомню, что даже гугл признал, что понятия не имеет как правильно собеседовать. Где то встречал даже статью об околонулевой корреляции успешного собеседования с качеством работы сотрудника.
мда, вроде и знаю что такое virtual и даже иногда использую в коде.
Но вот честно, на внезапный вопрос что такое virtual, я наверно даже через минуту не отвечу правильным определением. А это значит провал собеседования. Это значит что любой джуниор сразу после универа будет выглядеть круче меня… на собеседованиях.
Но вот честно, на внезапный вопрос что такое virtual, я наверно даже через минуту не отвечу правильным определением. А это значит провал собеседования. Это значит что любой джуниор сразу после универа будет выглядеть круче меня… на собеседованиях.
И да — теперь, пока за мной не будет стоять мой код, на собес я не пойду.
Можете раскрыть мысль?
Тестовое. Я написал код, я могу доказать, что он мой, я точно не самозванец. Если код им показался плохим — собеса и не будет. Зато меня никто не унизит.
У вас логическая ошибка. Если есть желание унизить — что мешает им обговнять ваш код с ног до головы в письме и последней строчкой написать — собеса не будет. Не получится избегать оскорблений, можно только толщину кожи нарастить. Или всю жизнь сидеть в уютной конторе, где не шибко платят не шибко повышают, зато не оскорбляют и не давят. И надеяться что какой-то более толстокорый друг или коллега будет вас за собой тягать в более доходные проекты, и защищать вас от контактов.
Опять-же, вы согласитесь писать тестовое бесплатно в течении недели? И как вы докажите что код, ваш?
Вы не подумайте, я и сам не очень толстокорый. Просто не вижу другого выхода. Для себя нашел решение — не работать на русскоязычных начальников и заказчиков, вообще. Англоязычные более вежливые, менее напористые, менее авторитарные, они готовы уступать и разговаривать. А русскоязычные вечно строят армейскую дисциплину. Ну или мне так везло. Ну и кстати, я самозванцев не оскорблял, говорил «мы подумаем и если что свяжемся с вами». Не думаю что у них после собеседований были эмоциональные проблемы.
Опять-же, вы согласитесь писать тестовое бесплатно в течении недели? И как вы докажите что код, ваш?
Вы не подумайте, я и сам не очень толстокорый. Просто не вижу другого выхода. Для себя нашел решение — не работать на русскоязычных начальников и заказчиков, вообще. Англоязычные более вежливые, менее напористые, менее авторитарные, они готовы уступать и разговаривать. А русскоязычные вечно строят армейскую дисциплину. Ну или мне так везло. Ну и кстати, я самозванцев не оскорблял, говорил «мы подумаем и если что свяжемся с вами». Не думаю что у них после собеседований были эмоциональные проблемы.
Бизнес почему-то безумно боится самозванцев
Потому что один не опытный спец способен загубить при некоторых условиях бизнес на корню, если бизнес сильно зависим от ИТ.
Я как-то по молодости убил БД, копию не сделал.
После этого предприятие сильно скатилось вниз две недели восстанавливая базу и практически не работая, потом еще пару месяцев работая не шатко не валку. Конкуренты не дремали в это время.
Предприятие так и не поднялось до былого уровня.
У руководства любой организации есть обязанность: делегировать полномочия. Причём делегировать полномочия и подойти абы к кому и приказать абы что — не одно и то же.
В вашем случае вина делится долями между вами и теми, кто вам доверял. Это нормально, что за свою беспечность владелец бизнеса платит из своего же кармана.
Строго говоря, с точки зрения бизнеса вы вообще не виноваты, если у вас не было злого умысла.
В вашем случае вина делится долями между вами и теми, кто вам доверял. Это нормально, что за свою беспечность владелец бизнеса платит из своего же кармана.
Строго говоря, с точки зрения бизнеса вы вообще не виноваты, если у вас не было злого умысла.
Я как-то по молодости убил БД, копию не сделал.
Девопса/сис.админа на предприятии не было? Туда им и дорога.
Девопса/сис.админа на предприятии не было? Туда им и дорога
Ну дык я ими всеми и был.
А выделенный сис.админ — это очень круто. Вы представляете себе что такое малый бизнес?
до 150человек, с активами до 400млн. Вы наверно имели ввиду микро-бизнес. Там можно взять приходящего админа как и приходящего бухгалтера. Организационный вопрос.
У нас в студии из 2х разработчиков был отдельный сис. админ т.к. время обоих разработчиков стоит несоизмеримо дороже времени сис. админа.
У нас в студии из 2х разработчиков был отдельный сис. админ т.к. время обоих разработчиков стоит несоизмеримо дороже времени сис. админа.
Вы считаете, что проблема была только в вас? Т.е. что у предприятия не было бэкапов, логов, и всего-всего остального нужного, это нормально?
Junior, который в первый день работы удалил базу данных с production
Junior, который в первый день работы удалил базу данных с production
Так это вопрос разграничения доступа. Именно поэтому логично иметь некую тестовую БД, хотя бы просто копию. И новобранцев отправлять на неё, никакой боевой БД.
А бекапы у вас не делались?
Что такое virtual?Вот тоже в тупике от этого вопроса. Столько всякого мозг сразу вспомнил, что даже не знаю что бы выбрал.
Для чего virtual? Для того что бы базовые классы вели себя как наследующие классы. Как будто бы класс один, а объекты ведут себя по разному, потому что разные реализации наследования/переопределения виртуальных методов.
А, почитал и вспомнил, в C# оно пришло с тем же значеним из С++, на котором я когда-то кодил. Расспрашивая по синтаксису конкретного языка сеньера можно только отпугнуть.
Ну, если virtual реально так же работает как в C++ то вопрос еще имеет право на жизнь. Хуже когда вопрос становится настолько популярным что его пихают куда не поподя как тот же «чем отличается абстрактный класс от интерфейса». И пофиг что собеседуешь ты по C++ (где в принципе нет интерфейсов) или ObjC (где нет абстрактных классов (распространенный вариант «кидать эксепшн при вызове метода» это все-таки костыль-имитация, а не настоящий абстрактный класс), интерфейс строго говоря это просто описание что есть в классе/категории, а то что подразумевается под интерфейсом в вопросе называется протоколом )
Но вопрос был не «для чего», а «что такое». Тут, думаю, и кроется затруднение для нескольких отписавшихся в подобном ключе выше.
Интересно почему минуса. Я что-то неправильное написал?
Ну, в целом, да. Наследование работает и без virtual. Пока вы работаете с экземплярами класса, виртуальные методы вам не нужны, они выхотят на сцену, когда появляются указатели. virtual нужен, чтобы указатель на базовый класс, указывающий на класс-потомок, вызывал методы класса-потомка.
Наследование работает и без virtual.Обратного я и не писал.
virtual нужен, чтобы указатель на базовый класс, указывающий на класс-потомок, вызывал методы класса-потомка.Я написал примерно тоже. Что указатель указывающий на базовый класс, при вызове override методов, будет иметь поведение отличное от поведения базового класса из-за переопределения виртуальных методов классом-наследником.
Я не ставил вам минуса, — не имею такой привычки — поэтому не могу отвечать за тех, кто ставил. Но скажу честно, объяснение
На собеседовании, если бы мне пришло в голову об этом спросить, я бы, наверное, ожидал услышать ключевые слова «указатель» или «ссылка». Впрочем, на собеседовании можно уточнить, конечно, или (еще лучше) попросить набросать пример.
Для того что бы базовые классы вели себя как наследующие классы.вынесло мне мозг. Единственная разумная интерпретация, которую я смог придумать — что вы таким образом описываете обычное наследование.
На собеседовании, если бы мне пришло в голову об этом спросить, я бы, наверное, ожидал услышать ключевые слова «указатель» или «ссылка». Впрочем, на собеседовании можно уточнить, конечно, или (еще лучше) попросить набросать пример.
они выхотят на сцену, когда появляются указатели. virtual нужен, чтобы указатель на базовый класс...
Не совсем точно. Полиморфного поведения можно добиться, даже работая с конкретным классом наследника и невиртуальным API. Конечно, указатели на базовый класс появляются, но неявно. Идею проиллюстрирую на C#. Но на C++ то же самое, называется NVI; может работать просто через стековую переменную наследника, без явных ссылок/указателей.
abstract class Pet
{
public void NonVirtual() { NonPublic(); }
protected abstract void NonPublic();
}
sealed class Cat : Pet
{
protected override void NonPublic() { Console.WriteLine("Meow"); }
}
sealed class Dog : Pet
{
protected override void NonPublic() { Console.WriteLine("Bow!"); }
}
...
Cat cat = new Cat();
cat.NonVirtual();О том и речь. Для полиморфизма не нужен virtual. Virtual нужен только для того варианта полиморфизма, который использует указатели/ссылки на базовый класс.
А где именно в вашем примере полиморфизм?
А где именно в вашем примере полиморфизм?
Cat cat = new Cat();
cat.NonVirtual();
Dog dog = new Dog();
dog.NonVirtual();В обоих случаях вызывается один и тот же невиртуальный метод базового класса Pet.NonVirtual(). Но поведение будет разным, будет напечатано Meow и Bow!
Полиморфизм в методе public void NonVirtual() { NonPublic(); } Его реализация тут состоит из одного вызова, но может кроме этого содержать и какую-то общую для наследников логику. Паттерн Template method.
Полиморфизм в методе public void NonVirtual() { NonPublic(); }
Не-не, погодите. Полиморфизм у вас в методе NonPublic, и он как раз виртуальный. В NonVirtual никакого полиморфизма нетути.
В NonVirtual никакого полиморфизма нетути.
Он полиморфный по поведению, с точки зрения пользователя класса (которому недоступен виртуальный метод NonPublic() напрямую). Он был бы мономорфным, если бы использовал только функционал базового класса и не обращался к виртуальным методам, переопределённым в потомках.
Он полиморфный по поведению
По какому поведению?
с точки зрения пользователя класса
Никакой точки зрения нет. Метод либо объективно полиморфный, либо объективно не полиморфный. NonVirtual() — не полиморфный.
Метод либо объективно полиморфный, либо объективно не полиморфный.
abstract class Pet
{
public void NonPolymorphicNonVirtual()
{
Console.WriteLine("I'm pet");
}
public void PolymorphicNonVirtual()
{
Console.WriteLine($"{Virtual} {Virtual}");
}
protected abstract string Virtual { get; }
}
sealed class Cat : Pet
{
protected override string Virtual => "Meow";
}
sealed class Dog : Pet
{
protected override string Virtual => "Bow!";
}
...
{
Pet pet = new Cat();
pet.NonPolymorphicNonVirtual(); // I'm pet
pet.PolymorphicNonVirtual(); // Meow Meow
}
{
Pet pet = new Dog();
pet.NonPolymorphicNonVirtual(); // I'm pet
pet.PolymorphicNonVirtual(); // Bow! Bow!
}Полиморфизм — это абстракция, а не конкретная реализация. Это люди называют полиморфизмом такое поведение объекта, которое зависит от его подтипа, а не стандарт языка. Если трактовать класс Pet как черный ящик, то метод NonVirtual — однозначно полиморфный, ведь он ведет себя по разному, в зависимости от того, к какому подтипу относится объект.
Если трактовать класс Pet как черный ящик, то метод NonVirtual — однозначно полиморфный, ведь он ведет себя по разному, в зависимости от того, к какому подтипу относится объект.
Допустим, у меня два разных класса (не в общей иерархии, просто два разных класса). У каждого из них есть метод foo, определен он по-разному. У объекта одного класса вызвали — результат один, у объекта другого класса — результат другой. Следует ли из этого, что метод foo — полиморфный? Если нет, то почему?
Но тут-то другой случай. Метод вызывается один и тот же.
Допустим, у меня два разных класса (не в общей иерархии, просто два разных класса)
Так это не в общей. А тут общая иерархия и метод предка. Классический полиморфизм в ООП понимании, не забудьте про соблюдение LSP.
У каждого из них есть метод foo, определен он по-разному. У объекта одного класса вызвали — результат один, у объекта другого класса — результат другой. Следует ли из этого, что метод foo — полиморфный? Если нет, то почему?
Давайте более конкретный пример, хорошо? Вот есть классы Array, HashMap, Tree. В иерархию не входят. В каждом есть функция map(), интерфейс один. Полиморфная ли это функция?
Так это не в общей. А тут общая иерархия и метод предка.
То есть, полиморфизма нет, но вот я добавляю общего предка (при этом поведение программы никак не меняется) и полиморфизм появляется? Но как же это так, ведь выше рассуждения как раз о том, что полиморфизм определяется как раз по поведению, а остальное все — черный ящик?
Полиморфная ли это функция?
Следуя моей логике — безусловно, нет, точно так же как не являются полиморфными ф-и из примеров выше. Следуя вашей — безусловно, да.
Следуя моей логике — безусловно, нет, точно так же как не являются полиморфными ф-и из примеров выше.
Посмотрите хотя бы в Википедии, что такое полиморфизм.
Я-то знаю, и не только из википедии.
Полиморфизм в обсуждаемом контексте = позднее связывание.
Естественно, у этого термина есть и другие значения, но не стоит подменять понятия.
Это, кстати, легко доказать, вот есть такая штука, что три ключевых концепции ООП — это инкапсуляция, наследование и полиморфизм. Но наследование и полиморфизм подтипов (если подтипы номинальные) — это одно и то же. Следовательно, либо упоминаемый тут принцип полиморфизма — это не наследование (то есть не полиморфизм подтипов), либо у нас второй принцип совпадает с третьим. Вы какой вариант предпочитаете?
Это называется compile time polimorphism
this в методе NonVirtual — это тоже как бы переменная. Ее тип — Pet, а тип лежащего внутри объекта — Cat. Вот и полиморфизм.
Так никто не спорит, что полиморфизм есть. Просто он в методе NonPublic, а не в методе NonVirtual.
Полиморфизм — это способность функции обрабатывать данные разных типов. Этой способностью обладают оба метода.
Полиморфизм — это способность функции обрабатывать данные разных типов. Этой способностью обладают оба метода.
Это замечательно что вы прочитали статью из википедии, но мы тут обсуждаем совсем не этот полиморфизм.
В частности, согласно этому определению полиморфизмом являются перегрузки методов (ad-hoc полиморфизм типичный), однако на практике перегрузку полиморфизмом никто не называет.
В данном случае здесь не надо путать математическую модель (о чем и речь в случае subtyping-полиморфизм, и это никак вообще не связано с наследованием) и механизм позднего связывания (что подразумевается под полиморфизмом в контексте ООП и связано с наследованием напрямую).
Полиморфизм в ООП является частным случаем полиморфизма вообще. Я привел общее определение, чтобы показать что полиморфизм является свойством функции относительно ее входных параметров, а не механизмом.
Так вот. В обсуждаемом коде функция NonVirtual является полиморфной, поскольку может принять в качестве нулевого параметра не только объект типа Pet, но и любого наследника Pet.
Так вот. В обсуждаемом коде функция NonVirtual является полиморфной, поскольку может принять в качестве нулевого параметра не только объект типа Pet, но и любого наследника Pet.
Полиморфизм в ООП является частным случаем полиморфизма вообще.
Конечно же, нет! Частным случаем полиморфизма вообще является полиморфизм подтипов. Но полиморфизм подтипов — это просто констатация того факта, что любой метод предка есть у потомка. Он вообще никак не связан с разным поведением, перегрузкой методов в потомке и т.п.., это обычное наследование.
Вы же сейчас пытаетесь просто подменить понятия. О полиморфизме подтипов никто в этой ветке не говорил, забудьте про него вообще. Он не относится к делу.
Нет, полиморфизм подтипов — это констатация того факта, что потомка можно использовать всякий раз когда кто-то просит предка (или указатель на предка в таких языках как С++). К примеру, вот эта функция полиморфна, но не наследуется:
void Foo(Pet pet) {
pet.NonVirtual();
}Нет, полиморфизм подтипов — это констатация того факта, что потомка можно использовать всякий раз когда кто-то просит предка
Именно об этом я вам и говорю, но вы упорно не хотите этого факта понять.
К примеру, вот эта функция полиморфна, но не наследуется:
Прекратите подменять понятия. В смысле полиморфизма подтипов полиморфной является абсолютно любая функция в языке с наследованием. Неполиморфных просто не существует. Например:
class Pet {
public void Foo() {
Console.WriteLine("foo")
}
}тоже вполне полиморфная, ведь вы можете применить ее к любому потомку
Да, вы правы, полифорфной будет почти любая функция («почти» — потому что бывают типы от которых невозможно унаследоваться).
Но это же не означает что «наследование» и «полиморфизм подтипов» — это одно и тоже.
Но это же не означает что «наследование» и «полиморфизм подтипов» — это одно и тоже.
Да, вы правы, полифорфной будет почти любая функция («почти» — потому что бывают типы от которых невозможно унаследоваться).
Да без почти. Все методы любого типа можно вызвать на подтипе, то есть эти методы полиморфны. То, что подтипа может не быть у конкретного типа, полиморфизм не отменяет, предыдущее высказывание для таких типов точно так же остается истинным.
Но это же не означает что «наследование» и «полиморфизм подтипов» — это одно и тоже.
Наследование и полиморфизм подтипов — это эквивалентные вещи по определению. Не бывает наследования без полиморфизма подтипов и не бывает полиморфизма для номинальных подтипов без наследования.
В любом случае это бессмысленный разговор. В контексте ООП под полиморфизмом подразумевается не полиморфизм подтипов, а механизм позднего связывания. И в таком контексте в языке без виртуальных функций полиморфизма в принципе нет. Хотя полиморфизм подтипов — конечно же, есть.
не бывает полиморфизма для номинальных подтипов без наследования
https://dlang.org/spec/class.html#alias-this
Не бывает наследования без полиморфизма подтипов
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
https://dlang.org/spec/class.html#alias-this
Где вы тут нашли подтипирование в том или ином виде? Его нет.
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_sci
ко/контра-вариантность — это когда подтипирование объединяется с параметрическим полиморфизмом, то есть полиморфизм подтипов там гарантированно есть. Вы бы сами в вопросе лучше разобрались и желательно не по википедии, возьмите TaPL почитайте.
Где вы тут нашли подтипирование в том или ином виде?
Алиас позволяет создать подтип без наследования. Посмотрите примеры внимательно.
ко/контра-вариантность — это когда подтипирование объединяется с параметрическим полиморфизмом, то есть полиморфизм подтипов там гарантированно есть.
Полиморфность надтипа в случае контравариантности и полное отсутствие полиморфизма в случае инвариантности.
Алиас позволяет создать подтип без наследования.
Где? Я не вижу в примерах создания подтипа.
Полиморфность надтипа в случае контравариантности и полное отсутствие полиморфизма в случае инвариантности.
Так отсутствие полиморфизма только для T, сами А прекрасно наследуются и соответствующие ф-и полиморфны, все в порядке.
Где? Я не вижу в примерах создания подтипа.
Эта конструкция собственно и объявляет структуру/класс подтипом другого типа. По спецификации языка. С чем вы тут пытаетесь спорить — ума не приложу.
сами А прекрасно наследуются
А я где-то утверждал, что не наследуются? Наследование и полиморфизм — оргогональные понятия.
и соответствующие ф-и полиморфны, все в порядке.
Не знаю, о каких "соответствующийх функциях" вы говорите (надеюсь не съехали на позднее связывание?), но если я не могу вместо одного типа где угодно подставить его подтип, то полиморфизмом подтипов тут и не пахнет.
Эта конструкция собственно и объявляет структуру/класс подтипом другого типа.
Я не понимаю, с чего вы это взяли.
По спецификации языка.
Ну там неправильно написано. Демонстрируемое в примерах поведение этому не соответствует. Либо под "подтипом" подразумевается что-то другое. Нигде это значение не ведет себя как подтип, оно просто ведет себя как соответствующее поле, то есть выполняется неявная конверсия. И неявная конверсия — это не подтипирование. Неявная конверсия и подтипирование ведут себя по-разному, и эту разницу можно пронаблюдать.
А я где-то утверждал, что не наследуются?
То, что наследуются — утверждал я, а вы это оспаривали. Если вы оспаривали мое утверждение — с-но, утверждали нечто обратное, разве нет?
Наследование и полиморфизм — оргогональные понятия.
Мы же уже выяснили, что наследование и полиморфизм подтипов — это одно и то же, как понятие может быть ортогонально само себе? Невозможно реализовать наследование без полиморфизма подтипов и наоборот.
Не знаю, о каких "соответствующийх функциях"
Я говорю о любых ф-ях, которые принимают А (они же могут принимать и любой подтип А, то есть полиморфизм подтипов есть).
но если я не могу вместо одного типа где угодно подставить его подтип, то полиморфизмом подтипов тут и не пахнет.
Но вы можете.
Я немного разбирался в кухне рекрутмента, смотрел какие отзывы народ оставляет у нас в проекте, беседовал с людьми которые устраивались.
Вывод достаточно очевиден — если на собеседовании было некомфортно, то в самой компании вряд ли будет лучше — будете иметь дело с такими же самодовольными чуваками, просто потом они будут ставить такие же бессмысленные задачи.
Вывод достаточно очевиден — если на собеседовании было некомфортно, то в самой компании вряд ли будет лучше — будете иметь дело с такими же самодовольными чуваками, просто потом они будут ставить такие же бессмысленные задачи.
Еще мы постоянно забываем, что HR работает не только с программерами, они пытаются решить задачу «ненайма самозванца» для любой более-менее ответственной должности в компании.
Самодовольство человечка, проводившего собеседование говорит только о том, что они на поиск сеньора отрядили начальника или зам-начальника, и им важно не облажаться с самозванцем.
А чем выше должность в вакансии, тем выше риски. Бывает, что ищут замдиректора, там вообще сливай воду — туши свет, говорить умеют все, работать — один на тысячу.
Самодовольство человечка, проводившего собеседование говорит только о том, что они на поиск сеньора отрядили начальника или зам-начальника, и им важно не облажаться с самозванцем.
А чем выше должность в вакансии, тем выше риски. Бывает, что ищут замдиректора, там вообще сливай воду — туши свет, говорить умеют все, работать — один на тысячу.
Нельзя брать разработчика, ориентируясь только на его код.
Бывают соискатели, которые берут код своего тимлида и выдают за свой, например, выкладывают на Гитхаб.
Поэтому и актуален и вайтбординг, и опрос по базовым вещам. Такова реальность.
К вайтбордингу легко подготовиться, прорешивая задачки с LeetCode, например.
Бывают соискатели, которые берут код своего тимлида и выдают за свой, например, выкладывают на Гитхаб.
Поэтому и актуален и вайтбординг, и опрос по базовым вещам. Такова реальность.
К вайтбордингу легко подготовиться, прорешивая задачки с LeetCode, например.
Ужас! Вот, я. Думаю, что мне делать. Просто так читать книги, да мануалы? Пополнять ряды ничего не умеющих «самозванцев»?… Их (тем, вопросов, сред разработки, библиотек, языков программирования) много. А я один.
Может быть подкинете мне мне какую-нибудь «домашку». Хочу сделать что-нибудь реальное. Работающее. Нужное. Заодно, изучу новое для себя. Испытаю свои силы. Стану лучше соображать.
А? Пожалуйста!
Может быть подкинете мне мне какую-нибудь «домашку». Хочу сделать что-нибудь реальное. Работающее. Нужное. Заодно, изучу новое для себя. Испытаю свои силы. Стану лучше соображать.
А? Пожалуйста!
Вы тут про программирование, а я вот уже с середины лета никак не могу найти работу сисОдмином.
И знаете, ситуация точь в точь такая же.
Был в одной компании, такое знаковое собеседование, побеседовал с старшим админом (искал сменный график, а это в основном тп), простой мужик, простые вопросы, спокойная беседа, и вдруг вваливается ЭТО… кашляя, задыхаясь, чихая во все стороны — начальник ИТ отдела!
Первый вопрос — какая команда в цискаре нужна для вот этого (уже не помню сути).
мысли путаются, ладошки потеют, последний раз кошака мацал год назад — не помню.
Итог — с гордым видом рассказывает мне пошагово от и до как мацать кошку… и похуй что в мои обязанности даже близко не будут стоять блохастые. Давай, дасвидания.
И почти всегда всё в таком же духе, реально как в школе…
p.s. а ещё все очень сильно удивляются, что на моём текущем месте работы очень редки форс-мажоры. всё исправно и стабильно работает, и нет ацких «юзверей». и хер им докажешь, что грамотно отстроенные системы и регулярный контроль решают, и что людей можно выдрессировать не «сувать в принтер скрепки»…
только у меня не бомбит как у тс, у меня депрессия =)
И знаете, ситуация точь в точь такая же.
Был в одной компании, такое знаковое собеседование, побеседовал с старшим админом (искал сменный график, а это в основном тп), простой мужик, простые вопросы, спокойная беседа, и вдруг вваливается ЭТО… кашляя, задыхаясь, чихая во все стороны — начальник ИТ отдела!
Первый вопрос — какая команда в цискаре нужна для вот этого (уже не помню сути).
мысли путаются, ладошки потеют, последний раз кошака мацал год назад — не помню.
Итог — с гордым видом рассказывает мне пошагово от и до как мацать кошку… и похуй что в мои обязанности даже близко не будут стоять блохастые. Давай, дасвидания.
И почти всегда всё в таком же духе, реально как в школе…
p.s. а ещё все очень сильно удивляются, что на моём текущем месте работы очень редки форс-мажоры. всё исправно и стабильно работает, и нет ацких «юзверей». и хер им докажешь, что грамотно отстроенные системы и регулярный контроль решают, и что людей можно выдрессировать не «сувать в принтер скрепки»…
только у меня не бомбит как у тс, у меня депрессия =)
Сколько народу набрал в своё время, вообще о таких опасениях не задумывался.
Приходит человек, спрашиваешь опыт — сразу задаёшь любой вопрос из деталей рассказанного, сразу видна правда или ложь. Приходят зелёные, но хотят работать — через год-два они заткнут многих "сеньоров".
Мне реально хватало 15 минут чтобы понять — брать человека или нет. Набирали конвейером. Ни разу не пожалел.
Самые адекватные компании — это где либо HR не участвует в отборе и нет рекрутеров, либо же где реально клёвые ребята на этих местах — сами бывшие технари.
P.S. Один раз мне отказали в интервью, т.к. в списке скиллов не было Ajax, но был JS и React.
А в чем, собственно, проблема?
Мне тоже доводится частенько собеседовать самых разных людей на позиции SE. Я вижу, чем люди занимались. Я знаю, чем им предстоит заниматься. На основе этого я прикидываю, о чем следует поговорить с человеком, чтобы понять _как_ он работал. У моего работодателя есть возможность выбирать между кандидатами, и будь я проклят, если я ей не воспользуюсь.
Т.е. лучше я перестрахуюсь и не возьму пять отличных инженеров, чем случайно возьму одного. Знаете, как идеология гугловых собеседований — ни в коем случае не уменьшать планку уровня уже имеющихся разработчиков, потому что в итоге это приведет к деградации УровняТМ.
Вернемся к тому, _как_ человек работал свои 5, 10, 15 лет стажа. У собеседовающих же нету информации по результатом внутреннего эвалюэйшена по сотруднику в каждом его месте работы. Он мог выполнять несложные задачи, которые давал ему лид, а мог драться и спорить по поводу целесообразности и того, как делать каждую задачу. Мог шлепать по одному и тому же принципу однотипные сайты/сервисы/приложения/etc. А мог постоянно изучать новые техники и подходы к проектированию, анализу и разработке. Мог использовать остальные компоненты системы (ОС, компилятор, соседние сервисы, либы) как блекбоксы, а мог ковыряться в кишках, понимать внутреннее устройство и под каким соусом эти компоненты лучше всего готовить.
Не бомбите. Не горите. Просто либо вам не повезло, либо работодатель и правда искал не вас. На одном сотруднике и на одном работодателе свет клином не сошелся. Благо, мы в IT, можем себе позволить :)
Мне тоже доводится частенько собеседовать самых разных людей на позиции SE. Я вижу, чем люди занимались. Я знаю, чем им предстоит заниматься. На основе этого я прикидываю, о чем следует поговорить с человеком, чтобы понять _как_ он работал. У моего работодателя есть возможность выбирать между кандидатами, и будь я проклят, если я ей не воспользуюсь.
Т.е. лучше я перестрахуюсь и не возьму пять отличных инженеров, чем случайно возьму одного. Знаете, как идеология гугловых собеседований — ни в коем случае не уменьшать планку уровня уже имеющихся разработчиков, потому что в итоге это приведет к деградации УровняТМ.
Вернемся к тому, _как_ человек работал свои 5, 10, 15 лет стажа. У собеседовающих же нету информации по результатом внутреннего эвалюэйшена по сотруднику в каждом его месте работы. Он мог выполнять несложные задачи, которые давал ему лид, а мог драться и спорить по поводу целесообразности и того, как делать каждую задачу. Мог шлепать по одному и тому же принципу однотипные сайты/сервисы/приложения/etc. А мог постоянно изучать новые техники и подходы к проектированию, анализу и разработке. Мог использовать остальные компоненты системы (ОС, компилятор, соседние сервисы, либы) как блекбоксы, а мог ковыряться в кишках, понимать внутреннее устройство и под каким соусом эти компоненты лучше всего готовить.
Не бомбите. Не горите. Просто либо вам не повезло, либо работодатель и правда искал не вас. На одном сотруднике и на одном работодателе свет клином не сошелся. Благо, мы в IT, можем себе позволить :)
«лучше я перестрахуюсь и не возьму пять отличных инженеров, чем случайно возьму одного». Думаю, посыл автора статьи в том, какие вы меры предпринимаете для того, чтобы производить отсев, и какие вопросы задаете. Вопросы типа тех, о которых он говорит позволят вам отсеить пять отличных инженеров и взять одного профессионального проходимца собеседований.
А мой посыл в том, что у каждого собеседующего есть своя мотивация задавать те вопросы, которые он задает (если собеседующий — сам инженер, конечно, хехе). Если не сошлись его вопросы и ваши ответы — значит вы друг другу не подходите, очень просто.
В маленьких компаниях, не претендующих на единорогов, собеседования проводятся по-другому, например. Куда более по-свойски.
Понимаете, спрос-предложение — это и для рынка вакансий и рабочей силы справедливо. Если спроса на отличных спецов, которые не могут знать стандарты языка наизусть, нет — то это уже проблема спецов будет подстроиться под рынок. А не проблема рынка подстроиться под спецов.
Опять тот же гугл. Все знают, что там вайтбординг. Все знают, что там алгоритмы, которые в работе никогда не встретятся. Все знают, насколько там, казалось бы, несуразное интервью. И все равно идут и специально (!!!) готовятся именно к этому интервью.
Если работодатель достаточно хорош и знаменит — ему простят его причуды. Если работник достаточно хорош и знаменит — ему простят незнание чего-либо. А все остальные следуют Невидимой Руке Рынка(ТМ)
В маленьких компаниях, не претендующих на единорогов, собеседования проводятся по-другому, например. Куда более по-свойски.
Понимаете, спрос-предложение — это и для рынка вакансий и рабочей силы справедливо. Если спроса на отличных спецов, которые не могут знать стандарты языка наизусть, нет — то это уже проблема спецов будет подстроиться под рынок. А не проблема рынка подстроиться под спецов.
Опять тот же гугл. Все знают, что там вайтбординг. Все знают, что там алгоритмы, которые в работе никогда не встретятся. Все знают, насколько там, казалось бы, несуразное интервью. И все равно идут и специально (!!!) готовятся именно к этому интервью.
Если работодатель достаточно хорош и знаменит — ему простят его причуды. Если работник достаточно хорош и знаменит — ему простят незнание чего-либо. А все остальные следуют Невидимой Руке Рынка(ТМ)
Если не сошлись его вопросы и ваши ответы — значит вы друг другу не подходите, очень просто.
Как-то дочитал "Как сдвинуть гору Фудзи" до задачи «как бы вы спроектировали интерфейс видеомагнитофона» — чуть-чуть понял, почему продукты Microsoft немного особенные.
По статье +, но есть вопрос.
Почему так?
И уже не важно, что я на самом деле стараюсь избегать классического наследования, предпочитая ему композицию, и проектирую свои классы и системы таким образом, чтобы от них не требовалось делать наследников.
Почему так?
Потому что как правило, это более гибко и лучше масштабируется.
Об этом часто пишут в книгах, например Design Patterns
Об этом часто пишут в книгах, например Design Patterns
Я уже наблюдаю другую крайность, когда некоторые "гении" полностью отказываются от наследования. Полностью! И кидают в тебя кучу интерфейсов, которые нужно реализовать.
Как говорится, заставь дурака Богу молиться, он и лоб расшибет.
Я в книгах наоборот это редко встречаю («ООАиП» Гради Буч, «ООАиП» Крег Ларман, «Принц. пат. и мет. г.р.» Роберт Мартин, «Чистая архитектура» Роберт Мартин). Выбор между наследованием, ассоциацией, композицей и агрегацией не всегда прост, если в предметной области не сильно разбираешься.
Я не те книги возможно читаю.
Но меня тоже иногда тревожит, когда например, абстрактный класс сенсор имеет наследников на 3-4 уровня. Подобное на проде я бы и сам побоялся сделать.
Но в целом да, более гибко, по обстоятельствам короче.
Я не те книги возможно читаю.
Но меня тоже иногда тревожит, когда например, абстрактный класс сенсор имеет наследников на 3-4 уровня. Подобное на проде я бы и сам побоялся сделать.
Но в целом да, более гибко, по обстоятельствам короче.
Ой все эти "гибко и масштабируется" настолько сферический конь в вакууме. У меня на практике выходило так что хорошо спроектированный и написанный код никто масштабировать и гнуть не собирается. а когда таки придет время то там будет проще переписать. А почему? А потому что в хорошем коде уже все продумано и реализованно с учетом возможных изменений требований на ближайшую перспективу. и два там так напроектированно что только сеньеров туда пускать. а то первый джун превратит всю стройную архитектуру в кусок очень сложного навоза.
И какая разница что пишут в книжках про паттерны проектирования. Мы тут сейчас комментируем претендента на должность сеньера. который забыл про virtual… Ну не верю я в это. можно забыть про что то редкое или необязательное. но виртуал я не зная языка скажу что это про наследование, динамический полиморфизм и позднее связывание речь идёт.
Мне кинули предложение — Senior full-stack .NET Developer, удаленно, крутой проект, куча денег. В списке требований хренова гора не связанных между собой вещей из мира .net и js/ts. Выглядит так, будто просто свалили в кучу все, что нагуглили за 10 минут — причем мало понимая, что именно.
Тревожно, но ничего.
Конец немного предсказуем:
Ну привет. Я только что с собеса, и у меня бомбит. Сколько не пишут на Хабре, как правильно собеседовать — лучше не становится.
Странно было ожидать чего-то другого...
Нет никакого «бизнеса», который что-то хочет. Есть разраб, который неплохо кодит и тут ему дают задание провести собеседование. Он идет в гугл и пишет «вопросы на собеседование .net». Видит вопросы, иногда знает, а иногда нет ответы на них. Узнает что-то новое для себя, повторяет основы, наслаждается жизнью.
Потом приходит и спрашивает то же самое у вас. Это все мы, товарищи, мы и есть такие разрабы. Многие из нас не подходят к вопросам собеседования с прагматических позиций.
Потом приходит и спрашивает то же самое у вас. Это все мы, товарищи, мы и есть такие разрабы. Многие из нас не подходят к вопросам собеседования с прагматических позиций.
Подход «при необходимости я найду это в справочнике» вполне допустим, но на практике есть какая-то грань разумности такого… нигилизма что ли. Не ответить про virtual — это за этой гранью кмк. Чисто субъективно, разумеется.
Хах…
В этом месяце меня в Билайн собеседовали. Тоже была куча вопросов по синтаксису и ни одного программисткого вопроса. Я бы не смог оценить человека по таким вопросам-ответам за 10 минут. В Билайне смогли и отказали. Видимо из-за недостаточной квалификации :D
PS 10+ лет опыта на тяжёлых проектах в основном зарубежом.
В этом месяце меня в Билайн собеседовали. Тоже была куча вопросов по синтаксису и ни одного программисткого вопроса. Я бы не смог оценить человека по таким вопросам-ответам за 10 минут. В Билайне смогли и отказали. Видимо из-за недостаточной квалификации :D
PS 10+ лет опыта на тяжёлых проектах в основном зарубежом.
Может это был первичный собес?) Тот же яндекс любит устраивать по 2-3 технических интервью.
2-3 это вполне сносно. В некоторых компаниях по 5-6.
Ну да, это первичное собеседование было. Но зачем такое собеседование (вопросы по синтаксису) — оно ведь не показательно. Ведь в результате него отсеивается человек, который лучше подготовлен, чем тот кто только-что прочитал какой-нибудь beginners и знает 'все' конструкции языка.
Но зачем такое собеседование… — оно ведь не показательно.
Отсеить совсем уж бестолковых людей. Там, как правило, сильно тонких тонкостей не спрашивают, поэтому опытный программист пройдет его в любом случае.
знает 'все' конструкции языка
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Смотря какой язык.
ВСЕ конструкции легендарного PL/1 — мало кто знал.
Учитывая, как некоторые языки (не буду указывать пальцем) пухнут от версии к версии из-за синтаксического сахара, у меня закладывается смутного подозрение, что многие профессионалы, каждый день использующие этот язык на практике, могут и не знать абсолютно все его конструкции.
Не могу ничего сказать про PL/1.
Практика показывает, что на собеседованиях (как и сам бизнес) не особо гонятся за трендовыми штучками. Но интерес к развитию своих инструментов — это тоже показатель, имхо. Часто через «сравнения» и «перспективы» на собеседованиях развиваются дискуссии, где в милой беседе можно достаточно глубоко копать человеку в голову. При подготовке стоит это учитывать.
некоторые языки (не буду указывать пальцем) пухнут от версии к версии из-за синтаксического сахара, у меня закладывается смутного подозрение, что многие профессионалы… могут и не знать абсолютно все его конструкции.
Практика показывает, что на собеседованиях (как и сам бизнес) не особо гонятся за трендовыми штучками. Но интерес к развитию своих инструментов — это тоже показатель, имхо. Часто через «сравнения» и «перспективы» на собеседованиях развиваются дискуссии, где в милой беседе можно достаточно глубоко копать человеку в голову. При подготовке стоит это учитывать.
Дык по С++ то же самое, вряд ли сам Страуструп все конструкции помнит. Это я на момент 2010 года пишу, с тех пор, я слышал, еще больше всего появилось.
Знать все конструкции языка — это нормально и необходимо для любого уровня профессионального развития человека, который сам пишет код.
Не соглашусь. Это нужно знать джунам, так как сосуд пока полностью пустой, и неплохо было бы его хоть чем-то наполнить. Спустя 10-15-20 лет у вас уже нет места в сосуде и чтобы туда залить что-то еще, оттуда должно вытечь что-то другое.
Поэтому юные программисты умеют писать красивый код и помнят все конструкции по памяти (одного ЯП), а старожилы (часто знающие от 4 ЯП) не код пишут, а создают программное обеспечение, фактически создают готовое решение!
Спустя 10-15-20 лет у вас уже нет места в сосуде и чтобы туда залить что-то еще, оттуда должно вытечь что-то другое.
Если откинуть романтизацию опыта «исчисляемого годами», это звучит как возрастные проблемы с обучаемостью (если «вытекает»), серьезно. Не встречал действительно крутых профессионалов, у которых наблюдались бы провалы в памяти по поводу базовых конструкций основного языка.
Зато часто встречаются люди, которые годами пишут одинаковые приложения с помощью одинаковых подходов и напрочь забывают о существовании альтернатив. Это годы застоя, а не опыт.
Поэтому юные программисты умеют писать красивый код
Потому что они не умеют читать некрасивый код. С опытом причуды оформления становятся менее значимыми и болезненными. Но это уже совсем другая история.
Спорим, что я угадаю ваш возраст? ))) Не многим более 20 лет. Угадал?
Вы никогда не задумывались почему Запад аутсорсит только кодеров, а не идейных вдохновителей. Почему нужны только дешевые рабы на галеры?
Нет, дело не в нашем опыте, знаниях и уникальности. Все дело в цене!
А у вас не возникал вопрос, кто же все таки все те люди, которые придумывают для крутого софта алгоритмы/подходы/идеи/паттерны и т.д.? И почему они все только на Западе. А еще очень интересно сколько лет этим людям? Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Так в какой же момент вашего времени произошел перекос, когда вы можете утверждать, что знаете ЯП лучше, чем его создатель? Маркером будет какой показатель? То что вы помните какие-то конструкции, а он уже нет?
В тысячный раз повторюсь, программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT. Многим даже и код никакой писать не нужно, для этого они аутсорсят нас за еду!
Вы никогда не задумывались почему Запад аутсорсит только кодеров, а не идейных вдохновителей. Почему нужны только дешевые рабы на галеры?
Нет, дело не в нашем опыте, знаниях и уникальности. Все дело в цене!
А у вас не возникал вопрос, кто же все таки все те люди, которые придумывают для крутого софта алгоритмы/подходы/идеи/паттерны и т.д.? И почему они все только на Западе. А еще очень интересно сколько лет этим людям? Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Так в какой же момент вашего времени произошел перекос, когда вы можете утверждать, что знаете ЯП лучше, чем его создатель? Маркером будет какой показатель? То что вы помните какие-то конструкции, а он уже нет?
В тысячный раз повторюсь, программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT. Многим даже и код никакой писать не нужно, для этого они аутсорсят нас за еду!
Нет, вы ошиблись.
При чем здесь Запад и топ-менеджмент вообще? R&D-отделов крупных вендоров и в СНГ хватает, например.
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
Дядьки эти, как правило, код не пишут, а руководят проектами и теми, кто пишет (теми самыми сеньорами-миддлами-джуниорами простопрограммистами).
почему Запад аутсорсит только кодеров, а не идейных вдохновителей.
При чем здесь Запад и топ-менеджмент вообще? R&D-отделов крупных вендоров и в СНГ хватает, например.
Вы учились по книгам и лекциям 18 летних парней или все же взрослых уже людей?
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
программное обеспечение не кодеры строят, а те самые бородатые дядьки, обладающие колоссальным опытом и знаниями во многих сферах IT.
Дядьки эти, как правило, код не пишут, а руководят проектами и теми, кто пишет (теми самыми сеньорами-миддлами-джуниорами простопрограммистами).
Взрослых и умных, разумеется. Ценные знания формошлёпа с 15+ стажем я могу почитать только в заминусованном посте на хабре.
Ха, не удержались, кинули какашкой. А что можно почитать от такого крутого специалиста, как вы? Уж вы-то точно не формошлепер. И у вас такой богатый опыт в комментариях. Хочу у вас чему-то научиться. Ведь это же нормальное желание? Поделитесь своими статьями, можно даже заминусованными.
Приняли на свой счет? Я понятия не имею о том, какой вы специалист и по этой причине не перехожу на личности с незнакомым человеком в интернете. Писалось не о вас лично, разумеется.
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Расскажите же по сути обсуждения: почему давно практикующий разработчик не может быть бестолковым?
Конечно может быть, как и инженер, как и архитектор, также как и врач и т.д.
Но если немного порассуждать, то возникает вопрос, а зачем люди шли в такие тяжелые сферы, долго обучались в университетах и много лет практиковались, что бы быть бестолковыми?
Зачем им все это? Зачем такие усилия, чтобы спустить их на безделие и стать бестолковыми? Разве нет более простых, гуманитарных специальностей, где можно быть бестолковым вполне комфортно и не напряжно?
А я скажу, почему витает в воздухе дух того, что взрослые люди бестолковые, а молодые дарования — гении.
Все просто. 20-30 лет назад программирование только зарождалось, и те кто в него приходили, делали это не из-за денег или престижа. А из-за жажды новых технологий и прогресса. Подавляющее большинство таких людей, если не все, заканчивали технические университеты с профильными факультетами: автоматизированные системы/кибернетика/робототехника/схемотехника и т.д. Такие люди прошли весь свой путь до сегодняшнего дня с нуля. А некоторые еще и помнят, как нашкрябать простой контроллер в машинных кодах!
И теперь вернемся к нашему времени. Молодые и талантливые дарования, которые считают, что образование/университеты/опыт взрослых людей все это полная шляпа и отстой, быстро изучают по «супер курсам» и роликам из Ютюб какой-то ЯП высокого уровня. Выпендриваются друг перед другом знанием классов/методов и т.д. тем самым пытаясь поднять свое ЧСВ. А как работает комп, что такое шина данных/управления и т.д. знать вообще никому на фиг не нужно. Не царское это дело. Можно взять какой-нибудь фреймворк/CMS и просто шлепать типовые задачи — УРА, профит!
А все те, кто говорят, что уровень знаний таких талантов около нуля, и что ЯП вообще в разработке стоит на последнем месте, то те ламеры, старые и бестолковые пердуны, которые не развиваются ни в чем и максимум что помнят — это какой-нибудь Фортран или Кабол. Короче стандартная подмена понятий.
Именно по этому толковый преподаватель в ВУЗе натянет на экзамене любое юное дарование, которое все знает и умеет.
И такая ситуация не только в ИТ. Она везде.
Именно по этому многие компании (часто Зарубежные) ищут разработчиков за 30-50 лет. Так как золотая молодежь, которая все знает и умеет, и которой насрать на бизнес заказчика, реально уже многих зае… ала.
И если просмотреть реальный успех в ИТ людей по возрастной рамке, то окажется, что он приходит часто после 40 лет, и почти никогда, сразу после 20.
А так как на хабре в подавляющем большинстве сидит молодежь, чьи реальные имена скрыты, у которых нет своих публикаций/сайтов/блогов/опенсорс и т.д., то при таких комментариях или статьях у них реально пригорает, так как бьет по их самолюбию. И какая бы статья не была полезной/важной/правдивой ее обязательно обосрут и заминусят. Что, в свою очередь, никак не принизит опыт/знания/интеллект автора, и уж тем более не возвысит комментаторов, кидающихся фикалиями.
Надеюсь, я смог развернуто ответить на ваш вопрос?
20-30 лет назад программирование только зарождалось, и те кто в него приходили, делали это не из-за денег или престижа.
Да ты че?
Лет 25 назад мой преподаватель рассказывала о том, как именно программирование уже вовсю применялось на примере огромного завода, на котором она работала в 1970-х. То есть почти 50 лет назад. А один из старейших ныне еще применяемых языков программирования для бизнес-приложений, а вовсе не для научных целей — Cobol — был создан в 1959 году. Применяется до сих пор по той причине, что еще тогда были написаны горы программного кода.
А можете назвать, пожалуйста, этот современный, на те года, советский завод, где во всю применялось программирование, чего, кстати?
Я не говорю про программирование в мире. Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
Я не говорю про программирование в мире. Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
А можете назвать, пожалуйста, этот современный, на те года, советский завод, где во всю применялось программирование, чего, кстати?
АвтоВАЗ
Я говорю про наши реалии. А наши реалии таковы, что на множестве отечественных предприятий сегодня сотрудники компьютера в глаза не видели, не то что писали софт.
А что, в наше время, абсолютно все должно делаться в Виртуалии?
Очевидно, что такие предприятия ведут свою деятельность в реальном, а не виртуальном мире, что не может не радовать. Едим-то мы вполне материальные вещи.
Мне уже плохо. Честное слово, при одном упоминание все поплыло перед глазами.
Мне уже плохо. Честное слово, при одном упоминание все поплыло перед глазами
Это сейчас. Все же полвека минуло.
А на момент основания в 1966 году — АвтоВАЗ был вполне себе технологически совершенным, в том числе и по меркам всего мира. И ВЦ на АвтоВАЗе был весьма и весьма хорош.
ВАЗ, не АвтоВАЗ. Хотя и АвтоВАЗ тоже, но по контексту, кмк имеется в виду именно завод, не ПО.
А так да — например, некоторые мои преподаватели по ряду предметов в ВУЗе принимали непосредственное участие в роботизации ВАЗа, приводили конкретные примеры.
Мой отец разрабатывал АИС для сервисных центров АвтоВАЗа в 80е.
А так да — например, некоторые мои преподаватели по ряду предметов в ВУЗе принимали непосредственное участие в роботизации ВАЗа, приводили конкретные примеры.
Мой отец разрабатывал АИС для сервисных центров АвтоВАЗа в 80е.
Какая разница, что в мире есть предприятия, которым компьютер нужен постольку-поскольку? Очевидно, что такие предприятия ведут свою деятельность в реальном, а не виртуальном мире, что не может не радовать. Едим-то мы вполне материальные вещи.
С одной стороны вы правы, а с другой ведь софт и придумали для автоматизации и повышения эффективности труда. Был у меня в жизни реальный случай, пару лет назад.
Наняла меня контора, которая занимается бурением и цементированием нефтегазовых скважин, чтобы я подготовил им документацию, для создания софта, который поможет взаимодействовать с кучей отделов, лабораторий и софт для расчета цементирования скважин. Не уже готовое ТЗ для создания софта, а только концепцию и алгоритмы (блок схемы, диаграммы, описание и т.д.).
Так вот, какую проблему я у них увидел. Коммуникация между отделами и лабораториями на каких-то служебных записках, по мылу и по скайпу. Все расчеты для цементирования скважин в экселе!!!
В итоге, при последнем заказе при цементировании скважины, подаваемый в скважину цемент схватился раньше, чем успели произвести технологический процесс. Финансовая потеря составила 2 млн. долларов! Они этот косяк называю «словить козла». Начали искать виновного, чей это косяк, лаборатории, которая неправильный состав рассчитала, отдела инженеров, которые нарушили тех. процесс, производителя (у них свой завод по производству спец. цемента), который нарушил рецептуру. Кто виноват, так и не нашли. И в чем была проблема, тоже не выяснили. Просто попали на капусту.
И вот после такого больного попандоса и пришло понимание, что все же автоматизация и софт нужны.
Да, спасибо. Хотя, я все же считаю, что проблема не в возрастах, а в людях. Хотя современное развитие веба действительно протолкнуло в ИТ много не особо увлеченных сферой людей.
Хватит подозревать разрабов в самозванстве. Научитесь лучше собеседовать