Про рутину и поддержку
Есть любопытные кандидаты в разработчики, которые честно говорят что не любят рутину и поддержку/сопровождение (maintenance).
Да, но интервьюер тоже скорее всего не очень ее любит. Почему? Ну потому что он ведет интервью, как правило это не последний человек в компании и как нормальному непоследнему человеку ему хочется хреначить что-то новое и великое, а не сидеть месяцами на поддержке и бафиксе.
И вот этот непоследний человек слышит, что кандидат говорит следующее: "я приду в эту компанию и буду делать все новое, а ты сам будешь это все фиксить, а я буду делать что-то другое, новое"
Вопрос. Кому нужен такой кандидат? Ответ -- никому.
Вопрос. Как нужно отвечать на этот вопрос? Ответ: я могу делать все и оно все по-своему интересно, но предпочитаю, чтобы доля поддержки и багфиксов была не более 30%.
Вообще, поддержка и сопровождение дают уникальные знания и опыт, касающиеся эксплуатации систем. Они дают понять, что по-настоящему надежный и простой код -- это очень и очень не просто. Они говорят, где код ломается чаще всего, и ты начинаешь обращать на эти места внимание. В итоге, разработчик, который никогда не фиксит или крайне редко фиксит проблемы в системе лишается этого важного источника информации о проекте. И такой разработчик лучше пусть поработает в другой компании :)
Да, но интервьюер тоже скорее всего не очень ее любит. Почему? Ну потому что он ведет интервью, как правило это не последний человек в компании и как нормальному непоследнему человеку ему хочется хреначить что-то новое и великое, а не сидеть месяцами на поддержке и бафиксе.
И вот этот непоследний человек слышит, что кандидат говорит следующее: "я приду в эту компанию и буду делать все новое, а ты сам будешь это все фиксить, а я буду делать что-то другое, новое"
Вопрос. Кому нужен такой кандидат? Ответ -- никому.
Вопрос. Как нужно отвечать на этот вопрос? Ответ: я могу делать все и оно все по-своему интересно, но предпочитаю, чтобы доля поддержки и багфиксов была не более 30%.
Вообще, поддержка и сопровождение дают уникальные знания и опыт, касающиеся эксплуатации систем. Они дают понять, что по-настоящему надежный и простой код -- это очень и очень не просто. Они говорят, где код ломается чаще всего, и ты начинаешь обращать на эти места внимание. В итоге, разработчик, который никогда не фиксит или крайне редко фиксит проблемы в системе лишается этого важного источника информации о проекте. И такой разработчик лучше пусть поработает в другой компании :)