Есть образование - хорошо. Нет образования - к тебе будет больше вопросов и недоверия, но ты можешь пройти если докажешь что способен выполнять работу.
По мне программирование это особое мышление, оно либо есть, либо нет. Никакой ВУЗ этого не сможет засунуть в голову, если она не способна или не хочет это принять. Мы все разные, у каждого свои + и -, не катит программирование, ок, найдёшь что то другое (дизайн, музыка, менеджмент и т.д.).
Это моё имхо за 10 лет практики. Всегда собес, всегда проверка.
Еще есть CSRF токен - https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work, которому CORS помогает.
Все также в УТС, там нет перевода. Перевод будет видно только в при конвертации в тот часовой пояс где этот перевод есть. И то конвертацию просто так не сделать, надо сходить в АПИ для запроса времени перевода и затем рассчитать локальное. Просто добавить оффсет как это делают в большинстве случаев недостаточно.
Самое простое - храни в УТС, все остальное можно рассчитать. Если можешь хранить DateTimeOffset (C#), то это удобнее.
Лучше всего передавать аналог DateTimeOffset как в C#, при помощи сторонних либ.
Многим вообще только УТС и хватает, их не интересует время клиента, нужен только точный момент времени. Учитывая что такого не может быть, где гарантия что на клиенте время верно указано, это если докапываться до миллисекунд. Проблема не новая, и раз все еще так работает значит большого кипеша нет.
1) Эту новость можно было написать в первые дни начала замедления, не дожидаясь атак.
2) ИБ не имеет отношения к происходящему. Связывание их с политикой это обида, перенаправление стрелок. Подобное происходит по всему миру, но замечаешь только свое.
По пункту № 2. Буква С в СОЛИД как раз и говорит о том что не надо связывать код разных "похожих" модулей. Потому что потом они начнут отличаться. Это же говорил и Мартин Фаулер в книге рефакторинг. Так что мысль старая и хорошая. Согласен что ООП и СОЛИД ни как не противоречит указанным пунктам в статье.
Одно другому не мешает. Теорию тоже надо спрашивать. Одно дело ее можно спрашивать в "сухую" вне бизнес кейсов, другое ее можно спрашивать по ходу решения этих самых кейсов. Live кодинг не проблема, можно и на доске писать и на бумаге, и в IDE, где угодно, все по желанию и возможности. Заучить можно и теорию и прохождение бизнес кейсов, т.к. думаю что больше 3-5 шт. сложно придумать, все шаблонные будут.
Я проходил разные собесы, меня называли джуном и сеньором в течении одной недели. Все зависит от опыта собеседующего и собеседуемого. Чем больше у этих людей пересечений в знаниях тем лучше пойдет собес, и наоборот.
Сейчас лично мне без разницы что у меня будут спрашивать и какие задачки давать. Если мы на собесе не сможем договориться, то в процессе работы вероятно тоже. Так что отказ в таком случае это лучше устройства и быстрого ухода. И наоборот есть вероятность того что собеседуют тебя люди с которыми ты вероятно в работе никогда на столкнешься на прямую, не окажешься в одной команде.
UPD Похоже что бизнес кейсы это аналог систем дезинга с допами в многоступенчатом собесе.
Раздражает реклама внутри почты. Я не использую поисковик Яндекс из-за рекламы которой слишком много. Не знаю как гугл умудряется действовать менее навязчиво.
Это очередной раз доказывает что нет идеального процесса найма в ИТ. Крутые компании могут себе позволить творить что угодно, скушают, желающих очень много. Пока соискатели поймут что к чему в количестве достаточном для бунта, компания уже придумает новый подход который "устраняет" недостатки предыдещего.
Телеграм сделал конкурс, и выбрал победителей. Нормальный подход, всем не подойдет, но на фоне всех работает.
Интересно было бы посмотреть как люди проводящие собеседования сами их проходят :) Взять 100 таких человек и каждый у каждого пройдет собес, отличался бы результат от "обычного" рынка соискателей или нет? :) Имхо, думаю результат будет не сильно лучше, но лучше.
Они реально сделали доступность без регистрации, но только для некоторых стран.
Инструкция. 1) Включаем VPN на любую страну. 2) Переходим по адресу https://chat.openai.com 3) Если вы видите ошибку доступа или требование пройти регистрацию/авторизацию, меняйте страну в VPN и переходите к пункту № 2.
IOS хорош, Android хорош. Бери что нравится. Сейчас вот только пользователям IOS приходится карточки с собой таскать, в то время как на Android вопрос решен. Остальное вкусовщина, которую бесполезно объяснять и пытаться что то доказать, зря время тратить.
По ТВ и в сети рекламу бы пускали с подобным материалом.
Спасибо.
На меня пару раз выходили люди, называли мои данные. Я на один звонок ответил, а на втором одумался, скинул, и начал проверять номера. Оставил заязку в тех. поддержку банка с указанием телефонов с которых мне звонили. И это я, который смотрел много методик взлома, а все равно через N-лет чуть не повелся.
После такого в голове все картинка, что кого то да проведут, заберут последнее, и не скажут спасибо. Монстры.
Когда задается вопрос, некоторые его детали могут быть упущены, умышленно или нет. Так сказать отвечай как знаешь, или задавай уточняющие вопросы, если в этом возникла необходимость. Это так же может быть одним из этапов проверки, как поведет себя человек, просто ответит или уточнит перед тем как ответчать.
Автор ожидает услышать разницу в использовании. Вот этого слова не хватает в вопросе — «использовании», тогда и ответ хорошо подходит. А так, можно ответить по разному, и эти ответы могут считаться как правильные, в зависимости от ожиданий задающего вопрос человека.
Как гласит поговорка: правильно поставленный вопрос — это уже половина ответа.
The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server.
Также POST используется для вызова Controller (REST, 4-й Resource Archetype).
Есть образование - хорошо. Нет образования - к тебе будет больше вопросов и недоверия, но ты можешь пройти если докажешь что способен выполнять работу.
По мне программирование это особое мышление, оно либо есть, либо нет. Никакой ВУЗ этого не сможет засунуть в голову, если она не способна или не хочет это принять. Мы все разные, у каждого свои + и -, не катит программирование, ок, найдёшь что то другое (дизайн, музыка, менеджмент и т.д.).
Это моё имхо за 10 лет практики.
Всегда собес, всегда проверка.
Если бы юзали ЦПУ то да, но они юзают НПУ, поэтому нет.
Еще есть CSRF токен - https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work, которому CORS помогает.
Складывать все файлы в рут фолдер тоже не стоит :)
Все также в УТС, там нет перевода. Перевод будет видно только в при конвертации в тот часовой пояс где этот перевод есть. И то конвертацию просто так не сделать, надо сходить в АПИ для запроса времени перевода и затем рассчитать локальное. Просто добавить оффсет как это делают в большинстве случаев недостаточно.
Самое простое - храни в УТС, все остальное можно рассчитать. Если можешь хранить DateTimeOffset (C#), то это удобнее.
Можем, для этого есть таймзона которую можно передать отдельно.
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)Лучше всего передавать аналог DateTimeOffset как в C#, при помощи сторонних либ.
Многим вообще только УТС и хватает, их не интересует время клиента, нужен только точный момент времени. Учитывая что такого не может быть, где гарантия что на клиенте время верно указано, это если докапываться до миллисекунд. Проблема не новая, и раз все еще так работает значит большого кипеша нет.
Новое апи круто, посмотрим.
1) Эту новость можно было написать в первые дни начала замедления, не дожидаясь атак.
2) ИБ не имеет отношения к происходящему. Связывание их с политикой это обида, перенаправление стрелок. Подобное происходит по всему миру, но замечаешь только свое.
Всем бобра.
По пункту № 2. Буква С в СОЛИД как раз и говорит о том что не надо связывать код разных "похожих" модулей. Потому что потом они начнут отличаться. Это же говорил и Мартин Фаулер в книге рефакторинг. Так что мысль старая и хорошая. Согласен что ООП и СОЛИД ни как не противоречит указанным пунктам в статье.
Одно другому не мешает.
Теорию тоже надо спрашивать.
Одно дело ее можно спрашивать в "сухую" вне бизнес кейсов, другое ее можно спрашивать по ходу решения этих самых кейсов.
Live кодинг не проблема, можно и на доске писать и на бумаге, и в IDE, где угодно, все по желанию и возможности.
Заучить можно и теорию и прохождение бизнес кейсов, т.к. думаю что больше 3-5 шт. сложно придумать, все шаблонные будут.
Я проходил разные собесы, меня называли джуном и сеньором в течении одной недели. Все зависит от опыта собеседующего и собеседуемого. Чем больше у этих людей пересечений в знаниях тем лучше пойдет собес, и наоборот.
Сейчас лично мне без разницы что у меня будут спрашивать и какие задачки давать. Если мы на собесе не сможем договориться, то в процессе работы вероятно тоже. Так что отказ в таком случае это лучше устройства и быстрого ухода. И наоборот есть вероятность того что собеседуют тебя люди с которыми ты вероятно в работе никогда на столкнешься на прямую, не окажешься в одной команде.
UPD
Похоже что бизнес кейсы это аналог систем дезинга с допами в многоступенчатом собесе.
Раздражает реклама внутри почты. Я не использую поисковик Яндекс из-за рекламы которой слишком много. Не знаю как гугл умудряется действовать менее навязчиво.
Это очередной раз доказывает что нет идеального процесса найма в ИТ. Крутые компании могут себе позволить творить что угодно, скушают, желающих очень много. Пока соискатели поймут что к чему в количестве достаточном для бунта, компания уже придумает новый подход который "устраняет" недостатки предыдещего.
Телеграм сделал конкурс, и выбрал победителей. Нормальный подход, всем не подойдет, но на фоне всех работает.
Интересно было бы посмотреть как люди проводящие собеседования сами их проходят :) Взять 100 таких человек и каждый у каждого пройдет собес, отличался бы результат от "обычного" рынка соискателей или нет? :) Имхо, думаю результат будет не сильно лучше, но лучше.
Они реально сделали доступность без регистрации, но только для некоторых стран.
Инструкция.
1) Включаем VPN на любую страну.
2) Переходим по адресу https://chat.openai.com
3) Если вы видите ошибку доступа или требование пройти регистрацию/авторизацию, меняйте страну в VPN и переходите к пункту № 2.
Для USA работает.
del
IOS хорош, Android хорош.
Бери что нравится.
Сейчас вот только пользователям IOS приходится карточки с собой таскать, в то время как на Android вопрос решен. Остальное вкусовщина, которую бесполезно объяснять и пытаться что то доказать, зря время тратить.
Но есть альтеративное мнение, которое возможно заинтересует читающих про ИИ людей.
Искусственный Интеллект или профанация. Профессор Савельев
Рассеиватель иллюзий.
Спасибо.
На меня пару раз выходили люди, называли мои данные. Я на один звонок ответил, а на втором одумался, скинул, и начал проверять номера. Оставил заязку в тех. поддержку банка с указанием телефонов с которых мне звонили. И это я, который смотрел много методик взлома, а все равно через N-лет чуть не повелся.
После такого в голове все картинка, что кого то да проведут, заберут последнее, и не скажут спасибо. Монстры.
Когда вас собеседуют — что за вопросы они задают.
Круговорот неоправданных ожиданий.
Когда задается вопрос, некоторые его детали могут быть упущены, умышленно или нет. Так сказать отвечай как знаешь, или задавай уточняющие вопросы, если в этом возникла необходимость. Это так же может быть одним из этапов проверки, как поведет себя человек, просто ответит или уточнит перед тем как ответчать.
Автор ожидает услышать разницу в использовании. Вот этого слова не хватает в вопросе — «использовании», тогда и ответ хорошо подходит. А так, можно ответить по разному, и эти ответы могут считаться как правильные, в зависимости от ожиданий задающего вопрос человека.
О разности POST и PUT в RFC:
tools.ietf.org/html/rfc7231#section-4.3.4
Также POST используется для вызова Controller (REST, 4-й Resource Archetype).