Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>Кстати не всегда. В больших компаниях все убюрократизировано по самое не балуй. И твой грейд определяет границы рейта.

Бывает, что прикручивают титул, когда рейт пробивает границы Видимо, мой не пробил ещё

Здравствуйте, nekocoder, Вы писали:

N>Распространение Линукса. Если ядро и компилятор в нем кое-как допилили благодаря стараниям корпораций, то все остальное — лютый хлам. Но приходится с ним работать. Пример того, как демпинг уничтожает конкуренцию.

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

Здравствуйте, kaa.python, Вы писали:

KP> в C++, дескать, нет безопасного форматирования,

Это аналог жавского PrintStream. В одной конторе был C++ велосипед- аналог жавского MessageFormat, там где можно написать "{2} abc {1}".

Здравствуйте, CreatorCray, Вы писали:

S>>Любые заходы из категории "Нарисуйте мне дом" говорят о конторе и интервьюерах многое. Даже если они принимают форму "напишите на доске обращение строки".
CC>Нет, это не "нарисуйте дом", это вот описанная словами задача, напиши к ней любое решение а дальше побеседуем и посмотрим как ты умеешь инженерно мыслить.

Тут придется привести подробные пояснения. Посему написать придется много, а времени мало. Засим прошу прощения за сумбур и качество текста.

Есть два момента, которые обязательно следует раскрыть.

Момент первый. Не очень важный. Но важный.

Принципиальная разница между подходом "Нарисуйте мне дом" -- "Какого размера, для каких целей, для какой местности, из каких материалов и пр." и "Переверните строку" -- "Алгоритм или код на каком-то языке? Мутабельную или иммутабельную? Простое представление или ROPE? Оглядываемся на эффективность или нет? И пр." заключается в том, что: разговор про переворот строки больше заточен на конкретные навыки программирования и некий профессиональный кругозор. Т.е. подход с переворотом строки, вроде как, более специализирован на отсечение негодных программистов.

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

1. На самом деле это не проверка того, как соискатель рассуждает. А проверка реакции соискателя на соответствие с тем, что вы ждете. Т.е. задавая подобный вопрос интервьюер ожидает либо вполне определенных вопросов от соискателя, либо подтверждения того, что соискатель не заслуживает рассмотрения (если вопросов нет, либо они не те, которые ожидаются). Поэтому есть некоторая вероятность, что используя данный подход вы, на самом деле, проверяете не то, что нужно.

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

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

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

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

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

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

Момент второй. Самый важный.

Вопрос про переворот строки задавался именно мне, а не какому-то гипотетическому Кумару Гашишевичу или Василию Аллибабаевичу.

Со мной, например, можно пообсуждать различия в организации процесса разработки при аутстафе, аутсорсе, заказной разработке, продуктовой разработке (с вариациями от "коробки" до конструктора из которого решения собираются под конкретного клиента). О том, когда лучше административное деление по проектному признаку, когда по технологическому. О том, как организовать отбор сотрудников. Как обеспечивать рост и обучение сотрудников, включая мотивацию и компенсацию. Как обеспечить хранение и передачу знаний в команде. Отчетность и контроль, KPI для программистов -- нужен или нет, если да, то что. Как разработка может помогать другим подразделениям (начиная от маркетинга и продаж, заканчивая техподдержкой). И т.д., и т.п.

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

И, если бы у меня было соответствующее настроение, я бы поразвлекался интервьюированием интервьюера на предмет того, понимает ли он разницу между разными представлениями строк и как быстро он смог бы сформулировать достаточно точное и полное ТЗ. Но, скорее всего, постарался бы объяснить несовпадение интересов и перестал тратить бы свое и чужое время.


Как-то так. Все вышеизложенное является моим частным мнением, которое никому не хочу навязывать, как и утверждать, что оно единственно правильное.

Здравствуйте, kaa.python, Вы писали:

KP>Да зачем брать современный C++, ты же за старые, проверенные технологии. Давай возьмем старый C++98 и найдем в нем... stringstream, так как мы не ленивые, то пройдя по ссылке внизу странички и нас волшебным образом перенесет на не менее важную функцию из этого самого stringstream-а – str.

Ты серьезно думаешь, что я не знаю про stringstream? Да, им можно форматировать строки, жутко громоздким и корявым образом. Я же говорю про функции вроде дотнетовской String.Format().

Здравствуйте, CreatorCray, Вы писали:

