Программирование[11]

kez написал 50 минут назад:

Я пишу архитектуру, декомпозирую задачи, формирую ТЗ, составляю задачи на другие отделы, делаю код-ревью, по возможности делаю маленькие задачи сам.
Ну такие вещи как поддержание актуальности стека, техническое развитие проекта, планирование рефакторингов — это само собой на мне тоже.

 

Если просто, то процесс такой:
1. Бизнес говорит менеджеру "Сделайте вот такую хуйню"
2. Менеджер приходит ко мне и спрашивает, что нужно, чтобы это реализовать.
3. Я перечисляю список того, что нужно от дизайна, других команд, накидываю архитектуру. 

4. Мне приносят макеты

5. Я декомпозирую все это на задачи, везде пишу ТЗ, выстраиваю порядок выполнения, оцениваю сроки. Попутно прописываю контракты и создаю задачи на другие команды.
6. Мы все это делаем командой, я делаю код-ревью всего. Пишу ТЗ на тестирование
7. В промежуток между "У команды есть задачи и ответы на все вопросы" и "Дата релиза" я могу выдохнуть и спокойно поулучшать процессы в команде, пописать документацию, какой-нибудь рефакторинг затащить

ну ты молодец, че

я бы сказал проблема, которую ты выше описал, корень имеет не в том что ты в менеджменте а в том что тебя перенапрягают

+ то что ты не делегировал нихуя из разработки

по хорошему твой фокус работы должен быть на людях и процессах команды, а всем остальным (типа архитектуры и мелкой декомпозиции задач) скорее в свободное время заниматься. и по хорошему ты должен команду довести до такой автономности что она будет работать ок если ты выпадешь на 2-4 недели.

в плане того что начальство перенапрягает - ну можно наверное попробовать аргументированно и полит корректно посылать их нахуй, типа мы уже работаем на пределе и транспарентно и конструктивно обьяснять что быстрее уже не возможно. если не понимают по хорошему - начать заниматься очковтирательством в виде переоценки чтобы были запасы времени передохнуть.

ну либо нагрузку спускать на команду (собственно делегировать около технические/разработческие вещи), а тем что тебя лично нагружает начальство заниматься больше - вы так конечно нихуя больше не сделаете, но у начальства будет ощущение что ты пашешь пиздец и наверное они от тебя отстанут

я бы первым дропнул код ревью, контракты, тестирование, архитектуру - это все прямые обязанности разработчиков рядовых, а ты уже нихуя не разработчик. плюс синьерам надо расти, а куда они будут расти если они как черви уже все готовое просто кодят не задумываясь ни о чем.

хай левел "че как вообще это можно сделать", зависимости и координацию с другими командами, коммуникацию со стейкхолдерами я бы пока оставил на себе тк это вполне make sense делать менеджеру

Kant написал 2 часа назад:

это типа как в первом классе вместо оценок ставят рандомную положительную хуйню, чтобы дети не догадались, что они в реальности дауны?

 

пиздец блять

Ну не совсем.

"+" - все ок, к тебе не доебываются

"+-" - неок, но есть шанс исправиться

"-" - обычно его ставят задним числом, так как сотрудник оказывается на морозе раньше ревью

Все что выше одного плюса - это выше "ок". От количества плюсов (бывает до 4х штук) зависит премия. Два раза подряд больше одного плюса - возможность для повышения. Чем больше суммарно плюсов - тем выше шанс получить повышение.

От количества плюсов за последние 3 ревью зависит повышение зарплаты на текущем.

От количества плюсов за последние 3 ревью зависит шанс получить опционы на грейдах от 18го (ведущий разработчик) и выше. Правда на 18м надо дохуя плюсов сейчас, чтобы получить опционы.

Grohuf написал 1 час назад:

Kant написал 4 часа назад:

это типа как в первом классе вместо оценок ставят рандомную положительную хуйню, чтобы дети не догадались, что они в реальности дауны?

 

пиздец блять

Ну не совсем.

"+" - все ок, к тебе не доебываются

"+-" - неок, но есть шанс исправиться

"-" - обычно его ставят задним числом, так как сотрудник оказывается на морозе раньше ревью

