Comments 32
Спрашиваем, казалось бы, не слишком сложные технически вещи. Но многие
кандидаты, сами себя оценивающие достаточно высоко, "залипают" на этих
вопросах, не хватает глубины, знаний основ. Начинаю задумываться: а в
чём причина? И опыт больше трёх-пяти лет, и образование техническое, и
опыт руководства у соискателя имеется, но зацепиться не за что.
Если у человека есть профильное образование, опыт больше 5 лет и опыт руководства, но на ваши "не слишком сложные вопросы" ему тяжело ответить, то ваши вопросы не сложные, а жесть какие сложные. Не впадайте в неадекват, не жестите, и задавайте нормальные вопросы.
А то ведь погонять вас по "несложным вещам" тут каждый первый может. Вы же сами засыпитесь, даже если будете в гугл и википедию подглядывать, всё равно поплывёте. Даже на самых базовых вещах.
Если у человека есть профильное образование, опыт больше 5 лет и опыт руководства...
...то это ещё ни о чем совершенно не говорит. Могут быть перегибы во время собесов, ведь нет и, наверно, не может быть единых стандартов их проведения, так что каждый их проводит индивидуально. Но статья, по большому счету, о массовом недостатке систематических знаний. Систематические знания в первую очередь можно получить из книг, тут с автором на 100% согласен - из видео, статей и SO можно обычно получить только отдельные факты, совершенно не понимая, как с ними обращаться в сложных ситуациях
опыт больше 5 лет и опыт руководства ... ваши вопросы не сложные, а жесть какие сложные
Или наоборот, слишком простые. Поэтому давно забыты и отброшены как неиспользуемые. Общее представление есть - что после 5 лет и для должности руководителя достаточно, а с деталями разбираются уже исполнители.
Хорошие издательства технической литературы, на мой взгляд: O'Reilly
Лично, я считаю, что в последнее время качество падает. Возьмём, например, недавнюю Bill Lubanovic - FastAPI: Modern Python Web Development. У меня создалось такое впечатление, что он её писал из-под палки. Первая версия относится к 2023 году, а в 2024 вышла новая версия, так как в первоначальной версии было огромное количество косяков
Packt
Здесь как повезёт. Наряду с хорошими авторами издательство любит нанянь индусов или негирийцев (без расизма с моей стороны) - и потом получаем опять нестыковки и legacy код
Можно было под спойлер несколько примеров вопросов написать, было бы интересней
Контекст вызова и this, чем вызывается ререндер в React и подобное.
Для тех, кто senior frontend и работает с React, кажется, это элементарные вещи.
Это просто к вам на собеседование с микронаушниками и gpt4o ещё не стали ходить. А как начнут вы все сразу посыпитесь. Я по возможности буду спосбствать популяризации этой идеи. Ну, или начнёте пальцами в ухи к собеседуемому залезать. Тоже вариант.
Ререндер в React может вызываться несколькими факторами:
Изменение состояния (state): Если вы вызываете функцию setState, это приводит к обновлению состояния компонента и его ререндеру.
Изменение пропсов (props): Если родительский компонент передает новые пропсы дочернему компоненту, это также вызывает ререндер дочернего компонента.
Контекст (Context): Если компонент подписан на изменения контекста и значение контекста изменяется, это также приведет к ререндеру.
Принудительный ререндер: Вы можете вызвать ререндер компонента вручную, используя методы, такие как forceUpdate.
Изменение ключа (key): Если вы изменяете ключ компонента в списке, React воспринимает это как новый компонент и ререндерит его.
[s]Чатгпт[/s] Собеседумый ответил на ваш вопрос?
Кандидат будет зависать на минуту, выслушивая в наушнике ответ. Потом воспроизводить его, запинаясь на незнакомых словах. А потом галлюцинировать на уточняющий вопрос, потому что в интернете не нашлось именно такой формулировки. Я бы посмотрел на этот цирк.
Вы серьёзно думаете, что это будет так работать? Вы от своих шелестящих книг отрывались и смотрели видео на ютубе как работает gpt4o?
Изменение состояния (state) - 1.5 секунды Если вы вызываете функцию setState, это приводит к обновлению состояния компонента и его ререндеру - 3 секунды
Я уже не говорю о том, что gpt4o может включить режим работы суфлера и делать паузы пока вы заканчиваете фразы. Умеет различать голоса собеседников.
Поэтому, если человек хоть немного в теме, подобного уровня подсказки смогут его вытянуть. В идеале конечно приспособить это, чтобы любая макака из зоопарка проходила ваши интервью. Вот будет смеха, я точно буду ржать.
>в интернете не нашлось именно такой формулировки
Похоже вы даже не понимаете как работает технология LLM...
Либо вы собеседовали бэкэндера, который не очень силен во фронте на позицию фулстека, либо фронтендера ангулярщика спрашивали по реакту, либо вы что то ещё не договариваете.
Приходят на фронтенд React вакансии собеседоваться целенаправленно. Для Angular отдельные вакансии.
А тот, кто запилил свой фронтенд фреймворк и использует только его, ещё на уровне HR будет срезан? В добрый путь!
Если человек написал свой хороший фреймворк, востребованный сообществом разработчиков, вряд ли он будет по собеседованиям на реакт-фронтендера ходить. Думаю, такого будут сами искать и приглашать хоть как консультанта, хоть как архитектора. А так-то этих фреймворков-велосипедов воз и маленькая тележка, но кому они кроме автора нужны? Кроме того, чтобы своё хорошее написать, неплохо бы поизучать и понять, как у других сделано. Что хорошо, что плохо, где возможности для улучшений, которые будут востребованы. Так что да, недооценённый гений со своим очередным убийцей реакта, возможно, будет срезан HR.
вопросы адекватные, а минусовальщики - нет
альманах искатель
Во-первых не всегда человек знающий может толково и внятно передать свои знания. Хокинг конечно это слишком утрируемый пример, но суть ясна. Условный интроверт который не любит общаться с людьми, но любит код и видит во снах схемотехнику транзисторов в 90% проиграет харизматичному балаболу с подвешенным языком, но с уровнем джуна.
Во-вторых конечному клиенту для которого разрабатывается продукт, плевать на то какие вы читаете книги и можете ли вы вообще читать. Ему нужно получить результат быстро и кач-но насколько это возможно.
И о чудо, оказывается что есть аишки которые уже выиграли у человека в возможном объеме хранения информации и оптимальном методе ее использования. А на собеседованиях до сих пор спрашивают, "какая функция вызывает... какие методы проектирования вы знаете..." да плевать какая) я и до аишек ее смогу загуглить за 10 сек, а сейчас вообще даже зная нет смысла тратить время на писанину кода. Забавный факт что из 10 собесов, я на 8-9 получаю негативный фидбек, но при этом когда я нахожу сам клиента и он не задает лишних вопросов, то в 9 случаях из 10 я выполняю его задачу.
Но конечно я понимаю, если ты потратил много времени на чтение книг, то врядли будешь одобрять таких "недоразработчиков" которые только и могут в клауди запросы писать. А реальность сейчас такова, что наоборот если дев не будет использовать современные методы в разработке, то пусть он дальше сам наслаждается шелестом листов своих книг.
Какие "технические вопросы" спрашиваете? Для примера будем считать, что по деталям языка программирования. Например: покажите, что горутины работают на десктопе и в браузере по-разному.
С одной стороны, не прочитав всю документацию по языку и, как следствие и среди прочего, не обретя способность на такие вопросы отвечать, профессилнальным программированием нельзя заниматься вообще. Потому что есть шанс писать не лучшим способом просто потому что возможности языка, которые использует лучший способ, неизвестны. Второе по силе утвержление - о существовании.
С другой, имея дело с человеком который проблемы со знанием о существовании решил, можно налететь на неудобного сотрудника. Или результат интересует его меньше чем технологии, или на денежные стимулы он слабо реагирует, или коллег оценивает по достоинству в своей шкале ценностей, или ещё что...
Проблема - несомненно. Корень проблемы - нежелание учить и неверие в свою способность удерживать.
Обычно задаю вопрос: из каких источников получаешь знания о новых технологиях в своей области?
Нормально отвечают. Если делать акцент на «новые» то это «новостные» источники.
Книга больше к «фундаментальным» знаниям. Но не о новинках
Такс, ещë один советчик книг. А теперь дайте ответ на такие вопросы: “
что такое инкапсуляция
И что такое абстракция по Бутчу?”
(Да-да, это из книжка про Объектно-ориентированный Анализ и проектирование)
Второй вопрос: что лучше, Шилдт или Хорсман? (подсказка - Лошадь)
Подозреваю, что такое Вы и спрашиваете.
Чтобы читать книгу - это надо полноценно погружаться в предмет, который сам автор изучал несколько лет, стараясь сконцентрировать там свой опыт. Например, по дотнету есть прекрасная книга про организацию памяти Конрада Кокосы, и её надо изучать внимательно и полноценно, так как она раскрывает все, начиная от аппаратной части и инструментов анализа до фич в написании кода. Но вопрос - когда разработчику-джуну этим заниматься, если есть еще тысячи аспектов, которые надо освоить, еще и работу работать? Этим могут заниматься, на мой взгляд, уже только сеньоры, у которых есть как свой опыт, так и время, которое можно выделить на самообразование. А последние как-то не особо часто бегают между работами, отсюда и впечатление, что все знают материал поверхностно. Другой вопрос в том, что знания в книгах могут быстро устаревать, если книга по конкретной технологии, и надо либо их читать с пылу с жару, либо использовать другой источник, документацию и пресловутые видео. Ну и напоследок, работе с книгой надо обучаться, конспектировать, перечитывать материал, пробовать на практике. В общем, чтение книги для погружения в вопрос - это большой затратный проект, который не все могут себе позволить. А те, кто могут, собеседования как раз и проводят, а не ходят по ним :)
Константин Харламов @Boeses_Genie
Frontent developer
frontenD, конечно же. глаз режет, простите.
есть подозрение, что по фронту внятных книжек не почитать, тк книжка пишется дольше чем выходит yet another revolution feature в твоем фреймворке.
в бэке постабильнее
как вообще по ютубу программировать учиться - ума не приложу. разве что посмотреть лекции/доклады, или что то вроде объяснения алгоритмов. базу текстом воспринимать сильно легче
Спасибо, что заметили опечатку.
По фронту переиздаётся что-то, когда технологии обновляются. А что-то не так уж быстро устаревает. Например, справчник Мейера по CSS, Флэнаган по JS.
базу текстом воспринимать сильно легче
Что такое база? Мы, например, не одному человеку уже советовали гарвардовский cs50 и именно как база (несмотря на то, что там есть достаточно сложные вещи) он (по нашему имху и отзывам тех, кому советовали) великолепен, а подобных книг нет вообще.
По ютубу прекрасно учиться, если смотреть специализированные темы, есть "пишем компилятор" на 30 роликов по два часа, есть конференции NDC, с топовыми докладчиками, есть лекции MIT, да много всего ещё.
Вот как раз специализированные темы, имхо, по видео изучать сложно. Собственно основная проблема та же, что и с электронными планшетами, только хуже. По сути видео это как хранение на лентах по сравнению с хдд, скажем. Рандомный поиск нереален, заметки рядом делать нереально, скорость считывания информации медленная и по сути константа, точное позиционирование не работает и так далее.
О книгах и собеседованиях