CC>Да и хрен с ней, со стандартной библиотекой. Всё равно толку от неё мало.
Да как сказать. Я писал на C# одно время, там стандартная библиотека шикарная и очень сильно облегчает жизнь. Ее бы в С++, и наверно процентов 80 библиотек бы можно было выбросить.

CC>Я ещё до появления вариадиков написал себе printflike safe форматтер, после появления вариадиков он стал ещё более safe, его и пользую везде. Он ещё и заметно быстрее чем библиотечный printf оказался.
Я тоже писал форматтеры. И вероятно тысячи других людей. Очевидно, что форматтер нужен практически в каждом проекте, но вот только комитет С++ вместо этого занят впихиванием фич в язык.

N>>Fallout 76 с патчем на 45 ГБ в первый день тому пример.
CC> Только не говори что ты думаешь что там 45 гигов кода!
Место занимают в основном текстуры. Я же имею ввиду подход — зачем заморачиваться качеством если можно в случае чего быстро обновить.

Здравствуйте, kaa.python, Вы писали:

KP>Мне тоже этот подход не нравится, тут я полностью согласен. Просто меня удивило заявление о том, что в C++, дескать, нет безопасного форматирования, когда оно там с 98 года, пусть и странненькое такое.

Заявление звучал как "У него в стандартной библиотеки нет функции форматирования строк", а не "нет безопасного форматирования". Функции format(...) действительно нет.

Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>Вот вопрос использования такого зоопарка в реальных проектах уже надо переводить в бизнес плоскость. И в JVM мире на Scala, и на Kotlin сейчас пишется много нового софта. И эти товарищи считают джаву коболом 21 века Кстати мне свалилось уже что-то на скале, надо разбираться. Хорошо, что я скалу не учил, теперь выучу за деньги работодателя.
Ну вот нам бизнес в этой плоскости говорит примерно следующее:

Мы к C# ничего плохого не испытываем, но у нас в деревне нет вообще такой профессии "программист". Есть "веб-разработчики", поэтому все новые проекты мы будем делать на php. И нам всё равно, что у вас в Новосибирске 1 C# девелопер за месяц делает проект, который нужно два месяца делать вдесятером на php (и он потом работает, а php нужно ещё полтора года отлаживать).
У нас в активе — ровно 0 девелоперов на С#, 1 девелопер, которого мы могли бы научить, и 15 девелоперов на php. Поэтому мы этого одного умного лучше обучим на быстрых курсах менеджмента, и он будет тим лидером на 15ю разработчиками.

В плане личного развития — интересно новые языки.
В плане менеджмента важно минимизировать риски. В том числе и риск "вся команда встанет и уволится, и мы должны набрать с улицы ещё десяток таких же. При этом за минимальные деньги".

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>>Выглядит точно как ересь какая-то:
CAF>>ss << std::fixed << std::setprecision(2) << d;

KP>И так как подобный подход выглядит непривычным, это не форматирование. Я правильно мысль уловил?
Нет, неправильно. Когда в Виллариба форматные строки являются частью пакета локализации, что позволяет, к примеру, выводить в одной стране валюту с 0 знаков после запятой, а в другой — с 4мя, в Виллабаджо наслаждаются вкомпилированными в код деталями форматирования. Удачи, кык грица.

Здравствуйте, nekocoder, Вы писали:

N>Я же говорю про функции вроде дотнетовской String.Format().

Которая скопирована с жавской MessageText.format(). В бусте есть формат https://theboostcpplibraries.com/boost.format.

Здравствуйте, kaa.python, Вы писали:

KP> если, конечно, команда адекватная и достаточно технически грамотная.

такой команде пофиг на чем делать успешные проекты

Здравствуйте, kaa.python, Вы писали:

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

KP>Мне кажется, приводить столь "одаренных" товарищей в качестве примера скорее плохая идея, нежели хорошая.

