Наскільки програмісту важливо знати, як реалізувати алгоритм QuickSort / MergeSort з пам'яті? [зачинено]

Я переглядав свої замітки і натрапляв на реалізацію різних алгоритмів сортування.

Коли я намагався осмислити реалізацію QuickSort і MergeSort, мені прийшло в голову, що, хоча я займаюся програмуванням на життя і вважаю себе гідним, чим займаюся, у мене немає ні фотографічної пам'яті, ні чистої мозкової сили, щоб реалізувати ці алгоритми без спираючись на мої записки. Я пам’ятав лише, що деякі з цих алгоритмів є стабільними, а деякі - ні. Деякі потребують часу O (nlog (n)) або O (n ^ 2). Деякі використовують більше пам'яті, ніж інші ...

Я відчуваю, що я не заслуговую на таку роботу, якби не вона, тому що моя позиція не вимагає, щоб я використовував будь-який алгоритм сортування, окрім тих, що знайдені у стандартних API. Я маю на увазі, скільки у вас є посада програмування, де насправді важливо, щоб ви могли запам'ятати або придумати такі речі самостійно?

Давайте запитаємо Альберта і подивимось, що він має сказати з цього приводу:

"Мені не потрібно все знати, я просто повинен знати, де її знайти, коли мені це потрібно"

- перефразовано Альберт Ейнштейн

Амінь, брат Альберт, амінь.

Після того, як ви добре проаналізували основні алгоритми в будь-якій конкретній дисципліні (сортування, пошук, будь-яке інше), ви можете забути про деталі реалізації, поки вам фактично не знадобиться альго, і в цьому випадку ви переглянете його або скористаєтеся попередньо існуюча lib. 25 років тому я створив основну пошукову систему за допомогою B * -трей, але сьогодні мені знадобиться RTFM, щоб добре їх використовувати.

1. Це насправді не питання запам’ятовування. Це питання глибокого розуміння загальних класів алгоритмів, таких як ділити і перемагати. Якщо ви дійсно розумієте розділення і перемогу, то вам не потрібно запам’ятовувати швидкості. Ви можете вивести його на місці за потребою. Крім того, справжня виплата не полягає навіть у тому, що ви зможете самостійно відновити хитрощі, це те, що ви можете розпізнати, коли нова проблема підлягає розриву і перемогу.

2. Не всі завдання програмування однакові. Деякі завдання потребують глибокого знання алгоритмів, деякі потребують людей, які розуміють теорію типів, а деякі просто потребують людей, які можуть скребки даних із веб-форми та переміщення їх у базу даних. Деяким робочим місцям навіть потрібні всі ці навички одразу. На якій роботі ви хочете працювати?

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

У мене були співробітники, які переписують quicksort та інше, але я постійно кажу їм повернутися до використання вбудованих функцій сортування, які є в мові. Я знаю, що залежно від того, над якими типами проектів ми працюємо, ми повинні пам’ятати інші алгоритми, оскільки вони зазвичай не включаються до стандартних бібліотек, але сортування не є тим, що з'являється, оскільки воно зазвичай вбудовано в мову.

Коли нам потрібно пам’ятати ці алгоритми, ми зазвичай звертаємося до google чи книги, і зазвичай це не пошук конкретної реалізації, а яка найкраща реалізація для нашої проблеми.

Просто запам'ятати, який алгоритм корисний у яких сценаріях, було б більш ніж достатньо, щоб допомогти під час вашої роботи. Насправді, більшість завдань програмування не потребує запам'ятовування підходу, скоріше вони зацікавлені у вашому способі розпізнавання алгоритмічного шаблону при зіткненні з проблемою .

Власне кажучи, у більшості програмних блогів / статей на теми алгоритмів є велика кількість інформації. Таким чином, запам'ятовування точної реалізації не має значення. Найціннішою інформацією буде отримання основного уявлення про те, який тип алгоритму доступний, і яку конкретну проблему вони добре вирішують . Пошук точної реалізації, коли ви знаєте, що шукаєте, відбувається досить швидко.

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

Точна реалізація не дуже важлива. Але принцип, що стоїть за об'єднанням / кваксортом - рекурсія, розподіл тощо, є дуже базовим і кожен програміст повинен розуміти. Цей алгоритм насправді дуже просто описати словами, коли ти зрозумієш.

Це насправді не проблема в тому, чи можете ви її шукати, чи можете ви в Google, а чи програміст розуміє ці методи вирішення проблем і чи зможе застосувати їх до інших ситуацій.

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

Мені важко отримати неупереджену відповідь на цю тему, оскільки я програмую так довго, напевно, я забув більше алгоритмів, про які я зараз знаю, - але я все ще знаю сортування, згадане в цьому питанні. Я думаю, що лідери думок Agile (наприклад, Рон Джефріс, Алістер Кокберн) мають непогані ідеї поблизу цієї ідеї (наприклад, Шу-Ха-Рі).

Підсумовуючи цю невпинну відповідь: Однозначно використовуйте API (NIH - ознака незрілості розробника), але завжди розумійте основні принципи. Я сподіваюся, що це допомагає.

Сортування та пошук надзвичайно важливі, чи є ви прихильником Дональда Кнута чи хочете стати наступним Ларрі Пейдж. Залежно від бізнесу, в якому ви перебуваєте, та рівня конкуренції, якою ви можете керувати серед своїх кандидатів, я рекомендую вам включити в інтерв'ю деякі наступні поняття.

Сортування

• Ескіз якогось алгоритму сортування.
• Перерахуйте кілька прикладів алгоритмів сортування.
• Порівняйте / порівняйте два сорти з різними характеристиками.
• Якщо вони не згадують про використання пам'яті, запитайте про це.

Пошук

• Назвіть якомога більше алгоритмів пошуку.
• Порівняйте / порівняйте два алгоритми пошуку.
• Накресліть будь-який пошук, окрім лінійного пошуку.

Дехто може сказати, що вимагати код для цих алгоритмів є надмірним, якщо робота не знаходиться на безлюдному острові без підключення до Інтернету. Ще одна думка полягає в тому, що якщо у вас є 30 хвилин, і ви хочете запитати про що-небудь інше, для багатьох кандидатів реалізація сорту може зайняти великий шматок вашого часу.