Я пытаюсь понять, почему вы считаете, что выполнение задания на бумажке покажет уровень кандидата лучше, нежели в IDE. Если цель — максимально усложнить ему жизнь, можно вот так ещё делать: тестовое задание джуниору на бумажке
Ну а что, мало ли какие бывают ситуации в реальной жизни, вдруг придётся писать код там, где нет стульев. Я считаю, что это очень важный навык для программиста. Вот у нас среди клиентов есть очень большой и крупный международный банк, так представляете, у них мебели не хватает, компьютеры на полу стоят. Что бы делали разработчики, привыкшие писать код, сидя в комфортном кресле? А так пришёл, быстренько интегрировал ПО или что-то поправил, стоя на корточках, и готово. Естественно, настоящий профессионал сумеет писать код и стоя. Если на собеседовании человек даже не может этого сделать, то с ним не о чем разговаривать. Все так привыкли к стулу, что даже не представляют что его может и не быть по разным причинам.
Я написал это не как инструкцию для организации работы программистов, а пример того, как это бывает в реальной жизни.
Да, мир не идеален. И всем, кто говорит про «реальную жизнь», у меня к вам огромная просьба. Давайте вы будете в своих вакансиях сразу писать (убеждать ваших тимлидов и HR-ов писать) про эту нелёгкую жизнь в ваших компаниях, как у вас всё бывает порой печально IRL. Это было бы очень здорово.
Хорошо, допустим, вы собеседуете кандидата. Отрубите интернет, раз вы сами взяли вашу задачу оттуда и не хотите, чтоб соискатель нагуглил решение. Или чтобы не спросил на SO, хотя я сомневаюсь, что он успеет получить ответ. Предоставьте ему просто IDE, без статических анализаторов. И озвучьте запрет на дебаггинг (хотя я бы при этом мысленно покрутил пальцем у виска). Так и скажите грозным голосом: «Вам запрещается запускать и отлаживать своё решение!» Ну и следите, как он кодит ваши пузырьки или фибоначчи, да пусть даже ханойские башни. Вот чем, скажите, в такой ситуации бумажка выиграет у IDE?
Я говорю про отсутствие всякой проверки написанного кода, кроме как в голове у программиста. Типа написал где-то в блокноте или vim-е — применил этот пресловутый супер-скилл дебаггинга взглядом — удостоверился, что всё правильно.
Не поймите меня неправильно. Ситуации бывают разные, согласен. Изначально речь шла о написании алгоритмов, а не про «в интерфейсе было firstName, добавить ещё и lastName», например. В этом ключе я и рассуждаю. Реализовав какой-нибудь алгоритм посложнее пузырька, нужно как-то убедиться, что он работает.
Вообще, призываю сторонников чёткого ТЗ. Они объяснят, что все ваши задачи, интерфейсы, сигнатуры и операции с чёрным ящиком должны быть специфицированы, а если написано «на вход пришло А и Б — выдать В и Г», то должно быть так и никак иначе.
Иногда пишешь код и коммитишь без возможности проверить и запустить — реальная жизнь обширна и разнообразна :)
Тогда вы НЕ МОЖЕТЕ быть уверены в том, что ваш код корректен. Я серьёзно. Обратная связь бесценна. Дробите ваши монолиты, от которых IDE виснет на полчаса, настраивайте распределённую сборку (где-то тут видел статью), но обеспечьте хотя бы проверку на синтаксис, сиречь компиляцию.
Задача решается в IDE гораздо наглядней. Код написан, скомпилировался, корректно отработал и выдал верный результат на тестовых данных — задача решена.
Чтобы написать код в IDE, как раз и надо сперва знать или составить алгоритм. Автокомплит для алгоритмов пока не придумали.
Так в псевдо- или в коде? Если в коде, не вижу причин не использовать IDE.
О каких итерациях идёт речь, алгоритма или написания алгоритма? Если написания алгоритма, то это совершенно ненужное умение, т.к. в IDE всегда можно что-то поправить, прежде чем показать код интервьюеру или отправить в продакшн либо ещё куда.
А какие спецсредства здесь могут что-то подсказать? Разве есть такие?
Зачем? Зачем дебажить без отладчика? Можно и шуруп вкручивать без помощи отвёртки, например плоскогубцами, навык закручивания шурупа это никак не показывает. Ясен пень, если человек умеет дебажить, то он догадывается, что операторы и функции выполняются не в рандомном порядке.
Для меня это прямо загадка века. Зачем компании нанимают разработчиков? Чтобы были? Чтобы сделали что-то конкретное? Потому что «нужно больше программистов»?
Где-то надо допилиливать какую-нибудь легаси систему на миллионы строк, которая писалась 20 лет и со временем только обрастает костылями, потому что рефакторинг займёт ещё 10 лет. Где-то надо каждый месяц клепать новый проект для «иностранных заказчиков», используя устоявшийся конвейер из модных фрэймворков, шаблонов и чёрт знает чего ещё. А где-то тебе просто скажут: «Вот наша студия поймала очередной заказ с upwork-а, выполняй».
Где-то хряк-хряк — и в продакшн, потому что «надо вчера», лишь бы работало. Где-то вылизывают каждый класс и над строчкой кода можно думать по часу, а на code review обсуждают Макконелла и best practices (нет).
Где-то надо будет придумывать, как решать сложные задачи, используя результаты научных исследований и наработки флагманов индустрии. А в другом месте говорят: «Вот у нас есть то-то и то-то, надо ещё примерно такого же 50 штук, вперёд!».
«Кто нужен-то и для чего?» — вот какой вопрос у меня теперь постоянно возникает, когда я вижу очередные статьи и комментарии о human resources.
Чудеса, да и только. Я вот никогда не пробовал рубить деревья, а вдруг окажется, что я это умею, мало того, заткну за пояс лучших лесорубов. Надо как-нибудь попробовать.
Очень даже поможет. Я бы предположил, что многие вообще никогда не пробовали либо пробовали неудачно, многие даже не считают этот навык достойным умения, а те, кто когда-то умели, но давно не пробовали, уж верно смогут сказать, по-прежнему они умеют или уже разучились.
Хороший программист должен уметь писать код на листочке!
О5 25. Холивар «IDE vs листочек», наверно, даст фору табам против пробелов. Впору опрос проводить, сколько программистов умеют писать код на листочке, и как это умение коррелирует с профессионализмом.
Вы описали просто некую свободу в выборе одного из проектов, которые есть в подразделении. Насколько я понимаю, «правило 20%» означало, что можно пилить что угодно, с сохранением прав компании на получившиеся результаты, если таковые будут.
В отличие от теорем, здесь есть побочные эффекты, ну там ввод-вывод, запрос даты-времени и вот это всё. В этом ключевое отличие от модной функциональщины.
В итоге имеем красивую идею с отлично проработанным математическим бэкграундом… и полное отсутствие программистов, согласных на этом писать.
Как только появляются побочные эффекты, перестаёт работать всенаправленность предиката и «красивая идея» вырождается в «модную функциональщину». А если не видно разницы, зачем мучиться, допиливая напильником N! до log(N).
Кто-нибудь уже выяснил, бессознательное состояние — это приостановка сознания на паузу или его полное выключение с последующим запуском нового сознания?
Привет студенту родной альма-матер и специальности.
После запуска десятков, а то и сотен экспериментов на целом кластере машин, чтобы получить результат лучше, чем у кого-либо, энтузиазма для работы над курсовой работой едва ли хватает.
С этим вообще проблем не должно быть. Рассказываете научруку о своём опыте и интересующих направлениях, согласовываете подходящую тему и вперёд — делать первые шаги на пути получения результатов, которые не просто лучше, чем у кого-либо, а которые будут принципиально новыми.
Опыт. Помимо приятной строчки в резюме, здесь можно получить важные профессиональные навыки: писать чистый код, планировать свои задачи, знать state-of-the-art подходы и продакшн решений. Яндекс поддерживает стремление сотрудников расти в профессиональном плане: здесь вам и различные мероприятия и воркшопы по программированию, и наличие собственной библиотеки, и регулярные командировки на конференции. В службе компьютерного зрения практически каждый сотрудник раз в год ездит на одну из топовых конференций, таких как NIPS, ICML, ICLR, CVPR и т.д. Но для того чтобы знать самые передовые разработки в своей области, не обязательно куда-то уезжать — регулярные семинары с разбором научных статей позволяют всегда оставаться в курсе последних результатов.
Это плюсы для сотрудников, а не плюсы стажировки. Стажёру за три месяца успеть разобраться в структуре проектов, используемом стеке технологий, наборе собственных и не очень инструментов и вникнуть в процесс разработки — уже плюс. Иначе зачем стажировка, можно было сразу в миддлы идти.
Частично из своего опыта… могу сказать, что отсутствие хорошего университета в резюме
Ну что ж вы так :( Не самый плохой институт, если брать общематематическую подготовку.
Наконец-то запилили тулзу, решающую 90% задач машинного обучения 90% компаний методом перетаскивания мышкой. Возможно, когда каждая домохозяйка сможет в machine learning, хайп вокруг него поубавится.
я по-англйиски читаю свободно с такой же скоростью, что и на русском. так что ничего не пропускаю.
Как вы этого достигли? Варились какое-то время в англоязычной среде? Я просто нигде не находил свидетельств, что без этого можно хорошо овладеть языком (не считая всяких феноменальных полиглотов). Пытаюсь поднять уровень, но прогресс очень медленный.
тестовое задание джуниору на бумажке
Ну а что, мало ли какие бывают ситуации в реальной жизни, вдруг придётся писать код там, где нет стульев. Я считаю, что это очень важный навык для программиста. Вот у нас среди клиентов есть очень большой и крупный международный банк, так представляете, у них мебели не хватает, компьютеры на полу стоят. Что бы делали разработчики, привыкшие писать код, сидя в комфортном кресле? А так пришёл, быстренько интегрировал ПО или что-то поправил, стоя на корточках, и готово. Естественно, настоящий профессионал сумеет писать код и стоя. Если на собеседовании человек даже не может этого сделать, то с ним не о чем разговаривать. Все так привыкли к стулу, что даже не представляют что его может и не быть по разным причинам.
Да, мир не идеален. И всем, кто говорит про «реальную жизнь», у меня к вам огромная просьба. Давайте вы будете в своих вакансиях сразу писать (убеждать ваших тимлидов и HR-ов писать) про эту нелёгкую жизнь в ваших компаниях, как у вас всё бывает порой печально IRL. Это было бы очень здорово.
Не поймите меня неправильно. Ситуации бывают разные, согласен. Изначально речь шла о написании алгоритмов, а не про «в интерфейсе было firstName, добавить ещё и lastName», например. В этом ключе я и рассуждаю. Реализовав какой-нибудь алгоритм посложнее пузырька, нужно как-то убедиться, что он работает.
Вообще, призываю сторонников чёткого ТЗ. Они объяснят, что все ваши задачи, интерфейсы, сигнатуры и операции с чёрным ящиком должны быть специфицированы, а если написано «на вход пришло А и Б — выдать В и Г», то должно быть так и никак иначе.
Где-то надо допилиливать какую-нибудь легаси систему на миллионы строк, которая писалась 20 лет и со временем только обрастает костылями, потому что рефакторинг займёт ещё 10 лет. Где-то надо каждый месяц клепать новый проект для «иностранных заказчиков», используя устоявшийся конвейер из модных фрэймворков, шаблонов и чёрт знает чего ещё. А где-то тебе просто скажут: «Вот наша студия поймала очередной заказ с upwork-а, выполняй».
Где-то хряк-хряк — и в продакшн, потому что «надо вчера», лишь бы работало. Где-то вылизывают каждый класс и над строчкой кода можно думать по часу, а на code review обсуждают Макконелла и best practices (нет).
Где-то надо будет придумывать, как решать сложные задачи, используя результаты научных исследований и наработки флагманов индустрии. А в другом месте говорят: «Вот у нас есть то-то и то-то, надо ещё примерно такого же 50 штук, вперёд!».
«Кто нужен-то и для чего?» — вот какой вопрос у меня теперь постоянно возникает, когда я вижу очередные статьи и комментарии о human resources.
С этим вообще проблем не должно быть. Рассказываете научруку о своём опыте и интересующих направлениях, согласовываете подходящую тему и вперёд — делать первые шаги на пути получения результатов, которые не просто лучше, чем у кого-либо, а которые будут принципиально новыми.
Это плюсы для сотрудников, а не плюсы стажировки. Стажёру за три месяца успеть разобраться в структуре проектов, используемом стеке технологий, наборе собственных и не очень инструментов и вникнуть в процесс разработки — уже плюс. Иначе зачем стажировка, можно было сразу в миддлы идти.
Ну что ж вы так :( Не самый плохой институт, если брать общематематическую подготовку.