Я знаю карартэ, кунг-фу и много других страшных слов!

Пришлось пособеседовать нескольких кандидатов на dev middle/senior, и т.к. в мои обязанности это не входит, и раньше я этим не занимался, то испытал некоторый бугурт, которым спешу поделиться с теми, кто заставил меня его испытать :)

Нередкая картина: приходит резюме, где от аббревиатур аж в глазах рябит, о смысле половины из них я даже не догадываюсь. Приглашаем, задаю несколько вопросов по тем трем с половиной технологиям, которые нас интересуют, и вижу что знания в лучшем случае на уровне хеловорда, а чаще на уровне прочтенной когда-то статьи на вики.

Я не знаю, может в остальных пятидесяти технологиях он шарит как гуру, но, блин, во-первых мы в вакансии четко написали, что нам нужно, а во-вторых нахрена ты пишешь в резюме название языка или технологии только потому, что знаешь как расшифровывается ее название? В итоге тех, у кого все резюме пестрит заглавными буквами при возрасте менее 30 лет даже не приглашаем.

Тоже частая картина: аббревиатур поменьше, знания получше, но до мидла все равно как до луны. Я все понимаю, молодость, кровь бурлит, хочется узнать побольше нового, но, блин, ты потратил на базовые знания кучи технологий столько времени, что мог уже быть сеньором, а подходишь только на позицию продвинутого джуна. Самому не обидно?

Найти специалиста, который по паре-тройке смежных технологий готов был бы сходу сеньорствовать почти невозможно вне зависимости от предложенной зарплаты. 99% кандидатов предпочитают вообще ни во что не погружаться глубже, чем по колена, зато, блин, резюме похоже на китайский манускрипт.

Что за паскудная тенденция?

P.S. Сегодня неожиданно вышел на контакт довольно молодой паренек, с одной стороны с немаленьким списком баззвордов, а с другой — отлично шарит в том, что нам нужно. Говорит, что узнал о наличии такой вакансии из данного топика, а дальше было только делом техники идентифицировать ее на сайтах поиска работы. Не зря, значит, я тут баттхертил :)

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Сидишь значит на работе, типа развиваешься в профильной технологии между делом, тут к тебе приходят и грят «значит так, теперь мы еще должны пофиксить вот это, оно на XXX» — «эмм, а я тут причем?» — «ты специалист или куда? — разберешься». Фиксишь. Фиксить шо-нить на незнакомом языке или фреймворке — проблема, но не такая уж большая. Время тратится, да. И шо с этим делать? — писать в резюме — не очень правильно, собеседование не пройдешь, не писать — глупо, все же этим занимался.
***
Или так: приходишь на собеседование, а там чувак выполз из своих странных тасков и спрашивает... странное. Ну то есть вообще в этом разобраться — 20 минут, но если каждый день этого не видеть, то забыть очень легко, потому что нафиг не надо. Хотя казалось бы элементарные штуки. В итоге чувак в непонятках «как так, как можно не знать того что я каждый день вижу», и ты в непонятках: «что это вообще было?».
***
И еще(реальная история):
Рекрутер: добрый день, у нас есть вакансия надо XXX YYY
Я: XXX видел, пару лет назад, YYY — не особо. Но вообще интересно
Рекрутер: ок, а опыт управления командой у тебя есть?
Я: ага
... технический допрос (понятно шо за давностью, не все вспомнил) ...
Рекрутер: к сожалению у вас немного не хватает знаний для позиции Team Lead’а.
Я: ... (афигеть, я об этом говорил с самого начала, хотя если «немного не хватает», то я вообще офигенно крут)

Если бы на работу принимали технари, было бы как вы хотите. Отпала бы необходимость во вранье и реверансах. Пример: «надо фиксить JSP-ки старые, денег столько-то», чувак посмотрел и пошел или не пошел. Улавливаете мысль?

Сейчас фреимворки и технологии настолько часто меняются, что задрачивать их до уровня настоящей синьйорности часто бессмысленно. Даже такой, казалось бы, основополагающий гранит как SQL — нынче не в моде.
Во вторых для большенства работы на рынке синьйорность по конкретной технологии и не нужна. Куда более ценное возможность быстро включиться в новую технологию, сделать как-нибуть но быстро, нагуглить решение, почитать сорцы чтобы найти решение, итд.

Классика уже была?
МОЛОДАЯ ДИНАМИЧНО РАЗВИВАЮЩАЯСЯ КОМПАНИЯ ОПЫТНЫЙ ПРОГРАММИСТ НЕ СТАРШЕ 15 ЛЕТ JAVA SENIOR DEVELOPER 8 ЛЕТ СТАЖА, УМЕНИЕ РАБОТАТЬ В КОМАНДЕ GIT + SUBVERSION + BZR + ЗАДРОТ-VCS-0.2 PHP ZEND PYTHON СПРАВКА ЧТО НЕ ВЕРБЛЮД КОММУНИКАБЕЛЬНЫЙ, ОТВЕТСТВЕННЫЙ, ЦЕЛЕУСТРЕМЛЕННЫЙ ВЫСШЕЕ ОБРАЗОВАНИЕ КО-КО-КО НАВЫКИ ПОЧИНКИ КОМПЬЮТЕРА, РЕМОНТА РЕАКТИВНОГО ДВИГАТЕЛЯ, РЕАНИМИРОВАНИЯ ЯЩЕРИЦ С БОЛЕЗНЬЮ АЛЬЦГЕЙМЕРА, АНГЛИЙСКОГО, МАНДАРИНСКОГО И ЭЛЬФИЙСКОГО ПРИВЕТСТВУЮТСЯ СТАЖИРОВКА 25 ЛЕТ В КРЕДИТ ЗП ОТ 15т.р. КАРЬЕРНЫЙ РОСТ (НЕ РАНЕЕ ЧЕМ ЧЕРЕЗ 10^24 ЛЕТ) ВОЗМОЖНО ДОПОЛНИТЕЛЬНО ВЕРСТКА НА HTML CSS3 JAVASCRIPT JAVASCRIPT JAVASCRIPT NODEJS JS JSJSJS PHP, КАНДИДАТЫ С ТРЕТЬЕЙ ГРУППОЙ КРОВИ НЕ РАССМАТРИВАЮТСЯ, ВХОД С ТОРЦА ЗДАНИЯ СКАЗАТЬ ОХРАННИКУ, ЧТОБЫ ОТКРЫЛ ПОРТАЛ ПРОИЗНЕСТИ OVUS SORARE NIHIL SANCTI MORTUM EST 13 РАЗ ПРОТКНУТЬ ЛЯГУШКУ ОТВЕРТКОЙ (ЛЯГУШКА ВАША) 3 ЭТАЖ «ООО» «E-BAILEN-Soft»

Что за паскудная тенденция?
Приходится продавать то, что покупают. Вот когда HR’ы перестанут покупать аббревиатуры — тогда их и перестанут продавать. Пока же в большинстве вакансий куча баззвордов, фронтендщику будет плюсом знание бэка, бэку знание С++, приходится в резюме эти баззворды вставлять.
А ещё, возможно вы неправильно ищете. Чтобы работать с той или иной технологией, нужно понимать основные концепции, а не знать всё. Знает всё документация. Взять тот же JS (node особенно). Сколько всего пакетов в npm? Я не знаю, но даже если посмотреть на первые пару страниц most starred (www.npmjs.com/browse/star) — жизни не хватит, чтобы знать всё. Вместе с тем, для работы знать и не нужно, нужно помнить названия полезных пакетов или даже просто помнить что такой пакет есть (а если что-то существует — это можно загуглить). А освободившееся в памяти место занять правильной архитектурой проекта например.
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Избыток аббервиатур в резюме — ответ на завышенные требования

Классика уже была?
МОЛОДАЯ ДИНАМИЧНО РАЗВИВАЮЩАЯСЯ КОМПАНИЯ ОПЫТНЫЙ ПРОГРАММИСТ НЕ СТАРШЕ 15 ЛЕТ JAVA SENIOR DEVELOPER 8 ЛЕТ СТАЖА, УМЕНИЕ РАБОТАТЬ В КОМАНДЕ GIT + SUBVERSION + BZR + ЗАДРОТ-VCS-0.2 PHP ZEND PYTHON СПРАВКА ЧТО НЕ ВЕРБЛЮД КОММУНИКАБЕЛЬНЫЙ, ОТВЕТСТВЕННЫЙ, ЦЕЛЕУСТРЕМЛЕННЫЙ ВЫСШЕЕ ОБРАЗОВАНИЕ КО-КО-КО НАВЫКИ ПОЧИНКИ КОМПЬЮТЕРА, РЕМОНТА РЕАКТИВНОГО ДВИГАТЕЛЯ, РЕАНИМИРОВАНИЯ ЯЩЕРИЦ С БОЛЕЗНЬЮ АЛЬЦГЕЙМЕРА, АНГЛИЙСКОГО, МАНДАРИНСКОГО И ЭЛЬФИЙСКОГО ПРИВЕТСТВУЮТСЯ СТАЖИРОВКА 25 ЛЕТ В КРЕДИТ ЗП ОТ 15т.р. КАРЬЕРНЫЙ РОСТ (НЕ РАНЕЕ ЧЕМ ЧЕРЕЗ 10^24 ЛЕТ) ВОЗМОЖНО ДОПОЛНИТЕЛЬНО ВЕРСТКА НА HTML CSS3 JAVASCRIPT JAVASCRIPT JAVASCRIPT NODEJS JS JSJSJS PHP, КАНДИДАТЫ С ТРЕТЬЕЙ ГРУППОЙ КРОВИ НЕ РАССМАТРИВАЮТСЯ, ВХОД С ТОРЦА ЗДАНИЯ СКАЗАТЬ ОХРАННИКУ, ЧТОБЫ ОТКРЫЛ ПОРТАЛ ПРОИЗНЕСТИ OVUS SORARE NIHIL SANCTI MORTUM EST 13 РАЗ ПРОТКНУТЬ ЛЯГУШКУ ОТВЕРТКОЙ (ЛЯГУШКА ВАША) 3 ЭТАЖ «ООО» «E-BAILEN-Soft»

Черговий абстрактний вкид з бла-бла-бла ні про що. Найбільше, що дратує в нашому IT, — це обмеженість. Один сидить сапортить старе «працює не чіпай» на першій-другій яві з біндінгами в плюси і вважає що розуміється на тому, як працюють всі інші, другий накидає сайти і вважає, що розуміє проблеми «паяльників». Веб-манагери манаґєрять плюсовиків і дивуються результату. В сусідньому топіку мешканці Васюків досліджують перспективи тих самих плюсів у світовому масштабі. Насправді ж, без деталів будь який топік про роботу це срач ні про що. Щоб там не напарювала «універсальна» тусовка, люди — різні, проєкти — різні, а досвід — завжди персональний і обмежений.

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

Не пойму я наверное подобных топиков. Если надо готового специалиста, почему его не вырастить у себя и мотивировать, что бы он не перешел к конкурентам? Тогда будут прямые рекомендации, и не нужно будет покупать кота в мешке. Если специализация узкая — отдайте на аутсорс. Удивляет обилие вакансий мидл/сеньер. Это недосмотр стратегического планирования или банальная жадность? При таком количестве желающих программировать, при таком уровне зарплат все вакансии должны были бы закрыться за год. ИМХО, взгляд с другой специальности.

Ну не только жадность. Тут ещё дело в том, что надо на сейчас, а что бы вырастить на сейчас, то надо было с пол-года — год назад угадать что надо будет сейчас. А оно далеко не всем даётся. Ростить — это вложение. Ростить специалиста и не угадать какого — убытки. Потому и желающих угадывать всё меньше.

Причем для того, чтобы растить специалиста, нужны проекты на несколько лет, кои в аутсорсе редкость.

истинно так :)

Ага еще в вакансиях пусть тоже не пишут все известные аббревиатуры, ато выходит “ПОДВОДНЫЙЭЛЕКТРОГАЗОПАРИКМАХЕР”. Т.к. судя по требованиям некоторых вакансий должен быть специалист в администрировании всего и иногда надо уметь еще и чайник починить, вот пример такого бреда, тут минимум 5 в 1 Windows админ, Linux админ, админ БД, сетевик, телефонист + продукты специфичные для DevOps:
You have several years of relevant work experience in the software engineering field.
You are experience with next list:
— VMware, own cluster
— Linux, mostly Ubuntu. Slackware and BusyBox from third-party providers.
— Windows Server 2008/2012
— MS SQL 2008/20014
— Solr, MongoDB, Memcached
— IIS, NGINX, Apache, lighthttpd, Tomcat
— Microsoft AD, DNS, DHCP, Failover Cluster, GPO, Network Policy Server
— Integration with AD, TACASC+
— Zabbix, monit
— TeamCity
— GIT (gitolite)
— Atlassian — JIRA, Confluence, Crucible, FishEye, ServiceDesk
— Chef
— Akamai CDN
— VoIP, FreePBX
— Fusion Inventory
— OTRS
— Cisco Catalyst 2960, Cisco Catalyst 3560, Cicso ASA 5510, Cisco ASA 5585, Cisco 7301, Cisco WLC 4400, — Cisco WLC 2100, Cisco Aironet 1140, Cisco Aironet 3600
— IPSec, 802.1X
— Dell PowerEdge servers
— MS Office 365, MSDN, Microsoft licensing
— If you have approximately 2/3 skills from that list or you are a real expert in one of Windows/Linux/Network and you have strong basic level in others, you should try to apply for this position.

