Комментарии 18
Скорее всего, если вы на собеседовании начали смеяться над чем-то вместе с интервьюером, то вас точно не возьмут, ибо, "не время улыбаться".
А вот это вы зря.
Берем случайный старый и очень известный мем. (Выбирал быстро, если подготовиться то можно лучше. Даже под резюме подобрать можно. Чтобы максимально непонятно для всех, но человек с таким резюме должен понять)
мем
Разыгрываем первую его часть. Улыбаемся и смотрим на кандидата. Если у кандидата в резюме: "сеньор, много лет работы, софт скилы и все как обычно" и он при этом хлопает глазами и ничего не понимает то это очень тревожный звоночек. С ним скорее всего что-то не так.
Всего 5 минут времени, а сразу куча информации о человеке получается.
Возможно, это какая-то статистическая погрешность, но у меня практически в 100% случаев смех означал отказ. Самому интересно, почему)
Это значит что вы не поняли над чем смеялись.
У вас есть небольшая БД на 100 гигабайт в прыжке. Приходит к вам тимлид фронта со словами надо туда положить поле с ямлом. В нем будут какие-то конфиги ваших юзеров. Бизнесу надо, тут все ок. Что делать будете?
ответ
Вежливо и культурно послать его описывать нормальные типы того что там лежать будет. И юзкейсы как это будет использоваться и расширяться. Помощь предложить тоже стоит. Любой другой ответ как раз вызовет смех у меня. Ладно не совсем любой, но многие варианты ответа. И no hire кандидату. Если кандидат вежливо посмеется вместе со мной то тем более no hire. Он мало того что неверно ответил, так еще и подхалим.
По мне так проще не смеяться на собеседовании, чем выяснять, оскорбил ли я кого-нибудь смехом или шуткой.
Шутки на собеседовании только над кодом и над типичными проблемами разработки. Над собой шутить можно всем и всегда.
Вы устраиваетесь работать к живым людям. С которыми вы будете проводить по 8 часов в день 5 дней в неделю годами. Мы все люди. Мы шутим. По разному шутим. Кандидат не понимающий о чем речь вызывает подозрения. Он вообще с коллегами говорил до этого? Лучше отказать.
Звезды могли и не говорить с коллегами, но поймут о чем речь и так. На то они и звезды.
С выводами не согласен, а шпаргалка хорошая.
Спасибо за свежий фидбек с собеседований) Относительно простые вопросы, почти не затронута тема асинхронности/многопоточности, работа с памятью, zombi object, side table, responder chain, hit test, autolayout, size classes и т.д.
Про autolayout спрашивали только в чём разница между frame и bounds. Но довольно редко, поэтому даже записать забыл. Да и в принципе, про UIKit редко кто спрашивал. Больше вопросов было про SwiftUI.
Про асинхронность спрашивали в основном про то, какие механизмы есть, но не как они работают, поэтому уложил всё в один вопрос: "What asynchronous functionality is available in Swift?"
По поводу работы с памятью никто дальше ARC не спрашивал. Хотя, три года назад памяти меня спрашивали про работу с памятью в Objective-C, про разницу между strong, retain, atomic, nonatomic, и т.д. Но за последнее время такого точно не было.
А вот про остальное ни разу не спрашивали за последнее время. Разве что, года три назад.
А можете рассказать, какие бы вы задали вопросы по темам: асинхронности/многопоточности, работа с памятью, zombi object, side table, responder chain, hit test, autolayout, size classes ?
Вопросов можно много задавать) стандартные вопросы,
по асинхронности/многопоточности: какие бывают очереди, чем отличаются, что такое dead lock, race condition, инверсия приоритетов, как выполнить группу асинхронных запросов, как отменить задачу, чем отличаются GCD/Operation/async и т.д.
по работе с памятью: как хранятся ссылки и выполняются методы в классах/потомках, как высвобождаются объекты, weak/self/unowned и т.д.
responder chain, hit test: какие бывают жесты, как обрабатываются нажатия, какие есть нюансы и т.д.
autolayout, size classes: что такое autolayout, как сделать адаптивную верстку на разных устройствах, как верстать кодом, когда лучше использовать сториборды, что такое констрейнты и для чего нужны и т.п.
Интересно, что стало много вопросов по SwiftUI, при том что в проде его все-таки немного.
А, ну еще можно поспрашивать про хранение данных в CoreData, Keychain, UserDefaults, обработку пушей и диплинков.
Вообще, эти комментарии заставили вспомнить из-за чего я и решил этот сборник сделать.
Несколько разных компаний могут написать одни и те же требования в вакансии, к примеру, вот вполне стандартная вакансия:
3+ years of experience in iOS development.
Experience with ObjC, Swift and SwiftUI.
Familiarity with RESTful APIs to connect applications to back-end services.
Knowledge of iOS design principles, patterns, and best practices.
А как придёшь: одна компания спросит про многопоточность и App Transport Security, другая - про жизненный цикл приложения и ViewController, третья - про наследование классов и Codable protocol, четвёртая про то, какие бывают publisher-ы в Combine. И всё это вакансии с одним и тем же описанием.
А ты при этом занимался какими-нибудь VPN-ками, Bluetooth Low Energy и REST-клиентскими приложениями.
В iOS много непересекающихся друг с другом областей, а каждая компания при этом требует что-то своё и требует практически 100% совпадения с используемыми ими фреймворками.
Потому и решил несколько обобщить.
Интересно, что стало много вопросов по SwiftUI, при том что в проде его все-таки немного.
Наверное, от компании зависит. Последнее время часто слышал, что, мол, у нас всё было написано на UIKit, но мы всё перевели (или сейчас переводим) на SwiftUI.
Со SwiftUI есть ещё проблемы, это да, но сейчас что-то новое нативное если пишут, то чаще выбирают SwiftUI.
по асинхронности/многопоточности: какие бывают очереди, чем отличаются,
что такое dead lock, race condition, инверсия приоритетов, как выполнить
группу асинхронных запросов, как отменить задачу, чем отличаются
GCD/Operation/async и т.д.
Хорошие вопросы. Некоторые из них действительно встречались. Особенно dead lock, race condition.
responder chain, hit test: какие бывают жесты, как обрабатываются нажатия, какие есть нюансы и т.д.
autolayout, size classes: что такое autolayout, как сделать адаптивную верстку на разных устройствах, как верстать кодом, когда лучше использовать сториборды, что такое констрейнты и для чего нужны и т.п.
Любопытно. Такое не встречалось, разве что, про constraints, но спасибо за дополнение.
А где же вопросы про мягкие навыки?
Какой ответ вызвал смех у вас обоих?
И устроились ли Вы в итоге, зазубрив ответы на самые популярные вопросы?
Тут я привёл только технические вопросы. Вопросы про мягкие навыки общие для всех разработчиков, не только для iOS.
Смех. Буду учитывать случаи, где технические вопросы были отвечены хорошо. Помню как минимум три случая:
1) Как-то раз посмеялись над полнотой документации Apple, к примеру. Что описание частенько ограничивается прототипом функции.
2) Стало как-то раз смешно после сравнения обработчиков ошибок в Си-образных языках и в Swift.
3) Над удобством constrains
Это просто к примеру. Почему это вызвало отказ на техническом собеседовании - не знаю, но смех был единственным общим моментом в этих собеседованиях при правильно отвеченных вопросах.
И устроились ли Вы в итоге, зазубрив ответы на самые популярные вопросы?
Ну, прям сидеть и зубрить - это не практично. Просто, если слышал вопрос, то пробовал это использовать в каком-нибудь тестовом проекте.
Как я в одном из комментариев уже отвечал: в iOS множество непересекающихся областей, работая над которыми можно никогда за затрагивать другие области. А спросить могут что угодно при одном и том же описании вакансии.
К примеру, вопрос, что такое ServiceLocator. Или надо ли держать в голове такие вопросы как, например, какие есть события у делегата UITableView, когда я уже 3 года использую SwiftUI и в описании вакансии стоит SwiftUI? Показывает ли реально твои навыки работы с iOS? На мой взгляд, не особо.
Не думаю, что я поступаю нечестно, составляя такой список. Не всегда же держишь в голове вещи, которые раз в год от силы применяются, как например App Transport Security. А если спросят и не ответишь - откажут.
P.S.: Устроился в одну московскую компанию.
P.P.S.: А вы знаете более способ получше, чтобы подготовиться к iOS собеседованию, чем вот такой итеративный?
Нет. Способ подходящий. Сам им активно пользуюсь, только не заморачиваюсь со списком :)
Просто мне кажется, что Вы ошибаетесь, когда говорите, что из-за одного неотвеченного хардварного вопроса Вам отказывают потому, что находится тот, кто отвечает и на этот вопрос.
Хардварные вопросы, кажется, уже давно не являются критерием приема во многих компаниях (ну, если не ищут супер-пупер-архитектора). Они, скорее, просто повод, чтобы о чем-то поговорить. Чтобы заполнить пустоту на собеседовании. С таким же успехом можно было бы поговорить и о Вашем хобби, но это бы у Вас еще большее недоумение вызвало и гневную статью о бренде на Хабре. Поэтому и принято говорить о том, что меньший стресс у человека вызывает. :)
А решение принимают все же по другим критериям. Иногда чисто по очень субъективным. Увы и ах, но да.
Поэтому и спросил про мягкие навыки. Без их упоминания и анализа делать глубокие выводы, которые делаете Вы, немножко некорректно. Нужно анализировать всю картину целиком. Возможно, Вы как раз проваливали мягкую часть и шутейки ^.^
Ну, поначалу были отказы с формулировкой: плавал в некоторых вопросах. Поэтому и поставил в вывод, что это фатально)
Было и такое: с командой прямо как родные оказались - очень душевно побеседовали по многим вопросам, но я не знал, можно ли closure как weak сделать и это оказалось решающим фактором.
Порой возникало ощущение, что половина компаний не прощупывает твои навыки, а ищет малейший повод тебя не взять)
Подготовка к собеседованию на iOS разработчика (актуально на начало 2023 года)