Как стать автором
Обновить

Комментарии 173

если у него есть правильные ответы

Такие ответы есть, как правило, у людей с опытом. Как задача для стенда, что бы получить футболку/кружку вполне ок. Как задача для собеседования – не ок. Зачем нужны такие задачи можно найти в книге Java Puzzlersю
Опыт в мире разработки — ничего не стоит. Вообще ничего, нет никакой корреляции между опытом и скиллом. И это важно понимать

Важно понимать, что опыт стоит достаточно много. Тот, кто сталкивался с тысячей мелких препятствий (и уже знает направление, как решать) пишет код быстрее того, кто пока не сталкивался. А тот, кто помнит особенности языка (а значит потратил время их изучить) совершает меньше глупых ошибок.

Опыт стоит достаточно много

Нет. Опыт позволяет помнить готовые решения типовых задач, в то же время лишая разработчика возможности/желания подумать над этим ещё раз. Принято считать, что опытный разработчик by default лучше неопытного, хотя когда спрашиваешь, почему, то получаешь в ответ абстрактное «ну он сталкивался с кучей проблем и знает их решение». Только google тоже знает их решение, единственный важный показатель для разработчика — способность создавать (не брать готовое) решение, не зависит от его опыта. Кому нужны динозавры со своими 1000000 лет опыта на делфи?
Опыт позволяет помнить готовые решения типовых задач, в то же время лишая разработчика возможности/желания подумать над этим ещё раз.

Тоже нет. Опыт позволяет абстрагироваться от деталей конкретной задачи, выделяя общее с теми задачами, которые ты уже решал. Чем больше задач решено — тем лучше и точнее можно сформировать абстракцию, тем точнее будет понимание что в задаче важно, а что нет. Что в свою очередь позволяет выбрать наиболее правильный из известных подходов (которые тоже изучаются в том числе из-за того что сталкиваешься с ними на практике).

думаю, он имеет ввиду часть опыт вне «скилла» (умения). то что вы сказали можно отнести к умению.

Нельзя отделять одно от другого. Равно как и нельзя поставить === между этими понятиями. Эти вещи коррелируют, но не имеют прямой зависимости.
Мне нравится такая формула:


опыт       = количество_опыта * качество_опыта
умение     =        интеллект * талант
навык      =             опыт * умение
полезность =            навык * мотивация

Формула ваша, или откуда-то взята? В любом случае — действительно, интересное наблюдение и, IMHO, похоже на правду.

Формула моя. Я использовал ее при разработке игры, которой уже никогда не увидеть свет.

Что есть талант?

Некоторый "врожденный" коэффициент предрасположенности к чему либо.

Нет врожденных коэффициентов, есть только опыт. Другой вопрос как опыт был набран.

Например талант к музыке может быть у человека, который еще в утробе матери слышал музыку, его мозг смог различить что звуки имеют систему, проявилось любопытство либо какая-то связь между музыкой и кормлением, и мозг мотивированно стал формировать нужные связи для различения звуков. А после рождения и обретения речи «какой талантливый ребенок».

P.S. Это очень-очень грубый и ненаучный пример, просто показательность того, что талант — не предрасположенность, а наработка. Возможно даже в другой области, но благодаря высокому уровню абстрации, доступному мозгу, этот опыт может быть спроецирован на текущую задачу, уже имея готовые подходы к решению.

Ваш пример показывает как это может работать, но никак не доказывает что так и есть. Более того, так как мозг у разных людей разный — это как раз доказано, разный как минимум по объему, то логично предположить что у разных людей лучше работают разные его отделы в разных задачах. Что в свою очередь вполне можно назвать врожденным талантом. Так что более вероятно что вы неправы.

талант — не предрасположенность, а наработка

Попробуйте стать двухметровым бейсболистом за счет наработки, если у вас генетически максимальный рост при рождении метр с кепкой.

Во многих видов спорта вы просто не сможете достичь реальных успехов, если вы имеете неправильную генетику.
Простите, но двухметровый рост это не талант, а габариты.
Еще никого в мире не называли «талантливый верзила», «талантливый дистрофик».

Талант всегда приравнивался к тому, как человек что-то умеет делать, а не какой он внешне.
Талант всегда приравнивался к тому, как человек что-то умеет делать, а не какой он внешне.


Вопрос не в том какой он внешне, важно что человек с ростом в метр не сможет играть в баскетбол в проф. лиге NBA, человек шкаф в плечах не сможет выиграть бег мира на 100 метров, дистрофик не станет чемпионом по боксу, генетический даун не станет чемпионом мира по шахматам и т.д.

То есть мы видим уже определенную генетическую предрасположенность к одному виду деятельности и слабость к другому.

Следовательно, логическое условие:
Нет врожденных коэффициентов, есть только опыт. Другой вопрос как опыт был набран.


Не верно. Врожденные генетические коэффициенты как раз есть и они очень важные для любой деятельности. Можно только спорить насколько влияет генетика, характер и опыт (упорство), но полностью сбрасывать генетику со счетов никак нельзя.
«То есть мы видим уже определенную генетическую предрасположенность к одному виду деятельности и слабость к другому.»

Не так. Человек с любым ростом может гениально играть в баскетбол, например закидывая мячи с неудобных позиций, в полете, прыжке и не глядя. Просто его не пустят играть в какой-то там NBA, где ради шоу и денег талант заменяют ростом и габаритами.
Умение играть в баскетбол определяется количеством выигранных игр и чемпионатов, а в первом приближении — количеством забитых мячей. А не способностью нанести удар с неудобной позиции. И количество забитых мячей при двухметровом росте и равном умении будет больше. Также как боксёр лёгкого веса не выстоит против громадного супертяжа, даже при том, что техника в лёгком весе обычно лучше.
«Умение играть в баскетбол определяется количеством выигранных игр и чемпионатов»

Вот тут я не соглашусь. Умение играть в баскетбол определяется количеством выигранных игр. А не чемпионатов.
Чемпионаты, конкурсы и так далее — если это профессиональные мероприятия, в это вмешивается огромная рука коррупции, политики и интриг. Плюс бюджет. Не каждый гениальный игрок имеет возможность попасть в команду, участвующую в профессиональных чемпионатах.
Не в последнюю очередь, что из-за профессионального подхода, в подобные команды отбирают в том числе и по внешним данным (рост, вес).
Не так. Человек с любым ростом может гениально играть в баскетбол,


Даже если может игроку метрового роста будет играть намного сложнее чем 2 метровому (его банально заблокировать проще и ему сложнее закинуть мяч вблизи). А значит он потратить времени и сил намного больше при том же результате.

Вот вы серьезно утверждаете, что не существует генетических различий между людьми (даже в физических параметрах)?

Любая девушка может стать моделью и победить в конкурсе красоты? Не бывает некрасивых девушек от рождения? Не бывает слабых от рождения людей, которые никогда не смогут попасть в грузчики, десантники, пожарные? Проблемы со здоровьем не бывает генетическими от чего закрыт путь в летчики и космонавты?

Вам любой тренер почти в любом виде спорта скажет, что когда к нему приводят 3-5 летних детей, он может уже 100% сказать у кого нет никаких шансов в профессиональном спорте (именно в этом виде спорта). Это не значит что все виды спорта закрыты, если генетически вам не стать спринтером, вы можете стать марафонцем и наоборот.

