Check Levi9 best QA positions to Backbase team!
×Закрыть

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

Работаю программистом уже достаточно долгое время (6+ лет). За это время набрался неплохого опыта в разработке веб приложений на Java с использованием Spring, Hibernate и прочих технологий. Успешно работаю на проекте, перформлю хорошо ... но ...
когда на каком-то из собеседований меня попросят решить простую алгоритмическую задачку например смерджить два отсортированных массива в один — я впадаю в полный ступор, особенно в местах, где требуется итераци по эллементам массива и инкрементация всяхих i-тых, j-тых. Причем самое интересное, что когда прихожу домой и пытаюсь решить эту задачку дома, то на бумаге решение нахожу относительно быстро, но имплементировать могу день, два, три — не меньше.

Хочу спросить у коллег :
1. Сталкивались ли кто-то с подобным — что определенная область знаний в программировании дается с очень большим трудом?
2. Стоит ли мне париться насчет этого и все таки вкладываться в эту область или забить прокачивать то, что получается?

Спасибо.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Работаю программистом
Скорее занимаешь должность программиста.
я впадаю в полный ступор, особенно в местах, где требуется итераци по эллементам массива и инкрементация всяхих i-тых, j-тых. Причем самое интересное, что когда прихожу домой и пытаюсь решить эту задачку дома, то на бумаге решение нахожу относительно быстро, но имплементировать могу день, два, три — не меньше.
Два года физ-мат лицея мы решали такие задачи по десятку в день, причём как на листиках, в блок-схемах, так и на разных языках программирования, до аццкой тошноты. Вопрос практики.
1. Сталкивались ли кто-то с подобным — что определенная область знаний в программировании дается с очень большим трудом?
Это не область программирования — это есть сама суть программирования.
2. Стоит ли мне париться насчет этого и все таки вкладываться в эту область или забить прокачивать то, что получается?
Конечно, не стоит вкладываться. Плыви по течению, оно скоро вынесет тебя в Днепр, главное пройти запорожские пороги, дальше будет легче и сплав практически будет закончен.

Сильно удивлю, но в реальной жизни ты просто берёшь готовую реализацию и вызываешь библиотечную функцию. В действительности это напоминает школьную алгебру и геометрию. Если тебя сейчас попросить воспроизвести теорему косинусов или формулу Герона, ты этого не сделаешь. Но это не значит что тебя надо отправить в 9 класс. Но почему-то для собеседований берут не реальные задачи, а из специального справочника «Параноидальная шизофрения, звёздные болезни, задачи для собеседований.»

была та же фигня, ужасно бесило. Прошла курс Сэджвика на курсере, теперь таких проблем нет. Все качается, нужно только начинать с основ и тренироваться. Никто с этим не рождается. Если чувак может такую штуку сходу запилить — это означает только то, что он потратил N часов отбивания на клавиатуре подобных задач. И все. Никакого скрытого таланта и математического мышления. Проверено на домохозяйках без технического ВО, кстати.

Забей. ИТ это как медицина.
Тут пасутся от психологов до ветеринаров.
И сколько бы тут хирурги не сокрушались, в медицине есть место даже для гомеопатии.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

У меня, в бытность мою уеб-девелопером, редко когда возникали алгоритмические задачки.
Когда стал писать библиотеки финансовой математики на голых плюсах (причем нельзя даже было использовать stl, чтоб код компайлился и на мэйнфреймах), таких задач возникало много*.
Когда основным занятием стал анализ временнЫх рядов в R, алгоритмических задачек опять стало меньше, ибо в R уже имлементированы ну буквально все алгоритмы.
Хотя нет, все-таки не все, но сегодня стало на один больше :)
letyourmoneygrow.com/...​rt-and-resistance-levels

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

*была своя недоверсия stl, написанная с нуля.
Ее я тоже дорабатывал, заменил quicksort на heapsort, т.к. первый давал stackoverflow на больших массивах

В Україні для проходження стандартної співбесіди копатися глибоко в алгоритмах не треба, це зрозуміло. Але ж, блін, це ж цікаво, це ж вчить думати, ви ж перестаните вирішувати проблеми «в лоб». Радує, що зараз купа студентів цим цікавиться. Займаються алгоритмами як хобі) Я з Kyiv Algorithms Club, і судячи з акривності (не тільки студентів) тема в Україні буде розвиватись. Рекламана пауза))) Осьо наш клуб www.facebook.com/...​5610171/?active_tab=about

Ну раз отрекламировался на ДОУ, то подкину я вам алгоритмическую задачку:
Есть два множества в R^N. Нужно найти наилучшее нечеткое соответсвие между ними. Нечеткое в смысле, что не все объекты из первого множества будут во втором. Во втором множестве векторов больше, чем в первом. И совпадающие вектора из первого множества не равны векторам из второго, но по некоторой метрике достаточно близки. Для упрощения и евклидова пойдет.
Да, это задачка не на готовые решения, а на подумать и не только тебе, а всему вашему клубу. Мне кажется, что если что оригинальное придумаете, то и публиковаться в приличном месте с таким можно.
Простейший KNN скучен.
Лично я пока заюзал KNN и RANSAC с точки зрения быстродействия. Но у ранзака есть большой минус — он часто выдает ошибочные решения (что понятно из собственно его самого).
В реальной задачи есть обеъкты, описываемые вектором и их координаты. На первом шаге KNN по вектору описания, на втором ранзас для позиций.

Ладно расскажу решение. Венгерский алгоритм, но и он уже прилично тормозит от 100 объектов.

такі задачки — це як грати гами для піаніста — їх треба робити на автоматі. для цього щодня рішайте хочаб одну задачу на codeeval , codeabbey і т.п. і через рік питання зникне, а свій код будете пистаи швидше і якісніше.

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

имхо, типы мышления программистов (позволю себе немного адаптировать Колмогорова)
— алгебраический
— топологический (геометрический)
— порядковый (я бы назвал его алгоритмическим)
— ну, и еще «вайти в айти» в наших палестниках

------
люди первых двух типов тяготеют к ФП. для них естественным примитивом будет функция (и вот оно лямбда-исчисление).

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

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

люди первого и второго типа — это программисты-математики. их место — неистовые R’n’D, инновации, симпозиумы и scientific papers. эти люди не будут выслать на галере, если им не очень интересно. они также могут быть хорошими архитекторами, если станут чуть ближе к народу. рядовые алгоритмические задачи воспринимают как унылую рутину, от цикла for нос воротят (иногда это правильная реакция).
------

люди третьего типа — это именно программисты. они лучше шарят в деталях языка и часто быстрее (но не лучше) решают алгоритмические задачи. математический часто бэкграунд ограничен базовым матаном из универа и простой дискреткой.
зато с точки зрения бизнеса и коллег эти люди ЛУЧШЕ программируют, они любят ООП, используют элементы ФП, их код понятен, они редко что-то изобретают. главный скилл — огромный объем знаний в области компьютеров вообще и предметной области в частности, сильная инженерная интуиция и отсутствие нездорового перфекционизма.

именно на таких рассчитаны гуглоподобные собеседования — только матчасть и алгоритмы + пару вопросов по дискретке (в нашей реальности обычно дальше школьной комбинаторики/графов дело не идет, ибо теорвером часто не владеют даже god senior executive architects, а зашквариться на собственном интервью стремно), мат логике и теории вычислимости. часто из них получаются девопсы уровня БОГ.
-------

вайти в айти не всегда хуже — по началу, они даже кажутся лучше. пока не произойдет ЭТО — тот случай, который отличает человека с головой от человека с пиццей. обычно это нестандартная задача и жесткий факап колллеги, который надо элегантно исправить. главный скилл вайти в айти — количество фреймворков и конференций. that’s it.
-------

мораль. дорогой ТС, надеюсь, мой скромный субъективный alignment поможет вам определить свое место среди сыроедов элиты нации и прокачать те скиллы, которые хорошо соответствуют вашей интеллектуальной конституции.

удачи вам во всем! :)

люди первых двух типов тяготеют к ФП. для них естественным примитивом будет функция...
тяготеют к слишком абстрактному коду...... но очень читабелен
Шо? Читабелен очень ? Помоему вв этой цитате взаимоисключающие параграфы...

спасибо, что написал, а то я думмал это я совсем аутист в ит

ты аутсайдер и неудачник, а у аутистов с алгоритмами как раз все ок обычно

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

Алгоритмы разрабатываются для более эффективного решения задачи. Решения «в лоб» могут иметь плохие последствия в будущем. Не на стадии прототипа, а когда уже все сделано и работает на продакшене. Готовые решения под конкретную ситуацию могут не подходить, либо может быть какой-то нюанс, который готовое решение не учитывает. Так же у использования готовых решений может быть недостаток — «Leaky abstraction», вот пример про ML: medium.com/...p-e2f06eab496b#.ulmz4e4d4 .

Поэтому потихоньку вкладываться стоит. Нужно изучить:
— методы разработки алгоритмов
— основные идеи известных алгоритмов (решения и идеи могут повторяться между задачами)
— структуры данных

Ох привели пример с бекпроп...
В МЛ есть несколько вещей которые надо помнить алгоритмах, и бекпроп тому пример. Но даже в МЛ вы тот же SVM имплементить не будете надо понимать что он делает и что функции для kernel могут быть разные.

Да, алгоритмы решают задачи с разной эффективностью. Но все что вам нужно знать это асимптотическую сложность алгоритма — на этом как правило все в 95% случаев, а оставшиеся 5 процентов не имеют значения ибо с задачами на алгоритмы в современного айти вы будете встречатся как правило раз в пятилетку, а на собесах это только яйцами померятся

Знания структур данных и алогритмов, к слову, очень полезны в highload проектах, например я как-то оптимизировал web-crawler (ходит по страницам и считает ссылки) по памяти просто заменив HashMap на Trie. В результате можно было оный ранить на меньшем количестве нод.
Почему-то об этом здесь забыли и обсуждают только в разрезе собеседований.

Для большинства это очень редкий кейс

это тож нужно, но немного другое, так как готовых реализаций HashMap и Trie — полно.

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

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

А сколько вообще знаний используется из принудительно полученных в школе и ВУЗ-е?
Может сразу человека на работу?

Если хотите набить руку — практикуйтесь codility.com/programmers/lessons и/или www.hackerrank.com

Этот навык редко нужен в повседневном корпоративном Java программировании, но если хочется — почему нет?

Сильно удивлю, но в реальной жизни ты просто берёшь готовую реализацию и вызываешь библиотечную функцию. В действительности это напоминает школьную алгебру и геометрию. Если тебя сейчас попросить воспроизвести теорему косинусов или формулу Герона, ты этого не сделаешь. Но это не значит что тебя надо отправить в 9 класс. Но почему-то для собеседований берут не реальные задачи, а из специального справочника «Параноидальная шизофрения, звёздные болезни, задачи для собеседований.»