Если бы водителей нанимали как программистов, то описание вакансии было бы примерно такое:

Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны.
Опыт управления болидами «Формулы 1» — приветствуется.
Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей.
Опыт проведения кузовных и окрасочных работ — приветствуется.
Претенденты должны иметь сертификаты Mercedes, BMW, General Motors, а также справки об участии в крупных международных соревнованиях не более, чем двухлетней давности.
Зарплата: определяется по результатам собеседования.

И снизу приписочка, мелким шрифтом про должностные обязанности: водить придется мопед, иногда даже носить посылочки пешком.

Я на днях гуглил англоязычный сайт вопросов и ответов по поводу программирования. То что я там увидел меня шокировало — куча людей советуют учить по пару языков сразу, советуют каждый год изучать новый язык("для расширения сознания") и вообще никуда не углубляться, ибо инжынер то вам не код манки и нафиг не сдалось. Вот так вот. Доходит до абсурда когда человеку советуют учить сразу и мобайл(андроид, иос) и веб. Мультикодер.

Ну тут один товарищ доказывал что есть некое научное исследование на эту тему, что мол так лучше учится.

Какой смысл учить все подряд? Как там сами же говорят что хорошему программисту выучить еще один язык или фреймворк не предоставит труда. Тогда почему нельзя быть профи в чем то одном, а даже если эта область/язык накроется то за месяц переучиться на другое.

Я так понимаю там у них тренд выучить синтаксис языка и гордо заявлять «я знаю +1 язык».

Ага, лучше, забить голову всем подряд чтобы и без того каша превратилась в болото. В итоге на каком языке, в каком стиле человек будет программировать?

В целом полезно знать больше двух достаточно разных языков.
Тогда будете на новых языках в их стиле, и осваивать будете очень быстро.

Тогда будете на новых языках в их стиле, и осваивать будете очень быстро.

Знание C++, Java и C# не сильно поможет в освоении, скажем, Хаскелля, сильно лучше, чем знание одного лишь C++.

Я же написал, достаточно разных.
К примеру С++ , скала, питон.

Ага, лучше, забить голову всем подряд чтобы и без того каша превратилась в болото.

Нет. В результате такого освоения найти своё, и в большинстве случаев это не язык и не фреймворк, а тематика. Кому-то веб и фронтэнд, кому-то сетевые сервисы, кому-то математика или бухгалтерия.
Имея тематику и знания в ней, уже практически неважно, на каком языке её реализовывать — важнее куча других аспектов. Например, в data mining все языки должны в итоге сводиться к высокооптимизированным библиотекам, даже если на верхнем уровне это весь из себя динамический Питон или JS, а в сетевых сервисах важнее эффективное ожидание внешних событий и минимизация контекста одного клиента, чем тяжёлые раздумья вида «Java или C++».

Хотя, согласен, это стратегия не для 23-летнего outstaff-сеньора. :)

В итоге на каком языке, в каком стиле человек будет программировать?

На тех, что лучше в конкретный момент под конкретную ситуацию.

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

Часто это вполне нормально — когда реализация предметной области важнее стиля конкретного языка.

Я таким образом недавно сделал версию своего проекта на C++, который был в чистом виде «C с классами», и только после этого стал дополнять реальными фишками C++ :) и зато оно заработало сразу, а не после 2-3 лет курения Александреску с компанией (или, альтернативно, пересадки на проект некоторых спецов по C++, которые не знали в целевой тематике ни шиша и полгода бы в неё врубались).

Та я знаю что теперь это нормально овнокодить. Бизнес требует. Потому и пошла мода на мультипрограммистов.

OK, договорились (кроме моральной оценки, но не фатально для данного треда).

C с классами
а не после 2-3 лет курения Александреску с компание
Во многих проектах сознательно отказываются от шаблонного метапрограммирования. Ембедд и околоембедд вообще по MISRA C++ стандарту и иже подобным пишут.

Есть язык, у него есть возможности, ими можно пользоваться. Есть общие рекомендации от «давать вменяемые имена переменным» до «делать одну вещь, но делать ее хорошо».

Все остальное — ересь для построения храма собственной исключительности. Потому что если вдруг окажется что ничего в этом вашем JS/PHP/Java/Ruby/Python/whatever нет, и любой чувак который вообще писал код на чем угодно, с гуглом и такой-то матерью на второй день знакомства сможет вполне успешно суппортить этот код, а через месяц-другой и писать новый, то корона исключительности упадет.

Короче я с этим тезисом не согласен, но исследований я не проводил для обоснованности моего не согласия

Как там сами же говорят что хорошему программисту выучить еще один язык или фреймворк не предоставит труда.

Нет. Точнее, получится на уровне «писать на новом языке как на старом». Чтоб выучить все преимущества нового языка, новую парадигму — пары месяцев мало. Иногда и года мало — учитывая, что этот год язык не учится каждый день, а используется собственно на практике в каком-либо усечённом варианте.

Я так же думаю, но нынче мода считать что умеешь писать на десятью а то и более языках. Кто то годами не может полностью понять джаву, а кто то за 2 года уже «выучил» 5+ языков.

а кто то за 2 года уже «выучил» 5+ языков.

Да пусть себе «учит». Потом засыпется на первом же собеседовании по любому из них.

Это могли написать фрилансеры, где их умения никто особо и не может проверить. Была тут тема как человек за месяц пошел овнокодить на вордпресе за большие деньги. И пофиг как, главное шо работало. Хотя кто их знает. Но тем не менее гугление показывает что специалисты и там нужны. Но встречал один забавный комментарий — «вакансии где ищут разработчиков под Х я откидаю в первую очередь». Типа я архитектор епта, не надо мне тут требовать несколько лет опыта на одном языке.

Была история как в Киевском Самсунге хотели по-быстрому синьйоров с Java пересадить на С++

Очевидно что такая идея потерпела фиаско.

Ужасно то что такая идея вообще была. Сегодня пересадить на с++, при том желать иметь таких же сеньйоров но уже в с++, завтра захотелось что то другое и пересадить на го, послезавтра еще на что то.

Разве? Я понимаю что сейчас модно говорить про рабов на галерах, но за синьйоров сейчас такая конкуренция что все просто поувольняются и перейдут к конкурентам.

Здесь ты сеньор, а на собеседовании в другую контору джун.

Ну значить такой был сеньер, нет?

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

Зависит от технологии. PHP или древние JSP и прочее.

Была история как в Киевском Самсунге хотели по-быстрому синьйоров с Java пересадить на С++

Кстати, а в обратном направлении могло бы и получиться.

Ну скажу по своему опыту — переучиваться с одного основного стека технологий на совсем другой может оказаться и не так просто. Можно подзабыть как это надо учиться с нуля. Можно не правильно оценить свои силы и это может демотивировать.

Когда постоянно что-то новое учишь — оно намного легче.

Программист и так должен постоянно учиться чтобы повышать квалификацию в даже одной области с одним языком и не ввпасть, так что не аргумент

Программист и так должен постоянно учиться чтобы повышать квалификацию

Только рекрутёров потом не устраивает результат в виде «я учил это самостоятельно».

А как можно выучить «не самостоятельно»?)

Попасть на продакшн, который надо поддерживать на этом самом языке.
Под «самостоятельно» я имел в виду, что нет внешних стимулов учить и применять, и твой опыт на этом языке ограничен лишь твоими поделками. «Студенческий» или даже «школьный» вариант.

Попасть на продакшн, который надо поддерживать на этом самом языке.
Как же ж на него попасть ,если у тебя нет опыта на этом языке?)
Как же ж на него попасть ,если у тебя нет опыта на этом языке?)

Варианта по большому счёту два — или тебя берут на этот проект «за мозги» с тем, чтобы ты быстро выучил язык (но на такое обычно идут не бодишопы, а продуктовые компании) — или ты на каком-то этапе своей карьеры саппортишь проект из двух языков, и этот второй также упоминаешь в своём резюме, а потом тебя уже берут именно на него.

Получается по вашим словам- построение карьеры- это броуновское движение.
Достаточно случайное..

или ты на каком-то этапе своей карьеры саппортишь проект из двух языков
или нет, как повезет.
построение карьеры- это броуновское движение.

Открою тебе секрет — весь мир есть броуновское движение. Тем не менее, людям удаётся как-то строить устойчивые конструкции. Как это у них получается, интересно? :)

Ага, прям как в цитате с баша:
«Мне недавно рассказали как делают корабли в бутылках. В бутылку засыпают силикатного клея, говна и трясут. Получаются разные странные штуки, иногда корабли.»

Весь успех жизни человека- упирается в проблему выбора, на самом деле:
Например:

Проблема выбора автомобиля

1. Год выпуска.
а) б/у гомно — будут сыпаться
б) новые гомно — тоже будут сыпаться, да еще и дорого

2. Страна-производитель
а) немецкие гомно — нет настоящего японского качества
б) японские гомно — нет настоящего немецкого качества
в) корейские гомно — нет вообще никакого качества
г) французские гомно — потому что гомно и все
д) американские гомно — потому что нет ни японского, ни немецкого качества
е) китайские гомно — тут вообще все ясно, даже говорить не о чем.
ж) наши гомно — ну не могут нормальные машины делать в стране, где медведи ходят по улицам

3. Двигатель
а) Бензиновый гомно — жрет много
б) Дизельный гомно — ремонтировать дорого
в) Гибрид гомно — батареи бешеных денег стоят
г) Газ гомно — непременно взорвется и воняет

4. Коробка передач
а) Ручка гомно — ее надо все время дергать, да еще и сцепление менять иногда
б) Роботизированная ручка гомно — дергает на переключениях и вообще ни фига не автомат
в) Автомат гомно — переключает не то и не туда, и ремонтировать дорого
г) Вариатор гомно — непременно сдохнет

5. Привод
а) Передний гомно — непонятно, как из заноса выходить
б) Задний гомно — непонятно, как в занос не попасть
в) Полный гомно — вообще ничего непонятно, обязательно убьешься

6. Кузов
а) Седан гомно — холодильник не влезет
б) Хетчбек гомно — багажник маленький
в) Универсал гомно — на фига этот сарай
г) Купе гомно — назад лезть неудобно
д) Кабриолет гомно — дует
е) Автобус гомно — большой слишком

7. Класс авто
а) А гомно — мопед с крышей
б) B гомно — едет как мопед, жрет как машина
в) C гомно — типа большой, а на самом деле маленький
г) D гомно — думали, это почти Е, а оказалось, это большой C
д) E гомно — ну и как парковать эту корову?
е) F гомно — вы видели, сколько оно стоит?

8. Руль
а) Правый гомно — обгонять не получится
б) Левый гомно — дорого и нет настоящего японского качества

9. Прочее
а) Тонировка гомно — ничего не видно
б) Отсутствие тонировки гомно — все видно с улицы и жарко

Вміння розбиратися в сортах гівна — це вже половина успіху, вміння зліпити щось корисне з нього — це неймовірний успіх і трохи вдачі :)

Т.е. попасть на продакшин с древней джавой более полезно нежели учить ее самостоятельно, учить актуальные версии?

С точки зрения востребованности на рынке труда — получается так.

Учиться в глубь там где ты уже мастер и учиться чему-то совсем новому с нуля это 2 большие разницы.

Ну пусть каждый учится как хочет, и что хочет. Не баранчики чтобы все одинаково делали.

советуют каждый год изучать новый язык
Ну тут нужно понимать что популяризировал эту идею чувак, который пишет книжки про языки программирования :) (если что: David Thomas, серия Pragmatic Programmer)

Отлично, безоговорочно принимаем на веру. А другой чувак который с++ написал говорит что надо выучить 5 языков. Третий чувак тоже какой то список дал что надо выучить каждому. Становится трудно поклоняться каждому богу.

я о том что ему вообще выгодно чтобы Вы не останавливались на первом попавшемся языке, а продолжали покупать книжки про новые.... :)

А вообще если серьезно, то вспоминается еще одна старая статья, ESR’а, написанная задлого до «войти в айти», пресловутого рынка и прочего: www.catb.org/.../faqs/hacker-howto.ru.htm Соответственно автор концентрируется на «научится программировать», а не на «быть конкурентноспособным на рынке».

Между всем остальным там есть совет обратить внимание на четыре языка: Python, C, Perl, и LISP. Python vs. Perl возможно с точки зрения текущего времени несколько избыточно(хотя, до сих пор определенная логика в этом есть). Идея в том чтобы посмотреть на разработку с разных позиций, посмотреть на разные подходы, получить в своем арсенале разные инструменты. Но... это не рыночный совет о том как пройти собеседование и не иметь проблем с работой :)

Ну вот подтверждение что советы это всего лишь советы. Кому какие языки понравились тот их и сует в советы «Выучи ибо не будешь тру!!11».

Идея в том чтобы посмотреть на разработку с разных позиций, посмотреть на разные подходы, получить в своем арсенале разные инструменты

