Если речь не идёт о госконторе то коммерческая фирма зарабатывает деньги. Если из-за косяка сервер упадёт или клиент разорвёт контракт фирма закроется и программисту придётся искать работу. И наоборот, если его наблюдательность или сознательность улучшит работу сервиса ему будут благодарны, фирма улучшит материальное положение и возможно выпишут бонус.
Знакомому в похожем случае оплатили поездку в США, он был доволен.
Всякая идентификация по номеру телефона это дыра в безопасности человека. Сольют логи с сервера по запросу роскомпозора и нарисуют двушечку. Скайп в этом смысле безопаснее. Ник к делу не пришьёшь.
А при чём тут разработчики ejabberd? Нарушены права широкого неограниченного круга пользователей. Они представлены Free Software Foundation с момента опубликования кода под лицензией GNU GPL v2. Почему не засудят Whatsapp? Не хотят, или времени нет. Опять таки слова на иск не намажешь, нужны доказательства. Я сомневаюсь что суд выдаст иск на арест серверов Facebook на основании слов балабола.
От вас скорее всего потребовали не ошибку найти конкретную, а порассуждать что там может быть не так. И подсказку дали - асинхронный код. А дальше вслух проговариваете - вот эта строчка кода потокобезопасная, а вот тут читается переменная класса, дальше делаются вычисления на основе её значения и запускается функция. Переменная незащищённая, другой поток вполне может её поменять и функция вызовется неправильно.
Если программист владеет базой то шансы написать глючный код уменшаются экспотенциально. Особенно если он досконально разбирается в механизмах многопоточности. Конечно, современные библиотеки берут на себя почти все низкоуровневые детали типа мьютексов и критических секций, но замечать дурно пахнущий код интервьюируемый обязан. Тем более миддл или сеньор.
В чём-то соглашусь. Два раза собеседовался в Jetbrains на релевантную опыту позицию, оба раза не прошёл дальше HR. С какими-то совершенно левыми отписками, типа я не вижу у вас необходимой мотивации или команде не понравилось ваше резюме. Если сотрудник нужен думаю вопрос нравится-не нравится не стоял бы. Взяли бы с потрохами.
Может в данном случае техлид и старается для успеха проекта. Потому что предыдущие уволенные программисты накосячили и пришлось переделывать, что задержало проект. Лучше день потерять и потом за 5 минут долететь (с)
Вот у нас был пример когда мы несколько раз в месяц напарывались на ошибку записи на диск в ядре линукса. Понятно что всего предусмотреть невозможно и у нас высоконагруженное приложение со скоростями порядка терабит в секунду. Но кто-то из авторов ядра накосячил и нам пришлось делать принудительный сброс очереди на диск, что существенно ухудшило производительность. Если бы сразу сделали нормально, не пришлось бы приставлять костыли.
Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.
Я к тому что нормальный программист, даже не разбираясь в технологии используемой в соседнем отделе, может бегло просмотреть код и указать на очевидные ошибки. Чем принесёт пользу общему делу. А миддл клепающий формочки придёт в 9 уйдёт в 5 и ничего его не волнует.
Это да. Техлид отвечает за код. Если у него был негативный опыт исправления банальных ошибок не владеющих базой программистов - не нужно тимлиду лезть туда чего он сам не понимает. Даже если кандидат кажется нормальным, но не в состоянии решить типичную задачу в рамках техзаданий - дешевле поискать другого чем потом огрести проблем.
Ну и да, нужно заранее оговорить с техлидом критерии, желательно с конкретными багами из трекера и примерами кода - чтобы и тим-лид понимал что нужно от кандидата.
В том пункте что вы процитировали говорится прямо. Если это внутренний инструмент типа линтера или хитрого парсера логов - публиковать не надо. Если код используется в публично доступном проде - извольте опубликовать.
HR, вопросы к вам, как моя ценность, как сотрудника, вырастет, если я получу "вышку"?
Это скорее софт-скилы. Если человек смог закончить ВУЗ он как минимум упорный и умеет решать поставленные задачи. Опять таки стрессоустойчивый (сессия) и способен грамотно излагать свои мысли. Это всё может присутствовать и у вас, но придётся проводить дополнительное тестирование. Опять таки в нынешней ситуации программиста без вышки могут забрать на СВО, а с вышкой попадёт под бронь.
1 - "1" неинтересен сам по себе как результат. Важно чтобы человек понимал что такое строка, что такое число, что такое приведение типов и так далее. Если мне ответят неправильно, но развёрнуто - такой человек получит больше плюсиков чем тот кто зазубрил ответ и не понимает как его получить.
когда из 100500 необходимых для должности технологий, ты не знаешь буквально одну
Я перед собесом читаю описание вакансии и если вижу что не знаю буквально одну, а вакансия вкусная - мне ничто не мешает загуглить, поставить софт в виртуалку, поиграться часа три и посмотреть типичные вопросы. Не вижу тут особой проблемы.
По поводу базы и алгоритмов - не спрашивать базу у специалистов уровня мидл и выше - глупость.
Кто даст гарантию что мидл это тот за кого он себя выдаёт? Может он 10 лет сидел формочки ваял, никак не развиваясь. Формально опыт есть, фактически ничего не знает и не хочет знать. Возьмёте его, а потом придётся увольнять через пару недель и всё по-новому.
База это гарантия того что человек как минимум знает основы. Остальному можно научить.
почему я должен искать ошибку по коду который при мне даже не удосужились запустить?
Потому что асинхронщина вещь такая - сто раз запустишь работает, на стопервом упадёт. Если человек не понимает что переменная может внезапно измениться между двумя строчками кода он напишет труднообнаруживаемый баг. Который потом придётся отлавливать саппорту у клиента, разбирая многотонные дампы.
База необходима даже ЛОРу. Допустим он видит запредельное количество лейкоцитов в анализе крови. Он не спец по раку, но может послать человека к другому специалисту. Это как в программировании. Фронтэндщик может проигнорировать неправильный ответ от сервера, типа моё дело маленькое, не работает да и хрен с ним. А может подойти к бекендщику и грамотно рассказать о проблеме. Вся команда только выиграет от этого.
Не везде и не всегда. Есть правила наработанные практикой которая отличается от теории. Потому что последняя не учитывает пограничные случаи. Та же сортировка. Один алгоритм работает быстрее в случае почти отсортированных данных, другой незаменим если мало памяти и тд и тп. Новичок может не знать какие именно данные поступают из очереди и тогда ему проще заучить то что говорят более опытные коллеги.
Опять таки вопрос времени. Книжка Кнута размером в три тома замечательная и после неё ты точно будешь разбираться в теории и сможешь ответить на любой вопрос. Но есть ли у тебя время на Кнута? И сотни других книжек.
Я думаю что в чём-то конкретном программист должен разбираться досконально. В остальном можно зазубрить. Например, если он фронтендщик, ему не надо разбираться в node.js, достаточно запомнить пару команд как быстро поднять сервер локально, дальше пусть devops парится.
Если речь не идёт о госконторе то коммерческая фирма зарабатывает деньги. Если из-за косяка сервер упадёт или клиент разорвёт контракт фирма закроется и программисту придётся искать работу. И наоборот, если его наблюдательность или сознательность улучшит работу сервиса ему будут благодарны, фирма улучшит материальное положение и возможно выпишут бонус.
Знакомому в похожем случае оплатили поездку в США, он был доволен.
Всякая идентификация по номеру телефона это дыра в безопасности человека. Сольют логи с сервера по запросу роскомпозора и нарисуют двушечку. Скайп в этом смысле безопаснее. Ник к делу не пришьёшь.
А при чём тут разработчики ejabberd? Нарушены права широкого неограниченного круга пользователей. Они представлены Free Software Foundation с момента опубликования кода под лицензией GNU GPL v2. Почему не засудят Whatsapp? Не хотят, или времени нет. Опять таки слова на иск не намажешь, нужны доказательства. Я сомневаюсь что суд выдаст иск на арест серверов Facebook на основании слов балабола.
От вас скорее всего потребовали не ошибку найти конкретную, а порассуждать что там может быть не так. И подсказку дали - асинхронный код. А дальше вслух проговариваете - вот эта строчка кода потокобезопасная, а вот тут читается переменная класса, дальше делаются вычисления на основе её значения и запускается функция. Переменная незащищённая, другой поток вполне может её поменять и функция вызовется неправильно.
Дзен левел это когда ты постиг "работает не трожь, а если трожь, то напиши сначала юнит тесты с полным покрытием".
Если программист владеет базой то шансы написать глючный код уменшаются экспотенциально. Особенно если он досконально разбирается в механизмах многопоточности. Конечно, современные библиотеки берут на себя почти все низкоуровневые детали типа мьютексов и критических секций, но замечать дурно пахнущий код интервьюируемый обязан. Тем более миддл или сеньор.
В чём-то соглашусь. Два раза собеседовался в Jetbrains на релевантную опыту позицию, оба раза не прошёл дальше HR. С какими-то совершенно левыми отписками, типа я не вижу у вас необходимой мотивации или команде не понравилось ваше резюме. Если сотрудник нужен думаю вопрос нравится-не нравится не стоял бы. Взяли бы с потрохами.
Один из наших самых гуманных судов дал двушечку за протест против воблы. Будет надо - запретят и хлеб.
Может в данном случае техлид и старается для успеха проекта. Потому что предыдущие уволенные программисты накосячили и пришлось переделывать, что задержало проект. Лучше день потерять и потом за 5 минут долететь (с)
Вот у нас был пример когда мы несколько раз в месяц напарывались на ошибку записи на диск в ядре линукса. Понятно что всего предусмотреть невозможно и у нас высоконагруженное приложение со скоростями порядка терабит в секунду. Но кто-то из авторов ядра накосячил и нам пришлось делать принудительный сброс очереди на диск, что существенно ухудшило производительность. Если бы сразу сделали нормально, не пришлось бы приставлять костыли.
Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.
Я к тому что нормальный программист, даже не разбираясь в технологии используемой в соседнем отделе, может бегло просмотреть код и указать на очевидные ошибки. Чем принесёт пользу общему делу. А миддл клепающий формочки придёт в 9 уйдёт в 5 и ничего его не волнует.
Это да. Техлид отвечает за код. Если у него был негативный опыт исправления банальных ошибок не владеющих базой программистов - не нужно тимлиду лезть туда чего он сам не понимает. Даже если кандидат кажется нормальным, но не в состоянии решить типичную задачу в рамках техзаданий - дешевле поискать другого чем потом огрести проблем.
Ну и да, нужно заранее оговорить с техлидом критерии, желательно с конкретными багами из трекера и примерами кода - чтобы и тим-лид понимал что нужно от кандидата.
Скайп был мегапопулярным. Пока его не купила Microsoft. Но у самой Microsoft было как минимум два схожих приложения. И на скайп положили болт.
В том пункте что вы процитировали говорится прямо. Если это внутренний инструмент типа линтера или хитрого парсера логов - публиковать не надо. Если код используется в публично доступном проде - извольте опубликовать.
Это скорее софт-скилы. Если человек смог закончить ВУЗ он как минимум упорный и умеет решать поставленные задачи. Опять таки стрессоустойчивый (сессия) и способен грамотно излагать свои мысли. Это всё может присутствовать и у вас, но придётся проводить дополнительное тестирование. Опять таки в нынешней ситуации программиста без вышки могут забрать на СВО, а с вышкой попадёт под бронь.
1 - "1" неинтересен сам по себе как результат. Важно чтобы человек понимал что такое строка, что такое число, что такое приведение типов и так далее. Если мне ответят неправильно, но развёрнуто - такой человек получит больше плюсиков чем тот кто зазубрил ответ и не понимает как его получить.
Я перед собесом читаю описание вакансии и если вижу что не знаю буквально одну, а вакансия вкусная - мне ничто не мешает загуглить, поставить софт в виртуалку, поиграться часа три и посмотреть типичные вопросы. Не вижу тут особой проблемы.
Кто даст гарантию что мидл это тот за кого он себя выдаёт? Может он 10 лет сидел формочки ваял, никак не развиваясь. Формально опыт есть, фактически ничего не знает и не хочет знать. Возьмёте его, а потом придётся увольнять через пару недель и всё по-новому.
База это гарантия того что человек как минимум знает основы. Остальному можно научить.
Потому что асинхронщина вещь такая - сто раз запустишь работает, на стопервом упадёт. Если человек не понимает что переменная может внезапно измениться между двумя строчками кода он напишет труднообнаруживаемый баг. Который потом придётся отлавливать саппорту у клиента, разбирая многотонные дампы.
База необходима даже ЛОРу. Допустим он видит запредельное количество лейкоцитов в анализе крови. Он не спец по раку, но может послать человека к другому специалисту. Это как в программировании. Фронтэндщик может проигнорировать неправильный ответ от сервера, типа моё дело маленькое, не работает да и хрен с ним. А может подойти к бекендщику и грамотно рассказать о проблеме. Вся команда только выиграет от этого.
Не везде и не всегда. Есть правила наработанные практикой которая отличается от теории. Потому что последняя не учитывает пограничные случаи. Та же сортировка. Один алгоритм работает быстрее в случае почти отсортированных данных, другой незаменим если мало памяти и тд и тп. Новичок может не знать какие именно данные поступают из очереди и тогда ему проще заучить то что говорят более опытные коллеги.
Опять таки вопрос времени. Книжка Кнута размером в три тома замечательная и после неё ты точно будешь разбираться в теории и сможешь ответить на любой вопрос. Но есть ли у тебя время на Кнута? И сотни других книжек.
Я думаю что в чём-то конкретном программист должен разбираться досконально. В остальном можно зазубрить. Например, если он фронтендщик, ему не надо разбираться в node.js, достаточно запомнить пару команд как быстро поднять сервер локально, дальше пусть devops парится.