Из-за частых переездов в разных странах потерялась клавиатура с русской раскладкой. Купить было негде (или долго ждать нужно было) и пришлось (захотелось или просто по приколу) запомнить русскую раскладку. С тех пор прошло больше 10 лет, я и не парился больше никогда.
И этот комментарий я пишу без русской раскладки. Так что да, на клавиатуру я не смотрю — бесполезно.
На текущей работе на интервью задали вопрос: «Как ты понимаешь, кто такой full stack developer?» — В процессе обсуждения решили, что это разработчик, имеющий знания и опыт в front-end, back-end, database и devops. Вот так вот, специалист, разбирающийся в 4 сферах. Не мастер во всех 4-х, прошу заметить, а имеющий понимание обо всех 4 сферах. Такой разработчик дизайнит полные решения — от пользователя до сервера и обратно (речь о веб-приложениях).
Согласен про работу в потоке. Когда нет внешних раздражителей, когда задачи понятны и знаешь что делать — работа идет быстро и продуктивно. Но мне не понятно следующее: если убрать у программиста сроки, то по тому же закону Паркинсона, он будет тратить все время на одну задачу. Ведь сроков нет, а значит сроки — все доступное время, то есть пока менеджеру не надоесть видеть постоянно занятого программиста и не видеть результатов.
Вот только недавно прочитал статью на тему, что сроки все-таки нужно ставить. Даже самому себе, иначе будешь все время тратить на одно и тоже, так как спешить некуда.
То есть, нельзя давать сроков, но они все-таки нужны?
Я не писал, что не знаю, как работает сборщик мусора. Я написал, что одна фирма отсеивает множество кандидатов на первом интервью такими вопросами и при этом ни один из собеседовавших меня людей не смог мне внятно привести пример как им это помогло в работе. Я знаю какие у них проекты, и они не маленькие. Качество — уж простите, не проверял.
Я не писал, что не прошёл такое первое интервью. Я просто получал оффер из другой компании раньше, чем эта компания звала меня на следующее интервью, у них очень длительный процесс найма.
Мне приходилось проводить технические интервью, то есть я был по обе стороны в процессе найма на работу. Я готовил вопросы на темы, которые плотно используются в проекте, на который мы искали кандидата. Время интервью ограничено и сроки поиска нового программиста в команду тоже не резиновые. Поэтому лучше уж спрашивать знания того, что конкретно используется в проекте, чем знания о внутреннем устройстве Java, которые при достаточно прямых руках могут и не понадобиться.
Я знаю лично много программистов, которые затрудняются объяснить устройство сборщика мусора, но при этом пишут нормальный код с минимальным количеством проблем. И знаю также программистов, которые идеально расскажут как устроен сборщик мусора и как работает память в Java-приложении, но при этом пишут вот такой код:
class SomeClass {
private String someValuableData = "Most Valuable Information";
/* Getters and Setters are ommitted. */
public void updateData(String newData) {
this.setSomeValuableData(this.getSomeValuableData());
}
}
Пример утрированный конечно, но суть проблемы демонстрирует. Реальный пример из реального проекта.
В Монреале есть одна компания, у которой процесс найма на работу занимает очень продолжительное время. Самый короткий срок от первого собеседования по телефону до контракта, который я знаю, занял 6 недель. Самый длинный — 18 месяцев. Как правило они проводят несколько интервью по телефону и несколько личных встреч. Всегда на первом интервью задают вопросы о том как работает сборщик мусора, как там всё устроено. Ни один из проводивших интервью не смог мне внятно привести примеры из их реальных проектов, когда эти знания помогли или были по-настоящему необходимы.
Я спрашивал нескольких разработчиков, которые работали в этой компании, как им приходилось использовать эти конкретные знания в работе. Самый лучший ответ: «Знание о том, как работает сборщик мусора, нужны чтобы пройти интервью. Больше они не нужны.»
И этот комментарий я пишу без русской раскладки. Так что да, на клавиатуру я не смотрю — бесполезно.
Вот только недавно прочитал статью на тему, что сроки все-таки нужно ставить. Даже самому себе, иначе будешь все время тратить на одно и тоже, так как спешить некуда.
То есть, нельзя давать сроков, но они все-таки нужны?
Я не писал, что не прошёл такое первое интервью. Я просто получал оффер из другой компании раньше, чем эта компания звала меня на следующее интервью, у них очень длительный процесс найма.
Мне приходилось проводить технические интервью, то есть я был по обе стороны в процессе найма на работу. Я готовил вопросы на темы, которые плотно используются в проекте, на который мы искали кандидата. Время интервью ограничено и сроки поиска нового программиста в команду тоже не резиновые. Поэтому лучше уж спрашивать знания того, что конкретно используется в проекте, чем знания о внутреннем устройстве Java, которые при достаточно прямых руках могут и не понадобиться.
Я знаю лично много программистов, которые затрудняются объяснить устройство сборщика мусора, но при этом пишут нормальный код с минимальным количеством проблем. И знаю также программистов, которые идеально расскажут как устроен сборщик мусора и как работает память в Java-приложении, но при этом пишут вот такой код:
Пример утрированный конечно, но суть проблемы демонстрирует. Реальный пример из реального проекта.
Я спрашивал нескольких разработчиков, которые работали в этой компании, как им приходилось использовать эти конкретные знания в работе. Самый лучший ответ: «Знание о том, как работает сборщик мусора, нужны чтобы пройти интервью. Больше они не нужны.»
Когда появится ТаскТрекер, позволяющий настраивать его под свой специфический процесс и по приемлемой цене, вот тогда все на него и перейдут.