×Закрыть

Абстрактные вакансии

Часто слышно негодование, что HR/рекрутеры «не умеют» составлять (публиковать) вакансии. Но смешно то что технические специалисты с этим справляются не лучше.

На многих «прогерских» форумах есть раздел вакансий, в основном там отмечаются те самые рекрутеры, но иногда кто-то из тех-спецов создает тему в стиле «Мы ищем человека». И тут начинается самое интересное.

Далеко не каждый удосуживается назвать, кто такие «мы». А те, кто называют, ограничиваются Имя_Компании, более продвинутые дают ссылку на сайт (обычно главную страницу). Еще интересный момент: если «мы» — это аутсорс или просто большая компания, мало кто уточняет направление деятельности и описывает проект. Неужели для человека, который работает на проекте, так сложно дать парой предложений описание понятное описание. Почему я должен идти на:

Разработку системы для крупной западной конторы.

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

Много умных слов. Часто встречаются строки (например, для Java-программистов):

J2EE, WebServices, JMS, Hibernate, JDBC, SQL, EJB, Spring, GWT...

Скажите, у вас реально каждый занимается всем этим? В команде нет никакого разделения труда? Человека с лабания GUI перебрасывают на настройку межсерверных коммуникаций?

Hibernate, JDBC. Неужели на всех проектах в равной мере разработчику придется использовать обе технологии? Да, JDBC — это база, ее надо знать, но вы же не пишете «обязательно знание классических алгоритмов и структур данных».

EJB, Spring. Для других языков, наверное, также есть аналоги. Неужели у вас на проекте такая большая либа используется на 100%? Используется? И что, каждый разработчик активно работает со всеми частями?.. Ну, как скажете... А EJB? Тоже на 101%?.. Ну, как скажете...

Немного о базах данных. У вас и правда используются ORACLE, MySQL, PostgreSQL, MS SQL Server? И каждый разработчик активно работает со всеми и должен знать их особенности? Тогда зачем вам Hibernate? Неужели в комманде нет DBA/DBD/чего-то_в_этом_роде?

Мы предлагаем. Зачем вы перечисляете стандартный набор плюшек, или нестандартный. Напишите один-два пункта избранного, то, что вас бы заинтересовало. Для чего писать про страховку или удобный офис? Вы же там работаете — значит, это все есть или для вас это неважно; тот, для кого это важно, сам спросит.

Выводы:
Разница в том, что HR/рекрутер ищет человека, чтобы закрыть вакансию. Вы же ищете коллегу. Вы ищете человека не на проект, а на конкретную роль в этом проекте. По крайней мере, вы можете написать более точные аббревиатуры: если уже весь Spring, то хоть 2 или 3. :)

P.S. Кому интересно, кто я и чем занимаюсь, можете посмотреть в профиле + там есть ссылка на LinkedIn. Это если вам и правда интересно.

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

Похожие статьи




Підписуйтесь: iTunes | Google Podcast | YouTube


101 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Хорошая тема.
Бывает звоню, общаюсь долго, а потом спрашиваю, что реально нужно, кого вы ищите? Например:
Заявлено: Java SE, SQL, XML, Intermediate English. По факту: Теория Java.
И нафига спрашивается что-то выдумывать, вы же косите потенциальных отличных кандидатов, которые постесняются прийти тк. всё любят доводить до конца и до SQL, XML, UML...ML они ещё не добрались.

Не совсем по теме, но не могу не выразить негодование.

Многие описание вакансии не идеально, часто описания «усреднены», это потому что есть, например, ограничение по числу размещения на сайте. Есть корпоративные стандарты, которые нужно учитывать при описании вакансии, даже если кому-то они кажутся не столь хороши как кажутся.
И конечно же только программист может найти лучшего коллегу и написать лучшее объявление. :)
Критерий оценки качества объявления и размещения очень простая. С помощью данных объявлений находятся нужные сотрудники? Рекрутер закрывает вакансии? Если да, занчит объявления хорошие. Точка.
Но не идеальные. Хотите идеальных — помогите рекрутеру на общественных началах и во вне рабочее время, напишите ему письмо, что привлекательнее на ваш взгляд, для специалиста если объявление звучало бы так: «....» Нормальный HR и рекрутер будут благодарны.

