Регулярно имею дело с собеседованиями: как прохожу, так и провожу их. Расскажу, что с ними не так и как это можно исправить.
Давайте поговорим сегодня на тему технических собеседований в IT. Я хотел бы поделиться своим опытом, рассказать, каким я вижу хорошее собеседование, остановиться на проблемах и ошибках, совершаемых различными компаниями при организации процесса собеседования, и дать набор рекомендаций по улучшению данного процесса. Но сначала давайте знакомиться.
Меня зовут Михаил, я занимаюсь frontend-разработкой, на момент написания статьи работаю в Альфа-Банке. С собеседованиями имею дело регулярно и бываю по разные стороны баррикад: и прохожу собеседования, и провожу их. Проходил собеседования в разных по масштабу компаниях — от стартапов и небольших проектов до больших компаний в индустрии. Случалось также выступать собеседующим в качестве независимого эксперта, помогая товарищам в поиске идеального кандидата. Также регулярно выступаю в роли интервьюера на своем рабочем месте и провел суммарно около 60 собеседований.
Дисклеймеры
Прежде чем перейти к обсуждению проблемы, хочу оговорить некоторые важные моменты во избежание недопонимания:
Без теории. Пишу только о том, с чем сталкивался лично сам, и обязательно подкрепляю тезисы примерами из практики.
Только российский рынок. Что касается собеседований в эталонных иностранных компаниях, то здесь у меня опыт такой: либо собеседование проводили русские сотрудники на русском языке, либо русские сотрудники на английском языке, либо сама компания основана выходцами из России. Так что не считается.
Критикуешь — предлагай. Один из важнейших пунктов этого списка: не ныть, а высказать критику и предложить альтернативу.
Кому будет полезна данная статья:
Интервьюерам она позволит взглянуть на проблему с противоположной стороны и подсмотреть альтернативные практики, которые можно интегрировать в процесс.
Руководители найма увидят новый вектор развития HR-бренда, что будет им чрезвычайно полезно.
Соискатели, я за вас! Отлично понимаю эмоции, которые мы испытывали, и выскажу слова поддержки.
В этой статье не будет:
Обсуждения матрицы скилов для оценки кандидата.
Рекомендаций по организации процесса найма от А до Я, даже в разрезе технической части.
Случай #1 Алгоритмы
Большинство собеседований я проваливаю по одной причине — из-за алгоритмических задач. Моя проблема в том, что нерешенные задачи производят самоусиливающийся эффект: чем чаще я их проваливаю, тем глубже в моем подсознании укореняется мысль, что я никогда не смогу их решить. На данном этапе собеседования начинаю нервничать, и получается швах.
Разумеется, было бы в разы проще, если бы я занялся подготовкой, благо существует масса ресурсов (leetcode, codewars), где можно отточить сей навык. Собственно, я и пытался этим заняться и пришел к следующим выводам:
Трачу много времени на решение. Будучи человеком импульсивным, могу генерировать идеи или решения быстро. Но в отношении алгоритмических задач это не работает. Нужно подумать, порисовать, попробовать, потыкать. Глядишь — и выходной уже прошел.
Через пару дней все вылетает из башки: непрактикуемый навык слабеет. Также считаю навык бесполезным, так как он не применим в моей практике, и сильного желания попасть на работу в FAANG у меня нет.
Многие компании практикуют алгоритмическую секцию в собеседованиях, причем независимо от уровня и масштаба самой компании. Назревает вопрос, откуда появилась такая страсть к алгоритмам на собеседованиях? Думаю, это было как-то так:
В индустрии существует ряд компаний-камертонов, задающих стандарты. Данные стандарты или шаблоны хороши тем, что уменьшают время и когнитивную нагрузку при выполнении операции, а также служат примером, на который можно ориентироваться.
Большие технологические компании, например Google, нанимают на работу высококвалифицированных спецов. Судя по их hr-процессу, кандидат должен уметь вообще все:
computer science,
алгоритмы и структуры данных,
свое направление (frontend, backend, …),
систему задизайнить,
а еще коммуникативные навыки должны быть на пределе.
А что остальные? Создается следующее впечатление: когда речь заходит о формировании процесса найма, то ответственные люди, не желая тратить много времени, копируют схемы других компаний или специалистов. Рассуждают так: ребята знают, что делают, и мы сделаем так же.
Вот в этом суть проблемы: инструмент-то нужно подбирать под конкретную задачу и конкретные условия.
В моей практике, только один провал алгоритмического собеседования не вызвал у меня негативных эмоций. Команда занималась написанием различных парсеров документов для своего продукта — онлайн-учебника. Это явно не моя специальность. Но порадовало то, что ко мне пришел сам собеседующий с честным и объективным фидбеком.
Приведу интересный разговор с моим коллегой по поводу алгоритмических задач на собеседованиях. На своем первом месте работы я спросил коллегу: “Почему на junior позицию постоянно гоняют по алгоритмам, а меня ты не спрашивал? Мы просто беседовали и смотрели мой код. Почему не было задач или чего-то похожего?”
В ответ я услышал, что мол, junior-ов часто гоняют по алгоритмам, потому что собеседующий понятия не имеет, о чем еще говорить с человеком подобного уровня. Свой же подход к собеседованию он описал так: “Мне было важно узнать две вещи: способен ли ты писать код и готов ли ты учиться. Большего и не надо”.
Альтернатива #1 Подмена
В собеседование при поступлении в Альфа-Банк была включена алгоритмическая секция. И что удивительно — я этого не заметил. Мой мозг был легко обманут тем, что мне дали алгоритмическую задачу под видом рабочей, часто встречающейся в практике.
Суть задачи проста: имеется коллекция объектов денежных операций, нужно отсортировать их по датам и составить хеш-таблицу с этими операциями, где даты являются ключами. Просто? Так оно и есть.
Потом я осознал, что на собеседовании абсолютно не нервничал и не боялся провала. Просто в момент решения я переключился в рабочее состояние, будто выполняю рядовую операцию. Данный подход хорош тем, что способен значительно снизить уровень тревоги кандидата. Этот метод я взял на вооружение.
К сожалению, впоследствии, я часто видел задачи на переворачивание матриц, на подсчет лучших ходов на шахматной доске и прочее занудство, вгоняющее меня как в ступор, так и в уныние.
Альтернатива #2 Ну-ка, что ты там написал?
В ходе того же собеседования в Альфа-Банк я увидел еще один интересный тип задач. И уже впоследствии, когда я сам проводил собеседования в Альфу, мне этот тип задач понравился еще больше. Итак, задача — провести код-ревью.
import React from "react";
const ReviewMe = () => {
const [taskText, setTaskText] = React.useState("");
const [tasks, setTasks] = React.useState([]);
const [taskCount, setTaskCount] = React.useState(0);
React.useLayoutEffect(() => {
document.addEventListener("keydown", (event) => {
if (event.keyCode === 13) {
addTask(taskText);
}
});
});
const addTask = React.useCallback((text) => {
const newTask = { id: taskCount, text: text };
setTasks([...tasks, newTask]);
setTaskCount(taskCount + 1);
setTaskText("");
});
return (
<div>
<input
type="text"
value={taskText}
onChange={(e) => setTaskText(e.target.value)}
placeholder="Enter a new task"
/>
<button onClick={() => addTask(taskText)}>Add Task</button>
<div>
{tasks.map((task) => (
<div>{task.text}</div>
))}
</div>
<p>Total Tasks: {taskCount}</p>
</div>
);
};
export default ReviewMe;Мне нравится давать такие задания на интервью по нескольким причинам. Во-первых, кода в подобных задачах — кот наплакал, из-за этого не рассеивается внимание кандидата. Да и вам будет не трудно наклепать таких задач с десяток. Во-вторых, хоть самого кода и мало, но скользких моментов в нем очень много, что позволяет довольно быстро понять, где кандидат буксует и насколько он внимателен. В-третьих, код-ревью — это рутинная задача большинства разработчиков, что позволяет взглянуть на разработчика в условиях, приближенных к боевым. Это тебе не матрицу разворачивать, переворачивать и выворачивать.
Дам совет. Кандидату лучше сразу сказать, чтобы он отнесся к этой задаче как к реальному код-ревью. Он должен высказать все мысли, которыми поделился бы с коллегой.
Таким образом, мы можем:
составить реальный портрет кандидата;
избежать фраз в подведении итогов по задаче типа: “Ой, да я забыл” или ”Да, я хотел сказать, но решил не говорить”.
Рекомендации
Следование моде и бездумное копирование — не самое лучшее решение. Отсеивать кандидата из-за 2–3 нерешенных алгоритмических задач за отведенное время, при том что его основными задачами будут всевозможные перекраски кнопок, на мой взгляд, выглядит не совсем честно.
Не лицемерьте — предоставляйте кандидату реальные задачи или те задачи, которые ему предстоит выполнять в его потенциальной рабочей деятельности. Так будет больше шансов получить объективную картину навыков кандидата, что даст больше фактического материала для оценки его уровня и принятия в отношении его решения.
Случай #2 Тестовые задания
Однажды по ошибке я получил резюме php-разработчика для ознакомления перед собеседованием. Пробежавшись по тексту, я задержал внимание на фразе, которая четко отпечаталась в памяти: “Не присылайте тестовые задания, так как все свои экзамены, лабораторные и курсовые я уже сдал в молодости.”
Концептуально у меня нет претензий к тестовым заданиям — это хороший способ проверить кандидата в деле по следующим причинам:
кандидат имеет больше времени на решение, стресс-фактор минимален;
весь рабочий инструментарий под рукой;
можно посмотреть как кандидат пишет код, выдерживает ли структуру, как документирует код, пишет/не пишет тесты и как их пишет.
Проблема не в самих тестовых задания, в тех, кто эти задания дает и проверяет.
За свою карьеру мне пришлось выполнить около 6 полноценных тестовых заданий, и я столкнулся с однотипными проблемами.
Так что вам надо-то?
Когда собеседовался в JetBrains, моим тестовым заданием было создать react компонент table of content:
К слову, репозиторий с заданием и реализацией.
Задача решаема, но в глаза бросается оформление самого задания. Мне выдали google doc с:
основными заданиями;
дополнительными заданиями;
двумя ссылками: на дизайн документацию и дубль части документации, но в виде pdf.
Дизайн документация и ее pdf-аналог в некоторых моментах противоречили друг другу. Мелочь? Да, но она показывает подход людей к работе. Зачем нужна pdf-ка, если есть спецификация в figma?
В ходе написания статьи я проверил все эти документы: они выглядели по-прежнему. Значит, они не придали значения моим комментариям по этому поводу.
Условия были поставлены следующие: временные рамки на выполнение не ограничены, я волен потратить хоть несколько недель. Я решил сделать только обязательную часть задания, так как не хотел тратить недели своего личного времени на то, по чему даже адекватного фидбека не дадут (я уже имел опыт и сразу почувствовал неладное).
Выполнив задание за 3 дня, послал его и ждал обратной связи около трех недель.
Обратная связь оказалось такой: вы не выполнили даже обязательные задания (но какие — они умолчали) и не справились с дополнительными заданиями, хотя ваше время было не ограничено.
Конец.
Рекомендации
Прежде чем давать кандидату тестовое задание, потратьте время на его грамотное оформление или актуализируйте. Это снизит когнитивную нагрузку на кандидата и уменьшит временные затраты на понимание условий задачи. А вы не будете выглядеть глупо.
Четко оговорите сроки. Нет смысла предоставлять много времени на тестовое задание: уважайте личное время человека. Вряд ли кому-то понравится кодить вечерами ваше задание. Строго говоря, за потраченное на тестовые задания время надо платить.
Предоставьте четкую и объективную обратную связь. Лучше всего — обсуждение выполнения кандидатами тестовых заданий напрямую. Это позволит понять, почему кандидат выбрал данную реализацию и обсудить спорные моменты, причиной которых могло стать: взаимное недопонимание, некорректные формулировки и т.д.
Определитесь. Строго определите список обязательных задач: если задание указано как необязательное, то и не требуйте его непременного выполнения. Делов-то.
Случай #3 Скажи то, что я хочу услышать
Однажды собеседовался в Tele2. В технической его части мне предстояло решить две задачки: одна на переворачивание матрицы (-_-), а вторая — на рефакторинг небольшого приложения. Так как первая задача меня не впечатлила, то рассчитывал разгуляться во второй, ведь это как раз то, что я делаю каждый день.
Задача: есть небольшое todo приложение (не поверите, но тут тоже можно включить фантазию и придумать что-то новенькое), в котором допущены различные ошибки — от верстки до логики. Есть фиксированный список проблем, которые нужно устранить. Начали мы с верстки.
Нужно было привести карточки в порядок (добавить отступы элементам списка) и выровнять контент карточек по горизонтали. Условие одно — нельзя изменять верстку.
Разметка каждой карточки следующая:
<div className="todoCard">
<input type="checkbox" checked={completed} />
<div>{todo}</div>
<div className="removeBtn">x</div>
</div>Мое решение выглядело так: сделать todoCard flex-контейнером и задать removeBtn отступ слева со значение auto. Легко — подумал я. Но интервьюер стал настойчиво задавать вопрос за вопросом, пытаясь выяснить, а какие еще есть способы решения проблемы. Ответ: “Я бы мог все-таки изменить верстку, объединив первые два элемента в блок, и с помощью space-between развести блоки в сторону”, — его не устроил (правила же!). Почесав репу, я признался, что пока ничего в голову не приходит, и интервьюер разочарованно вздохнул.
Позднее я догадался, что можно сделать через grid-ы, но дал комментарий, что это чересчур: так как grid удобнее использовать для создания крупной сетки. Этим комментарием я удивил собеседующего — ему эта идея не казалась странной. Мой social credit продолжал падать.
Далее мы перешли к обработке формы. В своих рабочих проектах я использую библиотеки для работы с формами. В пет-проектах либо сам костылю обработку (через useState), либо беру готовые решения.
Не успел я приступить к написанию кода, как тут же услышал осуждающие комментарии: “А что, без useState не можешь?”, “А там, по-твоему, зря стоит form элемент?”.
К тому моменту я уже привык к формату проведения встречи и понял, что от меня ждут “правильного” решения, которое выглядит так:
...
const AddTodoForm = () => {
const { addTodo } = React.useContext(TodoContext);
const onSubmitHandler = (evt) => {
evt.preventDefault();
const value = evt.target.elements["todo-name"].value;
if (value) {
addTodo(value);
evt.target.reset();
}
};
return (
<div className="addTodoForm">
<form onSubmit={onSubmitHandler}>
<input name="todo-name" type="text" />
<input type="submit" />
</form>
</div>
);
};
...Пришлось воспользоваться логами, так как давно не обрабатывал формы таким образом, но, помня, что такое возможно, реализовал требуемое. Так как реализовал не с наскока и поскольку к тому моменту мой street credibility был уже слишком низок, ребята решили прервать собеседование. Встреча закончилась, но осадочек остался.
Проводя интервью, я стараюсь свести его к диалогу. Мне нравится, когда кандидат рассказывает о собственных решениях и причинах, по которым он сделал именно так. Моя цель — узнать, понимает ли кандидат суть проблемы, ее причины и ограничения выбранного решения. Мне важно услышать ход мыслей кандидата и понять, насколько глубоки его знания. Я не жду от него идеального решения.
К примеру, мне не очень интересно, знает ли кандидат устройство event loop. Когда речь заходит об асинхронности, мы говорим о проблеме, которую асинхронность решает. Спрашиваю, какие еще подходы есть для решения этой проблемы? Какие ограничения у этих подходов? Таким образом копаю вглубь.
Вывод
Искреннее убежден, что в ходе беседы можно многое узнать о человеке. Допрос не требуется. Дайте кандидату объяснить принятые решения, а сами следите за ходом его мыслей и аргументацией. Задавайте вопросы и, если нужно, возражайте. Главное — понять: способен ли кандидат рассуждать и принимать обоснованные решения.
В боевых условиях не всегда рядом окажется коллега с перечнем правильных решений возникшей проблемы. А бизнесу, которому выполненная задача требовалась еще вчера, будет по барабану, как и что вы там нативненько обработали.
Случай #4 Обратная связь
Регулярное прохождение и проведение собеседований могут быть крайне полезными, ведь это возможность для обеих сторон узнать что-то новое.
В ходе интервью, ошибившись, я прошу собеседующего объяснить, в чем была моя ошибка, и рассказать, как следовало сделать и почему. Если собеседование провожу я, то после каждого задания мы с кандидатом разбираем ошибки и недочеты в выполнении задания, или же я высказываю свое мнение по поводу ответа кандидата на теоретический вопрос.
В конце встречи подводятся итоги. Я привык к схеме, практикующейся в банке: есть табличка навыков, которую вы с напарником должны заполнить, оценивая каждый навык по пятибалльной шкале. Также каждый интервьюер пишет обратную связь по кандидату.
Матрица скилов, матрица навыков для собеседования и способы их оценки — отдельные большие темы, выходящие за рамки данной статьи. Там тоже есть свои проблемы, но они другого характера.
Четкого стандарта ОС нет, поэтому каждый пишет, что хочет, но, в основном, это общие впечатление о кандидате, отзыв о его коммуникативных и технических навыках. Подобные комментарии полезны:
командам, в которых открыта вакансия, так как можно понять, насколько им подходит кандидат;
самому кандидату, ведь часть этой информации hr-ы передают как ОС.
Проблема в том, что большинство аспектов собеседования стандартизированы, за исключением самого важного — обратной связи.
Обратная связь важна больше, чем вы думаете, так как она являет собой результат всей вашей работы в направлении найма. Если вы не можете дать четкую и понятную ОС, то по каким критериям тогда вы оценивали кандидата? Если вы понимаете, по какой причине кандидат вам не подходит, то почему бы не структурировать свои выводы и не передать их? Зачем заставлять кандидата гадать, что вам не понравилось? Почему бы не помочь человеку стать лучше? А вы также задумывались над тем, с каким посылом кандидат уйдет от вас?
Последние два вопроса особенно интересны. Не секрет, что IT-компании заботятся о своем hr-бренде и стараются продвигать его всеми силами. Забавно, но за пару дней до написания статьи, я был участником презентации обновленной спецификации по проведению интервью в JS дирекции. По факту, новая версия спецификации была приукрашенной версией предыдущего варианта. Около часа комьюнити собеседующих слушали, как один человек зачитывает эту спеку. В конце прозвучала мысль о важности как данной встречи, так и работ по улучшению процесса проведения интервью, так как одна из целей компании — улучшение и продвижение hr-бренда. К сожалению, до блока обратной связи мы так и не дошли из-за нехватки времени. Жаль, ведь именно этот блок мог бы помочь в продвижении hr-бренда компании.
В случае отказа кандидат всегда испытывает негативные эмоции. Но в ваших силах снизить уровень негатива и направить его в правильное русло. Если предоставить кандидату перечень четких критериев, по которым он не подошел, и список рекомендаций, то это покажет, что:
вам не плевать на него;
конечная оценка была не от балды.
Помните: кандидат может не подойти как вовсе, так и из-за нехватки конкретных навыков. К примеру, вы ищете человека с глубоким пониманием движка, а этот момент отсутствует. И это непременно следует подсветить при обратной связи.
Рекомендации
Протяните руку. Потратьте немного своего времени для написания по возможности развернутой обратной связи по кандидату. Выделите понравившиеся вам моменты, обратите внимание на слабые места и дайте нужные рекомендации. Это охарактеризует вас с лучшей стороны, а сарафанное радио сделает свое дело.
Без воды. Некоторые перечисляют абстрактные рекомендаций в ОС по типу: почитай про архитектуру, настройка CI/CD и прочее, хотя на собеседовании об этом либо речь не шла вовсе, либо кандидат сказал, что этим не занимался. Совет подтянуть все и сразу — абсолютно никчемная рекомендация. Говоря начистоту, в квалификации любого инженера можно найти изъяны, а тем более составить список тем, которые ему следовало бы подтянуть.
Случай #5 Что читаешь?
Крайне редко слышал подобный вопрос на собеседованиях, а жаль, ведь очень важно выяснить у кандидата, какими способами он прокачивает свои профессиональные навыки, помимо выполнения рабочих задач. Благо, таких вариантов масса:
статьи или видео;
курсы;
пет-проекты;
книги;
конференции или митапы.
Данный вопрос чрезвычайно важен, так как показывает уровень мотивации, вовлеченности и стремления к карьерному росту, а также дает представление об психологическом складе человека.
Можно возразить, что и соврать нетрудно. Это справедливое замечание, но в большинстве случаев кандидаты, не занимающиеся самосовершенствованием, отвечают искренне:
“Да я вот научился использовать <НАЗВАНИЕ_ФРЕЙМВОРКА>, и мне большего не надо”;
“Да как-то не интересно все это”;
”Нет, не интересуюсь, а зачем?”;
“Я редко что-то читаю, stack overflow достаточно”.
Понимаю ли я таких людей? Да, так как ситуации бывают разными. Кто-то устал от вечной гонки технологий и решил притормозить, кто-то занялся нашим ремеслом, чтобы заработать денег, а профессиональная сфера ему не слишком интересна. Некоторые и вовсе безамбициозны: выполняют небольшой набор функций, и им этого вполне достаточно.
Это не хорошо и не плохо, потому что разным проектам нужны разные разработчики. Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то — разработчики, готовые брать на себя больше ответственность, драйвить разработку.
В любом случае, полезно обратиться к данной тематике, чтобы понять, что за человек перед вами. Обычно я задаю следующие вопросы:
читаешь статьи?
– на каких площадках?
– какая из статей запомнилась больше всего? Почему? Расскажи о своих мыслях после прочтения.
– писал ли сам статьи? Хотел бы? Какие идеи были?какие конференции или митапы посещаешь?
– можешь рассказать о запомнившихся докладах? Чем запомнились?
– был ли доклад, который помог в практике?
– какие спикеры тебе нравятся больше всего? Почему?
– посещаешь ли конференции других направлений? Каких? Почему? Что нового узнал?
– есть ли идея для собственного доклада?занимаешься ли пет-проектами?
– если да, то какими: учебными или бизнес-проектами?
– какие новые технологии опробовал на таких проектах? Какие плюсы и минусы выделил?
– если бизнес-проект, то чему научился в ходе создания? Что удалось, а что нет?
– сможешь показать?
Задача данных вопросов — копнуть поглубже, чтобы узнать какую программу обучения выстроил для себя кандидат. При этом помните: правильного ответа нет, ибо все люди разные, и вовсе не у всех есть потребность постоянно учиться. Исходите из реалий и требований проекта.
Итак
Статья вышла достаточно большой, поэтому резюмирую кратко, как можно улучшить процесс проведения технического интервью:
Не лицемерьте. Составьте набор заданий, максимально приближенных к будущей реальной работе кандидата. Это позволит вам понять его профессиональный уровень и принять решение, подходит ли он вам.
Интервью — диалог, а не допрос. Спорьте и обсуждайте, чем больше вы выясните, тем лучше.
Обратная связь — лицо компании. Наравне с другими процессами найма стоит создать форму и стандарты ОС. Это выставит вас в более выгодном свете на фоне сотен других работодателей как добросовестных и доброжелательных нанимателей.
Спасибо, что дочитали до конца. Надеюсь, вы смогли подчерпнуть для себя что-то новое.
Делитесь своими впечатлениями о технических собеседованиях. Каким вы видите хорошее техническое собеседование? Какие моменты подмечаете в процессе прохождения интервью? Какой у вас какой опыт прохождения технических интервью?
Буду рад вашим комментариям и с удовольствием отвечу на все вопросы.
Комментарии (228)
Drucocu
28.05.2024 22:31+19Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то — самостоятельные разработчики, готовые брать на себя ответственность и драйвить разработку.
Ну зачем? Почти нетоксичная статья же получилась. Чуток не дотянул.
kbnrjlvfrfrfrf
28.05.2024 22:31+12Ну зачем? Почти нетоксичная статья же получилась. Чуток не дотянул.
Чо все такие нежные? Нормально всё написано.
Drucocu
28.05.2024 22:31+14Отвратительно написано. Автор автоматически превозносит себя над другими только по причине того, что прочитал какую-нибудь "умную книгу" (возможно даже не до конца). Применяет он на практике полученные знания или нет - мы не знаем. На поверку может оказаться, что автор такой же формошлёп, как и большинство, но нашёл повод выпендриться.
При этом, есть ли корреляция между чтением рандомных книжек и теми, кто действительно тянет на себе разработку ("драйвит" - слово неопределённое, ничего не говорит о результатах, только о суете) - ещё надо доказать.
Тем не менее, мне нравятся все советы, которые изложены в статье. Я и сам стараюсь им следовать (особенно о проработке тестовых и задач типа "проведи code-review"), но вот это ложное чувство превосходства собеседующего над собеседуемым - оно просочилось в пассаже про формошлёпов. То, что ты раньше пришёл в компанию N не даёт тебе никакого преимущества над тем, кто пришёл позже. Завтра ты достанешь всех со своей "умной книгой" и уже тебя будет собеседовать тот, кто приходил на интервью к тебе.
Плюс, бесит, если честно, манера считать, что везде "перекладывают json'ы", а вот у нас - настоящее программирование. Автор мог бы сохранить анонимность относительно места работы, и тогда читатель мог бы предположить, что они действительно на работе занимаются чем-то эдаким. Но автор пишет с корпоративного блога) А вот это вот топовое российское IT - он небольшое, на самом деле. Разработчики постоянно переходят между 10 условными компаниями и все прекрасно знают кто, что и как делает.
MadeByFather
28.05.2024 22:31+1Так у автора в описании `frontend dev`, вот он, наверное, про себя и говорит формошлеп json'вый...
mrerberg Автор
28.05.2024 22:31+6Спасибо за отзыв! Попробую ответить на все возражения и моменты по-порядку.
> Чуток не дотянул
> Отвратительно написано.
Интересно поменялась градация оценки)
> автоматически превозносит себя над другими
Ни в коем случае не старался вложить этот смысл в текст. Тем более, не было намерения демонстративно подняться над кем-то.
> ... только по причине того, что прочитал какую-нибудь "умную книгу"
Честно говоря, не читал специализированных книг про интервью. Если вы говорите про книги, связанные с программированием в целом, то тогда не совсем понимаю аргумента, не вижу связи.
> На поверку может оказаться, что автор такой же формошлёп, как и большинство, но нашёл повод выпендриться.
Ну так да, я этого и не скрываю) Есть много подобного рода задач, которые надо выполнять. Программирование - ремесло.
Вообще, в нашей рабочей среде подобные формулировки не воспринимаются обидными. Мы часто подшучиваем так друг над другом или люди сами себя так описывают.
В конкретном примере мне нужно было вкратце описать ситуацию, поэтому я выбрал ярлыки, которые лаконично вписывались.
По названным причинам выше не думал, что это сможет задеть. Надеюсь, донес до вас свою точку зрения.
> Плюс, бесит, если честно, манера считать, что везде "перекладывают json'ы", а вот у нас - настоящее программирование.
Не уверен, что вы нашли это в моем тексте, но все же. Я не писал ничего подобно, уж тем более не имел в виду. Стараюсь реально смотреть на вещи. Большинство задач так или иначе однотипны, похожи. Как и писал ранее, программирование - ремесло. Не все задачи интересные, сложные, заставляют изобрести что-то новое, ознакомиться с какой-то новой технологией.
> Но автор пишет с корпоративного блога)
Вы могли заметить, что изначально статья вышла не под корпоративным хабом. Я выпустил ее специально от своего имени, чтобы избежать комментариев в предвзятости. Лишь позже мне предложили добавить в статью в корпоративный блог. Возможно, удалю привязку к корпоративному блогу, чтобы не было таких мыслей.Drucocu
28.05.2024 22:31+5Интересно поменялась градация оценки)
Мне понравилась статья в целом, поэтому наличие этого абзаца - это именно "чуток". Но сам по себе абзац, если рассмотреть вне текста, весьма неприятен. Вот почему:
Ну так да, я этого и не скрываю) Есть много подобного рода задач, которые надо выполнять. Программирование - ремесло.
Смотрите, как интересно выходит. Вы и сам, с ваших слов, формошлёп, и однотипных задач у вас полно, и с коллегами вы шутите по этому поводу. Но если у вас по результатом собеседования сложилось впечатление, что кандидат - точно такой же формошлёп, то это уже минус:
разным проектам нужны разные разработчики. Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то — самостоятельные разработчики, готовые брать на себя ответственность и драйвить разработку.
Возникает закономерный вопрос: а откуда гонор? Вам человек нужен, чтобы вместе с вами ваши ежедневные задачи решал или запускал ракеты в космос? А вы уверены, что для такого "драйвера" у вас найдётся подходящая работа? Или нужна ли вам вся команда, состоящая исключительно из "драйверов"?
Поймите, я не просто так придираюсь к этим формулировкам. Это признак ещё одного пункта некачественного интервью, о котором вы не написали: несоответствие ежедневных задач и требований к кандидату. В других подобных статьях об этом пишут довольно часто, и это весьма распространённая болезнь людей, которым приходится заниматься подбором персонала. Не берусь утверждать, откуда растут ноги у этой болезни: то ли из-за собственного синдрома самозванца, то ли из-за страха отвечать перед начальством за "недостаточно строгое интервью", не суть. Главное, что это тоже распространённая проблема.
Тем не менее, учитывая общую адекватность выводов, к которым вы уже смогли прийти и которыми с поделились в статье, есть надежда, что и до этого вопроса вы доберётесь.
Rorg
28.05.2024 22:31+2Но если у вас по результатом собеседования сложилось впечатление, что кандидат - точно такой же формошлёп, то это уже минус:
Наверно мы с вами читали разные статьи, но с чего вы взяли, что автор считает что "формошлёп – это уже минус"? А раз 5 перечитал статью и не нашел этого.
Если что я формошлеп и json-перекладыватель большую часть времени. А еще я "вайтишник" (если я правильно вспомнил модное нынче слово). Я "вайтишнулся" лет 15 назад. Мое ВО никак не связано с IT.
Drucocu
28.05.2024 22:31+3В цитате, которую я привёл, явное противопоставление:
разным проектам нужны разные разработчики. Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то —самостоятельные разработчики, готовые брать на себя ответственность и драйвить разработку.
В этом месте читателю явно дают понять, что формошлёпы и перекладыватели json-ов - это не самостоятельные разработчики. А вы что же, как собеседующий, самостоятельных не хотите?
kbnrjlvfrfrfrf
28.05.2024 22:31Медсестра тоже должна обижаться что её не хирургом называют?
Drucocu
28.05.2024 22:31А вы точно хирург? :)
Вообще, вы что-то во все стороны воюете. Не могу проследить в ваших комментариях единую точку зрения.
kbnrjlvfrfrfrf
28.05.2024 22:31Не могу проследить в ваших комментариях единую точку зрения.
Это называется сохранять объективность.
Newbilius
28.05.2024 22:31Ложная аналогия. Тут скорее вместо "медсестры" звучит "перекладывалка бинтов". Тоже кривая аналогия, но ближе к сути)
mrerberg Автор
28.05.2024 22:31...что кандидат - точно такой же формошлёп, то это уже минус
Не считаю это минусом. Как писал ранее, все зависит от требований проекта и команды.
К примеру, если мы говорим про банк, часто отсеиваются кандидаты, которых вполне можно было бы взять. Они бы справились с рабочими задачами. А где не смогли бы, легко бы научились, так как можно пообщаться с коллегами или попросить о помощи ментора. Это я к чему? К тому, что зачастую мнения собеседующих расходятся. Я понимаю, что человек не идеально прошел стандартные задания на интервью, но вижу, что он вполне способен выполнять будущие задачи. Поэтому даю зеленый свет. Напарник же считает, что если не запустил ракету, то уже никуда не полетит. Это я считаю проблемой, о чем, собственно, и написал в тексте.
Не вижу никаких противоречий.Вам человек нужен, чтобы вместе с вами ваши ежедневные задачи решал или запускал ракеты в космос?
Чаще — первое. Что касается драйверов, то обычно их ищут целенаправленно. Под конкретный запрос, например: techlead, мейнейнер uikit, и тд. То есть в вакансии об уровне ответственности и об ожиданиях пишется заранее.
В моем направлении, к слову, приветствуется, когда разработчик начинает брать на себя больше ответственности и становится "драйвером". Подчеркну, это происходит по личной инициативе.Drucocu
28.05.2024 22:31+1Это более подробный комментарий, спасибо.
Как писал ранее, все зависит от требований проекта и команды.
Ну, как я написал в другом комментарии, вы сделали из этого явное противопоставление. У "драйверов" у вас есть положительные стороны: самостоятельные разработчики, готовые брать на себя ответственность. А у "формошлёпов" никаких достоинств нет. Выбор для читателя очевиден. Хотя, по опыту, как раз "формошлёпы" умеют прогнозировать адекватные сроки и выдавать стабильный результат. Ну и с самостоятельностью я бы поспорил. Но не буду накидывать)
Напарник же считает, что если не запустил ракету, то уже никуда не полетит.
Считаю, что нужно уважительно относиться к коллегам, даже если им не довелось сделать что-то эдакое. Илон Маск, конечно, молодец, но ещё большие молодцы его инженеры. Вам не нужна команда, состоящая целиком из Масков. Даже не в каждой команде он нужен, строго говоря.
mrerberg Автор
28.05.2024 22:31+1Ну, как я написал в другом комментарии, вы сделали из этого явное противопоставление.
Уловил суть. Подобная формулировка показалась предвзятой и настроена на предвзятость и выглядит как противоречие. Могу заверить, что это лишь формулировка, целей создать такое впечатление не было. Я посчитал, что "драйвер" звучит слишком абстрактно и решил именно этот термин раскрыть.Считаю, что нужно уважительно относиться к коллегам, даже если им не довелось сделать что-то эдакое.
Поддерживаю. Думал, что раскрою этот тезис больше, но вышло наоборот. Признаю, что формулировка неоднозначная.
ShaltaiBoltai
28.05.2024 22:31+6Вставлю и я свое особо ценное. Российские IT компании собеседуют кандидатов так, как будто они Google и будут платить тому счастливчику, которого они возьмут, $10000 в месяц. Но в действительности так собеседуют на $1000. Потому, что спецов на $3000 и выше по HeadHunter'ам они не ищут. Таких берут по рекомендации от коллег.
В общем, для кандидата собеседование - это чистая лотерея. Нет, конечно, если ты мега-гига крутой спец, то у тебя, подозреваю, уже работа есть и на зарплату ты не жалуешься. А если ты обычный простой прогер, то для тебя собеседование - это лотерея. Если у собеседующего еще осталось желание "копаться и выбирать", то кандидату ничего не светит. Ибо он же не само совершенство, а собеседующий на данном этапе ищет именно, что само. А вот если собеседующий уже продолжительное время ищет и пришел к мысли "А ну его всё к черту, возьму уже следующего, который более-менее понравится", то тогда шанс есть. В общем, главный вывод: от кандидата почти ничего не зависит.
kbnrjlvfrfrfrf
28.05.2024 22:31+2К слову, это ещё одно очень большое заблуждение будто все высококлассные спецы уже работают на крутых работах за 300К/наносек. Да, если по знакомству перетащат на сытное место, это очень хорошо. Но для этого ещё должны быть такие знакомые в таких местах, иметь там политический вес, и готовые словечко замолвить перед высоким начальством. Такое стечение обстоятельств вообще ни разу не что-то такое само собой разумеещеся. Поэтому соверешенно в порядке вещей спецам прозябать на 150К во второсортных конторах, потому что с улицы с неприглядным резюме, с нынешними собесами без специальной подготовки, им вход де-факто закрыт.
Metotron0
28.05.2024 22:31+2Знаете какие-то вакансии, где можно так попрозябать? Я бы не прочь попрозябать за 150. А если ещё и не будут гонять по кишкам фреймворка, а достаточно только уметь им пользоваться и учиться нужному по мере возникновения потребности, то совсем красота.
Ой, коммент про спецов. Не факт, что я спец, я не проходил никакую квалификацию. Тогда отбой.
Drucocu
28.05.2024 22:31+1Прошу прощения, что врываюсь с непрошенным советом: но попроходите собеседований просто. Прям так массивно, чтобы не 2-3, а ближе к 20 (что подразумевает как минимум 50 откликов, а то и больше).
Во-первых, с каждым новым будете увереннее себя чувствовать и сможете интереснее про себя рассказать.
Во-вторых, где-то и повезёт. Как бы не пытались систематизировать опыт собеседований в таких аналитических статьях - это всё ещё лотерея. Иногда в неё выигрывают)
Metotron0
28.05.2024 22:31Если мне на каком-то собеседовании предложат трудоустройство, а я откажусь, то буду чувствовать себя неуютно, это как обман чужих ожиданий. Они думают, что нашли работника, а я просто так у них время отнял. Я понимаю, что где-то я нужен и с нынешними знаниями, я же нашёл нынешнюю работу, но даже не знаю, где искать интересные мне вакансии. Вчера ходил по хабр-карьере, там удалёнка с указанной зарплатой с фронтендом на vue — это пять что ли вакансий. Потом отключил обязательность указания зарплаты, из всего выбрал лишь парочку, которые тематически мне бы подошли, но там есть некоторые требования, которым я не удовлетворяю. Они ещё так пишут, типа "знание vue-router". Ну, я с ним просто работал, а вдруг им нужно умение написать свой движок роутинга или хотя бы помнить на память все параметры? Последние два года я делаю такое легаси, что уже даже не помню, как там сейчас канонично этот роутер подключать к проекту, но точно знаю, что это одна строчка в документации, могу банально посмотреть.
Drucocu
28.05.2024 22:31Если мне на каком-то собеседовании предложат трудоустройство, а я откажусь, то буду чувствовать себя неуютно, это как обман чужих ожиданий.
Вы эту херню бросьте. Когда я последний раз искал работу, я откликнулся на 25 вакансий, прошёл в общей сложности 27 интервью (с учётом предварительных созвонов с HR и прочих этапов) и получил в финале то ли 4, то ли 5 офферов. Очевидно, мне пришлось кому-то отказать - я ж не волчара какой)
Думаете, отвергнутые компании занесли меня в чёрный список? Очень даже наоборот: раз в полгода пишут и спрашивают, не хочу ли передумать в их пользу.
Вы скажете, это потому что я такой офигенный? Вовсе нет. Меня вон выше IT-медсестрой обозвали) Просто это норма, так сейчас всё устроено. Вы тоже в компании будете не единственный кандидат. Откажетесь вы - позовут следующего по списку. Вот пример со стороны нанимателя под этой же статьёй.
Последние два года я делаю такое легаси
А у нас же везде такой качественный код, что обосраться можно, ага) Говорите честно, что делали. Вспомните два-три примера задач, решением которых особенно гордитесь, и вперёд.
Metotron0
28.05.2024 22:31Я понимаю, что так устроено, но воспитание так просто не изменить. Мне внутреннее тяжело обманывать. Или мне с самого начала сказать, что я пришёл не на работу устраиваться, а просто так? Они ведь будут отвлекаться от своей работы, чтобы провести собеседование.
Вопрос, чем я горжусь, и что могу показать из прошлых работ, меня всегда ставит в тупик :( Я половины вообще не помню, а то, что помню, потому что делал это долго, обычно находится за паролем, потому что это какие-то внутренние сервисы. Да и они из-за долгой разработки перестали быть тем, чем я горжусь. Во многих случаях я даже не знаю, под каким адресом работает сайт, который я делаю, потому что моё взаимодействие заканчивается на тестовом сервере. А ещё многое из того, что я делал, уже переделано почти полностью, да и я сам там делал не всё с нуля, а что-то дорабатывал. Типа, один раздел в админке или часть корзины, но её потом ещё допиливали, в итоге там код пяти человек.
Раз был случай, несколько месяцев делали для автоваза сайт, я там писал подбор комплектации машин, где можно было галочками отметить желаемый двигатель, коробку передач, подогрев руля, всё такое, а он на каждом шаге отключал галочки, которые не сочетаются с выбранными, чтобы выйти на что-то финальное. В итоге завернули и сказали, чтобы все галочки были всегда доступны, показывало бы самую близкую комплектацию из имеющихся, а там уж менеджер по телефону уболтает. По итогу сайт так и не запустили. Несколько месяцев работы! Мы тогда ещё после украинских фрилансеров его доделывали, там были какие-то подрядчики на подрядчиках, у них ещё в 2014 стали в обед свет отключать, в итоге разработка попала к нам. В качестве байки наверное могу такое поведать, но код там был страшноват. Если бы я владел какими-то паттернами, то мог бы сделать лучше. Но я и сейчас книгу по ним не прочитал — сил нет на учебники, хочется просто поспать уже неделю по 10-12 часов.
Ещё я на jQuery месяц делал то, что сейчас на vue сделал бы неспешно за неделю. Переизобретал SPA на глобальных переменных. Аж в дрожь бросает. И ведь до открытия мной Vue оставалось полгода что ли.
Вообще говоря, человек, ковыряющийся в легаси, тоже обладает спросом. Но я бы не сказал, что мне это прямо нравится. Я бы сейчас на полгода бросил работу, если бы были какие-то накопления.
Kanut
28.05.2024 22:31+1Или мне с самого начала сказать, что я пришёл не на работу устраиваться, а просто так?
Вам просто так сказать что вы ищите новую работу, но пойдёте к ним только если всё устроит и не будет вариантов получше.
Более того это даже говорить не нужно. Адекватные работодатели это сами понимают.
обычно находится за паролем, потому что это какие-то внутренние сервисы.
И? Вас же не просят секреты фирмы выбалтывать. У меня тоже большинство проектов под NDA. Но я могу сказать что занимаюсь автоматизацией производственных линий. И что например наиболее интересные проекты были проекты с интеграцией чужих промышленных роботов.
И вы не должны ничего работающего показывать. Спрашивают не для этого, а скорее чтобы понять что вам интересно.
Раз был случай... Ещё я на jQuery месяц делал...
Ну вот это прямо вот так и расскажите.
Metotron0
28.05.2024 22:31Опять проблема: мне не то чтобы прямо интересно :) Интересно было, пока я не начал работать в этом всём. Через месяц пропали хобби, связанные с разработкой, потому что работы хватает по горло. Что дают, то и делаю, если могу.
ShaltaiBoltai
28.05.2024 22:31Вы прямо с языка сняли. У меня точно такой же вопрос немедленно возник после прочтения предыдущего коммента.
Но вообще, если спец настолько крут, то он полгодика попрозябает-попрозябает, да и найдет себе местечко за 400к вечнодеревянных. Ведь таких как он не так уж и много, и потому конкуренция сильно меньше. Не сравнить с теми, кто не может Linux kernel с нуля написать или полностью разработать концепт распределенной системы биллинга и реализовать его за месяц.
kbnrjlvfrfrfrf
28.05.2024 22:31Знаете какие-то вакансии, где можно так попрозябать? Я бы не прочь попрозябать за 150.
Так идите в ГУП например. Но учтите что обратно выбраться с такой чёрной меткой будет сложно. Будь у вас хоть семь пядей во лбу, это значения не имеет. При поиске новой работы оценивают вас по статусным конторам в вашем резюме, а не по уму. И плевать что в этом ГУПе вы абсолютно всё на себе вывозили в одну харю, а кто-то в Сбере впятером одну кнопку влево на 5 пикселей двигал.
AndrewKainov
28.05.2024 22:31Да вам прям не остановится)) И правда, зачем статьи писать, когда их можно в комментах наваливать.
Inojj
28.05.2024 22:31+16Дошел до мысли, что бигтехи очень коряво зовут к себе. Вот недавно писали с нескольких крупных компаний, показывают вакансии, ну +- по задачам одно и тоже. Хочется как то подробнее узнать о людях на проектах, что реально хотят и все такое, но нет, ты должен пройти 3+ собеса к каждому из них. И так лень время на это тратить, абсолютно никак не продают работу у них.
А собеседования у многих реально мрак. Единичные истории когда не душат на них как на экзамене
Dolios
28.05.2024 22:31+17А собеседования у многих реально мрак. Единичные истории когда не душат на них как на экзамене
Я преподом в вузе работал довольно много лет. Некоторые студенты тоже считали, что я душил их на экзамене, а я их изо всех сил за уши тянул, чтобы они сдали. Мне меньше всего хотелось тратить своё время на их пересдачи..
Конечно, есть самовлюбленные мудаки, которым нравится самоутверждаться за счет других. Но большинство собеседующих, действительно, искренне хотят найти себе коллегу в команду и закрыть вакансию. И хотят они это сделать как можно быстрее, потому что пока они собеседуют, задачи стоят. Нет никакого смысла тратить время на кандидата, изначально, желая ему отказать, это идиотизм.
Просто кандидат не всегда может понять, что именно хочет проверить и узнать собеседующий. В статье есть пример, когда дали тестовое с противоречивыми вводными. Автор посчитал, что это небрежность. Тем временем, в компании может быть
бардакустоявшаяся практика при постановке задач, ожидается, что исполнитель прежде чем начать что-то делать, все уточнит и напишет "спек", чтобы не переделывать потом. Ищут именно такого человека, который так привык работать. И именно это автор не стал делать, чем и завалил тестовое. Я не хочу сейчас давать тут оценок, плохо это или хорошо, правильно или нет. Я пытаюсь указать на то, что кажущийся идиотизм на сабеседовании, на самом деле, может быть четко спланированной тактикой проверки навыков, необходимых компании. Но вы не понимаете, что именно проверяют и вам всё происходящее кажется глупостью.kbnrjlvfrfrfrf
28.05.2024 22:31+5Ищут именно такого человека, который так привык работать.
А если не привык, в чём проблема адаптироваться? Может лучше сразу честно сказать "у нас бардак", чтобы кандидат сам решил нужно ли ему это?
Dolios
28.05.2024 22:31+3Кому лучше, кандидату? На кандидата компании наплевать на данном этапе. Для синьора не проблема "адаптироваться" и освоить любой фреймворк, но куча компаний требуют в вакансии опыт работы с конкретным каким-нибудь и кандидатов без такого опыта не рассматривают, даже если кандидат думает, что ему это нужно. Вас это не смущает?
piton_nsk
28.05.2024 22:31+2На кандидата компании наплевать на данном этапе.
большинство собеседующих, действительно, искренне хотят найти себе коллегу в команду и закрыть вакансию. И хотят они это сделать как можно быстрее
Так наплевать или хотят быстрее закрыть вакансию? Одно противоречит другому.
пока они собеседуют, задачи стоят
Пусть себе стоят. Собеседование это такая же часть работы как и непосредственное решение задач. К чему это противопоставление? Или тут бардак, когда люди завалены потоком задач когда все надо сделать вчера. Собеседование при этом не часть рабочего процесса, а что-то отвлекающее от основной работы, с чем надо побыстрее разделаться.
Dolios
28.05.2024 22:31Так наплевать или хотят быстрее закрыть вакансию? Одно противоречит другому.
Одно другому не мешает, никакого противоречия нет. К тому же, про бардак вы сами что-то придумали и заранее обиделись.
Пусть себе стоят.
Кто будет оплачивать этот банкет?
Собеседование это такая же часть работы как и непосредственное решение задач.
У разных работ есть разные приоритеты.
Или тут бардак, когда люди завалены потоком задач когда все надо сделать вчера.
Я понял. Когда у программиста есть задачи и сроки, это бардак. Не бардак, это когда он пьёт смузи, а ему платят 100500 денег в секунду, чтобы когда-нибудь он снизошел до решения возложенных на него задач. Всего хорошего, вы нам не подходите.
piton_nsk
28.05.2024 22:31+1когда он пьёт смузи, а ему платят 100500 денег в секунду, чтобы когда-нибудь он снизошел до решения возложенных на него задач.
Тут только вас можно процитировать в ответ
вы сами что-то придумали и заранее обиделись
asdfddsa
28.05.2024 22:31+21Может лучше сразу честно сказать "у нас бардак"
Тогда окажется, что собеседующий глупее собеседуемого, а так быть не должно. ))))
На самом деле, в ИТ сформировался некий КУЛЬТ, где вы должны бесконечно зубрить и самообучаться, а потом какой-то "гуру" на собесе проведет вам экзамен, на тему, которую рандомно выберет он сам. Вы должны со щенячьим взглядом ждать фидбек, не воспринимать отказ в работе как обвинение в профнепригодности, а радоваться прохождению 3 уровней и готовиться к новым собесам. Ради обычной рутинной работы, где вас попытаются прогнуть на зарплату ниже рынка, обнулив весь ваш предыдущий опыт.
Такого идиотизма я не вижу ни в одной профессии. Никто и нигде не ходит по сотням собеседований, чтобы порешать задачки, не ждет идиотских фидбеков, словно манну небесную от богов, и не внушает коллегам нормальность подобного. Теперь ко всему этому цирку прибавилось "вы привыкли работать не так". Уже не знают, чего еще придумать, чтобы потешить свое ЧСВ и отказать в работе.
NCNecros
28.05.2024 22:31+7Аналогичные мысли пришли в голову. Нужно решать модные задачки, читать книжки, ходить на митапы, по ночам спать в наушниках со стримами систем дизайну и т.д. Стало очень сильно напоминать культ достигаторства и продуктивности ради достигаторства и продуктивности. А все остальные - перекладыватели json и формошлепы, кто не литкодит по 12 часов в день.
kbnrjlvfrfrfrf
28.05.2024 22:31+3Это всё повесточка от молодёжи. Ни семьи, ни детей. Ни пожилых недееспособных родителей пока ещё тоже. Порой даже увлечений никаких за пределами айти не имеют. А само айти чисто за счёт эффекта новизны пока ещё весело заходит. Хрен бы с ними, ровно до момента пока они не задают типа стандарты что вот они и есть типа труъ программисты. А кто в свободное время не "саморазвивается", тот типа профнепригоден.
sergeyns
28.05.2024 22:31+11Автор посчитал, что это небрежность. Тем временем, в компании может быть
бардакустоявшаяся практика при постановке задач, ожидается, что исполнитель прежде чем начать что-то делать, все уточнит и напишет "спек", чтобы не переделывать потомопыт говорит, что чаще это просто бардак, а не хитроумные практики
kbnrjlvfrfrfrf
28.05.2024 22:31+3опыт говорит, что чаще это просто бардак, а не хитроумные практики
Более того, всю ответственность пытаются свалить на исполнителя. Мол сам виноват что не уточнил и не переуточнил.
northrop
28.05.2024 22:31Поэтому communication skills - превыше всего, по крайне мере в западных конторах
kbnrjlvfrfrfrf
28.05.2024 22:31+4Чего только манагеры и аналитики не придумают чтобы ничего не делать и снять с себя ответственность. Если задание выполнено в чётком соответствии с ТЗ - значит оно выполнено. Если оказывается что ТЗ имеет двойное толкование - это проблема исключительно тех кто это ТЗ писал.
Dolios
28.05.2024 22:31+1это проблема исключительно тех кто это ТЗ писал
А кто должен писать ТЗ?
kbnrjlvfrfrfrf
28.05.2024 22:31А кто должен писать ТЗ?
Тот кто получает за это зарплату.
Dolios
28.05.2024 22:31+2Так именно этого человекка и планируется нанять в примере выше. Он называется синьор. Именно он берет нечетко сформулированную задачу бизнеса, прорабатывает её, разбирается, что там на самом деле нужно, думает об архитектуре и реализации и формирует то самое ТЗ. В этом ключевое его отличие от мидла, для которого кто-то другой ТЗ пишет.
Тут у нас как раз то, о чем я говорил, прямо отличная иллюстрация получилась. У вас не хватает квалификации, чтобы осознать требования компании, но вы уже имеете своё мнение и высказываете его в довольно резкой форме. Именно для этого и даётся такое тестовое, чтобы отсеять вас на первом этапе и не тратить на вас дорогое время интервьювера. Вы пока не подходите.
kbnrjlvfrfrfrf
28.05.2024 22:31+4Он называется синьор. Именно он берет нечетко сформулированную задачу бизнеса, прорабатывает её, разбирается, что там на самом деле нужно,
Он называется аналитик. Либо продукт-оунер. Я вот поэтому сразу и попросил вас чтобы вы прямо сказали что у вас бардак и перекладывание ответственности. Мне с такими не по пути.
Dolios
28.05.2024 22:31+2Да, синьор, это тот, кто разжевааное просто кодирует, просто он больше всех фреймворков выучил, всё так. Я сразу сказал, что у вас слишком низкая квалификация, чтобы участвовать в этой дискуссии. Приходите через пару лет, поговорим.
kbnrjlvfrfrfrf
28.05.2024 22:31просто кодирует
В том-то и дело что на уровне серьёзных проектов нельзя вот так взять и "просто кодировать". Сеньйор и есть тот человек который отвечает за программную логику проекта, а не за бизнес-логику. Продумывает как запилить фичу так чтобы и фича работала, и всё остальное не отвалилось. Скажем мидл не сможет этого сделать просто потому что не знает всей полноты проекта.
Могу только пожелать дальше искать лоха на которого можно будет всё спихнуть за 3 копейки.
Kanut
28.05.2024 22:31+1Сеньйор и есть тот человек который отвечает за программную логику проекта
Тогда в мире нужно было бы условно говоря два с половиной сениора.
А вообще то, что вы описываете обычно делают архитекты и/или техлиды.
2medic
28.05.2024 22:31+2Ой, у меня ещё круче было. Я, разработчик ПО, был виноват в том, что НЕ ДОГАДАЛСЯ предупредить контрагентов о том, что у банка, в котором открыт счёт предприятия, отзывают лицензию. Хотя за обедом краем уха слышал об этом. Я, оказывается, по собственной инициативе, должен был написать предупреждение, которое должен был опять же сочинить сам, и разместить на сайте, на который вряд ли кто-то ходит и что-то читает. Банки с отозванными лицензиями принимают все входящие платежи, но пользоваться счетами не дают. Поэтому контрагенты деньги перевели туда, куда в договорах прописано. А предприятие не могло ими пользоваться. Ну вот я и был стрелочником.
Ivan22
28.05.2024 22:31запилил бы функционал чтобы все входящие платежи в банк с отозванной лицензией отклонялись (за минусом небольшой комиссии на твой счет). Вин-вин
Kahelman
28.05.2024 22:31Не ищите умысла в том что можно объяснить разгильдяйством. :)
Хотя с комментарием согласен
Inojj
28.05.2024 22:31+3На одном из последних собеседований речь зашла про снифферы, и один из собеседующих спросил: "Что там за значение в одной из колонок". Не сказать, чтоб я так сильно запоминал меню того сниффера, при необходимости уже на опыте понимал куда примерно нужно смотреть. Мне такой вопрос не сильно понравился, и спросил, как часто они такой информацией пользуются, "ну и пару раз за 10+ лет" ответили мне. Ну это же душнилово)) Как потом оказалось, хотели услышать про протокол).
На экзамене, право экзаменатора спрашивать сколько он считает нужным, как мне кажется. Но я же к ребятам прихожу не экзамен сдавать. При таком раскладе и коллег надо будущих экзаменировать. Я так по неопытности пришел на новое место, а там такой мрак был в проекте, совсем не совпадало с вопросами на собеседованиях)
Maarek999
28.05.2024 22:31+2Деньги под программистов выделяет бизнес под определённые цели. Быстрее продукт выпустить, сделать больше фич, уменьшить количество багов, сократить время инцидентов
Большинство собеседующих не понимают что спрашивать и кого они ищут. Чтобы понимать - должна быть выстроенная матрица. Должна быть потребность в ресурсах разработки, а после этого должен быть выделен пул задач и требования к кандидату. И у большинства технических специалистов здесь полный швах. Собеседования в it проводить просто не умеют - те "бест практис", что есть на ютубе, просто слизаны с фаанг
Когда собеседуют тимлида, наверное не стоит спрашивать теорию для Джуна - во-первых, задачи там уже гораздо более верхнеуровневые, чем написание кода, во-вторых - деньги под найм не выделяют для найма теоретиков, у человека есть прикладной опыт и надо понять что он делал.
Заметил, что как раз преподавательский подход и тащат на собесы, устраивая экзамен, вместо того, чтобы понять - комфортно ли вам вместе работать и потянет ли тот пул задач.
SpiderEkb
28.05.2024 22:31+2А почему вы думаете что
Большинство собеседующих не понимают что спрашивать и кого они ищут. Чтобы понимать - должна быть выстроенная матрица. Должна быть потребность в ресурсах разработки, а после этого должен быть выделен пул задач и требования к кандидату. И у большинства технических специалистов здесь полный швах.
У нас есть поток задач от бизнеса и есть ресурсы разработчиков. Если мы видим, что ресурсов не хватает, мы пытаемся выбить их расширение. Если это удается, ищем разработчика. И мы прекрасно понимаем какими задачами его загрузим и чего от него ждем. Более того, мы это понимаем куда лучше других - HR'ов и прочих.
kbnrjlvfrfrfrf
28.05.2024 22:31+5Если это удается, ищем разработчика.
Вроде последний раз вы нанимали 3 (трёх) разработчиков в позапрошлом году. Больше найма нет. Может вы и хорошие, но никакой погоды на рынке вы не делаете.
helmm
28.05.2024 22:31Я как-то спросил у собеседующего для чего он задаёт все эти вопросы, он ответил "ну, все обычно задают, вот и я тоже. Best practice."
В другом интервью был ответ "я хочу понять как вы думаете", нейросайнтист попался видимо)
В третьем, "а что вы поспрашивали бы".
Т.е. так и есть, собеседующие зачастую вообще не понимают чем они занимаются.
khajiit
28.05.2024 22:31Все правильно, только вот если в компании бардак начинается уже на постановке ТЗ, то этот идиотизм — не кажущийся.
И хорошо, что он вылезает на собесе.
Drucocu
28.05.2024 22:31+1Просто кандидат не всегда может понять, что именно хочет проверить и узнать собеседующий.
Извините, но вы описываете какую-то битву экстрасенсов, а не собеседование. У всех разный контекст, у всех разные подходы к решению задач. Вы проверяете только то, что человек пришёл из среды, максимально похожей на вашу, и привык работать в контексте, похожем на ваш.
Я тоже постараюсь не давать вам оценок, но обычно считается, что погружение в контекст - это процесс, который естественным образом происходит в течении испытательного срока. Следовательно, на собеседовании имеет смысл проверять более абстрактные навыки.
Dolios
28.05.2024 22:31+2Вы проверяете только то
Я пропустил момент, когда в треде начали обсуждать меня. Я про себя еще ни слова не написал (за исключением рассказа про преподавание).
Следовательно, на собеседовании имеет смысл проверять более абстрактные навыки.
Для кого? Для работодатели имеет смысл проверять те навыки, за которые он собирается платить.
Я тоже постараюсь не давать вам оценок
Спасибо. Я тоже не буду слать вас по матери за переход на личности.
Drucocu
28.05.2024 22:31А вы, будучи преподавателем, хорошо научились воспринимать критику. Профессионально, не агрессивно, с достоинством. Курсы не ведёте?
А если серьёзно, вы когда комментарий начали с того, что занимались преподаванием, а потом продолжили рассуждать про собеседования - естественным образом создалось впечатление, что вы сейчас так собеседования и проводите. Следовательно я к вам, как к собеседующему, и обращаюсь.
Rorg
28.05.2024 22:31+1будучи преподавателем, хорошо научились воспринимать критику
А как работа преподавателем соотноситься с умением воспринимать критику?
Drucocu
28.05.2024 22:31В моём представлении среднестатистический преподаватель сталкивается с огромным количеством провокаций и словесных выпадов в свой адрес. В каждой группе есть какой-нибудь уникум, который вместо обучения играет в игру "кто тут самый умный/смешной/говорливый". Со временем должен формироваться иммунитет.
Dolios
28.05.2024 22:31Не увидел в вашем сообщении критики. Увидел демагогию, провокации и переход на личности. Второй раз, кстати.
создалось впечатление
Так всегда бывает, когда не читаешь то, что написано.
Drucocu
28.05.2024 22:31Увидел демагогию, провокации и переход на личности.
И как меня земля только носит.
Так всегда бывает, когда не читаешь то, что написано.
Да что-то у вас все кругом должны угадывать, что творится в вашей голове: что соискатель на собеседовании, что читающие ваш комментарий на хабре. Кажется, проблема таки не во мне.
Dolios
28.05.2024 22:31Вы можете продолжать усираться и брызгать слюной, пытаясь меня хоть как-то задеть, реальность от этого не прменяется, реальности пофиг.
Да что-то у вас все кругом должны угадывать, что творится в вашей голове
И опять вы выдумываете ерунду пытаясь оправдать саою неспособность прочитать и осознать несколько предложений...
Вы долго еще за мной бежать будете, доказывая, как я вам безразличен?
Drucocu
28.05.2024 22:31реальность от этого не прменяется, реальности пофиг
Реальность вообще штука весьма инертная. Такая деятельность, как комменты на Хабре в принципе оказывают на неё мало влияния: что мои, что ваши. В этом смысле мы с вами равны, как ни в одном другом.
Вы долго еще за мной бежать будете, доказывая, как я вам безразличен?
Вы и сами можете перестать "усираться", и закончить диалог)
Dolios
28.05.2024 22:31Хорошо, напишите еще что-нибудь в ответ, для таких как вы, это важно, а я откланяюсь.
2medic
28.05.2024 22:31+3Тем временем, в компании может быть
бардакустоявшаяся практика при постановке задач, ожидается, что исполнитель прежде чем начать что-то делать, все уточнит и напишет "спек", чтобы не переделывать потом.Ну т.е. соискатель должен угадывать, что же от него хотят?
Dolios
28.05.2024 22:31+2Нет, зачем. Когда я прихожу на рынок, яблокам не нужно угадывать, что я хочу, я просто выберу те, что нужны мне. Работодатель выбирает кандидатов, которые подходят ему, соискатель выбирает компании, которые подходят ему. Каждый из них руководствуется каким-то своими соображениями. Если эти множества пересекутся, возникнет контракт.
2medic
28.05.2024 22:31+2Не знаю как насчёт яблок, но вот помню басню о том, как лисица виноград выбирала. Не смотря на то, что виноград был в общем-то вполне себе хорош, лисица его всё-таки забраковала.
killyself
28.05.2024 22:31Как опытный студент, скажу, что студенты попались глупые и ленивые. Разумист всегда отличит препода, который ждет невероятных знаний и сам шага к студенту не сделает, от преподавателя которому важнее, чтобы студент хоть как-то переварил и записал в пзу знания по дисциплине (хотя бы и те что ему же на экзамене сам и рассказал), такие еще обычно тройки не ставят.
dae-fromru
28.05.2024 22:31+7Собеседования в западных биг[техах] это самая сложная часть работы (если приняли). Ежедневная работа в разы проще.
northrop
28.05.2024 22:31+1Дошел до мысли, что бигтехи очень коряво зовут к себе
Сила бренда и "вас много , а я одна" во всей красе - другого тут вряд ли стоит ожидать. Рынок-с и вал желающих попасть к ним ...
Inojj
28.05.2024 22:31+3вспоминается старая строчка: "лайков 100, а секса 0". Все к ним ломятся, а позиции не закрываются, за рефки успешные готовы платить по 300к (про больше не слышал). Но проблем в найме у них конечно нет)
Dolios
28.05.2024 22:31+3Дизайн документация и ее pdf аналог в некоторых моментах противоречили друг другу. Мелочь? Да, но она показывает подход людей к работе. Зачем нужна pdf-ка, если есть спецификация в figma?
Это могло быть сделало специально. От вас могли ждать, что вы начнете уточнять задачу.
Можно возразить, что и соврать не трудно.
Так можно и впросак попасть. Если каниддат скажет, что он читает/читал книгу, которую чилал я, я могу задать пару вопросов по существу. Что больше всего понравилось? Согласен ли ты с автором по вопросу Х? И т.д.
kalombo
28.05.2024 22:31+11Это могло быть сделало специально. От вас могли ждать, что вы начнете уточнять задачу.
Могло быть, но автором это было интерпретировано как небрежность. В этом проблема таких mind games. Кандидаты тоже выбирают компании, как ни странно. Готовы тратить время и терять кандидатов - ок, продолжайте игры разума.
Dolios
28.05.2024 22:31Если всё так и было, кандидат и компания сэкономили друг другу время. Нет тут никакой проблемы, ситуация win-win.
panzerfaust
28.05.2024 22:31+18Назревает вопрос, откуда появилась такая страсть к алгоритмам на собеседованиях?
Ответ очевиден. В ситуации фаангов, если у вас за забором тысячи кандидатов, то у вас нет ресурсов беседовать с каждым по душам. Особенно если каждый второй там по-английски кое-как шпрехает. Только бездушный конвейер, только хардкор. Ну а в наших широтах как всегда устроили карго-культ. Не поняли мотивации, но пафос и низкие трудозатраты пришлись по душе.
Но мне кажется, недолго этой музыке играть. Техногигатны сами выпустили нейро-джинна, который вращает деревья заведомо лучше, чем все кожаные вместе взятые. Я прям уверен, что на просторах Индии и Юго-Восточной Азии уже тьма хитрожопых, которые без проблем гарантированно проходят удаленную алгоритмическую секцию любой сложности с помощью ИИ.
Скоро фаанги столкнутся с выбором. Или отказываться от удаленки вообще и заставлять кандидатов прогать на бумажке при очном присутствии. Или жрать продукт ИИ-революции и принимать в штат всех хитрожопых, а потом увольнять после испыталки. Или искать способы оценить человека именно как человека, а не вращателя деревьев.
andmerk93
28.05.2024 22:31+3Или сторонняя сертификация, как в других инженерных отраслях
StjarnornasFred
28.05.2024 22:31+1Всё верно. Формализация трудоустройства и соблюдение трудового законодательства: если соискатель удовлетворяет требованиям вакансии, то его обязаны нанять. Если его нанять не готовы, то вакансия в публичном доступе висеть не должна.
panzerfaust
28.05.2024 22:31+6как в других инженерных отраслях
В какой именно инженерной отрасли сертификация заменила собес? У меня есть знакомые из АСУ ТП, энергетики и производства аппаратуры КИПиА. Везде есть собесы даже несмотря на наличие корочек. Никто не хочет себе в штат хитрожопа, который обмазался сертификатами, оставаясь при этом плохим практиком.
Или вы транслируете голубую мечту тех, что в 2005 году получил сертификат Оркла по Java и теперь хочет, чтобы его везде брали на java senior просто так?
northrop
28.05.2024 22:31+1В медицине, насколько знаю, практически именно так и обстоит - корка и формальное резюме без вопросов о практике
event1
28.05.2024 22:31что в 2005 году получил сертификат Оркла по Java
<режим душнилы>В 2005-м сертификаты по Java выдавал Sun, а не Oracle </режим душнилы>
andmerk93
28.05.2024 22:31Не заменила, а дополнила
Заменила не собес, а тестовые задания, и 33-уровневый цирк с конями и найм по вайбу и софт-скиллам.
ManGegenMann
28.05.2024 22:31Я слышал есть такая штука диплом об образование. Говорят отличный вариант.
Люди готовы тратить 10 лет жизни на подтверждение стажа для рабочей визы и пару лет на самообразование, но не могут потратить 4 года с 16-18 до 20-22 лет на получение диплома.
SpiderEkb
28.05.2024 22:31+5Говорят. Вот только у меня, например, в дипломе (от 1988 года) написано "Техническая физика". При том, что разработкой профессионально занимаюсь с 1991-го. А программистов в те времена готовили только на матмехе универа (и подготовка там была достаточно специфической). И никаких мобильных, никакого web тогда не было. Писали на фортране, кто-то на коболе, кто-то на С. И, в основном, под большие машины типа ЕС-1033 или БЭСМ-6 (персоналки в те годы у нас только появлялись).
И что толку с того диплома в плане квалификации разработчика?
StjarnornasFred
28.05.2024 22:31Если в дипломе написан гипоним к слову специальность, а не специалист, то он мало что говорит о его обладателе. Не то чтобы это было правилом, но наблюдения подтверждают это. Чем общéе специальность в дипломе - тем меньше.
Например, если в документе написано "обслуживание механизмов", "информационные технологии", "кулинария" - то это всё ни о чём. То есть это говорит, что человек отучился, что-то знает по теме (возможно, даже хорошо знает), но ничего не говорит о том, что он умеет и кем может работать.
Если же в документе написано "механик", "программист", "повар" - это уже лучше. Это означает, что данный человек может быть конкретным специалистом согласно диплому. И лучше быть да хоть поваром, чем "специалистом в области кулинарии".
Kanut
28.05.2024 22:31+6Извините, но это полнейшая ерунда. По крайней мере по моему опыту нет вообще никакой корреляции между названиями/формулировками в дипломе и умениями людей.
SpiderEkb
28.05.2024 22:31+1Если в дипломе написан гипоним к слову специальность, а не специалист, то он мало что говорит о его обладателе
В моем случае это сделано намеренно. У нас у всего факультета (как и у других факультетов аналогичного профиля) пишется именно так. Ну на вкладыше в диплом чуть "более подробно" - ФТ-0311 :-)
Это "закрытый" фаукультет, курировался он минсредмашем (ныне росатом). Там не полагалось писать чему именно человека учили - все спецкурсы были закрытыми.
panzerfaust
28.05.2024 22:31+2Это означает, что данный человек может быть конкретным специалистом
Это означает, что в его вузе так решили вписать, а им на это дал разрешение какой-то госорган. Всё.
ManGegenMann
28.05.2024 22:31Это значит что вуз вам написал какую-то шляпу. Есть перечень государственный специальностей по кодам.
CorwinH
28.05.2024 22:31+1Это значит что вуз вам написал какую-то шляпу.
У меня в дипломе написано "инженер-физик". Трудно придумать что-то более "обобщённое". Если не ошибаюсь, код ОКПДТР 42858.
MadeByFather
28.05.2024 22:31+1Диплом в этом плане актуален лет 5, потом уже либо человек большую часть знаний забыл, если не работал в этой сфере, либо они у него появились в ходе работы и самообучения.
dae-fromru
28.05.2024 22:31+1Не смогут они оценивать человека как человека. Поезд ушёл. Они оценивают человека как автомат как минимум последние 10 лет, местами и больше. Культура уже воспроизвела себя. Максимум, что они сделают - добавят к оценке кандидата другого "нейроджинна". Этот кризис на Западе повсеместен и добрался уже и до небольших компаний. Пишу по личному опыту.
OldNileCrocodile
28.05.2024 22:31А "нейроджин" будет им отвечать, что кандидаты списывают с него. В итоге добавится ещё одно казино, где людям, которые прошли все этапы, будут отказывать из-за списывания. Точнее, на каждом этапе будет кубик от джина, который определит, честный ли кандидат. Кому не повезёт, сразу отказ.
avdosev
28.05.2024 22:31+1Вот вы смеетесь, а антиплагиат с его генеративным контентом уже именно так и работает
gromyko21
28.05.2024 22:31+5Сам сейчас прохожу много собеседований(ищу новое место) и выделяю для себя ряд забавных моментов.
кандидат должен уметь вообще все:
computer science
алгоритмы и структуры данных
свое направление (frontend, backend, …)
систему задизайнить
а еще коммуникативные навыки должны быть на пределе.
Вот это на самом деле довольно забавный момент, действительно люди хотят, чтобы ты знал все это еще и на очень глубоком уровне. То есть ты должен на протяжении лет 15 все это выучить, применить на проектах, знать, как все реализовано под капотом, все преимущества и недостатки, сложность всего этого, но платить мы тебе будем не сильно больше мидла.
Так же по обратной связи за частую стандартная отписка происходит. Недавно проходил собеседования с Авито - прошел первую секцию на аглоритмы без проблем. Далее, чтобы ускорить процесс попросил оставшиеся 2 секции поставить в 1 день. Мне их поставили и получилось такое:
2я секция решил задачу, в ОС сказали, что решил ее не оптимально (честно, нет вариантов, как можно решить оптимальнее). Хотел постичь тайну оптимального решения этой задачи - мне сказали, что такое они не разглашают, чтобы не слить свои задачи(хотя, суть задачи я помню и так и слить нет никаких проблем). Далее были действительно некоторые спорные моменты по одной из технологий, которую я знаю не на глубоком уровне.
3я секция - проектирование системы, проектировали начальную версию твиттера, как мне показалось - прошло все хорошо(учел все моменты, отвечал на доп. вопросы интервьюера). В итоге мне на эту секцию не дали фидбека вообще потому что по результатам 2го этапа я у них не прошел бы дальше.
Итого казалось бы большая компания, а нормального фидбека от них не получить, что уж тут говорить о мелкихOldNileCrocodile
28.05.2024 22:31Так а что за задача то в итоге? Напишите уж.
gromyko21
28.05.2024 22:31Есть 2 списка посещенные страницы и рекомендуемые.
Посещенные [5, 6, 9], Рекомендуемые [9, 1, 4]
Нужно вернуть список рекомендуемых, исключая посещенные, с той же сортировкой. Размеры список могут быть разными могут быть разными.В этом примере результатом будет [1, 4] только в этой последовательности.
Мое решение:
Я сделал так - завернул посещенные в set(чтобы можно было искать за O(1)). Итерировался(зная индекс) по посещенным - смотрел есть ли в рекомендуемых и если да - удалял.
VladD-exrabbit
28.05.2024 22:31Возможно, они считали списки предварительно отсортированными, и хотели чтобы вы прошли двумя указателями по обоим спискам (типа как merge наоборот).
kalombo
28.05.2024 22:31+4Что примечательно, вы уже знаете такой тип задач и я тоже так подумал, но знаем мы их не потому что на работе подобное делали, а потому что на собесдованиях с такими сталкивались. Такой сюр.
gromyko21
28.05.2024 22:31+1Ахаха. Вот это правда смешно, в работе у меня такого не было, только на литкоде. Но все же решение задач такого уровня скорее плюс, чем минус(по моему мнению). Но это не должно быть решающим фактором при найме, а лишь небольшим преимуществом.
piton_nsk
28.05.2024 22:31[9, 1, 4] на отсортированный непохож.
VladD-exrabbit
28.05.2024 22:31Возможно, ТС недопонял задание. Или, возможно, нужно было поддерживать эти списки всегда в отсортированном состоянии, чтобы иметь возможность фильтровать однопроходным алгоритмом. Кто его знает, какое решение авторы задачи имели в виду, когда давали её?
piton_nsk
28.05.2024 22:31+1Кто его знает, какое решение авторы задачи имели в виду, когда давали её?
В этом и проблема таких задач, напридумывать можно очень много всего, но поди догадайся чего именно от тебя хотят. Вообще вопросов много, какой типичный размер списков, сколько всего страниц, может там вообще битовые маски сравнивать можно, кто его знает.
VladD-exrabbit
28.05.2024 22:31Ну вот и надо нафонтанировать идей, чтобы интервьюер не успел вставить и слова.
Sabiko
28.05.2024 22:31По логике задачи они скорее отсортированы по разым принципам (посещённые - по порядку посещения, рекомендуемые - приоритет). Может в удалениях проблема, если там структура с удалением за O(n) и надо было in place сделать.
Racheengel
28.05.2024 22:31Я сделал так - завернул посещенные в set(чтобы можно было искать за O(1)). Итерировался(зная индекс) по посещенным - смотрел есть ли в рекомендуемых и если да - удалял.
Завернуть в сет - это хорошо. Но надо было после этого итерироваться по рекомендуемым, с конца списка - тогда затраты на удаление будут минимальными, без возможных реаллокаций памяти.
PVoLan
28.05.2024 22:31Если списки изначально вида arraylist, то удаление из списка хоть ты тресни будет неоптимально и вызывать реаллокации. Надо создавать новый arraylist result (сразу аллоцируя память размером Рекомендуемыe.size()) и по мере итерации добавлять отфильтрованные элементы в результирующий список.
Если изначально списки вида linkedlist, то там другая история
SpiderEkb
28.05.2024 22:31+1Если списки изначально вида arraylist, то удаление из списка хоть ты тресни будет неоптимально и вызывать реаллокации. Надо создавать новый arraylist result (сразу аллоцируя память размером Рекомендуемыe.size()) и по мере итерации добавлять отфильтрованные элементы в результирующий список.
В целом верно. Хотя, если список не сортированный (порядок следования элементов не важен), то "удаление" можно проводить путем копирования последнего элемента списка вместо удаляемого с уменьшением значения счетчика "количество элементов в списке".
Предположительно по скорости будет то же самое что и перенос подходящего элемента в новый список (тоже одно копирование), но по памяти экономичнее - один список вместо двух.
Lyova5
28.05.2024 22:31+2Идём по второму списку двумя указателями, по первому проверяем посещение, по второму записываем если посещения не было (ин-плейс, как писали выше). В конце подрезаем размер. И никаких реаллокаций.
CorwinH
28.05.2024 22:31+1смотрел есть ли в рекомендуемых и если да - удалял.
Не знаю, что за язык и что за список, но предположу, что удаление из этого списка O(n).
SpiderEkb
28.05.2024 22:31+1"Удаление" из списка может быть очень экономичным - см выше (перенос последнего элемента вместо удаленного). Или вообще флажок "активен/не активен" для каждого элемента. Или два списка с переносом подходящих элементов из одного в другой (если нужно несколько "просевов" делать, то списки после каждого просева меняются местами).
Как раз недавно была такая задача с реализацией "play-off" алгоритма где в цикле на каждом этапе происходил отсев элементов, не прошедших отбор.
CorwinH
28.05.2024 22:31+1"Удаление" из списка может быть очень экономичным
Под удалением я имею ввиду предлагаемый из коробки метод remove. То есть, то, что не нужно писать самому и указывать при описании алгоритма.
vitya_lazer
28.05.2024 22:31+1Возможно стоило аллоцировать мапу из посещенных, завести счетчик, и далее проходя по рекомендуемым, смотреть - есть ли элемент из рекомендуемых в мапе. Если же его нет, то мы меняем элемент по индексу счетчика в списке рекомендуемых на текущий, и инкрементируем счётчик. В конце обрезаем длину рекомендуемого списка по счетчику. То есть на примере: мы завели мапу из посещенных, идем по списку Рекомендуемых, счетчик = 0. Попадаем на элемент 9, есть в мапе, пропускаем. Далее следует 1, в мапе нет, заменяем в списке элемент с индексом счетчика(0) на 1, счетчик++. И в конце попадаем на 4, в мапе есть, заменяем в списке элемент с индексом счетчика(1) на 4, счетчик++. В итоге получается список [1, 4, 4], который мы обрезаем по значению счетчика(2).
OldNileCrocodile
28.05.2024 22:31По сути вернуть разность множеств B \ A (B - рекомендуемые, А - посещённые).
Задача из leetcode. (Только там нужно посчитать ещё в две стороны).
https://leetcode.com/problems/find-the-difference-of-two-arrays/
M_AJ
28.05.2024 22:31+2Не секрет, что IT-компании заботятся о своем hr-бренде
Так это делается для новых людей, чтобы пришли на собеседование, а не отказывали заранее. Как скидки для новых абонентов у операторов связи и сервисов подписки.
Но вообще, я все ждал когда автор доберёшься до многоступенчатых многодневных собесов, на мой взгляд, в плане отношения ко времени кпндидата, это ничем не лучше кривого тестового, его хотя бы сам решаешь когда делать, но автор их почему-то не упоминает.
mrerberg Автор
28.05.2024 22:31Спасибо за отзыв. Я решил не включать это в статью, так как подобного опыта у меня было крайне мало. Одно или два подобных собеса, где весь процесс растягивался на недели, а опыт был крайне негативным.
Соглашусь, долгие процессы и многоступенчатые собеседования — отдельная боль из-а ощущения, что тебя хотят провести по всем кругам ада, которые только имеются. И усугубляется все тем, что в конце ты получаешь стандартную отписку без какой-либо обратной связи.
SpiderEkb
28.05.2024 22:31+2Раз уж упоминалась Альфа. Тут много систем, много направлений, много команд (вообще IT подразделение Альфы оценивается в примерно 5тыс человек по всем направлениям). И каждая проводит собес в своем формате.
У нас (центральные банковские системы - то, что работает на центральных серверах) собес (единственный) - это просто разговор с командой. Мы рассказываем чем занимаемся мы, кандидат - чем занимался он. Никаких алгоритмов, никаких тестовых задач.
А дальше уже и кандидат решает нужно ли ему вот это все вот и мы думаем подойдет ли он нам. Обычно после собеседования нескольких кандидатов команда их "рейтингует" - этот лучше всех, тот второй в списке, ну а тот на случай если первые два откажутся...
Все равно потом 3 месяца будет обучение с наставником ну и потом уже в процессе работы наберется опыта.
beduin01
28.05.2024 22:31+1А это не вы мне фидбек дали: "не подходит, потому что слишком самостоятельный"?
SpiderEkb
28.05.2024 22:31+1Нет. Я принципиально не мог дать такой фидбек :-) Люблю самостоятельных - они не задают вопросы, ответы на которые есть на первой странице выдачи гугла. Таки если и приходят с вопросом, то над этим вопросом порой самому задумываться приходится :-)
Drucocu
28.05.2024 22:31+1Обычно после собеседования нескольких кандидатов команда их "рейтингует"
"Всё познаётся в сравнении".
Вообще, хороший подход, потому что если оценивать всех кандидатов индивидуально, недостатки можно найти у кого угодно. Когда мы выбираем из нескольких вариантов, включаются совершенно другие когнитивные механизмы, чем если бы мы принимали решение - взять ли конкретного человека. Разная мотивация и разная цена ошибки.
SpiderEkb
28.05.2024 22:31Ну тут вопрос выбора из имеющихся...
Вот в последний раз собеседовали троих. Собеседующих было 3 или 4 человека. Когда всех троих "отсобеседовали" (по очереди) потом собрались и обсудили кому кто и почему понравился или не понравился. Выстроили рейтинг. Послали офер первому по рейтингу. Но он уже нашел себе что-то другое и отказался. Тогда послали следующему. Тот согласился. Сейчас работает.
Это вопрос команды - руководитель управления (в нашей иерархии - административный рукводитель) и лиды (тимлид,техлид). Может быть еще "функциональный руководитель" (тот, с кем решаются все рабочие вопросы, не административные). И раз мы ищем человека в команду, с которым нам потом работать, то решает тут все-таки команда.
mrerberg Автор
28.05.2024 22:31+1Спасибо за комментарий! Хороший подход. А ведется ли какая-то статистка, чтобы понять, сколько решений вынесено удачно, а сколько нет?
Хорошо подметили про наставника. Считаю, что это вполне закрывает некоторые пробелы, выявленные на собеседовании. Так и так кандидат будет вникать, спрашивать, изучать экосистему. А там уже разберется.
alextradex
28.05.2024 22:31+1весь абзац "Пришлось покряхтеть с реализацией, .............. но осадочек остался. " повторяется два раза.
Следующий за ним "Проводя интервью ...." тоже, но частично
Bessome
28.05.2024 22:31+1Добавлю свой опыт: технические собеседования могу вестись по алгоритмам, по пониманию предметной области, по логике специалиста, по стремлению развиваться. Лучшие мои работы "мечты" были такие, где будущий руководитель беседовал со мной немного по знаниям, много по софтам и получал от меня пакет моих работ.
Считаю, что касается технической части, вроде алгоритмов и знаний предмета можно давать тестовое задание на пару часов, которое можно оценить количественно и качественно минут за 10 и выяснить лишь грейд специалиста.
Тестовые задания, по моей оценке поглощающие более двух часов моего времени характеризуют работодателя с худшей стороны. Именно так работодатель доказывает, что ему плевать на личное время потенциального сотрудника.
Итого: собес с Хантером 30 минут, второй собес с хантером еще 30 минут, 1-2 часа техсобес очно, 2+ часа на задание уже приблизительно 5 часов времени, когда работающий в другом месте специалист в режиме многозадачности пытается не провалить собеседование.
Если, конечно, работодатель очень желаемый, то можно и потратить время. Но, как правило, нет.
SpiderEkb
28.05.2024 22:31+6Все, что выходит за рамки "поговорить с командой на предмет поиска точек общих интересов" уже не интересует.
Вообще преподносить работу как милость, которую еще надо заслужить - такое себе...
northrop
28.05.2024 22:31+1Вообще преподносить работу как милость, которую еще надо заслужить - такое себе...
В этот момент все фаанги планеты издают демонический смех ))))
blind_oracle
28.05.2024 22:31+1Фаанги и платят соответствующе сильно выше рынка, так что, можно сказать, имеют право :)
Drucocu
28.05.2024 22:31+1А как же бессмертное
Работать в нашем банке — большая честь
(не намекаю на ваше или автора место работы, цитата принадлежит сотруднику другого банка, все совпадения случайны)
elena_chmut
28.05.2024 22:31+1Супер, спасибо за мысли и опыт. Особенно коснулся момент по поводу включения в интервью реальных задач, с которыми столкнётся человек, а не просто заданиями по типу "ну, это же бэст прэктис". Актуально для любой сферы.
На старте работы в найме не придавала этому значения, думала, что могу сама правильно декомпозировать запрос работодателя и из него выстроить вопросы/задания для первичного собеса с кандидатом. В итоге опытные и классные ребята, идеально подходящие под запрос, пролетали на этапе собеса с нанимающей командой, и оказывалось, что им задавали вопросы максимально отличающиеся от изначально сформулированного запроса. "Что за ...?" - не могла я понять, пока не дошло, что нужно прям вынуть (а если будет нужно и принудительно) из нанимателя конкретные задачи, на которые он ищет человека (а не хотелки уровня "хочу найти родственную душу и чтоб код писал, как Толстой романы"). Кто-то закатит глаза и скажет: "Банально просто!" Да, но оказалось не так очевидно в начале пути.
mrerberg Автор
28.05.2024 22:31Спасибо за отзыв!
Соглашусь, сбор четких критериев и хотелок нанимателя крайне важно, чтобы подобрать более подходящих кандидатов. Это довольно объемная и сложная тема, которую надо так же практиковать. Часто встречаю проблемы на этом этапе, когда описание вакансии составляется некорректно или слишком абстрактно, с включением максимума ключевых слов.
Отмечу, что еще важно следить за судьбой кандидата, если вы дали добро после интревью. Был опыт, когда кандидат мне очень понравился, рекомендовал его в команду, а он не прижился. Так что следует держать руку на пульсе и рефлексировать, это может помочь в будущем.elena_chmut
28.05.2024 22:31Да, хороший рекрутер в ответе за тех, кого приручил :) Это почти золотое правило из проф.кодекса этики.
iboltaev
28.05.2024 22:31С техническими собеседованиями вообще всегда было непросто - последние 10 лет все кинулись решать задачи, до этого (~ 2010 - 2012) все были укушены паттернами программирования, чуть раньше и одновременно с этим досконально зубрили стандарт языка, чтобы отвечать на бесконечные вопросы "что выдаст вот этот говнокод".
Но вообще алгосы нужны, но в них нужна мера. По моему опыту, нужно обязательно проверять 4 вещи: знает ли человек про динамический массив и куда в него можно вставлять, а куда нельзя, знает ли про двусвязный список и куда в него можно вставлять, а куда нельзя, знает ли пользу сортировки и бинарного поиска и знает ли, что такое хэш-мапа. RB-мапа - как бонус. Потому что 80% неоптимального кода - когда юзают динамический массив вместо мапы. 20% - на все остальное, преимущественно списки (это моя личная статистика за ~12 лет, когда я так или иначе ревьюил чужой код в разных компаниях).
Тестовое задание - вообще тема. Если честно, я бы никогда не взял человека, который откажется сделать тестовое. Единственный минус тестового - нет уверенности в том, что человек его сделал лично, даже после беседы (да, я обожаю делать тестовые, никогда не отказывался и всегда они были интересными).
Просто на поговорить - мне кажется, такие собеседования контрпродуктивны, так как проверяют навыки коммуникации, а не собственно разработки, я такие интервью не люблю ни проводить, ни проходить.
Drucocu
28.05.2024 22:31+9Если честно, я бы никогда не взял человека, который откажется сделать тестовое.
Как интересно устроен мир: вы бы меня не взяли, а я бы к вам и не пошёл.
А если серьёзно, вы рассуждаете исключительно с точки зрения своего удобства как нанимателя. Кажется, вам самому надо пройти пару-тройку собесов для разнообразия.
andmerk93
28.05.2024 22:31+2Тестовое задание - вообще тема.
Скопируйте, пожалуйста, в ответный комментарий 5 последних ответов на тестовые задания, если не сложно.
Очень интересно прочитать, как дают обратную связь в нормальных компаниях. Без имён, анонимно, естественно, чтобы ничего не нарушить.
evetester
28.05.2024 22:31+1Зачастую нет вообще никакой обратной связи, ни в больших компаниях, ни в средних, ни тем более в маленьких. Обычно всегда говорят так: "Да вы нам подходите, мы с вами свяжемся...". И всё на этом. Ещё задают не те задания, задают вопросы которые вообще никакого отношения не имеют к должности которую предлагают, спрашивают совершенно не то для чего ищут сотрудника. Я давно уже понял то что эти так называемые рекрутеры берут вопросы из каких-то шаблонов.
SloN1
28.05.2024 22:31Работаю на промпредприятии.
Программисты, насколько я знаю, просто давали задание часа на два, а потом смотрели на результат. Сколько себя помню, ни про кого ничего плохого не говорили, т.е. про работу спросили, работу потом и получали.
----
Мы в техподдержке старались брать только знакомых (ошибка в работе рекомендуемого - это минус рекомендующего), а если через кадровиков, то просили только резюме (никаких тестов на корреляцию знака зодиака претендента с площадью предприятия и ИНН секретаря генерального директора).
Приглашали соискателя и рассказывали: з/п базовую; з/п с переработками; что пользователи адекватны не все; что техника разная; что если на производстве что-то бумкнуло в 2 часа ночи, то один беги и восстанавливай с принтером/системником/сканером/монитором в зубах (напарник остаётся на телефоне и если может, то помогает только дистанционно, а резерв на месте стоит не всегда); что если открыли простой производства, то будь готов с написать подробно что-где-когда и договориться с производственниками, чтобы они отозвали простой; что частенько бывает так, что что-то крикнут в трубку и сразу бросят её: нужно сделать обратный звонок (слава АОНу), выяснить что-где-когда и постараться помочь или найти исполнителя; что смены начинаются с привязкой к графику производства: цеховые к 07:00, наши к 06:30, чтобы проверить/восстановить работу систем, домой вторая смена ночью; что с 17:00 до 08:00 ты админ ИС и перезагрузить сервер или узлы системы – это рутинная операция; что придётся ходить к директорам на поддержку конференций, где можно всякое услышать в адрес ИТ-службы и себя лично; что если проблема на стороне иностранцев, то быстренько оформи инцидент в их системе (Do you speak English?), накидай туда логов, утром поясни им, кто редиска и почему, оповести руководство; что ночью у тебя только три друга: твой мозг, твой напарник и папка с документацией по ИС; что бесплатные печеньки и кофе дома; что "team building" у нас – это не перетягивание каната, а вот это всё описанное выше. В общем – вводили в курс дела.
Зато: кто не пугался, все вписывались в коллектив; всегда помощь друг другу; если эмоции, то на полную, до достижения результата; если решил уйти, то в добрый путь, с наилучшими пожеланиями.
ОЧЕНЬ помогало то, что техподдержка, предоставление доступа и админы были в одном помещении, что даёт рассмотреть любую проблему сразу со всех сторон. Да и программисты для нас не небожители: всё работает – молодцы, что-то сломалось – БЕГИТЕ разбираться вместе.
PS. Всё написал в прошедшем времени, потому что сейчас я занимаюсь другим.
PSS. В Альфе я сам не работал. Работал бывший коллега (сильнейший программист, из тех, кого я знал тогда), был доволен. Лично я общался с сотрудниками Альфы в Москве, когда мы выбирали ITSM- систему (внедренцы сделали нам экскурсию по 4-м организациям с 4-мя разными ИС). До сих пор ощущение спаянного коллектива, настоящей команды без лишних.
SpiderEkb
28.05.2024 22:31пользователи адекватны не все; что техника разная; что если на производстве что-то бумкнуло в 2 часа ночи, то один беги и восстанавливай с принтером/системником/сканером/монитором в зубах...
Вот я тоже предпочитаю сразу карты на стол - платформа мощная, интересная, но весьма специфическая. Т.е. весь опыт будет "нерелевантным" - в стране мало кто ее использует. Требования по производительности, эффективности очень жесткие. Чтобы потом у человека не было "а я не это загадывал..." (с)
Но при этом "люди хорошие" :-) Всегда помогут, всегда ответят, отношения всегда доброжелательные. Руководство адекватное. По деньгам тоже норм.
Kirill_Dan
28.05.2024 22:31Мое личное мнение, что невозможно в принципе улучшить процес найма и собеседования. А причина банальна до безобразия - бизнес ищет не того, кто им нужен на самом деле. Попробую раскрыть свою мысль. Любая работа, это не про алгоритмы и закрытие тасок - это про социум, отношения и достижение общей цели. Предположим, что вы молодой парень (а может уже и не очень молодой), и вы хотите построить семью. Вопрос номер один: зачем вам это нужно. Если ответ звучит, как: чтобы стирала, убирала и сопли мне вытирала, то это явно не про построение семьи идет речь. Если вам это нужно для того, чтобы поделиться вашей любовью и заботой, разделить все тяготы совместной жизни и все радости, завести детей, то это уже кардинально другая стратегия. Если вы решили, что семья - это первый ответ, то вполне логично, что вы дилегируете поиск "жены" HR менеджеру, а собеседование будет проводить ваш женатый коллега, с опытом
эксплуатации женысемейной жизни. Если ответ второй, то вы озаботитесь поиском сами. Второй вопрос, а как вы будете искать свою половинку? Дадите объявление, что вы молодой и данамично развивающийся парень, и ваша будущая половинка получит хороший опыт, большие перспективы и бесплатный абонемент в тренажерный зал? Опишите требуемый опыт и набор навыков? Думаете, что это сработает? Не буду дальше все расписывать до мелочей, надеюсь, что читатель и сам поймет суть аналогии.Еще одну аналогию могу привести в пример. Предположим, что на СТО приехал клиент и просит заменить ему свечи зажигания. Механик делает замену свечей, а клиент начинает недовольно предъявлять претензии, что он не доволен проделанной работой. Когда к спору подключается руководство и начинают выяснять, в чем причина, то клиент заявляет, что проблема в том, что двигатель его автомобиля троит, и он решил, что проблема в свечах. Почему он так решил, да потому, что это самое бюджетное решение проблемы из всех возможных, поэтому он его и выбрал. Получается, что проблема клиента - это троящий двигатель, который жрет бензин и колбасит весь автомобиль, но он не об этом говорит механику, а просит произвести замену свечей, надеясь, что само все как-то решится. А когда его надежды рухнули, начинает в этом винить не себя, а механика.
Возвращаемся к бизнесу и найму. Из вышеописанных примеров вполне ясно, что речь не идет о каких-то технических знаниях, а речь идет об отношениях между людьми. Топ менеджер в 99% случаев ведет себя, как клиент на СТО из второго примера или ищет себе
рабыню"жену" из первого примера. А при таком подходе это в принципе не может решить проблемы и потребности бизнеса, поэтому и ищут не того, кто реально нужен. А главное, скидывают этот поиск на людей, которым бизнес босса вообще по барабану. Сегодня они здесь, а завтра их уволили. И в какой-то момент сотрудник понимает, что он больше не хочет быть "женой" с односторонней любовью. Поэтому все эти собеседования не про то, что будет выбран самый подходящий кандидат для решения поставленных бизнес задач, а про то, что будет выбран сотрудник, который лично понравится собеседующему, по его каким-то внутренним убеждениям и критериям. А это уж точно не про бизнес! Отсюда вывод: сама система найма в корне неправильна, а значит нет никаких рецептов для улучшения этого процесса, так как борьба идет не с причиной, а со следствием.SpiderEkb
28.05.2024 22:31+2А причина банальна до безобразия - бизнес ищет не того, кто им нужен на самом деле.
На самом деле, бизнесу нужно чтобы его задачи решались. Как - это уже наша забота и головная боль. Поэтому выбор способа решения задач бизнеса лежит на нас, а не на бизнесе. Бизнес зарабатывает деньги, мы ему в этом помогаем за "толику малую" от заработанного.
Kirill_Dan
28.05.2024 22:31+1И как много денег вы помогли заработать бизнесу? Вам компания скинула финансовый отчет лично по вашей персоне? А что значит, что задачи решались? Задача "сделать меня богатым за три месяца", как вами решается?
SpiderEkb
28.05.2024 22:31Конкретно по моей персоне не так давно
Вам сегодня должна прийти премия за особый вклад в развитие и оптимизацию нашей АБС, который сделан в рамках проекта Феникс, в части оптимизации процедур процедуры массовых проверок клиентов в части комплаенс процедур и проверок - рассылки уведомлений на наличие паспортов в ФМС (сокращение c 2 часов до 40 минут), ускорении процедуры актуализации данных по клиентам, оптимизацию проверки по спискам террористов
Это не столько про "заработать" сколько про то, чтобы не огрести проблем от регулятора и убытков (в т.ч. и репутационных) со стороны клиентов от того, что что-то тормозит или не работает.
Это "внеплановая" премия (вполне себе ощутимого размера) помимо регулярных бонусов.
Gradiens
28.05.2024 22:31+1Задача "сделать меня богатым за три месяца", как вами решается?
Путем направления к бизнесу толкового аналитика. Который принесет в клювике нормально сформулированные бизнес-цели. Потом подключаем архитектора. И вот у нас определены стейкхолдеры, скоуп проекта, есть черновик архитектуры, оценка трудозатрат, матрица рисков и вот это все.
Подключаем еще людей, и каждый в рамках своей компетенции делает кусочек паззла, чтобы бизнес стал богатым.
Насколько много каждый сотрудник принести бизнесу денег - вопрос риторический. Ответа на него нет.
Зато есть ответ на вопрос какая у проекта экономическая эффективность.
Kirill_Dan
28.05.2024 22:31+3А подключаете, это как? Через какой-то порт, который есть в теле менеджера? А что значит, направляете аналитика? Вы, как наемный сотрудник, нанимаете за свой счет аналитика (которого еще нужно найти под конкретные бизнес задачи) и направляете его своему боссу? Все это софистика, которая не имеет к реальности никакого отношения.
А вот что действительно имеет отношение к реальности, так это то, что Гугл в этом году закрыл ряд своих проектов, в которые вложил сотни миллионов долларов (например из сегодняшнего, это Гугл подкасты), если не больше. И там были и толковые архитекторы, аналитики и разработчики. Но это никоем образом не сделало их продукты конкурентно способными, хотя компания, по факту, является крупным монополистом с "бесконечными" ресурсами.
И тут возникает вполне логичный вопрос, а почему же ваша логика не сработала в такой компании, как Гугл? А может потому, что подход в корне неверен?
Gradiens
28.05.2024 22:31А подключаете, это как? Через какой-то порт, который есть в теле менеджера?
Да.
Есть такой порт. Называется рот и уши.
Все это софистика, которая не имеет к реальности никакого отношения.
все это - реализация конкретных проектов, которые более чем имеют отношения к реальности. Проектов которые приносят прибыль. Или не приносят по тем или иным причинам.
Реализация определенных рисков вовсе не говорит о том, что методология разработки плохая. Если мат. ожидание прибыли больше нуля - значит, все нормально. Даже , если какие-то конкретно проекты закрываются с убытком.
И тут возникает вполне логичный вопрос, а почему же ваша логика не сработала в такой компании, как Гугл?
А может наоборот, сработала?
Количество прибыльных проектов явно выше количества убыточных.
saboteur_kiev
28.05.2024 22:31Бизнес это не только деньги. Это еще и жизнь бизнесмена, его время и нервы на управление. Его возможность похвалиться своим детищем.
Люди по-разному ведут свой бизнес.
Бизнес может вложиться в процесс найма и организовать его так, чтобы и нанимались люди грамотно и процесс работы был грамотный.SpiderEkb
28.05.2024 22:31Вы серьезно считает что можно нанять какого-то "специалиста", который сможет адекватно оценивать уровень человека в той области, где он не является профессионалом высокого уровня?
Искусство управления заключается в том, чтобы уметь грамотно делегировать полномочия профессионалам. Если вам говорят "нам в команду нужен еще один человек" и убедительно это аргументируют - дайте команде самой подобрать того, с кем им потом работать. Не вмешивайтесь в то, чего не понимаете. Разные оргвопросы - да, возьмите на себя. Но выбор должен быть за командой. Только так вы получите действительно сильную команду, а не сборище случайных людей.
saboteur_kiev
28.05.2024 22:31Я серьезно считаю, что если владелец бизнеса заинтересован в грамотном найме, он может его устроить, поставив соответствующие задачи и выдав соответствующие полномочия.
janvarev
28.05.2024 22:31+1Вопрос номер один: зачем вам это нужно. Если ответ звучит, как: чтобы стирала, убирала и сопли мне вытирала, то это явно не про построение семьи идет речь. Если вам это нужно для того, чтобы поделиться вашей любовью и заботой, разделить все тяготы совместной жизни и все радости, завести детей, то это уже кардинально другая стратегия. Если вы решили, что семья - это первый ответ, то вполне логично, что вы дилегируете поиск "жены" HR менеджеру, а собеседование будет проводить ваш женатый коллега, с опытом
эксплуатации женысемейной жизни. Если ответ второй, то вы озаботитесь поиском сами.Да что ж вы делаете-то! *утащил и поставил в рамочку*
squaremirrow
28.05.2024 22:31+3Во всех рассуждениях о найме и том, как надо проводить собеседования, я вижу пугающее отсутствие каких-либо эмпирических данных об эффективности того или иного метода отбора.
Понятно, что полноценные исследования могут проводить либо очень большие компании, либо агенства. Но даже им очень тяжело оценить свой уровень ложно-отрицательных ошибок - разве что случайным образом брать тех, кого забраковал HR/нанимающий менеджер, и смотреть, как они будут работать.
С другой стороны, даже если такие исследования кто-то делает, то публиковать их результаты - не в интересах команий/агенств, т.к. кандидаты могут прочесть его и начать мимикрировать под хороших кандидатов.
Titsubishi
28.05.2024 22:31+1Классная статья! Самое главное, что все это прожито на практике. Респектую автору.
upcFrost
28.05.2024 22:31+1Статья хорошая, правда для нашего интервью косяков не нашёл. Мы делаем мини-проект из двух частей, которые симулируют жизненный цикл проекта. Первая часть mvp на пару часов, дальше мини-тикеты на его улучшение. Такой структурой убиваем сразу пачку зайцев: chatgpt теряет контекст (пользоваться можно всем) и кандидаты без головы отлетают; видим как человек адаптируется к изменениям; задачи сменяются и человеку интересно; можно оценивать сколько доп тикетов сделано и их уровень
mrerberg Автор
28.05.2024 22:31Спасибо за комментарий! Под mvp вы имеете в виду тестовое задание? Если да и это возможно, то поделитесь, пожалуйста, заданием подробнее, звучит интересно
upcFrost
28.05.2024 22:31Самим заданием не поделюсь, по понятным причинам. Подробнее - сначала мы просим сделать совсем примитивную фигню типа "нужно приложение которое умеет Х" (например страница форума с кнопкой "ответ" и записью в базу, без регистрации и смс). На это идёт 2-3 часа чтоб человек успел взять кофе, оттупить и вообще.
Дальше идут доп "тикеты" типа "прикрути регистрацию", "прикрути редактирование", "загрузка файлов", "деплой" и прочее. И к ним идёт условие что "приложение должно жить", то есть никаких вайпов базы и прочего. Тикеты бывают разной сложности, от "напиши докерфайл" до "сделай биллинг с моками" (утрирую, биллинга нет).
На тест идёт целый день, с 9 до 5 с обедом. До этого мини-разговор по видео и онлайн-тест (примитивный)
mrerberg Автор
28.05.2024 22:31Интересно, спасибо, что поделились. А сколько обычно занимает процесс закрытия такого проекта? Это присходит в асинхронном режиме? Почему решили не выдавать все задание целиком?
upcFrost
28.05.2024 22:31Проект на день с 9 до 5, это он-сайт интервью (дорогу/проживание покрываем), закрытие минут 30-40 включая демо, пару вопросов по не вошедшим тикетам типа "а как бы сделали", ну и просто за жизнь поговорить. Всё синхронно, можно общаться с командой, задавать вопросы и прочее. По сути пытаемся приблизить тест к жизни (удалёнку не практикуем, только офис). Потому же и задание идёт частями, продукт всё-таки не сразу имеет все возможные тз на весь цикл, сначала mvp, дальше по ситуации.
Плюс очень большой момент с выдачей по частям это chatgpt, он довольно быстро теряет контекст задачи и начинает генерить бред. У нас уже была пара chatgpt-программистов, такое себе, код красивый и абсолютно бессмысленный.
Drucocu
28.05.2024 22:31Какое-то лютое моталово, если честно. Кандидаты очень сильно должны хотеть у вас работать, если соглашаются на такое. Интересно, чем вы их так привлекаете.
Кажется, что без ущерба качеству можно было бы подготовить для собеседуемых основу проекта, которую уже надо допилить (когда-то занимался таким: у меня даже был отдельный сервак, на котором я для каждого нового кандидата разворачивал свежую тестовую среду).
Вот что вы проверяете первым этапом, когда он создаёт страницу с кнопкой? Что он может нагуглить бойлерплейт, получается. Вся сложность же потом начинается. Зато стресса от того, что надо на собеседовании всё делать с нуля, кандидат хапает прям с порога.
upcFrost
28.05.2024 22:31Про моталово я ответил в другой ветке, где и упомянул что речь про Швейцарию, а не про Россию. Чем привлекаем думаю тоже понятно, как минимум зарплатой.
Про среду и прочее - можно. Но пока идея такая что кандидат свободен юзать что умеет, и главное - умение решать задачу, а не настраивать неизвестный ему фреймворк
Drucocu
28.05.2024 22:31Тогда да, это многое меняет)
upcFrost
28.05.2024 22:31У нас это по сути единственный вариант. Компания небольшая, мороки при найме прилично (Швейцария не ЕС, нужно оформлять пермит даже для европейцев), с жильём для вновь прибывших засада (съем в женеве это боль), да и айтишников в Европе вообще-то не густо. То есть да, в Москве можно найти условного питониста который умеет работать например с фастапи, постгресом и такой-то либой для аналитики. У нас же в лучшем случае выйдет найти питониста с мозгами, который сможет все это освоить в разумные сроки, и то его придётся везти с севера Франции. Завлекаем тем что зп выше чем в окрестных странах раза в 3, ну и что есть достаточно умные люди которые после крупных гуглоамазонов хотят в небольшую компанию чтоб просто иметь импакт, а не долбить одну и ту же функцию до посинения.
Ну и моталово мы пытаемся сгладить. Например рейс не день в день, а в субботу чтоб пару дней погулять по городу. И отель не койка в хостеле с клопами, а нормальный с завтраками и прочим. Понятно что все равно такое, но как лучше я хз.
helmm
28.05.2024 22:31И видимо ожидается что соискатель всё это будет делать забесплатно?
upcFrost
28.05.2024 22:31В плане? Это собеседование. Проезд/жилье оплачиваем если соискатель из другого города/страны. Проект к основному бизнесу не относится никак вообще, его результаты мы тоже кроме оценки соискателя использовать не будем, это отдельно прописано в той кипе бумаг которую подписывают перед собесом. Вы что, платите деньги за собеседование? Я б прошёл в таком разе.
helmm
28.05.2024 22:31+1Удивительно как быстро вы уловили суть вопроса. Компании занимаются всей этой ерундой с тестовыми заданиями только потому что для них это бесплатно.
Как только оказывается, что надо платить, то методики отбора существенно меняются - выгоднее не давать тестовое задание, а после собеседования сразу нанимать и оценивать работу уже в процессе испытательного срока. Что характерно, имено такой процесс предусмотрен законом.
А принудительный бесплатный труд, который выдаётся за "тестовое задание" наоборот законом запрещён.upcFrost
28.05.2024 22:31+1Во-первых законом тестовые задания не запрещены, и я не знаю откуда вы взяли этот бред. Равно как и не понимаю почему вы назвали его принудительным, вы сами подались на вакансию, не хотите - не надо.
после собеседования сразу нанимать и оценивать работу уже в процессе испытательного срока.
Вы очень плохо себе представляете рынок труда и законы в Европе. Да, внезапно, я живу в Швейцарии и компания внезапно тоже здесь. Нанять "сразу" у вас не выйдет просто потому что notice period здесь обычно от 2-3 месяцев и выше, а не 2 недели как в России. Нельзя просто "взять и нанять".
Далее, я живу в Женеве, население 500к человек, и для Европы это нормальный город. Айти здесь не особо популярно, соответственно 99% соискателей живут в лучшем случае в радиусе 100км, а обычно ещё дальше, у нас был ровно один чувак из непосредственно Женевы. То есть после принятого оффера соискателю придётся натурально переезжать как минимум в другой город, и скорее всего - в другую страну, со всеми вытекающими арендами, счетами, регистрациями и т.д.. В такой ситуации выгнать тряпками на мороз через 3 месяца испытательного просто по-человечески некрасиво, потому и делается полный день на месте чтоб и мы, и кандидат убедились что по крайней мере не бесит друг друга.
Как только оказывается, что надо платить
И вот на этот счёт - я там выше написал что жилье и проезд оплачен. И я имел ввиду не метро, а самолёт из условного Мадрида и отель в Женеве. Это стоит денег, поверьте.
helmm
28.05.2024 22:31Очень хорошо, что вы всё-таки решили упомянуть о том, что говорите об особенностях найма в Европе (хотя это не так уж важно для топика).
Нанять "сразу" у вас не выйдет просто потому что notice period здесь обычно от 2-3 месяцев и выше, а не 2 недели как в России. Нельзя просто "взять и нанять".
Notice period это же про увольнение? А нанять-то никакой проблемы нет, я так полагаю. В России для уведомления по увольнению на испытательном сроке даже не 2 недели, а 3 дня. Не знаю как это в Швейцарии, но для испытательного срока что-то аналогичное по-любому должно быть предусмотрено.
То есть после принятого оффера соискателю придётся натурально переезжать
Странно, конечно, что в 2024 году для работы предполагается куда-то переезжать. Но опять же, это это отдельный вопрос, не относящийся к тому, что за работу по выполнению "тестового задания" вы почему-то считаете нормальным не платить.
Равно как и не понимаю почему вы назвали его принудительным, вы сами подались на вакансию, не хотите - не надо.
"Тестовое задание" не было бы принудительным, если бы отказ от его выполнения не влёк за собой негативных последствий для соискателя. Но работодатели зачастую практикуют отказ от дальнейшего рассмотрения соискателя на позицию по вакансии как меру принуждения к выполнению "тестовых заданий", из-за этого и стоит рассматривать "тестовые задания" как принудительный труд.
В такой ситуации выгнать тряпками на мороз через 3 месяца испытательного просто по-человечески некрасиво, потому и делается полный день на месте
И вот на этот счёт - я там выше написал что жилье и проезд оплачен. И я имел ввиду не метро, а самолёт из условного Мадрида и отель в Женеве. Это стоит денег, поверьте.Если работодатель очень заботится о том что его действия некрасивы, то ничто не мешает работодателю оплатить жильё для нового сотрудника на время испытательного срока, тогда уволив неподошедшего сотрудника не придётся сильно переживать.
upcFrost
28.05.2024 22:31Notice period это же про увольнение? А нанять-то никакой проблемы нет
А человек вот прям сидит без работы и ждёт когда ж вы его наймете. Нет, это значит что после собеседования компании надо ещё от 2 до 6 месяцев ждать пока человек выйдет. И кстати он может ещё отказаться, контракт не подписан.
Странно, конечно, что в 2024 году для работы предполагается куда-то переезжать
У нас фулл-тайм в офисе, без удаленки. Если вам нужна удаленка - ну, работайте там где она есть, никто не заставляет же.
Тестовое задание" не было бы принудительным, если бы отказ от его выполнения не влёк за собой негативных последствий для соискателя
Что за шиза? Негативные последствия это на работу не возьмут? А за что брать, за красивые глаза? Или просто "на посмотреть"? И зарплату тоже платить при этом, даже если квалификация на нуле? Зашибись план, звучит надёжно
ничто не мешает работодателю оплатить жильё для нового сотрудника на время испытательного срока, тогда уволив неподошедшего сотрудника не придётся сильно переживать.
Не совсем. Во-первых переезд это стресс. Во-вторых снять жилье здесь мягко говоря сложно, и если контракт меньше 3 лет то ценник будет конский. В-третьих жилье от компании это доход, с дохода налог, шкала прогрессивная, учитывая цены на меблированные квартиры (а это редкость) на срок меньше года человеку с зп после налогов не останется нихрена.
Короче вы пишете какую-то невероятную чушь уровня школьника с розовыми очками и ощущением что ему все должны. Это не так. Трудовой договор это именно договор, между двумя партиями, от которого обе стороны получают выгоду. Это не благотворительность и не содержание.
helmm
28.05.2024 22:31До оскорблений про школьников, шизу и прочее скатываться, конечно не хорошо. Неужели получше аргументов не нашлось?
iEstale
28.05.2024 22:31Читать дальше после слов о бесполезности алгоритмических задач считаю бесполезным.
mrerberg Автор
28.05.2024 22:31+2Спасибо за комментарий! Считаю бесполезными их для себя. Опять же, если вы разрабатываете низкоуровневые вещи, новые алгоритмы, движки, утилитарное ПО - то это важный навык, которой стоит проверять.
mrerberg Автор
28.05.2024 22:31Хотел еще добавить кое-что. По факту, человек все делает через алгоритмы. Мы программируем на алгоритмах, наши программы — комбинация алгоритмов. Другой вопрос, какая их сложность, для чего используются.
Если говорить конкретно, то алгоритмы для обхода графа мне не нужны сейчас. Я знаю, что такие есть в готовом виде, о них написано много материалов. Если понадобятся, возьму готовые. Если задача будет требовать, то погружусь детальнее.
Все зависит от целей. Например, мне в разы интереснее стало погружаться в создание и развитие продуктов. Мне уже не так важно, на каких технологиях это будет сделано — не принципиальный и не первостепенный вопрос, лишь бы создавало ценность. А есть инженеры, которым нравится изучать вопрос детально: раскладывать технологии на винтики, разбирать механики. Супер! Такие люди тоже нужны, без них никуда. Вопрос в том, где они нужны и в каком количестве.
upcFrost
28.05.2024 22:31Спорно, смотря какая вакансия. Вот например для условного перекладывателя жсонов с фронта в базу зачем нужно знать как r‐b tree работает или как сделать in-place сортировку? Не, оно полезно, я не спорю, но это не определяющий фактор. Это все равно что спрашивать у фронта основы сети - да, неплохо бы знать что такое dns и как оно работает, но есть и более важные для него вещи
iosuslov
28.05.2024 22:31+3"что с собеседованиями не так"? - то что каждая контора или средненький тимлид хочет написать статью про собеседования на Хабре.
Уже тыщу раз одно и то же перелопатили - и что изменилось? Ничего. Рынок и нехватка рабочих рук - вот что влияет на процессы найма. Если нужно много работников и быстро - процесс найма будет упрощён. Если собираете сливки с рынка - будете выдумывать хитрые этапы, чтобы купить бриллиант по цене сгущенки.
Все что надо знать соискателю - если тебе не нравится как проходит собес, скорее всего, тебе и работа в конторе не понравится - скипай и ищи дальше. Благо вариантов много.
mrerberg Автор
28.05.2024 22:31Спасибо за комментарий!
В целом, вы правы. Видел не одну статью на эту тематику, но все же решился написать, так как это был внутренний позывхайпануть.
Что касается полезности/бесполезности материала, это вещь субъективная. Не претендовал на смену мирового порядка, но если хотя бы 1 человек вынес для себя что-то новое и увидел альтернативу, которую можно внести в свою практику, то я считаю задачу выполненной.
P.S. Я не тимлид c:
Pardych
28.05.2024 22:31Про JB пример видится жизненным как раз с точки зрения реальной работы.
Какой бы ни был коллектив и налаженные процессы - чаще всего выстраивать разработку приходится по разного уровня ущербности драфтам, которые друг-другу где-то противоречат, где-то копируют, многое умалчивают и главная задача все это систематизировать прежде чем писать код. Наверняка можно было спросить насчет вопросов по заданию и наверняка на них отвечают. А код любой сложности ты должен уметь писать по умолчанию. Не важно умеешь ли ты это на бумажке, или с гуглом/чатгпт в обнимку.
А все сложившиеся приседания с целью выявить надрессированную на справочники по сдк и алгоритмы мартышку это конечно же профанация.
mrerberg Автор
28.05.2024 22:31Спасибо за комментарий!
Вы правы, в настоящей работе часто многое неизвестно, так же присутствует человеческий фактор. Хаос, бюрократия и прочее. И в этих реалиях приходится жить. Что касается тестового задания, то на мой взгляд, это не mind games, это просто халтура. В случае JB она оказалась незначительной, я по большей части придрался к оформлению, а задавать вопросы не было необходимости, так как разобрался с условиями. Я стараюсь задавать вопросы по тестовым в крайних случаях, так как, во-первых, люди работают, а я их буду отвлекать. Во-вторых, переписка чаще всего идет по почте, а это не самый быстрый канал коммуникации, а ручки то чешутся.
everdens
28.05.2024 22:31В идеале бизнес работает в логике: вложен капитал, его необходимо обернуть чтобы получить рост, для этого требуется живой работник, работник должен изготовить достаточный для рынка продукт чтобы тот продать.
Почему тогда бизнес отказывается нанимать работника готового работать? Причин может быть несколько:
1) работников хватает,
2) вклад этого работника на (конкретно) этом предприятии незначительно влияет на продукт,
3) навыков работника не достаточно, чтобы произвести продукт (конкретно) в той бизнес-модели, в которой существует предприятие,
4) (конкретно) этот бизнес - на самом деле не бизнес, и не занимается оборотом капитала,
5) с рынком происходят изменения, что ставит под вопрос производства продукта,
-- наверное список можно продолжить.
Если эти причины правда имеют место и набор работников всё равно происходит, то налицо отрыв целей набора от целей бизнеса.
Вот и получаются ничем неограниченные, свободные творческие поиски методик собеседований.
Какая разница как набирать людей, если сама задача набора людей не ограничена ни сроком, ни целью, ни требованиями качества.
Modin
28.05.2024 22:31+1Мне нравится такой подход к собеседованию. Помню, что где-то на просторах интернета видел собес в Альфу на котором собеседующие спрашивали, что будет если функцию 2 раза привязать к контекстам через bind (запомнил только это, но там было еще много чего интересного)
mrerberg Автор
28.05.2024 22:31Спасибо за комментарий! Да, сам из собеса вынес пару интересных фактов. Это, правда, зависит от собеседующих. Некоторые могут прям подробно рассказать про механики, накидать ссылок почитать. За это таким ребятам респект.
ibessonov
28.05.2024 22:31+1Так а в чëм проблема задач вроде "переворачивания матриц"? Я могу понять неприязнь к более сложным задачам, но эта же совсем элементарна и подвластна любому первокурснику! Кажется авторы таких статей совсем перегибают палку, надо как-то более явно границы обозначать.
mrerberg Автор
28.05.2024 22:31+1Спасибо за комментарий.
Поясню. В конкретном случае я не маркировал задачу на переворот матриц как сложную или легкую. Подметил сам факт наличия данной задачи в списке задач. На мой взгляд, эта задача крайне скучная.
На самом деле в том собеседовании был другой забавный нюанс, который я не обозначил, связанный с этой задачей. Собеседущие постоянно вносили корректировки в условия. И нужно было в конце выдать функцию, которая может переворачивать матрицы n на m с использованием только одного цикла на всю функцию.
CorwinH
28.05.2024 22:31Так а в чëм проблема задач вроде "переворачивания матриц"?
Проблемы начинаются, когда размер матрицы кратен кэшу процессора. :)
kbnrjlvfrfrfrf
28.05.2024 22:31Так а в чëм проблема задач вроде "переворачивания матриц"?
Нет проблем если будущая работа связана с этими матрицами (и линейной алгеброй, видимо). Заодно кандидата проверите, не врёт ли об опыте - резюме вы наверняка выбирали людей с релевантным опытом. Во всех остальных случаях - а зачем, что это покажет?
ibessonov
28.05.2024 22:31Покажет, что человек знает что такое массив :)
Я бы такие задачи отнёс в разряд "отсеять совсем слабых". Углубляться в дополнительные условия - на мой взгляд действительно лишнее, особенно если в реальной работе такого делать не придётсяkbnrjlvfrfrfrf
28.05.2024 22:31Покажет, что человек знает что такое массив
Почему тогда просто взять и не спросить непосредственно про массив?
Я бы такие задачи отнёс в разряд "отсеять совсем слабых".
Совсем слабые определяются довольно просто - как правило это свитчер из гуманитарной профессии, прошедший 3месячные курсы, и искренне полагающий что ща ему 300К насыпят.
Daniel217D
Лучший формат собеседования - это обычный разговор, хотя и со списком тем к обсуждению. Получается проверить хард и софт скиллы и рассказать про компанию в течение часа-двух. В итоге вы с кандидатом понимаете насколько подходите друг другу
Когда проводил первые собесы, они у меня из-за неопытности были в формате допроса и вспоминая их сейчас, понимаю, что это была полная лажа
Плюс тестовое собственной разработки. Когда его делал, главным условием было "3 часа на все пункты". Судя по обратной связи, так и получилось. И ещё по этому тестовому не только даю фидбэк, но и запрашиваю его для допиливания
whoisking
Тоже пришёл к этому, самый лучший собес - разговор. В ходе разговора можно выяснить практически всё, что необходимо, плюс для кандидата это наименее стрессовый вариант, хорошие кандидаты раскрываются просто на ура. Но решил всё же оставить лайвкодинг для кандидатов ниже уровня сеньор, чтобы отсеять явных самозванцев, но без каких-то алгоритмов, а с реальными небольшими практическими задачками. А для всего остального, конечно же, есть испытательный срок.
Притом, простая повседневная задача даёт немало плюсов. Во-первых, мы смотрим актуальные для нас навыки. Во-вторых, в отличие от сложных алгоритмов, задачу решит большинство и можно проверить стиль написания, качество кода, подход к неймингу, размышления, обработку ошибок и тд. А когда часть кандидатов задачу не решает, то всё это увидеть сложно.
SpiderEkb
Аналогично, только без кодинга. Стек специфический, обучать ему будут во время испытательного срока (он же обучение).
Так что просто разговор на равных.
MadeByFather
Кодинг не должен быть на вашем стеке, это абстрактные задачи на любых популярных языках программирования, чтобы убедиться, что кандидат может в принципе написать какой-то цикл или не делает n квадрат там, где это не нужно
killyself
Хотя в реальной практике куда чаще встречаются задачи где можно и даже предпочтительно делать N^2 и даже N^3. Всё зависит от реальной нагрузки, и есть на вход раз в час приходит N = 150 в самом фантастическом сценарии, то наивный алгоритм N^3, написанный за 2 часа, будет лучше чем N logN, на полировку которого ушло 20, и потом это еще невозможно изменить под новые требования. Конечно, речь не идет о совсем базовых алгоритмах.
saboteur_kiev
Задачи технического собеседования - две
1. выяснить что знает кандидат - просто идешь по его резюме и в меру своей компетенции интересуешься что было сделано, как, почему. Беседуете о различных инструментах, библиотеках, как они использовались, кто принимал решение о использовании. Можно для себя полезного почерпнуть много
2. Выяснить подходит ли кандидат на ваш проект. Идешь по своему опроснику, где перечислены и технологии и базовые вопросы, важные для вашего проекта, спрашиваешь. И не ждешь "своего правильного ответа", а слушаешь компетенцию со стороны. Расширяет кругозор. Не обязательно по своему опроснику все вопросы задавать - у кандидата могут быть гэпы в одном и наоборот углубленные знания в другом. Это ты на пункте первом мог уловить. И глубже нужно копать именно там, где кандидат больше знает. Так сказать узнать глубину его кроличьей норы. Это скажет тебе насколько кандидат в принципе умеет копать и разбираться с тем, с чем прямо и долго работал.
Ну а дальше - зависит от тебя, насколько ты сам вообще как человек, разумный, адекватный и умеешь в психологию.
Didimus
Я раньше просил рассказать про свой диплом. Большинство не могли даже тему вспомнить.
Сейчас бы спрашивал из текущих своих задач проблемные ситуации и как их человек будет решать
andmerk93
Потому что только название темы - 2 абзаца. Кто эту чушь вообще запоминает.
Didimus
А в чем разница проекта на работе и диплома?
Metotron0
Я на работе тоже не могу вспомнить, какому заказчику что мы делаем. Каждый раз приходится смотреть, разбираться. Тут шаблоны на ejs, тут на handlebars, тут на pug, тут на чистом html, там есть TypeScript, там нет, там jQuery, там чистый JS. У меня проекты делятся на "тот самый, где картинки по-марсиански прибиты к шапке", "тот, где таблицы за экран вылазят", "тот, где у каждого блока подблоки 6-го уровня вложенности", "тот, где на каждой странице свои стили, потому что делали их отдельно одну от другой, и маленькие синие стрелки".
Didimus
Вот чтобы такого не было, есть люди, обеспечивающие платформенный системный подход. И они помнят все, потому что понимают, зачем и как что надо делать
ManGegenMann
Чушь. Бесполезно. Зачем надо.
Вы зачем в университете учились? Я помню не то что тему, а весь свой диплом наизусть и до сих пор поддерживаю его в актуальном виде, помогает на собеседование пропускать лайв секции заменив на просмотр этого магнум опуса.
Вы поэтому и не понимаете в чем смысл вышки потому что штаны протирали и диплом для глаки сдавали. Учиться надо было.
Didimus
Зато воинствующие невежды не поленились заминусовать. Вот таких людей я сразу отсеивал. Диплом это образец того, как человек работает по задаче
Drucocu
Думаю, вас заминусили не невежды, а просто люди со стажем.
Мой диплом писан уже более 10 лент назад на PHP. При всей моей гордости на тот момент, сейчас он никому не интересен.
kbnrjlvfrfrfrf
Сам ПХП 10 летней давности конечно неинтересен. А диплом как показатель что его обладатель problem solver - очень даже интересен. Я когда на первую работу после ВУЗа устраивался, гендир чисто посмотрел во вкладыш с оценками за курсовые и всякие производственные практики. Вот и весь собес, больше никого ничего не интересовало.
Didimus
Именно так: ты такому-то преподавателю этот предмет сдал? А как сдал? Ну ок, пойдет
Drucocu
Ну мы же не только про первую работу говорим, а про собеседования в целом.
Я как-то уже успел поинтереснее проблем порешать за свою карьеру.