Мягко говоря утверждать, что все люди от рождения одинаковые это перечеркивать всю генетику. Да, возможно можно затратим намного больше труда и сил можно достичь успехов больших, чем тот кто от рождения имеет преимущество, но утверждать, что не существует никаких генетических отличий между людьми — очень странно.
«Все люди абсолютно равны и одинаковы» — это нынче повестка либеральной пропаганды
«Все люди абсолютно равны и одинаковы» — это нынче повестка либеральной пропаганды
Давайте тогда уж пруф на цитату.
То, что люди одинаковы, считалось, ЕМНИП, в Советском Союзе. И всех неодинаковых упорно старались подогнать под общий стандарт. Равные возможности декларировались (и только). ИМХО либерализмом это назвать никак нельзя.
Либерализм — за равенство — да (причем с оговорками). Но не за одинаковость (глупо было бы отрицать разницу между высоким и низким человеком, ученым и рабочим на конвейере). Идея в том, чтобы разным людям дать равные возможности. А что каждый конкретный человек будет с ними делать — зависит только от него…
Либералы отрицают физическое и умственное неравенство рас и полов например.
То что негры имеют в среднем ниже iq это «плохое окружение», «всё зависит от воспитания», и подобная чушь
То что негры имеют в среднем ниже iq это «плохое окружение», «всё зависит от воспитания», и подобная чушь

Почему же чушь? Мозг у всех одинаковый. Однако, у алкашей вырастают дети совсем не так, как у обычных людей.
Мозг у всех одинаковый.
Да ладно. Даже у детей с синдромом дауна? На самом деле если бы мозг действительно был у всех одинаковый — это значило бы что мозг развился не в результате естественного отбора, а просто так, причем у всех одновременно и одинаково.
Да ладно. Даже у детей с синдромом дауна?

А при чем здесь заведомо больные люди? Мы говорим о в равной степени здоровых представителях разных рас, социальных слоев и так далее.

На самом деле если бы мозг действительно был у всех одинаковый — это значило бы что мозг развился не в результате естественного отбора, а просто так, причем у всех одновременно и одинаково.

Вы играете с неоднозначностью слова «одинаковый», это скучно.
т.е. вы отрицаете существование различий между расами и полами?
Нет, вы передергиваете.
т.е. вы отрицаете существование различий между расами и полами?

1) Различия несомненно есть, главный вопрос насколько сильные, особенно в том что плохо измеряется (интеллектуальных способностях). Может окажется, что при абсолютно равных условиях обучения и воспитания статистическая разница будет не особо значительной (грубо говоря при равном обучении и условиях из 100 миллионов представителей негроидной расы/женщин будет 30 ученых с мировым именем, от представителей белой расы/мужчие 31)
2) тест iq это как раз чушь, так как он не дает реальных представлений о интеллекте,
3) интеллект это намного более сложная штука, чем показатель умный/не умный. Один хорошо запоминает все подряд, но не может понять азы математики.

Скорость реакции, распознавания образов, социальной адаптации, понимания информации, умении делать выводы, скорость обучения и запоминания, определение мошейнников и лжи и т.п. это все интеллект и он может быть совершенно разным для разных людей.
Т.е. вы готовы отрицать все тесты, все измерения только ради незыблимости вашей теории о «всеобщем равенстве».
Не даун, а «альтернативно одаренный».
Ок, по пункту 1 даю пояснение: дело не в среднем интеллекте, а в разбросе интеллекта. Не знаю, как насчёт негров и белых, но вот разный разброс интеллекта для мужчин и женщин — это факт. То есть даже при одинаковом среднем интеллекте мужчин и женщин мы имеем ситуацию, что среди мужчин тупых и одарённых индивидов больше, чем среди женщин.

Как следствие, если мы возьмём 5-10% процентов самых умных, то подавляющее их большинство будет мужчинами (и, возможно, белыми). Если же 50% самых умных, то мужчин и женщин будет поровну.
Т.е. кости разные, мышцы разные, череп разный, вес мозга разный, форма мозга разная, но вот мозг обязательно должен быть одинаковый вне зависимости от расы и пола.
А что такое «одинаковый» в вашем понимании?
Когда я говорю, что мозг одинаковый, то подразумеваю те параметры, которые позволяют говорить, что и мышцы, и кости тоже одинаковые.
Мышление это не что-то абстрактное и непознаваемое.
Мышление это стандартный физический процесс, напрямую зависящий от физических характеристик органа.
Физически мозг различается, с чего вы решили что мышление при этом не различается?
Т.е. вы готовы отрицать все тесты, все измерения только ради незыблимости вашей теории о «всеобщем равенстве».

Это не моя теория и я не считаю расы равными (особенно, физически), тем не менее IQ известно что плохой тест (его результаты у ученых с мировым именем могут быть значительно ниже чем у домохозяек).

Для 100% ответа о различии рас нужно проводить сложный социальный элемент когда дети разных рас и полов воспитываются абсолютно одинаково и после этого измеряются их интеллектуальные характеристики в разных задачах.
Такого эксперимента никто не проводит, все остальная статистика страдает от того что дети растут в разных условиях и не может 100% дать ответ насколько отличия есть на самом деле.
Обычно статистика строиться на выводах вида «смотрите в шахматы женщины не могут соперничать с мужчинами», при этом забывают, что в шахматную секцию могут приводит 20 мальчиков и 1 девочку. Естественно, статистика будет в пользу мужчин.

Физически мозг различается, с чего вы решили что мышление при этом не различается?

Мышление различается несомненно, но в какую сторону? Может, наоборот, женщины/чернокожие умнее в каких-то ситуациях?

З.Ы. Я не приверженец теории всеобщего равенства, просто все текущие измерения не могут быть реально точными.
Для 100% ответа о различии рас нужно проводить сложный социальный элемент когда дети разных рас и полов воспитываются абсолютно одинаково и после этого измеряются их интеллектуальные характеристики в разных задачах.
Такого эксперимента никто не проводит,

Сейчас не проводит, так как это запрещает sjw сообщество.

В 1915 году, доктор Г.В.Ферфусон взял 1000 школьников в Вирджинии, разделил их на 5 расовых категорий, и проверил их умственной способности. В среднем. Чистокровные негры показали 69.2 % от показателей Белых. Негры на три четверти – 73.0 %. Негры-полуровки – 81.2 %. Негры на одну четверть – 91.8 %. Все эти чернокожие жили как и рассматриваемые чистокровные негры. Их среды обитания и «преимущества» или неудобства были точно такими же.

Занятия, проводимые с идентичными близнецами, воспитанными отдельно в радикально различных средах обеспечивают заключительное доказательство, что полное влияние наследственности превышает влияние среды в отношении приблизительно 3 к 1.

Идеологи пресловутого «равенства» часто обесценивают результаты тестов на I.Q. с оправданием, что они – искусственно подтасованы. Тем не менее, НИКТО, ни Объединенный Негритянский Фонд, ни любая другая пронегретянская организация не оказалась способна разработать тест интеллекта, который показывает одинаковость чернокожих и Белых.

Американские индейцы, которые часто живут в условиях далеко хуже чем американские чернокожие в течение всей жизни, тем не менее постоянно обгоняют их на I.Q. тестах
В 1915 году, доктор Г.В.Ферфусон взял 1000 школьников в Вирджинии

1915 год? Вирджиния? В то время и в том штате рассизм был куда покруче, чем в нацистской Германии, если бы он получил какие-то другие результаты местный Ку-клукс-клан его бы банально повесил.

Ладно, не хочу спорить, слишком оно политизировано. Рассисты вам приведут 100 и 1 довод что только белые люди разумные, а все остальные непонятно кто.
> Ладно, не хочу спорить, слишком оно политизировано. Рассисты вам приведут 100 и 1 довод что только белые люди разумные, а все остальные непонятно кто.

