Комментарии 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 проектах. Мне важна реальная работа — что кандидат уже делал и о чём он может рассказать.
Странно, что задача с анаграммами вызвала такие затруднения… Используемые-то трюки общие для очень большого класса задач!
Первый трюк: нормализация. Если построить функцию, которая будет выбирать один и тот же элемент для целого класса эквивалентности — то проверка двух элементов на эквивалентность сведется к применению этой функции и проверке на строгое равенство.
Может, это и звучит страшно, то используется-то этот прием постоянно! Когда хотят сравнить две строки без учета регистра — обе строки приводят к нижнему регистру (вы точно за всю карьеру программиста ни разу этого не делали?). Когда хотят сравнить две строки без учета различий в записи одних и тех же символов при помощи кодовых позиций юникода — их обе приводят к нормальной форме. Когда подписывают XML-файл, из него выкидывают незначимые пробелы...
Да, а когда сравнивают две строки на предмет анаграммы — их обе сортируют.
Второй трюк — для нахождения одинаковых элементов в массиве надо массив отсортировать.
В мобильной разработке основной спектр задач состоит в построении интерфейсов и обеспечении клиент-серверной архитектуры. Алгоритмические задачи бывают не так часто, плюс у меня было немного офигевшее состояние от просьбы написать работающую программу в шумном кафе в текстовом редакторе айфона)
В общем, всё знать невозможно. Я пришёл домой и разобрался в вопросе, закрыл свой пробел. Ну и Вам спасибо за описанные трюки)
Возможно, Вам не хватило уверенности для того, чтобы аргументированно отказаться от выполнения безумного предложения? Я бы ответил предложением написать код на бумажке в псевдокоде, предварительно описав устно общую идею алгоритма (кому-то хватило бы и этой части ответа). Некоторые работодатели заинтересованы в наличии у соискателя критического мышления в отношении заданий, а с другими я работать не сьал бы.
P.s. писал с телефона, на ходу. Лёд, холод. Ничего страшного. Но код… "Извините, нет"
А вот аргументированно отказаться от этого безумного предложения — стоило бы. Честно признаться — был шокирован, поэтому как-то не сразу смог сообразить что не нужно такой ерундой страдать, а надо сразу отказываться от дальнейшего продолжения интервью.
Но что есть — то есть, и опыт получил, и вам грабли показал)
Алгоритмию дают для того чтобы понять ваш стиль мышления, скорость понимания вопроса, возможность задавать нужные вопросы, и думать не имея полного описания проблемы.
Много раз я слышал, особенно в СНГ сообществе, о том, что такой подход не адекватен — да он не адекватен для определенных условий, например стабильных продуктовых или аутсорс компаний, а для стартапов, стрессоустойчивость при неизменной производительности — ключ к успеху в некоторых аспектах.
И суть тут далеко не в том, что решение этой проблемы гуглится за 5 или менее минут или не в том, что вы никогда не будите это применять на практике. Проходя в свое время собеседование в Facebook, они дают множество материалов на эту тему, на тему собеседований и ожиданий от кандидата(Facebook хочет чтоб у вас получилось поэтому они вам помогают), могу порекомендовать книгу http://www.crackingthecodinginterview.com
Многим людям присущи ошибочные суждения, когда нет полной информации об условиях. С вашей стороны собеседование могло быть абсолютно неадекватным, а со стороны основателя это мог быть давным давно пройденный этап, десятки уволенных сотрудников неспособных держать нужный темп, он даже мог сам понимать, что вы думаете, что это интервью неадекватное, но тем не менее он делал свою работу.
Прежде чем я продолжу комментарий, хочу отметить, что сейчас у меня 5 стартап по счёту, в котором я отвечаю полностью за всю техническую часть (CTO). Я не считаю себя экспертом, обучение — вещь бесконечная, но определённый опыт у меня есть.
Начну со стрессоустойчивости и стартапов. Я считаю, что если в стартапах стрессовая обстановка, то это явная недоработка со стороны руководства. Посмотрите Joel Test, в 8 пункте явно написано «Do programmers have quiet working conditions?». Стартап может менять направление, приоритет задач может меняться, но обстановка вокруг программистов должна быть нормальной. Разумеется, при смене направления развития продукта или критических багах в субботу вечером у программистов может возникнуть дискомфорт, но почти все программисты, с которыми я работал, достаточно спокойно относятся к таким явлениям. А вот шумная обстановка для программиста — верная гибель, не позволяет сосредоточиться и ведёт к быстрому выгоранию. Крупные компании вроде Google зарабатывают огромные деньги и они могут позволить себе текучку кадров из-за «выгоревших» работников, а вот стартапам и небольшим компаниям нужно лучше организовывать труд работников для того, чтобы сохранить костяк команды и нормально дойти хотя бы до релиза, а ещё лучше — до точки безубыточности.
В нашем стартапе мы уважительно относимся друг к другу, постоянно работаем над взаимопониманием между всеми участниками. Именно поэтому мы с удовольствием работаем сверх нормы и без проблем фиксим баги в час ночи. Если в стартапе изначально токсичная атмосфера, то стоит ли туда идти? Душевный покой не купишь)
Теперь по поводу адекватности подхода. Программирование это как искусство, так и ремесло. Так вот, с точки зрения ремесла, нужны инструменты для решения тех или иных задач. Если мы лишим инструментов электрика, то чем ему замерять напряжение в сети? Пальцами? К тому же, достаточно глупо просить электрика заменить сантехнику, равно как и просить мобильного разработчика решить алгоритмическую задачу. В мобильной разработке алгоритмические задачи встречаются крайне редко, основные задачи это красивый интерфейс и приём-передача данных на сервер. Электрик может разбираться в сантехнике, а может и не разбираться — это не его основная задача. Мобильный программист может быть подкован в алгоритмах, а может и не быть — это также не его основная задача.
Теперь давайте подумаем с точки зрения бизнеса. И работодатель, и программист должны понимать, зачем и для чего вообще пишут программу. А программу пишут для того, чтобы удовлетворить потребности клиента. Клиенту всё равно — умею ли я решать анаграммы и могу ли я подсчитать сколько шариков влезет в школьный автобус. Ему также плевать на то, знаю ли я почему крышки люков делают круглыми. Всё, чего хочет клиент — это продукт. Всё, что должен делать я — дать ему этот продукт. Нет клиента — нет бизнеса — нет смысла в программе, которую я пишу. Работодатель должен проверять умею ли я пользоваться инструментами, которые позволяют создать эту программу. Всё остальное — порнография.
Начну со стрессоустойчивости и стартапов. Я считаю, что если в стартапах стрессовая обстановка, то это явная недоработка со стороны руководства.
Тем не менее, это давольно часто встречается, более того многие руководители понимают, что это недоработка и что недоработка эта явная и тем не менее не всегда есть средства, силы, умения это исправить. А найм сотрудников должен проходить по плану и в соответствии количеству работы, при этом имеет смысл нанимать сотрудников, которые смогут «выжить» в такой среде. Ни в коем случае не утверждал в моем комментарии, что иметь стрессовую ситуацию на рабочем месте — это круто и правильно.
Крупные компании вроде Google зарабатывают огромные деньги и они могут позволить себе текучку кадров из-за «выгоревших» работников, а вот стартапам и небольшим компаниям нужно лучше организовывать труд работников для того, чтобы сохранить костяк команды
Во многих стартапах это компенсирую деньгами.
К тому же, достаточно глупо просить электрика заменить сантехнику, равно как и просить мобильного разработчика решить алгоритмическую задачу. В мобильной разработке алгоритмические задачи встречаются крайне редко, основные задачи это красивый интерфейс и приём-передача данных на сервер.
Сам мобильный разработчик, сам никогда для проектов не писал поиск в ширину в графе, но тем не менее, в компаниях типа Facebook(упоминаю, опять таки потому что проходил интервью) это объясняют тем, что им нужно понять какого типа человек, как он думает, как умеет решать проблемы и адаптировать задачи. Если человек грубо говоря «умный», то сможет легко освоить любую технологию, и как они же утверждают у них достаточно времени и средств для того чтобы переучить вас под любую специальность, им не завтра теплой делать.
Почему так делают в стартапах, насколько я сталкивался, меня просто собеседовании спецы из другой области, в один из стартапов на должность iOS дева, собеседовал джавист, а общего у нас только Компьютерные науки, где алгоритмия берет большую часть.
Нет клиента — нет бизнеса — нет смысла в программе, которую я пишу.
Далеко не весь бизнес так работает. В основном так работает малый и средний. Большой бизнес и отдельно стартапы иногда работают по другому.
Работодатель должен проверять умею ли я пользоваться инструментами, которые позволяют создать эту программу. Всё остальное — порнография.
Завтра поменяться инструменты — вы сможете адаптироваться? Хватит ли вам сноровки и ловкости, или вы просто один из строжил на асемблере. Я бы не был так однозначен насчет инструментария.
Во многих стартапах это компенсирую деньгами.
Каждый волен распоряжаться своим временем и здоровьем так, как он считает нужным. Лично я никому не рекомендую идти в токсичную среду — заработаете денег и большую часть спустите на восстановление здоровья. Если вычесть все компенсационные расходы, то получится не так уж и много — эти же деньги можно заработать менее «травмоопасным» способом. Тут уже каждый решает сам, стоит ли игра свеч.
Далеко не весь бизнес так работает. В основном так работает малый и средний. Большой бизнес и отдельно стартапы иногда работают по другому.
Ну тут опять же, смотря какой контекст. Я проходил собеседование в стартап и имею в виду работу в стартапах. Если взять крупные компании, то там другой уровень и другие условия найма — там нужны винтики в системе, которые могут чётко и быстро выполнять задачи без лишних вопросов. В стартапах и небольших компаниях акцент всё-таки идёт на личность человека и на его мотивацию довести проект до конца, текучка там крайне нежелательна — время и средства ограничены, а текучка запросто приведёт к появлению спагетти-кода. Если бы я проходил собеседование в большую компанию, я бы прогнал все свои знания по алгоритмам, структурам данных, ООП, паттернам и т.д., т.к. я понимаю специфику и понимаю чего от меня будут ожидать на этом собеседовании.
Завтра поменяться инструменты — вы сможете адаптироваться? Хватит ли вам сноровки и ловкости, или вы просто один из строжил на асемблере. Я бы не был так однозначен насчет инструментария.
Давайте не будем утрировать) Инструменты не поменяются в одночасье, но тем не менее, идёт определённая эволюция, за которой я слежу очень пристально. Я регулярно читаю новости из мира разработки, регулярно зависаю на Github, постоянно нахожу какие-то новые инструменты и библиотеки и пробую их. Если мне инструмент нравится — я внедряю его в текущий проект, зачастую переписывая много кода. Я считаю это нормальным подходом для любого программиста — профессионал должен держать руку на пульсе отрасли, в которой он работает, для того, чтобы быть востребованным на рынке труда.
С точки зрения pre-junior было бы интересно почитать ответы на предложенные вопросы :)
В частности, очень интересно про вопрос 11 – что там конкретно не так? %)
Тоесть чтобы попасть к вам на джуниора нужно сидеть дома с 2-3 версиями айосов под рукой, писать телеграмм, быть опытным в UI и дебажить кроссверсионные баги? Если вам нужны такие джуниоры, то организуйте стажировку или курсы. Я вот не понимаю зачем джуниору, который может внятно ответить на "только на iOS 10, но не на iOS 9", плюс всё остальное, вообще идти на джуниора лично к вам? Дайте угадаю. У вас штат программистов на 3/4 стоятит из студентов-выпускников приближенных кафедр?
В каждой компании требования разные. Даже в среднем по России требования могут отличаться.
Например, есть такое определение: "...Junior: студент старших курсов и без опыта работы. Если с человеком нужно сидеть и постоянно помогать. Можно доверить баги, но никак не рефаторинг или таски на 1-2 недели, то это 100% джуниор. Опыт фултаим: 0.5-1 год. Либо партайм: 1-2 года. Предметную область знает слабо..."
Каким образом указанный в этом определении джуниор сможет решить задачу №3 самостоятельно и без подсказки, если предметную область он знает плохо? Он даже нагуглить это не сможет, т.к. не поймет, что ему нужно гуглить.
Напишите Ваши требования к junior, middle, senior (или требования в среднем по рынку). Возможно, это тема для отдельной статьи.
- Использовать RBQFetchedResultsController, но будет медленно. Подойдет для несложных экранов.
- Сделать отдельный relationship для секций. Например, если нужно разделять таблицу по дням, то сущность будет 'день'.
- Оставить единый список, а секции сделать искусственно внутри ячеек. Которые будут показываться по условию.
Но, в любом случае, материал интересный и заставляет задуматься. Спасибо.
Ещё сделала для себя вывод — к сожалению, собеседование не очень показательно — часто бывает так, что кандидат себя отлично проявил на собеседовании и даже справился с заданиями, но на стажировке показал себя плохо, или наоборот — после собеседования очень сомневалась брать ли на стажировку, а потом была счастлива, что взяла. Но чем больше собеседований провожу, тем меньше ошибаюсь)
Сейчас для меня собеседование — это 2 одинаково ценных вопроса: 1. какой уровень навыков, 2. какой человек, его взгляды и реакции. Сейчас я уже не готовлю вопросы, просто стараюсь расслабиться и поговорить с кандидатом, к минимуму свести официоз, больше смотрю в глаза, говорю спокойнее. Некоторым сразу предлагаю перейти на «ты», если это уместно. Больше вопросов про практику — прошу рассказать про реализованные проекты/задачи, какие вопросы вставали, как решили, что именно сделали. Прошу рассказать, как человек решают какую-то конкретную типовую задачу (например, проектирует БД под новый проект и строит его архитектуру) — помогает понять, как он думает и умеет ли объяснять свои идеи, умеет ли составлять простой план своих действий. Ещё важно понять, умеет ли человек следовать простым инструкциям — для этого подойдёт даже короткое задание с множеством простых условий.
Всегда старался помочь кандидату раскрыть свои знания, оценить ход его мысли, широту и гибкость взлядов и оценивал как могу их использовать в проекте. Как «дорого» будет «доточить» кандидата под проект.
А знания «API по памяти»- в большистве своем бессмысленны. На это мануалы есть и отладчик :)
Я ему честно — 'Узнал про термины checked/unchecked сегодня, но ответ знаю… бла бла бла'. Он мне в ответ: — ' Я тоже этим утром, когда узнал что пойду собеседовать вместо начальника'
Мы вместе посмеялись.
Когда провожу собеседование всегда обращаю на потенциал человека, сделал для себя вывод, что это ключевое при принятии решения.
На втором месте — навыки программирования, которые говорят о возможной должности кандидата в компании.
Про пуши, может быть ещё ошибка на сервере, например. Все помнят какой размер могут иметь пши в той или иной версии iOS?
Отличная статья, спасибо!
Много полезной информации и вопросов, которые заставляет увидеть свои пробелы в знаниях и подходах к решению задач!
Было бы очень классно, если бы ты выложил список того, о чем стоит знать начинающему разработчику (например, полезных протоколов/классов вроде UIAppearance, что бы использовать их вместо всяких хаков и костылей, т.е. привыкать к правильному подходу изначально). Я имею ввиду знать не наизусть, а просто о том, что такая вещь существует и для чего она нужна, что бы в случае появления соответствующей задачи знать, что её стоит использовать.
Какие вопросы задавать на собеседовании