но в реальной жизни ты просто берёшь готовую реализацию и вызываешь библиотечную функцию.
Помню на одном собеседовании попросил куски кода из проекта(c#, desktop+web) для ознакомления и там была кастомная реализация коллекции. Так что не надо обобщать. И судя по
я впадаю в полный ступор, особенно в местах, где требуется итераци по эллементам массива и инкрементация всяхих i-тых, j-тых.
, дали бы ТСу задачу написать такую же коллекцию проект затянулся бы на пару лет. Мердж 2-х массивов это не олимпиадные задачи, которые и вправду идиотизм давать на собеседованиях.

Как раз по итерации i-тых и j-тых — самое простое и удобочитаемое решение. Явно легче понять чем
myData->magicWord()->magicWord()->magicWord()->magicWord()->killThemAll();

А кастомная реализация коллекции наверняка имеет своего не такого уж и кастомного родителя. Обычно коллекции делать кастомными моветон, чаще кастомайзят сам элемент.

Вот деревья — те да, просто таки рождены для кастомизации, это их природа — принятие решений в каждом узле.

Как раз по итерации i-тых и j-тых — самое простое и удобочитаемое решение. Явно легче понять чем
myData->magicWord()->magicWord()->magicWord()->magicWord()->killThemAll();

Если набить руку в том, что люди называют «фп» — может выясниться что это не так.

Если набить руку в том, что люди называют «ф..п», то и девушка не нужна.
А речь идёт только об удобочитаемости кода, и радикальном снижении вероятности ошибок как следствие. Доводы же типа «набить руку» граничат с фанатизмом, можно и в машинных кодах сразу писать, чего уж там. Вот только эта вся «магия» удорожает разработку в разы!

Несогласен. Суть в выражении целого набора команд меньшим количеством слов.
i,j — это игра с изменением состояния. Если систематизировать различные измения состояния, так же как «паттерны» систематизируют различные варианты взаимодействия объектов, то на выходе получиться ФП.
Но в конечном итоге — меньшое количество слов = меньшая ментальная нагрузка на то чтобы увидеть картинку целиком, или пропустить баг.

Как раз наоборот. 90% узнаваемых шаблонов — это тот нижний предел, при котором информация перестаёт восприниматься и вызывает депрессию, с целью задействовать ещё большее количество шаблонов памяти аж пока не будет достигнута узнаваемость. Иначе говоря, мозг должен уже у себя поднять итерации, и куда более тяжёлые, сложные и неимоверно медленные — просто чтобы прочитать. Не говоря уже о том, что мозг не имеет логики — только шаблоны, и среди плохо узнаваемой картины найти то что ей несоответствует — задача адская, и может затянуться на годы (бывали прецеденты).

Машине глубоко до одного места, в сколько слов это будет записано. Проблема в stateless-подходе, который противоречит модели мозга, которая stateful везде где только можно. Например, пройти по бордюру — проблем не вызывает, задача для 4-летнего ребёнка. Но по краю крыши на высоте 9-го этажа — тоже без проблем для паркуриста. Но для абсолютного большинства людей она закончится предсказуемо — отказом это делать. Так и с кодом. Тот кто пишет код для профессиональных паркуристов, которые натренировались своему стилю — в разу удорожает проект и тем более его сопровождение. Иначе говоря, чтобы заработать на этом программисте, его нужно уволить, написав отличные рекомендации чтобы его взял конкурент.

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

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

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

Проблема в stateless-подходе, который противоречит модели мозга, которая stateful везде где только можно.

На практике нет никакого stateless. Миф для дурачков. Просто управление стейтом делается не на прямую через оператор присваивания.
Например, пройти по бордюру
Странная аналогия.
Я больше вижу аналогию с умножением чисел (без калькулятора), — чтобы умножить два числа, проше всего циклически прибавлять число. Однако, если выучить на память таблицу умножения, и правила по кторым большие числа умножаються — результат получиться более эффективным.

Ну давай, умножь в уме 378 на 612, и расскажи потом про stateless. Только не говори что это для тебя проблема.

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

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

А ведь задача элементарная. Буквально строчка кода. Которой можно сломать весь проект.

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

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

Умножь 378 на 612 тем методом, как ты это делаешь в уме. Просто в качестве примера абстрактной задачи, где два однотипных объекта представлены последовательностью и обрабатываются нелинейным алгоритмом.
Как ни странно, задача «кратко» — решаема. Но я акцентирую, чтобы алгоритм был тот, которым в уме, это критически важно для понимания кода. Задача не является кратко и однозначно описываемой, то есть нельзя где-то в сторонке создать метод умножающий два числа. Нужно именно инлайново.
Хочешь на Хаскеле — пиши на Хаскеле, чай не операционка, разберёмся. Задача исключительно в удобочитаемости. Напиши так, как написал бы человек уже лет 10 занятый программированием.

Ты же понимаешь, что если задашь такую задачку на собеседовании, то будешь послан.
-Задача уже решена максимально эффективно в любом компьютере.
-Вопрос эффективного перевода человеческого представления чисел в машинное. Человеку не составляет труда разделить число на «масив чисел», просто расчленив 378 на 3 7 8.
В машине же нужно выполнить кучу действий, циклически умножать и делить на 10, для того чтобы в конечном итоге сэмулировать умножение? Вообщем любой

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

Что и требовалось доказать. А теперь взгляни на объём комментов, и попробуй хотя бы допустить мою точку зрения — что краткость не есть самоценно. Скорость восприятия важнее. Она же даёт скорость написания.

// Умножить 378*612, как сказано здесь.
int[] a=[300,70,8];
int[] b=[600,10,2];
int sum;
sum+=a[0]*b[0];
sum+=a[1]*b[0];
sum+=a[2]*b[0];
sum+=a[0]*b[1];
sum+=a[1]*b[1];
sum+=a[2]*b[1];
sum+=a[0]*b[2];
sum+=a[1]*b[2];
sum+=a[2]*b[2];

Да, такие алгоритмы имеет смысл записывать более компактно. Но попробуй только сказать,что:
— ты не понял, что он делает;
— тебе придётся перечитывать весь код, чтобы это понять;
— если есть подозрение на ошибку, её будет сложно найти;
— этот код сложно будет протестить в боевом исполнении, когда переменные задаются к примеру параметрами функции, строковыми константами для карты данных или же идентификаторами сущностей на стороне базы;
— найти ошибки обычным просмотром сложнее чем тестировать.

Упоротая задача, упоротое и решение.
Попытка оформить рассказ языком программирования накшталт
class MyLife[...]
Плохо имеет отношение к чему либо вообще.
Всеже если рассматривать в таком стиле, в чем проблема написать


final int sum =a[0]*b[0]+
a[1]*b[0]+
a[2]*b[0]+
a[0]*b[1]+
a[1]*b[1]+
a[2]*b[1]+
a[0]*b[2]+
a[1]*b[2]+
a[2]*b[2];
?

Во-первых, потому что задачи «упоротые» не только лишь все. Во-вторых, нужно читать условие задачи: не перемножить конкретно 2 числа, а на примере этой достаточно понятной задачи реализовать именно тот алгоритм, которым умножают в уме. Критерий достаточно понятный?

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

Это я и пытаюсь доказать. Не «состояние» требует мозг для удобоваримости, но локализацию объектов памяти, сокращения нужды в памяти и возможность данные «подгрузить» не затрачивая память на задачу нахождения места откуда грузить.

По сути, это и есть ООП. Не реализация всего в одной точке, но локализация объектов для понимания кода. В частости, локализация имён, право именовать приватные данные как угодно, и разумеется удобство комментирования данных и манипуляций с ними. Иначе говоря, свобода как осознанная необходимость.

А ещё нужно уяснить, что забывается всё. Абсолютно всё, даже самые казалось бы очевидные вещи. И хочешь того или нет, но придётся читать свой «чужой код», и весьма плачевно пытаться вспомнить а что же собственно хотелось.
______________
Лично я считаю, что будущее программирования — это когда код можно будет форматировать как обычный текст, вставлять в него картинки и гиперссылки, скрывать под кат, цитировать и ссылаться на фрагменты. И я не исключаю даже, что код будет содержать туеву хучу обсуждений (ссылкой на сторонний ресурс, разумеется). И умение кодить будет сродни умению объяснять.

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

Иначе говоря, по сей день код есть примитивный текстовый файл. Это создаёт проблемы при его чтении, и фактически способы хранения информации не относящейся к коду — очень слабо регламентированы, если вообще регламентированы.

Самый простой пример: комменты невозможно отделить от временно закомменченного кода.

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

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

Однако это половинчатое решение. Нужно в самом языке создавать управляющие конструкции именно под документирование и тесты. Хотя бы по той причине, что это солидный процент кода. А код пока он пишется, пока не завершён — имеет раза в 3 больше документации, особенно если это код не тривиальная шаблонка.

А ведь ничего фантастичного по сути.
Ну как же? Это, извини, уже уровень ИИ в широком смысле.

Уже было несколько попыток на моей памяти и ничего не получилось.
Причем даже никто не встроил отображение теха в комментах. Хотя проблема соответствия кода комментам в этом случае даже не затрагивается.

Это уровень «настолько просто, что всем лень». Когда-то и книги были без картинок, и буква ё без точек.

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

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

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

А он работает чуть-чуть не так, как ожидалось. Причём выясняется это после того, как уже запилил в проект. Новый искать и прикручивать слишком долго и дорого, нужно просто пофиксить...

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

Ладно, говоришь сможешь? Ну пиши кусок кода, а я потом дам массивы и посмотрим что выйдет.

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

Никто и не говорит давать весь проект. Дать частичную задачу: кусок реального кода, небольшая рихтовка под задачу, и к примеру написать функцию.

А задачи дают по принципу «они же простые». Да, простые. Когда тести попугай, прочитавший готовый ответ, и считающий его единственным.

была та же фигня, ужасно бесило. Прошла курс Сэджвика на курсере, теперь таких проблем нет. Все качается, нужно только начинать с основ и тренироваться. Никто с этим не рождается. Если чувак может такую штуку сходу запилить — это означает только то, что он потратил N часов отбивания на клавиатуре подобных задач. И все. Никакого скрытого таланта и математического мышления. Проверено на домохозяйках без технического ВО, кстати.

на твоє питання є дві відповіді

1. Це ази, це треба знати.
2. Це окремий скіл який зараз нікому крім інтерв’юверів не потрібний.

обидві відповіді правильні:

1. Так, це дійсно ази, і так це дійсно треба (ну хоча б бажано) знати. Так є місця де такі навички можуть реально знадобитися — алготрейдінги, низькорівневі задачі, ембедед і тд. Якби це не було потрібно зовсім то ніхто б і не вимагав.

2. Так, це окремий скілл який в більшості випадків для ентерпрайза і веба не потрібний, оскільки з таким стикнутися в цій сфері малореально. Більш того, наявність такого скілза в даній сфері взагалі мало що показує чи доводить.

Мабуть єдиний нормальний вихід — як уже радили вирішуй задачі(коділіті і йому подібні) і качай скілл, якщо працюєш з джавою то в роботі не згодиться, але на співбесідах може допомогти, зайвим так точно не буде. Якщо забити і не качати то в цілому поганого нічого не станеться але кількість потенційно добрих місць для роботи обмежиш.

А что давайте спрашивать алгоритмические задачки на собесеах и тогда свитчеры и вайтишники начнут рвать на себе волосы. Западные коллеги это уже давно просекли, кстати.
А выучить это не тяжело, просто прорешайте 100+ задач на hackerrank и leetcode.

А что давайте спрашивать алгоритмические задачки на собесеах и тогда свитчеры и вайтишники начнут рвать на себе волосы. Западные коллеги это уже давно просекли, кстати.
Тут вопрос в другом. Есть проект, сколько стоит нанят человека на проект? Обычно стоит это хорошую копеечку, ему платят зарплату за разогрев и т.п. Максимальную мощность человек покажет через 4-6 месяцев, когда вникнет в существующее положение вещей и т.п. Можно просто нанять толкового человека, разбирающегося в базовых вещах, которого потом можно бросить на любой другой проект, а можно просто достаточного для здесь и сейчас. Вот и прикидываем, компании банально не выгодно нанимать человека, умеющего отделять бананы от яблок, потому что на конвеере могут попасться и груши со сливами, человеку банально не выгодно, что после окончания проекта его не выставят на мороз. А в условиях украинского аутсорса может такое случиться, что тебе скажут, спасибо, ваш профиль больше не нужен, можете самовыпиливаться.
которого потом можно бросить на любой другой проект
This, на собеседовании хорошо определять достаточно ли человек задрот. Вот программисты вашего возраста это хардкорные нерды по сравнению с модными бородачами frontend developer’ами. Как минимум, потому что Кнута не читали, алгоритмы и математику не то что не помнят, а даже и не учили.

Среди старшего поколения, ~50 лет, действительно можно найти читавших Кнута. Mike Gorchak на этот вопрос сможет лучше меня ответить.

Я просто предпочитаю различать читавших, дочитавших, перерешавших )))

Я ещё не дорос, мне только 38 :) Но Кнута второй том (ещё старого трёхтомного издания) прочёл и заимплементировал когда мне было 26. Но дело не в возрасте, а в специфике украинского аутсорса, до тех пор, пока обезъянки будут радоваться высоким зарплатам и низким порогом вхождения для псевдо-программистских задач, они всё глубже будут продолжать погружаться в эту болотную трясину. Уже за Украиной стоит слава low-tech страны, как только окончательно пройдут точку невозврата, будет сильнейший обвал зарплат, иммигрировать они не смогут, т.к. с такими скиллами они никому не будут интересны, будет несколько сот тысяч ртов, которые будут радоваться любой работе за любой прайс ... филиал Индии в Восточной Европе. Для сравнения даже далеко ходить не надо, взять хотя бы Польшу, которая хайтеком высасывает остатки классических программеров из Украины. Мы радуемся, что мы аутсорсер лоу коста N1 в Восточной Европе, даже круче поляков, только Польша N1 R&D центр в Восточной Европе с количеством программеров в 1.5-2 раза превосходящая Украину при том же количестве населения. Мы радуемся как дети, что к нам заходят аутсорс проекты со всего мира, а поляки радуются, что у них открываются R&D офисы со всего мира — Google, Siemens, Delphi Automotive, Intel, General Electric, Motorola, Bombardier, Alcatel—Lucent и прочее.

Уже за Украиной стоит слава low-tech страны
Это вопрос пиара, но все таки, это в первую очередь из за того, что у нас high tech не востребован, в отличии от.
низким порогом вхождения для псевдо-программистских задач
Это всяких mobile, ecommerce, wordpress и прочий веб? Ну и формочки на Java/C#? Я правильно вас понял?
классических программеров
Мне понравился термин. Лучше чем тру/не-тру.
Это вопрос пиара, но все таки, это в первую очередь из за того, что у нас high tech не востребован, в отличии от.
Не совсем вопрос пиара, часто вопрос того, что делать такие задачи банально некому. Большие галеры имеют статистику, сколько проектов не зашло только потому что некому их делать.
Это всяких mobile, ecommerce, wordpress и прочий веб? Ну и формочки на Java/C#? Я правильно вас понял?
Например, в Канаде, когда говорят software development подразумевают не то, что в Украине, поэтому часто встречается такое сочетание как software and web development. Мухи — отдельно, котлеты — отдельно.
Большие галеры имеют статистику, сколько проектов не зашло только потому что некому их делать
Это уж точно, на моей текущей галере, мы получили классный новый проект, только благодаря лабе(внутреннему проекту) с микросервисами, докером и OpenCV.
Например, в Канаде, когда говорят software development подразумевают не то, что в Украине
А что там подразумевается под понятием software development?

К этому шли с начала 2000 по куче причин.

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

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

3. Ну а дальше по кругу. Да же если предлагается сложный наукоемкий проект, то делать его некому.

Кстати ровно такой пост я писал на старом Кывте еще где-то в 2003 году про 2015, сейчас я его просто повторил (по сути напомнил.)

И единственные виноватые в этой ситуации именно владельцы и директора лидеров рынка.
Кстати и сейчас в Украине и РБ, если говорить в среднем, то зарплата того, кто делает математику или эмбедера в среднем на 30-40% меньше зарплаты в жабе или жабаскрипте.
И такая вилка в разнице зарплат была все последние 20 лет.

З.Ы. И да восточная Европа правильно делает, что наконец-то перешла на R&D и начала выгребать спецов из постсовка. Через года 3-5 тут останутся программисты, что могут делать такие проекты только в возрасте от 50 (но производительность этих будет сильно сливать производительности 30 летних в той же Польше). Молодых не будет, потому как они продолжать сваливать сразу после ВУЗа или после школы.