Увы и ах, белые люди не самые умные. Азиаты (китайцы и японцы) умнее белых. А самые умные, как это ни странно — это евреи.
А мышцы и кости тоже не одинаковые. Например от места крепления мышц к кости — зависит возможное развиваемое усилие (больший или меньший рычаг). Также в мышцах разное содержание красных и белых волокон, что естественно влияет на возможности. Скелет тоже имеет свои особенности (объем грудной клетки может влиять на возможный объем потребляемого кислорода в единицу времени, размер скелета влиять на общую массу тела). Гормоны влияют на все это дело в т.ч. Все эти факторы дают разным людям разные способности в разных видах деятельности и все они обусловлены именно наследственностью. Для мозга действуют те же принципы. Удельный объем разных долей мозга, влияние гормонов на нервную деятельность… Тут я далеко не специалист конечно, но тоже уверен что часть этих факторов обусловлена генетически. И естественно что все это влияет на способности человека в разных областях. Т.е. те самые врожденные коэффициенты.
Давайте тогда уж пруф на цитату.
Да пожалуйста. Обратите внимание на формулировку — его уволили не за то, что он сказал, что женщины чем-то отличаются от мужчин, а за то, что он усомнился в том, что они одинаковы (а иначе все эти попытки уравнять количество мужчин и женщин бессмысленны).
То, что люди одинаковы, считалось, ЕМНИП, в Советском Союзе. И всех неодинаковых упорно старались подогнать под общий стандарт.
То, что сейчас происходит в США очень на это похоже. Вплоть до «разговоров на кухне», когда «все всё понимают, но сказать не могут».
Либерализм — это свобода капитала и только. Libero для капитала. Если слушать, что вам гадят в уши, то можно еще много чего придумать про либерализм, но лучше почитать источники.
«Любая девушка может стать моделью и победить в конкурсе красоты?»

Как вы можете гениальность определить внешним видом человека?
Плохой пример. Талант к музыке вполне зависит от генов. Например кто то предрасположен слышать более широкий диапазон частот — кто то более узкий.
На самом деле почти для всего что бы вы не привели — можно будет найти контрпример.
Талант к музыке вполне зависит от генов. Например кто то предрасположен слышать более широкий диапазон частот — кто то более узкий.
Скорее нет, чем да. Позволю себе немного углубиться в тему (на отдельную статью мои наблюдения не тянут, а в комментах — вполне :)).

Слух есть у всех, кроме глухих. Соответственно, голос есть у всех, кроме немых. Априори немузыкальный человек, говорящий «у меня нет слуха» неправ. Если вы такое слышите — легко можете привести контраргумент, спросив: «а если при тебе поют известную песню и фальшивят — ты это слышишь?». В 90% случаях ответ будет «да», что какбэ намекает: со слухом все хорошо.

Так почему же не все люди хорошо поют, хотя имеют и слух, и голос? Все просто: не отработано взаимодействие этих двух служб. Услышать ноту «ля» первой октавы могут все. А вот воспроизвести своим голосовым аппаратом соответствующий звук (440 Гц), т.е. «попасть в ноту» — не все.

Так что поверьте, вопрос исключительно в тренировке, никакого волшебства. На вход принимаем сигнал ухом, на выходе — генерируем звук голосом. И стремимся к совпадению. Кстати, для этой цели можно использовать программы для смартфонов, изначально предназначенные для настройки гитары. Там даже видно — выше или ниже надо звучать.
Вот не надо, например у дочери моей крестной — проблема со слышимостью низких частот. Она часто не слышит что ей говорят, либо слышит частично. Вот такой уродилась. Соответственно ей бы было трудно в музыкальной школе, неправда ли? Да и глухие люди, это разве не отсутствие таланта? А есть еще разные нарушения координации, зрения, слуха, цнс, работы мозга… И все это зависит часто от генов. Вы этим людям тоже скажете что это от отсутствия тренировки?
Глухие люди это не отсутствие таланта. Бетховен.

Не путайте дефекты и талант.
Опередили меня с комментом :) Добавлю еще пять копеек…
Вот не надо, например у дочери моей крестной — проблема со слышимостью низких частот. Она часто не слышит что ей говорят, либо слышит частично.
Наверняка делали исследования — на каких частотах провал и насколько сильный. Если дитё прям очень хочет заниматься музыкой — ничего не мешает подобрать инструмент в слышимом диапазоне. Флейту-пикколо, например.
Но тем не менее это уже препятствие и заставляет потратить больше усилий на достижение результата. К тому же вы сами говорите что «нужно подобрать инструмент», что тоже есть ограничение.
То что способности нет, это конечно неправда. Но в реальности не у всех есть средства(деньги, время) опровергать диагноз «медведь на ухо наступил», этот просто экспертное мнение: «овчинка выделки не стоит». Вы вот как оцениваете соревнование с дельфином в плавании?
Вы вот как оцениваете соревнование с дельфином в плавании?
Некорректная метафора. Вы еще Ахилла и черепаху вспомните.
в реальности не у всех есть средства(деньги, время) опровергать диагноз
Дык это ко всему относится. И к карьере, и к образованию… Нет времени/денег — не учись в школе, не поступай в институт, работай в Маке/сиди на шее у родителей. Все в этой жизни упирается в желание чего-то достичь…
Некорректная метафора. Вы еще Ахилла и черепаху вспомните.


Отчего же некорректная? У людей очевидная генетическая разница с дельфинами и гепардами — и, как ни тренируйся, в плавании-беге их не побить.
Очевидно, что тренировками можно ощутимо улучшить результаты в практически любой сфере деятельности. Но по-моему также достаточно очевидно, что гены дают определенный «потолок», для всех разный.

Но при этом совершенно неясно, отличается ли этот потолок в интеллектуальных сферах деятельности для людей разных рас и разных полов. К примеру количество нобелевских премий и чемпионов мира по шахматам может обуславливаться традициями, а не генами. Последнее наглядно видно по тому, как китайцы начинают осваивать шахматный топ, а евреи напротив его покидают. Приоритеты изменились.

Господа, вы слишком серьезно к этому относитесь.
Это же просто выдуманная формула для тайкуна.
Я не проводил никаких исследований по этому поводу.

способность создавать решение
Предположу, что вы имеете ввиду не типичное ПО.
На моей практике, ПО строится на похожей архитектуре, потому что так видимо проще нанять кучу народу и хоть как то пытаться их заменять друг на друга и заставить работать вместе. Не надо учить всю банду новой архитектуре. За это и платят деньги чаще всего. А поскольку всё похожее, то чем больше опыта тем быстрее разработка в условно типичных случаях.
способность создавать (не брать готовое) решение, не зависит от его опыта.

В реальном мире готовое решение в большинстве случаев будет дешевле и более качественное, чем поделие любителя велосипедов.

Кому нужны динозавры со своими 1000000 лет опыта на делфи?

Кому нужны новички с амбициями, но без опыта?

Готовые решения типовых задач? У вас есть какие-то подтверждения этому утверждению? Опыт — это набор абстракций в голове. Например, вы знаете паттерны проектирования или каждый раз любую мелкую задачу решаете с нуля?


"Сталкивался с кучей проблем" — это понятие абстрактное для тех, кто не сталкивался. Для остальных оно конкретное. Знаешь, как работает менеджер пакетов apt? Можешь начать работать с npm за 5 минут, а не за час. Экономия времени. Знаешь, чем отличается hash и b-tree? В следующий раз выбираешь за пять минут, а не после боевой эксплуатации с проблемами и тормозами. Опять экономия. Таких вещей сотни. Гугл вам на вопрос "hash vs b-tree", конечно, даст ссылку на документацию, но если человек не знает про hash, он даже гуглить не будет.


P.S. да, я смешиваю опыт и знания, потому что они частично взаимозаменяемы.

