Это необязательно может быть конкретный код, это может быть детальное описание системы, ключевых проблем, путей их решения. Вы же не покажете просто мегатонны кода — вот тут все мое, разбирайтесь, что вас тут интересует? Интервьюверу делать нечего, как разбирать чужое решение в коде — ему надо видеть, что вы умеете решать проблему. Декомпозировать, подбирать технологии и инструменты. Отсюда вопросы вида «расскажите о самой сложной проблеме на предыдущем месте и как вы ее решали». Да, по коду можно увидеть «адекватно» ли человек работает — не будет ли у него течь память и тому подобное, но для этого достаточно небольших кусочков-примеров. Если говорить именно о разработке систем, здесь важнее, кмк, продемонстрировать умение решить проблему, а не код.
Если вы можете показать код проектов с предыдущей работы, а не только рассказать о них, вам очень сильно повезло. У меня такое впечатление, по крайней мере
Когда как. Иногда — да, приходится обходиться детальным описанием без кода, с тестовыми заданиями. С другой стороны, опять же, глядя на то, какие бури в стакане возникают при обсуждении стилей кода здесь (вида «где ставить скобки, допустима ли венгерская нотация» и т.п.), порой опасаешься, как сторонний человек будет воспринимать твой проект. Мало ли, ему ненавистен GNU style, скажем.
Но ведь это было возможным лишь тогда, когда соответствующие технологии достигли хоть какого-то разумного статуса готовности к продакшену, разве нет?
Да, но я не понимаю, к чему вы клоните. На всякий случай, говоря о новых технологиях я имел в виду новые для конкретного человека, а не отрасли.
Вопрос тогда в том, что я забыл у костра. И кто меня туда позвал, если я уже отказался от социальной жизни.
Так это шуточный пример — в любом случае, как-то ты социализируешься, не совсем же затворником живешь. Все равно хоть какие-то горизонтальные связи будут.
равно как и вопрос о том, что именно подразумевается под всестороннестью
Я употребил это слово в значении «не только профессиональные навыки».
Поэтому считать наличие своего существенного опенсорса (не для галочки, конечно, как вы привели пример выше) весомым плюсом, равно как его отсутствие считать не самым последним минусом, представляется разумным.
С одной стороны — да. С другой — в качестве примера — когда меня нанимали, в качестве личного проекта я показывал свою операционку; при этом она была моим личным закрытым проектом. Это тоже аргумент (хотя, конечно, вы можете сказать о критике, улучшениях на основе нее итд).
Технологию вы, возможно, смените (хотя я бы посмотрел, где и что вы на Go бы пописали в 2010-м году, или на Idris сегодня, завтра и в любой разумной перспективе, если вы там уже на нём не пишете).
В качестве примера — не в 2010, нет, позже, но у нас разные люди стали применять Java для написания одного из нестандартных компонентов системы с интеграцией в легаси код, другой человек — один из серверов на Go. Это все новые куски, с интеграцией. И они делали(ют) это в рабочее время.
Кому не надо — никаких вопросов, разговор не о них, у них таких проблем нет.
Так статья вроде как о «топ» разработчиках, что может предполагать и специализацию, а не мастеров на все руки, верно?
Ну, там не только про болячки говорилось — про «принесет ли счастье». Речь о том, что всесторонняя развитость многими желанна. Абстрактный простой пример полу-шутка: сидишь ты у костра со своими приятелями весь такой топ-перетоп-senior, а на гитаре играть не умеешь и рассказать тебе, кроме математических экскурсов, нечего. И толку от твоей топовости — минус бесконечность.
Делают. Хочешь изучить новый язык/платформу — пождалуйста, изучил за счет фирмы, написал и внедрил новый проект/часть существующего с использованием этой технологии — вот тебе и теория за счет фирмы и практика.
А, вы знаете, оценивают. И вопросы с примерами кода отпадают сами собой
Человек может больше отдаваться работе, чем личному проекту (сверх обычного рабочего времени), это нормально. Мне сейчас интереснее, например, поработать сверхурочно, чем пилить свои проекты.
Так едва ли получится вылезти за пределы своего рабочего круга задач. Ну и редких ништяков со стороны компании вроде обучения языкам/парадигмам/матану, не используемым в решаемых задачах.
Очень сильно зависит от конкретного места работы и проекта(ов), здесь сложно обсуждать в терминах вероятности.
Пишете вы какую-нибудь тырпрайз-унылость, условно, на Java, какие шансы у вас перелезть на работе в машинное обучение и хаскель?
А надо? Может быть, лучше в таком случае шагнуть на ступень выше в мире «тырпрайз»?
А так, за счёт вклада в опенсорс, у меня было меньше этапов перед устройством на работу.
Нет, ну это замечательно, спору нет. Только вряд ли можно считать, что человек, который форкнул проект на гитхабе, добавил свистелку и пулл реквест на фикс в две строки, имеет сто очков по профессионализму перед человеком, который разрабатывал закрытые системы, возможно, с ноля. Это я не в ваш адрес, а так, рассуждаю о «галочках».
В малой компании человек вынужден развиваться самостоятельно, вне рабочего времени. В крупной компании он предложит использовать новую технологию и предложить направить его на курсы/конференции по такой-то технологии. И будет он это делать за счет фирмы и в рабочее время. Ребята из первой вынуждены вкалывать в свое личное время, вот и вся дихотомия.
Даже здесь на Хабре постоянно проскакивают комментарии вида «в хорошем резюме обязательно будут открытые проекты», «добавьте свой GitHub, чтобы работодатель видел, чем вы занимаетесь». Иногда хочется спросить, мол orly кто-то всерьез будет оценивать человека, проработавшего пол-жизни на проприетарном бэкэнде по наличию/отсутствию опенсорс проектов/вкладов в них?
Такое ощущение, что автора каким-то образом «обидело» опенсорс сообщество. Хотя, судя по всему, у человека просто кризис среднего возраста.
Это единичный контр-аргумент к тренду — см. выше. Увязка, если судить по местным комментаторам, стопроцентная — «хороший разработчик должен иметь свои проекты и коммитить в оупенсорс». Автор же предлагает противоположный взгляд — человек может развиваться на рабочем месте, в рабочее время. Просто наниматели у всех разные и области работы тоже.
Про B-Tree рассказано мало, по верхам. Какое-нибудь АВЛ дерево тоже сбалансировано, и поиск в нем, с поправкой на кол-во дочерних узлов, происходит аналогично. Да почти в любом дереве так.
А вот почему применяется имеено Б-дерево (не только в постгре и вообще не только в реляционных БД)? Как выбирается размер узла, как он связан с размером блока, какова сложность поиска, сколько блочных операций ввода-вывода надо — это ключевые особенности B-Tree.
А ведь есть еще B+Tree.
Еще бы неплохо дополнить описанием альтернативного стандарта (не помню, кто производитель — вроде бы Sony) — там не было совместимости с аналоговыми записями, а цифровая запись производилась блоком наклонных вращающихся головок.
В журнале «Радио» было описание, помню.
Бессмысленный спор — нравится работать на одном месте — это хорошо
При чем здесь «нравится-не нравится»? Разговор совершенно не о предпочтениях.
а вот считать, что меняя место работы человек остается молодым специалистом — это нехорошо
Это передергивание. Я сказал, что если менять работу со сменой технологии стабильно раз в 2 года, то человек останется «молодым специалистом» в каждой из этих технологий. Это очень «узкое» высказывание, не надо толковать его расширительно.
«Интересно, а откуда вы взяли данные о том, что 64 МБ в 2001 году — было мало? Учитывая, что мой первый компьютер обладал в 2001 году 32 МБ, и это было немало по сравнению с моими друзьями.»
Мир — большой и разный. 32 Мб у меня было в 1998, очень быстро нарастил до 128, иначе тормозило все с постоянным свопом.
«то она мне не нравилась дизайном и любовью к съеданию ресурсов. С 98, я перешёл на 2000 Про»
Включается Classic Theme и никаких отличий, кроме производительности ( в лучшую сторону).
Два года — это также период для получения специализации в советской высшей школе.
Ровно об этом я и сказал: это период, необходимый, чтобы состояться как специалист в определенной технологии, после идет наработка опыта. Иначе человек будет вечно «молодым специалистом» — технология изучена, опыта нет.
Угу, помню я как-то одну debug сессию, часов на 20, в ходе которой была исправлена ошибка-виновница в 1(!) символ.
Когда как. Иногда — да, приходится обходиться детальным описанием без кода, с тестовыми заданиями. С другой стороны, опять же, глядя на то, какие бури в стакане возникают при обсуждении стилей кода здесь (вида «где ставить скобки, допустима ли венгерская нотация» и т.п.), порой опасаешься, как сторонний человек будет воспринимать твой проект. Мало ли, ему ненавистен GNU style, скажем.
Да, но я не понимаю, к чему вы клоните. На всякий случай, говоря о новых технологиях я имел в виду новые для конкретного человека, а не отрасли.
Так это шуточный пример — в любом случае, как-то ты социализируешься, не совсем же затворником живешь. Все равно хоть какие-то горизонтальные связи будут.
Я употребил это слово в значении «не только профессиональные навыки».
С одной стороны — да. С другой — в качестве примера — когда меня нанимали, в качестве личного проекта я показывал свою операционку; при этом она была моим личным закрытым проектом. Это тоже аргумент (хотя, конечно, вы можете сказать о критике, улучшениях на основе нее итд).
В качестве примера — не в 2010, нет, позже, но у нас разные люди стали применять Java для написания одного из нестандартных компонентов системы с интеграцией в легаси код, другой человек — один из серверов на Go. Это все новые куски, с интеграцией. И они делали(ют) это в рабочее время.
Так статья вроде как о «топ» разработчиках, что может предполагать и специализацию, а не мастеров на все руки, верно?
Человек может больше отдаваться работе, чем личному проекту (сверх обычного рабочего времени), это нормально. Мне сейчас интереснее, например, поработать сверхурочно, чем пилить свои проекты.
Очень сильно зависит от конкретного места работы и проекта(ов), здесь сложно обсуждать в терминах вероятности.
А надо? Может быть, лучше в таком случае шагнуть на ступень выше в мире «тырпрайз»?
Нет, ну это замечательно, спору нет. Только вряд ли можно считать, что человек, который форкнул проект на гитхабе, добавил свистелку и пулл реквест на фикс в две строки, имеет сто очков по профессионализму перед человеком, который разрабатывал закрытые системы, возможно, с ноля. Это я не в ваш адрес, а так, рассуждаю о «галочках».
Даже здесь на Хабре постоянно проскакивают комментарии вида «в хорошем резюме обязательно будут открытые проекты», «добавьте свой GitHub, чтобы работодатель видел, чем вы занимаетесь». Иногда хочется спросить, мол orly кто-то всерьез будет оценивать человека, проработавшего пол-жизни на проприетарном бэкэнде по наличию/отсутствию опенсорс проектов/вкладов в них?
Это единичный контр-аргумент к тренду — см. выше. Увязка, если судить по местным комментаторам, стопроцентная — «хороший разработчик должен иметь свои проекты и коммитить в оупенсорс». Автор же предлагает противоположный взгляд — человек может развиваться на рабочем месте, в рабочее время. Просто наниматели у всех разные и области работы тоже.
А вот почему применяется имеено Б-дерево (не только в постгре и вообще не только в реляционных БД)? Как выбирается размер узла, как он связан с размером блока, какова сложность поиска, сколько блочных операций ввода-вывода надо — это ключевые особенности B-Tree.
А ведь есть еще B+Tree.
В журнале «Радио» было описание, помню.
При чем здесь «нравится-не нравится»? Разговор совершенно не о предпочтениях.
Это передергивание. Я сказал, что если менять работу со сменой технологии стабильно раз в 2 года, то человек останется «молодым специалистом» в каждой из этих технологий. Это очень «узкое» высказывание, не надо толковать его расширительно.
Мир — большой и разный. 32 Мб у меня было в 1998, очень быстро нарастил до 128, иначе тормозило все с постоянным свопом.
«то она мне не нравилась дизайном и любовью к съеданию ресурсов. С 98, я перешёл на 2000 Про»
Включается Classic Theme и никаких отличий, кроме производительности ( в лучшую сторону).
Ровно об этом я и сказал: это период, необходимый, чтобы состояться как специалист в определенной технологии, после идет наработка опыта. Иначе человек будет вечно «молодым специалистом» — технология изучена, опыта нет.