Это хорошо, но лично мне сначала надо понять хотя бы полностью ООП, а не только синтаксис для его использования. Хотя на данный момент я не вижу смысла разбираться в парадигмах функционального или там процедурного программирования. В большинстве областей разработки теперь рулит ООП. Я как типичный разработчик на технологии Х под платформу Х буду учить то что решат те кто создают технологии. Если завтра решат что фигачить апы надо в функциональном — ну что ж, возьмусь. А пока что слава ООП. Ну а использовать малопопулярные языки программирования не то чем должен заниматься типичный разработчик. Если уж и выбирать это для проекта то кем то уровня сеньер минимум. Создают каждый год какой то очередной язык в надежде что он выстрелит, а по факту нафиг не нужен. А за фреймворки так вообще. Сущий бардак в айти.

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

Ну вот подтверждение что советы это всего лишь советы. Кому какие языки понравились тот их и сует в советы «Выучи ибо не будешь тру!!11».

Мне не нравятся LISP и JS, но я их «сую в советы». ЧЯДНТ? :)

Это хорошо, но лично мне сначала надо понять хотя бы полностью ООП, а не только синтаксис для его использования.

«Полностью»? Тогда нужен как минимум один язык с ООП на внешнем треде (C++, Java, C#, JS, Python — все одинаковы) и ООП «рыбы в аквариуме» (Smalltalk, Simula, с заметной натяжкой — Erlang).

и есть ruby- похож и на верхних и на нижних..

Да как-то не очень похож. Скорее как какая-то странная отдельная сущность, ещё и с диверсиями типа «скобки при вызове можно не писать»

Python vs. Perl возможно с точки зрения текущего времени несколько избыточно

В современном мире таки надо заменить Perl на Javascript и добавить на выбор Java или C#. Хотя это уже 5 языков ;)

Java вместе с C# - это полтора языка, имхо :)

Именно поэтому «или»

там не давно вторая часть вышла так в сумме 14 уже!

да я в общем то глянуть хотел а не отзывы услышать )))

Ну как бы, для работы в вебе нужно знать минимум 3 — JavaScript, SQL и любой серверсайд. Конечно можно обойтись только JS, но те кто прогаммировал только на js это не программисты.

То есть чистых бэкэндщиков не бывает и всех заставляют кодить на JS?

SQL
мне казалось что это даже не обговаривается. Это даже за язык отдельный нельзя назвать. Так же ясное дело что надо еще кому то хмл знать а кому то хтмл и ксс. Вопрос в языках которые нафиг не сдались в области.
те кто прогаммировал только на js это не программисты
тем не менее вакансий на фронт-енд куча. Фронт уже давно не джейквери. На джеквери и я могу наляпать что то.
Это даже за язык отдельный нельзя назвать.
вы явно тригеры и хранимые процедуры не писали

Не писал. Я о базовом знании которое любой программист должен иметь. А углубляться ли дальше покажет место работы.

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

Суть не только в знании SQL(и да, не надо всех ровнять, я про джоины), а и в умении проектировать базы данных

обычно познания заканчиваются
ну раз заканчиваются значить в данный момент для работы человеку больше и не нужно. Мало ли.
а это как бы вообще ни о чем
ой, ну, не. если это ни о чем, то как тогда назвать «писал селект с несколькими джойнами, в итоге отъедает кучу памяти, а агрегация уже клиентским кодом делается»? дно дна?
если ставить планку «0» слишком высоко, понадобятся подземные этажи

видел такое.... ну это уже не столько не знание скл сколько общее дно

полноценный язык
то, как оно будет работать, это другое дело

«У меня полноценная жена. То что она не умеет готовить кушать, пъет и наркоманка — это другое дело»

Фронт уже давно не джейквери.
Фронт — это UI на 50-70%. А UI — это часто таки jquery.

Все движется к полноценным фронт-енд фреймворкам как ангуляр. Фронт все больше будет похож на мобильные апы, а бек енд все больше на апи сервисы для этих апов. Я даже верю что джаваскрипт скоро заменят на компилируемые языки и эти апы будут скачиваться с сайта только 1 раз а не каждый раз тянуть кучу файлов. И власть имущие в айти таки шото такое и затеяли, по крайней мере дать выбор с других языков не только джаваскрипт.

Я даже верю что джаваскрипт скоро заменят на компилируемые языки и эти апы будут скачиваться с сайта только 1 раз а не каждый раз тянуть кучу
файлов
Можно с этого места поподробнее?

ну веб ассемблай же..

Если я правильно понял суть технологии, то разработчик пишет код на своем языке, он компилируется в промежуточный код(на подобии MSIL), а браузер будет его выполнять (как CLR)?

Да. Сейчас, кстати, происходит почти то же самое (в прогрессивных браузерных движках), только браузер получает исходный код и компилирует в промежуточный на клиентской стороне. Иначе скорость выполнения JS была бы совсем тоскливой.

джаваскрипт скоро заменят на компилируемые языки и эти апы будут скачиваться с сайта только 1 раз а не каждый раз тянуть кучу файлов
application cache + http2 ради передачи кучи файлов в одном подключении + html import ради внедрения сразу целого компонента через единую точку входа
можете использовать TypeScript/CoffeeScript поверх JS. Типизация, компиляция, как и хотели.
или вам именно в формате «для нормальной работы нашего сайта вы должны установить вот этот вот скомпилированный bundle с yandex bar’ом внутре»? :)

Можете использовать сколько угодно костылей, но это все так же будут джаваскрипт файлы, а не полноценное приложение на нормальном языке.

TypeScript/CoffeeScript поверх JS

Ну так в том то и дело что джаваскрипт уже давно пытаются заменить. Спасибо что только что подтвердили мое мнение о данном тренде. Кстати ангуляр 2 уже на тайпскрипте. Тоже ищут замену джаваскрипту. Так вот чтобы не писать такие обертки-костыли можно просто дать возможность писать код на других языках и обеспечить возможность браузера его исполнять. Что собственно и будет сделано.

или вам именно в формате «для нормальной работы нашего сайта вы должны установить вот этот вот скомпилированный bundle с yandex bar’ом внутре»? :)
Не знаю как комментировать этот бред(вброс).
а не полноценное приложение на нормальном языке
можете дать определение «полноценности»?

Скачиваемый пакет с точкой входа. То чем являются мобильные приложения, к примеру. А не просто как кусок вспомагательного кода на странице, взаимодействующий с разметкой через опять же костыли.

просто как кусок вспомагательного кода на странице
Так броузер является недостающим звеном..

так такое уже имеется.
называется «просто приложение». пишется на компилируемом языке. выполняется изолированно(насколько возможно) от других приложений.
для решения проблемы актуальности(обновлений) используются всякие пакетные менеджеры с соответствующей инфраструктурой. apt, appStore, playMarket, windowsStore или как там его.

apt, App Store, Play Market и Windows Store.

(жабо-нонация — не та вещь, которую нужно тянуть в человеческий разговор)

простите великодушно, уже не могу исправить комментарий по причине истекшего срока давности

Вот именно. И пофиг как быстро работает скриптовый движок, если для перемещения одного объекта интерфейса нужно целиком нагрузить многогигагерцовое ядро процессора.

>ищут замену джаваскрипту
>тайпскрипт
Ничего, что тайпскрипт — просто диалект жс и он, не поверите, все равно компилируется в жс? замена от б-га просто.

тайпскрипт это замена джаваскрипту, как его не называйте.

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

Не вижу проблемы.
Вы просто не умеете их готовить ©
Тем более забавно слышать упреки в сторону жс от пхпшника :)

забавно слышать упреки в сторону жс от пхпшника :)

Джаваскрипт не стоит сравнивать с пхп, ибо даже по сравнению с пхп это плохой язык :)

Так а чем конкретно он не угодил? Правда интересно.

судя по постам в духе «недоязык», «написан на коленке», «перейду на нормальный язык», просто не нравится. концептуальное неприятие.

На каком языке пишите вы? Хотелось бы узнать.

На пхп и джейквери. Но если получится теперь доучить нормально и закрепиться в этой другой области то буду на отличном языке писать, кстати тест на него уже сдал на 1.7 из 5 на апворке, при том что последний раз изучал его и чуть писал(малый пет проект) более полу года назад и теперь за пару дней прошел базовый туториал, повторил изученое и нового набрался.

на отличном языке писать
на каком ?

Какая разница? На том который мне более нравится и который я считаю лучше пхп и джаваскрипта. Если все получится то впишу тут в профиле джуниор Х девелопер ет апворк) А нет то увы( Хотя все должно быть.

Так хочется знать,какой в вашем понимании нормальный язык программирования :) Можете написать в приват если это так «секретно» ))

скорее всего какой-нибудь компилируемый -андроид или свифт..

Что толку от asm, если потом все равно js?

asm.js мягко говоря не читабелен, так что вы получите свой код + скомпиленный в сабсет джса который херово читается, но зато работать будет быстрее

но все херня, ждем вебассембли

А ведь ТАК распиарить вакансию — это еще не каждый сможет ;)

Что за паскудная тенденция?
+
Полностью поддерживаю вашу мысль, у нас так и есть. Кадровику запрещено фильтровать резюме каким-либо образом, его работа — вести первоначальную переписку и согласовывать время интервью.

Вы сумеете сложить 2 +2 или нужно помочь ? ))

Ну вообще-то никто не требует, чтобы кадровик перед предложением прийти на интервью не спрашивал кого-нибудь технического «а этот хоть на что-то выглядит?»

У Вас тут хрень какаято с падежами — я не могу понять что Вы хотели этим сказать )

Падежи все правильные на правильных местах.

все.

кришназевул 3-го ранга в Дарницкие пещеры
теперь понял )

Жаль. Забрали такой шанс написать «Я уже и сам не понимаю»...
:trollface:

падежи норм, пару запятых не хватает, но смысл уловить можно

Хм, про запятые я бы таки послушал подробнее :)

Так это нормально. Приходилось собеседовать тестировщиков, вспоминается такой момент: у кандидата в резюме написана ISTQB сертификация. Я как раз к ней активно готовился, думаю — о, как раз пообщаюсь с человеком, заодно и себя проверю. Начинаю задавать вопросы — без подковырок, по базовым вещам. Получаю в ответ грустный взляд и «эээээ» вместо ответа. Спрашиваю — ок, мэн, у тебя написана сертификация, почему ты не можешь ответить на простые вопросы по материалу, изложенному в доках по подготовке к ней же? В ответ: «Ну, я пару лет назад сдавал, всё забыл уже...» Вывод — человек сдавал по системе 3-х «З»: «Зазубрив, здав, забув». Так нафига ж ты её пишешь, если не можешь подтвердить эти знания? Надеешься, что интервьюер будет вдохновляться мощью резюме и не проверит, можешь ли ты ответить за то, что там написал? Смешно, право слово...
И такой случай в моей практике интервьюера — отнюдь не единственный.
У кандидата указана Java. Говорю — оки, bubble sort написать сможешь? Не, говорит, не могу. Так какой же ты в пень автоматизатор, если не можешь простейший алгоритм реализовать? Таких, например, каждый 2-й кандидат на позицию автоматизатора.
Так что, ничего удивительного :)

Так какой же ты в пень автоматизатор, если не можешь простейший алгоритм реализовать?

Инструкция следующая: заходите к программистам, лучше чтобы 20-30, вырубаете интернет и просите написать эту самую сортировку пузырьком. Результат вас удивит. Чтобы офигеть от результата: зайдите к фронтендерам с тем же вопросом.

Ну пузырёк это вообще днище

Ну если интервьюер больше ничего не помнит — why not? ))))

Интервьюер много чего помнит. В том числе и алгоритмы построения поверхностей методами приближённого счисления первообразных определённых интегралов функций с помощью рядов, это когда первообразную получить невозможно — но интервьюер предполагает, что не каждый тестировщик закончил КПИ и не обязан знать такие вещи. Но при этом кандидат, претендующий на роль автоматизатора, обязан иметь навык алгоритмического мышления и уметь этот навык демонстрировать. Как по мне, bubble sort неплохо показывает, умеет ли кандидат вообще составлять алгоритмы или нет. Естессно, это не единственный вопрос по программированию, который я задаю на интервью. Просто этот почему-то оказывался самым показательным.

я согласен с Вам в том что автоматизатор

обязан иметь навык алгоритмического мышления и уметь этот навык демонстрировать
, но зачем это
В том числе и алгоритмы построения поверхностей методами приближённого счисления первообразных определённых интегралов функций с помощью рядов, это когда первообразную получить невозможно
??? Как часто в работе Вы это применяете?
но интервьюер предполагает, что не каждый тестировщик закончил КПИ
в наших широтах это ниочем )

Это — не применяю. Привёл как пример более сложных алгоритмов.

А вы давно учились? В первые полгода после окончания универа я тоже много чего интересного помнил.

А мне уже интересно (не владея опенспейсом на 100 человек и не имея сейчас, увы, ни одного фронтэндера в команде) — что будет у фронтэндеров? Они сразу же постараются убить и закопать, или, наоборот, напишут вполпинка и спросят «а чего ты такую банальщину спрашиваешь, лучше нам ван Эмдена закажи или там осциллирующее слияние на частичном порядке»? :)

Не оценят. Видимо ближе к первому варианту.

У нас не было задач/вопросов типа "вспомнить алгоритм"(память у всех по-разному работает, да еще вроде как в стрессовой ситуации, поэтому я бы не закладывался на то что обязательно вспомнит, если не готовился специально), но была простенькая задачка в которой надо было посчитать сумму массива и решить линейное уравнение: большинству без подсказок оказывалась не по зубам; была задачка решением которой может быть метод половинного деления: чуть лучше, но все равно туго. С профильными знаниями(ну там JS/HTML/CSS) особой корреляции нет.