У меня сложилось впечатление, что вы немного путаете стаж и опыт. Разница, если очень кратно:
стаж: протирание штанов в офисном кресле, решение исключительно типовых задач путём механического копирования найденных решений схожих/подобных задач; развивается только навык слепой печати, да и то не всегда;
опыт: решение задач путём использования головного мозга и имеющихся в этом мозгу знаний для анализа условий и формализации задачи с целью выработки пути решения; анализ имеющихся средств и способов решения для выбора наиболее соответствующего условиям задачи (средств и способов зачастую несколько); собственно решения задачи и, наконец, оформления отчёта о проделанной работе. Финальный пункт также включается в опыт, ибо Вы задачу решаете не только в своё удовольствие, но и, в подавляющем большинстве случаев, для использования Вашего продукта более другими людьми.
Когда вы набираете опыт, мало того, что набирается некоторая база знаний, ещё и мозги развиваются, что весьма важно для решения сложных и трудоёмких задач.

Опыт, помимо прочего, развивает «чуйку».

Ага, когда вроде понимаешь, а словами объяснить не можешь.

Кому нужны динозавры со своими 1000000 лет опыта на делфи?

Если будет выбор кого лучше иметь в команде Java разработчиков — джуна годом использования Java или человека лет 10 разрабатывающего серьезные проекты на дельфи, то при прочих равных я предпочту скорее Дельфийста. Потом что язык и библиотеки это важно, но тайм менеджмент, умение работать самостоятельно и в коллективе, умение учится, знание паттернов/алгоритмов/принципов дизайна, какой код хороший и какой плохой и т.п. намного важнее.


Настоящий синьор с большим опытом на одном языке за считаные недели/месяцы при реальном желании станет, как минимум, твердым мидлом на другом, а вот для начинающего все намного сложнее.

Это зависит от пластичности мозга кандидата. Дело в том, что накопленный опыт может, не способствовать, наоборот, а мешать пониманию новых технологий — это всё индивидуально. И умение учиться у программистов с большим опытом может оказаться хуже.

Например, многие люди, которые годами писали на компилируемых в нативный код языках с ручным управлением памяти, испытывают сильное отторжение от, например, сборщика мусора.

Где-то это правда, но им по крайне мере не нужно объяснять зачем сборщик мусора в принципе нужен. К тому же, горе от ума может быть и у просто опытных программистов на том же языке, которые считают себя слишком крутыми для простых или нудных задач. Термин овер квалификация тоже придумали не просто так.


Но в целом, я бы поставил, что вероятность быстро перейти опытному программисту с одного языка на другой выше, чем джуну резко прыгнуть на мидла или синьора (это практически невозможно меньше чем за несколько лет, ИМХО).

Где-то это правда, но им по крайне мере не нужно объяснять зачем сборщик мусора в принципе нужен.

Как раз наоборот. Им то как раз нужно объяснять, потому что они не понимают или не желают принимать преимущества его использования.

Я по своему опыту скажу: когда после 7 лет программирования на C++ переключился на C# сборщик мусора был сразу воспринят как божественная фича. Поскольку я на своей шкуре ощущал, сколько у нас проблем и багов вылезало из-за неправильной работы с распределением-освобождением памяти.
Вы, наверное, путаете умение мыслить и решать задачу понятно с тыканием мышкой в экран. Я пишу на дельфи и на С#, и на JavaScript под Node.js и т.п. А человек, который знает методы, но не умеет думать или который выучил 100500 бесполезных ненужных никому сейчас «оптимизаций» С в стиле +(a++-c-)-b, мне в команду не нужен.

А при чём тут конкретно Delphi? Если Delphi позволяет адекватно решить поставленную задачу, то почему бы и нет? Это одно. А второе:


единственный важный показатель для разработчика — способность создавать (не брать готовое) решение

Есть такая штука, как время и бюджет проекта. Если они резиновые, можно и пописать велосипеды, конечно. Только зачастую это не так, поэтому обычно адекватный разработчик не будет создавать видимость работы, тратя время и пиля в 100500-ый раз собственный фреймворк или какую-то либу, а для начала поищет в том же Гугле имеющиеся решения, примерит их. И только в том случае, если они ему не подошли (и не по причине «у нас нет времени это изучать, проще запилить своё»), он запрограммит узконаправленное решение.

Я знаю компанию, которая готова много платить динозаврам с 1000000 лет опыта на дельфи. У них сейчас наверное с десяток вакантных позиций.
Я слышал, что программисты на Коболе и Аде сейчас гребут деньги лопатой, потому что их во всём мире единицы, а спрос (для поддержки легаси-кода) ненулевой.

Делфи скоро тоже будет в этой нише :)
Без опыта сложно решать поставленные задачи и разбираться с проблемами, так как совершенно не знаешь с чего начать. И в то время, пока человек без опыта будет безуспешного гуглить, пытаясь найти хоть что-то, о чего можно оттолкнуться, опытный человек уже может решить проблему, причем гораздо изящнее. Опыт — ключевое понятие вообще в нашей жизни. Это приобретение осознанных, пережитых знаний.
У опыта есть свойства: количество и качество, как greabock упоминает в своем комменте.

Количество опыта – это время работы. Месяц, год, два… за это время на пути встречается большое количество проблем, которые как-то решаются.
пример: 3 года работы с Фреймворком Х означает, что разработчик на своем пути столкнулся с множеством проблем. точка.

Качество опыта – это время, потраченное на исследование проблем и их решений.
пример: 3 года работы с Фреймворком Х совершенно не означает, что разработчик получил качественный опыт – он мог гуглить и копипастить «решения» без понимания, что происходит.

Количество опыта позволяет обходить проблемы стороной и быстрой выйти в релиз.
Качество опыта позволяет решать проблемы и повышать качество проекта.

И то и другое свойство очень важно! Чаще всего они важны на разных этапах жизни проекта. Количество необходимо для быстрого запуска, качество – для стабилизации и поддержки после.
Наверное, в каком-то вашем особом мире опыт ничего не стоит.
Только с опытом разработчик будет знать, когда какие подходы применять, когда лучше сделать так, а не иначе. Чувак со скилом 100 только что из универа никогда не будет лучше чем разраб со скилом 90 и опытом лет 10. Точнее будет. Лет через 8.
Ну это если разделять скил и опыт. Так-то опыт обычно в скил перетекает, если человек с мозгом, конечно (тех, кого опыт ничему не учит мы не рассматриваем).
Если у разраба с 8 годами опыта скилл меньше, чем у чувака без опыта, возможно ему стоит подыскать себе местечко на помойке? Какой идиот наймёт этого бездаря?
очевидно вся перепалка в том что вы упомянули скилл и опыт но не дали определения терминам.
По русски скилл это наверное навык, а экспириенс это опыт.
Тем не менее, что такое навык что такое опыт?
Набить руку на кидание дротика, это навык, а что такое опыт? Вроде как память о сделанных ошибках и удачах (достижений)?
Тут всё просто. Уметь писать код — навык. Работать программистом — опыт. То-есть опыт подтверждает только то, что ты занимался разработкой. Он не является доказательством того, что ты — хороший разработчик. Естественно шансы иметь высокий скилл выше, если у тебя большой опыт.Но это только шансы. Не у всех с большим опытом есть хороший навык, это не может и не должно быть значащим параметром. Ведь ничто не мешает человеку десять лет разрабатывать код, оставаясь при этом низкоуровневым разработчиком.

Опыт — это не то, что с тобой происходило (это "прошлое" или "воспоминания"), это то, что ты из этого вынес.


Дурака жизнь не учит — про это. События происходят, а опыт не набирается.

