И что вы показали мне по вашему? :)
Что, не нужно формулы учить? Что образовательная программа не включает все полезные знания и надо продолжать изучение самостоятельно? Ваш поинт в чем?
Я вот уверенно могу заявлять, что куча народа даже умножать, даже по памяти не умеет, не говоря уже про вычисление по формулам. Это потому что они не изучали или не учились?
Обучение начинается с, в том числе, обычной зубрежки у детей. Чтобы что-то изучать в голове должен быть какой-то базис.
Надо ли учиться? Надо. Надо ли, что-то глубоко изучать? Тоже надо, если мозгов хватает.
Я искренне не понимаю, какую разницу и для чего вы мне тут показывать собрались. Я вижу только словоблудство: «учить/изучать». Есть еще слова: исследовать, постигать, понимать, вникать, разбираться. Давайте, найдите и покажите еще и с ними разницу :)
А так все адекватные люди и так понимают, что есть какие-то нюансы, которые не описаны в конкретной книге. Всем так же понятно, что наличие знания не говорит об умении его применения.
А еще всем понятно что нужно учиться. И, конкретно, знание алгоритмов на любом уровне лучше их полного незнания, особенно для программиста.
1) Я не утверждал, что программист не может обойтись без знаний алгоритмов. Полно примеров, что может;
2) Про лояльных соискателей и низкие зп, ну хз, крупные компании разные есть, они тоже друг от друга отличаются;
Алгоритмы — это определенные паттерны для решения определенной задачи. Сразу видно костыли, когда человек реализует уже известный алгоритм из г*вна и палок, хотя можно проще. Так что самый частый кейс — кодревью. Вы можете усомниться в полезности этого кейса, но я считаю, что это самый полезный постоянно работающий кейс, который спасает от корявых велосипедов, легаси будущего и т.п.
Дальше: написание своих библиотек. Во-первых, ты сам можешь велосипед придумывать, хотя уже все придумано было, а ты просто не знаешь. Во-вторых, полно популярных фреймворков, а в них дыры, утечки и всякое нехорошее. Почему? Потому что автор не шарит и его никто не проверил.
Время запуска приложений деградирует в приложениях, приложения больше весят, жрут батарею — это проявления в том числе и отсутствия у автора понятия об алгоритмах.
Совсем тупые примеры — с хэшами постоянно работа идет, часто вижу ошибки в их использовании, потому что нет понимания что это вообще.
Это все вроде мелочи, но их много.
Ну и вообще алгоритмы, паттерны, архитектуры, предметные области — все надо знать. Ну если развиваться в профессии хочешь и создавать что-то действительно новое, а не использовать чужие наработки, для решения однотипных задач.
Открою секрет: когда вам говорят, что не смотрят на то, правильно ли вы решили задачу — вам банально лгут. Всегда, в 100% случаев.
Как максимум, смотреть могут не только на правильность решения.
Опять чудеса интернет-экстрасенсорики :)
Я не буду углубляться, но есть случаи, когда кандидат вообще не решает предложенную задачу (или решает каким-то читерским способом) и успешно проходит собес. Пускай это будет лично моя практика :)
Вообще, вот вы ниже написали, что вы у себя задачи давали кандидатам. Вы какие-то «правильные» задачи давали?
Полно людей, которые могут рассказать алгоритмы, а вот задачу решить не могут. Как к этому вы относитесь?
И этот же человек говорит о переходе на личности, ага.
И почему я не могу отметить про вас что-то очевидное, если вы про меня не стесняясь пишите? :)
Про проблемную область найма сотрудников я вам выше всё написал: когда вы нанимаете сотрудника делать работу — проверяйте, может ли он делать эту работу. Не более и не менее. Любые попытки строить проекции (от обсуждения алгоритмов до чего угодно) — заведомо менее полезные, чем прямые проверки, и работают только в условиях неиссякаемого потока кандидатов.
Я вам про неиссякаемый поток кандидатов и пишу. Их нужно фильтровать постоянно и постоянно искать новых. У Яндекса, например, как раз так. Удивительно, почему они алгоритмы спрашивают, совпадение, наверно. А еще они зазнались и вообще во всем не правы :)
Да нет, это вы хотите о чём-то «общем» упорно поговорить. Я на собеседованиях говорю исключительно о частностях, никогда не было потребности нанимать «программиста в широком смысле слова», знаете ли.
А вот раз вы хотите поговорить об общем — я вам предложил еще более общее, чем алгоритмы, но вы почему-то не в восторге. Почему?
Т.е. вы в частности программист, а в общем нет? :)
Да я то не против поговорить об общем. Я могу и математику спрашивать и физику. Могу про биологию поговорить, про философию тоже немного могу :)
Еще раз, алгоритмы — удобная тема.
Оно и видно, что вы прям «душой лежите» к экзаменам, ага. Насчёт бреда — спасибо, я уже в жизни много работал с «отличниками», которые заучили в десять раз больше, чем я способен в голове держать, вот только применять это заученное могут только со страшным скрипом и наводящими пинками, а не сами по себе. А один из самых страшных авралов в моей жизни случился из-за необходимости срочного переписывания куска кода рук двух блестящих решателей олимпиадных задачек, которые устроили безумный оверинжиниринг на ровном месте.
И что вы своим примером доказали? Видимо, теперь все отличники плохие, а вы хороший? Я про отличников вообще ничего не писал, между прочим.
Вообще, вы постоянно с темы съезжаете в какие-то крайности, личности, еще что-то. Тут у вас отличники теперь неправильные. Я так думаю, что все, кто больше вас знает — нехорошие.
Ну-ну.
Что «ну-ну»? Это моя ценность: «мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями». Исходя из своей ценности я оцениваю кандидата. Допустим, кандидат не знает алгоритмов, а у меня есть вопросы на алгоритмы. Значит ли это объективно, что он «раздолбай»? Нет, но может и значить. Зато если кандидат подготовился к вопросам, выразил знания о продукте/компании/команде/докладе/митапе в компании, ну очевидно, что он замотивирован, готов что-то учить, а первый — хз. Кого надо нанять по вашему?
Какой-то поток сознания, простите. Кто глупее кого, при чём тут рекрутёры и алгоритмы?
Гугл и прочие нанимают именно так, потому что могут. Наличие постоянного входящего потока кандидатов позволяет устанавливать какой угодно входной фильтр, чтоб проходил только небольшой процент. Как это делать — не так уж и важно, смахивать 99 из 100 резюме в корзину — тоже отличный фильтр, например.
Да у вас все само собой происходит в мире. Вы, видимо, думаете, что в гугле не умеют деньги считать и, видимо, поэтому у них их столько? А вам не приходила в голову мысль, что дело не в том, что «могут», а в том, что по-другому не могут? Может к ним настолько дохрена спецов ломится, что они не могут ничего лучше придумать? И не кажется ли вам, что это действительно рабочая стратегия и там действительно крутые спецы работают, а не те «отличники» про которых вы писали?
Ну и не забывайте, что гугл стал гуглом задолго до того, как начал устанавливать повальные входящие фильтры для новых сотрудников. Это к вопросу об «успешности» тех или иных стратегий найма: судить об этом по успешности самой компании довольно бесполезно, связь этих двух вещей очень опосредована и между ними большая временная задержка.
Да при чем тут вообще стратегия найма, гугл разбогател, потому что клиентам услугу успешно продал, а не потому что как-то особенно людей нанимал.
Другой вопрос, это возникшая проблема с наймом, когда туда люди ломанулись. Ну вот так они ее решают. У вас лучшее решение есть? В конце концов, если хотите работать в такой компании, вам нужно знать теоритический минимум по computer science (в гугле вас не только по алгоритмам прогонят). Нравится вам это, не нравится, используете ли вы все это в работе — на этапе собеседований это фильтрационные задачи. Не можете такое осилить? Ну значит вам не подходит такая компания. Я понять не могу вашего нытья.
Полезно ли это в работе? Любое знание полезно. Раньше ныли на то, что заставляли книжки по научному коммунизму учить в универах :D
А тут алгоритмы :) Извините, мне уже смешно этот диалог продолжать :)
А чего это? Сомнения в эффективности такого подхода есть?
Очевидно, что у работодателя есть стратегия для своего пиара и специально обученные сотрудники.
Сами-то много алгоритмов знаете?) И что вы вкладываете в слово «знать»?
Достаточно. Что-то на память, что-то забывается со временем. Иногда повторяю.
Знать — уметь объяснить и реализовать.
Пока вся эта история с алгоритмами на собесах выглядит как карго-культ, а вы — как душный сноб, который критику не приемлет. Вы и на работе также с людьми общаетесь?
У нас с вами разное понятие о критике :) Я тут критики никакой вообще не увидел. Я вижу нытье взрослых, казалось бы, людей, которые себя, видимо, профессионалами считают, но при этом отказываются понимать, как работает система найма крупных компаний и почему именно так.
Ну и просто искренне смешно, когда программисты пытаются доказывать, что знать алгоритмы им не надо.
Вам все люди с не такой точкой зрения как у вас душными снобами кажутся?
Про меня тут уже наговорили гадостей, и про мое мышление и про качества мои деловые и еще что-то было. Не стесняйтесь, высказывайтесь дальше, вы же в интернете :)
Такие штуки не разглашаются без разрешения, очевидно.
Просто спрашивайте у hr, какие этапы и вопросы вас ожидают или сразу предупреждайте, что алгоритмы не знаете и отвечать не будете, делов-то.
Почему бы не о погоде на Марсе? Ну или если вы всерьез делите где-то по грани вычислительной техники, почему бы не поговорить о логическом устройстве CPU? Что вы, что программист на C — на всё тех же процессорах работаете, тема универсальнее некуда.
Я могу хоть о чем из этого на собеседовании говорить :) Тем не менее, алгоритмы самая универсальная тема.
А серьезный ответ на этот вопрос очень простой: если вам нужен человек делать некоторую работу, вам за короткое время собеседования стоит выяснять главным образом то, справится ли человек с этой работой. «Олимпиадные задачки» проверяют, справляется ли человек с решением таких задачек. Для каких-то очень узких случаев проверять будет нужно именно это, но обычно энтерпрайз-программист занимается таки совсем другой работой. Статья выше наших комментариев, кстати, это прекрасно демонстрирует, хотя написана была вроде даже для утверждения обратного ¯\_(ツ)_/¯
Открою секрет: когда вам дают олимпиадную задачку, то смотрят не на то как правильно вы ее решите. Я думаю вы вообще не понимаете проблемную область найма сотрудников и не пытаетесь понять.
Мышление развивает примерно 100500 самых разных вещей, так что совершенно неясно, почему из этих 100500 выбираем алгоритмы. «Общая профессиональная грамотность» — пустой беспредметный баззворд, в который, опять же, можно вписать 100500 совершенно разных вещей, и непонятно, почему алгоритмы тут какие-то особенные.
Потому что в выч. технике так или иначе постоянно используются. Это удобно для собесов, потенциально полезно и близко для общего знаменателя для разных сортов программистов. Вы действительно хотите про устройство процессоров говорить, их регистры и т.д.?
Действительно. Вас, кстати, очень хорошо этот ответ раскрывает: я ведь не зря выделил «учить» болдом в прошлом сообщении. «Учить» не означает «изучать», не означает «пользоваться», и вообще много чего не означает. Однако вы упираете именно в «учить».
Опять интернетная экстрасенсорика и переход на личности :)
Я вам идею закину — разберите эти слова в стиле Задорнова, наверняка, там еще что-то зашифровано обо мне :)
Так вот, ответ на ваш вопрос очень простой, на самом деле: таблицу умножения учить не нужно, и более того, абсолютно вредно. Нужно разобраться с принципами работы умножения. Алфавит учить не нужно, большая часть знаний об алфавите придёт из изучения языка, тогда же и будет сформирован необходимый контекст знаний. А алфавитный порядок букв потом как-нибудь уже зафиксируется по ходу дела, тем более, что намеренно запихивать его в память нет необходимости. Иностранные языки «учить» не нужно, и даже вредно. Их нужно «изучать».
Отчасти игра словами (учить/изучать), отчасти, простите, бред. Алфавитный порядок у вас «как-нибудь» зафиксируется, принципы умножения тоже, видимо, «как-нибудь» изучатся… Я пару лет репетитором по физике/математике/программированию походил, насмотрелся я на этот принцип «как-нибудь». Надеюсь, что когда ваших детей «как-нибудь» выучат, у вас проснется понимание, что «как-нибудь» — это никак.
Ну нет. Наше обсуждение началось с вашего «кто сказал, что готовиться не надо?», а потом вы немедленно начали продвигать тему, что если где-то вас собеседуют в хвост и гриву — то это признак хорошей работы, крутых коллег, и так далее. Это и есть «поиск лучших», только сформулированный как «раз требуют алгоритмы — значит там круто».
Эти эпитеты вы сами придумали. Я сводил к оценке кандидата, к уверенности, что он справится с задачами. Когда вы постоянно проводите собесы, а параллельно занимаетесь другими важными вещами — нужна какая-то линейка/метод для оценки кандидатов объективно, а не субъективно. Вы этого упорно не понимаете.
Зачем придумывать то, что уже прекрасно существует? Я надеюсь, вы осознаете, что далеко не все крупные конторы собеседуют как FAANG (и как яндекс, который на них пытается быть похожим)?
Для рекрутеров найм айтишников — это открытая проблема. Если вы придумаете лучший способ — вы можете на этом заработать. Они так собеседуют не потому что они глупее вас. Может, если бы вы изучали алгоритмы, то вам было бы проще понять почему так происходит.
А еще вам про мягкое говорят, а вы про теплое думаете. Алгоритмы полезно знать, но, явно, не обязательно. Если хотите работать на Яндекс — соберите свой десятилетний опыт в кулак и повторите базовые алгоритмы или не тратьте их время на собеседование — оно дорогое между прочим.
Это не имеет никакого отношения к размеру проекта, команд, и тому подобного. Даже странно, что вам приходится это объяснять. Есть большие дорогие проекты, есть большие дешевые, есть маленькие дорогие, есть маленькие дешевые. Более того, в каждом проекте есть места, дорогие в поломке, а есть дешевые.
Я опять не понял, что вы хотите сказать :) Я имею дело с большими проектами, большим кол-вом вовлеченных людей и цена ошибок — большая. Процессы в большой компании с большим кол-вом сотрудников и клиентов отличаются от каких-нибудь стартапов. Я работал и в маленьких конторах и там о многом можно не париться. Влияет ли это все на процесс найма разработчиков? Конечно влияет.
Это всё ортогональные друг другу и размеру проекта вещи. Более того, некоторые вещи из этого списка конфликтуют с другими. Дорогой код и высокая ответственность? Добро пожаловать в махровое легаси, которое «работает и не трогай». И так далее.
Здравствуйте :D Уж не знаю где как, но сейчас все адекватные люди переходят на гибкие методологии разработки, модульные архитектуры, девопсы всякие внедряют. Если так не делать — через 10 лет станешь неконкурентноспособным. Как вы думаете, что происходит с махровым легаси, которое лучше не трогать?
А алгоритмы тут каким боком? Тот, кто на бумажке пишет пять сортировок — в пять раз менее раздолбай, чем тот, кто только пузырёк?
Вы когда-нибудь экзамены сдавали?
Вот простая, понятная, универсальная тема с кучей литературы и от предметной области практически не зависит. Я, программист swift, могу собеседовать программиста C по алгоритмам. О них очень просто говорить, просто готовиться. Почему бы на собесе не поговорить именно о них? Потому что кандидату лень книжку полистать? Ну и почему я должен хотеть работать с ним?
Нет, работодатель — это тот, который благодаря сотрудникам вообще имеет какую-то сущность. Работодатель без сотрудника — лишь условная юридическая конструкция.
Даже не знаю что сказать на это. Ну это так, да. Только почему-то деньгами и работой рулит работодатель. И все сотрудники на него работают. Как-то все условности пропадают, когда на зарплаты смотришь. Если у вас это условность, то я на вашем месте убрал бы эту условность и распределил освободившиеся деньги.
Конечно. Именно поэтому на собеседованиях обычно царит махровая клановость и не более того. Не «вы должны готовиться к собеседованиям», а «я считаю, что к моим собеседованиям должны готовиться, а кто не готовится — говно и отстой, и я с такими работать не буду». Я, собственно, нисколько не против — я просто не люблю, когда мне начинают это впихивать как некий критерий «лучшести», «лучшей работы», и так далее. Нанимайте как угодно, хоть тех, кто жонглирует десятью предметами, это ваше право. Только не называйте это «мы нанимаем лучших».
Впрочем, в больших конторах, за которые вы топите — «коллеги» собеседуют как максимум после большого толстого общеконторского фильтра, и выходит как с тем же яндексом — «собеседование по алгоритмам — только одно из многих», но вот только не прошедшие его выкидываются сразу же, и на все остальные просто не идут.
Принимаем тех, в ком уверены, что они справятся с задачами. Алгоритмы — понятный критерий для отбора людей. Если человек настолько хорош, что повторить алгоритмы и ответить на вопросы для него слишком затратно, или какие там причины этого не делать, то да, фильтр его отсеит. Когда набор людей бесконечный, не страшно потерять пару действительно хороших, но ленивых кандидатов, важнее выстроить надежную систему приема подходящих людей на постоянной основе.
А зачем учить алгоритмы? Чтоб ночью разбудили и всё рассказал?
Затем, что это развивает мышление и общую профессиональной грамотность, например. Зачем учить таблицу умножения, алфавит, английский язык? Глупый вопрос, на самом деле.
Я не буду вас учить как вам жить. Считаете, что можете работать программистом и утверждать, что знание алгоритмов бесполезно? Это ваше право на личное мнение.
А что заставляет вас думать, что нет? Я, например, уже более 10 лет работу работаю, а к собеседованиям не готовлюсь, не собираюсь, и помашу ручкой тем, кто будет пытаться мне доказать обратное. Мотивации к выполнению работы у меня предостаточно, а вот какая у меня должна быть мотивация для подготовки? Страсть как хотеть работать именно с этими людьми? Но, как я выше уже писал, это не для всех работает. Мир большой, людей много.
1) Я не знаю кто вы и как работаете;
2) Возможно, что вы гордый гений и изучение алгоритмов для вас бесполезно. Ну поздравляю, вы не пройдете такой собес. И это совершенно не страшно для большой конторы, так же как и для вас в текущей экономической ситуации. Так что вы так нервничаете по этому поводу, если все всех устраивает?
Впрочем, для вашего образа мышления целая статья википедии есть.
Ох уж эти интернетные экстрасенсы…
Конечно надо, если есть мотивация. Проблема в том, что делать это ради собеседования а) мотивации нет вплоть до тех пор, пока вы не стремитесь к конкретным людям, проводящим такие собеседования, к которым вам надо готовиться; б) более того, есть мотивация этого не делать, так как любое приукрашивание реальности на собеседовании, как со стороны конторы, так и со стороны кандидата — повышает шансы попасть в коллектив, работать в котором будет в дальнейшем неприятно.
Ну так вот у вас нет мотивации готовиться к собеседованию с людьми, которые на вас свое рабочее время тратят. И на вас, конечно же, надо потратить еще больше времени, прежде чем выяснится, что у вас работать тут мотивации нет? Глупость какая-то. Вы свою важность преувеличиваете из-за ситуации на рынке труда. Вангую, что если вы доживете до момента, когда такая нужда в программистах упадет — вам станет не очень комфортно.
Я собеседовал людей в команду как техспециалист, да.
В большую контору? Как совмещали рабочие задачи с собеседованиями? Сколько кандидатов в неделю собеседовали? Как отчитывались о кандидатах? Сколько длились собеседования?
У вас какая-то статистика есть, или это всё «я художник, я так вижу»?
Просто с позиции художника я вам ровно противоположный вывод легко сделаю: если человек готов ради работы с вами подпрыгивать строго на заданную вами высоту, то он точно так же готов будет подпрыгивать ради следующего предложения о работе, чуть круче вашего по важным для него параметрам (которые он вам не скажет, разумеется) — чуть больше денег, чуть больше престижа у позвавшей его конторы, и тому подобное — и вот он сразу же с вами прощается.
Если человек пришел на встречу, где оценивают его профессиональные навыки, не подготовившись к ней и покажет, что эта работа ему особо-то и не нужна, т.к. другой много, то вывод будет о нем примерно как я написал без всякой статистики. Вы, как художник, можете видеть это как угодно со своей стороны.
Дополнительно обращаю ваше внимание на то, что отсутствие «хочу работать конкретно у вас до дрожи в коленках» не означает «всё равно где работать». Просто вы, как работодатель — один из многих и многих тысяч тех, кто кандидата устраивает по его внутреннему фильтру.
Про дрожь в коленках, это вы как художник придумали, я так не говорил.
Если кандидат думает, что за ним бегать и упрашивать работать должны — я бы по возможности с таким не связывался.
Впрочем, я вашу позицию понял. Другое дело, что я её не разделяю, и работать с подобными вам — не собираюсь, благо хватает работодателей гораздо адекватнее. И пока вы не пытаетесь выдать ваши критерии найма за «поиск лучших» — даже и спорить не буду, каждый пляшет как хочет.
Если что — я не работодатель.
«Поиск лучших» вы сами придумали. Я говорил про адекватный постоянный поиск подходящих кандидатов, как в крупных конторах типа Яндекса.
Вы очень активно не спорите уже который комментарий, утверждая свое право ничего не делать для устройства на работу.
Лучше вместо этих потоков добра в мою сторону, вы бы придумали рабочую многократно повторяемую систему найма, может быть денег на этом заработали даже.
Я заметил, что вы дополнили комментарии, отвечу сюда.
Лично я вот сменил работу за апрель, так и не начав рассылать резюме сам. Единственное отличие от более лучших времен — то, что я внутренне был на низком старте относительно необходимости идти стучаться в двери самому, а не ждать рекрутёров. Но нет, не пришлось.
Никто же не спорит, что предложения выше спроса сейчас. Рынок труда на стороне соискателя (программиста) — это факт.
Тут есть маленькая проблемка: я не вижу никаких исчислимо лучших условий там, где «со всякими алгоритмами» относительно мест «без всяких алгоритмов». Разница, главным образом, именно в этом: одни прям жить не могут без алгоритмов и структур данных на собеседованиях, вторые — могут. В остальном всё плюс-минус похоже.
А как вопросы со стороны работодателя к вам должны влиять на качества работы у этого работодателя непосредственно? Это часть алгоритма отбора кандидатов, сама работа может вообще не предполагать написание кода.
Вообще, собеседование — двухсторонняя вещь. Вы со своей стороны должны выяснить все важные для вас нюансы. Можете и про использование алгоритмов и структур данных в работе заодно спросить и про аттестации и т.д. Я не стесняюсь спрашивать, где применяются алгоритмы, которые у меня спрашивают — это дает представление о том, чем я лично буду заниматься.
Даже не знаю почему вы так интерпретировали мои слова.
Я тоже работал в команде >10 человек в проекте с >1000 (если считать очень-очень веерно, как, собственно, и вы сделали) разработчиков. Что дальше? Там всё совсем не так, как в очередном стартапчике на коленке? Конечно не так, объективная разница всё-таки огромная. Но с точки зрения адекватности работы — первое не безусловно лучше второго, и наоборот. Адекватность вообще не от размера проекта зависит.
Я не понял, что вы именно пытаетесь этим сказать.
Лично я говорю про большую развитую инфраструктуру, где много узких мест и поломка может стоить дороже, чем ответственный программист за год заработает. А еще где много команд, много ответственностей и зависимостей, где важны сроки и качество кода. Мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями.
А кто вы такие, чтоб для вас это делать?
Работодатель — это тот благодаря кому сотрудник кушает каждый день и крышу над головой имеет. Но собеседует, обычно, не работодатель, а коллеги будущие. Те, с кем вы, возможно, бок о бок будете трудиться, выполнять планы и т.д. Не хотите с нами работать? Ну работайте где-то еще, никто не возражает, мы лучше еще поищем.
Не готовиться к собеседованиям != не заниматься самообразованием. Если вы не делите эти вещи — у вас полная каша в голове.
Вы все на личности пытаетесь перепрыгнуть :) Это вы как-то слова через запятую в одно понятие склеиваете, не надо мне это приписывать.
Про самообразование конкретно я имел в виду, что не учит алгоритмы. Вообще, самообразование, конечно, бывает разное, например, можно танцевать учиться. Но вот мне на собеседовании интересно про алгоритмы с кандидатом поговорить больше, чем о чем-то не относящемся к работе или о том, что и так все знают.
А про подготовку: ну если человек не желает подготовиться к собеседованию, то захочет ли он готовится к демонстрациям, сроки выполнять, делать задачи которые нужно делать, а не хочется? Мы тут работаем, у нас должна быть дисциплина. Смешно объяснять даже, что к встречам в принципе готовиться надо, не только к собеседованиям.
Вы сами набирали людей в команду когда-нибудь?
Всё чудесатее и чудесатее — как вы от «не готовится к собеседованиям» переходите к «готов ливнуть»? Здесь нет логической связи, ни прямой, ни даже опосредованной.
Никак я от этого не переходил. Это вы сказали, что не все хотят работать у конкретного работодателя. Из этого вывод, что человек наверняка ливнет, когда столкнется с задачей, которая его не устроит. Он ведь даже подготовиться к собеседованию (которое между прочим почти везде похожее и легкое) не желает.
Я бы не брал человека, которому все-равно где работать и который не может осилить элементарно повторить алгоритмы уровня университета перед собесом, т.к. не уверен в его профессионализме.
Я видел. Адресов давать не буду — это неэтично.
Возможно, у меня требования к грамотности специалиста выше, чем у вас. Я давно работаю в командах >10 человек в проектах с >1000 разработчиков.
Брать людей в команду, которые почему-то решили, что могут не готовиться, не заниматься самообразованиям, которые готовы ливнуть в другую контору в любой момент — зачем?
Лично я хочу работать там, куда не всех подряд берут. Более того, я стремлюсь в конкретные команды у конкретных работодателей.
Если вам все равно с кем/на каких условиях/над чем работать, то вас без всяких алгоритмов возьмут обязательно куда-нибудь.
Вчерашний студент и программист с 11-летним стажем не могут претендовать на одну и ту же вакансию в принципе. Какой смысл сравнивать несравнимое?
Да и похоже на нытье какое-то. По-моему стыдно с таким стажем жаловаться, что у вас спрашивают вопросы на которые студенты отвечают легко. Понятно что в голове может и не быть готового ответа, т.к. редко используются такие знания на практике, но кто сказал, что к собеседованиям готовиться не надо? Если вы собрались в конкретную компанию по общему конкурсу пройти (вы, судя по всему, не известный специалист в своей области, которому без всяких собеседований офферы шлют), то сходите потренируйтесь в другие компании, освежите свои знания.
Вы себя продавать идете людям, которые с вами работать будут. Хочется, чтобы вы с 11летним стажем могли обучать новичков (вчерашних студентов) и быть авторитетом для них, а вы на вопросы по алгоритмам жалуетесь.
Сейчас к программистам и так требования заниженные, т.к. рынок труда в пользу кандидата.
Читайте внимательнее. Мы используем некоторые библиотеки в том числе гугла, когда они решают нашу задачу потому, что гугл способен обеспечить качество и поддержку, хотя даже с ними бывают проблемы. Надо к выбору библиотек подходить ответственно и брать только те, которые действительно нужны. В посте же представлены свистоперделки, которые правильнее уметь делать самому.
К чему это вообще? Если обобщить то, что я написал, то большинство библиотек не подходят по качеству кода и поддержке. Т.е. я и моя команда обеспечиваем несопоставимо большее качество и мы не рискуем тащить в проект непонятно что. Просто базовый набор библиотек для логов/di/верстки какой-нибудь уже несут с собой краши и утечки (даже если библиотеку разрабатывает google).
В моей практике на ios я видел тонны говнокода именно в командах, где вопросами качества кода не задаются и готовы с радостью к своим тоннам говнокода присовокупить еще и чужие.
Вы поднимаете другую проблему.
1) Не должно быть специализации на проектах/компонентах в командах. Есть задача — ее подхватывает освободившийся, а не «разработчик этого модуля». Таким образом в команде не случится больших проблем при увольнении кого-либо;
2) Код должен проектироваться/документироваться/тестироваться/ревьювиться — таким образом вопросов к этому коду будет гораздо меньше;
3) Код должен поддерживаться и рефакториться постоянно. Таким образом код никогда не станет legacy.
Связываясь с библиотеками (особенно с UI библиотеками) невозможно толком гарантировать качество кода — автор библиотеки не будет гарантировать вам ничего, а, следовательно, в любой момент приложение может просто перестать работать и принести непредсказуемый убыток и ничего толком с этим не сделать. Поэтому решение об использовании библиотеки должно быть серьезно мотивировано, а команда разработки должна быть готова к последствиям этого использования.
Самая большая проблема, что о возможных последствиях никто и нигде не говорит в таких статьях, но при этом пишут что-то вроде: «5 iOS-библиотек, которые сделают пользовательский интерфейс вашего приложения действительно популярным».
Если проект еще не приносит денег, я бы рекомендовал заказчику не тратить деньги на такие штуки и сделать проще. Если заказчик решает, что это ему нужно, тогда да, можно предложить вариант на этой стадии сэкономить и взять готовое чужое решение с возможными рисками.
В случае если делаешь проект «для души», лично свой, то я тоже понимаю эксперименты с такими библиотеками.
В остальных кейсах, даже если форки делать, то это все равно чужой код, который нужно изучать, адаптировать, тестировать, поддерживать. Стоит ли эта красота таких денег? Если ответ да, то скорее всего в перспективе будет дешевле написать свой компонент — его поддерживать и развивать будет проще.
Это все красиво-свистопердящее надо поддерживать.
1) Никто не даст гарантий, что это завтра не сломается;
2) Никто не будет анализировать качество кода этих библиотек (с каждой версией);
3) Рано или поздно требования к приложению изменятся и придется вносить изменения в стороннюю библиотеку;
Я не призываю к полному отказу от сторонних библиотек, но каждая такая зависимость должна быть мотивирована, вписана в архитектуру и команда разработки должна быть готова взять поддержку библиотеки на себя в случае чего.
Я не вижу в этих библиотеках достаточной пользы, чтобы брать такую ответственность перед заказчиком за них.
Понятно, что любой код может сломаться, но свой код ты сам контроллируешь, можешь покрыть тестами и т.д.
Без обид, но я бы руки оторвал тому, кто что-либо из этой подборки в рабочий проект в виде зависимости сунул…
Единственный плюс подборки, который я вижу — это в образовательных целях на код посмотреть.
Есть еще такая подборка: github.com/vsouza/awesome-ios. Но опять же тащить это в что-то кроме личного проекта — наверняка будет безответственно.
Что, не нужно формулы учить? Что образовательная программа не включает все полезные знания и надо продолжать изучение самостоятельно? Ваш поинт в чем?
Я вот уверенно могу заявлять, что куча народа даже умножать, даже по памяти не умеет, не говоря уже про вычисление по формулам. Это потому что они не изучали или не учились?
Обучение начинается с, в том числе, обычной зубрежки у детей. Чтобы что-то изучать в голове должен быть какой-то базис.
Надо ли учиться? Надо. Надо ли, что-то глубоко изучать? Тоже надо, если мозгов хватает.
Я искренне не понимаю, какую разницу и для чего вы мне тут показывать собрались. Я вижу только словоблудство: «учить/изучать». Есть еще слова: исследовать, постигать, понимать, вникать, разбираться. Давайте, найдите и покажите еще и с ними разницу :)
А так все адекватные люди и так понимают, что есть какие-то нюансы, которые не описаны в конкретной книге. Всем так же понятно, что наличие знания не говорит об умении его применения.
А еще всем понятно что нужно учиться. И, конкретно, знание алгоритмов на любом уровне лучше их полного незнания, особенно для программиста.
2) Про лояльных соискателей и низкие зп, ну хз, крупные компании разные есть, они тоже друг от друга отличаются;
Алгоритмы — это определенные паттерны для решения определенной задачи. Сразу видно костыли, когда человек реализует уже известный алгоритм из г*вна и палок, хотя можно проще. Так что самый частый кейс — кодревью. Вы можете усомниться в полезности этого кейса, но я считаю, что это самый полезный постоянно работающий кейс, который спасает от корявых велосипедов, легаси будущего и т.п.
Дальше: написание своих библиотек. Во-первых, ты сам можешь велосипед придумывать, хотя уже все придумано было, а ты просто не знаешь. Во-вторых, полно популярных фреймворков, а в них дыры, утечки и всякое нехорошее. Почему? Потому что автор не шарит и его никто не проверил.
Время запуска приложений деградирует в приложениях, приложения больше весят, жрут батарею — это проявления в том числе и отсутствия у автора понятия об алгоритмах.
Совсем тупые примеры — с хэшами постоянно работа идет, часто вижу ошибки в их использовании, потому что нет понимания что это вообще.
Это все вроде мелочи, но их много.
Ну и вообще алгоритмы, паттерны, архитектуры, предметные области — все надо знать. Ну если развиваться в профессии хочешь и создавать что-то действительно новое, а не использовать чужие наработки, для решения однотипных задач.
Предлагайте.
Опять чудеса интернет-экстрасенсорики :)
Я не буду углубляться, но есть случаи, когда кандидат вообще не решает предложенную задачу (или решает каким-то читерским способом) и успешно проходит собес. Пускай это будет лично моя практика :)
Вообще, вот вы ниже написали, что вы у себя задачи давали кандидатам. Вы какие-то «правильные» задачи давали?
Полно людей, которые могут рассказать алгоритмы, а вот задачу решить не могут. Как к этому вы относитесь?
И почему я не могу отметить про вас что-то очевидное, если вы про меня не стесняясь пишите? :)
Я вам про неиссякаемый поток кандидатов и пишу. Их нужно фильтровать постоянно и постоянно искать новых. У Яндекса, например, как раз так. Удивительно, почему они алгоритмы спрашивают, совпадение, наверно. А еще они зазнались и вообще во всем не правы :)
Т.е. вы в частности программист, а в общем нет? :)
Да я то не против поговорить об общем. Я могу и математику спрашивать и физику. Могу про биологию поговорить, про философию тоже немного могу :)
Еще раз, алгоритмы — удобная тема.
И что вы своим примером доказали? Видимо, теперь все отличники плохие, а вы хороший? Я про отличников вообще ничего не писал, между прочим.
Вообще, вы постоянно с темы съезжаете в какие-то крайности, личности, еще что-то. Тут у вас отличники теперь неправильные. Я так думаю, что все, кто больше вас знает — нехорошие.
Что «ну-ну»? Это моя ценность: «мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями». Исходя из своей ценности я оцениваю кандидата. Допустим, кандидат не знает алгоритмов, а у меня есть вопросы на алгоритмы. Значит ли это объективно, что он «раздолбай»? Нет, но может и значить. Зато если кандидат подготовился к вопросам, выразил знания о продукте/компании/команде/докладе/митапе в компании, ну очевидно, что он замотивирован, готов что-то учить, а первый — хз. Кого надо нанять по вашему?
Да у вас все само собой происходит в мире. Вы, видимо, думаете, что в гугле не умеют деньги считать и, видимо, поэтому у них их столько? А вам не приходила в голову мысль, что дело не в том, что «могут», а в том, что по-другому не могут? Может к ним настолько дохрена спецов ломится, что они не могут ничего лучше придумать? И не кажется ли вам, что это действительно рабочая стратегия и там действительно крутые спецы работают, а не те «отличники» про которых вы писали?
Да при чем тут вообще стратегия найма, гугл разбогател, потому что клиентам услугу успешно продал, а не потому что как-то особенно людей нанимал.
Другой вопрос, это возникшая проблема с наймом, когда туда люди ломанулись. Ну вот так они ее решают. У вас лучшее решение есть? В конце концов, если хотите работать в такой компании, вам нужно знать теоритический минимум по computer science (в гугле вас не только по алгоритмам прогонят). Нравится вам это, не нравится, используете ли вы все это в работе — на этапе собеседований это фильтрационные задачи. Не можете такое осилить? Ну значит вам не подходит такая компания. Я понять не могу вашего нытья.
Полезно ли это в работе? Любое знание полезно. Раньше ныли на то, что заставляли книжки по научному коммунизму учить в универах :D
А тут алгоритмы :) Извините, мне уже смешно этот диалог продолжать :)
Очевидно, что у работодателя есть стратегия для своего пиара и специально обученные сотрудники.
Достаточно. Что-то на память, что-то забывается со временем. Иногда повторяю.
Знать — уметь объяснить и реализовать.
У нас с вами разное понятие о критике :) Я тут критики никакой вообще не увидел. Я вижу нытье взрослых, казалось бы, людей, которые себя, видимо, профессионалами считают, но при этом отказываются понимать, как работает система найма крупных компаний и почему именно так.
Ну и просто искренне смешно, когда программисты пытаются доказывать, что знать алгоритмы им не надо.
Вам все люди с не такой точкой зрения как у вас душными снобами кажутся?
Про меня тут уже наговорили гадостей, и про мое мышление и про качества мои деловые и еще что-то было. Не стесняйтесь, высказывайтесь дальше, вы же в интернете :)
Просто спрашивайте у hr, какие этапы и вопросы вас ожидают или сразу предупреждайте, что алгоритмы не знаете и отвечать не будете, делов-то.
Я могу хоть о чем из этого на собеседовании говорить :) Тем не менее, алгоритмы самая универсальная тема.
Открою секрет: когда вам дают олимпиадную задачку, то смотрят не на то как правильно вы ее решите. Я думаю вы вообще не понимаете проблемную область найма сотрудников и не пытаетесь понять.
Потому что в выч. технике так или иначе постоянно используются. Это удобно для собесов, потенциально полезно и близко для общего знаменателя для разных сортов программистов. Вы действительно хотите про устройство процессоров говорить, их регистры и т.д.?
Опять интернетная экстрасенсорика и переход на личности :)
Я вам идею закину — разберите эти слова в стиле Задорнова, наверняка, там еще что-то зашифровано обо мне :)
Отчасти игра словами (учить/изучать), отчасти, простите, бред. Алфавитный порядок у вас «как-нибудь» зафиксируется, принципы умножения тоже, видимо, «как-нибудь» изучатся… Я пару лет репетитором по физике/математике/программированию походил, насмотрелся я на этот принцип «как-нибудь». Надеюсь, что когда ваших детей «как-нибудь» выучат, у вас проснется понимание, что «как-нибудь» — это никак.
Эти эпитеты вы сами придумали. Я сводил к оценке кандидата, к уверенности, что он справится с задачами. Когда вы постоянно проводите собесы, а параллельно занимаетесь другими важными вещами — нужна какая-то линейка/метод для оценки кандидатов объективно, а не субъективно. Вы этого упорно не понимаете.
Для рекрутеров найм айтишников — это открытая проблема. Если вы придумаете лучший способ — вы можете на этом заработать. Они так собеседуют не потому что они глупее вас. Может, если бы вы изучали алгоритмы, то вам было бы проще понять почему так происходит.
А еще вам про мягкое говорят, а вы про теплое думаете. Алгоритмы полезно знать, но, явно, не обязательно. Если хотите работать на Яндекс — соберите свой десятилетний опыт в кулак и повторите базовые алгоритмы или не тратьте их время на собеседование — оно дорогое между прочим.
Я опять не понял, что вы хотите сказать :) Я имею дело с большими проектами, большим кол-вом вовлеченных людей и цена ошибок — большая. Процессы в большой компании с большим кол-вом сотрудников и клиентов отличаются от каких-нибудь стартапов. Я работал и в маленьких конторах и там о многом можно не париться. Влияет ли это все на процесс найма разработчиков? Конечно влияет.
Здравствуйте :D Уж не знаю где как, но сейчас все адекватные люди переходят на гибкие методологии разработки, модульные архитектуры, девопсы всякие внедряют. Если так не делать — через 10 лет станешь неконкурентноспособным. Как вы думаете, что происходит с махровым легаси, которое лучше не трогать?
Вы когда-нибудь экзамены сдавали?
Вот простая, понятная, универсальная тема с кучей литературы и от предметной области практически не зависит. Я, программист swift, могу собеседовать программиста C по алгоритмам. О них очень просто говорить, просто готовиться. Почему бы на собесе не поговорить именно о них? Потому что кандидату лень книжку полистать? Ну и почему я должен хотеть работать с ним?
Даже не знаю что сказать на это. Ну это так, да. Только почему-то деньгами и работой рулит работодатель. И все сотрудники на него работают. Как-то все условности пропадают, когда на зарплаты смотришь. Если у вас это условность, то я на вашем месте убрал бы эту условность и распределил освободившиеся деньги.
Принимаем тех, в ком уверены, что они справятся с задачами. Алгоритмы — понятный критерий для отбора людей. Если человек настолько хорош, что повторить алгоритмы и ответить на вопросы для него слишком затратно, или какие там причины этого не делать, то да, фильтр его отсеит. Когда набор людей бесконечный, не страшно потерять пару действительно хороших, но ленивых кандидатов, важнее выстроить надежную систему приема подходящих людей на постоянной основе.
Затем, что это развивает мышление и общую профессиональной грамотность, например. Зачем учить таблицу умножения, алфавит, английский язык? Глупый вопрос, на самом деле.
Я не буду вас учить как вам жить. Считаете, что можете работать программистом и утверждать, что знание алгоритмов бесполезно? Это ваше право на личное мнение.
1) Я не знаю кто вы и как работаете;
2) Возможно, что вы гордый гений и изучение алгоритмов для вас бесполезно. Ну поздравляю, вы не пройдете такой собес. И это совершенно не страшно для большой конторы, так же как и для вас в текущей экономической ситуации. Так что вы так нервничаете по этому поводу, если все всех устраивает?
Ох уж эти интернетные экстрасенсы…
Ну так вот у вас нет мотивации готовиться к собеседованию с людьми, которые на вас свое рабочее время тратят. И на вас, конечно же, надо потратить еще больше времени, прежде чем выяснится, что у вас работать тут мотивации нет? Глупость какая-то. Вы свою важность преувеличиваете из-за ситуации на рынке труда. Вангую, что если вы доживете до момента, когда такая нужда в программистах упадет — вам станет не очень комфортно.
В большую контору? Как совмещали рабочие задачи с собеседованиями? Сколько кандидатов в неделю собеседовали? Как отчитывались о кандидатах? Сколько длились собеседования?
Если человек пришел на встречу, где оценивают его профессиональные навыки, не подготовившись к ней и покажет, что эта работа ему особо-то и не нужна, т.к. другой много, то вывод будет о нем примерно как я написал без всякой статистики. Вы, как художник, можете видеть это как угодно со своей стороны.
Про дрожь в коленках, это вы как художник придумали, я так не говорил.
Если кандидат думает, что за ним бегать и упрашивать работать должны — я бы по возможности с таким не связывался.
Если что — я не работодатель.
«Поиск лучших» вы сами придумали. Я говорил про адекватный постоянный поиск подходящих кандидатов, как в крупных конторах типа Яндекса.
Вы очень активно не спорите уже который комментарий, утверждая свое право ничего не делать для устройства на работу.
Лучше вместо этих потоков добра в мою сторону, вы бы придумали рабочую многократно повторяемую систему найма, может быть денег на этом заработали даже.
Никто же не спорит, что предложения выше спроса сейчас. Рынок труда на стороне соискателя (программиста) — это факт.
А как вопросы со стороны работодателя к вам должны влиять на качества работы у этого работодателя непосредственно? Это часть алгоритма отбора кандидатов, сама работа может вообще не предполагать написание кода.
Вообще, собеседование — двухсторонняя вещь. Вы со своей стороны должны выяснить все важные для вас нюансы. Можете и про использование алгоритмов и структур данных в работе заодно спросить и про аттестации и т.д. Я не стесняюсь спрашивать, где применяются алгоритмы, которые у меня спрашивают — это дает представление о том, чем я лично буду заниматься.
Даже не знаю почему вы так интерпретировали мои слова.
Я не понял, что вы именно пытаетесь этим сказать.
Лично я говорю про большую развитую инфраструктуру, где много узких мест и поломка может стоить дороже, чем ответственный программист за год заработает. А еще где много команд, много ответственностей и зависимостей, где важны сроки и качество кода. Мне важно, чтобы коллеги были грамотными профессионалами, а не раздолбаями.
Работодатель — это тот благодаря кому сотрудник кушает каждый день и крышу над головой имеет. Но собеседует, обычно, не работодатель, а коллеги будущие. Те, с кем вы, возможно, бок о бок будете трудиться, выполнять планы и т.д. Не хотите с нами работать? Ну работайте где-то еще, никто не возражает, мы лучше еще поищем.
Вы все на личности пытаетесь перепрыгнуть :) Это вы как-то слова через запятую в одно понятие склеиваете, не надо мне это приписывать.
Про самообразование конкретно я имел в виду, что не учит алгоритмы. Вообще, самообразование, конечно, бывает разное, например, можно танцевать учиться. Но вот мне на собеседовании интересно про алгоритмы с кандидатом поговорить больше, чем о чем-то не относящемся к работе или о том, что и так все знают.
А про подготовку: ну если человек не желает подготовиться к собеседованию, то захочет ли он готовится к демонстрациям, сроки выполнять, делать задачи которые нужно делать, а не хочется? Мы тут работаем, у нас должна быть дисциплина. Смешно объяснять даже, что к встречам в принципе готовиться надо, не только к собеседованиям.
Вы сами набирали людей в команду когда-нибудь?
Никак я от этого не переходил. Это вы сказали, что не все хотят работать у конкретного работодателя. Из этого вывод, что человек наверняка ливнет, когда столкнется с задачей, которая его не устроит. Он ведь даже подготовиться к собеседованию (которое между прочим почти везде похожее и легкое) не желает.
Я бы не брал человека, которому все-равно где работать и который не может осилить элементарно повторить алгоритмы уровня университета перед собесом, т.к. не уверен в его профессионализме.
Возможно, у меня требования к грамотности специалиста выше, чем у вас. Я давно работаю в командах >10 человек в проектах с >1000 разработчиков.
Брать людей в команду, которые почему-то решили, что могут не готовиться, не заниматься самообразованиям, которые готовы ливнуть в другую контору в любой момент — зачем?
Если вам все равно с кем/на каких условиях/над чем работать, то вас без всяких алгоритмов возьмут обязательно куда-нибудь.
Да и похоже на нытье какое-то. По-моему стыдно с таким стажем жаловаться, что у вас спрашивают вопросы на которые студенты отвечают легко. Понятно что в голове может и не быть готового ответа, т.к. редко используются такие знания на практике, но кто сказал, что к собеседованиям готовиться не надо? Если вы собрались в конкретную компанию по общему конкурсу пройти (вы, судя по всему, не известный специалист в своей области, которому без всяких собеседований офферы шлют), то сходите потренируйтесь в другие компании, освежите свои знания.
Вы себя продавать идете людям, которые с вами работать будут. Хочется, чтобы вы с 11летним стажем могли обучать новичков (вчерашних студентов) и быть авторитетом для них, а вы на вопросы по алгоритмам жалуетесь.
Сейчас к программистам и так требования заниженные, т.к. рынок труда в пользу кандидата.
В моей практике на ios я видел тонны говнокода именно в командах, где вопросами качества кода не задаются и готовы с радостью к своим тоннам говнокода присовокупить еще и чужие.
1) Не должно быть специализации на проектах/компонентах в командах. Есть задача — ее подхватывает освободившийся, а не «разработчик этого модуля». Таким образом в команде не случится больших проблем при увольнении кого-либо;
2) Код должен проектироваться/документироваться/тестироваться/ревьювиться — таким образом вопросов к этому коду будет гораздо меньше;
3) Код должен поддерживаться и рефакториться постоянно. Таким образом код никогда не станет legacy.
Связываясь с библиотеками (особенно с UI библиотеками) невозможно толком гарантировать качество кода — автор библиотеки не будет гарантировать вам ничего, а, следовательно, в любой момент приложение может просто перестать работать и принести непредсказуемый убыток и ничего толком с этим не сделать. Поэтому решение об использовании библиотеки должно быть серьезно мотивировано, а команда разработки должна быть готова к последствиям этого использования.
Самая большая проблема, что о возможных последствиях никто и нигде не говорит в таких статьях, но при этом пишут что-то вроде: «5 iOS-библиотек, которые сделают пользовательский интерфейс вашего приложения действительно популярным».
В случае если делаешь проект «для души», лично свой, то я тоже понимаю эксперименты с такими библиотеками.
В остальных кейсах, даже если форки делать, то это все равно чужой код, который нужно изучать, адаптировать, тестировать, поддерживать. Стоит ли эта красота таких денег? Если ответ да, то скорее всего в перспективе будет дешевле написать свой компонент — его поддерживать и развивать будет проще.
Это все красиво-свистопердящее надо поддерживать.
1) Никто не даст гарантий, что это завтра не сломается;
2) Никто не будет анализировать качество кода этих библиотек (с каждой версией);
3) Рано или поздно требования к приложению изменятся и придется вносить изменения в стороннюю библиотеку;
Я не призываю к полному отказу от сторонних библиотек, но каждая такая зависимость должна быть мотивирована, вписана в архитектуру и команда разработки должна быть готова взять поддержку библиотеки на себя в случае чего.
Я не вижу в этих библиотеках достаточной пользы, чтобы брать такую ответственность перед заказчиком за них.
Понятно, что любой код может сломаться, но свой код ты сам контроллируешь, можешь покрыть тестами и т.д.
Единственный плюс подборки, который я вижу — это в образовательных целях на код посмотреть.
Есть еще такая подборка: github.com/vsouza/awesome-ios. Но опять же тащить это в что-то кроме личного проекта — наверняка будет безответственно.