А критика это слишком просто :)

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

А критика это слишком просто :)

Угу, сначала читаем статью, а потом критикуем :)

Каждый разработчик активно не работает со всеми технологиями. но все-таки работает, в большей или меньшей степени в тот или иной период времени.
лично я пока не встречал команд с четким разделением труда. Выделенного архитектора и дизайнера обычно нету. так же как и отдельного разработчика на middle или ui уровни.
В Enterprise level project, SOA архитектура в разных частях сиcтемы используются и nHibernate, и Ado.net. Dba есть только на стороне заказчика.
используется куча технологий, по тому же оффису и OpenXml и Vsto и старый добрый interop.

Если какой-то разработчик скажет что будет только работать например с entityFramework и не хочет ничего слышать об том же Hibernate, то команда его не поймет и пошлёт подальше.

Гы::) это вам еще не встречались вакансии «ищем программиста, главное требование — чтобы вписался в команду» :))

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

Или одевают одно и тоже на протяжении 1 года ....

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

Евгения, а Вы недавно HR-еннинге ?

Взгляд какой-то незамыленный, свежий довольно.

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

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

Тогда прочитайте еще раз пост :)

Если честно — не понимаю в чем проблема. Никто ведь в вакансиях не пишет, что все перечисленные технологии нужно знать досконально. И даже если кто-то всю жизнь занимался бэкэндом, то как по мне — хорошо, если он знает почему для того же GWT не стоит возвращать groovy бины.
Аналогично с БД: «поэтом можешь ты не быть», но знать как вызывать хранимки и получить от них курсоры для разных типов баз все-таки стоит.

Вообще, в приведенном примере только GWT и выбивается, все остальное вполне нормально для JavaEE разработчика.

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

А как их нужно знать? Часто это не указывается. От сиди и фантазируй: я добавив метод в класс вебсервиса (копипастом) и написав пару вызовов другого вебсервиса, знаю WebServices или нет?

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

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

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

Это в предположении что у соискателя куча свободного времени и наниматель готов тратить кучу времени тех-спецов и ХР.

Я например пропускал вакансии, где в требованиях были SWT, Swing и прочее — т.к. явно не мое.

Шас это уже не часто встречается, но раньше Swing писали «чисто для профилактики».

Это в предположении что у соискателя куча свободного времени и наниматель готов тратить кучу времени тех-спецов и ХР.

Куча времени — это на что? У соискателя — на прочтение вакансии, а у техспеца — на прочтение резюме? Мне кажется проблема слегка преувеличена..

лично я в таком случаю задам один-два вопроса по вебсервисам и пойму твой уровень :-)

Не факт что зададите, патамушо я приду/дойду к вам на собеседование.

Снова, к примеру, «понимание принципов работы вебсервисов и знание AXIS2» более понятно чем WebServices.


J2EE, WebServices, JMS, Hibernate, JDBC, SQL, EJB, Spring, GWT...

Скажите, у вас реально каждый занимается всем этим? В команде нет никакого разделения труда? Человека с лабания GUI перебрасывают на настройку межсерверных коммуникаций?

А где там настройка межсерверных комуникаций? И вообще wtf настройка межсерверных комуникаций?

Писалось в порыве гнева, поэтому может содержать выдуманную терминологию :)

Имеется ввиду межпроцессное взаимодействие в контексте распределенной системы, типа РМИ, КОРБА туда же JMS (хотя это немного другое)

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

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

Собственно я думаю такие требования вполне уместны для Senior Developer, но такое встречается даже в описании вакансий типа Junior Developer. Да и вообще такое впечатление, что все вакансии по одному шаблону делаются.

(оффтопик) когда постоянные читатели ДОУ пишут колонку и развиртуализируются — это круто! :)

Это ж как нужно было его достать :) что б для крика души пошел на такие жертвы

Я успокаиваю себя мыслью о новом ДОУ с ... ну вы поняли чем (обещанном с октября)

мечты, мечты, вот вот если б стали былью

А что будет с октября? Я не в курсе, ребята...

А что это дает в случае де-анонимизации?

Первое не знаю, а второе ... ну вы поняли :)

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

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

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

Важно:

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

Мо не надо трогать рекрутеров, это совсем отдельная тема.

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

