До сих пор не понимаю чем это отличается принципиально от того чтобы взять любой уже готовый образец на гитхабе, перебить название например на "болгенос" и выдать за новую программу. То, что столько программистов из за этого боятся потерять работу доказывает только одно, они не програмисты, а копирасты, которых легко заменить даже не gpt, а ботом поверх стековерфлоу. И второй момент, допустим сделают робота футболиста который в 100% случаев запинывает мяч от своих ворот до ворот соперника мощнейшим пушечным ударом, неужели это как то повлияет на популярность человеческого футбола со своими звёздами и борьбой? Наличие пушек например даже не смогло уничтожить соревнования по стрельбе из лука, а кто-то даже пращей увлекается. Естественно я могу не осознавать всего величия gpt. Но скорее всего через год он просто станет рутиной с очень ограниченным практическим применением, а хайп будет вокруг какой-то новой игрушки.
Не знаю о чем статья. Работаю в IDE за 0 евро. Idea ce, vs code. При этом часто особенно для голанга для сборки использую старый добрый мейк, который вызываю во встроенном в ide терминале. Я вот в итоге и не знаю, автор бы меня похвалил или предал бы анафеме???)))
Какого такого сотрудничества с США и их вассалами вы жаждите? К какому такому открытому интернету аппелируете и взываете? Из детского сада я смотрю куча комментаторов. Патч не приняли и фиг с ним, ещё поди разбери что там первичнее политота или качество патча. Главное что противная сторона пока не имеет серьёзной возможности закрыть основной форк ядра, значит при необходимости можно спокойно вести свой с патчами для того же Байкала. Так как Байкал не особо бытовой, а в основном для военных всяких нужд, к нему так и так делается отдельное ядро. Да есть риск что разъедутся ветки, но блин так и ядерной войны не хилая вероятность есть.
Но опрос то проведён здесь и сейчас и много где C++ незаменим, например в геймдеве серьёзном. Понимаете некоторые вещи не заменимы не потому что ничего нет что выполнило бы их функцию, а потому что никто и не пытается их менять,
Претензии не к idea а отсутствия как такового встроенного тулинга. Если не работаете с новым поколением языков типа go где всё типовые вопросы а-ля тестирование, пакетныйменеджер, профилирование, авто форматирование, линтинг, покрытие, кодогенерация и прочее идёт из коробки и очень простое, то вам сложно понять что не так с Java или C++. Настройка авто сборки того же голанга пара простых команд в makefile. Адекватная же сборка на gradle, npm, CMake, это уйма копипасты или тайных знаний и привлечения всякого набора внешних средств.
Если для Вас ЭТА задача является "спортивным программированием", то задайтесь сами вопросом - Вы точно представляете себе чем занимаются компании которые набирают именно программистов для разработки софта, а не сопровождением легасных телеграм ботов и сайтов на ванильном PHP?
Знаю, что наберу минусов. Но мне лично как-то без разницы.
Очередная отличная статья, написанная о собеседовании со стороны собеседующего, а не со стороны стоноты, который бегает собеседуются, а его ""мучают", "не берут" и вообще все вокруг идиоты, а он такой молодец".
И опять человек в 100-й раз Вам пишет, как писали многие до этого, что вся соль на собеседовании в умении задавать вопросы и рассуждать, а не в Ваших хардскиллах, к тому же фальшивых, если под ними нет базы.
Когда на работу берут например строителя в бригаду прежде всего смотрят не то как он пользуется лопатой - этому научат. На что смотрят: 1. кто по национальности и вере и где родился, чтобы не оказалось, что у тебя в бригаде потом на этой почве поножовщина с другими 2. что по пьянке 3. что набито на руках и спине 4. кто его знает, кому позвонить спросить кто такой 5. может наличие хоть какого-то документа 6. отсуствие признаков внешних каких-то явно нездоровых в части психики
Вот что будут смотреть. И программистов это касается в полной мере. Собеседование это не про "лопаты", а про "наколки"
Если вы идете программистом, то только тимлиды, не уважающие свой коллектив и работу и сами не имеющие квалификаций будут проводить интервью только по хардскиллам и только ровно по тем, что именно сейчас в работе. Вот кто тут жалуется в комментариях и негодует я скажу следующий чеклист в компаниях где действительно есть комманды разработчиков и они разрабатывают
1. если у вас стремные софты - это перевесит в итоге хорошие харды, хотя если софты хорошие это не значит, что они перевесят отсутствие хардов 2. умение мыслить - важнее гораздо готовых знаний 3. умение задать вовремя правильный вопрос - важнее чем готовые ответы 4. умение действительно справиться со стрессом - важнее чем показное веселье или напускное спокойствие 5. и да - такие простенькие задачи на алгоритмы (простые в плане что условия понятны, кода точно много не требуется и легко в голове прикидывать на числах типа 1,2,3) - надо решать до какого-то хотя бы уровня, хотя бы на хэшмапах - а ведь не все кандидаты даже это в состоянии предложить!
И только потом будет хоть какое-то разделение по уровням компаний и их требованиям. Я сам не знаю до какого алгоритма сам бы дошел если бы на собеседование попал, но когда сам собеседую - мне в принципе в большинство команд годятся люди там второго примерно уровня сложности (по автору задачи) ну то есть чутка оптимизированее чем хэшмапы. И я бы не стал слишком спрашивать сильно за расчет О. А может в какую-нибудь другую команду они хотят видеть тех, кто умеет это хорошо считать и глубже анализировать.
Если Вас это бесит - значит просто ВЫ не годитесь в эту команду, а команда и без ВАС спокойно проживет. Не хотите никаких требований на собесе? Идите работать на галеры - там Вас ни о чем кроме имени Вашего не спросят.
А мне лично только с такими и нравится работать действительно по-настоящему, кто видит глубину в работе и что есть всегда не один только какой-то очевидный вариант.
Вопрос не то чтобы плохой, скорее он симптоматичный. Но надо понять симптом "чего" - не понимания постановки? просто невнимательности? переусложнения?.
Я бы ответил на такой вопрос "поясните, не совсем понял, мне казалось в задаче все прозрачно, может я чего-то не замечаю?"
Далее варианты такие 1. человек вчитывается и говорит "а тут N+1, а числа тоже 1..N", ок тут точно хотя бы 1 повтор - это мелкий залет совсем, такой на тему "резиновой уточки" 2. человек говорит "тут может быть ловушка с типами данных, например равен ли float64(2.0) числу int32(2), потому что хотя с точки зрения математики - это все еще целые числа, для кода это все же нечто различное" - я бы понял, что этот вопрос результат некоторого избыточного усложнения, с другой стороны ничего некорректного в этом нет. Я бы сказал в ответ, что тип не имеет значения, важна только "чистая математическая сторона" int(2)==float64(2.0) - это я не буду считать залетом 3. человек просто перечитывает задачу и говорит - "ну тут вообще нет никакой информации - есть там повторы или нет" - залет - просто не умеет читать условия в абстрактном представлении с - N там, множествами и прочим - признак конкретного мышления или очень и очень неподвижного мышления
То есть меня устроит вариант - что он просто понял, что там есть повторы или вариант 2 с каким-то усложенением, меня не особо напряжет вариант 1 и очень напряжет вариант 3.
Если автор рассматривал этот вопрос только как вариант 3 - то кончено это очень плохой вопрос.
Ну наверное на собеседовании не один такой вопрос используется. К тому же опять какие-то "оба знают алгоритмы, как выбрать". А я Вам скажу как - HR спросит у тимлида - кто тебе в целом больше понравился, с кем работать готов? - а тут не может уже быть совсем двух равных кандидатов
Молодой человек, видимо не проводящий сам собеседования. В этих вопросах и есть самая соль. Я часто задаю что-то что человек ЗАВЕДОМО не знает из серии "у нас была такая-то проблема и мы умудрились ее решить, проломав всем коллективом голову месяц, можете сейчас за 10 минут каким-то образом предложить решение?" и смотрю только на вопросы и на направление мыслей. Умение в таких ситуациях отбрасывать из головы лишнее, сосредотачиваться на проблемах и ограничениях, умение задать точный и действительно что-то значащий для выводов вопрос и при этом не терять присутствия духа - это и есть тот кандидат, который мне предпочтительней того, у кого этих качеств нет, даже если он более хард-скилловый в данный момент времени. Потому что хардскиллы нарабатываются со временем, а вот эта общая способность размышлять, коммуницировать и справляться со стрессом - нет
Ну то есть вы сами подтверждаете, что само по себе наличие библиотек уже готовых, софта уже написанного и каких то чудо тулзовин сказывается на специализации, а не на количестве нанятого персонала. А на количестве сказываются другие факторы. Тот же вздутый и усиленный ковидом массовый найм джунов на космические зарплаты, а сейчас схлопывание этого пузыря. При всей очевидности искуственности раздувания и естественности в схлопывании, наверняка найдутся умники чтобы связать сокращение наймов с чатгпт )))
До сих пор никакой корреляции между ростом продуктивности и снижением количества разработчиков не было, хотя на каждом витке развития средств разработки об этом начинают писать тонны статей. Иначе программистов должно было бы сейчас быть меньше чем в 2000-м.
Про basketId - вот не всегда, особенно если это сущность из базы. В БД часто из-за объединений в таблицах делают явные имена полей и их лучше и в коде такими оставить. Также часто бывает, что тип ид это что-то известное, типа cardId какого то, а сущность типа CartHandler синтетическая, и лучше оставить некоторую избыточность, но узнавабелтность. Но статья хорошая много тем закрывает, но 99% назовут поле с ИНН inn, а не tin и будут правы, если софт для России. Всё же главное это конвенции и простота и однозначность прочтения.
Хотя я выше и написал кому то что переменные надо на английский переводить для того чтобы код читаемый был. Но когда такие комментарии как ваш вижу... Так и хочется спросить кто вы такой в плане экспертизы? Что отправляете флагманскую и вполне рабочую бухгалтерию в ад и не считаетесь с очевидным - есть 100500 продуктов и сайтов и API, в российском сегменте, где есть ИНН. В 99% поле будет называться inn, а не tin, потому что это самое читаемое для всех и понятное. Также и "физлицо" многие обозначат как FL, и не будут морочаться с Person, Human или Individial. Кроме вашего мира радикального есть ещё и практика реальная, в которой много конвенций.
Магия?
До сих пор не понимаю чем это отличается принципиально от того чтобы взять любой уже готовый образец на гитхабе, перебить название например на "болгенос" и выдать за новую программу. То, что столько программистов из за этого боятся потерять работу доказывает только одно, они не програмисты, а копирасты, которых легко заменить даже не gpt, а ботом поверх стековерфлоу. И второй момент, допустим сделают робота футболиста который в 100% случаев запинывает мяч от своих ворот до ворот соперника мощнейшим пушечным ударом, неужели это как то повлияет на популярность человеческого футбола со своими звёздами и борьбой? Наличие пушек например даже не смогло уничтожить соревнования по стрельбе из лука, а кто-то даже пращей увлекается. Естественно я могу не осознавать всего величия gpt. Но скорее всего через год он просто станет рутиной с очень ограниченным практическим применением, а хайп будет вокруг какой-то новой игрушки.
Улыбнуло что make это баш. Тогда и yaml для Хелм чартов тоже баш, раз туда можно баш команды вставлять и вообще что угодно "тот же баш")))
Не знаю о чем статья. Работаю в IDE за 0 евро. Idea ce, vs code. При этом часто особенно для голанга для сборки использую старый добрый мейк, который вызываю во встроенном в ide терминале. Я вот в итоге и не знаю, автор бы меня похвалил или предал бы анафеме???)))
Ну товарищ про микро сервисы пишет надо полагать в заголовках http или метаданных grpc
Какого такого сотрудничества с США и их вассалами вы жаждите? К какому такому открытому интернету аппелируете и взываете? Из детского сада я смотрю куча комментаторов. Патч не приняли и фиг с ним, ещё поди разбери что там первичнее политота или качество патча. Главное что противная сторона пока не имеет серьёзной возможности закрыть основной форк ядра, значит при необходимости можно спокойно вести свой с патчами для того же Байкала. Так как Байкал не особо бытовой, а в основном для военных всяких нужд, к нему так и так делается отдельное ядро. Да есть риск что разъедутся ветки, но блин так и ядерной войны не хилая вероятность есть.
Но опрос то проведён здесь и сейчас и много где C++ незаменим, например в геймдеве серьёзном. Понимаете некоторые вещи не заменимы не потому что ничего нет что выполнило бы их функцию, а потому что никто и не пытается их менять,
Претензии не к idea а отсутствия как такового встроенного тулинга. Если не работаете с новым поколением языков типа go где всё типовые вопросы а-ля тестирование, пакетныйменеджер, профилирование, авто форматирование, линтинг, покрытие, кодогенерация и прочее идёт из коробки и очень простое, то вам сложно понять что не так с Java или C++. Настройка авто сборки того же голанга пара простых команд в makefile. Адекватная же сборка на gradle, npm, CMake, это уйма копипасты или тайных знаний и привлечения всякого набора внешних средств.
Если для Вас ЭТА задача является "спортивным программированием", то задайтесь сами вопросом - Вы точно представляете себе чем занимаются компании которые набирают именно программистов для разработки софта, а не сопровождением легасных телеграм ботов и сайтов на ванильном PHP?
Знаю, что наберу минусов. Но мне лично как-то без разницы.
Очередная отличная статья, написанная о собеседовании со стороны собеседующего, а не со стороны стоноты, который бегает собеседуются, а его ""мучают", "не берут" и вообще все вокруг идиоты, а он такой молодец".
И опять человек в 100-й раз Вам пишет, как писали многие до этого, что вся соль на собеседовании в умении задавать вопросы и рассуждать, а не в Ваших хардскиллах, к тому же фальшивых, если под ними нет базы.
Когда на работу берут например строителя в бригаду прежде всего смотрят не то как он пользуется лопатой - этому научат.
На что смотрят:
1. кто по национальности и вере и где родился, чтобы не оказалось, что у тебя в бригаде потом на этой почве поножовщина с другими
2. что по пьянке
3. что набито на руках и спине
4. кто его знает, кому позвонить спросить кто такой
5. может наличие хоть какого-то документа
6. отсуствие признаков внешних каких-то явно нездоровых в части психики
Вот что будут смотреть. И программистов это касается в полной мере. Собеседование это не про "лопаты", а про "наколки"
Если вы идете программистом, то только тимлиды, не уважающие свой коллектив и работу и сами не имеющие квалификаций будут проводить интервью только по хардскиллам и только ровно по тем, что именно сейчас в работе. Вот кто тут жалуется в комментариях и негодует я скажу следующий чеклист в компаниях где действительно есть комманды разработчиков и они разрабатывают
1. если у вас стремные софты - это перевесит в итоге хорошие харды, хотя если софты хорошие это не значит, что они перевесят отсутствие хардов
2. умение мыслить - важнее гораздо готовых знаний
3. умение задать вовремя правильный вопрос - важнее чем готовые ответы
4. умение действительно справиться со стрессом - важнее чем показное веселье или напускное спокойствие
5. и да - такие простенькие задачи на алгоритмы (простые в плане что условия понятны, кода точно много не требуется и легко в голове прикидывать на числах типа 1,2,3) - надо решать до какого-то хотя бы уровня, хотя бы на хэшмапах - а ведь не все кандидаты даже это в состоянии предложить!
И только потом будет хоть какое-то разделение по уровням компаний и их требованиям. Я сам не знаю до какого алгоритма сам бы дошел если бы на собеседование попал, но когда сам собеседую - мне в принципе в большинство команд годятся люди там второго примерно уровня сложности (по автору задачи) ну то есть чутка оптимизированее чем хэшмапы. И я бы не стал слишком спрашивать сильно за расчет О. А может в какую-нибудь другую команду они хотят видеть тех, кто умеет это хорошо считать и глубже анализировать.
Если Вас это бесит - значит просто ВЫ не годитесь в эту команду, а команда и без ВАС спокойно проживет. Не хотите никаких требований на собесе? Идите работать на галеры - там Вас ни о чем кроме имени Вашего не спросят.
А мне лично только с такими и нравится работать действительно по-настоящему, кто видит глубину в работе и что есть всегда не один только какой-то очевидный вариант.
Вопрос не то чтобы плохой, скорее он симптоматичный. Но надо понять симптом "чего" - не понимания постановки? просто невнимательности? переусложнения?.
Я бы ответил на такой вопрос "поясните, не совсем понял, мне казалось в задаче все прозрачно, может я чего-то не замечаю?"
Далее варианты такие
1. человек вчитывается и говорит "а тут N+1, а числа тоже 1..N", ок тут точно хотя бы 1 повтор - это мелкий залет совсем, такой на тему "резиновой уточки"
2. человек говорит "тут может быть ловушка с типами данных, например равен ли float64(2.0) числу int32(2), потому что хотя с точки зрения математики - это все еще целые числа, для кода это все же нечто различное" - я бы понял, что этот вопрос результат некоторого избыточного усложнения, с другой стороны ничего некорректного в этом нет. Я бы сказал в ответ, что тип не имеет значения, важна только "чистая математическая сторона" int(2)==float64(2.0) - это я не буду считать залетом
3. человек просто перечитывает задачу и говорит - "ну тут вообще нет никакой информации - есть там повторы или нет" - залет - просто не умеет читать условия в абстрактном представлении с - N там, множествами и прочим - признак конкретного мышления или очень и очень неподвижного мышления
То есть меня устроит вариант - что он просто понял, что там есть повторы или вариант 2 с каким-то усложенением, меня не особо напряжет вариант 1 и очень напряжет вариант 3.
Если автор рассматривал этот вопрос только как вариант 3 - то кончено это очень плохой вопрос.
Ну наверное на собеседовании не один такой вопрос используется. К тому же опять какие-то "оба знают алгоритмы, как выбрать". А я Вам скажу как - HR спросит у тимлида - кто тебе в целом больше понравился, с кем работать готов? - а тут не может уже быть совсем двух равных кандидатов
Молодой человек, видимо не проводящий сам собеседования. В этих вопросах и есть самая соль. Я часто задаю что-то что человек ЗАВЕДОМО не знает из серии "у нас была такая-то проблема и мы умудрились ее решить, проломав всем коллективом голову месяц, можете сейчас за 10 минут каким-то образом предложить решение?" и смотрю только на вопросы и на направление мыслей. Умение в таких ситуациях отбрасывать из головы лишнее, сосредотачиваться на проблемах и ограничениях, умение задать точный и действительно что-то значащий для выводов вопрос и при этом не терять присутствия духа - это и есть тот кандидат, который мне предпочтительней того, у кого этих качеств нет, даже если он более хард-скилловый в данный момент времени. Потому что хардскиллы нарабатываются со временем, а вот эта общая способность размышлять, коммуницировать и справляться со стрессом - нет
Хотите переведу?
```kotlin
enum class DayTime { Morning, ... }
val names = DayTime.values().map{it.name() }
```
А то что в джаве jit и уже давно вы тоже не слышали? Так то с 1999 года
Ну то есть вы сами подтверждаете, что само по себе наличие библиотек уже готовых, софта уже написанного и каких то чудо тулзовин сказывается на специализации, а не на количестве нанятого персонала. А на количестве сказываются другие факторы. Тот же вздутый и усиленный ковидом массовый найм джунов на космические зарплаты, а сейчас схлопывание этого пузыря. При всей очевидности искуственности раздувания и естественности в схлопывании, наверняка найдутся умники чтобы связать сокращение наймов с чатгпт )))
До сих пор никакой корреляции между ростом продуктивности и снижением количества разработчиков не было, хотя на каждом витке развития средств разработки об этом начинают писать тонны статей. Иначе программистов должно было бы сейчас быть меньше чем в 2000-м.
Про basketId - вот не всегда, особенно если это сущность из базы. В БД часто из-за объединений в таблицах делают явные имена полей и их лучше и в коде такими оставить. Также часто бывает, что тип ид это что-то известное, типа cardId какого то, а сущность типа CartHandler синтетическая, и лучше оставить некоторую избыточность, но узнавабелтность. Но статья хорошая много тем закрывает, но 99% назовут поле с ИНН inn, а не tin и будут правы, если софт для России. Всё же главное это конвенции и простота и однозначность прочтения.
Хотя я выше и написал кому то что переменные надо на английский переводить для того чтобы код читаемый был. Но когда такие комментарии как ваш вижу... Так и хочется спросить кто вы такой в плане экспертизы? Что отправляете флагманскую и вполне рабочую бухгалтерию в ад и не считаетесь с очевидным - есть 100500 продуктов и сайтов и API, в российском сегменте, где есть ИНН. В 99% поле будет называться inn, а не tin, потому что это самое читаемое для всех и понятное. Также и "физлицо" многие обозначат как FL, и не будут морочаться с Person, Human или Individial. Кроме вашего мира радикального есть ещё и практика реальная, в которой много конвенций.