Capture list 🤔
Сегодня разберем еще один классический вопрос с ios собеседований. Необходимо понять, что будет выведено в консоль.
Начем с самого простого. Переменная cityClass в пункте 4 меняет свое значение поля name. Т.к классы относятся к reference type, то захват в capture list никак не повлияет на итоговое значение. В консоле мы увидем в обоих случаях "Liverpool".
Переменная cityStruct - cтруктура, поэтому в первом замыкании она будет скопирована при захвате в capture list, а во втором обращение произойдет в момент выполнения замыкания к уже обновленной переменной. Поэтому "London" и "Marseille" соответственно.
Последний случай может показаться самым неочевидным. Переменная cityClassOptional захватывается в первом замыкании по слабой ссылке. В пункте 4 сначала создается еще один указатель на cityClassOptional, а потом заниляется. В замыкании closure1 будет выведено Paris - счетчик ссылок у объекта еще не равен нулю (doubleClass удерживает объект по сильной ссылке), а вот closure2 обратится по указателю уже к пустому значению.
Как итог, вывод в консоль будет выглядеть следующим образом:
1 - my city is Liverpool
2 - my city is London
3 - my city is Paris
4 - my city is Liverpool
5 - my city is Marseille
6 - my city is nil
А что произойдет если применить weak к переменной с типом структуры? К счастью, компилятор поможет понять, что такое действие недопустимо. ARC не применим к Value Types
'weak' may only be applied to class and class-bound protocol types
#interview #ios #swift
Сегодня разберем еще один классический вопрос с ios собеседований. Необходимо понять, что будет выведено в консоль.
Начем с самого простого. Переменная cityClass в пункте 4 меняет свое значение поля name. Т.к классы относятся к reference type, то захват в capture list никак не повлияет на итоговое значение. В консоле мы увидем в обоих случаях "Liverpool".
Переменная cityStruct - cтруктура, поэтому в первом замыкании она будет скопирована при захвате в capture list, а во втором обращение произойдет в момент выполнения замыкания к уже обновленной переменной. Поэтому "London" и "Marseille" соответственно.
Последний случай может показаться самым неочевидным. Переменная cityClassOptional захватывается в первом замыкании по слабой ссылке. В пункте 4 сначала создается еще один указатель на cityClassOptional, а потом заниляется. В замыкании closure1 будет выведено Paris - счетчик ссылок у объекта еще не равен нулю (doubleClass удерживает объект по сильной ссылке), а вот closure2 обратится по указателю уже к пустому значению.
Как итог, вывод в консоль будет выглядеть следующим образом:
1 - my city is Liverpool
2 - my city is London
3 - my city is Paris
4 - my city is Liverpool
5 - my city is Marseille
6 - my city is nil
А что произойдет если применить weak к переменной с типом структуры? К счастью, компилятор поможет понять, что такое действие недопустимо. ARC не применим к Value Types
'weak' may only be applied to class and class-bound protocol types
#interview #ios #swift
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥2😱2🤡1
Vibe собесов 😏
Посмотрел на днях интервью Антон проходит собеседование на iOS разработчика – оффер 550к. Оно навело меня на мысли о том, насколько важен именно вайб или ощущение от происходящего, для обеих сторон. Собственно многие позитивные флаги, поддержание правильной атмосферы и продемонстрировал Антон в этом, на мой взгляд, интересном интервью.
Теперь по порядку. Начинающие разработчики зачастую готовятся только по хард скиллам. Заучивают топ 100-150 вопросов по вставь_свой_язык_программирования и думают, что это оптимальный подход. На первых порах может быть так оно и есть, важно продемонстрировать свои навыки и компетенции, зачастую, выдавая заученные клише на популярные вопросы. Но когда речь заходить о высокой позиции, где от сотрудника будет требоваться намного больше, важно попасть в так называемый culture fit.
Бывает и такое, что интервью не задается, вопросы пошли душные и тд. Многие начинают нервничать, выдумывать, или говорят что-то невнятное. Люди поопытней могут сделать более хитрый маневр и постараться перевести поток мыслей и внимание интервьюеров в другую сторону, и попробовать порассуждать или даже убедить их в том, что вопрос не имеет прикладного значения или вообще бессмысленный. Собственно, похожие приемы и помогают выйти победителем по итогу.
Зачастую, после собеседования думаешь, что прошел его хорошо, ответил на все вопросы, но оффер так не получил. Но покопавшись глубже понимаешь - коннекта не было! Ты не смог убедить почему именно тебя должны позвать на работу. А бывает и наоборот. Вопросы сложные, ответы слабые, но получилось быстро понять, кого ищет компания, найти точки соприкосновения и дать им то, что они хотят в другом виде.
Из своего опыта хочется вспомнить несколько моментов, для лучшего описания, что я имею ввиду. Однажды, я попал на собеседование в компанию, приложением которой я пользовался, и оно мне нравилось. Я понятия не имел, как там все устроено в техническом плане. Релевантного опыта тоже не было в этом бизнес направлении. После технической части, я думал, что провалил интервью и на эту позицию компания будет искать разработчика дальше. Но когда дело дошло до моих вопросов (я подготовил их заранее, что рекомендую делать всегда) диалог пошел намного бодрее, я смог продемонстрировать, что мне интересно, как я могу улучшить то, чем уже пользуюсь и люблю. Подсветил вопросы со стороны клиента и мобильного разработчика и даже некоторыми вопросами поставил в тупик интервьюеров. Я думаю, это сыграло ключевую роль при найме меня и я тоже, с радостью, согласился пойти работать в эту компанию.
Что еще важно продемонстрировать на интервью?
Рассуждения вслух. Телепатов среди нас нет, а вот умение переносить поток мыслей в поток вербальности - хороший навык. Любой, кто проводит собеседования обращает на это внимание.
Не сдаваться. Если не знаете, как ответить на вопрос или решить задачу, продолжайте набрасывать идеи и предлагать разные подходы. Важно осознавать, что в современных реалиях вся работа - командная, поэтому не обязательно вывозить все на своих плечах. Грамотный интервьюер всегда направит вас в нужное русло, чтобы вместе прийти к успешномууспеху результату.
#interview #random #it
Посмотрел на днях интервью Антон проходит собеседование на iOS разработчика – оффер 550к. Оно навело меня на мысли о том, насколько важен именно вайб или ощущение от происходящего, для обеих сторон. Собственно многие позитивные флаги, поддержание правильной атмосферы и продемонстрировал Антон в этом, на мой взгляд, интересном интервью.
Теперь по порядку. Начинающие разработчики зачастую готовятся только по хард скиллам. Заучивают топ 100-150 вопросов по вставь_свой_язык_программирования и думают, что это оптимальный подход. На первых порах может быть так оно и есть, важно продемонстрировать свои навыки и компетенции, зачастую, выдавая заученные клише на популярные вопросы. Но когда речь заходить о высокой позиции, где от сотрудника будет требоваться намного больше, важно попасть в так называемый culture fit.
Бывает и такое, что интервью не задается, вопросы пошли душные и тд. Многие начинают нервничать, выдумывать, или говорят что-то невнятное. Люди поопытней могут сделать более хитрый маневр и постараться перевести поток мыслей и внимание интервьюеров в другую сторону, и попробовать порассуждать или даже убедить их в том, что вопрос не имеет прикладного значения или вообще бессмысленный. Собственно, похожие приемы и помогают выйти победителем по итогу.
Зачастую, после собеседования думаешь, что прошел его хорошо, ответил на все вопросы, но оффер так не получил. Но покопавшись глубже понимаешь - коннекта не было! Ты не смог убедить почему именно тебя должны позвать на работу. А бывает и наоборот. Вопросы сложные, ответы слабые, но получилось быстро понять, кого ищет компания, найти точки соприкосновения и дать им то, что они хотят в другом виде.
Из своего опыта хочется вспомнить несколько моментов, для лучшего описания, что я имею ввиду. Однажды, я попал на собеседование в компанию, приложением которой я пользовался, и оно мне нравилось. Я понятия не имел, как там все устроено в техническом плане. Релевантного опыта тоже не было в этом бизнес направлении. После технической части, я думал, что провалил интервью и на эту позицию компания будет искать разработчика дальше. Но когда дело дошло до моих вопросов (я подготовил их заранее, что рекомендую делать всегда) диалог пошел намного бодрее, я смог продемонстрировать, что мне интересно, как я могу улучшить то, чем уже пользуюсь и люблю. Подсветил вопросы со стороны клиента и мобильного разработчика и даже некоторыми вопросами поставил в тупик интервьюеров. Я думаю, это сыграло ключевую роль при найме меня и я тоже, с радостью, согласился пойти работать в эту компанию.
Что еще важно продемонстрировать на интервью?
Рассуждения вслух. Телепатов среди нас нет, а вот умение переносить поток мыслей в поток вербальности - хороший навык. Любой, кто проводит собеседования обращает на это внимание.
Не сдаваться. Если не знаете, как ответить на вопрос или решить задачу, продолжайте набрасывать идеи и предлагать разные подходы. Важно осознавать, что в современных реалиях вся работа - командная, поэтому не обязательно вывозить все на своих плечах. Грамотный интервьюер всегда направит вас в нужное русло, чтобы вместе прийти к успешному
#interview #random #it
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍5❤1👏1🤡1🤣1
Method dispatch
Про то, как устроена диспетчеризация методов в Swift написано не мало, поэтому я не хочу повторяться в пересказе. Детально погрузиться или повторить все аспекты, предлагаю за просмотром видео Swift Mehtod Dispatch. Статей, где подробно объясняется зачем и почему в Swift сосуществуют различные типы нахождения и вызовов методом предостаточно, например, вот. Вообще говоря, большого прикладного применения я в этом не вижу, но понимать базово все же стоит.
Разберем несколько "tricky" примеров-вопросов с собеседований, которые могут действительно застать врасплох.
На первом скрине, у нас есть вызов метода сначала у структуры, а затем у структуры приведенной к протоколу. В случае если метод определен только в расширении протокола, мы получим ответы:
// In Struct
// In Protocol
Будет использована Static dispatch для метода из расширения протокола.
Если же мы добавим метод и в объявление протокола, то будет применен Witness table (скрин 2) и ответ станет:
// In Struct
// In Struct
На третьем скрине ситуация посложнее. Метод определен в протоколе и в его расширении. Есть класс B, который реализует протокол, но не перегружает метод из него. И есть класс С потомок класса B и переопределенный метод из протокола P. При вызове метода у класса С приведенного к протоколу, логично предполагать, что будет вызван переопределенный метод из класса С, но мы получаем вызов метода из расширения протокола 🤯.
Баг открыт много лет и пока не был поправлен. Собственно, как можно его закостылись смотреть там же)
#ios #swift #interview
Про то, как устроена диспетчеризация методов в Swift написано не мало, поэтому я не хочу повторяться в пересказе. Детально погрузиться или повторить все аспекты, предлагаю за просмотром видео Swift Mehtod Dispatch. Статей, где подробно объясняется зачем и почему в Swift сосуществуют различные типы нахождения и вызовов методом предостаточно, например, вот. Вообще говоря, большого прикладного применения я в этом не вижу, но понимать базово все же стоит.
Разберем несколько "tricky" примеров-вопросов с собеседований, которые могут действительно застать врасплох.
На первом скрине, у нас есть вызов метода сначала у структуры, а затем у структуры приведенной к протоколу. В случае если метод определен только в расширении протокола, мы получим ответы:
// In Struct
// In Protocol
Будет использована Static dispatch для метода из расширения протокола.
Если же мы добавим метод и в объявление протокола, то будет применен Witness table (скрин 2) и ответ станет:
// In Struct
// In Struct
На третьем скрине ситуация посложнее. Метод определен в протоколе и в его расширении. Есть класс B, который реализует протокол, но не перегружает метод из него. И есть класс С потомок класса B и переопределенный метод из протокола P. При вызове метода у класса С приведенного к протоколу, логично предполагать, что будет вызван переопределенный метод из класса С, но мы получаем вызов метода из расширения протокола 🤯.
Баг открыт много лет и пока не был поправлен. Собственно, как можно его закостылись смотреть там же)
#ios #swift #interview
🔥7👍4👏2🤡2
Salary negotiation 🤑
Тейки на тему "деньги не главное" мне не нравятся. Мы продаем свои навыки и время - наш главный невозобновляемый ресурс. Стремление зарабатывать больше и получать дополнительные перки для меня естественное. Это не означает, что при выборе работы это должен быть основополагающий аспект и на остальные пункты обращать внимание не стоит. Также, вполне нормально, заниматься какой-то деятельностью бесплатно как хобби, волонтерство, искусство и тд.
Получив оффер на новую работу, зачастую, кандидаты сразу соглашаются, что несомненно, на руку работодателю. На самом деле практически всегда есть место для торгов и переговоров. Никогда не слышал, чтобы оффер отзывали после того, как кандидат попросил больше. Не стоит стесняться и боятся этого.
Я недавно для себя открыл, что есть сайты и даже курсы, которые могут в этом помочь, на разных условиях. До этого я встречал только посты и упоминания в книгах.
🪙 10 правил переговоров о зарплате. Стоит всегда держать в голове.
💸 Level.fyi - можно узнать сколько платят известные компании своим сотрудникам на разных должностях. Полезно, когда вы ищите работу на новом для себя рынке. В том числе, предоставляет сервис по зарплатным переговорам. Готовы сделать все за вас)
🤑 Rora - отдельный продукт, который уже помог более 1к сотрудников увеличить оффер в топ компании FAANG+
🤑 Курс - Если вы планируете сменить работу или увеличить свой заработок, оставаясь на текущей работе, этот курс прокачает вас в этом моменте.
Я не пользовался помощью платных сервисов, поэтому если у кого-то есть такой опыт напишите в комментариях. От себя точно могу рекомендовать -📕 Cracking the coding interview. Тема переговоров часто затрагивается в главах вступления.
#interview #random #thoughts
Тейки на тему "деньги не главное" мне не нравятся. Мы продаем свои навыки и время - наш главный невозобновляемый ресурс. Стремление зарабатывать больше и получать дополнительные перки для меня естественное. Это не означает, что при выборе работы это должен быть основополагающий аспект и на остальные пункты обращать внимание не стоит. Также, вполне нормально, заниматься какой-то деятельностью бесплатно как хобби, волонтерство, искусство и тд.
Получив оффер на новую работу, зачастую, кандидаты сразу соглашаются, что несомненно, на руку работодателю. На самом деле практически всегда есть место для торгов и переговоров. Никогда не слышал, чтобы оффер отзывали после того, как кандидат попросил больше. Не стоит стесняться и боятся этого.
Я недавно для себя открыл, что есть сайты и даже курсы, которые могут в этом помочь, на разных условиях. До этого я встречал только посты и упоминания в книгах.
💸 Level.fyi - можно узнать сколько платят известные компании своим сотрудникам на разных должностях. Полезно, когда вы ищите работу на новом для себя рынке. В том числе, предоставляет сервис по зарплатным переговорам. Готовы сделать все за вас)
Я не пользовался помощью платных сервисов, поэтому если у кого-то есть такой опыт напишите в комментариях. От себя точно могу рекомендовать -📕 Cracking the coding interview. Тема переговоров часто затрагивается в главах вступления.
#interview #random #thoughts
Please open Telegram to view this post
VIEW IN TELEGRAM
haseeb qureshi
Ten Rules for Negotiating a Job Offer
When the story of how I landed a job at Airbnb went viral, I was surprised at how infatuated people were with my negotiations. Media stories portrayed me as some kind of master negotiator—a wily ex...
👍15🔥5❤2😱1
Swift for Algorithm 👌
Swift - классный язык программирования, но он не очень удобен при решения алгоритмических задач на собеседованиях. Я не владею, на должном уровне, другими языками, поэтому выбора нет.
На алгоритмических секциях отводится ограниченное количество времени на решение задачи, обычно 30-50 минут, за это время нужно понять что от тебя хотят, придумать решение и написать его. Поэтому экономить приходится каждую минуту.
Хочу обратить внимание на несколько хаков, которые помогли мне ускорить и повысить качество решений на интервью в такие компании, как Yandex, Bloomberg и AliExpress.
1. Работа со строками
В Swift это какая-то мутота. Мы не можем спокойно обратиться по порядковому номеру символа в строке и получить объект типа Character. Нужно создавать объект типа String.Index и работать с ним.
⛔️
let myString = "Hello, Swift!"
let index = myString.index(myString.startIndex, offsetBy: 7)
let characterAtIndex = myString[index]
print(characterAtIndex) // "S"
Мне больше нравится работать со строкой, как обычным массивом. У меня это получается лаконичней и быстрее. Но уточните насколько критично для решения выделение доп памяти под новый массив. Например, на собеседовании в Яндексе такой прием был допустим и интервьюер согласился, что работа со строками не сильно место в Swift)
❇️
let collectionOfCharacters = Array(myString)
let characterAtIndex = collectionOfCharacters[7]
print(characterAtIndex) // "S"
2. Сложность стандартных операций
Системные методы могут работать не так, как мы предполагаем. Был случай, что я неправильно оценил сложность алгоритма, потому что не учел сложность метода removeAll у коллекций. В документации сказано, она О(n) я подумал, что константная. ⛔️
❇️ array = [] - решает проблему выше.
3. Сигнатура метода
Обычно алгоритмические задачи предполагают написание одного метода. Прежде чем ее решать нужно выяснить все требования. Часть из них можно поместить сразу в параметры (при условии, что вы пишите все с чистого листа без шаблона, как на LeetCode).
Допустим в задаче есть двумерный массив, тогда метод может выглядеть следующим образом:
⛔️
func testMethod(array: [[Int]]) -> Int {
let n = array.count
let m = array[0].count
...
}
Но можно лучше и вам уже не придется высчитывать границы этого массива:
❇️
func testMethod(array: [[Int]], n: Int, m: Int) -> Int { … }
На первый взгляд мелочь, но когда у вас жесткий дедлай и волнение, даже в таких мелочах можно лажануть)
4. Функции высшего порядка
Ну это база. Допустим есть массив целых чисел, нужно найти сумму всех элементов.
var numbers = [0, 1, 2, 3]
⛔️
var sum = 0
for number in numbers {
sum += number
}
print(sum)
❇️
let sumFast = numbers.reduce(0, +)
print(sumFast)
Кода меньше, пишется быстрее - профит. Map, filter, compactMap, reduce и forEach пригодятся в 80% задач на собесах.
5. Работа со словарем
Первый вариант стремный, второй православный. Тут даже не обсуждается.
var dict: [Int: Int] = [:]
⛔️
if dict[0] != nil {
dict[0]! += 1
}
❇️
dict[0, default: 0] += 1
P.S. Если интересно узнать больше об алгоритмах и собеседованих - ставьте лайки. Расскажу, как я готовился и получил предложение о работе на One day offer в Яндексе.
#swift #interview #algorithm
Swift - классный язык программирования, но он не очень удобен при решения алгоритмических задач на собеседованиях. Я не владею, на должном уровне, другими языками, поэтому выбора нет.
На алгоритмических секциях отводится ограниченное количество времени на решение задачи, обычно 30-50 минут, за это время нужно понять что от тебя хотят, придумать решение и написать его. Поэтому экономить приходится каждую минуту.
Хочу обратить внимание на несколько хаков, которые помогли мне ускорить и повысить качество решений на интервью в такие компании, как Yandex, Bloomberg и AliExpress.
1. Работа со строками
В Swift это какая-то мутота. Мы не можем спокойно обратиться по порядковому номеру символа в строке и получить объект типа Character. Нужно создавать объект типа String.Index и работать с ним.
⛔️
let myString = "Hello, Swift!"
let index = myString.index(myString.startIndex, offsetBy: 7)
let characterAtIndex = myString[index]
print(characterAtIndex) // "S"
Мне больше нравится работать со строкой, как обычным массивом. У меня это получается лаконичней и быстрее. Но уточните насколько критично для решения выделение доп памяти под новый массив. Например, на собеседовании в Яндексе такой прием был допустим и интервьюер согласился, что работа со строками не сильно место в Swift)
❇️
let collectionOfCharacters = Array(myString)
let characterAtIndex = collectionOfCharacters[7]
print(characterAtIndex) // "S"
2. Сложность стандартных операций
Системные методы могут работать не так, как мы предполагаем. Был случай, что я неправильно оценил сложность алгоритма, потому что не учел сложность метода removeAll у коллекций. В документации сказано, она О(n) я подумал, что константная. ⛔️
❇️ array = [] - решает проблему выше.
3. Сигнатура метода
Обычно алгоритмические задачи предполагают написание одного метода. Прежде чем ее решать нужно выяснить все требования. Часть из них можно поместить сразу в параметры (при условии, что вы пишите все с чистого листа без шаблона, как на LeetCode).
Допустим в задаче есть двумерный массив, тогда метод может выглядеть следующим образом:
⛔️
func testMethod(array: [[Int]]) -> Int {
let n = array.count
let m = array[0].count
...
}
Но можно лучше и вам уже не придется высчитывать границы этого массива:
❇️
func testMethod(array: [[Int]], n: Int, m: Int) -> Int { … }
На первый взгляд мелочь, но когда у вас жесткий дедлай и волнение, даже в таких мелочах можно лажануть)
4. Функции высшего порядка
Ну это база. Допустим есть массив целых чисел, нужно найти сумму всех элементов.
var numbers = [0, 1, 2, 3]
⛔️
var sum = 0
for number in numbers {
sum += number
}
print(sum)
❇️
let sumFast = numbers.reduce(0, +)
print(sumFast)
Кода меньше, пишется быстрее - профит. Map, filter, compactMap, reduce и forEach пригодятся в 80% задач на собесах.
5. Работа со словарем
Первый вариант стремный, второй православный. Тут даже не обсуждается.
var dict: [Int: Int] = [:]
⛔️
if dict[0] != nil {
dict[0]! += 1
}
❇️
dict[0, default: 0] += 1
P.S. Если интересно узнать больше об алгоритмах и собеседованих - ставьте лайки. Расскажу, как я готовился и получил предложение о работе на One day offer в Яндексе.
#swift #interview #algorithm
Please open Telegram to view this post
VIEW IN TELEGRAM
👍33🔥7❤5❤🔥2👏2
Как One Day Offer в Yandex стал One Month Offer 🤡
One Day Offer - это когда вам обещают провести процесс отбора в компанию быстро и в случае успеха сделать оффер за 1-2 дня.
На собесе в Яндексе я уже бывал однажды, но оподливился и больше не совался.
Несколько месяцев назад я порешивал задачи на Leetcode, и тут мне пришло письмо попробоваться в Яндекс. Без каких-то серьезных намерений, я решил проверить свои силы в бою.
Первый этап
Отборочный тур на платформе Yandex.Contest. Проходил за неделю до основного этапа, что как бы намекает на долгий процесс.
Платформа от Яндекса максимально неудобная. Вы должны использовать стандартные методы для ввода/вывода в консоль, чтобы заполнить модели из командной строки и вывести результат. Кто-то вообще делал такой треш на Swift?
Два из трех задания были, на мой взгляд, адекватными для позиции iOS разработчика. Третье, для прохождения всех тестовых условий, требовало сложный алгоритм. Классический BFS не был достаточно оптимальным. Все ли разработчики могут его написать? Сомневаюсь. Конечно, это остается на усмотрение организаторов, но я считаю ту мач.
Второй этап
Если вы набираете достаточно количество баллов, то вам ставят 2 этапа в субботу на 1ч каждый. Первая встреча предполагала решения двух небольших задач на проектирование фичи, по 30 минут на каждую - System Design на минималках. Не буду сливать прям точь-в-точь, но это достаточно классические задания на интервью. Например: “Спроектируй модуль, который отвечает за поиск с подсказками при вводе запроса”. Необходимо выяснить требования, ограничения и предложить решение. Сразу писать код не нужно, можно просто порассуждать и назвать плюсы/минусы такого решения. Потом можно накидать протоколов/классов/методов и углубится в реализацию при необходимости.
Третий этап
Достаточно классическая задача на строки. По ощущениям Leetcode medium. Решение было в лоб и не требовало специфичного алгоритма. В комменты закину список материалов, которые рекомендуют рекрутеры для подготовки.
Вечером мне написали, что все классно и я хорошо справился, но на финал команды позвать не готовы, потому что ищут мидлов) Через несколько дней ко мне вернулся рекрутер и сказал, что появились подходящие позиции, но нужно пройти еще один технический этап перед финалом.
Четвертый этап
Проводила команда Яндекс.Маркет. Длительность 1.5ч. Начали с решения алгоритмической задачи, опять попалась на строки и тоже среднего уровня. Потом интервьюер давал примеры кода, в которых нужно было что-то поправить или просто ответить на вопросы. Последняя задача подразумевала проектирование модуля для работы с логами и требовала хорошего понимания, как использовать дженерики в Swift.
Было задание, где фигурировал
Пятый этап
Через несколько дней рекрутер предложил пообщаться с руководителями из двух команд. Это финальные собеседования, без технических заданий. Я рассказал о себе, а мне презентовали продукт и команду. Обе команды были готовы сделать мне оффер, осталось только выбрать в какую из них я хотел бы пойти.
Я выбрал позицию в команде, которая предполагала, что я смогу нанимать и лидить команду. На согласование оффера ушло больше недели, а все наше общение и прохождение пяти этапов растянулось больше чем на месяц. Так One Day Offer превратился в One Month Offer 😄
Яндекс не смог предложить те условия, на которые я рассчитывал, но были готовы продолжить общение и попробовать договорится о более высоком вознаграждении или должности. Это не входило в мои планы, поэтому я отказался.
Позиция, на которую был оффер, предполагала переезд в Белград, как альтернативу можно было выбрать Армению и Казахстан.
Норм ли такой хайринг флоу или напряжно?
#interview #yandex
One Day Offer - это когда вам обещают провести процесс отбора в компанию быстро и в случае успеха сделать оффер за 1-2 дня.
На собесе в Яндексе я уже бывал однажды, но оподливился и больше не совался.
Несколько месяцев назад я порешивал задачи на Leetcode, и тут мне пришло письмо попробоваться в Яндекс. Без каких-то серьезных намерений, я решил проверить свои силы в бою.
Первый этап
Отборочный тур на платформе Yandex.Contest. Проходил за неделю до основного этапа, что как бы намекает на долгий процесс.
Платформа от Яндекса максимально неудобная. Вы должны использовать стандартные методы для ввода/вывода в консоль, чтобы заполнить модели из командной строки и вывести результат. Кто-то вообще делал такой треш на Swift?
let N = Int(readLine()!)!
var graph: [Int: [Int: Bool]] = [:]
for _ in 0..<N {
let line = readLine()!.split(separator: " ").map { Int($0)! }
let A = line[0]
let B = line[1]
graph[A, default: [:]][B] = true
}
Два из трех задания были, на мой взгляд, адекватными для позиции iOS разработчика. Третье, для прохождения всех тестовых условий, требовало сложный алгоритм. Классический BFS не был достаточно оптимальным. Все ли разработчики могут его написать? Сомневаюсь. Конечно, это остается на усмотрение организаторов, но я считаю ту мач.
Второй этап
Если вы набираете достаточно количество баллов, то вам ставят 2 этапа в субботу на 1ч каждый. Первая встреча предполагала решения двух небольших задач на проектирование фичи, по 30 минут на каждую - System Design на минималках. Не буду сливать прям точь-в-точь, но это достаточно классические задания на интервью. Например: “Спроектируй модуль, который отвечает за поиск с подсказками при вводе запроса”. Необходимо выяснить требования, ограничения и предложить решение. Сразу писать код не нужно, можно просто порассуждать и назвать плюсы/минусы такого решения. Потом можно накидать протоколов/классов/методов и углубится в реализацию при необходимости.
Третий этап
Достаточно классическая задача на строки. По ощущениям Leetcode medium. Решение было в лоб и не требовало специфичного алгоритма. В комменты закину список материалов, которые рекомендуют рекрутеры для подготовки.
Вечером мне написали, что все классно и я хорошо справился, но на финал команды позвать не готовы, потому что ищут мидлов) Через несколько дней ко мне вернулся рекрутер и сказал, что появились подходящие позиции, но нужно пройти еще один технический этап перед финалом.
Четвертый этап
Проводила команда Яндекс.Маркет. Длительность 1.5ч. Начали с решения алгоритмической задачи, опять попалась на строки и тоже среднего уровня. Потом интервьюер давал примеры кода, в которых нужно было что-то поправить или просто ответить на вопросы. Последняя задача подразумевала проектирование модуля для работы с логами и требовала хорошего понимания, как использовать дженерики в Swift.
Было задание, где фигурировал
DispatchQueue.main.sync и интервьюер пытался меня убедить, что он всегда приводит к deadlock. Помните, что это не так)Пятый этап
Через несколько дней рекрутер предложил пообщаться с руководителями из двух команд. Это финальные собеседования, без технических заданий. Я рассказал о себе, а мне презентовали продукт и команду. Обе команды были готовы сделать мне оффер, осталось только выбрать в какую из них я хотел бы пойти.
Я выбрал позицию в команде, которая предполагала, что я смогу нанимать и лидить команду. На согласование оффера ушло больше недели, а все наше общение и прохождение пяти этапов растянулось больше чем на месяц. Так One Day Offer превратился в One Month Offer 😄
Яндекс не смог предложить те условия, на которые я рассчитывал, но были готовы продолжить общение и попробовать договорится о более высоком вознаграждении или должности. Это не входило в мои планы, поэтому я отказался.
Позиция, на которую был оффер, предполагала переезд в Белград, как альтернативу можно было выбрать Армению и Казахстан.
Норм ли такой хайринг флоу или напряжно?
#interview #yandex
🤡19🔥10❤2👍2👏2
System Design interview для мобильщика
Давно не было постов в канал, был занят переездом и энергии для творчества не хватало) Пора бы это исправить. Я уже писал об алгоритмических и поведенческих секциях в крупных компания на интервью. На позиции младших разработчиков редко достается этап по системному дизайну (System design), а на сеньера и выше почти всегда.
Из своего опыта могу сказать, что в том или ином виде он может встретиться не только в FAANG. Даже маленькие и средние компании хотят проверить навыки в проектировании систем. Верхнеуровнево задача может звучать: “Как бы ты сделал Instagram” или “Давай спроектируем месенджер”. И в такой формулировке много вероятных сценариев развития диалога с собеседующим. Задача может быть и с меньшим уровнем неопределенности “Реализуй модуль для загрузки фотографий”.
Как бы не стояла задача, к ним можно и нужно подготовиться. Хочу порекомендовать мой топ материалов.
✅ Туториал, который научит решать комплексные задачи на проектирование уровня FAANG-interview. Есть разборы популярных вопросов в письменном виде и записи на YouTube
✅ Канал AndreyTech нравится подача и нет сомнений в опыте и экспертизе автора. 3 года лидил в Meta, сейчас тим лид в Bloomberg. Более того, Андрей был моим руководителем в МТС)
✅ Обычно для решения задачи отводится от 40 до 60 минут. Терять время на то, чтобы освоить новый интерфейс какого-то графического редактора слишком дорого. Лучше сделать это заранее и потренироваться в рисовании графиков и схем. Мой фаворит - excalidraw
✅ На литкоде можно найти отдельные курсы (не входят в основую подписку) и подборки задач без классических алгоритмов, а именно на проектирование классов/модулей. Например можно выбрать задачи, которые попадались на собеседовании в Google
Дальше я хочу окунуться глубже в некоторые темы касательно system design для мобильных разработчиков.
PS. Новости из туманного альбиона и мои впечатления от жизни в Лондоне в следующих постах.
#interview #lookingforjob #development
Давно не было постов в канал, был занят переездом и энергии для творчества не хватало) Пора бы это исправить. Я уже писал об алгоритмических и поведенческих секциях в крупных компания на интервью. На позиции младших разработчиков редко достается этап по системному дизайну (System design), а на сеньера и выше почти всегда.
Из своего опыта могу сказать, что в том или ином виде он может встретиться не только в FAANG. Даже маленькие и средние компании хотят проверить навыки в проектировании систем. Верхнеуровнево задача может звучать: “Как бы ты сделал Instagram” или “Давай спроектируем месенджер”. И в такой формулировке много вероятных сценариев развития диалога с собеседующим. Задача может быть и с меньшим уровнем неопределенности “Реализуй модуль для загрузки фотографий”.
Как бы не стояла задача, к ним можно и нужно подготовиться. Хочу порекомендовать мой топ материалов.
Дальше я хочу окунуться глубже в некоторые темы касательно system design для мобильных разработчиков.
PS. Новости из туманного альбиона и мои впечатления от жизни в Лондоне в следующих постах.
#interview #lookingforjob #development
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - weeeBox/mobile-system-design: A simple framework for mobile system design interviews
A simple framework for mobile system design interviews - weeeBox/mobile-system-design
🔥16👍5❤3
Четвертое интервью. Классическое поведенческое интервью. На мой взгляд, хорошо пообщались, получилось узнать много о команде, проекте и задачах. Вопросы для меня были стандартные, к которым можно легко подготовить хорошие кейсы. Для подготовки смотрел видео на Youtube и прошел курс. Сложно выделить чего то интересного из этого интервью. Главный вывод - учите английский язык, если ставите себе цель работать в международной компании, и учитесь себя продавать как специалиста.
Спустя неделю я получил приглашение забронировать звонок с моим эйчаром, и он сообщил, что к сожалению “мы сделали выбор в пользу другого кандидата”. Он смог дать фидбек, который подтвердил мои ощущения от интервью. С первым этапом я справился не очень, а остальные были вполне достойными.
Для себя сделал несколько выводов из этого процесса:
- В Google работают такие же люди с такими же проблемами. Девушка-интервьюер на третьем этапе нервничала больше меня. Общение на всех этапах было очень приятное, никаких гиков и роботов я не встретил)
- Подготовка решает. Уже не для кого не секрет, что прохождение интервью-это навык. Интервью в FAANG-сложный, но детерминированный процесс. В свободном доступе есть куча хороших ресурсов для подготовки. Осталось найти время и самое главное - мотивацию.
- На рынке сейчас очень высокая конкуренция. Тот уровень знаний и умений, которого было достаточно несколько лет назад, сегодня не хватает. Права на ошибку практически нет, иначе наймут другого, кто готовился по 10 часов в день не разгибаясь.
- Работа в Google - это все еще работа. Не нужно ее идеализировать. Рутина, легаси, выгорание, лэйоффы - в наличии весь букет. В вашим мире не появятся розовые пони или горы золота после трудоустройства.
- Получать реджекты не страшно совсем. Главное - научиться к этому относиться спокойно и по-философски извлекать опыт. Ведь всегда можно попробовать еще раз. Но для себя пока не решил, нужно ли мне это?
Если у вас есть интересный опыт собесов, делитесь в комментариях. Если вам нравятся посты на такие темы, накидайте реакций, и я расскажу о собеседованиях в другие компании.
#interview #experience #Google
Спустя неделю я получил приглашение забронировать звонок с моим эйчаром, и он сообщил, что к сожалению “мы сделали выбор в пользу другого кандидата”. Он смог дать фидбек, который подтвердил мои ощущения от интервью. С первым этапом я справился не очень, а остальные были вполне достойными.
Для себя сделал несколько выводов из этого процесса:
- В Google работают такие же люди с такими же проблемами. Девушка-интервьюер на третьем этапе нервничала больше меня. Общение на всех этапах было очень приятное, никаких гиков и роботов я не встретил)
- Подготовка решает. Уже не для кого не секрет, что прохождение интервью-это навык. Интервью в FAANG-сложный, но детерминированный процесс. В свободном доступе есть куча хороших ресурсов для подготовки. Осталось найти время и самое главное - мотивацию.
- На рынке сейчас очень высокая конкуренция. Тот уровень знаний и умений, которого было достаточно несколько лет назад, сегодня не хватает. Права на ошибку практически нет, иначе наймут другого, кто готовился по 10 часов в день не разгибаясь.
- Работа в Google - это все еще работа. Не нужно ее идеализировать. Рутина, легаси, выгорание, лэйоффы - в наличии весь букет. В вашим мире не появятся розовые пони или горы золота после трудоустройства.
- Получать реджекты не страшно совсем. Главное - научиться к этому относиться спокойно и по-философски извлекать опыт. Ведь всегда можно попробовать еще раз. Но для себя пока не решил, нужно ли мне это?
Если у вас есть интересный опыт собесов, делитесь в комментариях. Если вам нравятся посты на такие темы, накидайте реакций, и я расскажу о собеседованиях в другие компании.
#interview #experience #Google
Leetcode
Explore - LeetCode
LeetCode Explore is the best place for everyone to start practicing and learning on LeetCode. No matter if you are a beginner or a master, there are always new topics waiting for you to explore.
👍19🔥17❤2🤯1🤡1
Теоретическое vs Практическое интервью ⁉️
Я сразу скажу, что отдаю предпочтение практическим aka live coding интервью. Мне нравится задавать теоретический вопрос и сразу же валидировать его практическим применением.
Расскажу, почему я считаю это более эффективным способом проверки уровня кандидата.
❇️ На стандартные вопросы 9 из 10 человек отвечают одинаково cловами и даже фразами прямиком из учебников по программированию. Не особо интересно слушать такие заученные пересказы, на практике эти знания может применить 1 из 10 человек)
❇️ Сложные теоретические вопросы или точечные тоже не имеют смысла. Если вопрос посвящен теме, с которой вы вряд ли столкнетесь в реальном проекте, то этот вопрос можно было бы и не озвучивать.
❇️ После собеседования интервьюер должен дать оценку кандидату. Разглагольствования на тему “какую базу кандидат не знал” чаще встречаются, когда нет четких требований к ответам. С практическими задачами проще. Если решение рабочее, то и оценка будет объективной.
❇️ После live coding’a остаются эвиденсы с решением, пусть и не рабочим. Гораздо легче вернуться к этому черновику, чем вспоминать устные ответы.
❇️ Теория может быть оторвана от реальных задач программиста. Суть разработки - в проектировании решения и написании кода, а не в философских рассуждениях, почему Apple сделала ARC, а не Garbage Collector? Давайте оставим эти дилеммы университетам. В продуктовой разработке нужны совершенно другие качества.
Для тех, кто хочет с легкостью справляться с практическими задачами, выложил второй урок. В нем разобраны вопросы по функциональному программированию из таких компаний, как Yandex, Qiwi, Capital One.
Для обсуждения добавляйтесь в телеграм чат. Он поможет вам в более качественной проработке материала и даст возможность задавать любые вопросы.
P.S Буду в Тбилиси с 10 по 15 марта, если кто-то хочет встретиться - пишите.
#interview #livecoding #course
Я сразу скажу, что отдаю предпочтение практическим aka live coding интервью. Мне нравится задавать теоретический вопрос и сразу же валидировать его практическим применением.
Расскажу, почему я считаю это более эффективным способом проверки уровня кандидата.
❇️ На стандартные вопросы 9 из 10 человек отвечают одинаково cловами и даже фразами прямиком из учебников по программированию. Не особо интересно слушать такие заученные пересказы, на практике эти знания может применить 1 из 10 человек)
❇️ Сложные теоретические вопросы или точечные тоже не имеют смысла. Если вопрос посвящен теме, с которой вы вряд ли столкнетесь в реальном проекте, то этот вопрос можно было бы и не озвучивать.
❇️ После собеседования интервьюер должен дать оценку кандидату. Разглагольствования на тему “какую базу кандидат не знал” чаще встречаются, когда нет четких требований к ответам. С практическими задачами проще. Если решение рабочее, то и оценка будет объективной.
❇️ После live coding’a остаются эвиденсы с решением, пусть и не рабочим. Гораздо легче вернуться к этому черновику, чем вспоминать устные ответы.
❇️ Теория может быть оторвана от реальных задач программиста. Суть разработки - в проектировании решения и написании кода, а не в философских рассуждениях, почему Apple сделала ARC, а не Garbage Collector? Давайте оставим эти дилеммы университетам. В продуктовой разработке нужны совершенно другие качества.
Для тех, кто хочет с легкостью справляться с практическими задачами, выложил второй урок. В нем разобраны вопросы по функциональному программированию из таких компаний, как Yandex, Qiwi, Capital One.
Для обсуждения добавляйтесь в телеграм чат. Он поможет вам в более качественной проработке материала и даст возможность задавать любые вопросы.
P.S Буду в Тбилиси с 10 по 15 марта, если кто-то хочет встретиться - пишите.
#interview #livecoding #course
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥4❤🔥3❤2
Два типа технических собеседований в IT
Часто в компаниях исповедуют два полярных подхода к найму.
Первый - спрашивать по стеку как теоретические так и практические вопросы и, соответственно, заранее понимать, куда нужен новый человек. Второй - искать разработчиков с “базой” в разработке ПО и нанимать в “пул”, т.е в общий набор, из которого людей выбирают команды, или сам новичок выбирает, куда было бы интересно пойти работать.
Второй подход выбирают в FAANG’e. Они ищут разработчиков-инженеров в широком смысле, поэтому проверяют умение писать алгоритмы, работать со структурами данных и проектировать фичи. Проще говоря, это задачи с Leetcode и систем дизайн. Количество этапов и грейд, на который вы целитесь, по сути определяется эйчаром по результатам скрининга и резюме. На технических этапах будут задания, соответствующие уровню. Все мои знакомые из Meta, Amazon и тд попадали на новый для себя стек. Почему именно так, можно узнать от Senior Staff developer из Netflix.
На мой взгляд, этот подход применять легко, т.к на LeetCode есть уже 2000+ задач и вам не нужно составлять их, а на секции по системному дизайну просто задать вопрос в стиле “Как бы ты задизайнил WhatsApp?”. Но если вы не FAANG, то такой способ найма работать не будет. Вам нужен профильный инженер со знанием стека, например, iOS и времени на то, что он будет перекатываться, у вас тоже нет. Поэтому, алгоритмы убираются и делаются профильные задачи.
Здесь возникает другая проблема. Такого же сервиса как LeetCode для задач на техсобесы по определенному стеку нет (звучит как стартап). Команда собирается и выстраивает свой процесс найма и оценки кандидата. Зачастую это live coding и проектирование фичей, приближенных к проблемам, с которыми столкнется новый разработчик, если попадет в команду. Но чтобы придумать хорошие задачи и протестировать их, уходит много времени. По итогу все компании используют одни и те же задачи, воруя друг у друга)
Особо отличившиеся, не буду называть кто именно, не меняли процесс найма два года! Хотя у них хайринг большой и непрерывный. Вне зависимости от уровня iOS разработчика они спрашивают одну и ту же задачу на проектирование нотификейшн центра. Предлагаю посмотреть, какие ответы я бы ожидал от кандидатов с различным опытом работы и заявленным грейдом.
#interview #iosdevelopment
Часто в компаниях исповедуют два полярных подхода к найму.
Первый - спрашивать по стеку как теоретические так и практические вопросы и, соответственно, заранее понимать, куда нужен новый человек. Второй - искать разработчиков с “базой” в разработке ПО и нанимать в “пул”, т.е в общий набор, из которого людей выбирают команды, или сам новичок выбирает, куда было бы интересно пойти работать.
Второй подход выбирают в FAANG’e. Они ищут разработчиков-инженеров в широком смысле, поэтому проверяют умение писать алгоритмы, работать со структурами данных и проектировать фичи. Проще говоря, это задачи с Leetcode и систем дизайн. Количество этапов и грейд, на который вы целитесь, по сути определяется эйчаром по результатам скрининга и резюме. На технических этапах будут задания, соответствующие уровню. Все мои знакомые из Meta, Amazon и тд попадали на новый для себя стек. Почему именно так, можно узнать от Senior Staff developer из Netflix.
На мой взгляд, этот подход применять легко, т.к на LeetCode есть уже 2000+ задач и вам не нужно составлять их, а на секции по системному дизайну просто задать вопрос в стиле “Как бы ты задизайнил WhatsApp?”. Но если вы не FAANG, то такой способ найма работать не будет. Вам нужен профильный инженер со знанием стека, например, iOS и времени на то, что он будет перекатываться, у вас тоже нет. Поэтому, алгоритмы убираются и делаются профильные задачи.
Здесь возникает другая проблема. Такого же сервиса как LeetCode для задач на техсобесы по определенному стеку нет (звучит как стартап). Команда собирается и выстраивает свой процесс найма и оценки кандидата. Зачастую это live coding и проектирование фичей, приближенных к проблемам, с которыми столкнется новый разработчик, если попадет в команду. Но чтобы придумать хорошие задачи и протестировать их, уходит много времени. По итогу все компании используют одни и те же задачи, воруя друг у друга)
Особо отличившиеся, не буду называть кто именно, не меняли процесс найма два года! Хотя у них хайринг большой и непрерывный. Вне зависимости от уровня iOS разработчика они спрашивают одну и ту же задачу на проектирование нотификейшн центра. Предлагаю посмотреть, какие ответы я бы ожидал от кандидатов с различным опытом работы и заявленным грейдом.
#interview #iosdevelopment
boosty.to
Шестой урок. Потокобезопасный нотификейшн центр. - Vadim Chistiakov | IT Community
Популярная задача на собеседованиях. Встречалась на интервью в AliExpress и Озон.
🔥8👍5❤4
Паровозик собеседований 🚂
Заметил возросшую активность вокруг такой практики на рынке поиска работы как паровозик собеседований.
Для тех, кто не в курсе, поясню. Собирается группа людей, которые ищут работу по одному стеку технологий, например, iOS разработчик. Затем они по очереди ходят на собеседования в одну и ту же компанию. Интервью записывают, чтобы потом вместе обсудить вопросы/ответы. Таким образом следующий кандидат осведомлен о процессе интервью и имеет больше шансов пройти его успешно.
Тема не новая, наряду с накруткой опыта или помощи через помощника-суфлера. Индусы давно пользуются, в России только набирает популярность.
Какие есть мысли на этот счет:
- Вряд ли кто-то из интервьюеров даст свое согласие на запись и дальнейшую публикацию. Поэтому, такие видео, очевидно, выкладываются без их разрешения;
- Компании могут обидеться, если спалят и отказать кандидату в независимости от того, как он прошел интервью. Будет ли это просто отказ или долгосрочный бан в конкретной компании, вопрос;
- Сталкивался с практикой подписки NDA перед интервью. В таком случае, компания точно не горит желанием, чтобы собес с ней слили. Что может быть за слив в рамках этого соглашения не знаю, скорее, в суд никто не пойдет, просто тоже бан;
- Те, кто получит работу таким способом, с бОльшей вероятностью могут столкнуться с синдромом самозванца. Придется раскошелиться на психолога.
- Те кто записывают видео и выкладывают в паблик ставят себя под удар, те кто просто смотрят - ни чем не рискуют
Не хочу примерять на себя «белое пальто», но мне кажется, что, в основном, это морально-этический вопрос, также как с накруткой опыта или использованием помощников на интервью. Некоторые считают, что это нечестный способ получить работу и некий абьюз найма.
В мои планы не входит отменять, осуждать или мешать людям это делать, это их выбор. Также в планах нет выкладывать свои интервью в паблик. Мне интереснее иначе расти и развиваться и помогать это делать другим.
Хочется лишь узнать мнения всех сторон, кандидатов, эйчаров и нанимающих менеджеров. Что думаете насчет такой практики? Это эффективный способ получить оффер или мошенническая схема? Повлияет ли это на процессы найма в будущем, если да, то как?
Жду ваших конструктивных мыслей и оценок по этим вопросам)
Оставлю анонимный опрос ниже.
#interview
Заметил возросшую активность вокруг такой практики на рынке поиска работы как паровозик собеседований.
Для тех, кто не в курсе, поясню. Собирается группа людей, которые ищут работу по одному стеку технологий, например, iOS разработчик. Затем они по очереди ходят на собеседования в одну и ту же компанию. Интервью записывают, чтобы потом вместе обсудить вопросы/ответы. Таким образом следующий кандидат осведомлен о процессе интервью и имеет больше шансов пройти его успешно.
Тема не новая, наряду с накруткой опыта или помощи через помощника-суфлера. Индусы давно пользуются, в России только набирает популярность.
Какие есть мысли на этот счет:
- Вряд ли кто-то из интервьюеров даст свое согласие на запись и дальнейшую публикацию. Поэтому, такие видео, очевидно, выкладываются без их разрешения;
- Компании могут обидеться, если спалят и отказать кандидату в независимости от того, как он прошел интервью. Будет ли это просто отказ или долгосрочный бан в конкретной компании, вопрос;
- Сталкивался с практикой подписки NDA перед интервью. В таком случае, компания точно не горит желанием, чтобы собес с ней слили. Что может быть за слив в рамках этого соглашения не знаю, скорее, в суд никто не пойдет, просто тоже бан;
- Те, кто получит работу таким способом, с бОльшей вероятностью могут столкнуться с синдромом самозванца. Придется раскошелиться на психолога.
- Те кто записывают видео и выкладывают в паблик ставят себя под удар, те кто просто смотрят - ни чем не рискуют
Не хочу примерять на себя «белое пальто», но мне кажется, что, в основном, это морально-этический вопрос, также как с накруткой опыта или использованием помощников на интервью. Некоторые считают, что это нечестный способ получить работу и некий абьюз найма.
В мои планы не входит отменять, осуждать или мешать людям это делать, это их выбор. Также в планах нет выкладывать свои интервью в паблик. Мне интереснее иначе расти и развиваться и помогать это делать другим.
Хочется лишь узнать мнения всех сторон, кандидатов, эйчаров и нанимающих менеджеров. Что думаете насчет такой практики? Это эффективный способ получить оффер или мошенническая схема? Повлияет ли это на процессы найма в будущем, если да, то как?
Жду ваших конструктивных мыслей и оценок по этим вопросам)
Оставлю анонимный опрос ниже.
#interview
👍7🔥4😁2💯2🤔1