Работа работе рознь. Вам платят за устойчивость к стрессам. Кто-то (я в том числе) предпочитает получать деньги за квалифицированное решение задач бизнеса в комфортных условиях.
За свою многолетнюю карьеру (пара стран + несколько предприятий) я такого сравнения не встречал.
А у меня наоборот. Тоже много лет опыта, несколько стран (> двух), несколько компаний, разные сферы бизнеса и т.д. и т.п… Везде работа была комфортной и не стрессовой, хоть иногда и весьма интеллектуально сложной.
Бывает. Не стоит расстраиваться. Но считаю, что вы сделали неправильный вывод из ситуации:
теперь, пока за мной не будет стоять мой код, на собес я не пойду
Такой подход очень сильно ограничивает вас.
На мой взгляд правильный вывод должен быть другой. Да, собеседование зачастую — это дурацкая игра. Поэтому и готовиться надо как к игре. За неделю до собеседование погуглите «top c# interview questions» (или какие другие технологии вы используете). Зазубрите ответы на бессмысленные вопросы, типа, сколько поколений в сборщике мусора, список из 10 отличий структуры от класса, расшифровки аббревиатур (SOLID, например), 3 главных слова про ООП, разновидности полиморфизма и т.д. Это никак не изменит ваши реальные качества как разработчика, только в глазах собеседующего. Разве что где ещё сможете блеснуть фразой: «это же ad hoc полиморфизм/утиная типизация!».
И ещё интересный момент на собеседованиях — это задачки. Иногда знакомые рассказывают, какие задачки они задают зачастую в весьма посредственные компании. Я в них довольно неплох, но понимаю, что с нуля за час даже в спокойной обстановке дома решение не осилю. Знакомые утверждают, что таким образом они проверяют умение мыслить. Но почему-то не понимают, что лучше всего умение мыслить продемонстрирует человек, который уже эту задачку заранее знает. Поэтому на собеседовании надо играть. Даже если вы знаете ответ и решение, сделайте вид, что усиленно думаете, задавайте больше уточняющих вопросов, спрашивайте, что лучше оптимизировать (использование памяти или сложность, а может и размер кода).
И ещё. Не навешивайте ярлыки сразу. А в конце собеседования, если ярлык всё-таки прилип, осознайте, что с пафосными напыщенными идиотами лучше не работать. К счастью рынок труда сейчас это позволяет.
По-моему, что-то здесь не так. Среднедушевой доход — это же не зарплата, как я понимаю. Это могут быть и пенсии, например. А может и вообще считаться как весь доход делённый на всех жителей (т.е. включая детей). Нужно описание методики.
Где-то полгода назад тоже заинтересовался, чему равна мода (самая распространённая) зарплата в России. Сделал это натягиванием данных росстата на распределение Burr. Ничего лучшего для моделирования распределения зарплат не придумал. Получилось примерно также, в районе 17 тысяч рублей в месяц. Если правильно помню. Само распределение тоже выглядит довольно интересно и печально. Даже хотел на Хабр статью написать, но понял, что у меня нет никаких сильных аргументов за то, что мой подход правильный))
Это очень хорошо. Если высшее образование было реально хорошим и пошло на пользу, то его обладатель на собеседовании это конкурентное преимущество сможет продемонстрировать без упоминания корочек. А если не сможет, то зачем компании отдавать ему предпочтение?
Нельзя так делать, не смотреть на оси графика при его анализе.
Здесь другая ситуация. Не читатель делает анализ. Анализ делал автор статьи, сделал какие-то выводы, теперь рассказывает нам о них, подкрепляя статистикой. Но сейчас это подкрепление похоже на манипуляцию. Зависимость вроде как есть, но мы ничего не знаем про этот параметр, не знаем, в каких рамках он колеблется и как считается. Насколько плохо падение этого параметра на 0.05 чего-то там?
В зависимости от задачи — или нельзя или можно и нужно. В финансовых графиках, где колебания доли процента, именно так и делается (никому не интересно рассматривать абсолютно равные графики из-за дискретности экрана и не100%ного зрения).
Да, но в финансовых графиках не используют столбцовые диаграммы. Там используют либо свечки, либо линии. Столбцевые диаграммы нужны для визуализации сравнения абсолютных значений. Для визуализации изменений используют другие инструменты.
1. К сорока годам вы ДОЛЖНЫ уйти из него или стать владельцем его части. Тут не получиться, как адвокату или хирургу наращивать репутацию и мастерство до наступления альцгеймера.
На мой взгляд слишком сильное утверждение. С одной стороны согласен, абсолютное большинство разработчиков доходят почти до потолка своего профессионализма лет за 10-15. Дальше в лучшем случае идёт небольшое шлифование и изучение новых технологий взамен устаревшим. Но с другой стороны, в абсолютном большинстве работ точно такая же ситуация или даже значительно хуже. Кассир с годом опыта работы ничем не отличается от кассира с 5 годами опыта, а старший кассир (условно) отличается от рядового только наличием ключика для открытия кассы. Но в отличие от других профессий, даже без профессионального роста программист может иметь интересную работу и зарплату на уровне топ 5% по России.
А так конечно хорошо быть эльфом в стране эльфов и всегда писать идеальный код, но задач много, времени мало и иногда чуток говнокода, здоровый цинизм и юнит-тесты позволяют сворачивать горы гораздо меньшими усилиями.
В данном случае можно было бы потратить столько же времени и написать более читаемый код, который было бы гораздо проще и приятнее покрывать тестами. И автор совершенно правильно делает, что хочет научиться делать лучше, вынося свой код на ревью общественности. Не у каждого смелости хватит.
Здесь проблема не в тестировании и тестируемости. Хотя и в этом тоже, так как для того, чтобы протестировать такую смесь UI, бизнес-правил и состояния окружения, надо написать кучу моков, выделить кучу интерфейсов и т.д. И получится вместо одного непонятного метода куча непонятных методов и классов.
Проблема в читаемости. Код пишется один раз, правится несколько раз, а читается иногда десятки и сотни раз. Прочитать написанное очень сложно: приходится постоянно прыгать в начало или конец метода, приходится постоянно проверять, что означают непонятные переменные, а также прослеживать все цепочки до конца кода. Возьмём, например, строку: «Actions userChoise = (A & D)? askUserForAction(event): null;». По каким причинам userAction может стать null? Потому что не (A & D). А что такое A? А что такое D? Возвращаемся в самое начало, чтобы выяснить. А может ли метод askUserForAction вернуть null, при том что (A &D)? Лезем смотреть реализацию askUserForAction. А если userAction реально станет null? Случится ли что-нибудь плохое? Надо проследить всё до самого конца, разобраться в каждой проверке, чтобы понять, что ничего страшного не произойдёт, хотя можно было бы сразу выйти.
Перед тем, как менять названия переменных и наводить красоту, было бы хорошо поработать над тем, чтобы отделить UI от логики. В функции сначала вычисляются предикаты, а потом 1 или 2 раза запрашиваются действия пользователя: askUserForAction(event) и askUserWantToRewrite(). Пользователь может не отвечать довольно долго. За то время, пока он решит ответить, ситуация в окружении может измениться значительно: может закончиться место, кто-нибудь другой может добавить файл с таким же названием в директорию назначения, директория назначения может быть вообще удалена. Да и как-то это неправильно смешивать бизнес-правила с сценарием UI.
Вы дошли уже до того что реальные пользователи снимают фото?
Да, мы работаем именно с фотографиями мерчандайзеров (они и так делают снимки каждого стеллажа для отчётов и отсылают своим менеджерам), так что им даже не надо специально что-то фотографировать для нас.
Вообще, успехов, вам конечно. Но рынок этот очень странный. Вроде их всех 4-5 компаний которые я знаю в какой-то плюс сейчас одна всего смогла выйти.
У нас немного проще ситуация. Мы и так делаем решение для заказчика, просто добавляем ещё одну фичу. С точки зрения бизнес-процесса, никому не надо делать дополнительной работы (мерчандайзеры и так ездят по торговым точкам, и так фотографируют, и так отправляют фотографии), а мы просто аккуратно встраиваем распознавание в эту цепочку.
Буквально позавчера уже была статья про похожую задачу, писал там комментарий. В принципе, у вас он почти такой же :)
Читал и статью и комментарий. Согласен полностью. Поставил бы +, но кармы не было :).
Нельзя решать задачу поиска товаров в магазинах переходя к задаче «поиск пачек сигарет». Как только ваша задача станет более общей, когда у вас появятся стиральные порошки, молочка, планограммы с товарами прикрепленными к стойкам — ваши методы перестанут работать.
К счастью, мы не решаем общую задачу поиска всех товаров на всех прилавках. Сейчас мы делаем решение для определённой группы товаров на довольно стандартизированных стеллажах в границах одной страны. С детектированием проблем практически нет. В статье тоже рассматриваем частный случай.
Про то как вы классификацию выхода делаете — вообще промолчу. 10 классов с точностью 92% это очень плохо.
Опять же, про 92% согласен. Но в данных, которые мы использовали для статьи, у нас на 10 классов меньше 2000 примеров, для некоторых классов примеров для тренировки в районе 50, а для проверки в районе 10. Цель статьи была не добиться максимально возможного результата на этом скудном объёме данных (доверия к цифре всё равно не было бы), но показать, что точность, для которой раньше приходилось реализовывать каскад алгоритмов, сейчас достигается использованием примера из Keras без усилий.
А у меня наоборот. Тоже много лет опыта, несколько стран (> двух), несколько компаний, разные сферы бизнеса и т.д. и т.п… Везде работа была комфортной и не стрессовой, хоть иногда и весьма интеллектуально сложной.
Такой подход очень сильно ограничивает вас.
На мой взгляд правильный вывод должен быть другой. Да, собеседование зачастую — это дурацкая игра. Поэтому и готовиться надо как к игре. За неделю до собеседование погуглите «top c# interview questions» (или какие другие технологии вы используете). Зазубрите ответы на бессмысленные вопросы, типа, сколько поколений в сборщике мусора, список из 10 отличий структуры от класса, расшифровки аббревиатур (SOLID, например), 3 главных слова про ООП, разновидности полиморфизма и т.д. Это никак не изменит ваши реальные качества как разработчика, только в глазах собеседующего. Разве что где ещё сможете блеснуть фразой: «это же ad hoc полиморфизм/утиная типизация!».
И ещё интересный момент на собеседованиях — это задачки. Иногда знакомые рассказывают, какие задачки они задают зачастую в весьма посредственные компании. Я в них довольно неплох, но понимаю, что с нуля за час даже в спокойной обстановке дома решение не осилю. Знакомые утверждают, что таким образом они проверяют умение мыслить. Но почему-то не понимают, что лучше всего умение мыслить продемонстрирует человек, который уже эту задачку заранее знает. Поэтому на собеседовании надо играть. Даже если вы знаете ответ и решение, сделайте вид, что усиленно думаете, задавайте больше уточняющих вопросов, спрашивайте, что лучше оптимизировать (использование памяти или сложность, а может и размер кода).
И ещё. Не навешивайте ярлыки сразу. А в конце собеседования, если ярлык всё-таки прилип, осознайте, что с пафосными напыщенными идиотами лучше не работать. К счастью рынок труда сейчас это позволяет.
Зачем ждать? Можно порешать задачи предыдущих соревнований. Раньше иногда участвовал, соревнования реально затягивают. Но времени для хорошего результата надо очень много тратить www.codingame.com/profile/9566133fdfe7b48c719829a19302be237492341
Здесь другая ситуация. Не читатель делает анализ. Анализ делал автор статьи, сделал какие-то выводы, теперь рассказывает нам о них, подкрепляя статистикой. Но сейчас это подкрепление похоже на манипуляцию. Зависимость вроде как есть, но мы ничего не знаем про этот параметр, не знаем, в каких рамках он колеблется и как считается. Насколько плохо падение этого параметра на 0.05 чего-то там?
Да, но в финансовых графиках не используют столбцовые диаграммы. Там используют либо свечки, либо линии. Столбцевые диаграммы нужны для визуализации сравнения абсолютных значений. Для визуализации изменений используют другие инструменты.
На мой взгляд слишком сильное утверждение. С одной стороны согласен, абсолютное большинство разработчиков доходят почти до потолка своего профессионализма лет за 10-15. Дальше в лучшем случае идёт небольшое шлифование и изучение новых технологий взамен устаревшим. Но с другой стороны, в абсолютном большинстве работ точно такая же ситуация или даже значительно хуже. Кассир с годом опыта работы ничем не отличается от кассира с 5 годами опыта, а старший кассир (условно) отличается от рядового только наличием ключика для открытия кассы. Но в отличие от других профессий, даже без профессионального роста программист может иметь интересную работу и зарплату на уровне топ 5% по России.
В данном случае можно было бы потратить столько же времени и написать более читаемый код, который было бы гораздо проще и приятнее покрывать тестами. И автор совершенно правильно делает, что хочет научиться делать лучше, вынося свой код на ревью общественности. Не у каждого смелости хватит.
Проблема в читаемости. Код пишется один раз, правится несколько раз, а читается иногда десятки и сотни раз. Прочитать написанное очень сложно: приходится постоянно прыгать в начало или конец метода, приходится постоянно проверять, что означают непонятные переменные, а также прослеживать все цепочки до конца кода. Возьмём, например, строку: «Actions userChoise = (A & D)? askUserForAction(event): null;». По каким причинам userAction может стать null? Потому что не (A & D). А что такое A? А что такое D? Возвращаемся в самое начало, чтобы выяснить. А может ли метод askUserForAction вернуть null, при том что (A &D)? Лезем смотреть реализацию askUserForAction. А если userAction реально станет null? Случится ли что-нибудь плохое? Надо проследить всё до самого конца, разобраться в каждой проверке, чтобы понять, что ничего страшного не произойдёт, хотя можно было бы сразу выйти.
Да, мы работаем именно с фотографиями мерчандайзеров (они и так делают снимки каждого стеллажа для отчётов и отсылают своим менеджерам), так что им даже не надо специально что-то фотографировать для нас.
У нас немного проще ситуация. Мы и так делаем решение для заказчика, просто добавляем ещё одну фичу. С точки зрения бизнес-процесса, никому не надо делать дополнительной работы (мерчандайзеры и так ездят по торговым точкам, и так фотографируют, и так отправляют фотографии), а мы просто аккуратно встраиваем распознавание в эту цепочку.
Читал и статью и комментарий. Согласен полностью. Поставил бы +, но кармы не было :).
К счастью, мы не решаем общую задачу поиска всех товаров на всех прилавках. Сейчас мы делаем решение для определённой группы товаров на довольно стандартизированных стеллажах в границах одной страны. С детектированием проблем практически нет. В статье тоже рассматриваем частный случай.
Опять же, про 92% согласен. Но в данных, которые мы использовали для статьи, у нас на 10 классов меньше 2000 примеров, для некоторых классов примеров для тренировки в районе 50, а для проверки в районе 10. Цель статьи была не добиться максимально возможного результата на этом скудном объёме данных (доверия к цифре всё равно не было бы), но показать, что точность, для которой раньше приходилось реализовывать каскад алгоритмов, сейчас достигается использованием примера из Keras без усилий.