Це ви так тонко троллите? На нашому перегрітому ринку, де девелопер більше одного абзацу з себе не може витиснути, творів у школі не писав, і зайвий раз напрягатися для заповнення якоїсь формочки не буде. Ібо впадло. А піде туди, де сильно більше з.п., бо девелопера треба на позавчора.

Наші контори до цього може й доросли, а от з іншої сторони дєцкій сад.

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

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

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

оффтопик, но не первый раз натыкаюсь на это непонимание — рекрутёры НЕ составляют требования к кандидатам!

но рекрутеры должны все-же как-то организовывать процесс найма сотрудников
с них-то обычно и спрос :)

вот это правильно, процесс «хантинга» — это на их ответственности) но далеко не все из них понимаю, что такое

J2EE, WebServices, JMS, Hibernate, JDBC, SQL, EJB, Spring, GWT...

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

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

но это все моё мнение... ведь аргументы чаще не действуют на людей, которым и так тепло-хорошо

Качество описания вакансий (Job Description) у нас примерно такое же как описание проектов. А все вместе равно качеству написания резюме. Единственная возможность что-то изменить к лучшему — начать с себя, а затем помочь другим.

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

Job Description
На постоянную работу
требуется Джава-программист, разработчик бинов.
Требования: знание геттеров\сеттеров.
Опыт работы с безаргументными конструкторами 1 год.
Английский со словарём.
Официальное оформление, оплата сжатым воздухом.
это правда про резюме — у нас вообще мало кто умеет писать их правильно — я видела неоднократно резюме синиоров, у которых, я точно знаю, есть готовые две страницы примеров — и при этом резюме не тянет на тестера в том виде, в котором оно имеется
вот оно... вот в том то и дело, что наши описания вакансий и наши резюме — это комплементарные сущности. поясняю:
1- никто никогда точно не знает что за работу ему в предложат в данноконкретной конторе, потому что единственная вещь, на которую можно понядеяться наверняка — это нестабильность форева. любая контора — это blackbox.
Поэтому и нет возможности отформатировать подачу своего опыта в том виде, в каком он интересен конторе.
2- люди, отвечающие за найм в конторе очень редко себе представляют куда всё движется. Поэтому ведут себя как исполнительные винтики: "опубливовать объявы«- йес, «простобеседовать NN кандидатов на данную вакансию» — йес.
зы: очепятку «простобеседовать » - не стал исправлять, что-то в ней правильное, имхо.
В не-аутсорсинге, как мне показалось, описания вакансий более человечны, например:

docs.google.com/...XNM5xqZPw43fAe4

www.work.ua/jobs/529156

Это уже ближе к тому что хотелось бы видеть.

P.S. Давайте не будем про аутсорс/не-аутсорс. Рисковая тема. :)

Вот еще одна неабстрактная вакансия попалась на глаза:
Лидер веб-команды в ДубльГИС:
rabota.ua/.../vacancy4729437

Да ну? Судя по требованию «от 2-х лет» совмещенного с внушительным количеством требований в непростом проекте, они ищут того самого абстрактного сениора 23-х лет. Обязательно в вакууме.

А мне показалось что там нет ничего особенного кроме ссылки на DOU

неужели Вам не доводилось попадать в команды в которых «все делают все»? Я в такой работал и, признаться, был просто в восторге. Я, придя на вакансию java дева, умудрялся попрограмить на java, flex + редактировал базу, когда в этом была необходимость. Это было круто и все вышеприведенные требования вполне отвечают таким вакансиям.

О, вот он раскол сознания!

Мне так же приходилось работать в такой команде. И у меня ощущения абсолютно противоположные: свалил чисто из принципа.

Повторюсь. Если все-таки ищут «универсального солдата», то хотелось бы чтобы было человеческим языком так и написано, а не список аббревиатур (особенно если вспомнить что пишет не ХР, а потенциальный коллега).

Я согласен, но и сам не встречал еще чтобы кто-то писал о том, что профиль будет узким. Идя в люксофт я понятия не имел, что будет только и только java. Шаг влево, шаг вправо — расстрел. Это даже немного удручает, особенно на фоне того, что для java дева работы сейчас особо то и нет:)

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

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

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

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

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

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

А зачем мне на них смотреть? Меня устраивает мое место работы. :) Конечно хочется, чтобы все было по-человечески. Но в нашей стране везде не так. :)

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

