Комментарии 648
2. Орать, пинка под зад, плохая мотивация особенно для творческих видов работ.
з.ы. и нет, конечно, это не истина в последней инстанции и сейчас можно дальше в комментах накидать кучу других ссылок и обхаять эту. но эта, как реально рабочий один из вариантов построения архитектуры приложения, покатит.
Времязатраты увеличиваются с ростом проекта.
Все правильно. Только вот статья не о трудозатратах.
А о плато.
Авто статьи говорит не о каком-то сложном проекте. А о ситуации, когда в Гугле заканчиваются готовые рецепты.
Готовые рецепты заканчиваются, когда речь начинает идти об нюансах проекта. Так как ваш проект априори уникальный (иначе зачем бы вы его делали, если есть уже полностью готовое решение) — то вот эти сами нюансы проекта вы нагуглить никак не сможете.
Причем на этой стадии вы еще можете гуглить какие-то мелочи. Как и на более поздней стадии. Но это будут только мелочи универсального общего свойства.
Уникальную составляющую вашего проекта нагуглить нельзя.
Автор пишет, что гуглопрограммисты прекращают быть полезными, когда от универсальных общих присутствующих во всех проектах вещах — они переходят собственно к тому что составляет суть проекта.
Уникальную составляющую вашего проекта нагуглить нельзя.
Нельзя, но например мой опыт говорит о том, что в подавляющем большинстве проектов технической уникальной составляющей нет от слова «вообще». Бывает бизнесовая, но её понимание для программистов — приятный бонус, а не профессиональная обязанность. Поэтому StackOverflow-Driven Development, это вполне жизнеспособный подход, который в большинстве случаев позволяет реализовать проект «от и до». А тем, кому надо иметь в команде знающего гуру, те и наймут знающего гуру.
Нельзя, но например мой опыт говорит о том, что в подавляющем большинстве проектов технической уникальной составляющей нет от слова «вообще».
Разумеется, конечный продукт — это сочетание обычных обще-универсальных способов решения.
Никаких супер-оригинальных алгоритмов от программистов не требуется, как правило. Исключения редки.
Однако тем удивительнее факт выхода программиста на плато «ничего не могу», когда готовые рецепты в Гугле закончились.
Да, нужно всего лишь составить новый рецепт на базе готовых, выбрав именно то, что нужно для вашего случая. Но не все это могут сделать, потому что готового рецепта об том, как сделать под конкретную задачу нет. Об этом и статья.
Встречал "программистов", которые ошибки гуглили без малейших попыток абстрагировать их, вот прямо со своими личными путями и неймингами проектов типа /home/vasya/work5/super-project/src/Api/RogaAndKopytaApiClient
что гуглопрограммисты прекращают быть полезными, когда от универсальных общих присутствующих во всех проектах вещах — они переходят собственно к тому
… что плавно приводит нас к мысли, что пора не строить все с нуля, растить зерно, молоть муку, вырастить дрожжи-закваску и лишь потом выпекать хлеб — а просто брать с полки в упаковке. И пока кто то растит пшеницу другой кушает бутерброд.
Все придумано до нас (с)
Да он будет не уникален — но годен и быстро и удообно.
С программированием пора строить задачу из типовых гугло-кусков. Как опенсорсные блочные дома.
То есть надо менять подход — коий новое поколение мудро указало и выявило.
так что две цитаты:
Человек, который почувствовал ветер перемен, должен строить не щит от ветра, а ветряную мельницу. © китайская народная мудрость
Надежные машины из ненадежных элементов! © Джон фон Нейман
С программированием пора строить задачу из типовых гугло-кусков
Ну так тут выше и написали, что StackOverflow-Driven Development, это вполне жизнеспособный подход ))
Но речь то не об этом, а о том что уникальные вещи (которые, пусть и в минимальных количествах, но всегда присутствуют в любом коммерческом проекте сложнее условного калькулятора) — так просто не скопипастить, даже путем склейки нескольких кусков.
И это я не говорю о
Когда-то да придется рефакторить, а то и вовсе, о ужас, менять архитектуру/структуру, под новые фичи. И сможет ли во всё это копипастокодер — вопрос
Но речь то не об этом, а о том что уникальные вещи
Для этого нужно два, максимум три обученных программиста на всю компанию. Остальные должны быть индусами. И вообще чем меньше уникальностей, если вы не ракету на марс делаете — тем лучше. Весь прикладной софт этого не требует совсем. Уникальность должна быть в полезности и удобстве.
Опять же, надо (нонче) проектировать софт, чтоб кодо-уникальностей не было, и вообще все было искллючительно блочно, дабы менять (и выкидывать) без страха и упрека, и первый залетевший с улицы дятел мало того чтоб не рушил, так мог еще и кусок дописать.
И сможет ли во всё это копипастокодер — вопрос
Надо верить в лучшее — появятся копипасто рефакторы. В среднем квалификация публики растет — но некий возвышенный уровень падает. Что данность, и даже понятно почему — так эффективнее, жизнь заставляет давать ответ раньше чем успел подумать и обсосать.
Для этого нужно два, максимум три обученных программиста на всю компанию. Остальные должны быть индусами.
А если их всего три?
Это не компания а кружок. Но в русской культурной традиции для троих предусмотрены особые варианты.
Посидят, подумают, что нибудь придумают © Чистяков
Это не компания а кружок. Но в русской культурной традиции для троих предусмотрены особые варианты.
Ну а если их 300 разработчиков всего?
Настоящих программеров все равно должно быть 3?
А остальные 297 — тупые просто приложения к клавиатуре?
P.S.:
Индустрия разработки ПО существует вот уже более полусотни лет, всё уже рассчитано до нас.
Например, один из классических трудов по организации разработки ПО «Мифический человеко-месяц» Ф. Брукса опубликован еще в 1975 году.
И старших разработчиков нужно довольно много. Типично, на каждые 2-5 человек обычных разработчиков — 1 старший.
А вовсе не:
Для этого нужно два, максимум три обученных программиста на всю компанию. Остальные должны быть индусами.
Настоящих программеров все равно должно быть 3?
А остальные 297 — тупые просто приложения к клавиатуре?
В компании обасучивающей прачечные, в общем то — да. С некой долей условности. И это 99% рынка. Наверно обидно звучит.
Не, там где искусственный интеллект, квантовые компьютеры — все иначе.
Индустрия разработки ПО существует вот уже более полусотни лет, всё уже рассчитано до нас.
То, что было полсотни лет назад — не годится. Настолько все меняется — на моей памяти по два раза в год, минимум. Это я про штаты.
Важным становится скорей быстрая обучаемость и слаженность, а не алгоритмичность. Поэтому, ясен пень, и гуглят активно.
И старших разработчиков нужно довольно много. Т
Дык все поделено на группы, а не все 300 скопом над одним проектом. Что нам и дает изолированные блоки внутри компании. И в таком, из нескольких команд над проектом — как раз единицы. Остальные пилят нишу.
Все равно при поставленной разработке за пределы ниши выходить не приходится.
Так кстати не только в китах рынка — но и в стартапах.
«А как насчет крылышек? — спросил я. — Или, скажем, сияния вокруг головы?
Один на тысячу!» — «А нам всего-то один и нужен», — сказал горбоносый. «А
если их всего девятьсот?» — «Согласны на девять десятых».
Всегда веселил подобный подход к собеседованиям в рандомных «ООО Рога и копыта». Как только на собеседовании заходит речь про бумагу и задачи — я сразу улыбаюсь, благодарю за собеседование и прощаюсь. Думаю, как и любой уважающий себя специалист.
Да и в целом какой-то совковый подход. Я так понимаю, автор статьи застрял во времени, где-то в конце 90х-начале нулевых. Индустрия давно поменялась, искать решения в гугле — это нормально. Задача программиста в первую очередь закрывать задачи бизнеса, а не писать идеальный код из головы и знать все методы библиотечных классов. Удивительно что вы, как тимлид (или кто вы там?) этого не понимаете…
Попахивает (очень) «эффективным» менеджментом.
Я дико извиняюсь, но… Слить карму на Хабре — это как нефиг делать. Вот поднять — тяжко, если не считаешь для себя честным заполнять Хабр десятками иноземных переводов. А вот слить — очень легко. Достаточно "не понравиться" или "не сойтись во мнении" с парой-тройкой индивидуумов, плохо переносящих личные мнимые "обиды".
Кривую систему кармы Хабра ругали уже столько раз, что снова начинать это уже даже неинтересно.
Там пара тройка минусов (за комменты), тут пара тройка (за них же) — вот карма и досвидос. Если предпочитаешь Хабр в основном читать, а не писать уникальный и ценный текст, шансы поднять карму — практически минимальны. Потому что минимальное количество людей повышают карму за комменты. Вот слить карму за них же — каждый считает себя прям обязанным, а поднять — фигушки.
Иными словами, если ты предпочитаешь Хабр в основном читать — то лучше его читать? Ну, пожалуй соглашусь, только не понимаю причём тут карма...
Что непонятного?
Можно писать статьи, а можно писать комменты (это тоже как ни странно — писать). Карма получается за первое, а сливается — за второе (и почти никогда за второе карма — не начисляется). И второе же и ограничивает.
Я бы понял если бы за ценные комменты (за +10 +50 +100 и т.д.) — она начислялась бы как за статьи автоматически, но нет. В комментах всё зависит только от критиков, которые, повторюсь, сливают — с удовольствием, а начисляют чуть чаще чем никогда.
Не вижу ничего зазорного в том, чтобы обращаться в гугл за помощью в том, как работает тот или иной инструмент, главное — не копировать бездумно куски кода из SO в свой проект. Программирование — не знание на зубок всех языковых конструкций и стандартных библиотек. Программирование про умение думать, и правильно компоновать доступные инструменты для получения оптимального в данной ситуации решения.
Т.е. если я не помню как называется нужная мне функция — не страшно, главное что я помню, что она есть.
Знание функций стандартной библиотеки и используемого фреймворка дает беглость. — Есть некоторая разница, пишешь нужную функцию сразу, или тратишь на поиск как-там-она-называлась пусть даже 10 секунд. Потому что эти секунды накапливаются.
Влияние, конечно, не так чтобы сильное, но оно есть.
Вообще, не совсем. Сравним с обычным, человеческим, но иностранным языком. Нужно на нем какую-нибудь статью написать на заданную тему. Там тоже подумать/прочитать — большая часть работы. Но скорость написания статьи будет довольно разной в случае 'знаю иностранный язык' и в случае 'знаю иностранный язык со словарем' (т.е. как раз вариант, когда знаю, что слово есть, могу его найти, но вот прямо сразу написать не могу).
А без знания нужно либо перерывать подсказки в поисках нужной — это работает в целом с методами разве что, но не с типами/интерфейсами
Ты можешь не помнить не строчки синтаксиса, но само ощущение «Я очень похожее уже решал, есть стандартное решение и какой то хитрый хак» позволит тебе быстрее нарыть эту штуку, чем просто «надо погуглить»
Оказалось, что только один программист из десятка умеет работать с базовыми сущностями, типами, знает их свойства и методы.
Мы это и обсуждаем. На кой черт помнить все это? Если примерно помнишь то разберешься.
Если быть точным мы даже скорее обсуждаем начальное сообщение в этой ветке
и знать все методы библиотечных классов
Зависит от статьи. Если это вывод сложной, исследовательской работы, то собственно, написание — занимает небольшой процент. И разница между наивным языком и другим, но со словарём — будет минимальной (в процентном отношении к другой работе). И с другого конца — если это просто перевод, то вариант "со словарём" проигрывает кардинально. Работа программиста, на мой взгляд, ближе к исследовательской. Для ребят, что просто переводят с бизнес-логики на какой-нибудь питон (надеюсь, никого не обидел), знать наизусть команды фреймворка, наверное, важно.
разной в случае 'знаю иностранный язык' и в случае 'знаю иностранный язык со словарем'
Не верная аналогия, большую часть программирования составляет написание базовых структур (функций, классов, циклов, определения переменных),
который как раз любой программист знает наизусть. А 'знаю иностранный язык со словарем' это скорее аналог вообще не писал на этом языке.
Верная аналогия — два опытных переводчика, которые базовую лексику знают в совершенстве, но переводят скажем юридическую докементацию или технические тексты и
одному приходятся использовать иструменты вроде онлайн словарей для специфических терминов (десятка слов на страницу), а другой помнит их наизусть.
Вот далеко не гарантировано, что второй будет переводить быстрее или качественее.
Ну так "знаю английский со словарём" подразумевает, что знаешь базовую грамматику (синтаксис функций, классов, циклов, определения переменных), но словарный запас (стандартная и популярные библиотеки/фреймворки) маленький.
«знаю английский со словарём» подразумевает
Скорее подразумевает, что вы его толком не знаете.
Если вы знаете все граматические структры, обычно понимаете речь без сложных оборотов на слух и можете бегло объясниться простыми словами и оборотами в большинстве рабочих и бытовых ситуаций это уже B1-B2 (Upper Intermediate) уровень.
Это уже далеко не "знаю со словарём". Вообще мне кажется, что типичный "знаю английский со словарём" под эти классификации не попадает, даже под elementary. Эти уровни подразумевают, кажется, наличия примерно одинаковых четырёх основных аспектов владения языком, без перекосов. Хотя, вроде можно пройти сертификацию на Intermediate, владея только чтением, грамматикой и относительно небольшим словарным запасом "в тему"
Это уже далеко не «знаю со словарём»
Ну так речь и про то, что программист хорошо знающий все аспекты своего языка и способный писать большинство типовых программ с подсказками Ide это намного выше уровня «знаю со словарём».
Многие проф.переводчики активно используют аналоги IDE для перевода и вполне успешно.
Вообще, не совсем. Сравним с обычным, человеческим, но иностранным языком.
То что в названии и человеческого языка и языка программирования есть слово «язык» это не означает что это понятия одного поля, которые можно сравнивать вот так вот просто.
Вам же не приходит в голову приравнивать часть тела, что находится у вас во рту и тоже называется «язык» к разговорному или компьютерному языку?
Ключевых слов в языках программирования — исчисляется, как правило, десятком или несколькими десятками. Сопутствующих этим словам синтаксических конструкций — примерно столько же. Зная их, вы уже, по большому счету, можете программировать на этом языке без каких либо ограничений. Остальное уже навык использования в той или иной ситуации.
Количество слов базового английского, придуманного чтобы представители Британской Империи могли общаться с туземными колонистами — 850 слов. И этого вам хватит разве чтобы сходить в магазин купить товары повседневной необходимости. Не более. И то, при условии, что вы на товар пальцем будете показывать, не зная как его назвать. И даже не всегда сможете объяснить продавцу что вам нужно, описывая свойства товара, кроме простейших свойств.
Зная несколько десятков ключевых слов и несколько десятков языковых конструкций — вы сможете прочитать любую программу на этом языке.
С человеческим языком — совсем другие порядки:
400–500 слов – активный словарный запас для владения языком на базовом (пороговом) уровне.
800–1000 слов – активный словарный запас для того, чтобы объясниться; или пассивный словарный запас для чтения на базовом уровне.
1500–2000 слов – активный словарный запас, которого вполне хватит для того, чтобы обеспечить повседневное общение в течение всего дня: или пассивный словарный запас, достаточный для уверенного чтения.
3000–4000 слов – в общем, достаточно для практически свободного чтения газет или литературы по специальности.
Около 8000 слов – обеспечивают полноценное общение для среднего европейца. Практически не нужно знать больше слов для того, чтобы свободно общаться как устно, так и письменно, а также читать литературу любого рода.
Приравнивать десятки слов компьютерного языка, дающих полное понимание языка программирования, к 8000 слов человеческого языка и проводить аналогии — это как-то смело с вашей стороны.
Ключевые слова и конструкции в ЯП больше соответствуют грамматическим конструкциям в естественных языках. Какое-нибудь "to be going to" или "to have been" не требует дословного понимания (оно даже вредить может), так же как if/then/else тоже его особо не требует. А "слова" ЯП — это как раз библиотеки.
Ключевые слова и конструкции в ЯП больше соответствуют грамматическим конструкциям в естественных языках.
При этом знание языковых конструкций дает вам понимание всего языка программирования.
А знание всех языковых конструкций живого языка не дает вам ничего.
Ибо Вам нужно заучить тысячи слов.
И не только слов, а еще и выражений (потому что слова на другой язык далеко не всегда переводятся однозначно, исключение только в простейших словах, типа местоимений, те, да, переводятся просто).
Смотря что называть "всем языком программирования"
Смотря что называть «всем языком программирования»
То, что в реальности нужно знать программисту помимо синтаксиса — алгоритмы, паттерны, концепции — это вовсе не слова зубрить.
Имхо, за уши притянуто сравнение человеческого языка и языка программирования.
притянуто сравнение человеческого языка и языка программирования
Просто, говоря о человеческом языке вы думаете об устном разговорном.
А вот если сравнивать с письменным официальным (письма, жалобы, юридические документы, тех.документация), то неожиданно
там тоже есть алгоритмы, паттерны, концепции, код.стайлы, а вот слова зубрить совсем не обязательно (хотя какой-то базовый набор сильно облегчит жизнь, впрочем в программировании тоже), есть множество инструментов которые могут подсказать нужное слово.
А вот если сравнивать с письменным официальным (письма, жалобы, юридические документы, тех.документация), то неожиданно
там тоже есть алгоритмы, паттерны, концепции, код.стайлы
Code Style — да.
А вот алгоритмы и концепции в каком-то официальном документе — это уже другая область человеческого знания, например, юриспруденция.
Но это не собственно знание самого языка.
А так то — да. Любая область человеческой деятельности использует язык как минимум как вспомогательный инструмент.
Приравнивать десятки слов компьютерного языка, дающих полное понимание языка программирования,
А я не про понимания языка программирования. Я про понимание и написание всей программы. Где уже надо знать, что вызываемые функции делают. Которых функций и классов — сильно побольше, чем десяток.
Приравнивать десятки слов компьютерного языка, дающих полное понимание языка программирования,
А я не про понимания языка программирования. Я про понимание и написание всей программы. Где уже надо знать, что вызываемые функции делают. Которых функций и классов — сильно побольше, чем десяток.
Это как?
Вы приравниваете понимание работы алгоритма к изучению человеческого языка?
Понимаете человеческий язык и язык программирования — это о разном.
Да, приравниваю.
Знать человеческий язык — уметь выразить письменно на этом языке свою мысль так, чтобы тебя поняли именно так, как тебе надо. Ну и в обратную сторону — понять, что тут тебе написали.
Знать/уметь программировать на языке — это выразить письменно на этом языке, что надо сделать, так, чтобы тебя поняли и машина и человек, который когда-нибудь будет это читать. В обратную сторону — понять, что тут этот кусок кода сделать пытается.
Знать человеческий язык — уметь выразить письменно на этом языке свою мысль так, чтобы тебя поняли именно так, как тебе надо. Ну и в обратную сторону — понять, что тут тебе написали.
То есть программисты, если они действительно хорошие программисты, то они априори способны написать хорошее художественное произведение?
Это вы напрасно.
Не художественное. А понятное произведение/документацию/статью итд итп. Просто обязаны по профессии.
Как только им дадут, с одной стороны, систему команд эмоционального интеллекта, а, с другой, ТЗ на то какие эмоции нужно вызвать :)
то они априори способны написать хорошее художественное произведение
Вас совсем не в ту степь понесло.
На это даже дипломированные филологи не способны (написать художественное произведение без ошибок они могут, стать популярныеми писателями — очень немногие), умение пользоваться видеокамерой не означает, что вы сумеете снять культовое кино.
Понимаете человеческий язык и язык программирования — это о разном.
Да не особо, если говорить о письменном естественном языке для каких-то задач (обычно на ЯП мы устно все-таки не общаемся).
Условно написать официальное письмо в какую-то службу практически аналогично написать программу для комьютера, те же блоки, обороты и т.п,
даже код стайл есть. Документация легко конвертируется в программу и обратно, более того есть системы написания unit test'ов где пишешь
практически на ествественном языке условия.
Не имеет абсолютно никакого значения количество слов или условных конструкций, вроде дженериков. Да и в обычных разговорных алфавитах букв десятки, даже не сотни. Однако судя по чатам и комментариям, у многих даже на родном языке написать не достаточно способностей, чтобы быть понятым…
… или гуглишь непонятно что, так как не знаешь что оно вообще есть.
То что будет часто использоваться запомнится быстро, после нескольких нагугливаний, то что редко — один черт придется каждый раз вспоминать и лезть в гугл/доку. Главное знать что такая штука есть в принципе, а найти и применить проблема не большая.
Так обычно те функции, которые используешь часто, знаешь. Но бывают такие, что раз в год попадаются. Я, например, каждый раз в Гугл лезу за какой-нибудь связкой socket/bind и т. п. Ну не часто мне приходится сервера писать. Не думаю, что пятиминутное вспоминание раз в год, где что прописывать, сильно влияет на производительность.
а все функции зубрить смысла никакого нет. и не получится все запомнить, и времени больше потратишь, чем сэкономишь.
Смотрим снова аналогию с иностранным языком. Слова, когда учат язык, именно зубрят. Не все подряд, конечно, а по методикам, но именно зубрят. А не 'какие больше используешь, так и запомнятся'. И когда учат много языков — учат слова каждого.
Правда отсюда нулевая грамматика при свободном чтении технического английского, но это уже другой вопрос, зубрежка слов тут бы никак не помогла.
Ну вот это наше "не надо специально учить библиотеку" и есть полный эквивалент.
Результат будет, возможно, даже, хороший. Но, также как с естественным языком, если учить/зубрить специально и под руководством тех людей, которые этим процессом управлять умеют — результат будут получше и получится быстрее.
вас кто то очень сильно обманул
Ну да, обычно дают не просто список слов со словами 'выучить', а еще кучу фраз и примеров, где эти слова употребляются, а потом еще заставляют не меньшую кучу употреблений конкретно этих слов сделать самостоятельно (в рамках обучения, не реального использования языка).
В любом случае с 'само выучится в процессе работы' даже близко не лежит.
Не уверен, что у вас иначе.
Базовый активный словарный запас — 1500-2000 слов. Именно их обычно целенаправленно учат. Потом человек его подтягивает до десятков тысяч слов пассивного запаса.
Ни и сколько из нас наизусть помнит 1500-2000 классов стандартной библиотеки (может сразу пользоваться ими, не залезая в подсказки)?
А десятки тысяч пассивного наберется(т.е. пользоваться не умею, но понимаю, что делает, не залезая в тот же хелп)?
В любом случае, при изучении языка программирования, я лично(может быть вы делаете иначе?) начинаю с синтаксиса+базового набора встроенных языковых конструкций. Далее, понимание общей архитектуры языка, назначение крупных библиотек. И никогда я не учу: где в каком пакете что находится — для этого у меня есть IDE, которая заботливо импортирует, я лишь, руководствуясь правилами расположения пакетов(родные-сторонние) проверю, что импорт был правильным. Может быть вы делаете иначе и зубрите все методы+все аргументы+что-где располагается, ну что ж — у каждого свой путь, но это делает вас максимально непродуктивным.
Ну и как для языка, так и для для программирования — активный и пассивный словарь имеются. И потому, скорее всего, в моем активном словаре будут некоторые ф-ии, которые я часто использую.
1500-2000 классов стандартной библиотеки
Только класс это не аналог слова, у класса может быть сотня публичных методов с разными аргументами.
«Словом» в программировании это максимум название функции без аргументов, вроде в классе Math есть функция sin вычисляющая синус, либо базовые конструкции языка (циклы, определение переменных, массивов и т.п.). Думаю, если посчитать — то 2 тыс. наберется даже у джуна.
Что меня в своё время заставило писать код качественно и стуктурированно — это моя дырявая память, когда не помнишь не то что стороннюю либу, но и свой функционал забываешь, если он нелогичен.
Другое дело, что мне и моему начальству в голову не придет писать код для прода, без гугла любых спорных моментов.
Хотя рукой рисовать может быть полезнее в плане заучивания материала — механическая память помогает зрительной.
Истина где-то по середине — что-то похожее на рисование на планшете стилусом и с последующим упорядочиванием блоков.
Пишите печатными. К счастью, в обычной жизни что-то писать нужно действительно редко.
Проще скачать рукописный шрифт и брать с собой принтер на собеседование )
дык вот же ж едят рис палочками 124 миллиона японцев и 1.5 миллиарда китайцев и не жужжажт же
Более того, очень многие едят палочками блюда японской или китайской кухни, в ресторанах их подают по умолчанию к ним. И просьба подать европейские приборы вызывает удивление часто если не у официанта, то у компании с которой ты пришёл.
Одно дело когда ты делаешь это регулярно и совсем другое когда решил попробовать ради интереса съесть комплексный обед палочками, попробуйте.
Вангую что после салата уже это начнёт превращаться в челлендж ) мышцы соответствующие не привыкшие к такой нагрузке забьются и начнут сначала ныть а к концу второго блюда даже отказывать, еда не будет держаться в палочках.
Когда пишешь от руки раз в год что то длинее чем роспись, происходит тоже самое.
Если вам непривычно писать от руки, то вам не важно как именно писать: печатными или "как в школе учили" — в любом случае будет трудно.
Однако читать потом удобнее именно печатные буквы.
Мне кажется отличный способ показать свою крутость. Пусть смотрят открыв рот и удивляются как профессионалы работают.
Есть даже такая методика работы — парное программирование.
И совсем другое дело писать тестовое задание под надзором.
И совсем другое дело писать тестовое задание под надзором.
Это вообще бред, от таких конторок надо держаться по дальше, если надзор организован не с целью помощи кандидату. А кто сомневается может попробовать встать за спиной у любого человека, который занят каким то делом, пристально на него пялиться и посмотреть чем такое кончится.
Если конечно это не в тюрьме, концлагере или типа того происходит.
=========
По статье тоже не особо понятно, если задача такова, что для ее решения существует надежный ответ в гугле или готовая нормальная либа, то именно это и нужно использовать, подправив под себя если необходимо.
Что там за задачи такие были, что полгода всё в гугле было, а потом пропало, код с гугла или СО очень редко подходит полностью, все равно обычно надо менять добавлять что-то.
Особой разницы не вижу. Более того, такое тествое исключает дальнейшие конфликты уже на работе "а чего ты гуглишь постоянно всё, что, ты и тествоое так писал?1"
Не суть. Показывая в реалтайме как ты решаешь задачи ты уменьшаешь вероятность того, что ожидания в отношении тебя не оправдаются. Лучше уж просто не получить оффер, чем получить, принять и, например, не пройти испыталку из-за твоей манеры работать.
Пока еще достаточно компаний, где такой чепухой не занимаются.
А любители шаринга пусть продолжают искать шустрых мышек, который будут вкалывать «под давлением»
Да какое давление? Давление это когда ствол на тебя направляют и говорят "если за ночь не заработает, то может тебя в Финском заливе найдут, но вряд ли!
После чего очень не люблю начальствующих мудаков
я против бумаги и за нормальную иде (типа визуал студии, что б во всём мс так тормозило!), где есть подсказки.
Насчёт встроенной справки — хорошая она была в делфи 7, больше нормального нигде никогда не видел. А! Ещё по авр доки в принципе норм (в отличие от стм, где доки и софт напоминают китайское "продать железку, сляпать х… ый софт и доки". Кстати, синовойп для банана пи м3 и то кое-как, но собирают дистрибутивы на "отъе… сь, пожалуйста", а не как стм — без уважения. Извините, наболело)
А на собеседованиях нужно было выдавать комп без инета, это 100%. Затем по желанию/возможности всё-таки сидеть рядом (напротив) для контроля смартфонов и просто очередной психологический тест на работу в коллективе.
Даже перевод на русский чаще всего вменяемый, за редкими исключениями.
Увы, но эти самые редкие исключения заставляют меня желать, чтобы перевода на русский не было вовсе...
PS. Вроде раньше там плашка висела, что на русский перевод машинный. Убрали?
целом какой-то совковый подход
Это все, что вы увидели в статье?
Как только на собеседовании заходит речь про бумагу и задачи — я сразу улыбаюсь, благодарю за собеседование и прощаюсь.
Собеседования в гугл, фейсбук, амазон, майкрософт и т.д. именно такие.
Программист-решатель задач бизнеса такая же чушь, простите, как машинист поезда-решатель задач бизнеса и скрипач-решатель задач бизнеса; такие тоже есть, но в индустриальном и пост-индустриальном обществе являются помехой.
Мысль автора абсолютно понятна. Он не говорит, что гуглить это плохо. Он говорит, что плохо гуглить и копипастить, не понимая основ и сути скопированного. И начинающему, и крутому специалисту пользоваться справочниками нормально — но при условии понимания, что ты там нашёл и как оно работает. А не вроде-примерно-подходит-контрол-це-контрол-вэ-и-в-продакшен.
Собеседование без гугления имеет своей целью проверить понимание сути. А вовсе не зазубренные имена методов, которые действительно есть в доке и IDE. Никто не ждет на собеседовании корректно работающего кода, смотрят на ход мысли.
Вы про какие то совсем вырожденные случаи, когда надо прямо идеально исполняемый код на бумаге написать, причем совсем академический — типа сортировки пузырьком?
Тоже провожу собеседования, как тимлид, и пару раз приходили разработчики с подобными радикальными взглядами. Это, правда, выглядело совсем утрировано — примеров кода нет, своих проектов нет, резюме состоит из закопанных или закрытых продуктов. Шарить экран во время собеседования не готов. Тестовое задание на написание микро-проекта, в любое удобное время без какого либо контроля, с обсуждением написанного — не согласен. И я не могу никак понять, из чисто голосового обсуждения базовых принципов языка и контекста — что это за специалист. Он может наизусть знать определения терминов, но совершенно не понимать как их применять. Компания небольшая, брать каждого желающего на испытательный срок — дорого, да и каждый новичок это нагрузка на команду разработки. При этом ребята искренне недоумевали, почему я хочу от них такого табу как тестовое задание. Видимо начитались статей, где говорят что тестовых задач делать никогда не надо, а за просьбу что то написать в прямом эфире — надо сразу в окно убегать. Еще раз — мне бы хватило любой демонстрации скиллов для дальнейшего обсуждения, но их не было ни в одном виде.
P.S. Ручка и бумага подразумевают, по моему опыту, не знание синтаксиса, а проверку хода мышления, хоть метакод набрасывай, хоть диаграммы рисуй, лишь бы понятно было куда мысль идет.
На мой взгляд, человека который и собеседует и собеседуется, такой подход в среднем уменьшает вероятность, что я как то совсем по разному с работодателем понимаю программирование, и не выясню это в середине испытательного срока, потеряв в итоге больше времени.
Я про крайние случаи, когда программист не показал вообще никакого кода, только софт скилы. Если есть репозиторий в гитхабе например, и там хоть немного релевантного кода, да даже тестовые задачи для другого собеседования — всё замечательно, будем их обсуждать, зачем писать что-то ещё.
Сам хожу по собеседованиям периодически, и места где мне сразу предлагают устраиваться на работу настораживают. Как люди могут рассчитывать, что часа общения достаточно, чтобы проработать вместе несколько лет?
Иногда испытательное нужно, иногда нет. Вот такие заявления радикальные "если видите тестовое задание/белую доску/бумагу с ручкой/юникс админа без бороды — сразу уходите" они могут кому-то чересчур внушаемому больно аукнуться.
Соглашусь, что если тестовое задание требует сходу HR, не вникая есть там у кандидата что показать или нет — да, это плохой признак.
Не очень хороший признак, когда на позиции сеньор+ требуют тестовое раньше интервью с менеджментом: непосредственным начальником, ПМом и т. д.
Всё верно, просто мне со своей колокольни опыта веб-разработки и контекста статьи казалось что речь про продвинутых джуниоров/мидлов. Если я где-то потерялся по пути к этому комментарию — прошу меня простить.
Разве в контексте статьи есть намеки, что это не про сеньоров?
Сам процесс собеседования, стиль общения тимлида, и обороты вроде "застыли на уровне стажёра", в моей практике сеньоры как то сразу проходят мимо этого уровня. Если статья про сеньоров то мои комментарии совсем не в кассу. nmivan, подскажите пожалуйста, какие вакансии должны были закрыть специалисты описанные в статье?
Вот только если человек знает все из головы, он в долгосрочной перспективе будет решать задачи бизнеса лучше. Потому что гораздо быстрее разберется в ситуации, когда гугл не спасает. И да, написание кода на листочке, без подсказок ide — неплохой способ проверить эти знания. Может потому раньше софт и был оптимизированнее и стабильнее, из-за этого ненавидимого вами "совкового" подхода? У вас логика студента, которому лишь бы списать на зачет, а не научиться чему-то. Ноль творчества или повышения квалификации
Вот только если человек знает все из головы, он в долгосрочной перспективе будет решать задачи бизнеса лучше. Потому что гораздо быстрее разберется в ситуации, когда гугл не спасает. И да, написание кода на листочке, без подсказок ide — неплохой способ проверить эти знания.
Ну уж прямо. я например из головы ооочень много чего знаю но при этом синтаксис зачастую не помню, например, ситуация из жизни. Коллега программист несколько дней пытался понять почему у него фризы в сервисе… а мне было достаточно взглянуть на логи чтобы понять что это dns недоступен на одном из серверов балансировщиков nginx и сервис подвисает до таймаута обратного запроса к dns при этом ни слова не пишет в логах что ему плохо.
При этом он может на бумажке огромные программы писать по памяти, а я гуглю синтаксис как питоновский враппер сделать (в работе это не часто встречается у меня).
«решать бизнес задачи лучше» — это не знать наизусть язык программирования, а вообще иметь кругозор чуть шире своей узкой области. а все остальное можно нагуглить.
Я довольно часто вижу программистов которые не знают ничего глубже своего языка вообще, SQL — как ни странно редкость (вообще свидетели-ORM сейчас плодятся и это печально), понимания хотябы основ devops — тоже нечастое явление…
Тем более обычно просят совсем примитивные вещи вроде перевернуть строку или обойти дерево.
Разве на собеседовании не возникло ни одного вопроса, ни желания обсудить реализацию с кандидатом, предоставившим решение (хоть и идеальное), что сразу позволило бы определить, что человек не сам писал код. Разве за 3-6 месяцев не возникло ни одного обсуждения рабочих вопросов, обсуждения пулл реквестов, позволяющих понять, что человек совсем не в теме того, что пишет?
Ну еще нюанс что по 1с в сети готовых решений нет почти, ни просто в текстовом виде на SO, ни готовых библиотек и приходится из головы многое писать. Плюс проблема с переиспользованием кода по разным причинам (сложившиеся практики, сам язык мешает это делать).
От вендора есть решение в виде перепиленного эклипса, но работает не сказать что идеально, да и им почти никто не пользуется насколько знаю, ибо выстроенные процессы ломать не хотят, да и железо там нужно дикое чтобы хорошо работало.
Очень рад что теперь пишу на котлине с использованием нормальных инструментов. В 1с даже гит распространения не получил пока.
В смысле IDE? Эта дрянь даже в 2020 еще не научилась работать через language server с любой современной IDE хотя бы с VSCode?
«Спорить о вкусе устриц с тем, кто их пробовал… До хрипоты, до драки». © Михаил Жванецкий
Всё там нормально с подсказками в 1С. Не так здорово, как в языках со статической типизацией, но получше, чем в языках с динамической типизацией.
Получше за счет того, что в 1С вы пишете не просто голый код, а код, привязанный в метаданным предметной области. И IDE 1С умеет вам давать подсказки не только по голому языку, а прямо по структуре базы данных, которая используется в конкретной задаче.
Говорю как человек проработавший 4.5 года с конфигуратором и пощупавший немного EDT и почти 2 года проработавший с Android Studio.
Тогда можете и конкретику?
P.S.:
Довольно странно сравнивать те возможности, что может дать IDE для языка со статической типизацией Java. Честнее будет сравнивать с JS, Python.
Не стоит забывать, что 1C это интегрированная система, где интерфейс, БД и код связаны воедино и обновление новой версии накатываются одной кнопкой ровно под одну конкретную версию прикладного решения. И универсализм Android Studio просто не нужен.
Впрочем, если речь идет об разработке оконченного решения на 1С, когда работает множество программистов, нужно множество веток (как в git) и работа над проектом по частям — да, IDE 1C не лучше Android Studio.
Однако когда речь идет о поддержке у конечного пользователя, а не об разработке готового продукта — как раз удобнее идеология 1С IDE, где БД+GUI+код оставляют единое целое в дереве метаданных.
EDT и сейчас еще в активной разработке. А то, с чем вы могли работать несколько лет назад — это какая-то пред-альфа, зачем на неё ссылаться?
Что касается остального сообщения — спор начинать не хочу, уже не раз в него встревал, но мы сейчас обсуждаем именно конкретные проблемы, заставляющие кучу лишнего в голове держать, так что аргументы о доработке у клиентов, запуске одной кнопкой и прочему мимо, они эту проблему никак не решают.
Ну а EDT уже лет 5 в разработке и все никак. Да и уступает эклипс идее.
Плюс даже для динамически типизированных языков разные эвристики есть по выводу типов аргументов и результатов вызова функций, но, само собой не в 1с.
Неправда ваша. В некоторых случаях в 1С подставляет с использованием типов. В тех случаях, когда речь идет о метаданных из БД, например.
Ну а EDT уже лет 5 в разработке и все никак. Да и уступает эклипс идее.
IDEA уже лет 20. И это лучшее, что есть в мире.
Экслипс тоже помнится пока взлетал — люди матерились годами и удивлялись как же можно такой долгострой делать. Более менее юзабелен он стал версии к 3-й, но уступал IDEA всегда.
Угу. Именно что в некоторых. С эвристиками нормальных IDE не сравнить, они и в вызываемую функцию сходят посмотрят что она возвращает, а если она чего то вызывает — то и туда сходить могут.
Не выдумывайте ерунды.
Вы работали в этих «нормальных» IDE только с языками со статической типизацией, полагаю?
Качество подсказок для того же JS в той же IDEA по сравнению с Java — просто небо и земля.
Другой вопрос, что сам LSP и debug protocol еще не являются промышленным стандартом, и авторы реализаций языков не слишком заморачиваются с его поддержкой — зная как 1С поддерживала промышленные СУБД, lsp ожидаем где-то к колонизации Марса 8)
Вообще обалдели, от php-разработчиков знания типов требуют.
В асм (x86) разве уже завезли типы?
Типы-то завезли, а вот проверку типов не завезли.
Где там типы? Пускай и без проверки. Какая-нибудь ADD AX, BX понятия не имеет, что в регистрах написано — числа, адреса, смещения, строки...
Почти любая инструкция ассемблера ожидает данных в определённом формате.
fadd m32/m64 ожидает данные формате с плавающей точкой, fiadd m32/m64 — в целочисленном формате. И плюс в обоих случаях есть разница, 32 или 64 бита. Нельзя путать эти инструкции, хотя все они — сложение ST(0) с операндом в памяти. Если перепутать, результат будет неверным (почти всегда, за исключением разве что случая побитового совпадения "нуля" в этих форматах, если числа одинаковой длины).
Что значит "неверным"? Что найдёт в операндах, то и сложит по правилам того или иного формата. И результат будет верным по правилам этого формата. Дело не в том, что типы не проверяются, а в том, что нигде вообще нет информации о типе, проверять нечего. Одно и тоже значение может быть интерпретировано как любой "ассемблерный тип".
Изменения я внёс очень простые – теперь люди писали код не на бумаге, а на компьютере.
Первая мысль была — «интернет-то отключили?». Нет, не отключили. И судя по тому, что до конца статьи эта идея так и не была озвучена — даже в голову не пришла. Это же значит — опять будете собеседовать на бумажке. Воистину идиот.
Телефоны тоже отбирать?
2) IDE — это понятие растяжимое. Для меня — это vim, многие emacs используют, некоторые vscode, sublime, eclipse и даже Kdevelop.
На каком из IDE должно проверяться тестовое задание?
Фейспалм. Не знаю, что там у вас за галера (подозрения рождаются при рассказе о бывших коллегах с собственным 1С бизнесом), но нормальные люди не захотят с вами работать. Фейспалм.
И таки да, если сравнивать этот период с периодом, когда у меня появился интернет (вторая половина 90х), то он был просто ужасен. Как по скорости обучения, так и по качеству выдаваемого кода (и количеству велосипедов тоже).
Еще кто-то из старых (по-моему Джон Соча) сказал: «Если вы хотите научиться программировать, посмотрите, как это делают другие».
ИМХО, автор не разделяет тех, кто кроме как содрать сэмпл со стековерфлоу, воткнуть его себе в код и посмотреть, что в итоге получится, не могут ничего. Отличить их от «настоящих» на собеседовании не составит особого труда — достаточно поставить нетривиальную задачу (или просто хорошо изменить/замаскировать любую популярную).
И другой тип людей (программистов), которые используют пресловутый гугл (стековерфлоу, гитхаб и т.п.) для того, чтобы получить новую информацию — КАК это делают другие, сравнить со своим кодом, возможно что-то поменять в нём в лучшую сторону, применить приёмы о которых они ЕЩЁ не знали, поделиться своими наработками с сообществом.
Гугл позволяет обмениваться информацией между программистами чуть менее, чем со скоростью света. И это здорово.
Хех, я делал курс по C в открытом университете Израиля, первый экзамен я завалил, так как он был составлен так, что если ты от корки до корки не прочитал книгу и не знаешь где искать ответы на специфические вопросы (на экзамен можно было приносить эту книгу) то ты его не сдашь.
Если вам нужно, чтобы программисты на собеседовании решали задачи — то не надо ставить им задачи, решение которых можно нагуглить. Но да, это означает, что к собеседованию нужно готовиться. Удивительно, правда?
Еще из текста следует, что выход на плато продуктивности — это следствие гуглящих программистов. А если бы из головы — то их продуктивность росла бы, пока не проткнула собой небесный свод. Агащасконечно.
Но да, это означает, что к собеседованию нужно готовиться. Удивительно, правда?
К каждому?
И как вы предлагаете интервьюверу готовиться к собеседованию? придумывать на каждое собеседование задачки которых нет на сайтах олимпиадного программирования?
Обычно подготовка подразумевает — прочитать резюме и составить список уточняющих вопросов по резюме.
И да, придумывать задачи, которых нет на сайтах.
Автору же нужны негуглящие программисты (что, по-моему, глупость, но у каждого свои заморочки. Кто-то любит боль, кто-то двойное проникновение, кто-то негуглящих программистов — имеет право), для этого ему и нужно готовиться к собеседованию своеобразным образом.
А вопросы по резюме — это не техническое собеседование.
я на когда собеседования проводил — вообще тестовые задания не давал. Максимум на поразмышлять на тему прикольных кейсов с которыми столкнулись в проекте.
например.
«Как бы вы заимплементили errno. Почему так?»
Ну почему вопросы разными бывают по резюме. Я часто по проектам спрашиваю детали и примерно половина плавает. Ну то есть ключевые технические вещи. У чувака, например, был какой-то балансер в списке проектов, я спросил какой алгоритм балансировки он использовал там и структуры данных для него, а он вообще ничего внятного сказать не смог.
Я вообще последние года два прошу сначала с менеджером поговорить, а уж потом по технической части, если у менеджера и меня останется ещё желание работать вместе. Исключает многие конфликты или просто неудобные ситуации потом.
Если на сеньора и выше, то наверное не стоит спрашивать про красно-черные деревья.
А то ни одного кандидата не останется )))
Зависит от компетенции кандидата. Если на сеньора и выше, то наверное не стоит спрашивать про красно-черные деревья. Если же на интерна, то вполне можно порасспрашивать по теории. А что еще их спрашивать…
А вот это, кстати, интересно. А почему? Мне казалось, что наоборот — джуна можно не спрашивать про глубокие вещи, а просто можно убедиться, что хоть как-то код пишет.
А вот если сеньор не может оперировать понятиями типа "сложность алгоритма", то это автоматом нивелирует всю сеньорность (как мне казалось).
Говоря другими словами: в этом и суть разделения уровней: кто-то знает и умеет мало, а потому уровень X (что означает ответственность и пр), а кто-то знает и умеет много, а значит уровень Y.
Причем не сомневаюсь что если таки книжечку пройду — мне это и в практике полезно будет. То же наверно и со всякими деревьями. В каких нибудь сложных задачах можно будет увидеть общие черты между задачами и решить схожим образом.
Ну я вот на днях книжечку начал читать о динамическом программировании. Там первым примером как раз нахождение фиббоначи было. Я конечно и до сеньера пока не дотягиваю, и даже на мидла под вопросом, но потому всякое разное и читаю/слушаю иногда.
Ну так о том и речь. Были бы вы сеньором — вы бы эту книжку давным-давно прочли и к настоящему моменту уже забыли. Не обязательно, конечно же — но вполне возможно.
вы бы эту книжку давным-давно прочли и к настоящему моменту уже забыли
Если прочитать и забыть, то чем это отличается про "не читать"? Я вот забыл номер телефона своего знакомого, для меня это слабо отличается от "не знаю номер телефона этого знакомого".
Если сеньор запомнил определенные пункты из этой книги, то ничего больше на собеседовании и не потребуют. Например, если на вопрос про B*-дерево кандидат ответит что-то в стиле "я не помню, но это, вроде, такое дерево, где глубина у всех нижних элементов одинакова. Оно, вроде, еще очень ветвистое. И, как я помню, они применяются в файловых системах и базах данных", то это будет абсолютно корректный ответ (точнее, по моему опыту нахождения с обоих сторон интервью).
Если же "сеньор" на вопрос выше про деревья (не В, а просто деревья) ответит "я бизнесу помогать пришел, а этой вашей * заниматься" или "я не знаю, читал, но забыл", то лично у меня было бы сильное подозрение, что вряд ли вообще знал (и я запросто смогу ошибиться).
Если прочитать и забыть, то чем это отличается про "не читать"?
Ничем. Среднему программисту на самом деле нет необходимости знать ни числа Фибоначчи, ни B* деревья, на работе он не будет писать ни то, ни другое. Это всё — не более чем учебные примеры.
Разумеется, это не означает, что сеньор "имеет право" забывать то, с чем он работает каждый день. Скажем, если программист хоть немного пересекался с базами данных и оптимизацией запросов в них, он должен помнить что самый популярный тип индекса называется B-деревом и его примерные свойства, чего должно хватить чтобы достроить остальное на основе своих познаний в программировании. Но не следует ожидать, что ответ сеньора будет более полон чем ответ вчерашнего студента, который всего год или два назад сдавал по базам данных экзамен.
Но не следует ожидать, что ответ сеньора будет более полон чем ответ вчерашнего студента, который всего год или два назад сдавал по базам данных экзамен.
Почему? Я вот как раз ожидаю того, что вчерашний студент ответит голую теорию. Например, про статистику в базе данных он просто ответит в стиле "как-то применяется в оптимизаторе запросов" (хотя я считаю, что этот вопрос уже выше требований, ну да ладно). Тогда как сеньор скажет детальнее, как корректная статистика влияет на запросы. И сможет показать, просто на основе этого факта, почему при очень больших таблицах оптимизатор может выдавать неэффективный план чаще.
Для вопроса про "процессор и спекулятивное выполнение" я бы ожидал от джуна даже просто не совсем корректной теории, вроде "пытается угадать результат if'а". Тогда как от сеньора я бы ожидал вдобавок еще примеры из жизни, например "это помогает в оптимизации условий assert'ов, а еще Java/.Net расставляют подсказки на основе своих замеров, чтобы все ускорить типичное выполнение кода; как следствие — не всегда стоит переконфигурировать систему после старта, если говорить о сверкритичных по скорости вещах". Хотя, этот вопрос я бы тоже не задавал ни джуну, ни сеньору.
Скорее всего, я бы задал вопрос про деревья, в стиле "как может помочь структура 'дерево' решению задач". И от джуна я бы удовлетворился ответом в стиле "у них скорость поиска log N", тогда как от сеньора я бы ожидал "скорость поиска log N, причем основание этого логарифма зависит от типа дерева, например, для файловых систем часто используют большие основания, то есть деревья ветвистые, но для поиска в памяти они работают зачастую менее эффективно, так поиск на каждом ярусе занимает M, а не log M в общем случае, а значит логично использовать бинарные. А еще есть всякие цифровые деревья, которые можно использовать для матчинга url с роутом (маршрутом) в web приложении, хотя тот же Spring Flux (который самый новый) использует тупое сравнение с общей сложностью min(M*N)^2, где M — средняя длина маршрута в приложении, а N — длина URL'а от пользователя".
Повторю тезис: если от джуна ожидать теории, то от сеньора надо ожидать теории и практики. Если от сеньора не ожидают теории, то от джуна её тоже не надо требовать.
Тогда как сеньор скажет детальнее, как корректная статистика влияет на запросы.
Да. Но он при этом не сможет с ходу рассказать как B-дерево устроено внутри, потому что он занимался работой с СУБД, а не написанием B-деревьев.
Да. Но он при этом не сможет с ходу рассказать как B-дерево устроено внутри, потому что он занимался работой с СУБД, а не написанием B-деревьев.
Сеньор не сможет рассказать идею B дерева? Это сейчас шутка или сарказм такой?
Сразу оговорюсь — если из всех деревьев программист не слышал именно об этом, то такое случается, тут нечему стыдиться. Если же "сеньор" не сможет вообще ничего рассказать ни о каких видах деревьев, то вот вешать на него эту лычку я бы не стал в общем случае. Да, бывают редкие-редкие исключения, наверное, когда человек идеально разбирается в IT системах, но вот конкретно этот пункт не знаком. Я такого не встречал, к сожалению.
Мне кажется, мы разошлись немного в понятии слова "сеньор". По моим заметкам, кроме всяких там реактов и растов, человек должен еще обладать достаточным кругозором в IT (чтобы иметь возможность выбирать стек и технологию, а не просто кодить на одном и том же языке), а также должен обладать фундаментальными знаниями в этой области. Иначе просто-напросто не получится систематизировать эти знания, и получается скорее такая реализация цепи Маркова (когда человек просто заучил ответы на некоторые комбинации входных фраз).
На хабре тут уже приводили пример, как рендеринг React приложения можно сделать случайно за O(N^2) (самый простой случай — перерисовка полного состояния при бесконечной верстке). И вот "сеньор" должен видеть такое сразу (и в более сложных сценариях тоже), в моем понимании. И из-за этого и вырастает требование по алгоритмам и пр.
По моим заметкам, кроме всяких там реактов и растов, человек должен еще обладать достаточным кругозором в IT
Я тоже считаю что должен. Но нет никаких стандартов на кругозоры, любой наперёд выбранный вопрос запросто может не входить в кругозор хотя бы одного сеньора и это нормально.
Очень частое применение деревьев в стандартном веб-девелопменте — меню и каталоги товаров. А также другие иерархические справочники а-ля страны/города. Про DOM я уж молчу.
Аналогия ошибочная. Примерно как сказать что знание ООП требует знания поиска в бинарных деревьях, т.к. структура классов — это дерево.
Макс фон Лауэ
Не так важно приобретённое знание, как развитие способности мышления. Образование есть то, что остаётся, когда все выученное забыто.
Для тех кто не знал — это цитата физика XIX-XX веков, нобелевского лауреата.
Я правильно понимаю, что она является истиной (с Вашей точки зрения) и в доказательстве не нуждается? Ну то есть Вы советуете dominigato не спрашивать не только синьоров про красно черные деревья, но и джуниоров, так как главное — это сообразительность, верно?
Можно спросить dominigato — Вы прислушаетесь к мудрости предков и перестанете спрашивать людей про алгоритмы и технологии, верно?
А вот сеньер как по мне знать должен. А если не знать — то уметь вывести из того что знает.
Окей, тогда Вы тоже на моей стороне. Я утверждаю, что множество ожидаемых знаний от кандидата-джуниора должно быть подмножеством ожидаемых знаний от кандидата-сеньора. Соображалка тут ортогональна им, это отдельное требование, как и разрешение на работу.
Вы привели отличный пример — на старте карьеры (если я Вас правильно понял) требования были ниже, чем в будущем. И тут все корректно, вопросов нет.
Может и должно, но из этого не следует, что сеньора надо проверять на собеседование по подмножеству знаний джуна. Это, в теории, проверили когда брали его джуном.
Может и должно, но из этого не следует, что сеньора надо проверять на собеседование по подмножеству знаний джуна. Это, в теории, проверили когда брали его джуном.
Ну если сеньор скажет что-то "для TreeMap надо переопределить hashCode" или "для HashSet надо определить компаратор", то я вот поспрашиваю теорию еще. Так как меня будут терзать смутные сомнения.
Я повторюсь — для сеньора требования будут более глубокими. Например, если человек с 10 годами опыта написал "работал с большими базами данных", я спрошу "зачем нужна статистика". И этим вопросом заранее подразумевается, что человек ответит еще и про сложность структур данных, которые может использовать SQL.
Если же на вопрос выше будет ответ "нууу типа работать должно правильнее со статистикой", то это скорее будет означать, что знания у человека крайне поверхностные, а под фразой "работал с технологией Х" скорее стоит понимать "работал в проекте, где была технология Х".
Другой пример — спросить про "когда в Java/.Net наивная реализация toString/ToString выдаст O(N^2) по памяти, где N — это результирующая строка". Наивная реализация в моем описании — это функция вида return StringUtils.join(field1, field2, field3, ...). Ну и, конечно, у каждого field одинаковая ненулевая длина toString (для простоты вопроса). От сеньора знания по сложности требуются по-умолчанию.
Еще пример — спросить, как в React приложении можно получить сложность отрисовки O(N^2) (N — число элементов в результирующем dom дереве).
«для HashSet надо определить компаратор»
А с этим в чем проблема? Не редко бывают случаи, когда нужно либо несколько компараторов завести для одного набора данных, либо когда GetHashCode и Equals уже были переопределены для основной задачи.
Хотя для уточнения: вы про IComparer, или вы про IComparable, который для класса определяется? Я про первый.
Наивная реализация в моем описании — это функция вида return StringUtils.join(field1, field2, field3, ...)
PS. Понял про что вы, реально неприятная особенность у StringUtils.join. Не буду остальное удалять, жалко.
Вы точно с конкатенацией в цикле не перепутали? Обычно этим массово грешат.
На .NET StringBuilder конечно пошустрее будет, но чаще всего достаточно банальной интерполяции или String.Concat. Просадка по времени компенсируется читабельностью кода.
Конечно можно подогнать особенности хранения строк в .NET и приколы со сборщиком мусора, который совершенно не хочет удалять большие строки. Ну и прочие уловки с прямой записью через MemoryStream при подготовке данных на экспорт, но с этим на практике-то сталкивались единицы, а уж в теории оно встречается еще реже.
Хотя для уточнения: вы про IComparer, или вы про IComparable, который для класса определяется? Я про первый.
Эээ, насколько я знаю, TreeSet нет в C#, речь идет явно про Java, а IComparer и IComparable это явно не про Java (если только про какую-то очень редкую библиотеку).
А с этим в чем проблема?
Для HashSet (в Java) бесполезно переопределять компораторы, так как порядок элементов там не определен.
Эээ, насколько я знаю, TreeSet нет в C#, речь идет явно про Java, а IComparer и IComparable это явно не про Java (если только про какую-то очень редкую библиотеку).
У вас там про HashSet было написано. И ниже про Java/.NET. Да и хэшсеты врятли сильно отличаются между этими платформами.
Для HashSet (в Java) бесполезно переопределять компораторы, так как порядок элементов там не определен.
Порядок и в .NET не определен. В .NET оно нужно для сравнения элементов, особенно помогает для сложных ключей, что бы дубликаты не хранить, когда объекты разные, а данные одинаковые, либо ключи нужно извлечь напрямую из строки данных. Часто бывает нужно при работе с Flat-файлами, особенно, когда по 2-3 поля в сцепленном ключе на другие файлы и нужно быстро кэш из ключей построить, что бы потом данные потоково перелопачивать.
Одна аккуратная реализация компаратора для HashSet дает сразу:
1. Корректную и быструю проверку на Contains;
2. Корректную проверку ключей, когда они являются разнымит объектами в памяти (это и HashSet, и Dictionary, и прочие коллекции с хэшированием);
3. Гарантирует только уникальные данные в хэше, без каких либо дополнительных телодвижений.
vedenin1980 правильно ответил — для HashSet порядок элементов не определен, так что Dictionary (т.е. HashSet от .Net) не требует именно IComparable, а требует IEqualityComparer — см. тут.
Я плохой вопрос написал (понятно, что комментарии пишутся быстрее, чем вопросы к собеседованиям), но вот суть быстро можно понять: для HashSet не будет требоваться никакой поддержки сравнения элементов. А для TreeSet не требуется хешкод. А потому если вдруг "сеньор" так оговорится, то я спрошу чуть детальнее, что как и почему.
Вы точно с конкатенацией в цикле не перепутали? Обычно этим массово грешат.
Вот потому я и написал вопрос. Люди знают простой пример (я ниже расписал), и не могут его обобщить зачастую.
Итак, стандартный вопрос на собеседовании — что не так с циклом ниже:
var result = "";
foreach(var s in fields) {
result += s.ToString();
}И я думаю сейчас уже все скажут про O(N^2) и пр.
Давайте усложним сценарий: мы будем вызывать ToString у объекта, которые имеет много внутренних подобъектов. Т.е. для классов с большим уровнем вложенности полей, где можно вызывать что-то вроде return a.B.C.D.E.F. Если в каждом классе только одно поле, то на самом деле мы напишем код, аналогичный циклу выше — мы будем абсолютно в таком же духе складывать строки, просто наш цикл "будет статическим и размажется по разным классам". Я видел один раз проблему с таким подходом, так как из-за большой глубины вложенности код работал как O(N*log(N)), а не O(N). Ну и по памяти тогда сильно било подобное.
И вот если мы говорим про сеньора, то такие фокусы данный человек обязан ловить еще на стадии дизайна системы (с моей точки зрения). А потому я и сказал выше, что базовое понимание сложности все-таки должно требоваться (в рамках разумного, очевидно). Опять-таки — это в моей системе ценностей, и по моему мнению.
не требует именно IComparable, а требует IEqualityComparer — см. тут.
Перепроверил сейчас что я использую в проекте, да — это конструктор с IEqualityComparer. Компаратор? Компаратор, только другой. Издержки языка и сленгового перевода терминов, в условиях, когда ты не помнишь точное название интерфейса. Слава IDE(:
Давайте усложним сценарий: мы будем вызывать ToString у объекта, которые имеет много внутренних подобъектов.
DEL
И вот если мы говорим про сеньора, то такие фокусы данный человек обязан ловить еще на стадии дизайна системы (с моей точки зрения). А потому я и сказал выше, что базовое понимание сложности все-таки должно требоваться (в рамках разумного, очевидно). Опять-таки — это в моей системе ценностей, и по моему мнению.
На вопрос в исходном виде, за пару минут он об этом даже не подумает, без наводящей информации и общей бредовости того ответа, который вы ожидаете услышать. Переопределение (override) ToString? Кажется что-то в проекте пошло не так.
Сериализация на костылях? Опять кажется что-то пошло не так.
Давайте усложним сценарий: мы будем вызывать ToString у объекта, которые имеет много внутренних подобъектов. Т.е. для классов с большим уровнем вложенности полей, где можно вызывать что-то вроде return a.B.C.D.E.F.
За-то от такой формулировки сразу волосы дыбом встают. А раз это реальная реализация была, то сразу хочется спросить: сколько лет тому легаси было или это кто-то втихую накрутил велосипедов? Даже без оценки на О, это говорит об очевидных больших проблемах с производительностью. Оно же у вас явно крутилось на сериализации данных, раз расходы по памяти стали критичными, т.е. велосипед с квадратными колесами для велосипедиста на костылях:)
Например большинство людей, имеющих водительское удостоверение, имеют смутное представление о многих правилах дорожного движения, скажем правила разъезда с трамваем (если каждый день не ездят по трамвайным путям) или жесты регулировщика (это учтено в правилах — «Регулировщик может подавать и другие понятные участникам движения сигналы ...»), тем не менее аварий происходит удивительно мало (правила проезда перекрестков знают практически все). При приёме водителя на работу ему экзамен не устраивают — интересует наличие категории и опыта работы.
А ценность учёбы (в той или иной форме) я не отрицаю — именно при этом происходит развитие и приобретаются необходимые знания, навыки и опыт.
Спрашивать-то можно о чём угодно, только надо уважать и ценить великую способность человека — забывать.
Я не понимаю Вас… Я говорю, что требования к сеньору должны быть строго серьезнее, чем требования к джуниору.
Если мы спрашиваем про Х у джуниора, и надеемся, что он все помнит, то значит можно спрашивать про Х у сеньора. Более того, я скорее поверю, что 20летний будет стрессовать, чем 30летний.
Если Вы согласны с моим посылом, однако, просто хотите сделать ремарку, что знания необходимо опрашивать грамотно, то, наверное, надо так про согласие и написать.
Например большинство людей, имеющих водительское удостоверение, имеют смутное представление о многих правилах дорожного движения
Программисту платят достаточно, чтобы было больше знаний, чем у водителя машины. Я бы с Вами согласился в обсуждении собеседования таксистов. А к программистам, нейрохирургам и другим специальностям с высокой оплатой, обычно, предъявляются более серьезные требования.
Спрашивать-то можно о чём угодно, только надо уважать и ценить великую способность человека — забывать.
Если вы сеньор, то вы можете уже и не помнить про пирамидальную сортировку. Ничего зазорного в этом нет.
Но в свободном разговоре на темы архитектуры ИТ-систем будет всё равно видно сеньор вы или нет.
Я не знаю почему для вас так тяжело понять простую мысль — люди лучше всего помнят и знают то, что они или учили недавно или тренировали в течении долгого времени вплоть до сейчас.
Я вот учил про деревья больше десяти лет назад. Узнал про разные виды хеш таблиц тогда же. И последние лет 10 я не написал ни одной реализации ни дерева, ни хеш таблицы. А ваши "сеньоры", почему-то, все резко забыли. Так как я далеко не гений, выходит, что или у меня сверхпамять (что не так), или что люди на собеседованиях часто говорят "ну забыл" тогда, когда правильно сказать "да, в общем, и не знал никогда".
Более того, с моими коллегами я могу довольно свободно говорить и про деревья, и про сложность сортировки и про прочие алгоритмы. Отсюда я получаю еще одно подтверждение, что Вы преувеличиваете забывчивость человека.
Условно, от опытного врача я ожидаю бОльших знаний по предмету, а не меньших.
Если вы сейчас с ходу под стрессом за время интервью (не больше часа) напишете реализацию алгоритмов, которые вы учили 10 лет назад и не использовали — поздравляю. То ли у вас суперпамять, то ли вы с тех пор ничего нового не выучили.
А у вас джунов просят написать по памяти реализацию дерева на собеседовании за час? Если да, то уже собеседование какое-то дикое.
Обычно, на собеседовании максимум просят написать класс "хеш таблица" и определить метод Add (ну или максимум — еще и Delete) с корректной асимптотикой (константа не важна, естественно). С этим сеньоры прекрасно справляются.
По вашим словам, джун на пятом в своей жизни собеседовании более стрессоустойчивый, чем сеньор, у которого и авралы были, и продакшн падал и пр. (если мы говорим не про 20летних сеньоров, конечно).
На самом деле хорошо ответил Amomum в соседнем топике:
Я бы очень удивился, если бы в ответ на этот вопрос ожидали услышать все в подробностях, а не что-то вроде "красно-черное дерево — это бинарное дерево, в котором узлы условно делятся на красные и черные, и в котором всегда соблюдается некий инвариант (который я сейчас не помню), при каждой операции, благодаря чему дерево всегда сбалансировано".
Если человек отвечает что-то в этом роде, то дальше можно спросить, зачем вообще нужны деревья, зачем их балансировать, какие есть альтернативы — на мой взгляд это просто позволяет узнать, изучал ли человек алгоритмы и структуры данных вообще, а если изучал — то зубрил определения или ухватил суть.
Если ожидается точный ответ как по учебнику, то это другое дело, конечно. Но сам вопрос по мне так вполне нормальный.
С моей точки зрения, на уровне сеньора вам нужны нефункциональные характеристики всех этих алгоритмов. Грубо говоря, чтобы распознать момент для применения TreeMap вместо HashMap.
А вот джуну и мидлу да, обычно достаточно для стандартных вещей помнить/уметь прикинуть временную и сложность по памяти.
Сеньер как по мне не обязан помнить детали реализации, но обязан понимать подходы лежащие в основе этих алгоритмов, уметь распознавать соответствующие задачи где эти подходы применимы, и соответственно применять.
Еще раз: разговор зашел с того, что о некоторых вещах джуну знать обязательно, а сеньору — нет. Именно с этого.
Сейчас же Вы говорите, что сеньор обязан знать больше и глубже. А это уже подтверждение тезиса того, что если сеньор не может решить задачи джуна, то это как минимум не сеньор (ибо не знает даже поверхностно), и не джун (ибо не знает хотя бы поверхностно).
Потому что если сеньор занимается красно-черными деревьями он делает что-то не то.
А если джуниор будет кодить красно-черное дерево, это он будет "делать то"? У меня вопрос-то хитрее: почему от джуниора требуют тех знаний, которых не требуют от сеньора?
Я бы понял ответ в стиле "сеньор на описании дизайна системы и так продемонстрировал знание алгоритмов", однако, в этом случае мы все-таки требовали знания у синьора.
Или я бы понял ремарку "у сеньора мы все равно спросим, что лучше — TreeMap или HashMap", так как для их сравнения надо знать про красно-черное дерево (хотя бы в общих чертах). Однако, тут так же мы от сеньора требуем надмножество знаний джуна.
Я уж не говорю, что есть старая схема (не ручаюсь за её корректность) — "если не можешь написать простой алгоритм, то зачем нам тебе доверять написание системы?" Как мне казалось ранее, все алгоритмы спрашивают ровно по этому — прежде чем комбинировать программу из кусков, продемонстрируй, что хоть немного разбираешься в этих кусках. Повторюсь — не ручаюсь за корректность, но, по моим наблюдениям, из этой фразы строятся гугловые собеседования.
Вам просто нужно отличать гуглеж незнающего человека от гуглежа непомнящего человека :)
Когда пишешь на 4-5 языках практически одновременно (на чем-то по работе, на чем-то в качестве хобби, а что-то просто изучаешь), и у всех одна и та же стандартная функция из библиотеки называется по-разному, то легче бывает нагуглить, чем вспоминать.
Поэтому нужно не тестовые задания давать, которые человек решит с помощью стаковерфлоу и такой-то матери, а устно задавать вопросы, без привязки к какому-либо языку.
Вам просто нужно отличать гуглеж незнающего человека от гуглежа непомнящего человека :)
Когда пишешь на 4-5 языках..., и у всех одна и та же стандартная функция из библиотеки называется по-разному, то легче бывает нагуглить, чем вспоминать.
-инет, +иде, как я недавно написал выше.
один раз пришлось разрабатывать проект под четыре платформы: веб, десктоп, микроконтроллер и fpga вместе с их схемотехникой, вот там такая каша в голове стояла… И даже не помогло то что я смог чтобы всё генирилось из одного си исходника, всё равно вылезло столько нюансов и мелочей, что я стал сомневаться в самых популярных функциях стандартной библиотеки. И реально если бы не гуглил и не сверял с доками любое казалось бы тривиальное поведение, то утонул бы в отладке.
И к сожалению нередко собеседованиях встречал фирмы, которые спрашивали именно знание наизусть этих мелких нюансов и имён функций при рядовом фулстеке: веб, десктоп, микроконтроллер.
Вдохновляет.
И да, я просто поделился своим опытом свежим.
Так испытательный срок на то и испытательный, чтобы убедиться, что человек может делать работу.
Или не может.
" тут уже вопрос — сам он его сделал, нагуглил или его приятель Вася помог"
А какая разница КАК была сделана работа, если она сделана и есть результат?
Если я не умею программировать, например, это не мешает мне купить микроконтроллер, погуглить и подсмотреть у кого-то код прошивки, погуглить как этот код поправить под свои задачи (или просто почитать комментарии), и что-нибудь этим микроконтроллером у себя автоматизировать. И оно будет работать, будет результат, будет решенная задача.
Вообще умение быстро находить нужную информацию, это очень полезный навык. Интернет для того и существует.
В контексте 1С экзамен на 1С: Специалиста идёт 5 (если ничего не изменилось) часов и там 4 или 5 (не помню) задачи. Причём, не 1С-ника если спросить о времени разработки этих задач — будет оценка 1-2 недели (это если объяснить, что именно надо разработать). Если топикстартер будет давать задание в 1,5 такого экзамена — у него будет примерно 0 сотрудников. 80% не сдадут, 20% откажутся сдавать.
В современных сертификациях (1С тут не одинока) почти всегда всё уныло, узкие срезы знаний и не вполне релевантно. Я бы даже сказал, что 1С-ный экзамен релевантнее многих. Но это задание по объёму точно вылетает за рамки того, что большинство соискателей готовы были бы сделать для тестирования.
Смысла в них мало, согласен. Но временами так и хочется, чтобы на собеседовании посмотрели наличие сертификата, а то недавно было так:
— Назовите модификаторы видимости полей в Java?
— private, protected, public и package-private. Он же default. Ребята, у меня есть базовый сертификат OCA и четыре года опыта, давайте более сложные вопросы.
— О, сертификат? Оракловский, по восьмой джаве?
— Ага. Так что азы точно знаю.
— А, тогда переходим к вопросам посложнее. Какие методы есть у класса Object? (это тоже входит в список вопросов на подготовку)
— ...
Впрочем, это собеседование, кажется, было проведено по первому попавшемуся в гугле списку на запрос "вопросы на собеседование java", но всё равно как-то бессмысленно вышло.
1. 80% не сдадут — так если на вакансию нужны люди, которые это должны уметь делать за положенное время — значит это просто волшебная экономия времени и ресурсов, позволяющая не платить этим людям з/п на испытательном сроке и не тратить на них своё время (а поскольку такое тестовое стоит в конце процесса приёмки на работу — значит без тестового мы бы 80% эти собрали себе в «пассив» и промучались бы с ними)
2. 20% откажутся сдавать — с чего бы вдруг, если вы предложите интересные условия на своей вакансии? А уж как вы это обеспечите — это ваша задача, как работодателя. Я вас уверяю, хорошие спецы работу ищут не по принципу «лишь бы устроиться за 2-3 дня».
PS: А еще сэкономленные на п.1 ресурсы надо потратить на интересные условия в п.2
PPS: Есть еще вариант оплачивать такое тестовое, чтобы снизить количество тех, кто «откажутся сдавать», это тоже намного экономически более целесообразно, чем потом с 80% неудачных вариантов тратить время и бюджет на испытательном сроке.
Сначала погрузился тупо в помощь людям. Не получается решить задачу? Зови меня. Я подойду, сгоню тебя с компа, сяду и доделаю. А ты, бездарь, сиди рядом и запоминай, как работать надо.
Это не помощь, а медвежья услуга, оказанная в надменно-высокомерном тоне.
Я отслеживал все показатели их продуктивности и эффективности
Это какие?
Пока дочитал статью родилось в голове определение: гугл-программист == менеджер по продаже кода.
(ну или код-менеджер, хотя не звучит)
Не, ну тут очевидно все, виновато отсутствие бумажки. Писали бы код на бумажке — все было бы идеально. И вовсе не в том, что не так-то сложно придумать задачу, которая даже с возможностью гугления не решится без своих мозгов.
Почему бы кстати не предоставлять на собеседовании для решения задач самый быстрый компьютер с самой лучшей IDE но без интернета?
Сам делю разработчиков на "авторов своего" и "сборщиков из готового". Последних недолюбливаю.
Другой вопрос что надо адекватно проектировать задачи. Многие штуки действительно не делаются без готового — нужны шаблоны проектов, некоторые базовые библиотеки и фреймворки. Без них не получить результата.
Но если речь идёт о несложных задачках на алгоритмы или системный дизайн — то вполне норм. Ну или как вариант можно давать заранее заготовленный проект с открытыми местами для дописывания логики/фикса бага или что вас там интересует.
А я уже себя начинаю недолюбливать из-за того, что я слишком "автор своего". Сколько часов потрачено на реализацию бинарных протоколов для передачи данных между клиентом и сервером вместо простого JSON, чисто по приколу. Сколько кода написано для реализации собственной ORM, что бы без этих всяких кодогенераций и рефлексий. А запал на пет проект не бесконечный, вот и висят проекты в зачаточном состоянии, но зато со своим протоколом и ORM.
Как я вас понимаю…
(я не шучу, поглядите в мои публикации).
У Вас по большей части архитектурные вопросы подняты. В моем же случае это не так критично, т.к. в Android сообществе вопрос архитектуры в данный исторический момент почти всегда решается в пользу Clean Architecture, а в маленьких пет проектах архитектура не так важна.
В одной из Ваших статей столкнулся с близкой для меня проблемой строгой типизации и попыткой максимально полно отловить все ошибки ещё на этапе компиляции (одну из своих идей, связанных с этим вопросом описал в комментарии). В Android приложениях много что традиционно описывается через xml (верстка экранов, различные параметры, векторные изображения и многое другое), что часто приводит к падениям уже в Runtime. Использование xml было более-менее оправданно во времена многословной Java, в нынешние же Kotlin'овские времена плюсов в xml для этих целей вообще не вижу, т.к. Kotlin и более краток и типизирован и подсказки лучше работают.
Мне кажется, что это все таки не этап развития, а особенность человека, потому как я эти велосипеды пишу сколько себя помню. А многие программисты уже с университетской скамьи грамотно используют чужие наработки. Это скорее связано с тем, что для меня программирование это скорее хобби, а уже потом профессия.
Нет, я работаю программистом и использую в работе библиотеки. Я говорю про внутреннее стремление к велосипедостроению, а не про фактическое их применение в работе.
вместо простого JSON
Вместо минного поля, а не простого. Бинарных действительно имеет смысл. Но в 2013 году, к счастью, CBOR уже стандартизировали в RFC, можно не велосипедить уже.
Не в быстродействии (это не критично для пет проекта) и не в минности (не сталкивался с нестабильностью JSON) дело. А в том, что в Java использование рефлексии ограничено тем, что во время компиляции типы всех дженериков чистятся, и нет возможности без плясок с бубном раскодировать JSON в List<User>. Соответственно использование JSON'a накладывает определенные ограничения на передаваемые по сети данные.
Проблема обострилась ещё тем, что я решил использовать для валидации данных и наглядности кода обертки вокруг значений. То есть вместо того, что бы использовать в коде String в качестве логина пользователя, я решил сделать класс-обертку Login, который во-первых проверяет в конструкторе корректность строки логина и дает возможность в дальнейшем уже не переживать по этому поводу, а во-вторых позволяет писать более выразительный код (user: Login выглядит куда понятнее, чем user: String, ведь в этом случае можно подумать, что в поле user хранится не логин, а какой нибудь другой идентификатор пользователя). Такую же обертку я сделал и для пароля. А потом оказалось, что для параметра серверного метода login совершенно не нужно писать свой класс (Обычно такие POJO классы называются LoginParam и содержат два поля: login: String и password: String), а можно просто использовать Pair из Kotlin'а: Pair<Login, Password>. Но такая конструкция совсем уже была неудобна для JSON сериализации через рефлексию. А компактность Kotlin кода позволяет весьма аккуратно сделать бинарную сериализацию.
echo calc(12)(4)(1)(fn($x, $y) => $x + $y); // 17
echo calc(2)(3)(fn($x, $y) => $x * $y); // 6
echo calc(5)(2)(fn($x, $y) => $x / $y); // 2.5
или
// чем заполнить переменную $i, чтобы код заработал верно
var_dump(!is_bool($i) && $i == '1' && $i == '3' && $i == '5');
// bool(true)
или по телефону придумать реализацию связанную с оптимизацией и хранением в высоконагруженной части проекта. Задача практическая, как было сказано «попила не мало крови в свое время». Т. е. чуваки с тестовыми данными, пробовали разные запросы, «эксплейнили» их в доль и поперек не один месяц, а тут по телефону за 30 минут )))
Вторую через магический метод __toString().
За 20 минут, если не сильно нервничать, успеть можно.
уметь гуглить это тоже важный навык, потому что если экстраполировать это на обучение то получится что читая книги в библиотеке вы тоже не исследуете сами, а используете чужой опыт. цивилизация основана на расшаривании чужого опыта, и это нужно чётко понимать. другой вопрос что то что нагугленное нужно хорошо понимать, а не просто копировать и вставлять в свои решения. так что думаю что проблема именно в этом — в том что stackoverflow в вашем случае является кагбэ "виртуальным опытом" который вы приняли за реальный
я пользуюсь персонифицированным поиском уже давно, тоесть Гугл запоминает что я ищу и какие ссылки открываю и на каких задерживаюсь. и я заметил, что когда ищу на своём компьютере или телефоне (со своего аккаунта), то поиск оказывается намного более релевантным, чем с компьютеров моих учеников. но потом их аккаунты тоже обучаются и первым выходят сайт stackoverflow, потом Microsoft и так далее
Впрочем, хороший специалист далеко не всегда хороший руководитель.
Подход «напиши говно, а я за тебя переделаю» однозначно показывает, что автор руководить не умеет
У меня высокий рейтинг на StackOverflow
Ну это смотря, что вы считаете высоким рейтингом. :) У меня на английском SO рейтинг приближается к 50k, но я не считаю его прямо особо высоким (это лишь 3k место в глобальном списке).
Ну, в смысле, что я понимаю, что я опытный разработчик в своем стэке, но не суперзвезда, которая может открывать двери HR гугла ногой и требовать принять её без собеседований.
574 это высокий рейтинг? https://meta.stackoverflow.com/users/785581/andrey-epifantsev
звезды довольно трудно накрутить
А в чем сложность? Зарегистрировал 100500 пользователей и от их имени поставил звездочки.
По-моему причина отсутсвия накрутки просто в том что это никому ненужно.
Я там, допустим, в топ 3% глобальном сейчас, в прошлом году был в топ 1% или даже 0.5%, и на 30 месте по весьма хайповому тегу kubernetes (если интересно, вот тут можно свое место по тегу посмотреть — data.stackexchange.com/stackoverflow/query/52750/tag-rankings-fun). Был сильно выше, последний год очень редко отвечаю. Рейтинг набран исключительно ответами в скоупе Kubernetes и сопутствующих технологий.
Так вот, нужна эта информация примерно никому. Никто туда не смотрит, не смотря на ссылку на профиль в СV.
Ни разу еще такого небыло, чтобы кто-то сказал «да, мы не будем задавать вам тупых вопросов по K8s, потому что видели на SO что вы очевидно знаете на них ответ и даже отвечали там на точно такой же». Выборка — порядка 15-20 собесов за последние два года. И это учитывая, что все собеседования были в рамках европейского\американского рынка труда, в англоязычных компаниях и там уж точно нет проблем с тем, чтобы пройти по ссылке на англоязычный портал и что-то там понять.
Говорить за всех — моветон.
Если кандидат в CV даёт ссылку на гитхаб, всегда смотрю что за проекты делает кандидат и в каких участвует.
Это просто кладезь для собеседования. Куча предметных вопросов, а почему ты тут вот так сделал, а здесь вот так, а как можно по другому это решить?
Не надо задавать тупых вопросов, ответы на которые в гугле пачками висят.
И не надо выдумывать нестандартные вопросы, они сами из кода проистекают)
Как пример что там можно найти)
В одном из недавних интервью, кандидат с несколькими годами опыта в Java + Spring дал ссылку на гитхаб, а там на сервисах висят одновременно 3 аннотации: Component, Service, Repository. Было забавно слушать фантазии на тему того как спринг обработает эту ситуацию)
P.S. Проблема только в том, что на пару-тройку десятков последних соискателей гитхаб был только у одного.
Например затем, что глупо делать далеко идущие выводы по паре строчек кода)
Причины появления такого кода на гитхабе могут быть самыми разными.
Помечаю как вопрос перед подготовкой к собесу, а дальше уже от объяснения кандидата зависит.
В данном конкретном случае кандидат не понимал, что делает. Просто "так привык" и "всегда так делали", т.е. он банально не понимал, что этот код значит.
Но меня вполне устроило бы объяснение в духе: "А, лол, это копипаста, очевидная хрень написана, потому что… и объяснение что там написано и почему не имеет смысл так писать".
А что если кандидат в теме своих проектов разбирается намного лучше вас и у вас не будет хватать экспертизы, чтобы оценить правильно ли он сделал и насколько правильно?
Тут просто надо понять, что разбирается лучше вас и решить, нужен или нет такой человек вам, пригодятся или нет его знания.
Если бы вы внимательно читали, что я написал, то могли увидеть, что я не решаю "правильно" ли решена тема проекта.
Мы же не бизнес развиваем, а техническое собеседование проводим)
И меня интересует в первую очередь техническое решение и его объяснение почему именно так сделано. Это тема для обсуждения решения, а не далеко идущие выводы по паре строк кода.
Когда разовьетесь как инженер, вам станет понятно, что единственного "правильного" решения просто не существует. Всё можно сделать разными способами. А собеседование на примере проекта это всего лишь способ пообсуждать эти решения, чтобы понять как человек мыслит и принимает решения.
Дело в том, что в CV можно вставить ссылку на любой произвольный профиль SO.
Как убедиться, что тот крутой чувак с SO это действительно вы?
Вряд ли есть еще один человек с таким же именем и фамилией, который занимается примерно тем же чем я, учитывая что я не «Джон Смитт».
Ок. Тогда следующий уровень.
Как убедиться, что тот крутой чувак отвечал на SO самостоятельно, а не нанимал китайцев для прокачки аккаунта?
Вы мне кажется придумываете какую-то проблему, которая могла бы объяснить «почему не стоить верить человеку». В таком случае можно много заговоров подкинуть, к примеру — интервью за меня может проходить тоже другой человек. Ремоут же.
А зачем нанимать китайца для прокачки профиля SO?
Например для того, чтобы потом хвастаться в резюме какой он крутой специалист.
Я просто обратил ваше внимание на то, что одна только ссылка на профиль SO не может освободить вас от ответов на вопросы. Хотя бы парочку вопросов для проверки вам все равно зададут.
Интервью тоже может проходить другой человек. Вот только собеседования не всегда телефонные. Даже на телефонных можно услышать голос отвечающего. Если потом голос изменится, то будут закономерные вопросы.
Я же не говорю о пропуске собеседования в этой части вообще, я говорю о весьма тупом опросе, вместо перехода к сути дела. Какой смысл долбить человека тупыми базовыми вопросами, чтобы вызвать у него скуку и ненависть вместо того, чтобы обсудить что-то действительно интересное и важное — архитектуру там, тонкости использования, малоизвестные, но важный грабли, паттерны и т.д. Понятно, что для того, чтобы поднять эту серьезную тему, надо убедиться что человек хотя бы основы знает, но если понятно что человек основый знает, то можно немного сохранить ценное время и пройти по более полезным вещам. Я сам собеседую периодически, недостаток живой информации о кандидатах весьма острый, любая доп. информация кроме резюме на самом деле большая ценность, но то ли я такой замороченый, то ли у большинства в голове скрипт засел, то ли просто большинство не особо заморачивается.
Кстати про «голос изменится» — большинство отборов сейчас — это раунды с совершенно разными людьми на разные темы. Чисто теоретически один человек может проходить одно собеседование, другой — другое и то, что это были разные люди никто не узнает.
Даже потом, т.к. кандидатов обычно много и вряд ли кто-то запомнит голос какого-то конкретного человека и потом свяжет его с тем, кого увидит через какое-то время лично.
Если вы наемный работник, работаете за зарплату, то вам важно чтобы если кандидат все зафекапит, вас не обвинили. В этом случае нормальной выглядит стратегия гугления типичных вопросов для собеседования и спрашивания их.
Если вам хоть немного важно качество работы, то поступаете так же как с другими работниками. Я вот недавно нанимал дизайнеров, у них у каждого инстаграм(что в нашем случае равно github или SO), смотрите, выбираете. Ну т.е. я допускаю что может быть есть отличные дизайнеры которые не ведут инстаграм, но я бы побоялся их нанимать
С другой, стороны, по моему опыту, ни работодатели, ни, тем более, кадровые агентства этого всего не ценят. И как наниматель, я тоже, не стану отказывать человеку, если у него нет проектов на гитхабе. Опять же, из 20-и последних кандидатов, чего-то интересного ни у кого не было. Курсовые, у свежевыпущенных студентов, вот и весь улов
По поводу блога, я вот хабр читаю лет десять, а писать начал две недели назад. Если же более глобально, то в России на 1-2 миллиона работников ИТ сферы (не считая русских из других стран) приходиться столько активных блогов на хабре? 1000? 10000?
Какие личные качества мешают писать в блог? Перфекционизм (не хочется писать плохо или ерунду) и стеснительность
Делает ли это его плохим программистом?
Нет, не делает конечно. Но он явно не очень мотивирован и программирования у него это чисто работа. Что вполне нормально, конечно.
Обожаю категоричные мнения!
Я вот уже много лет как превосходно мотивирован в программировании.
Но на ГитХабе у меня нет пет-проектов. У меня их вообще нет.
Мой любимый «пет-проект» на сегодня — это тот проект над которым я сейчас работаю, за который мне и платят деньги.
Я считаю, что нет ничего такого в том, если информация будет находиться в гугле. НО! Человек, который воспользуется ответом из сети — должен понимать тот код, который он будет копировать и вставлять в продакшен
В первый день учёбы в институте нас собрали в аудитории на кафедре, и старый прокуренный дядька, зам. декана и доцент, сказал: «Институт не даёт знаний. Он учит добывать знания самостоятельно».
В первый день учебы на каждом учебном курсе, будь то «Основы программирования», «Сетевые технологии», «Тестирования ПО», «Операционные системы» преподаватели честно признавались «инфы — гора, раньше я этот курс читал 2-3 семестра, сейчас — один, а рассказать нужно то же самое + современные реалии, готовьтесь». Тут простонет времени посидеть в библиотеке и поизучать «все подряд», физически нет этого времени, потому чтоизучать нужно слишком много. А студенты всё те же самые люди, с теми же самыми нейросвязями в мозгу, двумя руками и двумя ногами, как было в начале 2000х, конце 1970х и пр.
Потом вот с этой кашей в голове ты выпускаешься. Уходишь из общаги, надо где-то жить. Просить родителей оплачивать жилье или жить с ними — уже стыдно, тебе 24 (магистратуру же закончил, умничка), большой человек. Идешь на собеседование по специальности, а там тебя валят сразу всем (на всякий случай): основы ООП, историю Java, что такое MVC, опишите алгоритм Дейкстры, найдите Аленький цветочек, расскажите про Java Beans, перечислите все методы библиотеки String, опишите пару аннотаций, «а что вы нервничаете? мы же с вами так хорошо беседуем», «ну а теперь решите задачу». Неужели кто-то упустит возможность найти красивое решение, чтобы попасть на желанную должность?
Да, в 95м меня можно было ночью дёрнуть за пятку и спросить как решить на Си какую-нибудь там задачу о рюкзаке (например), я бы скорее всего написал бы ее и без ПК (и возможно даже без ошибок).
Но эти «сакральные» знания никак не помогали мне писать код чище, лучше (быстрее). Изобретались дичайшие велосипеды, забивались костыли размером с серпуховскую мотоколяску — просто не хватало знаний, как можно наиболее элегантно решить ту или иную задачу.
И только с появлением возможности смотреть на большое количество ЧУЖОГО кода (интернет+поисковики), возможности делиться знаниями, все сразу круто пошло в гору.
Именно условный «гугл» (источников конечно же больше — это и SO и гитхаб и прочие ресурсы) позволяет мне сейчас довольно свободно и более-менее результативно на 5-7 языках и разбираться на среднем уровне в десятках технологий. Именно возможность получить мнение по моему коду от более продвинутого камрада, который может предложить более быстрое/элегантное/простое/красивое/итп решение моей проблеме — вот это решает. А не возможность «писать код без ПК».
И меня не смущает факт того, что если меня прямо вот сейчас просить про упомянутую «задачу о рюкзаке», я не то, чтобы не решу ее на бумаге, я даже вряд ли сходу вспомню сам алгоритм решения. Зато я знаю, где за 5 секунд про это в мельчайших подробностях почитать, а уже после я без проблем решу ее на любом доступном мне языке. И если сильно будет нужно — на неизвестном на текущий момент мне.
Гугл решает, да.
Я — хороший специалист. Уж поверьте на слово.
Не программист, экономист — но не суть. Несколько лет назад, когда я устраивался на работу, энчар выдала мне лист бумаги и калькулятор: "Составьте бюджет".
Я сел — и понял, что я разучился писать руками. Честно попытавшись написать несколько строчек и высчитать сложный процент на калькуляторе — я признал, что очевидно, не готов работать по старинке — без клавиатуры и эксела.
Я понял, почему у меня стажер резко снизила показатели, как только пошли реальные задачи чуть посложнее, чем раньше.
Проверил — точно, все время гуглит, не запоминает даже что было неделю назад и не понимает суть кода.
loc?
В институтах кстати есть пласт студентов которые «учатся не учась» — т.е. имитирут понимание материала и выдают стандартные ответы на стандартные вопросы.
не запоминает даже что было неделю назад и не понимает суть кодаА как она тогда гуглит? Как формулирует запрос, как находит нужную ссылку в выдаче, как понимает, что по ссылке то что нужно и как это применяет в своей тех. среде?
Сейчас вернулись к основам (базовым курсам), которые уже «прошли» и начали снова вдумчиво изучать.
Да, речь идет об 1С.
Надо было сделать два стандартных компонента для обработки своих данных со стандартными интерфейсами. А вот потом надо было обеспечить взаимодействие двух подобных компонентов, но для этого нет удобных стандартных интерфейсов, интеграция в разных ситуациях строится по-разному и есть какие-то нюансы. Это всё судя по ссылкам из гугла:
forum.infostart.ru/forum9/topic206847
infostart.ru/1c/articles/694647
Тут уже явно требуется не только хорошее знание платформы, но и опыт реализации таких штук. Неудивительно, что стажёр на чём-то споткнулась, удивительно, что сидела целую неделю и билась об стену, вместо того чтобы подойти и сказать «я тут застряла, не получается вот то-то». Вот об этом бы я на вашем месте задумался и поискал причины, а не о показателях.
не запоминает даже что было неделю назад и не понимает суть кода
Это вполне нормально для массы людей, у которых нет желания в этом разбираться. Именно так большинство школьников и студентов зазубривают материал перед сдачей экзаменов и зачетов. Стажер скорее всего не хочет или не имеет мотивации развиваться как разработчик.
Вы пойдёте оперироваться к хирургу, который зазубрил, сдал и забыл, потому что желания разбираться нет?
Это нормально для людей, которым не дают время разобраться, а подкидывают следующую задачу. Нет, понятно про в 'свободное время'. Но если то, в чем нужно разобраться, применимо исключительно в рамках текущего проекта и больше нигде — то желающих разбираться в свободное время будет маловато.
Хотите спецов, которые отлично решают задачи на бумажке, без интернета — так ищите. Ну будет у вас конверсия 0.1% от приглашенных — в чем проблема? За капризы надо платить.
Или проблема в том, что бизнесу нужны люди, которые просто решают задачи, а вас тянет на ностальгию по программированию в 90-х? Тогда это вам стоит задуматься, за что вам платят — за решение задач (поиск программистов) или за личные прихоти.
Что-то мне мало верится, что в гугле можно так быстро найти решение на отдельную задачу, прям чтоб и код красивый и структуры и оптимизация. Либо задания были не сложнее 2*2=4, но тогда непонятно, откуда вводы про хороший код.
Я сам программист и не раз проходил интервью с компьютером, скорость потска кода в гугле намного меньше чем написание его самому.
В-общем, так и зочется воскликнуть: "поздравляю вас, автор, соврамши"
Сугубо на мой взгляд, метод собеседования «на бумажке» вполне применим при абстрактном описании алгоритма решения задачи, при проверке понимания задачи, правильности выбранного метода, логики и т.д. и т.п. Не современно? — может быть. Но на способность понимания алгоритмов это не влияет, а набросать карандашом на бумаге будет быстрее и куда нагляднее.
Полное нагугливание всего и всегда, без осмысления — это зло. Типа, зачем самому думать если «весь» код давно написан (по аналогии, все географические/физические/химические/любые другие открытия уже сделаны, на самом деле нет). Но совмещение одного с другим, на мой взгляд, должно давать неплохие результаты. Абстракции на бумажке + конкретика в IDE.
Дальше стараюсь вникнуть что какой кусок делает и что мне нужно переписать под себя для внедрения в свой код.
Я бы сказал, что это и есть разумный подход. Он даёт решение задачи, а если при этом ещё удалось разобраться в том, почему исходный вариант был неверен — так вообще шикарно.
набросать карандашом на бумаге будет быстрее и куда нагляднее
Если схемку поиска маршрута в графе, работу двусвязного списка или, на худой конец, сортировку шелла, то это удобнее, чем расчехлять фотошоп/иллюстратор/визио.
Но если код — то нафиг, нафиг. Это имеет мало общего с написанием кода на компьютере, как по мне.
Это требует шибко специфичного навыка планировать место на бумаге/доске и стараться делать минимум исправлений. И этот навык пригождается только лишь на прохождении интервью, так зачем его тренировать.
минусаторы — аргументируйте
Полагаю, кто-то среагировал на "Сам не программист, учился не на программера" и не стал читать дальше, кто-то был несогласен, а третий — эффект толпы. Два минуса у комментария — значит автор явно не прав, надо минуснуть за компанию. :)
Если схемку поиска маршрута в графе, работу двусвязного списка или, на худой конец, сортировку шелла, то это удобнее, чем расчехлять фотошоп/иллюстратор/визио.
Но если код — то нафиг, нафиг. Это имеет мало общего с написанием кода на компьютере, как по мне.
Это требует шибко специфичного навыка планировать место на бумаге/доске и стараться делать минимум исправлений. И этот навык пригождается только лишь на прохождении интервью, так зачем его тренировать.
Ровно об этом я и писал :)
Несовременную бумагу можно заменить на модную доску и фломастеры или интерактивную eBord. Естественно, есть смысл в таких вещах писать укрупненные алгоритмы, схемы и т.д. Допускаю использование некоторых коротких элементов кода, например, сложных условий и т.п. для лучшей наглядности. Писать чистый код, тем более без ошибок в такой ситуации неуместно и не показательно, ИМХО.
Полагаю, кто-то среагировал на «Сам не программист, учился не на программера» и не стал читать дальше, кто-то был несогласен, а третий — эффект толпы. Два минуса у комментария — значит автор явно не прав, надо минуснуть за компанию. :)
Может быть, но мне интересен диалог, мнение, а не тупые минусы. Такое ощущение, что люди разучились выражать свои мысли, выродились в проставляторов лайков на фоточках.
Звучит, конечно, что гугл у вас в роле козла отпущения просадки KPI, хотя возможно дело в самом KPI?
Я продолжал беситься и орать в чатах.
Но на самом деле непонятно зачем им работать с вами.
Можно ли утвердить, что если человек копипастит из гугла участки кода, то он не будет развиваться?
Да, с вероятностью, превышающей половину. Кому как, но по мне, этого достаточно для отсева на собеседовании.
Можно ли утвердить, что если человек копипастит из гугла участки кода, то он не будет развиваться? Я уверен что нет, особенно в начале карьеры, проходится искать и адаптировать решения, но в итоге это же заставляет разобраться со всеми сложностями, копать глубже, читать книги.
Зависит от конкретного человека.
В жизни автора статьи попадались такие, как мы видим, что заточены прежде всего на копипаст, да.
Мне тоже попадался чел, который на полном серьезе рассказывал, что «всё есть в Гугле и этого достаточно».
«копипастит из гугла участки кода» и «искать и адаптировать решения» две большие разницы.
На мой взгляд, если по существу "претензий", то везде есть правда (и в мнении автора, и в совокупном мнении комментаторов).
Я очень благодарен тому, что, поступив на ВМК (МГУ) в 2010-ом, всё ещё попал на проверочные работы и экзамены по программированию, когда код надо писать на бумаге. Это дало мне ценнейший опыт "прорабатывания кода в голове", "думать как интерпретатор/компилятор" и т.д. Не знаю, практикуют ли они сейчас по-прежнему такой формат — но "пожалуйста, да".
А потом, когда я пошёл работать, я начал понимать, что информации становится очень много, и я не хочу свою "оперативную память" забивать процессами, которые мне сейчас не нужны.
Со временем, как мне кажется, я научился держать в голове то, что мне сейчас нужно, и всё лишнее оставлять на "я знаю, где посмотреть".
А вот умение тщательно въедаться в код не пропало, очень помогает при ревью, как своего кода, так и чужого.
И я рекомендовал бы практиковаться так тем, кто испытывает сложности в фундаментальном понимании того, что вообще происходит в программе. Так бывает, люди разные, в программирование пришли по-разному.
Давно не ходил по собеседованиям, но мне кажется, если бы пошёл — стоял бы на том, что держать в уме все нюансы нецелесообразно (да, даже если в коде встретилась дичь, которая на самом деле работает совершенно не так, как думаешь: ты в любом случае привыкаешь к "хорошему коду", если "стремишься к лучшему", и любые необычные решения должны вызывать желание проверить, как оно работает внутри, если уж ты не помнишь).
И, проводя собеседования, никогда не упираюсь в то, помнит ли человек сигнатуру функции и т.д. Вообще, я стараюсь вычислить его умение мыслить и желание развиваться и писать хороший код, нередко мне вообще не нужно человека напрягать какими-то решениями каких-то типовых задач. Я считаю, что собеседование — это тоже немалое искусство, и нужен персональный подход (во всяком случае там, где компании могут себе это позволить).
И, скажем прямо, описанную в топике проблему я бы вычислил на стадии код-ревью, достаточно быстро. Ничего даже страшного, если бы такой сотрудник прошёл собеседование и начал у нас работать. Иногда лучше всего понятно, что за человек, уже "в боевых условиях". Во всяком случае, мне обиднее упускать потенциально ценного кандидата, чем отбраковывать по причине того, что ему некомфортно, скажем, на бумаге код писать.
Конечно, бумажка не обязательна. Да и универ не обязателен. Вообще, обязательного в нашем мире не так много, как кажется. Просто всё имеет свои последствия, приятные или не очень.
Я говорю о том, что это может помочь настроить своё мышление определённым образом.
Один из способов / инструментов достичь определённого понимания, при условии наличия хоть какой-то мотивации (но про мотивацию — это само собой разумеющееся).
Прелесть наличия подобной практики в университете для меня как раз в том, что человек сам собой таким редко занимается, это требует определённой толики мазохизма, а "в универ ходить вроде как надо" (если присутствует соответствующее воспитание), и — особенно про ВМК — это вроде как "место престижное", и вам сквозь некоторый дискомфорт приходится этим заниматься.
(Конечно, тут исключается человек абсолютно сознательный, коих процентно существенно меньше, кто уже в свои 17-18 понимает чётко, чем он хочет заниматься, как он хочет этим заниматься, какой университет/институт ему нужен, или что ему это вообще не нужно, и потом ни разу не жалеет о своём выборе. Такие ребята сами всеми силами пробьются к своей цели, потому никакие доп.стимулы им не нужны.)
Потом уже можно осознать определённую пользу от этого подхода. Да, кому-то, вроде вас, это не требуется, кому-то, вроде меня, это оказалось очень полезным.
Но если спросить и меня, и вас во время экзамена, хотите ли вы на бумаге писать, или нет — оба ответят "нет" :)
Я считаю, что появление гугл-програмистов это следствие любимого многими гражданами из айти постулата "Программирование — новая грамотность". Когда вы набираете людей из данного поколения, вы должны быть готовы к приходу кадров с подобным уровнем подготовки. Соответственно должны сами иметь достаточную квалификацию и чёткое осознание требований вашего бизнеса. Такие люди вполне успешно могут решать ваши задачи за ваши деньги, но это в том случае, если вы действительно понимаете кем вы руководитель.
Я сам не являюсь человеком из айти, но с 10 лет(сейчас мне 23) практически ежедневно с помощью Гугла пишу для себя полезные программы и решения. Я совершенно не понимаю что нужно бизнесу, но вполне могу для себя реализовать человеческий Майнкрафт лаунчер на c++ или Авито парсер с кучей фильтров на go. Просто подобные мне люди бывают более решительны, чтобы пойти с этим багажом куда-то работать)
Начал возмущаться – блин, да как так! Ладно там новую технологию раскурить с помощью интернета, или научиться пользоваться какой-нибудь редко встречающейся хренью, чтобы голову не забивать. Но базовые-то вещи! Как вы можете их из интернета списывать?!На себе даже почувствовал весь жар негодования
ЗЫ. А успокоительных попейте. Помогает.
В итоге я получаю возможность смотреть на язык как на совокупность «концептов». Предположим: есть дженерики и пишу нечто в стиле ООП, значит я знаю, что у меня будут дженерные сервисы и методы, я знаю, для чего я буду их использовать, и если в legacy коде я не вижу их, я в первую очередь задаюсь вопросом, а что пошло не так?
2. Я, конечно, люблю изобретать, но больше всего я люблю четкую инструкцию, желательно, для дебилов, как по шагам сделать то и то. Потому я пользуюсь паттернами. Я не всегда знаю, как они реализованы(например, сложные сортировку и какие-нибудь btree индексы ), но я пользуюсь реализацией более грамотных и умных людей в этом вопросе — не вижу в этом особой проблемы.
Как итог получаем, что я, при написании кода на листке(если требуется до буквы использовать методы из конкретного языка с нужными аргументамИ) — сомневаюсь, что смогу написать код длиннее пары десятков строк без ошибок. И в итоге я, если не знаю для своей задачи подходящего решения — ищу паттерн для него, скачиваю его из гугла и радуюсь жизни, если оно решает мне задачу. Я гуглопрограммист — и кайфую от этого.
p.s.Добро пожаловать в реальность: Со слов Сассмана, «Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». — это ведь правда.
сомневаюсь, что смогу написать код длиннее пары десятков строк без ошибок
Я вот уверен что не смогу. Современные инструменты настолько все упростили что я не всегда даже в голове держу синтаксические конструкции языка с которым каждый день вот уже второй год работаю. Особенно если конструкции не каждый день используются. Куда уж там стандартную библиотеку помнить если часто ее помнят пальцы а не голова. Это как с паролями, я пару паролей не помню настолько хорошо чтобы на бумаге записать, но пальцы с клавиатуры их вводят безошибочно.
при написании кода на листке(если требуется до буквы использовать методы из конкретного языка с нужными аргументамИ) — сомневаюсь, что смогу написать код длиннее пары десятков строк без ошибок
А на бумажке на собеседовании больше и не нужно — это вполне достаточно, чтобы оценить мышление кандидата.
Со слов Сассмана, «Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». — это ведь правда.
Знаете, описан совершенно не научный подход.
а вы ни в каком КБ случайно не работали главным технологом? я такой маразм только на производстве видел
Институт не даёт знаний. Он учит добывать знания самостоятельно
Боже какая чушь. Как раз лекторы нужны за тем, чтобы от них получать знания. Самостоятельно можно знания добыть БЕЗ вуза. Кстати я вот с очень большим количеством людей говорил, которые повторяют эту мантру, и просил объяснить мне как их научили вот этому всему? И знаете что? А ничего, никто вообще не смог после размышлений подтвердить эту фразу, ну а поскольку бремя доказательства утверждения лежит на высказывающем, считаем эту фразу антинаучной.
По-моему, как раз базовые вещи, которым учат в ВУЗе. Для примера, я привык конспектировать в mindmap`е, архивировать в закладках по папкам, нужной вложенности, дополняя тэгами их. А у вас как?
Добыча знаний с появлением гугла кажется устаревшей, но под добычей подразумевают не только поиск, но и структуризацию, куда входят такие вещи, как конспектирование, доказательство того, что знания применимы к выбранной задаче и решают ее, и архивирование, по которым подразумевается ведение некоего «словаря, где вы можете повторно эти знания найти.
— все что я запишу я забуду, с гарантией, из-за этого у меня были очень большие проблемы в школе и вузе и никто не удосужился объяснить, что так бывает, выяснил это самостоятельно.
— архивы не веду, работаю в слишком большом количестве областей и закладок накапливается столько, что поиск по ним сам по себе невероятно затратен.
— все что я применял я помню, написанный код помню практически построчно
— тонкости реализаций находим, пролистываем по диагонали, реализуем и забываем. Помнить их незачем совершенно. Если что в гите или на винчестере лежат.
— по целому ряду областей даже алгоритм поиска неочевиден: например сейчас развелось много статей о UI/UX но вот особенности человеческого восприятия изучают единицы и статьи на эту тему днем с огнем не найдешь а как без лектора догадаться о таких не очевидных вещах, что направление взгляда на фотографии фокусирует внимание смотрящего на линии взгляда я даже придумать не могу.
В общем и целом поиск знаний как правило начинает с осознания проблемы, посему самым важным скиллом для разработчика является способность использовать свой продукт и видеть его недостатки. Кстати, простой пример: попапов для вебстраничек с отображением по наведение — миллион и почти все любят пропадать если мышка ползет не строго над ними. Разработчики этого не видели? Они не в курсе как это бесит? Быть такого не может. (кстати, фраза для гугление «Dropdown Menus with More Forgiving Mouse Movement Paths»)
Не надо обобщать. На мой скромный взгляд, у вас проблемы (особенности?) с памятью. Потому что однажды записанное всё равно так или иначе остаётся в голове.
Не надо обобщать. На мой скромный взгляд, у вас проблемы (особенности?) с памятью. Потому что однажды записанное всё равно так или иначе остаётся в голове.
Это не проблемы, это вполне нормальная особенность работы мозга: выкинуть из памяти все, что ему не нужно. В качестве бонуса остаются несвязанные крохотные огрызки знаний, зачастую, абсолютно бесполезных.
До сих пор помню многие прочитанные в детстве художественные книги, но совершенно не помню ни одной лекции в универе, не говоря уже про школу.
Банальное дифференцирование? Гугл.
Большая часть геометрии и тригонометрии? Гугл.
За-то до сих пор помню формы эпюр усилий от разных нагрузок, и что сумма моментов сил в системе равна 0. А так же чем отличается формула серной кислоты от сернистой.
Теория прочности грунтов? Да вообще ничего не помню, хотя у меня 3 рабочих блокнота полностью исписаны формулами и рассчетами. Именно рабочих, не студенческих.
Нюансы работы с компортом напрямую? Я 3 года этим занимался по работе, сейчас даже не вспомню какие классы использовал, не то что параметры, а прошло «всего» 7 лет. За-то помню порядок открытия и закрытия клапанов от режима работы шагового двигателя насоса у установки, с которой через этот самый COM-порт я и работал.
7 уровней модели ОСИ? Ну 4 я еще вспомню.
За-то я до сих пор помню как работают карты Карно, хоть ни разу в работе оно мне и не пригодилось. Или решение СЛАУ методом Гаусса, которым я ни разу после универа не пользовался, даже когда эти самые СЛАУ надо было решать по работе.
При этом все актуальные рабочие знания замечательно лежат в памяти, а все редкоиспользуемые замечательно вытаскиваются из гугла с офф манов, статей или хабра. После этого так же замечательно забываются. Написать сложный SELECT на пяток таблиц и десяток условий? Легко и быстро, только надо глянуть в мане, как там дифф между датами вычисляется и какой синтаксис у HAVING, которым я пользуюсь 2 раза в год.
Регулярки? 4 раза в год, нужно глянуть краткую справку по синтаксису.
Обработка текстовика на несколько сотен метров с парсингом числовых данных из него? Да вообще не проблема, даже выбор запятая-табуляция и корректная поддержка кавычек будет без напоминаний. В довесок из коробки обработка будет поточная, расход памяти в сотню мегабайт, и без утечек памяти на строки, и даже c кастомным парсингом чисел, для N кратного ускорения работы. Я с этими нюансами постоянно сталкиваюсь, они уже давно лежат в оперативной памяти мозга.
И нас таких даже не двое, а намного-намного больше.
И да, вас таких действительно не двое, а 99.9%.
Хорошо, добавим деталей: СЛАУ описывает точку пересечения N линий на гиперплоскости, через уравнения прямых. Это все еще абстракция или уже частный случай? Наверно все таки уже частный, так как Гаусс и Крюгер тут уже применимы. Полезно в жизни? Сомнительно.
Или возьмем такую абстракцию, как усилия и моменты в ж/б балке, возникающие от сосредоточенной нагрузки. При этом вы на работе клепаете микросервисы, получающие данные из одного места и передающие в другое? Ну или кашеварите в школьной столовой. Полезны вам эти абстрактные знания?
Ну раз мы на IT ресурсе, давайте возьмем такую абстракцию, как Сборщик Мусора, который этот самый мусор из памяти и собирает. Прекрасная абстракция, понятная даже далеким от IT людям. А теперь столкнем эту абстракцию с реальностью, которая прекрасно проявляется на собеседованиях, ибо вопрос про особенности работы сборщика мусора в .NET/Java — это просто святая святых (хорошо отличает тех, кто читал спеку, от тех, кто ее не читал). Интересна эта абстракция интервьюеру? Нет, даже если вы на джуна собеседуетесь. Почему-то они будут оценивать знание нюансов в виде порядка очистки, основных триггеров срабатывания и методов принудительного освобождения памяти, а так же о возможных недостатках, которые могут вызвать эти действия.
Туда же идет глубокая теория пределов, диффуров и интегралов. И даже на интервью повара вас будут спрашивать как готовить суп, а не как пойдут трещины в плите перекрытия, если вся школа решит дружно встать на нее.
Вот вам и реальная польза всех абстракций без практического применения. Полезны? Нет, совершенно бесполезны, даже если практические применение знаниям есть, но не в вашей сфере деятельности.
Мозг тоже понимает, что если с пределами в обозримом будущем он не столкнется, то все эти 20+ методов решения ему нафиг не нужны, и удаляет их. И останутся в голове фрагменты знаний, как это происходит на винте, после удаления файла и дефрагментации диска.
Интересный эффект. А если не записывать, запоминается лучше?
ЗЫ ну вот сейчас пока писал вспомнилась встреча 6 месяцев назад, когда обсуждали проект и мною высказывались проблемы, которые скорее всего возникнут (и возникли, в формате «с размаху в пень»), помню время суток, обстановку, уровень освещения, участников, их положение за столом/у доски, позы, тон, что демонстрировалось на экране, все обсуждаемые темы, в какой последовательности обсуждались и принятые решения.
Неврологическое что-то?
а что, стоит боятся?Не думаю. Это не то, чтобы очень распространённый образ мышления, но таких людей достаточно.
Это мои личные выводы, но видимо просто сознание заточено на «понимать», а не на «запоминать», а понимать — это дорого, потому что на это тратится время и энергия. Поэтому тривиальная ерунда и фильтруется на входе.
В «Программистском камне» подобное хорошо описано.
Лично у меня персональная вики в Zim на минималках
А что там доказывать? Даже элементарное написание реферата по источникам в библиотеке (да, в бумажной) уже прокачивает этот скилл.
Вообще то лектор прав. Знания могут и не пригодиться но скилл обучаться он должен прокачивать.
Предлагаю задаться вопросом, не являются ли эти гугл-программисты интерфейсом к "китайской комнате", перерабатывающей изречения требования заказчика в код.
А там и до подозрений, не философские зомби ли они, недалеко.
Неча на зеркало пенять коли рожа крива. (с)
Насколько разработчик потенциально хорош, можно выяснить в беседе.
А то, что разработчики вставали на плато — так это в основном вопрос качественного наставничества и обучения сотрудника. Берите не знающих, а смышленых, и качественно их обучайте
ГОСТ Р 43.0.21-2020
Сознание и самосознание (Информационное обеспечение техники и операторской деятельности)
Это человек который что-то может, но совершенно не понимает, что и как работает.
Как результат, если он не может найти решение в гугле, то даже самая казалось бы элементарная задача полностью его парализует.
Часто нужно всего лишь поменять один параметре в решении из гугла, но он не может.
Он начинает перебирать решения хоть как-то похожие на его задачу. И если не одно не решает проблему, то все припыли, и даже скомпилировать из готовых вариантов готовое, он не может. Он просто не понимает, что все эти буковки значат.
Еще часто у них встречается синдром тыкателя, тыкать по кнопкам пока не заработает.
Спрашиваешь, а зачем ты вот здесь такой параметр поставил, отвечает, а вдруг поможет.
Фэйс палм, не понимая, что за параметр, зачем он, просто а вдруг подойдет.
Ингода их можно даже починить. На каждую возникшую проблему, бьешь по рукам и стоя над душой, заставляешь думать( это для них очень мучительный процесс ), по каждому параметру, по каждому пункту, чтобы объяснил зачем он нужен и за что отвечает, потом пусть построит взаимосвязи и так постепенно выйдет на правильный ответ.
Для разработчиков где-то видел, stackoverflow developer.
Точнее это называлось SDD — Stackoverflow-driven development.
Для админов я использую термин, может где подсмотрел, а может и сам выдумал, monkey админ.
Я чаще всего встречал — эникейщик.
Ну нет, эникейщик — это должность. А в комментарии выше описана квалификация, это разные вещи.
Называться-то должность может как угодно, вопрос в фактических должностных обязанностях. "Эникейщик" — это, по определению, человек, который бегает от одного пользователя к другому и нажимает им на клавиатуре "Any key" (более современный вариант — нажимает на кнопку "ОК" в модальном диалоге).
Понятное дело, что такие "должностные обязанности" коррелируют с низкой квалификацией, но прямой зависимости тут нет.
что такие «должностные обязанности» коррелируют с низкой квалификацией, но прямой зависимости тут нет
Ну странная логика, разумеется вы можете работать дворником, но быть доктором физическим наук.
У любой должности есть минимально необходимая квалификация, можно работать джуном при опыте на архитектора, но это обычно не типично. Тут лучше говорить о том какую квалификацию должность подразумевает.
сносно работают со встроенной справкой...
Зачем?! Я ещё помню то время, когда вместе со средой разработки ставил все хэлпы (MSDN, справку по Python и т. п.) и активно ими пользовался — давно перестал, в современных реалиях это нафиг не нужно. Тот же MSDN весь есть в интернетах, и другие всякие справочные сайты, на которых, зачастую объяснено подробней и доходчивей.
И гуглить готовые чужие решения — очень полезная привычка, зачастую узнаёшь что-то новое: библиотека какая-то новая появилась, новая фишка в языке, старая фишка в языке, которая почему-то прошла мимо тебя, или ты всю жизнь делал что-то одним способом, а тут — сурпрайз! — есть, оказывается, способ лучше.
сносно работают со встроенной справкой...Зачем?!
Автор в сфере 1с работает. Там документацию только недавно частично открыли в бесплатный доступ.
И гуглить готовые чужие решения — очень полезная привычка, зачастую узнаёшь что-то новое: библиотека какая-то новая появилась, новая фишка в языке, старая фишка в языке, которая почему-то прошла мимо тебя, или ты всю жизнь делал что-то одним способом, а тут — сурпрайз! — есть, оказывается, способ лучше.
В 1с чаще всего если чего и нагугливается, то за редкими исключениями платные (пусть часто и копеечные) решения на сайте 1сного коммьюнити. Иногда что то бесплатное. На гитхабе не уверен что хотя бы пара сотен проектов вообще наскребется.
Впрочем автора статьи я все таки в большей мере не понимаю чем понимаю.
Увы, MSDN давно уже не торт — попробовал в этом году пользоваться на сайте, вскоре заностальгировал по временам шести дисков Visual Studio (404 на какие-то ссылки, недописанное в статьях, и прочее, и прочее).
а потом через полгода в гугле кончились примеры.
автор сам то верит в эту чушь?
Потом кандидат все интересные моменты поясняет, что, как, почему. Не возможно, что бы человек загуглил решение петшопа на левел 2 или 3 REST API и потом не смог объяснить, как он пришел к этому решению, в каких случаях рест оправдан, когда и как контракты и т.д.
Если на собесе папка, то и это сразу видно. Разговор плавно уходит на архитектуры, реализации различных консистенций и комуникаций.
Автор здесь какую то ересь толкает. Либо с людьми потом общались о небесных пирожках и сразу контракт.
З.Ы. И да, я запросто путаю на sql sort вместо order by и гуглю все, что мне незачем держать в голове
Дизайнеры повторяют работы других, строители делают скворечники по готовым зарисовкам— это все же уровень начального учебного процесса, когда еще далеко до бизнеса.
Тестовое задание должно быть:
1) разумным по времени и сложности, чтобы кандидату не было ощущения необъятного фронта работ.
2) сохранять пользу (выяснение компетенции) даже при активном использовании гугла.
3) требовать разумного объёма нажатых кнопок (это немаловажно, потому что задание может быть лёгким, но требовать много бойлерплейта — такое лучше избегать).
4) Не быть гуглябельным (т.е. кандидат должен решить какую-то задачу в голове, и код на экране — всего лишь выражение этого решения, а не решение).
5) Не напоминать рандомную таску из джиры компании (потому что это будет подозрительно напоминать "программирование халявными программистами").
6) Должно быть сделано хотя бы двумя-тремя действующими программистами в режиме тест-драйва.
Вот последний пункт часто забывают.
1990-ые воспитали в нашей стране поколение IT-гениев.
Связываю это с золотым поколением футбола в Бразилии, на фоне ужасного кризиса.
Нужда мотивирует сильнее всего.
Дискас? Или ну его?
Тогда футбол был единственным способом выбраться из нищеты.
В 1990 же айти была более-менее уверенной сферой в нашей стране.
Сам офигевал – неужели современное поколение настолько прониклось технологиями, что пишут код, как дышат?
Обычно таким красавцам на собеседовании по коду вопросы задают, чтобы понять их причастность.
сажал за комп и оставлял на полчаса-час
Зачем оставлял? Не важно было посмотреть и проанализировать то, как именно человек решает задачи?
Ну, получил в итоге то, что получил :)
Я бы сказал, это естественное развитие, потому что действительно бОльшую часть задач можно решить поиском информации в гугл.
А если в проекте есть свои архитектурные решения, то и собеседование должно проверять навыки построения архитектуры.
На мой взгляд, не нужно пытаться оправдать своё нежелание (лень и т.п. причины) составить задачи для собеседования, подходящие под проект, и просто спросить: «а почему именно такое решение?» и будет понятно понимает человек архитектуру, которая будет в проекте или нет, тем что появились «гугл-программисты» и виноваты они. Иначе получается перекладывание ответственности — я бы не хотел иметь дело с такими руководителями.
Сегодня «гугл-программисты» завтра «github-программисты», времена и люди меняются, но чтобы найти ответ, который поможет решить проблему, в первую очередь нужно научиться правильно и точно задавать вопросы.
немало встречал людей на интервью с 5+ летним опытом и знаниями уровня джуна.
даже нередко в различных статьях таким людям дают определение — «вечный джун» =)
не думаю что они заменят нормальных специалистов, просто такие люди будут занимать линейные позиции как кассир в пятерочке и получать соответсвующий оклад.
а тот кто захочет стать настоящим профессионалом — будет развиваться
Второй вопрос — умные все разбежались разом? Наставничество, кмк, могло бы частично решить эту проблему.
Интересно, что чувствует человек, который видит статью где начальник себя и подчиненных называет идиотами.
А почему идиота нельзя назвать идиотом? Или можно только хвалить? Пусть всю жизнь проходит в заблуждении?
Ну он или обиделся и не признает себя идиотом или понял, что нужно браться за ум.
Если первое — то он идиот на самом деле.
Но если бы меня назвали идиотом, то я бы все равно обиделся. Тому, что оказывается я идиот, работаю рядом с идиотами, и начальник тоже идиот по его же словам. Как-то сразу лишает мотивации и перспектив развития. Тем более если можно надеяться только на помощь гугла.
Идентифицировал себя как Гугл-программиста, печалька :-(
А что вы хотели, сегодняшний век IT предполагает, что нужны не только философы-гении программирования, но и обычные IT-работяги, от которых и не требуется быть профессионалами, знающими все парадигмы програмирования.
Почему-то никто не вспоминает о миллиарде простых задач, которые каждый день закрываются именно копи-пастом кода из SO, тем кодом, который не касается архитектуры проекта, а является именно тем самым «забей гвоздь, чтобы повесить картину». Конечно, идеалистический подход к коду имеет своё место (потом легче будет меинтененсить, будут меньше расходы на развитие и поддержку), но тогда придёшь к тому, чтобы для простых вещей нанимать профиков, а это уже переплата за мелочи.
И опять, как и в каждой дискуссии о качестве кода, часто проскальзывает некая нотка… нарциссизма и неприкосновенности (привет идеалистам). Не забывайте, что и без уборщиц этот мир выглядел бы иначе.
Проблема SO-программистов в том, что они будут забивать гвозди в стенку из гипсокартона, потому что не будут понимать, что такое гвоздь, и что такое гипсокартон. Да что уж там, они даже не задумаются, что стена может быть сделана не из дерева. Стена из кирпича составит очевидные проблемы, но преодолимые. А вот бетонная поставит в тупик.
Был опыт, пару лет назад искали пыхаря на усиление команды, тяжко шло, то нам не нравится, то мы — вообщем стандарт.
Однажды тех дир сказал, вы все олени, сейчас я быстро найду. В программировании он был около 0, но все же… нашёл где то вопросы по пхп с ответами, и давал их всем кому не глядя. Но не спрашивал их лично, а просто давал листочки и уходил по своим важным делам. Приходил где то через часик, спрашивал «кем вы видите себя через 5 лет» и отпускал кандидата.
В итоге, один такой персонаж успешно вышел на работу, как раз когда тех дир был в отпуске. На мою голову. После 3х дневных попыток поставить докер на убунту, и вопросы типа «какой порт фтп у гитлаба» человечек был уволен — тех дир больше не собеседовал никого)
Никогда не дают компьютер на собеседовании. Только ручка, бумажка и голова. Всегда задаю вопросы в том числе и по базовым моментам(даже у сеньоров и Лидов): структуры данных, алгоритмы, понимание работы ОС на уровне переключение контекста, шедулера и фрагментации памяти и тд и тп
Команда важнее всего, даже времени руководителя
Согнать с компа и сделать за подчиненного — верх непрофессионализма. Вот даже не верю что так бывает, что какой-то начальник может себе это позволить — так втаптывать в грязь подчиненных. Представляю, какая у вас там атмосфера.
Конец эпохи: в Индии массово увольняют программистов
Я не программист, поэтому до сего дня не вполне осознавал истинные причину и масштаб происходящего. Только прочитав эту статью на «Хабре», я понял, почему настолько медленно и неповортливо развиваются, в общем-то немногочисленные, программы и операционные системы, которыми пользуются сотни миллионов людей. Почему зачастую программистам проще похоронить отличный проект (пример — Opera на движке Presto), чем решать неизбежно возникающие в процессе его развития проблемы.
С помощью копипасты и бездумного конструирования мы, конечно, далеко не уедем.
habr.com/ru/post/303486
habr.com/ru/post/274987
С другой стороны, например, мне ничего не известно о процессах разработки ПО в корпоративном секторе, есть ли там изменения, сокращают программистов или нет.
Впрочем, вот свежая статья на ту же тему:
mediavektor.org/14391-gerd-leonhard-cherez-10-let-vse-programmisty-stanut-bezrabotnymi.html
Совсем давно это называлось выпускной в школе и вступительный в вузе но теперь ЕГЭ.
Совсем совсем давно экзамены были в школе каждый год по нескольким предметам. Теперь от этого осталась только сценка с Волькой Ибн Алёшой из Старика Хотабыча.
Так что…
Так что да, выкину интернет я, возьму по три книжки на каждый фреймворк, ямль etc и буду писать код, сверяясь только с ними, наконец преодолею своё Плато! Спасибо автору за совет! А то ведь я думал-гадал, почему я так путаюсь во всём и не могу запомнить ничего, не то что в универе, когда писал на голой Java диссер.
99.9% так называемых программистов — программистами не являются вовсе. Это было сказано хз когда и хз сколько раз уже.
При этом, сея «статья» выглядит логически противоречивой.
Джентльмены, ну сами посудите, если автор является «программистом» [всмысле реальным], то он никак не мог не заметить, причём давно, что его окружение из так называемых программистов ими никак не являются, причём сие не заметит только что слепой-глухой-инимножычкатупой. Ессно автор всё это и так видел, причём давно. Однако же почему то только сейчас для него сие стало «открытием». Что и приводит к фундаментальным противоречиям, и это в свою очередь позволяет отправить сей чюдный авторский рассказ в раздел «фентези».
п.с.: Имеется тривиальная дыра, однако же т.к. она тривиальная, то и смысла нет про неё говорить конечно. Можно предположить, что автор вообще не программист, ни реальный ни липовый [«Рогозин»]. Но это совсем из разряда сюра.
Я вот без гугла не могу, наизусть оч много чего не помню (у меня не фотографическая память), помню даже завалил собеседование где мне сунули бумажку А4 со словами, а теперь напиши программу… я завис с синтаксисом языка… который всегда IDE подсказывает...wtf мы в каком веке чтобы синтаксис помнить наизусть? я конечно работал с программистами на emacs и vi, но я не такой всёже.
Я вообще не понимаю как можно копипастить код и он будет работать, 90% кода на SO или кривой или очень привязан к контексту или вообще лишь маленький кусок.
imho с точки зрения автора я наверное гугл-программист, но я там максимум буду гуглить официальную документацию и в крайнем случае бойлерплейт какойнить редкой штуки
Очень часто такое слышу и читаю. и блин никак не могу понять, а что реально можно ничего не зная копипастить код с SO и всё прям работать будет?
https://gkoberger.github.io/stacksort/
Раньше эта штука в среднем скорее работала чем нет, но сейчас что-то поломалась...
Не пробовали гугл-програмистам отключить интернет при сдаче тестов?
Чувак сначала проходил длинное собеседование по куче разнообразных вопросов, потом решал несколько задач. На бумаге, как мы делали в ВУЗе.
ИМХО, на подобного рода собеседованиях больше проверяется стрессоустойчивость, чем собственно знания.
Человека загоняют в очень некомфортную ситуацию, когда у него отбирают привычные инструменты разработки, и при этом оценивают его знания, да еще и с жестким лимитом времени зачастую. Кто-то с такими ситуациями справляется легко, а многих людей просто «клинит» и они не могут решить простейшую задачу, вовсе не оттого что уровень знаний у них низок или опыта недостаточно.
В некоторых задачах на работе по срочному прикручиванию какой-нибудь новой «фишки» гуглом закрывается 90%, пусть не полной копипастой, но условным заимствованием с подгонкой под наши стандарты. Если разбираться подробно в «чудесной мега-супер архитектуре» очередного фреймворка или библиотеки, можно просто тупо потратить полгода времени, а за это время уже новую мажорную версию выкатят, со своими фишками и багами.
И когда я наблюдаю как какой-нибудь очередной джун у нас на работе изучает усиленно, очередной модный фреймворк в надежде «научиться кодить годноту», вместо того чтобы идти и писать код (пусть и при помощи гугла), я делаю себе заметочку — посмотреть через год,. А через год это оборачивается либо тем что он все эти свои теории бросает, и начинает просто клепать продакшен, либо начинает изучать еще один фреймворк (тот уже устарел) и его увольняют, потому-что он вроде получается в теме, но работать ему некогда.
Гуглом можно не пользоваться, если ты работаешь несколько лет в одном окружении, и ничего там не меняется, ты все выучил, и всю систему можешь отлаживать в уме. Я хоть и работаю уже в веб-разработке около 15 лет, далеко не в курсе всех модных новинок. На PHP и JQuery могу что угодно написать, занимаю хорошую позицию в нашей компании, если что-то нужно «эдакое», то всегда ко мне идут. А вот по новым модным фишкам JS я бы наверное на джуна собесдование не прошел, и случись на нем писать, я бы наверное тоже неслабо копипастил.
И вообще главное не код, а архитектура. Вот ей нужно людей и обучать в первую очередь, а как они уже пишут свой код, дело десятое.
Я интроверт и Гугл программист, и не вижу в этом ничего странного, да я провалю любое собеседование, где меня попросят писать код, но есть одно большое "но".
Я очень креативный, мои решения могут выходить за рамки стандартно умных, код для меня практически в любой форме второстепенное занятие. Я находил и нахожу решения, где другие программисты, которые могут писать "очень умный код" подходят к стене или пытаются создав ракету на Марс, перейти через улицу. Я не конфликтная личность и очень хорошо умею слушать других, за счет этого я хорошо вливаюсь в группу и потом зная общие запросы представляю свои решения. Мои решения имеют 100% попадание в цель и выполняю все раньше срока и за мой нестандартный подход, за короткое время, получил множество благодарностей и значительно вырос по зарплате. За короткое время я решил все наболевшие вопросы, решать которые не приходило на ум никому и продвинул фирму реально вперед, жалко только что из за этого уволили множетство работников.
И да, я был на собеседовании, где меня просили писать код, я его провалил с грохотом. Меня спроси в это время, сколько пальцев на руке, скажу 3. Я долго себя после этого успокаивал.
Теперь я знаю, что это моя сущность и моя сила. Я просто другой, это признают мои коллеги и мое руководство.
С уважением ваш
Гугл программист.
Теперь я знаю, что это моя сущность и моя сила. Я просто другой, это признают мои коллеги и мое руководство.
только ко всему этому надо иметь способ проходить собеседования, не заваливаясь на «элементарных вопросах»
Автоматизация процессов. Делалось вручную, соединил 2 системы. Фактически все было, но спали и в этом направлении, никто не думал, так как предыдущий программист завалил проект и сказал что апи очень сырое и не работает вообще. Это позволило запустить другие процессы, которые привели к сокращению персонала.
Людей держали из за нужды переноса данных из одной системы в другую.
По сути присоединили 3 системы куда поступали данные с основной, откуда уже были рабочие пути дальше.
Одну из систем подключили даже через human Emulator, я проработал путь и предоставил сырое, но рабочее решение, которое довелось до ума другим. При некоторых задачах, люди это ошибки, которые появляются при переносе.
Я художник — я так вижу :)
Будет очень хорошей идеей давать задание на который самому создавать код который бы гуглился в первую очередь. Потом их можно будет троллить вопросами — ой, какой интересный стиль, у кого учились? Как пришли к такому решению? Кстати, а вот эта строчка, она что делает?
Сомнительная история — может быть прояснится, когда автор скажет, где в начале нулевых интернет был на картинках
А оказывается, можно в принципе не стараться, и тупо воровать куски кода, не задумываясь о содержимом. Потрясающая в своей простоте гениальность.
Ну если вы хотите вечно жить на зарплату начинающего джуна — тогда да.
В статье же написано — за пределы стажерского уровня выйти этим ребятам не получилось.
Не представляете сколько народу согласны жить на зп начинающего джуна.
Да я не возражаю.
Однако часто бывает, что «слышал сколько платят в ИТ и хочу столько; что платят только специалистам, так я же гуглить научился уже; что нужно несколько лет вникать в суть программирования, то нет, то вы мне врёте и эксплуатируете; просто дайте денег».
Я очень хорошо помню тим-лида, который сказал: «Я всегда предпочту программиста, который использует встроенную в язык функцию, а не начнёт изобретать что-то своё». «Гугл-программисты» — это требование рынка. Других просто не возьмут. Те, кто умеют думать и могут придумать что-то без готового решения называют «изобретателями велосипедов» и отбраковывают.
Не-а.
Вы упускаете что будет если таковой функции не существует и её всё же надо написать.
Автор статьи написал об этом «выход на плато, без дальнейшего роста производительности».
P.S.:
А не писать то, что уже написано до вас нужно было еще и в прошлом веке, это никакое не требование сегодняшнего рынка.
На сколько я понимаю, в Европе очень важны рекомендации, без них даже квартиру арендовать в Западной Европе сложно. Так же важна психологическая совместимость и адекватность. Но если нет рекомендация и человек приехал из России, то приходится с ним долго общаться чтобы понять, что за человек
1. А у вас везде принято за фиксированную зарплату, положенную при приеме, требовать неограниченный рост продуктивности и сложности решаемых задач? Или в договоре сразу оговаривается, что либо ты обязательно вырастаешь и мы тебя озолотим, либо выходишь на плато и сразу «с пляжа»?
2. Может, у автора в конторе сразу выписывают денег в 3 раза «выше рынка» и ты уже как бы обязан расти над собой?
3. В IT не бывает пласта задач типовых относительно несложных задач, которых процентов 80-90 от объема и их надо тянуть ежедневно (просто потому что даже в прекрасном дворце большая часть физобъема стройки — тупо кладка камня по шаблону)? Для них тоже обязательно держать программистов с высоким потенциалом и заставлять кодить из головы, то, что миллион раз до этого уже использовано и работает?
Всякие такие нетиповые задачи, где нужно наконец-то применить что-то из теории, скорее радуют — ну наконец-то что-то не рутинное подвалило.
это если со своей колокольни…
патерны это крутой инструмент, которым нужно уметь пользоваться. Без паттернов сложные задачи весьма сложно решать. Как без моста сделать M+N реализаций вместо M*N? Или как без visitor'а собрать/обработать разнородные данные? Ну и т.д. Только колхозить.
Хотя это не значит, что везде их нужно пихать и каждую задачу пытаться решить хотя бы с использованием одного из них. Плюс многие из описанных GoB устарели (в том виде, в котором они описаны).
Сложное и дурак придумает.
В общем и в целом везде по разному и, чаще всего, индивидуально. Зарплаты, формальные и фактические обязанности могут отличаться в разы у людей на одной позиции в одной команде.
В договоре обычно нет, рост подразумевается, но с повышением зп. Но вот если N лет просидел на позиции джуна, не війдя на смиддла, то вполне могут решить расстаться в достаточно крупных компаниях.
За рыночную зарплату от тебя ожидают постоянного догоняния рынка: изучать и участвовать во внедрении новых технологий прежде всего. В среднем в личное время теорию изучаешь, в рабочее на практике пробуешь. Вот за отказ от этого "в рабочее" частенько готовы платить выше рынка в варианте: "у нас устаревшие технологии, переход на новые не планируем, за отказ от новых мы готовы переплачивать"
Сплошь и рядом, но скорее не кладка камня по шаблону в аналогии с дворцом, а проектирование плюс-минус стандартных помещений для слуг, охраны и т. п. из стандартных же элементов с мелкой кастомизацией под заказчика.
Не знаю как в других сферах, но в программировании достаточно ощутимое время тратится на вникание в уществующий проект. Ну т.е. каким бы сеньористым сеньором не был программист, в первое время на новом для себя проекте он может быть менее продуктивным чем условный джун, который на этом проекте сидит уже пару лет. В итоге, в первые месяцы работы наблюдается рост продуктивности нового сотрудника, а потом происходит выход на плато. При этом высота этого плато, и время зак которое до него сотрудник доходит, зависит от квалификации и сложности проекта. И ЗП в договоре, зачастую, выбирается с учетом эффективности на этом плато. И если сотрудник, не выходит на ожидаемое плато, то к нему возникают закономерные вопросы.
В теории, выход на плато должен случиться во время испытательного срока. В реальности же, есть огромное количество проектов такого качества, что там до плато можно год добираться. И тут уже испытательный срок тупо не работает и начинаются танцы с бубном на собеседованиях, чтобы хоть как-то увеличить шансы нанять нормального специалиста. Другое дело, что наймом зачастую занимаются люди, которые в найме имеют достаточно поверхностные знания, вот и имеем что имеем.
В случае джуна как раз выхода на плато, на которое платят ЗП при приёме, явного может и не быть, если он не просто в проект погружается, а и квалификацию свою увеличивает. там закладывается, например, что, условно, через год джун станет миддлом. А на испыталке экстраполируют рост перфоманса на этот год — попадёт или нет. Если, кажется, что через год не станет — не прошёл.
С джунами по-разному бывает. Бувают и вечные джуны, и бывают позиции на которых именно джун и нужен. Но в целом, да, в 90% от джуна ожидается рост как минимум в мидла.
А на испыталке экстраполируют рост перфоманса на этот год — попадёт или нет. Если, кажется, что через год не станет — не прошёл.
Нельзя экстраполяцией найти точку фазового перехода на плато. Экстраполяцией вы сможете только скорость роста эффективности получить, но никак не предел этой эффективности.
Так предполагается, что у джуна плато будет когда он сеньором станет, ну или хотя бы миддлом. Да, речь не о позициях где именно вечный джун нужен, а если такого вечного нет, то ищем нового как старый заикнулся о повышении.
Мы похоже про разное плато говорим. Когда сотрудник только приходит в уже существующий проект, то он в начале очень не эффективный, но при этом первое время его эффективность растет за счет вникания в проект. И этот рост многократно быстрее чем рост эффективности сотрудника за счет общего повыешения его скила. Но подобный рост достаточно ограничен по времени, и достаточно быстро (время сильно зависит от конкретного проекта) подобный рост останавливается и происходит выход на плато. Рост эффективности за счет роста общих навыков никуда при этом не девается и у него есть свои особые точки.
Увы, у меня не было нормальной возможности сравнивать эффективность двух джунов, один из которых давно на проекте, а другой только пришёл. Или просто проекты были достаточно большие и принципиально старались не допускать появления "ответственных" за ту или иную его часть. Каждый должен без проблем работать с каждой частью проекта. В рамках специализации, конечно — у бэкендера писать реакт-компоненты не требовали. Поэтому, возможно, плато о котором вы говорите не наблюдал. То есть растёт джун до миддла и одновременно вникает в проект. Как дорос, то вроде уже и со всеми частями проекта поработал, и любая новая задача не вызывает необходимости разбираться с нуля в новой части проекта.
Для меня как самоучки(чего я стыжусь и что стараюсь в скором времени исправить)основным критерием усвоенности является способность применить знания в реальном проекте, но иногда даже этого бывает недостаточно.
:(
Я постоянно что-нибудь забываю (C++ такой язык в котором нужно многое помнить чтобы использовать правильно) и поэтому без гуглежа и помощи со стороны я мог бы вообще отлететь как программист.
Некоторые упыри еще и по несколько часов мурыжат.
задавать вопросы нужно на понимание, тогда и не получишь говнокодеров. За 15 минут можно понять что из себя представляет человек.
Если за 15 минут можно понять что из себя представляет человек, то что мешает вам спустя 15 минут уйти с собеседования, поняв что перед вами "идиот" и "упырь", вместо того чтобы позволять себя "мурижить по несколько часов"?
Если я выполняю бизнесовые задачи (ну и меня на них и берут), а у меня просят написать подсчет чисел фибоначчи — до свидания. Не потому что я не знаю или не могу, а потому что я занимаюсь совершенно другими вещами. Я же не идиот, чтобы каждый день сидеть и ради таких деятелей поддерживать эти ненужные мне знания (и по факту они ему тоже не нужны).
Давайте представим мир в котором верна гипотеза "за 15 минут каждый может понять что из себя представляет человек". В нем все "не идиоты" уходят с подобного рода собеседований спустя 15 минут. Следовательно, интервьюеры, практикующие подобный подход, смогут нанять только идиотов. Следовательно, у них не будет нормальных сотрудников. Наблюдаем ли мы такое в нашем мире? Нет, не наблюдаем. Следовательно гипотеза не верна.
Скил "за 15 минут можно понять что из себя представляет человек" — это охренительно круто и охренительно редко. Большинство людей такими навыкаим не владеет. Если вы таким скилом владеете, то это прям очень мощно. Но не стоит окружающих мерять по себе.
«можно понять за 15 минут» не означает, что все собеседования должны длиться 15 минут.
Интервью должно 1) соответствовать целям набора 2) раскрывать сильные стороны интервьюируемого (ну или слабые).
Если ты берешь спеца на сортировку пузырьком, наверное да, он должен это знать. Если нет, то зачем ты вопросы высасываешь из пальца?
БОльшее число спецов работает по навыкам (порой не понимая сути). Это в любой сфере. Есть гугл, нет гугла — не важно. В любое время и в любой эпохе так было и будет. Почему? Таковы люди. Понимать — сложно. Научиться на примере легче. Перенять навык легче. Кто из нас любит сложности? Кто любит штудировать книги? Упорно работать? Единицы. Поэтому и хороших спецов вне зависимости от сферы всегда единицы.
А что касается 15 минут. Ну так задавай вопросы на понимание и понятно будет — разбирается человек или нет, понимает или нет. Чуть углубился и сразу понятно — вчера ли он это прочитал или реально разбирается.
пусть IDE, пусть редактор с подстветкой синтаксиса — но _без_ интернета (и без смартфона!)
тогда это будет адекватной заменой «писать код на листке бумаги»
Пускай сам себе изготовит из руды инструмент, срубит и распилит на доски дерево и сделает наконец-то табуретку!!!
Нам ведь нужен не столяр, умеющий работать, а супермен, который оказавшись на необитаемом острове с одной зубочисткой в руках, сумеет построить небоскреб.
скажем для проверки элементарщины вроде «написать реализацию односвязного списка с добавлением-удалением-поиском элементов» интернет не нужен.
мы ведь хотим проверить реальные знания кандидата, а не умение гуглить ответы.
Почему на интервью должны быть отличные от работы условия?
Потомучто реальные задачи обычно требуют знания кодовой базы проекта и редко решаются за время отведенное на интервью.
На работе у вас отключают интернет? Если нет, то почему на интервью должны быть другие условия?
На работе могут встречаться задачи, ответы на которые не гугляться. Следовательно нужны сотрудники которые бы умели решать задачи, на которые нет ответа в гугле. Следовательно было бы уместно проверить такой навык на собеседовании. Можно придумать задачу, которая бы не гуглилась. После того как такую задачу начнут задавать на собеседовании, она быстро попадет в гугл и начнет гуглиться. Следовательно перестанет удовлетворять критерию "не гуглиться". Следовательно придется придумывать новую задачу. Придумывать хорошие негуглящиеся задачи для собеседования очень трудозатратно. "Отключенный интернет" — это по-сути эмуляция "отсутствия задачи в гугле". Эдакий компромис между качеством собеседования и трудозатратами на него.
Следовательно нужны сотрудники которые бы умели решать задачи, на которые нет ответа в гугле.
ага, и с включенным таймером на 5 минут и двумя наблюдателями за спиной?
Мне вот чтобы решить задачу, которой нет в гугле, может несколько часов понадобится, подумать, чая попить, пару тестовых вариантов накидать.
А на собесе без гугла я по памяти за короткое время обязан накидать без ошибок рабочее решение… ага, офигеть как релевантно
1) мы вам платим за знания а не за поиск в гугле
2) если вы чтото ищите в гугле, вы обманули нас при найме, сказав что вы специалист
p.s. ппц конечно
Даже в докомпьютерные времена, типичное рабочее место инженера выглядело как стол с разложенными на нем справочниками и окруженный шкафами с книгами. Ни один человек, даже если он гений не может держать в голове весь массив информации, необходимый для хоть сколько-нибудь сложной профессиональной деятельности.
ага, и с включенным таймером на 5 минут и двумя наблюдателями за спиной?
Я не очень понимаю как из того, что "На работе могут встречаться задачи, ответы на которые не гугляться", следует что нужны сотрудники, которые бы умели решать задачи "с включенным таймером на 5 минут и двумя наблюдателями за спиной".
мне на собесе суют ручку с бумажкой и я должен выдавить из себя решение «без интернета» за промежуток времени очевидно не превышающий время интервью, то они хотят человека который способен сделать именно это.
А вы сами когда-нибудь проводили собеседования? Обычно гораздо более сложная логика чем просим сделать что-то потому что хотим человека, который способен это сделать. Может хотим человека, который скажет "задача идиотская, это есть в стандартной библиотеке"
А вы сами когда-нибудь проводили собеседования?
Да и не раз, мне нужен человек который думать может, а не по памяти конструкции из учебника переписывать на время
Тоесть если он на словах скажет где и как он будет искать решение — будет норм. Искать на SO решение которое есть в штатной документации — не норм например.
Обычно гораздо более сложная логика чем просим сделать что-то потому что хотим человека, который способен это сделать.
да, но судя по всему интервьюверы об этом не догадываются, что в реальности они проверяют совершенно не то что им нужно. Я много видел таких людей-коллег, которые знают наизусть учебник по языку, но совершенно не способны создать какуюто сложную систему… зато на кодревью потратить три дня на обсуждении реализации перебора списка при выводе логирования в режиме дебага- самое то, не обращая внимание на то что узкое место совершенно не там (а этомы уже не умеем, это нам не надо, там DBA нужен. SQL не учили, ORM наше всё)
Только мне кажется, что автор - писатель-фантаст?
Гугл-программисты. Как идиот набрал на работу идиотов