и почему в моей команде нет Кар-Карыча. А Крош — есть.
Тут можно сходу назвать причину, не вчитываясь в статью: потому что Кар-Карычу за 40 :)
Здесь гугл не поможет. Нужен практический опыт.
Я разработчик, но моя история менеджерских секций на собесах говорит о том, что важен не ваш опыт, а только те куски опыта, которые совпадают с представлениями интервьюера о правильных процессах. Если в вашей предыдущей компании процессы были не такие, которые любит интервьюер, то рассказывать про опыт бессмысленно.
Всегда ли синдром самозванца — признак хорошего специалиста?
Всегда полезный для нанимающего признак того, что оффер можно занизить.
P.S. Кстати, когда искал работу, то Альфа-Банк полностью проигнорировал мой отклик даже при подаче через знакомство по внутренней программе реферралов. Зато зумеров, как я вижу, нанимают, чтобы они просидели полгода и убежали )
Что-то вы себе противоречите. Так всё-таки удобный сервис или "дельцы, которые возят"?
Удобный сервис это залил файлы, оплатил картой, указал адрес, через месяц пришло. А дельцы это дельцы, серая зона, сложность поиска и коммуникации, переводы как правило на личный счёт итд.
Почти всё, что я запомнил, есть в статье. Ну ещё по опыту поспрашивали: как у нас в компании было планирование, что делали лиды, какие возникали трудности и как решал.
Для меня существование и проникновение в стандарты разработки огромной дополнительной надстройки над технологией является признаком проблем у технологии. Например, для HTML+JS таких надстроек много: Dart, TS, React/Vue/Angular, препроцессоры CCS, а до этого jQuery. Если сообществу нужно так много свистелок поверх языка, с языком точно что-то не так (с JS + HTML сильно много чего не так, очевидно).
Так вот в Java это Spring. Если сообществу в таких критически больших объёмах потребовался фреймворк, который превращает Java чуть ли не в новый язык, то это признак наличия больших недостатков. Ну и Kotlin, опять же, он даже гуглом принят, как стандарт для Андроида, а появился же не на пустом месте.
большую часть времени играю один, но пару раз в неделю собираюсь играть с друзьями
Считаю, что если человек может пару раз в неделю (!) собираться с друзьями, то у него вообще нет никаких проблем с организацией таких собраний, и бот не нужен. Я со своими могу собраться раз в два месяца, если повезёт. У всех работа, семьи, дети (у меня тоже). Синхронизировать расписания нереально, если вам 30+.
Блин, а ведь точно. Теперь у меня в голове модель укладывается. Структура, очевидно, работает: компания прибыльная, продукт продаётся и функционирует. И люди внутри, кажется, действительно верят в их систему, вон как тут защищают её. Но при этом у системы есть много сомнительных для внешнего наблюдателя признаков, начиная от показного противопоставления себя общепринятому и заканчивая более специфичным ритуалом отбора, чем это обычно бывает.
Это же секта. Прямо по пунктам: противопоставление обычному, ритуалы, замкнутость, отличие своих и не своих, истовая вера адептов в учение, и даже фактическая стабильность и работоспособность системы. Дословно прям, теперь идеально всё сошлось, спасибо!
Но... это ведь та же вакансия, на которую я откликнулся. А как же два кандидата на более поздней стадии найма? Я уже неделю как работаю в другом месте, а вы всё вакансию не закрыли?
Вот вам пришлось добавить композицию там, где по бизнесу её нет (включить документ в письмо). Это усилило coupling. На таком мелком примере проблем нет, но что если на самом деле таких сценариев много, и к письму кроме документа может быть приложен протокол, отчет, акт сверки итд. И у каждого свои правила. Вы не только в письмо добавите кучу полей, но и письмо начнет становиться божественным объектом, бизнес-логика из других контекстов протечет в него.
Но в обычной здоровой корпоративной среде я тоже ставлю себе продуктовые цели и тоже могу с любым коллегой любого ранга, который в контексте, обсуждать решение. Просто в обычной среде мне не нужно одобрение джунов, чтобы доказать свою экспертизу )
Извольте. Есть в одном сервисе две сущности: письмо и документ.
Пусть у письма бывают статусы: создано, отправлено.
У документа бывают статусы: создано, согласовано.
Никакая из этих сущностей не является композиционно составной частью второй: они вполне себе живут изолировано. Но иногда к письму может быть приложен документ. И в таком случае сменить статус письма с "Создано" на "Отправлено" (то есть отправить письмо) можно только тогда, когда документ в нём согласован. Типичная энтерпрайз задача на минималках.
Как на Go будет выглядеть модель данных, которая не даст использующему её программисту сломать инвариант?
Вижу прямое противоречие между "твоя экспертиза ценнее" и "твоё решение не имеет большего веса". Конечно, имеет. Это буквально определение экспертизы: более высокий вес мнения эксперта.
В общем, это описание подтвердило для меня, что вы примешиваете к работе инженера чрезмерно большое количество, прости, мышиной возни: с этим договориться, тому понравиться, там собрать обсуждение и так далее. Так что ты совершенно правильно понял, что мы не сработаемся, за что спасибо. С моей точки зрения технический специалист высокого класса должен эффективно и правильно решать технические задачи, а коммуникациями заниматься в рамках минимума, необходимого для естественного человеческого взаимодействия в команде, не больше. А здесь игры престолов отнимали бы очень много внимания.
Привет, спасибо за отзыв. Но почему нельзя было так и сказать в обратной связи? Я бы абсолютно нормально это воспринял. И было бы понятнее, чем то, что мне написали, причём только после моего вопроса :)
я бы головы отрезал всем тем гениям которые взяли за моду поголовно в каждом ЯП считать с 0
Но у этого же есть математическая подоплёка. Индексация с нуля это не мода, а удобство вычислений. Например, когда нужно разместить элементы с шагом N, то координата i-го элемента будет равна i*N, и таких задач очень много. Размещения, сортировки, группировки, выборки, там везде математика красиво сходится, если считать с нуля, и некрасиво, если с единицы.
Тут можно сходу назвать причину, не вчитываясь в статью: потому что Кар-Карычу за 40 :)
Я разработчик, но моя история менеджерских секций на собесах говорит о том, что важен не ваш опыт, а только те куски опыта, которые совпадают с представлениями интервьюера о правильных процессах. Если в вашей предыдущей компании процессы были не такие, которые любит интервьюер, то рассказывать про опыт бессмысленно.
Всегда полезный для нанимающего признак того, что оффер можно занизить.
P.S. Кстати, когда искал работу, то Альфа-Банк полностью проигнорировал мой отклик даже при подаче через знакомство по внутренней программе реферралов. Зато зумеров, как я вижу, нанимают, чтобы они просидели полгода и убежали )
Для того, что вы описали, есть пиэм. Тимлид всё-таки член команды, и это ключевое отличие:
Что-то вы себе противоречите. Так всё-таки удобный сервис или "дельцы, которые возят"?
Удобный сервис это залил файлы, оплатил картой, указал адрес, через месяц пришло. А дельцы это дельцы, серая зона, сложность поиска и коммуникации, переводы как правило на личный счёт итд.
Почти всё, что я запомнил, есть в статье. Ну ещё по опыту поспрашивали: как у нас в компании было планирование, что делали лиды, какие возникали трудности и как решал.
Для меня существование и проникновение в стандарты разработки огромной дополнительной надстройки над технологией является признаком проблем у технологии. Например, для HTML+JS таких надстроек много: Dart, TS, React/Vue/Angular, препроцессоры CCS, а до этого jQuery. Если сообществу нужно так много свистелок поверх языка, с языком точно что-то не так (с JS + HTML сильно много чего не так, очевидно).
Так вот в Java это Spring. Если сообществу в таких критически больших объёмах потребовался фреймворк, который превращает Java чуть ли не в новый язык, то это признак наличия больших недостатков. Ну и Kotlin, опять же, он даже гуглом принят, как стандарт для Андроида, а появился же не на пустом месте.
Считаю, что если человек может пару раз в неделю (!) собираться с друзьями, то у него вообще нет никаких проблем с организацией таких собраний, и бот не нужен. Я со своими могу собраться раз в два месяца, если повезёт. У всех работа, семьи, дети (у меня тоже). Синхронизировать расписания нереально, если вам 30+.
Блин, а ведь точно. Теперь у меня в голове модель укладывается. Структура, очевидно, работает: компания прибыльная, продукт продаётся и функционирует. И люди внутри, кажется, действительно верят в их систему, вон как тут защищают её. Но при этом у системы есть много сомнительных для внешнего наблюдателя признаков, начиная от показного противопоставления себя общепринятому и заканчивая более специфичным ритуалом отбора, чем это обычно бывает.
Это же секта. Прямо по пунктам: противопоставление обычному, ритуалы, замкнутость, отличие своих и не своих, истовая вера адептов в учение, и даже фактическая стабильность и работоспособность системы. Дословно прям, теперь идеально всё сошлось, спасибо!
Но... это ведь та же вакансия, на которую я откликнулся. А как же два кандидата на более поздней стадии найма? Я уже неделю как работаю в другом месте, а вы всё вакансию не закрыли?
Вот вам пришлось добавить композицию там, где по бизнесу её нет (включить документ в письмо). Это усилило coupling. На таком мелком примере проблем нет, но что если на самом деле таких сценариев много, и к письму кроме документа может быть приложен протокол, отчет, акт сверки итд. И у каждого свои правила. Вы не только в письмо добавите кучу полей, но и письмо начнет становиться божественным объектом, бизнес-логика из других контекстов протечет в него.
Первым же голосованием тебя уволят )
Но в обычной здоровой корпоративной среде я тоже ставлю себе продуктовые цели и тоже могу с любым коллегой любого ранга, который в контексте, обсуждать решение. Просто в обычной среде мне не нужно одобрение джунов, чтобы доказать свою экспертизу )
Этот вопрос не даёт мне покоя.
Извольте. Есть в одном сервисе две сущности: письмо и документ.
Пусть у письма бывают статусы: создано, отправлено.
У документа бывают статусы: создано, согласовано.
Никакая из этих сущностей не является композиционно составной частью второй: они вполне себе живут изолировано. Но иногда к письму может быть приложен документ. И в таком случае сменить статус письма с "Создано" на "Отправлено" (то есть отправить письмо) можно только тогда, когда документ в нём согласован. Типичная энтерпрайз задача на минималках.
Как на Go будет выглядеть модель данных, которая не даст использующему её программисту сломать инвариант?
Вижу прямое противоречие между "твоя экспертиза ценнее" и "твоё решение не имеет большего веса". Конечно, имеет. Это буквально определение экспертизы: более высокий вес мнения эксперта.
В общем, это описание подтвердило для меня, что вы примешиваете к работе инженера чрезмерно большое количество, прости, мышиной возни: с этим договориться, тому понравиться, там собрать обсуждение и так далее. Так что ты совершенно правильно понял, что мы не сработаемся, за что спасибо. С моей точки зрения технический специалист высокого класса должен эффективно и правильно решать технические задачи, а коммуникациями заниматься в рамках минимума, необходимого для естественного человеческого взаимодействия в команде, не больше. А здесь игры престолов отнимали бы очень много внимания.
Привет, спасибо за отзыв. Но почему нельзя было так и сказать в обратной связи? Я бы абсолютно нормально это воспринял. И было бы понятнее, чем то, что мне написали, причём только после моего вопроса :)
Но у этого же есть математическая подоплёка. Индексация с нуля это не мода, а удобство вычислений. Например, когда нужно разместить элементы с шагом
N, то координатаi-го элемента будет равнаi*N, и таких задач очень много. Размещения, сортировки, группировки, выборки, там везде математика красиво сходится, если считать с нуля, и некрасиво, если с единицы.Москва, видимо? Налог на пафос же :)
Офигеть, вот это разнос. В историю!
Ну, нанимали всё-таки разработчика, а не промпт-инженера )
Кажется, про R снова заговорили последние годы