ЗЫ: но алгоритмы — то фигня. Очень запомнился Rails-чувак:
— напиши простой select
— не, сори, не знаю sql, никогда не писал. В Rails используется ORM.
— ок, что такое ORM?
— ...

посчитать сумму массива
var sum= [1,2,3,4].reduce(function(x,y) { return x + y});
Вы там наглухо отбитых собеседуете?

это то к чему сводится решение. задача чуть более абстрактная конечно. ну то есть никто не спрашивает «как посчитать сумму массива». не хочу палить вопрос, а то людям придется новый придумывать.

echo array_sum([1, 2, 3, 4]);

Array(1, 2, 3, 4, 5).reduceLeft[Int](_+_)
Все равно лучше чем пример на R выше не напишите.

Scala же, а если умножение, то (_*_)

Андерстрайки — матчинг для агрегатора и аргумента?

Да, чтобы не делать алиасы — a,b,c и прочие в замыканиях.

Протестую!
C#:
Enumerable.Range(1, 9).Aggregate(0, (col, next) => col + next); — трансляція фактично :)

var sum = (new[] { 1, 2, 3, 4, 5 }).Sum();

В чём прикол?

«надо было посчитать сумму массива и решить линейное уравнение» — это то к чему сводится решение задачи, а не задача :) В принципе нужно было задачу свести к уравнению, решить, написать три строчки кода.

Смотрю на ответы к вашему комменту, и возникла идея разбивать задачи на мелкие таски и постить «как бы невзначай» на дуо.

Так я даже предлагал рассказать сам алгоритм. Мне интересно не то, знает ли кандидат данный алгоритм, а то, сможет ли он его реализовать. Так даже после того, как я рассказал, как данный алгоритм работает, ни один из тех, кто сказал, что не помнит, не смог его реализовать по-человечески.

Это где ж вы таких кандидатов находите? в КПИ? )))))))))))))

Вы думаете, я помню, откуда они приходили? :)
У меня были периоды, когда я собеседовал по 3 кандидата в день. Вы думаете, я всех упомню? :)

Та да ))) После недели в таком режиме я написал рекрутёрам — типа народ, мне ещё и поработать надо бы. Уменьшили до 2-х в день 1 раз в 2 дня. Там надо было набрать пачку народу на новый проект, меня попросили помочь, поскольку на проекте своих QA инженеров ещё не было.

В таком случае разработчики могут воспользоваться мобильным интернетом

Да лучше сразу свет вырубить, чего уж там.

у кандидата в резюме написана ISTQB сертификация. Я как раз к ней активно готовился,
1. Судя по Вашему профайлу сертификацию Вы так и не осилили ? )
2. Если на собеседовании начинают спрашивать по «foundation level» можно смело оканчивать интервью: интервьюер слабо себе представляет предметную область в которой он работает.
3. Про сортировку — да. грустно.

1. Я её так и не сдавал: не удалось на тот момент договориться о компенсации стоимости сертификации с конторой, в которой я на тот момент работал, а потом привалили новым проектом и на сертификацию времени просто не осталось. Но это не означает, что я похоронил эту мысль навсегда :)
2.

интервьюер слабо себе представляет предметную область в которой он работает.
Не совсем понял. Поясните.
Не совсем понял. Поясните.
«foundation level» — это некоторый базовые вещи для человека который никогда не занимался обеспечением качества. Там все достаточно не сложно и не совсем логично. Пруф — большинство сеньеров проходивших сертификацию без «специальной подготовки» ее благополучно завалили, потому то они использовали свой опыт(сеньеры настоящие и знания у них были отличные). Если же мы говорим об адванс уровнях, а там их дохрена, то да — эти вопросы имеют право на жизнь.

Факт. Не всё в ISTQB соответствует практике. Но, как я говорил выше, я спрашивал некие совсем базовые вещи, на которые сможет ответить даже человек, никогда ISTQB не сдававший.
Кроме того, когда я задавал вопрос по ISTQB, я всегда предупреждал кандидата, в каком формате я жду ответ. Я смотрю, у Вас сертификация есть. Сходу могу припомнить 2 вопроса, которые я задавал. Интересно, ответите или нет? Не подглядывая в силлпабус, на честность :)
1). Сколько уровней тестирования, начиная от Unit, выделяются в ISTQB и какие?
2). Сколько уровней изоляции тестирования от разработки есть в ISTQB и какие?

минута позора ))))))

1). Сколько уровней тестирования, начиная от Unit, выделяются в ISTQB и какие?</blackout>
4: unit, integration, system, acceptance

2). Сколько уровней изоляции тестирования от разработки есть в ISTQB и какие?
без малейшего. по моему не было такого в «foundation level» либо перевод сильно хромает )))

1. Правильно.
2. Было.
Тоже 4.
1). Сам написал, сам протестил.
2). Написал, отдал коллеге на ревью.
3). Написал, отдал команде QA на тестирование.
4). Написал, отдал независимой конторе вместе с ТЗ на тестирование.

Может быть, мы читали разные версии. Я читал на инглише, вроде как называлось isolation level, если память мне не изменяет.

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

Апдейт. Сорри, ошибся в предыдущем коменте. Не isolation level, а independence level.
Вот они
istqbexamcertification.com/...g-its-benefits-and-risks

Да... на DOU еще меня не собеседовали ))))

Всё когда-нибудь бывает в 1-й раз :)

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

по второму то что вы ответили — это «Организация и независимость тестирования».
по вашему вопросу сложно догадаться :) (просто скопирую)

5.1.1 Организация и независимость тестирования (K2)
Эффективность поиска дефектов и рецензирования может быть повышена с
помощью независимых тестировщиков, Варианты независимости могут быть
следующими:
• Отсутствие независимых тестировщиков: разработчики тестируют
собственный код;
• Независимые тестировщики в команде разработчиков;
• Независимая команда или группа тестирования в организации,
отчитывающаяся менеджеру проекта или исполнительному менеджеру;
• Независимые тестировщики из бизнес-организации или сообщества
пользователей;
• Независимые специалисты тестирования для отдельных типов
тестирования, например, тестировщики удобства использования,
тестировщики безопасности или тестировщики сертификации (которые
сертифицируют ПО на соответствие стандартам и правилам);
• Независимые тестировщики, привлеченные на аутсорсинг или сторонние по
отношению к организации.

Значит, этот вопрос составлен мной не совсем корректно. Спасибо, учту на следующих собеседованиях :)

Вот херню какую-то спрашиваете, ей-богу.

Вот ведь странные люди — разработчики экзамена ISTQB. Такую херню спрашивают... ;)

а вы собеседование на конкретную позицию проводите, или экзамен на ISTQB принимаете?

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

Я имел в виду “QA Automation Engineer”.

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

Так какой же ты в пень автоматизатор, если не можешь простейший алгоритм реализовать?
Давай алгоритм — реализую. Почему это сам алгоритм нужно помнить и почему именно этот?
Почему это сам алгоритм нужно помнить

Потому что реальный опыт (а не знание сертификатов) у человека это всегда некоторое количество набитых шишек именно на реализации алгоритмов. Только тогда появляется нормальное видение процессов, происходящих при работе программы, и умение применять это видение хотя бы на уровне поиска банальных описок в своём коде.

А дальше — вопрос, в какой именно традиции этот претендент набрал свои умения. В основной учебной традиции в наших краях «пузырёк», да и вообще сортировки, есть чуть менее чем всегда, даже если на практике вокруг исполнителя будут только хэш-таблицы и RB-деревья.

и почему именно этот

Какой ещё? Назови, какой можно проверить, предполагая как минимум 90% вероятность, что исполнитель его уже знает и не нужно будет объяснять полчаса.

Потому что реальный опыт
Не-а, если человек помнить сортировку пузырьком — возможно он вчера прочел книгу по алгоритмам, готовился к интервью. Только это computer science, редко имеющая отношение к работе. Реализация алгоритма — это когда тебе описали словами как что-то сделать, и ты это перевел в программу. Хоть это сортировка пузырьком, хоть что-то ещё.
Какой ещё?
Никакой, вам потом кандидат должен будет работу работать или экзамены по алгоритмам сдавать?
Не-а, если человек помнить сортировку пузырьком — возможно он вчера прочел книгу по алгоритмам, готовился к интервью.

Повторяю из соседнего ответа — смотрится не результат, а процесс, и не только на пузырьке. Чрезмерно бойкий ответ (только вчера готовился) тоже покажет перекос. Но тут уже наступает неформализуемая часть процесса интервьюирования.

Реализация алгоритма — это когда тебе описали словами как что-то сделать, и ты это перевел в программу.

Реализация алгоритма, описанная словами, или формальными методами, но на общем уровне, оставляет очень много вопросов для самостоятельного решения и мест, где ошибиться. Переход от «выполнить для всех элементов найденной последовательности» до «пройти в цикле по переменной i от n1 до n2», а от него, в свою очередь, до «for(i=n1;i<=n2;++i)» — то, на чём проверяется наличие хотя бы минимального опыта программирования и понимания основ выбранного языка. Это отлично видно на обучении самых начинающих. И тут стандартные алгоритмы вроде пресловутого пузырька — очень хороший тест.

Реализация алгоритма, описанная словами, или формальными методами, но на общем уровне, оставляет очень много вопросов для самостоятельного решения и мест, где ошибиться.
Естественно. Вот и просите реализовать алгоритм, лучше если какой-то свой, реализации которого в книжках нет.

Это на архитектора или [UPD: хотя бы] сеньора, и обычно уже на испытательном сроке. А не на первом техническом интервью юниора.

Резюме пишется для всех: для рекрутёра, технического специалиста, ПМа и т.д. Ложь в резюме — очень плохой знак. Если я вижу ложь хотя бы в одном пункте — как я вообще могу доверять тому, что там написано? Почему бы в этом случае супер-пупер-мега синьору с 20+ годами опыта не оказаться банальным джуном с полугодом опыта и невменяемыми амбициями?

Давай алгоритм — реализую.
Так давал же. Не смогли :)
Почему бы в этом случае супер-пупер-мега синьору с 20+ годами опыта не оказаться банальным джуном с полугодом опыта и невменяемыми амбициями?
Сейчас так работу и ищут :) И курсы даже на курсере есть, как вратьписать резюме. Понимаете, резюме читают-то все. Но первый читает HR, и нужно чтобы резюме выделялось, иначе могут выбросить в мусорную корзину. А потом то же резюме читаете вы (к сожалению). Да, было бы круто, если бы можно было писать резюме для каждого отдельно. Типа, перед приглашением на собеседование написать резюме для технического специалиста. Может там даже более фривольно бы всё описывали. Но пока такого нет.
Так давал же. Не смогли :)
У меня нет для них больше оправданий :)

Помню меня 2-е человек собеседовали по скайпу, через codeshare.
Попросили написать алгоритм поиска 2 макс чисел в массиве. Ну я написал хоть и через задницу. Потом показали кусок кода из проекта, попросили объяснить построчно что тут происходит, с чем я спокойно справился. Хотелось попросить кусок кода, где они ручками пишут сортировки и свои «List» с нуля. Суть работы заключалась в написании оберток на api бирж. Я это к тому, что было бы неплохо если бы интервьюеры давали более менее реальные задачи, которые кандидату нужно будет решать. А то однажды случится так, что возьмете человека, который только базовые алгоритмы и знает.

угу, давать чинить поломанный код, например.

Суть работы заключалась в написании оберток на api бирж.
Прелестно

Ну, спрашивали по сортировке массивов, а писать обертку к апи. Это же просто восхитительный интервьюер

Ну, спрашивали по сортировке массивов, а писать обертку к апи.

Да.

Это же просто восхитительный интервьюер

Очень верхоглядское мнение.

Из реального, что приходилось мне или коллегам по отделу делать в таких обёртках (да, бирж, или близкого к ним):

1. Трекинг заявок и ответов на них в своём прокси, при условии, что внешние участники могут терять часть своего состояния. Выливается, грубо говоря, в мапы (упорядочённые) в памяти и на диске.

2. Журналирование происходящего, с последующим распределением журнала по категориям. Включает в себя сортировку, причём местами объёмы намекают, что надо будет делать внешнюю (полные объёмы событий на биржах уже давно превысили терабайт в сутки).

3. К пункту 2 — умная фильтрация только интересующего. В тылу — весьма непростая алгоритмика (даже то, что я краем уха слышал, глубоко ДСП, извините уж).

4. Перегруппировка запросов/ответов между контекстами и сессиями. Необходима трансляция уникальных идентификаторов, меры по защите от дублей (и их эмпирический обход в реальном мире с массовыми нарушениями стандартов), хэши, оптимизированные на длинные общие части строк.

5. Кросс-матчинг запросов на поиск несовместимых комбинаций и случаев явного фрода, начиная с торговли с самим собой. Обязательно к реализации, если поставщик прокси с такой «обёрткой» отвечает (лицензией) за операции через него. На практике выливается в достаточно хитрые структуры данных с поддержкой нечёткого поиска и статистическим выдвижением подозрений.

Вот маааленькая выдержка из уже «устаревшего» (хотя используемого в полный рост) FIX 4.2:

Instructions for order handling on exchange trading
floor. If more than one instruction is applicable to an
order, this field can contain multiple instructions
separated by space.
Valid values:
1 = Not held
2 = Work
3 = Go along
4 = Over the day
5 = Held
6 = Participate don’t initiate
7 = Strict scale
8 = Try to scale
9 = Stay on bidside
0 = Stay on offerside
A = No cross (cross is forbidden)
B = OK to cross
C = Call first
D = Percent of volume «(indicates that the sender
does not want to be all of the volume on the
floor vs. a specific percentage)»
E = Do not increase — DNI
F = Do not reduce — DNR
G = All or none — AON
I = Institutions only
L = Last peg (last sale)
M = Mid-price peg (midprice of inside quote)
N = Non-negotiable
O = Opening peg
P = Market peg
R = Primary peg (primary market — buy at bid/sell
at offer)
S = Suspend
T = Fixed Peg to Local best bid or offer at time of
order
U = Customer Display Instruction (Rule11Ac1-
1/4)
V = Netting (for Forex)
W = Peg to VWAP

и «обёртки» должны это умно странслировать, а иногда отработать и/или запретить.

Если в принципе не подозревать о подобных тонкостях, можно, да, всю эту работу назвать «обёрткой для API бирж» и не понять, зачем там вообще нужно хоть какое-то понимание алгоритмов ;) Реальность же такова, что голова потрескивает ;)

Сомневаюсь, что они искали Junior .Net на такое. По заявленным требованиям, максимум что меня ждало:"На, Владик, 3 интерфейса, реализуй их для биржи X". А к кору меня на пушечный выстрел не подпустили бы)

В данном случае это не Core. Пусть это не логика даже прокси первого слоя, но тематика тут такова, что что-то больше тупого фронтэнда обычно требуется даже на тупом фронтэнде :)

Абсолютно не понимаю, как умение реализовать алгоритм связано со знанием алгоритмов и тем более умением составить алгоритм. Вопрос на сортировку пузырьком — это вопрос на знание алгоритма (может человек только один этот алгоритм и знает и ничего больше реализовать не умеет), вопрос на поиск макс. чисел — это вопрос на умение составлять алгоритмы. А умение реализовать алгоритм ни один из этих вопросов не проверяет.

Абсолютно не понимаю, как умение реализовать алгоритм связано со знанием алгоритмов

Точно так же, как в любой учёбе: невозможно уметь реализовывать алгоритм, не пройдя это на практике; невозможно пройти практику по реализации алгоритмов, не выучившись каким-то из них. Применяя их на практике, невозможно их забыть и ни один не знать.

и тем более умением составить алгоритм

Невозможно программировать (по крайней мере на процедурных языках), не составляя алгоритмы.

Вопрос на сортировку пузырьком — это вопрос на знание алгоритма (может человек только один этот алгоритм и знает и ничего больше реализовать не умеет)

1. Безусловно, речь идёт не только об одном вопросе про пузырёк.
2. Грамотный интервьер может увидеть по самому ходу решения такой задачи — написать пузырёк — как и о чём претендент думает, как он ведёт решение задачи. Контролируется не готовый результат, а процесс.

вопрос на поиск макс. чисел — это вопрос на умение составлять алгоритмы.

Да, и это правильно. Это не фатально сложный алгоритм, чтобы превысить типичную рабочую задачу.

А умение реализовать алгоритм ни один из этих вопросов не проверяет.

Вы чрезмерно разделяете вопросы «составить» и «реализовать» алгоритм. Для таких простых случаев это практически одно и то же.

Применяя их на практике, невозможно их забыть и ни один не знать.
Серьезно? Может у вас феноменальная память, не знаю. Я в 2009м в команде разработчиков одной CMS был. За год покопался в самых разных частях. Но чего-то сейчас ничего не помню, что там и как.
Да что там, недавно мне понадобилось начать писать emberjs-приложение с нуля, так я в своем же блоге смотрел что куда писать чтобы прикрутить i18n, авторизацию, обработку ошибок. Забылось всё за несколько месяцев.
Я в 2009м в команде разработчиков одной CMS был. За год покопался в самых разных частях. Но чего-то сейчас ничего не помню, что там и как.

Это не алгоритмы. Это детали реализации «одной CMS». Алгоритмы очень сильно зависят от области, где-то и «пройти в цикле по ключам хэша» алгоритм, а где-то требуется спектральный анализ неточных данных, но это проверяется уже специализированно по области.

Забылось всё за несколько месяцев.

Верно. Помнится или то, что запомнилось на высоких эмоциях, или то, что регулярно повторяется. Помнится то, что обросло самыми высокими ассоциативными связями. Видя резюме и имея сходный опыт, можно хорошо предсказать, что из этого должно лучше закрепиться на описанных механизмах.

В вашем конкретном случае наверняка не будут помниться детали конкретного emberjs, но вот основы JS и типичные грабли, на которые наступалось не раз — будут, причём на уровне «отскакивает от зубов».

Нет, не только. А к чему это, если вопрос всей темы поставлен в плане — как отличить действительно умеющего (и того, который «несколько лет работал программистом на разных конторах»), то есть обратную твоей постановке?

Вот именно, что субъективное. А его надо перевести в хоть сколько-то объективное. И делать это можно разными методами, но при невозможности получить объективные параметры прямыми ретроспективными методами — нужно анализировать вживую, по желательной тематике и одновременно по общим отраслевым параметрам.

Хорошо, если хочешь, я специально отвечу прямо (хотя мне казалось, и прошлого достаточно): да, в случае прихода кандидата с такими параметрами, как описаны в исходном сообщении темы (возраст до 30, при этом 100500 баззвёрдов в резюме) я не просто буду это предполагать — я сделаю явную проверку на это, пусть и не такую грубую. Пузырёк, скорее всего, задавать не буду:), но прощупывать буду.
Точно так же, если кандидат — явный студент или близкий по параметрам, я это проверю.

Красивый вопрос. Настолько, что я близок к тому, чтобы выдать за него звание тролля этого дня. Но, если отбросить интересы претендента (которые в данной игре в среднем противоположны моим) и остаться только при моих интересах как интервьюера от работодателя, вопрос перейдёт в следующий: не отброшу ли я кого-то ценного, заведомо отдавая предпочтение тем, у кого меньше баззвордов?
Ответ — на какие-то проценты — возможно, но не думаю, что это даст существенный перекос по сравнению с идеальным (для данного момента на данном рынке) результатом.

Почему?

А вот это уже 101% троллинг. Ты отлично знаешь ответ.

Где здесь противоположные интересы?

Не было бы — не было бы баззвордов. От слова «вообще».

Нет. Я просто подвожу тебя к тому, что ты действуешь абсолютно не рационально,

Не вижу никаких причин для подобного вывода. Или ты не умеешь объяснять, или у тебя нет аргументов.

но пытаешься прикрыться типа чем-то объективным.

Оно и есть объективно. Статистически.

В смысле? Резюме только с информацией о фамилии и имени?

Было бы только то, что человек действительно умеет, а не что прочитал за 5 дней. Ты контекст-то вспомни.

По сути я элементарно ловлю тебя

Ты даже не начал.

Ну и если включить «психолога», то просто дешево самоутверждаешься за счет приходящих к тебе на собеседование.

А ещё ты банально путаешь собеседников, если приписал мне то, что должно было пойти тому, кто спрашивал про пузырёк.

Не пройдет HR.

Вот это и есть твоя априорная ложная посылка, после которой странно что-то обсуждать.

Интересы-то не противоположны.

И это тоже — ты как минимум путаешь состояние до и после начала работы.

Подготовить 2 резюме
PROFIT!1!!

Это как бы вариант, но боюсь многие не поймут

Я собеседовал тестировщиков, не разработчиков.
Кроме того, это был вопрос на понимание алгоритмов вообще, кроме этого я задаю вопросы по тому, с чем надо работать (обычно Selenium). Это необходимо для того, чтобы кандидат не смог пройти собеседование, тупо зазубрив стандартные операции Selenium + типичные сценарии, притом не понимая, о чём говорит.

Только я одна зашла на эту статью из-за
<sarcasm>

Я знаю карартэ, кунг-фу и много других страшных слов!
</sarcasm>?
испытал некоторый бугурт, которым спешу поделиться
Бугу́рт (др.-в.-нем. Buhurt, старофр. bouhourt или buhurt «бить») — рыцарский турнир, в ходе которого две группы рыцарей, вооружённых затупленным оружием (копьями, либо другим турнирным арсеналом, как например: палица, меч, двуручный меч, топор, алебарда, или комбинацией, состоящей из одинаковых типов оружия) сражались друг против друга.
Или кто-то перепутал бугурт с баттхёртом, или я что-то пропустил в современном мемостроении.

Даже такой старпер, как я, в теме, а вы пропустили :)

Значит, я более старпёр. Пойду гордиться.

не вы один, я тоже первый раз это вижу, но я как бы не старпер

я как бы не старпер
Извините, но в нашем клубе строгие правила. Мы вам обязательно перезвоним.

Нормальный бугурт — это когда человек 50 на 50 с алебардами и парой сломанных конечностей в итоге.

В общем, особой разницы со срачами на DOU нет :)

Если бы на работу принимали технари, было бы как вы хотите. Отпала бы необходимость во вранье и реверансах. Пример: «надо фиксить JSP-ки старые, денег столько-то», чувак посмотрел и пошел или не пошел. Улавливаете мысль?

Полностью поддерживаю вашу мысль, у нас так и есть. Кадровику запрещено фильтровать резюме каким-либо образом, его работа — вести первоначальную переписку и согласовывать время интервью.

Якщо пішла така розмова, то дайте опис вакансії, а то безпредметна розмова.
Технологія технології часто не рівня. Чувак може дійсно працював з технологією на рівні, що може вирішити 99% типових задач, з якими стикався, а ви задаєте йому 1% не типову задачу і робите висновок, що він хеловордщик.
Врешті-решт, чувак може нормально кодити, вирішувати якісь архітектурні питання, швидко вчитись і бути відповідальним, а може кодити херово, не виходити за скоуп своїх формальних задач, клайсти *ер на роботу, але справді мати досвід роботи з необхідним фреймворком і досвід вирішення 1% нетипових задач, які ви йому задали на співбесіді.
Перевіряти таке, напевно, тільки випробувальним терміном.

Якщо пішла така розмова, то дайте опис вакансії, а то безпредметна розмова.
Native, WinAPI, Sockets, трохи COM.

Достатньо?

Это гораздо ближе, чем вы считаете.

Да я с ностальгией :-)
Когда-то я с этим плотненько работал, было интересно...

Что значит Native C++, NET?
Хм... давно .NET стал native?
Оно гигансткое и не существует в мире человека, что всё его знает, причем разные его части сильно разные, одни очень грамотно сделаны, другие, как быдто социняли после литра водяры.
Да, и нужно осознавать хотя бы этот самый факт. Как и отдавать себе отчет, что если словил segmentation fault в GetWindowText, то это не значит, что ошибка внутри GetWindowText.
Ну и сейчас таких уже не много, это старичков искать надо больше, а не молодых.
Не обязательно, попадаются и молодые, которые знают.
как быдто социняли после литра водяры.
Сюда можно добавить ущербную документацию.

Помню как писал кейлоггер(через глобал хук), и помню как у меня клавиши через задницу читало если не пихнуть GetKeyState без параметров, хотя в документации нет инфы, что оно что-то меняет(только возвращает). Может и я тогда что-то упустил, но 3 дня мучений меня вывели из себя. У MSDN хорошая документация по .Net, SQL Server.

что лучше ее не видел.
Так потому что она единственная) Ну еще есть частично русифицированная версия на firststeps. ру.
Так потому что она единственная)
Скажем так, если сравнивать их документацию по .net и их документацию по winapi, видно где забили болт, а где потели.

Apple’s Developer Documentation

Кстати таки лучше. Когда есть, конечно.

Честно говоря — даже борландовская дока была лучше MSDN.

Это когда не врёт. А врало нередко... я раз 15 натыкался, при том, что под винду писал эпизодически.

Эхехе, это вы не видели документацию на Carbon (OS X C API), причём в раннюю эпоху, года эдак 2003-го. Тогда на MSDN вообще молиться можно было. Да и сейчас всё-таки он получше будет, мне кажется.

Хорошо, что не видел, мне тогда 9 лет было, мог бы заикой остаться)
Да 7 лет назад хорошей литературы по html/css не было, чего уж там. Сейчас по o’reilly даже моя мама освоит верстку.

Ну в принципі, ± нормальні вимоги. Очікував побачити щось більш екзотичне.
Хоча доволі загальні речі, я б радив краще розписати в описі вакансії або кандидатам на стадії запрошення на інтерв"ю уточнювати вимоги.

У вакансії більш детально, це для місцевої публіки, щоб не думали, що ми вимагаємо 10+ років досвіду в Swift чи node.js

Вот и думаю, что на собеседовании будет какая-то теория из области математических олимпиад или терминология. И можно не ответить, но на практике то конкретная задача не раз мне была в новинку, но все решалось в срок и качественно. А если задача вообще не из моей области сразу могу сказать — не знаю. Но вопросы обычно по россыпи разных технологий, без которых можно обойтись в подавляющем большинстве случаев.

