Если сотрудник уходит сам, я прошу у него честный и развёрнутый фидбэк о своей работе как лида. Ведь мы все помним поговорку: «приходят в компанию, а уходят от руководителя».
И вы действительно уверены, что сотрудник будет честен на 100%? Это как при расставании двух людей спрашивать «в чём дело» и услышать «дело не в тебе, а во мне». Навряд ли у сотрудника будет желание обсуждать острые углы.
Если я увольняю сотрудника, то это тоже не является сюрпризом для него: за месяцы до увольнения я даю корректирующую обратную связь и обозначаю ожидания по улучшению.
Давайте поразмышляет. Выше вы писали про «получить обратную связь»
Я предпочитаю собирать рекомендации сам. На собеседовании я узнаю, как зовут руководителей кандидата на прошлых местах работы и беру их контакты.
Как вы отнесётесь к тому, что соискателя уволили на прошлом месте работы? Скорее всего вы не захотите нанимать его. Никто не захочет озвучивать данную тему тем более давать какие-то контакты руководителей с прошлого места работы, учитывая что расстались «на ножах». Не получится ли так, что из-за увольнения у бывшего сотрудника закрывается сама возможность трудоустройства?
Excel не входит в стек используемых технологий разработки ПО, по крайней мере не этого блога. Базы данных входят в стек и поэтому да должен. Если программист пишет SQL — запрос то интересоваться, что выводит explain и как долго исполняется запрос, какие индексы задействованы, его обязанность.
Пайтон — это высокоуровневый язык, он специально создавался чтобы не думать о том что там творится под капотом на уровне OS
человек, который ограничивает свои знания такими заявлениями ограничивает себя и в профессиональном росте. Плох тот Junior, который не хочет стать Senior. Вы от Senior тоже такого ответа будете ждать?
Вы даёте ссылку на статью про CHM с Java8 где не больше объяснений чем у вас, умещающееся в предложение «вместо деления на сегменты в java 8 массив бакетов представляет собой единый массив». ИМХО: слабова-то для разбора такой важной коллекции.
В остальном, подбор информации хороший, хоть и чуствуется желание выдать всю информацию за раз, что излишне. Можно было разделить на большее количество отдельных статей.
Изменил на: «выполнить интеграционные тесты если они являются частью вашего проекта». Так же дополнил описание в статье:
Интеграционные тесты могут быть или частью вашего проекта, или вынесены в отдельный проект, или оба варианта вместе. В первом варианте вы работаете с локально поднятыми службами (message queue, database) + используете HTTP Mocks, эмитируя ответы сторонних сервисов. Во втором варианте вы проверяете работу вашего сервиса и его взаимодействие с другими сервисами в окружениях QA/Stage.
Конечно я предложу свой вариант, а ещё объясню, что прочитав такое название понять «что делает тест и зачем он это делает» гораздо быстрее чем тратить время на переходы в основной код. Это помогает не тратить время в будущем, угадывая мысль автора каждый раз.
Вы как будто с самим собой поспорили и с самим собой согласились =)
Регламенты и документация это как правильно про решение «делаем» и меньше всего про ответы на вопросы «зачем» и «почему» именно так делаем. Вы как будто не встречались с людьми когда говорите про одно и тоже, но у каждого свой взгляд. Как результат вы друг друга не понимаете и снова и снова возвращаетесь к одному и тому же вопросу:
(PR: code review)
— «Нужно исправить и написать нормальное название метода»
— «Оно и так нормальное»
— «testFileSerializer это ненормальное название»
— «А какое нормальное? Вроде бы ок, меня устраивает. Мы же сериализатор файла протестировали там»
… (немая сцена и занавес)…
Как объяснить свой взгляд другому человеку? Добавить чуть больше воды, объяснений, привести пример с вымышленным сотрудником… Так статья и получилась.
Например я получил опыт такой работы и он тоже интересный. Как минимум я могу дать ответы на вопросы, а не теоритизировать «почему так надо» или «почему так не надо». Что плохого-то? =) Ни-че-го.
в коде app-net
Для этого необязательно писать статью, которая не приносит ничего нового и полезного. Изложение материала ужасное.
И вы действительно уверены, что сотрудник будет честен на 100%? Это как при расставании двух людей спрашивать «в чём дело» и услышать «дело не в тебе, а во мне». Навряд ли у сотрудника будет желание обсуждать острые углы.
Давайте поразмышляет. Выше вы писали про «получить обратную связь»
Как вы отнесётесь к тому, что соискателя уволили на прошлом месте работы? Скорее всего вы не захотите нанимать его. Никто не захочет озвучивать данную тему тем более давать какие-то контакты руководителей с прошлого места работы, учитывая что расстались «на ножах». Не получится ли так, что из-за увольнения у бывшего сотрудника закрывается сама возможность трудоустройства?
Что вы мне хотите донести: что программист с БД не умеет работать? Увольте, в таком диалоге я не буду участвовать
человек, который ограничивает свои знания такими заявлениями ограничивает себя и в профессиональном росте. Плох тот Junior, который не хочет стать Senior. Вы от Senior тоже такого ответа будете ждать?
В остальном, подбор информации хороший, хоть и чуствуется желание выдать всю информацию за раз, что излишне. Можно было разделить на большее количество отдельных статей.
я не хотел увеличивать словами текст статьи, всё-таки фокус на тестах.
Регламенты и документация это как правильно про решение «делаем» и меньше всего про ответы на вопросы «зачем» и «почему» именно так делаем. Вы как будто не встречались с людьми когда говорите про одно и тоже, но у каждого свой взгляд. Как результат вы друг друга не понимаете и снова и снова возвращаетесь к одному и тому же вопросу:
(PR: code review)
— «Нужно исправить и написать нормальное название метода»
— «Оно и так нормальное»
— «testFileSerializer это ненормальное название»
— «А какое нормальное? Вроде бы ок, меня устраивает. Мы же сериализатор файла протестировали там»
… (немая сцена и занавес)…
Как объяснить свой взгляд другому человеку? Добавить чуть больше воды, объяснений, привести пример с вымышленным сотрудником… Так статья и получилась.
и вы вставляете такой текст с названиями методов 'filterByDateCreated', 'filterByCategory'. Это плохие имена методов.
Глагол 'filter' не отвечает на вопросы «кто» и «что тестируется». Прибавка «ByDateCreated» не даёт мне нужной информации.