На самом деле часто именно в Job Description большая проблема. Таки открыв любой сайт с вакансиями, ты увидишь что компания А предлагает тоже, что и компания Б. Именно поэтому я не ищу работу на сайтах с вакансиями. Я ее вообще не ищу последнее время, но это не существенно :)

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

я всеми руками за:
1. нужно давать описаение проекта + ссылку на сайт компании (технологии многим уже вторичны для того чтобы заинтересоваться этой вакансией)
2. ограничить кол-во технологий разбив их на группы (важно иметь\ желательно)
3. кол-во человек на проекте
4. указывайте диапазон зп. тратить время на то, чтобы узнать что у вас потолок по зп в два раза меньше текущей — это как минимум неуважение к чужому времени и плохие реккомендации самой компании

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

Заходишь в контору как конь в вакуум.

Обычно ищут человека, а не узкого специалиста.

Пост был о том, что вместо того чтобы искать человека, ищут широкого специалиста (чем шире тем лучше, типа ширина лишней не бывает).

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

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

Скажите, у вас реально каждый занимается всем этим? В команде нет никакого разделения труда? Человека с лабания GUI перебрасывают на настройку межсерверных коммуникаций?

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

Hibernate, JDBC. Неужели на всех проектах в равной мере разработчику придется использовать обе технологии? Да, JDBC — это база, ее надо знать, но вы же не пишете «обязательно знание классических алгоритмов и структур данных».

Надо именно знать JDBC. Иначе потом вы можете закончить в глубоком дебаге кода Hibernate без малейшего понятия как обойти появившуюся проблему. Я упоминал это в презентации «Why Do I Hate Hibernate?» (www.slideshare.net/...ate-hibernate)

EJB, Spring. Для других языков, наверное, также есть аналоги. Неужели у вас на проекте такая большая либа используется на 100%? Используется? И что, каждый разработчик активно работает со всеми частями?.. Ну, как скажете... А EJB? Тоже на 101%?.. Ну, как скажете...

Конечно можно написать Spring (Core, JMS, Transactions, JDBC, MVC, JMX, AOP), но зачем? Обычно уже на собеседовании вы зададите вопрос с какими модулями из Spring человек работал. Для этого и назначается собеседование. Обычно действительно ключевые технологии расписывают, а не столь важные оставляют в общем виде. То же самое касается EJB.

Немного о базах данных. У вас и правда используются ORACLE, MySQL, PostgreSQL, MS SQL Server? И каждый разработчик активно работает со всеми и должен знать их особенности? Тогда зачем вам Hibernate? Неужели в комманде нет DBA/DBD/чего-то_в_этом_роде?

Представьте себе, да! Надо поддерживать продукт на всех этих базах. Или нескольких из них. Разработчик отвечает за создание структуры базы данных. И не всегда можно любой запрос выразить HQL. Элементарный пример «update with subselect to the same table» не работает в MySql. И надо таки использовать «update with join» фишку MySql. Но откуда вам о ней знать, если вы знаете только Hibernate? И ооочень мало в каких командах есть выделенный DBA/DBD. А что если он в отпуске? Или уволился? Все, разработку остановить?

По крайней мере, вы можете написать более точные аббревиатуры: если уже весь Spring, то хоть 2 или 3. :)

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

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

ИМХО, тут надо менять организацию команды, а не добавлять слова в вакансию, но это все в теории, на практике может быть не возможно. Кстати, не встречал вакансий где бы честно писали «у нас каждй работает со всем стеком».

Надо именно знать JDBC.

Наверное я не смог объяснить свое отношение к JDBC. ... JDBC — это та база которую не надо указывать в требованиях (она подразумевается), особенно если есть слова связанные с БД.

Представьте себе, да! Надо поддерживать продукт на всех этих базах. Или нескольких из них.

Представляю... последние несколько лет ;) Иногда всплывают подобные проблемы. Но это не повседневная ситуация (рабочая, но не повседневная).

ИМХО, тут надо менять организацию команды, а не добавлять слова в вакансию, но это все в теории, на практике может быть не возможно. Кстати, не встречал вакансий где бы честно писали «у нас каждй работает со всем стеком».