Ага, фантастика с разделением стеной бедных и богатых уже не выглядит такой уж фантастикой.

И да восточная Европа правильно делает, что наконец-то перешла на R&D и начала выгребать спецов из постсовка. Через года 3-5 тут останутся программисты, что могут делать такие проекты только в возрасте от 50
Разделение идет, в результате которого страна станет сырьевым придатком. Уровень бедности будет повышаться, технологический уровень понижаться. Это делается искусственно и мы сейчас наблюдаем этот процесс. Обидно :)

И какое сырье у вас есть, чтобы стать сырьевым придатком кого-либо?
Ты не путай Украину с РФ.
В РБ хотя бы калийные соли есть, что китайцам нужны. Но в РБ их хватит ровно на то, чтобы обеспечить среднюю зарплату на уровне 20-30 баксов в месяц.

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

Это делается искусственно
Нет, это происходит само по себе. Вспомни про энтропию и как она проявляется в нашей жизни.
Но, я например, не знаю, что именно делают поляки, что к ним R&D приходит, а из постсовка сваливает все ускоряющимися темпами.

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

Может и энтропия. Как-то у вас все пессимистично получается.
Говорят конопля от этого помогает. Водка не работает, она только усилит депрессию.
А полякам просто подфартило, когда у них все политики разом гуфнулись в самолете какое-то время назад, это дало шанс, которого у нас нет.
Ну вы одних гуфнули сами, но другие, вами выбранные, не сильно другими оказались. Так что это метод у вас не работает.
в основном чернозем
Он имел значения в 40 года прошлого века. Сейчас при современных технологиях выращивания сельхозпродукции не так сильно он и важен. В Европе Поляки не знают куда впихнуть свою сельхозпродукцию — их у нее море.
У других стран есть вопрос с затоплением некоторых частей суши, у нас с этим проще.
Это даже не смешно. Посмотри на скорость поднятия поверхности океана. Лет через 20 может люди на побережьях что и заметят.

А да в отличие от вас в той же РБ есть еще один важный ресурс — пресная вода. Пока он экспортируется, но лет через 20 вполне может стать приличной статьей сырьевого экспорта.

Но, я например, не знаю, что именно делают поляки, что к ним R&D приходит, а из постсовка сваливает все ускоряющимися темпами.
Они делают стабильность и инвестиционный климат. Я когда-то тут писал, что мне ответили управленцы Renesas, почему они никогда не придут в Украину. Это работа и процесс, который будет длиться лет 10-15, нужна преемственность власти, государственная программа развития на годы вперёд, поэтому ни один пиздобол у власти этим заниматься не будет, т.к. не получится попиариться здесь и сейчас.

Могу только согласиться.
Вот пример из РБ. Есть такая конторка КБ Индела. Сами делают различные беспилотники, зарплаты нормальные. Но занимаются только разработкой собственно моделей и их мелким производством. У них работают рабочие и авиа-конструктора.

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

А почему не доложили об этом Рыгорычу? Он, по идее, мог бы вложиться, если вложения окупятся.

Он спонсирует только выращивание бульбы.

И единственные виноватые в этой ситуации именно владельцы и директора лидеров рынка.
О нет, виноватых тут много. Владельцы галер, конечно, виноваты, но отчасти, вторая часть вины лежит на тех кто орёт про популяризацию Украины, как выгодно сюда аутсорсить, те, кто делает курсы и штампует войтишников.

Ну мне он был просто скучен, ибо ничего нового я у него толком не вычитал. Да и его книжки появились гораздо позже того, как начал работать програмером. Так что это настольная книжка для тех, кому 35-40 сейчас.
Но, книжки у него хорошие и полезные.

Ну почитайте Кормена, он попсовее

А давайте спрашивать ЭЙЧАРОВ алгоритмические задачки, и те которые они не читали. И только после этого допускать к тестированию. То есть никогда.

Google search «IEEE Software Engineering Body of Knowledge COMPUTING FOUNDATIONS».

Знания, которыми Вы владеете полностью предопределяет то, ЧЕМ Вы занимаетесь.

Mike Gorchak прав насчёт «сплавления по Днепру».

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

Особисто мене напрягає коли на співбесіді з’являються запитання про переведення чисел з десяткової систему в бінарну або шістнадцяткову, а потом ще робити їм бінарні здвігі на певну кількість розрядів. За +5 років якось зустрічав на практиці таке лише пару раз.

Я в институте двойные интегралы решал, «як базис шкільного рівня», но держать это последующие 16 лет в голове без реального применения? То же и с системами счисления.

Ви шуткуєте? В CSS навіть для кольорів треба робити конвертацію HEX>DEC та навпаки. А бітові маски використовуються в повсякденному житті в правах доступу до файлів.

зачем? можно же всегда пользовать HEX

И что, это делается в уме/вручную? Не быстрее ли калькулятором или типа того? И меньше ошибок будет.

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

За +5 років якось зустрічав на практиці таке лише пару раз.
все залежить від галузі в якій працюєте, в Embedded — бітові операції і ссуви використовуються дуже часто, наприклад встановлення/очистка біта в регістрі/порті

Тоді я подавався в GameDev компанію

в геймдеві це маст-хев. звичайно, в нормальному геймдеві, а не просто посовати спрайтики по екрані.

Можна будь ласка приклад, для кращого розуміння?

З власного досвіду на С++:
— маски флагів (поставити/зняти флаг, перевірка чи маска включає флаг/набір флагів)
— перекодувати колір RGB888 <=> RGB565
— в шейдерах, коли потрібно пакувати дані, або «економити» на операціях

Если тема алгоритмов интересна то можно начать с «Структуры данных и алгоритмы в Java. Классика Computers Science — Роберт Лафоре» www.bookzone.com.ua/...ogue/catalogue_33009.html
Потом почитать «Алгоритмы на Java — Роберт Седжвик, Кевин Уэйн» www.bookzone.com.ua/...ogue/catalogue_36439.html
Ну и по ходу дела решать задачи. Например сайты Codeforces, Code Battle, CodeKata и т.п.

Сталкивался. Чтобы научиться решать алгоритмические задачки — надо их решать (ваш К.О.)
На собеседовании мешает фактор стресса, страха. Страх блокирует мозги, ты можешь забыть какие-то совсем простые вещи. С этим можно справиться только тренировками, например попросить приятеля устроить тебе «тестовое собеседование» . Пробовать самому делать простые задачи по кодированию на листке бумаги. Мы окружили себя умными IDE, и разучились писать код руками. На собеседованиях которые я проводил, многие кандидаты не могут написать решение тривиальной задачи, которое требует буквально 5 строк кода .

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

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

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

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

что-то вроде обряда посвящения, как дедовщина в армии и ритуалы в некоторых учебных заведениях.
Которая приводит к тому, что влияет на репутацию уже целой компании, в которых такая методика приживается. А потом что-то кандидаты на собеседование не идут, когда реально срочно надо.
я против того чтобы мучить людей на собесах, но с другой стороны если человек с 6 годами опыта работы не понимает счетчики в циклах — это печально
В 2017-м году это — нормально.
нужно как-то отсеивать тех кто не умеет писать код руками, и привык только копи-пастить чужое
А я думаю, надо отсеивать тех, кто принимает неочевидные архитектурные решения, не умеет пользоваться современным АПИ и плодит ненужные классы вместо использования стандартных механизмов.
Особенно, когда пишет свои сортировки с нуля из-за того, что не умеет пользоваться встроенными.
Как-то раз, когда мне в сотый раз предложили отсортировать массив, я не задумываясь ни на секунду о вставках-пузырьках написал Collections.sort();
Мне на это сказали, что так не интересно, на что я уже ответил, что дальше не интересно мне.
Нет, я могу потратить пару десятков минут и вспомнить реализацию всех этих методов сортировки. Но извините, текущая задача этого не требует.
Как-то раз, когда мне в сотый раз предложили отсортировать массив, я не задумываясь ни на секунду о вставках-пузырьках написал Collections.sort();
говорю тоже самое. Часто не понимают.
написал Collections.sort();
Когда писал тестовое так написал, как результат — не решенное задание :(

Я сделал довольно много тестовых. Часть из моих тестовых получались нерабочим хламом, часть работали и выглядели внутри более-менее. Но много было и грамотно продуманных решений с использованием подходящих паттернов и без излишеств, к тому же, вполне рабочих (это такая моя о них оценка спустя 2 года. При том, что у меня куча собственного кода годичной давности, на который смотреть сейчас противно, но конкретно те тестовые решения были произведением искусства).
Какую закономерность я заметил?
Чем больше времени уделяешь тестовому, чем лучше оно вылизано и красивее задумано, тем более гнилую отмазку придумают при отказе. Апофеозом был ответ «код клиента не впечатлил» после 4-х дней работы над тестовым, адаптации его для разных разрешений экрана, красивой имплементации «Наблюдателя» для кэширования и подгрузки данных, идеального разделения приложения по слоям. При этом, однажды получил оффер за имплементацию обычного быдлокода за 3 часа с асинктаском. работающим внутри активити и тупо подгружающим список. В общем, сделанного «лишь бы работало и не падало да побыстрее». Вот там «код впечатлил».
Из всего этого сделал вывод, что тестовое — это пустая формальность, на неё вообще не смотрят, решение принимают по каким-то своим критериям, а тестовое нужно просто для отписки.
С тех пор сразу шлю на йух рекрутёров, заикающихся о тестовом, оно просто не стоит потраченного времени и усилий. И видно, не я один. Последний год никто уже о тестовых не заикается даже почему-то))

Чем больше времени уделяешь тестовому, чем лучше оно вылизано и красивее задумано, тем более гнилую отмазку придумают при отказе. Апофеозом был ответ «код клиента не впечатлил» после 4-х дней работы над тестовым, адаптации его для разных разрешений экрана, красивой имплементации «Наблюдателя» для кэширования и подгрузки данных, идеального разделения приложения по слоям. При этом, однажды получил оффер за имплементацию обычного быдлокода за 3 часа с асинктаском. работающим внутри активити и тупо подгружающим список. В общем, сделанного «лишь бы работало и не падало да побыстрее». Вот там «код впечатлил».

Ну тут ещё вопрос специфики клиента... видел таких клиентов (и не одного), которые принципиально не готовы платить за красивые и вылизанные решения. Другое дело, что рекрутеру хорошо бы уточнять этот нюанс при постановке задачи.

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

По моему мнению,

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

Так как редко кто будет ставить задачу, про которую программист говорит, что «выполнить невозможно» или «долго делать такое». Поэтому выбирают либо готовое решение, если такое есть, что правильно, или делают «в лоб», что не всегда правильно.

Сори, потрите предыдущую попытку пожалуйста.

особенно в местах, где требуется итераци по эллементам массива и инкрементация всяхих i-тых, j-тых.
То есть, Вы не вкуриваете чем отличается итератор от счетчика, пост-инкремент от пре-инкремента, как оптимальным образом зарезервировать память... так? Если так, то «это печально» :(
как оптимальным образом зарезервировать память... так?
Резервировать память? В Java??)))

Use ByteBuffer.allocateDirect() everywhere and make GC getting pissed!

Да, GC писали идиоты! Наши велосипеды будут управлять памятью в сто раз лучше!

Почему сразу идиоты? GC может быть не рассчитанным на все случаи жизни, а только на наиболее распространнённые.

Угу, и мы из-за этого впилим неочевидный костыль в приложение и добьёмся от него поведения, которого 99% разработчиков, которым в будущем предстоит поддерживать проект, от него не ожидают и будут долго искать его причину.
Не лучше ли придумать, как свести поведение приложения к тем случаям, для которых GC предназначен?
Не хотите, чтобы ваши объекты уничтожались? Храните на них ссылки, только ж и всего.
Хотите, чтобы уничтожались? Подчищайте ссылки, когда надо. За 5 лет не припомню проблем с этим.

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

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

отдельный контракт на maintenance
PROFIT
PROFIT
Иногда этот контракт заключается уже с другим подрядчиком.

распределение с помощью GC не подходит для ряда задач.
поэтому и изобретают велосипеды типа аллокации на базе массивов статического размера
приходилось работать в одном проекте (финансы, трейдинг), где было табу на использование new ArrayList<>() .

Кастомные аллокаторы для подобных целей используют и в C++, где никакого сборщика мусора отродясь не было (зато по-прежнему есть фрагментация кучи и не совсем предсказуемое по времени поведение системных функций выделения памяти, ибо виртуальная память, paging и всё такое).

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

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

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

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

а де джава? хто сказал джава? сори :)

Работаю программистом уже достаточно долгое время (6+ лет). За это время набрался неплохого опыта в разработке веб приложений на Java с использованием Spring, Hibernate и прочих технологий.

А что, джава теперь единственный ЯП? Вот в C/C++/Obj-C есть вообще куча способов управлять памятью, от RAII, smart pointers и allocators до memory mapping и банального memset.

ТС — джавист.
Ну и в языках, появившихся после джавы и получивших хоть какую-то популярность, тоже автоматическое управление памятью.

При этом много чего делается на DirectByteBuffer или на Unsafe, взять хотябы тот же Kryo. Или всякие HFT проекты.

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

чессгря — не знаю как прокомментировать ... если Вы написали решение на бумаге, Вы наверно можете и нарисовать из этого блок-схему (хотя бы мысленно), если есть блок-схема — то заменить ее операторы на операторы в джаве или любом другом языке программирования, не задумываясь об оптимальности — это пальчики делают, не голова, т.е. дело чисто техническое. Серьезно мазги надо включать именно тогда, когда думать об оптимальном решении. Т.е. чиста поверхностно, похоже, что написание программ — это не Ваше :(

Но любое умение можно развивать, постоянными тренировками...

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

Може краще спочатку краще пройти пару курсів по матану на курсері Або спочатку хоч алгоритми сейндженика

Практиковаться имеет смысл только если по работе ты регулярно с таким сталкиваешься. Если этого нет, любой достигнутый уровень через время будет потерян. Навыки, которые не используются, быстро улетучиваются. Конечно, всегда есть вариант практиковать эти навыки на собеседованиях при отборе кандидатов, но я бы не рекомендовал опускаться до такого.

Резервировать память — я не об этом. Это немного другой вопрос.

особенно в местах, где требуется итераци по эллементам массива и инкрементация всяхих i-тых, j-тых.
определенная область знаний в программировании
Это не область, это азы.

Решай задачи по учебнику. Тыщу задач решишь — проблем не будет.

А ти не пробував примусово тренувати навик розв’язувати такі задачи?! Якщо динаміка буде позитивна то все ок, якщо ні тоді реально проблема. Ступор зазвичай від того, що не вистачає знань і навиків до вирішення проблеми.

Редко пробовал. Щас займусь єтим вплотную

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

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

Ну раз ты этот топик запилил, то уже паришься, выходит. Раз так — научись, будешь чувствовать себя увереннее :)

Книжка, курсера + набить руку на хакерранке и подобных сайтах.

Это еще что! Вот когда задают логические задачки!

Вот когда задают логические задачки!
Разворачиваешься и ухоишь с собеса. Ладно бы новые выдумывали, так еще и одни и теже мусолят.

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

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

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

Будучи выпускником технического вуза/олимпиадником это был бы твой единственный скилл — решать алгоритмические задачки,

Вы действительно считаете, что выучить любой из современных фреймворков — это большое достижение, недоступное многим?

Так то если посмотреть на тех кого приходится видеть на собеседованиях , то по ходу , да

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

А вы правда считаете что выучить какойто алгоритм большая проблема?

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

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

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

Та всё нужно учитывать, и неспокойное состояние собеседуемого также.

Условно реальная задача — реализовать скажем CRUD. Это может и любой войтивайти, выучив это за неделю. Но нанять хотят не войтивайти, а того, кто решит логическую задачу в случае чего.

Для этого можно придумать практическую задачу. Например реализация класса Money лучше оптимизированной сортировки вставкой. ИМХО, разумеется.

Для этого можно придумать практическую задачу. Например реализация класса Money лучше оптимизированной сортировки вставкой. ИМХО, разумеется.

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

во первых, если ищут когото кто будет клепать CRUD, то зачем спрашивают про алгоритмы?

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

к примеру для оптимизации вы хотите добавить LRU Cache — только вот реализовывать вы его не будете, а возьмете где-то либу.

в реальности все эти собеседования с алгоритмами не более чем «померятся яйцами».

во первых, если ищут когото кто будет клепать CRUD, то зачем спрашивают про алгоритмы?

Потому что для того, чтобы клепать CRUD — вообще можно взять домохозяйку из войтивайти. Заказчик хочет быть уверен, что при первой нестандартной задаче (даже среди CRUD’ов) процесс не зависнет.

На самом деле даже простой крад половина нормально не состряпает

Да, не каждая домохозяйка с ходу состряпает, но после пары месяцев в айти — вполне

Некоторые их пилят последние пять лет и до сих пор не умеют

Так чтобы рид простых сущностей не занимал 5 секунд с учетом того что выдать надо 20 штук а их суммарное колво около 20 тысяч. Так чтобы инсерт 500 записей в базу не занимал минуту с учетом того что всего записей миллион.
Так чтобы изменения сложных объектов было атомарно а не 3 ендпоинта в результате чего нарушается атомарность и в случае чего объект может сломатся изза внутреней несогласованости.
Так чтобы время высылать колво секунд с начала юниксэпохи а не конкатенацией даты-время без таймстемпа.

ох хорощо прошелся по мозолям java-истов и .Net-чиков с их любимыми ORM Hibernate и EntityFramework.

Если че я список выше могу еще долго продолжать.

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

Он сказал «очень часто», и я по своему опыту это поддерживаю. Ну не их задача писать остальное :)

Есть «тру-программисты» учившиеся на мат факультетах (и даже чтото от туда помнящие, и раз в 100 лет применяющие), которые скорей всего пилят формочки-энтерепрайз вместе со всеми остальными. А есть «тру-математики», которые учили программирование скорей в дополнение по необходимости.

Это какие-то везунчики. Мне пришлось пописать разное от гуев до навороченной математики и разработки алгоритмов (не того барахла из STL, а гораздо более интересных). Единственное чего избегал это уеба и баз данных — они меня раздражают.
Так что научился, как гуйню лепить, так и многое другое. На матлабе алгоритм разрабатываешь, потом, если нужно на плюсы портируешь — такой метод оказался самым качественным и эффективным. Если сразу на плюсах, то обычно тонешь в том, как написать, а не что написать. Матлаб же просто не сможешь использовать много где и у него есть свою нюансы для применения в продакшен.

Потому что скорее всего у них слабые места в другом месте — в ООП, например. Потому как математические задачи делают акцент на алгоритмах. «Обернуть» его в архитектуру — совсем другая петрушка.

И вообще тру математики часто вообще склонны к стилю процедурного программирования.

математики нынче склонны к фп

Та даже фп — там такое фп нечатабильное и неподдерживаемое.

Это тоже много где удобно, но не всегда и не везде.
Так что обычно и ООП и ФП и процедурное.

Туфта. Куча математики прекрасно кладется на ООП.

так-то оно так, вот только математикам это сложно объяснить
по факту сталкивался только с функциональным и процедурным адом, который надо было заставить работать с нормальной скоростью и сделать код читаемым и поддерживаемым

Ну эта странная традиция меня тоже удивляет до сих пор, а также удивляет, что всем она очень нравиться.
Скорее всего эта традиция основывается на социальной ответственности бизнеса, иначе я ее объяснить не могу. Чтобы толпы народа были при деле. А по сути — классическая картинка когда скупой платит дважды.

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

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

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

Лично меня учили и математике и программингу, причем это было еще в Союзе.
Да, тогда рулил фортран и ассемблер. Сейчас с и с++. Если математик не может понять программирование, то это не математик (это тупая обезьяна с стиле малпинг-тестера). Извини, но в основе программирования и ООП и ФП всё та же математика.

Извини, но в основе программирования и ООП и ФП всё та же математика.

да, только ООП подход как минимум нужно выучить и понять. Если у человека направление реализовывать мат.алгоритмы, то ему, возможно, простительно не знать ООП

Непростительно, ибо оное элементарно в сравнении с любой математической задачей.

всеравно требует знаний + практики. Вообще мне кажется что это фундаментальное различие между математикой и любым инженерным делом. ООП — продукт инженеров, нужны чтобы сделать куски кода реюзабельными и поддерживаемыми. Здесь нет математики.

Есть, но на на уровне массового применения. Она там, где диссеры по CS пишут.
А так да, в массовом применении обычное инженерное дело. Прикладная математика в массовом применении тоже становиться инженерным делом. Ты же не разрабатываешь каждый раз новые подходы и не доказываешь их сходимость, устойчивость и т.п. Ты просто юзаешь уже готовые блоки (реализованные в разных либах).
И ООП тут ничуть не сложнее, чем понять какие блоки и как слепливать при реализации какой распознавалки чего-то, как пример. Просто для юзания этих блоков еще нужно понимать, что именно и как кони делают, что в итоге сложнее 3 принципов ООП.

Я так понимаю, вопрос не в том что сложно-не сложно, а в том что впадлу\не интересно\корона череп жмет итд.

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

только ООП подход как минимум нужно выучить и понять

Как можно «выучить ООП подход»? Вы точно уверены, что вы его понимете сами? А объяснить можете? Без слова петрушка и неопределённых жестов руками.

Проблема с математиками в том, что их тренируют держать определённый уровень обоснованности в спорах. Но это не только математиков касается. В софтверной индустрии, особенно в тех местах, где алгоритмы не нужны (жаба, руби, ООП, нувыпонели) споры часто ведутся на уровне средневековой схоластики в лучшем случае. Результат — взаимное непонимание и попытка уйти от спора.

Видео в тему. vimeo.com/9270320
Длинное и немного медленное, но я рекомендую осилить и попытаться понять ту мысль, которую он пытается донести.

Как можно «выучить ООП подход»? Вы точно уверены, что вы его понимете сами? А объяснить можете? Без слова петрушка и неопределённых жестов руками.

не придирайтесь к словам

Замечательная демонстрация поинта лол.

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

Потому что приходиться постоянно проверять делает-ли твой алгоритм то, что надо, сходиться-ли, устойчив-ли и не в теории, а на практике.

это только если ты один разрабатываешь все
а в групповой разработке все сложнее

Всё тоже самое.
От математика алгоритм готов только тогда, когда он написал его на требуемом языке, написал понятно и покрыл тестами.
Иначе будет бардак обыкновенный. Проверенно оное кучу раз.
Ну как пример. Вот были на конторе два чела. Я написал алгоритм и реализовал его в С++ с тестами. Алгоритм до сих пор юзается.
Другой насочинял формул, набросал жуть как криво на С, алгоритм был выкинут буквально сразу. Начальство предложило мне его по быстрому привести в порядок, я послал их к тому, кто оное наваял. Сказал, что если вам надо, я его буду писать с нуля, а ту муть можете выкинуть и потраченное бабло списать в убытки. Решили, что и без него (алгоритма того) обойдутся.

это просто везение и ничего больше
в 95% случаев как раз все наоборот

Ну я стат исследований не проводил и высказываюсь на основе своего опыта.

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

Туфта. Куча математики прекрасно кладется на ООП.

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

Не задумывающийся математик — это нечто.
Может не надо его считать математиков, а просто попильщиком.

Не задумывающийся математик — это нечто.

не передёргивай.

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

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

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

Так он может запрограммировать. Он может написать алгоритм и он будет работать.То, что в КОНКРЕТНОЙ реализации софта части этого самого алгоритма нужно раскидать по дереву наследования и вообще по разным классам — это совсем другое.

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

это как-то противоречит тому, что я выше сказал?

Вот посмотри kaldi как пишут на с++ математики, а не обезьянки, что выучили наизусть 3 формулы.

Вот посмотри kaldi как пишут на с++ математики, а не обезьянки, что выучили наизусть 3 формулы.
Кошмар. Там обратная болезнь, мы всё напишем сами, а чего стоит натыканная по всему кода принудительная типизация, постоянные касты и т.п. Вместо того, чтобы сесть и всё продумать, им некогда, код педалить надо. А попугаи и магические числа в коде, например, количество потоков 8 и хоть ёпнись апстену...

Вообще-то 1 поток. Но я сильно код не копал, может и 8 где-то. Многопоточность там на уровне баша и хоть мульен потоков юзай.

А сами, потому как они еще один движок и очень неплохой написали. По многим тестам лучше HTK и Сфинкса.

Это так и есть, что тут считать или не считать.

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

Все можно натренировать, но олимпиадные алгоритмические задачи — если ты потратил в школе/универе на них 2-3 года то это бекграунд который уже есть, и разобраться/вспомнить будет легче, но если ниразу не сталкивался, то конечно времени придется потратить гораздо больше, но все это реально.

Лол. В програмуванні вже давно не треба мати мозок щоб програмувати. Веб сайтики — робота знайдеться для всіх.

да тупо умение подумать о том где какой объект в памяти расположен в какой момент времени — это уже 85% успеха в решении алгоритмических задач. И да, это тренеруется. И да, имхо Саппольски таки прав, старый добрый си наилучче этот навык тренерует, ибо там чуть что намудрил с поинтерами — сегфолт.

Вот когда напишешь какой движок распознавания речи на С, расскажешь про его «доброту».
Си неудобен даже для очень мелкого железа. Уж лучше С с классами.
Кстати, поддерживаемость написанного эмбедерами фанатами С сравнима с перлом.

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

Си неудобен даже для очень мелкого железа.
Абаснуй!
Кстати, поддерживаемость написанного эмбедерами фанатами С сравнима с перлом.
Если бы это была правда, то такие маленькие компании как наша уже давно бы самораспустились.

Потому что Си с классами приятнее и на мелком железе.

Потому что Си с классами приятнее и на мелком железе.
Ага, видел. Синглтон БлаБлаЖелезкаИнстанс с одним методом run().

Только почему синглтон? Там у тебя многопоточность железом поддерживается?
А вообще я люблю такие классы SetConfig, GetConfig и Run. Всё просто и понятно.

Только почему синглтон?
Потому что железка одна и входы со множества потоков должны сериализироваться.

У меня наоборот, i, j инкрементирую с удовольствием, а фреймворки нагоняют скуку. Но может это неправильно. Вот книги рисовались раньше вручную специальными людьми буковка за буковкой. Потом Гутенберг выпустил свой фреймворк, и все поменялось.

Кстати по поводу алгоритмов, один раз на интервью попросил рассказать как работает merge sort , но там у человека в резюме акцент был на то, что человек вот вот только окончил курс алгоритмов.
Но я сразу сказал, что это так сказать бонусный вопрос и на моё решение это никак не повлияет.

Ну вы даете... i, j... А я не умею складывать двухзначные числа, не знаю, сколько бит в байте и путаюсь в приоритетах арифметических операций. Но в работе мне это не нужно!

Толлинг — не троллинг, но как то мне пришлось собеседовать кандидата на должность девелопера, который не смог ответить на вопрос, сколько бит в байте.

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

По поводу битов в байте анекдот вспомнился:

Место действия — совковый вуз. Время действия — экзамен. Предмет — что-то про программирование, точно не помню... впрочем, мне простительно, ибо я препод.

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

Возвращаюсь — красавица вся светится от радости и сообщает: «Восемь!». «Слава Богу», — думаю я и собираюсь уже ставить зачет, как она добавляет: «...а в каждом четвертом — девять!»
— Почему?!! — я аж кляксу ей в зачетку поставил...
— Потому что каждый четвертый — високосный!
....

А вы точно сами знаете ответ на этот вопрос?

Да, мне еще в юности удалось чуть-чуть поработать на Минск-22, где был 7-битный байт. А мои одногруппники поработали на БЭСМ-6, у которой были 48 битные машинные слова (других единиц памяти там не было). Так что если бы кандидат захотел-бы блеснуть эрудицией, я бы его понял. Но я не могу вспомнить пример архитектуры компьютера моложе 1970 года рождения, у которого байт НЕ равнялся 8 битам (естественно, на уровне программной архитектуры). Я так понял, что Ваш вопрос был задан с целью привести такой пример. Очень интересно было бы услышать.

Да куча систем вообще не имеют байтов. Если брать интел, то флаг переноса прекрасно делает байт 9 битовым во многих операциях. Знаковые операции используют только 7 бит и т.п. , далеко ходить не надо. Если говорить о машинном хранении, то байт в ECC памяти 9 ти битовый. И т.д и т.п.

> Если брать интел, то флаг переноса прекрасно делает байт 9 битовым во многих операциях.

IMO, так рассматривать некорректно. В таких операциях именно что дополнительный бит, причём только с одной стороны (у приёмника операции).

> Если говорить о машинном хранении, то байт в ECC памяти 9 ти битовый.

ECC это 7 дополнительных бит на 64 по схеме Хоффмана, а не 1 на 8. И завтра поменяют схему, будет, например, 14 дополнительных бит, а 64 основных останутся.

В общем, тут любое рассмотрение, где не 8, слишком криво.

IMO, так рассматривать некорректно. В таких операциях именно что дополнительный бит, причём только с одной стороны (у приёмника операции).
Как разница? Он есть? Есть. Остальное не имеет значения, и является лишь предрассудком.
ECC это 7 дополнительных бит на 64 по схеме Хоффмана, а не 1 на 8. И завтра поменяют схему, будет, например, 14 дополнительных бит, а 64 основных останутся.
What??? Всегда использовалась 72-bit шина вместо 64 бит. JFYI: 9×8 = 72. Это фишка контроллера памяти, дело памяти предоставлить лишний чип для хранения.
Как разница? Он есть? Есть.
Не везде, не всегда, и не создаёт информацию. Что и требуется.
What??? Всегда использовалась 72-bit шина вместо 64 бит. JFYI: 9×8 = 72.
JFYI: 64+7==71. А ты вместо того, чтобы хоть пару секунд подумать, принялся возражать тому, что я не говорил.
Не везде, не всегда, и не создаёт информацию. Что и требуется.
Требуется для чего? Не замечать очевидного?
JFYI: 64+7==71. А ты вместо того, чтобы хоть пару секунд подумать, принялся возражать тому, что я не говорил.
JFYI: 2+2=4. Ты бы хоть одну спецификацию открыл на контроллер памяти. Любую.
JFYI: 2+2=4.

64+7+1 == 72 — я таки чуть промахнулся.
en.wikipedia.org/wiki/Hamming_code#SECDED
ещё общую чётность включают.

А вот твои 2*2 и 9*8 говорят, что ты читаешь что угодно, только не то, что нужно.

Ты бы хоть одну спецификацию открыл на контроллер памяти. Любую.

Я их читал, не волнуйся. Явно внимательнее, чем ты.

Не замечать очевидного?

Как раз замечать. Что все эти контрольные биты не создают большее количество информации. Тебя надо в твоём же стиле отправить читать основы теории информации.

А вот твои 2*2 и 9*8 говорят, что ты читаешь что угодно, только не то, что нужно.
А, понятно, ну сходи, плиз, наведи порядок в графике, а то говорят YUV 12 bpp, RGB 16 bpp и т.п. Также говорят и про память, когда вместо 8 чипов стоят 9, получается 9 бит на байт, используется 72 битовая шина данных и т.п. Избыточность 1 бит на 8. Ты же лезешь в ньюансы имплементации, которые опять же, как ты и сказал, могут быть сейчас одни, в другом месте другие, только стандарт на ECC есть стандарт (алгоритм там не заложен).
Я их читал, не волнуйся. Явно внимательнее, чем ты.
Не видно :)
Как раз замечать. Что все эти контрольные биты не создают большее количество информации.
Если бы ты замечал, то принимал бы мир сложенным из деталек лего разного размера, которые сцепленны между собой соплями, слюнями, моментальным клеем и прочими отходами, а не красивой картинкой.
акже говорят и про память, когда вместо 8 чипов стоят 9, получается 9 бит на байт, используется 72 битовая шина данных и т.п.

Да, на транспорте есть такое. Называются не только целевые биты, но полный набор, включая фреймовые, контрольные и т.п.
Но именно в данном случае это никак не 8 байт по 9 бит, это целое 72-битовое слово с двумя контрольными суммами.
А так я даже могу вспомнить про «полтора бита» в RS-232. С точки зрения информации это анекдот, а с временно́й точки зрения — норма. Но это не значит, что надо информационную ёмкость так оценивать.

Избыточность 1 бит на 8.

И снова нет. 8 на 64, а не 1 на 8. См. выше, почему.

только стандарт на ECC есть стандарт (алгоритм там не заложен).

Это в смысле, что модуль памяти хранит всё, что ему дали, все 72 без изменения? Вот тут сильно сомневаюсь. Помнишь, лет 15 назад были популярны модули с fake ECC? Нельзя сделать такой фейк без знания точного метода.

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

Я умею видеть и картинку, и детальки. В зависимости от того, что сейчас нужно.

И снова нет. 8 на 64, а не 1 на 8. См. выше, почему.
Тебя опять заносит в имплементацию, а если используется 1 бит чётности на 8 бит данных?
Вот тут сильно сомневаюсь.
www.jedec.org — многое бесплатно после регистрации.
Помнишь, лет 15 назад были популярны модули с fake ECC? Нельзя сделать такой фейк без знания точного метода.
Возможно было заточено под определённый контроллер на рынке. В automotive применяется и Hsiao вместо классического Hamming. Различные triple-mode, quadruple-mode redundancy, часто важно не восстановить данные, а отрепортить о повреждении. Так и в модулях памяти обычно два сигнала — была ошибка, данные восстановлены и была ошибка, передали по шине мусор.
Тебя опять заносит в имплементацию, а если используется 1 бит чётности на 8 бит данных?

Я подразумевал контекстом PC + SDRAM. Там, кажется, везде схема ECC 64+7+1. На более ранних была и просто чётность (вот не помню, какие были последние с ней — SIMM-30 или SIMM-72).

В automotive применяется и Hsiao вместо классического Hamming.

Там много чего существенно иначе :) но я их не учитывал для данной темы.

Я подразумевал контекстом PC + SDRAM. Там, кажется, везде схема ECC 64+7+1. На более ранних была и просто чётность (вот не помню, какие были последние с ней — SIMM-30 или SIMM-72).
Если честно, то во времена SIMM я не вдавался в электрические спецификации, а вот с DDR DIMM пришлось. Например, у Intel есть своя технология Lockstep, когда их контроллер может утилизировать всю память в таком виде, в каком он хочет и может предлагать самые злые алгоритмы за счёт уменьшения доступной памяти. У модификаций процессоров с буквой ’T’ (Military/Aerospace) AFAIK все контроллеры памяти с такой изюминкой, некоторые алгоритмы утилизируют 11-12 бит на 8 бит информации, могут работать как с ECC, так и с non-ECC памятью.
то флаг переноса прекрасно делает байт 9 битовым во многих операциях
Увы, не делает.
Бит — по определению — единица информации. Каждый из восьми бит в байте — добавляет количество представимой информации. Флаг переноса никакой дополнительной информации не добавляет. Т.е. к объему представимой информации он отношения не имеет.
Между прочим, аппаратная реализация байта может быть какая угодно по емкости — вон в некоторых реализациях вполне может присутствовать бит контроля четности, что тоже, естественно не делает 8 битный юнит информации(байт)- 9-и битным. И кроме того, я не даром выше написал «(естественно, на уровне программной архитектуры)».
Знаковые операции не делают байт 7-битным. Бит знака — это добавление информации о хранимом значении. Т.о. для представления числа (информации) вам все равно требуется 8, а не 7 бит.
Флаг переноса никакой дополнительной информации не добавляет. Т.е. к объему представимой информации он отношения не имеет.
Садись, два. x86: ADC/SBC.
8 битный юнит информации(байт)
8 битный юнит информации называется октет.
И кроме того, я не даром выше написал «(естественно, на уровне программной архитектуры)».
Хорошо, безбайтовые процессоры — их валом, оперируют только словами или байтами, как их тоже называют, ибо они там являются атомарной единицей.
Знаковые операции не делают байт 7-битным. Бит знака — это добавление информации о хранимом значении. Т.о. для представления числа (информации) вам все равно требуется 8, а не 7 бит.
Вопрос на пять. Какой размер имеет floating point регистр на x86 архитектуре?

Байт — AFAIK, минимально адресуемая единица памяти. Т.е. мы можем создать указатель на область памяти, начинающуюся в такого-то байта или с такого, но не (к примеру) середины байта. А размер регистра тут ни при чём, по-моему; если регистры в архитектуре исключительно, к примеру, 64-битные (и не меньше) — а минимально адресуемая единица памяти будет 8 бит — то байт там, AFAIK, будет 8 бит, а не 64; размер регистра — это, собственно, AFAIK, слово (word), хотя, AFAIK, из-за уродливой обратно-совместимой архитектуры (и терминологии) x86’ых слово стало ассоциироваться с 16 битами.

Байт — AFAIK, минимально адресуемая единица памяти.

Есть дурные архитектуры типа Alpha (времён до BWX), где в байте 8 бит, но операция с данными — 64.

хотя, AFAIK, из-за уродливой обратно-совместимой архитектуры (и терминологии) x86’ых слово стало ассоциироваться с 16 битами.

У кого стало, а у кого и нет. Для меня слово — это минимум 32 бита.

Кстати,

> x86’ых

Тут должно использоваться U+02BC, а не U+2019.

Есть дурные архитектуры типа Alpha (времён до BWX), где в байте 8 бит, но операция с данными — 64.
Ну так я ж и говорю, что это по минимаемо адресуемому кванту памяти опередяется, а не по операциям с данными. (Или Вы хотите сказать, что там указатель мог указывать только на позицию, кратную 64 битам?)
У кого стало, а у кого и нет. Для меня слово — это минимум 32 бита.
Я об этом: „For example, Microsoft’s Windows API maintains the programming language definition of WORD as 16 bits, despite the fact that the API may be used on a 32- or 64-bit x86 processor, where the standard word size would be 32 or 64 bits, respectively. Data structures containing such different sized words refer to them as WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) and QWORD (64 bits/8 bytes) respectively. A similar phenomenon has developed in Intel’s x86 assembly language — because of the support for various sizes (and backward compatibility) in the instruction set, some instruction mnemonics carry ‚d’ or ‚q’ identifiers denoting ‚double-’, ‚quad-’ or ‚double-quad-’, which are in terms of the architecture’s original 16-bit word size.”
Кстати,

> x86’ых

Тут должно использоваться U+02BC, а не U+2019.

Чего? Или это троллинг по поводу моего предложения нормировать U+02BC в украинской википедии, как основной апостроф? И, кстати, почему в данном случае должно быть U+02BC, а не U+2019? (Собственно, у меня там было вообще U+0027 — это уже DOU переделал в U+2019.)
(Или Вы хотите сказать, что там указатель мог указывать только на позицию, кратную 64 битам?)

Да. Кратно 4 для 32-битного доступа, 8 для 64. Там ещё злобнее. Вот цитата из официальной документации:

4.2.3 Load Unaligned Memory Data into Integer Register

LDQ_U Ra.wq,disp.ab(Rb.ab)

The virtual address is computed by adding register Rb to the sign-extended 16-bit displacement, then the low-order three bits are cleared. The source operand is fetched from memory and written to register Ra.

Как по мне, это просто подлость — сбрасывать три младших бита и называть это «load unaligned».

Microsoft’s Windows API maintains the programming language definition of WORD as 16 bits

Ну так это только Windows и хвосты Intel. Да, я, конечно, в курсе.
В некоторых ассемблерах от этого ушли и пишут что-то в духе «load32». Это на символ дольше, но IMO сейчас безусловно правильнее.
А ещё имеет смысл вводить совсем новые слова для таких битовых групп. Например.

Чего? Или это троллинг по поводу моего предложения нормировать U+02BC в украинской википедии, как основной апостроф?

Я не в курсе такого предложения и его авторства, но если оно есть, то я его безусловно поддерживаю.

И, собственно, почему в данном случае должно быть U+02BC, а не U+2019 :)?

Именно потому, почему есть это Ваше предложение.

Хм... Ну тем не менее, в самом указателе-то записан номер октета (а не номер амады (64-битного элемента); хоть потом при загрузке его и округляют до 8). Вероятно, это обратная совместимость или задел на будущее.

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

Я бы нормально воспринял следующий вариант, например, если адрес равен 9, ldq_u1 читает байты 8-15 и грузит в регистр X, ldq_u2 читает байт 16 и грузит в регистр Y, потом ldq_combine скрещивает результаты по маске, заданной младшими битами адреса, и в результате получаем именно корректно прочитанное невыровненное. Это честная помощь — ну да, 3 команды вместо одной, но плата относительно мелкая, зато концептуальная целостность на месте.

Но то, что я вижу у них, ни обратной совместимостью (с чем? архитектура сделан совсем с нуля), ни заделом не объяснить. Просто кривая тупая фича.

Ну тем не менее, в самом указателе-то записан номер октета

Потому что там есть ещё LDB. Споры по поводу длины байта имели бы смысл, если бы оно выравнивалось на 4 для всех опкодов. Но там natural alignment, т.е. LDW выравнивается на 2, LDB на 1.

Зачем сделано — скорее всего чтобы у декодера побольше общего было для LDB, LDW, LDD и LDQ.

И, кстати, почему в данном случае должно быть U+02BC, а не U+2019?

U+2019 — парный ограничитель, правая одинарная кавычка.
U+02BC — просто символ, апостроф.

Но да, если это DOU делает, то претензии к DOU.

Ну, вообще-то, нет.

Вот и гадай теперь. Да, U+02BC логичнее (даже для английского языка, т.к. «don’t» — это одно слово, и «’» там ну никак не кавычка). Но Unicode, видимо, решил, что «хомячки всё равно не отличают кавычку от апострофа, давайте и мы не будем». И куча сайтов потянулись за ним (автоматически заменяют U+0027 на U+2019, не глядя в середине оно слова или нет).

Байт — AFAIK, минимально адресуемая единица памяти. Т.е. мы можем создать указатель на область памяти, начинающуюся в такого-то байта или с такого, но не (к примеру) середины байта.
Где? Внутри процессора в качестве операнда команды или в адресе выставленном на шине адреса процессора?
размер регистра — это, собственно, AFAIK, слово (word)
_Машинное_ слово.

Полагаю, минимум из этих двоих. (А, кстати, второе может быть меньше первого?)

Полагаю, минимум из этих двоих.
Надо просто понимать, что интеловская архитектура предлагает два режима работы — совместимость и нативный режим. Без нужды использовать процессор в режиме совместимости не стоит. Об этом знают все компиляторы, JVM и прочее, которые, например, char в структуре могут сделать размером 4/8 байт, ещё и выравняют её на границу 4/8 байт, чтобы убрать лишнее обращение.
А, кстати, второе может быть меньше первого?
Может, если используется SIMD регистры, а память по-прежнему 64 битовая. Но, допустим в шестом поколении x86 (gen6: skylake, apollolake) память может работать в режиме 6-way interleave mode, образуя виртуальную 384 битовую шину адреса.
шину адреса
шину данных, сорри.

И меньше, и больше.

Вообще-то «указатель» это абстракция до тех пор, пока не указано, как именно с ним работают. Например, на C, если я пишу


uint32_t *a;
bool getBit(unsigned index) {
  return (a[index>>5]>>(index&31))&1;
}

чем этот index не указатель на бит? Ну да, доступ более сложный, чем просто по фиксированному биту :)

Или, наоборот, если все команды порциями кратно 32 бита, то смещения в команде локальных переходов не содержат младшие 2 бита, тем самым позволяя расширить ширину области возможного перехода.

Память в современном x86 адресуется порциями в 64 байта, если кэшируемая (основной интересный случай). Некэшируемая — да, по байту, но хитро — при этом на классической PCI, например, в адресе два младших бита просто не выведены на шину, а линии BE0-BE3 содержат маску с 1 на месте конкретного применённого байта. Так что тут понятие байта обеспечивается за счёт того, что грануляция только до 8 бит. То же самое для IO пространства.

Байт как минимальная адресуемая единица в этом смысле сейчас некоторая усреднённая по больнице абстракция, которая устраивает подавляющее большинство, и имеет практические особенности типа «на типичных операциях нельзя записать один бит, надо прочитать байт, модифицировать его и записать обратно». Но и это не всегда видно программисту напрямую. Например, в x86 команды типа BTS, BTC могли бы вполне быть использованы с адресацией по 1 биту :)

Флаг переноса никакой дополнительной информации не добавляет.
Вот тут ошибаетесь. Добавляет, и очень важную.
бит контроля четности, что тоже, естественно не делает 8 битный юнит информации(байт)- 9-и битным.
Знаковые операции не делают байт 7-битным. Бит знака — это добавление информации о хранимом значении. Т.о. для представления числа (информации) вам все равно требуется 8, а не 7 бит.
Тут согласен в обоих случаях.
Добавляет, и очень важную.
Добавляет, но не в ПРЕДСТАВЛЕНИЕ данных.
Добавленная информация возникает в момент выполнения операции и теряется, если оказывается незадействована непосредственно вслед за ней. Если упростить — то взяли информацию из памяти, прибавили другую. Получили результат и флажок о том, было или нет переполнения. Вопрос — сколько бит информации у нас задействовано для представления результата? И сколько информации мы можем обратно сохранить в память?
Кстати — "прочитали байт из памяти"=="прочитали 8 бит из памяти" (в x86), а никак не 9.
И еще, на этом пример отлично видно разница между битом знака (который есть неотъемлемой частью представления информации) и флагом переполнения.
А вообще-то мы как-то далеко отошли от темы, что должен знать девелопер. И неужели то, что он не читал мануал по микропроцессорам, дает ему право не знать, сколько бит в байте в стандарте его языка программирования?
Добавляет, но не в ПРЕДСТАВЛЕНИЕ данных.

Именно что в представление.
Результатом операции add with carry (ADC в большинстве ассемблеров) от входных данных — двух N-битных целых и входящего переноса — является N+1-битное целое.
То, что оно представлено раздельно в виде N-битной нижней части и бита переноса — это технологические особенности представления.

и теряется, если оказывается незадействована непосредственно вслед за ней

Хотел попридираться, но скипну. Ну и что, что теряется? CC это такая же память, как и любая другая. Перезаписал — ушло. Сохранил — не ушло. Точно так же, как тот целевой регистр, куда записали нижние N бит суммы.

Кстати — "прочитали байт из памяти"=="прочитали 8 бит из памяти" (в x86), а никак не 9.

Так это опять же о чисто информационных (я рядом обсуждаю с Горчаком). Со всякими контрольными может быть сколько угодно. Например, есть помехозащищённые кодирования 8->9 (чётность), 8->10 (4B5B, 8B10B), 8->14, и так далее.

И неужели то, что он не читал мануал по микропроцессорам, дает ему право не знать, сколько бит в байте в стандарте его языка программирования?
OMFG, ну и сколько бит в байте в С?

Не обязательно ж именно байт в памяти. На RS-232 («компорт») тоже «байты», можно ставить от 5 до 8 бит, а если с битом чётности считать, то и 9 получится.

Но я таки принял бы ответ «8» от любого, кому не нужно быть системщиком, и «обычно 8, но <список исключений>» от системного программиста.

Но я таки принял бы ответ «8» от любого, кому не нужно быть системщиком, и «обычно 8, но <список исключений>» от системного программиста.
Абсолютно согласен.

:) вы правильно поняли о чем я. Но главный момент в том что это не совсем корректный вопрос, изза возможности разных ответов в зависимости от системы

Ладно, соглашусь ты знаешь для некоего железа. Но вообще обычно лучше свериться с докой для некоего специфического железа обычно.

Да ладно, какое «специфическое железо» для разработчика фронтэнда или даже какого-нибудь Андроид-приложения? :-) Это примерно так, как задать школьнику вопрос про аксиому параллельности прямых, а в случае, если он не сумеет дать правильный ответ, списывать это на его глубокое понимание геометрии Лобачевского :-)

Тролль вообще-то квант и вполне возможно успел столкнуться с разными байтами в молодости. Сейчас не юзает оного совсем и уже забыл.

Это примерно так, как задать школьнику вопрос про аксиому параллельности прямых, а в случае, если он не сумеет дать правильный ответ, списывать это на его глубокое понимание геометрии Лобачевского :-)

Ну, такие случаи бывают. Но их надо совсем отдельно рассматривать. Как правило, такие люди годятся только на генераторы идей и набираются по отдельному конкурсу.

Да ладно, какое «специфическое железо» для разработчика фронтэнда или даже какого-нибудь Андроид-приложения? :-)

А вот тут есть грустный факт — например, несмотря на то, что железа с представлением целых не в дополнительном коде не осталось вокруг от слова «вообще», в стандарте C до сих пор говорится, что есть три метода представления со знаком (прямой, обратный и дополнительный код), и дефайна «на этой платформе дополнительный» не дают. Java на все, кроме дополнительного, намеренно забила и требует его за основу — и, наверняка, не только она.

Запитання в такому вигляді не має правильної відповіді. ;)

Якби-ж то кандидат дав декілька відповідей, та ще й обґрунтував їх застосування — я би взяв його на роботу не вагаючись. Але якщо він був не в змозі дати хоча б одну, то тут вже мало що можна обговорювати далі.

Ерудиція не дорівнює вмінню вирішувати складні задачі. Я вже бачив людей, які знають на відмінно теорію, але не вміють писати код.

Хочу послушать ответ. Я вот тоже в оном не всегда уверен и приходилось и приходиться лезть в доку.

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

Умение работать с AngularJS и ReactJS сегодня более востребовано, и более оплачиваемо чем знание количества битов в байте. Даже можно делить на ноль, это тебе не помешает быть хорошим js программистом.

сколько бит в байте
Если ты не 23-летний июнь-сеньор, то это вполне ожидаемо.

На unittest.work можно выбрать уровень сложности задач, время выделенное на решение или участвуйте в ежедневном открытом контесте.

Вам бы тему на bootstrap перенести может.

Как это поможет в решении алгоритмических задач?

Поможет тем, что сейчас заходишь на сайт и первая мысль, что это какая-то заброшенная помойка, сделанная студентом по заказу декана из под палки. Думаете на DOU ходили бы, если бы он выглядел так? Регистрацию сделать через соц сеть, тоже не помешало бы. Какая-то странная CMS, зачем делать paging внутри длинных страниц, и мелкий шрифт. Пользование сайтом через силу.

На DOU ходят не задачи решать, это как сравнивать глянцевый журнал и сборник задач.

Я согласен есть монополисты своих категорий с вырвиглазными сайтами, но Вы ж не монополист. Пойдут в другие 100 сайтов, где можно решать задачи. Хотя может быть Вы монополист в каком-то ВУЗе-школе, где заставляют использовать этот сайт. Хотя исходя из объема трафика 300kb первичная загрузка, вполне приятно.

В своей области (географически) — монополист :-) , да и во всем рунете других таких 100 сайтов не насобираете, а поддерживаемых с 10-ок.

ще тут багато хто радить почитати Algorithm Design Manual — Steven Skiena.
але з чого краще почати, Cormen чи Skiena — нехай порадять знатоки.

лучше всего — с grokking algorhitms. Проще и доступнее некуда

Algorithms 4th edition + курс на Курсере от авторов

Немножко в сторону от алгоритмов, но в целом в тему «Я знаю HTTP и Hibernate , этого достаточно, зачем мне эти файлы и сокеты».
Из текущей практики. Есть клиент и сервер общающиеся через Websocket. Все замечательно, пока запускаются на девелоперской машине. Как только начинается минимальное нагрузочное тестирование — сервер падает. Постмортем анализ показывает на обращение к несуществующему дескриптору сокета где-то в глубине сетевой библиотеки.
Ваши действия?

Ваши действия?
начать мерджить два отсортированных массива?

Было подобное очень давно, когда писал на Дельфи. Сдуру создал свой TSocket с вызовами всех функций через winapi. работало без ошибок.

Я как с дуру, kernel.dll wrapper сделал

Хук на функцию WinAPI с переопределением логики для этого сокета ?
Есть еще пару решений — но это все костыли

Але-але. Настоящему программисту надо знать Хибернейт, а не муть вроде хуков, сокетов и API.
P.S. Код кроссплатформенный.

Стикався з подібною проблемою. В кінці дійшов до висновку, що у мене елементарно не було фундаментальної бази, а всі свої знання отримував на реальних проектах + google + stackoverflow.

Відносно недавно почав робити те, що ніколи не робив раніше — читати серйозну літературу по програмуванню. До речі, одна з перших книжок, яку я купив, а не просто скачав в інтернеті, була якраз «Алгоритми — ввідний курс» Кормена. Мало того, що вона сама по собі цікава і легко читається будь-ким, у кого є хоча б мінімальна зацікавленість, так ще й дозволяє без проблем проходити 95% співбесід, де є питання на алгоритми.
www.chytayka.com.ua/...y-vvodnyj-kurs-52714.html

Стоит ли мне париться насчет этого и все таки вкладываться в эту область или забить прокачивать то, что получается
Якщо ти задаєш собі таке питання, це вже говорить про те, що не все так погано, як могло б бути.

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

А разве не ясно? Он прошел собеседование и все напрочь забыл уже через полгода.

Одно из двух. Либо ты продолжаешь использовать это на работе каждый день, либо у тебя феноменальная память.

Регулярно перечитую книгу або розв’язую задачки. Хочу довести це діло до автоматизму — це моє особисте бажання. Та і сам процес мені приносить задоволення — набагато цікавіше, ніж фільми/серіали/футбол дивитися.

Дело вкуса. Я вот практикуюсь в придумывании всяких несуществующих/маловажных задач и убедительных оснований необходимости их реализации. Очень помогает по легкому срубить дополнительных денег.

Згоден, що дуже часто вони не несуть практичного значення. Але не треба також забувати, що часто людина, яка має певне уявлення про алгоритми, пише, в середньому, більш якісний код.

Структури даних там також описуються?

Ні. Ось зробив скріншоти деяких сторінок, щоб зрозуміти, про що йдеться в книзі.
drive.google.com/...3ucRBvxpzyeDJYTmd4NUZHX2s

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

P.S. Посмотрел вашу тему годичной давности — dou.ua/forums/topic/16075 Похоже, не сильно вы любите новое и застой все таки имеется.

Забей. ИТ это как медицина.
Тут пасутся от психологов до ветеринаров.
И сколько бы тут хирурги не сокрушались, в медицине есть место даже для гомеопатии.

в медицине есть место даже для гомеопатии
Это когда поправил один юнит-тест из 1000 и ожидаешь, что поднимецца упавший продакшен?

Это когда на продакшене переполнение стека, а ты где-то в коде добавляешь
throw "The requested operation caused a stack overflow."
Подобное подобным лечат же.

ну мердж двух отсортированных массивов это не алгоритмическая задачка, это самая-самая база Computer Science. Ну, работая CRUD программистом можно и не знать такое, конечно. CRUD-CRUD и в продакшен, как говорится.
Кстати, в мердже этом for циклов нет )

Так это просто последний шаг для merge sort, так то вообще считаю , что всякий кто называет себя software engineer, должен знать хоть одну сортировку, кроме как пузырьком.

Так это просто последний шаг для merge sort
ну да, по этому я и сказал что это не алгоритмическая задачка а база computer science
должен знать
Кому должен?
Алексей — а как насчет устройства и архитектуры современных процессоров?
Вы скорее всего и ассемблер знаете и умеете, хотя бы один?
А поиск циклов в графе напишите, хотяьы самый простой?
Алгоритм дейкстры вы конечно напишите не заглядывая в Кормена?
Красно черные деревья — каждый день а работе применяете?
Динамическое программирование в обеденный перерыв решаете вместо просмотра лицокнига?
А определение вероятностей возникновение коллизий в хеш алгоритме- для вас делаете просто на уровне подсознания- незадымываясь?

А я вот считаю что пока вот все основы computer science не пройдены и поняты- то допуск к компьютеру не выдавать

Прошу- не надо решать за других кто что должен делать, знать
Тогда и за вас не будут решать что вы обязаны делать, знать

увернен, что в твоём случае ты напишешь 5 сортировок и ещё два алгоритма поиска сверху:)

Вот я ДП сходу напишу, а вот сортировку нет, кроме пузырька.

Не благодари :)
public class Sort {

public void monkeySort(int[] arr) {
if (arr.length <= 1)
return;

Random rnd = new Random();
while (!check(arr)) {
int i1 = rnd.nextInt(arr.length);
int i2 = rnd.nextInt(arr.length);
int tmp = arr[i1];
arr[i1] = arr[i2];
arr[i2] = tmp;
}
}

private boolean check(int[] arr) {
for (int i = 1; i < arr.length; i++)
if (arr[i — 1] > arr[i])
return false;
return true;
}
}

public class TestSort {

@Test
public void testMaxElement32() {

Sort sort = new Sort();

int[] act = { 4, 89, 5, 12, 75, 96 };
int[] exp = { 4, 5, 12, 75, 89, 96 };
sort.monkeySort(act);
assertArrayEquals(exp, act);
}
}

Динамическое программирование
А вот это сходу напишу, в отличие от сортировки. Дело в том, что именно с ДП мне приходилось прилично возиться.

это как? ДП это ведь всего подход к решению, а не определенный алгоритм.

Ну так это общий подход, а как именно его применить в конкретном случае — решается по обстановке.

с этим я согласен. но утверждения: «решаю ДП», «пишу ДП» и т.д. кажутся мне некорректными.

Сортировка — это тоже подход, а вот реализации и применений мульён.

Можно я отвечу вместо Вашего собеседника? По пунктам.

> Алексей — а как насчет устройства и архитектуры современных процессоров?

Знаю, и считаю, что мало знаю (GPUʼшки не гонял, Tomasulo в деталях не осознал (каким чёртом они решают, как координировать reservation stations???), но даже мелочи на Verilogʼе помучал).

> Вы скорее всего и ассемблер знаете и умеете, хотя бы один?

Хм, считаем. S/360, PDP/11, M6502, x86... Думаю, не заблужусь в обоих ARM, MIPS, RISC-V, Sparc, но с cheat sheet под рукой. Вот к IA64 не хочу пробовать — там слишком ум за разум заходит. А что тут сложного-то?

> А поиск циклов в графе напишите, хотяьы самый простой?

Да. Как минимум BFS и DFS это уровень банальности.

> Алгоритм дейкстры вы конечно напишите не заглядывая в Кормена?

Да. Вот что такое A* — уже не помню навскидку.

> Красно черные деревья — каждый день а работе применяете?

Красно-чёрные не уважаю. Уважаю AVL и B-деревья. Красно-чёрные — не понимаю, накойхер их держат — AVL по всем известным мне тестам на 2-20% быстрее, и перекос меньше. Но для современной RAM B-деревья предпочтительнее (см. tarantool). И не то чтобы лезу внутрь, но знаю, что там и почему, и в моём коде std::map используется регулярно.

И вот по этому всему — считаю, что я ещё таки очень мало знаю. Можно было бы и больше.

> Динамическое программирование в обеденный перерыв решаете вместо просмотра лицокнига?

А вот это уже аргумент другого типа, слишком ad hominem. Я его знаю, и в основе это чудовищно банальная штука, и помогал реализовывать, но чтобы в обеденный перерыв — это перебор. Перерыв предназначен для совсем другого. :)

> А определение вероятностей возникновение коллизий в хеш алгоритме- для вас делаете просто на уровне подсознания- незадымываясь?

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

> Прошу- не надо решать за других кто что должен делать

Ну вот и не решайте. Потому что всё перечисленное это минимум того, что должен знать действительно толковый специалист. Вот уже достаточно давно был список — он и сейчас актуален на >95%.

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

Ожидаю _аргументированного_ возражения

Так я не вижу смысла возражать. Практически всё по делу написано. Кроме как «должен знать».

чудовищно банальная штука

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

Попытка решать за всю отрасль — куда её вести или нет — не нужно. Реалии Украинского рынка таковы, что тут нужны низкоквалифицированные специалисты знающие язык программирование (выбери по вкусу) + пачку фреймворков(для выбранного языка).
Замечательно, если специалист знает fundamental CS, но в большинстве украинского IT, надо будет делать сайтики и данные в базу гонять не задумываясь- как оно работает.
Вот например возмём фронтендера- он не сможет писать на ангуляре без знаний CS?
Хорошо, возьмем типичного джависта- который знает спринг и хибернейт. Он что не сможет ан работу устроиться без знаний CS? Да больше половину в ступор впадают если их спросить как построить остовное дерево графа.

Я уверен- у Украине есть разработки компиляторов, и тех кто контрибютит драйвера для unix систем, и эмбед есть (хотя это несильно сложнее веб программирования)- только это не мейнстрим в нашем IT. Рынок сам решит что требуется от специалистов.
Всё перечисленное мною в предыдущем комменте- частью того что «должен» знать настоящий программист- только вот в реальности- нифига никто не должен никому.

Я уверен- у Украине есть разработки компиляторов, и тех кто контрибютит драйвера для unix систем, и эмбед есть (хотя это несильно сложнее веб программирования)- только это не мейнстрим в нашем IT. Рынок сам решит что требуется от специалистов.

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

Всё перечисленное мною в предыдущем комменте- частью того что «должен» знать настоящий программист- только вот в реальности- нифига никто не должен никому.

Реальность ты создаёшь сам.

все перечисленное делал в институте, но сейчас конечно не сделаю, не заглянув в книгу

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

Так-то сортировку можно написать просто «из общих соображений».

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

Когда мне был нужен джун для программирования математики я тому давал домашку перед собеседование — написать класс для матриц и реализовать многопоточное блочное умножение матриц. Дальше смотрел на то, что он написал и обсуждал с ним и после уже решал брать или нет.
Тут я получал понимание о том, насколько джун умеет гуглить, какой код написал, какой стиль написания и т.п. Всегда можно еще задать вопрос на месте, а как бы ты в твоем классе реализовал транспонирование матриц.

можно еще запихнуть в сортированный список (сортировка в момент вставки — тоже сортировка)
а в яндексе давали задачу на radix sort

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

Ну и по итогу они эту задачу чехам зааутсорсили ну и результат у них на лице.

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

На собеседовании может быть обстановка нервная. :) Если дома, в спокойной обстановке, не тупишь тогда все не так страшно.

С нахождением решения туплю меньше, а с реализацией — достаточно сильно)

реализация готового решения — это школьный уровень. Пара недель практики помогут очень сильно

Это все легко тренируется

Вот сайты на которыз можно найти интересные задачи и попробоваать их решить.

Codeforces
TopCoder
HackerRank
CodeChef
HackerEarth
CS Academy
AtCoder
leetcode.com

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

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

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

у вас устаревшие данные
Хз. в 2010-2012 Помню когда Амазон и Микрософт устраивали хайринг ивенты в Киеве и москве- мгного сениоров с Люкса участвовали и естественно не прошли- и примерно через пару недель после этого прочитав книжки начали сами доминировать спрашивать алгоритмы уже при устройстве в Люкс новичков.

А что сейчас спрашивают?

Хз. в 2010-2012 Помню когда Амазон и Микрософт устраивали хайринг ивенты в Киеве и москве- мгного сениоров с Люкса участвовали и естественно не прошли- и примерно через пару недель после этого прочитав книжки начали сами доминировать спрашивать алгоритмы уже при устройстве в Люкс новичков.
А что сейчас спрашивают?

хе, я теж у ті роки у тих забєгах учавствував, витверезуюче дійство

Ещё как минимум
codingame.com (вкусен командными играми)
acmp.ru
acm.timus.ru
www.e-olymp.com
informatics.mccme.ru
вообще, „тысячи их” ™

ну это как я вижу уже более олимпиадные задачки.

Любая задача на использование мозга может считаться олимпиадной задачей.

Знаешь. Когда я учился в школе на отлично математику у нас знали 3 человека в классе (я один еврей и девушка чеченка). В то время сильнейшая с мат уклоном школа в Минске.
Так вот еврею по какой-то причине при поступлении дали решать олимпиадную задачку. На олимпиадах он такие решал шутя, а на экзамене завалил.
так что разница между олимпиадными и не олимпиадными таки есть.

З.Ы.
Правда в итоге я сейчас в жопе мира в Минске, а он в США свою конторку имеет и даже програмерская приличная книжка от него была.
Чеченка тоже долго в институте математики НАН тусовалась (до 40 лет), но по итогу вышла замуж за американца и сейчас тоже в США. За год там с обычного тестера выросла до начальника подразделения на какой-то конторе. Ну да пришлось ей выкинуть свои знания математики и начать там с 0 тестером.

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

Вообще-то я на такую удочку попался на экзамене. Решил задачку тремя разными способами и результат был одинаков. Не мог поверить, что такие простые могут быть на экзамене — искал подвох.
А да перед этим я поразвлекался с задачками для МФТИ, там получалось, что решить могу ходу только 3 с половиной из билета и очканул туда поступать.

А разница в сложности и не очевидности решения.

А его завалили, потому что он что-то там учудил на экзамене и это сильно разозлило экзаменатора.

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

Ну у меня всё было просто. Когда я показал экзаменатору исписанные листочки он задал только один вопрос. В какой я школе учился и больше ничего не спрашивал и поставил отлично.

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

Книжка про це є
You Failed Your Math Test, Comrade Einstein
www.amazon.com/...de-Einstein/dp/981256358X

This groundbreaking work features two essays written by the renowned mathematician Ilan Vardi. The first essay presents a thorough analysis of contrived problems suggested to „undesirable” applicants to the Department of Mathematics of Moscow University. His second essay gives an in-depth discussion of solutions to the Year 2000 International Mathematical Olympiad, with emphasis on the comparison of the olympiad problems to those given at the Moscow University entrance examinations.The second part of the book provides a historical background of a unique phenomenon in mathematics, which flourished in the 1970s-80s in the USSR. Specially designed math problems were used not to test students’ ingenuity and creativity but, rather, as „killer problems,” to deny access to higher education to „undesirable” applicants. The focus of this part is the 1980 essay, „Intellectual Genocide”, written by B Kanevsky and V Senderov. It is being published for the first time. Also featured is a little-known page of the Soviet history, a rare example of the oppressed organizing to defend their dignity. This is the story of the so-called Jewish People’s University, the inception of which is associated with Kanevsky, Senderov and Bella Subbotovskaya.

Практически все они именно алгоритмические.
С олимпиадами у них связь есть, но слишком косвенная: за счёт того, что в силу специфики олимпиад на них преобладают алгоритмические задачи.

Тогда просто тупо практика тебе поможет.

Работаю программистом
Скорее занимаешь должность программиста.
я впадаю в полный ступор, особенно в местах, где требуется итераци по эллементам массива и инкрементация всяхих i-тых, j-тых. Причем самое интересное, что когда прихожу домой и пытаюсь решить эту задачку дома, то на бумаге решение нахожу относительно быстро, но имплементировать могу день, два, три — не меньше.
Два года физ-мат лицея мы решали такие задачи по десятку в день, причём как на листиках, в блок-схемах, так и на разных языках программирования, до аццкой тошноты. Вопрос практики.
1. Сталкивались ли кто-то с подобным — что определенная область знаний в программировании дается с очень большим трудом?
Это не область программирования — это есть сама суть программирования.
2. Стоит ли мне париться насчет этого и все таки вкладываться в эту область или забить прокачивать то, что получается?
Конечно, не стоит вкладываться. Плыви по течению, оно скоро вынесет тебя в Днепр, главное пройти запорожские пороги, дальше будет легче и сплав практически будет закончен.

Спасибо за отрезвляющий ответ)

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

Майк, а сколько в день ты проводишь на форуме доу?

По-разному, сегодня минут 20, бывает в день суммарно минут 30-40. Из общения на родном языке остался только ДОУ, я уже некоторые слова стал забывать. Часто совмещаю приятное с полезным, например, читаю форум в туалете (что из них приятное, а что полезное — я так и не определился), жаль, что он не на бумаге.

жаль, что он не на бумаге
Наоборот, приятное и полезное не улетит в трубу ;)
например, читаю форум в туалете

Воот, не зря мы так много времени потратили на оптимизацию ДОУ для мобильных устройств.

Это всё замечательно, но Я СВ просил уже долго и давно сделать кнопочку — перейти в десктопную версию, потому что на телефоне разрешение 2560×1440, что как бы намекает, что неплохо было предложить снова обычный контент :)

Хм, фича «Полная версия сайта» не пашет с айфона.

Маленькое замечание,
На iOS 10.2, iPhone 5s, 7 plus, при заполнение гугл формы когда отмечаешь радио баттон, либо когда в зарплатном виджете например в этой статье dou.ua/...es/salary-report-dec-2016 начинаеш перемещать ползунок с годами опыта кидает в конец страницы.
Особенно больше всего напрягает с Гугл формами, пару раз хотел с телефона заполнить анкету, но из-за того, что каждый раз после любого действия кидает в конец страницы — забил.

Давным давно когда деревья были большими а Америка по 60 тысяч и делал из интернета распечатки и читал именно таким путём до сих пор пачка «обраток» на складе лежит а выбросить жалко...

А дома с семьёй уже на английском полностью общаетесь? О_О

туалетная бумага величайшее изобретение человечества.
ведь именно благодаря ей (а точнее ее отсутствию) я стал программистом

да ладно тебе, обгадил человека.
я бы рекомендовал алгоритмически задачи разбивать на приватные методы, а не по 10 раз раздупляться что ты делаешь с переменной i,j,k...

я бы рекомендовал алгоритмически задачи разбивать на приватные методы
Сейчас прибегут любители вместо написать 3 приватных метода влупить еще 4-5 классов с одним методом каждый с идиотскими суффиксами типа Factory или Strategy.

банда четырёх перевернулась где бы она не была

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

А можно не утрировать попусту, а во всём искать применение и пользу в меру. И это, как правило, лучше, чем пугать говнокодингом в один файл.

Как я люблю классы у которых есть только три метода setConfig, getConfig и operator().

я бы рекомендовал алгоритмически задачи разбивать на приватные методы, а не по 10 раз раздупляться что ты делаешь с переменной i,j,k...
я може чогось не розумію..., можете навести приклад, як вищенаведену алгоритмічну задачку про мердж розбити на приватні методи? (і що це значить, і нафіга?)

Теперь метод merge как художественная литература читается! pastebin.com/WUrPnB64

окромя матів, нічого видати не можу :-)

Не могли бы вы написать задачу и показать ее как блок схему? Я художник, но дали такое задание на информатике в универе. Любую задачу. Буду благодарна

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

Тебе стоит научиться бороться «со ступором» перед людьми, что тебя интервьюируют.

А это психологическая проблема, а никак не вопрос знаний и понимания алгоритмических задач.
Просто удивительно, что ты не посоветовал бухло и каких-нибудь колёс %)

А нахрена они тут.
Ему что надо отрубиться? Чтобы бухло советовать.
А колеса нахрена, если у него по сути просто классический страх перед собеседованием или экзаменом. Да, 50 г коньяка могут чуть этот страх приглушить, но не избавить от этого страха, причем приглушат или нет сильно зависит от его печени, желудка и его гормональных особенностей.

А нахрена они тут.
Ему что надо отрубиться?
А я почём знаю? Ты всегда советуешь бухло и колёса во всех непонятных ситуациях %)

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

Ну вот, наконец-то посоветовал где найти колёс. :)

Ты всегда советуешь бухло и колёса во всех непонятных ситуациях %)

:))))

На интервью с бухлом? Годный вариант)

Утверждаю, что существуют конторы, где оное будет главным фактором твоего найма.

А в этом может помоч только практика :)
Свой первый сон про США , я увидел когда билеты были на руках ждали отъезда.
Мне приснилось, что прихожу в компанию, я усаживаюсь, интервьюверы усаживаются, а меня сверлит мысль «как же мы будем общатся если я английского не знаю».

Ну оно с трудом дается потому что как сам понимаешь всякие

i-тых, j-тых
используются только в институте при перемножении матриц и больше нигде. На работе такого не бывает. Неужели кто-то использует цикл for в java/c#? А кому нужны массивы, если есть коллекции? Дурачки таким страдают на собеседовании имхо. Задачи на sql гораздо важнее, чем вся эта хрень с циклами.

у меня тоже спрашивали замудоханные задания связанные с циклами, после вопроса «зачем?» ведь ничего подобного не будет в работе, было сказано что если не умеешь или не знаешь, то ты слабый программист. Хз...мне кажется те кто задают такие вопросы, сами не догоняют зачем это спрашивать.
П.С. в итоге пошел в другую компанию и там все ок до сих дней

у меня тоже спрашивали замудоханные задания связанные с циклами, после вопроса «зачем?» ведь ничего подобного не будет в работе, было сказано что если не умеешь или не знаешь, то ты слабый программист. Хз...мне кажется те кто задают такие вопросы, сами не догоняют зачем это спрашивать.
П.С. в итоге пошел в другую компанию и там все ок до сих дней

Вообще-то это гарантия того, что в случае нестандартной задачи ты её решишь. А просто реализовывать стандартные CRUD операции — это умеют все и тогда вообще нет смысла тебя собеседовать.

Вообще-то это ни разу не гарантия.

Вообще-то это ни разу не гарантия.

хорошо, неумение решать подобные задачи — почти 100% гарантия того, что в случае нестандартной задачи он её не решит :)

Возможно. Но в большинстве случаев как раз требуется решать стандартные задачи, причем, что важно, стандартными методами. А не изобретать очередной велосипед.

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

Ну нет. Нестандартные задачи бывают разные, и если уж появилась такова, и есть затруднения, что мешает заскочить на тот же стек и узнать как ее решить? Учитывая что сейчас реально большинство ответов можно найти на стеке (90%). Заодно и выучить раз уж на то пошло. Но не умение решать какие-то странные задачи с циклами, которые придумывает человек вообще не показатель скилла.

Да зачем вообще нанимать программеров с опытом, можно войтивайти нанять за пару сот баксов. В состоянии жмакать клавиши и нагуглить на стековерфлоу — сразу даём 23-х летний сеньор и хай педалит код.

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

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

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

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

Я бы на месте HR учитывал бы все факторы.

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

Например вопросы по технологиям, которые кандидат указал в резюме. Если ему задают вопросы по этим технология, а он и слова связать не может, то все станет ясно.
Вы правы, нужно учитывать все факторы( и их должно быть много) Если вы идете как java dev, то вы должны знать что такое коллекции, java core, не теряться в этих понятиях, уметь привести примеры ООП а не просто заучить что такое инкапсуляция или полиморфизм.
Но если человек который вас собеседует говорит что вы слабый из-за того что не можете решить логическую задачку ( а на все выше перечисленное ответили) то лучше пойти в другую контору и не терять время.

На этом все. Я выразил Вам свою точку зрения. Желаю автору удачи как и Вам Олег.

то вы должны знать что такое коллекции

Я вот этот тред читаю и люди не понимают, зачем нужны массивы, если есть коллекции. Тогда в чём смысл спрашивать кандидата, что такое коллекции, если он их по сути не отличает от массивов; как можно в таком случае ожидать понимания хеш-таблиц, очередей и т.д.? Как он представляет коллекции? Типа есть один объект определённого типа, а есть множество такого же типа и их можно сортировать/добавлять/удалять? В таком представлении и домохозяйка может выучить что такое коллекции, без преувеличения.
А вот логические задачки как раз косвенно и связаны с пониманием деталей в различии между хеш-таблицой и «коллекцией», потому как Computer Science прежде всего учит использовать правильно базовые вещи.

Есть базовые вещи, которые называются «алгоритмы и структуры данных».
И есть их конкретные реализации в виде Java Collections, C++ STL, стандартных типов в Python, сторонних библиотек в С.
И человек или понимает, как сравнивать и проходить итератором по любому возможному типу, или он просто выучил десяток стадартных приемчиков и полный ноль за их рамками.

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

Показатель.

Учитывая что сейчас реально большинство ответов можно найти на стеке (90%).

На ДОУ пропагандируют stackoverflow driven development. Мнда.

А просто реализовывать стандартные CRUD операции — это умеют все и тогда вообще нет смысла тебя собеседовать.
Спасибо. Насмотрелись уже. Вытаскивают с помощью EF таблицы в раму по 500 000 — 1 000 0000 record, а потом начинают проводить вычисления с использованием i,j,k (ну прям как на собеседовании).

странное собеседование, где для успеха будет достаточно брут форс решения

можно и гвозди телефоном забивать, только как кореллирует вытягивание огромных данных из БД для дальнейшей фильтрации с умением или неумением решать логические задания?

Просто хочу сказать, что куда важнее знать и понимать как поведет себя outer apply vs subquery на больших данных, чем игры с i,j,k.

Просто хочу сказать, что куда важнее знать и понимать как поведет себя outer apply vs subquery на больших данных, чем игры с i,j,k.

это уже совсем другой вопрос и он перпендикулярен умению решать логические задачки также, как знание ПДД зависит от умения сварить себе борщ.

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

Насколько это нормально для программиста, который с этим не работал — не сориентироваться в ситуации и не решить все таки задачу?
Считаю, что это нормально. Проработка 50-100 задачек такого типа однозначно помогут перед подобным собеседованием. Если оно того стоит — вперед.

Да все таки начинаю склонятся к мысли, что это вопрос практики. Как раз этого мне не хватает

если очень хочется получить работу, то конечно стоит. Слишком сильно ли оно тебе поможет в будущем да(нет).

Просто если брать по факту — ты не решил, а кто-то другой решил — значит кто-то другой и будет лучшим и его возьмут. И очень часто так и происходит.

Таки да — берут тех, кто лучше, гибче и быстрее. Сенсация!

А кому нужны массивы, если есть коллекции?

Массивы быстрее. Попробуй сделать кластеры/чанки в майнкрафте под мобильную версию, используя списки, а не массивы.

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

Далеко не все операции над данными можно сделать с помощью Linq. К тому же никто не отменял генерацию данных. В геймдеве циклы чуть ли не в каждом классе. Возможно у вас просто другие задачи, к примеру, интеграция какого-то фреймворка в систему.

Задачи на sql гораздо важнее, чем вся эта хрень с циклами

У каждого направления свои приоритеты. Не нужно так абсолютизировать.

Ты пропустил все через призму геймдева. А мы с ТС живем в другом мире, где 99 % производительности теряется при работе с базой.

Далеко не все операции над данными можно сделать с помощью Linq
Больше чем половину нельзя так точно. Поэтому делаем упор на sql.
Массивы быстрее. Попробуй сделать кластеры/чанки в майнкрафте под мобильную версию, используя списки, а не массивы.
Я недавно брался за голову от таких чудесатиков. Нужно организовать мини-кеш выделенных участков памяти, чтобы постоянно не дёргать аллокатор. Участков памяти всего 5 и других значений принципиально быть не может, так как связано с аппаратурой, хотя число 5 и спрятано за макросом. Делается массив и тривиальный поиск нужного участка памяти. На коудревью повылазили умники — массивы это детский сад, используй списки. Потом пришли к тому, что нужны красно-чёрные деревья и массив нужно хранить в отсортированном виде и прочее. Многие просто стыдятся использовать массивы, считая это ньюби уровнем и прочее. Я столько фейспалмов за всю свою жизнь не раздавал %)

Та це крізь. Набіжуть хом’ячки, давай пихато хейтити якусь технологію. А потім через свою пихатість страждають.

Неужели кто-то использует цикл for в java/c#?

Использую цикл for в пхп. Уделал этих ссаных джавистов и сишарпников. Учись, молодежь.

Неужели кто-то использует цикл for в java/c#? А кому нужны массивы, если есть коллекции?

Вы серьёзно спрашиваете?

Задачи на sql гораздо важнее, чем вся эта хрень с циклами.

если Вы про разные JOINы — то подобные решения находятся без проблем, даже забыв синтаксис (я, кстати, его «в этом месте» почему-то постоянно забываю), если что-то сложное — тогда это будет всё те же задачки на логику, просто SQL направленности

Неужели кто-то использует цикл for в java/c#? А кому нужны массивы, если есть коллекции?

просто так сложилось, что для большинства девелоперов лист или коллекция универсальная струрктура данных и терпимая с точки зрения производительности на высоком уровне абстракции, на котором кодят множество девелоперов с#/java. Напротив же на более низком уровне во многих задачах это недопустимо. Чего стоят последние тендеции в том же дотнете — появление структур и АПИ, которые стремятся избегать аллокаций и обработки данных в обход GC — привет высокоуровневое апи, которое внутри юзает массивы, стек, указатели, счетчики и никакого Heap’a, в том же asp.net core основной pipeline полностью описан путем использования switch goto и никаких делегатов и излишних обьектов в Heap’e + одни циклы везде.
В целом это мало отношения имеет к алгоритмам, скорее к оптимизации скорости и работы приложения с памятью, но без этого никак и это надо знать почему список работает медленно.

ТС занимается веб-скриптованием с использованием «хибернейт», что уже говорит о том, что все эти оптимизации на уровне коллекций до глубокой сра*ки и уже одно упоминание «хибернейт» все эти потуги сведет к нулю. А так я все понимаю о чем речь конечно.

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

сейчас циклы в жаве уже не модно, модно функциональный стиль с лямбдами

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

Подписаться на комментарии