Резюме — это, так сказать, рекламная листовка для профессионала. Резюме, из которого не видно, почему именно этот кандидат мне подходит, проскальзывает мимо и сливается с сотней других. Резюме, в котором выделено именно то, что мне нужно в кандидате, привлекает и запоминается: «О! Похоже, именно то, что мне нужно!»
Но никто не заставляет подстраивать резюме. Это просто элемент искусства продать себя. Нужно четко осознавать, что на первом этапе конкурируют не Ваши технические навыки, а Ваш имидж. И если Вы проигрывете на этом этапе, то, как бы хороши Вы ни были, до второго этапа, когда будут оценивать Ваш ум, дело просто не дойдёт.
Это в интересах соискателя — принести запасное резюме. У меня несколько раз было, что из-за накладок у интервьюера не было моего резюме. Если бы у меня не оказалось запасной копии, то интервьюер мог бы просто не запомнить меня, да и сама беседа протекала бы по-другому.
Я в последнее время ВСЕГДА прошу кандидатов написать кусок простенького кода. Ничего сложного или заумного: проверить, является ли строка палиндромом; посчитать N-ное число Фибоначчи; да хоть пресловутый FizzBuzz, наконец! Я не придираюсь к синтаксису — меня не волнует случайно пропущенная точка с запятой. Меня не волнуют детали API — не страшно, если человек забыл, как получить длину строки. Меня интересует другое: может ли кандидат осознать преобразовать простейший алгоритм и преобразовать его в программу. То есть, умеет ли о (или она) собственно программировать?
В моей практике примерно 70% кандидатов были неспособны это сделать. О, они блистали техническими познаниями, отвечали на заковыристые вопросы, были милы и общительны, демонстрировали широту эрудиции и кругозора… Но вот программировать они не могли.
Есть такой интересный тезис: хороших специалистов трудно найти потому, что их просто нет на рынке. Классный профессионал на рынке может оказаться только случайно, в результате, скажем, неожиданного сокращения. В основном эти люди переходят с места на место напрямую. Да и оказавшись на рынке, такой человек находится там весьма недолго, ибо нужен людям.
Слабые же работники, наоборот, находятся на рынке часто и подолгу. Их чаще увольняют, их хуже берут. И в результате мы получаем нынешнюю ситуацию: на сто резюме может быть будет один-два действительно достойных кандидата, ещё человек 7-8 приличных, а остальное — увы-увы…
Конечно, согласен, кто ж спорит. И хорошо, если автомобиль мигает по этому поводу лампочкой на панели, пищит, напоминает. Но ездить он всё равно должен.
Это попытка предотвратить нехорошие поледствия чужих ошибок. Да, это так. Но если Вы посмотрите вокруг, то Вы увидите что так построено огромное количество вещей, которые нас окружают. Лифт откроет обратно двери, если кто-то сунул в последний момент внутрь руку; кофемолка не запустится с незакрытой крышкой; предохранитель сработает, если воткнуть в розетку обогреватель на 20 киловатт… Так что ничего странного или необычного в этом нет.
Если программа не может корректно сделать то, что должна, она, безусловно, не должна делать это некорректно. Но если программа может продолжить функционирование с уменьшенным функционалом, то, скорее всего, она должна это сделать.
В конце концов, мы не стали бы пользоваться, скажем, автомобилем, который отказывается ехать оттого, что у него перегорела одна фара.
Отключение их поможет плохо — пул соединений может в тестовых условиях и не истощиться. Гораздо лучше на тестовом сервере из финализатора, если там есть незакрытое соединение, просто ронять программу. С этим я на сто процентов согласен.
Ну, в данном случае это скорее не долг, а кредит. Возможность оплатить счёт позже, когда будут деньги :)
Кстати, аналогия на самом деле неплохая: при злоупотреблении такой политикой возможно техническое банкротство. Однако при разумном использовании всё получается очень хорошо. Мы, например, периодически проводили такие релизы с «раздачей долгов», стараясь назначить их на спокойное время.
Я в ветке выше привёл пару иллюстраций того, почему это далеко не всегда так… Для полноты картины поясню, что описываемые ситуации происходили в крупной финансовой компании. Стоимость того, что система упала и не смогла в нужное время выполнить требуемую операцию, там может быть высока. ОЧЕНЬ высока.
Стоимость того, что из-за течи замедляется работа сервера и его, пока не починили, время от времени нужно перезапустить — ничтожна. Стоимость неполного отчёта может тоже быть велика, но она меркнет на фоне стоимости застрявшей ночной обработки данных.
Я с этим утверждением полностью согласен. Именно поэтому я придерживаюсь философии «Let it crash» — это позволяет узнать о проблеме намного раньше. Не работающий код должен кричать об этом во все горло, а не «тихо неправильно работать».
С точки зрения бизнеса такая позиция далеко не всегда оправдана. Ошибки бывают разные. Понятно, что если код, к примеру, тихой сапой портит базу данных, то это никуда не годится. Но вот другой пример (тоже из личной практики): код должен прочитать файл с кучей записей транзакций, провести некие действия и выдать отчёт. В результате некоей неразберихи в какой-то момент на вход пошли файлы, в которых дата была не в том формате. Если бы программа свалилась, мы получили бы возмущённое начальство, бессонную ночь или две, а также всякие корпоративно-политические неприятности. Но программа была написана так, что она не упала, а написала подробный отчёт об ошибках, отправила его по почте, а сама вместо даты взяла текущую. Пользователи посмотрели с утра (программа ночью работала) и сказали: «Ну и ничего страшного. Вот у таких и таких транзакций поменяйте дату на вчерашнюю, а так всё нормально». Днём мы спокойно поправили формат и вопрос был закрыт.
А с логами у меня было так: все ошибки из логов автоматически присылались по почте всеё команде, и непременно разбирались. Так что если бы та библиотека, которой мы пользовались, продиагностировала течь и сообщила об этом, мы бы непременно эту ошибку внесли в план исправлений, и исправили бы достаточно скоро.
Я всегда стараюсь писать код, который будет работать — хоть как-то — даже если его используют неправильно. В конце концов, задача ведь — сделать, чтоб работало, и позиция «Прокукарекал — а там хоть не рассветай» не очень конструктивна.
Конечно, если код видит, что что-то идёт не так, он должен сообщить об этом. Ну, скажем, сказать" конфигурация не найдена — использую значения по умолчанию". Поэтому в моём примере финализатор, если он обнаружит незакрытое соединение, попробует ещё и записать в лог.
Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват. В моём же примере неправильная работа кода приводит к утечке ресурса, а это ошибка гадкая, трудноуловимая, и на продакшене может попортить немало крови.У меня в своё время был именно такой случай — из-за изменения в логике вкралась ошибка, и иногда управление не попадало на тот кусок, который закрывал соединение с базой. В результате начались падения программы из-за того, что закончились соединения. Происходило это не всегда, в совершенно ином куске программы, и нам потребовалось немало времени на то, чтобы поймать ошибку.
Единственный смысл finalize, который я знаю — последняя линия обороны против чужих ошибок. К примеру, я создаю класс, который использует соединение с каким-то внешним ресурсом (ну, скажем, с базой данных). Предполагается, что использоваться он будет примерно так:
MyClass c = new MyClass();
c.openConnection();
c.doSomething();
c.doSomethingElse();
…
c.doOneMoreThing();
c.closeConnection();
Я не могу гарантировать, что тот, кто будет пользоваться классом, не забудет закрыть соединение. Поэтому, на самый крайний случай, я могу добавить закрытие соединения в finalize в своем классе.
Но никто не заставляет подстраивать резюме. Это просто элемент искусства продать себя. Нужно четко осознавать, что на первом этапе конкурируют не Ваши технические навыки, а Ваш имидж. И если Вы проигрывете на этом этапе, то, как бы хороши Вы ни были, до второго этапа, когда будут оценивать Ваш ум, дело просто не дойдёт.
Встречают-то по одёжке… :)
Интересное у Вас представление о тим лидах… :)
В моей практике примерно 70% кандидатов были неспособны это сделать. О, они блистали техническими познаниями, отвечали на заковыристые вопросы, были милы и общительны, демонстрировали широту эрудиции и кругозора… Но вот программировать они не могли.
У меня когда я ищу работу как правило есть 2-3 базовых варианта резюме; я выбираю для отправки наиболее близкий вариант и частенько подкручиваю его.
Слабые же работники, наоборот, находятся на рынке часто и подолгу. Их чаще увольняют, их хуже берут. И в результате мы получаем нынешнюю ситуацию: на сто резюме может быть будет один-два действительно достойных кандидата, ещё человек 7-8 приличных, а остальное — увы-увы…
Если программа не может корректно сделать то, что должна, она, безусловно, не должна делать это некорректно. Но если программа может продолжить функционирование с уменьшенным функционалом, то, скорее всего, она должна это сделать.
В конце концов, мы не стали бы пользоваться, скажем, автомобилем, который отказывается ехать оттого, что у него перегорела одна фара.
Кстати, аналогия на самом деле неплохая: при злоупотреблении такой политикой возможно техническое банкротство. Однако при разумном использовании всё получается очень хорошо. Мы, например, периодически проводили такие релизы с «раздачей долгов», стараясь назначить их на спокойное время.
Стоимость того, что из-за течи замедляется работа сервера и его, пока не починили, время от времени нужно перезапустить — ничтожна. Стоимость неполного отчёта может тоже быть велика, но она меркнет на фоне стоимости застрявшей ночной обработки данных.
С точки зрения бизнеса такая позиция далеко не всегда оправдана. Ошибки бывают разные. Понятно, что если код, к примеру, тихой сапой портит базу данных, то это никуда не годится. Но вот другой пример (тоже из личной практики): код должен прочитать файл с кучей записей транзакций, провести некие действия и выдать отчёт. В результате некоей неразберихи в какой-то момент на вход пошли файлы, в которых дата была не в том формате. Если бы программа свалилась, мы получили бы возмущённое начальство, бессонную ночь или две, а также всякие корпоративно-политические неприятности. Но программа была написана так, что она не упала, а написала подробный отчёт об ошибках, отправила его по почте, а сама вместо даты взяла текущую. Пользователи посмотрели с утра (программа ночью работала) и сказали: «Ну и ничего страшного. Вот у таких и таких транзакций поменяйте дату на вчерашнюю, а так всё нормально». Днём мы спокойно поправили формат и вопрос был закрыт.
А с логами у меня было так: все ошибки из логов автоматически присылались по почте всеё команде, и непременно разбирались. Так что если бы та библиотека, которой мы пользовались, продиагностировала течь и сообщила об этом, мы бы непременно эту ошибку внесли в план исправлений, и исправили бы достаточно скоро.
Конечно, если код видит, что что-то идёт не так, он должен сообщить об этом. Ну, скажем, сказать" конфигурация не найдена — использую значения по умолчанию". Поэтому в моём примере финализатор, если он обнаружит незакрытое соединение, попробует ещё и записать в лог.
Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват. В моём же примере неправильная работа кода приводит к утечке ресурса, а это ошибка гадкая, трудноуловимая, и на продакшене может попортить немало крови.У меня в своё время был именно такой случай — из-за изменения в логике вкралась ошибка, и иногда управление не попадало на тот кусок, который закрывал соединение с базой. В результате начались падения программы из-за того, что закончились соединения. Происходило это не всегда, в совершенно ином куске программы, и нам потребовалось немало времени на то, чтобы поймать ошибку.
MyClass c = new MyClass();
c.openConnection();
c.doSomething();
c.doSomethingElse();
…
c.doOneMoreThing();
c.closeConnection();
Я не могу гарантировать, что тот, кто будет пользоваться классом, не забудет закрыть соединение. Поэтому, на самый крайний случай, я могу добавить закрытие соединения в finalize в своем классе.