Все что выше одного плюса - это выше "ок". От количества плюсов (бывает до 4х штук) зависит премия. Два раза подряд больше одного плюса - возможность для повышения. Чем больше суммарно плюсов - тем выше шанс получить повышение.

От количества плюсов за последние 3 ревью зависит повышение зарплаты на текущем.

От количества плюсов за последние 3 ревью зависит шанс получить опционы на грейдах от 18го (ведущий разработчик) и выше. Правда на 18м надо дохуя плюсов сейчас, чтобы получить опционы.

На ячане и хурале уже кучу времени педалируют, что одни + получать это ггвп. И в некоторых юнитах это реально так, видимо в браузере более лайтово 

А ну речь естественно про 15, 16, 17. Выше там понятно, что для выше плюса там другая ситуация 

Just.Doit написал 11 часов назад:

у начальства будет ощущение что ты пашешь пиздец и наверное они от тебя отстанут

)

Grohuf написал 02.12.2025 в 18:10:

Kant написал 02.12.2025 в 15:26:

это типа как в первом классе вместо оценок ставят рандомную положительную хуйню, чтобы дети не догадались, что они в реальности дауны?

 

пиздец блять

Ну не совсем.

"+" - все ок, к тебе не доебываются

"+-" - неок, но есть шанс исправиться

"-" - обычно его ставят задним числом, так как сотрудник оказывается на морозе раньше ревью

Все что выше одного плюса - это выше "ок". От количества плюсов (бывает до 4х штук) зависит премия. Два раза подряд больше одного плюса - возможность для повышения. Чем больше суммарно плюсов - тем выше шанс получить повышение.

От количества плюсов за последние 3 ревью зависит повышение зарплаты на текущем.

От количества плюсов за последние 3 ревью зависит шанс получить опционы на грейдах от 18го (ведущий разработчик) и выше. Правда на 18м надо дохуя плюсов сейчас, чтобы получить опционы.

какая текучка сеньёров в яше? скажем сколько времени (лет) работает среднеститистический сеньёр?

на 1й взгляд, гоняться за плюсами = рвать жопу. рвать жопу постоянно затруднительно, перестал рвать, оказался на морозе, велком следующий, благо поток обеспечен постоянным хантингом

Olololnet написал 48 минут назад:

какая текучка сеньёров в яше? скажем сколько времени (лет) работает среднеститистический сеньёр?

хз, довольно мало людей увольняется, в основном те, кто переезжает за рубеж (в последний год много ушло людей, работающих в Сербии, перплексити переманивает).Так сходу могу вспомнить только 2 сеньора за последние лет 5, которые уволились из Яндекса и перешли в другую российскую контору. Один ушел, чтобы работать из дома постоянно, другой ушел и вернулся. В целом сеньорский костяк браузера очень стабилен. Текучка продакт менеджеров или тестировщиков заметно выше.

kez написал 02.12.2025 в 18:01:

Я пишу архитектуру, декомпозирую задачи, формирую ТЗ, составляю задачи на другие отделы, делаю код-ревью, по возможности делаю маленькие задачи сам.
Ну такие вещи как поддержание актуальности стека, техническое развитие проекта, планирование рефакторингов — это само собой на мне тоже.

 

Если просто, то процесс такой:
1. Бизнес говорит менеджеру "Сделайте вот такую хуйню"
2. Менеджер приходит ко мне и спрашивает, что нужно, чтобы это реализовать.
3. Я перечисляю список того, что нужно от дизайна, других команд, накидываю архитектуру. 

4. Мне приносят макеты

5. Я декомпозирую все это на задачи, везде пишу ТЗ, выстраиваю порядок выполнения, оцениваю сроки. Попутно прописываю контракты и создаю задачи на другие команды.
6. Мы все это делаем командой, я делаю код-ревью всего. Пишу ТЗ на тестирование
7. В промежуток между "У команды есть задачи и ответы на все вопросы" и "Дата релиза" я могу выдохнуть и спокойно поулучшать процессы в команде, пописать документацию, какой-нибудь рефакторинг затащить

