Я просто имел в виду, что если пишут, что требуется знание языка и вы действительно использовали этот язык некоторое время, то не факт, что пройдёте собеседование, потому что спросить могут по специфическим особенностям языка, которых вы вообще не касались. Такое я и у зарубежных и у наших компаний встречал, только у наших подготовиться проще, если в анкете конкретные технологии уточняют.
С полпинка инженер с опытом во многом разобраться может, только вот на собеседовании большинство компаний, что наших, что зарубежных, потребуют уже знание этих технологий, а не возможность в них разобраться)
А там разве нет? Да в половине зарубежных компаний при подаче на вакансию есть вопрос: Вы пришли по рекомендации? Если да, то укажите, от кого. Ну и разные вариации этого вопроса. Разве это не неформальные связи?
На западе обычно пишут: знание Java или другого ООП-языка. И всё!
Пишут - это да. А вот что спросят на собеседовании - это большой вопрос. К примеру, работаете вы несколько лет на C++ 14 с сетевыми библиотеками, STL и boost, а на собеседовании вас могут спросить о том, что такое RAII, diamond problem, о каких-нибудь очередных отличиях в реализации умных указателей в C++ 20 и надо сходу ответить. Сразу без подготовки на такое не ответить, а ведь требования формально соблюдены - несколько лет опыта в условном C++.
Поэтому лучше конкретно знать, чего хочет работодатель, порой даже лучше с привязкой к версии
Ну, поначалу были отказы с формулировкой: плавал в некоторых вопросах. Поэтому и поставил в вывод, что это фатально)
Было и такое: с командой прямо как родные оказались - очень душевно побеседовали по многим вопросам, но я не знал, можно ли closure как weak сделать и это оказалось решающим фактором.
Порой возникало ощущение, что половина компаний не прощупывает твои навыки, а ищет малейший повод тебя не взять)
Тут я привёл только технические вопросы. Вопросы про мягкие навыки общие для всех разработчиков, не только для iOS.
Смех. Буду учитывать случаи, где технические вопросы были отвечены хорошо. Помню как минимум три случая:
1) Как-то раз посмеялись над полнотой документации Apple, к примеру. Что описание частенько ограничивается прототипом функции.
2) Стало как-то раз смешно после сравнения обработчиков ошибок в Си-образных языках и в Swift.
3) Над удобством constrains
Это просто к примеру. Почему это вызвало отказ на техническом собеседовании - не знаю, но смех был единственным общим моментом в этих собеседованиях при правильно отвеченных вопросах.
И устроились ли Вы в итоге, зазубрив ответы на самые популярные вопросы?
Ну, прям сидеть и зубрить - это не практично. Просто, если слышал вопрос, то пробовал это использовать в каком-нибудь тестовом проекте.
Как я в одном из комментариев уже отвечал: в iOS множество непересекающихся областей, работая над которыми можно никогда за затрагивать другие области. А спросить могут что угодно при одном и том же описании вакансии.
К примеру, вопрос, что такое ServiceLocator. Или надо ли держать в голове такие вопросы как, например, какие есть события у делегата UITableView, когда я уже 3 года использую SwiftUI и в описании вакансии стоит SwiftUI? Показывает ли реально твои навыки работы с iOS? На мой взгляд, не особо.
Не думаю, что я поступаю нечестно, составляя такой список. Не всегда же держишь в голове вещи, которые раз в год от силы применяются, как например App Transport Security. А если спросят и не ответишь - откажут.
P.S.: Устроился в одну московскую компанию.
P.P.S.: А вы знаете более способ получше, чтобы подготовиться к iOS собеседованию, чем вот такой итеративный?
Вообще, эти комментарии заставили вспомнить из-за чего я и решил этот сборник сделать. Несколько разных компаний могут написать одни и те же требования в вакансии, к примеру, вот вполне стандартная вакансия:
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, но спасибо за дополнение.
Про 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 ?
И рад бы согласиться, но увы. Зачастую даже правильно написанный код не означал прохождение этого собеседования. А когда кандидатов на должность от 50 человек и больше, то ошибка стоит дорого.
Вопрос такой, а как избежать такого момента: если я поставлю на загрузку в задаче класса .background несколько гигабайт картинок, и уберу приложение в бэкграунд, то в пределах минуты приложение из бэкграунда закроется со словами, мол, использует > 80% CPU. И загрузка не завершится.
Как задать потоку .background такое состояние, чтобы он потреблял определённое количество ресурсов процессоров (<80%)? А то ОС просто закроет его. В foreground такой проблемы нету
Холостяк решил погладить рубашку перед работой, включает утюг, а он не работает.
Решил он сходить к соседке за утюгом.
Звонит в дверь, а сам думает, сейчас она откроет дверь, я попрошу у нее утюг, она скажет:
Ну что вы стоите в пороге, проходите попьем кофе, где кофе, там и коньяк, после коньяку затащит меня в постель, пересплю с ней, она забеременеет, родится ребенок, придется на ней жениться, пойдут пеленки, распашонки, начнутся скандалы…
В это время открывается дверь, на пороге красивая девушка!
Западную технику погубит автоматика. Сломается механика — та поддаётся починке отвёрткой, сломается автоматика — проще заменить прибор, нежели его чинить, следовательно, должны быть предусмотрены запчасти, причём на все автоматические приборы, а ведь каждый килограмм на счету при полёте к орбите.
Я просто имел в виду, что если пишут, что требуется знание языка и вы действительно использовали этот язык некоторое время, то не факт, что пройдёте собеседование, потому что спросить могут по специфическим особенностям языка, которых вы вообще не касались.
Такое я и у зарубежных и у наших компаний встречал, только у наших подготовиться проще, если в анкете конкретные технологии уточняют.
С полпинка инженер с опытом во многом разобраться может, только вот на собеседовании большинство компаний, что наших, что зарубежных, потребуют уже знание этих технологий, а не возможность в них разобраться)
А там разве нет? Да в половине зарубежных компаний при подаче на вакансию есть вопрос: Вы пришли по рекомендации? Если да, то укажите, от кого. Ну и разные вариации этого вопроса. Разве это не неформальные связи?
Пишут - это да. А вот что спросят на собеседовании - это большой вопрос. К примеру, работаете вы несколько лет на C++ 14 с сетевыми библиотеками, STL и boost, а на собеседовании вас могут спросить о том, что такое RAII, diamond problem, о каких-нибудь очередных отличиях в реализации умных указателей в C++ 20 и надо сходу ответить. Сразу без подготовки на такое не ответить, а ведь требования формально соблюдены - несколько лет опыта в условном C++.
Поэтому лучше конкретно знать, чего хочет работодатель, порой даже лучше с привязкой к версии
Ну, поначалу были отказы с формулировкой: плавал в некоторых вопросах. Поэтому и поставил в вывод, что это фатально)
Было и такое: с командой прямо как родные оказались - очень душевно побеседовали по многим вопросам, но я не знал, можно ли closure как weak сделать и это оказалось решающим фактором.
Порой возникало ощущение, что половина компаний не прощупывает твои навыки, а ищет малейший повод тебя не взять)
Тут я привёл только технические вопросы. Вопросы про мягкие навыки общие для всех разработчиков, не только для iOS.
Смех. Буду учитывать случаи, где технические вопросы были отвечены хорошо. Помню как минимум три случая:
1) Как-то раз посмеялись над полнотой документации Apple, к примеру. Что описание частенько ограничивается прототипом функции.
2) Стало как-то раз смешно после сравнения обработчиков ошибок в Си-образных языках и в Swift.
3) Над удобством constrains
Это просто к примеру. Почему это вызвало отказ на техническом собеседовании - не знаю, но смех был единственным общим моментом в этих собеседованиях при правильно отвеченных вопросах.
Ну, прям сидеть и зубрить - это не практично. Просто, если слышал вопрос, то пробовал это использовать в каком-нибудь тестовом проекте.
Как я в одном из комментариев уже отвечал: в iOS множество непересекающихся областей, работая над которыми можно никогда за затрагивать другие области. А спросить могут что угодно при одном и том же описании вакансии.
К примеру, вопрос, что такое ServiceLocator. Или надо ли держать в голове такие вопросы как, например, какие есть события у делегата UITableView, когда я уже 3 года использую SwiftUI и в описании вакансии стоит SwiftUI? Показывает ли реально твои навыки работы с iOS? На мой взгляд, не особо.
Не думаю, что я поступаю нечестно, составляя такой список. Не всегда же держишь в голове вещи, которые раз в год от силы применяются, как например App Transport Security. А если спросят и не ответишь - откажут.
P.S.: Устроился в одну московскую компанию.
P.P.S.: А вы знаете более способ получше, чтобы подготовиться к iOS собеседованию, чем вот такой итеративный?
Вообще, эти комментарии заставили вспомнить из-за чего я и решил этот сборник сделать.
Несколько разных компаний могут написать одни и те же требования в вакансии, к примеру, вот вполне стандартная вакансия:
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% совпадения с используемыми ими фреймворками.
Потому и решил несколько обобщить.
Наверное, от компании зависит. Последнее время часто слышал, что, мол, у нас всё было написано на UIKit, но мы всё перевели (или сейчас переводим) на SwiftUI.
Со SwiftUI есть ещё проблемы, это да, но сейчас что-то новое нативное если пишут, то чаще выбирают SwiftUI.
Хорошие вопросы. Некоторые из них действительно встречались. Особенно dead lock, race condition.
Любопытно. Такое не встречалось, разве что, про constraints, но спасибо за дополнение.
Про 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 ?
По мне так проще не смеяться на собеседовании, чем выяснять, оскорбил ли я кого-нибудь смехом или шуткой.
И рад бы согласиться, но увы. Зачастую даже правильно написанный код не означал прохождение этого собеседования. А когда кандидатов на должность от 50 человек и больше, то ошибка стоит дорого.
Возможно, это какая-то статистическая погрешность, но у меня практически в 100% случаев смех означал отказ. Самому интересно, почему)
Как задать потоку .background такое состояние, чтобы он потреблял определённое количество ресурсов процессоров (<80%)? А то ОС просто закроет его. В foreground такой проблемы нету
Решил он сходить к соседке за утюгом.
Звонит в дверь, а сам думает, сейчас она откроет дверь, я попрошу у нее утюг, она скажет:
Ну что вы стоите в пороге, проходите попьем кофе, где кофе, там и коньяк, после коньяку затащит меня в постель, пересплю с ней, она забеременеет, родится ребенок, придется на ней жениться, пойдут пеленки, распашонки, начнутся скандалы…
В это время открывается дверь, на пороге красивая девушка!
— Да пошла ты со своим утюгом!!!
У операторов это вполне реально узнать.
Зато они в помогают при поиске.