Превосходство Linux можно демонстрировать по-разному. Например, недавно 16-летний хакер NSG650 представил специальный Windows-драйвер BugCheck2Linux, который запускает Linux на компьютере сразу после того, как Windows зависла с синим экраном смерти (BSOD), причём перезагрузка не требуется.
Забавная штука, но в чём именно здесь состоит демонстрация превосходства?
Да, сравнил, но это не моя вина, что кассир получает столько же, сколько учитель. Или вы хотели сказать, что выпускник трёхмесячных курсов разработки является высококвалифицированным специалистом?
Только ленивый не писал, про большие зарплаты в IT. Опять же, если они такие большие, то зачем вообще нужна IT ипотека?
В IT действительно большие зарплаты. Настолько большие, что с ними можно взять ипотеку. Какому-нибудь кассиру из магазина или учителю ипотеку просто-напросто не дадут.
Если человек просит научить его программированию, это уже повод отказать ему, т.к. это означает, что он недостаточно мотивирован, чтобы научиться самому.
Практика показывает, что если человек работает очень медленно и скрупулёзно, то это далеко не всегда приводит к хорошим результатам. И этому есть вполне логичное объяснение: код, который принято называть "чистым" (или более чистым) всегда выглядит более кратким и читаемым, соответственно, работать с таким кодом будет быстрее, а писать его меньше. Но для того, чтобы сразу писать чистый код, нужен опыт, чтобы видя задачу, быстро сообразить, как её решать, и ещё перед написанием первой строчки кода сразу представлять, что именно собираешься писать. Естественно, что это приходит с опытом, не за год и не за два. Но к этому нужно стремиться. Хороший программист - это тот, кто решает задачи быстро и качественно. Если получается недостаточно быстро или недостаточно качественно, значит, программист недостаточно хорош.
Плюс никто не мешает руку подкинуть еще пару задач.
С учётом вышесказанного, надо применять такой способ: есть задача, оценённая, скажем в 4 часа. Делаешь её за час или за два, и логируешь три часа времени, и вот у тебя есть час-два, чтобы поесть/поспать/погулять, а начальство довольно, что ты справился на час быстрее. В следующий раз, когда эстимэйт такой задачи попробуют урезать, нужно возразить, что надо добавить час на возможные непредвиденные обстоятельства, ведь на самом деле что-то непредвиденное может произойти. Плюс объективно далеко не каждую задачу получается сделать в разы быстрее, но если в неделю попадается 2-3 таких задачи, это уже приятно.
Другое дело, если стоят жёсткие тайм-трекеры, которые отслеживают всё, что делаешь за компом. В таком случае лучше просто работать неспеша, всё по 10 раз перепроверять, писать развёрнутые комментарии и т.д. Опять же это поможет с профилактикой выгорания, т.к. работаешь неспеша.
Если же опыта мало, и не укладываешься в эстимэйты, это всё равно не повод овертаймить, потому что в таком случае ты из неопытного работника превратишься в уставшего неопытного работника и ситуация станет ещё хуже, а далее срыв дедлайнов, нервный срыв, увольнение. Лучше закончить работу во время, передохнуть, собраться с мыслями, постараться понять, почему не успеваешь, погуглить какие-то материалы по работе, просто почитать статьи или мануалы, чтобы завтра продолжить работу со свежей головой и новыми мыслями.
Хм, интересно, спрсил у ChatGPT, сколько должны платить в Восточной Европе разработчику с моей квалификацией и опытом. Он выдал пределы от и до, и моя зарплата оказалась ровно посередине.
40 часов - это то, с чего надо начинать. Если работать больше, выгорание наступит в любом случае, если меньше, то там уже всё индивидуально. Например, я всегда заканчиваю рабочий день в 18:00, независимо от того, во сколько начал. Называю это полугибким графиком
Самый простой способ оценить, эффективно ли ты работаешь - если не успеваешь сделать всё за 40 часов в неделю, значит работаешь неэффективно. Всё остальное - обман с целью заставить работать больше за те же деньги.
Не помню, сколько раз я повторял, но я спрашиваю "расскажи про контейнер зависимостей в Symfony", а не как вызвать метод, и какие параметры туда передать. Если для вас контейнер зависимостей это только "как вызвать метод и какие параметры туда передавать и как настройки в конфиге править", то это говорит лишь о том, что вы крайне слабо владеете данным вопросом.
Существуют такие люди, которые умеют писать код без нейросетей. Немного, но они есть. И чем больше кода будут генерировать нейросети, тем выше будет спрос на услуги тех, кто умеет писать код сам.
Думаю, через год-два главным навыком любого программиста станет способность исправить г-код, написанный нейросетью. И думаю, что спрос на такие услуги может оказаться просто взрывной. Но перед этим нужно переждать волну ИИ-оптимизма, пик которой ещё не наступил.
Если вы по такому вопросу можете только пересказать документацию, то я бы мог вам смело предложить позицию джуна. Кандидат на более высокие позиции сможет дополнить свой рассказ пояснениями, зачем это всё вообще нужно и где это используется.
В точности аналогичная ситуация произошла и с автором статьи - он прочитал и выучил документацию по yield, но пока ещё не понял, зачем.
Попросить запроектировать что-то - это тоже вполне универсальный способ оценки знаний. Если конечно речь идёт именно о рассказе в стиле "как бы я проектировал вот это", а не о том, что нужно выдать готовый и работоспособный код проекта))) Если бы я собеседовал кого-то, скажем, по реакту, я бы тоже попросил что-то спроектировать, потому что я пока ещё не придумал такой вопрос по реакту, чтобы по ответу на него был виден столь объёмный срез, как по вопросу о контейнере зависимостей.
Вопрос был "расскажи о DI-контейнере в Symfony". Где вы в этом вопросе увидели что-то об отличиях контейнера Symfony от других реализаций?
Тегирование есть в контейнере Ларавеля
И что с того? Значит ли это что тэгирования нет в Symfony. Представьте, дали вам на работе что-то сделать в проекте на Symfony. И надо там объявить сервис с тегом. И что вы будете делать, ведь тэгирование есть в Laravel, а у вас проект на Symfony? Станете из-за этого решать задачу обходным путём? Звучит глупо? Но ведь вы сами дали такой ответ на уточняющий вопрос.
Если в рассказе о DI-контейнере Symfony человек не упоминает тэги, то тут два варианта, либо он просто забыл о них сказать, (что в принципе нормально, потому что рассказать можно ещё много чего другого), либо он просто не знает что это.
мне как кандидату вообще неочевидно, что вы ожидаете услышать
В конкретно данном случае я ожидаю услышать всё, что кандидату известно об указанной теме. В любой форме. Я прекрасно себе отдаю отчёт, что это будет крайне сумбурный, скомканный и неструктурированный рассказ, но именно это я ожидаю услышать. К слову, уточняющие вопросы я тоже ожидаю услышать.
Кажется, мы стали забывать, что слово "собеседование" означает беседу, а не экзамен. Собеседование в виде теста не может являться собеседованием по определению.
Вот по вашему ответу я уже склоняюсь к тому, чтобы сказать вам "Спасибо, вы нам не подходите". Задавая такой вопрос, я ожидаю услышать о том, как объявить сервис, как его использовать, как передать в него аргументы, что такое автовайринг, какие опции можно задать в yaml-файле конфигурации, как декорировать сервисы, что такое ленивые сервисы, зачем сервисам теги. И если человек может по каким-то пунктам привести примеры из своего опыта, где он это использовал или хотя бы где он видел, как это используется, то это выйдет рассказ минут на 40. И сразу будет понятно, какой у человека опыт, с какими проектами он работал, и какова была лично его роль в реализации этих проектов.
Принципиально ничем, но это вовсе не теоретический вопрос, т.к. постановка вопроса не "что такое DI контейнер?", а "расскажи о DI-контейнере в Symfony". Если человек собирается тянуть в проект на Symfony какую-то свою реализацию контейнера, то такому лучше с ходу отказать. Ну и в процессе рассказа будет понятно, насколько большой или небольшой у человека опыт. И ответ на такой вопрос невозможно заучить. Более того сам вопрос не подразумевает наличие единственно правильного ответа.
Собеседовался обычно в небольшие аутсорсинговые компании численностью 15-100 человек. Тестовое задание видел в последний раз в 2016 году.
обычно спрашивают что-то о чем знают сами в силу опыта или о чем читали недавно
Это вообще какой-то странный кейс из разряда, что джуна попросили провести собес. У опытного разработчика обычно есть в арсенале пару вопросов, по которым полностью понятно, что из себя представляет человек. Например "расскажи про контейнер зависимостей в Symfony" - и тут сразу понятно будет с чем человек работал, какой у него уровень, насколько хорошо он понимает ООП, паттерны и всё остальное
Забавная штука, но в чём именно здесь состоит демонстрация превосходства?
Специально посмотрел сейчас. Вакансии водителей-международников до 2500€. Это зарплата пхп-шного мидла.
Причём тут какая-то вина? Я всего лишь констатирую факт, что в IT платят больше, чем в большинстве других сфер.
Да, сравнил, но это не моя вина, что кассир получает столько же, сколько учитель. Или вы хотели сказать, что выпускник трёхмесячных курсов разработки является высококвалифицированным специалистом?
В IT действительно большие зарплаты. Настолько большие, что с ними можно взять ипотеку. Какому-нибудь кассиру из магазина или учителю ипотеку просто-напросто не дадут.
Интересно, каких?
Если человек просит научить его программированию, это уже повод отказать ему, т.к. это означает, что он недостаточно мотивирован, чтобы научиться самому.
Практика показывает, что если человек работает очень медленно и скрупулёзно, то это далеко не всегда приводит к хорошим результатам. И этому есть вполне логичное объяснение: код, который принято называть "чистым" (или более чистым) всегда выглядит более кратким и читаемым, соответственно, работать с таким кодом будет быстрее, а писать его меньше. Но для того, чтобы сразу писать чистый код, нужен опыт, чтобы видя задачу, быстро сообразить, как её решать, и ещё перед написанием первой строчки кода сразу представлять, что именно собираешься писать. Естественно, что это приходит с опытом, не за год и не за два. Но к этому нужно стремиться. Хороший программист - это тот, кто решает задачи быстро и качественно. Если получается недостаточно быстро или недостаточно качественно, значит, программист недостаточно хорош.
С учётом вышесказанного, надо применять такой способ: есть задача, оценённая, скажем в 4 часа. Делаешь её за час или за два, и логируешь три часа времени, и вот у тебя есть час-два, чтобы поесть/поспать/погулять, а начальство довольно, что ты справился на час быстрее. В следующий раз, когда эстимэйт такой задачи попробуют урезать, нужно возразить, что надо добавить час на возможные непредвиденные обстоятельства, ведь на самом деле что-то непредвиденное может произойти. Плюс объективно далеко не каждую задачу получается сделать в разы быстрее, но если в неделю попадается 2-3 таких задачи, это уже приятно.
Другое дело, если стоят жёсткие тайм-трекеры, которые отслеживают всё, что делаешь за компом. В таком случае лучше просто работать неспеша, всё по 10 раз перепроверять, писать развёрнутые комментарии и т.д. Опять же это поможет с профилактикой выгорания, т.к. работаешь неспеша.
Если же опыта мало, и не укладываешься в эстимэйты, это всё равно не повод овертаймить, потому что в таком случае ты из неопытного работника превратишься в уставшего неопытного работника и ситуация станет ещё хуже, а далее срыв дедлайнов, нервный срыв, увольнение. Лучше закончить работу во время, передохнуть, собраться с мыслями, постараться понять, почему не успеваешь, погуглить какие-то материалы по работе, просто почитать статьи или мануалы, чтобы завтра продолжить работу со свежей головой и новыми мыслями.
Хм, интересно, спрсил у ChatGPT, сколько должны платить в Восточной Европе разработчику с моей квалификацией и опытом. Он выдал пределы от и до, и моя зарплата оказалась ровно посередине.
40 часов - это то, с чего надо начинать. Если работать больше, выгорание наступит в любом случае, если меньше, то там уже всё индивидуально. Например, я всегда заканчиваю рабочий день в 18:00, независимо от того, во сколько начал. Называю это полугибким графиком
Самый простой способ оценить, эффективно ли ты работаешь - если не успеваешь сделать всё за 40 часов в неделю, значит работаешь неэффективно. Всё остальное - обман с целью заставить работать больше за те же деньги.
Не помню, сколько раз я повторял, но я спрашиваю "расскажи про контейнер зависимостей в Symfony", а не как вызвать метод, и какие параметры туда передать. Если для вас контейнер зависимостей это только "как вызвать метод и какие параметры туда передавать и как настройки в конфиге править", то это говорит лишь о том, что вы крайне слабо владеете данным вопросом.
Существуют такие люди, которые умеют писать код без нейросетей. Немного, но они есть. И чем больше кода будут генерировать нейросети, тем выше будет спрос на услуги тех, кто умеет писать код сам.
Думаю, через год-два главным навыком любого программиста станет способность исправить г-код, написанный нейросетью. И думаю, что спрос на такие услуги может оказаться просто взрывной. Но перед этим нужно переждать волну ИИ-оптимизма, пик которой ещё не наступил.
Если вы по такому вопросу можете только пересказать документацию, то я бы мог вам смело предложить позицию джуна. Кандидат на более высокие позиции сможет дополнить свой рассказ пояснениями, зачем это всё вообще нужно и где это используется.
В точности аналогичная ситуация произошла и с автором статьи - он прочитал и выучил документацию по yield, но пока ещё не понял, зачем.
Попросить запроектировать что-то - это тоже вполне универсальный способ оценки знаний. Если конечно речь идёт именно о рассказе в стиле "как бы я проектировал вот это", а не о том, что нужно выдать готовый и работоспособный код проекта))) Если бы я собеседовал кого-то, скажем, по реакту, я бы тоже попросил что-то спроектировать, потому что я пока ещё не придумал такой вопрос по реакту, чтобы по ответу на него был виден столь объёмный срез, как по вопросу о контейнере зависимостей.
Вопрос был "расскажи о DI-контейнере в Symfony". Где вы в этом вопросе увидели что-то об отличиях контейнера Symfony от других реализаций?
И что с того? Значит ли это что тэгирования нет в Symfony. Представьте, дали вам на работе что-то сделать в проекте на Symfony. И надо там объявить сервис с тегом. И что вы будете делать, ведь тэгирование есть в Laravel, а у вас проект на Symfony? Станете из-за этого решать задачу обходным путём? Звучит глупо? Но ведь вы сами дали такой ответ на уточняющий вопрос.
Если в рассказе о DI-контейнере Symfony человек не упоминает тэги, то тут два варианта, либо он просто забыл о них сказать, (что в принципе нормально, потому что рассказать можно ещё много чего другого), либо он просто не знает что это.
В конкретно данном случае я ожидаю услышать всё, что кандидату известно об указанной теме. В любой форме. Я прекрасно себе отдаю отчёт, что это будет крайне сумбурный, скомканный и неструктурированный рассказ, но именно это я ожидаю услышать. К слову, уточняющие вопросы я тоже ожидаю услышать.
Кажется, мы стали забывать, что слово "собеседование" означает беседу, а не экзамен. Собеседование в виде теста не может являться собеседованием по определению.
Вот по вашему ответу я уже склоняюсь к тому, чтобы сказать вам "Спасибо, вы нам не подходите". Задавая такой вопрос, я ожидаю услышать о том, как объявить сервис, как его использовать, как передать в него аргументы, что такое автовайринг, какие опции можно задать в yaml-файле конфигурации, как декорировать сервисы, что такое ленивые сервисы, зачем сервисам теги. И если человек может по каким-то пунктам привести примеры из своего опыта, где он это использовал или хотя бы где он видел, как это используется, то это выйдет рассказ минут на 40. И сразу будет понятно, какой у человека опыт, с какими проектами он работал, и какова была лично его роль в реализации этих проектов.
Принципиально ничем, но это вовсе не теоретический вопрос, т.к. постановка вопроса не "что такое DI контейнер?", а "расскажи о DI-контейнере в Symfony". Если человек собирается тянуть в проект на Symfony какую-то свою реализацию контейнера, то такому лучше с ходу отказать. Ну и в процессе рассказа будет понятно, насколько большой или небольшой у человека опыт. И ответ на такой вопрос невозможно заучить. Более того сам вопрос не подразумевает наличие единственно правильного ответа.
Собеседовался обычно в небольшие аутсорсинговые компании численностью 15-100 человек. Тестовое задание видел в последний раз в 2016 году.
Это вообще какой-то странный кейс из разряда, что джуна попросили провести собес. У опытного разработчика обычно есть в арсенале пару вопросов, по которым полностью понятно, что из себя представляет человек. Например "расскажи про контейнер зависимостей в Symfony" - и тут сразу понятно будет с чем человек работал, какой у него уровень, насколько хорошо он понимает ООП, паттерны и всё остальное