Комментарии 136
В основном даешь хороший умный совет, которого тебе самому хватило бы 10 лет назад, чтобы сэкономить год развития, а его не только не понимают, но еще и отрицают от незнания, и осознают только через тот самый год.
Я часто задаю вопросы по своему опроснику, но меня интересует не да/нет, и даже не столько правильный/неправильный ответ, сколько какими словами и в какую сторону человек думает.
какими словами и в какую сторону человек думает
А можете эту фразу поподробнее объяснить?
Такому человеку можно подсказать какой из его аргументов некорректен, чтобы он сразу понял ошибочность своей точки зрения. А бывает и наоборот — я могу заблуждаться, и в этом плане я тоже не держусь за свое мнение, если очевидно что есть аргументы.
Просто существует множество вайтишников с реально поломанной логикой, которых невозможно исправить.
Говорить о технической части не имеет смысла, я с первого вопроса начал угадывать.Таки вопросы были не на мидла, или не тянете на мидла, поэтому пришлось угадывать?
Мидл должен суметь ответить хоть на что-то (если дело не в волнении, бывает).
И если спрашивают на мидла — вопросы тоже должны быть адекватны, не на синьора сразу.
Ну или полный промах по языку\технологиям, тогда это и будет например косяк рекуртера.
И если спрашивают на мидла — вопросы тоже должны быть адекватны, не на синьора сразу.Очень индивидуально, при этом чем дальше, тем индивидуальнее.
Скажем 15 лет назад собеседование на миддла в пхп подразумевало, что человек знает язык настолько, что в чужом коде не встретит никогда и ничего, из-за чего придется лезть в код. При этом не требовалось ни грамма скиллов в соседних областях.
Сейчас собеседование на миддла может подразумевать, что человек не знает особенности прохода форич по массиву с попутным его изменением, т.к. «софтскиллс важнее» и вообще «это можно в документации посмотреть если надо, зачем это знать» А вот знания в соседних областях могут высоко оценить.
Отдельный вопрос теория программирования как таковая, алгоритмы и все такое. При собесе на миддла в мелких компаниях всем будет по фиг знаешь ли ты 4 алгоритма сортировки и уж тем более их сложность, при собесе в крупную компанию могут потребовать написать новый алгоритм с учетом контекста задачи и высчитать его сложность.
Ну или вообще, не читая резюме, с ходу предлагают левую вакансию (Часто — продажника или техпода), хотя в резюме прямо написано, что тебе это ниразу не интересно… и вообще вакансия на программиста…
хотя в резюме прямо написано, что тебе это ниразу не интересно…
Не пишите это в резюме. Основная часть «хедхантеров» ищет чисто по ключевым словам и текст не читает. Уберите ключевые слова и жизнь станет легче.
А то у меня тоже в резюме написано, что я люблю devops-подход (ну просто чтоб быстрее в продакшон катить) и 10 лет назад писал на питоне. А перед ссылкой на резюме у меня написано, что я сейчас не ищу работу. Угадайте, сколько и какого hr-спама мне приходит.
Спрашивают по языку, спрашивают то что есть даже в книгах (т.е. не самое свежее, что даже напечатать ещё не успели), нормально относятся к «посмотрю на мсдн», и минимум алгоритмов.
Ну и, этого я жду от адекватного тимлида. Потому что если на собеседовании у меня спрашивают алгоритм сортировки, я всегда задаю вопрос — сколько раз на проекте заиспользовали самописные алгоритмы и почему так получилось. Если тимлид может ответить на этот вопрос — отлично, а если не может — мы явно не подходим друг другу.
ПС: и да, я смогу наверное написать сортировку. Но за 7 лет работы мне не пришлось этого делать ни разу.
и да, я смогу наверное написать сортировку.
если можете написать, отчего же не написать? А вот если не написать, то возникает сомнение, что сможете написать и что-то более сложное. А если отказаться писать по принципиальным соображениям, то возникает сомнение в адекватности и подозрения в токсичности кандидата.
Но за 7 лет работы мне не пришлось этого делать ни разу.
Как-то писал сортировку то ли троек, то ли четвёрок объектов. Вызывать для них тяжёлый квиксорт претило моему перфекционизму :).
А если отказаться писать по принципиальным соображениям, то возникает сомнение в адекватности и подозрения в токсичности кандидата.
Ну, тут от вакансии зависит. На джуна можно и сортировку написать. А в случае с сеньорами, у меня бы больше возникло сомнений в адекватности кандидата, если он на такое согласится)
Как-то писал сортировку то ли троек, то ли четвёрок объектов. Вызывать для них тяжёлый квиксорт претило моему перфекционизму :).
Это несколько неадекватно, если это не является узким местом. Ради чего вы добавили когнитивной нагрузки всем людям читающим данный код, потратили время на написание самого кода, тестов на него и проведение бенчмарков? Насколько ваш код "обогнал" квиксорт на массиве из 4 элементов то?
Насколько ваш код "обогнал" квиксорт на массиве из 4 элементов то?
Quicksort рекурсивный, так что сортировка нескольких объектов будет использоваться на массиве любого размера. А с когнитивной сложностью приходится смиряться, если речь идёт о performance-critical коде (ну и библиотечные функции читают не так уж и часто). Если эти изменения действительно были полезны, конечно.
Quicksort рекурсивныйЭээ, он может быть реализован итеративно.
А в случае с сеньорами, у меня бы больше возникло сомнений в адекватности кандидата, если он на такое согласится)
Вооо! Я бы поостерёгся брать на работу такого токсичного кандидата. А то вдруг случится для него задание, которое он посчитает неадекватно простым для Своего Величия (Величества), встанет в позу и откажется работать. Да, ну, нафиг такого проблемного работника. И, это, неужели вы не видели ни разу кандидатов, подающихся на сеньоров и не умеющих при этом программировать? :)
Ради чего вы добавили когнитивной нагрузки всем людям читающим данный код, потратили время на написание самого кода, тестов на него и проведение бенчмарков?
Вообще, это я тестовый мок-стенд для экспериментов делал, было время и любопытство проверить гипотезу, вот и проверил, благо для меня написать пару реализаций простых сортировок не составляет непреодолимых трудностей, как для некоторых суперсеньоров. Код этот кроме меня вряд ли кто читал (хотя стенд, возможно, так и используется, надо бы спросить у бывших коллег). Ну, и там была строчка комментария почему так.
Насколько ваш код "обогнал" квиксорт на массиве из 4 элементов то?
Насколько-то обогнал. На память я не помню. Кстати, если бы делал не стенд, а боевую часть, то экспериментов именно в этом месте провёл бы существенно больше.
Вооо! Я бы поостерёгся брать на работу такого токсичного кандидата. А то вдруг случится для него задание, которое он посчитает неадекватно простым для Своего Величия (Величества), встанет в позу и откажется работать.
Я такое и от джуна видел.
неужели вы не видели ни разу кандидатов, подающихся на сеньоров и не умеющих при этом программировать? :)
Если человек подаётся на синьора, значит он должен приложить сколько-то лет опыта. А как он смог бы его набрать если он не умеет программировать?
Если человек подаётся на синьора, значит он должен приложить сколько-то лет опыта.
Как говорится, «должен, но не обязан»
Просто интересно как это было:
- Чел думал что умеет, а на самом деле нет?
- Чел отсортировал все возможные вакансии по з/п и выбрал "подходящую" и пришёл не зная что ещё будет техническое собеседование?
- Свой вариант...
Чел отсортировал все возможные вакансии по з/п и выбрал «подходящую» и пришёл не зная что ещё будет техническое собеседование?
Тут отнюдь не симметричные отношения.
Вы выбираете вакансию, видите точную сумму зарплаты. Это однозначное число. Ну плюс-минус 20% торга.
То есть зарплата определена довольно четко. Это всего лишь одно число. Или небольшая вилка из двух чисел.
Теперь берем ваши скиллы, которые вы продаете за эти известные деньги. Ваши скиллы кандидата в резюме (или скиллы требований к кандидату в описании вакансии) не так просто описать словами.
Словами вы разве что названия технологий можете описать точно-достоверно. JavaScript, Angular.
А вот уровень владения ими вы никак точно-формально не опишите.
Вывод:
С пониманием оценки зарплаты проблем нет.
С пониманием оценки скиллов — всё очень непросто.
Возможно, это ошибка кандидата в понимании того, что описано в вакансии.
Возможно, что это желание кандидата пройти на халяву даже туда, куда ты точно не дотягиваешь.
Возможно, что это недостаточно точно описанная вакансия (хотя как я выше написал — совсем точно вы её никогда не опишите).
Возможно, что это недопонимание фирмы кто именно ей нужен.
Вы еще можете придумать несколько таких «возможно».
Но ключевой момент тут такой:
«Ясная сумма зарплаты» VS «Весьма приблизительного описания скиллов».
Да и даже после прохождения собеседования всё равно мы имеем:
«Точная сумма зарплаты» VS «Довольно грубая оценка скиллов».
А уж что говорить о том, что понятие «сеньор» и «джун» никак не формализовано. И вы можете быть в одной фирме «сеньором», а в другую придете и там вы не более чем «джун».
Да и плюс еще узкая специализация: ваши скиллы «супер-пупер-специалиста-мега-сеньора» по Vue в фирме, работающей с Angular, а не с Vue — менее ценны. (хотя универсальные навыки, разумеется, в цене не падают).
А также не будем забывать о легкости с которой можно в ИТ чуть в более другую фирму придя и чуть более по другому поговорить — получить в 2 раза больше денег. И куча статьей как это сделать. Что стимулирует как честных, напрягающихся, подтягивающих свои скиллы, так и халявщиков-болтунов.
Если человек подаётся на синьора, значит он должен приложить сколько-то лет опыта.
Легко. Ковырял много лет однотипные сайтики-визитки в уеб-студии. Потом решил, о, я умею программировать и опыта у меня 10 лет — пойду подамся на синьора-помидора.
Ну, зачем просто сортировку… Это скучно!
Можно модифицировать. Например, "недосортировка": Нужно N результатов, накопили в массиве 4*N — и теперь нужно оставить только N лучших.
Как раз можно и про знание сортировок понять, и про глубину хода мысли тоже.
Скажем 15 лет назад собеседование на миддла в пхп подразумевало, что человек знает язык настолько, что в чужом коде не встретит никогда и ничего, из-за чего придется лезть в код.
Условие выглядит крайне странно, наверное опечатка. В гугл не придётся лезть, может?
Тут тоже эмоция, но немного другая — у фила негатив и пассивная позиция. Было бы что-то типа. "Меня размазали на собеседовании и заставили работать за еду". Тут же автор восхищен и принимает на себя ответственность за свое восприятие.
Удивительно, как каждый интерпретирует прочитанное, откуда взялось высокомерие? Лид провёл прекрасное занятие, урок, показал себя отличным педагогом. Человек увидевший высокомерие, возможно недостаточно уверен в себе, чтобы учиться у окружающих, когда появляется такая возможность.
Да тоже какой-то мазохизм: «о, я пришёл на собеседование и меня размазали, но я так рад, что не могу сдержаться». А другой человек (с другой самооценкой) увидел бы неадекватного тимлида, который зачем-то высокомерно показывает собеседнику какой он крутой и охеренный и всё знает.
О! Телепат, умеющий ставить диагнозы удаленно.
Давно хотел к вам обратиться:
Скажите, когда мне в такой ситуации было бы пофиг, то какой у меня диагноз, что там у меня самооценкой?
Пример вопроса, более чем простого, но с контекстом, который я в практике не встречал, за ненадобностью такого кода в реальной жизни. От чего быть уверенным на 100% в правильности ответа, даже в теории понимая механику работы, я не мог. Я ответил верно и это было предположение, потому что «В теории вообще-то должно быть так». Вывод в консоль?
new Promise(res => res())
.then(() => {
throw new Error('Ошибка')
console.log(2)
})
.catch(err => {
console.log(1)
throw err
})
.then(() => console.log(3))
.catch(() => console.log(4))
.then(() => console.log(5))
.catch(() => console.log(6))
Я ответил верно и это было предположение, потому что «В теории вообще-то должно быть так».
А какой еще тут может быть вариант, кроме "это было предположение, потому что «В теории вообще-то должно быть так». "?
Оба вывода ну ни разу не лестные.
Вроде как это наоборот считается признаком хорошего тона — накануне освежить в памяти ключевые моменты, не используемые на практике. Просто потому что при реальной разработке, условно, можно применять SOLID не зная, как он определяется формально.
В моей картине мира не должно быть ни капли сомнений при ответе на элементарные вопросы про базовые механизмы технологии.
Так это вопрос психологии, не знания.
В реальности такой код никто не пишет, по-этому как он работает можно знать только в теории. кому-то знания "в теории" вполне достаточно, чтобы не испытывать сомнений. Кому-то — нет.
торгуя «зеленой» древесиной и как-то сказал коллегам, что не понимает почему доски выкрашенные в зеленый вызывают такой ажиотажО какой зелёной древесине речь? В чём соль истории?
"Талеб наткнулся на комичную историю об одном из лучших продавцов древесины в мире по имени Джо Сигель. Джо Сигель однажды сказал, что не понимает, почему люди платят огромные деньги за крашеную древесину.
Сначала подумали, что Сигель шутит. Зеленой древесина называлась не потому, что она была выкрашена в зеленый цвет, а потому, что была недавно заготовлена и не успела пройти обработку и сушку"
Соль в том, что герой истории не в курсе с чем он работает, вот в разработке, на мой взгляд, такое не прокатит, не должно :)
Соль в том, что герой истории не в курсе с чем он работает, вот в разработке, на мой взгляд, такое не прокатит, не должно :)Да полно такого, интеграции с api, например. Есть интерфейс, а что за ним скрывается — неизвестно. Можно успешно пользоваться, не задумываясь что там внутри.
По сути биржевой трейдер так и делал. Если бы древесина реально крашеная была — ничего бы в байке не изменилось.
Ответ на вопрос про промисы с припиской «в теории» мне кажется вполне нормальным. Потому что «практика» подразумевает, что ты когда-то это написал и проверил. Вероятность такого КРАЙНЕ МАЛА.
Хотя сам вопрос довольно интересный, но не понимаю, почему тебя смущает неуверенность. Очевидно, что тебя не 2 + 2 будут спрашивать, а вопросы, где надо подумать.
В моей картине мира не должно быть ни капли сомнений при ответе на элементарные вопросы про базовые механизмы технологии.
Я тоже раньше так думал. А потом понял, что был скорее не прав. Если есть какой-то редкоиспользуемый и не очевидный момент в инструменте(а это справедливо для любого промышленного ЯП и фреймворка, для JS это еще в кубе), то, то что ты правильно ответил сейчас вообще не означает, что ты правильно ответишь через месяц или даже через час и vice versa. Поэтому лучше консультироваться с документацией и проверять(документация иногда лукавит, stackoverflow.com тем более). И чем лучше знаешь инструмент, тем большее количество подводных камней служат триггерами для освежения памяти.
Хотя я всё-равно в консоли проверил свой ответ :)
Но это, кмк, нормально. Если есть возможность проверить — лучше проверить, а то мало-ли, может упустил чего по невнимательности.
Вывод тут может быть только один — нужно найти по истории коммитов того, кто это написал в прод, и запинать ногами. Годится ответ?
Ну понятно же, что тут специально составленный синтетический пример, чтобы в одном вопросе проверить знание как работают промисы. Зачем ногами сразу?
Наверное, потому что этот пример ничего не говорит о знании промисов испытуемым. Если уж так надо проверить именно этот аспект языка, то надо было бы дать кусок на колбэках, например с циклами или каким-нибудь "выполняем эти два параллельно, а третий по их завершении" и предложить переделать в промисы. Из того что чел разгадает ОДНУ "головоломку" из куска кода, никак не следует, что он полностью понял концепцию. Понял именно в контексте "применить на практике". А неуверенность при разборе таких кусков "известной субстанции" — это нормально. Если бы программист всегда знал как работает его код, так не нужна была бы куча инструментов для отладки кода.
async/await позволяет писать более красивый и понятный код.
Можно ведь await поставить перед Promise.all и тогда не будет портянки then/catch.
let results = await Promise.all([
fetch(url1),
fetch(url2),
...
]);
В любом случае в приведенном выше коде не кажется, что нужны промисы.
Довольно часто вижу вот такой паттерн
const data = await fetch('/api').then(res => res.json());
Позволяет избежать создания переменной res в замыкании ради только одного использования.
Позволяет избежать создания переменной
имхо тут следует рассматривать не с точки зрения «избежать ради того, чтобы избежать», а с точки зрения «удобнее».
const data = (await fetch('/api')).json();
То же самое, только короче.
Чтобы было то же самое, нужно два await
const data = await (await fetch('/api')).json();
Чтобы было то же самое, нужно два await
поясните, плиз.
тут же фактически возможные тормоза именно из-за сети (fetch), для обхода этого ожидания и нужен await
а второй — зачем?
response.json()
тоже возвращает промис, который нужно подождать: https://developer.mozilla.org/en-US/docs/Web/API/Body/json
То же самое, только короче.
Читается хуже.
Смысла экономить байты исходного кода — нет.
В чем несоответствие то хоть было?
Был программистом Си, а пришел на Swift?
Был резчиком колбасы, а пришел на мясника?
Откуда столько эмоций на очевидных моментах?
Будешь всем рекомендовать контору, а там в рекрутерах шлак и лиды безответственные, а этот вообще из-за ухода на новое место решил выпендриваться напоследок
Я завалил собеседование на миддла за приличные деньги. И я хочу в команду к моему интервьюеру джуном за еду.
Круто, разводка у компании получилась, осталось договориться о еде, думаю на трехразовом питании сойдетесь, в неделю конечно же :)
у меня девушка была, кстати фронтэндер… она мне по началу рассказывала про каких-то мега-чуваков-исполинов разработчиков… которые крутые во всем… но конкретно в чем, сказать не могла. И я тоже не мог понять, как она смогла это понять, ибо ее компетенция оставляла желать лучшего. А как меня это поклонение абстракции выводило… жуть…
И такая ерунда смущать не должна.
Потому что у вас на завтра назначено еще 5 собеседований у конкурентов данной фирмы.
И на послезавтра еще 3.
И еще письма какие-то новые в почте, вы еще не разбирали корреспонденцию. С большой вероятностью там еще собеседования.
Ну и плюс миддлом вы стали не в одночасье, скорее всего это у не первое место работы и собеседования вы уже проходили. Чего стрессовать-то?
P.S.:
Не очень верю в миддла после одного-двух лет работы на одном месте, настоящий крепкий миддл — это 3-5 года опыта и 2-3 места работы за плечами, имхо. (могут быть исключения: если вы программируете с 14 лет, со школы, если у вас есть опыт работы над коммерческими проектами в школе или ВУЗе).
Ну а такому собеседования не страшны.
То есть тим-лид вместо собеседования провел некий коучинг.
Повезло, лиду видимо действительно было это интересно
Я на собеседованиях на синиор позиции получал «по щам» от лидов и других синиоров, и ничего, жив. У меня вообще особенность ужасная — из-за стресса после первого неправильного ответа у меня отключается мозг и память :) Но учитывая то что я работаю всё же, значит и таких психов как я может ждать успех.
К автору — работать в таких командах где много сильных сотрудников, и большие проекты это конечно мечта и довольно приятно, но рост там не такой бурный как в небольших командах с сильными коллегами, тут хочешь не хочешь прийдется расти. В идеале найти команду из 2-5 синьйоров и пилить что-то. (ну когда будешь готов)
У меня вообще особенность ужасная — из-за стресса после первого неправильного ответа у меня отключается мозг и память :)
О! Привет коллега! До боли знакомо. В октябре менял работу… похудел на 4+ кг в первую неделю из стресса связанного с прохождением интервью…
Доходило до смешного, завалил наипростейшую SQL-задачу (и естественно мне потом отказали), но ничего, сейчас работаю, условия лучшие из всех вакансий :)
Радует, что не всем нужны академические знания отскакивающие на зубок, а нужны люди, умеющие решать поставленные задачи :)
Мне вот когда-то тоже пришло приглашение на собес от интересной компании на позицию React разработчика, я вдохновился и с потными ладошками начал общение…
Провалился в первые 5 мин по базе. Хотя был уверен, что даже об объектах знаю достаточно. Сейчас смешно, а тогда я не знал даже о встроенных туСтринг)
Мне тоже сказали успокойся, всё хорошо, ты не на войне.
В итоге ещё 30 мин продуктивного общения по технологиям и в конце сразу прямой фидбек, что я ещё не дорос до боевой единицы (мидл) + полезные наставления по пробелам знаний. Даже ссылки на книги дали…
Я тогда тоже прыгал до потолка на контрасте)
Как итог, есть достаточно ответственных людей и компаний, я уверен.
Спасибо Ланит-Терком!
То, что вам попался умный и толковый интервьюер, еще ничего не говорит о фирме, так что рекомендовать ее не надо. Обычно все зависит не от фирмы, а от начальника конкретной группы, конкретного проекта.
Кажется, что ты слишком буквально воспринимаешь написанное, это в хабе «читальный зал» и посыл один, интервьюер очень достойно отвел собес, поделился опытом и направил кандидата, ему плюс, компании плюс, а кандидат доволен. Не понравилась гипербола. Ну я понял :)
Как будто Лавкрафта почитал — "а эмоции такие, что словами описать решительно невозможно, разочарование и одновременно просветление таких масштабов выходят за рамки человеческого сознания, и всю человеческую сущность переворачивают с ног на голову, обращая против нее жизненный опыт, накопленный десятилетиями, и вообще интервь'юер фхтагн" и никакой конкретики. Как бы здорово, порадовался за автора, что у него там эмоции сильные, а дальше-то что?
В теории дальше какой-нибудь лид/hr при проведении следующего интервью вспоминают яркую и эмоциональную историю с Хабр и начинают вкладываться в имидж компании делая мир лучше
начинают вкладываться в имидж компании делая мир лучше
Очень трудно представить как одно следует из другого.
Можно пофантазировать, но это больше про добро, таким образом они приносят пользу и кандидатам, как мне, например, приносят пользу компании (если допустить, что это инициатива на уровне компании и кадры там подобраны замечательно) и в целом делают рынок привлекательнее, а людей довольнее, в частности программистов, ну мир должен от этого стать немного лучше, очень хочется верить :)
В общем завалил я то интервью…
Шо это? Почему это в топе? Ниочём.
Хантил людей на очень сложном рынке, будучи руководителем филиала небольшой IT-компании без громкого имени. Собеседовал всегда лично. В чём недостаточно компетентен — привлекал опытных подчиненных. HR — только общие вопросы.
Встречались разные люди. Были и такие, с которыми сразу вежливо расставались. Полный ноль, хам, конфликтный — это сразу мимо, не отнимая времени. До проф. вопросов даже не доходили.
Но больше всего, конечно, запомнились самородки, которых удавалось откопать. Вышестоящее руководство удивлялось: «Где вы их берёте?» Вот оттуда и берём. Сидим, обсуждаем, выводим человека на решение. Даже те, кого не брали, уходили с благодарностью.
Особенно запомнилась женщина лет 30-ти, работавшая в госконторе «за еду». Тест по Oracle был очень непростой из 20 вопросов, она ответила сходу за 30 минут на 18 из них (!) Две задачи решила не идеально, но без грубых ошибок. Когда я ей озвучил сумму, которую готов предложить, она была в полном шоке.
Увы, это было моё последнее собеседование. Вместо согласования кандидата пришло известие о закрытии филиалов компании во всех регионах ((( Осталась только голова, которая сейчас дышит на ладан.
Однако я позвонил этой женщине не только для того, чтобы сообщить неприятное известие, но и потратил некоторое время на её мотивацию. Она поняла и надеюсь, что у неё сейчас всё хорошо.
После закрытия филиала нужно было искать работу, с руководящими должностями было совсем негусто, поэтому опять стал разрабом (о чём пока нисколько не жалею). Считаю, что в некоторой степени мне воздалось. За годы руководящей работы навыки были частично утрачены, но мой нынешний руководитель на собесе смог меня разглядеть. И надо сказать, это было очень похоже на то, что описал автор в статье. И волнение, и пробелы в навыках, и мысли о несоответствии искомой должности. И обсуждение, почему не так. И тонкое подведение к решению. И даже спор, в котором в итоге я оказался прав )
Разница в том, что меня всё-таки взяли и никто об этом пока не пожалел. Так что есть ещё такие компании и есть в них такие прекрасные люди. И дело тут не в должности и не в стоимости часа тимлида. Дело в отношении.
Я тоже собеседовал студента-выпускника. Он показывал проекты на Unity. Код местами даже интересный. Стал задавать околопрограммные вопросы: системы счисления двоичная, 16-ричная — плавает. IP адресация — не знает. Работа с БД — на уровне select *. Но ведь это базовые вещи! И как кто-то писал статью про современный уровень начинающих программистов — найти решение задачи в интернете, скопипастить его и заставить компилироваться (ну и работать при удачном раскладе) это могут, а разработать свой алгоритм и уж тем более архитектуру — тут затык… Печально...

Ну, слава богу, отнимать время у читателя на эти сопли уютно и не стыдно.
Собеседование на миддла за деньги, после которого я готов идти джуном за еду