Невинная головоломка
Некоторые из задач предусматривают решение головоломки с кодом, вроде такой:
Каким будет результат выполнения следующего кода:
public class Sum { public static void main(String[] args) { System.out.println(0123 + 3210); } }
- 3293
- 3333
- Этот код не компилируется
- Этот код приводит к ошибке
IllegalArgumentException- Ничего из вышеперечисленного
Моя обычная реакция — или немедленно покинуть стенд, или, если время позволяет, набрать код на ноутбуке, чтобы посмотреть результат (или поискать в Google). Вы можете упрекнуть меня в лености, но я предпочитаю представлять себя экспертом по тайм-менеджменту.
Просто, но бесполезно
Единственное преимущество такого подхода — оценить ответы может любой, если у него есть правильные ответы. И это всё.
Кроме этого, такого рода головоломки ни о чём не говорят. Это не было бы проблемой, если бы подобные задачки не выходили за пределы выставочных стендов как «забавные» игры. К сожалению, такие штуки начинают использовать повсеместно для отсева кандидатов при приёме на работу или сертификации.
В обоих случаях следует оценить способности, а наиболее простым решением видят как раз тест-опросник с несколькими вариантами ответа. Конечно, если у человека нет доступа к IDE или Google, то это становится трудной задачей. Но что проверяется в вышеприведённом примере? Знание очень специфической ситуации, которая возникает при определённых параметрах. Это специфическое использование, которое в любом случае я запретил бы использовать в своих проектах по той же причине: это исключительная ситуация! А я не хочу, чтобы в моём коде встречались такие ситуации.
Другой пример
Вот ещё одна задачка, с которой вы можете столкнуться:
Какова корректная сигнатура методаservice()в классеjavax.servlet.http.HttpServlet?
public void service(ServletRequest, ServletResponse)public void service(HttpServletRequest, HttpServletResponse)public int service(ServletRequest, ServletResponse)public int service(HttpServletRequest, HttpServletResponse)protected void service(ServletRequest, ServletResponse)protected void service(HttpServletRequest, HttpServletResponse)protected int service(ServletRequest, ServletResponse)protected int service(HttpServletRequest, HttpServletResponse)
Такие вопросы не проверяют ничего, кроме способности запомнить часть функциональности основных IDE или документации JavaDoc.
Примечание. На самом деле полное название это статьи должно быть «Ты не компилятор, не среда выполнения и не документация».
Ключевая проблема
Нет ни единого доказательства положительной корреляции между правильными ответами на вышеприведённые вопросы и реальным умением применить способности, которые должны оценивать эти тесты. Существует ли альтернатива? Да. Не нужно проверять незначительные фрагменты знаний, а следует проверить именно то, что вы хотите оценить, при тех же условиях, включая IDE, документацию, Google и проч.
- Хотите оценить, как кандидат справляется с чтением кода? Дайте ему прочитать свой собственный код — или похожий код, если ваш секретный.
- Хотите оценить, как кандидат пишет код? Дайте ему написать код, например, пофиксить уже исправленный баг.
То же самое относится к сертификации.
Конечно, недостаток такого решения в том, что оно требует времени. Времени для подготовки материала. Времени для анализа результатов. Времени для собеседования.
Осуществимо ли такое? К сожалению тех, кто считает это утопией, такая система уже существует. Наилучший пример — Java EE Enterprise Architect. Хотя на первом этапе нужно пройти тест с несколькими вариантами ответа, другие этапы предусматривают выполнение заданий как в настоящем проекте и написание соответствующего эссе.
Другой пример более личный. Я работаю лектором в ряде высших учебных заведений. На некоторых курсах я оцениваю студентов, давая им задание: разработать очень маленькое приложение. Задание даётся в виде спецификаций, как принято в мире бизнес-аналитики.
Вывод
Ради блага нашей индустрии, давайте прекратим притворяться, что головоломки имеют какую-то ценность кроме как забавные задачки для развлечения с коллегами. Нам нужно больше думать о последствиях приёма на работу плохого профессионала, чем о времени, которое мы тратим на оценку способностей кандидата. Есть же альтернативы, используйте их. Или разгребайте последствия.
Комментарии (142)
Varim
31.08.2017 12:20+2нет никакой корреляции между опытом и скиллом
fillpackart Поясните что такое опыт, а что такое скилл?
Для вас опыт это количество отработанных лет?
Упс, не та ветка.
fillpackart
31.08.2017 12:50-10Хотел сказать, что кол-во лет в разработке не связанно с умением её вести.
balexa
31.08.2017 19:19+4Количество лет в разработке и опыт — это разные вещи, не путайте.
Можно иметь стаж 10 лет и не иметь большого опыта, тут вы правы. Но нельзя получить хоть какой-то опыт, не имея стажа.
gbg
31.08.2017 13:20+4Эти головоломки входят в волшебный скилл «умение разбираться в чужом коде». Который приходится применять например в тех случаях, когда:
-нужно в точности повторить поведение дремучего легаси
-нужно выяснить, почему в разных браузерах | компиляторах | версиях баша изделие ведет себя не по спецификации, а по произволу великого Ктулху.
-во всех других случаях, когда необходимо на сто процентов осознать, что тут происходит.
А для языков, которые содержат возможность создания UB, данный скилл необходим (потому что тест на конкретном компиляторе будет невалиден), иначе количество отстреленных конечностей превратит ваш офис в уровень DOOM, на который кто-то забрел с бензопилой.mSnus
31.08.2017 16:11+3"выстрелит себе в ногу из бензопилы" отдельный скилл))
gbg
31.08.2017 16:17+4А в чем собственно проблема?
pm_wanderer
31.08.2017 13:33+1Приятно, что все чаще появляются статьи такого рода. Начинается пробуждение индустрии от догматического сна, а значит меньше времени понадобится тратить на дискуссии о целесообразности написания кода на бумажке и прочих «must-have skills».
spmbt
31.08.2017 14:23+3Просто всё больше писателей кушать хотят и бегут туда, где слышат какой-либо спор. За ними подтягиваются паразиты — реклама, на которую смотрят, кликают, она на радостях писателям платит копейку. Писатели — разносчики паразитов, от них всё чаще появляются статьи.
pm_wanderer
31.08.2017 16:26Спор не рождается на пустом месте, ибо дыма без огня не бывает)
Программист, который следует best practices не станет писать код, где потенциально может возникнуть ошибка компиляции (сложение восьмеричного числа с десятичным), а следовательно он не сталкивается с таким кодом на практике. И даже если в студенческие годы он знал, как отреагирует компилятор на это безобразие, то со временем такое знание благополучно улетучивается из его головы за ненадобностью.
SADM
31.08.2017 18:34Задачу на знание особенностей языка можно инвертировать: {кусок некомпилируемого кода} — Почему не компилируется? Ведь какая разница какой текст ошибки выбросит компилятор, главное заметить где ошибка.
khim
01.09.2017 01:23+1И даже если в студенческие годы он знал, как отреагирует компилятор на это безобразие, то со временем такое знание благополучно улетучивается из его головы за ненадобностью.
Что значит, что ошибку, которую его коллега, у которого «знание не улетучилось из головы за ненадобностью» увидит «сходу» он будет искать час или неделю — как повезёт.
Делать вывод только на основании подобного теста я бы не стал, но наряду с разными другими — подобный вопрос на собеседовании имеет право на существование.pm_wanderer
01.09.2017 07:40-1Не совсем так. Он будет понимать, что код таит в себе потенциальную ошибку, но не будет помнить, что конкретно выведет компилятор. Взять к примеру JS. Если объявить переменную через var и через добавление к свойству объекта window, то они будут вести себя по разному в некоторых ситуациях. Не все знают в чем конкретно будет проявляться эта разница, однако есть рекомендация объявлять глобальные переменные только через var, следуя которой мы гарантированно не столкнемся со «странным» поведением среды исполнения.
Я лишь смотрю на вещи взглядом реалиста. Жизнь человека очень сильно ограничена по времени и на получение знаний нам отведено всего несколько десятков тысяч часов. На что тратить это время — каждый должен решить самостоятельно. Я предпочитаю изучать смежные области, чтобы упростить коммуникацию со специалистами этих направлений. Другие люди предпочитают изучать и держать в голове всякие тонкости компиляторов (которые могут устареть и поменяться в любой момент с выходом новой версии языка).
Кто из нас инвестирует свое время более мудро — покажет лишь время и уровень дохода в старости)
Free_ze
01.09.2017 11:47Ревью и юнит-тесты решают подобные проблемы.
khim
01.09.2017 13:55Не решают. Для того, чтобы на review проблема была замечена нужно, чтобы его проводил человек, могущий получить футболку на соответствующем контесте — а откуда ему взяться если мы отказываемся такие вопросы задавать «за ненадобностью»?
Тесты подобное отловят тоже только если про подобного рода проблема знал их соcтавитель или ревьюер.
Вы правы говоря о том, что ревью и тесты снижают «остроту проблему» — но они отнюдь не делают подобное знание бессмысленным!Free_ze
01.09.2017 14:03Для того, чтобы на review проблема была замечена нужно, чтобы его проводил человек, могущий
Нет же. Если я вижу, что кусок кода мне не очевиден, прошу его упростить. Мне не нужно знать, что там конкретно там происходит.khim
01.09.2017 14:10Серьёзно? Вы ринетесь упрощать кусок кода типа:
enum ProcessingLevels { MinimalProcessing = 001, SmallProceassing = 015, FullProcessing = 123 };
Да вы это даже не заметите, если у вас нет знания о том, что нуль в начале числа — это восьмеричная система! Ну выровнял автор константы — где тут криминал?Free_ze
01.09.2017 15:06Здесь — возможно. Хотя, это как-то слишком элементарно.
Я говорю о всяких хаках i+++++i
shushu
31.08.2017 13:47-6Первая картинка: 5 — ничего из вышеперечисленного.
Какой то класс Sum, со статическим методом мейн (был бы class Main можно было бы предположить что восьмеричное число скоадывается с десятичным).
Так вот, нигде не видно что вызывается метод main из класса Sum. Поэтому — 5
Какой «правильный» ответ?
soon
31.08.2017 15:30+2А в чем проблема именно класса Sum? В java можно в любой класс засунуть метод main и выполнить его.
sets
31.08.2017 16:28-1Да, но на первой картинке его никто не вызывает.
AlexNis
31.08.2017 17:06Не знаю как в Java, но в C# статический метод Main является точкой входа. Когда запускаешь exe файл, то именно данный метод отрабатывает.
Ritan
31.08.2017 19:30+1Всё почти так же. В качестве Main класса можно указать любой класс, содержащий статический метод main(). Можно иметь несколько точек входа
khim
01.09.2017 08:57Есть важное отличие: при сборке C# программы вы явно указываете точку входа. Всегда. При сборке программы на Java это возможно в некоторых случаях, но практически почти никогда не используется — она указывается при запуске программы в 99% случаев.
avost
02.09.2017 23:13Что вы подразумеваете под сборкой программы на яве? Jar? Там необходимо указывать точку входа. Или вы "сборку" кучки .class-файлов имеете в виду? Так это не программа на яве в 99% случаев, а, в лучшем случае, запуск девелоперской версии внутри ide. Так что в 99% случаев ява-программы точка входа указывается явно.
Ritan
05.09.2017 12:40Я не слишком хорошо знаком с миром Java-разработки, но разве не приложения под Android/ какие-то серверные штуки являются основной частью? Standalone Jar я так понимаю не слишком часто встречаются.
Там необходимо указывать точку входа.
Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запуска
khim
05.09.2017 14:22Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запуска
Это не так важно. Важно, что есть ещё куча тестов — и я ещё не видел никого, кто собирал бы их в отдельные JAR'ы с указанием «главного» класса.
Вот если бы avost сказал «99% программистов на Java собирали хоть раз JAR с указанием главного класса», то я бы согласился. Но ведь подавляющее большинство программ, которые они создают — не таковы.
shushu
01.09.2017 05:47-1Можно, но для этого надо изменить строку запуска.
Строка запуска не указана: поэтому я считаю её стандартной, а при стандартной метод Sum::main не вызовется.
Maccimo
01.09.2017 07:25Вы говорите загадками, о какой «стандартной строке запуска» речь?
Более стандартную строку, чемjava Sumвряд ли можно придумать, а она именно что будет искать классSum, затем методmain()в нём и вызывать последний.
DarthVal
31.08.2017 14:02У меня такой индусский код был на сессии, до сих пор гадаю, это была подготовка к неадекватным собеседованиям или просто некомпетентность лектора.
SADM
31.08.2017 18:57Кто знает, может лектор тех, кто делает ему замечания отправляет на собеседования в компании, а потом получает от них бонусы.
shurutov
31.08.2017 14:02+2первая задача — вполне себе достойная задача для собеседования разработчика с некоторым опытом. На понимание того, как работает компилятор/ява машина.
Причем важен не только и не столько правильный ответ, а именно то, как человек будет решать данную задачу.
Вот я, ни разу не ява-разработчик, вижу следующие подводные камни: число начинается с нуля, сколько встречался с языками программирования — восьмеричная система счисления, второе — десятичное. Отсюда вопрос — умеет ли ява складывать два числа в разных системах счисления, и если да, то проверяется пониманию соискателем преобразования чисел между системами счисления.
Serge78rus
31.08.2017 16:03+3А какое отношение имеет форма записи константы в исходнике к внутреннему представлению чисел при вычислении?
shurutov
31.08.2017 16:51-1Я повторю, вдруг не видно было:
Причем важен не только и не столько правильный ответ, а именно то, как человек будет решать данную задачу.
Комментарий. Задача из разряда посмотреть, как человек думает. Без вариантов ответов будет лучше, наверное.
Serge78rus
31.08.2017 18:27+5Я тоже повторю:
// Число 41 в десятичной системе int v1 = 41; // Число 41 в шестнадцатеричной системе int v2 = 0x29; // Число 41 в восьмеричной системе счисления int v3 = 051; // Число 41 в двоичной системе int v3 = 0b101001;
При этом переменные v1, v2, v3, v4 будут представлены в памяти абсолютно одинаково, и если человек задается вопросом
умеет ли ява складывать два числа в разных системах счисления
то как бы он не рассуждал, его уровень знаний, даже не конкретно Java, а вообще в области компьютеров, оставляет желать лучшего.
Ayahuaska
31.08.2017 16:07+2Какая разница в каком виде представленно одно и то же число?..
Забыл обновить комменты -____-Varim
31.08.2017 16:10-1Может там разные представления и разные числа?
В Java с 0 какие числа начинаются, десятичные?
Десятичное 123 и восьмеричное 123, это разные числа.
Так же как десятичное 10 и двоичное 10, это десять и два.x67
31.08.2017 17:19а в каких языках 0 является ключевым словом, говорящим о том, что число в другой системе счисления?
khim
01.09.2017 01:39+2Ва лучше скажите где 0 не используется подобным способом. Из распространённых языков, которые «на слуху» — разве что Pascal (Delphi) и разные диалекты Lisp'а (хотя можно ли их считать распространёнными?). А так… C и C++, Java и Javascript, PHP и Python, Ruby и даже Bash (это не совсем язык программирования, но 0123 там обозначет там тоже 83). Странный вопрос…
netch80
01.09.2017 09:18> то проверяется пониманию соискателем преобразования чисел между системами счисления.
Я бы сказал чуть иначе — ответ (умение преобразовывать) не самое главное, главное — включится ли у кандидата «тревожная лампочка» при виде этого кода. Если он скажет в первые несколько секунд «ой, восьмеричка, зачем мне это <допустимое в обществе грубое ругательство>?» — цель уже достигнута, а пересчитывать 0123 в более привычное — можно и на калькулятор возложить. Возможен другой вариант реакции, главное, что он заметил «подставу».
> сколько встречался с языками программирования — восьмеричная система счисления
К счастью, эта диверсионная черта встречается далеко не всегда, и в новых языках стараются от неё отказываться.shurutov
01.09.2017 09:55Вооот! Спасибо Вам за комментарий, у меня как-то не получилось эту мысль донести, растёкся по древу. :)
hexploy
31.08.2017 17:06+3Какова корректная сигнатура метода service() в классе javax.servlet.http.HttpServlet?
Действительно плохой вопрос.
1. public void service(ServletRequest, ServletResponse)
...
В сигнатуру метода не входят ни модификаторы доступа, ни возвращаемый резльтат — только имя метода и аргументы (docs.oracle.com)
avost
31.08.2017 17:20+4К сожалению, такие штуки начинают использовать повсеместно для отсева кандидатов при приёме на работу или сертификации.
К сожалению, это ваше утверждение эквивалентно утверждению, что 78.6% числовых данных в интернет-статьях берутся с потолка.
Вот ещё одна задачка, с которой вы можете столкнуться
Этот пример ещё более надуманный. Скажите, вы реально с такими примерами сталкивались? И именно "повсеместно"? Можете привести хотя бы десяток компаний на собеседованиях с которыми давались такие задачки?
Мой опыт показывает ровно обратное. Мало того, что подобные задачи вообще никогда не предлагались, так ещё замечаю неуклонный рост культуры собеседований (нет, не повсеместный — мне далеко до подобных обобщений, только в тех компаниях, с которыми доводилось пообщаться).
System.out.println(0123 + 3210)
Но в что проверяется в вышеприведённом примере? Знание очень специфической ситуации, которая возникает при определённых параметрах.Как задачка для стенда, эта задачка исключительно хороша. Отсеивает совсем уж халявщиков :). А что проверяется… Проверяется умение видеть и оценивать не только очевидные ветки развития событий, но и крайне странные граничные. Очень полезно, например, при многопоточном программировании. Нет, это не совет пользоваться этим примером, это ответ на вопрос :).
Это специфическое использование, которое в любом случае я запретил бы использовать в своих проектах по той же причине: это исключительная ситуация! А я не хочу, чтобы в моём коде встречались такие ситуации.
Неа. Это наглядный пример того, как можно выстрелить себе в ногу на ровном, казалось бы месте и повод задуматься о том, что
совы не то чем они кажутсядумать надо глубже, чем просто прямолинейно.balexa
31.08.2017 19:30Этот пример ещё более надуманный. Скажите, вы реально с такими примерами сталкивались? И именно «повсеместно»? Можете привести хотя бы десяток компаний на собеседованиях с которыми давались такие задачки?
Яндекс деньги, например.
Там меня спрашивали сигнатуры методов апачевского http-клиента. Серьезно, не шучу. Для чего? Я не помню сигнатуры на память, тем более что там с каждой версией все меняется.
И еще какую-то тупую задачу вроде того что вызовется первым при вызове test(0);
Варианты ответов:
- void test(int n);
- void test(long n);
- void test(Long n);
- void test(Integer n);
- void test(Number n);
- void test(Object n);
После выбора правильного ответа, назовите какой бы вызвался следующим, если бы метода с данной сигнатурой не было.
Скажите, какой скилл проверяет этот вопрос? Я вот не знаю. Зато понял зачем мне эти вопросы задавали — чтобы предложить оффер с суммой на треть ниже запрошенной (хотя я и так запросил у яндекса ниже своей обычной суммы).fukkit
31.08.2017 20:51Самое смешное, разумеется — тип void у возвращаемого test.
vedenin1980
31.08.2017 23:44Самое смешное, разумеется — тип void у возвращаемого test.
А что именно вы нашли смешным? Вполне обычный Java метод, это же не void get().
Скажите, какой скилл проверяет этот вопрос?
Знание правил перезагрузки Java методов (то есть основы языка Java), помню несколько случаев когда это приводило к хитрым багам, когда управление ушло не в тот метод, что ты ожидал (например, всякие ассерты в юнит тестам, которые неожиданно оказывались неравны хотя визуально с обоих сторон вроде бы одно и тоже число). В качестве разминочного вопроса про язык — нормально, ИМХО.
balexa
01.09.2017 01:11+1Чтобы такое не приводило к хитрым багам, нужно писать тесты и не нужно писать такие перегруженные методы. А еще внутри они должны иметь идентичную логику (как правило вызывать один приватный либо другой перегруженный метод).
В качестве разминочного вопроса про язык — нормально, ИМХО.
Да как бы проверить что человек не врет что он писал на джаве можно и более простым способом.
VladVR
01.09.2017 08:36всякие ассерты в юнит тестам, которые неожиданно оказывались неравны хотя визуально с обоих сторон вроде бы одно и тоже число
можно текст теста демонстрирующего такое поведение?vedenin1980
01.09.2017 12:12Ну, например
// Где-то глубоко в нашем коде 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 в ассертах.VladVR
02.09.2017 12:05а assertTrue(getInt() == getShort()) даст тот же результат, что и assertEquals во всех этих случаях или будут расхождения?
hssergey
01.09.2017 15:28Мне в реальной практике встречались похожие ситуации. Где было у класса два метода, например
void doSome(Class1 obj) { ... } void doSome(Class2 obj) { ... }
И в результате где-то не отследили и на вход doSome() пришел null. Причем система от этого не упала, а глюки вылезли намного позже. И надо понять, какой конкретно код выполнился.balexa
01.09.2017 18:46И надо понять, какой конкретно код выполнился
Чтобы такого не было, код первого метода должен выглядеть примерно так.
void doSome(Class1 obj) { doSome(convertToClass2(obj)); }
hssergey
01.09.2017 20:50Сейчас было немного больше времени, вспомнил, какая была ситуация. Немного не такая, но близка к этой. Вот смотрите, следующий код:
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»…
VladVR
01.09.2017 00:23+1Этот пример ещё более надуманный. Скажите, вы реально с такими примерами сталкивались?
Мне при приеме на предыдущую работу задали вопрос какой по умолчанию capacity у класса List. Очень полезное знание, помогало прям все четыре года работы там.
tyomitch
01.09.2017 17:19Как задачка для стенда, эта задачка исключительно хороша. Отсеивает совсем уж халявщиков :)
Если организаторы стенда не заинтересованы в наплыве халявщиков, то для чего они раздают на своём стенде халяву?
ogoNEKto
31.08.2017 19:58-1Многие комментаторы, видимо, упускают, что проблема может быть шире. То, что в ИТ большУю ценность «приписывают» решателям таких вот задачек, несмотря на сомнительную практическую полезность подобных способностей, означает лишь, что это выгодно бизнесу. Выгодно существование подобной искаженной картины ценностей относительно программистов, например. Это не поломаная логика, конечно способность приносить пользу и решать головоломки — навыки разные. Но где-то нужно именно это. Например, чтобы красиво оправдыть ЗП в 1.5 раза выше средней — а-ля «просто у нас работают одни гении, и дело вовсе не в монополии в какой-то области». Ну или другие маркетинговые причины.
Что с этим делать — совсем третий вопрос. Индивидуальный. Важно вначале успокоиться, принять факт, что мир несовершенен. Что есть — то есть.
commanderxo
31.08.2017 22:21+2Вообще говоря, у таких викторин могут быть совсем другие, не очевидные на первый взгляд причины. Например, клиентов хотят привлечь подарками или шансом выиграть какой-нибудь айпэд, но в стране законодательно запрещено устраивать «бесплатные» лотереи — от участников требуется сперва сознательно решить какую-то, пусть и очень простую задачу. Так обстоят дела в Австрии.
Semenych
31.08.2017 23:35+1Действительно, можно писать код не держа все это в голове, не заглядывая в документацию и читая StackOverflow где все подробно расписано. Но код в результате будет писаться много медленнее и намного менее надежный.
Говоря же о викторинах на выставках — цель там скорее привлечь внимание и выдать приз тем кто соображает лучше.
Чтобы писать хороший код к сожалению действительно надо знать много прямо из головы здесь и сейчас. Плюс есть проблема — я не знаю того чего я не знаю.
В конце концов специально для тренировки ответов на такие вопросы есть сайт skillotron.com — и вот что интересно — люди которые там находятся в топе по любой из технологий почему сплошь достаточно матерые надежные синьеры, а вот как раз джунов там не видно. С чего бы это?
playermet
02.09.2017 14:48+1В конце концов специально для тренировки ответов на такие вопросы есть сайт skillotron.com — и вот что интересно — люди которые там находятся в топе по любой из технологий почему сплошь достаточно матерые надежные синьеры, а вот как раз джунов там не видно. С чего бы это?
Ну не знаю. Только что для интереса прошел полный набор тестов по питону, вообще без гугла и какой либо помощи. Занял 41 место в рейтинге. Да, это далеко не топ, но загвоздка в том что я за всю свою жизнь написал лишь несколько строк на питоне (правил плагин для саблайма), и никогда его не учил, лишь натыкался в интернете. Кто все эти люди которых я обошел?Semenych
04.09.2017 13:20Те люди которых вы обошли примерно такие же :-)
Заняли 41-ое место по питону я так думаю потому, что 1) хороший программист 2) питон достаточно «прямой» язык и в нем часто «как слышится, так и пишется»
Ну и там всего людей в питоне не много может быть не больше сотни.playermet
05.09.2017 15:59питон достаточно «прямой» язык и в нем часто «как слышится, так и пишется»
Вопросов которые попали бы под эту категорию там не так и много. Большую часть правильных я вывел либо из знаний Lua, либо просто интуитивно угадал. Больше всего проблем было с вопросами типа «что питон делает, когда сталкиваются логически несвязные типы».
Ну и там всего людей в питоне не много может быть не больше сотни
Я между тестами пока набирал баллы один раз был за 150+.
lxsmkv
01.09.2017 02:10+1Если вам нужно написать книгу, кого вы возьмете, того кто уже писал книгу или человека который в совершенстве владеет грамматикой языка? Смешно, да? А на деле, для крупных заказчиков важен сертификат.
У нас сениоров заставляли сдавать сетификат по яве, так они выли от бессмысленности вопросов. «В какой последовательности можно ставить слова в public static void main ()», помню мне коллега жаловался. «Я, — говорит, — последний раз писал main() восемь лет назад, в универе»VladVR
01.09.2017 10:17+1Если вам нужно написать книгу, кого вы возьмете, того кто уже писал книгу или человека который в совершенстве владеет грамматикой языка?
Другой конец этой палки — соискатель, заявляет что участвовал в десятке проектов, но не может ответить на совсем элементарные вопросы, не может словами описать, не говоря уж про то чтоб написать на бумажке, как бы он реализовывал простейший алгоритм. Был качественный перец, заявляющий, что работает архитектором ERP системы в каком то госучреждении, который не смог сказать, что такое interface и с чем его едят.
Истина где то посередине, видимо.khim
01.09.2017 13:59Истина где то посередине, видимо.
Истина зависит от того какую книгу вам нужно писать. Если «роман в стихах» — то нужно брать поэта, ничего не попишешь.
Если «руководство пользователя» — то лучше «человека который в совершенстве владеет грамматикой языка», так как поэт может быть несколько не курсах оной грамматики (ему можно, в стихах это обычно прощается, там другие критерии) и ваше «руководство пользователя» будет выглядеть безграмотно…
mental3d
01.09.2017 08:49После института попал на собеседование, первое в моей жизни. До этого писал небольшие проекты, обычно сам и крайне скептически относился к всякого рода тестам с «дурацкими задачками». На собеседовании мне начали давать «ребусы-загадки на С++» с вопросом «а что будет?». Я мягко говоря опешил, кое как ответил на часть, где-то удивился, что так можно, но лучше не стоит. Потом сказал, что такой код нельзя писать. С грустной улыбкой мне ответили, что такой код на самом деле не пишут.
Теперь я знаю, что все гораздо абстрактнее и объемнее. И главное, сколько боли может сделать вполне логичный, невинный код, но никакой дебагер не может помочь.
Markscheider
01.09.2017 09:40На некоторых курсах я оцениваю студентов, давая им задание: разработать очень маленькое приложение. Задание даётся в виде спецификаций, как принято в мире бизнес-аналитики.
А можно пример задания?
По сабжу — а умение алгоритмизировать сейчас уже не проверяют? В стародавние времена учитель программирования в школе раздавал люлей тем вундеркиндам, которые сразу начинали писать код, не составив предварительно блок-схему. Лично я считаю это правильным. А вы?khim
01.09.2017 14:02Сейчас считаете что программу, которую можно написать за 45 минут можно (и нужно!) сразу писать «набело».
Блок-схемы — это при проектировании больших систем, которые закодить на интервью не получится.
Можно провести два интервью — на одном довести до кода маленькую задачку, на другом — поговорить о (но не писать код… разве что примеры) — большуо.
pavlushk0
01.09.2017 10:03+1Во всех инженерных областях одни и те же проблемы) Пример из машиностроения — требования знать нормы ЕСКД к чертежам досконально, хотя для изложения конструкции на ватмане скорее всего и не нужно это. И корреляция между репутацией инженера и знанием документации очень мутная. Хотя мы все стремимся быть образованными людьми — значит необходимо постоянно узнавать!
Nickola75
01.09.2017 11:04+1Соглашусь в части головоломок. Их, конечно, можно задать на собеседовании. Но мы же не берем сотрудника для решения головоломок. Мы нанимаем для решения задач. Вот и дайте ему несколько небольших задач. В них может быть как чтение когда, его анализ, предложения по доработке, фиксу багов, так и работа с базами, написание в схематическом виде запросов, небольшое проектирование, так и вопросы по принципам работы с партнерами, их api и т.д. В общем, все то, чем предстоит заниматься разработчику в схематической, короткой форме.
ogoNEKto
01.09.2017 13:50+2Еще пришло в голову: характер вопросов / задачек на интервью больше говорит о компании и ее ценностях, чем о кандидате. У кого-то в почете сферические кони в вакууме для собственного успокоения или соревнований у кого (мысль) длиннее. А кому-то важно, чтобы на встречу приходили вовремя и код писался ДО дедлайна, хоть с костылями, хоть с велосипедами, хоть копи-паст…
Так что вполне себе решение — прийти, получить идиотскую задачку, посмеяться и попрощаться.
ЗЫ Однажды на вопрос к присланному собеседовать спецу почему мы пишем код на доске получил простой ответ: «Я вообще-то не с этого проекта/отдела, но мне надо же как-то кандидатов оценивать. Ато в резюме все такое пишут...» Так вот, бывает.
SilicicArcher
03.09.2017 13:18(isYouCompiler)&(isYouVirtualMachine)&(isYouSoftwareArchitect)&(isYouDataScientist)?You=ForwardLookingSeniorDeveloper: You=ImmortalJunior
MacIn
05.09.2017 12:48Первая и вторая задачи — совершенно разные.
Первая — отличная задачка на соображалку, вторая — на тупое запоминание документации.khim
05.09.2017 14:26Не совсем так. Она, на самом деле — тоже, в основном, на соображалку. Начнём с того, что правильных ответов там не один, а два. Потому что javax.servlet.http.HttpServlet — это варинт javax.servlet.GenericServlet и, стало быть, у него не может быть только методов с HttpServletRequest'ом. Вариант с ServletRequest'ом обязан быть тоже. И он, как раз — будет публичным. И ничего не будет возвращать (тип void), у него ж целый ServletResponse в аргументах есть!
А второй вариант — уже защищённый service(HttpServletRequest req, HttpServletResponse resp).З
В общем — в этом классе всё логично и до всего можно дойти «исходя из логики». Ничего «тупо запоминать не нужно». Запоминать нужно там, где нелогично…MacIn
05.09.2017 14:55Для меня это выглядит как «надстройка», дополнительная задача, тогда как основная — знание библиотеки. Вещи вроде «javax.servlet.GenericServlet и, стало быть, у него не может быть только методов с HttpServletRequest'ом» — как раз оно самое. Сугубо imho.
forceLain
Такие ответы есть, как правило, у людей с опытом. Как задача для стенда, что бы получить футболку/кружку вполне ок. Как задача для собеседования – не ок. Зачем нужны такие задачи можно найти в книге Java Puzzlersю
fillpackart
Опыт в мире разработки — ничего не стоит. Вообще ничего, нет никакой корреляции между опытом и скиллом. И это важно понимать
Hardcoin
Важно понимать, что опыт стоит достаточно много. Тот, кто сталкивался с тысячей мелких препятствий (и уже знает направление, как решать) пишет код быстрее того, кто пока не сталкивался. А тот, кто помнит особенности языка (а значит потратил время их изучить) совершает меньше глупых ошибок.
fillpackart
Нет. Опыт позволяет помнить готовые решения типовых задач, в то же время лишая разработчика возможности/желания подумать над этим ещё раз. Принято считать, что опытный разработчик by default лучше неопытного, хотя когда спрашиваешь, почему, то получаешь в ответ абстрактное «ну он сталкивался с кучей проблем и знает их решение». Только google тоже знает их решение, единственный важный показатель для разработчика — способность создавать (не брать готовое) решение, не зависит от его опыта. Кому нужны динозавры со своими 1000000 лет опыта на делфи?
dimm_ddr
Тоже нет. Опыт позволяет абстрагироваться от деталей конкретной задачи, выделяя общее с теми задачами, которые ты уже решал. Чем больше задач решено — тем лучше и точнее можно сформировать абстракцию, тем точнее будет понимание что в задаче важно, а что нет. Что в свою очередь позволяет выбрать наиболее правильный из известных подходов (которые тоже изучаются в том числе из-за того что сталкиваешься с ними на практике).
qdb
думаю, он имеет ввиду часть опыт вне «скилла» (умения). то что вы сказали можно отнести к умению.
greabock
Нельзя отделять одно от другого. Равно как и нельзя поставить
===между этими понятиями. Эти вещи коррелируют, но не имеют прямой зависимости.Мне нравится такая формула:
monah_tuk
Формула ваша, или откуда-то взята? В любом случае — действительно, интересное наблюдение и, IMHO, похоже на правду.
greabock
Формула моя. Я использовал ее при разработке игры, которой уже никогда не увидеть свет.
domix32
Что есть талант?
greabock
Некоторый "врожденный" коэффициент предрасположенности к чему либо.
saboteur_kiev
Нет врожденных коэффициентов, есть только опыт. Другой вопрос как опыт был набран.
Например талант к музыке может быть у человека, который еще в утробе матери слышал музыку, его мозг смог различить что звуки имеют систему, проявилось любопытство либо какая-то связь между музыкой и кормлением, и мозг мотивированно стал формировать нужные связи для различения звуков. А после рождения и обретения речи «какой талантливый ребенок».
P.S. Это очень-очень грубый и ненаучный пример, просто показательность того, что талант — не предрасположенность, а наработка. Возможно даже в другой области, но благодаря высокому уровню абстрации, доступному мозгу, этот опыт может быть спроецирован на текущую задачу, уже имея готовые подходы к решению.
dimm_ddr
Ваш пример показывает как это может работать, но никак не доказывает что так и есть. Более того, так как мозг у разных людей разный — это как раз доказано, разный как минимум по объему, то логично предположить что у разных людей лучше работают разные его отделы в разных задачах. Что в свою очередь вполне можно назвать врожденным талантом. Так что более вероятно что вы неправы.
vedenin1980
Попробуйте стать двухметровым бейсболистом за счет наработки, если у вас генетически максимальный рост при рождении метр с кепкой.
Во многих видов спорта вы просто не сможете достичь реальных успехов, если вы имеете неправильную генетику.
saboteur_kiev
Простите, но двухметровый рост это не талант, а габариты.
Еще никого в мире не называли «талантливый верзила», «талантливый дистрофик».
Талант всегда приравнивался к тому, как человек что-то умеет делать, а не какой он внешне.
vedenin1980
Вопрос не в том какой он внешне, важно что человек с ростом в метр не сможет играть в баскетбол в проф. лиге NBA, человек шкаф в плечах не сможет выиграть бег мира на 100 метров, дистрофик не станет чемпионом по боксу, генетический даун не станет чемпионом мира по шахматам и т.д.
То есть мы видим уже определенную генетическую предрасположенность к одному виду деятельности и слабость к другому.
Следовательно, логическое условие:
Не верно. Врожденные генетические коэффициенты как раз есть и они очень важные для любой деятельности. Можно только спорить насколько влияет генетика, характер и опыт (упорство), но полностью сбрасывать генетику со счетов никак нельзя.
saboteur_kiev
«То есть мы видим уже определенную генетическую предрасположенность к одному виду деятельности и слабость к другому.»
Не так. Человек с любым ростом может гениально играть в баскетбол, например закидывая мячи с неудобных позиций, в полете, прыжке и не глядя. Просто его не пустят играть в какой-то там NBA, где ради шоу и денег талант заменяют ростом и габаритами.
vadimr
Умение играть в баскетбол определяется количеством выигранных игр и чемпионатов, а в первом приближении — количеством забитых мячей. А не способностью нанести удар с неудобной позиции. И количество забитых мячей при двухметровом росте и равном умении будет больше. Также как боксёр лёгкого веса не выстоит против громадного супертяжа, даже при том, что техника в лёгком весе обычно лучше.
vedenin1980
Даже если может игроку метрового роста будет играть намного сложнее чем 2 метровому (его банально заблокировать проще и ему сложнее закинуть мяч вблизи). А значит он потратить времени и сил намного больше при том же результате.
Вот вы серьезно утверждаете, что не существует генетических различий между людьми (даже в физических параметрах)?
Любая девушка может стать моделью и победить в конкурсе красоты? Не бывает некрасивых девушек от рождения? Не бывает слабых от рождения людей, которые никогда не смогут попасть в грузчики, десантники, пожарные? Проблемы со здоровьем не бывает генетическими от чего закрыт путь в летчики и космонавты?
Вам любой тренер почти в любом виде спорта скажет, что когда к нему приводят 3-5 летних детей, он может уже 100% сказать у кого нет никаких шансов в профессиональном спорте (именно в этом виде спорта). Это не значит что все виды спорта закрыты, если генетически вам не стать спринтером, вы можете стать марафонцем и наоборот.
Мягко говоря утверждать, что все люди от рождения одинаковые это перечеркивать всю генетику. Да, возможно можно затратим намного больше труда и сил можно достичь успехов больших, чем тот кто от рождения имеет преимущество, но утверждать, что не существует никаких генетических отличий между людьми — очень странно.
Neikist
Плохой пример. Талант к музыке вполне зависит от генов. Например кто то предрасположен слышать более широкий диапазон частот — кто то более узкий.
На самом деле почти для всего что бы вы не привели — можно будет найти контрпример.
Markscheider
Слух есть у всех, кроме глухих. Соответственно, голос есть у всех, кроме немых. Априори немузыкальный человек, говорящий «у меня нет слуха» неправ. Если вы такое слышите — легко можете привести контраргумент, спросив: «а если при тебе поют известную песню и фальшивят — ты это слышишь?». В 90% случаях ответ будет «да», что какбэ намекает: со слухом все хорошо.
Так почему же не все люди хорошо поют, хотя имеют и слух, и голос? Все просто: не отработано взаимодействие этих двух служб. Услышать ноту «ля» первой октавы могут все. А вот воспроизвести своим голосовым аппаратом соответствующий звук (440 Гц), т.е. «попасть в ноту» — не все.
Так что поверьте, вопрос исключительно в тренировке, никакого волшебства. На вход принимаем сигнал ухом, на выходе — генерируем звук голосом. И стремимся к совпадению. Кстати, для этой цели можно использовать программы для смартфонов, изначально предназначенные для настройки гитары. Там даже видно — выше или ниже надо звучать.
Neikist
Вот не надо, например у дочери моей крестной — проблема со слышимостью низких частот. Она часто не слышит что ей говорят, либо слышит частично. Вот такой уродилась. Соответственно ей бы было трудно в музыкальной школе, неправда ли? Да и глухие люди, это разве не отсутствие таланта? А есть еще разные нарушения координации, зрения, слуха, цнс, работы мозга… И все это зависит часто от генов. Вы этим людям тоже скажете что это от отсутствия тренировки?
saboteur_kiev
Глухие люди это не отсутствие таланта. Бетховен.
Не путайте дефекты и талант.
Markscheider
Опередили меня с комментом :) Добавлю еще пять копеек…
Наверняка делали исследования — на каких частотах провал и насколько сильный. Если дитё прям очень хочет заниматься музыкой — ничего не мешает подобрать инструмент в слышимом диапазоне. Флейту-пикколо, например.Neikist
Но тем не менее это уже препятствие и заставляет потратить больше усилий на достижение результата. К тому же вы сами говорите что «нужно подобрать инструмент», что тоже есть ограничение.
Kealon
То что способности нет, это конечно неправда. Но в реальности не у всех есть средства(деньги, время) опровергать диагноз «медведь на ухо наступил», этот просто экспертное мнение: «овчинка выделки не стоит». Вы вот как оцениваете соревнование с дельфином в плавании?
Markscheider
Дык это ко всему относится. И к карьере, и к образованию… Нет времени/денег — не учись в школе, не поступай в институт, работай в Маке/сиди на шее у родителей. Все в этой жизни упирается в желание чего-то достичь…
greabock
Господа, вы слишком серьезно к этому относитесь.
Это же просто выдуманная формула для тайкуна.
Я не проводил никаких исследований по этому поводу.
Varim
На моей практике, ПО строится на похожей архитектуре, потому что так видимо проще нанять кучу народу и хоть как то пытаться их заменять друг на друга и заставить работать вместе. Не надо учить всю банду новой архитектуре. За это и платят деньги чаще всего. А поскольку всё похожее, то чем больше опыта тем быстрее разработка в условно типичных случаях.
Free_ze
В реальном мире готовое решение в большинстве случаев будет дешевле и более качественное, чем поделие любителя велосипедов.
Кому нужны новички с амбициями, но без опыта?
Hardcoin
Готовые решения типовых задач? У вас есть какие-то подтверждения этому утверждению? Опыт — это набор абстракций в голове. Например, вы знаете паттерны проектирования или каждый раз любую мелкую задачу решаете с нуля?
"Сталкивался с кучей проблем" — это понятие абстрактное для тех, кто не сталкивался. Для остальных оно конкретное. Знаешь, как работает менеджер пакетов apt? Можешь начать работать с npm за 5 минут, а не за час. Экономия времени. Знаешь, чем отличается hash и b-tree? В следующий раз выбираешь за пять минут, а не после боевой эксплуатации с проблемами и тормозами. Опять экономия. Таких вещей сотни. Гугл вам на вопрос "hash vs b-tree", конечно, даст ссылку на документацию, но если человек не знает про hash, он даже гуглить не будет.
P.S. да, я смешиваю опыт и знания, потому что они частично взаимозаменяемы.
shurutov
У меня сложилось впечатление, что вы немного путаете стаж и опыт. Разница, если очень кратно:
стаж: протирание штанов в офисном кресле, решение исключительно типовых задач путём механического копирования найденных решений схожих/подобных задач; развивается только навык слепой печати, да и то не всегда;
опыт: решение задач путём использования головного мозга и имеющихся в этом мозгу знаний для анализа условий и формализации задачи с целью выработки пути решения; анализ имеющихся средств и способов решения для выбора наиболее соответствующего условиям задачи (средств и способов зачастую несколько); собственно решения задачи и, наконец, оформления отчёта о проделанной работе. Финальный пункт также включается в опыт, ибо Вы задачу решаете не только в своё удовольствие, но и, в подавляющем большинстве случаев, для использования Вашего продукта более другими людьми.
Когда вы набираете опыт, мало того, что набирается некоторая база знаний, ещё и мозги развиваются, что весьма важно для решения сложных и трудоёмких задач.
Aleks_ja
Опыт, помимо прочего, развивает «чуйку».
franzose
Ага, когда вроде понимаешь, а словами объяснить не можешь.
vedenin1980
Если будет выбор кого лучше иметь в команде Java разработчиков — джуна годом использования Java или человека лет 10 разрабатывающего серьезные проекты на дельфи, то при прочих равных я предпочту скорее Дельфийста. Потом что язык и библиотеки это важно, но тайм менеджмент, умение работать самостоятельно и в коллективе, умение учится, знание паттернов/алгоритмов/принципов дизайна, какой код хороший и какой плохой и т.п. намного важнее.
Настоящий синьор с большим опытом на одном языке за считаные недели/месяцы при реальном желании станет, как минимум, твердым мидлом на другом, а вот для начинающего все намного сложнее.
DistortNeo
Это зависит от пластичности мозга кандидата. Дело в том, что накопленный опыт может, не способствовать, наоборот, а мешать пониманию новых технологий — это всё индивидуально. И умение учиться у программистов с большим опытом может оказаться хуже.
Например, многие люди, которые годами писали на компилируемых в нативный код языках с ручным управлением памяти, испытывают сильное отторжение от, например, сборщика мусора.
vedenin1980
Где-то это правда, но им по крайне мере не нужно объяснять зачем сборщик мусора в принципе нужен. К тому же, горе от ума может быть и у просто опытных программистов на том же языке, которые считают себя слишком крутыми для простых или нудных задач. Термин овер квалификация тоже придумали не просто так.
Но в целом, я бы поставил, что вероятность быстро перейти опытному программисту с одного языка на другой выше, чем джуну резко прыгнуть на мидла или синьора (это практически невозможно меньше чем за несколько лет, ИМХО).
SirEdvin
Как раз наоборот. Им то как раз нужно объяснять, потому что они не понимают или не желают принимать преимущества его использования.
depadep
Я по своему опыту скажу: когда после 7 лет программирования на C++ переключился на C# сборщик мусора был сразу воспринят как божественная фича. Поскольку я на своей шкуре ощущал, сколько у нас проблем и багов вылезало из-за неправильной работы с распределением-освобождением памяти.
Arbane
Вы, наверное, путаете умение мыслить и решать задачу понятно с тыканием мышкой в экран. Я пишу на дельфи и на С#, и на JavaScript под Node.js и т.п. А человек, который знает методы, но не умеет думать или который выучил 100500 бесполезных ненужных никому сейчас «оптимизаций» С в стиле +(a++-c-)-b, мне в команду не нужен.
franzose
А при чём тут конкретно Delphi? Если Delphi позволяет адекватно решить поставленную задачу, то почему бы и нет? Это одно. А второе:
Есть такая штука, как время и бюджет проекта. Если они резиновые, можно и пописать велосипеды, конечно. Только зачастую это не так, поэтому обычно адекватный разработчик не будет создавать видимость работы, тратя время и пиля в 100500-ый раз собственный фреймворк или какую-то либу, а для начала поищет в том же Гугле имеющиеся решения, примерит их. И только в том случае, если они ему не подошли (и не по причине «у нас нет времени это изучать, проще запилить своё»), он запрограммит узконаправленное решение.
dovg
Я знаю компанию, которая готова много платить динозаврам с 1000000 лет опыта на дельфи. У них сейчас наверное с десяток вакантных позиций.
tyomitch
Я слышал, что программисты на Коболе и Аде сейчас гребут деньги лопатой, потому что их во всём мире единицы, а спрос (для поддержки легаси-кода) ненулевой.
Делфи скоро тоже будет в этой нише :)
i_visseri
Без опыта сложно решать поставленные задачи и разбираться с проблемами, так как совершенно не знаешь с чего начать. И в то время, пока человек без опыта будет безуспешного гуглить, пытаясь найти хоть что-то, о чего можно оттолкнуться, опытный человек уже может решить проблему, причем гораздо изящнее. Опыт — ключевое понятие вообще в нашей жизни. Это приобретение осознанных, пережитых знаний.
AndreyRubankov
У опыта есть свойства: количество и качество, как greabock упоминает в своем комменте.
Количество опыта – это время работы. Месяц, год, два… за это время на пути встречается большое количество проблем, которые как-то решаются.
пример: 3 года работы с Фреймворком Х означает, что разработчик на своем пути столкнулся с множеством проблем. точка.
Качество опыта – это время, потраченное на исследование проблем и их решений.
пример: 3 года работы с Фреймворком Х совершенно не означает, что разработчик получил качественный опыт – он мог гуглить и копипастить «решения» без понимания, что происходит.
Количество опыта позволяет обходить проблемы стороной и быстрой выйти в релиз.
Качество опыта позволяет решать проблемы и повышать качество проекта.
И то и другое свойство очень важно! Чаще всего они важны на разных этапах жизни проекта. Количество необходимо для быстрого запуска, качество – для стабилизации и поддержки после.
L1ar
Наверное, в каком-то вашем особом мире опыт ничего не стоит.
Только с опытом разработчик будет знать, когда какие подходы применять, когда лучше сделать так, а не иначе. Чувак со скилом 100 только что из универа никогда не будет лучше чем разраб со скилом 90 и опытом лет 10. Точнее будет. Лет через 8.
Ну это если разделять скил и опыт. Так-то опыт обычно в скил перетекает, если человек с мозгом, конечно (тех, кого опыт ничему не учит мы не рассматриваем).
fillpackart
Если у разраба с 8 годами опыта скилл меньше, чем у чувака без опыта, возможно ему стоит подыскать себе местечко на помойке? Какой идиот наймёт этого бездаря?
Varim
очевидно вся перепалка в том что вы упомянули скилл и опыт но не дали определения терминам.
По русски скилл это наверное навык, а экспириенс это опыт.
Тем не менее, что такое навык что такое опыт?
Набить руку на кидание дротика, это навык, а что такое опыт? Вроде как память о сделанных ошибках и удачах (достижений)?
fillpackart
Тут всё просто. Уметь писать код — навык. Работать программистом — опыт. То-есть опыт подтверждает только то, что ты занимался разработкой. Он не является доказательством того, что ты — хороший разработчик. Естественно шансы иметь высокий скилл выше, если у тебя большой опыт.Но это только шансы. Не у всех с большим опытом есть хороший навык, это не может и не должно быть значащим параметром. Ведь ничто не мешает человеку десять лет разрабатывать код, оставаясь при этом низкоуровневым разработчиком.
Hardcoin
Опыт — это не то, что с тобой происходило (это "прошлое" или "воспоминания"), это то, что ты из этого вынес.
Дурака жизнь не учит — про это. События происходят, а опыт не набирается.
fillpackart
Да, вот только судят о чужом опыте именно исходя из того, что происходит с человеком. Отсюда и мой тезис, что опыт — ничего не стоит, ведь мы не знаем, что человек из этого вынес.
Aleks_ja
Вероятность существенно больше того, что программист со стажем 8 лет умеет больше чем программист со стажем 1 год.
playermet
> что опыт — ничего не стоит, ведь мы не знаем, что человек из этого вынес
Человек вообще без опыта гарантированно ничего не умеет. Величина того что умеют программисты кореллирует с их опытом.
AndreyRubankov
Для этого с людьми общаются. Проводят собеседования, чтобы понять, как много ценного опыта человек получил за свою карьеру. Как он решал проблемы и прочее.
Odrin
Вы путаете опыт и стаж.
Maccimo
Вы путаете слова.
«Низкоуровневый разработчик» это разработчик, работающий на низком уровне абстракций.
Разработчик драйверов, например.
Судя по всему, вы хотели сказать «низкоквалифицированный разработчик».
Aleks_ja
Значит, опытные программисты, программируют драйвера, а умелые — сайтики свои клепают :-)
Color
Это как раз и есть то, что отличает джуниора от мидла, например.
Скилл (навык) есть ничто иное, как знание теории. Да, это хорошо, этого даже может хватить для сертификации, но не более.
Экспириенс (опыт) — это то, что нельзя получить без практики. Без практики нельзя осознать (выучить — можно) принципы разработки ПО, нельзя понять (запомнить — можно) чем и почему плохой код отличается от хорошего.
Вкратце — неважно, какой "размер" у твоего скилла — главное умение им пользоваться. Странно, что это вызывает сомнения
nightvich
Вы тут единственный раз оказались правы, если человек занимается низкоуровневой разработкой, то ничего ему не мешает продолжать ей заниматься.
darkdan92
Хм, на мой взгляд сильное утверждение.
Именно опыт помогает выбрать оптимальное решение задачи исходя из знаний о удачных и неудачных решений похожих задач в прошлом.
Ну и все таки опыт — это часть скилла. Как вы себе представляете скиллованного человека без опыта?
1coff
Вы путаете понятие стажа работы и опыта. Опыт — это очень дорого стоит, возможно даже больше каких-то навыков. А вот по стажу работы о разработчике сказать ничего нельзя.
Вполне могут быть ситуации когда один имеет стаж 8-10 лет разработки, второй 2-3 года, но при этом у второго опыта больше потому что работал с более разнообразными проектами, писал больше кода и на большее количество граблей наступил.
saboteur_kiev
«нет никакой корреляции между опытом и скиллом»
Вообще-то любой скилл развивается практикой, а практика — есть опыт, то есть корреляция просто прямая. Вообще невозможно развить скилл чего-либо без практики.
GarfieldX
Во-первых, ваш «скилл» и есть опыт.
Во-вторых, опытный разработчик знает как правильно спроектировать задачу, какими инструментами и технологиями воспользоваться, как их наиболее эффективно использовать, а так же их нюансы и тонкости применения.
fillpackart
Так, ладно. Отчаянная попытка вернуть свою карму: имел ввиду стаж, а не опыт, но до меня не дошло, что остальные люди не знают, что я имею ввиду
vedenin1980
Даже в этом случии, выражение
Неверно, так как корреляция это любое статистическое взаимоотношение двух случайных величин отличное от случайного. То есть если величина x = N, то величина y = M c вероятностью p, где p не совсем случайное.
Так как человек с 15 годами в каком-то языке с намного большой вероятностью имеет нужные скиллы, чем человек с 0 годами, то корреляция вполне тут есть.
Если вы имели в виду что 15 лет стажа не гарантия хорошего программиста и реального навыка это правда, с которой, думаю, любой программист согласится.