Комментарии 136
парсишь выражения - ты программист, парсишь джейсоны - увы, не дотягиваешь
Если вы напишете свой json парсер, вопросов нет. А если вы имеете ввиду взять пакет и оно само, то тут вопросы.
На мой взгляд, для написания json парсера сходу, нужно иметь, хотя бы, небольшой опыт решения похожих задач. Вот с реализацией двусвязных списков согласен - это типа база. Реализация клеточных автоматов - тоже. Допустим, я давно работаю с высокоуровневыми интерпретируемыми языками. Это значит, что я без дополнительной подготовки фиг напишу лексический анализатор и построю какое-нибудь АСД. Я вообще не запоминаю предметные области, с которыми не работаю. Но, как я понимаю, у вас эти задачи решаются регулярно, и вы ищете человека на решение этих задач. Может, имеет смысл конкретизировать эти требования в вакансии?
Вот с реализацией двусвязных списков согласен - это типа база.
Это не база. Это одна из специфик. Более того, вручную реализовывать такие вещи имеет смысл только на низкоуровневых языках с прямым доступом в память. А на какой-нибудь Жаве с GC это уже чисто обезьянничанье чтобы казаться типа крутыми. Там можно использовать только готовые встроенные имплементации где VM уже точно знает что она делает.
Имхо, си-шарп - это нативное обезьянничество. Его прикладные возможности - довольно странные. Его пытались впихнуть в вэб, но он не победил даже PHP. Не уверен, что он смог сильно пошатнуть позиции Java. Но, если честно, он на третьем месте после golang и kotlin среди языков с которыми я хотел бы плотно поработать. Хотя, может, даже и на втором месте после go.
Здесь есть определëнный интерес: мы решаем сходные логические или арифметические, или коммуникационные задачи на разных языках. И перевод арифметической формулы - в некую структуру данных и операторов, я нахожу стандартной задачей парсинга. Как и реализацию парсера структурированных данных. Это интересно, это база. Программирование построено на преобразовании человеческого языка - в машинный. Формулы или структуры данных - это человеческий язык. Их представление в машинных инструкциях - это наша основная задача, которую мы решаем каждый день в разных формах. Разве нет?
Вот понимаете тут в чем дело, вы не обладая знаниями УЖЕ делаете выводы. Си шарп занимает долю равную по объему джаве, причем шарп растет (в прошлом году это язык года по росту). Основная доля - как раз таки веб.
Я это слышал ещё когда си-шарп считался убийцей PHP. В итоге, в вэбе язык с таким порогом вхождения оказался даром не нужным. Ещё и компилируемый. Если вэб однажды и будет готов к тому, чтобы в нём выросла доля компилируемых проектов, то, скорее-всего, они будут написаны на golang.
Но, не скрою: мне он интересен. И я обязательно найду время в этом году, чтобы с ним познакомиться.
Это интересно, это база.
Это база для тех кто пишет низкоуровневые библиотеки и предоставляет сервисы уровню выше. Разработчик бизнес-приложений в принципе не должен заниматься столь низкоуровневыми вопросами. Если некий сеньйор не понимает концепции разделения сфер ответственности, то тут возникает серьёзный вопрос компетентен ли такой "сеньйор".
То есть, вы сейчас всерьëз считаете, что плохой сеньор - это тот, который не будет задавать вам неудобные вопросы?
Не могу с вами согласиться. Сеньор отличается, как-раз, широким спектром знаний и умений. Что если готовая библиотека не будет удовлетворять вашим потребностям? Или, что если вы не сможете использовать готовую библиотеку? Уверенное владение инструментом - это уровень middle, причëм, это начинающий middle. Middle+ уже знает как устроен инструмент внутри. Сеньор уже решает те задачи, которые стояли перед создателями инструмента. Хотя, с позиции middle starter кажется, что современная разработка решает какие-то новые вещи, на самом деле, это принципиально не так. Мы реализуем те же самые алгоритмы, что и разработчики до нас. Мы решаем те же проблемы. Изменился только объëм проблем и вычислительная мощность. Даже нейросети - это не новое изобретение. Книги о них я начал читать в начале десятых, и то, они тогда уже основывались на старой литературе.
То, о чëм вы говорите - это и есть описание современных проблем отрасли. IT нуждается в людях, которые осознали свою профессию, осознали необходимость решать тот объëм задач, о котором говорит, например, ТС. Но этих людей крайне мало. На их место и их зарплату претендуют люди, которые ещë не вышли из стадии работы с инструментами, и не перешли к стадии реализации типовых задач. Соответственно, этих людей никто брать не хочет, а они сами выйти за пределы своих возможностей не могут. Для них виноватым является интервьюер, который задаëт дурные задачки и "не понимает специфику современного IT".
То есть, вы сейчас всерьëз считаете, что плохой сеньор - это тот, который не будет задавать вам неудобные вопросы?
Неудобные вопросы задаёт следователь. А на собесе должны задаваться вопросы по делу. В принципе, я не возражаю когда хотят многостаночника. Но пусть пишут об этом сразу в вакансии.
Не могу с вами согласиться. Сеньор отличается, как-раз, широким спектром знаний и умений.
Я как разработчик с 25 летним стажем тоже конечно могу накидать сейчас в панамку вопросов как устроен CPU, как работает механизм виртуальной памяти, какие вы знаете механизмы поддержки когерентности кэшей. Ну а чо, "база" же, ухли. Или всё же это не совсем то о чём должна болеть голова у писателя микросервисов, а?
И таки да, я примерно это знаю. Знания не лишние. Но я на собесе по дотнету не задаю вопросы про ассемблер и даже про jit компиляцию а прошу лишь написать пару вложенных циклов.
Меня, помню, как-то мучали вопросами про кеширование строк Явой.. Все ответил, хотя и удивился такому акцентированию внимания на не слишком уж важной теме.
Потом, когда вышел на работу, оказалось что у них один сервак в ноде падал по памяти, и дамп был весь загажен повторяющимися строками, и они, таким образом надеялись найти виртуоза кеширования, который бы эту проблему поправил. :))))
Я поправил, но, разумеется, кеши там не при чем были, просто не надо давать джуну задачи по интеграции, и лить его код в прод без ревью (а именно так они и поступили, похоже). Джун написал какой-то дикий велосипед с фоновым потоком, который некорректно юзал Гибернейт, не давал ему "отпускать" сущности, в результате чего память текла и Гибер сжирал гигабайты оперативки пока сервер не падал..
Но тут, хотя-бы, люди хоть и довольно тупо, но пытались решить насущную проблему, а не занимались всякой фигней с "интересными викторинами" плана - "подловим этого дурачка на неожиданном вопросе"..
Я придерживаюсь мнения, что программист не должен уметь всё или хоть что-то из специфики. Программист должен мыслить на подобии тех кто работает с ним в команде.
Тот же парсер json сможет написать кто угодно, главное дайте ему возможность найти нужную инфу.
А на любом новом проекте будет своя специфика, где синьёр застрянет ровно как джун.
Отличие джуна от синьора в том, что у последнего больше вариантов как найти решение проблемы. А еще синьёр не станет скорее всего писать свой парсер json. А возможно и весь сервис заменит опенсорсом. Потому что это быстрее и эффективнее.
Я когда собеседую кандидатов, придерживаюсь тактики понять сам подход к решению задачи. Мне не нужен правильный ответ. Мне нужно знать зависает кандидат иза за неуверенности, анализа, какой из вариантов решения будет лучше, или потому что ему просто неинтересно.
Если я скину вам свой простенький синтаксический/лексический анализатор (с грамматикой, где помимо арифметики есть переменные, битовые операции, операции сравнения), который писал по учёбе лет десять назад, будет достаточно для прохождения собеседования?
, будет достаточно для прохождения собеседования?
Нет конечно. Вы что. Для устройства на работу в современном айти нужно пройти ритуал собеса в виде обряда лайвкодинга и допроса верховным шаманом. Это реально какой-то сектантский ритуал, не имеющий ничего общего с определением квалификации кандидатов.
В целом-то написано правильно. В целом. Но после "из 100 кандидатов не взяли никого" есть стойкое ощущение, что проблема была всё же не в кандидатах
Ну я сталкивался со случаями, когда мой коллега нанимал разработчика, и тоже, выбирая из примерно 50-60 кандидатов, не взял никого. Только это не вчера было, а году так в 2008. Оба случая конечно удивительные, но почему-то я в это верю.
Ну я сталкивался со случаями, когда мой коллега нанимал разработчика, и тоже, выбирая из примерно 50-60 кандидатов, не взял никого.
Подозреваю что коллеге надо к психологу. Поясню. Я когда-то, было дело, забежал к знакомым, чемоданами торгуют. Ну пока то да сё перетираем мы за жизнь, краем глаза наблюдаю, парнишка, явно программистского типажа, чемодан мучается выбирает. Ну все и всё перепроверил, мозг консультанту вынес. Прям на Марс собирается, не иначе. Вот мне потом эти знакомы рассказали они сходу таких распознают. Типичный обыватель просто берёт первое что ему более-менее подходит. А эти перфекционисты сами не знают чего хотят. А потом оба чемодана полетят в обычную Турцию и оба справятся со своим предназначением. Вот подумалось, а ведь эта же публика и людей нанимает также. Вместо того чтобы взять первого который будет просто таски закрывать, они Линуса Торвальдса зачем-то ищут.
Ах, это милое сердцу деление людей на "обычных" и "программистов"! Как вам там в 1998 году живется?
Ну, прямо скажем, айтишника довольно часто можно выделить из общей массы. Не все айтишники выделяются, но уж если выделяются, то это сразу видно.
Как говорится, не вся рыба - селёдка, но вся селёдка - рыба.
А кто такой IT-шник? Гик с безумным взглядом? Или холеный лид из финтэка? Или сисадмин с 25 летним стажем, который по совместительству уже архитектор? Или network engineer, который держит сеть в 15 локациях по всему свету?
В последнее часто слышу IT-шик, подразумевается программист. Прям обидно.
Как говорил преподобный Паисий Святогорец: присутствие христианина - это уже исповедание веры.
Присутствие айтишника - это уже токсичная духота.
Так непросто нанять Торвальдса на зарплату джуна, вот и мучаются люди :)))
Мне интересно сколько прособеседовали, чтобы хоть одного нанять. Я когда работал в компании которая жила "на свои", а не на инвестиции у нас тоже была статистика найма 1-2 на 100. Это как раз нормально когда у вас нет показателя найма и совсем небольшая текучка.
Никто не хочет вкладываться в людей и делится опытом, все сходу хотят найти сеньора помидора который знает все за пачку риса. Вместо этот статьи лучше бы документацию в конфлюенс написали, наняли джуна и заставили ее читать. Глядишь выйдет спец, не выйдет, не жалко.
Но ведь это тааак сложно, нужно человеку что то объяснять, писать какие то статьи в конфе... А еще, о боже он может позвонить и начать задавать вопросы, а у меня самого времени нет и тааак лень. Не, ну нафиг, я лучше поною тут, что спецов нет, пока есть 10 минут между созвонами.
Вместо этот статьи лучше бы документацию в конфлюенс написали, наняли джуна и заставили ее читать
Так и было до всем известных событий, когда у компаний были деньги и перспективы. Сейчас у многих до сих пор состояние неопределенности, а в таких состояниях бизнес всегда режет косты. Отсюда желание брать сотрудника, который будет работать и приносить пользу здесь и сейчас, а не может быть/потом.
Доки написать - это надо оторвать от процесса: "херак, херак и в продакшен", как минимум одного синьора-помидора, если этого не сделать, то там наверняка доки если и будут, то уже сто лет как неактуальные и толку от их чтения не будет, скорее вред.
Это во первых, во вторых - джуну придется придать няньку - того-же помидора, ну на крайняк мидла какого-нибудь, иначе толку не будет, это опять же человек от "херак-херак" будет оторван.
В третьих - у нас во многих фирмах процесс роста зарплаты с повышением квалификации поставлен просто никак. В итоге джун набравшись опыта и став мидлом, продолжает получать джунскую з/п, в результате чего начинает искать другую работу на мидловскую зарплату.
В итоге фирма на несколько месяцев нанимает не особо полезного работника, отрывает нескольких человек от основного "продактхерашинга", и не получает нового полезного работника.
Количество вакансий будет расти
Еще бы опцию:
Вакансии будут диверсифицироваться (разнообразиться) и расти.
Например, не было вакансий с использованием AI продуктов.
Программист/разработчик - нет. Что-то новое.
Да, я единственный в производственной компании, кто знает как работают хранимки в ПО, просто потому что я создавал эти системы как архитектор, как программист, который sql знает не понаслышке и хорошо знает предметную область.. Но создавал я их вынужденно, так как найти специалистов, знающих предметную область этих разработок практически невозможно, их просто нет. А без технологического ПО невозможна разработка и производство интеллектуальных датчиков. И мне существенно больше 48. На самом деле задач в компании множество, автоматизация бизнес - и производственных задач очень низкая, так как их много.
Чот не понял, с какого это перепоя парсинг [арифметических] выражений стал типовой задачей для встречного поперечного сеньйора? Либо ты варишься во всех этих парсерах, грамматиках и лексемах, либо правильно говорят «Это же в универе было».
Короче, на поверку опять оказывается "в моём представлении сеньйористый сеньйор это тот кто ответит на все вопросы моей викторины".
В универе очень ловко парсил все такие штуки. Сейчас (после 20+ лет работы в IT) вот так сходу, да еще в стрессовой ситуации (а кодинг на собесе это по любому стресс) хрен я вспомню и напишу. Реально - в работе таким не занимаешься, как правило, если нужен парсинг чего-либо, то самое разумное использовать соответствующие библиотеки, которые умеют это делать лучше чем твой самописный велосипед. А любые неиспользуемые навыки быстро и основательно забываются.
То есть вы на серьезных щах заявляете, что вычленить из формулы
1.2*x+(2.1*y-z)*0.12 числа, переменные операторы и константы вы после 20 лет в айти не можете?
Ну собственно статья как раз об этом, отрасль избаловала людей так, что люди напрочь отвыкли работать и думать головой.
Я заявляю что в стрессовой ситуации, с надзирателем за спиной, жестким лимитом времени и не попрактиковавшись - мне это будет сложно.
Спасибо, конечно за лестную оценку моего умения работать и думать головой. Именно это я и люблю в нашем IT сообществе - его непередаваемую токсичность.
Что такое "не попрактиковавшись"?
Вы не пишете циклы? Вы не пишете SQL? В не читаете ТЗ и не понимаете что делать обычно?
По поводу умения работать головой - получается что так. Я на всех своих рабочих местах за последние лет 12 многократно:
Парсил строчки в циклах
Писал и использовал регэкспы
Строил ExpressionTree чтобы дальше передавать их в EF
Использовал Reflection
Мне лично кажется что синьор тем и отличается от джуна, что у него есть и опыт и знания, то есть он способен быстро и самостоятельно разобраться как проще и эффективнее сделать задачу.
Вы крутой, тяжко вам наверное в окружении нас, тупарей, не способных за 15 минут решить такой примитив.
Я на всех своих рабочих местах
Внезапно, а другие люди на своих рабочих местах могут заниматься совершенно другими задачами.
Мне лично кажется что синьор тем и отличается от джуна, что у него есть и опыт и знания, то есть он способен быстро и самостоятельно разобраться как проще и эффективнее сделать задачу.
Он и разберётся. Разберётся с построением лексем и синтаксического дерева. Оценит, лучше рекурсивный спуск, или цикл с таблицей переходов и состояний. Он обязательно всё это сделает. Но не в формате собеса за 30 минут.
А кто-то требовал построение лексем и синтаксического дерева? Задача так и ставится обычно, если кандидат впадает в фрустрацию, а давайте в лоб в цикле разберем?
Еще раз, мне так никто и не ответил, как нужно собеседовать синьоров? Мы джентльмены, на слово верим? И тут мне карта как пошла!
А кто-то требовал построение лексем и синтаксического дерева? Задача так и ставится обычно, если кандидат впадает в фрустрацию, а давайте в лоб в цикле разберем?
Для чего? Для того чтобы подловить кандидата на какой-нибудь херне? Ведь не имея опыта обязательно херню сморозишь. Опытный сеньйор вот пятой точкой это чувствует и даже не пытается какие-то там циклы в лоб херачить. Решение любой задачи начинается с research, изучения best practices и всего такого. Даже если решал уже такие задачи, за несколько лет многое могло и измениться. В лоб херачить интуитивные решения побежит только джун.
Еще раз, мне так никто и не ответил, как нужно собеседовать синьоров? Мы джентльмены, на слово верим? И тут мне карта как пошла!
Выкатывайте абстрагированные задачи и проблемы хоть из Жиры. Побеседуйте с кандидатом как он будет их решать. Сразу несколько проблем решается:
Видно есть ли у кандидата требуемый опыт, не врёт ли. Подразуменевается что в вакансии все нужные требования указаны.
Приемлемы ли вам те подходы и решения которые предлагает кандидат. Любую задачу можно решить разными способами. Но может так оказаться что вы сторонник другой "школы". На собесе вот лучше это сразу выяснить.
Кандидат будет иметь представление с чем ему придётся связываться. Может ему нафиг это неинтересно. Пусть лучше сразу это поймет чем свалит потом через 2 месяца.
Понимаете, вот мы опять возвращаемся к теме статьи. Я не хочу
подловить кандидата на какой-нибудь херне
Я хочу, чтобы кандидат справлялся с работой. Если он начинает искать пакеты на любой чих, не представляя, как эта задача решается, это проблема. Если базовые алгоритмы (мы же не Кнута обсуждаем) вызывают сложности, это проблема. Если простейший запрос SQL вызывает сложности, это проблема.
Научить можно, но не синьора. Я лучше джуна возьму.
Я хочу, чтобы кандидат справлялся с работой.
Если это работа, то так и пишите в вакинсии:
Опыт низкоуровневой имплементации xxx, yyy, zzz. Использование готовых решений не допускается.
Опыт самостоятельной имплементации алгоритмов от xxx до yyy.
Знание SQL (тут примерно дать понять уровень). VACUUM там VACUUM, просто дайте понять какого пошива кандидат вам нужен.
Научить можно, но не синьора.
Это в 1998 сеньйоры были +- однинаковые. И то очень спорно. Сейчас даже в рамках одного стека и прикладной тематики знания могут очень сильно различаться и непересекаться. Написание прасеров хоть и не rocket science, но весьма узкоспецифичная тема, и каждый встречный-поперечный вовсе не обязан ею владеть.
Почитайте про "проклятие знания". В этом есть проблема и тестовых заданий, и подобных задач, которые вы даёте на собеседованиях. Вы знаете решение конкретной задачи и ожидаете, что хороший специалист должен эту задачу решать так же хорошо, как и вы и также быстро. Но ваши ожидания - ваши проблемы. По факту вы просто редкие выборку специалистов и сужаете себе круг таким фильтром. Давайте те задачи, которые специалисту надо будет решать в работе.
Лично я понимаю, что задача простая. Но я бы никогда не дал подобное на собеседовании, если бы этого не требовала работа. Всё люди разные и у всех есть свои лучшие и худшие стороны. И вы никогда не сможете определить уровень специалиста за одно собеседование и скорее всего упустили хороших кандидатов.
Если он начинает искать пакеты на любой чих, не представляя, как эта задача решается, это проблема.
Потому что любой разработчик, участвовавший в разработке реального продукта, а не парсинга строк знает, что если есть готовый, популярный, функциональный, покрытый тестами и имеющий кучу звезд на гите пакет - то нужно брать его, с некоторыми оговорками. Потому что изобретение велосипеда - это дорого по времени, дорого по деньгам и дорого по багам.
Если базовые алгоритмы (мы же не Кнута обсуждаем) вызывают сложности, это проблема.
Вы готовы за себя поручится, что, условно я, задавая задачи по алгоритмам, известным мне, услышу от Вас ответ в точности такой, какой хочу и по всему полю моих знаний?
Я согласен с вами. Сеньор должен иметь широкий спектр знаний в разных предметных областях. Но, допустим, для программистов на JS, Python, построения Expression Trees не являются популярной задачей. Но, гугл подсказывает, что для сишарпа это важная область.
А потом, после написания, в плечи еще прилетит: "Я бы вот эту лапшу рефакторить дальше не стал".
Т.е. мало в викторине угадать, надо еще сразу набело написать.
И вот каждый раз в такой ситуации вопрос возникает: если вы и в самом деле такие задачи у себя по пять раз на дню решаете на автомате, то почему так мало решений продаете, что всего 350+ в получку специалисту выходит?
почему так мало решений продаете, что всего 350+ в получку специалисту выходит
А сколько должно выходить? Фирма платит по верхней планке рынка.
если вы и в самом деле такие задачи у себя по пять раз на дню решаете на автомате
Когда я устраивался, я на собесе написал простенький DI, что имхо посложнее чем по строчке побегать. И SQL запрос сделал. И знаете, я не считаю, что это круто, я считаю, что для синьора это маст хэв.
В ФААНГ жестче отбор и мне действительно бы пришлось зубрить несколько месяцев, а вот это все можно с нуля сделать быстро.
А, ну то есть тут некоторая дедовщина имеет место быть - "вот я на собесе диай написал, пусть и они тоже помучаются".
А сколько должно выходить? Фирма платит по верхней планке рынка.
А он, этот рынок, он сейчас вместе с нами в этой комнате? Вроде, и те, Петька, и эти сеньоров ищут, но в собеседованиях есть нюансы.
Логично было бы ожидать, что эквилибристы в коде нужны на закрытие очень дорогостоящих для клиентов задач, за которые и вознаграждение не "по рынку" должно строиться, а "от реализации".
а вот это все можно с нуля сделать быстро
Зачем набирать специалистов, которые сделают быстро то же, что и вы? Набирать надо тех, кто сделает лучше то, что вы делаете медленно. Попробуйте на собеседование давать такие задачи, и увидите, как много вокруг ценных кадров :)
Я на всех своих рабочих местах за последние лет 12 многократно:
Парсил строчки в циклах
Писал и использовал регэкспы
Строил ExpressionTree чтобы дальше передавать их в EF
Использовал Reflection
Если соревноваться своим "я", то я вот написал и вывел в прод сервис который парсит сайты, вытягивая нужный контент. Много всякой невалидной фигни повидал. Думаю что в парсинге я что-то понимаю. Но ваша задачка у меня вызвала фрустрацию, и я бы на неё не ответил. Вам не просто так намекают на некорректность вопроса.
Мне лично кажется что синьор тем и отличается от джуна, что у него есть и опыт и знания, то есть он способен быстро и самостоятельно разобраться как проще и эффективнее сделать задачу.
Золотые слова. Но как соотносятся с вашей задачкой про парсинг? Я вот использовал несколько библиотек (в которых пришлось разобраться) и пару регэкспов. Почему-то мне этого хватило, без ручного разбора строки на токены.
Если у вас специфика продукта связна с парсингом - то это валидный вопрос на собеседовании именно в вашу компанию. Если нет - то нет. Но в статье вы привели этот вопрос как универсальный, ещё и для найма. И от этого пригорает.
Ну у нас есть и задачи парсинга, т.к. мы грузим гигабайты сырых данных из разных источников. Это делает коллега на питоне. И еще у нас есть движок вычисленя выражений для серий данных на бэке. Но тут проблема не в этом.
Это НЕ специфика, а одна из кучи задач, как я уже писал что-то там считать из csv, сгенерить эксель, написать интероп.
Если это вызывает проблемы, то сотрудник не сможет эффективно работать, а зачем мне такое?
Ну, во первых, не все учились в универе. Во вторых, математическая тема чаще всего висит на аналитике, а не конечном разработчике. В третьих, чтоб использовать и писать свой токен, нужно сначала оценить "а нахрена"?
Реально задачка на уровень синьора: реализуйте в asp.net обработку ошибок.
Джун натыкает везде catch и return null; middle везде new CustomException и натыкает логеров, а синьёр не забудет в CustomException добавить внутренний Exception + впишет ExceptionHandlerMiddleware и уже туда логер. Тут и видна разница опыта. Без специфики.
Собеседующие, которые предлагают лайвкодинг, вообще должны гореть в аду, как по мне. Особенно если он не в привычной IDE, а как многие альтернативно одаренные любят - на доске или листочке.
Потому что лайвкодинг не покажет ничего, кроме того, умеет ли кандидат работать в сильном стрессе. И если это единственное важное качество на данном рабочем месте - бежать оттуда надо не оглядываясь
Я ниже отписал. Оно в любимой IDE, гуглом можно пользоваться. Что оцениваем тоже написал.
А как отбирать синьоров еще? Просто поговорили и взяли?
Как ни странно да, поговорили и взяли. В крайнем случае дали тестовое домой.
Если вы не можете по разговору о прошлых местах и задачах на них понять, сеньор перед вами с опытом, или джун после курсов - у меня для вас плохие новости.
А главный прикол (я не про вашу компанию, я не знаю чем вы занимаетесь и что разрабатываете) - это когда такие вот лайвкодинг "на 15 минут распарсить формулу на бумажке" дают компании, которые занимаются тем, что гоняют джейсончики из базы во фронт и обратно и рисуют формочки
А что даст тестовое задание домой?
Простое тестовое задание будет скопипащено со стэковерфлоу.
Сложное тестовое задание на много часов давать бесплатно синьору это моветон. Лайвкодинг - это нечто среднее. Нет требований сделать готовое решение, мы смотрим как человек работает.
Если вы не можете по разговору о прошлых местах и задачах на них понять, сеньор перед вами с опытом, или джун после курсов - у меня для вас плохие новости.
Ну лично мое мнение, что эти синьоры в 70% случаев ничего не умеют и лучше бы шли на завод. Процетнов 15 из оставшихся умеют хорошо говорить, но вот код пишут с трудом.
Фирма наша делает решения для энергетического рынка, мы считаем математические модели рынка, делаем прогнозы и предлагаем SAAS для них
Простое тестовое задание будет скопипащено со стэковерфлоу.
О, я ждал этого! Точнее, был уверен, что вы напишете именно это. Вам шашечки или ехать? Программисты должны решать прикладные задачи, если часть задачи он за 10 минут нагуглил на стековерфло, еще 10 минут потратил чтобы разобраться почему решение именно такое, и по факту за 20 минут законтрибьютил фичу - разве это не то, что нужно бизнесу?
Или у вас чисто академический интерес в программировании и вы платите своим разрабам просто за академическое программирование в вакууме? Тогда конечно такой вариант вам не подойдет.
Ну и как вишенка на торте - конечно по тестовому можно поговорить с человеком - почему именно так, какие еще варианты можно было бы и так далее - все эти кейсы на 99% покрывают проблемы найма, сразу будет понятно кто перед вами, без позорного (для обеих сторон) лайвкодинга
Вклинюсь в увлекательный топик, извините ?
Может просто хочется, чтоб с тобой работал кто-то "на одной волне", с кем будет интересно обсуждать и искать решения? Ведь "я" иду человека в "свой" коллектив, неужели не имею права?
Мнение имеет место быть, согласшусь, но тогда к чему этот плач Ярославны о том, как всё плохо в айти, что все сеньоры мошенники, ничего не умеют и профнепригодны? По факту всё сводится к тому, что автор не может найти людей на "своей волне", а не профессионалов, ну вы понимаете
Ну, честно говоря, найти таки сложно.Такое ИТ ?♂️
Откровенно, очень сложно представить практикующего программирование сеньора, который не может решить такую задачу, если у него в принципе есть навыки решения нешаблонных задач.
И что за стресс для сеньора на простом собеседовании? У него что, от этого зависит судьба семьи? Если сегодня не пройдёт, то компаний нет и завтра дети с голоду начнут погибать?
Откровенно, очень сложно представить практикующего программирование сеньора, который не может решить такую задачу, если у него в принципе есть навыки решения нешаблонных задач
Я считаю, что навык писать код и навык решать логические задачи нужно проверять отдельно друг от друга. Задача на кодинг должна быть в максимально известной кандидату предметной области. Логика - вопрос дискуссионный.
Тут уже писали, что навык решения практических задач и навык выдать ответ кодом на произвольный вопрос за 15 минут это разные навыки.
Алгоритмические собеседования лучше проходят не синьеры, а студенты, которые не прогуливали информатику в текущем семестре. Способность решить задачку ни чего не говорит о синьерности, но за то показывает, что кандидат в принципе интересуется темой и у него вероятно есть потенциал для дальнейшего развития.
Синьерский опыт это способность взять на себя ответственность за разработку компонента или подсистемы. Разбираться в требованиях, понимать критерии качества и уметь их достигать в рамках своей зоны ответственности. В случае парсинга я бы послушал как будет решаться задача, какие альтернативы он видит и как будет выбирать (готовые, кастомная разработка, или что-то ещё). Как считать эстимации. И естественно - как он поступает, если у него или его младших коллег на старте нет нужных компетенций.
Знаете, всё так, но именно основы алгоритмизации я рассматриваю, и ни в коем случае не навязываю мнение другим, как базовую грамотность, и нежелание или тем более неумение написать какой-то базовый алгоритм (именно базовый, просить написать на коленке какую-то сортировку слияниеи, конечно глупо) объяснить просто не могу и при оценке кандидата считаю очень подозрительным.
Это как гаммы - это не музыка, не мелодия, но без них музыкантом не станешь.
Ещё раз, это исключительно частное мнение.
А откуда все это возьмется, если простейшая задача уже в ступор его вводит?
По факту всё сводится к тому, что автор не может найти людей на "своей волне", а не профессионалов, ну вы понимаете
Как кто-то это охарактеризовал: "Складывается впечатление, что тимлид ищет себе собутыльника, а не человека который сегодня же начнёт закрывать таски".
синьоры в 70% случаев ничего не умеют
Процетнов 15 из оставшихся умеют хорошо говорить
И один вы в белом платье такой стоите красивый, да?
Я бы ответил так: я напишу какой-то код, который разберут эту строку на части, но я ХЗ как вообще принятно в индустрии такие задачи решать и в продакшен такой код пускать нельзя. В реальной ситуации, я бы сначала сходил в гугл с этим вопросом и посоветовался с коллегами. М.б. в компании есть какие практики по парсингу строк.
Ставлю на то, что сеньёры не просто хотят решить эту задачу, но и сделать это "правильно". А правильного решения они не знают, т.к. не занимаются такими задачами.
Это вы точно подметили. Тут похоже принципиальная разница между вчерашними студентами и людьми проработавшими какое-то количество лет в реальных боевых условиях. Студенту норм выдать что-то что как-то компилится и делает что-то примерно то что нужно, профессионала такое не устраивает и он крайне неохотно решает такие задачки на экзамене.. ой.. пардон, на собеседовании.
Ну так задача и состоит, написать какой-то код, заодно обсудить варианты а как еще это можно сделать.
С другой стороны, если мы будем с коллегами решать вопросы типа "а как лучше строчки парсить" на отдельных митингах, то мы будем иметь что имеем, десятки тысяч разработчиков в компаниях и кривой тормозной софт.
Вот мой опыт буквально пару дней назад. Нужно было быстро зачитать набор csv файлов в структуры, которые затем передаются через интероп в наш плюсовый расчетный модуль для отладки модели.
Есть прекрасный пакет CsvHelper, который, однако, не умеет просто так работать со структурами. Я бы мог конечно собрать митинг с коллегами на час, чтобы обсудить best practice по парсингу csv, посокрушаться, что есть траблы и с разделителями, и с экранированием, да и кодировка внезапно разная бывает!
А я просто написал за полчасика экстеншн метод который просто грузит эти файлы, который потом, если нужен будет в системе можно дорефакторить до production ready.
Я жду таких людей, а митинги пусть Сбер собирает
Согласен, если если разовая задача и мы контролируем входные данные, то без разницы как писать.
посокрушаться, что есть траблы и с разделителями, и с экранированием, да и кодировка внезапно разная бывает!
Ну то есть ты написал велосипед, который единожды отработал, но сломается при следующем вызове и считаешь, что запилил интеграцию? Сеньористо.
Создаётся впечатление, что у вас в компании много подобных решений.
Это проблема всех тестовых - угадай что подумал экзаменатор.
Я например подумал, что нужно получить такую структуру, которая потом позволит вычислить это выражение. Иначе какой смысл в парсинге?
Проблемными являются скобки, которые ломают порядок операций и только рег-экспами тут не обойтись.
А оказывается надо было просто вычленить каждый компонент, и запихнуть например в массив. Ну да, тут и рег-эксп, сплит или цикл по строке с динамическим окном.
Но по хорошему - в лит код задачах дают пример входных и выходных данных.
Вычленить это же не просто нарезать на лексемы а дерево построить? Т.е. какой-нить рекурсивный спуск использовать? Т.е. надо расписать грамматику и все это грамотно закодить прям на собесе в лайф режиме и надеяться что оно все заведется? Сколько вы там пркдлагаете, 350к? Если бы я сходу такое мог решить, то поехал бы в штаты работать за 10к долларов в гугл или Фейсбук, кажется там задачи попроще даже.
Соглашусь, задача из разряда - если никогда такого не делал, то тупить можно долго, особенно если еще и гуглом нельзя пользоваться.
У меня, наверное, была какая-то нетипичная работа, но за последнии 5 лет я писал подобные парсеры минимум 3 раза.
На кодинг в собесе обычно отводят очень мало времени, по остаточному принципу, сколько осталось после основной беседы, что-бы в час-полтора вложиться. Вот и получается, что к нему человек подходит во первых уже довольно уставший от беседы, во вторых с жестким ограничением по времени, в третьих с большим стрессом. Для многих (и для меня в т.ч.) очень тяжело что-то писать, когда времени мало и, условно, за спиной, тяжело дышит надсмотрщик. Если надо написать что-то привычное еще куда ни шло, а когда писать надо что-то что ты со студенческих времен не делал..
И вот вопрос - что в таком тесте проверяется? Стрессоустойчивость? Вам прямо на фирме постоянно приходится фигачить в прод огромные куски кода за считанные минуты? Тогда нам точно не по пути! Или вашей фирме нужны готовые специалисты по парсингу? Так было-бы честным про это заранее написать в требованиях к вакансии - нужен нам мол суперпрофи, занимающийся парсингом выражений. По крайней мере кандидат хотя-бы подготовился, освежил в памяти как это делается..
Кодинг сессия проводится отдельно, в удобное для кандидата время, в его удобной IDE, так что усталость - не тот вариант.
Задания даются итерационно, от простого к сложному, никто не требует написать за час алгоритм Дейкстры, хотя знать его было бы неплохо, конечною. В процессе сессии рекрутер помогает и направляет, если тупняки.
Предлагаются задачи на простые алгоритмы, максимум два цикла на десять строчек и пара функций на несколько строчек. И небольшой SQL где требуется IN со значениями из GROUP BY.
Что позволяет выявить такой тест?
Умение пользоваться любимой IDE (как человек использует шорткаты и рефакторинг). Это совместно с другими факторами позволяет понять насколько часто человек пишет код
Умение понять задачу, вычленить из нее подзадачи
Умение писать нормальный код - без копи-паста кусков, с вынесением отдельных методов, с нормальными названиями переменных/методов. Тут же идет и знание английского языка.
Охват знаний - например человек говорит, что строку можно распарсить регулярками. Не обязательно именно так делать, но то, что человек знает про регулярки или про ExpressionTree уже говорит о многом
Насколько человек вообще знает SQL, как оказалось, что 90% кандидатов ВООБЩЕ не способны написать что-то.
Насколько вообще человек умеет общаться с людьми
Еще раз, мы собеседуем людей с белой зарплатой 350 на руки + премия. Если вы считаете, что знать чутка SQL и написать цикл это огромные требования, то мы с вами живем в разных вселенных
Ну, у вас значит нетипичные собесы. Все лайфкодинги, прости господи, в которых я имел неудовольствие поучаствовать выглядели так как я описал выше - на бумажке, или в лучшем случае в обычном текстовом редакторе, с временным ограничением минут так в 15, и сопящим над ухом надсмотрщиком. Выдать что-то не то что годное, хотя-бы просто не тупое, в таких условиях, вот лично мне очень тяжело. Я привык даже простые задачи сначала обдумывать не спеша, потом кодить их в нормальной IDE, причем не пытаясь сразу выдать суперкачественный код, итеративно его улучшаю, добившись сначала просто приемлемой работоспособности и скорости.
Ну то, что в разных вселенных - это действительно правда. Вы - в той, где новые задачи, под которые у вас происходит найм, у вас будут решать бедняги, которые у вас в штате (то есть накинете на них допнагрузку без допденег). А все потому что по вашему мнению из 100 кандидатов нет ни одного нормального, которые не смогли пройти все ваши квесты именно так, как было нужно вам. И вот я вам скажу - живете в этой вселенной сами.
Проблема в том, что синьоры, которые не могут написать цикл, мне на текущем месте не помогут. Я и есть тот бедняга, который делает эти задачи и я не хочу брать синьора на 350к и еще год вводить его в курс проекта, заниматься парным программированием, проводить код ревью и рефакторить.
А чувак будет пить смузи и ныть про кривую архитектуру, легаси и вообще все надо переписать
Обжегшийся раз на молоке начинает с такой силой дуть на воду, что на него бывает страшно смотреть
Вы знаете, я скоро 20 лет в разработке и я видел два типа команд:
Команды которые в 30 разработчиков, аналитиков, скрам мастеров и коучей за 2 года не могут написать портал с интеграцией с 5 сервисами
Команды в 5 разработчиков за полгода пишут такой портал с интеграцией с 15 сервисами
На текущем месте у нас второй вариант. Хотел бы я работать по первому? Было и такое, нет не хочу.
И - дайте угадаю - проблема в первых командах ВСЕГДА была только в программистах, да? Ни в аналитиках, ни в заказчиках, ни в менеджерах - только в программистах, верно?
Нужен ли опыт парсинга выражений, чтобы писать портал с интеграцией с 15 сервисами?
Благодаря этому комментарию стало понятно, каких людей вы ищете.
Действительно очень круто, когда команда состоит из профессионалов, которые самостоятельно могут решать любые задачи.
Сейчас таких людей очень не хватает.
Однако есть мнение, что 350 тыс. в месяц на руки - это даже близко не "по верхней планке рынка" для таких людей.
Я бы с удовольствием бы услышал от вас, где дают такие деньги, потому что то что мне рекрутеры предлагают от сберо-втб-иннотехов и прочих мтсо-мейлру это 350 как потолок.
Понятно, что какая-нибудь суперспецифика (а как ее найти?) может дать больше, понятно, что кое-где заграницей зарплата выше, но я не видел множество вакансий даже на 400к.
За 450 я бы и сам с удовольствием перешел, а то я уже запарился так-то.
Предлагаю посмотреть на всё это с такой стороны.
Сейчас острый дефицит толковых людей, которые могут самостоятельно решать задачи (особенно сложные), доводить их до результата. Как я понял, вы ищете только таких людей.
Часть таких людей сейчас получают плюс-минус 350к. Им нет особого смысла переходить на такую же сумму.
Часть толковых людей сидят на невысокой зарплате. Лично знаю немало таких ребят из провинции, с хорошим опытом работы и совершенно неразвитым навыком прохождения интервью. В режиме экзамена они будут ошибаться, забывать вещи, которые на самом деле знают, их опыт будет казаться ненастоящим. Про таких вы скажете "на рынке огромное количество некомпетентных специалистов".
Есть толковые люди с прокачанным скиллом прохождения интервью, которые вышли на рынок и активно ищут работу. В момент выхода на рынок появляется огромное количество компаний, которые хотят пообщаться, провести интервью. Такой кандидат гарантированно получит несколько хороших офферов, это компании конкурируют за него. Есть предположение (да что уж, почти уверенность), что ваши подходы к проведению интервью отпугивают таких кандидатов.
ну так найми джуна за 35к)
Чем Git Flow отличается от GitLab Flow и GitHub Flow?
Есть аналогичный вопрос: "Чем отличается REST API и RESTFUL API" ?
Вообще бывает странно когда на позицию мидла или синиора начинают спрашивать юниорсксие или студенческие вопросы. Как бы юниорские вопросы задавай юниору.
Автор во многом прав, рынок перенасыщен псевдокодерами, псевдо hr, и даже целыми псевдо ИТ командами, от которых выхлоп меньше чем от одного нормального настоящего Мидла. Даже глянуть на статистику опроса, 50 % синьеры, насмешили. Постоянно набираем людей, у нас есть небольшое тестовое мин на 30. На проверку базовых навыков, минимальный sql и мини задачка на 10 строк кода. Набираем мидл+ так вот. Правильно его делает примерно 1 из 10 человек, которые считают себя мидл+. В результате отбор проводим только по нему. И чудесно но по факту 90% людей считающих себя крутыми кодерами, не достойны даже быть джуном в адекватной команде. А эффективные HR набирают огромные команды из этих упырей. Жду глобальной зачистки рынка с появлением эффективного скрининга.
Ваш фильтр отсеивает тех, кто не может в стрессовой ситуации с жестким лимитом времени решить эти задачки, наверняка еще и на бумаге, без возможности запустить и отладить, и с сопящим за спиной надзирателем.Только и всего. Возможно, среди отсеянных и есть какие-то "упыри", по вашему определению (класс, кстати, отличное отношение к людям в вашей фирме), но в основном я уверен, ваш бестолковый фильтр отсеивает массу годных работников. В общем-то оно и хорошо, я бы точно не пошел туда где людей "упырями" называют, только оттого что они не осилили вашу бестолковую викторину.
В IDE, с гуглом.
Вы не можете цикл написать без гугла? Вы не можете в этом цикле пройтись посимвольно, определить циферка это или буковка? В чем сложность? Мы же даже не вычисляли там это через обратную польскую запись.
Для понимания мы не сидим на созвоне с человеком, он делает его после небольшого интервью с hr, уже после созвона. С использованием чего угодно и на любом языке котором захочет, даже можно словами алгоритм описать. И даже иногда даём второй шанс если он потратил меньше часа на это что бы поправить задание. К тому же не называем лимит времени вообще, куда ещё комфортней?
В среднем закрываем вакансию в 10-15 кандидатов и несколько дней.
Вспомнил, кстати одно из недавних проваленных собесов с лайфкодингом..
Писал на "бумажке" (в текстовом редакторе) по заданию экзаменатора SQL запрос. Конкретно уже не помню, но такой, средней сложности с группировками и джоинами. Да, согласен из-за нервной обстановки допустил ошибку - забыл указать одно поле из селекта в группировке. Но эту проблему, если бы я в реальной рабочей ситуации писал реальный запрос, я бы увидел и исправил, сразу же как попытался его запустить. И даже там, я ошибку чуть позже поправил.
После собеса, из интереса даже запустил его на тестовой БД, запрос был корректный и без особых косяков в производительности.
И что вы думаете? В фидбеке (что само по себе удивительно, у нас редко кто дает фидбеки) упомянули что я совершенно не знаю SQL - не знаю что надо в группировке упомянуть поле из селекта, иначе запрос не будет выполнен..
И такой формальный и тупой подход я часто где встречал на собесах, его превращают натуральный экзамен с целью подловить экзаменуемого на ошибке или невнимательности.
Вы, кажется, забыли про псевдо-ИТ-компании, хе-хе (у вас ведь ИТ-компания, да?)
Почему из ста кандидатов мы не взяли никого?
да фигней страдаете потому что
вы потратили своих сил на пару человеко-месяцев
и чужих столько же
пора понять что поиск у вас кривой
и стоит просто взять кого-то на испытательный срок
или закрыть поиск потому что ну не шмогли вы
и еще
пора вам усилить/заменить менеджмент ))
Они нашли путь гораздо лучше - ныть на хабре какие все синьоры лодыри и самозванцы, ни одного нормального, а все те кто работает в индустрии и разрабатывает - они все самозванцы и не должны работать программистами (не смотря на то, что каждый из них где-то работал/работает и что-то делал/делает)
пора вам усилить/заменить менеджмент
Автор может за 15 минут написать парсер на .Net, а найти разработчика не может.
Может быть он просто занимается у них не тем, что умеет хорошо делать. Но почему? Было бы интересно услышать мнение менеджмента на этот счёт). //sarcasm
А менеджмента у нас особо и нет)
Как бы я неоднократно намекал руководству, что тут проблема и людей нужно брать вообще на развитие а не под проект через месяц, но это другая проблема.
В любом случае, я не хочу команду разработки в 20 человек там, где достаточно пяти нормальных. Просто этих людей надо искать профессионально.
И да, я отнюдь не жажду собеседования проводить, у меня там легаси нерефакторен и 3 проекта одновременно.
Просто этих людей надо искать профессионально.
Иногда достаточно этих людей просто не распугивать всякими лайвкодингами и прочими экзаменационными допросами.
у меня там легаси нерефакторен и 3 проекта одновременно
Ну вот это уже деловой разговор)) Если серьезно, человеческий фактор это ключевая составляющая любого технического решения. Нужен баланс между сложностью системы и доступностью людей с соответствующими навыками.
Сейчас найти разработчика-универсала, знакомого с VACUUM и .Net, думаю в разы сложнее, чем 10 лет тому назад. Значит-ли, что уровень упал? Не думаю. Скорее сменилась конъюнктура и ландшафт технологий стал другим. Сейчас чаще сталкиваешься с облачными хранилищами, без всех вот этих заморочек (но с массой других).
Но во всем этом есть и позитивная нота - на этой неделе весь хабр узнал про VACUUM в Postgres и теперь уже вряд ли забудет. Другими словами общий уровень грамотности сообществе чуть-чуть да вырос!
По моим наблюдениям, VACUUM в Postgres нужен больше для того, чтобы народ не паразитировал на бесплатном, а покупал какие есть коммерческие сборки - чем больше заплатите, тем меньше с ним будет возьни.
Например, в AlloyDB от Google достаточно знать, что есть флажок enable_google_adaptive_autovacuum. Хотя и это не обязательно - он включен по умолчанию. В общем, если вы классно пишите на .Net, то с этим скорее всего ни когда не столкнетесь. Либо у вас должна быть очень специфичная нагрузка на базу, или очень богатое руководство, которым не куда деньги девать. Поэтому они сидят на версии из опенсорса и ищут таких же бедалаг, кто согласится страдать над настройками вместе с ними, вместо того чтобы нормальный работой заниматься.
Вопрос про разбор математического выражения конечно улыбнул. Помню как в институте писал как раз похожий парсер, который разбирал подобные выражения и решал их: "приведение к нормальной форме" - кажется так это называется. Но с ходу в уме сообразить вот прям на собесе, может уже и не вспомню. Надо загуглить, почитать, и после этого будет результат.
Это я к чему? Что кандидат может элементарно забыть что то. Но помнить где это искать в случае необходимости.
Ну а то что проинтервьюировали столько кандидатов и не нашли нужного ну тут явно что-то не так. С теми, кто интервьюировал. Или с теми кто искал кандидатов, раз набрали одних тимлидов да директоров вместо сеньоров.
Вот вы устраиваете онлайн кодинги, какие-то задачки придумываете. А как это раскрывает потенциал человека? Особенно если у него опыта 10-15 лет и он может спокойно устроиться в другое место, где нет такого маразма на собеседовании.
Первый рабочий день нового сотрудника будет состоять совсем не в распарсивании строки на токены или разворачивании двусвязного списка. Вы на него вывалите кучу кода из репозитория, кучу багов и задач из бэклога, с формулировкой - разберись и сделай!
Так может стоит так же и собесы проводить?
Дайте кусок своего кода или кода с ошибкой, код мз МР джуна. Попросите разобраться и выполнить рефакторинг, объяснить, что код делает, найти в нем ошибки.
Конечно для вас такой подход будет сложней, потому что прийдется думать вместе с кандидатом и погружаться в его мысли и рассуждения. А не просто сверять ответ алгоритмической задачи с литкода.
Но если у вас очередь за забором 10 человек на место, то конечно можно и алгоритмическими задачами и онлайн коддингом отсеивать действительно стоящие кадры.
Если распарсить (не посчитать) выражение вида 1.2*x*(5*y-2)/z это сложно, то что вообще может сделать кандидат?
Что под этим имеется в виду? Построить AST-дерево выражения?
А! Так вот как это называется. Вот их надо на собес позвать:
https://habr.com/ru/articles/150043/
https://habr.com/ru/articles/281495/
(Мда, там только обе стати читать 50 минут, таким как я, не успею на собесе).
Если вы единственный знаете, как работают вот эти хранимки на проде — скорее всего, вас не уволят.
... но замену будут искать отчаянно, а как найдут, да подешевле - на вылет пробкой
А что кодили? Ну что говорили, то и кодил. Окей, что уж.
Т.е. просто работу работать это уже "фу таким быть" стало?
Напишите, пожалуйста, ваше мнение вот по таким вопросам
1. Вот у вас в компании требуется новый сотрудник (сотрудники). Вы их ищете какое-то время (полгода-год), вроде как находите того, кто понравился и вам, и вашему руководству. Идёте к директору, а он спрашивает: "Зачем нам ещё сотрудник, если вы уже полгода-год сами задачи закрываете?" Ну вот смысл расширения ИТ-подразделения, если на текущих задачах все справляются? Про запас тратить ещё 350к в месяц?
2. Вот вы приводите какие-то задачи для собеседования и спрашиваете: нормально или нет решать такие на 350к. А что у вас за задачи в вашей системе отслеживания задач? Например, там 10 открытых задач висят на вас и вы хотите 5 из них переназначить на нового коллегу. Они будут про что? Перенести и перекрасить кнопку? Развернуть новый сервис? Распарсить какой-то сайт?
" Ну вот смысл расширения ИТ-подразделения, если на текущих задачах все справляются? Про запас тратить ещё 350к в месяц?
Новые проекты. На старых более-менее справляются с растущим бэклогом на рефакторинг. Новые просто не потянем этой командой.
Задачи начиная от развернуть новые сервисы под новый проект, в которых в частности будет вычислительный движок формул, интеграции с кучей сервисов по REST и SOAP, выгрузки и загрузки CSV, реализация REST API для фронта на реакте, всякие генерации пдф и прочая фигня.
новый проект, в которых в частности будет вычислительный движок формул
Выглядит как идея статьи на Хабр :)
> Выгрузки и загрузки CSV, ... всякие генерации пдф
А это уже идея для тестового задания: "Вот пользователь совершил 100000 операций в нашем сервисе, они выгружены в csv, сделай отчёт для пользователя в pdf"
И вопрос про время найма. Вот у вас нужны сотрудники под новые проекты. О них узнаём в июле. Директор планирует начать в январе, есть полгода на поиск.
Через полгода возникает ситуация с отсутствием новых сотрудников. Я так понимаю, что вы сейчас здесь.
Если не секрет, то что происходит? Понятно, что новые проекты не запускаются. Но директор случаем не планирует что-то менять с наймом? Если планирует, то будет интересно почитать третью часть.
То есть я правильно понимаю, что из 100 человек-сеньоров никто не подходит под перекладывание json и сsv, фронт на реакте и генерации PDF?
Задачи начиная от развернуть новые сервисы под новый проект, в которых в частности будет вычислительный движок формул, интеграции с кучей сервисов по REST и SOAP, выгрузки и загрузки CSV, реализация REST API для фронта на реакте, всякие генерации пдф и прочая фигня.
Ну вот почему, почему нельзя всё это сразу написать в вакансии? Вычислительный движок формул? ОК. Значит и откликаться будут товарищи более-менее в теме. Значит и вопрос "а раздербань, мил дружок, формулу на лексемы" совсем не поставит кандидата в тупик. Польская нотация? Человек в теме прекрасно знает о чём речь.
Проблема не в квалификации разработчиков. Проблема что вы совершенно не умеете искать разработчиков с нужной вам квалификацией.
ТС, ты невнимательно читал комменты. Там чел сказал, что это было собеседование на Джуниора. У него Сеньëрство дальше никнейма не пошло.
И вообще, вся эта статья "Вас стало слишком много" - какая-то нездоровая накачка сообщества. Я там начал писать, что в России сейчас особые условия для развития айти, что Россия, в принципе, может даже принять сейчас уволенных гуглом разработчиков, и меня почти сразу назвали кремлеботом.
Судя по текущей политико‑экономической ситуации, расти рынок IT в ближайшие несколько лет однозначно не будет.
Хотя в целом с тезисами статьи согласен, некоторые детали вызвали у меня сомнение. Возможно, автор сознательно вставил в текст несколько сомнительных высказываний просто для того, чтобы было больше реакции на них? Не знаю. В цитате - как раз один из таких сомнительных тезисов. Я бы разделил прогноз на две части - положительную и отрицательную, и реализуются в реальности в скором времени оба сценария параллельно-одновременно. Положительный стрим: 1) будет расти объем и глубина серьезных проектов у серьезных бизнесов, прежде всего в области big data и высококачественного data science (хотя автор их вроде как поругивает) - в том числе в России и прежде всего в России, как бы ее ни ругали (просто потому, что идет мощный процесс "как бы выкрутиться из сложившейся ситуации", то есть именно сейчас тот самый "жареный петух клюнул нас в мягкое место", и нужно реагировать - российский ИТ сектор как раз и реагирует, мы вообще здесь максимально реализуемся, когда у нас начинает подпекать, но раз уж подпекло - только держись, развитие непременно будет!), 2) будет расти и очень быстро и значительно спрос на очень квалифицированных специалистов, в том числе и на узких специалистов-экспертов в какой-то области, как бы ни хвалили пресловутых T-shape специалистов. Отрицательный стрим - вот как раз для низкокачественного бизнеса, финансово неустойчивого (например, я считаю, что рынок мелкого и среднего online retail в РФ заметно перенасыщен плохо работающими и плохо ИТ-оснащенными компаниями, накопившимися у нас за "жирные годы развития экономики", когда можно было работать тяп-ляп и тем не менее оставаться на плаву) - вот этот слабый бизнес будет тонуть, и поэтому слабые и средненькие специалисты будут страдать, для них рынок ИТ действительно будет падать, поскольку именно такого рода слабый и средненький бизнес "пылесосил" их, так как скиллов у подобных специалистов вполне хватало, что обслуживать такого рода бизнес. У тех из средних специалистов, у кого остался запас энергии и решимости перешагнуть через себя и подтянуться до действительно хорошего уровня, чрезмерно тяжелых проблем не будет. У закосневших и не желающих развиваться - будут, и очень большие проблемы. Таким образом, ИТ рынок сейчас раздваивается - для стоящих специалистов он растет и будет расти долго и беспредельно, для слабых - резко падает и падать будет глубоко и долго. Но с точки зрения финансов - в России сейчас идут существенно, на порядки более мощные вливания финансов в ИТ, причем именно с хорошим контролем за результатом, а не просто "на распил", как это бывало раньше. И это не возможно не увидеть даже безо всякого инсайда, просто из открытых источников. Пускай жизнь заставила это делать вынужденно, после мощнейших "пинков от реальности" в виде всяких санкций и прочего - но процесс действительно пошел, и только слепой или ангажированный противоположной точкой зрения человек может этого не замечать. Как ни странно, полагаю, что за пределами РФ идет тот же процесс "очищения ИТ бизнеса от накопившегося неэффективного мусора", хотя характер трудностей там обусловлен несколько другими причинами, но это отдельная тема для обсуждения, останавливаться на ней не стану. В целом все как всегда в истории человечества - чем сложнее обстоятельства в какой-то сфере, тем быстрее эта сфера развивается и прогрессирует.
в России сейчас идут существенно, на порядки более мощные вливания финансов в ИТ
Судя по вилкам вакнсий этого не видно от слова совсем, где-то даже предлагают меньше, чем до войны, а хрюшка, вывесившая вакансию, на прямой вопрос в честь чего я должен дешеветь с годами просто молчит. При том, что три года назад она же другому моему нику только что "устную работу" сделать не предлагала в ответ на пожелание увидеть цифры в оффере процентов на 10 больше .
Хотелось бы мне увидеть вакансию, где за такую туфту платят 350к. Обычно или гигантский список технологий, где HR отфильтрует за отсутствие опыта хотя бы с одним пунктом (какая-нмбудь хрень, с которой можно разобраться за неделю), или вообще ЗП не написана.
Даже если кандидат и решит ваши задачки, я уверен на 99.9 что к таким душнилам он не пойдёт работать. От ТС веет таким снобизмом, что это место работы надо за километр обходить. Видишь ли, ТС, вокруг полно работы за те же деньги, где вот этого всего нет.
Порешал задачки, взяли на проект. 2 года формочки красил, 2 часа в день сдизайнером спорил из-за цвета. И через эти 2 года так отупел, что память начало отшибать. И так по кругу от компании к компании. Паспарсить уравнение теперь действительно = написать выпускную работу.
Когда не сумел нанять хоть кого-нибудь на 350+ и так припекло что аж на Хабр написал.
Суровая правда о разработчиках и разработке. Part 2. Три года спустя