Наращивая опыт, нужно не количественно больше трудиться, а качественно. То есть делать то же самое, но лучше, надёжнее, предсказуемее. Если работодатель этого не ценит — нафиг его, а если ценит — у вас будет возможность контролировать количество времени, уделяемого труду. Ну и время на саморазвитие при желании выкроить можно. Или на котиков.
Сложные скрипты внутри задач — зло. И простые кстати тоже. Если к ним отнестись как к полноценному коду, окажется, что они не выгодней сервисных задач на java. А если не отнестись — быть беде.
Я считаю, они годятся для прототипирования разве что. И для тестирования — если жизненный цикл процесса за пределы теста не распространяется.
15 лет оутсорса — борьба с техдолгом только «за свой счет». Где-то в свободное от работы время, где-то сознательно превышал оценки на разработку, чтоб в оставшееся время порефакторить, где-то пытался новичков к этому делу приспособить, покуда от них менеджмент пользы не ждет.
Официально — никаким языком не воспринимают.
Мой предыдущий тимлид был герой.
Широчайшая техническая эрудиция, нереальная трудоспособность «ночь работе не помеха», способность принимать решения за секунды а потом «отвечать за базар» — все это позволило ему протащить проект с пресейла до уверенного полета, и все это в крупном международном банке, без тестировщиков (но с тестами).
Хаос был его стихией, но менеджменту стал важней порядок — и он ушел.
За два года работы с ним я получил больше, чем за предыдущие 8 лет.
Я провожу собеседования только на свой проект, считаю, сложность некоторых реальных задач проекта значительно превышает сложность задач на интервью.
Не Гугл, Фейсбук или Эппл.
Полноценный парсер JSON — боюсь, слишком круто для полутора часов, если в языке нет какой-то специфической поддержки и нельзя использовать сторонние библиотеки. Ну разве что какое-то подмножество покрыть можно.
Не стою, не занимаюсь микроменеджментом, не грожусь уволить (да и не могу).
Но вы немножко передергиваете. Интервью не предполагает увольнения или наказания за «плохой код».
Это встреча двух профессионалов, которые должны решить, хотят ли они работать друг с другом, причем собеседуемый заранее знает, что от него будет требоваться.
Я не знаю, какой у вас стек и ЯП, может, у вас реалии другие. Но в Java джун редко хорошо знает стандартную библиотеку. Он может хорошо зазубрить ответы на стандартные вопросы, но с практическим использованием у него туго, допускает много ошибок, опыта мало. Даже если такой человек умен и схватывает быстро, я не могу его порекомендовать к найму.
Если кандидат на практическом уровне знает Java и JDK, способен реализовать тестовую задачу с многопоточностью, способен понять, какие тесты нужны и написать их — сеньор почти наверняка.
Вот описанная вторая задача — она как раз по существующему коду, ее сеньор за 15 минут решает, если на четверку знаком с языком программирования и имеет
некоторый опыт поддержки реальных приложений.
Было за все время два интересных кандидата — правильно решили задачу на кодинг (с документацией и гуглом), но не смогли решить на ревью. Оказалось — сеньоры, но язвк недавно сменили. Умели тесты писать, принципы многопоточки понимали, но еще плохо знали JDK.
Таким образом, сочетание задач позволяет с приемлемой долей вероятности позволяет отличать новичков в Java, мидлов и джунов от сеньоров.
У вас все разработчики пишут сервисы под вашим пристальным взглядом и на время?
Таки да. Сами при планировании дают оценки, а потом иногда укладываются в них. Непосредственно во время разработки наблюдения нет, зато потом перекрестное code review проходят вообще все, разработчики, лиды, архитектор. Причем люди уже поняли, что тащить сомнительное себе дороже, если нужна ранняя критика — сами придут к коллеге и попросят взглянуть.
А вообще есть только один способ узнать, может ли человек работать — это нанять его и поработать с ним вместе относительно длительное время.
Менеджмент к такому не готов, потому что на большом и сложном проекте человек за испытательный срок не выходит на полную мощность, а после — его уже просто так не уволить.
Так что приходится идти на компромиссы.
Модель "уличного музыканта" вполне рабочая, хоть и с оговорками.
Некоторые из персон, которым я доначу на соответствующих сервисах, имеют суммарный доход от тысячи долларов США.
Если б в мои 15 - 25 лет так было можно, я б может и в IT не подался бы никогда, может даже и в универ не стал поступать.
Хороший код отличается от плохого тем, что решает больше проблем, чем создает. ) Не пишите плохой код.
Отличие в уровне ответственности, которую персонаж успешно вывозит.
Можешь принять задачу в бизнес-терминах и сделать ее без контроля со стороны старших коллег - сениор.
Моя любимая: "Чушь: гид вёз кэб цапф, юный жмот съел хрящ."
А если добавить диодов?
Наращивая опыт, нужно не количественно больше трудиться, а качественно. То есть делать то же самое, но лучше, надёжнее, предсказуемее. Если работодатель этого не ценит — нафиг его, а если ценит — у вас будет возможность контролировать количество времени, уделяемого труду. Ну и время на саморазвитие при желании выкроить можно. Или на котиков.
Сложные скрипты внутри задач — зло. И простые кстати тоже. Если к ним отнестись как к полноценному коду, окажется, что они не выгодней сервисных задач на java. А если не отнестись — быть беде.
Я считаю, они годятся для прототипирования разве что. И для тестирования — если жизненный цикл процесса за пределы теста не распространяется.
Официально — никаким языком не воспринимают.
Периодически повторяющиеся «средние» косяки должны заставить задуматься и о разрабе, и о процессе.
Мой предыдущий тимлид был герой.
Широчайшая техническая эрудиция, нереальная трудоспособность «ночь работе не помеха», способность принимать решения за секунды а потом «отвечать за базар» — все это позволило ему протащить проект с пресейла до уверенного полета, и все это в крупном международном банке, без тестировщиков (но с тестами).
Хаос был его стихией, но менеджменту стал важней порядок — и он ушел.
За два года работы с ним я получил больше, чем за предыдущие 8 лет.
Не Гугл, Фейсбук или Эппл.
А средняя зарплата — это какая, по вашему мнению?
Но вы немножко передергиваете. Интервью не предполагает увольнения или наказания за «плохой код».
Это встреча двух профессионалов, которые должны решить, хотят ли они работать друг с другом, причем собеседуемый заранее знает, что от него будет требоваться.
Если кандидат на практическом уровне знает Java и JDK, способен реализовать тестовую задачу с многопоточностью, способен понять, какие тесты нужны и написать их — сеньор почти наверняка.
Вот описанная вторая задача — она как раз по существующему коду, ее сеньор за 15 минут решает, если на четверку знаком с языком программирования и имеет
некоторый опыт поддержки реальных приложений.
Было за все время два интересных кандидата — правильно решили задачу на кодинг (с документацией и гуглом), но не смогли решить на ревью. Оказалось — сеньоры, но язвк недавно сменили. Умели тесты писать, принципы многопоточки понимали, но еще плохо знали JDK.
Таким образом, сочетание задач позволяет с приемлемой долей вероятности позволяет отличать новичков в Java, мидлов и джунов от сеньоров.
иногдаукладываются в них. Непосредственно во время разработки наблюдения нет, зато потом перекрестное code review проходят вообще все, разработчики, лиды, архитектор. Причем люди уже поняли, что тащить сомнительное себе дороже, если нужна ранняя критика — сами придут к коллеге и попросят взглянуть.А вообще есть только один способ узнать, может ли человек работать — это нанять его и поработать с ним вместе относительно длительное время.
Менеджмент к такому не готов, потому что на большом и сложном проекте человек за испытательный срок не выходит на полную мощность, а после — его уже просто так не уволить.
Так что приходится идти на компромиссы.