Комментарии 304
Во Франции, например, резюме с фото очень даже практикуют.
Регулярно вижу резюме с фото в России. А в Европе, на сколько я знаю, без фото на резюме вообще смотреть не будут.
Субъективно, резюме с фото выглядит более привлекательно, нежели без него.
А в Европе, на сколько я знаю, без фото на резюме вообще смотреть не будут.
На мое посмотрели, успешно трудоустроился.
Резюме с фото — дополнительный повод для дискриминации (пусть и непроизвольной). За всю Европу не скажу, за Германию только, но мы тут получаем и рассматриваем много резюме без фото. Сама я тоже без фото отправляю.
нас в школе тут учили, что к каждому CV обязательно прикрепляется фото, типа как «best practice»
А вы говорите фото
Справедливости ради, hr-ы такое читают. Но за полноту охвата аудитории и силу воздействия на их работу ничего сказать не могу. Прошлая статейка сделала круг и вернулась ко мне же в виде репостов и упоминаний в hr-чатиках. Так что не всё так безнадёжно, но есть куда стремиться.
Их всех переманивают топовые КА, где з/п с учётом бонусов шестизначная.
За восемь лет я собеседовался в 150 (по ощущениям) компаниях, из них работаю сейчас в восьмой. Процент адекватных и вменяемых подборщиц в районе 20%. Совсем отбитых было всего три (штуки). Возможно, мне просто не повезло и Ваш опыт более релевантен.
Чаще всего дятлами оказываются те, кто собеседует. Несмотря на их
«титулы» синьор++, они просто вообще не понимают где находятся.
И все из-за того, что в львиной доле они эти титулы сами себе присваивают,
либо им их прилепляют работодатели, которые ничего в этом не смыслят.
Как правило такая схема у стартапов. Там студент находит программиста, который
делает ему какую-то эффектную крутилку, чем доказывает что он знатный прогер
и ему сразу можно доверить руководить отделом, в котором только он и числится.
Ну и естественно при расширении он же и будет собеседовать. Ну а кому же ещё?
Вот они и называют потом всех дятлами, которые хотят слишком много денег по их
меркам.
Жаргон в описании вакансии («катают» вместо лексически правильного «катаются») — еще минус 10 баллов.
Я люблю делать дело, которое умею, а не кикеры с бордами. А на паруснике я сам с удовольствием похожу, но на небольшом и в одиночку.
Вот, вы описали отличный пример того, как по вакансии сэкономили время и силы. Если коллектив немного контуженный и шебутной, то вам он не подходит и вы пойдёте дальше, а не будете тратить время на собеседования и прочие активности. А по дефолтному описанию таких выводов сделать не получится. Профит же!
Ну вот для Вас это минус 20 баллов, а кому-то наоборот, хочется стартапов, смузи и жаргона. И это прекрасно, что часть заведомо неподходящих кандидатов отсеется еще на этапе просмотра вакансии.
Вы можете быть прекрасным специалистом, технически подходить на 145%, но если Вам будет некомфортно работать, стоя на гироскутере со стаканом смузи, не лучше ли сразу этот вопрос прояснить?
Мне кажется, основной посыл как раз не в том, что "пишите стильно-модно-молодежно", а "пишите правду, а не отделывайтесь шаблонными фразами, из которых вообще не понятно, что вы из себя представляете".
Cайты типа hh дают возможность писать полноценные CV
А где там на hh место для CV?
Там есть место для вольного текста — раздел «Обо мне», но его описание («Ваше хобби, личные качества, любая дополнительная информация») как-то не намекает на подробное расписывание.
Тут я от юзкейса отталкиваюсь: распечатки из LinkedIn мне ещё ни разу не давали в качестве описания кандидата, а с hh — многократно. Поэтому позиционирую hh как платформу для CV. Но проблема как раз в том, что либо вы пройдёте hr-а, но не расскажете ничего интересного инженеру, стоящему за ним, либо наоборот — порадуете инженера, но можете не пройти hr-а.
А где там на hh место для CV?
Ответ прост — если вы откроете HH на английском языке, то «Резюме» будет там называться CV. (покрайней мере так было год назад, когда я им последний раз пользовался).
CV — Подробное жизнеописание на несколько страниц.
CV — Подробное жизнеописание на несколько страниц.и
Cайты типа hh дают возможность писать полноценные CVвытекает «сайты типа hh дают возможность писать подробное жизнеописание на несколько страниц». Ну а поскольку в «типа hh» должен входить и сам hh — то «hh даёт возможность писать подробное жизнеописание». А это несколько расходится с бегло наблюдаемым мной интерфейсом hh.
Я не берусь утверждать, что там такой возможности нет — возможно, она просто неочевидна. Поэтому я и спросил автора «а где там такая возможность?»
Статья класс, я специально на хабре зарегистрировалась, чтобы лайк поставить. Мне как рекрутеру очень интересно узнать, как IT-шники процесс найма воспринимают.
Ну вот, а господин zxweed в первом комментарии говорил что рекрутёры такое не читают. Значит не всё так плохо.
А если по делу. Не могли бы вы описать как там в Северной Америке дела с описанием вакансий и содержанием резюме? Коротенечно, для общего образования, если не затруднит. А то про РФ и Европу хоть как-то в курсе, а про соседний континент вообще ничего не знаю.
С описанием вакансий там дела обстоят не лучшим образом, хотя ситуация меняется. Многие компании сейчас понимают, что рекрутмент это тоже брендинг, что завлекательное описание вакансии при прочих равных поможет обойти конкурентов. Лично я еще лет 10 начала писать крутые описания позиций с описанием компании, отдела, команды, аппликухи над которой человек работать будет, перспективами роста и тп. Но у меня был продвинутый шеф, начальник рекрутмента, он нас научил, когда еще никто особо этого не делал. Проблема в том, что обычно нанимающий начальник ответственен за составление описания, а они ненавидят и боятся заниматься рекрутментом, т.к. не умеют. Получается, что рекрутеру придется брать на себя доп. задачу по написанию продающих вакансий, а времени и так ни на что нет.
По поводу резюме мне трудно сравнивать, я русский рынок не знаю. Специфика России в том, что у нас люди широкой специализации, а в Америке, Канаде наоборот очень узкой. У рекрутеров там так называемое compartmentalized thinking, если Java, то только Java, им надо кандидата в ячейку впихнуть. Хотя там тоже стали популярны так называемые full-stack developers в связи с появлением мелких стартапчиков, которые не могут платить отдельно за front-end и отдельно за back-end.
Еще интересно, что в России до сих пор очень много мелких контор, в которых мальчик бросающий сетку и устанавливающий 1С называется программистом. Но это наверное более верно для провинции. В столицах понятно дело не так.
Огромное спасибо за описание!
Я, честно говоря, не знаком ни с одним рекрутёром, который бы хорошо писал "продающие вакансии". Всё хорошее, что видел, оказывалось творениями CEO/CTO (если компания маленькая) либо ведущих разработчиков. Хотя на полноту охвата не претендую. ЗдОрово что есть рекрутёры, которые пишут такое сами.
А касаемо узкой специализации: на сколько она узкая? До уровня языка или инструмента (например, СУБД или веб-сервер) или ещё глубже до уровня специфичной библиотеки или конкретного юзкейса в разрезе технологии?
Вот оно как, когда предложение большое. Кажись, России и окрестностям такое ещё долго не светит. У нас все вакансии с нужным языком можно руками отсмотреть. Помню даже как-то раз таким занимался. Просто ищешь адекватного человека в нужный бюджет, лишь бы направленность хоть как-то совпадала с желаемой. Порой и соседние языки/технологии цепляешь, чтобы хоть кого-нибудь найти.
Тьфу ты. Я, по аналогии с РФ, наивно представил толпу жителей Северной Америки и порадовался за широту рынка местных кадров.
Тогда с другой стороны вопрос: соотношение местных вакансий и внешних (индия/китай) какое? И в каких пропорциях хантят? Точнее даже не так: какие политики найми глабально существуют среди компаний и как в них вписываются местные жители и "аутсорс" в густонаселённые страны?
Эки всё интересно в заморском государстве. То есть получается, прошу простить за сравнение: в Москве толпа дешёвой рабочей силы из соседнего Таджикистана и окрестностей, а в Канаде индусы просто захватили часть IT-сектора и чем больше захватывают тем быстрее ширятся?
Что же это за женский орган из двух букв...
«Многих женщин возбуждает мужской орган из четырех букв, и орган этот — мозг!»
В обеих фразах ошибка в том, что называть орган «мужским» или «женским» не совсем верно, т.к. он не специфичен для конкретного пола, но в статье ошибка еще и в том, что «ум» — не орган, как выше верно подметили.
Потому что где-то достаточно добра от PM'а и можно хоть завтра в отпуск, а где-то «бронируйте за два месяца с одобрением трёх разных людей».
«бронируйте за два месяца с одобрением трёх разных людей»
Это ещё не самый плохой кейс. Вот когда принуждают в начале года весь отпуск распланировать без возможности изменения — это засада.
Это не засада, а Трудовой кодекс Российской Федерации который требует составлять график отпусков (вот не помню он должен быть составлен в начале года или к началу года). Правда я, к сожалению, не в курсе, что ТК РФ думает на счет переноса отпусков.
С отпусками там вообще много вещей, которые вроде бы как должны защитить работника от «плохого» работодателя, но так же и в обратную сторону мешают работнику когда у него «хороший» работодатель. Например что вы обязаны ходить в отпуска, или что хотя бы один кусок отпуска не может быть менее 14 дней подряд. Или что вам должны заплатить отпускные не позднее чем за три дня до начала отпуска (а это значит что вы не смоежет в последний момент взять отпуск «завтра», т.к. вам скорее всего не успеют заплатить, т.е. работодатель «нарушил ваши права»).
Да одни эти 14 дней, в которые выходные непременно входят, чего стоят. Очень сложно такую систему европейцам объяснить. Хорошо, когда работодатель на этом не настаивает (с риском для себя), и разрешает две недели как 12 отпускных дней брать.
Отпускные тоже тот еще артефакт.
Это требование ТК РФ, вообще-то.
Я знаю, что требование. Но, как сказали выше, требование можно крутить как в пользу компании, так и пользу сотрудников. Я, как раз, говорю про случай в пользу компании, за счёт дикой головной боли для трудящихся. Ванга не у всех есть, чтобы прозреть будущее с точностью до дня. А пересогласование и переносы — это куча бумажек и нервов. Получается "стабильность" бюджета в обмен на потерю вагона лояльности и уважения со стороны сотрудников.
Ванга не у всех есть, чтобы прозреть будущее с точностью до дня.А пересогласование и переносы — это куча бумажек и нервов.
1) просто в ОК пишешь заявление о переносе отпуска и все ок… (недельки за две, если по графику не пойдешь)
2) согласуется c начальником — если он против, идешь как хочешь, а в отделе кадров все будет как в плане (т.е. ОК так и не узнает, что ты отдохнул сейчас, а не по графику), ну только отпускные не получишь…
Это ещё не самый плохой кейс. Вот когда принуждают в начале года весь отпуск распланировать без возможности изменения — это засада.
Это ещё не самый плохой кейс — хуже, когда половину отпуска можно брать в теплое и сухое время года, а вторую обязательно в слякоть и холод… а то вся контора летом уйдет — кто работать то будет?
ИП удобно, когда работаешь не на территории работодателя и в актах можешь писать разную работу, а не «мыл полы с 8 до 17 с понедельника по пятницу».
"Приходит налоговая, сообщает, что у вас трудовой договор.."
Не понял. У вас, как ИП, есть договор, есть акты выполненных работ, налоги заплачены, но налоговая вам не верит?
Ну если по формальным не стандартизованным признакам ваш договор похож на трудовой. Прописаны: график работы и укомплектованное рабочее место на территории работодателя, оговоренные отпуска\больничные и ещё что-нибудь. Интернеты нас таким пугают.
Именно. Если вы целиком зависите от вашего единственного клиента, то вы не предприниматель, а работник. Договор и прочая атрибутика будут признаны фиктивными. Плюс обоим уклонение от налогов.
А вот если ООО Рога и Копыта заключают договор с ИП Васяном о том, что тот будет находиться в их таксопарке с 9 утра до 14 дня и чинить автомобили, то налоговая очень даже может заинтересоваться.
Все дело в УСН, которая позволяет не платить 13 % на доход, а платить 6 %, плюс уменьшаются расходы на соцстрах. Налоговой об этих схемах также прекрасно известно.
Де-юре, это незаконная самодеятельность налоговой.Нет, не незаконная, ревизор проверил, заявление в суд передал. Суд признал сделку притворной или не признал.
Предпринимательская деятельность представляет собой самостоятельную, осуществляемую на свой риск деятельность, цель которой — систематическое получение прибыли от пользования имуществом, продажи товаров, выполнения работ или оказания услуг лицами, зарегистрированными в этом качестве в установленном законом порядке.
Соответственно, когда работаешь на дядю в определенное время, используя его материалы, то это никак не «осуществляемая на свой риск деятельность». Тем более, если тебе стабильно два раза в месяц зп выписывают.
Получается что закон позволяет платить 6% вместо 13%, но налоговой пох на такой закон, она может «увидеть схему», и лично у меня созрело два закономерных вопроса: а) где еще налоговая может видеть схемы? б) как мне об этом узнать ДО отсидки за схемы?
Нет, закон позволяет снизить выплаты для ИП и ИП этим пользуются. А уходить от налогов, сваливая риски на работника — это незаконно.
Сосед — физлицо. Васян ИП, сам устанавливает правила и тарифы. Может чинить машины других. Кассовый аппарат, отчетность. Так? Нет проблем.
Понимаю желание довести до ситуацию до абсурда. Но Я конце-концов вы же понимаете с какой целью ваш начальник предлагает оформить ИП? Вот и инспекторы налоговой поймут, по совокупности формальных признаков — там по долгу службы больше вашего в курсе разных мутных схем.
КМК, при таком подходе каждый первый ИП является фиктивным. Если договор составлен с компанией "Рога и копыта" на год — тут уже есть признаки мошенничества? А если на месяц? А в следующем месяце — работаем с компанией "Копыта и рога" — тогда все ок?
А то я и сам знаю почему HR мудаки. Но теперь хотелось бы понять, как не выглядеть в глазах HR мудаком.
Только если очень анонимно, но тогда смысл исчезнет и доверия не будет. А если в открытую, то слишком велики риски по потере репутации. Что-нибудь не то скажешь и припоминать будут остаток жизни. Так что мечтать можно, но увидим вряд ли… но не спорю, было бы очень интересно.
Но теперь хотелось бы понять, как не выглядеть в глазах HR мудаком.
Не HR, но по памяти могу накидать микро-список:
Лчиное
— Чистая кожа. Даже если на улице дикая жарень, элементарно убрать испарину с лица и рук будет только в плюс — могут ведь и поздороваться рукопожатием… вам приятно, когда жмут руку потной ладонью? А если еще и пыльной / в масле / липкой?
— В целом «прибранный вид»: ногти/волосы/зубы. Знаю случаи, когда были соискатели, что кажется считают зубную щетку своим личным врагом.
— Чистая одежда: знаю людей, от который чем только не несло. Были и просто что не мылись (это совсем ужас), а были и такие, что сами моются, но одежда пахнет дровами/углем/сараем.
Коммуникации
— Если указан телефон, то брать трубку. По email — аналогично, отвечать на письма.
В письмах следовать правилу «меньше 24 часов на ответ», в идеале «через час и/или меньше».
— Если указан в контактах компании Skype (или прочий VoIP/IM), то не «брать и сразу звонить», а, как минимум, в начале написать «День добрый, я по вашей вакансии, вам можно позвонить?».
— Если нет фото в CV, при договоренности на очное собеседование дать не только свое имя/фамилию, но и описание внешности — иначе могут возникнуть конфузы на режимном объекте (со мной было лично, мой прокол).
— Не перебивать собеседника, даже если от стресса под энерго-инъекцией и «на взводе».
Более с ходу ничего вспомнить не могу — кто в силах, прошу дополнить.
P.S. Ах да, верно сказано — за свои слова надо отвечать (брать на понт и/или врать — это может выйти боком).
г.Томск, ОЭЗ, один из корпусов. Резидентом там была одна фирма с корнями из Юго-Восточной Азии. Они набирали в РФ людей на инженерные позиции.
А рядом, в том же корпусе, была фирма №2.
Это была вводная, а теперь экшен: меня зовут «Василий Пупкин», я иду на собеседование в фирму №1… параллельно этому приходит туда же, «за 7 минут» до меня еще один «Василий Пупкин», что шел в фирму №2. Мы оба выходцы из центральной Азии, одного возраста. Пропуска выдают под документы пришедших и документы принимающей стороны. «Моя» фирма увидела «Василия Пупкина» (а не меня — моего фото не было, себя не описал… спутали, ибо ФИО идентичные), оформила его к себе. А следом пришел я… дальше начались проблемы из-за того, что на объект проник посторонний, заранее не согласованный с отделом безопасности.
Лишь поделился тем, с чем столкнулся на практике — дальше дело каждого из нас, учитывать подобное или нет.
Как-то раз пришел на собеседование его тезка — Максим Куликов…
Потом долго шутили, что его не взяли на работу, чтобы LDAP не ломать :) (на самом деле по другим причинам).
Т.е. техники днями на пролет учат алгоритмы и решают тестовые задания в поте лица, готовясь к собесу. А HR по результатам выбирают того кто симпатичные и от кого вкуснее пахнет?)
Вот и вопрос — а оно надо то, такое терпеть в XXI веке? У нас не «железный зановес»: что парикмахеры/стилисты, что магазины с мужскими средствами гигиены (и нормальной одежды так же) — всего в избытке, остается только брать и использовать.
Делаю ставку на то, что большинство все это знает. Тогда к чему ваше замечание?
К тому, что бывает иная крайность (выбираем только за вид)?
Ну да, shit happens =/
Но ведь это не значит, что не надо следить за собой и быть приятным для окружающих.
но все же ваши девочки там явно не из-за опрятности оказались.
Нынче программист может не найти работу в двух случаях: он либо клинический дятел и неадекват, либо хочет в качестве оклада звездолёт.
Ой да ладно. Посмотри вакансии, там большинство хотят опыт работы от 6 лет и чтобы знал все технологии на свете и английский уровня (B2).
А касательно английского — это сложилось из-за того, что кандидаты любят себе накидывать дополнительный уровень.
Но, согласитесь, так не должно быть. Ведь хочется видеть релевантные данные о потребностях бизнеса, а со своей стороны предоставить честный рассказ о достижениях и умениях. А то получается базар какой-то, где друг друга обмануть пытаются, а не долгосрочные взаимовыгодные отношения построить. И навыки при таком подходе нужны от продажника гербалайфа, а не от профессионала в своей сфере плюс чуточку софтскилов.
Бесспорно, после определённого размера компании, кадровики нужны. Они, если правильные, снимают много нагрузки и знатно время освобождают для профильных активностей. Другое дело, что отдел кадров тоже надо правильно организовывать, чтобы толк был и реально нагрузку снимали. Но это уже вопрос бизнес-процессов.
А можете пару примеров показать, если есть? Ради личного интереса посмотреть хочется.
Тем не мение, именно эту версию я продолжаю адаптировать под вакансии когда хочу куда-то зааплаиться.
На самом деле очень часто встречаю название кнопки «Upload CV/Resume». Т.е. уже подразумевается двойственность документа.
Что Вы не раскрыли, это Cover Letter. Это момент в пост-советском пространстве, как культура, отсутствует напрочь. Хотя важность этого документа даже в западных рекрутёрских кругах не имеет единого мнения, но все сходятся — лучше с ним чем без него.
Нынче программист может не найти работу в двух случаях: он либо клинический дятел и неадекват, либо хочет в качестве оклада звездолёт
Пока Вам не исполнилось 35 лет именно так и происходит.
Честно говоря, знаю только про проблемы молодых девушек, которых не хотят брать из-за большого шанса их ухода в декрет в ближайшие пару лет. Больше ничего системного и масштабного в этом вопросе не встречал. Поэтому хочу поинтересоваться, что происходит после 35 лет? Знания и опыт превращаются в тыкву или компании перестают быть в вас заинтересованными? Интересно не только из любопытства, но и для лучшего понимания своего будущего.
Впрочем, на растущем рынке это не сильно страшно.
Вопросы, собственно, простые: 1) как долго рынок будет расти 2) насколько вы уверены в своих силах толкаться на этом рынке с молодыми в 63 года (да-да, вам еще 2 года до пенсии, как кульминация проблем с возрастом).
Вы, отчасти, описали выгорание. Про него недавно писал Стратоплан. Отлично получилось.
А про боязни — это молодые и странные менеджеры. Взрослых разработчиков, многие, больше любят. Ибо у них дети, они более спокойны и локализованы в пространстве. Шило в попе уже рассосалось, а опыт никуда не делся. Так что разные ниши вижу, а проблему людей после 35 понять всё ещё не могу.
Очень абстрактно и спорно. Нужна статистика по возрастам и профессиям, чтобы предметно о таком говорить. Плюс, полгола — это совсем жёстко. Такую заразу ещё поискать надо.
От себя могу только личное мнение высказать: работал с разработчиками до ~50 лет. На здоровье никто не жаловался и чаще/дольше молодых они на больничных не были. Плюс, субъективно, программисты (в большинстве своём) — зануды и следят не только за качеством кода, но и за здоровьем и другими важными аспектами жизни.
Вы правы, такое бывает, но с частотой возникновения заболевания — примерно 1/25 000 человек/год (источник). Чтобы гарантированно заметить проблемы, нужна частота побольше. Хотя бы десятые части процента, а лучше единицы процентов. Например, простудой в год болеет 20-40% населения. Это легко наблюдать каждый год и она реально влияет на нашу жизнь.
Честно говоря, знаю только про проблемы молодых девушек, которых не хотят брать из-за большого шанса их ухода в декрет в ближайшие пару лет. Больше ничего системного и масштабного в этом вопросе не встречал
То есть там где вы работаете средний возраст работников как вцелом по промышленности 40 лет с небольшим?
Или мы говорим о разных вещах?
Про девушек пишу по опыту работы в военке. Конкретно в моём месте средний возраст очень разный был. От отделов из дедушек пенсионного возраста, до отделов где в команде средний возраст 25 лет. Так что это то же самое, что среднюю температуру по больнице мереть. Но, справедливости ради, стоит отметить, что чем ближе к программированию абстрактному, тем моложе был коллектив. Токари-слесари — почтенные дядечки, плисоводы-железячники — мужики с 1-2 детьми, веб-разработка — по больше части молодёж. И всё это в рамках одной компании. Надеюсь ответил на вопрос.
Личное мнение: редкий программист доживает в ранге программиста до 50 лет. Он гораздо раньше уходит в архитекторы/руководители, либо меняет поле деятельности на, например, собственную фирму. Поэтому численность возрастных программистов невелика и, вполне возможно, они спокойно работают в серьёзных энтерпрайзах, где их ценят.
С другой стороны, где-то на хабре была статья про взрослых программистов. Там был основной посыл, что большая часть современных программистов — это люди из 1980-90 годов и им до 50 лет ещё минимум 10 лет. Поэтому, бум 50-илетних нам ещё предстоит. Поживём — увидим.
Для меня было потрясение в первой международной команде, как много программистов 45+
Вот после нормального технического ВУЗа тебя «никуда не берут». И идешь работать абы куда. Вроде бы ничего все. Работаешь «абы где» лет 5 и начинаешь задумываться о своем будущем. Идешь на рынок труда. Берут уже «поболее, чем никуда, но тоже почти никуда». Ладно. Работаешь еще лет 10. Начинаешь уже волноваться о своей профпригодности. Опять идешь на рынок. Берут уже «чуть больше, чем никуда». Нормально. А что делать? Жить-то надо. Работаешь дальше. И так проходят десятилетия!
И вот ты уже почти в 45 понимаешь, что надо бежать так быстро как только возможно, и еще быстрее, чтобы «взяли больше, чем никуда». Может успеешь продаться «больше, чем никуда и еще больше», может уже не успеешь…
Что это, Бэрримор?
На собеседованиях стали спрашивать почему я столько лет работал простым программистом. Неужели не было желания попроектировать? Резонный вопрос, черт подери! И я стал задумываться, не реджектить «глупые вопросы». Было!!! Было желание попроектировать! Было на каждой работе желание сделать суперсистему. Надежную и быструю. Но улетучилось. Сейчас уже никакого желания нет. Всё равно. Работаю идеально, быстро, багов не делаю, фичи прикручиваю исправно. Но всё равно.
И лихорадочно ежедневно цепляюсь за уходящую лодку новейших технологий, иначе останусь за бортом!
Но если есть желание, то разумно действовать так: взять какую-нибудь боль и предложить архитектурное её решение. Если получится его продвинуть, то в резюме можно будет добавить галочку про улучшение архитектуры. Дальше уже в той же или в иной компании можно претендовать на позицию с большей ответственностью. Разумеется при этом нужно иметь ещё и неплохой кругозор в этой и в смежных областях.
разумно действовать так: взять какую-нибудь боль и предложить архитектурное её решение
У нас ща в компании есть проблема производительности софта, она постепенно решаются распараллеливанием. Архитекторов у нас в компании нет. То есть просто ставятся задачи распараллелить этот компонент, тот компонент и проч. Такую заслугу себе в резюме не приклеишь. Да еще и все эти задачи идут в другую команду, не в мою.
Просто мне кажется, стоит лично для себя ответить и найти этот основной мотив. Он есть.
Хм, не многовато ли архитекторов/руководителей получается?
Кроме того за знания и опыт платить мало кто хочет. У меня отец java/oracle программист в банковской сфере. И когда меня просят посоветовать крутого oracle специалиста (обращались уже раз 50 (за 70 тысяч, ага (да еще ведут себя как Эдисон))), то я еще ни разу не дал его контакты. Работу менять он не любит, а беспокоить его таким, простите чесслово, фуфлом, это ну просто крайняя степень неуважения.
А в 35 если он не дятел — его уже по рекомендациям передают как руководителя отдела/департамента/архитектора из рук в руки.
Смею поспорить. Бывают нехорошие люди в руководстве, но их не больше, чем засранцев во всех остальных сферах жизни. Просто результаты и косяки руководителей гораздо заметнее. Это как ошибка выжившего, только наоборот.
Бывают нехорошие люди в руководстве, но их не больше, чем засранцев во всех остальных сферах жизни
Ой ли… Поговорка из СА «Чистые погоны — чистая совесть» Вам знакома? А если телек включить, то там просто живая иллюстрация того, что все руководство — это собрание мразей и тварей.
если человека не повысили в руководители до 35,
Бывают люди, которым это нахрен не надо, им больше по душе сидеть и писать кот.
Начальники — получают больше
Как внизу правильно заметили, геморроя у них тоже больше.
когда есть жена и дети, то лишние деньги совсем не помешают
Они и без жены-детей не помешают.
Сие есть великое заблуждение. Начальники могут получать больше подчинённых, но верно и обратное: разработчики могут получать больше своих руководителей. Это не везде практикуется, но факт остаётся фактом.
Тут же хочется вспомнить "Мифический человеко-месяц". Там предлагали замечательнейшую штуку: в общем случае, менеджмент и разработка — это параллельные ветви эволюции. Эти две ветки можно комбинировать в любых пропорциях.
Вы же, кажется, рассматриваете частный случай, когда разработчик пошёл в руководителя без отрыва от основной деятельности. В этом случае, обычно, даётся "бонус", за "вредность" сверх стандартной ставки. Но такое работает только до тимлида. Дальше совмещать тёплое с мягким не получается. Но рост из-за этого не кончается.
Правильно ли я понимаю вас, что после 35 лет, надо, в угоду деньгам (к тому же "лишним"), ставить крест на своих интересах и желаниях? Т.е. вместо того, чтобы делать то, что сердцу мило, надо получать, условно на 20% больше, но руководить?
Мне всегда казалось, что с каждым годом должен быть прогресс. Задачи всё интереснее и интереснее, жизнь краше и проще, возможностей все больше и они разнообразнее. А тут получается, что в будущем какое-то прямо проклятье подстерегает. Мол или неудачник, или начальник.
И я таких людей знаю больше одного.
400 тыс * 2**8 = 102,4 млн. человек
что уже первышает чилсенность всего трудоспособного население России (см. www.gks.ru/bgd/free/b04_03/isswww.exe/stg/d01/36.htm) которое еще имеет тенденцию и к снижению.
Единственный вариант, который я вижу — это вкладывать свои средства (пусть и меньше указанных) и найти тот вариант вложений, который позволит заниматься чем угодно до конца жизни. И тут уже неважно в какой сфере ты работал раньше
Не ждать пока оторвут от груди и дадут новую погремушку, а возьмут свою судьбу в свои руки. В IT сфере, в отличие от многих других, пока еще можно подниматься и этот процесс зависит только от тебя.
И не всем дано в руководители. В свое время я сознательно полез в это дело. Пришлось вырабатывать методики и корректировать подход, чтобы не сдохнуть под бесконечным стеком задач. Сейчас я вокруг вижу людей, которые сталкиваются с теми же самыми вещами и не справляются, не успевают итд итп
Тут уместно вспомнить, что многим мальчикам нравится женский орган из двух букв. Этот же орган позволяет качественно хантить и нескучно жить.
Блин, все вспомнил, которые мне нравятся: ни одного из двух букв. Потом вспомнил рекрутерш, которые мне нравятся, качественно хантят и нескучно живут: множества органов пересекаются, но то тоже ни одного из двух букв нет.
Пришлось гуглить...
Тут немного выше уже обсудили эту тему. Так что вам туда.
Общие фразы про ТК не работают
Это всё равно, что на базаре у торговки спрашивать: «а помидоры свежие?». Вам хоть раз отвечали: «нет, вялые, позавчерашние и изрядно давленные»?
Не совсем в тему, но:
- однажды мне на вопрос «свежая ли рыба?» продавщица в большом супергипермаркете очень тихо сказала "лучше не покупайте, приходите через пару дней",
- а моей подруге охранник в фирме «бесплатные услуги косметолога, презентация» охранник сказал "не ходите, это обман, вы и так красивая".
Примеры реальные, но не совсем корректные. В обоих случаях "советчики" не являются обладателями доли в бизнесе и им решительно пофиг что с ним будет. Даже оклад у них никак не зависит от продажи. А бабка с помидорами лично заинтересована в их продаже так же как и компания в скорейшем и успешном хантинге нужных кадров.
— Официант, будьте любезны яичницу и пару добрых слов!
— Пожалуйста, вот ваша яичница.
— Благодарю, а что насчет добрых слов?
— Не ели бы вы эти яйца…
Бабка с помидорами не будет продавать гнилые помидоры, в отличие от компании… Ресурсов не хватит...
Это лишь снаружи все HR одинаковы. Изнутри у них разный бизнес и разные цели. Поэтому и рекрутинг сильно разный. Как получать больше профильных предложений? Заводите личные знакомства и устанавливаете прямые контакты.
Изнутри у них разный бизнес и разные цели.
А не могли бы чуть более развёрнуто рассказать? Интересно что там внутри и с чем ассоциировать то или иное поведение/действие рекрутра.
Стартап 5 человек ищет спеца с нужными компетенциями. Готовы всерьез общаться на профильные темы. Но не много. Еще же на свои kpi надо накодить.
Веб-студия, 40 человек. Свой HR. За последний год провела очно более 200 собеседований. Взяли 10. Сколько обработала резюме уже не помнит. Много. :)
Рекрутер на фрилансе. Собирает контакты кандидатов по ключевым словам на горячие вакансии. Сегодня ищет девопса, завтра senior sap тыцмыц. Вникать во все эти аббревиатуры? Сума сошли, я экономист по образованию. Пара писем, 15 минут общения. Продан. Больше с этим кандидатом она не встретится.
Аутсорс. Over9k голов. На собеседование? Рекрутеры на 10м этаже. Здасте. Вы к кому? Он в другом офисе на тренинге. Там зал больше. Английский B1? Cool! Оформляйся. Завтра обсудим детали.
А еще заводы, гос.сектор, продуктовые компании, диджитал агенства, фриланс, торговые сети, банковский сектор и сотни мутных контор.
Разработчики же считают себя штучным товаром и требуют индивидуального подхода. Как мама с папой считали 20 лет тому назад, так и теперь считает каждый из тех немногих десятков тысяч, кто год назад указал в резюме реакт.жс. Такова традиция. Как то так.
Я на данный момент ищу вакансию на Senior SA с функциями DevOps.
На собеседованиях задолбался уже отвечать на однотипные вопросы по типу «А расскажите, как устроен протокол TCP/IP с описанием датаграм», «А какой ключ нужно использовать в iptables, чтобы добавить правило в prerouting», «Какие ключи вы будете использовать для сборки йобы/неба/
Неужели собеседующие не понимают, что в работе system administrator важен, простите за тавтологию, системный подход?
И что senior не должен весь этот мусор держать в голове, если его можно за 30 секунд найти в гугле? Жопа горит жутко.
Я от этого становлюсь хуже как специалист?
Касаемо iptables — я в курсе, что iptables использует ряд таблиц для работы с правилами. Если мне надо составить цепочку, например, тот же форвард (за последние 10 лет работы мне нужно было это сделать от силы раз 10), я загляну в ман.
Зачем мне это помнить? Если я на дню буду писать по 10-15 цепочек в iptables, то естественно я выучу синтаксис наизусть, но нафига оно мне надо в оперативной памяти?
Я тоже людей собеседовал, для меня совершенно нормальным ответом на вопрос «Как пробросить порт через nat?» является ответ «С помощью iptables». Человек знает, что это такое, знает, что есть такая технология/софт. Значит, может зайти в гугл и посмотреть ман или best practices.
Даже ответа «Сейчас точно не знаю, но предполагаю, что есть некий софт, который позволит решить данную задачу, а архитектуру я бы выстроил таким образом {развернутое описание}» тоже котировался бы.
Нафига нужно зубрить ключи? В эпоху IaaС как-то странно акцентировать внимание на каких-то конкретных технологиях и уж тем более изучать их досконально. Главное системный подход. Но почему-то работодатели этого не понимают.
Я еще кучу примеров по теме могу привести, но я думаю основной посыл вы поняли.
Вообще, на моей памяти, я всегда устраивался почему-то именно в те компании, на собеседованиях в которых меня меньше всего гоняли по теории, а спрашивали общее видение решения проекта. И в них я меньше 2-3 лет не работал после трудоустройства.
А вот эти вот все вопросы по ключам/софту/цепочкам — это, извините меня, дроч.
Таки вы всё великолепно описали! Если на собеседовании экзаменуют размер вашей памяти и её содержимое, а не изучают ваше понимание предметной области, навыки и опыт, то это большой намёк на то что нужно либо разобраться зачем они это делают, либо валить подальше.
Я в таких случаях задаю любимый вопрос "а зачем вы это спрашиваете?". Если начинают что-то невнятное говорить про "это же основы и их надо знать", либо начинают злиться, то всё с ребятами понятно и конструктивно с ними не поработаешь.
Со своей стороны (как собеседующий), до вопросов про ключи команд и прочие детали дохожу очень редко. Если человек в теории ориентируется шикарно, видно что недавно пользовался технологией и настраивал что-то, то можно спросить и про конкретные ключи, чтобы понять действительно ли он много настроил и каким способом использовал технологию. Но оценка в этом случае работает в одну сторону: если ответил, то плюс, если не ответил, то просто идём дальше, ибо не обязан знать такое.
Ну понимание предметной области - тоже штука весьма растяжимая. Как ее оценивать?
Например, сетевое взаимодействие. Как приложение связывается с сервером по сети? На какой стадии ответ будет достаточным? На "по TCP/IP"? Или нужно знать про SYN/SYN-ACK/FIN/FIN-ACK? Или надо добавить знание последовательностей и перепосылок? Или еще сверху знанием про TCP-window придавить? Или еще знанием про структуру заголовка секгмента присыпать? Все это основы и их надо знать (если мы говорим про senior SA/Devops), но степень погружения может быть очень разная.
В целом я согласен, что знание конкретных ключей или заголовков - это излишне и можно гуглить. А вот на каком этапе признать знание достаточным и сказать "остальное гуглится" - я для себя не решил, что при собеседовании кандидатов (или прохождении собеседования) несколько мешает и с одной стороны приводит к "они спрашивают какую-то легко гуглимую дичь", а с другой "он же элементарных вещей не знает".
И с третьей стороны, читать ман и гуглить в случае аварии будет уже поздно.
Таки, как я и писал выше, есть же вопрос "а зачем вы это спрашиваете?" Если есть более-менее жизнеспособный юзкейс, который может случиться с кандидатам в ходе работы и по которому нужно знать очень интимные подробности — никаких противоречий. Кандидат чуть лучше узнаёт ваш проект и ваши насущные проблемы, а вы получите представление о глубине знаний кандидата в конкретной области. Чаще же всего, либо спрашивают дикуху, а потом оказывается, что по работе эта дикуха вообще не нужна, либо забывают подготовиться к собеседованию и не могут вразумительно объяснить причину столь глубокого вопроса, хотя она и есть. В обоих случаях — косяк собеседующего, а страдает кандидат… ну и бизнес заодно.
Ещё вариант из личного опыта. Иногда я люблю делать следующее: предупреждаю человека "вот щас я буду спрашивать адовую дикуху, не пугайся, в породе это не надо и на результате собеседовании негативно не отразится, только в плюс может зачестья; хочу попробовать твою широту знаний оценить". И дальше идёт любая адовая хрень. Либо тыкаю пальцем в небо, либо стараюсь спросить что-то в районе навыков, которые ранее человек озвучил, при условии что я сам хоть что-то там понимаю. Так мне как-то рассказали очень подробно о процессе загрузки юникса, о нюансах работы с ffmpeg в конкретной области обработки видео и ещё несколько весёлых историй. С людьми было просто интересно общаться. Заодно я понял на сколько глубоко кандидаты могут закопаться, а это очень важно для некоторых позиций.
Ну а ответы в стиле — я не помню, но могу загуглить/посмотреть на SO, это конечно хорошо, но для уровня senior не подходят, имхо. По крайней мере когда мы говорим о базовых вещах, а не о ключах программы.
Нафига нужно зубрить ключи? В эпоху IaaС как-то странно акцентировать внимание на каких-то конкретных технологиях и уж тем более изучать их досконально.это одна из базовых и наиболее важных служб, на работу которой завязаны почти все остальные сервисы и я не понимаю, как можно не знать. Возможно я старой закалки :)
Или вот, для понимания кругозора кандидата прошу как можно подробно описать процесс загрузки linux (без привязки к дистрибутиву) от момента нажатия кнопки питания и до момента появления приглашения в консоль. Так вот мой опыт показывает, что только 10-15% кандидатов хоть как то могут описать этот процесс. Остальные в том же стиле — а зачем мне это знать/не было нужды. И это печально.
В последнее время я начал давать тестовые задания, но тут есть как плюсы так и минусы. В идеале бы всем кандидатам давать тестовое и посмотреть как они загуглят решение и сколько у них уйдет на это время, но увы это практически не реально.
Ведь не зря у того же Red Hat сертификация это только практика, никаких вопрос с вариантами ответов. Вот комп, вот задания — вперед. И там вы уже не скажете — а я не помню, сейчас загуглю, единственное насколько помню — можно пользоваться man :)
— В 2-х словах на пальцах пояснить принцип?
— Зачитать наизусть RFC на 100 страниц?
— Знать алгоритм работы BIND с учётом всех оптимизаций для последних 5-ти версий?
— Знать наизусть все постановления ICANN за последние 15 лет и ещё парочку подковёрных баек от знакомого администратора корневого сервера?
Если, например, пишите, что «эксперт в PostgreSQL», то будьте добры знать как он устроен внутри, а не запускать «explain analyze» раз в пару месяцев.
Ох зря вы им это подсказываете. Я считаю, что я неплохо владею pg, но на вопросы об устройстве wal/репликации/и тд отвечать не буду, это есть в справочниках.
Большая проблема в том, что все пытаются играть в какую то викторину. Дайте блин конкретную задачу, я вам скажу как ее решать.
Дайте блин конкретную задачу, я вам скажу как ее решать.
А, у вас тоже на собеседованиях создается впечатление, что вы попали на гребаный экзамен, и по окончании собеседования у вас попросят зачётку?
Полностью поддерживаю, с наймом в ИТ сейчас какой-то трэш.
Цель не ответить как устроен WAL, какой размер страниц и как его можно изменить или любые иные тонкости. Цель понять, что вы ходили внутрь и в курсе что там не драконы и бабайка, а конкретные технологии и архитектурные решения.
На примере ПГ, если человек говорит что отлично в нём разбирается, то я ожидаю, что он сможет рассказать про этапы разбора запроса, зачем нужен WAL, как там ПГ с ФС взаимодействует, где там особенности могут быть и тд. То есть без конкретных конфигов и значений, а просто глубокое понимание технологии. Иначе можно до бесконечности ковырять explain, когда у вас просто ститистика стухла, а вы просто не в курсе, что это и зачем она.
И да, задачки тоже есть. Есть люди, которые от практики идут. Сам такой. У них спрашиваю варианты решения практических задач.
то я ожидаю, что он сможет рассказать про этапы разбора запроса
Зачем? Откройте справочник и прочитайте. Я отвечаю коротко: не знаю. Я не знаю какие есть индексы у пг, понятия не имею об используемых алгоритмах, о кеше линукса и тд и тп. Я лично не ищу рабовладельца, я ищу людей с которыми можно работать. И то не нахожусь в поиске, а просто люблю побеседовать.
Конечно я знаю и как устроен кеш(примерно) и прочие вещи. Но я знаю это в контексте. Как справочник моя память просто не работает. И собственно вокруг слишком много и быстро все меняется, я лучше лишний раз загляну в документацию.
Пример: какие есть типы индексов в пг? Понятия не имею. Надо построить индексы — открываем доки и смотрим. По сути если не считать gist/gin то там только b-tree. В новой версии есть подвижки по hash индексам. И я это знаю только потому, что регулярно заглядываю в доки.
зачем нужен WAL
А зачем? Админы пг настроили? Памяти пг выдали? Положили WAL на отдельный диск? Все, забыли и не трогаем.
как там ПГ с ФС взаимодействует, где там особенности могут быть и тд.
И еще разок: зачем? Вопросы про фс, page cache и прочее я слышу с завидной регулярностью. Вы действительно уперлись в производительность настолько? Простите, не верю. Я уже даже на спор переписывал запрос с многократным ускорением.
Иначе можно до бесконечности ковырять explain, когда у вас просто ститистика стухла, а вы просто не в курсе, что это и зачем она.
А оно нужно? Вы правы, понятия не имею. У пг можно при желании в такие дебри забраться, но зачем, если среднее время выполнения запроса 15мс?
Есть люди, которые от практики идут.
Дело не только в практике. Дело в YAGNI
Поймите меня правильно. Я маньяк производительности, у меня глаз дергается когда я вижу на сайте 360 запросов со временем выполнения 1 сек (ок, пусть даже 0.3с). Я люблю вылизывать запросы и узнавать нечто новое. Но у меня ощущение постепенно складывается, как будто я один такой. С одной стороны у всех хайлоад, тестирование и прочие классные штуки(увидеть бы эту страну оз) с другой какие то туповатые ORM, полный игнор prepared запросов и форумы(или минисайтики), заваливающие нормальный сервак уже на 1000 пользователей.
Почему не поговорить о денормализации? О функциональных индексах и immutable процедурах? CTE? FDW? И миллион прочих классных штук)
Уважаемый, была бы у нас вакансия открыта, я бы к вам уже с офером бежал. За конструктивную критику подхода, описание его минусов и предложение своего варианта обсуждения.
Именно так и хочется общаться. Либо слышать ответ с описанием практики, либо встречный вопрос "а зачем вам это?". Рассказать зачем, где столкнулись и сколько времени потратили; порассуждать о возможных причинах, понять что оба не дураки и пойти дальше.
А из личного: мне о FDW вообще говорить не с кем. Вон, аж писал про доступ в MSSQL и Access через ПГ. Но любителей поговорить на такие темы практически не нашлось.
Уважаемый, была бы у нас вакансия открыта, я бы к вам уже с офером бежал. За конструктивную критику подхода, описание его минусов и предложение своего варианта обсуждения.
Спасибо на добром слове. Действительной такой формат мне тоже нравицо.
понять что оба не дураки и пойти дальше.
Эх еслиб так было хотя бы в половине случаев. Обычно наоборот: жуткий допрос, ответы в стиле «не важно», «любые», «миллиард», «много петабайт» итд, потом переход на повышенные, понимание что оба дураки. О или мое любимое — листочек: сразу возникает желание спросить нет ли проблем с денежкой на phpstorm/idea/datagrip
А из личного: мне о FDW вообще говорить не с кем
У меня несколько специфичный опыт. Я делаю всякие простенькие интранет штуки типо касс, статистики и прочих сервисов с упором на скорость работы оператора, попутно собирая данные из всевозможных crm/erp и прочих штук. Постоянно ищу способы оптимизировать это дело. Причем велосипедами, да, хотя с моей колокольни велосипеды это те самые большие, толстые, универсальные, общедоступные инструменты.
Access через ПГ
Например, не так давно захотел я себе фиас в базу. Все же говорят: возьми готовое решение. Ну я попробовал. Дня два пробовал я вам скажу. То куча ошибок, то записей не хватает, то скорость обработки на грани фантастики, каждый второй поля переименовывает, ухх веселье. Быстрее бы свое решение написал ей богу 8)
Вот ради посмеяцо накидал как то:
— нашел ФИАС
— скачал, распактовал, увидел что на 1 таблицу по сотне DBF
— скачал утилиту для ипорта dbf в pgsql
— импортировал
— увидел кривую кодировку
— выяснил что фиас в доброй ламповой cp866
— час танцевал с кодировкой
— скачал новую утилиту, pgdbf там все легко и просто а в случае чего можно использовать Iconv не изнутри а через пайп
— затолкал, все гут
— написал скриптик для обхода каталогов
— затолкал все
— обнаружил что ~15% не затолкались
— час танцевал с кодировками
— выяснил что DBF битые и даже без перекодировки им плохо
— пробую утилиту на go
— формат не тот, ошибки возвращается через ж
— сношу утилиту вместе с go
— часа 2 на гитхабе искал утилиту разбирающую xml в потоковом режиме и не старую (ибо формат меняется)
— 2 часа качаю xml, 6 часов распаковываю
— нахожу вроде все то что мне нужно но на php/yii
— качаю фигню композером
— не робит, выясняю что установленный через apt композер нежизнеспособен
— снес композер,
— ставлю через php согласно оф документации (sick)
— пробуем… ага надо поставил плагингчик судя по ошибкам
— ставим плагин, ставим yii
— Блин как это долго, а че это оно ниче не делает? ой да унего глюк и строки статуса не в длинну а в ширину пошли)
— пробуем вызвать композер или yii через командную строку, облом
— смотрим лог, ошибок нема
— выяснил что у композер не положил линк в /usr/bin мб не хватило прав, хотя он сам орет не запускайте его под рутом)
— положил симлинки на композер и yii
— запустил создание проекта
— час ждем О_О
— создал проект
— применил миграцию
— прописал соединение с pgsql
— выяснил что с пг работать оно не умеет от слова почти никак
— переписал на mysql
— выяснил что в библе автор юзаед load data local infile на кой то хрен
— прописал его юз в конфиг
— выяснил как затолкать его юз в конфиг yii
— выяснил что в начале импорта библа дропает ключи, и в случае ошибки при импорте следующий раз сдохнет на этом моменте
— отрезал дроп и добавление индексов
— запустил!
— ждал 6 часов
— перекинул данные в пг
— открываю оф документацию фиас
— привожу имена полей в соотетствие с документацией
— ставлю коментарии из оф документации всем полям
— ой а почти все поля у нас varchar(255), меняем
— делаю пачку индексов, добавляю триграмм индекс по названию
— накидываю запрос, тестирую, 12 мс, ура
— выдыхаю
Весело у вас. Описать не хотите в в виде статейки с неприличными техническими деталями?
Конкретно по фиасу на глаза попалась перловская утилитка, которая по отзывам работает и не мучит мозг, как нить попробую, но и тем для статьи уже не станет 8(
Да потому что дать конкретную задачу — достаточно сложно
Вы нанимаете человека просто посидеть за компом? Мне уже неинтересно. Какие у вас реальные задачи?
Когда на проде упадет перфоманс по непонятным причинам
Какэта? Смотрим чем занят сервер, находим обжору, выясняем почему так. Решаем. Я собственно даже не очень понял слово «перфоманс»: как конкретно это выглядит?
а не начал читать в справочнике «что такое WAL и как устроена репликация»
Вот просто взял и перестал? И в логах у обоих серверов пусто? Мистика 8)
А ведь придецо читать. Ибо решения у разных компаний могут быть весьма различными.
ЗЫ и кроме всего прочего, разбирацо с этими вещами не дело разработчика.
Вы ни за что меня не убедите, что вы не смогли изучить это за всю вашу жизнь, но прочитаете и найдете нужное место в толстенном справочнике когда возникнет продинцидент.
Мне вас убеждать лениво. К тому же, есть подозрение, что это работа ваших администраторов. Незнаю почему вы разработчику такие вопросы задаете.
Обычная база их много пишет в разные файлы, знаете ли.
cd /var/log/postgresql
А если вы о статистике то там ее столько, что помнить всю невозможно от слова совсем.
Например если вы просто не знаете про существование library cache lock, вы до посинения можете логи читать, что вы там увидите?
Oracle? Не эксперт, но нечто мне подсказывает, что если
SELECT v.terminal,
w.*
FROM v$session_wait w, v$session v
WHERE w.sid in ( select sid from v$session) and
w.event not like ('PX%') and
w.event not like ('SQL*Net%') and
w.wait_class <>'Idle' and
w.sid=v.sid
order by w.event
То узнаю. И быстрое гугление подтверждает мою догадку.
Реальная жизнь она очень разная, я хочу сказать. Возможно вам никогда это знание не пригождалось, это не значит, что все кому это знание нужно, занимаются херней.
Вы ищете сферического коня в вакууме? Раз у вас есть насущные задачи дак и задавайте по ним вопросы.
Когда зачастую в качестве реальной задачи дается кусок лога, где ничего кроме цифр метрик нет, с вопросом «что же нам делать» — почему-то часто собеседникам становится неинтересно.
Вот просто молча кусок лога? Спасибо, вы мне не подходите.
Если же:
— вот у нас такие задачи, такие трудности
— вот база
— вот лог
— может чтото сможете сразу предложить?
— вот ноут, инет, Datagrip (ну или консоль на худой случай)
И опять неинтересно, ну, наверное вы мало предлагаете и к вам идут совсем не те люди. Кстати часто слышу вопросы в стиле «не подскажете ли oracle-гуру на зп 70 тр», это даже не смешно.
Потому что вы(ну, не вы лично, а человек, который пришел на собеседование) эксперт в pg — напомню, именно с этого и началась эта ветка дискуссии. Кого мне еще спрашивать, как не эксперта?
Судя по вашим вопросам: DBA. Или у вас разработчики такие вопросы решают?
Если вы не знаете что гуглить, то и не найдете.
Посмотреть чего ждемс это такое странно и неочевидное решение?
Ну ок, вы нашли, дальше что?
Вы упорно упускаете, что я не спец по oracle. Но если вам нужно: дальше 2000р/час, по факту решения проблемы. Естественно за минусом времени на базовое изучение oracle.
Помнить — нет. Представлять внутреннее устройство — да.
Всего оракла? И как долго ваши знания будут актуальными?
А чем вам не насущная задача? Вот вам лог сервера, что с ним не так?
Я уже нахлебался задач где ответ: ничего. Учитывая, что я на вас еще не работаю и задача не представляет интереса, мне просто лень.
Вы не знаете ни где я работаю, ни кто к нам идет, ни сколько мы платим. Давайте обойдемся без переходов на личности
А я и не перехожу. Я делаю закономерные выводы.
Если контора ищет эксперта по постгре, то вполне вероятно что им действительно нужен эксперт, способный сказать в чем проблема по логу.
Ок, есть проблема. Давайте лог и консоль. Именно в логах нет там ничего особенного кстати.
Поэтому включают такой условный фильтр блума — если гуру не знает про то как разбирается запрос, возможно это не гуру вовсе, и дальнейший разговор не имеет смысла.
Вне контекста таких вопросов можно за 10 минут придумать сотню, Эйнштейна думаю цитировать нет необходимости? Свою кандидатуру снимаю сам.
Что вы не пошли к ДБА просить менять кодировку файлов и их импортировать? Сказали бы — не моя задача, я разработчик.
Потому как это заказное решение работающее через мой сервер. Хотя если вопрос был бы посложнее, нанял бы админа.
зону ответсвенности разработчика перфоманс базы тоже входит, особенно если у этого разработчика написано что он эксперт по используемой субд и мы берем его как эксперта.
Нуда, а еще ему наверное надо знать конфигурации и особенности СХД, что такое LUN и прочую ересь?
Я не верю, что вашей компетенции хватит чтобы эту проблему решить.
Ваше право. Разубеждать не намерен
Особенно с подходом «у меня не заработало, я нагуглил другую утилитку и переустановил»
Обычно я пишу утилитку и все работает. А тут взять готовое и пилить его напильником? Вы кстати невнимательно читали. В рамках документации были испробованы всевозможные варианты. А решение на php/yii переписано очень прилично. Или вы за тупой труд? В той же утилите на go нужно переписать было вообще все.
И вы, с вашей ленью и умением решать проблемы с помощью СО ей не подходите, вот и все.
То есть вы не ищите незнакомые штуки в гугле? Прикольно. Очень рад за вас. Если у вас смотрят плохо на тех кто ищет по СО, так надо сразу и говорить.
Кстати сам я по со не ищу. Мне очень редко попадаются там решения. Чаще — сходные вопросы, на которые я сам в половине случаев могу ответить.
Просто людям нужен другой уровень. Выше чем ваш в данной конкретной сфере.
Или ниже, потому как им кто-то сказал что корень всех бед — файловый кеш. А то что запросы с кучей функций в условиях без использования функциональных индексов дак этоже фигня…
А если мне нужен человек который будет писать такие утилитки?
Я как раз этим обычно и занимаюсь. Вы опять невнимательно читали. Это была моя попытка «не писать велосипед» и использовать «готовые решения». Но если она работает то лучше ее и взять, ибо время — бабулечки. Так то там конечно ничего сложного, документацию по DBF в зубы и вперед.
Полностью поддерживаю. В конце концов то что вы будете делать на работе скорее всего — это решать задачи, а не писать Фибоначчи с утра до вечера, а потом в тривию играть.
если мы говорим про чистого DBA, а не разработчика которому по долгу приходится писать запросы и левым глазом следить за сервером базы данных, то без глубокого понимания работы кешей, причем как ос, так и самой субд, и внутреннего устройства самой СУБД, вы точно не сможете сказать как решить задачу или исправить серьезную проблему в разумные сроки. И справочники и маны вам тут не помогут ибо не будете знать что именно искать, имхо.
И я говорю про реальные задачи на high load, а не сферические задачи вида — вот запрос без индексов как его можно оптимизировать.
Давно пару раз приходилось сталкивать с установкой и базовой настройкой Oracle, удовольствие еще то надо сказать. Так вот перед успешным запуском инсталятора там надо было выполнить 100500 подготовительных действий. В том числе правка sysctl.conf и если DBA не знает для чего правятся эти параметры, за что они отвечают и как они могут повлиять на производительность СУБД в целом, то грош цена такому DBA.
Если же речь про разработчика, то тут соглашусь, таких тонкостей ему знать не обязательно, хотя базовые представления будут большим плюсом, имхо
то без глубокого понимания работы кешей, причем как ос, так и самой субд, и внутреннего устройства самой СУБД, вы точно не сможете сказать как решить задачу или исправить серьезную проблему в разумные сроки. И справочники и маны вам тут не помогут ибо не будете знать что именно искать, имхо.
Где то эту мантру проповедуют? Слышу ее отовсюду. Что значит не будете знать что искать? Определяем бутылочное горлышко, итеративно.
И я говорю про реальные задачи на high load
Что такое high load. В цифрах пожалуйста. Хотя бы примерно, мы же о вебе говорим.
Давно пару раз приходилось сталкивать с установкой и базовой настройкой Oracle, удовольствие еще то надо сказать. Так вот перед успешным запуском инсталятора там надо было выполнить 100500 подготовительных действий. В том числе правка sysctl.conf и если DBA не знает для чего правятся эти параметры, за что они отвечают и как они могут повлиять на производительность СУБД в целом, то грош цена такому DBA.
У Оракла подробнейшая документация и хорошая ТП. Установка делается один раз и забывается к чертям.
Вам самому не смешно?
Не смешно. Я интересуюсь ораклом время от времени, почитываю доки. И периодами имею беседы оракловые с человеком, который лет 20 с ним работает.
У вас типичный синдром даннинга-крюгера.
В области недооценки своих знаний. Я с этим борюсь всеми силами и это мне стоило очень больших денег в виде упущенной выгоды.
ЗЫ Кстати вы прямо таки наглядная иллюстрация к тому о чем я говорил. Ноль конкретики, никаких задач, запредельная уверенность в своей правоте. Но оскорбить попытались уже раза 3. Дальнейшие беседы с вами считаю пустой тратой времени.
У Оракла подробнейшая документация и хорошая ТП.следуя вашей логики — если есть хорошая документация и ТП, то спец вообще не нужен? Или сойдет любой технарь, который умеет гуглить и читать? Но тогда вопрос — сколько времени будет занимать решение задач у такого спеца. А время как вы знаете — деньги.
Установка делается один раз и забывается к чертям.до первой нештатной ситуации, а она ведь случится
Где то эту мантру проповедуют? Слышу ее отовсюду. Что значит не будете знать что искать? Определяем бутылочное горлышко, итеративно.ок, вы нашли что узкое место дисковая подсистема. Дальше что? Как вы поймете это проблема самих дисков, проблема с кешем дисков или кешем рейд контроллера, или может у рейда отвалился bbu и он перевел режим кеширования c write back на write through или у вас неправильные параметры в sysctl или вы выбрали неудачную фс или размер блока или ...?
следуя вашей логики
Нет, но помнить все нюансы просто незачем.
Дальше что?
У РСУБД? Для начала вопрос почему это вообще так. Не отобрали ли вы слишком много памяти у БД? А может ей памяти на сортировку не хватает? Или разработчики понаписали жутких запросов.
В любом случае лезем в статистику.
Кроме того: где лежит WAL, где лежит журнал фс?
Как вы поймете это проблема самих дисков, проблема с кешем дисков или кешем рейд контроллера
Зависит от СХД
или может у рейда отвалился bbu
мониторинга так понимаю нет?
выбрали неудачную фс или размер блока
прогнать тесты на чтение/запись
Хотя в общем и целом если узкое место для РСУБД — диск. То либо у вас очень серьезные нагрузки на запись, либо схд настроена в дым неправильно, либо чтото происходит совсем неправильное.
Вы так же не ответили на вопрос о highload. Если у вас проблемы с бд на миллиарды записей это одно, если на миллионах то это совсем другое.
Прошу простить за любопытство и смену темы, но где и как Haskell используете? Штука здо́ровская, но куда его можно по-взрослому приложить я так и не понял (так чтобы Haskell имел значительные преимущества в случае использования). Можете немного рассказать?
Я причем не пойму в чем тут дело. Я более 10 лет развлекался с MySQL. В том числе не раз консультировал и оживлял сервера. Я насмотрелся на такие бредовые запросы (например ради выборки в 10 строк перелопачивание 40 млн с файлсорт сортировкой) и вопросы тоже из того же разряда: мы затолкали все денные в одну таблицу без нормализации, выведите теперь вот этот кусочек используя full outer join (которого в Mysql небыло), group by, having. Я вот кстати having использовал в своей жизни 1.5 раза, нечего ему делать в запросах в общем случае, в вебе.
У меня самого на серверах была куча каталогов+рейтинг+форум+чат+сервисы: 1 млн пользователей, 450 млн личных сообщений, до 50 тысяч постов на тему на форуме, несколько тысяч сайтов в рейтинге. И бегало очень все шустро на одном единственном сервере, причем я тогда был молод и не очень опытен.
Но как мы начинаем говорить про PostgreSQL то тут же все как помешанные спрашивают про кортежи, репликацию, кеш, фс и прочее. Хотя в запросах все та же херня. А объемы вроде 50 млн записей вдруг начинают попадать в категорию «высокой нагрузки».
ЗЫ позволю себе заметить, что я никогда даже беседовать не стану на позицию админа. Более того, даже когда звали без опубликованной вакансии разговор всегда начинался с php/nodejs/java + postgresql
Про собеседования
В целом я согласен с изложением ваших мыслей. Хочу добавить пару смешных историй про себя (Senior Mobile Dev 8+ лет опыта только в мобайле).
1) «Нарисуйте воображаемое животное» — Нет ну серьезно? Я думал только шутки про это ходят, однако я просто охренел от вопроса. Или они серьезно думают, что по этой картинке они определят мой психотип?
2) «Не болеете ли вы ЗППП» — До этого мне рассказывали про корпоративы каждые выходные, и что то девченок в команде я не видел.
Собеседование это было 4 года назад, и я запросил 100к на руки, в офере было прописано 55к на испытательный. Нет, я конечно понимаю, что в России принято урезать хотя бы на десятку на испытательный, но не на 45%. Это же вообще бред. В целом я готов за половину ЗП приходить раз в неделю и анекдоты рассказывать но не более того.
— 3) «Кем вы видите себя через три года» — ох Господи как меня бомбит с этого вопроса. Прям хочется взять и карты таро разложить. И самое тупое, что все мы знаем «Правильный» ответ на этот вопрос: «Конечно я вижу себя сеньером в вашей компании, потому что у вас уникальный продукт, а также если мне повезет я и буду трудиться не покладая рук, то я стану менеджером или типа того». Но мой ответ, классически был прекрасен «Я стою на вершине горы, подо мной деревня в огне а на моем лице улыбка».
— П.2
Про резюме
Зачастую, CV крайне важная вещь. Я провожу собеседования в текущую компанию и это первое, от чего можно оттолкнуться. Правильно было подмечено, что не стоит писать что вы знаете технологию, а на самом деле вы ее просто трогали перед сном.
Классика это знание «Git» — мистеры мисиксы которых приходится собеседовать наивно думают, что если они пробовали работать с гитом через какой нибудь редактор, то это делает их экспертами, однако пару вопросов типа «Что делает эта команда git rebase -i HEAD~2» ставит их в тупик.
Пишите то, что вы действительно знаете. Если пишите про «Rx» то вы должны знать о «Subject». Я спрашиваю в основном по резюме, однако в добросок идут базовые знания на алгоритмы и комплексити.
— П.3
Про заграницу
Вот уже как больше года не живу в России. Скажу честно, собеседования в зарубежные компании намного проще, чем в домашние. Почему? Да просто в 80% в России у интервьюверов стоит цель — подкрепить свое ЧСВ или завалить. У них есть только один ответ который они хотят слышать и порой он крайне абстрактен.
«Вот допустим вы нашли решение на StackOverFlow — что вы будите делать дальше?» — Этож просто сфероконь в вакууме.
За границей, в основном конечно, упор идет на технологии и то, как долго вы будите интегрироваться в команду.
Пишите то, что вы действительно знаете.
Ну так и обратное верно.
У меня в резюме написано что знаю Git.
Но на ваш вопрос я бы не ответил. При этом моего знания Гит хватает всем работодателям с кем я работал и у кого было указано знание ГИт в требованиях. Потому что вся работа через GUI и всё что им нужно от знаний Гита — это уметь коммиты пушить.
Если Вы работаете в команде в 2 человека то да, базовых знаний достаточно. Однако, в моем случае это слегка проблематично (40+ на платформу).
И как не крутись, приходится сквошить, черипикать, а еще в гит кэш чистить. Это не критический вопрос, просто будет огромным плюсом знание, что происходит за ширмой UI
Я согласен с вами, что по факту эти пунты не должны присутствовать в моем резюме. Потому что у меня знание минимальное, на уровне «базовое использование каждый день». Проблема в том, что в большинстве случаев требуется именно такое знание. И ничего больше.
У меня возникли ситуации, когда был серьезный конфликт. Ну я пошел к админу, он всё разрулил и я продолжил пользоваться в базовом виде. Я мог бы залезть в маны по гиту. Но учится на рабочем репозитории — это бред. Проще и безопаснее привлечь специалиста.
Что делает эта команда git rebase -i HEAD~2
Работаю с git исключительно с консоли. Но с ходу не точно не скажу что делает, хотя чисто по буквам предположу, что от текущей головы перемещает две последних фиксации.
А все почему? Потому что rebase это один из механизмов git. И многие его вполне обоснованно не применяют и на специфичные вопросы про него не ответят.
-i флаг добавляет interactive mode в rebase. Очень полезно, когда вы хотите сквошнуть коммиты например, а другой ваш коллега сможет сделать cherry-pick.
Хотите спросить про интерактивный ребейз — так спрашиваете прямо что это такое и зачем нужно
Имхо, вполне себе нормальный вопрос на собеседовании. Если человек знает, что такое интерактивный ребейз и как он делается, но не может ответить на вопрос про git rebase -i, то как же он до сего дня ребейзил свои ветки? Более удобного механизма в гит пока что не завезли.
2) «Не болеете ли вы ЗППП»как вариант задавали этот вопрос с учетом того, что заказчик/начальство будет вас иметь, как в прямом так и в переносном смыслах?
P.S.
а такие вопросы вообще уместны по законодательству?
По своему опыту могу сказать, что интервьюрер может быть не уверен в вашей квалификации с таким оффером, это не значит что он хочет вас обмануть и заставить поработать «нахаляву».
Да и само название «Испытательный срок» говорит о возможности безпроблемного расторжения контракта. Если вдруг работодатель понимает, что человек не проходит по скилам — увольнять или пересматривать условия договора
Сейчас такое удивительное время, когда в программирование очень много народу идёт из других областей и они сильно наглее и увереннее чем реально умеющие программировать люди. И платить таким товарищам «как специалистам» — преступление.
У меня в практике было пару человек которые делали достаточно сложные проекты, а на собеседовании мямлили как джуны. И с одним из них, благодаря «полставки» удалось плодотворно поработать (разобрались что он умеет за неделю).
Три месяца это много, за пару недель уже можно понять соответствует или нет.
Много людей приходят именно за деньгами. А писать код и мартышку можно научить, но вот строить архитектурно правильные решения достаточно трудоемкая задача.
Всегда спрашивают как инвертировать строку и какая там сложность у поиска по массиву.
Как будто именно знаение этих мелочей определяет квалификацию специалиста.
А ведь далеко не на джуна собеседовался.
Вот например dependency injection это уже вопрос архитектурного плана или ещё нет
Всегда нет в отрыве от конкретного контекста проекта. Как и любой другой шаблон (вообще шаблон как таковой в общем понимании этого слова) рассматриваемый в теории. Архитектура начнется когда некие известные подходы будут вписываться/адаптироваться/имплементироваться в конкретные реалии.
Но вот как тогда вообще должен выглядеть «вопрос архитектурного плана» на собеседовании?
А кого собственно собеседуем? Джун на позицию программиста это одни вопросы. Архитектор уже совершенно другие.
А сложную архитектуру впихать в рамки быстрого собеседования нет смысла вписывать.
Дальше заголовка редко кто идёт, ибо собеседование поставлено на поток и в ходе интервью разберёмся, что к чему.
Я не могу понять, почему, ведь просмотреть резюме и отсеять неподходящие гораздо быстрее, чем провести целое собеседование по каждому, на которое уйдет минимум час. Разве что создать видимость работы HR-ов.
Я в шоке.
Хотелось бы обратить внимание на интересный кейс. Реклама ломбарда признана ненадлежащей и нарушающей нормы русского языка. Подробности: Компании грозит штраф до полумиллиона за букву «ё», а официальная информация здесь.
Вольный опус про найм, собеседования и трэш на рынке IT-кадров