Что за паскудная тенденция?
Приходится продавать то, что покупают. Вот когда HR’ы перестанут покупать аббревиатуры — тогда их и перестанут продавать. Пока же в большинстве вакансий куча баззвордов, фронтендщику будет плюсом знание бэка, бэку знание С++, приходится в резюме эти баззворды вставлять.
А ещё, возможно вы неправильно ищете. Чтобы работать с той или иной технологией, нужно понимать основные концепции, а не знать всё. Знает всё документация. Взять тот же JS (node особенно). Сколько всего пакетов в npm? Я не знаю, но даже если посмотреть на первые пару страниц most starred (www.npmjs.com/browse/star) — жизни не хватит, чтобы знать всё. Вместе с тем, для работы знать и не нужно, нужно помнить названия полезных пакетов или даже просто помнить что такой пакет есть (а если что-то существует — это можно загуглить). А освободившееся в памяти место занять правильной архитектурой проекта например.
ты потратил на базовые знания кучи технологий столько времени, что мог уже быть сеньором, а подходишь только на позицию продвинутого джуна
Чем больше вариативность знаний разработчика тем больше у него выбор среди различных вакансий. Если разработчик узкопрофильный, тем меньше вакансий для него есть на рынке труда. Узкопрофильность — выгодна работадателю, но не выгодна разработчику с точки зрения поиска работы.

Да, особенно когда «внезапно» твоя узкая специализация окажется за бортом

Я говорю о разработчике и поиске работы, а не разработчике и одной компании. Если вы отличный специалист в одной узкопрофильной сфере, то и нужны будете крайне ограниченному количеству компаний. Понятно, что для разработчика это сужает рамки в выборе проектов/условий/компаний/зарплат.

У тебя какие-то странные обобщения, они не подтверждают, то что я вижу вокруг себя: рейты растут, в крайнем случае остаются на месте, бОльший спрос на разработчиков, которые имеет больший спектр знаний, а не узкопрофильников. Меня, как разработчика именно это и интересует.

Кушать-то хочется

А как становиться сеньйором не копая вглубь? Или я что-то не понимаю о наших сеньерах?

Мне любопытно, что вы понимаете под шарить в технологии?

Знание того что в версии 1.0.Х, есть недокументированный сайдэффект от использования какого-то апи? А в 1.0.Х+1 его пофиксили, но появился баг в другом методе?

Или знание на изусть все объекты и методы?

Если это так, то вам стоит пересмотреть критерии поиска.

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

окей, то есть вы вкладываете в это понятие понимание архитектуры, это радует.

получение таких знаний в реальности может быть достигнуто двумя путями.
1ый, самый популярный, путем набивания шишек самому, длинный муторный путь, требуются года
2ый, требует хорошей обучаемости, и крайне не популярный, путем прочтения (имеется ввиду не бегло пробежать глазами, а понять) техникал гайда, по времени занимает от нескольких часов до н-времени в зависимости от знаний человека

причем прикол в том, что в процессе 1ого пути люди начинают идти 2ым, но делают это весьма не охотно и медленно.

теперь интересный момент, после только 2ого пути люди могут не знать элементарных тех. вещей, но их гуглят за 1 минуту, но в состоянии построить нормальную систему с использованием технологии.

исходя из вашего поста, у меня сложилось впечатление что вы ищете 1ых, хотя хотите найти 2ых.

мне кажется что вы противоречите сами себе, или я вас не правильно понял

В основном согласен.

Ну и пятый, что ты понимаешь под сеньором, человека, который за день поймет всё, что вы написали и тут уже начнет круто кодить ваши задачи — по сути телепата.
Под сеньором мы понимаем человека, который в начале будет задавать глупые вопросы только архитектуре проекта, а не по особенностям фреймворка, на котором тот написан.
Напишите четко, что требуется опыт работы с такими-то и такими-то фреймворками не меньше такого-то.
Тоже субъективная оценка)
Человек может вертеть 2 года 20% возможностей той или иной технологии, а может за пол года выжать из нее все.

Ок, а чем продвинутый джун отличается от не продвинутого? :)

Нда ! Вообще то уровень человека вырисовывается за год и то весьма приблизительно. Но некоторые особо упертые хотят за день выяснить парой тройкой вопросов или вообще «тестовым» заданием ))))))

по этому рекомендации рулят
но для этого надо иметь команду не мдаков как стартовая точка и скорее всего придется платить выше рынка

по этому рекомендации рулят

В Украине разве что, да и вообще страной управляют по рекомендациям ...

я думаю вас ждет много разочарований если думаете что это чисто украинская фишка

Да кто спорит, гуманитариев и голубых полно в любой стране, я предпочитаю работать с людьми у которых голова на плечах а не бачок для слива «рекомендаций». Тем более в стартапах (!)

бу га га да стартапы как раз забиты друзяками да знакомыми, вот да с улицы уже обычно берут тех кому еквити не положено ( или положено совсем смешно )

Человек нужен сейчас, а не через год.

как то отбирали чуваков в другой стране, самые четкие резюме были у ребят из нигерии. Выглядит где то так — 18 лет админ циско на 1000 рутеров, 5 лееров архитектура впн, 10 доменов, с 19 лет — проект на уровне эксперта в сетевой безопастности и три проекта по фаерволам плюс переезд всего оффиса на актив директори и новый виндовс, с 20 лет программирую на джава, джаваскрипт, ангуляр джиэс — фронт энд, бекэнд, хайлоад системы, 21 лет — эксперт в машин ленинг и биг дата, 22 года — 8 проектов на пхп и еще менторил 5 проектов на с++, попутно правя код С шарпа, 23 года — солюшн архитект в международном банке (филиал в нигерии) . вот после таких резюме смотриш на других кандидатов уныло, у них всего один язык и одна технология, как можна так мало знать ?

я до сих пор вспоминаю одного юношу из солнечного Пакистана с 27 сертификатами по дот нету и черти чему

ну еще индусы мне попадались интерестные, но там заворот в другую сторону — типа менеджер в одной компании, менеджер в другой компании, упраление бюджетами с 6ю нулями. просим дать референсов — пропадает. второй — директор такого то проекта, директор такогото направления, просим дать референсов — опять пропадает. потом вижу индуса который у нас на проекте был всего три месяца консультантом и у него в линкедин написанно что он менеджил весь наш проект, весь бюджет, провел кост оптимизайшн и разработал стратегию на 5 лет вперед.

тю обычные индийские дела, ниче особенного

а еще слышал классную историю от одного канадца, вернее он из шриланки но теперь у него канадский пасспорт. Чувак вел курсы по цыске и рассказывал как он устроил своего брата в какую то энергетическую компанию канады. Типа им нужен был чувак по цискам, а его брат в этом плохо шарил. И типа позвали его на собеседнование (он жил в том же городе где и компания) и вот типа такой план они разработали — он рассказывает что приедет на собеседование в свой перерыв и опоздает на 40 минут, скажет что был трафик джем и что ему пора уже обратно но он таки может ответить на пару вопросов. В итоге ему задали всего 3 вопроса на 2 из которых он ответил и его приняли. В первый день чуваку дали закрывать какие то тикеты, он сказал что плохо себя чувствует и пошел в туалет звонить брату. Второй день опять дали тикеты, он сказал что еще со вчера плохо и нада к врачу, третий день он скрывался в серверной и т.д. ну короче со временем расшарился. Так вот, у чуваков сразу есть план как без знаний пройти собеседование и что делать что бы тебя не выгнали.

от потому некоторые и парят людей алгоритмическими задачами
типа концепция дубовая — если голова варит в наших велосипедах разберется и научим. ( А все большие продуктовые компании- это прям велозавод настоящий )

Имхо это даже правильно. По себе сужу, что дошел до такого состояния что могу писать на чем угодно из распространенного без задних мыслей. Нужно пайтон — будет пайтон, нужно на RoR налабать — а пожалуйста, то же самое с golang, nodejs, apex, c++, scala, groovy...
И это не пустая болтовня, а реально на проекте был и nodejs и golang и java и scala и python и легаси на ruby и ничего страшного не случилось.

p.s. Кто-то может возразить что на скале без задней мысли неудастся писать без хорошей подготовки, но большинство успешных опенсорс проектов(i.e. Kafka, Spark) используют ее именно как better java, с минимум имплиситов, макросов и прочих продвинутых фишек.

хуже другое
когда на собесе обсуждаем O нотации, какие коллекции в жабе какую сложность имеют и прочие не без интересные вещи и даже пишем прикольное тестовое ( типа подсчета слов в тексте произвольного размера ) а в итоге выясняем что надо будет сапортить ископаемую систему документооборота на 1.5 что ли....

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

да там можно было два требования выставить 1) железную жопу 2) небрезгливость

и не вы#бываться при найме было бы полезнее для кармы- все равно большинство в итоге ржет и уходит когда видит предложенную зп )))

освоил таки стекоферфлов ? )))

По мне так надо знать несколько основополагающих вещей (в моём случае это .net, ASP.net, SQL, js, jquery, html). Всё остальное — учить под проект. Всё равно заранее не угадаешь, а учить технологию не используя её — бесполезно.

Ну ладно еще js, а jquery с какого перепугу основополагающая?

Тому що мало хто хоче писати сотні рядків коду, коли можна обійтися десятками.

для использования jquery много мозгов не надо

Мала їх кількість не підходить для використання теж. Ви ще скажіть, що ті, що jQuery навчають та вивчають, лише дарма витрачають свій час та у них мало «мозгов». Я посміюся.

На собеседовании посмеетесь. Я сказал то, что хотел сказать.

пiздец оленiв в синийор консультанты уже берут

ты зря бычишь. По делу ведь написано.

ох йоптить а давай прикинем на сколько часто jquery встречается в природе? Наверно чуть чуть чаще чем поделки на голом JS...
ну блин хотя бы sizzle надо уметь использовать, с этим вы согласитесь?

О Боже, trends.builtwith.com/javascript/jQuery, аж 12% веба, и тенденция уверенно идет на спад.

78.1% первого миллиона сайтов по посещениям ))))

Ага, великая тройка Wordpress, Joomla и Drupal.
Я говорил про общую статистику.

Загальна статистика — це загальна статистика, звідти нічого не викинеш. Чи ви хочете сказати, що ці три CMS як МКАД, за яким немає жит...jQuery? От прям таки усюди немає, так? Не кажіть дурниць.

Сизл давно не нужен, есть нативный квери селектор, а если его возможностей не хватает, то вы чтото делаете не так

а что его перестали в jquery внутри использовать? давно выпилили?

Я к тому что можно и без него дом манипуляции делать. Правда выглядит это весьма громоздко

а мне что то показалось что вы просто не знали что это и есть то на чем селекторы в jquery работают, ок переобув на ходу засчитаем

Мой посыл был к тому что если юзать джквери ради сизл только, то можно и без него в принципе обойтись.

к сожалению сильно много народу не догадывается о том что его можно отдельно взять и тянут jquery куда попало есть такое дело

Хотя бы по той причине, что jquery является неотъемлимой частью ASP.net MVC.

Сейчас фреимворки и технологии настолько часто меняются, что задрачивать их до уровня настоящей синьйорности часто бессмысленно. Даже такой, казалось бы, основополагающий гранит как SQL — нынче не в моде.
Во вторых для большенства работы на рынке синьйорность по конкретной технологии и не нужна. Куда более ценное возможность быстро включиться в новую технологию, сделать как-нибуть но быстро, нагуглить решение, почитать сорцы чтобы найти решение, итд.

Сейчас фреимворки и технологии настолько часто меняются, что задрачивать их до уровня настоящей синьйорности часто бессмысленно.
Значит они сами по себе бессмысленны. Иначе почему так быстро уходят со сцены?
Даже такой, казалось бы, основополагающий гранит как SQL — нынче не в моде.
Мода — это не тот критерий, которым руководствуются специалисты.
Куда более ценное возможность быстро включиться в новую технологию
Фиговые знания даже того, что заявлено в резюме, по моему не лучшим образом характеризуют данную способность кандидата.

Так перед тем как пригласить -давайте тестовое задание, или даже расширенный список вопросов.. В любом случае джун не успеет их глубоко выучить за пару дней..
А Сеньоромидл с не тем стеком не пойдет на собеседование ,увидев что его ждет..

Уже так и делаем:
Если есть что показать готового, то показывайте и приходите.
Если нет — вот простейшее задание на 15 минут (с маленькой закавыкой, поэтому без реального опыта сделать правильно сходу не выйдет).

Только фидбеки присылайте. Было дело, попросили тестовое задание, часов на 5. Сделал, послал, через пять минут — приходите на собеседование. Ежу понятно, что не проверяли. Другой случай, задание на неделю (так в условии было написано). Неделя не неделя, а три вечера убил, послал, нет ответа. Подозреваю, что это был чей то диплом.

Было такое тоже :-)

Мода — это не тот критерий, которым руководствуются специалисты.

Вы это скажете когда работу будете искать, когда у вас 10 лет опыта оракла, а вокруг нужны токо монга да касандра.
Фиговые знания даже того, что заявлено в резюме, по моему не лучшим образом характеризуют данную способность кандидата.