Его осенило не в этом, просто кинуло в крайность минимализма(https://www.yaplakal.com/forum7/topic1847421.html)

Просто это один из старейших и преданейших clojure человек

Здравствуйте, so5team, Вы писали:

S>Тут придется привести подробные пояснения.
Не очень понятно что именно ты хочешь пояснить.

S>Принципиальная разница между подходом "Нарисуйте мне дом" -- "Какого размера, для каких целей, для какой местности, из каких материалов и пр." и "Переверните строку" -- "Алгоритм или код на каком-то языке? Мутабельную или иммутабельную?

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

S>Со мной, например, можно пообсуждать различия в организации процесса разработки при аутстафе, аутсорсе, заказной разработке, продуктовой разработке (с вариациями от "коробки" до конструктора из которого решения собираются под конкретного клиента). О том, когда лучше административное деление по проектному признаку, когда по технологическому. О том, как организовать отбор сотрудников. Как обеспечивать рост и обучение сотрудников, включая мотивацию и компенсацию. Как обеспечить хранение и передачу знаний в команде. Отчетность и контроль, KPI для программистов -- нужен или нет, если да, то что. Как разработка может помогать другим подразделениям (начиная от маркетинга и продаж, заканчивая техподдержкой). И т.д., и т.п.
S>Соответственно, если бы мне на собеседовании задали вопрос про переворот строки, то стало бы сразу понятно, что кто-то из нас сильно ошибся. Скорее всего оба.

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

Здравствуйте, CreatorCray, Вы писали:

CC>Топик, из которого Артёмка набрался идей был как раз про тот тип задач, которые совсем не про уточнение условий.
CC>Я потому и беру задачу с битами потому что там нечего уточнять, всё уже дано, а вот разных путей решения, которые можно пообсуждать как раз много.

У разворота строки ровно 1 (один) оптимальный способ.

Здравствуйте, $$, Вы писали:

$>У разворота строки ровно 1 (один) оптимальный способ.
Именно поэтому это плоховатая задача для собеседования — даже поговорить не о чем.

Здравствуйте, CreatorCray, Вы писали:

CC>Именно поэтому это плоховатая задача для собеседования — даже поговорить не о чем.

Это отсекатель говорунов.
https://youtu.be/lK6IEvbSBHg

Здравствуйте, $$, Вы писали:

$>Здравствуйте, CreatorCray, Вы писали:

CC>>Именно поэтому это плоховатая задача для собеседования — даже поговорить не о чем.

$>Это отсекатель говорунов.

Зря время тратится. Условно 10-20 минут тратите только что бы понять стоит ли с человеком вообще говорить. Лучше задачу в которой за 10 мин отсекаются все полные нули. А для остальных есть логическое продолжение. ( Как улучшить, или чуть понменять условия)

То есть нужна задача со множеством решений/подходов тактик.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>>Вот вопрос использования такого зоопарка в реальных проектах уже надо переводить в бизнес плоскость. И в JVM мире на Scala, и на Kotlin сейчас пишется много нового софта. И эти товарищи считают джаву коболом 21 века Кстати мне свалилось уже что-то на скале, надо разбираться. Хорошо, что я скалу не учил, теперь выучу за деньги работодателя.
S>Ну вот нам бизнес в этой плоскости говорит примерно следующее:
S>

S>Мы к C# ничего плохого не испытываем, но у нас в деревне нет вообще такой профессии "программист". Есть "веб-разработчики", поэтому все новые проекты мы будем делать на php. И нам всё равно, что у вас в Новосибирске 1 C# девелопер за месяц делает проект, который нужно два месяца делать вдесятером на php (и он потом работает, а php нужно ещё полтора года отлаживать).
S>У нас в активе — ровно 0 девелоперов на С#, 1 девелопер, которого мы могли бы научить, и 15 девелоперов на php. Поэтому мы этого одного умного лучше обучим на быстрых курсах менеджмента, и он будет тим лидером на 15ю разработчиками.

Валить надо из такого бизнеса да и все. Что за деревня то? (Интересна география собеседников.)
S>В плане личного развития — интересно новые языки.
S>В плане менеджмента важно минимизировать риски. В том числе и риск "вся команда встанет и уволится, и мы должны набрать с улицы ещё десяток таких же. При этом за минимальные деньги".
Об этом уже говорено и не раз тут

Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>Зря время тратится. Условно 10-20 минут тратите только что бы понять стоит ли с человеком вообще говорить.
Понятно за 1 минуту.

CAF>То есть нужна задача со множеством решений/подходов тактик.
Нужен фильтр. Необходимое, но недостаточное условие.

Здравствуйте, $$, Вы писали:

$>Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>>Зря время тратится. Условно 10-20 минут тратите только что бы понять стоит ли с человеком вообще говорить.
$>Понятно за 1 минуту.

Помнится, ты расписывал как вы по полчаса эту задачу обмусоливали. Я думаю, что минут 10 надо, что бы понять, что-нибудь уточнить, еще и проверить. Все это в условиях стресса, желания не ошибиться. Так что за 1 минуту это решит только тот, кто ждет эту задачу. Вам именно такие нужны?

CAF>>То есть нужна задача со множеством решений/подходов тактик.
$>Нужен фильтр. Необходимое, но недостаточное условие.

Да, но не столь дорогой. Впрочем — это не самый худший вариант, просто можно бы и улучшить.