Just.Doit написал 02.12.2025 в 19:03:

ну ты молодец, че

 

я бы сказал проблема, которую ты выше описал, корень имеет не в том что ты в менеджменте а в том что тебя перенапрягают

+ то что ты не делегировал нихуя из разработки

 

по хорошему твой фокус работы должен быть на людях и процессах команды, а всем остальным (типа архитектуры и мелкой декомпозиции задач) скорее в свободное время заниматься. и по хорошему ты должен команду довести до такой автономности что она будет работать ок если ты выпадешь на 2-4 недели.

 

в плане того что начальство перенапрягает - ну можно наверное попробовать аргументированно и полит корректно посылать их нахуй, типа мы уже работаем на пределе и транспарентно и конструктивно обьяснять что быстрее уже не возможно. если не понимают по хорошему - начать заниматься очковтирательством в виде переоценки чтобы были запасы времени передохнуть.

ну либо нагрузку спускать на команду (собственно делегировать около технические/разработческие вещи), а тем что тебя лично нагружает начальство заниматься больше - вы так конечно нихуя больше не сделаете, но у начальства будет ощущение что ты пашешь пиздец и наверное они от тебя отстанут

 

я бы первым дропнул код ревью, контракты, тестирование, архитектуру - это все прямые обязанности разработчиков рядовых, а ты уже нихуя не разработчик. плюс синьерам надо расти, а куда они будут расти если они как черви уже все готовое просто кодят не задумываясь ни о чем.

хай левел "че как вообще это можно сделать", зависимости и координацию с другими командами, коммуникацию со стейкхолдерами я бы пока оставил на себе тк это вполне make sense делать менеджеру

Объективно харош, да. Как по мне -  у тебя классическая ловушка джокера. Надо делегировать разработку на работяг. здесь бинарная развилка - или ты справляешься с делегировнием или ты вконце вконцов привыкаешь ахуевать от давления на работе и тебя начинает всё раздражать... превращаешься в серого кардинала на проекте, твой авторитет абсолютен,  внешне в софтах - ты даже можешь быть вполне ок. Но в реальных вопросах - никто без твоего согласия ничего не делает.
В ит - технологии бесконечно улучшаются. Но самое слабое место в ит - это психология человека.  Токсичную атмосферу - создает руководство, где разрабы просто не могут уже находится и начинается текучка... проект руинится 

sB.Raven написал 31 минуту назад:

В ит - технологии бесконечно улучшаются. Но самое слабое место в ит - это психология человека.  Токсичную атмосферу - создает руководство, где разрабы просто не могут уже находится и начинается текучка... проект руинится 

чуть попозже в своем развитии ты пойсешь что психология человека в целом тоже уже понятная механика и выйдешь на понимание того что все утыкается в организацию компании (процессы, иерархия, культура и тп)

но да, ты правильно этот этап понимания прошел. технологии не проблема.

Just.Doit написал 35 минут назад:

sB.Raven написал 1 час назад:

В ит - технологии бесконечно улучшаются. Но самое слабое место в ит - это психология человека.  Токсичную атмосферу - создает руководство, где разрабы просто не могут уже находится и начинается текучка... проект руинится 

чуть попозже в своем развитии ты пойсешь что психология человека в целом тоже уже понятная механика и выйдешь на понимание того что все утыкается в организацию компании (процессы, иерархия, культура и тп)

но да, ты правильно этот этап понимания прошел. технологии не проблема.

Я имел ввиду - что проблема разработки по, не в технологиях,  а в людях.

Как можно пофиксить чсв атмосферу?
- уволить руководителей(9из10 этого не произойдет - увольняют работяг)
- если компания уровня бигтех - начать переводить с проекта на проект управляющий состав условные каждые N лет(такое вроде есть в сбере....)
- продать новую супер пупер хард технологию и переписать проект

Обчно выбирают последний пункт.

Понятно, что психология социума и человека - досточно понятна миру. Кто будет только этим заниматься внутри компании?

sB.Raven написал 9 часов назад:

Кто будет только этим заниматься внутри компании?

вот

ты подошел к тому что важно устройство компании и кто в ней за что отвечает и что делает или не делает