Я считаю тут дело не в кандите, а в том, что вам нужно определиться какой левл технологии нужен. Если дествительно синьйорский — то нужно это скоммуницировать ХР, пусть а) явно укажет в вакансии что нужны реальные синьйоры с опытом вот по этой и этой технологии. б) явно спросит у кандидата какой у него опыт работы с этими технологиями и насколько он себя оценивает по ним.
Вы это скажете когда работу будете искать, когда у вас 10 лет опыта оракла, а вокруг нужны токо монга да касандра.
Ага, а еще через год какая-нибудь шманга и astraldb...
Мода — это не тот критерий, которым руководствуются специалисты.
угу, сначала ты посмеиваешься глядя на хипстерские технологии, а потом херак — и ты со своим перлом|делфи|коболом|etc никому не нужен.

А с хипстерскими технологиями все еще быстрее, и «херак» наступает на через 10, а через два года. И что это меняет?

Значит они сами по себе бессмысленны. Иначе почему так быстро уходят со сцены?
А откуда узнать, какая технология уйдёт, а какая останется? Когда-то на Delphi писали, и никто бы не подумал, что придет время когда знания Delphi будут никому не нужны.
А сейчас просто процесс смены технологий быстрее происходит. Так что, ни за что не браться, потому что «пока синьором стану — уйдёт»?

Короче ясно, пришло время «нахрена что-то знать, если через год весь этот буллшит никто и не вспомнит».

пришло время «нахрена что-то знать, если через год весь этот буллшит никто и не вспомнит».
Пришло время «нахрена зацикливаться на определенной технологии если через 3 месяца она может оказаться устаревшей, а разработчик выкинутый на обочину истории.»

Вы просто попытались убрать негативную окраску (для своей позиции) с того, что сказал я.

От перестановки слов смысл не меняется: 99% новомодных баззвордов через считанные годы будут помнить полтора анонимуса.

Вобще-то я к этому и веду — какой смысл зацикливаться на технологиях, получать в них узкую специализацию — если они очень быстро устаревают? Вас же пост именно об этом — вы не можете найти узкого специалиста в какой-то технологии. А я говорю, что нет сейчас смысла становиться супер-пупер спецом в одной технологии — это невыгодно разработчику — он становится неконкурентноспособным на рынке труда.

Не то чтобы нахрена знать совсем. Но что ты представляешь под сеньором в конкретной технологии? Я считаю, что если человек «сеньор» в чем-то одном, то это одно нужно знать на уровне ядра. Только вот чтобы на уровне ядра — нужно пару лет поработать над сложными задачами (не клепать стандартные аппликухи, которые на данном фреймворке легко клепать, а решать проблемы, требующие чтения сорцов). А это значит:
1) Сначала надо найти работу с возможностями такого роста (есть-то хочется, не о хобби говорим)
2) Надеяться что через 2 года не получится так, что ты никому со своим сеньорством во фреймворке X не нужен, так как более удобным и вообще намного лучше признан Y.
В общем, фигня это узкопрофильное синьорство, если надеяться заработать себе на покушать.
Нужно принимать новое понятие о синьоре — как о человеке, который имеет опыт разработки и умеет быстро разобраться в новом, а не как о гуру в какой-то одной технологии.

Ваша трактовка синьора ставит возрастной ценз на уровень «чуть за 30», потому как с возрастом желание бежать впереди паровоза пропадает (и вместо него появляется желание ехать на этом паровозе, посасывая вискарик у окна).

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

И результаты этого мы наблюдаем сегодня в том виде, что средства разработки работу программиста постоянно упрощают, а готовый результат работы этих самых программистов становится все хуже.
Раньше и трава была зеленей, и солнышко ярче светило, и программисты круче были) Забавно, конечно)

Нифига. Раньше программист гордился, что реализовал «А» или «Б», а сегодня программист гордится, что смог эти же самые «А» и «Б», реализованные N лет назад, запихнуть в браузер.

Если вам очень хочеться придумывать велосипеды, чтобы чувствать себя «настоящим программистом» — вам никто не запрещает это делать. Только это мало коррелируется с требованиями бизнесса — тут основное не велосипеды строить и ЧСВ тешить — а выполнять конкретные задачи. И если задача быстрее/эффективнее/мене бажно/менее затратно будет выполнена с помощью готового инструмента(а так оно в подавляющем количестве случаев и есть), то его и стоит использовать. А велосипеды, если очень хочеться, можно строить и на своих пет-проектах.

готовые инструменты тоже не с неба падают)

Ну, так логично писать интструмент, когда этого требует задача, а не потому, что «настоящий программист должен все-все писать сам».

Не понял, к чему ваша тирада. Я лишь сказал, что сегодня программисты очень часто решают уже давно решенные задачи. Разница только в том, что сегодня это все ценой гигантских усилий (и затрат вычислительной мощности, кстати) запихивается в браузер, работает там через одно место, но этим почему-то принято гордиться. И это, кстати, и есть типичное велосипедостроение.

Когда-то на Delphi писали, и никто бы не подумал, что придет время когда знания Delphi будут никому не нужны

Ещё в далёком 93-м году, когда я ещё только изучал C по K&R, уже было ясно, что паскаль и паскалеподобное — не нужны.

Тем не менее, их развивают.

Я хоть уже много лет пишу на C-подобном, но заявляю противоположное. Распространение сишного синтаксиса — величайшая ошибка человечества, отбросившая всю индустрию на десятилетия назад.

А еще дальше ее отбрасывает сегодняшняя скриптомания и браузероложество.

Распространение сишного синтаксиса — величайшая ошибка человечества, отбросившая всю индустрию на десятилетия назад.

А тут подробнее, пожалуйста. Что из этого ошибка, а что нет, и почему?
1. Скобки ’{}’ вместо begin-end или отступов
2. Отсутствие ’;’ после операторных скобок или, наоборот, присутствие после объявлений сложных типов
3. Необязательность операторных скобок вокруг одиночного оператора
4. Порядок объявлений типа int* a вместо a: *int
5. Слово struct вместо record, union вместо mix
6. Принципиально непригодные на идентификаторы ключевые слова
7. Операции вида +=
8. Операции ++, —
9. Две разновидности операций ++, —
10. Присвоение = вместо := или :
11. Конверсия типов через (type)primary
12. Вложенные выражения в while, if, и прочих
13. Отсутствие возможности вставить оператор (GCC {(...)}) вместо выражения (как допустимо в практически любом ФЯ)
14. Конструкция for из трёх выражений
15. Оператор ,
16. Отсутствие else в while, for
17. Неметочные break, continue
18. Поддержка goto
19. ???

Ответы вида «всё сказанное» заранее будут считаться сливом :)

1. Скобки ’{}’ вместо begin-end или отступов
Скобочки компактнее, но вопрос привычки
2. Отсутствие ’;’ после операторных скобок или, наоборот, присутствие после объявлений сложных типов
Как-то всё равно
3. Необязательность операторных скобок вокруг одиночного оператора
Это ошибка, так как в разы ухудшает читабельность. Со скобками с беглого взгляда понятно, что войдёт в if, без них — нет, ещё можно и ошибку ввести, если вдруг понадобился не 1 оператор, а несколько, и скобочки дописать забыл
10. Присвоение = вместо := или :
Это ошибка, потому что сравнение ==, легко ввести ошибку банальной опечаткой (
if ($something = true) { /*...*/ }
)
Всё остальное ок
но вопрос привычки
и еще вопрос времени — каждый раз писать кучу букоф нерационально.
легко ввести ошибку банальной опечаткой
есть такое. В питоне решили.

Понятно, спасибо.

Это ошибка, потому что сравнение ==, легко ввести ошибку банальной опечаткой

Дык используйте следующую конструкцию:

if (true == $something) { /*...*/ }

Даже если дали маху с оператором сравнения — компилятор не будет доволен)

Теряется читаемость, и так писать не тру

Я знаю этот финт ушами, и ладно с читаемостью, а если переменные с обоих сторон?

статический анализатор, который заматюкает до смерти
workaround, но сработает

Ну да, для js по-моему jshint выявлял подобные моменты. В общем обходных путей много, но изначально это был плохой синтаксис.

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

Для сравнения двух переменных аналог memcpy

А тут подробнее, пожалуйста. Что из этого ошибка, а что нет, и почему?

Смотреть надо в комплексе. Для меня главные критерии оценки: односимвольные опечатки и сложность их исправления. Плюс лёгкость написание парсера языка. Сишный синтаксис в этом отношении достаточно плох.

Единственное настоящее масштабное вредительство синтаксиса — это использование оператора ’=’ для присвоения. Паскалевское ’:=’ для присвоения и ’=’ для проверки на равенство мне кажется более логичным вариантом.

В остальном же именно паскалевский синтаксис — сплошное вредительство. Начиная от тяжеловесности служебных конструкций (визуально begin и end как ключевые слова создают больше визуального шума, чем {}) и продолжая отдельными секциями для объявлений переменных вместо того, чтобы объявлять их одновременно с инициализацией.

В остальном же именно паскалевский синтаксис — сплошное вредительство.
Для обучения основам программирования нормально, имхо.
Для обучения основам программирования нормально, имхо.

Нет. Оно, может быть, было «неплохо на фоне всего другого на то время», но сейчас я вообще не понимаю, например, зачем разносить декларацию переменной и её инициализацию. Мало того, что это просто bad practice и в продакшн-коде за это надо бить по рукам, но ведь это сложнее и самому человеку при написании! Тем более студенту.

А кроме того, в языке нет ни намёка на FP, так что для обучения основам программирования — также очень плохо. В 2016-м году азы CS должны включать в себя понятие функции как first class citizen.

Я вот прямо сейчас племянницу обучаю. У них стандартный школьный паскаль в виде Delphi. Так вот:

1. Язык с обязательными операторными скобками (как Вирт позже сделал в линии Модула — Оберон) — легче понимается, а Паскаль — очень тяжело. И портит картину то, что постоянно эти скобки пропускаются в примерах и учителями, а понять, как их расставлять — например, как после then и после else раздельно ставить, или не ставить — это для совсем юных очень сложно.
Вместе с проблемой отступов — которые вечно теряются — это ещё больше поддерживает идею, что Питон с его отступами тут лучше всего продуман — именно как для обучения.

2. Ещё сбивает с толку то, что repeat — until это само по себе скобки, а все прочие — нет.

3. Постоянный бардак с ’;’ как разделитель — местами он нужен, местами пофиг, местами (между end и else) — нельзя.

4. Очень непривычно то, что в read[ln], write[ln] необязательный первый параметр — объект файла. Обязательный, или другое название функции, как в C stdio (fprintf вместо printf) — был бы тут однозначно лучше. Потому что сначала учатся тому, что read(a,b) это прочитать a и b, а потом — переучиваются заново — что read(f,a,b) — это не прочитать f, a и b, а из f прочитать a и b.

5. Вечная идиотская проблема с тем, что and, or приоритетнее сравнений, поэтому написать a=b and c=d нельзя, нужно (a=b) and (c=d).

Это основное, на что нарвались именно в синтаксисе, и что именно специфика Паскаля. Тут ещё можно комментировать про кривой ввод-вывод (со специфической поддержкой компилятором), строки с норовом, крайне ограниченный for, и много чего.

В плюсы ему можно записать:
1. var для переменных по ссылке вместо указателей, которые ещё высоковата концепция как для среднего школьника;
2. Чуть более удобное для простых случаев разделение read/readln, write/writeln без проблемы передачи не того типа; хотя для чуть более сложной ситуации его ввод-вывод сразу теряет преимущество;
3. Разделение / и div, пропущенное в C с потомками; весьма грабельно без него;
4. То же := для присвоения — как для новичка, скорее в плюс;

Единственное настоящее масштабное вредительство синтаксиса — это использование оператора ’=’ для присвоения.

Форма записи типов, IMHO, существеннее как вредительство.

Второе — это отсутствие требования явного завершения конструкций. Это уже не по сравнению с паскалем, а в рамках собственного подхода. Грубо говоря, должно быть:


if (cond) {
  a;
} else {
  b;
};

или:


if (cond)
  a;
else
  b;;

но не как сейчас. Потому что если так сделать, это автоматически даст:
* Возможность делать одноуровневую цепочку if — elif*N — else, а не как сейчас, эмуляцию одного уровня с проблемами закрытия;
* автоматическое избавление от ситуации типа неправильно смещённого else;
* очень ценные иногда вкусности вроде else для for, while, try;
* надёжный метод задания атрибутов блокам и функциям;

Начиная от тяжеловесности служебных конструкций
Особенно это касается сишного оператора выбора. Он во-первых многословнее паскалевского, а во-вторых ведет себя нелогично, проходя по всем последующим вариантам, пока его не остановишь.
визуально begin и end как ключевые слова создают больше визуального шума, чем {}
Угу, а потом появляется это:

m(f,a,s)char*s; {char c;return f&1?a!=*s++?m(f,a,s):s[11]:f&2?a!=*s++?1+m(f,a,s):1:f&4?a--? putchar(*s),m(f,a,s):a:f&8?*s?m(8,32,(c=m(1,*s++,"Arjan Kenter. \no$../.\""), m(4,m(2,*s++,"POCnWAUvBVxRsoqatKJurgXYyDQbzhLwkNjdMTGeIScHFmpliZEf"),&c),s)): 65:(m(8,34,"rgeQjPruaOnDaPeWrAaPnPrCnOrPaPnPjPrCaPrPnPrPaOrvaPndeOrAnOrPnOrP\ nOaPnPjPaOrPnPrPnPrPtPnPrAaPnBrnnsrnnBaPeOrCnPrOnCaPnOaPnPjPtPnAaPnPrPnPrCaPn\ BrAnxrAnVePrCnBjPrOnvrCnxrAnxrAnsrOnvjPrOnUrOnornnsrnnorOtCnCjPrCtPnCrnnirWtP\ nCjPrCaPnOtPrCnErAnOjPrOnvtPnnrCnNrnnRePjPrPtnrUnnrntPnbtPrAaPnCrnnOrPjPrRtPn\ CaPrWtCnKtPnOtPrBnCjPronCaPrVtPnOtOnAtnrxaPnCjPrqnnaPrtaOrsaPnCtPjPratPnnaPrA\ aPnAaPtPnnaPrvaPnnjPrKtPnWaOrWtOnnaPnWaPrCaPnntOjPrrtOnWanrOtPnCaPnBtCjPrYtOn\ UaOrPnVjPrwtnnxjPrMnBjPrTnUjP"),0);} main(){return m(0,75,"mIWltouQJGsBniKYvTxODAfbUcFzSpMwNCHEgrdLaPkyVRjXeqZh");}

а потом появляется это:

не вижу связи между отсутсвием begin/end и наличием такого кода. Можно же просто так не писать, правда?

не-не вы шо, программиста надо ограничить и запретить ему писать плохо, он же сам не поймет, что плохо а что хорошо

Вообще запретить что либо писать, ибо он может еще названия переменным плохие давать. Максимум пусть плагины в вордпресе устанавливает, и то четко по инструкции.

вы забыли важную часть! только после сдачи экзамина на глубокому пониманию архитектуры компьютера, операционных систем, помимо архитектуры надо знать о всех изменениях апи во всех версиях, идеально знать все существующие структуры данных и алгоритмы их обработки, так же идеальное понимание ООП и ФП, и вот только тогда можно по инструкции прикручивать плагины на вордпрес

Ну... в паскалевском синтаксисе если ты получаешь ошибку компиляции в результате опечатки, то у тебя в 99% курсор указывает на место ошибки, а текст ошибки поясняет что не так. В сишном не факт, что ты даже ошибку компиляции получишь, не говоря уже про место и сообщение.

Больше визуального шума это субъективно. В Ada, например, можно дополнительно именовать блоки, в после end можно указывать имя блока, в результате чего пропущенный begin не создаёт много проблем. А имена блоков являются дополнительной подсказкой и/или использоваться вместе с операторами exit, ...

Единственное настоящее масштабное вредительство синтаксиса — это использование оператора ’=’ для присвоения.

Кстати, это можно решить требованием дополнительного обозначения, что результат операции присвоения используется дальше. Например, добавить take перед ней.

То есть «a = b» не имеет результата, а «take a = b» — имеет то, что присвоено переменной a.

После этого if (a = b) просто не будет компилироваться, а if (take a = b) — будет бросаться в глаза.

Возможный недостаток — конструкции вида

x = y = z = 0;

превращаются в

x = take y = take z = 0;

но они и так не очень допустимы по многим стилям.

Перейти такое за пару релизов можно в любом языке, если не побояться слома совместимости с редкими извращениями :)

Альтернативу в виде настоять на «:=» считаю нереализуемой, слишком уж привыкли к нынешнему виду.

Сидишь значит на работе, типа развиваешься в профильной технологии между делом, тут к тебе приходят и грят «значит так, теперь мы еще должны пофиксить вот это, оно на XXX» — «эмм, а я тут причем?» — «ты специалист или куда? — разберешься». Фиксишь. Фиксить шо-нить на незнакомом языке или фреймворке — проблема, но не такая уж большая. Время тратится, да. И шо с этим делать? — писать в резюме — не очень правильно, собеседование не пройдешь, не писать — глупо, все же этим занимался.
***
Или так: приходишь на собеседование, а там чувак выполз из своих странных тасков и спрашивает... странное. Ну то есть вообще в этом разобраться — 20 минут, но если каждый день этого не видеть, то забыть очень легко, потому что нафиг не надо. Хотя казалось бы элементарные штуки. В итоге чувак в непонятках «как так, как можно не знать того что я каждый день вижу», и ты в непонятках: «что это вообще было?».
***
И еще(реальная история):
Рекрутер: добрый день, у нас есть вакансия надо XXX YYY
Я: XXX видел, пару лет назад, YYY — не особо. Но вообще интересно
Рекрутер: ок, а опыт управления командой у тебя есть?
Я: ага
... технический допрос (понятно шо за давностью, не все вспомнил) ...
Рекрутер: к сожалению у вас немного не хватает знаний для позиции Team Lead’а.
Я: ... (афигеть, я об этом говорил с самого начала, хотя если «немного не хватает», то я вообще офигенно крут)

писать в резюме — не очень правильно, собеседование не пройдешь, не писать — глупо, все же этим занимался
Если писать все подобные случаи, то у любого специалиста с 10+ лет опыта резюме будет выглядеть как распечатка дампа оперативной памяти на нескольких страницах. На мой взгляд писать надо только то, в чем реально ориентируешься хотя бы на уровне «помню в каком разделе документации про это пишется».

У джунов немного другая проблема, и они частенько тулят все шо токо есть.

Ну помнишь ты, может быть даже нужная страница документации вот прям сейчас в закладках на панели быстрого доступа. Выдержать допрос с пристрастием это все равно не поможет.

Так никто допрос с пристрастием не устраивает. И интернетом можно пользоваться при прохождении теста.

Любому middle/senior программисту нет проблем выучить нужную «аббревиатуру» из списка и программировать на ней для вас. Какая разница на каком языке программировать или какими технологиями пользоваться?
Senior отличается уровнем ответственности и способностью решать проблемы в срок, а не знанием большего числа аббревиатур.

Смотрите послужной список, делайте первичный отсев на телефонном интервью, дайте ХРу список «каверзных вопросов» вроде строки в switch-case или определения VPTR.

Тут такое дело. Назападе резюме часто фильтруют по словам. Нет всех слов из списка — гуляй. Даже если отсутствие того или инго слова не критично для позиции, и человек мог бы спокойно работать и приносить компании пользу.

Об этом все знают, поэтому кандидаты пишут все малознакомое в резюме. Получается такой супчик из базвордов и абревиатур. Часто его даже выносят в отдельную секцию «keywords». Резюме проходит фильтр, а потом, когда человека собеседуют, интервьер просто игнорирует этот список. Такое себе джентельменское соглашение.

Раскручиваем нить дальше. Нам никто не рассказывает, как резюме составлять, поэтому мы все идем в Гугл и читаем советы, написанные для западной культуры. Люди читают «надо побольше абревиатур» и впихивают их в резюме.

Вообще в резюме есть только одна полезная секция: список проектов, в которых человек участвовал. Остальное — мусор. Узнайте, на чем он делал тот или иной проект, что именно он узнал, как решал задачи. Так получите от него список технологий и знаний по ним.

Добавлю. Если не собеседовали до этого, то вам совет. 99% джуниоров, кто пройдет HR и дойдет до вас — шлак. Для мидлов процент в районе 90, для синьоров аутсорса (3-4 года опыта) 80, для средних синьоров (7 лет) — 70, для маститых синьоров (10+ лет) 50.

Т.е. готовьтесь двум из трех людей с семью годами опыта говорить нет. А тертий попросит денег раза в полтора больше, чем получаете вы :)

ты потратил на базовые знания кучи технологий столько времени, что мог уже быть сеньором, а подходишь только на позицию продвинутого джуна.

Мысль вслух: люди, которые тратили время на одну технологию и стали «сеньорами», к вам не приходят ввиду несовпадения технологии.

Это само собой, но не все же выбрали именно «не ту» технологию...

Угу, конечно. «Требуются синьоры под iOS на Swift с пятилетним стажем».

И не забыть 10 лет Java 8!

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

то наверно надо 5 лет опыта

На технологию, которой полтора года в обед. Слово «надо» здесь, да, ключевое.

Но это расходится с тактикой многих «учить много по чуть чуть»

Чем расходится? Они себе тоже по 5 лет нарисуют.

На технологию, которой полтора года в обед
я о ситуации вообще а не о 5 лет для того что появилось 2 года назад.
Чем расходится? Они себе тоже по 5 лет нарисуют.
реальным положением. Вот топик как раз о рисовачах.
в реальности если требуют от человека там 5 лет опыта то наверно надо 5 лет опыта.

Самая смешная шутка сегодняшнего дня, извините :)

Это как с рыболовлей — расказчик всё множит на два, и слушатели всё делят на два, и все довольны.

Я видел вакансии по C++ с требованием десяти лет опыта. Я понятия не имею, чего такого можно в C++ выучить за десять лет, чего нельзя за пять. Другое дело, что если человек пробыл в общей сумме всего на трёх похожих проектах, сопровождая одно и то же раза три раза по три года — тут и разницы особой может не быть, что три, что десять, поэтому рисуют такую высокую планку для всех.

А ещё под «десять лет опыта на таком-то языке» имеют в виду не сколько опыт на этом языке, сколько опыт разработки вообще и уровень лида/архитекта. Ну так так же надо и писать, имхо!

«Старейшие члены комитета воспротивились, сказав, что коэффициент следует удвоить, и все реальные достижения умножать на двадцать.»

Ох боже, спасибо, а я и забыл про неё. Пришло время перечитать.

P.S. Вот отличный кусочек, как раз про резюме, баззворды и 23-летних синьоров вот это вот всё — poxod.ru/...roe/p_troe_glava17_a.html

Наверно все же 10 лет не так по языку как по области, где используется язык. Отличное знание апи и подходов, фреймворков...

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

Я не сказу сильно за джаву (хотя и там разница между андроидным и EE программированием очень даже велика), но за область в использовании C++ вообще скажу, что её единой нет. Там может быть что угодно — корпоративный виндософт на MFC, мобильный софт (через NDK в т.ч.), геймдев, бек-энд, обработка изображений, обработка звука, высокочастотный трейдинг, какой-нибудь риал-лайф продакшн (конвейер или нефтянка)... И даже C# есть отдельно корпоративный, отдельно под виндофон и отдельно под Unity3D.

У даній області технології навіть дворічної давнини вже не релевантні. Досвід шестирічної давнини он там, на початку графіку.

cdn-images-1.medium.com/...Ob39xf47de-Bqr9KcK9hw.png

Період напіврозпаду наукових знань взагалі — 10 років. В ІТ — півтора.

Это период полураспада знаний в JS-фреймворках полтора года.

JS — набагато швидше.

По первому «жирному» пункту:
Тут все ооочень просто (и вы это, я уверен, знаете) — простое вполне типичное желание а) понравиться и б) продать себя дороже («авось прокатит»). Тут мало что можно сделать, кроме как постоянно «тыкать» носом на собеседованиях, что они этого не знают (прочитанное использование без реального опыта) и что так делать плохо.
Возможное забавное непопулярное решение: предлагайте им перед началом собеседования платить вам за время, впустую потраченное на выяснение их отсутствующих знаний по технологиям/ЯП, написанным у них в резюме. Это может в самом начале сподвигнуть их сразу сказать, что 80% написанных умных слов из резюме они знают только как правильно написать, но не как использовать в проектах (утрировано).

По второму «жирному» пункту:
Судя по тому, что я нашел — вы в середине своих 30х. Это важно по одной причине — вы уже сформировались и нашли себя в определенной сфере. Вы знаете, что вам нравится, а что нет. И вы понимаете (в силу опыта) про

молодость, кровь бурлит, хочется узнать побольше нового
, но не принимаете это как достаточное основание для такого разнообразия «аббревиатур» в резюме.
«Молодым» не жалко тратить
на базовые знания кучи технологий столько времени
, потому что они ищут себя и уверены в том, что у них впереди еще много времени потом подтянуть то, что понравится.
Тут тоже ничего не сделаешь, смирится надо и искать дальше нужных вам людей :)

Итог
У нас на рынке аутсорса/аутстаффа в целом печаль с серьорами. Более менее адекватное распределение в продуктовых компаниях. Но я не знаю ни одного случая, когда «продуктовый» реальный серьор решил перейти в аутсорс с бухты барахты. Поиск всегда сопряжен с рисками и потерями времени, потому так ценится умение hr-ами первично отсеить людей по некоторыми техническим знаниями (вроде — слишком общие знания).

ИМХО.

предлагайте им перед началом собеседования платить вам за время, впустую потраченное на выяснение их отсутствующих знаний по технологиям/ЯП, написанным у них в резюме.
Не, это слишком толсто :)
Это важно по одной причине — вы уже сформировались и нашли себя в определенной сфере.
Ну, в их возрасте я уже во всю форсировал конкретное направление. Хотя, может потому, что их было тогда штук пять на все IT...

Но все равно непонятно, зачем идти на собеседование, где от тебя ждут знания WinAPI, если про этот самый API знаешь по сути только то, что он unsafe?

где от тебя ждут знания WinAPI
А каких конкретно знаний? В годы моей молодости был справочник по WinAPI.

Когда я в универе учился — у меня был даже попроще. Так и назывался, «Справочник по WinAPI32», на русском языке и покрывал наверное не весь API, а только его часть. Но я не на погромиста учился, так хобби было.

[не туда ответил]

Подписаться на комментарии