Да, вот только судят о чужом опыте именно исходя из того, что происходит с человеком. Отсюда и мой тезис, что опыт — ничего не стоит, ведь мы не знаем, что человек из этого вынес.
Вероятность существенно больше того, что программист со стажем 8 лет умеет больше чем программист со стажем 1 год.
> что опыт — ничего не стоит, ведь мы не знаем, что человек из этого вынес
Человек вообще без опыта гарантированно ничего не умеет. Величина того что умеют программисты кореллирует с их опытом.
Для этого с людьми общаются. Проводят собеседования, чтобы понять, как много ценного опыта человек получил за свою карьеру. Как он решал проблемы и прочее.
Вы путаете опыт и стаж.
Вы путаете слова.
«Низкоуровневый разработчик» это разработчик, работающий на низком уровне абстракций.
Разработчик драйверов, например.
Судя по всему, вы хотели сказать «низкоквалифицированный разработчик».
Значит, опытные программисты, программируют драйвера, а умелые — сайтики свои клепают :-)
Уметь писать код — навык. Работать программистом — опыт

Это как раз и есть то, что отличает джуниора от мидла, например.


Скилл (навык) есть ничто иное, как знание теории. Да, это хорошо, этого даже может хватить для сертификации, но не более.
Экспириенс (опыт) — это то, что нельзя получить без практики. Без практики нельзя осознать (выучить — можно) принципы разработки ПО, нельзя понять (запомнить — можно) чем и почему плохой код отличается от хорошего.


Вкратце — неважно, какой "размер" у твоего скилла — главное умение им пользоваться. Странно, что это вызывает сомнения

Ведь ничто не мешает человеку десять лет разрабатывать код, оставаясь при этом низкоуровневым разработчиком.

Вы тут единственный раз оказались правы, если человек занимается низкоуровневой разработкой, то ничего ему не мешает продолжать ей заниматься.
Хм, на мой взгляд сильное утверждение.
Именно опыт помогает выбрать оптимальное решение задачи исходя из знаний о удачных и неудачных решений похожих задач в прошлом.
Ну и все таки опыт — это часть скилла. Как вы себе представляете скиллованного человека без опыта?
Вы путаете понятие стажа работы и опыта. Опыт — это очень дорого стоит, возможно даже больше каких-то навыков. А вот по стажу работы о разработчике сказать ничего нельзя.
Вполне могут быть ситуации когда один имеет стаж 8-10 лет разработки, второй 2-3 года, но при этом у второго опыта больше потому что работал с более разнообразными проектами, писал больше кода и на большее количество граблей наступил.
«нет никакой корреляции между опытом и скиллом»

Вообще-то любой скилл развивается практикой, а практика — есть опыт, то есть корреляция просто прямая. Вообще невозможно развить скилл чего-либо без практики.
Во-первых, ваш «скилл» и есть опыт.
Во-вторых, опытный разработчик знает как правильно спроектировать задачу, какими инструментами и технологиями воспользоваться, как их наиболее эффективно использовать, а так же их нюансы и тонкости применения.
Так, ладно. Отчаянная попытка вернуть свою карму: имел ввиду стаж, а не опыт, но до меня не дошло, что остальные люди не знают, что я имею ввиду
Даже в этом случии, выражение

Вообще ничего, нет никакой корреляции между опытом и скиллом


Неверно, так как корреляция это любое статистическое взаимоотношение двух случайных величин отличное от случайного. То есть если величина x = N, то величина y = M c вероятностью p, где p не совсем случайное.

Так как человек с 15 годами в каком-то языке с намного большой вероятностью имеет нужные скиллы, чем человек с 0 годами, то корреляция вполне тут есть.

Если вы имели в виду что 15 лет стажа не гарантия хорошего программиста и реального навыка это правда, с которой, думаю, любой программист согласится.
нет никакой корреляции между опытом и скиллом
fillpackart Поясните что такое опыт, а что такое скилл?
Для вас опыт это количество отработанных лет?

Упс, не та ветка.
Хотел сказать, что кол-во лет в разработке не связанно с умением её вести.
НЛО прилетело и опубликовало эту надпись здесь
Эти головоломки входят в волшебный скилл «умение разбираться в чужом коде». Который приходится применять например в тех случаях, когда:

-нужно в точности повторить поведение дремучего легаси

-нужно выяснить, почему в разных браузерах | компиляторах | версиях баша изделие ведет себя не по спецификации, а по произволу великого Ктулху.

-во всех других случаях, когда необходимо на сто процентов осознать, что тут происходит.

А для языков, которые содержат возможность создания UB, данный скилл необходим (потому что тест на конкретном компиляторе будет невалиден), иначе количество отстреленных конечностей превратит ваш офис в уровень DOOM, на который кто-то забрел с бензопилой.

"выстрелит себе в ногу из бензопилы" отдельный скилл))

А в чем собственно проблема?

Приятно, что все чаще появляются статьи такого рода. Начинается пробуждение индустрии от догматического сна, а значит меньше времени понадобится тратить на дискуссии о целесообразности написания кода на бумажке и прочих «must-have skills».
Просто всё больше писателей кушать хотят и бегут туда, где слышат какой-либо спор. За ними подтягиваются паразиты — реклама, на которую смотрят, кликают, она на радостях писателям платит копейку. Писатели — разносчики паразитов, от них всё чаще появляются статьи.
Спор не рождается на пустом месте, ибо дыма без огня не бывает)
Программист, который следует best practices не станет писать код, где потенциально может возникнуть ошибка компиляции (сложение восьмеричного числа с десятичным), а следовательно он не сталкивается с таким кодом на практике. И даже если в студенческие годы он знал, как отреагирует компилятор на это безобразие, то со временем такое знание благополучно улетучивается из его головы за ненадобностью.
Задачу на знание особенностей языка можно инвертировать: {кусок некомпилируемого кода} — Почему не компилируется? Ведь какая разница какой текст ошибки выбросит компилятор, главное заметить где ошибка.
И даже если в студенческие годы он знал, как отреагирует компилятор на это безобразие, то со временем такое знание благополучно улетучивается из его головы за ненадобностью.
Что значит, что ошибку, которую его коллега, у которого «знание не улетучилось из головы за ненадобностью» увидит «сходу» он будет искать час или неделю — как повезёт.

Делать вывод только на основании подобного теста я бы не стал, но наряду с разными другими — подобный вопрос на собеседовании имеет право на существование.
Не совсем так. Он будет понимать, что код таит в себе потенциальную ошибку, но не будет помнить, что конкретно выведет компилятор. Взять к примеру JS. Если объявить переменную через var и через добавление к свойству объекта window, то они будут вести себя по разному в некоторых ситуациях. Не все знают в чем конкретно будет проявляться эта разница, однако есть рекомендация объявлять глобальные переменные только через var, следуя которой мы гарантированно не столкнемся со «странным» поведением среды исполнения.

Я лишь смотрю на вещи взглядом реалиста. Жизнь человека очень сильно ограничена по времени и на получение знаний нам отведено всего несколько десятков тысяч часов. На что тратить это время — каждый должен решить самостоятельно. Я предпочитаю изучать смежные области, чтобы упростить коммуникацию со специалистами этих направлений. Другие люди предпочитают изучать и держать в голове всякие тонкости компиляторов (которые могут устареть и поменяться в любой момент с выходом новой версии языка).

Кто из нас инвестирует свое время более мудро — покажет лишь время и уровень дохода в старости)
Ревью и юнит-тесты решают подобные проблемы.
Не решают. Для того, чтобы на review проблема была замечена нужно, чтобы его проводил человек, могущий получить футболку на соответствующем контесте — а откуда ему взяться если мы отказываемся такие вопросы задавать «за ненадобностью»?

Тесты подобное отловят тоже только если про подобного рода проблема знал их соcтавитель или ревьюер.