Зачем ее менять? Классная команда, которая делает все быстро и качественно. А самое главное самим членам команды интересно работать. Не надо делать целыми днями одну и ту же рутинную работу.

Наверное я не смог объяснить свое отношение к JDBC. ... JDBC — это та база которую не надо указывать в требованиях (она подразумевается), особенно если есть слова связанные с БД.
Ну а, собственно, почему бы и не написать? Или Вас так же может смутить запись о необходимости знать ООП? Наличие слов связанных с чем-то не обязательно означает, что человек хорошо ориентируется в ООП. Я многих знаю, знающих технологии, на продолжающих писать весть код в одном методе.

И я понимаю Вас, вы смотрите на все с точки зрения профессионала. Какие-то вопросы могут быть восприняты унизительными. Но не вы единственный читаете эту вакансию. Многию люди действительно могут понятия не иметь о чем идет речь.

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

Речь не в унизительности, а в ... целесообразности. Джавст без знания ООП (в джава-смысле) — это нонсенс, «знание Хибернейта без понимания ДжДБС и транзакций» — аналогично.

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

Были времена, когда я был уверен, что круто програмлю на делфи.

А есть люди которые пишут слово class в Си-шном коде и думают что программируют на ЦПП. Дописывание аббревиатур в вакансию решает эту проблему?

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

Логично. Но ведь можно заменить строку «Hibernate, JDBC» на «глубокое знание Hibernate» или что-то в этом роде. Например, можно написать «опыт работы с Hibernate и понимание принципов работы JDBC» — это ведь конкретнее чем «Hibernate, JDBC»?

Или Вас так же может смутить запись о необходимости знать ООП?

Для Джава-программиста это бессмысленно. Повторюсь:

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

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

Я многих знаю, знающих технологии, на продолжающих писать весть код в одном методе.

Тут дело не в ООП, а в культуре программирования. Такое можно только по живому коду проверить.

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

На Java EE как правило, да.
не хочу углубляться, но Hibernate, JDBC are must for JavaEE Dev

тем более, что ноги Hibernate растут из JDBC .

EJB, Spring. Для других языков, наверное, также есть аналоги.

EJB — это концептуальная вещь, её надо понимать, хоть в общем.
Да, не на 100%
Но банальные вопросы про message-driven\сессионные бины и JPA etc неизбежны на собеседовании.

Хотим мы этого или нет.

Немного о базах данных.

если Джава дев не рубит в БД он вообще никто.

Можно найти работу не связанную с Hibernate, JDBC, EJB, Spring, если влом разбираться.


Hibernate, JDBC are must for JavaEE Dev

тем более, что ноги Hibernate растут из JDBC

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

EJB — это концептуальная вещь, её надо понимать, хоть в общем.

EJB — это хе..а туча спек.

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

если Джава дев не рубит в БД он вообще никто.

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

Можно найти работу не связанную с Hibernate, JDBC, EJB, Spring, если влом разбираться.

Простите, но писал я совсем о другом. :)

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

Я вам привел один пример в своем комментарии. Есть и другие. К примеру при любой группировке MySql вставляет автоматически сортировку, которая очень сильно может ударить по производительности. Для ее отключения нужно использовать order by null. И таких примеров ооочень много. База не важна только если вы делаете простенькие CRUD приложения.

Я вам привел один пример в своем комментарии.

Я не говорил, что их нет.

Наверное, вы были правы, примеры неудачные. Если ищут человека который будет оптимизировать работу с БД, то знание джаваскрипта ему, как правило не надо. Это конечно же утрировано, но думаю суть передает.

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

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

чем менее универсален солдат, тем тяжелее найти ему замену

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

Кстати, назовите несколько (допустим 5) отличий Оракла от МайСиквела и как часто вам приходится их использовать в повседневной работе.
найдите пять отличий между the_finger и the_peni$.
да, на первый взгляд и в некоторых случаях они неотличимы.
EJB — это хе..а туча спек.
Снова же если требуется общее понимание, то зачем об этом писать в вакансии? Чтобы соискатель зазубрил пару определений?
Согласен, туева хуча спек, но тем не менее, было бы глупо не упомянуть EJB, если оно используется в проекте, на который собирается пойти соискатель. Сейчас у нас в проекте есть EJB и там действительно нужен общий уровень понимания, но, в вакансии о EJB не было ни слова. К счастью для меня, это не стало неожиданностью, но человека, который никогда с EJB не работал, это поставило бы в неудобное положение. Заказчикам надо, а он не дуплит и вообще затягивает сроки. Так что, пускай лучше пишут все что используется в проекте, а уже на собеседовании можно более детально пообщаться и отсеять неподходящих кандидатов.
Вся суть в том, что