Grohuf написал 02.12.2025 в 19:10:

Kant написал 02.12.2025 в 16:26:

это типа как в первом классе вместо оценок ставят рандомную положительную хуйню, чтобы дети не догадались, что они в реальности дауны?

 

пиздец блять

Ну не совсем.

"+" - все ок, к тебе не доебываются

"+-" - неок, но есть шанс исправиться

"-" - обычно его ставят задним числом, так как сотрудник оказывается на морозе раньше ревью

Все что выше одного плюса - это выше "ок". От количества плюсов (бывает до 4х штук) зависит премия. Два раза подряд больше одного плюса - возможность для повышения. Чем больше суммарно плюсов - тем выше шанс получить повышение.

От количества плюсов за последние 3 ревью зависит повышение зарплаты на текущем.

От количества плюсов за последние 3 ревью зависит шанс получить опционы на грейдах от 18го (ведущий разработчик) и выше. Правда на 18м надо дохуя плюсов сейчас, чтобы получить опционы.

Насколько надо убиться ради 4х плюсов?

mingrevone написал 56 минут назад:

Насколько надо убиться ради 4х плюсов?

Ну либо ебаться со своим руклем в сраку, либо работать круглые сутки. 

На самом деле фиолетовая не такая уж редкость на низших грейдах, но сеньору получить 4 плюса - это не просто

Just.Doit написал 4 часа назад:

sB.Raven написал 13 часов назад:

Кто будет только этим заниматься внутри компании?

вот

ты подошел к тому что важно устройство компании и кто в ней за что отвечает и что делает или не делает

 

Дай надежду, что где-то есть эльдорадо...

Grohuf написал 24 минуты назад:

mingrevone написал 1 час назад:

Насколько надо убиться ради 4х плюсов?

Ну либо ебаться со своим руклем в сраку, либо работать круглые сутки. 

На самом деле фиолетовая не такая уж редкость на низших грейдах, но сеньору получить 4 плюса - это не просто

 

Ты получал когда-то 4 плюса?

scarppy написал 12 минут назад:

Grohuf написал 36 минут назад:

mingrevone написал 1 час назад:

Насколько надо убиться ради 4х плюсов?

Ну либо ебаться со своим руклем в сраку, либо работать круглые сутки. 

На самом деле фиолетовая не такая уж редкость на низших грейдах, но сеньору получить 4 плюса - это не просто

 

Ты получал когда-то 4 плюса?

т.е. хочешь спросить ебался ли он с руклем? работать 24/7 исключаю заранее

scarppy написал 12 минут назад:

Grohuf написал 37 минут назад:

mingrevone написал 1 час назад:

Насколько надо убиться ради 4х плюсов?

Ну либо ебаться со своим руклем в сраку, либо работать круглые сутки. 

На самом деле фиолетовая не такая уж редкость на низших грейдах, но сеньору получить 4 плюса - это не просто

 

Ты получал когда-то 4 плюса?

Получал E, когда были буквенные обозначения (вроде это был макс, уже не помню), и пару раз три плюса. 4 плюсика - никогда.

Получал кучу красных мишек, сосите 

Grohuf написал 37 минут назад:

Получал E, когда были буквенные обозначения (вроде это был макс, уже не помню), и пару раз три плюса. 4 плюсика - никогда.

Это за успешный ребейз на ремоут хромиума? 

Arzanis написал 12 минут назад:

Получал кучу красных мишек, сосите 

Получил утку с ножом

Baza_KAiF написал 20.11.2025 в 12:04:

Vova написал 19.10.2025 в 12:06:

mingrevone написал 19.10.2025 в 12:04:

Вот же скотина.

Drakonian написал 19.10.2025 в 10:12:

 

 

Я задаю ровно ту же задачу которую сам решал на интервью

 

Есть поток цифр нужно в потоке считать среднее последних N цифр из которых удалили M самых больших значений и M самых маленьких

спасибо дядя вова нашел чем мне заняться после плотного обеда. а то пизда в курсах 2 месяца теории без практики

 

  Показать содержимое

#include <iostream>

