Зависит от компании и позиции на которую вы претендуете.
В большинстве случаев по алгоритмам не спросят ничего, что не было в университетском курсе или в среднем по направлению не принято знать.
Тут куча негатива было просто за сам факт вопросов по алгоритмам, хотя в целом это стандарт знаний в профессии.
Будем честны, обойтись без Xcode в процессе изучения Swift нельзя. Но ни в официальной документации, ни в большинстве онлайн-курсов (по личному опыту говорю) не рассказывается о контроле версий и о подходах к нему. Я рад, что вы знаете о системах контроля версий. Но для многих новичков это что-то далекое и непонятное, освоение чего, на их взгляд, можно отложить на потом.
Они правы, это можно отложить на потом. К iOS разработке как таковой это имеет опосредованное отношение.
Да и в заголовке не сказано, что речь про то, что нужно новичку в первую очередь изучить. Заголовок говорит о том, что должен знать iOS разработчик.
Спасибо. Не спорю, в статье нет многих важных понятий. Буду рад, если в комментариях список продолжится.
В рамках такой статьи список будет бесконечным. Вы можете сразу всю документацию к Cocoa Touch фреймворку, к Swift и Objective-C сюда перенести. А еще можно копнуть в паттерны, архитектуры, алгоритмы и структуры данных. Можно CI/CD копнуть. Можно напомнить про SOLID, про DI. Можно пойти по известным фреймворкам (хотя у вас уже про RX есть, а про Swinject, Alamofire, Realm — нет).
Есть базовые знания, базовые конструкты, которые плюс-минус одинаковы в большинстве языков. К ним можно отнести массивы, перечисления, кортежи и словари (хотя уже с оговорками), дженерики тоже. Но это база, которая затрагивается абсолютно в любых источниках, по которым изучают ЯП – будь то Swift, C++, Java, или (почти) любой другой. Особенности работы с протоколами, равно как и упрощения в синтаксисе замыканий, не относятся к настолько базовым знаниям, как приведения типов или алгоритмы сортировки. По крайней мере, на мой взгляд (и, кажется, на взгляд автора).
Так вы напишите, например, статью про особенности протоколов в Swift. В статье вообще никакой особенности протоколов нет. Интерфейсы/протоколы почти во всех языках есть. Замыкания/анонимные функции тоже почти везде есть. И те же массивы в Obj-C и Swift друг от друга отличаются и в других языках разница бывает.
А система контроля версий в других языках не используется? Для каких новичков статья в итоге то? У которых есть бекграунд других языков или нет?
Забавно, но быстрый поиск в гугле выдал примерно то же, что написано в этой части статьи – про скорость, типобезопасность, читаемость и т.д. Спасибо за информацию.
Так это все общие фразы, никакой конкретики. А вы копируете этот информационный мусор, который по сути ничего не говорит.
Думаю, по причине постоянного развития Swift автор и не стал упоминать про обратные отличия. Хотя это и дает однобокий взгляд на эти два языка, немалая часть проблем в Swift 3 (актуальной на момент публикации оригинальной статьи) решена к релизу пятой версии.
А немалая часть — не решена. Из статьи не видно, что вообще проблемы есть. Если брать третий свифт, то статья просто была вредной, т.к. человек мог выбрать глючную технологию и потерять из-за этого деньги/время.
Использование сторибордов ударяет не по производительности конечного приложения, а по скорости работы Xcode, а также по скорости разработки приложения: отсутствие реюзабилити и неудобность работы со Storyboards в команде (если честно, о последнем знаю только с чужих слов, но об этой проблеме указано и в статье, «Проблемы слияния возникают гораздо чаще...»). Не понимаю, что из этого является чушью.
Я про производительность ничего, вроде, не писал :) По скорости работы XCode бьют большие сториборды, но они сами по себе антипаттерн. Реюзабельности можно спокойно добиться с ними, если в них ничего не хардкодить. Проблем с конфликтами слияний с ними минимум (у меня большой опыт в этом плане), если соблюдать порядок в работе с системой контроля версий, выделять под разные цели разные сториборды, синхронизироваться по задачам в команде. Чтобы в сториборде была хорошая визуализация экрана (понятная дизайнеру), нужно дополнительно возиться, обычно, там визуально всякие прямоугольники накиданы.
Еще раз — это не проблемы. Настоящая проблема в том, что они не избавляют от необходимости писать код. Они по факту сокращают код на настройку констреентов (и то все равно руками придется с ними работать на чуть более сложных экранах), добавлении вьюх, на настройке сайз классов. В итоге: на простых экранах сториборды хорошо работают (но их и кодом сверстать просто), а на сложных экранах все равно придется верстку кодом настраивать и мы имеем дополнительный сложночитаемый ресурс с версткой. Вот поэтому в сложных проектах их не используют.
Прошу обратить внимание на тег «Swift 3». На момент публикации статьи SwiftUI не был анонсирован. Но прошу извинить, что не указал версию во вступлении, сейчас исправлюсь.
А я обратил внимание. Только что это меняет? Вот есть сегодняшний день и актуальные технологии и вы публикуете статью (хоть и перевод). Статья, вроде как, практическую ценность должна иметь именно на сегодняшний день. А тут, получается, неактуальная, неполная, несистематизированная информация.
Не сомневаюсь, что, начиная с уровня Middle, программисту будет сложно найти что-то полезное в этой статье. Однако она ориентирована сугубо на тех, кто начинает изучение Swift.
Мой поинт в том, что статья не будет полезна никому. Просто по отношению кол-ва знаков к практической ценности можно легко найти гораздо полезнее материал в гугле. Банально даже дока эпла и свифтбук, какой-нибудь. Приложения на iOS уже многие годы пишут, материала полно, как это делается. Ваша статья все-равно не отвечает толком на вопросы новичков.
Список ни о чем. Надо переименовать в «14 вещей в разработке для ios, про которые знает лично автор».
Системы контроля версий зачем-то приписаны. Ну ок, тогда точно нужен xcode, а еще нужен itunes connect. Можно еще инструменты вроде фастлейна, дженкинса, etc приписать — тоже ведь нужны.
Почему-то нужно знать геолокацию и локализацию, а про сетевые запросы нет.
Почему-то надо знать про протоколы и замыкания, а про дженерики не надо? А вывод типов надо или можно не знать? А про перечисления, кортежы, массивы, словари? ARC/MRC?
То что написано про разницу Swift и ObjC — это ни о чем. Эти языки различаются гораздо серьезнее. Хотя бы про рефлексию, наследование от NSObject/NSProxy, разницу value и reference типов написали бы (да и еще целая куча всего на самом деле). Некоторые вещи в свифте тупо нельзя сделать, хотя на обже они тривиальны. А еще со свифтом можно много удивительного словить, т.к. язык все еще активно меняется и на это будешь время тратить.
Про сториборды чушь написана. Можно хоть на каждый экран по сториборду сделать. Их проблема в том, что их читать в текстовом виде сложно, они почти не конфигурируются (нельзя задать отступы/цвета/шрифты в сториборде переменной, которые из конфига где-то сами вытащатся, надо это через код делать). Переходы между экранами тоже толком через сториборд не настроишь, придется код писать. В итоге плюсов от них в большом проекте остается мало, а ошибок может быть много.
Про SwiftUI ничего нет.
Надеюсь, эта статья была полезна!
Нет. В статье ничего полезного нет. Просто набор некоторых слов и терминов из ios разработки никак толком не раскрытых. Ни сама статья не нужна, ни, тем более, перевод.
Я ответил вполне конкретно в контексте обсуждаемого вопроса. Та конкретика, которую вы просите — ситуативная и плавает в зависимости от разных условий, а, следовательно, неадекватна в общем случае.
Мы:
1) Набираем людей разных уровней;
2) Набираем людей в разные команды с разными ответственностями;
3) Пытаемся говорить с кандидатом больше о том что он знает, а не знает. Не знает алгоритмы? Мы потратим час времени на другие вопросы;
4) Мы оцениваем разные качества кандидата в том числе и софт-скиллы.
Да успокойте себя уже :)
То, что мы спрашиваем на собеседованиях — мы делаем для решения конкретной производственной необходимости — найма людей. У нас нет целей кого-то оскорбить, своими знаниями похвастаться или что-то такое. Мы коллег будущих ищем.
А какую задачу вы сейчас решаете? Ищете возможность подковырнуть лично меня и потешить свое эго? Выглядит глупо и жалко, вне зависимости от того могу я ответить на ваш вопрос или нет.
Я уже ответил вам :)
На любую тему можно говорить сколько угодно.
У нас есть блоки вопросов по разным темам. Кандидаты либо знают о чем речь, либо нет. Это не тест и грамотных людей несложно отличить, они не пытаются скрывать знания.
Это сомнительная рекомендация. Я не припомню, чтобы хоть что-то из того, чем я пользуюсь на территории РФ не вызывало, скажем так, неоднозначных ощущений. :) Поэтому лучше считать, что я этим не пользуюсь вовсе.
Я ничего не рекомендовал. Вы дали ссылку на коммент, где про программный мусор писали. Нашим кодом пользуются, это не мусор.
А должно повысить? :) А для чего?
Вы же спрашивали для чего-то это. Я не знаю зачем.
Сейчас речь не о фильтрах в вашей конторе. Разговор с вами и фактически о ваших фильтрах. Вы ведь сейчас вашу фирму не представляете, верно?
Я описывал мое понимание фильтров в больших конторах.
Звучит солидно, конечно, но, что если в данном случае именно сознание определяет бытие? Иными словами, вы видите то, что сами находите и тех кандидатов, которых сами создали своими фильтрами и подходом.
Мы выставляем требования на позицию и ищем соответствующего человека путем применения некоторой методики на том рынке труда, который имеется. Конечно же, требования крупных работодателей и применяемые методы поиска оказывают влияние на рынок труда, во многом и формируют его. Очевидная мысль.
Вы уделили этому очень много внимания при описании вашего найма. Стало быть, это для вас важно — если бы это не случалось с высокой периодичностью, едва ли это удостоилось бы отдельного внимания.
Это ваша рефлексия. Очень странная. Я просто взял задачу, которую обсуждал недавно :)
Разумеется. Не в мелких подробностях, конечно, потому что на такое никакого собеседования не хватит. Но по общим принципам — как вообще делаются тесты, CI, и вот это всё — поговорить можно очень продуктивно, и понять, насколько человек вообще в теме.
Мы так и делаем в сжатых временных рамках.
Да и нам конкретная тема не так важна, нам важнее, чтобы человек при необходимости въезжал в новые темы.
Алгоритмы — часть собеседования. Они не какие-то сильно хитрые — их в универах проходят. Кандидат может их полностью завалить, но все равно попасть к нам (нехорошо, конечно, но всякое бывает, да мы и джунов в том числе набираем).
Это все ждут. Разница только в том, что конкретные люди понимают под каждым из этих красивых слов, потому что все понимают совсем разное.
Вы вот что конкретно понимаете под «кандидат понимает основы программирования»?
Алгоритмы и структуры данных/БД/многопоточность/архитектура ПО/платформа с которой работать планируется.
С того, что я их насмотрелся множество. Это, безусловно, необъективно, но тем не менее.
Так и есть. Вы не знаете кто у нас работает.
Просто интересно, какой? :) Вы тут где-то упоминали «бизнес». Вот это к вам как относится? Оно самое? Или вы там реально что-то значимое творите и вам вот прям алгоритмы край как необходимы?
Я не могу раскрывать детали моей работы. Но вы и ваше окружение так или иначе пользуетесь результатами нашей работы, если живете в РФ.
Мне просто интересно, а многострадальный фильтр Калмана, указанный в этом всём тексте выше (пусть и не вами) как алгоритм, вы лично можете сделать? Не открывая поиск, разумеется.
Не открывая поиск — не могу. Надеюсь это повысит вашу самооценку хотя бы.
А я разве так говорил? Я вам говорил про адаптацию фильтров к реальной задаче + испытательный срок. Вы на этом сроке не можете определить, что вот этот, пусть и без алгоритмов, с работой справляется, а вот тот, хоть и с алгоритмами нет?
Фильтры в текущем виде уже адаптированы. Вы из неверной предпосылки исходите. В текущей схеме найма принципиально ничего не докрутить — смиритесь. Думать нужно в сторону изменения самой схемы. Но пока как есть.
Испытательный срок замечателен и он применяется. Брать больше чем берем — работа встанет, т.к. новички много ресурсов съедают.
В таких фразах всегда логическое противоречие: я не могу говорить, не представляя, иначе что бы я описывал? :) Но, возможно, это представление не совпадает с вашим. Но тут уж как повезёт.
Ваше представление не совпадает с действительностью.
Выключите художника наконец :)
Где написано, что часто? Вы сочиняете ерунду, потому что не знаете как и что на самом деле происходит, но уверены, видимо, что во всем разбираетесь :)
Все проще — вот есть у нас ios команда. У этой команды есть задачи, например, наладить сборку на CI, тесты еще что-нибудь — эту задачу берешь и делаешь.
Вы считаете, что мы должны спросить все то, что предполагается потенциально делать? Мы и сами не все предположить можем, и где-то у нас компетенций нет. Что мы делаем? Учимся и делаем. От кандидата мы в том числе ждем понимания основ программирования, умение и желание учиться новому. И мы это выясняем на собесе.
Давайте уже прекращать наш диалог :) Нам же не работать вместе в конце-концов :)
А я про объективность моих критериев и не говорил. :) Но такой контингент, который рвёт жопу чтобы куда-то просто попасть и сделает ради этого что угодно (в данном случае зазубрит), вряд ли то, что вам нужно.
Еще раз: с чего вы взяли, что эти люди именно такие?
Вы ниже уже написали, какие у вас позиции. Грузы таскать не нужно? :)
Нужно. Но для этого не привлекаются квалифицированные кадры. Квалифицированной работы очень много.
Бедняги, столетия отбора, а не придумали. :) Ну хотя бы испытательный срок вам зачем?
Вы это всерьез про испытательный срок? Если убрать фильтры и брать всех подряд — работа встанет, а квалифицированные подходящие кадры все равно пройдут мимо.
Предлагаю закончить диалог. Вы вообще не представляете о чем говорите. Лучше идите работать, вы там в своем НИИ больше пользы принесете, чем в этом обсуждении.
У вас, похоже, у самого в голове каша :)
Где вы прочли конкретно это утверждение? Или вы снова, как художник, все придумали? :)
Вопросы мы задаем разные, в том числе и задачи, в том числе и на алгоритмы.
Нам неинтересно узнать, может ли кандидат конкретно со свифта пересесть на груви.
Мы смотрим базу. Если база есть, то, мы предполагаем, что когда нечто подобное случится, он должен будет справиться. Как и с другими возможными ситуациями.
Алгоритмы часть базовых знаний.
Попробуйте хотя бы расширить критерии оценки, не ограничиваясь уверенность, что «кандидат должен и обязан знать A (не связанное по существу с вашей задачей напрямую)». Ну и приведите требования к кандидату в соответствие с решаемой вами задачей.
Хочу отдельно на это ответить. У нас если берут человека, то у него нет четкой должностной инструкции. Есть возможность довольно просто менять команды, роли и выполнять самую разную работу. Поэтому спрашивать лучше всего общую базу. Мы больше всего заинтересованны именно в программистах, а не в людях освоивших какую-то платформу, IDE, пару фреймворков и утверждающих, что они могут работу работать. У нас, чтобы работу работать, сначала работу думают, а потом оказывается, что программист swift должен писать скрипты на груви для систем сборок, например. Или нужно написать кросс-платформенную библиотеку для обработки картинок. Да бизнес вообще с чем угодно может в любой момент придти и надо уметь сделать и сделать нормально и быстро.
Спрос на фундаментальные знания сейчас, фреймворки использовать любая обезьяна, по вашей терминологии, умеет.
Вот как не задать вопросов по алгоритмам программисту, скажите? :)
Так критериев и не один и даже не два :)
Просто конкретно от каждого всегда у кого-то боли в известном месте вызываются :)
Критерии именно объективные, а не субъективные. Хотя и субъективная оценка тоже есть.
Люди нужны разные. Карьеристы тоже отлично работают и мотивированны, другое дело, что их энергию надо в полезное русло направлять. Ну как и у других типов сотрудников.
А еще вы так просто ярлыки сами же навешиваете. Вот почему вы считаете, что все, кто проходит такой фильтр — карьеристы и у них мышление «не живое»? Вы сами рядом утверждали, что «Чужая душа — потёмки».
Жалобы постоянны. Кто-то на субъективность жалуется, кто-то на объективность, кто-то на алгоритмы, кто-то на фреймворки и т.д. Всем не угодишь. А задача не в том, чтобы кандидатов радовать, а в том, чтобы закрывать эффективно позиции.
Ваш совет ничего не меняет. Да и тут мало совета, это огромная работа должна быть проведена, чтобы придумать что-то принципиально лучшее в плане отбора людей.
Ну теперь вы хотя бы по теме написали.
Первостепенная задача собеседование — это нанять человека, желательно лучшего из выборки, но главное — подходящего. В крупных компаниях процесс найма сотрудников не останавливается. В итоге его формализуют насколько возможно и вводят какие-то объективные критерии для выбора кандидатов.
Это предположение ошибочное, хотя бы потому, что живое мышление ничего просто так заучивать не будет.
Просто так? Пройти собеседование и устроиться туда, куда хотел — это не просто так.
Да и учат, проходят собесы, на практике это видно. Может вы считаете, что у этих людей уже не живое мышление?
И еще вопрос: вы хотите сказать своим комментарием, что процесс отбора не идеален и хорошие спецы отфильтровываются постоянно? Это хорошо известно. Предложите лучшую схему отбора кадров, это всем на пользу пойдет.
Так я это отрицал разве?
Изначально я говорил о том, что:
1. Программисту с 10 годами опыта должно быть стыдно ныть, из-за того что работодатель спрашивает алгоритмы на собеседовании, т.к. не составляет никакого особого труда это повторить/заучить;
2. Требования к программистам и так заниженные, т.к. дефицит кадров на рынке.
Никто не требует и не проверяет глубоких познаний в этой теме (конечно же, специалист с глубокими алгоритмическими знаниями будет пользоваться авторитетом в этой области).
Как по мне, отбор и так предельно халявный, хотелось бы проверять именно глубокие знания, но, в данный момент, так не получается, т.к.:
1. Такая проверка сама по себе тяжело формализуется и => дорогая;
2. Ситуация на рынке труда не позволяет так напрягать кандидатов, когда они, действительно, могут пойти в любое место на те же условия еще халявнее.
Ну и в итоге имеем некоторый компромис между проверкой знаний/умений и тяжестью процедуры. Если человек может хотя бы зазубрить что-то перед собесом, то, предполагается, что он сможет выполнять свои задачи.
Еще раз: что вы мне доказываете? Что на зубрежке учеба не заканчивается? Думаете это открытие для кого-то? Это просто лучше, чем ничего, но безусловно учеба не сводится к этому.
Ваш ответ, кажется, единственным адекватным в этой ветке :)
Думаю, что кандидат, отправляя резюме в яндекс/гугл должен понимать через какую воронку ему придется пройти и готовиться к этому и к вопросам, которые там спрашивают. Это техническая необходимость для принятия на работу, так же как экзамены при обучении, какими бы глупыми они иногда не были.
На собесе сидят не звери и не роботы, а такие же люди как вы.
Отсутствие подготовки полностью – да, трата времени обоих, согласен, тем не менее, если у человека есть большой релевантный опыт, то как-то он готов. И в таком случае, даже если кажется, что именно к именно вашему собеседованию (а не к работе) он не очень готов, не обязательно он не готов к работе у вас. И это не значит, что как только он встретит трудную задачу или ему станет скучно — он уйдет.
Мне выше писали про кучу предложений на рынке и что готовиться вообще не надо. Если кандидат не готовится потому что уже готов, то он готов :)
Если на собесе видишь неготового кандидата, который выражает готовность работать где угодно и вы ему не сильно интересны (а примерно это мне и описывали), то тогда такой вывод. Он уже показал, что не будет напрягаться в вашей компании. Конечно, в каких-то случаях это будет ошибкой, но это ошибка со стороны кандидата так себя вести.
Не в той. В моей рефлексируют над тем, зачем вообще на него заехали.
Зависит от компании и позиции на которую вы претендуете.
В большинстве случаев по алгоритмам не спросят ничего, что не было в университетском курсе или в среднем по направлению не принято знать.
Тут куча негатива было просто за сам факт вопросов по алгоритмам, хотя в целом это стандарт знаний в профессии.
Они правы, это можно отложить на потом. К iOS разработке как таковой это имеет опосредованное отношение.
Да и в заголовке не сказано, что речь про то, что нужно новичку в первую очередь изучить. Заголовок говорит о том, что должен знать iOS разработчик.
В рамках такой статьи список будет бесконечным. Вы можете сразу всю документацию к Cocoa Touch фреймворку, к Swift и Objective-C сюда перенести. А еще можно копнуть в паттерны, архитектуры, алгоритмы и структуры данных. Можно CI/CD копнуть. Можно напомнить про SOLID, про DI. Можно пойти по известным фреймворкам (хотя у вас уже про RX есть, а про Swinject, Alamofire, Realm — нет).
Так вы напишите, например, статью про особенности протоколов в Swift. В статье вообще никакой особенности протоколов нет. Интерфейсы/протоколы почти во всех языках есть. Замыкания/анонимные функции тоже почти везде есть. И те же массивы в Obj-C и Swift друг от друга отличаются и в других языках разница бывает.
А система контроля версий в других языках не используется? Для каких новичков статья в итоге то? У которых есть бекграунд других языков или нет?
Так это все общие фразы, никакой конкретики. А вы копируете этот информационный мусор, который по сути ничего не говорит.
А немалая часть — не решена. Из статьи не видно, что вообще проблемы есть. Если брать третий свифт, то статья просто была вредной, т.к. человек мог выбрать глючную технологию и потерять из-за этого деньги/время.
Я про производительность ничего, вроде, не писал :) По скорости работы XCode бьют большие сториборды, но они сами по себе антипаттерн. Реюзабельности можно спокойно добиться с ними, если в них ничего не хардкодить. Проблем с конфликтами слияний с ними минимум (у меня большой опыт в этом плане), если соблюдать порядок в работе с системой контроля версий, выделять под разные цели разные сториборды, синхронизироваться по задачам в команде. Чтобы в сториборде была хорошая визуализация экрана (понятная дизайнеру), нужно дополнительно возиться, обычно, там визуально всякие прямоугольники накиданы.
Еще раз — это не проблемы. Настоящая проблема в том, что они не избавляют от необходимости писать код. Они по факту сокращают код на настройку констреентов (и то все равно руками придется с ними работать на чуть более сложных экранах), добавлении вьюх, на настройке сайз классов. В итоге: на простых экранах сториборды хорошо работают (но их и кодом сверстать просто), а на сложных экранах все равно придется верстку кодом настраивать и мы имеем дополнительный сложночитаемый ресурс с версткой. Вот поэтому в сложных проектах их не используют.
А я обратил внимание. Только что это меняет? Вот есть сегодняшний день и актуальные технологии и вы публикуете статью (хоть и перевод). Статья, вроде как, практическую ценность должна иметь именно на сегодняшний день. А тут, получается, неактуальная, неполная, несистематизированная информация.
Мой поинт в том, что статья не будет полезна никому. Просто по отношению кол-ва знаков к практической ценности можно легко найти гораздо полезнее материал в гугле. Банально даже дока эпла и свифтбук, какой-нибудь. Приложения на iOS уже многие годы пишут, материала полно, как это делается. Ваша статья все-равно не отвечает толком на вопросы новичков.
Системы контроля версий зачем-то приписаны. Ну ок, тогда точно нужен xcode, а еще нужен itunes connect. Можно еще инструменты вроде фастлейна, дженкинса, etc приписать — тоже ведь нужны.
Почему-то нужно знать геолокацию и локализацию, а про сетевые запросы нет.
Почему-то надо знать про протоколы и замыкания, а про дженерики не надо? А вывод типов надо или можно не знать? А про перечисления, кортежы, массивы, словари? ARC/MRC?
То что написано про разницу Swift и ObjC — это ни о чем. Эти языки различаются гораздо серьезнее. Хотя бы про рефлексию, наследование от NSObject/NSProxy, разницу value и reference типов написали бы (да и еще целая куча всего на самом деле). Некоторые вещи в свифте тупо нельзя сделать, хотя на обже они тривиальны. А еще со свифтом можно много удивительного словить, т.к. язык все еще активно меняется и на это будешь время тратить.
Про сториборды чушь написана. Можно хоть на каждый экран по сториборду сделать. Их проблема в том, что их читать в текстовом виде сложно, они почти не конфигурируются (нельзя задать отступы/цвета/шрифты в сториборде переменной, которые из конфига где-то сами вытащатся, надо это через код делать). Переходы между экранами тоже толком через сториборд не настроишь, придется код писать. В итоге плюсов от них в большом проекте остается мало, а ошибок может быть много.
Про SwiftUI ничего нет.
Нет. В статье ничего полезного нет. Просто набор некоторых слов и терминов из ios разработки никак толком не раскрытых. Ни сама статья не нужна, ни, тем более, перевод.
Мы:
1) Набираем людей разных уровней;
2) Набираем людей в разные команды с разными ответственностями;
3) Пытаемся говорить с кандидатом больше о том что он знает, а не знает. Не знает алгоритмы? Мы потратим час времени на другие вопросы;
4) Мы оцениваем разные качества кандидата в том числе и софт-скиллы.
Если бы мы хотели так делать, то мы бы предупредили кандидатов.
То, что мы спрашиваем на собеседованиях — мы делаем для решения конкретной производственной необходимости — найма людей. У нас нет целей кого-то оскорбить, своими знаниями похвастаться или что-то такое. Мы коллег будущих ищем.
А какую задачу вы сейчас решаете? Ищете возможность подковырнуть лично меня и потешить свое эго? Выглядит глупо и жалко, вне зависимости от того могу я ответить на ваш вопрос или нет.
На любую тему можно говорить сколько угодно.
У нас есть блоки вопросов по разным темам. Кандидаты либо знают о чем речь, либо нет. Это не тест и грамотных людей несложно отличить, они не пытаются скрывать знания.
Я ничего не рекомендовал. Вы дали ссылку на коммент, где про программный мусор писали. Нашим кодом пользуются, это не мусор.
Вы же спрашивали для чего-то это. Я не знаю зачем.
Я описывал мое понимание фильтров в больших конторах.
Мы выставляем требования на позицию и ищем соответствующего человека путем применения некоторой методики на том рынке труда, который имеется. Конечно же, требования крупных работодателей и применяемые методы поиска оказывают влияние на рынок труда, во многом и формируют его. Очевидная мысль.
Это ваша рефлексия. Очень странная. Я просто взял задачу, которую обсуждал недавно :)
Мы так и делаем в сжатых временных рамках.
Да и нам конкретная тема не так важна, нам важнее, чтобы человек при необходимости въезжал в новые темы.
Алгоритмы — часть собеседования. Они не какие-то сильно хитрые — их в универах проходят. Кандидат может их полностью завалить, но все равно попасть к нам (нехорошо, конечно, но всякое бывает, да мы и джунов в том числе набираем).
Алгоритмы и структуры данных/БД/многопоточность/архитектура ПО/платформа с которой работать планируется.
Так и есть. Вы не знаете кто у нас работает.
Я не могу раскрывать детали моей работы. Но вы и ваше окружение так или иначе пользуетесь результатами нашей работы, если живете в РФ.
Не открывая поиск — не могу. Надеюсь это повысит вашу самооценку хотя бы.
Фильтры в текущем виде уже адаптированы. Вы из неверной предпосылки исходите. В текущей схеме найма принципиально ничего не докрутить — смиритесь. Думать нужно в сторону изменения самой схемы. Но пока как есть.
Испытательный срок замечателен и он применяется. Брать больше чем берем — работа встанет, т.к. новички много ресурсов съедают.
Ваше представление не совпадает с действительностью.
Где написано, что часто? Вы сочиняете ерунду, потому что не знаете как и что на самом деле происходит, но уверены, видимо, что во всем разбираетесь :)
Все проще — вот есть у нас ios команда. У этой команды есть задачи, например, наладить сборку на CI, тесты еще что-нибудь — эту задачу берешь и делаешь.
Вы считаете, что мы должны спросить все то, что предполагается потенциально делать? Мы и сами не все предположить можем, и где-то у нас компетенций нет. Что мы делаем? Учимся и делаем. От кандидата мы в том числе ждем понимания основ программирования, умение и желание учиться новому. И мы это выясняем на собесе.
Давайте уже прекращать наш диалог :) Нам же не работать вместе в конце-концов :)
Еще раз: с чего вы взяли, что эти люди именно такие?
Нужно. Но для этого не привлекаются квалифицированные кадры. Квалифицированной работы очень много.
Вы это всерьез про испытательный срок? Если убрать фильтры и брать всех подряд — работа встанет, а квалифицированные подходящие кадры все равно пройдут мимо.
Предлагаю закончить диалог. Вы вообще не представляете о чем говорите. Лучше идите работать, вы там в своем НИИ больше пользы принесете, чем в этом обсуждении.
Где вы прочли конкретно это утверждение? Или вы снова, как художник, все придумали? :)
Вопросы мы задаем разные, в том числе и задачи, в том числе и на алгоритмы.
Нам неинтересно узнать, может ли кандидат конкретно со свифта пересесть на груви.
Мы смотрим базу. Если база есть, то, мы предполагаем, что когда нечто подобное случится, он должен будет справиться. Как и с другими возможными ситуациями.
Алгоритмы часть базовых знаний.
Хочу отдельно на это ответить. У нас если берут человека, то у него нет четкой должностной инструкции. Есть возможность довольно просто менять команды, роли и выполнять самую разную работу. Поэтому спрашивать лучше всего общую базу. Мы больше всего заинтересованны именно в программистах, а не в людях освоивших какую-то платформу, IDE, пару фреймворков и утверждающих, что они могут работу работать. У нас, чтобы работу работать, сначала работу думают, а потом оказывается, что программист swift должен писать скрипты на груви для систем сборок, например. Или нужно написать кросс-платформенную библиотеку для обработки картинок. Да бизнес вообще с чем угодно может в любой момент придти и надо уметь сделать и сделать нормально и быстро.
Спрос на фундаментальные знания сейчас, фреймворки использовать любая обезьяна, по вашей терминологии, умеет.
Вот как не задать вопросов по алгоритмам программисту, скажите? :)
Просто конкретно от каждого всегда у кого-то боли в известном месте вызываются :)
Критерии именно объективные, а не субъективные. Хотя и субъективная оценка тоже есть.
Люди нужны разные. Карьеристы тоже отлично работают и мотивированны, другое дело, что их энергию надо в полезное русло направлять. Ну как и у других типов сотрудников.
А еще вы так просто ярлыки сами же навешиваете. Вот почему вы считаете, что все, кто проходит такой фильтр — карьеристы и у них мышление «не живое»? Вы сами рядом утверждали, что «Чужая душа — потёмки».
Жалобы постоянны. Кто-то на субъективность жалуется, кто-то на объективность, кто-то на алгоритмы, кто-то на фреймворки и т.д. Всем не угодишь. А задача не в том, чтобы кандидатов радовать, а в том, чтобы закрывать эффективно позиции.
Ваш совет ничего не меняет. Да и тут мало совета, это огромная работа должна быть проведена, чтобы придумать что-то принципиально лучшее в плане отбора людей.
Первостепенная задача собеседование — это нанять человека, желательно лучшего из выборки, но главное — подходящего. В крупных компаниях процесс найма сотрудников не останавливается. В итоге его формализуют насколько возможно и вводят какие-то объективные критерии для выбора кандидатов.
Просто так? Пройти собеседование и устроиться туда, куда хотел — это не просто так.
Да и учат, проходят собесы, на практике это видно. Может вы считаете, что у этих людей уже не живое мышление?
И еще вопрос: вы хотите сказать своим комментарием, что процесс отбора не идеален и хорошие спецы отфильтровываются постоянно? Это хорошо известно. Предложите лучшую схему отбора кадров, это всем на пользу пойдет.
Изначально я говорил о том, что:
1. Программисту с 10 годами опыта должно быть стыдно ныть, из-за того что работодатель спрашивает алгоритмы на собеседовании, т.к. не составляет никакого особого труда это повторить/заучить;
2. Требования к программистам и так заниженные, т.к. дефицит кадров на рынке.
Никто не требует и не проверяет глубоких познаний в этой теме (конечно же, специалист с глубокими алгоритмическими знаниями будет пользоваться авторитетом в этой области).
Как по мне, отбор и так предельно халявный, хотелось бы проверять именно глубокие знания, но, в данный момент, так не получается, т.к.:
1. Такая проверка сама по себе тяжело формализуется и => дорогая;
2. Ситуация на рынке труда не позволяет так напрягать кандидатов, когда они, действительно, могут пойти в любое место на те же условия еще халявнее.
Ну и в итоге имеем некоторый компромис между проверкой знаний/умений и тяжестью процедуры. Если человек может хотя бы зазубрить что-то перед собесом, то, предполагается, что он сможет выполнять свои задачи.
Думаю, что кандидат, отправляя резюме в яндекс/гугл должен понимать через какую воронку ему придется пройти и готовиться к этому и к вопросам, которые там спрашивают. Это техническая необходимость для принятия на работу, так же как экзамены при обучении, какими бы глупыми они иногда не были.
На собесе сидят не звери и не роботы, а такие же люди как вы.
Мне выше писали про кучу предложений на рынке и что готовиться вообще не надо. Если кандидат не готовится потому что уже готов, то он готов :)
Если на собесе видишь неготового кандидата, который выражает готовность работать где угодно и вы ему не сильно интересны (а примерно это мне и описывали), то тогда такой вывод. Он уже показал, что не будет напрягаться в вашей компании. Конечно, в каких-то случаях это будет ошибкой, но это ошибка со стороны кандидата так себя вести.