Hibernate

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

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

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

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

«Мы предлагаем» считаю также важным пунктом: во-первых таки удобство офиса (и его расположения), наличие/отсутствие обедов/столовой, занятий спортом и прочие «мелочи» могут играть роль. При прочих равных условиях и только в одном из предложений — оплачиваемыми обедами в офисе логично выбрать работу с последними, не так ли? В этот же пункт обычно входит информация об официальном оформлении и формате этого оформления, что также может сильно повлиять на оценку объявления и выбор места работы.

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

Не так. Если для вас это важно, то выбирайте. А для кого-то важным может важна форма стола. Суть в том что у тех-спеца цель не заманить человека, а просто проинформировать или найти того-самого. Как в этой задаче поможет перечисление 100500 шаблонных пунктов?

завтра человек не станет работать на абсолютно другом проекте с другим набором технологий и базовой БД

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

Частично проверка происходит на собеседовании. С языка на язык обычно не перебрасывают, но с фреймворка на фреймворк (и, возможно, с разными БД) — в том же вебдеве на php — запросто.

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

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

Вспомнилось

Having two somewhat similar options together with dissimilar one will make people choose a better deal among similar options.
www.moskalyuk.com/...irrational/1642

Хорошо присмотреться можно лишь работая «внутри».

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

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

Речь не об идеале, а о расстановке акцентов и о том чтобы указывать максимум полезной информации. Основная проблема в том, что зачастую 2 случайных вакансии отличаются только порядком слов аббревиатур.

О! Вот что-то такое о чем писали, прямо сейчас, можно найти на ДОУ — rabota.developers.org.ua/.../vacancy4710018

Такое впечатление, что автор данной обьявы что-то курил, когда её писал... там ,и SIP, и WiFi, и сервлеты, и аплеты, и всего пара слов об Android скилсах, хотя ищут именно Android разработчика... Вообщем, если бы я в данный момент искал работу — то эта обьява, была бы последней по которой я написал, потому как очевидно, что люди её составляющие сами не знаю, что хотят видеть в разработчике...

SIP, и WiFi, и сервлеты, и аплеты, и всего пара слов об Android

недавно лепил приблуду под Андроид, там требовалось всё вышеперечисленное, + UPnP и DLNA
получил массу удовольствия.
Вообще, Андроид — это не та область которая позволит не учить БД, Hibernate, JDBC.

они вас всё равно настигнут. Может случиться, что Андроид- Клиент пойдёт на сервер, а они — там... притаились.

Да ну ладно, ссылку на маркет плиз,посмотри что у вас там получилось и где там Hibernate и JDBC ;-) Причем тут сервер к клиенту? Если сервер нормально написан то тебе по барабану, что там юзается, главное что есть API которая позволяет с ним работать... Просто при составлении вакансии, скорее всего, принемал участие Java EE-шник с этого же проекта, вот и понапихивал туда все что считает архи-важным... ИМХО: Специалист — во всем, не специалист — не в чем...

Да ну ладно, ссылку на маркет плиз

— Illya Rodin, коварно поглаживая dedexer и зловеще почёсывая dex2jar ....
Это не для маркета.
корпоративная тулза.
Хибер на сервере, с которого клиент получает инфу.

Сервер пришлось тоже самим....

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

Зустрічне питання — ти не міг би взяти якийсь опис вакансій і переписати його по-нормальному, або просто придумати вакансію і гарно оформити? В принципі, я з тобою згоден повністю, але цікаво було б глянути як ти собі уявляєш дійсно класний опис вакансії, навіть по тій же Джаві.

Мда, логично... Так и надо было сделать, вместо этой «статьи».

По настоящему классный не обещаю, но постараюсь сделать вменяемый (по моим меркам). Если «Мы» еще ищем, то будет что-то околореальное, если нет то буду придумывать. :)

Что тут сказать?

+1 =)

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