Вы правы говоря о том, что ревью и тесты снижают «остроту проблему» — но они отнюдь не делают подобное знание бессмысленным!
Для того, чтобы на review проблема была замечена нужно, чтобы его проводил человек, могущий
Нет же. Если я вижу, что кусок кода мне не очевиден, прошу его упростить. Мне не нужно знать, что там конкретно там происходит.
Серьёзно? Вы ринетесь упрощать кусок кода типа:
  enum ProcessingLevels {
    MinimalProcessing = 001,
    SmallProceassing  = 015,
    FullProcessing    = 123
  };

Да вы это даже не заметите, если у вас нет знания о том, что нуль в начале числа — это восьмеричная система! Ну выровнял автор константы — где тут криминал?
Здесь — возможно. Хотя, это как-то слишком элементарно.
Я говорю о всяких хаках i+++++i
Первая картинка: 5 — ничего из вышеперечисленного.
Какой то класс Sum, со статическим методом мейн (был бы class Main можно было бы предположить что восьмеричное число скоадывается с десятичным).
Так вот, нигде не видно что вызывается метод main из класса Sum. Поэтому — 5
Какой «правильный» ответ?

А в чем проблема именно класса Sum? В java можно в любой класс засунуть метод main и выполнить его.

Да, но на первой картинке его никто не вызывает.
Не знаю как в Java, но в C# статический метод Main является точкой входа. Когда запускаешь exe файл, то именно данный метод отрабатывает.

Всё почти так же. В качестве Main класса можно указать любой класс, содержащий статический метод main(). Можно иметь несколько точек входа

Есть важное отличие: при сборке C# программы вы явно указываете точку входа. Всегда. При сборке программы на Java это возможно в некоторых случаях, но практически почти никогда не используется — она указывается при запуске программы в 99% случаев.

Что вы подразумеваете под сборкой программы на яве? Jar? Там необходимо указывать точку входа. Или вы "сборку" кучки .class-файлов имеете в виду? Так это не программа на яве в 99% случаев, а, в лучшем случае, запуск девелоперской версии внутри ide. Так что в 99% случаев ява-программы точка входа указывается явно.

Я не слишком хорошо знаком с миром Java-разработки, но разве не приложения под Android/ какие-то серверные штуки являются основной частью? Standalone Jar я так понимаю не слишком часто встречаются.


Там необходимо указывать точку входа.

Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запуска

Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запуска
Это не так важно. Важно, что есть ещё куча тестов — и я ещё не видел никого, кто собирал бы их в отдельные JAR'ы с указанием «главного» класса.

Вот если бы avost сказал «99% программистов на Java собирали хоть раз JAR с указанием главного класса», то я бы согласился. Но ведь подавляющее большинство программ, которые они создают — не таковы.
Его вызывает строка «Каким будет результат выполнения следующего кода».
Можно, но для этого надо изменить строку запуска.
Строка запуска не указана: поэтому я считаю её стандартной, а при стандартной метод Sum::main не вызовется.

Вы говорите загадками, о какой «стандартной строке запуска» речь?
Более стандартную строку, чем java Sum вряд ли можно придумать, а она именно что будет искать класс Sum, затем метод main() в нём и вызывать последний.

У меня такой индусский код был на сессии, до сих пор гадаю, это была подготовка к неадекватным собеседованиям или просто некомпетентность лектора.
Кто знает, может лектор тех, кто делает ему замечания отправляет на собеседования в компании, а потом получает от них бонусы.

первая задача — вполне себе достойная задача для собеседования разработчика с некоторым опытом. На понимание того, как работает компилятор/ява машина.
Причем важен не только и не столько правильный ответ, а именно то, как человек будет решать данную задачу.
Вот я, ни разу не ява-разработчик, вижу следующие подводные камни: число начинается с нуля, сколько встречался с языками программирования — восьмеричная система счисления, второе — десятичное. Отсюда вопрос — умеет ли ява складывать два числа в разных системах счисления, и если да, то проверяется пониманию соискателем преобразования чисел между системами счисления.

А какое отношение имеет форма записи константы в исходнике к внутреннему представлению чисел при вычислении?

Я повторю, вдруг не видно было:


Причем важен не только и не столько правильный ответ, а именно то, как человек будет решать данную задачу.

Комментарий. Задача из разряда посмотреть, как человек думает. Без вариантов ответов будет лучше, наверное.

Я тоже повторю:
// Число 41 в десятичной системе
int v1 = 41;
//  Число 41 в шестнадцатеричной системе
int v2 = 0x29;
// Число 41 в восьмеричной системе счисления
int v3 = 051;
// Число 41 в двоичной системе
int v3 = 0b101001;

При этом переменные v1, v2, v3, v4 будут представлены в памяти абсолютно одинаково, и если человек задается вопросом
умеет ли ява складывать два числа в разных системах счисления
то как бы он не рассуждал, его уровень знаний, даже не конкретно Java, а вообще в области компьютеров, оставляет желать лучшего.
Какая разница в каком виде представленно одно и то же число?..

Забыл обновить комменты -____-
Может там разные представления и разные числа?
В Java с 0 какие числа начинаются, десятичные?
Десятичное 123 и восьмеричное 123, это разные числа.
Так же как десятичное 10 и двоичное 10, это десять и два.
а в каких языках 0 является ключевым словом, говорящим о том, что число в другой системе счисления?
А вот C# обижать не надо. Если бы там от наличия 0 в константе менялась бы система счисления было бы очень печально.
Ва лучше скажите где 0 не используется подобным способом. Из распространённых языков, которые «на слуху» — разве что Pascal (Delphi) и разные диалекты Lisp'а (хотя можно ли их считать распространёнными?). А так… C и C++, Java и Javascript, PHP и Python, Ruby и даже Bash (это не совсем язык программирования, но 0123 там обозначет там тоже 83). Странный вопрос…
Pascal, C#, SQL, Rust…

В любом случае, это очень странное решение, которое корнями наверняка в «потому что так в С». Префиксы 0х, 0b и так далее понятны. То, что число начинаясь с 0 должно менять основание — нифига не понятно и нарушает логику. Собственно несколько языков из перечня, которые я привел выше, об этом и говорят. Тот же C#/Rust я считаю намного более ортогональным, чем C/Java/JS, а решения их LDT — более вписывающимися в человеческую логику. Так что да, там 0 таким образом НЕ используется и после 7 лет разработки я впервые услышал, что есть языки, где это не так.
Так что да, там 0 таким образом НЕ используется и после 7 лет разработки я впервые услышал, что есть языки, где это не так.
Серьёзно? А как так получилось, что вы ни JavaScript, ни C не используете, но используете C# и Rust? Что вы такое, чёрт побери, пишите?
Ну на JS я не очень много разрабатывал, всякие простые куски на jquery/bootstrap/redux и там 0123 писать не приходилось.

Ну а на беке C#/SQL, раст просто ковырял.

С не использую. В универе один семестр винапи и еще один ассемблера, там как-то тоже больше шестнадцатеричные константы использовались.
> C и C++, Java и Javascript, PHP и Python

