Мати для кожного ПР свій тул сет і різні способи для проведення ревʼю, на мій погляд, значно ускладнює процесс. Та, з великою вирогідністтю, звужує коло ревʼюверів, тому що кожен хоче отримати якісне ревʼю, але не кожен може його дати.

В своїх командах я завжди намагаюся будувати якісні прроцеси та вводити правила, які сможуть спростити життя чи вберегти від помилок. Проведення код ревʼю не повино бути викликом.
Бувають і великі ПР, коли зводеться велика фіча, чи збирається великий реліз, але точно це не повинні бути кожне 1-2 ПР. І навіть всі ті великі ПР були колсь маленькими. 300-500 рядків бізнес-коду — це золоте правило на яке орієнтуюся я і яке вже допомагає моїм товаришам по команді

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

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

Не зміг знайти у вас в main гілці рішення, але побачив щось за тегом v1.8 — github.com/...​uent_elements/Solution.kt

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

На leetcode також є багато задачок с SQL і є набагато хитріші)

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

Згоден з вами. Думаю якщо хтось використав виклик бібліотечної функции (наприклад most_common(k)), то наступне питання було би пояснити як вона працює підкапотом та чи можете ви її написати самі.

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

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

ChatGPT крута та дуже потужна річь, але має проблеми з поясненням та інколи не вчитується в контекст питання або навмисне спрощує. Експерементував з ним і ставив одну та туж саму задачу двічі, але другий раз додав частку «не», яка змінила сути запиту в корені. Наприклад,
1 — видати Н унікальних чисел з массиву
2 — видати Н не унікальних чисел з массиву
Обидва рази рішення були однакові(

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

Маєте рацію, але не забувайте, що в гіршому кейсі ви прийдете до O(n^2)

Дякую за цей лайфхак. Полюбляю аналізувати та порівнювати код щоб зрозуміти чому в той чи іншій ситуації він працює краще/швидше/і тд