Comments 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) интеллект это намного более сложная штука, чем показатель умный/не умный. Один хорошо запоминает все подряд, но не может понять азы математики.
Скорость реакции, распознавания образов, социальной адаптации, понимания информации, умении делать выводы, скорость обучения и запоминания, определение мошейнников и лжи и т.п. это все интеллект и он может быть совершенно разным для разных людей.
Не даун, а «альтернативно одаренный».
Как следствие, если мы возьмём 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 довод что только белые люди разумные, а все остальные непонятно кто.
Давайте тогда уж пруф на цитату.Да пожалуйста. Обратите внимание на формулировку — его уволили не за то, что он сказал, что женщины чем-то отличаются от мужчин, а за то, что он усомнился в том, что они одинаковы (а иначе все эти попытки уравнять количество мужчин и женщин бессмысленны).
То, что люди одинаковы, считалось, ЕМНИП, в Советском Союзе. И всех неодинаковых упорно старались подогнать под общий стандарт.То, что сейчас происходит в США очень на это похоже. Вплоть до «разговоров на кухне», когда «все всё понимают, но сказать не могут».
Как вы можете гениальность определить внешним видом человека?
На самом деле почти для всего что бы вы не привели — можно будет найти контрпример.
Талант к музыке вполне зависит от генов. Например кто то предрасположен слышать более широкий диапазон частот — кто то более узкий.Скорее нет, чем да. Позволю себе немного углубиться в тему (на отдельную статью мои наблюдения не тянут, а в комментах — вполне :)).
Слух есть у всех, кроме глухих. Соответственно, голос есть у всех, кроме немых. Априори немузыкальный человек, говорящий «у меня нет слуха» неправ. Если вы такое слышите — легко можете привести контраргумент, спросив: «а если при тебе поют известную песню и фальшивят — ты это слышишь?». В 90% случаях ответ будет «да», что какбэ намекает: со слухом все хорошо.
Так почему же не все люди хорошо поют, хотя имеют и слух, и голос? Все просто: не отработано взаимодействие этих двух служб. Услышать ноту «ля» первой октавы могут все. А вот воспроизвести своим голосовым аппаратом соответствующий звук (440 Гц), т.е. «попасть в ноту» — не все.
Так что поверьте, вопрос исключительно в тренировке, никакого волшебства. На вход принимаем сигнал ухом, на выходе — генерируем звук голосом. И стремимся к совпадению. Кстати, для этой цели можно использовать программы для смартфонов, изначально предназначенные для настройки гитары. Там даже видно — выше или ниже надо звучать.
Не путайте дефекты и талант.
Вот не надо, например у дочери моей крестной — проблема со слышимостью низких частот. Она часто не слышит что ей говорят, либо слышит частично.Наверняка делали исследования — на каких частотах провал и насколько сильный. Если дитё прям очень хочет заниматься музыкой — ничего не мешает подобрать инструмент в слышимом диапазоне. Флейту-пикколо, например.
Вы вот как оцениваете соревнование с дельфином в плавании?Некорректная метафора. Вы еще Ахилла и черепаху вспомните.
в реальности не у всех есть средства(деньги, время) опровергать диагнозДык это ко всему относится. И к карьере, и к образованию… Нет времени/денег — не учись в школе, не поступай в институт, работай в Маке/сиди на шее у родителей. Все в этой жизни упирается в желание чего-то достичь…
Некорректная метафора. Вы еще Ахилла и черепаху вспомните.
Отчего же некорректная? У людей очевидная генетическая разница с дельфинами и гепардами — и, как ни тренируйся, в плавании-беге их не побить.
Очевидно, что тренировками можно ощутимо улучшить результаты в практически любой сфере деятельности. Но по-моему также достаточно очевидно, что гены дают определенный «потолок», для всех разный.
Но при этом совершенно неясно, отличается ли этот потолок в интеллектуальных сферах деятельности для людей разных рас и разных полов. К примеру количество нобелевских премий и чемпионов мира по шахматам может обуславливаться традициями, а не генами. Последнее наглядно видно по тому, как китайцы начинают осваивать шахматный топ, а евреи напротив его покидают. Приоритеты изменились.
Господа, вы слишком серьезно к этому относитесь.
Это же просто выдуманная формула для тайкуна.
Я не проводил никаких исследований по этому поводу.
способность создавать решениеПредположу, что вы имеете ввиду не типичное ПО.
На моей практике, ПО строится на похожей архитектуре, потому что так видимо проще нанять кучу народу и хоть как то пытаться их заменять друг на друга и заставить работать вместе. Не надо учить всю банду новой архитектуре. За это и платят деньги чаще всего. А поскольку всё похожее, то чем больше опыта тем быстрее разработка в условно типичных случаях.
способность создавать (не брать готовое) решение, не зависит от его опыта.
В реальном мире готовое решение в большинстве случаев будет дешевле и более качественное, чем поделие любителя велосипедов.
Кому нужны динозавры со своими 1000000 лет опыта на делфи?
Кому нужны новички с амбициями, но без опыта?
Готовые решения типовых задач? У вас есть какие-то подтверждения этому утверждению? Опыт — это набор абстракций в голове. Например, вы знаете паттерны проектирования или каждый раз любую мелкую задачу решаете с нуля?
"Сталкивался с кучей проблем" — это понятие абстрактное для тех, кто не сталкивался. Для остальных оно конкретное. Знаешь, как работает менеджер пакетов apt? Можешь начать работать с npm за 5 минут, а не за час. Экономия времени. Знаешь, чем отличается hash и b-tree? В следующий раз выбираешь за пять минут, а не после боевой эксплуатации с проблемами и тормозами. Опять экономия. Таких вещей сотни. Гугл вам на вопрос "hash vs b-tree", конечно, даст ссылку на документацию, но если человек не знает про hash, он даже гуглить не будет.
P.S. да, я смешиваю опыт и знания, потому что они частично взаимозаменяемы.
У меня сложилось впечатление, что вы немного путаете стаж и опыт. Разница, если очень кратно:
стаж: протирание штанов в офисном кресле, решение исключительно типовых задач путём механического копирования найденных решений схожих/подобных задач; развивается только навык слепой печати, да и то не всегда;
опыт: решение задач путём использования головного мозга и имеющихся в этом мозгу знаний для анализа условий и формализации задачи с целью выработки пути решения; анализ имеющихся средств и способов решения для выбора наиболее соответствующего условиям задачи (средств и способов зачастую несколько); собственно решения задачи и, наконец, оформления отчёта о проделанной работе. Финальный пункт также включается в опыт, ибо Вы задачу решаете не только в своё удовольствие, но и, в подавляющем большинстве случаев, для использования Вашего продукта более другими людьми.
Когда вы набираете опыт, мало того, что набирается некоторая база знаний, ещё и мозги развиваются, что весьма важно для решения сложных и трудоёмких задач.
Кому нужны динозавры со своими 1000000 лет опыта на делфи?
Если будет выбор кого лучше иметь в команде Java разработчиков — джуна годом использования Java или человека лет 10 разрабатывающего серьезные проекты на дельфи, то при прочих равных я предпочту скорее Дельфийста. Потом что язык и библиотеки это важно, но тайм менеджмент, умение работать самостоятельно и в коллективе, умение учится, знание паттернов/алгоритмов/принципов дизайна, какой код хороший и какой плохой и т.п. намного важнее.
Настоящий синьор с большим опытом на одном языке за считаные недели/месяцы при реальном желании станет, как минимум, твердым мидлом на другом, а вот для начинающего все намного сложнее.
Например, многие люди, которые годами писали на компилируемых в нативный код языках с ручным управлением памяти, испытывают сильное отторжение от, например, сборщика мусора.
Где-то это правда, но им по крайне мере не нужно объяснять зачем сборщик мусора в принципе нужен. К тому же, горе от ума может быть и у просто опытных программистов на том же языке, которые считают себя слишком крутыми для простых или нудных задач. Термин овер квалификация тоже придумали не просто так.
Но в целом, я бы поставил, что вероятность быстро перейти опытному программисту с одного языка на другой выше, чем джуну резко прыгнуть на мидла или синьора (это практически невозможно меньше чем за несколько лет, ИМХО).
Где-то это правда, но им по крайне мере не нужно объяснять зачем сборщик мусора в принципе нужен.
Как раз наоборот. Им то как раз нужно объяснять, потому что они не понимают или не желают принимать преимущества его использования.
А при чём тут конкретно Delphi? Если Delphi позволяет адекватно решить поставленную задачу, то почему бы и нет? Это одно. А второе:
единственный важный показатель для разработчика — способность создавать (не брать готовое) решение
Есть такая штука, как время и бюджет проекта. Если они резиновые, можно и пописать велосипеды, конечно. Только зачастую это не так, поэтому обычно адекватный разработчик не будет создавать видимость работы, тратя время и пиля в 100500-ый раз собственный фреймворк или какую-то либу, а для начала поищет в том же Гугле имеющиеся решения, примерит их. И только в том случае, если они ему не подошли (и не по причине «у нас нет времени это изучать, проще запилить своё»), он запрограммит узконаправленное решение.
Количество опыта – это время работы. Месяц, год, два… за это время на пути встречается большое количество проблем, которые как-то решаются.
пример: 3 года работы с Фреймворком Х означает, что разработчик на своем пути столкнулся с множеством проблем. точка.
Качество опыта – это время, потраченное на исследование проблем и их решений.
пример: 3 года работы с Фреймворком Х совершенно не означает, что разработчик получил качественный опыт – он мог гуглить и копипастить «решения» без понимания, что происходит.
Количество опыта позволяет обходить проблемы стороной и быстрой выйти в релиз.
Качество опыта позволяет решать проблемы и повышать качество проекта.
И то и другое свойство очень важно! Чаще всего они важны на разных этапах жизни проекта. Количество необходимо для быстрого запуска, качество – для стабилизации и поддержки после.
Только с опытом разработчик будет знать, когда какие подходы применять, когда лучше сделать так, а не иначе. Чувак со скилом 100 только что из универа никогда не будет лучше чем разраб со скилом 90 и опытом лет 10. Точнее будет. Лет через 8.
Ну это если разделять скил и опыт. Так-то опыт обычно в скил перетекает, если человек с мозгом, конечно (тех, кого опыт ничему не учит мы не рассматриваем).
По русски скилл это наверное навык, а экспириенс это опыт.
Тем не менее, что такое навык что такое опыт?
Набить руку на кидание дротика, это навык, а что такое опыт? Вроде как память о сделанных ошибках и удачах (достижений)?
Опыт — это не то, что с тобой происходило (это "прошлое" или "воспоминания"), это то, что ты из этого вынес.
Дурака жизнь не учит — про это. События происходят, а опыт не набирается.
Человек вообще без опыта гарантированно ничего не умеет. Величина того что умеют программисты кореллирует с их опытом.
«Низкоуровневый разработчик» это разработчик, работающий на низком уровне абстракций.
Разработчик драйверов, например.
Судя по всему, вы хотели сказать «низкоквалифицированный разработчик».
Уметь писать код — навык. Работать программистом — опыт
Это как раз и есть то, что отличает джуниора от мидла, например.
Скилл (навык) есть ничто иное, как знание теории. Да, это хорошо, этого даже может хватить для сертификации, но не более.
Экспириенс (опыт) — это то, что нельзя получить без практики. Без практики нельзя осознать (выучить — можно) принципы разработки ПО, нельзя понять (запомнить — можно) чем и почему плохой код отличается от хорошего.
Вкратце — неважно, какой "размер" у твоего скилла — главное умение им пользоваться. Странно, что это вызывает сомнения
Ведь ничто не мешает человеку десять лет разрабатывать код, оставаясь при этом низкоуровневым разработчиком.
Вы тут единственный раз оказались правы, если человек занимается низкоуровневой разработкой, то ничего ему не мешает продолжать ей заниматься.
Именно опыт помогает выбрать оптимальное решение задачи исходя из знаний о удачных и неудачных решений похожих задач в прошлом.
Ну и все таки опыт — это часть скилла. Как вы себе представляете скиллованного человека без опыта?
Вполне могут быть ситуации когда один имеет стаж 8-10 лет разработки, второй 2-3 года, но при этом у второго опыта больше потому что работал с более разнообразными проектами, писал больше кода и на большее количество граблей наступил.
Вообще-то любой скилл развивается практикой, а практика — есть опыт, то есть корреляция просто прямая. Вообще невозможно развить скилл чего-либо без практики.
Во-вторых, опытный разработчик знает как правильно спроектировать задачу, какими инструментами и технологиями воспользоваться, как их наиболее эффективно использовать, а так же их нюансы и тонкости применения.
Вообще ничего, нет никакой корреляции между опытом и скиллом
Неверно, так как корреляция это любое статистическое взаимоотношение двух случайных величин отличное от случайного. То есть если величина x = N, то величина y = M c вероятностью p, где p не совсем случайное.
Так как человек с 15 годами в каком-то языке с намного большой вероятностью имеет нужные скиллы, чем человек с 0 годами, то корреляция вполне тут есть.
Если вы имели в виду что 15 лет стажа не гарантия хорошего программиста и реального навыка это правда, с которой, думаю, любой программист согласится.
нет никакой корреляции между опытом и скилломfillpackart Поясните что такое опыт, а что такое скилл?
Для вас опыт это количество отработанных лет?
Упс, не та ветка.
-нужно в точности повторить поведение дремучего легаси
-нужно выяснить, почему в разных браузерах | компиляторах | версиях баша изделие ведет себя не по спецификации, а по произволу великого Ктулху.
-во всех других случаях, когда необходимо на сто процентов осознать, что тут происходит.
А для языков, которые содержат возможность создания UB, данный скилл необходим (потому что тест на конкретном компиляторе будет невалиден), иначе количество отстреленных конечностей превратит ваш офис в уровень DOOM, на который кто-то забрел с бензопилой.
Программист, который следует best practices не станет писать код, где потенциально может возникнуть ошибка компиляции (сложение восьмеричного числа с десятичным), а следовательно он не сталкивается с таким кодом на практике. И даже если в студенческие годы он знал, как отреагирует компилятор на это безобразие, то со временем такое знание благополучно улетучивается из его головы за ненадобностью.
И даже если в студенческие годы он знал, как отреагирует компилятор на это безобразие, то со временем такое знание благополучно улетучивается из его головы за ненадобностью.Что значит, что ошибку, которую его коллега, у которого «знание не улетучилось из головы за ненадобностью» увидит «сходу» он будет искать час или неделю — как повезёт.
Делать вывод только на основании подобного теста я бы не стал, но наряду с разными другими — подобный вопрос на собеседовании имеет право на существование.
Я лишь смотрю на вещи взглядом реалиста. Жизнь человека очень сильно ограничена по времени и на получение знаний нам отведено всего несколько десятков тысяч часов. На что тратить это время — каждый должен решить самостоятельно. Я предпочитаю изучать смежные области, чтобы упростить коммуникацию со специалистами этих направлений. Другие люди предпочитают изучать и держать в голове всякие тонкости компиляторов (которые могут устареть и поменяться в любой момент с выходом новой версии языка).
Кто из нас инвестирует свое время более мудро — покажет лишь время и уровень дохода в старости)
Тесты подобное отловят тоже только если про подобного рода проблема знал их соcтавитель или ревьюер.
Вы правы говоря о том, что ревью и тесты снижают «остроту проблему» — но они отнюдь не делают подобное знание бессмысленным!
Для того, чтобы на review проблема была замечена нужно, чтобы его проводил человек, могущийНет же. Если я вижу, что кусок кода мне не очевиден, прошу его упростить. Мне не нужно знать, что там конкретно там происходит.
enum ProcessingLevels {
MinimalProcessing = 001,
SmallProceassing = 015,
FullProcessing = 123
};
Да вы это даже не заметите, если у вас нет знания о том, что нуль в начале числа — это восьмеричная система! Ну выровнял автор константы — где тут криминал?
Какой то класс Sum, со статическим методом мейн (был бы class Main можно было бы предположить что восьмеричное число скоадывается с десятичным).
Так вот, нигде не видно что вызывается метод main из класса Sum. Поэтому — 5
Какой «правильный» ответ?
А в чем проблема именно класса Sum? В java можно в любой класс засунуть метод main и выполнить его.
Всё почти так же. В качестве Main класса можно указать любой класс, содержащий статический метод main(). Можно иметь несколько точек входа
Что вы подразумеваете под сборкой программы на яве? Jar? Там необходимо указывать точку входа. Или вы "сборку" кучки .class-файлов имеете в виду? Так это не программа на яве в 99% случаев, а, в лучшем случае, запуск девелоперской версии внутри ide. Так что в 99% случаев ява-программы точка входа указывается явно.
Я не слишком хорошо знаком с миром Java-разработки, но разве не приложения под Android/ какие-то серверные штуки являются основной частью? Standalone Jar я так понимаю не слишком часто встречаются.
Там необходимо указывать точку входа.
Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запуска
Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запускаЭто не так важно. Важно, что есть ещё куча тестов — и я ещё не видел никого, кто собирал бы их в отдельные JAR'ы с указанием «главного» класса.
Вот если бы avost сказал «99% программистов на Java собирали хоть раз JAR с указанием главного класса», то я бы согласился. Но ведь подавляющее большинство программ, которые они создают — не таковы.
Строка запуска не указана: поэтому я считаю её стандартной, а при стандартной метод 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х, 0b и так далее понятны. То, что число начинаясь с 0 должно менять основание — нифига не понятно и нарушает логику. Собственно несколько языков из перечня, которые я привел выше, об этом и говорят. Тот же C#/Rust я считаю намного более ортогональным, чем C/Java/JS, а решения их LDT — более вписывающимися в человеческую логику. Так что да, там 0 таким образом НЕ используется и после 7 лет разработки я впервые услышал, что есть языки, где это не так.
Так что да, там 0 таким образом НЕ используется и после 7 лет разработки я впервые услышал, что есть языки, где это не так.Серьёзно? А как так получилось, что вы ни JavaScript, ни C не используете, но используете C# и Rust? Что вы такое, чёрт побери, пишите?
В Python это запретили при переходе на 3-ю версию. Для избавления от проблемы при переносе кода там сейчас префикс 0 вообще недопустим — синтаксическая ошибка. Явный префикс восьмеричной — 0o.
В Swift тоже 0o.
Есть языки, где вообще другая система знаков (например, Erlang — надо писать 8#123, 16#7b).
Так что процесс идёт в верном направлении — хоть и слишком медленно.
Я бы сказал чуть иначе — ответ (умение преобразовывать) не самое главное, главное — включится ли у кандидата «тревожная лампочка» при виде этого кода. Если он скажет в первые несколько секунд «ой, восьмеричка, зачем мне это <допустимое в обществе грубое ругательство>?» — цель уже достигнута, а пересчитывать 0123 в более привычное — можно и на калькулятор возложить. Возможен другой вариант реакции, главное, что он заметил «подставу».
> сколько встречался с языками программирования — восьмеричная система счисления
К счастью, эта диверсионная черта встречается далеко не всегда, и в новых языках стараются от неё отказываться.
К сожалению, такие штуки начинают использовать повсеместно для отсева кандидатов при приёме на работу или сертификации.
К сожалению, это ваше утверждение эквивалентно утверждению, что 78.6% числовых данных в интернет-статьях берутся с потолка.
Вот ещё одна задачка, с которой вы можете столкнуться
Этот пример ещё более надуманный. Скажите, вы реально с такими примерами сталкивались? И именно "повсеместно"? Можете привести хотя бы десяток компаний на собеседованиях с которыми давались такие задачки?
Мой опыт показывает ровно обратное. Мало того, что подобные задачи вообще никогда не предлагались, так ещё замечаю неуклонный рост культуры собеседований (нет, не повсеместный — мне далеко до подобных обобщений, только в тех компаниях, с которыми доводилось пообщаться).
System.out.println(0123 + 3210)
Но в что проверяется в вышеприведённом примере? Знание очень специфической ситуации, которая возникает при определённых параметрах.
Как задачка для стенда, эта задачка исключительно хороша. Отсеивает совсем уж халявщиков :). А что проверяется… Проверяется умение видеть и оценивать не только очевидные ветки развития событий, но и крайне странные граничные. Очень полезно, например, при многопоточном программировании. Нет, это не совет пользоваться этим примером, это ответ на вопрос :).
Это специфическое использование, которое в любом случае я запретил бы использовать в своих проектах по той же причине: это исключительная ситуация! А я не хочу, чтобы в моём коде встречались такие ситуации.
Неа. Это наглядный пример того, как можно выстрелить себе в ногу на ровном, казалось бы месте и повод задуматься о том, что совы не то чем они кажутся думать надо глубже, чем просто прямолинейно.
Самое смешное, разумеется — тип 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 в ассертах.
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. Очень полезное знание, помогало прям все четыре года работы там.
Как задачка для стенда, эта задачка исключительно хороша. Отсеивает совсем уж халявщиков :)
Если организаторы стенда не заинтересованы в наплыве халявщиков, то для чего они раздают на своём стенде халяву?
Что с этим делать — совсем третий вопрос. Индивидуальный. Важно вначале успокоиться, принять факт, что мир несовершенен. Что есть — то есть.
Говоря же о викторинах на выставках — цель там скорее привлечь внимание и выдать приз тем кто соображает лучше.
Чтобы писать хороший код к сожалению действительно надо знать много прямо из головы здесь и сейчас. Плюс есть проблема — я не знаю того чего я не знаю.
В конце концов специально для тренировки ответов на такие вопросы есть сайт skillotron.com — и вот что интересно — люди которые там находятся в топе по любой из технологий почему сплошь достаточно матерые надежные синьеры, а вот как раз джунов там не видно. С чего бы это?
В конце концов специально для тренировки ответов на такие вопросы есть сайт skillotron.com — и вот что интересно — люди которые там находятся в топе по любой из технологий почему сплошь достаточно матерые надежные синьеры, а вот как раз джунов там не видно. С чего бы это?Ну не знаю. Только что для интереса прошел полный набор тестов по питону, вообще без гугла и какой либо помощи. Занял 41 место в рейтинге. Да, это далеко не топ, но загвоздка в том что я за всю свою жизнь написал лишь несколько строк на питоне (правил плагин для саблайма), и никогда его не учил, лишь натыкался в интернете. Кто все эти люди которых я обошел?
Заняли 41-ое место по питону я так думаю потому, что 1) хороший программист 2) питон достаточно «прямой» язык и в нем часто «как слышится, так и пишется»
Ну и там всего людей в питоне не много может быть не больше сотни.
питон достаточно «прямой» язык и в нем часто «как слышится, так и пишется»Вопросов которые попали бы под эту категорию там не так и много. Большую часть правильных я вывел либо из знаний Lua, либо просто интуитивно угадал. Больше всего проблем было с вопросами типа «что питон делает, когда сталкиваются логически несвязные типы».
Ну и там всего людей в питоне не много может быть не больше сотниЯ между тестами пока набирал баллы один раз был за 150+.
У нас сениоров заставляли сдавать сетификат по яве, так они выли от бессмысленности вопросов. «В какой последовательности можно ставить слова в public static void main ()», помню мне коллега жаловался. «Я, — говорит, — последний раз писал main() восемь лет назад, в универе»
Если вам нужно написать книгу, кого вы возьмете, того кто уже писал книгу или человека который в совершенстве владеет грамматикой языка?Другой конец этой палки — соискатель, заявляет что участвовал в десятке проектов, но не может ответить на совсем элементарные вопросы, не может словами описать, не говоря уж про то чтоб написать на бумажке, как бы он реализовывал простейший алгоритм. Был качественный перец, заявляющий, что работает архитектором ERP системы в каком то госучреждении, который не смог сказать, что такое interface и с чем его едят.
Истина где то посередине, видимо.
Истина где то посередине, видимо.Истина зависит от того какую книгу вам нужно писать. Если «роман в стихах» — то нужно брать поэта, ничего не попишешь.
Если «руководство пользователя» — то лучше «человека который в совершенстве владеет грамматикой языка», так как поэт может быть несколько не курсах оной грамматики (ему можно, в стихах это обычно прощается, там другие критерии) и ваше «руководство пользователя» будет выглядеть безграмотно…
Теперь я знаю, что все гораздо абстрактнее и объемнее. И главное, сколько боли может сделать вполне логичный, невинный код, но никакой дебагер не может помочь.
На некоторых курсах я оцениваю студентов, давая им задание: разработать очень маленькое приложение. Задание даётся в виде спецификаций, как принято в мире бизнес-аналитики.А можно пример задания?
По сабжу — а умение алгоритмизировать сейчас уже не проверяют? В стародавние времена учитель программирования в школе раздавал люлей тем вундеркиндам, которые сразу начинали писать код, не составив предварительно блок-схему. Лично я считаю это правильным. А вы?
Блок-схемы — это при проектировании больших систем, которые закодить на интервью не получится.
Можно провести два интервью — на одном довести до кода маленькую задачку, на другом — поговорить о (но не писать код… разве что примеры) — большуо.
Во всех инженерных областях одни и те же проблемы) Пример из машиностроения — требования знать нормы ЕСКД к чертежам досконально, хотя для изложения конструкции на ватмане скорее всего и не нужно это. И корреляция между репутацией инженера и знанием документации очень мутная. Хотя мы все стремимся быть образованными людьми — значит необходимо постоянно узнавать!
Так что вполне себе решение — прийти, получить идиотскую задачку, посмеяться и попрощаться.
ЗЫ Однажды на вопрос к присланному собеседовать спецу почему мы пишем код на доске получил простой ответ: «Я вообще-то не с этого проекта/отдела, но мне надо же как-то кандидатов оценивать. Ато в резюме все такое пишут...» Так вот, бывает.
Первая — отличная задачка на соображалку, вторая — на тупое запоминание документации.
А второй вариант — уже защищённый service(HttpServletRequest req, HttpServletResponse resp).З
В общем — в этом классе всё логично и до всего можно дойти «исходя из логики». Ничего «тупо запоминать не нужно». Запоминать нужно там, где нелогично…
Для меня это выглядит как «надстройка», дополнительная задача, тогда как основная — знание библиотеки.Несомненно. Но вам не нужно знать библиотеку во всех подробностях, чтобы уметь отвечать на подобные вопросы. Если вы её использовали — то, скорее всего, ответите. Если совсем нет… ну тут понятно.
Просто это не «тупое зубрилово» тоже и в самом вопросе — половина ответа. Вторую половину — таки надо знать, да.
Ты не компилятор