В Python это запретили при переходе на 3-ю версию. Для избавления от проблемы при переносе кода там сейчас префикс 0 вообще недопустим — синтаксическая ошибка. Явный префикс восьмеричной — 0o.
В Swift тоже 0o.
Есть языки, где вообще другая система знаков (например, Erlang — надо писать 8#123, 16#7b).

Так что процесс идёт в верном направлении — хоть и слишком медленно.
> то проверяется пониманию соискателем преобразования чисел между системами счисления.

Я бы сказал чуть иначе — ответ (умение преобразовывать) не самое главное, главное — включится ли у кандидата «тревожная лампочка» при виде этого кода. Если он скажет в первые несколько секунд «ой, восьмеричка, зачем мне это <допустимое в обществе грубое ругательство>?» — цель уже достигнута, а пересчитывать 0123 в более привычное — можно и на калькулятор возложить. Возможен другой вариант реакции, главное, что он заметил «подставу».

> сколько встречался с языками программирования — восьмеричная система счисления

К счастью, эта диверсионная черта встречается далеко не всегда, и в новых языках стараются от неё отказываться.

Вооот! Спасибо Вам за комментарий, у меня как-то не получилось эту мысль донести, растёкся по древу. :)

НЛО прилетело и опубликовало эту надпись здесь
К сожалению, такие штуки начинают использовать повсеместно для отсева кандидатов при приёме на работу или сертификации.

К сожалению, это ваше утверждение эквивалентно утверждению, что 78.6% числовых данных в интернет-статьях берутся с потолка.


Вот ещё одна задачка, с которой вы можете столкнуться

Этот пример ещё более надуманный. Скажите, вы реально с такими примерами сталкивались? И именно "повсеместно"? Можете привести хотя бы десяток компаний на собеседованиях с которыми давались такие задачки?
Мой опыт показывает ровно обратное. Мало того, что подобные задачи вообще никогда не предлагались, так ещё замечаю неуклонный рост культуры собеседований (нет, не повсеместный — мне далеко до подобных обобщений, только в тех компаниях, с которыми доводилось пообщаться).


System.out.println(0123 + 3210)
Но в что проверяется в вышеприведённом примере? Знание очень специфической ситуации, которая возникает при определённых параметрах.

Как задачка для стенда, эта задачка исключительно хороша. Отсеивает совсем уж халявщиков :). А что проверяется… Проверяется умение видеть и оценивать не только очевидные ветки развития событий, но и крайне странные граничные. Очень полезно, например, при многопоточном программировании. Нет, это не совет пользоваться этим примером, это ответ на вопрос :).


Это специфическое использование, которое в любом случае я запретил бы использовать в своих проектах по той же причине: это исключительная ситуация! А я не хочу, чтобы в моём коде встречались такие ситуации.

Неа. Это наглядный пример того, как можно выстрелить себе в ногу на ровном, казалось бы месте и повод задуматься о том, что совы не то чем они кажутся думать надо глубже, чем просто прямолинейно.

НЛО прилетело и опубликовало эту надпись здесь
Самое смешное, разумеется — тип void у возвращаемого test.
Самое смешное, разумеется — тип void у возвращаемого test.

А что именно вы нашли смешным? Вполне обычный Java метод, это же не void get().


Скажите, какой скилл проверяет этот вопрос?

Знание правил перезагрузки Java методов (то есть основы языка Java), помню несколько случаев когда это приводило к хитрым багам, когда управление ушло не в тот метод, что ты ожидал (например, всякие ассерты в юнит тестам, которые неожиданно оказывались неравны хотя визуально с обоих сторон вроде бы одно и тоже число). В качестве разминочного вопроса про язык — нормально, ИМХО.

НЛО прилетело и опубликовало эту надпись здесь
всякие ассерты в юнит тестам, которые неожиданно оказывались неравны хотя визуально с обоих сторон вроде бы одно и тоже число
можно текст теста демонстрирующего такое поведение?
Ну, например
   // Где-то глубоко в нашем коде
   private int getInt() {
        return 2;
    }
    private short getShort() {
        return 2;
    }

   // В юнит тестах
   assertEquals("все пропало!", getInt(), getShort());


Вопрос на засыпку, что вернет тест изначально и что случится если мы поменяем int getInt() на Integer getInt(), а если еще и short getShort() на Short getShort()?

Нет, это неправильные тесты и так писать не нужно, но когда работаешь с чужими тестами такое бывает, что всего-то поменял примитив на обертку и у тебя легло пара сотен тестов проекта.

Знание как именно Java перегружает методы — позволяет предсказать такое поведение и никогда не писать сравнения int c short в ассертах.
а assertTrue(getInt() == getShort()) даст тот же результат, что и assertEquals во всех этих случаях или будут расхождения?
Мне в реальной практике встречались похожие ситуации. Где было у класса два метода, например

void doSome(Class1 obj) {
...
}

void doSome(Class2 obj) {
...
}



И в результате где-то не отследили и на вход doSome() пришел null. Причем система от этого не упала, а глюки вылезли намного позже. И надо понять, какой конкретно код выполнился.
НЛО прилетело и опубликовало эту надпись здесь
Сейчас было немного больше времени, вспомнил, какая была ситуация. Немного не такая, но близка к этой. Вот смотрите, следующий код:
public class Test {

	static class Foo { 
	}
	
	static class Bar {
	}
	
	public static void doSome(Foo foo) {
		System.out.println("foo");
	}

	public static void doSome(Bar bar) {
		System.out.println("bar");
	}

	public static void doSome(Object obj) {
		System.out.println("Object");
	}

	public static void main(String[] args) {
		Object a;
		a = new Foo();	//тут пришли какие-то данные
		doSome(a);
	}
}


То есть попытка сделать универсальный вызов, который бы сам обрабатывал данные в зависимости от их типа. Думаешь, что тут должно вывестись «foo». А вот фиг, выведется «Object»…
Этот пример ещё более надуманный. Скажите, вы реально с такими примерами сталкивались?
Мне при приеме на предыдущую работу задали вопрос какой по умолчанию capacity у класса List. Очень полезное знание, помогало прям все четыре года работы там.
Как задачка для стенда, эта задачка исключительно хороша. Отсеивает совсем уж халявщиков :)

Если организаторы стенда не заинтересованы в наплыве халявщиков, то для чего они раздают на своём стенде халяву?
Многие комментаторы, видимо, упускают, что проблема может быть шире. То, что в ИТ большУю ценность «приписывают» решателям таких вот задачек, несмотря на сомнительную практическую полезность подобных способностей, означает лишь, что это выгодно бизнесу. Выгодно существование подобной искаженной картины ценностей относительно программистов, например. Это не поломаная логика, конечно способность приносить пользу и решать головоломки — навыки разные. Но где-то нужно именно это. Например, чтобы красиво оправдыть ЗП в 1.5 раза выше средней — а-ля «просто у нас работают одни гении, и дело вовсе не в монополии в какой-то области». Ну или другие маркетинговые причины.
Что с этим делать — совсем третий вопрос. Индивидуальный. Важно вначале успокоиться, принять факт, что мир несовершенен. Что есть — то есть.
Вообще говоря, у таких викторин могут быть совсем другие, не очевидные на первый взгляд причины. Например, клиентов хотят привлечь подарками или шансом выиграть какой-нибудь айпэд, но в стране законодательно запрещено устраивать «бесплатные» лотереи — от участников требуется сперва сознательно решить какую-то, пусть и очень простую задачу. Так обстоят дела в Австрии.
Действительно, можно писать код не держа все это в голове, не заглядывая в документацию и читая StackOverflow где все подробно расписано. Но код в результате будет писаться много медленнее и намного менее надежный.
Говоря же о викторинах на выставках — цель там скорее привлечь внимание и выдать приз тем кто соображает лучше.
Чтобы писать хороший код к сожалению действительно надо знать много прямо из головы здесь и сейчас. Плюс есть проблема — я не знаю того чего я не знаю.
В конце концов специально для тренировки ответов на такие вопросы есть сайт skillotron.com — и вот что интересно — люди которые там находятся в топе по любой из технологий почему сплошь достаточно матерые надежные синьеры, а вот как раз джунов там не видно. С чего бы это?
Ох, надо им туда вопросов по C++ покидать, из SO language-lawyer.
В конце концов специально для тренировки ответов на такие вопросы есть сайт skillotron.com — и вот что интересно — люди которые там находятся в топе по любой из технологий почему сплошь достаточно матерые надежные синьеры, а вот как раз джунов там не видно. С чего бы это?
Ну не знаю. Только что для интереса прошел полный набор тестов по питону, вообще без гугла и какой либо помощи. Занял 41 место в рейтинге. Да, это далеко не топ, но загвоздка в том что я за всю свою жизнь написал лишь несколько строк на питоне (правил плагин для саблайма), и никогда его не учил, лишь натыкался в интернете. Кто все эти люди которых я обошел?
Те люди которых вы обошли примерно такие же :-)
Заняли 41-ое место по питону я так думаю потому, что 1) хороший программист 2) питон достаточно «прямой» язык и в нем часто «как слышится, так и пишется»
Ну и там всего людей в питоне не много может быть не больше сотни.
питон достаточно «прямой» язык и в нем часто «как слышится, так и пишется»
Вопросов которые попали бы под эту категорию там не так и много. Большую часть правильных я вывел либо из знаний Lua, либо просто интуитивно угадал. Больше всего проблем было с вопросами типа «что питон делает, когда сталкиваются логически несвязные типы».
Ну и там всего людей в питоне не много может быть не больше сотни
Я между тестами пока набирал баллы один раз был за 150+.
Если вам нужно написать книгу, кого вы возьмете, того кто уже писал книгу или человека который в совершенстве владеет грамматикой языка? Смешно, да? А на деле, для крупных заказчиков важен сертификат.

