(UA) IT/Tech Ukrainians in Canada
-
Питати про те як писать читаемий код - власне написання коду це те чим всі займаються, а на інтервью майже ніколи не запитують
-
о, в мене навіть стікер є для такої ситуації, колись в автоклубі нашому сталось))
-
Та норм все, це оптимально. Взагалі підходи з мепінгом однієї структури на іншу часто використовуються в інших задачах типу LRU чи LFU чи ще якихось page replacement algorithm, які на інтерв’ю. Можна було б ще порозмірковувати про overflow на average чи concurrency проблеми чи над іншими рішеннями, якщо б знати requirements по часу, величині значень, use case, але для універсального кейсу звучить 👍
-
Я не можу у тебе питати те що ти будеш робити на роботі, бо 99% що ти ніколи з цим не працював, якщо ти до цього не був в компанії колись. Тому придумали більш дженералізований спосіб. Якщо є кращі пропозиції для відбору з потоку кандидатів, то всі тільки виграють від цього :)
-
То як алгоритми покажуть підхід до вирішення проблем?
-
Щось типу «як то розуміешь коли функція стає завеликою і потрібно її розбивати»
-
А не заставляти писати код
-
Це можна питати
-
То це ж ти побачишь процесс мислення для розвязання алгоритмічних задач - а не процесс мислиння реального скілла программування
-
На жаль, я замість doubly ll почав використовувати queue 😐
-
В реальній роботі код дуже простий с точки зору алгоритмів, але дуже обємний, і ключова задача це гарно його декомпозувати по файлам/функціям/классам. Зробити правильні абстракціі, правильну залежність
-
Я наймав тільки джунів, не думаю що це релевантно
