Comments 40
Отличная статья, Макс.
Я недавно решил потихоньку прощупывать рынок, т.к. на текущей работе проект близится к логическому завершению, и уже есть пара интересных случаев с собеседований.
В первом случае я предупредил что у меня есть основная работа с 9 до 18, поэтому могу подъехать на собеседование после 18 часов. На что мне сначала предложили приехать в понедельник в 15 часов, а потом предложили приехать в обед. Деньги текущего работодателя я не был готов тратить, равно как и пропускать приём пищи, поэтому написал вежливый отказ от собеседования. Было очень неприятно услышать в ответ от HR… тишину. Это к вопросу о культуре общения. Если этот комментарий читают HR-менеджеры — всегда вежливо «закрывайте» разговор с кандидатом, даже если что-то пошло не так.
Во втором случае всё было ещё интересней. Встретился с основателем калифорнийского стартапа в кафе. Целый час мне рассказывали про идею, стратегию компании, процесс привлечения инвестиций — было очень интересно. Ну а дальше… Мне дали айфон с открытым текстовым редактором и было предложено написать работающий код программы прямо в текстовом редакторе на экране айфона. Шумное кафе, мимо меня ходят люди и официанты, за соседним столиком орёт ребёнок, а я пытаюсь попасть по мелким клавишам… Задача была следующая — дан массив слов, найти все анаграммы. Я решил уточнить и спросить про анаграммы — правильно ли я понимаю что «face» и «cafe» это анаграмма, а вот «face» и «fface» — уже нет. Нормального ответа я так и не получил, пришлось гуглить и объяснять что анаграмма это когда переставили буквы в одном слове и получили другое, т.е. слова в анаграмме должны быть одинаковой длины. К слову говоря, задачу я успешно провалил, т.к. за все 10 лет программирования я так ни разу и не столкнулся с ней на практике. В итоге у меня получилась куча массивов — перебор всех слов в массиве и перебор символов в каждом слове — это было откровенно ужасное решение.Придя домой, я тут же залез в интернет, нашёл решение за несколько секунд (отсортировать сравниваемые слова по символам и сравнить) и за 5 минут его реализовал. От этого собеседования остался откровенно неприятный осадок. Я так и не понял, как знание алгоритма поиска анаграмм, который гуглится менее чем за минуту, и умение писать его в не самых лучших условиях поможет мне в реальной работе.
Теперь поговорим о моих методах найма. Я участвовал в нескольких стартапах и брал людей как на обучение, так и на работу. Расскажу про оба пункта:
1. Обучение. Тут большую роль играет мотивация, но кандидат должен хоть немного уметь программировать. Я сразу предупреждаю, что все глупые вопросы (из разряда «как найти подстроку в строке») нужно искать на SO и подобных ресурсах. Я же направляю кандидата: сначала предлагаю ему изучить GIT, потом работаем над git flow, стилем коммитов. После того, как освоена система контроля версий, начинается более детальное погружение в программирование — SOLID, KISS, DRY, YAGNI и прочие умные слова. Также я рассказываю про архитектуры, их плюсы и минусы, про паттерны и способы их применения, также даю стек библиотек, которые использую сам (Alamofire, ObjectMapper, Moya, RxSwift и т.д.) и помогаю с ними освоиться.
2. Найм. Обязательно спрашиваю про системы контроля версий, основные команды и правку конфликтов. Далее прохожусь по всем проектам кандидата и спрашиваю как он делал тот или иной элемент, какую архитектуру выбирал и почему, какие библиотеки он использовал. Иногда задаю теоретические вопросы чтобы посмотреть мышление, смотрю понимание принципов SOLID, участие в open-source проектах. Мне важна реальная работа — что кандидат уже делал и о чём он может рассказать.
Я недавно решил потихоньку прощупывать рынок, т.к. на текущей работе проект близится к логическому завершению, и уже есть пара интересных случаев с собеседований.
В первом случае я предупредил что у меня есть основная работа с 9 до 18, поэтому могу подъехать на собеседование после 18 часов. На что мне сначала предложили приехать в понедельник в 15 часов, а потом предложили приехать в обед. Деньги текущего работодателя я не был готов тратить, равно как и пропускать приём пищи, поэтому написал вежливый отказ от собеседования. Было очень неприятно услышать в ответ от HR… тишину. Это к вопросу о культуре общения. Если этот комментарий читают HR-менеджеры — всегда вежливо «закрывайте» разговор с кандидатом, даже если что-то пошло не так.
Во втором случае всё было ещё интересней. Встретился с основателем калифорнийского стартапа в кафе. Целый час мне рассказывали про идею, стратегию компании, процесс привлечения инвестиций — было очень интересно. Ну а дальше… Мне дали айфон с открытым текстовым редактором и было предложено написать работающий код программы прямо в текстовом редакторе на экране айфона. Шумное кафе, мимо меня ходят люди и официанты, за соседним столиком орёт ребёнок, а я пытаюсь попасть по мелким клавишам… Задача была следующая — дан массив слов, найти все анаграммы. Я решил уточнить и спросить про анаграммы — правильно ли я понимаю что «face» и «cafe» это анаграмма, а вот «face» и «fface» — уже нет. Нормального ответа я так и не получил, пришлось гуглить и объяснять что анаграмма это когда переставили буквы в одном слове и получили другое, т.е. слова в анаграмме должны быть одинаковой длины. К слову говоря, задачу я успешно провалил, т.к. за все 10 лет программирования я так ни разу и не столкнулся с ней на практике. В итоге у меня получилась куча массивов — перебор всех слов в массиве и перебор символов в каждом слове — это было откровенно ужасное решение.Придя домой, я тут же залез в интернет, нашёл решение за несколько секунд (отсортировать сравниваемые слова по символам и сравнить) и за 5 минут его реализовал. От этого собеседования остался откровенно неприятный осадок. Я так и не понял, как знание алгоритма поиска анаграмм, который гуглится менее чем за минуту, и умение писать его в не самых лучших условиях поможет мне в реальной работе.
Теперь поговорим о моих методах найма. Я участвовал в нескольких стартапах и брал людей как на обучение, так и на работу. Расскажу про оба пункта:
1. Обучение. Тут большую роль играет мотивация, но кандидат должен хоть немного уметь программировать. Я сразу предупреждаю, что все глупые вопросы (из разряда «как найти подстроку в строке») нужно искать на SO и подобных ресурсах. Я же направляю кандидата: сначала предлагаю ему изучить GIT, потом работаем над git flow, стилем коммитов. После того, как освоена система контроля версий, начинается более детальное погружение в программирование — SOLID, KISS, DRY, YAGNI и прочие умные слова. Также я рассказываю про архитектуры, их плюсы и минусы, про паттерны и способы их применения, также даю стек библиотек, которые использую сам (Alamofire, ObjectMapper, Moya, RxSwift и т.д.) и помогаю с ними освоиться.
2. Найм. Обязательно спрашиваю про системы контроля версий, основные команды и правку конфликтов. Далее прохожусь по всем проектам кандидата и спрашиваю как он делал тот или иной элемент, какую архитектуру выбирал и почему, какие библиотеки он использовал. Иногда задаю теоретические вопросы чтобы посмотреть мышление, смотрю понимание принципов SOLID, участие в open-source проектах. Мне важна реальная работа — что кандидат уже делал и о чём он может рассказать.
Странно, что задача с анаграммами вызвала такие затруднения… Используемые-то трюки общие для очень большого класса задач!
Первый трюк: нормализация. Если построить функцию, которая будет выбирать один и тот же элемент для целого класса эквивалентности — то проверка двух элементов на эквивалентность сведется к применению этой функции и проверке на строгое равенство.
Может, это и звучит страшно, то используется-то этот прием постоянно! Когда хотят сравнить две строки без учета регистра — обе строки приводят к нижнему регистру (вы точно за всю карьеру программиста ни разу этого не делали?). Когда хотят сравнить две строки без учета различий в записи одних и тех же символов при помощи кодовых позиций юникода — их обе приводят к нормальной форме. Когда подписывают XML-файл, из него выкидывают незначимые пробелы...
Да, а когда сравнивают две строки на предмет анаграммы — их обе сортируют.
Второй трюк — для нахождения одинаковых элементов в массиве надо массив отсортировать.
Может и делал когда-то давно. If you don't use it — you lose it.
В мобильной разработке основной спектр задач состоит в построении интерфейсов и обеспечении клиент-серверной архитектуры. Алгоритмические задачи бывают не так часто, плюс у меня было немного офигевшее состояние от просьбы написать работающую программу в шумном кафе в текстовом редакторе айфона)
В общем, всё знать невозможно. Я пришёл домой и разобрался в вопросе, закрыл свой пробел. Ну и Вам спасибо за описанные трюки)
В мобильной разработке основной спектр задач состоит в построении интерфейсов и обеспечении клиент-серверной архитектуры. Алгоритмические задачи бывают не так часто, плюс у меня было немного офигевшее состояние от просьбы написать работающую программу в шумном кафе в текстовом редакторе айфона)
В общем, всё знать невозможно. Я пришёл домой и разобрался в вопросе, закрыл свой пробел. Ну и Вам спасибо за описанные трюки)
Наверное удивитесь, но программист пришел со своего проекта и у него в голове свой код, свои объекты архитектура, шаблоны мышления решения именно «проектных» типовых задач. Нужно некоторое время на «переключени контекста», а собеседование и так дополнительный стресс для мозга (подсознательная и сознательная оценка собеседника(ов)). И тут тебе в лоб «задача-тест» не удивительно, что не все разу могут подобрать решение. Это не значит что программист «тупой» или «не грамотный» и т.д., просто «фоновые потоки» заняли все ресурсы. Вполне возможно что через минут 30 спокойной обстановки он выдаст решение, даже процитировав на память API
Вы, конечно же написали этот комментарий на айфоне? Скорее всего в метро, держась одной рукой за поручень. Я и рад был бы восхититься, но считаю подобный подход глупостью. Для всего есть свои инструменты, и скатываться в дикость (писать код не в IDE) это банально экономически неэффективно (равно как и развивать этот навык). Я лично не ем руками, для этого есть столовые приборы. Не пишу код в текстовых редакторах, для этого есть IDE с возможностью рефакторинга и анализаторы кода. И, конечно же, перед работой над задачей, я хотя бы поверхностно знакомлюсь с существующими реализациями и best practices (если применимо).
Возможно, Вам не хватило уверенности для того, чтобы аргументированно отказаться от выполнения безумного предложения? Я бы ответил предложением написать код на бумажке в псевдокоде, предварительно описав устно общую идею алгоритма (кому-то хватило бы и этой части ответа). Некоторые работодатели заинтересованы в наличии у соискателя критического мышления в отношении заданий, а с другими я работать не сьал бы.
P.s. писал с телефона, на ходу. Лёд, холод. Ничего страшного. Но код… "Извините, нет"
С уверенностью у меня всё нормально)
А вот аргументированно отказаться от этого безумного предложения — стоило бы. Честно признаться — был шокирован, поэтому как-то не сразу смог сообразить что не нужно такой ерундой страдать, а надо сразу отказываться от дальнейшего продолжения интервью.
Но что есть — то есть, и опыт получил, и вам грабли показал)
А вот аргументированно отказаться от этого безумного предложения — стоило бы. Честно признаться — был шокирован, поэтому как-то не сразу смог сообразить что не нужно такой ерундой страдать, а надо сразу отказываться от дальнейшего продолжения интервью.
Но что есть — то есть, и опыт получил, и вам грабли показал)
Подозреваю, что решение задачи было отнюдь не важным моментом. Как правило при стресс-собеседованиях смотрят на умение принимать решения в критических ситуациях, думать в напряжении и не сдаваться при поставленных задачах. Если это было собеседование в Долину, то тогда понятно почему именно так все и проходило. Во многих молодых стартапах обстановка на работе довольно стрессовая, постоянный шум-гам, изменение приоритетов, смена менеджмента и процессов каждую неделю. https://www.susanjfowler.com/blog/2017/2/19/reflecting-on-one-very-strange-year-at-uber
Алгоритмию дают для того чтобы понять ваш стиль мышления, скорость понимания вопроса, возможность задавать нужные вопросы, и думать не имея полного описания проблемы.
Много раз я слышал, особенно в СНГ сообществе, о том, что такой подход не адекватен — да он не адекватен для определенных условий, например стабильных продуктовых или аутсорс компаний, а для стартапов, стрессоустойчивость при неизменной производительности — ключ к успеху в некоторых аспектах.
И суть тут далеко не в том, что решение этой проблемы гуглится за 5 или менее минут или не в том, что вы никогда не будите это применять на практике. Проходя в свое время собеседование в Facebook, они дают множество материалов на эту тему, на тему собеседований и ожиданий от кандидата(Facebook хочет чтоб у вас получилось поэтому они вам помогают), могу порекомендовать книгу http://www.crackingthecodinginterview.com
Многим людям присущи ошибочные суждения, когда нет полной информации об условиях. С вашей стороны собеседование могло быть абсолютно неадекватным, а со стороны основателя это мог быть давным давно пройденный этап, десятки уволенных сотрудников неспособных держать нужный темп, он даже мог сам понимать, что вы думаете, что это интервью неадекватное, но тем не менее он делал свою работу.
Алгоритмию дают для того чтобы понять ваш стиль мышления, скорость понимания вопроса, возможность задавать нужные вопросы, и думать не имея полного описания проблемы.
Много раз я слышал, особенно в СНГ сообществе, о том, что такой подход не адекватен — да он не адекватен для определенных условий, например стабильных продуктовых или аутсорс компаний, а для стартапов, стрессоустойчивость при неизменной производительности — ключ к успеху в некоторых аспектах.
И суть тут далеко не в том, что решение этой проблемы гуглится за 5 или менее минут или не в том, что вы никогда не будите это применять на практике. Проходя в свое время собеседование в Facebook, они дают множество материалов на эту тему, на тему собеседований и ожиданий от кандидата(Facebook хочет чтоб у вас получилось поэтому они вам помогают), могу порекомендовать книгу http://www.crackingthecodinginterview.com
Многим людям присущи ошибочные суждения, когда нет полной информации об условиях. С вашей стороны собеседование могло быть абсолютно неадекватным, а со стороны основателя это мог быть давным давно пройденный этап, десятки уволенных сотрудников неспособных держать нужный темп, он даже мог сам понимать, что вы думаете, что это интервью неадекватное, но тем не менее он делал свою работу.
Я с вами не согласен во многом.
Прежде чем я продолжу комментарий, хочу отметить, что сейчас у меня 5 стартап по счёту, в котором я отвечаю полностью за всю техническую часть (CTO). Я не считаю себя экспертом, обучение — вещь бесконечная, но определённый опыт у меня есть.
Начну со стрессоустойчивости и стартапов. Я считаю, что если в стартапах стрессовая обстановка, то это явная недоработка со стороны руководства. Посмотрите Joel Test, в 8 пункте явно написано «Do programmers have quiet working conditions?». Стартап может менять направление, приоритет задач может меняться, но обстановка вокруг программистов должна быть нормальной. Разумеется, при смене направления развития продукта или критических багах в субботу вечером у программистов может возникнуть дискомфорт, но почти все программисты, с которыми я работал, достаточно спокойно относятся к таким явлениям. А вот шумная обстановка для программиста — верная гибель, не позволяет сосредоточиться и ведёт к быстрому выгоранию. Крупные компании вроде Google зарабатывают огромные деньги и они могут позволить себе текучку кадров из-за «выгоревших» работников, а вот стартапам и небольшим компаниям нужно лучше организовывать труд работников для того, чтобы сохранить костяк команды и нормально дойти хотя бы до релиза, а ещё лучше — до точки безубыточности.
В нашем стартапе мы уважительно относимся друг к другу, постоянно работаем над взаимопониманием между всеми участниками. Именно поэтому мы с удовольствием работаем сверх нормы и без проблем фиксим баги в час ночи. Если в стартапе изначально токсичная атмосфера, то стоит ли туда идти? Душевный покой не купишь)
Теперь по поводу адекватности подхода. Программирование это как искусство, так и ремесло. Так вот, с точки зрения ремесла, нужны инструменты для решения тех или иных задач. Если мы лишим инструментов электрика, то чем ему замерять напряжение в сети? Пальцами? К тому же, достаточно глупо просить электрика заменить сантехнику, равно как и просить мобильного разработчика решить алгоритмическую задачу. В мобильной разработке алгоритмические задачи встречаются крайне редко, основные задачи это красивый интерфейс и приём-передача данных на сервер. Электрик может разбираться в сантехнике, а может и не разбираться — это не его основная задача. Мобильный программист может быть подкован в алгоритмах, а может и не быть — это также не его основная задача.
Теперь давайте подумаем с точки зрения бизнеса. И работодатель, и программист должны понимать, зачем и для чего вообще пишут программу. А программу пишут для того, чтобы удовлетворить потребности клиента. Клиенту всё равно — умею ли я решать анаграммы и могу ли я подсчитать сколько шариков влезет в школьный автобус. Ему также плевать на то, знаю ли я почему крышки люков делают круглыми. Всё, чего хочет клиент — это продукт. Всё, что должен делать я — дать ему этот продукт. Нет клиента — нет бизнеса — нет смысла в программе, которую я пишу. Работодатель должен проверять умею ли я пользоваться инструментами, которые позволяют создать эту программу. Всё остальное — порнография.
Прежде чем я продолжу комментарий, хочу отметить, что сейчас у меня 5 стартап по счёту, в котором я отвечаю полностью за всю техническую часть (CTO). Я не считаю себя экспертом, обучение — вещь бесконечная, но определённый опыт у меня есть.
Начну со стрессоустойчивости и стартапов. Я считаю, что если в стартапах стрессовая обстановка, то это явная недоработка со стороны руководства. Посмотрите Joel Test, в 8 пункте явно написано «Do programmers have quiet working conditions?». Стартап может менять направление, приоритет задач может меняться, но обстановка вокруг программистов должна быть нормальной. Разумеется, при смене направления развития продукта или критических багах в субботу вечером у программистов может возникнуть дискомфорт, но почти все программисты, с которыми я работал, достаточно спокойно относятся к таким явлениям. А вот шумная обстановка для программиста — верная гибель, не позволяет сосредоточиться и ведёт к быстрому выгоранию. Крупные компании вроде Google зарабатывают огромные деньги и они могут позволить себе текучку кадров из-за «выгоревших» работников, а вот стартапам и небольшим компаниям нужно лучше организовывать труд работников для того, чтобы сохранить костяк команды и нормально дойти хотя бы до релиза, а ещё лучше — до точки безубыточности.
В нашем стартапе мы уважительно относимся друг к другу, постоянно работаем над взаимопониманием между всеми участниками. Именно поэтому мы с удовольствием работаем сверх нормы и без проблем фиксим баги в час ночи. Если в стартапе изначально токсичная атмосфера, то стоит ли туда идти? Душевный покой не купишь)
Теперь по поводу адекватности подхода. Программирование это как искусство, так и ремесло. Так вот, с точки зрения ремесла, нужны инструменты для решения тех или иных задач. Если мы лишим инструментов электрика, то чем ему замерять напряжение в сети? Пальцами? К тому же, достаточно глупо просить электрика заменить сантехнику, равно как и просить мобильного разработчика решить алгоритмическую задачу. В мобильной разработке алгоритмические задачи встречаются крайне редко, основные задачи это красивый интерфейс и приём-передача данных на сервер. Электрик может разбираться в сантехнике, а может и не разбираться — это не его основная задача. Мобильный программист может быть подкован в алгоритмах, а может и не быть — это также не его основная задача.
Теперь давайте подумаем с точки зрения бизнеса. И работодатель, и программист должны понимать, зачем и для чего вообще пишут программу. А программу пишут для того, чтобы удовлетворить потребности клиента. Клиенту всё равно — умею ли я решать анаграммы и могу ли я подсчитать сколько шариков влезет в школьный автобус. Ему также плевать на то, знаю ли я почему крышки люков делают круглыми. Всё, чего хочет клиент — это продукт. Всё, что должен делать я — дать ему этот продукт. Нет клиента — нет бизнеса — нет смысла в программе, которую я пишу. Работодатель должен проверять умею ли я пользоваться инструментами, которые позволяют создать эту программу. Всё остальное — порнография.
Ни в коем случае не высказывался за проведение собеседований подобными методами, и сам никогда такие не проводил. Но лишь описал, то почему такие собеседования существуют.
Тем не менее, это давольно часто встречается, более того многие руководители понимают, что это недоработка и что недоработка эта явная и тем не менее не всегда есть средства, силы, умения это исправить. А найм сотрудников должен проходить по плану и в соответствии количеству работы, при этом имеет смысл нанимать сотрудников, которые смогут «выжить» в такой среде. Ни в коем случае не утверждал в моем комментарии, что иметь стрессовую ситуацию на рабочем месте — это круто и правильно.
Во многих стартапах это компенсирую деньгами.
Сам мобильный разработчик, сам никогда для проектов не писал поиск в ширину в графе, но тем не менее, в компаниях типа Facebook(упоминаю, опять таки потому что проходил интервью) это объясняют тем, что им нужно понять какого типа человек, как он думает, как умеет решать проблемы и адаптировать задачи. Если человек грубо говоря «умный», то сможет легко освоить любую технологию, и как они же утверждают у них достаточно времени и средств для того чтобы переучить вас под любую специальность, им не завтра теплой делать.
Почему так делают в стартапах, насколько я сталкивался, меня просто собеседовании спецы из другой области, в один из стартапов на должность iOS дева, собеседовал джавист, а общего у нас только Компьютерные науки, где алгоритмия берет большую часть.
Далеко не весь бизнес так работает. В основном так работает малый и средний. Большой бизнес и отдельно стартапы иногда работают по другому.
Завтра поменяться инструменты — вы сможете адаптироваться? Хватит ли вам сноровки и ловкости, или вы просто один из строжил на асемблере. Я бы не был так однозначен насчет инструментария.
Начну со стрессоустойчивости и стартапов. Я считаю, что если в стартапах стрессовая обстановка, то это явная недоработка со стороны руководства.
Тем не менее, это давольно часто встречается, более того многие руководители понимают, что это недоработка и что недоработка эта явная и тем не менее не всегда есть средства, силы, умения это исправить. А найм сотрудников должен проходить по плану и в соответствии количеству работы, при этом имеет смысл нанимать сотрудников, которые смогут «выжить» в такой среде. Ни в коем случае не утверждал в моем комментарии, что иметь стрессовую ситуацию на рабочем месте — это круто и правильно.
Крупные компании вроде Google зарабатывают огромные деньги и они могут позволить себе текучку кадров из-за «выгоревших» работников, а вот стартапам и небольшим компаниям нужно лучше организовывать труд работников для того, чтобы сохранить костяк команды
Во многих стартапах это компенсирую деньгами.
К тому же, достаточно глупо просить электрика заменить сантехнику, равно как и просить мобильного разработчика решить алгоритмическую задачу. В мобильной разработке алгоритмические задачи встречаются крайне редко, основные задачи это красивый интерфейс и приём-передача данных на сервер.
Сам мобильный разработчик, сам никогда для проектов не писал поиск в ширину в графе, но тем не менее, в компаниях типа Facebook(упоминаю, опять таки потому что проходил интервью) это объясняют тем, что им нужно понять какого типа человек, как он думает, как умеет решать проблемы и адаптировать задачи. Если человек грубо говоря «умный», то сможет легко освоить любую технологию, и как они же утверждают у них достаточно времени и средств для того чтобы переучить вас под любую специальность, им не завтра теплой делать.
Почему так делают в стартапах, насколько я сталкивался, меня просто собеседовании спецы из другой области, в один из стартапов на должность iOS дева, собеседовал джавист, а общего у нас только Компьютерные науки, где алгоритмия берет большую часть.
Нет клиента — нет бизнеса — нет смысла в программе, которую я пишу.
Далеко не весь бизнес так работает. В основном так работает малый и средний. Большой бизнес и отдельно стартапы иногда работают по другому.
Работодатель должен проверять умею ли я пользоваться инструментами, которые позволяют создать эту программу. Всё остальное — порнография.
Завтра поменяться инструменты — вы сможете адаптироваться? Хватит ли вам сноровки и ловкости, или вы просто один из строжил на асемблере. Я бы не был так однозначен насчет инструментария.
В каких-то местах я вас не так понял. Я рад что мы оба считаем, что стрессовая обстановка на работе это плохо. Также мне нравится то, что вы сами понимаете, что такие собеседования — далеко не самый грамотный подход к поиску будущих коллег.
Каждый волен распоряжаться своим временем и здоровьем так, как он считает нужным. Лично я никому не рекомендую идти в токсичную среду — заработаете денег и большую часть спустите на восстановление здоровья. Если вычесть все компенсационные расходы, то получится не так уж и много — эти же деньги можно заработать менее «травмоопасным» способом. Тут уже каждый решает сам, стоит ли игра свеч.
Ну тут опять же, смотря какой контекст. Я проходил собеседование в стартап и имею в виду работу в стартапах. Если взять крупные компании, то там другой уровень и другие условия найма — там нужны винтики в системе, которые могут чётко и быстро выполнять задачи без лишних вопросов. В стартапах и небольших компаниях акцент всё-таки идёт на личность человека и на его мотивацию довести проект до конца, текучка там крайне нежелательна — время и средства ограничены, а текучка запросто приведёт к появлению спагетти-кода. Если бы я проходил собеседование в большую компанию, я бы прогнал все свои знания по алгоритмам, структурам данных, ООП, паттернам и т.д., т.к. я понимаю специфику и понимаю чего от меня будут ожидать на этом собеседовании.
Давайте не будем утрировать) Инструменты не поменяются в одночасье, но тем не менее, идёт определённая эволюция, за которой я слежу очень пристально. Я регулярно читаю новости из мира разработки, регулярно зависаю на Github, постоянно нахожу какие-то новые инструменты и библиотеки и пробую их. Если мне инструмент нравится — я внедряю его в текущий проект, зачастую переписывая много кода. Я считаю это нормальным подходом для любого программиста — профессионал должен держать руку на пульсе отрасли, в которой он работает, для того, чтобы быть востребованным на рынке труда.
Во многих стартапах это компенсирую деньгами.
Каждый волен распоряжаться своим временем и здоровьем так, как он считает нужным. Лично я никому не рекомендую идти в токсичную среду — заработаете денег и большую часть спустите на восстановление здоровья. Если вычесть все компенсационные расходы, то получится не так уж и много — эти же деньги можно заработать менее «травмоопасным» способом. Тут уже каждый решает сам, стоит ли игра свеч.
Далеко не весь бизнес так работает. В основном так работает малый и средний. Большой бизнес и отдельно стартапы иногда работают по другому.
Ну тут опять же, смотря какой контекст. Я проходил собеседование в стартап и имею в виду работу в стартапах. Если взять крупные компании, то там другой уровень и другие условия найма — там нужны винтики в системе, которые могут чётко и быстро выполнять задачи без лишних вопросов. В стартапах и небольших компаниях акцент всё-таки идёт на личность человека и на его мотивацию довести проект до конца, текучка там крайне нежелательна — время и средства ограничены, а текучка запросто приведёт к появлению спагетти-кода. Если бы я проходил собеседование в большую компанию, я бы прогнал все свои знания по алгоритмам, структурам данных, ООП, паттернам и т.д., т.к. я понимаю специфику и понимаю чего от меня будут ожидать на этом собеседовании.
Завтра поменяться инструменты — вы сможете адаптироваться? Хватит ли вам сноровки и ловкости, или вы просто один из строжил на асемблере. Я бы не был так однозначен насчет инструментария.
Давайте не будем утрировать) Инструменты не поменяются в одночасье, но тем не менее, идёт определённая эволюция, за которой я слежу очень пристально. Я регулярно читаю новости из мира разработки, регулярно зависаю на Github, постоянно нахожу какие-то новые инструменты и библиотеки и пробую их. Если мне инструмент нравится — я внедряю его в текущий проект, зачастую переписывая много кода. Я считаю это нормальным подходом для любого программиста — профессионал должен держать руку на пульсе отрасли, в которой он работает, для того, чтобы быть востребованным на рынке труда.
по моему айфон в кафе это такой хитрый отказ по-калифорнийски )
С точки зрения pre-junior было бы интересно почитать ответы на предложенные вопросы :)
В частности, очень интересно про вопрос 11 – что там конкретно не так? %)
Тоесть чтобы попасть к вам на джуниора нужно сидеть дома с 2-3 версиями айосов под рукой, писать телеграмм, быть опытным в UI и дебажить кроссверсионные баги? Если вам нужны такие джуниоры, то организуйте стажировку или курсы. Я вот не понимаю зачем джуниору, который может внятно ответить на "только на iOS 10, но не на iOS 9", плюс всё остальное, вообще идти на джуниора лично к вам? Дайте угадаю. У вас штат программистов на 3/4 стоятит из студентов-выпускников приближенных кафедр?
Я написал, что не обязательно знать ответ на этот вопрос. Достаточно уметь правильно его найти. Это даже важнее, чем с ходу выпалить.
В данной статье оперируете понятиями junior, middle, senior — без конкретного определения.
В каждой компании требования разные. Даже в среднем по России требования могут отличаться.
Например, есть такое определение: "...Junior: студент старших курсов и без опыта работы. Если с человеком нужно сидеть и постоянно помогать. Можно доверить баги, но никак не рефаторинг или таски на 1-2 недели, то это 100% джуниор. Опыт фултаим: 0.5-1 год. Либо партайм: 1-2 года. Предметную область знает слабо..."
Каким образом указанный в этом определении джуниор сможет решить задачу №3 самостоятельно и без подсказки, если предметную область он знает плохо? Он даже нагуглить это не сможет, т.к. не поймет, что ему нужно гуглить.
Напишите Ваши требования к junior, middle, senior (или требования в среднем по рынку). Возможно, это тема для отдельной статьи.
В каждой компании требования разные. Даже в среднем по России требования могут отличаться.
Например, есть такое определение: "...Junior: студент старших курсов и без опыта работы. Если с человеком нужно сидеть и постоянно помогать. Можно доверить баги, но никак не рефаторинг или таски на 1-2 недели, то это 100% джуниор. Опыт фултаим: 0.5-1 год. Либо партайм: 1-2 года. Предметную область знает слабо..."
Каким образом указанный в этом определении джуниор сможет решить задачу №3 самостоятельно и без подсказки, если предметную область он знает плохо? Он даже нагуглить это не сможет, т.к. не поймет, что ему нужно гуглить.
Напишите Ваши требования к junior, middle, senior (или требования в среднем по рынку). Возможно, это тема для отдельной статьи.
Очень жду в комментах продолжения из подобных вопросов. Если бы еще в спойлеры добавить ответы, то полезность статьи зашкаливала бы.
Окей, добавлю пояснения частично. На все подряд нет смысла, иначе можно копипастить документацию Apple просто.
Подъехало обновление.
А я так ждал ответ на вопрос номер 6. =(
Есть несколько вариантов:
- Использовать RBQFetchedResultsController, но будет медленно. Подойдет для несложных экранов.
- Сделать отдельный relationship для секций. Например, если нужно разделять таблицу по дням, то сущность будет 'день'.
- Оставить единый список, а секции сделать искусственно внутри ячеек. Которые будут показываться по условию.
С точки зрения статьи на хабре, которая должна иметь ценность для читателя, было бы гораздо полезнее дать пояснения по senior уровню, а джуниора можно было бы и пропустить. Как, например, номер 4. Не всем и не всегда нужно, но вопрос крайне занятный. Инстинктивно я понимаю, что нужно будет подниматься на мета-уровень и описывать все компоненты там. Но вот на счет конкретной реализации было бы очень интересно пару новодок получить.
Но, в любом случае, материал интересный и заставляет задуматься. Спасибо.
Но, в любом случае, материал интересный и заставляет задуматься. Спасибо.
Всегда чувствовал, что где то в программировании для Мак систем подвох. Но что ТАК много камней — да же представить себе не мог :-)
Иметь бы мне это знание года 4 назад, когда я начинала проводить собеседования в качестве тех.специалиста) Надменность, неумение просто поддержать беседу, задать действительно важные вопросы. Чувствовала, что что-то не так. Потом у себя спросила — что, если бы я была на месте этого кандидата. После этого я перестала задавать вопросы типа «чем хотите заниматься через 5 лет» — это глупо, даже если мы ищем человека на 5-летний контракт, или типа «как вы понимаете ООП» — можно 1 раз прочитать определение в двух разных источниках и правильно ответить — лучше попросить показать пример реализации или дать небольшое тестовое задание, если правильное понимание ООП для нас важно.
Ещё сделала для себя вывод — к сожалению, собеседование не очень показательно — часто бывает так, что кандидат себя отлично проявил на собеседовании и даже справился с заданиями, но на стажировке показал себя плохо, или наоборот — после собеседования очень сомневалась брать ли на стажировку, а потом была счастлива, что взяла. Но чем больше собеседований провожу, тем меньше ошибаюсь)
Сейчас для меня собеседование — это 2 одинаково ценных вопроса: 1. какой уровень навыков, 2. какой человек, его взгляды и реакции. Сейчас я уже не готовлю вопросы, просто стараюсь расслабиться и поговорить с кандидатом, к минимуму свести официоз, больше смотрю в глаза, говорю спокойнее. Некоторым сразу предлагаю перейти на «ты», если это уместно. Больше вопросов про практику — прошу рассказать про реализованные проекты/задачи, какие вопросы вставали, как решили, что именно сделали. Прошу рассказать, как человек решают какую-то конкретную типовую задачу (например, проектирует БД под новый проект и строит его архитектуру) — помогает понять, как он думает и умеет ли объяснять свои идеи, умеет ли составлять простой план своих действий. Ещё важно понять, умеет ли человек следовать простым инструкциям — для этого подойдёт даже короткое задание с множеством простых условий.
Ещё сделала для себя вывод — к сожалению, собеседование не очень показательно — часто бывает так, что кандидат себя отлично проявил на собеседовании и даже справился с заданиями, но на стажировке показал себя плохо, или наоборот — после собеседования очень сомневалась брать ли на стажировку, а потом была счастлива, что взяла. Но чем больше собеседований провожу, тем меньше ошибаюсь)
Сейчас для меня собеседование — это 2 одинаково ценных вопроса: 1. какой уровень навыков, 2. какой человек, его взгляды и реакции. Сейчас я уже не готовлю вопросы, просто стараюсь расслабиться и поговорить с кандидатом, к минимуму свести официоз, больше смотрю в глаза, говорю спокойнее. Некоторым сразу предлагаю перейти на «ты», если это уместно. Больше вопросов про практику — прошу рассказать про реализованные проекты/задачи, какие вопросы вставали, как решили, что именно сделали. Прошу рассказать, как человек решают какую-то конкретную типовую задачу (например, проектирует БД под новый проект и строит его архитектуру) — помогает понять, как он думает и умеет ли объяснять свои идеи, умеет ли составлять простой план своих действий. Ещё важно понять, умеет ли человек следовать простым инструкциям — для этого подойдёт даже короткое задание с множеством простых условий.
Никогда не «задавал вопросы» на собеседованиях :)
Всегда старался помочь кандидату раскрыть свои знания, оценить ход его мысли, широту и гибкость взлядов и оценивал как могу их использовать в проекте. Как «дорого» будет «доточить» кандидата под проект.
А знания «API по памяти»- в большистве своем бессмысленны. На это мануалы есть и отладчик :)
Всегда старался помочь кандидату раскрыть свои знания, оценить ход его мысли, широту и гибкость взлядов и оценивал как могу их использовать в проекте. Как «дорого» будет «доточить» кандидата под проект.
А знания «API по памяти»- в большистве своем бессмысленны. На это мануалы есть и отладчик :)
У меня добрый случай был на собеседовании лет 7 назад: Очередной вопрос от интервьюера по java: 'Чем отличаются checked exceptions от unchecked?
Я ему честно — 'Узнал про термины checked/unchecked сегодня, но ответ знаю… бла бла бла'. Он мне в ответ: — ' Я тоже этим утром, когда узнал что пойду собеседовать вместо начальника'
Мы вместе посмеялись.
Когда провожу собеседование всегда обращаю на потенциал человека, сделал для себя вывод, что это ключевое при принятии решения.
На втором месте — навыки программирования, которые говорят о возможной должности кандидата в компании.
Я ему честно — 'Узнал про термины checked/unchecked сегодня, но ответ знаю… бла бла бла'. Он мне в ответ: — ' Я тоже этим утром, когда узнал что пойду собеседовать вместо начальника'
Мы вместе посмеялись.
Когда провожу собеседование всегда обращаю на потенциал человека, сделал для себя вывод, что это ключевое при принятии решения.
На втором месте — навыки программирования, которые говорят о возможной должности кандидата в компании.
Чёт какие-то вопросы странные. Кучу мелких юзкейсов. Любое собеседование — зеркало боли и отчаяния интервьюера, с которым он столкнулся на практике. Полагаю, в данном случае автор втыкался во все эти вещи и вынес их на интервью. Я б добавил сюда ещё глобальных вопросов про архитектуру и организацию проекта, чтобы понять, насколько собеседуемый способен превратить проект в несопровождаемый ужас и кошмар. Очень многие сеньёры на рынке на это способны, увы и ах. Как и джуны.
Было бы весьма интересно ознакомиться с Вашим видением реализации пункта 4
Про опциональный метод у протокола… Действительно ли нужно переходить в объектам Objective-C ради этого? Может достаточно было бы разделить интерфейсы, а все методы оставить обязательными. Тогда и вызов не должен быть опциональным, а достаточно только разыменовать delegate.
Про пуши, может быть ещё ошибка на сервере, например. Все помнят какой размер могут иметь пши в той или иной версии iOS?
Про пуши, может быть ещё ошибка на сервере, например. Все помнят какой размер могут иметь пши в той или иной версии iOS?
Отличная статья, спасибо!
Много полезной информации и вопросов, которые заставляет увидеть свои пробелы в знаниях и подходах к решению задач!
Было бы очень классно, если бы ты выложил список того, о чем стоит знать начинающему разработчику (например, полезных протоколов/классов вроде UIAppearance, что бы использовать их вместо всяких хаков и костылей, т.е. привыкать к правильному подходу изначально). Я имею ввиду знать не наизусть, а просто о том, что такая вещь существует и для чего она нужна, что бы в случае появления соответствующей задачи знать, что её стоит использовать.
Sign up to leave a comment.
Какие вопросы задавать на собеседовании