#include <vector>

#include <string>

#include <algorithm>

 

int main() {

 

std::vector<int> potok;

std::string input;

int number;

int N = 10;

int M = 3;

std::vector<int> vec;

 

while (true){

    std::cout << "Enter number "<< std::endl << ">";

    if (std::cin >> number){

        potok.push_back(number);

        if (potok.size() >= N) {

            if (vec.size() > 0) {vec.clear();}

            double sum = 0.0;

            double mean=0.0;

            vec.clear();

            for (auto n=N; n>0; --n){

 

            vec.push_back(potok[potok.size()-n]);

            }

 

            std::sort (vec.begin(), vec.end());

            for (auto m=0; m<M; ++m){

 

                vec.erase(vec.begin()+(N-1-m*2));

                vec.erase(vec.begin());

                }

            for(auto i=0; i<vec.size(); i++){

                sum += vec;}

                mean = sum / (N-2*M);

                std::cout << "N=" << N << " M=" << M << std::endl << "mean=" << mean << std::endl;

        }    

    }

        else {std::cout << "Input error" << std::endl; break;}

}

}

 

У меня такая хуйня получилась

UglyBastard написал 5 часов назад:

Baza_KAiF написал 20.11.2025 в 01:04:

Vova написал 19.10.2025 в 02:06:

mingrevone написал 19.10.2025 в 02:04:

Вот же скотина.

Drakonian написал 19.10.2025 в 00:12:

 

 

Я задаю ровно ту же задачу которую сам решал на интервью

 

Есть поток цифр нужно в потоке считать среднее последних N цифр из которых удалили M самых больших значений и M самых маленьких

спасибо дядя вова нашел чем мне заняться после плотного обеда. а то пизда в курсах 2 месяца теории без практики

 

  Показать содержимое

#include <iostream>

#include <vector>

#include <string>

#include <algorithm>

 

int main() {

 

std::vector<int> potok;

std::string input;

int number;

int N = 10;

int M = 3;

std::vector<int> vec;

 

while (true){

    std::cout << "Enter number "<< std::endl << ">";

    if (std::cin >> number){

        potok.push_back(number);

        if (potok.size() >= N) {

            if (vec.size() > 0) {vec.clear();}

            double sum = 0.0;

            double mean=0.0;

            vec.clear();

            for (auto n=N; n>0; --n){

 

            vec.push_back(potok[potok.size()-n]);

            }

 

            std::sort (vec.begin(), vec.end());

            for (auto m=0; m<M; ++m){

 

                vec.erase(vec.begin()+(N-1-m*2));

                vec.erase(vec.begin());

                }

            for(auto i=0; i<vec.size(); i++){

                sum += vec;}

                mean = sum / (N-2*M);

                std::cout << "N=" << N << " M=" << M << std::endl << "mean=" << mean << std::endl;

        }    

    }

        else {std::cout << "Input error" << std::endl; break;}

}

}

 

У меня такая хуйня получилась

 

  Показать содержимое

 

но я чет заебался дебажить, когда изначально выбрал begin/end хранить n-середины, и код страшненький получился. С begin/rbegin более менее уже код

 

Но задача конечно хорошая для интервью, отсеет уйму народу из-за корнер кейсов

Я кстати сам когда решал задачу то создавал 3 std::multiset - smallest_m, middle, largest_m

Ты сделал это с итераторами ну ок так тоже пойдет но по-моему так более мозгоебно ну да ладно это уже вкусовщина

А вот если бы ты правильно разбил свою длинную функцию на подфункции это бы сделало твое решение сильно короче и сильно сэкономило бы твое время на интервью вместо того чтобы рассматривать миллион корнер кейсов

В общем основная сложность задачи это как правильно разбивать код на понятные и простые куски

Я бы конечно зачел тебе твое решение и поставил бы "recommend" но я все таки ожидал что кандидат заметил что left_mth и right_mth имеют полностью дублирующую логику друг у друга а еще тебе не обязательно двигать итераторы и после insert и после remove потому что можно это сделать один раз после remove + insert

Короче ты мог уменьшить количество корнер кейсов в 4 раза