Новичку очень трудно найти работающие примеры кода на фреймворках, потому что языки и фреймворки быстро меняются. У меня было большое количество случаев, когда новички не могли «припаять» друг к другу коды из двух курсов по Laravel/Yii/Angular/Vue и других, потому что эти куски кода от разных версий.
На ютубе надо обязательно смотреть дату выпуска кастов, они должны быть не позже чем год от сегоднящнего числа.
Не многие онлайн школы готовы обновлять курсы ежегодно. Даже англоязычные курсы устаревают очень быстро.
Интересно наблюдать когда лид передаёт функции код-ревью в команду, заставляет делать перекрёстный код-ревью.
Никто один не умнее кого-либо одного. У них разные ценности и разный способ мышления. Перекрёстный код-ревью позволяет обмениваться не только коду, но и ценностями и мыслями.
А лид выступает как фасилитатор процесса ревью.
Это полезно. Снимает с лида груз ответственности за боль. Даёт каждому в команде возможность стать лучше.
Во таких задачах должны быть оценки регрессии к среднему, а не оценка интуитивных предсказаний (там слишком много деталей, которые отвлекают), поэтому лучше начать с фразы «предоставьте статистику, пожалуйста».
У человека не 3D зрение, а стерео. Плюс мы видим объекты в движении.
Мы совмещаем два изображения, фиксируемые из наших глаз с небольшой разницей в угле и это позволяет строить несколько моделей наблюдаемых объектов в перспективе и определять взаимное расположение по глубине (дальше/ближе, за/перед).
Задняя невидимая часть нам неизвестна. Даже если это стекло. А вот выпуклость/вогнутость имеет ценность. Если один глаз закрыть, то стерео картинки не будет и мы начнём ошибаться в форме, размерах и относительном положении объектов.
Движение объекта тоже является ценным. По движению мы достраиваем невидимые стороны объектов. Если мы и объекты неподвижны, то мы тоже ошибемся.
Думаю, компьютерному зрению нужно подавать стерео-картинки или небольшие фрагменты видео (2-5 кадров), тогда алгоритмы будут определять объекты намного точнее.
На выдачу «нормального фидбека» требуется время, его часто не хватает.
Текстовый вариант ответа на некачественное решение звучит так: «При анализе решения были найдены значительные ошибки, код оформлен некачественно, алгоритмы выбраны неудачные, код не соотвествует концепции этого фреймворка… (пара абзацев, у каждого своё).» Это 5 минут или меньше. Стандартный ответ.
Если замечаний по качественной работе на 5 минут, то фидбэк будет.
Но если речь про нормальный ответ на разбор некачественно выполненой работы. то я пишу видео (скринкаст) разбора. Вслух высказываю найденные замечания (ещё раз). Про плохо оформлленный результат, недопонимание задания, про синтаксические/логические ошибки, про конвенцию фреймворка, про комментирование. Про SOLID, паттерны и про «запахи» кода, если совсем худо. Если кандидат думает, что он синьор и хочет работать в команде, а он не синьор и пишет «так, для себя».
Разбор занимает не 5 минут. И если кандидат не настаивает на разборе результатов — он не делается. Так вот, просили всего несколько человек. Я не против, но если не просят — зачем делать?
Я открыт к обмену опытом, и навыки есть. Была бы потребность. В последнее время разбор делал даже не в режиме видео, а в формате конференции с расшаренным экраном. Чтобы можно было услышать вопросы от кандидата, а не вещать как проповедник.
Кстати, по просьбе я делаю разбор результатов, которые отклонены другими софтвёрными компаниями без фидбека. Кандидаты просто в растерянности, что именно не так в их решении. Иногда в результате разбора претензий к коду нет (выполнено по заданию, написано понятно, по конвенции, с тестами). Наверное этих кандидатов отклонили по другим причинам. Я им рекомендую хорошо выполненные задания публиковать на github и вставлять в портфолио.
При обходе массива чисел попарно сравнивать два рядом стоящие a[i] и a[i+1] и менять местами если a[i+1] < a[i]
Повторять обход с самого начала, пока таких перестановок не встретится.
Да и это ломает мозг :(
Когда переходил с проекта на проект, где невозможно показать код и обсуждать технические решения, помогали две вещи: несложные тестовые задания на 1-2 дня и устные технические собеседования. Задания обычно не под NDA и я их с чистой совестью использовал дальше для демонстрации хорошего кода, а некоторые и для своих нужд (например, сокращатель ссылок как тест и для себя)
На тостере дал ответ на такую же ситуацию https://toster.ru/q/449109#answer_1064583
Думаю, эти стартаперы искали точки душевного соприкосновения, единство целей и интересов. Уверен, на посиделки они пригласили не на первый этап, а ещё в remote режиме предварительно уровень компетенции проверили.
Скорее пишут сортировочные функции для сложных случаев сортировки. Ну там, по коэффициенту массы тела, имея только пол, возраст, рост и вес. Это навскидку.
Спросили как то меня, что нужно чтобы построить дом. Я перечислять устал.
Про карандаш — некорректный пример. Знает как минимум технолог, возможно тех директор. Это же ежедневный процесс, он всегда на виду, всегда мониторится.
Хороший тимлид ищет человека, очень совместимого с ним
Люди ищут окружение с совпадающей точкой зрения и похожим уровнем компетенции. С сомнением смотрят на тех, кто лучше (можно ли мне у него научиться быть лучше?) и на тех, кто хуже (способен ли он научиться быть как я?). Ну не все конечно. Есть открытые для улучшения и есть готовые улучшать других.
В книге Tribal Leadership хорошее объяснение с примерами.
На ютубе надо обязательно смотреть дату выпуска кастов, они должны быть не позже чем год от сегоднящнего числа.
Не многие онлайн школы готовы обновлять курсы ежегодно. Даже англоязычные курсы устаревают очень быстро.
Никто один не умнее кого-либо одного. У них разные ценности и разный способ мышления. Перекрёстный код-ревью позволяет обмениваться не только коду, но и ценностями и мыслями.
А лид выступает как фасилитатор процесса ревью.
Это полезно. Снимает с лида груз ответственности за боль. Даёт каждому в команде возможность стать лучше.
Мы совмещаем два изображения, фиксируемые из наших глаз с небольшой разницей в угле и это позволяет строить несколько моделей наблюдаемых объектов в перспективе и определять взаимное расположение по глубине (дальше/ближе, за/перед).
Задняя невидимая часть нам неизвестна. Даже если это стекло. А вот выпуклость/вогнутость имеет ценность. Если один глаз закрыть, то стерео картинки не будет и мы начнём ошибаться в форме, размерах и относительном положении объектов.
Движение объекта тоже является ценным. По движению мы достраиваем невидимые стороны объектов. Если мы и объекты неподвижны, то мы тоже ошибемся.
Думаю, компьютерному зрению нужно подавать стерео-картинки или небольшие фрагменты видео (2-5 кадров), тогда алгоритмы будут определять объекты намного точнее.
Если замечаний по качественной работе на 5 минут, то фидбэк будет.
Но если речь про нормальный ответ на разбор некачественно выполненой работы. то я пишу видео (скринкаст) разбора. Вслух высказываю найденные замечания (ещё раз). Про плохо оформлленный результат, недопонимание задания, про синтаксические/логические ошибки, про конвенцию фреймворка, про комментирование. Про SOLID, паттерны и про «запахи» кода, если совсем худо. Если кандидат думает, что он синьор и хочет работать в команде, а он не синьор и пишет «так, для себя».
Разбор занимает не 5 минут. И если кандидат не настаивает на разборе результатов — он не делается. Так вот, просили всего несколько человек. Я не против, но если не просят — зачем делать?
Я открыт к обмену опытом, и навыки есть. Была бы потребность. В последнее время разбор делал даже не в режиме видео, а в формате конференции с расшаренным экраном. Чтобы можно было услышать вопросы от кандидата, а не вещать как проповедник.
Кстати, по просьбе я делаю разбор результатов, которые отклонены другими софтвёрными компаниями без фидбека. Кандидаты просто в растерянности, что именно не так в их решении. Иногда в результате разбора претензий к коду нет (выполнено по заданию, написано понятно, по конвенции, с тестами). Наверное этих кандидатов отклонили по другим причинам. Я им рекомендую хорошо выполненные задания публиковать на github и вставлять в портфолио.
И тот, что решает конкретно твою беду, будет иметь 0 голосов «за» :)
Повторять обход с самого начала, пока таких перестановок не встретится.
Когда переходил с проекта на проект, где невозможно показать код и обсуждать технические решения, помогали две вещи: несложные тестовые задания на 1-2 дня и устные технические собеседования. Задания обычно не под NDA и я их с чистой совестью использовал дальше для демонстрации хорошего кода, а некоторые и для своих нужд (например, сокращатель ссылок как тест и для себя)
На тостере дал ответ на такую же ситуацию https://toster.ru/q/449109#answer_1064583
Про карандаш — некорректный пример. Знает как минимум технолог, возможно тех директор. Это же ежедневный процесс, он всегда на виду, всегда мониторится.
Люди ищут окружение с совпадающей точкой зрения и похожим уровнем компетенции. С сомнением смотрят на тех, кто лучше (можно ли мне у него научиться быть лучше?) и на тех, кто хуже (способен ли он научиться быть как я?). Ну не все конечно. Есть открытые для улучшения и есть готовые улучшать других.
В книге Tribal Leadership хорошее объяснение с примерами.