У нас сениоров заставляли сдавать сетификат по яве, так они выли от бессмысленности вопросов. «В какой последовательности можно ставить слова в public static void main ()», помню мне коллега жаловался. «Я, — говорит, — последний раз писал main() восемь лет назад, в универе»
Если вам нужно написать книгу, кого вы возьмете, того кто уже писал книгу или человека который в совершенстве владеет грамматикой языка?
Другой конец этой палки — соискатель, заявляет что участвовал в десятке проектов, но не может ответить на совсем элементарные вопросы, не может словами описать, не говоря уж про то чтоб написать на бумажке, как бы он реализовывал простейший алгоритм. Был качественный перец, заявляющий, что работает архитектором ERP системы в каком то госучреждении, который не смог сказать, что такое interface и с чем его едят.

Истина где то посередине, видимо.
Истина где то посередине, видимо.
Истина зависит от того какую книгу вам нужно писать. Если «роман в стихах» — то нужно брать поэта, ничего не попишешь.

Если «руководство пользователя» — то лучше «человека который в совершенстве владеет грамматикой языка», так как поэт может быть несколько не курсах оной грамматики (ему можно, в стихах это обычно прощается, там другие критерии) и ваше «руководство пользователя» будет выглядеть безграмотно…
После института попал на собеседование, первое в моей жизни. До этого писал небольшие проекты, обычно сам и крайне скептически относился к всякого рода тестам с «дурацкими задачками». На собеседовании мне начали давать «ребусы-загадки на С++» с вопросом «а что будет?». Я мягко говоря опешил, кое как ответил на часть, где-то удивился, что так можно, но лучше не стоит. Потом сказал, что такой код нельзя писать. С грустной улыбкой мне ответили, что такой код на самом деле не пишут.
Теперь я знаю, что все гораздо абстрактнее и объемнее. И главное, сколько боли может сделать вполне логичный, невинный код, но никакой дебагер не может помочь.

На некоторых курсах я оцениваю студентов, давая им задание: разработать очень маленькое приложение. Задание даётся в виде спецификаций, как принято в мире бизнес-аналитики.
А можно пример задания?

По сабжу — а умение алгоритмизировать сейчас уже не проверяют? В стародавние времена учитель программирования в школе раздавал люлей тем вундеркиндам, которые сразу начинали писать код, не составив предварительно блок-схему. Лично я считаю это правильным. А вы?
Сейчас считаете что программу, которую можно написать за 45 минут можно (и нужно!) сразу писать «набело».

Блок-схемы — это при проектировании больших систем, которые закодить на интервью не получится.

Можно провести два интервью — на одном довести до кода маленькую задачку, на другом — поговорить о (но не писать код… разве что примеры) — большуо.

Во всех инженерных областях одни и те же проблемы) Пример из машиностроения — требования знать нормы ЕСКД к чертежам досконально, хотя для изложения конструкции на ватмане скорее всего и не нужно это. И корреляция между репутацией инженера и знанием документации очень мутная. Хотя мы все стремимся быть образованными людьми — значит необходимо постоянно узнавать!

Соглашусь в части головоломок. Их, конечно, можно задать на собеседовании. Но мы же не берем сотрудника для решения головоломок. Мы нанимаем для решения задач. Вот и дайте ему несколько небольших задач. В них может быть как чтение когда, его анализ, предложения по доработке, фиксу багов, так и работа с базами, написание в схематическом виде запросов, небольшое проектирование, так и вопросы по принципам работы с партнерами, их api и т.д. В общем, все то, чем предстоит заниматься разработчику в схематической, короткой форме.
Еще пришло в голову: характер вопросов / задачек на интервью больше говорит о компании и ее ценностях, чем о кандидате. У кого-то в почете сферические кони в вакууме для собственного успокоения или соревнований у кого (мысль) длиннее. А кому-то важно, чтобы на встречу приходили вовремя и код писался ДО дедлайна, хоть с костылями, хоть с велосипедами, хоть копи-паст…
Так что вполне себе решение — прийти, получить идиотскую задачку, посмеяться и попрощаться.
ЗЫ Однажды на вопрос к присланному собеседовать спецу почему мы пишем код на доске получил простой ответ: «Я вообще-то не с этого проекта/отдела, но мне надо же как-то кандидатов оценивать. Ато в резюме все такое пишут...» Так вот, бывает.
(isYouCompiler)&(isYouVirtualMachine)&(isYouSoftwareArchitect)&(isYouDataScientist)?You=ForwardLookingSeniorDeveloper: You=ImmortalJunior
Первая и вторая задачи — совершенно разные.
Первая — отличная задачка на соображалку, вторая — на тупое запоминание документации.
Не совсем так. Она, на самом деле — тоже, в основном, на соображалку. Начнём с того, что правильных ответов там не один, а два. Потому что javax.servlet.http.HttpServlet — это варинт javax.servlet.GenericServlet и, стало быть, у него не может быть только методов с HttpServletRequest'ом. Вариант с ServletRequest'ом обязан быть тоже. И он, как раз — будет публичным. И ничего не будет возвращать (тип void), у него ж целый ServletResponse в аргументах есть!

А второй вариант — уже защищённый service(HttpServletRequest req, HttpServletResponse resp).З

В общем — в этом классе всё логично и до всего можно дойти «исходя из логики». Ничего «тупо запоминать не нужно». Запоминать нужно там, где нелогично…
Для меня это выглядит как «надстройка», дополнительная задача, тогда как основная — знание библиотеки. Вещи вроде «javax.servlet.GenericServlet и, стало быть, у него не может быть только методов с HttpServletRequest'ом» — как раз оно самое. Сугубо imho.
Для меня это выглядит как «надстройка», дополнительная задача, тогда как основная — знание библиотеки.
Несомненно. Но вам не нужно знать библиотеку во всех подробностях, чтобы уметь отвечать на подобные вопросы. Если вы её использовали — то, скорее всего, ответите. Если совсем нет… ну тут понятно.

Просто это не «тупое зубрилово» тоже и в самом вопросе — половина ответа. Вторую половину — таки надо знать, да.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории