Я не говорю что это не нужно, я не понимаю почему это так важно на собеседовании?
Вам же ни когда не дадут задание «напишите двоичный поиск» в работе
У вас будет куча других заданий по поиску чего либо где либо.
А вот как вы это реализуете — показатель вашего умения как программиста.
Мое мнение такое.
Человеку важнее знать какие алгоритмы есть и где они используются, нежели среди ночи уметь их реализовывать.
Мне кажется больше толку будет от человека, который знает для чего нужен двоичный поиск, даже если он не смог его реализовать на собеседовании на листке бумаги, нежели человек, который зазубрил реализацию двоичного поиска, а нахрен он нужен — не знает.
Вы не согласны?
Можно пример задачи, где это так нужно знать? (я про двоичный поиск)
Поиск в тексте — не похоже
Поиск в отсортированном массиве — хорошо, а зачем? Плохо спроектировано что то?
Поиск в дереве — лучше, но это пишется 1 раз и работает годами.
Поиск в хеш таблице? Используется хешмап или array PHPшный, работать будет быстрее, нежели сам напишешь. PHP функции — скомпиленные, а самописный код — интерпретируемый + создает кучу мусора в памяти.
Я не думаю что знание двоичного поиска это один из вопросов
«проснись ночью и напиши мне алгоритм»
А на собеседованиях просят на бумаге это сделать… что не есть гуд.
Блок схему нарисовать — пожалуйста, а вот в коде, да еще на PHP, а прошлую неделю ты сидел в Java и bash… :)
Самое забавное что бинарный поиск мне приходилось реализовывать всего 2 раза (за 10 лет)
1) когда читал Вирта
2) когда изучал fork join на java
во всех остальных случаях за меня это делали всякие библиотеки.
Это так же с предметом «Стандартизация и спецификация» (как то так)
Мы проходили то, что «все гайки сделаны по стандарту, по этому есть стандартные ключи»
Для любого Советского ребенка это само собой разумеющееся было и подумать об обратном в голову не приходило.
Такая же фигня с принципом Парето.
9 из 10 моих знакомых знают правило 20/80, 3 из 10 вывели его сами в процессе взросления/получения опыта
А то что это именно ОН — знают человека 1-2.
Как был пример выше
Оцените ваш код от 0 до 10……
Мы узнали что мы можем назвать любое число от 0 до 10
Я знаю что местами он хороший, местами плохой. Доказывать это не вижу смысла.
Когда приходится поддерживать плохой код переписывается.
Есть конечно плохой код, который живет уже 8 лет. Но живет себе спокойно и ни кому не мешает.
Что такое рефакторинг и т.д. и как делать хорошо я знаю.
Хотите взять на работу — открою код.
неа
Они и называются РОН (Регистры общего назначения)
А вот вызов API как с любым апи
регистры — переменные функции, остальное ты сам кладешь в стек, чтобы вытащить потом нужные тебе данные.
за один день очень сложно даже на 2х писать
в разные дни на разных — пофиг.
Нарисовал себе UML диаграмки, в тетради набросал алгоритмы/автоматы, и пиши себе потихоньку.
я не работаю в команде, по этому не могу не знать что такое «хороший код».
Есть задача, она решается, практика показывает, что мои решения работают годами без сбоев.
Про слабую связанность могу сказать сразу.
О ней можно почитать, но ты не поймешь нахрена она нужна, пока тебе не попадется огромный проект, а он может попасться только на работе, на которую тебя не берут, пока ты не узнаешь что такое слабая связанность. :)
Я сначала изучил Visual Basic
Потом assembler
Почему у вас возникли сложности?
Используем api bios или os — 16h? и 21h(dos) соответственно.
Причем на разные подсистемы у bios разные прерывания.
Закинули что и куда нужно, вызвали int 21h, забрали результат.
Это я всё знаю. Просто тут одни говорят что это нужно и хорошо, вы говорите что плохо.
Выходит что для забивания гвоздей — молоток, а для закручивания гаек — ключ
Зачем тогда «требовать» решение задачи через рекурсию?
А средний уровень ЗП джуниора какой?
через сколько можно претендовать на другой уровень ЗП? (в среднем)
Вам же ни когда не дадут задание «напишите двоичный поиск» в работе
У вас будет куча других заданий по поиску чего либо где либо.
А вот как вы это реализуете — показатель вашего умения как программиста.
Мое мнение такое.
Человеку важнее знать какие алгоритмы есть и где они используются, нежели среди ночи уметь их реализовывать.
Мне кажется больше толку будет от человека, который знает для чего нужен двоичный поиск, даже если он не смог его реализовать на собеседовании на листке бумаги, нежели человек, который зазубрил реализацию двоичного поиска, а нахрен он нужен — не знает.
Вы не согласны?
Поиск в тексте — не похоже
Поиск в отсортированном массиве — хорошо, а зачем? Плохо спроектировано что то?
Поиск в дереве — лучше, но это пишется 1 раз и работает годами.
Поиск в хеш таблице? Используется хешмап или array PHPшный, работать будет быстрее, нежели сам напишешь. PHP функции — скомпиленные, а самописный код — интерпретируемый + создает кучу мусора в памяти.
Я не думаю что знание двоичного поиска это один из вопросов
«проснись ночью и напиши мне алгоритм»
А на собеседованиях просят на бумаге это сделать… что не есть гуд.
Блок схему нарисовать — пожалуйста, а вот в коде, да еще на PHP, а прошлую неделю ты сидел в Java и bash… :)
1) когда читал Вирта
2) когда изучал fork join на java
во всех остальных случаях за меня это делали всякие библиотеки.
Мы проходили то, что «все гайки сделаны по стандарту, по этому есть стандартные ключи»
Для любого Советского ребенка это само собой разумеющееся было и подумать об обратном в голову не приходило.
Такая же фигня с принципом Парето.
9 из 10 моих знакомых знают правило 20/80, 3 из 10 вывели его сами в процессе взросления/получения опыта
А то что это именно ОН — знают человека 1-2.
Никогда не слышал про SOLID, но знаю и стараюсь соблюдать все принципы SOLID, не подозревая о том, что это SOLID...)
Оцените ваш код от 0 до 10……
Мы узнали что мы можем назвать любое число от 0 до 10
Я знаю что местами он хороший, местами плохой. Доказывать это не вижу смысла.
Когда приходится поддерживать плохой код переписывается.
Есть конечно плохой код, который живет уже 8 лет. Но живет себе спокойно и ни кому не мешает.
Что такое рефакторинг и т.д. и как делать хорошо я знаю.
Хотите взять на работу — открою код.
Бросить всё и кодить тихо в углу :)
Они и называются РОН (Регистры общего назначения)
А вот вызов API как с любым апи
регистры — переменные функции, остальное ты сам кладешь в стек, чтобы вытащить потом нужные тебе данные.
в разные дни на разных — пофиг.
Нарисовал себе UML диаграмки, в тетради набросал алгоритмы/автоматы, и пиши себе потихоньку.
я не работаю в команде, по этому не могу не знать что такое «хороший код».
Есть задача, она решается, практика показывает, что мои решения работают годами без сбоев.
Получается что то в этом роде
habrastorage.org/files/643/fb5/4ac/643fb54ac9444b7896a646e2544ae2dc.png
дебажить ассемблер — одно удовольствие
Что ты написал, то и дебажишь :)
Знания минимальные
смотришь что в регистрах, смотришь что в стеке.
Как кубики собирать :)
О ней можно почитать, но ты не поймешь нахрена она нужна, пока тебе не попадется огромный проект, а он может попасться только на работе, на которую тебя не берут, пока ты не узнаешь что такое слабая связанность. :)
Потом assembler
Почему у вас возникли сложности?
Используем api bios или os — 16h? и 21h(dos) соответственно.
Причем на разные подсистемы у bios разные прерывания.
Закинули что и куда нужно, вызвали int 21h, забрали результат.
Выходит что для забивания гвоздей — молоток, а для закручивания гаек — ключ
Зачем тогда «требовать» решение задачи через рекурсию?
Я был молод и верил всему что пишут в журналах.
Задают «вопрос в лоб» без объяснений. Можно было просто тест сделать.
Если вы правда пытаетесь дойти до цели, то вам большой и жирный плюс.