Может это будет звучать очевидно, но для многих это не так, судя по комментариям: чтобы хорошо пройти собеседование не обязательно дать правильные ответы на каждый вопрос. Задача интервьюера - нащупать слабые места и глубину знаний кандидата, а не прогнать по формальному чек-листу и подсчитать сумму баллов. То есть результат определяет достижение необходимой глубины по всем важным областям, а не количество правильных ответов.
Если вас умудрились "завалить" только на вопросах-ультрахард, где нужны энциклопедические знания или специфический опыт, то вы - большой молодец и наверняка получите респект от интервьюера, хотя и не ответили. Если же кандидат знает везде, но лишь по верхам - то дальше рискует не пройти, не смотря на количество правильных ответов.
Как это сакральное знание влияет на написание кода?
Если вы знаете устройство платформы, ее сильные и слабые стороны, это позволит делать более производительный, экономный по ресурсам код. Это позволит со знанием дела анализировать проблемы по памяти и пользоваться профайлером.
Не знать совсем глубоких нюансов или забыть детали - это нормально и едва ли это "снимет баллы". Но если кандидат позиционирует себя опытным специалистом, а при упоминании поколений объектов делает совсем круглые глаза и/или несет окровенный бред, то это, как минимум, повод насторожиться и прощупать базу. Может это единственный пробел, тогда это не проблема, но если там откроется бездна, то использование избитого вопроса окупится сполна.
Это профанация, которая конфликтует с законами, но подается под видом серьезной бумаги. Равно как документы на иностранных языках без перевода, запрет на трудоустройство к конкурентам после увольнения, какие-то конские прописанные штрафы и подобные финты, не предусмотренные ТК.
Если NDA противоречит законам юрисдикции, то оно идет лесом юридически ничтожно.
Федеральный закон от 29.07.2004 N 98-ФЗ (ред. от 08.08.2024) "О коммерческой тайне":
Статья 5. Сведения, которые не могут составлять коммерческую тайну:
о численности, о составе работников, о системе оплаты труда, об условиях труда, в том числе об охране труда, о показателях производственного травматизма и профессиональной заболеваемости, и о наличии свободных рабочих мест;
Тем не менее, заработная плата может быть персональными данные работника (программист Олег у нас в компании Y зарабатывает 300 к₽/с), поэтому про коллегу рассказывать нельзя. Но можно сказать, что программист у нас в компании Y зарабатывает 300 к₽/с.
ORM делает простым и без того простое, а сложное - еще сложнее.
Пока не запустите - не добудете запрос, можете лишь полагаться на опыт и здравый смысл, прогнозируя выхлоп, а EF умеет удивлять. Экспрешны дают некоторую статическую типизацию, но если углубиться в их генерацию - можно здорово наотстреливать ног в рантайме, да так, что ревьюер не догадается, а компилятор - не подстрахует.
С другой стороны, писать запросы руками - это не сложное занятие, с маппингом типов справится какой-нибудь Dapper. Даже если запрос билдится - это будет что-то тривиальное, сложностью управлять здесь очень просто, в отличие от абстракций экспрешнов с СУБД-специфичной трансляцией. Статической проверки типов в запросе нет, но явные имена полей и таблиц поддаются грепу.
Для таких запрсов имеется RAW режим.
Когда сырых запросов достаточно много, возникает вопрос: а стоит ли игра свеч? Стремились к простоте, а получили ласкутное одеяло технологий, альтернативных решений и срачи в ревью о границах допустимой сложности.
К тому же, EF Core лишь относительно недавно вообще научился запрашивать unmapped types, без чего в этом режиме было мало смысла.
При таком подходе запрос не засоряет Go код и удобно читается.
Но зачем? Запрос - это полноценная часть логики, в чем выигрыш вынесения в отдельный файл? Тут упомянали анализ инструментами, но ведь тот же GoLand умеет проверять SQL в литералах.
Это все, чтобы легитимизировать для себя использование margin для блоков? 😉
Проблема с отступами — в чистом БЭМе блок не должен иметь margin, поэтому приходится создавать дополнительные обертки
Сложность переиспользования для позиционирования — приходится создавать множество модификаторов (block_position-top_margin-left_slightly-to-the-right-no-not-that-right-a-bit-more... идеально!)
То есть в п.4 вы решились нарушить п.2 и поплатились 😁
Разве схлопывание марджинов - это не та сложность переиспользования, с которой предназначены бороться обертки с паддингами?
Типичная работа, допустим, на 95% состоит из простой рутины, а, условно, оставшиеся 5% - из поиска неочевидных проблем/внедрения чего-то нового, что требует некоторой эрудиции и глубины знаний. Позиция звучит так, будто вопросы, актуальные для этх 5% не относятся к "реальной вакансии". Но ведь и эту часть работы тоже необходимо выполнять.
Адаптация подвела. Оригинальная книга опирается на Java 7-, до появления Optional<T>, сейчас этот совет звучал бы иначе. А в C# совет тоже работал, но потерял актуальность с недавних пор - завезли свой эрзац-optional в виде признака нуллабельности референсных типов.
Тем не менее, NRE - это однозначное зло, допускать их появление (полагаться на них, как на ассерт, к примеру)- плохая идея.
Плюсов много, да, но не соглашусь, что решение идеально.
Объединение нескольких (списков типов/discriminated unions) ошибок в единственный тип при пробросе ошибок наверх - это боль и туча бойлерплейта маппинга типов, а рефакторинг в таких условиях - дабл-боль. А если еще и вручную проверку результата нужно делать (отстствует аналог растового ?) - трипл-боль, код раздувается огромным количеством шума чуть ли не в разы (получи результат => проверь результат и подними ошибку => распакуй результат).
Обработка исключений этих проблем лишина, т.к. появляется только там, где это имеет смысл, никаких обвязок для проталкивания ошибки наверх и "запаковки типов" не нужно => нет кода - нет и необходимости его поддерживать.
Не возвращайте null! Это источник NullReferenceException ... используйте Nullable для значимых типов, применяйте паттерн Null Object.
Скорее всего подразумевалось противопоставление: "НЕ используйте Nullable, а применяйте паттерн Null Object".
Так же в контексте C# хотелось бы оговорки про nullability.
Используйте исключения, а не коды ошибок.
Все чаще встречаю проекты, где тем или иным образом пытаются делать свои решения в стиле растового Result<TResult, TErr> для обработки возможных/ожидаемых ошибок, а исключения - оставлять лишь фатальным, которые ловить сильно выше с целью только залоггировать. Как ни крути, но исключения - это дорогое удовольствие, подход Errors are values идет в массы.
Индустрия методом проб и ошибок рождает решения, совершенствуется. Очень часто случается, что сценарий использования не совпадает с идеями, на которыми инструмент создавался. На каждом углу трубят, что для каждой задачи - свой инструмент, так как же понять границы применимости и сильные/слабые стороны, если все время не шатать их обсуждением опыта с коллегами? Каждый такой наброс - это приглашение к дискуссии, проверка гипотезы.
Но тут интересно другое:
грязью облить
почему хейт инструмента скорбляет вас лично? Или вы глубоко в душе сами боитесь найти несокрушимый аргумент, разочароваться и пожалеть о том, сколько сил и времени вложили?😉
Используя программу Putty и предоставленные IP адрес и пароль, нужно войти на сервер
Как насчет перевода SSH логина на ключи? Вроде и само собой разумеющееся действие, но инструкция претендует на подробность, а о такой важной штуке ни слова.
"есть csv с такими-то столбцами, надо ее загрузить, отфильтровать, перевернуть и выгрузить в json"
Функционал вряд ли будет висеть в воздухе - его надо будет интегрировать в существующую кодовую базу, что резко поднимает сложность задачи для нейронки.
сейчас проще не поручать
Даже в стирильных условиях кому-то придется проверять выхлоп и допиливать при необходимости.
Поэтому как раз проще рассматривать нейронку - как инструмент в руках человека, а не как автономный заменитель человека.
Может это будет звучать очевидно, но для многих это не так, судя по комментариям: чтобы хорошо пройти собеседование не обязательно дать правильные ответы на каждый вопрос. Задача интервьюера - нащупать слабые места и глубину знаний кандидата, а не прогнать по формальному чек-листу и подсчитать сумму баллов. То есть результат определяет достижение необходимой глубины по всем важным областям, а не количество правильных ответов.
Если вас умудрились "завалить" только на вопросах-ультрахард, где нужны энциклопедические знания или специфический опыт, то вы - большой молодец и наверняка получите респект от интервьюера, хотя и не ответили. Если же кандидат знает везде, но лишь по верхам - то дальше рискует не пройти, не смотря на количество правильных ответов.
Если вы знаете устройство платформы, ее сильные и слабые стороны, это позволит делать более производительный, экономный по ресурсам код. Это позволит со знанием дела анализировать проблемы по памяти и пользоваться профайлером.
Не знать совсем глубоких нюансов или забыть детали - это нормально и едва ли это "снимет баллы". Но если кандидат позиционирует себя опытным специалистом, а при упоминании поколений объектов делает совсем круглые глаза и/или несет окровенный бред, то это, как минимум, повод насторожиться и прощупать базу. Может это единственный пробел, тогда это не проблема, но если там откроется бездна, то использование избитого вопроса окупится сполна.
Это профанация, которая конфликтует с законами, но подается под видом серьезной бумаги. Равно как документы на иностранных языках без перевода, запрет на трудоустройство к конкурентам после увольнения, какие-то конские прописанные штрафы и подобные финты, не предусмотренные ТК.
Если NDA противоречит законам юрисдикции, то оно
идет лесомюридически ничтожно.Федеральный закон от 29.07.2004 N 98-ФЗ (ред. от 08.08.2024) "О коммерческой тайне":
Тем не менее, заработная плата может быть персональными данные работника (программист Олег у нас в компании Y зарабатывает 300 к₽/с), поэтому про коллегу рассказывать нельзя. Но можно сказать, что программист у нас в компании Y зарабатывает 300 к₽/с.
В ХХ есть настройки видимости резюме с функционалом скрытия резюме для списка компаний.
Джойны в ORM - это либо те же много букв (деревья анонимных типов), либо черная магия (Automapper), либо оверфетчинг.
Если кого-то заинтересует, о каком кобанчике идет речь
ORM делает простым и без того простое, а сложное - еще сложнее.
Пока не запустите - не добудете запрос, можете лишь полагаться на опыт и здравый смысл, прогнозируя выхлоп, а EF умеет удивлять. Экспрешны дают некоторую статическую типизацию, но если углубиться в их генерацию - можно здорово наотстреливать ног в рантайме, да так, что ревьюер не догадается, а компилятор - не подстрахует.
С другой стороны, писать запросы руками - это не сложное занятие, с маппингом типов справится какой-нибудь Dapper. Даже если запрос билдится - это будет что-то тривиальное, сложностью управлять здесь очень просто, в отличие от абстракций экспрешнов с СУБД-специфичной трансляцией. Статической проверки типов в запросе нет, но явные имена полей и таблиц поддаются грепу.
Когда сырых запросов достаточно много, возникает вопрос: а стоит ли игра свеч? Стремились к простоте, а получили ласкутное одеяло технологий, альтернативных решений и срачи в ревью о границах допустимой сложности.
К тому же, EF Core лишь относительно недавно вообще научился запрашивать unmapped types, без чего в этом режиме было мало смысла.
А в чем тут языковая разница?
Но зачем? Запрос - это полноценная часть логики, в чем выигрыш вынесения в отдельный файл? Тут упомянали анализ инструментами, но ведь тот же GoLand умеет проверять SQL в литералах.
Это все, чтобы легитимизировать для себя использование
marginдля блоков? 😉То есть в п.4 вы решились нарушить п.2 и поплатились 😁
Разве схлопывание марджинов - это не та сложность переиспользования, с которой предназначены бороться обертки с паддингами?
Если не отменяет, то комментарий выше не потерял актуальность.
Ну почему же коней, вы выше сами предлагали отталкиваться от вакансии, а теперь почему-то - от кандидата.
Типичная работа, допустим, на 95% состоит из простой рутины, а, условно, оставшиеся 5% - из поиска неочевидных проблем/внедрения чего-то нового, что требует некоторой эрудиции и глубины знаний. Позиция звучит так, будто вопросы, актуальные для этх 5% не относятся к "реальной вакансии". Но ведь и эту часть работы тоже необходимо выполнять.
Адаптация подвела. Оригинальная книга опирается на Java 7-, до появления
Optional<T>, сейчас этот совет звучал бы иначе. А в C# совет тоже работал, но потерял актуальность с недавних пор - завезли свой эрзац-optional в виде признака нуллабельности референсных типов.Тем не менее, NRE - это однозначное зло, допускать их появление (полагаться на них, как на ассерт, к примеру)- плохая идея.
Плюсов много, да, но не соглашусь, что решение идеально.
Объединение нескольких (списков типов/discriminated unions) ошибок в единственный тип при пробросе ошибок наверх - это боль и туча бойлерплейта маппинга типов, а рефакторинг в таких условиях - дабл-боль. А если еще и вручную проверку результата нужно делать (отстствует аналог растового
?) - трипл-боль, код раздувается огромным количеством шума чуть ли не в разы (получи результат => проверь результат и подними ошибку => распакуй результат).Обработка исключений этих проблем лишина, т.к. появляется только там, где это имеет смысл, никаких обвязок для проталкивания ошибки наверх и "запаковки типов" не нужно => нет кода - нет и необходимости его поддерживать.
Скорее всего подразумевалось противопоставление: "НЕ используйте Nullable, а применяйте паттерн Null Object".
Так же в контексте C# хотелось бы оговорки про nullability.
Все чаще встречаю проекты, где тем или иным образом пытаются делать свои решения в стиле растового
Result<TResult, TErr>для обработки возможных/ожидаемых ошибок, а исключения - оставлять лишь фатальным, которые ловить сильно выше с целью только залоггировать. Как ни крути, но исключения - это дорогое удовольствие, подход Errors are values идет в массы.В Rust есть делегирование ошибок (оператор
?и трейтFrom<T>к нему), что позволяет держать happy path таким же чистым, как с исключениями.Индустрия методом проб и ошибок рождает решения, совершенствуется. Очень часто случается, что сценарий использования не совпадает с идеями, на которыми инструмент создавался. На каждом углу трубят, что для каждой задачи - свой инструмент, так как же понять границы применимости и сильные/слабые стороны, если все время не шатать их обсуждением опыта с коллегами? Каждый такой наброс - это приглашение к дискуссии, проверка гипотезы.
Но тут интересно другое:
почему хейт инструмента скорбляет вас лично? Или вы глубоко в душе сами боитесь найти несокрушимый аргумент, разочароваться и пожалеть о том, сколько сил и времени вложили?😉
Как насчет перевода SSH логина на ключи? Вроде и само собой разумеющееся действие, но инструкция претендует на подробность, а о такой важной штуке ни слова.
Функционал вряд ли будет висеть в воздухе - его надо будет интегрировать в существующую кодовую базу, что резко поднимает сложность задачи для нейронки.
Даже в стирильных условиях кому-то придется проверять выхлоп и допиливать при необходимости.
Поэтому как раз проще рассматривать нейронку - как инструмент в руках человека, а не как автономный заменитель человека.