Комментарии 33
На самом деле все немного по другому, но в целом вы на правильном пути и ваши мысли требуют дальнейшего развития. Ваши «звания» можно расположить в возрастающем порядке, сначала ты формошлепер потом теоретик и затем практик. Потому что когда ты джун: ты знаешь язык и инструменты с которыми прийдется работать, реального опыта при этом ноль. Если есть ментор — он тебе подсказывает, если нет — сморишь на то что уже работает и копируешь с изменениями. Когда ты мидл, ты уже хорошо знаешь языки и инструменты с которыми необходимо работать, умеешь писать красивый код, есть опыт решения типичных задач. Ну и когда ты уже «синьор помидор» — нет предела совершенству (потому что синьор синьору рознь). Ты не только знаешь инструменты и подходы, а можешь назвать преимущества и не достатки каждого и «крутость» тут измеряется в количестве решенных не типичных задач. В общем все те вещи которые растут только с опытом.
С одной стороны соглашусь, но с другой есть проблема — как понять градацию. Вопрос про SOLID задают на каждом собеседовании, я уже заучил эти принципы и рассказываю их с выключенным мозгом. При этом качество кода может быть любым. Собственно поток сознания и есть попытка как-то сделать переоценку. Ведь проблема когда кодер застревает на одном уровне по знаниям, но растет при этом банально из-за стажа, очень актуальна.
Понять очень просто — нужно задавать правильные вопросы на собеседовании. Конечно тут в большей мере играет квалификация собеседующего. Но, например, я когда спрашиваю про принципы SOLID и человек отвечает не задумываясь — я прошу привести несколько примеров из жизни. Кстати, стаж != опыт
Примеры тоже вполне успешно заучиваются.
А стаж вполне может быть аргументом в галерах, там важно тебя продать, а не умение писать код.
А стаж вполне может быть аргументом в галерах, там важно тебя продать, а не умение писать код.
Вот сразу видно что вы человек — теоретик, по своей собственной градации (: А вот если бы проводили собеседования и были, так сказать, практиком, то сначала бы расспрашивали про прошлые проекты и уже из них просили бы привести примеры. Ну и конечно, в особых случаях, ничего не мешает придумать свою собственную задачу и спросить как бы ее решили.
Если компании не важно умение писать код, то я бы подумал об том — стоит ли вообще тратить на нее время. В ней, скорее всего, ничему и не у кого будет учиться, а просто заработать денег можно и в другом месте.
Если компании не важно умение писать код, то я бы подумал об том — стоит ли вообще тратить на нее время. В ней, скорее всего, ничему и не у кого будет учиться, а просто заработать денег можно и в другом месте.
Не назвал бы себя прямо совсем теоретиком)
По тому что прикинул для себя:
— вопрос о прошлом опыте и интересных задачах смущает собеседника. Может быть так попадало, но ориентироваться на этот вопрос все же не стоит
— собственные задачи могут быть хороши, но то что для тебя очевидно для собеседника в стрессе может быть невероятно сложно.
— больше всего отдачи дают вопросы вида «Используете ли Вы Viper\Rx\Realm» и почему. Вот если тут нет понимания то это тревожный звоночек.
— теоретические вопросы в конце, как контроль.
По тому что прикинул для себя:
— вопрос о прошлом опыте и интересных задачах смущает собеседника. Может быть так попадало, но ориентироваться на этот вопрос все же не стоит
— собственные задачи могут быть хороши, но то что для тебя очевидно для собеседника в стрессе может быть невероятно сложно.
— больше всего отдачи дают вопросы вида «Используете ли Вы Viper\Rx\Realm» и почему. Вот если тут нет понимания то это тревожный звоночек.
— теоретические вопросы в конце, как контроль.
— опыт как раз и отличает июня от всех остальных, ну и если его негде было набраться за n-время, то селяви, нужно было искать контору где ценится качество кода, это кстати тоже показатель
— конечно сложно, но это показывает уровень. На рабочем месте тоже нужно будет сталкиваться с незнакомым, сложным и не очевидным.
С остальным примерно так и происходит (:
— конечно сложно, но это показывает уровень. На рабочем месте тоже нужно будет сталкиваться с незнакомым, сложным и не очевидным.
С остальным примерно так и происходит (:
Самое простое, сразу после теоретических вопросов про SOLID задать вопрос практического плана, на который должно быть несложно ответить, если действительно понимаешь принципы. В этом случае, если человек просто заучил, у него возникает ступор. Значит, на практике не применял.
Не соглашусь. Работаю в компании, где только айосников 20+ человек. Хорошо вижу на ревью и сеньоров копипастеров и джунов практиков. Меньше всего теоретиков, которые могут грамотно объяснить свое решение. А если лезет в UML нарисовать, то это очень большое удивление вызывает — очень круто с такими работать.
Ваше право. Лично мне кажется, здесь больше проблема в терминах и их значении (например когда я по малолетке подрабатывал тем что ставил «венду» и принтеры заправлял — меня называли программистом). Ниже greabock хорошо написал про роли, типа компания определяет тебе роль синьора за такие-то «заслуги» (много опыта, друг директора, переспал с ним и т.д.)
Статья не информативная, просто холивар можно разжечь на каждом абзаце и да, никто никогда не равен.
Не надо просить упрощать собеседования. Всегда спрашивал про SOLID и best practices, и давал примеры с ошибками, с просьбой обьяснить где архитектурная проблема и как исправить. При этом я никогда не делал акцент на теории, а на понимании, потому-что мне не нужны не пойми какие классы на 3000 строк и макаронные сервисы. При этом я никогда не спрашивал алгоритмы. А почему? Да потому-что не зачем мне грузить кандидата с алгоритмами для круд проекта.
А умение грамотно проходить собеседования не исключает умение их идентификации при собеседовании :)
У меня просто ощущение, что у автора не хватает опыта работы в корпоративных галеро-машин, чтобы понимать разницу.
Не надо просить упрощать собеседования. Всегда спрашивал про SOLID и best practices, и давал примеры с ошибками, с просьбой обьяснить где архитектурная проблема и как исправить. При этом я никогда не делал акцент на теории, а на понимании, потому-что мне не нужны не пойми какие классы на 3000 строк и макаронные сервисы. При этом я никогда не спрашивал алгоритмы. А почему? Да потому-что не зачем мне грузить кандидата с алгоритмами для круд проекта.
А умение грамотно проходить собеседования не исключает умение их идентификации при собеседовании :)
У меня просто ощущение, что у автора не хватает опыта работы в корпоративных галеро-машин, чтобы понимать разницу.
Идея не упрощать собеседования, а делать больший акцент на том почему принимаются те или иные решения. Примеры с ошибками — пример правильного подхода. Но многие ли так делают?
Может реально опыта не хватает, но толковых собеседующих попадается меньше чем хочется.
Может реально опыта не хватает, но толковых собеседующих попадается меньше чем хочется.
Я понимаю и мне жаль. Все упирается в корпоративные машины и протоколы. Обычно, к тебе приходят и говорят, надо сделать интервью и все, ты уже в сети интервьюверов. При этом софт скиллс не проверяется, да и в целом прям какого-то обучения, как его проводить не делается, просто ты сеньер, значит все ок. А потом получается так, что тебя собеседует человек, для которого не знание алгоритмов ставит на тебе крест, хотя с вероятностью в 90%, ты в своей работе не применишь ни одного. Есть чуваки которые просто показывают свое превосходство и морально давят, просто, потому-что они такие. Зато на бумажках все выглядит шикарно! Мария провела собеседования на софт скилс, Иван с Колей провели собеседование на тех скилс, кандидат не прошел, ищем другого, система работает. Бывает случаи когда есть паттерны по которым ты обязан спросить, даже если ты адекватный интервьювер, потому-что СТО придумал систему вопросов, которая не учитывает специфику проектов компании, а ищет вундеркиндов.
Что делать? Не отчаиваться, искать более адекватные компании, я бы сказал это 50 на 50 и делать упор на подготовку к собеседованиям, бред? Ну да бред, но так устроен процесс.
При этом в Европе как-то попроще, это больше проблема СНГ компаний.
Что делать? Не отчаиваться, искать более адекватные компании, я бы сказал это 50 на 50 и делать упор на подготовку к собеседованиям, бред? Ну да бред, но так устроен процесс.
При этом в Европе как-то попроще, это больше проблема СНГ компаний.
ох, больную тему вы затронули. по долгу службы сейчас веду проект, который плюс минус направлен на оценку /градацию/ ect проф.навыков и проф.пригодности в целом. и проведя многие месяцы долбясь головой о столешницу мы нашли только один правильный ответ на все наши вопросы: правильного ответа не существует. все градации основаны чисто на субъективном восприятии мира собеседующего с некоторой поправкой на масштаб организации. и тот, кого вы оцените дженом в своей организации с поправкой на ветер может быть оценен мидлом в другой, и даже сеньером в третьей. единого «ГОСТа» в этом направлении не существует. есть буквально несколько профессий, которые имеют нормативы как в теории так и в практике. но сфера IT и многие около IT направления не более чем чистой воды субъективизм
Слишком много слишком разных задач, всех подогнать под стандарт нельзя. Собственно и мысль в том чтобы не задавать шаблонные вопросы, а стараться оценивать способность человека принимать решения, тогда плюс-минус можно будет доверить любые задачи. А вот как это делать — тут уже реально можно холиварить вечно(
Да уже хватит измерять уровень компетенции должностным положением. Хватит, прошу. Во всех таких материалах — одна и таже ошибка: «как понять, что я сениор?». Да ни как не понять — ты либо прошел на сениора в конкретную контору, либо не прошел. А если прошел, то это еще не значит, что ты теперь «везде сениор». Просто ты подошел на эту роль здесь и сейчас. Ну или не подошел. Джун/миддл/сениор — это не про знания и опыт, а про роль в команде/проекте.
Вот есть продуктовый магазин в деревне Щукино, и там есть директор. А есть в каком ни будь Газпроме директор. Вы же не равняете этих директоров? Вот и с джунами/сениорами тоже самое. Конторы разные, необходимый уровень компетенций тоже разный. Всех под одну гребенку не причешешь.
Вот есть продуктовый магазин в деревне Щукино, и там есть директор. А есть в каком ни будь Газпроме директор. Вы же не равняете этих директоров? Вот и с джунами/сениорами тоже самое. Конторы разные, необходимый уровень компетенций тоже разный. Всех под одну гребенку не причешешь.
Ну, не совсем так, ваше замечание больше похоже на «синьор синьору рознь», всегда есть базовые вещи которые объединяют, условно, Senoir Web Developer и Senior Mobile Developer так же как и директоров деревенского магазина и в Газпроме. Остальное, так сказать — специфика предметной области.
А как писать вакансии? Нам нужен миддл и пачка текста что именно считается миддлом в данной конторе?
А как писать резюме? Я считаю себя сеньором потому что… и сочинение?
И тут нужна либо единая сертификация, либо другая точка отсчета.
Пример с директорами так себе, достаточно указать где работал.
А как писать резюме? Я считаю себя сеньором потому что… и сочинение?
И тут нужна либо единая сертификация, либо другая точка отсчета.
Пример с директорами так себе, достаточно указать где работал.
Нам нужен миддл и пачка текста что именно считается миддлом в данной конторе?
А разве сейчас как-то иначе делается? Миддл и необходимых набор навыков, плюс дополнительные пожелания.
А как писать резюме? Я считаю себя сеньором потому что… и сочинение
А разве сейчас как-то иначе делается? Работал там, делал то. Учитывая, что в резюме частенько преувеличивают заслуги, или умалчивают о причинах ухода — вполне себе сочинение.
И тут нужна либо единая сертификация, либо другая точка отсчета.
Так есть же сертификация. Только в сертификате написано "Профессионал" или "Специалист". Ни слова про "джуна/миддла/сениора". Потому что это про аттестацию знаний, а не про роль в команде.
В Badoo и Avito, например, ты без сертификата Zend не пройдешь на позицию Middle PHP Dev. C другой стороны, я знаю несколько сениоров из других контор, которые даже набора вопросов PHP Basics из этой сертификации не видели.
Еще раз: уровень компетенций !== должность. Только это я и хотел сказать.
Вариант оценки:
можешь решить задачу и отвечаешь за свои решения — специалист.
можешь решить задачу, но надо напоминать/контролировать — середнячок.
остальное — новичок.
можешь решить задачу и отвечаешь за свои решения — специалист.
можешь решить задачу, но надо напоминать/контролировать — середнячок.
остальное — новичок.
Только вариант.
Хороший кодер со слабыми софт скилами может впасть в ступор и стать середнячком.
Плохой кодер мог попасть на похожую задачу в прошлом и решить без проблем.
Оценивать надо не смог\не смог, а скорее как и почему. Иногда ход мыслей важней правильного ответа.
И задача должна быть максимально похоже на то что прийдется решать.
Хороший кодер со слабыми софт скилами может впасть в ступор и стать середнячком.
Плохой кодер мог попасть на похожую задачу в прошлом и решить без проблем.
Оценивать надо не смог\не смог, а скорее как и почему. Иногда ход мыслей важней правильного ответа.
И задача должна быть максимально похоже на то что прийдется решать.
Проблема, надуманная HR-ми! Если бы собеседование проводил тот тех-лид, к которому ты устраиваешься (а не случайный сеньор), то он знает и что спрашивать, и сколько за это стоит платить. И именно оторванность собеседования от процесса работы порождает всю эту канитель с градациями.
Почему этого не понимают руководители компаний — для меня загадка.
Почему этого не понимают руководители компаний — для меня загадка.
Сейчас меня закидают шоколадом, но приведу в пример 1С. Есть сертификация разных уровней: Профессионал, Специалист-Консультант, Специалист.
С одной стороны всё просто, есть бумажки которые определяют твой уровень.
С другой же но есть очень много «Манагеров пишущих тексты на русском языке» (Вроде как то так называют нынче 1Сников) которым эти дипломы не уперлись вообще.
Как следствие оценивать уровень просто по бумажкам — бред.
В основном оценка идет ориентируясь на прошлый опыт который подкреплен тестовым заданием и знанием теоретической части.
С одной стороны всё просто, есть бумажки которые определяют твой уровень.
С другой же но есть очень много «Манагеров пишущих тексты на русском языке» (Вроде как то так называют нынче 1Сников) которым эти дипломы не уперлись вообще.
Как следствие оценивать уровень просто по бумажкам — бред.
В основном оценка идет ориентируясь на прошлый опыт который подкреплен тестовым заданием и знанием теоретической части.
НЛО прилетело и опубликовало эту надпись здесь
Статью писал человек который на собеседованиях задавал вопрос «Используете ли Вы… и почему?» и в ответ слышал невнятное «ну все же так делают». И это не джуны.
Накидать формочки — задача не простая, но типичная и однообразная.
Множить на количество устройств? Это вообще зачем? Если использовать xib\storyboard то даже запускать проект не надо, сразу есть возможность видеть результат. Я понимаю если еще есть поддержка планшета в разных ориентациях, но для телефонов… Толковый дизайнер сразу укажет где надо сжать\добавить скролл, а где растянуть.
Помноженной на количество локализаций? Я правильно понимаю что создание экрана условно занимает час, добавление еще одной локализации уже будет 2 часа, двух — 3 и так далее?
Мысль в том чтобы задавать вопросы не о знании SOLID, а о умении в нужные моменты применять нужные принципы.
То что статья не для хабра понял слишком поздно(
Накидать формочки — задача не простая, но типичная и однообразная.
Множить на количество устройств? Это вообще зачем? Если использовать xib\storyboard то даже запускать проект не надо, сразу есть возможность видеть результат. Я понимаю если еще есть поддержка планшета в разных ориентациях, но для телефонов… Толковый дизайнер сразу укажет где надо сжать\добавить скролл, а где растянуть.
Помноженной на количество локализаций? Я правильно понимаю что создание экрана условно занимает час, добавление еще одной локализации уже будет 2 часа, двух — 3 и так далее?
Мысль в том чтобы задавать вопросы не о знании SOLID, а о умении в нужные моменты применять нужные принципы.
То что статья не для хабра понял слишком поздно(
НЛО прилетело и опубликовало эту надпись здесь
Использовать перегруженные storyboard вообще так себе подход + помним про @ibdesignable. Это если нужна наглядность, сам предпочитаю работать с кодом.
Верстка под разные экраны делается просто добавлением в отдельных местах UIScrollView для маленьких экранов и растягиванием отдельных вьюшек для больших. Если при получении макетов оговорить этот момент (что сжимать\растягивать\скроллить) время на разработку под разные экраны увеличивается незначительно.
Для локализаций есть возможность подгонять под размер контента, уменьшать шрифт если не помещается текст в UILabel. Опять таки, если оговорить поведение интерфейса при приемке макетов, то очень многих проблем можно избежать.
Верстка под разные экраны делается просто добавлением в отдельных местах UIScrollView для маленьких экранов и растягиванием отдельных вьюшек для больших. Если при получении макетов оговорить этот момент (что сжимать\растягивать\скроллить) время на разработку под разные экраны увеличивается незначительно.
Для локализаций есть возможность подгонять под размер контента, уменьшать шрифт если не помещается текст в UILabel. Опять таки, если оговорить поведение интерфейса при приемке макетов, то очень многих проблем можно избежать.
НЛО прилетело и опубликовало эту надпись здесь
Все это решается с atomic design вот вообще без проблем. В зависимости от условий меняете нужные шрифты\размеры, при этом сами вьшки получают уже нужные данные. Добиться pixel perfect можно без проблем (проверено).
И еще раз
Сделав сложный интерфейс один раз подход можно использовать везде, каждый раз при необходимости совершенствуя.
А теперь то что я пытался выразить статьей и у меня похоже не получилось.
Человек несколько лет пилит формочки. Он в этом мастер, реально делает гибкий и хороший UI. И хочет сменить контору.
И есть контора, у которой много задач на формочки. Но на собеседовании спрашивают про сложность алгоритмов. Которые мастер UI не может знать (именно знать, а не прочитать грокаем алгоритмы в ночь перед собеседованием), он с этим не работал.
И еще раз
Накидать формочки — задача не простая, но типичная и однообразная.
Сделав сложный интерфейс один раз подход можно использовать везде, каждый раз при необходимости совершенствуя.
А теперь то что я пытался выразить статьей и у меня похоже не получилось.
Человек несколько лет пилит формочки. Он в этом мастер, реально делает гибкий и хороший UI. И хочет сменить контору.
И есть контора, у которой много задач на формочки. Но на собеседовании спрашивают про сложность алгоритмов. Которые мастер UI не может знать (именно знать, а не прочитать грокаем алгоритмы в ночь перед собеседованием), он с этим не работал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного мыслей о джунах/миддлах/сеньорах