Comments 149
А где самое интересное?
В ответ на такие заявления я давно придумал пару небольших задачек с подло скрытой алгоритмикой
Из прикладного приходят в голову автоскейлинг чего угодно в зависимости от нагрузки, управление лифтами… все, закончилась фантазия.
На такие задачи многие специалисты по фронтэнду и мобильной разработке справедливо делают удивлённые глаза: «зачем мне это?»
Самое простое — дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу. Далеко не все уловят подвох и спросят «а зачем сортировать, когда достаточно одного прохода?»
Или попросите в том же списке организовать возможность связи между задачами, но попросите не дать пользователю возможности сохранять задачи с кольцевыми ссылками, например.
Самое простое — дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу. Далеко не все уловят подвох и спросят «а зачем сортировать, когда достаточно одного прохода?»
Или попросите в том же списке организовать возможность связи между задачами, но попросите не дать пользователю возможности сохранять задачи с кольцевыми ссылками, например.
Самое простое — дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу. Далеко не все уловят подвох и спросят «а зачем сортировать, когда достаточно одного прохода?»
Мне очень стыдно, но я тоже не вижу подвоха. Почему одного прохода недостаточно?
Спросят как раз те, кто уловит подвох. Большинство соискателей говорят «отсортирую и возьму первый элемент», а сложность такого решения в среднем будет линеарифмическая. И даже на вопрос «а можно проще?» отвечают не все.
А. Я просто удивился, подумав, что вы считаете, что надо сортировать, а это очень странно.
С другой стороны, будем честными, почти во всех современных языках и СУБД будет использоваться подход «отсортируй и возьми первый» (хотя, скажем, в F# есть
С другой стороны, будем честными, почти во всех современных языках и СУБД будет использоваться подход «отсортируй и возьми первый» (хотя, скажем, в F# есть
minBy и maxBy).Ну не знаю. В СУБД да, это стандартный подход, и меня это несколько смущало всегда. В Java рядом с Collections.sort есть Collections.min и Collections.max, и всё равно все фигачат сортировку для поиска граничных элементов.
А зря смущаетесь, кстати. SQL- декларативный язык, вы не знаете, как именно будет выполнен ваш запрос (например, если там был индекс… ну вы понимаете). Аналогично и в последовательностях, если захотеть — можно написать итератор, который даст сублинейное время (например, на основе алгоритма быстрой сортировки).
Да, но всё равно для достаточно частой задачи получения строки с экстремальным значением в этом декларативном языке нужно встать на уши, и выглядит полученная конструкция неинтуитивно. Предполагаю, что и оптимизатор там нетривиальный для распознавания таких ситуаций.
Ээээ, зачем вставать на уши-то? Select max(field1) from table1 group by field1; — что же тут неинтуитивного-то?
Это вы максимум нашли, речь шла про строку с экстремальным значением в одном из полей.
Эээ, а пример может показать?
У меня есть табличка с задачами todo_tasks, там есть поля id, name и created_timestamp. Я хочу найти самую раннюю задачу, т.е. ту, у которой значение в created_timestamp минимально. «Найти строку» — т.е. найти её идентификатор id, либо сразу всю строку. Без подзапросов или джойнов на стандартном SQL вы такое не напишете. Как-то так, например:
SELECT *
FROM todo_tasks
WHERE created_timestamp = (
SELECT MIN(created_timestamp)
FROM todo_tasks
GROUP BY created_timestamp
)
Вообще, конечно,
SELECT TOP 1 *
FROM todo_tasks
ORDER BY created_timestamp
Да, а в других базах есть ещё FIRST, LIMIT и т.д. Я говорил про стандартный SQL.
А смысл ограничивать себя ANSI, если в каждой БД есть своя оптимизация?
Нет, на практике всегда можно выкрутиться родным диалектом SQL, спору нет, но даже в вашей конструкции есть некоторая неинтуитивность. ORDER это всё-таки глагол, и мне надо очень постараться, чтобы увидеть в этой конструкции декларативное описание того, что я на самом деле хотел получить.
Там, вообще-то, все операции — глаголы (прямо начиная с SELECT), это нормально. Ну да, в SQL не заложили nth order selection, бывает — семантика «отсортируй/выбери» тоже неплоха. Что там внутри — вы все равно не знаете, а предполагаете.
К сожалению «что там внутри — вы все равно не знаете, а предполагаете» на практике не работает. Если хотите, чтобы ваши запросы отрабатывались быстро — нужно знать. Потому реально SQL очень часто используют не по делу. Если у вас SQL запросы не формируются программой, а статичны — в 9 случаях из 10 вам SQL не нужен и будет только мешать. Вырезание аппендицита не снимая пальто. Вот когда запросы заранее неизвестны — другое дело, тот SQLю найти альтернативу сложно.
Прежде чем начинать выпендриваться своими нанооптимизациями, стоит вспомнить про benchmark.
А то программа после этих нанооптимизаций начинает медленней работать.
А то программа после этих нанооптимизаций начинает медленней работать.
explain ANALYZE SELECT * FROM messages order by created_at limit 1;
QUERY PLAN
Limit (cost=0.14..1.15 rows=1 width=49) (actual time=0.009..0.009 rows=1 loops=1)
-> Index Scan using my_index on messages (cost=0.14..12.31 rows=12 width=49) (actual time=0.008..0.008 rows=1 loops=1)
Planning time: 0.059 ms
Execution time: 0.022 ms
explain ANALYZE SELECT * FROM messages WHERE created_at = (SELECT min(created_at) FROM messages);
QUERY PLAN
Seq Scan on messages (cost=1.16..2.31 rows=1 width=49) (actual time=0.016..0.018 rows=1 loops=1)
Filter: (created_at = $1)
Rows Removed by Filter: 11
InitPlan 2 (returns $1)
-> Result (cost=1.15..1.16 rows=1 width=0) (actual time=0.008..0.008 rows=1 loops=1)
InitPlan 1 (returns $0)
-> Limit (cost=0.14..1.15 rows=1 width=8) (actual time=0.007..0.007 rows=1 loops=1)
-> Index Only Scan using my_index on messages messages_1 (cost=0.14..12.34 rows=12 width=8) (actual time=0.006..0.006 rows=1 loops=1)
Index Cond: (created_at IS NOT NULL)
Heap Fetches: 1
Planning time: 0.096 ms
Execution time: 0.040 ms
1. Зачем тут group by?
2. Ваш запрос потенциально может вернуть более одной записи, в нарушение условий задачи.
2. Ваш запрос потенциально может вернуть более одной записи, в нарушение условий задачи.
Кстати говоря, максимум вы нашли неправильно. Этот код даже не запустится.
Самое простое — дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу.
Правильно ли я понимаю, что у человека при этом есть контекст "В Java рядом с" (просто без этого решение выглядит не так однозначно; да, привет РСУБД).
У человека есть контекст в виде процедурного языка программирования общего назначения, в котором есть циклы, присваивания и операторы сравнения. Этого достаточно, чтобы решить задачу в один проход.
Если задачу поставить как «Есть todo-лист, есть сортировка, напишите поиск» — то больше половины (мне даже кажется — значительно больше) опрашиваемых будут делать поиск через сортировку.
Да, сам по себе ответ «отсортирую и возьму первый элемент» ещё ничего не значит. Самое интересное начинается тогда, когда интервьюер задаёт вопрос «а можно быстрее?»
И я в такой ситуации могу и сообразить, а могу и затупить окончательно «чего он от меня хочет»… Тут от ситуации зависит — есть ли контакт с интервьером, важность конкретной вакансии для меня и ещё кучи факторов.
В общем, имхо, проще сразу как-то разграничить todo-листи сортировку… тем более, что сортировка для todo-листа вещь ну очень абстрактная.
В общем, имхо, проще сразу как-то разграничить todo-листи сортировку… тем более, что сортировка для todo-листа вещь ну очень абстрактная.
Если вы «затупите», то ничего страшного не произойдёт: просто вас не возьмут на работу. Самой главной задачей интервьюера не является отбор всех хороших кандидатов, самой главной задачей является отсев плохих кандидатов, задача отбора хороших всё-таки вторична.
Просто потому что последствия несравнимы: отсев хорошего кандидата обозначает, что вакансия ещё несколько дней (ну, может быть, недель) повисит, приём на работу плохого — последствия могут быть самыми различными, но в самом благоприятном случае — это несколько месяцев «выпитой крови» у остальных разработчиков.
Просто потому что последствия несравнимы: отсев хорошего кандидата обозначает, что вакансия ещё несколько дней (ну, может быть, недель) повисит, приём на работу плохого — последствия могут быть самыми различными, но в самом благоприятном случае — это несколько месяцев «выпитой крови» у остальных разработчиков.
Самой главной задачей интервьюера не является отбор всех хороших кандидатов, самой главной задачей является отсев плохих кандидатов, задача отбора хороших всё-таки вторична.
Просто потому что последствия несравнимы: отсев хорошего кандидата обозначает, что вакансия ещё несколько дней (ну, может быть, недель) повисит, приём на работу плохого — последствия могут быть самыми различными, но в самом благоприятном случае — это несколько месяцев «выпитой крови» у остальных разработчиков.
Эээ, странное у вас понятие о задаче приема сотрудников, действительно хороший разработчик может разработать новую архитектуру, исправить косяки старой и вообще спасти проект, который могут загубить чуть менее хорошие разработчики… но вы его отсеяли, потому что он не вспомнил алгоритм красно-черного дерева, который вообще никогда не требовался и не потребуется в реальной работе.
Прием на работу плохого это лишь потеря денег на зар.плату испытательного срока, а вот отсев очень хороших разработчиков это снижение общего уровня команды, что может быть фатально (действительно сильных разработчиков дефицит, а ошибочно отсеев очень хороших, вам останется просто хорошие, то есть более слабые разработчики). Так что это палка о двух концах, если вам реально нужны разработчики, а не просто исполнители.
Честно говоря не хочется с вами спорить. Когда в ответ на давно всем известные банальности (да-да, банальности, надо понимать что статьи Джоэла никаких откровений никогда не содержат, они просто хорошо описывают то, что «люди в теме» и так хорошо знают) начинаются какие-то странные абстрактные рассуждения неизвестно о чём…
Возможно мы опять говорим о каких-то других мирах? На всякий случай — я из мира «ширпотреба», где продукты разрабатываются годами, а используются миллионами. Впрочем я, если честно, людей и из других миров не встречал, которые кого-либо нанимали на работу руководствуясь другими подходами… ну то есть я видел много разработчиков которые считали, что «так нанимать людей нельзя», но никого из тех, кто решал — принять кого-то на работу или нет исповедующего вашу религию я, если честно, не встречал. Среди успешных компаний, по крайней мере. Легко могу поверить что в компании, которая и так готова вот-вот развалиться кто-то и будет так думать… но стоит ли туда идти работать?
А вы-то сами с какой «стороны баррикад» находитесь? Сколько людей проинтервьюировали, скольких с вашей подачи наняли? Мне вот «герои» способные спасти проект в одиночку не встречались, а вот «выродки» способные его извести встречались неоднократно — но возможно в других «мирах» по-другому…
Возможно мы опять говорим о каких-то других мирах? На всякий случай — я из мира «ширпотреба», где продукты разрабатываются годами, а используются миллионами. Впрочем я, если честно, людей и из других миров не встречал, которые кого-либо нанимали на работу руководствуясь другими подходами… ну то есть я видел много разработчиков которые считали, что «так нанимать людей нельзя», но никого из тех, кто решал — принять кого-то на работу или нет исповедующего вашу религию я, если честно, не встречал. Среди успешных компаний, по крайней мере. Легко могу поверить что в компании, которая и так готова вот-вот развалиться кто-то и будет так думать… но стоит ли туда идти работать?
А вы-то сами с какой «стороны баррикад» находитесь? Сколько людей проинтервьюировали, скольких с вашей подачи наняли? Мне вот «герои» способные спасти проект в одиночку не встречались, а вот «выродки» способные его извести встречались неоднократно — но возможно в других «мирах» по-другому…
А вы-то сами с какой «стороны баррикад» находитесь?
Сразу с двух сторон
Сколько людей проинтервьюировали, скольких с вашей подачи наняли?
Больше сотни, несколько десятков.
Мне вот «герои» способные спасти проект в одиночку не встречались, а вот «выродки» способные его извести встречались неоднократно
Вопрос не в спасти, вопрос в том что чтобы выбрать правильную архитектуру и правильную технологию нужен соответствующий уровень экспертизы, много раз встречал ситуации когда хорошие кодеры тратили кучу времени реализации ошибочной архитектуры или не верной технологии, потому что не было в команде человека с достаточным уровнем компетенции, который мог бы предложить правильный и короткий путь.
На самом деле, найти отличного специалиста с высоким уровнем компетенции очень сложно, насколько сложно что компании готовы выплачивать изрядные бонусы тем кто порекомендует такого специалиста для найма. Возможно в Вашем мире, хорошими специалистами можно разбрасываться, в нашем — нет.
Больше сотни, несколько десятков.Возможно мы действительно живём в совсем разных мирах раз вам удаётся из сотни кандидатов набрать «несколько десятков» подходящих.
Возможно в Вашем мире, хорошими специалистами можно разбрасываться, в нашем — нет.Хорошими специалистами разбрасываться нельзя, «хорошими» кандидатами — легко.
Вопрос не в спасти, вопрос в том что чтобы выбрать правильную архитектуру и правильную технологию нужен соответствующий уровень экспертизы, много раз встречал ситуации когда хорошие кодеры тратили кучу времени реализации ошибочной архитектуры или не верной технологии, потому что не было в команде человека с достаточным уровнем компетенции, который мог бы предложить правильный и короткий путь.Вообще в вашей фразе словосочетание «хороший кодер» меня несколько покоробило. Это вообще кто? Джуниор, который ещё опыта не имеет и потому не может сам спроектировать архитектуру? А как так получилось, что в команде одни джуниоры собрались? Вам не кажется, что подобные проблемы — как раз следствие того, что вы очень «бережно» относитесь к кандидатам и потому у вас нехватка людей «с достаточным уровнем компетенции»? Как-то само описание ваших проблем ну никак не наводит на мысли о том, что ваш подход привёл к тому, что уровень команды оказался офигительно высоким.
А вообще, похоже, проблема даже не в том с какой стороны баррикад вы находитесь, а скорее в каком мире вы живёте. И тут мир «ширпотреба» (в котором, как я уже рассказывал, я и живу) резко отличается от мира заказного ПО или внутреннего ПО. Потому что в случае заказного ПО или внутреннего ПО «какой-нибудь» результат — часто лучше, чем никакого. Контракты, сроки, etc. Отсюда и появляется желание «не упустить» мало-мальски грамотных людей, а после набора пресловутых «хороших кодеров», которые сами не видят проблем в архитектуре, начинаются проблемы с архитекторами, которые все их косяки не могут предугадать и т.д. и т.п.
В мире «ширпотреба» жизнь устроена совсем не так. Продажи «продукта №1» и «продукта №2» отличаются на порядок. Иногда — и не на один. Отсюда следует правило: никому не нужен «продукт №2». Речь всегда идёт только и исключительно о первом месте. Понятно, что первое место может принадлежать только одному продукту и иногда (достаточно редко) компаниям удаётся перейти с первого места но второе, это всё понятно. Главное — что вы никогда не будете и пытаться сделать продукт, который не планируется вывести на первое место. Вам на это никто денег не даст! Речь идёт только о том когда и как вы завоюете первое место, сама цель даже не обсуждается.
Отсюда и требования к командам и вообще рекрутингу: лучше не нанять никого (в этом случае вы «пропустите» всего лишь очередную попытку сделать что-то, что «всех удивит»), чем нанять кого-то неподходящего. Соответственно ситуация «а в команде не было архитектора и потому кодеры потратили время впустую» не возникает в принципе: никаких «кодеров» у вас в команде просто нет и быть не может, а если кто-то и потратил время на «кривую» и плохо работающую архитектуру — так это его вина в первую голову. Даже если архитектуру разработал кто-то с большим опытом — у него-то где была голова, когда он начал её реализовывать и понял, то так — оно работать не будет?
Если так — тогда разница в подходах понятна и простительна. Но только тогда уж и называть вещи нужно своими именами: в первом случае, когда вы «боитесь упустить» хороших разработчиков вы получаете в основном «просто исполнителей», а во втором случае — да, у вас будет команда разработчиков, причём хороших разработчиков. Хотя, возможно, и меньшего размера чем вам бы хотелось. Отсев хороших кандидатов ну никак не может «снизить общий уровень команды» — за исключением только лишь патологических случаев, когда вы умудряетесь отсеять хороших кандидатов, но почему-то берёте плохих. Но для мира ширпотреба это — никогда не проблема, там «закрытие плана по валу» не висит на интервьерах никогда. Как пишет Джоэл: «Это не ваша проблема. Это проблема рекрутеров и отдела кадров, это проблема Джоэля, но никак не ваша.» Откуда при таком подходе у вас в команде возьмутся «просто исполнители»? Непонятно.
В мире «ширпотреба» жизнь устроена совсем не так. Продажи «продукта №1» и «продукта №2» отличаются на порядок. Иногда — и не на один. Отсюда следует правило: никому не нужен «продукт №2». Речь всегда идёт только и исключительно о первом месте. Понятно, что первое место может принадлежать только одному продукту и иногда (достаточно редко) компаниям удаётся перейти с первого места но второе, это всё понятно. Главное — что вы никогда не будете и пытаться сделать продукт, который не планируется вывести на первое место. Вам на это никто денег не даст! Речь идёт только о том когда и как вы завоюете первое место, сама цель даже не обсуждается.
Отсюда и требования к командам и вообще рекрутингу: лучше не нанять никого (в этом случае вы «пропустите» всего лишь очередную попытку сделать что-то, что «всех удивит»), чем нанять кого-то неподходящего. Соответственно ситуация «а в команде не было архитектора и потому кодеры потратили время впустую» не возникает в принципе: никаких «кодеров» у вас в команде просто нет и быть не может, а если кто-то и потратил время на «кривую» и плохо работающую архитектуру — так это его вина в первую голову. Даже если архитектуру разработал кто-то с большим опытом — у него-то где была голова, когда он начал её реализовывать и понял, то так — оно работать не будет?
Если так — тогда разница в подходах понятна и простительна. Но только тогда уж и называть вещи нужно своими именами: в первом случае, когда вы «боитесь упустить» хороших разработчиков вы получаете в основном «просто исполнителей», а во втором случае — да, у вас будет команда разработчиков, причём хороших разработчиков. Хотя, возможно, и меньшего размера чем вам бы хотелось. Отсев хороших кандидатов ну никак не может «снизить общий уровень команды» — за исключением только лишь патологических случаев, когда вы умудряетесь отсеять хороших кандидатов, но почему-то берёте плохих. Но для мира ширпотреба это — никогда не проблема, там «закрытие плана по валу» не висит на интервьерах никогда. Как пишет Джоэл: «Это не ваша проблема. Это проблема рекрутеров и отдела кадров, это проблема Джоэля, но никак не ваша.» Откуда при таком подходе у вас в команде возьмутся «просто исполнители»? Непонятно.
Вот если вы прийдете на собеседование к плотнику и он вас попросит забить шуруп молотком, то половина народу забъет-таки этот шуруп молотком, не потому что они про отвертку ничего не знают, а потому что их конкретно попросили забить шуруп. И если потом их спросят: «а нельзя ли сделать это быстрее?», то далеко не все подумают о том, что можно взять шуруповерт, ведь в контексте забивания шурупов скорее подходит молоток потяжелее.
Отличный пример. Вот я предпочту взять тех немногих, кто выкинет молоток и попросит шуруповёрт.
Ну шуроповёрта может и не быть. А может оказаться, что и шуруп тут не нужен, а достаточно простого гвоздика. Но человек, который молча, не меняя выражения лица, берёт молоток и начинает им забивать шурупы — это совсем не тот человек, которого я хотел бы видеть у себя в команде. Об этом, собственно, весь разговор.
а потом такие, «с шуруповёртами» в мебель шурупами вкручивают подпятники, вместо того, чтобы гвоздиком прибить, т.к. молотка при себе нет. И не важно, что ножку раскорячивает от этого малость — зато шуруповёртом р-раз и готово
Быстрее? Ну если молоток потяжелее — оно всяко быстрее шуруповёрта… Проверял. ;)
Только это не очернь корректное сравнение — программирование предоставляет куда большую возможность/вариативность действий.
Только это не очернь корректное сравнение — программирование предоставляет куда большую возможность/вариативность действий.
Именно потому что программирование предоставляет куда большую вариативность действий подобные вещи и важно проверять. Если у вас кто-то начнёт шурупы забивать молотком — его соседи это заметят (хотя бы по странному шуму) и могут на это как-то повлиять, а если у вас кто-то N! памяти потребляет, то этого можно сходу на тестовых данных и не заметить, а чинить потом может быть весьма непросто.
По секрету: иногда бывает надо забить шуруп. Пример (несколько утрированный, но у меня что-то подобное случалось): на даче — не оказалось гвоздей, отвёрток, шуруповёртов, а вот саморезы и доски и чурбаны есть: что лучше, сидеть на земле, или таки забить саморезы, сделав скамейки?
Про это все как бы знают, но это совершенно не делает аналогию хуже: в программировании тоже бывают случаи, когда лучше-таки отсортировать. Но в обоих случаях нужна веская причина. Если человек грамотно аргументирует свои «странные» действия — то честь ему и хвала, но ведь ясно, что в большинстве случаев речь идёт не об этом…
Безусловно. Любая нормальная задача на собеседовании — это не какой-то однозначный вопрос, требующий правильного ответа, а приглашение к диалогу, в ходе которого человек может очень много всего рассказать, в том числе и по поводу того, в каких именно случаях правильнее забивать шурупы молотком. И чем больше человек скажет на эту тему умных мыслей, различных юзкейсов, случаев из практики, тем больше у него шанс произвести хорошее впечатление.
UFO just landed and posted this here
Знаете, а я, скорее всего, тоже попадусь на эту уловку… а с учётом того, что собеседование для меня всё-таки стрессовая ситуация, то и на уточняющий вопрос не факт, что смогу ответить, особенно сразу:
Вы ещё в постановке задачи сами же сбиваете с толку кидая в кучу «дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу». Вы в одном месте упоминаете задачу и инструмент, который может эту задачу решить (то что не оптимально — дело уже совсем другого порядка).
Вы ещё в постановке задачи сами же сбиваете с толку кидая в кучу «дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу». Вы в одном месте упоминаете задачу и инструмент, который может эту задачу решить (то что не оптимально — дело уже совсем другого порядка).
Это никак не связанно с пониманием алгоритмов, а просто эффект когда образование провоцирует на сложные шаблонные решения там, где лучше применить более простые. Наверное у этого эффекта есть какое-то звучное название, часто встречается.
Справедливости ради, сложность будет O(ln(n))+O(n)=O(n). Линеарифмическая — это, я так понимаю O(ln(n)*n) — никак не получится.
Справедливости ради, сложность будет O(ln(n))+O(n)=O(n). Линеарифмическая — это, я так понимаю O(ln(n)*n) — никак не получится.
Я тоже долго врубался в эту фразу :) Я так понимаю, forketyfork хотел сказать, что мало кто догадывается, что сортировка не нужна.
Да. Причём это выстраданная задача. Я часто видел подобный поиск граничного значения в реальном коде. Думаю, это SQL всех испортил.
А тут ещё и не факт, что она не нужна. Тут ведь какая засада: «логарифма не существует». В практической жизни у вас ln(N) в задаче сортировки явно не превысит сотню (а в ToDo списке вряд ли превысит и десяток). А разница между интерпретируемым кодом и компилируемым может достигать трёх порядков. И на старом JavaScript-движке сортировка будет быстрее. Тут уточняющий вопрос нужен. Что-нибудь типа «а если у нас дата хитрым образом записана?». Тогда использовать чисто встроенную сортировку нельзя, нужно вспомогательную функцию передавать — и вот тут-то уже лучше по массиву пробежаться.
А что на собеседованиях раздражает или напрягает вас?
Меня лично напрягает несоответствие требований в вакансии и вопросов на собеседовании, например, пишут нужен фуллстек js-девелопер, a на деле 70% вопросов про верстку и различия бордеров и прочих марджинов.
Нравится, когда менеджмент демонстрирует достаточную компетентность в технических вопросах. На одном из последних интервью в процессе общения с CTO подробно прошлись по тестовому заданию, я был приятно удивлен и принял предложение :)
Только 20 часов нужно любому человеку чтобы изучить что угодно с нуля!
Это 3-и рабочих дня.
Зачем спрашивать то, что так быстро можно изучить?
Лучше на собеседовании обсуждать и договариваться о мотивационных моделях.
Это 3-и рабочих дня.
Зачем спрашивать то, что так быстро можно изучить?
Лучше на собеседовании обсуждать и договариваться о мотивационных моделях.
Помимо знаний, которые действительно можно утрамбовать в краткосрочную память за несколько дней (как перед экзаменом), есть ещё навыки, опыт, кругозор, которые приобретаются сотнями и тысячами человеко-часов.
Только 20 часов нужно любому человеку чтобы изучить что угодно с нуля!
Ерунда,
1) вы просто не сталкивались с по-настоящему серьезными вещами, попробуйте изучить весь стек технологий Oracle хотя бы за месяц,
2) иметь отрывочные представления/вызубрить документацию и действительно знать — абсолютно разные вещи, скажем вам дадут задачу правильно спроектировать базу Oracle, оптимизировать её производительность, хранимые процедуры и прочее при том что вы даже sql не знаете, за 20 часов вы сможете выучить гайд, но не сможете выучить все best practise и в результате получится полная ерунда
А потом такие вот товарищи «20-ти часовики» пишут такую хрень, что возникает желание отрубить руки.
Надеюсь, из вас подобные утверждения лезут по неопытности, и со временем вы поймете, какую ббредятину только что сморозили.
Надеюсь, из вас подобные утверждения лезут по неопытности, и со временем вы поймете, какую ббредятину только что сморозили.
А как вы предлагаете мне мотивировать человека, который только через 3 рабочих дня, возможно будет знать то, с чем ему придется работать?
ИМХО, для миддла+ самое главное это паттерны и best practices.
А их ты никак не научишься видеть за 3 рабочих дня.
Для джуниора да, N часов на технологию и вперед кодить под руководством.
А их ты никак не научишься видеть за 3 рабочих дня.
Для джуниора да, N часов на технологию и вперед кодить под руководством.
Для джуниора да, N часов на технологию и вперед кодить под руководством.
Скорее для джуниора важнее ум, мотивация и общая адекватность, а технологию он изучить/ему расскажут по ходу дела.
ИМХО, для миддла+ самое главное это паттерны и best practices.
Брр, не согласен, ИМХО для миддла и синера важнее интуиция, которая позволяет находить золотую середину между паттерном и простой реализации, между чужими best practices и тем что реально нужно именно Вашему проекту. Как раз попытка чрезмерного бездумного следования паттернам и чужим описанием best practice и методологий характерна для сильного джуниора, а всегда вот находить золотую середину могут только хорошие миддлы и сеньоры, даже очень хорошему джуниору это как правило недоступно.
> Скорее для джуниора важнее ум, мотивация и общая адекватность, а технологию он изучить/ему расскажут по ходу дела.
Дык я об этом и написал, только не так явно.
> Брр, не согласен, ИМХО для миддла и синера важнее интуиция…
Senior — да, нужно еще больше опыта. Но для миддла достаточно идти по паттернам/практикам. Пусть даже и часто это бывает лишним для текущего проекта. Типа лепить для home page несколько слоёв абстракции, а-ля интерфейс репозитория + одна реализация + интерфейс data mapper'a + та же одна реализация под одну используемую БД + еще пара контрактов, используемых только в одном классе. Я такое видел, да.
Для меня разделение между middle и senior как раз и проходит в умении определять необходимый уровень абстракции.
Дык я об этом и написал, только не так явно.
> Брр, не согласен, ИМХО для миддла и синера важнее интуиция…
Senior — да, нужно еще больше опыта. Но для миддла достаточно идти по паттернам/практикам. Пусть даже и часто это бывает лишним для текущего проекта. Типа лепить для home page несколько слоёв абстракции, а-ля интерфейс репозитория + одна реализация + интерфейс data mapper'a + та же одна реализация под одну используемую БД + еще пара контрактов, используемых только в одном классе. Я такое видел, да.
Для меня разделение между middle и senior как раз и проходит в умении определять необходимый уровень абстракции.
Т.е. книжки «С++ за 21 день» это для лентяев, готовых заниматься менее часа в день?
сарказм_мод_выкл
сарказм_мод_выкл
>Только 20 часов нужно любому человеку чтобы изучить что угодно с нуля!
А вы пойдете вырезать аппендицит к хирургу, подготовленному за 20 часов?
А вы пойдете вырезать аппендицит к хирургу, подготовленному за 20 часов?
Интервьюер не станет спрашивать о том, в чём сам не разбирается.
Ага, конечно. Я когда-то на интервью доказал интервьюверу что он не прав, правда для этого пришлось вспомнить книгу и главу в ней, где данная тема освещалась (каким-то чудом я её недавно читал и помнил где искать). К его чести, он признал, что ошибался.
Я не говорил, что интервьюер не ошибается, я лишь говорил, что он не будет спрашивать о том, в чём не разбирается. Да, к его чести, он признал ошибку, но это плюс ему, а не вам. Не забывайте про человеческий фактор. Вот вы пришли к техническому специалисту, потенциальному будущему начальнику или наставнику, и в первый час общения с ним доказали ему, что он ошибается в том, в чём, как ему казалось, он разбирается. Как вы считаете, у человека возникнет желание с вами работать? Говорят, что «умников» никто не любит — здесь под «умниками» понимаются не просто грамотные специалисты, а те, кто любит спорить и доказывать чужую неправоту там, где это ну совершенно необязательно.
Если бы мне на собеседовании человек аргументированно доказал, что я ошибаюсь в чём-то, в чём я считал, что разбираюсь и это было бы действительно так — я бы начальству и HR-ам в тот же день мозг бы съел, чтобы его взяли немедленно.
Это зависит от стиля «доказательства», конечно, но в любом случае не забывайте, что вы принимаете на работу не сумму знаний, а живого человека, и работать он будет с живыми людьми.
А умение отстаивать свою точку зрения тоже полезно (и аргументированно вести дискуссию) тоже важно для выживания в коллективе. Если человек из-за боязни авторитетов не доказывает свою правоту, он может повести себя так же и при разговоре с «более опытным» коллегой, и будет принято неправильное решение.
Согласен, это важное умение, но есть целый спектр между умением отстаивать свою точку зрения ради пользы общего дела и самоутверждением в виде попыток на каждом ровном месте доказывать окружающим, какой ты крутой. Едва ли собеседование — это адекватное место для первого. Чаще на собеседованиях проявляется что-то ближе ко второму.
Собеседование — адекватное место, чтобы показать, как ты умеешь первое.
Для этого на собеседованиях, как правило, есть специальные задачи. Например, спроектируйте какую-нибудь архитектуру кода или системы. А почему вы так сделали? А как вы учли это? А почему выбран не этот, а тот вариант? Вот это хороший повод для того, чтобы проявить умение убеждать и аргументировать. А вот «вы не правы» — типичное самоутверждение.
Во-первых, таких «специальных» задач может и не быть.
Во-вторых, если человек, который меня собеседует, говорит мне что-то неправильное, откуда я знаю, он специально это говорит, чтобы меня проверить, или случайно ошибся, или действительно не в курсе?
Понимаете, собеседование — это двухсторонний процесс, мне как кандидату тоже полезно заранее знать, как люди, с которыми я планирую работать, реагируют на мое поведение.
Во-вторых, если человек, который меня собеседует, говорит мне что-то неправильное, откуда я знаю, он специально это говорит, чтобы меня проверить, или случайно ошибся, или действительно не в курсе?
Понимаете, собеседование — это двухсторонний процесс, мне как кандидату тоже полезно заранее знать, как люди, с которыми я планирую работать, реагируют на мое поведение.
Ну а это уже было бы из области провокаций, я мог бы добавить это шестым пунктом в «как отпугнуть соискателя». Я бы указал на ошибку, но спорить не стал бы. Если из этого следует какой-то вывод о моих личных качествах, то он, скорее всего, будет неверным.
Довольно интересно было наблюдать за вашим «спором». Один вывод для себя я сделал, что особенно если тебя собеседует твой будущий руководитель, то очень полезно увидеть как реагирует именно собеседующий на такое. Т.к. бывает, что ищут именно хорошего исполнителя, который бы не лез со своими знаниями, а лучше засунул их поглубже себе. Вот если руководитель из этого плана, который не воспринимает ни аргументированную критику, не хочет слышать никаких твоих начинаний, то тут стоит задуматься. И такая же зеркальная ситуация с другой стороны бывает. Тут вопрос именно в том, кого ищут все-таки?
Мне интересно работать конечно с теми, кто может сказать «вы не правы», даже если это утверждение ложно. Т.к. после окончания дискуссии каждый участник уже чему-то научится. А в конце концов научатся проводить продуктивные дискуссии, в которых рождается истина.
Мне интересно работать конечно с теми, кто может сказать «вы не правы», даже если это утверждение ложно. Т.к. после окончания дискуссии каждый участник уже чему-то научится. А в конце концов научатся проводить продуктивные дискуссии, в которых рождается истина.
Кроме технического аспекта «начинаний», есть ещё и аспект ответственности. С моей точки зрения, инициатива всегда приветствуется, но она наказуема. Это означает, что если человек принёс какую-то идею, то он за неё отвечает — т.е. помогает внедрять, подсказывает другим, собирает грабли, вовремя отслеживает, если идея не работает, и её надо пересмотреть и т.д.
Просто иногда случается такое, что человек приносит свою гениальную идею, а потом, когда она не работает, отходит в сторону со словами «мучайтесь сами, это не идея была плохая, это ваша задача отстой». Отвечать за криво реализованную идею приходится как раз начальнику. Поэтому начальник может не принимать идеи подчинённых не по причине того, что он самодур и считает себя умнее всех, а потому что он понимает, что отвечать за эту идею потом ему.
Просто иногда случается такое, что человек приносит свою гениальную идею, а потом, когда она не работает, отходит в сторону со словами «мучайтесь сами, это не идея была плохая, это ваша задача отстой». Отвечать за криво реализованную идею приходится как раз начальнику. Поэтому начальник может не принимать идеи подчинённых не по причине того, что он самодур и считает себя умнее всех, а потому что он понимает, что отвечать за эту идею потом ему.
Допустим вы — начальник. А зачем подчиненный должен/обязан делать работу начальства? Это тоже одна из проблем. Если вам принесли идею, а вы ее приняли, то дальше — ваша задача не ударить в грязь лицом. Риски принимаете вы. Никто не отменял того, что в дискуссии должны оговариваться и риски. А перекладывая ответсвенность на инициатора, вы подрываете свой авторитет как руководитель в глазах подчиненных. Ну допустим, переложили ответсвенность на подчиненного, а он воплотил идею. Вы как хороший руководитель получаете все лавры, подчиненный не получает ничего, только одобрительное похлопывание по плечу, в лучшем случае премию 10 тысяч рублей, усталость, недосып, чувство обиды. Так обычно и происходит. Но что дальше? Дальше вы получили безинициативного, обиженного, нелояльного, но в тоже время отличного специалиста, что хуже лояльного плохого. Со следующей идеей он уже к вам не придет, а может и придет, но уже к вашему начальнику, расскажет о своих идеях, о своем отношении к вам. А может и вообще пойдет увольнятся и все выскажет уже большому боссу. А если человек попадется устремленным, то увольняться пойдете вы, а он сядет на ваше место.
Я же расшифровал, какая именно часть ответственности приходится на подчинённого, а какая — на начальника. Начальник отвечает за принятое решение перед своим начальством. Подчинённый же отвечает за реализацию идеи перед самим начальником.
Иначе говоря, нормальный начальник никогда не «сдаст» подчинённого своему собственному начальству в духе «у нас не заработало, потому что имярек такой-сякой придумал хреновую идею» — потому что он сам принял решение и все шишки заранее взял на себя. Но при этом никто не снимает с подчинённого ответственность за эту идею перед его начальником и перед коллегами (в том числе и будущими разработчиками на проекте), которым тоже придётся с этой идеей потом жить.
Иначе говоря, нормальный начальник никогда не «сдаст» подчинённого своему собственному начальству в духе «у нас не заработало, потому что имярек такой-сякой придумал хреновую идею» — потому что он сам принял решение и все шишки заранее взял на себя. Но при этом никто не снимает с подчинённого ответственность за эту идею перед его начальником и перед коллегами (в том числе и будущими разработчиками на проекте), которым тоже придётся с этой идеей потом жить.
Мы просто не поняли друг друга. Простите. Если эта идея выходит за рамки области принятия решений подчиненного, то все риски берет на себя командование. Хотите, чтобы он нес ответственность перед товарищами — повышайте его до соответствующей должности. А если же входит в область принятия решений, то тут вы во всем правы. Да. За исключением того, что риски заранее обговариваются, т.е. подчиненный должен понимать, что его «гениальная» идея не стоит этих рисков. Вот и все, тогда все довольны. Ведь зачастую, подчиненный не видит всей картины, а после отвержения его «гениальной» мысли, вы в его глазах так и останетесь «самодуром».
Пример из жизни: интервьюер задаёт кандидату вопрос на тему работы с локами. Кандидат сразу даёт правильный ответ, интервьюер несёт полную чушь. Я (как shadow) на это смотрю с изумлением. Ну да ладно, разобрались.
Второй вопрос: развернуть строку (это было лет 10 назад, тогда эта задача не была ещё так заезжена). Кандидат (с пятилетним типа опытом работы на Java) минут пять пытается вспомнить какой функцией можно изменить букву в java.lang.String. В конце-концов, после кучи намёков интервьюер прямым текстом предлагает скопировать строку в массив. После чего ещё минут десять длятся попытки таки получить развёрнутую строку. Безуспешные.
Ваши действия? Всё ещё бежите в HR-отдел?
Второй вопрос: развернуть строку (это было лет 10 назад, тогда эта задача не была ещё так заезжена). Кандидат (с пятилетним типа опытом работы на Java) минут пять пытается вспомнить какой функцией можно изменить букву в java.lang.String. В конце-концов, после кучи намёков интервьюер прямым текстом предлагает скопировать строку в массив. После чего ещё минут десять длятся попытки таки получить развёрнутую строку. Безуспешные.
Ваши действия? Всё ещё бежите в HR-отдел?
Если я что-то вспомнить не могу — я предлагаю сделать в лоб либо свести к известной задаче. Потом можно и гугл напрячь и книжку поштудировать, если помнить что где примерно есть. Это с точки зрения собеседуемого. А с точки зрения собеседующего, мне вот в школе привили: если ты понимаешь физический смысл явления, мы можешь привести пример в окружающем мире: очередь — она и в любом магазине очередь; стек — стопку бумаги перекладываешь, вот тебе и стек; пул воркеров (или просто пул потоков) — электронная очередь с несколькими окнами обслуживания. Я, к примеру, плохо структуры данных знаю, но есть же какой-то базис, который нужно знать и понимать.
Это как отдать машину на ремонт механику, который толком не понимает что где и как, но где-то чуйка, где-то методом тыка — бац и получилось. А когда и не всё так радужно. Со своей машиной так можно повозиться — тут только ты виноват (этот как те люди, которые для себя что-то пишут), но когда появляется ответственность перед другими — это недопустимо.
Это как отдать машину на ремонт механику, который толком не понимает что где и как, но где-то чуйка, где-то методом тыка — бац и получилось. А когда и не всё так радужно. Со своей машиной так можно повозиться — тут только ты виноват (этот как те люди, которые для себя что-то пишут), но когда появляется ответственность перед другими — это недопустимо.
Если я что-то вспомнить не могу — я предлагаю сделать в лоб либо свести к известной задаче.Похоже вы не поняли всей глубины ужаса (возможно не работали с Java'ой). Строки в Java неизменяемы. В принципе. Для того, чтобы их создавать/менять (вернее создавать новую строку с изменённым содержимым) есть StringBuffer и StringBuilder, но они, разумеется, не могут изменить строку, они порождают новую. Про эту дихотомию есть ажно статья в Википедии и куча фреймворков построены на этом разделении (не конктретно на строку и StringBuffer/StringBuilder, а на идею хранения данных в виде неизменяемых объектов). И, понятно, если человек с как бы вроде как пятилетним опытом работы этого не знает (а если про это знать то сама идея «вспомнить» каким методом меняется буква в строке выглядит дикостью), то возникает вопрос: а чем, собственно, всё это время он занимался? Как выяснилось из собеседования — тестированием. Была попытка скромно и незаметно выдать свои пять лет опыта работы тестировщиком за работу программистом. А это, увы и ах, разные вещи. Причём они разные от слова «совсем».
Это как отдать машину на ремонт механику, который толком не понимает что где и как, но где-то чуйка, где-то методом тыка — бац и получилось.Нет, это как если бы автомеханик попытался устроиться работать конструктором. Ты можешь прекрасно разбираться в тонкостях уже существующих машин и двигателей, но из этого вовсе не значит, что ты сможешь создать с нуля свою. Для конструктора нужны совсем другие умения, чем для работы автомехаником.
Похоже вы не поняли всей глубины ужаса (возможно не работали с Java'ой). Строки в Java неизменяемы.На мой взгляд, интервьюер не правильно пытался проверить знания о неизменяемости строк. Он дал задачу — написать алгоритм для инвертирования строки. Это сделать можно. Да, будет создан новый экземпляр строки. Но вопроса об этом и близко не было. Только телепат из такой задачи мог бы понять, что его спрашивают о неизменяемости строк.
Интервьюер вообще не пытался проверять как-то отдельно эти знания. Ожидалось увидеть код, разворачивающий строку, а не что-то ещё. На обсуждение же неизменяемости строк более нескольких секунд тратить никто вообще не собирался. Ожидалось замечание типа «да, строки неизменяемы, а это значит, что мы либо должны принимать массив, либо создавать новую строку...» — и дальше уже, собственно, сам алгоритм. Всё. Причём тут телепатия?
Вы же не будете проверять — умеет ли маляр одевать щётку на ручку? Дадите ему ведро краски и попросите покрасить забор, А если он в результате не дойдёт до макания щётки в ведро — то что ж с ним делать-то?
Вы же не будете проверять — умеет ли маляр одевать щётку на ручку? Дадите ему ведро краски и попросите покрасить забор, А если он в результате не дойдёт до макания щётки в ведро — то что ж с ним делать-то?
А, собственно, что этим вопросом пытались проверить?
Разворачивать строку банальным разворотом последовательности char-ов в общем случае неверно, эдак мы все суррогатные пары поубиваем.
Разворачивать строку банальным разворотом последовательности char-ов в общем случае неверно, эдак мы все суррогатные пары поубиваем.
Можно и по кодпоинтам развернуть — не велика наука.
После кодпоинтов пойдут всякие комбинируемые символы и разные другие чудеса. Из одной этой задачи можно много чего вытащить. Но первое, что хочется увидеть — это, чёрт побери, алгоритм, который разворачивает строку в массиве.
Вы не поверите, но как минимум ¾ кандидатов этого сделать неспособны.
P.S. Только не нужно из этого делать вывод, что если вы на это способны, то вы входите в «Top 25% самых крутых программистов». Нет, конечно. Просто хорошо знающие своё дело программисты, когда нужно устроится на работу, проходят интервью в одном-двух, от силы трёх, местах, получают предложение и начинают работать. А вот людям, которые программировать не умеют от слова совсем могут от слова «совсем» приходится иногда сходить в сотню мест, пока они наконец «просочатся через фильтр» и куда-то устроятся. Потому среди кандидатов идиотов гораздо больше, чем «в среднем по больнице». Кстати это полезно учитывать и когда вы устраиваетесь на работу: не обижайтесь на интервьюеров, когда они задают вам совсем-совсем элементарные вопросы — поверьте, над вами не издеваются! Если бы эти вопросы не позволяли бы отсеять внушительную часть кандидатов — вам бы их не задавали.
Вы не поверите, но как минимум ¾ кандидатов этого сделать неспособны.
P.S. Только не нужно из этого делать вывод, что если вы на это способны, то вы входите в «Top 25% самых крутых программистов». Нет, конечно. Просто хорошо знающие своё дело программисты, когда нужно устроится на работу, проходят интервью в одном-двух, от силы трёх, местах, получают предложение и начинают работать. А вот людям, которые программировать не умеют от слова совсем могут от слова «совсем» приходится иногда сходить в сотню мест, пока они наконец «просочатся через фильтр» и куда-то устроятся. Потому среди кандидатов идиотов гораздо больше, чем «в среднем по больнице». Кстати это полезно учитывать и когда вы устраиваетесь на работу: не обижайтесь на интервьюеров, когда они задают вам совсем-совсем элементарные вопросы — поверьте, над вами не издеваются! Если бы эти вопросы не позволяли бы отсеять внушительную часть кандидатов — вам бы их не задавали.
Я не знаю что конкретно интервьюер хотел обсудить. Обычно следующим вопросом бывает либо как раз обсуждение суррогатов, особых символов и флагов, либо, наоборот, просят развернуть уже не строку целиком, а слова в строке и обсуждают как это всё немного порефакторить. В зависимости от того, какие слова будет кандидат произносить и вопросы задавать. Но тут всё рассыпалось на первом этапе — на попытке написать функцию в десять строк фломастером на доске.
P.S. Надо понимать, что написать десять строк на интервью гораздо, гораздо сложнее, чем написать десять строк в спокойной обстановке и на это нужно делать скидку, но всё-таки человек, устраивающийся на работу программистом, должен быть способен совершить подобный подвиг.
P.S. Надо понимать, что написать десять строк на интервью гораздо, гораздо сложнее, чем написать десять строк в спокойной обстановке и на это нужно делать скидку, но всё-таки человек, устраивающийся на работу программистом, должен быть способен совершить подобный подвиг.
> Вот вы пришли к техническому специалисту, потенциальному будущему начальнику
> или наставнику, и в первый час общения с ним доказали ему, что он ошибается в том,
> в чём, как ему казалось, он разбирается. Как вы считаете, у человека возникнет
> желание с вами работать?
Программист, который закрывает глаза на ляпы своих коллег, чтобы их не обидеть, создаёт технический долг.
Это очень большой минус ему как кандидату.
Ну и менеджер, который одобряет закрывание глаз на замеченные ошибки — соберёт ли он хорошую команду?
> или наставнику, и в первый час общения с ним доказали ему, что он ошибается в том,
> в чём, как ему казалось, он разбирается. Как вы считаете, у человека возникнет
> желание с вами работать?
Программист, который закрывает глаза на ляпы своих коллег, чтобы их не обидеть, создаёт технический долг.
Это очень большой минус ему как кандидату.
Ну и менеджер, который одобряет закрывание глаз на замеченные ошибки — соберёт ли он хорошую команду?
По собственному опыту могу сказать: очень нравится когда человек хорошо оценивает свои знания и очень не нравится, когда соискатели в своем резюме пытаются указать, что являются специалистами во всех технологиях о которых слышали.
Список технологий из резюме студента часто выглядит так: «MySQL, Postgres, Oracle, MsSql, css, html, javascript, php, C/C++, Rust, Golang, XML, Pascal, Delphi, Python, Java ...»
Резюме профессионала часто содержит в себе самый минимум того в чем он действительно разбирается. При этом о многих побочных (для него) технологиях он имеет хорошие средние знания.
Если человек заявляет, что он специалист в технологии X, а сам путается в основах — это крупный минус.
Если человек говорит, что он «с этой технологией не очень много работал», но выдает уверенные знания по теме с ньюансами, то это жирный плюс. Даже если он чего-то про это не знает — то это не будет минусом — он же не заявлял себя специалистом в этой технолгии.
Список технологий из резюме студента часто выглядит так: «MySQL, Postgres, Oracle, MsSql, css, html, javascript, php, C/C++, Rust, Golang, XML, Pascal, Delphi, Python, Java ...»
Резюме профессионала часто содержит в себе самый минимум того в чем он действительно разбирается. При этом о многих побочных (для него) технологиях он имеет хорошие средние знания.
Если человек заявляет, что он специалист в технологии X, а сам путается в основах — это крупный минус.
Если человек говорит, что он «с этой технологией не очень много работал», но выдает уверенные знания по теме с ньюансами, то это жирный плюс. Даже если он чего-то про это не знает — то это не будет минусом — он же не заявлял себя специалистом в этой технолгии.
меня в резюме смущает запись C/C++: как показывает практика, хорошие С-программисты пишут плохой код на С++, обратное тоже, отчасти, верно, но не на 100%.
В 90% случаев такая запись означает «прослушал курс С/С++ в университете». Тому кто хоть сколько-то работал с любым из них в голову не придет эти языки так сгруппировать.
Например моя повседневная работа и бывший хобби-язык (сейчас сменился на Haskell) связаны с С++. При этом я знаю так же и слой различий под чистый С, т.к. в свободное время иногда отвечаю вопросы на StackOverflow, которые больше любят тэгировать под С — и там в комментариях приходилось участвовать в разного рода каверзных дискуссиях на эту тему. И в самом начале я кодил на С++ как на С.
Я думаю, я бы подошел к программированию на чистом С, как на зверски урезанном Хаскелл. Мне не известны минусы этой идеи.
Я думаю, я бы подошел к программированию на чистом С, как на зверски урезанном Хаскелл. Мне не известны минусы этой идеи.
Меня тоже смущает — я специально в примере написал именно так.
Полагаю, дело в том, что С++ — понятие растяжимое. Формально, процедурное программирование в стиле С — тоже С++. Лично меня раздражает, когда под программированием на плюсах подразумевают только высокоуровневое ООП.
Как-то чуть не устроился админом в сеть кафешек. На собеседовании меня спросили, какая сейчас самая мощная видеокарта (мой ответ был устаревшим примерно месяца на три-четыре, потому что я не мониторю железячные новинки). С чувством собственного превосходства и снисхождения мне рассказали, какая карта была самой крутой. На мой вопрос, зачем в кафе игровая видеокарта и, что я могу подобрать оптимальную для задач конфигурацию, ответа я не получил.
Меня вот например в принципе раздражают собеседования формата вопрос-ответ, ибо собеседование процесс двусторонний, а такой формат просто убивает возможность понять, с кем придется работать и не позволяет ответить на главный вопрос, после собеседования — не мудак ли мой будущий начальник.
На текущем месте, перед собеседованием сделал тестовое задание, а собеседование больше походило на дружескую беседу программистов о своем опыте и взглядах на штуки типа ооп, паттерны и прочие best practices, по ходу решил несколько задачек по алгоритмам и то не все до конца и мы обсудили какие еще есть варианты решения и написал на бумажке 20 строк кода. Ни одного вопроса по синтаксическим конструкциям, деталям реализации какой-нибудь фигни и прикладным технологиям не было, ибо правильно написали выше, любую технологию изучить не проблема, особенно если коллеги с ней знакомы.
На текущем месте, перед собеседованием сделал тестовое задание, а собеседование больше походило на дружескую беседу программистов о своем опыте и взглядах на штуки типа ооп, паттерны и прочие best practices, по ходу решил несколько задачек по алгоритмам и то не все до конца и мы обсудили какие еще есть варианты решения и написал на бумажке 20 строк кода. Ни одного вопроса по синтаксическим конструкциям, деталям реализации какой-нибудь фигни и прикладным технологиям не было, ибо правильно написали выше, любую технологию изучить не проблема, особенно если коллеги с ней знакомы.
Естественно, универсальных способов построения команды нет. Для кого-то нормальный начальник («нему*ак» в ваших терминах) — это тот, с которым можно потрындеть про шутки на тему ООП и паттернов, а для кого-то — тот, кто всё под контролем держит и умеет нормально работу команды организовать. Далеко не всегда эти вещи совпадают.
UFO just landed and posted this here
Запасаемся попкорном.
«расскажите, как устроена хэш-карта»
Это hashmap так перевели? )
Это hashmap так перевели? )
Похоже на то.
У меня есть похожий вопрос про C++: «расскажите про то, как в C++ устроен std::map»…
Если кандидат честно заявляет, что про C/C++ он написал в резюме, потому что знал, что у нас программируют на C++, а так, в общем, он прослушал курс С/С++ в университете и всё, то вопрос немедленно меняется: «расскажите про то, как в C++ мог бы быть устроен std::map при условии, что стандартная библиотека также содержит тип std::unordered_map?»…
Хороший кандидат может много рассказать полезного/интересного даже притом, что он ничего не знает о С++, но знает о том, что его создатели были весьма озабочены эффективностью кода. Причём, что парадоксально, я предпочту взять на место C++ программиста такого кандидата скорее, чем кандидата, который помнит наизусть все сложности всех методов std::map'а (да-да — в стандарте это описано), но не понимает — почему они такие (в стандарте C++ этого нет, есть немного в стенограммах обсуждений стандарта).
У меня есть похожий вопрос про C++: «расскажите про то, как в C++ устроен std::map»…
Если кандидат честно заявляет, что про C/C++ он написал в резюме, потому что знал, что у нас программируют на C++, а так, в общем, он прослушал курс С/С++ в университете и всё, то вопрос немедленно меняется: «расскажите про то, как в C++ мог бы быть устроен std::map при условии, что стандартная библиотека также содержит тип std::unordered_map?»…
Хороший кандидат может много рассказать полезного/интересного даже притом, что он ничего не знает о С++, но знает о том, что его создатели были весьма озабочены эффективностью кода. Причём, что парадоксально, я предпочту взять на место C++ программиста такого кандидата скорее, чем кандидата, который помнит наизусть все сложности всех методов std::map'а (да-да — в стандарте это описано), но не понимает — почему они такие (в стандарте C++ этого нет, есть немного в стенограммах обсуждений стандарта).
Тоже запнулся на этом месте. «Хэш-таблица» вроде принято по-русски. Поискал в гугле «хэш-карта», первый результат — страница Вики «Хэш-таблица» :)
Я не программист, но меня как соискателя отпугнули только один раз. Интервьюер был полный мудак. Когда об этом тебе говорит сотрудник отдела кадров перед тем как передать тебя на техническое интервью — такое было только один раз.
UFO just landed and posted this here
Напрягают собеседования в большие конторы, где интервьюирующие считают себя асами, а соискателя, простите, говном. Особенно это любят ребята из Яндекса. Ощущение складывается, что они не нового сотрудника ищут, а просто развлекаются и собственное ЧСВ тешат.
Скорее всего это про московский офис, работает знакомая, с которой в институте учились, судя по тому, как изменились ее манеры, там такая идеология в компании. Ну и рекомендую пропускать мимо ушей и быть готовым к тщеславным людям, громкое имя всегда подобный контенгент привлекает. И не забывайте самое главное, что работать там — это быть всегда вторым после Google.
Такое случается очень много где. На счет Яндекса не знаю, я с ребатми от туда общался долго и с удовольствием. Причем с большой пользой для себя и не один раз =) Собеседование в Яндекс вообще удобно использоваться для того что бы получить множество подсказок, что полезно выучить для полее глубокого развития в своей области.
Другое дело, что завастую абсолютно непонятно зачем нужен такой уровень знаний на указанной должности. Лично я для себя решил что просто слабо представляю, чем они там занимаются.
Другое дело, что завастую абсолютно непонятно зачем нужен такой уровень знаний на указанной должности. Лично я для себя решил что просто слабо представляю, чем они там занимаются.
Уровень знаний адекватный требуется, учитывая их масштабы задач. Я согласен с той точкой зрения, что даже сисадмин должен понимать что-такое опкоды, системные вызовы, kernel threads и мало-мальски уметь что-нибудь состряпать на C при необходимости. Тут не об этом, о том, что у них с ЧСВ какие-то проблемы, считают почему-то, что за пределами Яндекса жизни нет, и надпись «Яндекс» в профиле дает индульгенцию хамить всем подряд.
Как раз сисадмин очень хорошо должен понимать, что такое системные вызовы, он с ними работает, другой вопрос, должен ли это понимать дежурный администратор, который парсит логи и говорит какой сервис сломался.
Ну а ЧСВ — от людей зависит. Я с этим сталкивался, когда решал задачки на стажера С++, а вот когда с инженерами общался — проблем не было.
Ну а ЧСВ — от людей зависит. Я с этим сталкивался, когда решал задачки на стажера С++, а вот когда с инженерами общался — проблем не было.
Ну так про ЧСВ и речь, и конечно зависит от людей. В крупных компаниях, а особенно у таких эстрадных звезд как Яндекс, процент тщеславных и высокомерных на порядок выше, ну и атмосфера и окружение меняют самомнение.
«дежурный администратор, который парсит логи и говорит какой сервис сломался» — это как? а как же системы мониторинга-оповещения???
Было у меня собеседование в Яндекс 1.5 месяца назад. 5 видео интервью из разных городов. Никто асами себя не считал, меня никто с говном не смешивал. Со всеми отлично пообщались… может мне повезло…
UFO just landed and posted this here
Я и работал в крупных конторах и соответсвенно на собесах был не раз. Так вот, это скорее вы на себя как-то не правильно переносите. С говном никого не машают, задают в основном стандартные вопросы, но из области базы + да, бывают довольно сложные алгоритмические задачм, и странно, что они оказываются полной неожиданностью для соискателей. Почему-то в народе бытует такой наивный подход, что достаточно почитать доки по библиотекам, там или стековерфлоу, и все, ты программист. Как программист может называться оным без базовых знаний алгоритмов и структур данных и problem solving skills?
Тут похоже как повезет, года 4 назад тоже собеседовался к ним (московский офис), хоть и не взяли в итоге, но ничего плохого сказать не могу, оплатили перелет из другой страны, на собеседовании (второе техническое после скайпа) около 2х часов общались на интересные темы и технологии, меня собеседовало 3 специалиста, все адекватные, вежливые и оставили приятное впечатление, так что похоже сильно зависит от отдела куда собеседоваться, гадюшники бывают везде, но я бы не делал такое заключение о всей компании на основе единичного опыта.
На самом деле большой вопрос, надо ли разработчику fe знать стек TCP/IP. Если рассматривать сферической IT в вакууме, то конечно всем надо знать все и чем больше знаешь в любой области — тем лучше. Но на самом деле, как разработчик fe должнет учитывать в своей работе ограничение MTU на последней миле? В общем виде, что такое, ip адрес, знания, думаю есть у всех, а более глубокие — это уже не его область ответсвенности. И к тому же такой подход — предпосылка к созданию вакансий: Инженер программист со знианием C/C++, php, ruby, java, js, mysql, postresql, oracle, mongodb, html5, css3, less, sass, tcp/ip, cisco, hp, junifer… ПУЭ.
Если под «фронтэндом» вы понимаете «программирование браузера», то пожалуй, хотя даже там это важно. Например, чтобы не городить велосипедный транспорт поверх HTTP/REST там, где можно перейти на более низкий уровень, или чтобы понимать, как работает TLS и сертификаты. А если рассматривать понятие «фронтэнд» как разработку клиентского ПО вообще, то там такое понимание незаменимо.
По-хорошему, любой разработчик приложений, которые что-то передают/принимают по сети, должен хотя бы примерно представлять себе, как происходит весь процесс передачи данных на всех уровнях, и к кому бежать, если что-то пошло не так. Область ответственности быстро расширяется, когда что-то не работает, и человек не может не то что решить проблему, а даже диагностировать её, чтобы определить эту самую область ответственности.
По-хорошему, любой разработчик приложений, которые что-то передают/принимают по сети, должен хотя бы примерно представлять себе, как происходит весь процесс передачи данных на всех уровнях, и к кому бежать, если что-то пошло не так. Область ответственности быстро расширяется, когда что-то не работает, и человек не может не то что решить проблему, а даже диагностировать её, чтобы определить эту самую область ответственности.
Но на самом деле, как разработчик fe должнет учитывать в своей работе ограничение MTU на последней миле?Очень просто: он должен понимать, что современные сервера настраиваются на initial congestion window в 10 сегментов, а более старые — на 2-4 сегмента. А это значит, что если ты хочешь получить хороший, отзывчивый, сайт, то тебе нужно сделать так, чтобы пользователь что-то увидел получив первые 14600 байт (а то и 2920 байт).
Любой код это алгоритм
О нет. И это хорошо.
По поводу протоколов TCP/IP и других подобных вопросов. Года 3-4 назад я мог в сетевом дампе разобрать начало IP-кадра, узнать значения флагов, и предположить, какие данные придут дальше. Сейчас я практически ничего из этого не помню, просто потому что этим не занимаюсь. Основы основами, но если человек хороший фронтенд/бэкенд разработчик, то совсем необязательно, что он знает тонкости смежных областей.
Вы бы сами для начала своим же статьям следовали.
Извините, конечно, но конкретно в этой компании процесс прохождения резюме построен просто отвратно: вначале hr не прочитал мое резюме и пригласил на собеседование, затем, «технический специалист» — тимлид тоже не удосужился прочитать резюме, да еще и нахамил.
Извините, конечно, но конкретно в этой компании процесс прохождения резюме построен просто отвратно: вначале hr не прочитал мое резюме и пригласил на собеседование, затем, «технический специалист» — тимлид тоже не удосужился прочитать резюме, да еще и нахамил.
Мне очень жаль, если у вас остались плохие впечатления о нашем собеседовании. У нас достаточно большая компания, много подразделений, куда набор идёт по совершенно разным критериям. Я отвечаю лишь за набор людей в свои команды, поэтому не в курсе всех происходящих интервью. На какую именно вакансию вас пригласили, и чем обидели?
Я не знаю, на какую вакансию меня пригласили. Мне это не сообщили, а я понадеялся, раз люди звонят, значит, прочитали резюме и им понравилось то, что они прочитали (можно еще статью дополнить: не говорят, на какую вакансию, и не говорят какие обязанности).
По факту выяснилось, что ни резюме ни читали, ну и почти что все антипаттерны из вашей статьи на этом собеседовании со стороны вашей компании были применены. И, между прочим, это было в екатеринбурге, так, что, скорее всего, прямо в вашем офисе, и я не уверен, что это были не вы.
По факту выяснилось, что ни резюме ни читали, ну и почти что все антипаттерны из вашей статьи на этом собеседовании со стороны вашей компании были применены. И, между прочим, это было в екатеринбурге, так, что, скорее всего, прямо в вашем офисе, и я не уверен, что это были не вы.
Нет, это был не я. Думаю, меня при желании можно опознать по аватарке: о)
Если HR не сообщил вам, на какую вакансию вас приглашают, это, конечно, не очень хорошо с его стороны. Но вообще совет лично от меня как от человека, много походившего по собеседованиям — следует помнить, что HRы далеко не всегда разбираются в тонкостях технологий и ориентируются в основном по ключевым словам в резюме. Нет смысла судить их за это, они не технические специалисты. Поэтому лучше не идти на собеседование вслепую, а всё же самостоятельно уточнять такие вещи, как вакансия и список требований, заранее. Не стоит надеяться на то, что ваше резюме правильно соотнесли с вакансией и догадались, какую именно должность вы ищете, особенно если в резюме написано «всё умею, всё могу»: о)
Если HR не сообщил вам, на какую вакансию вас приглашают, это, конечно, не очень хорошо с его стороны. Но вообще совет лично от меня как от человека, много походившего по собеседованиям — следует помнить, что HRы далеко не всегда разбираются в тонкостях технологий и ориентируются в основном по ключевым словам в резюме. Нет смысла судить их за это, они не технические специалисты. Поэтому лучше не идти на собеседование вслепую, а всё же самостоятельно уточнять такие вещи, как вакансия и список требований, заранее. Не стоит надеяться на то, что ваше резюме правильно соотнесли с вакансией и догадались, какую именно должность вы ищете, особенно если в резюме написано «всё умею, всё могу»: о)
Проблема заключается в том, что вакансии составляют тоже не очень разбирающиеся, и требования часто противоречивые и не соответствуют реальности.
Как раз-таки к тому, что мое резюме не соотнесли с вакансией я не жалуюсь. А жалуюсь я на то, что то, что происходило во время интервью прямо противоречит статье в блоге компании за вашим авторством.
У вас так принято — смеяться над резюме соискателей?
Как раз-таки к тому, что мое резюме не соотнесли с вакансией я не жалуюсь. А жалуюсь я на то, что то, что происходило во время интервью прямо противоречит статье в блоге компании за вашим авторством.
У вас так принято — смеяться над резюме соискателей?
Я не смеялся над вашим резюме, как раз наоборот, отметил, что спектр указанных там умений достаточно широкий, его сложно подогнать под какой-то ограниченный набор вакансий, и такие ошибки неизбежны. С таким резюме вам неизбежно придётся самостоятельно отсеивать все поступающие предложения, не надеясь на то, что резюме правильно истолкуют HRы, чтобы не погрязнуть в бесконечных собеседованиях на самые разнообразные вакансии.
Повторюсь. Я не жалуюсь на то, что не подошел для вакансии, я думаю, что это нормально — подходить не везде.
А вот ваша статья, размещенная в блоге компании явно не соответствует принятой в вашей же компании практике:
Вот например, 1. «Какое ещё техническое собеседование?». Со мной не проводили технического собеседования.
Пункт 2. «Ну и чем вы там занимались в этом своём…». Технического специалиста явно оторвали от очень важных дел, и всем своим видом он показал, что тратит напрасно свое время.
Пункт 5. «Неправильно. Дальше.». Выслушав мой рассказ о том, где я работал и что делал (что и так было написано в резюме), ваш технический специалист просто выгнал меня, даже не обмолвившись почему я, в итоге, не подхожу.
А вот ваша статья, размещенная в блоге компании явно не соответствует принятой в вашей же компании практике:
Вот например, 1. «Какое ещё техническое собеседование?». Со мной не проводили технического собеседования.
Пункт 2. «Ну и чем вы там занимались в этом своём…». Технического специалиста явно оторвали от очень важных дел, и всем своим видом он показал, что тратит напрасно свое время.
Пункт 5. «Неправильно. Дальше.». Выслушав мой рассказ о том, где я работал и что делал (что и так было написано в резюме), ваш технический специалист просто выгнал меня, даже не обмолвившись почему я, в итоге, не подхожу.
В статье речь идёт не об отсутствии технического собеседования, а о той ситуации, когда кандидата готовы принять без технического собеседования. Как я понимаю, оффер вам не делали, так что это не ваш случай. Рассказать своими словами о рабочем опыте — вполне нормальная просьба интервьюера, даже если всё подробно расписано в резюме, ведь на работу принимают не резюме, а живого человека.
«Выгнал» — сильное слово, это в моём понимании когда вам говорят «пшёл вон, свободен». Не могу себе представить что-то подобное из уст моих коллег. По окончании собеседования никто вам не скажет «вы нам не подходите, потому что...» — обычно интервьюер просто заканчивает собеседование тогда, когда считает нужным, и по его результатам составляет внутренний отзыв, который, естественно, никто и нигде вам не предоставит. При наличии положительного отзыва вам могут сделать оффер. Это абсолютно нормальная процедура проведения собеседования.
«Выгнал» — сильное слово, это в моём понимании когда вам говорят «пшёл вон, свободен». Не могу себе представить что-то подобное из уст моих коллег. По окончании собеседования никто вам не скажет «вы нам не подходите, потому что...» — обычно интервьюер просто заканчивает собеседование тогда, когда считает нужным, и по его результатам составляет внутренний отзыв, который, естественно, никто и нигде вам не предоставит. При наличии положительного отзыва вам могут сделать оффер. Это абсолютно нормальная процедура проведения собеседования.
Возможно, вы это имели в виду, но написали другое. В моем случае все ровно так как вы написали, но с противоположным знаком. «Мне не задали ни одного вопроса, чтобы проверить, что я действительно знаю своё дело.». Не могу утверждать наверняка, но, возможно, если бы такие вопросы задали, это бы повлияло на итог. А так получается, по каким-то формальным признакам отбраковка, как будто бы на работу принимают не живого человека, а резюме.
Вы искусственно критерии сужаете. Вроде как, раз «пшел вон, свободен» не сказали, значит, все норм. Пренебрежение можно выразить не только матом и руганью. А, например, посмеявшись над моими словами (это ваш коллега себе позволил). Тут вообще никаких слов нет, а все равно неприятно. До внутреннего отзыва дело не дошло (может быть и дошло, раз у вас такое предвзятое обо мне мнение), меня выпроводили сразу же по окончании.
Что касается моего резюме, то что делать, если я действительно все, что у меня там указано, продуктивно применял, умею с этим работать, и могу сделать с места в карьер то, чего еще не делал? Строчка «все умею, все могу», ироничная, разумеется, но и во многом правдива.
Вы искусственно критерии сужаете. Вроде как, раз «пшел вон, свободен» не сказали, значит, все норм. Пренебрежение можно выразить не только матом и руганью. А, например, посмеявшись над моими словами (это ваш коллега себе позволил). Тут вообще никаких слов нет, а все равно неприятно. До внутреннего отзыва дело не дошло (может быть и дошло, раз у вас такое предвзятое обо мне мнение), меня выпроводили сразу же по окончании.
Что касается моего резюме, то что делать, если я действительно все, что у меня там указано, продуктивно применял, умею с этим работать, и могу сделать с места в карьер то, чего еще не делал? Строчка «все умею, все могу», ироничная, разумеется, но и во многом правдива.
На самом деле чтение резюме — это бич современных HRов. У меня сложилось ощущение, что большинство этого не делают принципиально. К примеру у меня было два-три месяца открыто на hh резюме дежурного инженера. Помимо включенного пункта «Посменный график», я специально написал в резюме что учусь в аспирантуре и ищу исключительно посменную работу для совмещения. С частотой 2-3 раза в неделю мне приходили приглашения на полный день, причем один раз даже на вакансию Java Dev, хотя я явы не знаю и никогда ничего про нее не писал.
Так же очень расстраивает некорректное заполнение форм на сайте, к примеру на том же hh очень часто в вакансии написано что она посменная, а в соответсвующем поле «Полный день», или «Гибкий график», и либо приходится пересматривать вообще все вакансии, либо фильтр осеивает две трети нужных.
Так же очень расстраивает некорректное заполнение форм на сайте, к примеру на том же hh очень часто в вакансии написано что она посменная, а в соответсвующем поле «Полный день», или «Гибкий график», и либо приходится пересматривать вообще все вакансии, либо фильтр осеивает две трети нужных.
UFO just landed and posted this here
На самом деле чтение резюме — это бич современных HRов.К сожалению это бич вообще всего IT-рынка в России.
У меня сложилось ощущение, что большинство этого не делают принципиально.Вы почти правы. Проблема в том, что в России очень плохо пишут резюме и, как следствие, на них обращают очень мало внимания при рассмотрении. Да собственно вы сами об этом пишите:
Так же очень расстраивает некорректное заполнение форм на сайте, к примеру на том же hh очень часто в вакансии написано что она посменная, а в соответсвующем поле «Полный день», или «Гибкий график», и либо приходится пересматривать вообще все вакансии, либо фильтр осеивает две трети нужных.У HR'ов та же история — если они будут отсеивать людей, которые по формально заполненным признакам, им не подходят, то они пропустят две трети хороших кандидатов.
У меня был не большой опыт собеседований. Но безусловно смущают стандартные вопросы про люки, почерпнутые из паблика «Все для HR» и «Это интересно».
А еще я бы добавил, что соискателя на собеседовании может смутить излишняя суровость интервьюера. Собеседующий должен показать, что помимо интересных задач, карьерного роста и т.д. в колликтиве хороший микроклимат. В свое время, когда я пришел на собеседование на должность QA (не обладая большими знаниями, но стремясь их получить) меня спросили знаю ли я что такой bash, то я вместо того чтобы ответить, что это командная оболочка, переспросил: «Это цитатник рунета?», ребята посмеялись. Тон беседы был задан. В итоге меня подкупила простота общения с начальством отдела. Начальник и его зам серьезные вопросы могли разбавить шуткой, это как-то настраивает на хороший лад и демонстрировать свои знания/умения становится проще.
А еще я бы добавил, что соискателя на собеседовании может смутить излишняя суровость интервьюера. Собеседующий должен показать, что помимо интересных задач, карьерного роста и т.д. в колликтиве хороший микроклимат. В свое время, когда я пришел на собеседование на должность QA (не обладая большими знаниями, но стремясь их получить) меня спросили знаю ли я что такой bash, то я вместо того чтобы ответить, что это командная оболочка, переспросил: «Это цитатник рунета?», ребята посмеялись. Тон беседы был задан. В итоге меня подкупила простота общения с начальством отдела. Начальник и его зам серьезные вопросы могли разбавить шуткой, это как-то настраивает на хороший лад и демонстрировать свои знания/умения становится проще.
Я действительно иногда слышу на собеседованиях слова «я не разбираюсь в этой вашей теории, зато у меня большой опыт, и вообще я просто сажусь и делаю на автомате», и меня, честно говоря, немного пугают такие заявления, равно как и сравнение программирования с «ездой на велосипеде».
Мне всегда казалось, что с опытом разработчик должен более глубоко погружаться в основы того, что он делает, понимать, почему он это делает именно так. Какие есть подходы к решению тех или иных задач, чем они хороши и плохи, каковы их ограничения. Ну и наращивать свой понятийный аппарат, который позволяет ему рассуждать о том, что он делает, а не штамповать типовые задачи на автомате.
Я считаю, что можно и знать теорию, и иметь хороший практический опыт. Отсутствие первого или второго — это вполне ликвидируемый недостаток. Поэтому я решительно не понимаю, когда незнание теории едва ли не с гордостью выдают за достоинство.
Мне всегда казалось, что с опытом разработчик должен более глубоко погружаться в основы того, что он делает, понимать, почему он это делает именно так. Какие есть подходы к решению тех или иных задач, чем они хороши и плохи, каковы их ограничения. Ну и наращивать свой понятийный аппарат, который позволяет ему рассуждать о том, что он делает, а не штамповать типовые задачи на автомате.
Я считаю, что можно и знать теорию, и иметь хороший практический опыт. Отсутствие первого или второго — это вполне ликвидируемый недостаток. Поэтому я решительно не понимаю, когда незнание теории едва ли не с гордостью выдают за достоинство.
Техническое собеседование — процесс доминирования человека со списком ответов над человеком без списка вопросов. ©
Sign up to leave a comment.
Техническое собеседование: пять способов отпугнуть соискателя / пять способов взбесить интервьюера