Посетив множество компаний, я решил поделиться наблюдениями о том, как чаще всего проходит набор специалистов, в том числе техническое собеседование и просто общение с потенциальными коллегами. И после предложить свои идеи по улучшению общепринятого процесса.
Чтобы в итоге собеседование не выглядело для соискателя как:
Статья в первую очередь будет полезна всем, кто ищет работу в среде iOS разработки или хоть как-то связан с набором IT специалистов: проводит технические собеседования или любые другие.
И добро пожаловать под кат.
Вступление
Хочу отметить, что считаю себя человеком результата. Любые действия, в том числе самообразование, должны быть направлены на достижение конкретной цели или решение определенной задачи. Когда доводилось проводить собеседование в своей компании, то всегда старался спросить нечто полезное на практике, понять как соискатель поведет себя в 'боевых действиях', что предпримет для реализации того или иного модуля, или как будет бороться с определенным багом.
Так вот, я был поражен тем, что из более чем десятка посещенных мною довольно крупных организаций, с офисами в центре, объемными секретаршами, плойки и прочими атрибутами пафосного офиса, абсолютно все спрашивают только начитку.
Нерафинированная 100% теория без какой-либо связи с практикой. Никто не поинтересовался как я размышляю, подхожу к задачам, как стал бы ловить нестандартные вылеты, искать причины плохой производительности в приложении и решать прочие будничные проблемы с которыми разработчик сталкивается каждый день. Всех интересовало только отличие ARC от MRC и разнообразная ни разу в жизни не понадобившаяся муть. Например: чем строение файла xib отличается от строения файла storyboard. Именно файла. Такая полезная вещь. Каждый день ковыряюсь в xml.
Это не значит, что меня везде послали и я пришел ныть на Хабр. В большинстве случаев все проходило позитивно, разве что за небольшим исключением. А если где-то и сталкивался с откровенным пробелом в знаниях, то к следующему собеседованию он уже был успешно освоен. И порой даже простой разговор с будущим руководством компенсировал не слишком удачно(на мой взгляд) пройденное техническое собеседование.
Эта статья могла бы стать обычным нытьем о несовершенстве мира, но я решил вынести максимум пользы и составить список вопросов, по которым можно реально оценить реальную полезность кандидата, а не просто уровень его теоретических познаний. Так как по любой интересующей теме можно сформулировать практическую задачу.
Вопросы
Приведу пример вопросов, которые, на мой взгляд, лучше раскрывают букет навыков девелопера, чем просто в лоб: 'Как работает memory management в iOS?'. Важно не только с ходу решить задачу, но еще и уметь найти/придумать это решение, если не знаешь как делать.
- Как бы вы стали верстать такой экран? Какие узкие места тут есть и как бы вы их решали?
Входящая информация:
Есть объект Product, который состоит из некой общей информации, которая находится в шапке, и массива Parameters. Каждый параметр — это строковые поля name и value. Value — это самая обычная строка, где каждое значение отделено вертикальной чертой от другого. Например: «VM 505|BWM ZIGZAG 3|SOLID REKT 101». Каждое значение должно находиться на новой строке как в 'Спецификации OEM'.
Обратить внимание:
Разделяющая полоса между name и value доходит до первого слова. В случае, если полоска делается как обычная вью, а поле value как лейбл, то полоса будет заканчиваться у самого длинного слова, а не у первого.
Уровень: middle и выше.
РешениеВ первую очередь стоит услышать ход мыслей разработчика. Большинство людей залипают на этой задаче и упускают из виду множество деталей.
На мой взгляд, самый оптимальный вариант — это попросить дизайнера переделать.
Если решать задачу технически, то я бы провел линию от хвоста одного лейбла до хвоста другого. Чтобы линия именно заходила за лейбл с value. Потом добавляем атрибут с background color на лейбл. В итоге фоновый цвет закрасит вьюху под ним.
Еще вариант — это отсортировать слова по длине и наверх ставить самое длинное, а линию выровнять по началу value лейбла.
Попробуйте найти еще решения.
- Что произойдет после запуска приложения?
func application(_ application: UIApplication, didFinishLaunchingWithOptions...) -> Bool { DispatchQueue.global().async { Timer.scheduledTimer(timeInterval: 0.4, target: self, selector: #selector(self.tickTimer), userInfo: nil, repeats: true) } return true } func tickTimer() { print("Tick-Tack") }
Я обычно не сторонник задач в стиле: 'Какая проблема в коде на картинке?', но слишком уж часто всплывает непонимание принципов работы таймера и ранлупов, которые выливаются в крайне неприятные и трудноуловимые баги.
Вопрос можно переформулировать в задачу: 'Нужно сделать повторяемый таймер, который вызывается каждую минуту в бекграунде. Прицельная точность тиков не важна, достаточно некая периодичность. Как это сделать?'
Уровень: junior и выше.
РешениеНичего не произойдет. Ранлуп не взведен, как говорится. А еще будет небольшая утечка памяти, но это уже для гурманов.
Если надо сделать таймер в фоне, то стоит выбирать поток с бегущим ранлупом. Либо воспользоваться уже готовым решением для GCD.
- Поступила задача. Нужно написать приложение, цветовая гамма которого конфигурируется на сервере. То есть, приложение получает конфиг в котором содержится набор цветов, степень скругления иконок, и так далее. Как лучше сделать такое приложение? Что будем использовать? Какие будут ограничения у того или иного решения?
Уровень: junior/middle и выше.
Обратить внимание: не дай бог кандидат промолчит о UIAppearance. Просто сc***ми тряпками гнать такого, особенно, если это middle и далее. Здесь же можно спросить про базовые классы Obj-C в качестве небольшого отступления к теории.
Отмечу, что кандидату не обязательно в деталях повествовать о работе UIAppearance. Он мог ни разу не использовать его, но что это такое знать обязан.
РешениеСоздаем класс цветовой схемы и конфигурируем все элементы UI через UIAppearance. Для кастомных вьюх тоже реализуем этот протокол. Есть отличная статья на этот счет.
- Как сделать так, чтобы приложение могло себя обновлять без участия AppStore? Добавлять новые экраны и логику к ним, например. Какие есть ограничения у такого решения? Какое лучше подойдет в том или ином случае? Когда может быть реальная необходимость в этом механизме?
Уровень: senior.
РешениеЗадачи для senior идут без решения. Набивайте опыт, господа.
- Есть приложение с таблицей. В процессе скроллинга периодически наблюдаются легкие притормаживания. Тестировщики не выявили явной закономерности, но проблема регулярно встречается. То тут, то там происходит неприятный лаг. Как его поймать? На что обращать внимание?
Уровень: middle и выше.
РешениеПричиной торможения может быть:
- Перегруженный main thread.
- Инстанциирующиеся в процессе ячейки. Если у вас таблица состоит больше, чем из одного вида ячеек, то при отсутствии в очереди нужной, она сначала создастся, это требует ресурсов. Особенно при разархивации из nib.
Одно время даже либу написал, которая позволяет все cells заранее создать, чтобы не происходило скачков при скролле. - Все касающееся прорисовки, подсчета высоты и переиспользуемых ресурсов. Есть потрясающее исследование, которое на 100% закрывает этот пункт.
- Вопрос по Realm. Есть приложение с тем же чатом(можно любой другой пример), где таблица имеет некие разделители в виде даты или любого другого варианта. Как наиболее производительно сделать разделение по секциям? Какие есть варианты?
Уровень: middle и выше.
- Вопрос по CoreData. Есть приложение с тем же чатом. Сообщения могут приходить из сокета в одном из фоновых потоков. Нужно, чтобы пришедшее сообщение добавлялось в таблицу. Как будем делать? Какие есть варианты? С какими сложностями можно столкнуться?
Уровень: junior/middle и выше.
- Есть экран, наполнение которого зависит от нескольких запросов к серверу. То есть, содержимое должно быть показано только когда все они выполнятся. Например, страничка вконтакте. Пока не загрузится инфа о пользователе, сообщения со стены, первый поток фоток, должен крутится прогресс индикатор. Как будем строить логику?
Уровень: junior и выше.
Обратить внимание: хочу особенно здесь акцентировать на необходимость понимания gcd групп и синхронизации задач в Operation Queue. Будет здорово, если кандидат еще расскажет в чем разница того или иного решения.
РешениеDispatch group, синхронизированные операции.
- Случилась проблема. К вам прибежал разработчик из соседней команды и просит о помощи: приложение стало вылетать в релизе, но при этом нормально работает в дебаге. Как будем ловить ошибку? Что это может быть?
Уровень: middle и выше.
Обратить внимание: важно, чтобы кандидат был нацелен на результат. На факт исправления проблемы, а не на поиск причины. Первым делом человек должен спросить: 'Окей, гугл, а что, собственно, поменялось с момента, когда еще ничего не крашилось?', а только потом начинать захватывающий процесс отладки.
Почему это так важно: есть люди процесса, а есть результата. Разработчики процесса просто тратят деньги компании, что особенно заметно при лове нетривиальных багов. Они(разработчики) будут получать удовольствие от собственной компетенции, выставляя море бряков, читая статьи о вылетах и ошибках компилятора, погружаясь в профайлер с головой на весь день, когда достаточно было всего-то убрать сомнительный кусок кода. Это не значит, что не надо пользоваться профайлером и бряками. Просто надо понимать цель ради чего это делается.
РешениеДля начала надо вычислить точку вылета. Часто сомнительный код лежит на поверхности, стоит только сузить область поиска.
Если требуется отладка, то ставим whole module optimization + fast и проверяем вылет(для Swift). С вероятностью 90% воспроизведется в дебаге. Advanced отладку описывать нет смысла.
Еще можно попробовать обойтись только whole module optimization.
- В приложении есть некий модуль, который проводит большое количество операций в длинном цикле. В определенный момент происходит креш, приложение просто закрывается. Даже когда оставили всего один вывод строки, то проблема сохранилась. Приведен код для примера, в реальности операции гораздо сложнее и насыщеннее, вылет происходит быстрее:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { for index in 0...1000000 { let string = NSString(format: "test + %d", index) print(string) } return true }
Что это может быть? Как это вылечить?
Уровень: middle и выше.
Обратить внимание: понимание принципов управления памятью. Хотя бы в целом.
Я бы сказал, что ситуация из вопроса крайне редкая и задачу стоит использовать только для совсем уж распальцованных синьеров, всем остальным достаточно знать о наличии retain/release/retain count и retain circle.
РешениеДело в autoreleasepool. Лечится созданием своего пула или использованием не autoreleased объектов.
- Немного классики. Вы проводите Code Review подопечного джуна, который пишет класс календаря для вашего приложения, и обнаруживаете следующий кусок кода:
protocol CalendarDelegateProtocol { func didSelect(date: Date) } public class Calendar: UIView { var delegate: CalendarDelegateProtocol! ... func didReceiveTouchForDate(date: Date) { self.delegate.didSelect(date: date) print("Did touch: \(date)") } }
didReceiveTouchForDate — внутренний метод календаря, который вызывается при нажатии на определенную дату. Все ли тут в порядке на ваш взгляд?
Обратить внимание: проблем много, можно к каждой строчке докапываться почти. Чем больше деталей заметит соискатель, тем лучше.
Уровень: junior и выше.
Решение// Избыточное слово 'Protocol'. Достаточно просто 'CalendarDelegate' protocol CalendarDelegateProtocol { // Метод обязателен? Вряд ли. Должен быть optional. func didSelect(date: Date) } // Зачем public во внутреннем инструменте? Это только создаст помехи при оптимизации. public class Calendar: UIView { // Где weak? Потребуется еще отметка ':class' у протокола. // delegate не должен быть force-unwrapped var delegate: CalendarDelegateProtocol! ... // Название не по гайдлайнйам. Для Swift 3 должно быть: didReceiveTouch(date:) // Явно внутренний метод должен быть приватным func didReceiveTouchForDate(date: Date) { // Вызов должен быть опциональным. self.delegate.didSelect(date: date) // Лишний вывод. Просто мусор в логи print("Did touch: \(date)") } }
- Тестировщики обнаружили баг, что пуши в приложении приходят только на iOS 10, но не на iOS 9. Как будем исправлять? В чем может быть проблема?
Еще одна задачка из той же серии: пуши приходят при установке приложения напрямую на устройство, но не из Testflight/Crashlytics/HockeyApp. Как с этим жить?
Обратить внимание: если соискатель с ходу не может ответить в чем конкретно проблема, то можно дать ему ноут и предложить найти решение. Если на ноуте будет установлено сразу несколько браузеров, то замечательно. Поймете в какой поисковой системе человек предпочитает искать, на русском или английском, как формулирует запросы и так далее.
Уровень: middle и выше.
РешениеВозможно, уведомления рассылаются только с development сертификатом. Больше стоит уделить внимание тому как соискатель будет искать решение.
- Есть одномерный строковый массив, данные из которого выводятся в таблицу. При этом массив может меняться откуда-то извне. Как сделать так, чтобы данные в таблице обновлялись по мере изменения массива? Например, если объект добавился в массив, то в таблице должна появиться новая строка.
Уровень: junior и выше.
РешениеKVO. Если хочется совсем чистого решения, то можно еще засвиззлить некоторые методы.
- Вы делаете экран авторизации для Skype в storyboard с использованием autolayout. Так получилось. Все просто — квадратный лого, под ним текстовое поле и кнопка.
Вы классный, все сделали, но тут дизайнер заявляет, что при ландшафтной ориентации лого должно быть справа, а не сверху. Как будем делать?
Уровень: junior и выше.
Решение
- Нужно сделать scrollView с двумя картинками определенного размера друг под другом и отступами от края экрана со всех сторон в 30px. Нарисуйте на листочке какие будут констрейны.
Обратить внимание: понимает ли кандидат как определяется content size для scrollView? А если помнит про инсеты, так вообще замечательно. Может быть предложит поставить контент скроллвью на весь ее размер, без отступов, а расстояние от краев экрана сделать через margins.
Уровень: junior и выше.
Вопросы приведены в качестве примера. Если будет интересно, то составлю еще.
UPD1: добавил решения для большинства вопросов. Если оно отсутствует, то значит задача легко гуглится или решается самостоятельно.
Мой посыл следующий — используйте практические задачи. Если не нашли подходящей, то составляйте их сами. Вы берете на работу не энциклопедию, а специалиста, который должен делать дело, а не просто знать все на свете. А уж тем более не держать в голове то, что можно найти в гугле за секунды. Главное, понимать что искать.
Как говорил господин Шерлок Холмс, на моем чердаке должны находиться только необходимые инструменты.
Незаметное зло
Но сомнительные вопросы — не единственная проблема. Есть еще один фактор, который может отпугнуть даже успешного кандидата. Это неуважительное, надменное или высокомерное отношение. И я говорю не о девочках-hr или важных руководителях. А о будущих коллегах.
Во многих местах, где я проходил собеседование, техническое интервью происходит без присутствия наблюдателя из hr или руководства. Что в целом естественно, зачем человеку, который ни слова не понимает в терминологии, терять час на занудную беседу в стиле вопрос-ответ?
А вот зачем. Многие разработчики воспринимают проведение собеседования как возможность самоутвердиться. И проверка знаний превращается в самое обыкновенное
На тему задранных носов есть замечательная картинка у xkcd:
Но это все вовсе не значит, что в разработку идут одни чудаки. Технических специалистов просто никто не учит вести переговоры, проводить интервью и строить уважительный диалог. И не редко встречаются люди просто замкнутые, а порой даже забитые. Руководство бросает их на амбразуры со словами: 'Проверь уровень этого парня, подойдет он нам или нет'.
При этом нет никаких стандартов, образцов и требований. Каждый проводит собеседование в меру своего понимания и мироощущения при полном отсутствии обратной связи. Ведь кто может дать эту обратную связь? Руководство/HR и кандидаты. Первые в процессе не участвуют и ничего не могут сказать, а кандидатам точно уж не до этого. Если их приняли, то значит все хорошо. Если же нет, то смысл дальше разговаривать?
Всем этим я хочу сказать как компаниям, так и каждому коллеге-разработчику в отдельности: обратите внимание не только на то как вы проводите интервью, но и манеру в которой общаетесь со своими подчиненными и коллегами. Канцерогенное отношение может проявляться не только к соискателям.
Попросите кого-то поприсутствовать на паре собеседований и дать вам обратную связь. Спросите у самих кандидатов впоследствии как все прошло, было ли некомфортно или еще что. Это как Code Review, ничего постыдного тут нет. Вы только станете лучше как специалист.
Уважительное общение должно являться стандартом в технической сфере.
Заключение
Если эта статья изменит ситуацию хотя бы в одной компании, то значит мои усилия были не напрасны.
Я постарался подобрать максимально полезные вопросы. Если есть потребность в дальнейшем пополнении списка, то в следующий раз посвящу этому отдельную публикацию.
Будет здорово, если поделитесь своими вопросами и заданиями, которые даете на собеседовании, чтобы проверить специалистов. Ведь кому-то достаточно пяти минут, чтобы понять уровень, а кто-то маринует по полтора часа каждого.
И, как говорится, уважайте друг друга. Независимо от глубины ваших познаний в материале — это не повод смотреть сверху вниз на окружающих. Аминь.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (39)
norlin
21.02.2017 12:13+3С точки зрения pre-junior было бы интересно почитать ответы на предложенные вопросы :)
В частности, очень интересно про вопрос 11 – что там конкретно не так? %)
lookid
21.02.2017 12:15+2Тоесть чтобы попасть к вам на джуниора нужно сидеть дома с 2-3 версиями айосов под рукой, писать телеграмм, быть опытным в UI и дебажить кроссверсионные баги? Если вам нужны такие джуниоры, то организуйте стажировку или курсы. Я вот не понимаю зачем джуниору, который может внятно ответить на "только на iOS 10, но не на iOS 9", плюс всё остальное, вообще идти на джуниора лично к вам? Дайте угадаю. У вас штат программистов на 3/4 стоятит из студентов-выпускников приближенных кафедр?
Mehdzor
21.02.2017 12:29+1Я написал, что не обязательно знать ответ на этот вопрос. Достаточно уметь правильно его найти. Это даже важнее, чем с ходу выпалить.
MariyaSafonova
22.02.2017 12:39+3В данной статье оперируете понятиями junior, middle, senior — без конкретного определения.
В каждой компании требования разные. Даже в среднем по России требования могут отличаться.
Например, есть такое определение: "...Junior: студент старших курсов и без опыта работы. Если с человеком нужно сидеть и постоянно помогать. Можно доверить баги, но никак не рефаторинг или таски на 1-2 недели, то это 100% джуниор. Опыт фултаим: 0.5-1 год. Либо партайм: 1-2 года. Предметную область знает слабо..."
Каким образом указанный в этом определении джуниор сможет решить задачу №3 самостоятельно и без подсказки, если предметную область он знает плохо? Он даже нагуглить это не сможет, т.к. не поймет, что ему нужно гуглить.
Напишите Ваши требования к junior, middle, senior (или требования в среднем по рынку). Возможно, это тема для отдельной статьи.
Danik-ik
23.02.2017 20:56Присоединяюсь. Я, правда, в другом сегменте работаю, и много в примерах не понял, но общее ощущение таково, что джуниор для Вас — это уже какой-никакой, но опытный специалист. И мне интересно, какой именно уровень опыта Вы для него подразумеваете.
vitalrumyancev
21.02.2017 12:31+2Очень жду в комментах продолжения из подобных вопросов. Если бы еще в спойлеры добавить ответы, то полезность статьи зашкаливала бы.
Mehdzor
21.02.2017 13:39+1Окей, добавлю пояснения частично. На все подряд нет смысла, иначе можно копипастить документацию Apple просто.
Mehdzor
21.02.2017 16:41Подъехало обновление.
imsimon
21.02.2017 17:34А я так ждал ответ на вопрос номер 6. =(
Mehdzor
21.02.2017 18:30Есть несколько вариантов:
- Использовать RBQFetchedResultsController, но будет медленно. Подойдет для несложных экранов.
- Сделать отдельный relationship для секций. Например, если нужно разделять таблицу по дням, то сущность будет 'день'.
- Оставить единый список, а секции сделать искусственно внутри ячеек. Которые будут показываться по условию.
Siroque
26.02.2017 19:05С точки зрения статьи на хабре, которая должна иметь ценность для читателя, было бы гораздо полезнее дать пояснения по senior уровню, а джуниора можно было бы и пропустить. Как, например, номер 4. Не всем и не всегда нужно, но вопрос крайне занятный. Инстинктивно я понимаю, что нужно будет подниматься на мета-уровень и описывать все компоненты там. Но вот на счет конкретной реализации было бы очень интересно пару новодок получить.
Но, в любом случае, материал интересный и заставляет задуматься. Спасибо.
ijsgaus
21.02.2017 13:08+2Всегда чувствовал, что где то в программировании для Мак систем подвох. Но что ТАК много камней — да же представить себе не мог :-)
lencom
21.02.2017 13:08+2Иметь бы мне это знание года 4 назад, когда я начинала проводить собеседования в качестве тех.специалиста) Надменность, неумение просто поддержать беседу, задать действительно важные вопросы. Чувствовала, что что-то не так. Потом у себя спросила — что, если бы я была на месте этого кандидата. После этого я перестала задавать вопросы типа «чем хотите заниматься через 5 лет» — это глупо, даже если мы ищем человека на 5-летний контракт, или типа «как вы понимаете ООП» — можно 1 раз прочитать определение в двух разных источниках и правильно ответить — лучше попросить показать пример реализации или дать небольшое тестовое задание, если правильное понимание ООП для нас важно.
Ещё сделала для себя вывод — к сожалению, собеседование не очень показательно — часто бывает так, что кандидат себя отлично проявил на собеседовании и даже справился с заданиями, но на стажировке показал себя плохо, или наоборот — после собеседования очень сомневалась брать ли на стажировку, а потом была счастлива, что взяла. Но чем больше собеседований провожу, тем меньше ошибаюсь)
Сейчас для меня собеседование — это 2 одинаково ценных вопроса: 1. какой уровень навыков, 2. какой человек, его взгляды и реакции. Сейчас я уже не готовлю вопросы, просто стараюсь расслабиться и поговорить с кандидатом, к минимуму свести официоз, больше смотрю в глаза, говорю спокойнее. Некоторым сразу предлагаю перейти на «ты», если это уместно. Больше вопросов про практику — прошу рассказать про реализованные проекты/задачи, какие вопросы вставали, как решили, что именно сделали. Прошу рассказать, как человек решают какую-то конкретную типовую задачу (например, проектирует БД под новый проект и строит его архитектуру) — помогает понять, как он думает и умеет ли объяснять свои идеи, умеет ли составлять простой план своих действий. Ещё важно понять, умеет ли человек следовать простым инструкциям — для этого подойдёт даже короткое задание с множеством простых условий.
Lofer
21.02.2017 13:30+1Никогда не «задавал вопросы» на собеседованиях :)
Всегда старался помочь кандидату раскрыть свои знания, оценить ход его мысли, широту и гибкость взлядов и оценивал как могу их использовать в проекте. Как «дорого» будет «доточить» кандидата под проект.
А знания «API по памяти»- в большистве своем бессмысленны. На это мануалы есть и отладчик :)
reforms
21.02.2017 14:55У меня добрый случай был на собеседовании лет 7 назад: Очередной вопрос от интервьюера по java: 'Чем отличаются checked exceptions от unchecked?
Я ему честно — 'Узнал про термины checked/unchecked сегодня, но ответ знаю… бла бла бла'. Он мне в ответ: — ' Я тоже этим утром, когда узнал что пойду собеседовать вместо начальника'
Мы вместе посмеялись.
Когда провожу собеседование всегда обращаю на потенциал человека, сделал для себя вывод, что это ключевое при принятии решения.
На втором месте — навыки программирования, которые говорят о возможной должности кандидата в компании.
pronchik
21.02.2017 17:35+1Чёт какие-то вопросы странные. Кучу мелких юзкейсов. Любое собеседование — зеркало боли и отчаяния интервьюера, с которым он столкнулся на практике. Полагаю, в данном случае автор втыкался во все эти вещи и вынес их на интервью. Я б добавил сюда ещё глобальных вопросов про архитектуру и организацию проекта, чтобы понять, насколько собеседуемый способен превратить проект в несопровождаемый ужас и кошмар. Очень многие сеньёры на рынке на это способны, увы и ах. Как и джуны.
Mehdzor
21.02.2017 18:01Задачи подобраны таким образом, чтобы охватить наиболее частые вопросы на собеседованиях. Некоторые use-case из реальной жизни, другие придумал.
sstepashka
22.02.2017 08:11Про опциональный метод у протокола… Действительно ли нужно переходить в объектам Objective-C ради этого? Может достаточно было бы разделить интерфейсы, а все методы оставить обязательными. Тогда и вызов не должен быть опциональным, а достаточно только разыменовать delegate.
Про пуши, может быть ещё ошибка на сервере, например. Все помнят какой размер могут иметь пши в той или иной версии iOS?sstepashka
22.02.2017 08:12И почему бы при вылете приложения не исследовать crash-логи? А уже потом дебажить с whole module optimization…
Mehdzor
22.02.2017 12:38Не всегда они есть и не всегда информативны. Но в целом, если есть прямое указание на место крэша, то это здорово.
Ariandr
22.02.2017 15:29Отличная статья, спасибо!
Много полезной информации и вопросов, которые заставляет увидеть свои пробелы в знаниях и подходах к решению задач!
Было бы очень классно, если бы ты выложил список того, о чем стоит знать начинающему разработчику (например, полезных протоколов/классов вроде UIAppearance, что бы использовать их вместо всяких хаков и костылей, т.е. привыкать к правильному подходу изначально). Я имею ввиду знать не наизусть, а просто о том, что такая вещь существует и для чего она нужна, что бы в случае появления соответствующей задачи знать, что её стоит использовать.
svyat_reshetnikov
Отличная статья, Макс.
Я недавно решил потихоньку прощупывать рынок, т.к. на текущей работе проект близится к логическому завершению, и уже есть пара интересных случаев с собеседований.
В первом случае я предупредил что у меня есть основная работа с 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 проектах. Мне важна реальная работа — что кандидат уже делал и о чём он может рассказать.
mayorovp
Странно, что задача с анаграммами вызвала такие затруднения… Используемые-то трюки общие для очень большого класса задач!
Первый трюк: нормализация. Если построить функцию, которая будет выбирать один и тот же элемент для целого класса эквивалентности — то проверка двух элементов на эквивалентность сведется к применению этой функции и проверке на строгое равенство.
Может, это и звучит страшно, то используется-то этот прием постоянно! Когда хотят сравнить две строки без учета регистра — обе строки приводят к нижнему регистру (вы точно за всю карьеру программиста ни разу этого не делали?). Когда хотят сравнить две строки без учета различий в записи одних и тех же символов при помощи кодовых позиций юникода — их обе приводят к нормальной форме. Когда подписывают XML-файл, из него выкидывают незначимые пробелы...
Да, а когда сравнивают две строки на предмет анаграммы — их обе сортируют.
Второй трюк — для нахождения одинаковых элементов в массиве надо массив отсортировать.
svyat_reshetnikov
Может и делал когда-то давно. If you don't use it — you lose it.
В мобильной разработке основной спектр задач состоит в построении интерфейсов и обеспечении клиент-серверной архитектуры. Алгоритмические задачи бывают не так часто, плюс у меня было немного офигевшее состояние от просьбы написать работающую программу в шумном кафе в текстовом редакторе айфона)
В общем, всё знать невозможно. Я пришёл домой и разобрался в вопросе, закрыл свой пробел. Ну и Вам спасибо за описанные трюки)
Lofer
Наверное удивитесь, но программист пришел со своего проекта и у него в голове свой код, свои объекты архитектура, шаблоны мышления решения именно «проектных» типовых задач. Нужно некоторое время на «переключени контекста», а собеседование и так дополнительный стресс для мозга (подсознательная и сознательная оценка собеседника(ов)). И тут тебе в лоб «задача-тест» не удивительно, что не все разу могут подобрать решение. Это не значит что программист «тупой» или «не грамотный» и т.д., просто «фоновые потоки» заняли все ресурсы. Вполне возможно что через минут 30 спокойной обстановки он выдаст решение, даже процитировав на память API
TerraV
Вы, конечно же написали этот комментарий на айфоне? Скорее всего в метро, держась одной рукой за поручень. Я и рад был бы восхититься, но считаю подобный подход глупостью. Для всего есть свои инструменты, и скатываться в дикость (писать код не в IDE) это банально экономически неэффективно (равно как и развивать этот навык). Я лично не ем руками, для этого есть столовые приборы. Не пишу код в текстовых редакторах, для этого есть IDE с возможностью рефакторинга и анализаторы кода. И, конечно же, перед работой над задачей, я хотя бы поверхностно знакомлюсь с существующими реализациями и best practices (если применимо).
Danik-ik
Возможно, Вам не хватило уверенности для того, чтобы аргументированно отказаться от выполнения безумного предложения? Я бы ответил предложением написать код на бумажке в псевдокоде, предварительно описав устно общую идею алгоритма (кому-то хватило бы и этой части ответа). Некоторые работодатели заинтересованы в наличии у соискателя критического мышления в отношении заданий, а с другими я работать не сьал бы.
P.s. писал с телефона, на ходу. Лёд, холод. Ничего страшного. Но код… "Извините, нет"
svyat_reshetnikov
С уверенностью у меня всё нормально)
А вот аргументированно отказаться от этого безумного предложения — стоило бы. Честно признаться — был шокирован, поэтому как-то не сразу смог сообразить что не нужно такой ерундой страдать, а надо сразу отказываться от дальнейшего продолжения интервью.
Но что есть — то есть, и опыт получил, и вам грабли показал)
PavelGatilov
Подозреваю, что решение задачи было отнюдь не важным моментом. Как правило при стресс-собеседованиях смотрят на умение принимать решения в критических ситуациях, думать в напряжении и не сдаваться при поставленных задачах. Если это было собеседование в Долину, то тогда понятно почему именно так все и проходило. Во многих молодых стартапах обстановка на работе довольно стрессовая, постоянный шум-гам, изменение приоритетов, смена менеджмента и процессов каждую неделю. https://www.susanjfowler.com/blog/2017/2/19/reflecting-on-one-very-strange-year-at-uber
Алгоритмию дают для того чтобы понять ваш стиль мышления, скорость понимания вопроса, возможность задавать нужные вопросы, и думать не имея полного описания проблемы.
Много раз я слышал, особенно в СНГ сообществе, о том, что такой подход не адекватен — да он не адекватен для определенных условий, например стабильных продуктовых или аутсорс компаний, а для стартапов, стрессоустойчивость при неизменной производительности — ключ к успеху в некоторых аспектах.
И суть тут далеко не в том, что решение этой проблемы гуглится за 5 или менее минут или не в том, что вы никогда не будите это применять на практике. Проходя в свое время собеседование в Facebook, они дают множество материалов на эту тему, на тему собеседований и ожиданий от кандидата(Facebook хочет чтоб у вас получилось поэтому они вам помогают), могу порекомендовать книгу http://www.crackingthecodinginterview.com
Многим людям присущи ошибочные суждения, когда нет полной информации об условиях. С вашей стороны собеседование могло быть абсолютно неадекватным, а со стороны основателя это мог быть давным давно пройденный этап, десятки уволенных сотрудников неспособных держать нужный темп, он даже мог сам понимать, что вы думаете, что это интервью неадекватное, но тем не менее он делал свою работу.
svyat_reshetnikov
Я с вами не согласен во многом.
Прежде чем я продолжу комментарий, хочу отметить, что сейчас у меня 5 стартап по счёту, в котором я отвечаю полностью за всю техническую часть (CTO). Я не считаю себя экспертом, обучение — вещь бесконечная, но определённый опыт у меня есть.
Начну со стрессоустойчивости и стартапов. Я считаю, что если в стартапах стрессовая обстановка, то это явная недоработка со стороны руководства. Посмотрите Joel Test, в 8 пункте явно написано «Do programmers have quiet working conditions?». Стартап может менять направление, приоритет задач может меняться, но обстановка вокруг программистов должна быть нормальной. Разумеется, при смене направления развития продукта или критических багах в субботу вечером у программистов может возникнуть дискомфорт, но почти все программисты, с которыми я работал, достаточно спокойно относятся к таким явлениям. А вот шумная обстановка для программиста — верная гибель, не позволяет сосредоточиться и ведёт к быстрому выгоранию. Крупные компании вроде Google зарабатывают огромные деньги и они могут позволить себе текучку кадров из-за «выгоревших» работников, а вот стартапам и небольшим компаниям нужно лучше организовывать труд работников для того, чтобы сохранить костяк команды и нормально дойти хотя бы до релиза, а ещё лучше — до точки безубыточности.
В нашем стартапе мы уважительно относимся друг к другу, постоянно работаем над взаимопониманием между всеми участниками. Именно поэтому мы с удовольствием работаем сверх нормы и без проблем фиксим баги в час ночи. Если в стартапе изначально токсичная атмосфера, то стоит ли туда идти? Душевный покой не купишь)
Теперь по поводу адекватности подхода. Программирование это как искусство, так и ремесло. Так вот, с точки зрения ремесла, нужны инструменты для решения тех или иных задач. Если мы лишим инструментов электрика, то чем ему замерять напряжение в сети? Пальцами? К тому же, достаточно глупо просить электрика заменить сантехнику, равно как и просить мобильного разработчика решить алгоритмическую задачу. В мобильной разработке алгоритмические задачи встречаются крайне редко, основные задачи это красивый интерфейс и приём-передача данных на сервер. Электрик может разбираться в сантехнике, а может и не разбираться — это не его основная задача. Мобильный программист может быть подкован в алгоритмах, а может и не быть — это также не его основная задача.
Теперь давайте подумаем с точки зрения бизнеса. И работодатель, и программист должны понимать, зачем и для чего вообще пишут программу. А программу пишут для того, чтобы удовлетворить потребности клиента. Клиенту всё равно — умею ли я решать анаграммы и могу ли я подсчитать сколько шариков влезет в школьный автобус. Ему также плевать на то, знаю ли я почему крышки люков делают круглыми. Всё, чего хочет клиент — это продукт. Всё, что должен делать я — дать ему этот продукт. Нет клиента — нет бизнеса — нет смысла в программе, которую я пишу. Работодатель должен проверять умею ли я пользоваться инструментами, которые позволяют создать эту программу. Всё остальное — порнография.
PavelGatilov
Ни в коем случае не высказывался за проведение собеседований подобными методами, и сам никогда такие не проводил. Но лишь описал, то почему такие собеседования существуют.
Тем не менее, это давольно часто встречается, более того многие руководители понимают, что это недоработка и что недоработка эта явная и тем не менее не всегда есть средства, силы, умения это исправить. А найм сотрудников должен проходить по плану и в соответствии количеству работы, при этом имеет смысл нанимать сотрудников, которые смогут «выжить» в такой среде. Ни в коем случае не утверждал в моем комментарии, что иметь стрессовую ситуацию на рабочем месте — это круто и правильно.
Во многих стартапах это компенсирую деньгами.
Сам мобильный разработчик, сам никогда для проектов не писал поиск в ширину в графе, но тем не менее, в компаниях типа Facebook(упоминаю, опять таки потому что проходил интервью) это объясняют тем, что им нужно понять какого типа человек, как он думает, как умеет решать проблемы и адаптировать задачи. Если человек грубо говоря «умный», то сможет легко освоить любую технологию, и как они же утверждают у них достаточно времени и средств для того чтобы переучить вас под любую специальность, им не завтра теплой делать.
Почему так делают в стартапах, насколько я сталкивался, меня просто собеседовании спецы из другой области, в один из стартапов на должность iOS дева, собеседовал джавист, а общего у нас только Компьютерные науки, где алгоритмия берет большую часть.
Далеко не весь бизнес так работает. В основном так работает малый и средний. Большой бизнес и отдельно стартапы иногда работают по другому.
Завтра поменяться инструменты — вы сможете адаптироваться? Хватит ли вам сноровки и ловкости, или вы просто один из строжил на асемблере. Я бы не был так однозначен насчет инструментария.
svyat_reshetnikov
В каких-то местах я вас не так понял. Я рад что мы оба считаем, что стрессовая обстановка на работе это плохо. Также мне нравится то, что вы сами понимаете, что такие собеседования — далеко не самый грамотный подход к поиску будущих коллег.
Каждый волен распоряжаться своим временем и здоровьем так, как он считает нужным. Лично я никому не рекомендую идти в токсичную среду — заработаете денег и большую часть спустите на восстановление здоровья. Если вычесть все компенсационные расходы, то получится не так уж и много — эти же деньги можно заработать менее «травмоопасным» способом. Тут уже каждый решает сам, стоит ли игра свеч.
Ну тут опять же, смотря какой контекст. Я проходил собеседование в стартап и имею в виду работу в стартапах. Если взять крупные компании, то там другой уровень и другие условия найма — там нужны винтики в системе, которые могут чётко и быстро выполнять задачи без лишних вопросов. В стартапах и небольших компаниях акцент всё-таки идёт на личность человека и на его мотивацию довести проект до конца, текучка там крайне нежелательна — время и средства ограничены, а текучка запросто приведёт к появлению спагетти-кода. Если бы я проходил собеседование в большую компанию, я бы прогнал все свои знания по алгоритмам, структурам данных, ООП, паттернам и т.д., т.к. я понимаю специфику и понимаю чего от меня будут ожидать на этом собеседовании.
Давайте не будем утрировать) Инструменты не поменяются в одночасье, но тем не менее, идёт определённая эволюция, за которой я слежу очень пристально. Я регулярно читаю новости из мира разработки, регулярно зависаю на Github, постоянно нахожу какие-то новые инструменты и библиотеки и пробую их. Если мне инструмент нравится — я внедряю его в текущий проект, зачастую переписывая много кода. Я считаю это нормальным подходом для любого программиста — профессионал должен держать руку на пульсе отрасли, в которой он работает, для того, чтобы быть востребованным на рынке труда.