Технические собеседования приносят вред

Сооснователь платформы для рекрутинга Interviewing.co Алин Лернер ранее писала, что компании, которые опираются на сложные технические собеседования при найме, «тратят ресурсы на множество кандидатов, которые не понимают игровую сущность собеседований, и выбрасывают их в несовершенную, невариативную систему». Люди, которые успешно пробираются сквозь перипетии собеседований, зачастую хороши именно в этом — в прохождении интервью. Но далеко не всегда это утверждение правдиво и для рабочей эффективности.

большинство собеседований могут раскрыть лишь 14 процентов от потенциала сотрудника; www.wired.com/...​2015/04/hire-like-google
только 25 процентов кандидатов способны качественно показать свои возможности на технических собеседованиях; blog.interviewing.io/...​arbitrary-heres-the-data
высококлассные специалисты «заваливают» технические собеседования в 22 процентах случаев. blog.interviewing.io/...​arbitrary-heres-the-data

P.S.
Содрал с dev.by

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Американцы: Со Spring-ом работал? Что на нем писал? О чем было приложение?
Наши: Назовите сигнатуру методов класса SpringAPiХуеМое?
Я вчера столкнулся со сложной проблемой в Hibernate (и неделю гуглил, так как сам не осилил) — как ее решить ?
Вот кусок говнокода с тройным циклом и однобуквенными переменными и корявыми отступами — как это будет работать ?
Сколько весит в байтах вновь созданный Java объект?
Отбалансируй на листике красно-черное дерево...

Если жестко задрачивать кандидата, то любой сядет в лужу.

У кандидата спрашивают:
-Что такое собеседование?
-это беседа двух умных людей
-А если один из них — идиот?
-Тогда второй не получит работу

Любые собеседования, проводимые прасисианалами — вред.
Это касается любой деятельности, где требуется образование.
Но почему-то считается, что телятину в кисло-сладком соусе должен готовить шеф-повар с 20-летним стажем, зато с техническим собеседованием — справится 23-летний синьор.

Что он может спросить? Да то, что сам только что вычитал про супер-крутой фреймворк, и забудет через две недели. Но как этого можно не знать кандидату?

А факты таковы, что кандидат работал НА ДРУГОЙ работе, занимался ДРУГИМ делом, возможно всё ещё занимается. И львиная его доля знаний секундной доступности — об этом. А к собеседованиям лучше всего готовы проходильщики собеседований.

Вероятность ошибиться с кандидатом на собеседовании — ВЫШЕ, чем если не проводить его совсем. Именно потому, что чем кандидат ценнее, чем выше его способность фокусироваться на задаче — тем выше гарантия что его текущий фокус не совпадает с общерелигиозным бла-бла-бла вайтишников.

Классический вопрос — чем отличается абстрактный класс от интерфейса. Июнь назовёт 4 отличия по книжке. А те кто знаком с отладкой низкоуровневого кода — скажет что ничем по сути. Вы не можете ни собрать, ни разобрать такие объекты. Иначе говоря, ни тех ни других — не существует, но существуют объекты, отвечающие за приведение к этим типам. Другими словами, когда произошло приведение типа, создаётся КОНКРЕТНЫЙ объект АБСТРАКТНОГО класса — именно то, что якобы «невозможно», а по сути невозможно ничто иное.

И что, разве может вчерашний июнь с лычками принять кого-то сложнее такого же июня?

Кстати говоря. Был сегодня по своим делам на одной механической фирме. Пообщался с народом, вспомнил, как сам работал у «отечественного производителя».
И задумался, как собеседуют слесаря или сварщика. Что-то мне подсказывает, что не просят их перечислить ключи по номерам, калибры электродов или сорта стали. Задрочка на хрестоматийные задачки и справочные данные — отличительная особенность только ИТ-мирка.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ну да, сложные технические собеседования — балшит жуткий.
Ибо реальная работа имеет мало отношения к условиям воспроизводимыми на интервью.

вот потом так и работают в этих всех интсграммах: амазонаъх и гуглах иже с ними)
про эйпл вообще молчу) более идиотских интервбю чем там у меня нигде не было

У нас тоже некоторых гребцов набирали — полноценно интервьювили на 4 часа.
Однако подход в тиме все равно другой был: типа на тебе задание, например чет типа написать полноценный вебсервис чегото там; 3 часа времени; и делай что хочешь. Потом еще час на то чтобы рассказать и поотвечать на вопросы чего так сделал почему итд.
Куда более вменяемый формат, чем балансировать красно-черные деревья на доске. Однако не в галеру в Киевах.

вот это я понимаю конктено и по делу)
у меня же бывало так: позвали меня в одну команду одной компании где задача была яснее некуда, создать приложения АБС, чтобы с его помощю группа лиц могла через него прогонять данные и получать ответ на выходе)
а вот вопросы на том интервью, что бы вы делали иесли бы неожиддано в комнате появился человек! или такой как бы вы тестировали поздравительную открытку)
your bunny wrote, какой человек, какая открытка? тольок врожденная интелегентность и боязнь попасть в черный список этой компании были причиной, что я не ушел)

как так работают? Плохо что ли работают?)

Та шо непонятно? инстаграмм — галлерея фоток(функционал плагина на jQuery), амазон — интернет магаз(таких мульон на вордпрессе), андроид тупит, а в аффонах новые разьемы создают :-)

Какахи анимируют)

По моему мнению, тот подход котрый они применяют , очень на руку индусам и благодаря ему они там сидят пачками и белых просто не пропускают

Летом проходил собес в одну компанию: аутсорс на английскую фирму. Собес по скайпу был скорее разговором «за жизнь». Потом дали задание на HackerRank: дан код приложения на NN файлов, нужно допилить функционал. Задача проверяла способность кандидата за два часа понять код и допилить фичу, следуя уже существующему в коде архитектурному подходу. Дело плевое, всего-то увидеть один-два паттерна и написать пару десятков строк кода. Задачу выполнил, но не успел в последнюю секунду скопипастить свой код из IDE в онлайн-редактор HackerRank — счетчик тупо остановился и все заблокировалось. До сих пор стыдно :)

Будьте бдительны на HackerRank, не забывайте про счетчик.

Это читерство писать надо прямо в окне хакера без иде.

Это читерство писать надо прямо в окне хакера без иде.

В описании задачи было сказано, что IDE использовать можно. Не читерство, следовательно.

Оно и к лучшему, вдруг там каждый день нужно с таймером работать

Тоже мне новость, это ж даже лидеры рынка давно в курсе (по крайней мере тот лидер у которого название с поносом). Берем трейни, учим его вместо кодить собесы проходить и продаем как лида, PROFIT!

Есть два проекта, как два близнеца.

На одном индусы копчёные, на другом — задроты обречённые.
На каком работать будешь, а какой скорей забудешь?

Кстати говоря. Был сегодня по своим делам на одной механической фирме. Пообщался с народом, вспомнил, как сам работал у «отечественного производителя».
И задумался, как собеседуют слесаря или сварщика. Что-то мне подсказывает, что не просят их перечислить ключи по номерам, калибры электродов или сорта стали. Задрочка на хрестоматийные задачки и справочные данные — отличительная особенность только ИТ-мирка.

Вот так взяли и сравнили слесарей и байтослесарей

Ну да, первые обычно что-то полезное делают.

Как-то так у меня в карьере складывается так, что берут на работу без технических вопросов, а вот там, где задают технические вопросы, я не прохожу. Даже з/п ниже не предлагают. Обычно вопросы в стиле «Что делал? Как? Зачем?». Да, я технические детали рассказываю, но меня не српашивают как работает Set/List/Map.

Понаписали-то... Что вы разволновались? Все заложено в цену продукта. И долгие поиски кандидата, и просроченные дедлайны. Пока это «22%» это мало кого волнует (кроме организаторов курсов улучшения и углубления). И контор полно, и кандидатов.

Технические собеседования в тестировании не то чтобы очень сложные, но порой конечно вопросы задаются на диво странные. Более того, в мечтах хотелось бы конечно разграничивать беседу с тех специалистом и менеджером, но на практике у меня такого не было. Зато успела получить несколько «шуток» на тему своего образования и вайтивайти. Мне кажется, с учетом нажитого опыта, очень хорошая система забугорная, когда сначала идет беседа с hr, потом тех тесты и потом уже беседы с тех специалистами, если они нужны и менеджерами.
Последний раз меня на типа тех собеседовании мурыжили два часа, причем вопросы были либо ни о чем за жизнь (типа девушка, а вы бухаете, — нет — ой, ну мы пошли хаха), или же почему вы в 2005 году решили стать тестировщиком, либо как грепать логи (на тех вопросы я отморозилась, ибо работать с «шутниками» такого толка не хотела). Проблема баланса есть и будет. Это как у синьйор плюсиста спрашивать — а напишите мне пузырек на листочке.

типа девушка, а вы бухаете, — нет — ой, ну мы пошли хаха

Мудаки какие-то

причем вопросы были либо ни о чем за жизнь (типа девушка, а вы бухаете, — нет — ой, ну мы пошли хаха),

Они просто установили рекорд по продолжительности беседы с девушкой. Так далеко ещё не заходили и растерялись случайно.

Последний раз меня на типа тех собеседовании мурыжили два часа, причем вопросы были либо ни о чем за жизнь (типа девушка, а вы бухаете, — нет — ой, ну мы пошли хаха), или же почему вы в 2005 году решили стать тестировщиком, либо как грепать логи (на тех вопросы я отморозилась, ибо работать с «шутниками» такого толка не хотела). Проблема баланса есть и будет. Это как у синьйор плюсиста спрашивать — а напишите мне пузырек на листочке.

Идиоты, прости Господи.На западе они бы давно уже вылетели в трубу за подобные вопросики про пьянки.

Увы, подобные вопросы у нас лакмусовая бумажка определения, как мне кажется, сможет ли человек работать в команде или нет, типа компанейский ли он или она. Имхо это не соответствует действительности, но манагеры знают лучше. Да и традиционные культурные ценности никуда не деть. Типа тот кто не употребляет фрик, себе на уме и прочая

1.Гхм, себе дороже работать в ТАКОЙ команде. Слава Богу что и не прошла туда.
2.Такие «Традиционные ценности» очхорошо рисуются в клипах про лекарство от несварения, уж не упомню про что (потряс сам клип, вернее все жлобство, отраженное) — когда «городского» по виду мальчика разбитная деваха привозит «до батькив у сэло» где этот самый батько начинает парня пичкать «ковбасою та самогонякою» — и тот тайком сьедает волшебную таблеточку, чтобы сьесть это все. Финал — красномордый папка орет «ай молодэць» и бьет парня по спине.
. Знаете, я вот ненавижу, когда украинцев выставляют сплошь сельским бухо-жрущим жлобьем. И клипчик этот — тоже в кассу таких выставлятелей. Благодаря ним цветет и пахнет культура вот такого вот «корпоративизма», черт бы ее побрал.

Та они не только рисуются так, подобные лекарства. Наестся всякого и потом хавать какой-нибудь фестал. )))
Поддерживаю про выставление, но тут мне уже неясно, кто курица, а кто яйцо, то есть что было первым. И в итоге, особенно если коллектив молодой, удалой, человеку, ведущий спокойный образ жизни, уже проживший этап вот этого гона, задают соответствующие вопросы, потому что он не «впишется». но это так, чисто мои наблюдения. )

Некоторые штуки надо попробовать.
#10, например. Должно быть круто.

У кандидата спрашивают:
-Что такое собеседование?
-это беседа двух умных людей
-А если один из них — идиот?
-Тогда второй не получит работу

Я только готовлюсь к собеседованию. Ну... что я могу сказать — да, это рулетка. Могут спросить — то, что ты хорошо знаешь — значит ты хороший спец. А могут спросить то — что ты вообще не знаешь (при этом то, что ты хорошо знаешь уже никого не будет интересовать — вердикт — ты плохой спец.). Это не правильно ИМХО. Я прошел около 10 собеседований (может больше, не помню) правда не в ИТ. Поэтому еще раз повторюсь — это рулетка.

Возможно. Но рандом никто не сделает. И вообще, мне кажется что тут даже роль играет не техническое собеседование, а понравился ты ЭйЧару или нет .Читал историю, в, которой кандитат на тех. собеседовании мычал и бычал. Не мог ответить что такое int. Но его взяли. ЭйЧар в нем углядела перспективного спеца.

Что же до меня: я сейчас работаю банковским аналитиком. Очень активно учу .NET и технологии. Очень люблю кодить и творить:) Хлебом не корми — дай покодить :) Но если честно, читая подобные темы идти на собеседование (на джуна) хочется все меньше и меньше.

Спасибо за поддержку. А насчет int имелось ввиду что за тип данных. Без углубления — типа структура это или класс, где храниться на куче или в стеке. Вообщем, самое простое.

Ну я бы сказал так: это область памяти, которая работает по принципу last in, first out. Используется для хранения типов данных и не только.

Ну блин, а что .NET работает с другой памятью? От того, что маллоки и фри обернули внутри фреймворка ничего же не изменилось — разве что программисты могут не задумываться об этом и писать говнокод

Да я знаком и с тем и с другим, хоть и использовал последний раз их 10 лет назад. Ты лучше не отсылай куда-то меня читать непонятно что, а обьясни понятнее свою мысль.

Мысль такая. Зачем в системах, где менеджер памяти и сборщик мусора (а выделения памяти делаются не маллоком/фри, а плэйсмент-констракшном), понадобился стэк?

Да, .NET тоже может кидать стэк-оверфлоу эксэпшны (если они не отключены в настройках) — но это эмулированный стэк и эмулированные эксэпшны.

Так моя мысль в том, что неважно какая технология используется — память работает одинаково везде. Именно потому что ассемблер везде одинаковый :)
Для программиста оно может выглядеть по-разному, например, тот же StackOverflow нельзя в .NET закетчить, приходится по-другому его вылавливать. Но от этого стек никуда не девается, и переменные value type хранятся в стеке хоть там, хоть там.

Но от этого стек никуда не девается, и переменные value type хранятся в стеке хоть там, хоть там.

работа с памятью — это внутренние детали виртуальной машины, и то, как она аллоцирует нативные переменные, может меняться хоть каждый день. В питоне например в стек фрейме есть указатель locals, который указывает на массив в хипе, и в этом массиве хранятся «локальные» переменные питоньей функции

так его и нет в управляемых языках. Стеком там принято называть стек вызовов, в котором лежат структуры данных, описывающие вызванные подпрограммы

call stack, чтоли?
а вот в цешарпе
void foo() { int bar; }
bar где аллоцируется? а в яве?

я очень надеюсь, что технические собеседования вы не проводите, иначе сабж

int лежит в куче, а вот ссылка на него лежит в переменной которая в стеке )) easy-peasy

ссылка на int ? роскошно :)

public ref Person GetContactInformation(string fname, string lname);

Я, конечно, извиняюсь, но что это за епаная наркомания и какого Х она делает в моем теплом ламповом C#???

Не на int, а на обьект с интом, но само значение лежит в куче. Немного не так выразился ))
Ну а также ты можешь юзать ref и out чтобы кидать в метод не занчение а ссылку на него.

Вы с Integer не путаете? :)

call stack, чтоли?
а вот в цешарпе
void foo() { int bar; }
bar где аллоцируется? а в яве?

Depends. JIT компилятор постарается и оно вообще может быть выброшено, или существовать только в регистре.

вообще если быть занудой, то стек — это фича архитектуры, а не языка. В си нет стека, а есть локальные и глобальные переменные и выделяемая память.

Например, когда ты вызываешь сишную функцию, ты не знаешь, как компилятор передаст аргументы и вернет значение — через стек, через регистры или другим способом — это зависит только от соглашений в конкретной архитектуре и от желания компилятора придерживаться этих соглашений

о майн гот. смешались в кучу (в стэк???) кони, люди (вернее, передача параметров и внутренние переменные)

void foo() { int bar; }

тот же вопрос про си? куда покажет регистр sp?

Влад либо троллит, либо не понимает принципа работы JVM и прочих CLRов

мы про си или где?

вот например компилятор сишного кода под виртуальную машину джавы, в которой никаких регистров нет: github.com/davidar/lljvm

значит я был неправ)) не знал что его регистром называют

TI CC2530 !

на арм и х86 есть

В си нет стека, а есть

Нет стека а значит нет размера стека а значит нельзя выйти за его пределы чистый профитЪ!

Удобно. Потому что там логически то же LIFO.

А вот будет он связной областью памяти или цепочкой отдельных кусочков — уже не так важно — и в пределах одного языка разные VM вполне могут это реализовывать по-разному.

Ты о чём-то не о том.
Никакой GC не собирает то, что в стеках существующих тредов. Их содержимое, вместе с глобальными переменными — это стартовый набор для расчёта достижимости в цикле GC. А само понятие стека, независимо от организованности, всё равно сохраняется как отражение схемы работы как цепочки вызовов функций.

Вот если бы работа программы была организована совсем без функций, но в виде самостоятельно работающих сущностей с состояниями и обменом данными между ними — тогда твоё предположение получило бы смысл. Но сейчас так никто не пишет — невыгодно.

я уже плохо помню детали работы с памятью в с, но кажется, что-то подобное там делалось каждый раз когда была необходимость в рекурсивных функциях.

А какая максимальная глубина стека вызовов (как бы он ни был реализован) у этого «специфического железа»? Таки чисто интересно.

Я спросил про глубину стека, а не про последствия её превышения. Последствия я могу и не такие придумать :)

а что такое виртуальная машина и кому нахрен она нужна?

Это модель V60 в симулинке %)

и треды!!!

Ну да. Треды тоже начали эмулировать, в виде «зелёных тредов».

Ээээ... Народ, я вообще то определение стэка сказал — думаю такого ответа на собеседовании будет достаточно. Вы зачем в дебри полезли то? :)

Поздно. Это тут обычное дело.

Ну а что тут поделать. Пост совок жив и крепко осел в головах. Он всосался туда через идиотскую систему образование, где главное не понять как пользоваться и зачем оно, а тупо зазубрить. Он влез туда через синдром вахтера где любой HR ощущает себя большим начальником, вольным принимать грандиозные решения итд. Да и сами конторы все больше пауков в банке напоминают. И судя по всему это не остановить, у процеса не ООС а ПОС.

Знаю я. Очень похожая система в Азии. Но там главенствует принцип «я начальник — ты дурак» ну и наоборот тысячелетия. Но даже там это активно меняют. Ну или пытаются.
Короче, мое мнение что не успеют поменять. Все к с мозгами едут в ЕС учиться, часто в Польшу. У меня родители были в образовании, сейчас на пенсии. Так последнее время (несколько лет) говорят резко упал спрос на подготовку к ЕГЭ или как там его. Народ массово в Польшу едет после школы. Ну и я уже находил восторженные ответы оттуда. Как чевек поехал учиться в польшу на одно, понял что не нравиться, перевелся куда-то в Швейцарию итд. Читал чем там занимаются, мне тоже завидно было.

Знакомый (общался больше 10 лет назад) поехал в ИНДИЮ программировать. Писал что он просто афигел от лаболатории в ихнем ВУЗе (далеко не самом лучшем).

идти на собеседование (на джуна) хочется все меньше и меньше

Ну да, можно расплакаться какие конторы нехорошие, собеседования делают. А можно просто перестать ныть и херачить, чтоб добиться цели...

К сожалению, возраст когда можно было расплакаться уже прошел у меня К моему большуму сожалению..... :( Остается только «херачить» как вы выразились. :)

Просто с каждым днем становить все тяжелее: кодить левой рукой, а правой писать субдолг для банка для включения его в РК. Хочется заниматься только одним делом. Любимым делом. Поэтому некоторая нервозность присутствует, даже не смотря на весь мой опыт общения с Эй Чарами. Каждый раз когда не прошел собеседование => увеличение времени выполнения задачи по типу: return кодить левой рукой, а правой писать субдолг для банка для включения его в РК:)

даю подсказку... хр-ам не всегда нужно говорить правду (а всегда то, что они хотят услышать)

Дуже погана порада. Ніколи так не чинив.

А потім дізнаються, що збрехав, і будуть дутись на мене. А мене той мент-бот, що мені батьки і школа підсадили замість совісти, буде мучити. Танунах.

Приховувати суттєву для співрозмовника інформацію, так щоб у нього склалось хибне вреження — то та ж сама брехня. За таке люди в Пеклі горять, і не має значення, що Пекла і посмертя не існує.

безробітний лузер

кгмм...

кгмм...

Вибачте, не знаю цей мем чи абревіатуру.

я до того, що можливо

Дуже погана порада. Ніколи так не чинив.

і

безробітний лузер

якось пов’язані ? :)
Може, таки не варто завжди «рєзать правду матку» ?

Може ви праві. Може дійсно є звязок.
Не брешу — безробітний лузер.
Якби брехав, був би — брехливий безробітний лузер.

амінь.
P.S.
так ти слона не продаси ©

На щастя не маю жодного слона на продаж.

возвращайтесь в 1с -там полно работы, будете хоть с работой лузером)

Повернутись можна туди де був. 1С7 померла років з вісім тому. А в 1С8 мене не візьмуть, бо не маю досвіду. Це не враховуючи, що я вже понад 2 роки занадто тупий для програмування.
Хіба що Ви готові мене найняти не зважаючи на це. Тоді можна спробувати.

понад 2 роки занадто тупий для програмування.

то при чому тут досвід чи технологія?

ось тобі приклад, як треба боротися за світле майбутнє:
thepoint.rabota.ua/...​utm_campaign=news_all2711

Да, меня поразила история. Женщина — МОЛОДЕЦ !!!!!

Да, меня поразила история.

Мене найбільше вразив опис, як вона отримала першу роботу:

громко представив себя «опытным копирайтером»

Що повністю підтверджує мої висновки, що без досвіду шансів нуль.

Почему? Вот они спрашивают:"как долго вы намереваетесь у нас проработать".
Ты отвечаешь:"вообще то я нацелен на долгосрочное сотрудничество, но конечно многое зависит в том числе от вас". Соврал? Нет! Но что эйчар услышал:"этот человек внушаемый и послушный, будет работать у нас долго довольствуясь минимальными повышениями, или вовсе без них" — его проблемы.

На самом деле правду можно говорить только взрослым людям, детям рассказывают сказки и не важно, что «ребёночку» под сорок лет и он аж целый проджект менеджер :)

Без поняття як із:

«вообще то я нацелен на долгосрочное сотрудничество, но конечно многое зависит в том числе от вас»

можна зробити висновок:

«этот человек внушаемый и послушный, будет работать у нас долго довольствуясь минимальными повышениями, или вовсе без них»

Тому, якщо ейчар зробив такий висновок, це його вина і непрофесійність. А от, якщо ви здогадались про такий його висновок і не зробили все від вас залежне щоб виправити це непорозуміння, то це ваш гріх, тяжкий, особливо для атеїста, гріх перед Богом.

Рішення не виводити його з самоомани — то ваше рішення, і ви за нього відповідаєте.

якось занадто вітієвато для мене.
Пропустив момент переходу розмови на теми зоології. Трохи вище зіскочило на тему складностей торгівлі слонами, ви тут про тонкощі проходу верблюдів через КПП на воротах. Ви з Vitaliy Fedoriv зараз у зоопарку?

Достатньо задати пару запитань і все стає зрозумілим. Одне з них: розкажіть, що було цікавого в вашій професійній діяльності останні пів року. Друге: на скільки балів з 10 ви оцінюєте свої знання в технології X.

Спробуйте на собі. Результати вас здивують.

Алин — годный троль :)

Вот еще один очень годный пост: blog.interviewing.io/...​000-technical-interviews
Суть в двух словах: только две вещи в вашем резюме корелируют с прохождением собеседований, это количество грамматических ошибок и курсера.

Ве то вы верно говорите, вот только есть другая сторона медали, если бы не собеседования(много) то очень много теории я бы будучи джуном\мидлом просто не узнал или пропустил в с тиле «потом дочитаю», а так каждый раз после собеса я пирходил и учил, пробвал, ковырял, разибрался в деталях, а потом все это обьяснял, все что не знал на собеседовании, хорошо расширяет круогозор в стеке.
А когда приходил наработу то продолжал фиксить баги )))

Поэтому как для синоьра такой скилап это больше скилап прохождения собесов, а вот для милла и джуна самое оно.
Учителей у меня нет и не будет, что я за инженер если сам не могу выучить туже многопоточность, или паттерны, или sql фишки новые, или js фреемверк?
Я не говорю что эти собеседования эффективны, я говорю как получить полезный эффект для себя.

Я кстати понял идею, ТС говорит что надо выбирать не лучшего по навыкам, а лучшего как человека. Из тех кто прошел по навыкам. хм.

ну, а толку? Человек на месте не стоит и за завтра может вполне выучить спрашиваемую тобой технологию. А тот кто ответит лучше, может ничего не учить уже два года. и что тогда?

upd: собственно в этом и разница: ТС берет не тех кто одинаково подкован в подборку, а тех кто прошел даже минимально, а потом берет лучшего по человеческим качествам. Поправьте, если ошибаюсь %)

Нужен. Если любая альтернатива — переделывать больше 50% работы.

Если лучший был первый, пока остальных 9 прособеседуешь, он может уйти ;)

Есть подход брать первого, которого счёл достаточно хорошим.

Мне кажется, что вы немного додумываете, в своем оригинальном посте Алин просто говорит, что собеседования в том виде в котором они есть — сакс. Там нет предложений: что делать, на сколько я помню.

юмор у Вас, скажем так, специфический, мягко говоря ...

От пятого вопроса бомбануло, да? ;-)

О, я прям ждал, когда кто то спросит))на самом деле нет, я к этому абсолютно равнодушен,но смекалка у Вас прям супер))Как по мне, просто это скоуп шуток, которые под каким то предлогом надо было вбросить..(понятно, что это сарказм в отношении собесов на галерах, но по моему мнению шаблонно) Если кого веселит — искренне рад за них))

Вечер в хату на галеру)

Bitrix не движок, Unity не веб-фреймворк.

Наоборот тоже верно, ибо теорема эскобара обладает свойством транзитивности.

1. При входе на собеседование обрати внимание на полотенце на пороге. Нужно вытереть об него ноги, показав уважение к другим членам команды.

— Кто в митингруме старший? Где мне сесть можно?

13. Вейпер в глаз или в теннис раз?
14. Кончился бенч, появилось два проекта. На одном лес багов, на другом море говнокода. Куда пойдешь?
15. Ты пришел на кухню. На кухне печеньки и чай в пакетиках. Что съешь, что домой унесешь?
16. Гироскутер покататься дашь или мак продашь?
17. Есть два языка. На одном решетки точены, на другом плюсы дрочены. На каком писать будешь, за какой мать писать посадишь.

длительные сроки на галерах дают о себе знать

17. На решётках API напишу, на плюсах сервер поставлю, а мать писать фронт посажу.

Есть 2 модуля. Один технически важный, второй легаси бажный. На какой сам сядешь, на какой джуна посадишь?

Чем отличается интерфейс от абстрактного класса?

Really? ну-ну

Чим відрізняється інтерфейс абстрактного класу від абстрактного класу інтерфейсу?

Please pimp up your levels of abstraction.

Чем отличается интерфейс абстрактного класса от абстракта классного интерфейса?

Тим, що один — інтерфейс, а інший — клас. ;-P
Ви не підходите нам. :D

по п.7 после ответа «...и бесконечная масса» можно дальше не разговаривать — этот чел будет писать проги для бесконечной памяти, why not?

п.12 действительно все спрашивают, но намного полезнее спросить — «что лучше: абстрактный класс или интерфейс?» и по вашей логике подразумеваем подтекст «в каких случаях?». это намного информативнее в смысле узнать как рассуждает кандидат.

Да. Так и есть. Тех. собеседование проверяют способность пройти тех. собеседование.

Технічна співбесіда — це гра у цікаву ментальну гру. З одного боку той, хто проводить співбесіду, намагається затвердитися не тільки перед потенційним кандидатом в професійному плані як спеціаліст, а ще доводить це іншим колегам. З іншого боку кандидату треба дуже уважно слідкувати за тим, щоб під час інтерв’ю не перейти дорогу іншим «спеціалістам» в компанії та щоб його не визнали занадто кваліфікованим, ну або загрозою для поточних працівників. Тому технічні інтерв’ю — це про альфа-домінування, не про бізнес.

З іншого боку кандидату треба дуже уважно слідкувати за тим, щоб під час інтерв’ю не перейти дорогу іншим «спеціалістам» в компанії та щоб його не визнали занадто кваліфікованим, ну або загрозою для поточних працівників.

Поэтому работать в компаниях- это зло)
нужно прикидываться хуже ,чем ты есть.

обычно если описанное имеет место, то контора не подходит независимо от результатов собеса, работать в курятнике желания нет

а якщо там повно нетоптаних «ІТ курочок»?

Какие альтернативы?

Конкретнее, какой алгоритм? #тыжпрограммист

Когда требуется не думать а код писать от как заказчик сказал, а судя по всему только такая работа в украине и осталась, то самый востребованный работник — именно быстро писать что сказали.

А это уже не нашего прогера проблемы. Это проблемы тех кто в США или там в Германии сидит. А им надо чтобы обезъяна делала то что скажут, как скажут, быстро и дешево.

Короче говоря, альтернативы техническим собеседованиям нет

Есть у человека уже завершенные проекты? Хотя бы дипломная работа есть? Значит можно пообщаться какие были проблемы что именно он делал, как проблемы решал.

И? Что-то решал, что-то делал. Проекты под NDA, ничего сказать не могу, что дальше?

Чем толще NDA тем больше идиотизма в компании.

Вот именно! Там была серьезная секретность, а не манагер-дебил-сениор о 23годах. Когда серьезная военка то по идее должно быть четко прописано что именно запрещенно разглашать. А не 50 страниц юридического забористого бреда, который подробно расписывает что запрещенно все, всем, при всех условиях, и что в наказание за это будет все, причем сам текст подходит что для галер что для банковского служащего что для СБУ что для КГБ.

Читал где-то про позицию NASA по этому поводу: все открыто, если этим не может воспользоваться шизик типа Ына. Военные США вообще вовсю гражданские разработки используют. Открыто ВСЕ! Читал на EDN как решили проблему связи на поле боя — стандартная гражданская CDMA сота на хаммви. Обычные телефоны у рядового состава. Единственная военная тайна — код (CDMA в принципе без кода работать не может). Ну и еще военная краска для камуфляжа соты.

Если человек про проект говорит что там все под NDA, значит человек ничерта и не делал. Я не видел еще такого NDA, который запрещал примерно описать архитектуру, и вволю поговорить об проблемах при разработке.

Продробности — нет. А примерно одинаковые задачи примерно одинакого и решаются.

Да, да, даже запрещено говорить где работал и сколько времени. Более того запрещено сообщать свое имя, возраст и пол. Даже запрещенно обсуждать всякие гипотетические проблемы — а вдруг такая проблема тоже есть в компании. Даже вообще говорить запрещают.

Ну какой ущерб будет компании за то что рассказал что к примеру рассказал что писал под ARM9, и рассказал какие были глюки и как ловили?

Так вот на интервью признаться о оставленых бекдорах или глюках которые побороть не смог? Ну-ну. Можно придумать кучу отговорок. А можно просто рассказать базовые функции. А как оно потом будет выглядить, называться, когда пойдет в серию, и пойдет-ли это дело уже маркетологов, и инженер этого просто знать не может и не хочет.

Короче, если человек подписал такое НДА что вообще ничего рассказать не может то или он идиот или его начальство или он вообще ничего не делал. Очень удобно ли, записать себе какойнить мега-проект, несколько лет работы в Гугле или там в Тесле, а потом на все вопросы говорить НДА подписал. Кажется даже слышал что такое НДА даже незаконно в США: должно быть четко расписано что именно запрещено. Софт вообще не под НДА попадает а под интеллектуальную собственность компании. Разговаривать про него можно сколько угодно. Под НДА попадает список поставщиков, клиентов, диллеров итд. Надо оно инженеру? Надо оно на интервью?

На линкедине нашел кучу людей которые сейчас в гугле работают. Открыто пишут.

Пытаюсь понять почему после 40 лет не могу найти работу. Посадил яблуню надеюсь молодильные вырастут.

ну вот не удалось сдохнуть или куда свалить. :(

Увы. Оптимистом был. Не то направление выбрал. :(

Не покажешь как адаптироваться своим примером? Слабо снова 23х летним кодером стать?

Ты только начни рассказывать. А дальше опытные люди аккуратно по цепочке все вытянут. По копеечке — три копеечки, и вот вы уже от абстрактных вопросов повышения перформанса беседуете о конкретной реализации вашего текущего продукта. Мне пару раз попадались такие любопытные — им все было интересно, вплоть до версий используемых библиотек.
И кстати даже информация про ARM9 может быть компрометируещей — она сразу намекает на используемую ОС (с ее известными уязвимостями) и потенциальную производительность девайса.

она сразу намекает на используемую ОС

«Symbian OS, Palm OS, Linux and Windows CE» (с оф. сайта)
какая из четырёх? :)

Если уж совсем формально, то выбор сужается до двух.
Ну а в целом важнен факт, что ОС, а не bare metal . Взломщики спасибо скажут.

А PIN номер карточки тоже узнают?

Да даже плакат в коридоре с внутренним тимбилдингом сфоткать и расшарить не можешь

Сфоткать плакат ты не можешь, т.к. у тебя нет разрешения на фотканье в офисе/зданиях компании. К НДА это никакого отношения не имеет и регламентируется другими документами.

А что касается НДА, он запрещает разглашение чувствутельной информации. Ни запрета на упоминание компании, ни запрета на упоминание технологий — я в НДА ещё ни разу не видел (правда, на военку я не работал). К тому же, под разглашением имеется в виду не разговоры/собеседования, а перядача документов интервью медиа и прочие осязаемые информационные утечки, часто становящиеся достоянием гласности.

В общем, если на собеседовании чел услышит от кандидата «не могу рассказать про проект/технологии, т.к. это НДА» — на такого кандидата будут смотреть странно. :)

Ни запрета на упоминание компании, ни запрета на упоминание технологий — я в НДА ещё ни разу не видел (правда, на военку я не работал). К тому же, под разглашением имеется в виду не разговоры/собеседования, а перядача документов интервью медиа и прочие осязаемые информационные утечки, часто становящиеся достоянием гласности.

Бред простите помнится недавнюю инфу по свежему айфону слила дочка одного из разработчиков т.е. по твоему я беру приглашаю разработчиков конкурента на собеседование чтобы самому не палиться в специально нанятую третью прокладку и они такие «а ну это не НДА» и сливают мне «упоминание компаний» «упоминание технологий» сроки по проектам ну а что же ж когда ты мил человек с какого по какое число на проекте работал? а начали когда? а закончить когда планируете? бла-бла-бла а когда с клиентом работали? а как зовут? вау как круто возьми с полки пирожок мы тебе обязательно позвоним ещё!

В общем, если на собеседовании чел услышит от кандидата «не могу рассказать про проект/технологии, т.к. это НДА» — на такого кандидата будут смотреть странно. :)

Да-да-да расскажи ещё ))

та тут пол ДОУ в секретних хвайлах працюють і сліфф інфи ідьот нє па дєццкі.
жгітє ісчо о НДА
а ісчо єсть сікрєтна інфа (146%, утєчка с РНБО) шо С++ сінйорам мєньше 3,5койро не прєдлагають, лідам >5KEUR, а єслі прєдлагають мєньше, то це огєнти кремля, которих надо сдавать в СБУ.

Так и есть (( с синьорами сейчас ад ад ад и содомиты.

Почему же, есть такая NDA, называется доступ к гостайне по форме 1,2,3.

Это очень у «мышебратьев» популярно насколько я знаю. Типа зачем платить больше если можно сделать прогера невыездным. При чем тут оутсорс? Но там на это садят обычно молодеж, плюс дают квартиру от конторы, с выплатой кажись в 25 лет, и правом отобрать при увольнении, которое тоже в любой момент.

Пример моего NDA: в деталях, кроме маркетинговых, могу рассказать весь процесс разработки и львиную долю технической части. Не могу рассказать те алгоритмы, которые реализовывались самим кодом, то есть ТЗ. И абсолютно не могу рассказать имена и телефоны людей, для которых я это делал (или правильнее сказать, вместе с которыми).

Так вот, последнее для HR звучит как личное оскорбление — как это, не позвонить и не перемыть кости. А вот так! Не у всех задачи говносайты строить, есть те кто автоматизирует человеческий фактор.

Пример: если бы условно существовала лампа, потерев которую можно вызвать джина и заставить исполнять много желаний — вы уверены что джин с радостью узнает что кто-то вытрепал о самом факте существования лампы? Или о том, что я сам таким джином частично являюсь, и что мою лампу тоже может какая-то падла потереть? А прецеденты были. Решались методом «нет человека — нет проблемы».

Таковы реальные NDA, которые исполняются. А рассказ что запрещено строку через фреймворк прогнать, обфусцировать протокол, или банально развернуть бекэнд на веб-морду какому-нить казино — это действительно значит что человек мало что делал сам.

Лично я знаю как таких разговорить. Но здесь рассказывать не стану, это уже мой маленький NDA. Вот с психологами я на эти темы общаюсь с удовольствием :)

1. Про людей. Вам запретили LinkedIn? тяжеловато будет вам с поиском новой работы. По аналогии: это все равно что реелтер будет обзванивать жильцов дома, и узнавать, все ли в порядке с канализацией и не покосился ли фундамент. Им главное продать. Читал давно что в некоторых штатах вообще запрещено давать информацию о бывших работниках кроме как 1. Сколько работал, 2 на какой должности. И считаю что это правильно. Остальное субъективно.
2. ТЗ. Вот ведь везет человеку ему ТЗ дают. Самое лучшее ТЗ я получал, было в виде девайса и просьбы «хочу тоже самое, но дешевле и лучше». Алгоритмы — что за секретные алгоритмы? FFTW? Их уже готовых под самыми разными лицензиями как грязи. Все уже придумано давно.
3. Про джина — мы в инете. И мы не джины чтобы забесплатно желания исполнять. Тут чем больше себя разрекламируешь тем лучше. Да и джины у муслимов весьма неприятные существа. Тут вам не дисней.

Да и джины у муслимов весьма неприятные существа. Тут вам не дисней.

Вот именно. Насчёт штатов не скажу, но скажу что существует реально неразглашаемая работа. Разумеется, в аутсорс такую не дают, даже на аутсорс местной фирме.

Пример такой работы: разработка порносайтов, со съёмом жриц, в особенности разработка CRM этой системы — включая этапы пожизненного вовлечения клиентов. Разумеется не всем нужно знать, кто делает, что делает, как делает, и где это всё под носом хостится. Не всем надо знать, что получив админский доступ, можно перехватить контроль над целой организацией и даже отжать её себе если повезёт (разумеется за такое по головке не погладят). Не всем нужно знать, как подать сигнал шухера, если система себя скомпроментировала, и как собраться снова вместе и проверить кто крыса — и всё это на резервной системе.

Вот таким я НЕ занимался, но уровень ответственности примерно такой, уровень сложности выше раз в пять. И что мне писать в ЛинкедИне — писал CRM для сутенёров?

Ну, порносайты со съёмом жриц итд, типично Украинская продуктовая разработка. Также как и секс-онлайн, казино и прочие странные сервисы где Ляшко три раза сорвал какие-то нереальные джек-поты.

Остальное — не знаю. Да и нет такого у нас. У нас отжимом занимаются компетентные органы. Ну а кто и кого скомпрометировал, будет заниматься специальный антикоррупционный орган под пристальным контролем и по прямому указанию самого шоколадного величества.

В Конце 90х уже во всю были. У меня спросили чем отличается переменная в выделенной памяти от переменной объявленной внутри функции. (давно было, не помню точностей). Я ответил что в выделенной памяти это в хипе а внутри функции в стеке. И завалил интервью. Отказывается правильный ответ — переменная внутри функции изчезает при выходе из функции.

Г-но все равно размножилось и теперь для нас работы нет.

Дядя Витя ну когда же вы уже признаетесь что Артем Бондаренко это побочный эффект вашей дисперсинезации, проще говоря ваще второе я)

Как найти то, чего нет?

Быстрее сам г-ном станешь. Оно прилипает.

Анекдот про «папа, что такое аборт», пам’ятаєте ?
Першою відповіддю на питання повинне бути ... питання (а може і кілька), яке дозволить здогадатися, чи правильно ви зрозуміли, про що вас запитують. Після чого йде «it depends» і далі — все, що знаєте, аж поки вас задовбаються слухати і попросять перейти до наступного питання.
Тобто відповіддю на питання «котра година» мають бути запитання — «вам повідомити час по якому саме часовому поясу?», «усно чи письмово?», «з якою точністю він повинен бути вказаний?» і так доти, доки того, хто питав, перестане цікавати питання часу як такого. :)

Согласна. Это работает на ~95%. Но бывает, не все соискатели готовы к такой форме собеседования.

Соискатели и не должны быть готовы «к форме собеседований». Соискатели должны быть готовы исполнять свои обязанности по работе. И НИЧЕГО КРОМЕ.

А как только появляются «багини» без малейших признаков образования, которым настоящий мужчина кандидат «должен» — нужно увольнять, не сомневаясь ни секунды. Независимо от няшности внешности и половых предпочтений — для «багинь» есть другое место.

И для «богов» сыра и смузи место кстати там же: нет у тебя знаний и опыта — не проводи собеса, или зови того кто может провести, или давай тесты (опять же, не своего авторства). По той практической инфе, которая доступна мне, эффективность технических собеседований — 0%. Ровно ноль процентов, даже без статистической погрешности.

Почему так: в любой профессии, где используется компьютер — часть памяти находится там. И человек физически не способен воспроизвести «на бумажке» то, что он делает за своим рабочим местом. А собеседует его человек, который имеет своё рабочее место — настроенное, с расположенными в нужном месте данными, и огромными знаниями по мат.части того что делает прямо сейчас.

С тем же успехом можно потребовать на бумажке сделать копию паспорта карандашом, по памяти. А потом подойти к ксероксу, отксерить, и так «доказать» что кандидат очень долго делал и у него неточности. Зачем знать, что кандидат НИКОГДА не делал перерисовку там где можно отксерить?

А собеседует его человек, который имеет своё рабочее место

Для теста, для которого существенно использование IDE или какой-то специфической тулзы (да хоть /bin/sh), надо требовать установленный и настроенный комп с такой тулзой. Но таких задач не все.

И человек физически не способен воспроизвести «на бумажке» то, что он делает за своим рабочим местом.

Так потому и имеет смысл ограничиваться при этом теми задачами, для которых хватает бумажки. Мне не совсем нравится такой подход, но он работает хотя бы для алгоритмических вопросов. (Может, потому они и популярны? Никто не хочет / не умеет делать готовый комп для каждого кандидата и восстанавливать его к следующему гостю...)

надо требовать установленный и настроенный комп с такой тулзой. Но таких задач не все.

Пофигу. Даже если другая клавиатура или схема подсветки кода, человек уже потеряет половину своего автоматизма.
Любое новое рабочее окружение — да хоть руль чужой машины, требует определенного времени на притирку. Без нее он не покажет свое лучшее.
Разве что со своим ноутбуком приходить.

Так потому и имеет смысл ограничиваться при этом теми задачами, для которых хватает бумажки. Мне не совсем нравится такой подход, но он работает хотя бы для алгоритмических вопросов.

Если на уровне квадратиков и стрелочек — то да.

Даже если другая клавиатура или схема подсветки кода, человек уже потеряет половину своего автоматизма.

Мануальный автоматизм требуется от стенографистов или там наполнителей баз данных.

А кодерок может исполнить и в ноутпаде, с написанием мэйкфайла и последующим натравлением компилятора из командной строки.
Потому как, автоматизм кодерковый должен быть в мозгах.

Вот ты и спалился, аллах-акбарыч. На ИГИЛ значит работаем?

Макс, я знал что ты дурак, но не ожидал, что до такой степени.
Какой в жопу «автоматизм в мозгах», если ты два раза из трех банально попадаешь на капсок вместо таба?
Я уже промолчу про индивидуально настроенные шорткаты и алиасы.

На это можно сделать поправку (повторюсь). Но ты, похоже, считаешь, что чужая обстановка введёт кандидата в абсолютный паралич и он даже прочесть код не сможет.

Нет, просто постоянные опечатки в экзаменационной атмосфере собеса серьезно отвлечет человека от решения задачи.

Так задачу вирішувати в голові треба, а не під час написання коду.

Це не важливо. Важливий підхід до вирішення задач. Якщо людина пише код шляхом проб та помилок, а ще й повністю спирається на IDE, то для такої людини дійсно буде додатковим стресом будь-яке відхилення від середовища, до якого звикла людина. Але, думати треба до того, як сідати за клавіатуру.

Але, думати треба до того, як сідати за клавіатуру.

В смысле не нужно подписыватся на сложную работу, а брать только то, что можно быстро нафигачить, и сдать, или на гос-заказы?

Ви завжди в стані зміненої свідомості за комп’ютер сідаєте?

Приведіть приклади задач, які потенційно будуть на технічній співбесіді, які принципово неможливо вирішити «без клавіатури».

Значить таких задач не існує.

Задачі з створення повного застосунку, навіть дуже простого, для GUI-подібних середовищ десктопів і мобілок. Написати це на бумазі неможливо, а от запустити візарда та вставити потрібний код — запросто.
Задачі аналізу даних, коли треба ітеративно робити висновки і формувати нові аналізи.
Задачі із зневадження (за дампами чи коли зневадник піймав виняток); суттєво відрізняються від пошука помилок у друкованому тексті програми.
Задачі практичної діагностики пошкоджень ОС/заліза/etc. (для адмінів і опів).
Ще шукати?

Ці всі задачі потребують попереднього осмислення. Хоча їх дійсно можна проходити шляхом перебирання варіантів.

Ці всі задачі потребують попереднього осмислення. Хоча їх дійсно можна проходити шляхом перебирання варіантів.

Який звʼязок всього цього з технічним інтервʼю?

ну это больше для девопсов и сисадминов у вас задачи. Программистам все же на листочке легче..
Умение работать с отладчиком проверяют на собеседованиях?
Насчет анализа данных- там без тестового, наверное сложно действительно будет. Но можно скажем так, тоже попытаться объяснить на квадратиках..

Была книга старая, но прикольная «Энциклопедия профессора Фортрана», так там можно было вырезать и склеить клаву и даже комп! Видимо админов и девопсов на собесах просят именно это делать, в то время как программисты пишут код на листочках.

ну это больше для девопсов и сисадминов у вас задачи.

1 и 3 — программистские. Но тема не ограничивается только программистами, да.

Умение работать с отладчиком проверяют на собеседованиях?

Я думаю, на некоторые направления надо проверять. Если этого не делают, то только в предположении, что этому очень легко научиться или что если он хоть что-то умеет, то через отладчик уже продрался.
Но с нынешним потоком войти-в-айти уже и это надо проверять, по крайней мере на юниоров.

Насчет анализа данных- там без тестового, наверное сложно действительно будет. Но можно скажем так, тоже попытаться объяснить на квадратиках..

Нереально.

1 и 3 — программистские.

я бы маленькие екзешники не относил к программистским задачам в нашим реалиям- или что вам нужен специалист по визарду на работу? Где там ООП и алгоритмы?) В всплывающем окошке" хелло \вася,\ сколько тебе лет?"- как проверить уровень человека? А что-то более сложное никто не захочет делать.

Нереально.

возьмем на примере простого экселя.
Можно спрашивать -какие кнопочки нажимать и куда данные заносить,а можно погонять по статистическим формулам и по бизнес-моделям.

или что вам нужен специалист по визарду на работу

Ни один критерий технического интервью не является прямым, но этот позволяет проверить, реально ли сам сталкивался кандидат с разработкой подобного профиля.

А что-то более сложное никто не захочет делать.

На интервью — да. Поэтому все проверки должны быть относительно простые :)

а можно погонять по статистическим формулам и по бизнес-моделям.

Эксель не знаю, ничего тут не скажу. Но проверка знания формул и бизнес-моделей — независимая, хоть и тоже необходимая.

В компаниях до 50-100 человек можно вполне экселем обходиться для анализа внутренних данных)

при штате в 250 человек эксель тоже юзали:)

зависит от объема данных)

зневадження

О как. А театр— позорище.

Ну тогда и «отладку» забудьте.

вообщето работать работать можно єффєктивно, когда моск не отвлекать на паральние процесси типа «надо не забить вечером купить молока, не пропустить колл, а хто єто за окном шевелится ...»
шо можно показать на техсобес и тесте, ума не приложу, разве шо себя паказать і другіх посмотрєть, заодно по3,14ть прокачівая софтскіллz

Стресс у большинства людей ухудшает качество решений вообще-то.

Стресс — это нормальная форма работы с высокими требованиями/производительностью.

Точнее говоря, не стресс а давление. Стресса от этого быть не должно. Если стресс — в госслужбу на миску похлёбки.

Перевожу: гребцов надо лупить плёткой, иначе они сачкуют.

Кодерок дорвался до плетки? =)

Был он «духом» его гоняли. Стал «дедом» сам гоняет.

Я кодерок и знаю жизнь. Скажем, у меня оставалось в нынешней части заявки 130 часов до Нового Года (а это лишь 16 рабочих дней в декабре) — и я уж было собрался звонить агенту, чтобы зарезервировал мне побольше.

Но клиент уже сам обо всём позаботился, убрал срок до Нового года, вместо этого сделал срок до середины февраля и вывалил заказ на 500 часов.
Потому что, кто работает — того и грузят тот ест. :)

Макс, с такими друзьями как ты — враги нахрен не нужны.

Макс, с такими друзьями как ты — враги нахрен не нужны.

Кто не хочет работать — то будет получать июньскую зарплату «Украинского Синьора» (тм). :)

Максик, сдается мне, что ты и сам-то работать хрен умеешь, сидишь на социале.

сдается мне, что ты и сам-то работать хрен умеешь, сидишь на социале.

Не завидуй. Тебе-то жирный германский социал — неположен. :)

А мне он и не нужен, дурачок. Я считаю для себя постыдным воровать у государства, давшего тебе место работы и жилья. впрочем — ты только что ярко продемонстрировал свой совкизм, за что тебе отдельное данке шен. Постик заскринен.

Я считаю для себя постыдным воровать у государства, давшего тебе место работы и жилья

Не хочешь денег на шару?

А тебе и не дадут. :)

Я, в отличии от тебя, свою копейку зарабатываю и зарабатывал всегда честно.

Я, в отличии от тебя, свою копейку зарабатываю и зарабатывал всегда честно.

Копейку зарабатывать неинтересно. Лучше зарабатывать бакс. A ещё лучше — получать бесплатно. :)

П.С. Какой-то ты нервный. Под сокращение попал? Это может быть даже к лучшему — нечего протирать штаны на прожирании госбаблоса.

П.С. Какой-то ты нервный. Под сокращение попал? .

не-а. 8-)

Это может быть даже к лучшему — нечего протирать штаны на прожирании госбаблос

а ты завидуешь, да, мася ?

а ты завидуешь

Чел протирает штаны и получает за это госбаблос. Конечно завидую.

1. Я честно работаю на государство.
2. Протираешь штаны ты — ибо жрешь социал. Здоровый мужик живет на подачки — не стыдно ?
3. Если меня сократят — найду работу.

Здоровый мужик живет на подачки — не стыдно ?

Стыдно. Но что делать? Жажда халявы сильнее!

---ржот---
ну и хер с тобой.
только вот с этого времени — твои советы говна стоят.

только вот с этого времени — твои советы говна стоят.

Я, собственно, не претендовал. Так, балаболю от нечего делать. — благо, жирный германский социал оплачивает интернет тоже. :)

Я не совсем понял. У тебя зарплата в 3 раза больше, чем у среднего синиора в Мюнхене, и при этом еще и какая-то социалка?
А какие еще интересные факты о себе ты раскажешь?

и при этом еще и какая-то социалка?

Всё проще. Мог бы работать на проектах — но посмотришь на украинских госслужащих, и жажда халявы говорит в тебе: «Я тоже хочу протирать штаны за 4000 гривень/мес от государства!»

И ты бросаешь всё, садишься на жирный германский социал — и даже получаешь в месяц немного больше, чем украинские гос-халявщики. :)

П.С. Чё-то мой социальный интернет барахлит...

Вот для этого и существует лист бумаги с квадратиками и стрелочками. И если человек может обьяснить как решается задача на пальцах, то закодировать он ее точно сможет. Как побочный эффект — питонист может может успешно интервьюировать джавера.

У меня геймерская клавиатура с клавишами для макросов, и копировать/вырезать/вставить настроил на эти клавиши. И теперь выполнить эти простые операции на другой клавиатуре автоматически и быстро уже не могу — привык что нужно тыкать одну кнопку, а не 2-3.

Прийди со своей клавой. Тоже мне, неисполнимый каприз. Только не говори что она геймерская, тебя не поймут.

Та мне не надо никуда ходить, я фрилансер. Я пример привёл. Кстати с ней не придёшь — ей конфигуратор ещё нужно поставить и настройки подсунуть...

Какой в жопу «автоматизм в мозгах», если ты два раза из трех банально попадаешь на капсок вместо таба?

Я уже промолчу про индивидуально настроенные шорткаты и алиасы.

Это всё мишура хипстера-ламера. Монстры сидят в интерфейсе командной строки фри-бсд и пользуются мозгом, прежде чем давить кнопки (а мышки у них и вовсе нет, т.к. незачем). Bот это реальные кодерки.

Да и вообще, рискну предположить, что ты и понятия не имеешь, как выглядят реальные (а не хипстерские) билд-скрипты мало-мальски крупного кода. Они пишутся руками и не влезут в твой ИДЕ. :)

как выглядят реальные (а не хипстерские) билд-скрипты мало-мальски крупного кода. Они пишутся руками и не влезут в твой ИДЕ. :)

Рискну предположить что ты фанат говнокода и думаешь что это хардкор. Нет, файл не влезающий в IDE — это говнокод обычный. Сложно потому что через жопу.

Ты понятия не имеешь, о чём пишешь. :)

Я скорее согласен с m_d — в реальности сборка чего-то крупного это практически всегда весьма кастомный процесс комбинирования результатов отдельных частных сборок. И в IDE просто как файлы они влезут, но толку с этого никакого — IDE не сможет управлять их содержимым, будет максимум текстовым редактором.

Это не говнокод, скорее говноменеджмент управления сборкой, но такого подавляющее большинство, в основном из-за невозможности выделять каждый раз время на продумывание «красивого» решения. Вот и довольствуются тем, что кое-как оскриптовали.

Якщо код писати в текстовому редакторі, то ти автоматично будеш думати про всі ті проблеми, які можути виникнути з твоїм кодом в майбутньому. IDE дозволяє тобі писати лівою ногою та взагалі не замислюватися про архітектуру проекту. Класика жанру та апофеоз ідеїзації — розробники 1С.

Что за бред? IDE упрощает повторяющиеся задачи и нудные, но нужные операции, например когда на Java пишешь — куча вещей. IDE не имеет отношения к архитектуре.

Забей. Это же Шпак.
Эксперт по бизнеспроцессам, и написанию ентерпрайз систем за пол года в одиночку по требованиям из 10 предложений, написанных на листочке за чашкой кофе с гос-заказчиком.

Заздрити — дурна справа. Краще вчіться.

Пане Шпак, а як щодо різнокольорової підсвітки коду скриптів у vim ? От же ж хєрня,да ? тіки хардкор, тіки один колір !
Коротше, ти навіть уявлення не маєш, про що ти пишеш. Інтегровані середовища розробки були вже задовго до Дельфі — Watcom C 10 нa OS/2 — вже мав пристойний графічний інтерфейс й дозволяв шикарну як на ті часи , відладку навіть NLM модулів у реал-таймі з емулятором серверу Novell. IDE скорочує час розробки й робить її більш простою й як хочеш — надійною.

Ви дивні якісь, завжди обговорюєте якусь тезу, термін, вираз, замість того щоб обговорювати речення/думку цілком. Я в курсі, що саме робить середовище розробки. І я не казав, що воно погіршує швидкість розробки. Я казав, що воно робить вас ледачим. Ви припиняєте думати про інші аспекти, тому що вам зручно не думати про них. Приклад одинесників мені яскраво показав цей момент. Потім я багато разів чув фразу, що так писати не будемо, а будемо ось так, щоб IDE давало підказки. Це деформація. Ви починаєте підлаштовуватися під інструмент — ваш код стає гірше. А тепер уявіть систему, яка побудована на повному ігноруванні «правил» IDE. Скоріш за все, ви назвете її лайняною. Тому що замість осмислення підходу, ви будете мислити категоріями «є автосаджест» чи ні. Звичка.

А тепер уявіть систему, яка побудована на повному ігноруванні «правил» IDE.

Уявити можна що завгодно. Є реальний приклад?

Наприклад система, де використовується підхід ситуативного потоку виконання. Ви не знаєте що саме буде виконано, поки не почнете процес. В такому підході у вас будуть тонни хендлерів, якісь конфігурації, все буде мати уніфіковані абстрактні інтерфейси з нефіксованою структурою даних в середині. А ще додати сюди DBaaS...

Ви не знаєте що саме буде виконано, поки не почнете процес.

Будь-який GUI такий, і що? ;)

все буде мати уніфіковані абстрактні інтерфейси з нефіксованою структурою даних в середині.

Ой не факт.

Будь-який GUI такий, і що? ;)

Wrong. Більшість гуйні, яку зараз ліплять, імперативна всередені. Те, що юзер генерує події у випадковому порядку не значить, що й код обробників побудований за таким принципом. Уявіть собі, що ви ніколи не знаєте, що саме буде виконано при натисканні на кнопку. Тому що єдиного обробника не існує.

Ой не факт.

Що саме не факт?

Уявіть собі, що ви ніколи не знаєте, що саме буде виконано при натисканні на кнопку. Тому що єдиного обробника не існує.

Непідтримне. В морг.

Що саме не факт?

Нефіксовані структури даних.

Навіть на наскрізь дінамічних мовах намагаються фіксувати структури.

Непідтримне. В морг.

Саме цього я й очікував! Ви одразу відкидаєте варіанти, які не співпадають з вашою уявою про «правильне». Підтримка цього підходу не гірша та не складніша за класичні варіанти. А готовність до розширення та модифікації — в рази краща. Але ви про це ніколи не дізнаєтеся, бо мозок ще той ледацюга. З віком втрачає бажання змінювати роками відпрацьовані патерни.

Навіть на наскрізь дінамічних мовах намагаються фіксувати структури.

Це виключно тому, що мозок розробників, які намагаються збагнути повну динамічність, тріщить як кавун в руках волохатого таджика. Це визиває настільки великі протиріччя в їх свідомості, що вони намагаються в будь-який спосіб позбутися цього знання. Простіше назвати носія «токсичних» знань єретиком, ніж спробувати змінити власну уяву про «правильне» ;)
Підхід, про який я кажу, набагато ближчий до реальності яка нас оточює, ніж світ рожевих поні з IDE та ООП, до якого звикло 99% розробників.

Ви одразу відкидаєте варіанти, які не співпадають з вашою уявою про «правильне». Підтримка цього підходу не гірша та не складніша за класичні варіанти.

Докази в студію. Поки що я намірений вірити власному досвіду, а він показує, що система такого типу потребує в рази більше тестування, а її логіку звичайно не розуміють навіть автори.

Це виключно тому, що мозок розробників, які намагаються збагнути повну динамічність, тріщить як кавун в руках волохатого таджика.

Якщо з цього була б реальна користь, такі системи давно б існували навкруги. Є багато людей, яких складніть не лякає, а, навпаки, притягує. Майже все, що вни роблять, залишається академічними експериментами, але те, що реально корисне, виходить в промисловість. Може, Ви з таких. Тоді експериментуйте скільки завгодно, але не дивуйтесь, що результати нікому не потрібні.

Поки що я намірений вірити власному досвіду, а він показує, що система такого типу потребує в рази більше тестування

Ви неправильно підходите до тестування такої системи. Вона всередені дуже схожа на набір примітивних «цеглин», які мають фіксовану функціональність. Ви можете легко покривати тестами ці «цеглини», а можете цього зовсім не робити (якщо рівень програмістів трохи вищий). Бо ви майже ніколи не змінюєте ці «маленькі функціональні блоки», тому проганяти тести щоразу — дурна витрата часу. Єдине, що можна тестувати, так це саму «конфігурацію» флоу. А це можна робити інтеграційними тестами. Або інтегрувати тестування прямо в код (оцінка поточного стану та прийняття рішення). Або ви можете взагалі відмовитися від тестів, якщо побудувати систему по принципу «всі варіанти правильні та приймаються». При такому підході помилки є часткою дизайну, тому вони не призводять до негативних наслідків, а розрулюються системою як й звичайний безпомилковий флоу. І це я не кажу про тайкетчі.
Підводячі резюме, можу сказати наступне. Нова архітектура вимагає нових підходів до тестування. Старі інструменти не діють, і ви правильно на це акцентували увагу.

а її логіку звичайно не розуміють навіть автори.

Логіка системи проста, що двері. Навіть може бути простішою за інші класичні підходи. Та й коду в ній може бути в десяток разів меншим. Єдине що важко — це перебудувати свій мозок на цей підхід. Дуже хочеться повертатися на імперативщину і цей позив треба вирізати з себе каленим залізом.

Якщо з цього була б реальна користь, такі системи давно б існували навкруги.

Вони не існують тільки тому, що всі навкруги вчять та вчяться іншому. А якщо розповідати, що це працює, як я роблю зараз, то всі мене називають «єретиком» та намагаються спалити на кострищі. :D

А якщо розповідати, що це працює, як я роблю зараз, то всі мене називають «єретиком» та намагаються спалити на кострищі. :D

Ви не розповідаєте. Де хоч одна стаття з прикладом такої побудови? Хоча б у стилі хабра? Замість цього чутно тільки «ви без IDE нічого не вмієте». Ну, лементуйте в пустелі і далі :)
І не лестіть собі, до єретика вам ще як до Парижа пішки.

Ви не розповідаєте

Я не люблю засмічувати ефір тим, що від мене не хочуть почути. Тому якщо цікаво, то люди запитують, чому саме так я вважаю. Або ігнорують. А ще цікаве, я ніде не казав, що IDE — це погано. Я казав, що деформація під IDE — погана. Це різні речі. А коли ще й архітектуру проекта підганяють під можливості IDE — то це взагалі мене приводить до стану шоку.

А ще цікаве, я ніде не казав, що IDE — це погано. Я казав, що деформація під IDE — погана. Це різні речі.

Ай-яй-яй. Цитую:

>> Якщо код писати в текстовому редакторі, то ти автоматично будеш думати про всі ті проблеми, які можути виникнути з твоїм кодом в майбутньому. IDE дозволяє тобі писати лівою ногою та взагалі не замислюватися про архітектуру проекту.

це однозначно не «деформація під IDE», а саме використання IDE.

А тепер слухаю новий цикл жалоби про те, як вас «не розуміють».

Хм... Визнаю проблему, той коментар, який пояснював позицію, так й не був опублікований...

А зачем нужен непредсказуемый обработчик?
Это где такое чудо применяется?

А зачем нужен непредсказуемый обработчик?

А хто сказав, що він мусить бути один? А хто сказав, що саме обробник мусить бути непередбачуваним? Не плутайте процес виконання коду та обробник.

Это где такое чудо применяется?

Та де завгодно можна приміняти, починаючи від моделювання процесів (в тому числі й бізнес), закінчуючи UI.

Вам ніхто не казав,що ви демагог ?
Оце я перший і кажу.

Вам ніхто не казав,що ви демагог ?

Та мені чхати...

Оце я перший і кажу.

Полегшало на душі? Радий був допомогти!

Мені теж чхати на ваші високодумні роздуми ,які на ділі є пустопорожньою демагогією. Я вважаю, судяи з того що ви пишете — що ви все робите заради красного письменства. На душі в мене легко, було ,є й буде.
Я там трошечки вище навів цитату з шукшинського оповідання «Срєзал» , так от ви точнісінько той самий напівграмотний мужик Глєб, що всіх людей задовбує нісенітницями, заради того,щоб вважатися генієм в купки таких самих як і він. Заради Бога. «Срєзайте» Просто цікаво дивитися.

Мені теж чхати на ваші високодумні роздуми ,які на ділі є пустопорожньою демагогією.

Ага, вам настільки чхати, що ви навіть вирішили написати цілий опус заради цього? Ок, зрозуміло :D

щоб вважатися генієм в купки таких самих як і він

Вас це так сильно турбує? Я на вашу корону не зазіхаю, чесно. Те, що я роблю, оцінюють інші люди, які користуються результатами моєї роботи щодня. Ваша оцінка мені абсолютно індиферентна ;)

Ага, вам настільки чхати, що ви навіть вирішили написати цілий опус заради цього?

Має рацію. Бо когось же зібʼєте з глузду...

Та ви вросли своїми сідницями в ті теплі лампові підходи, що ви використовували роками, що все нове сприймаєте як загрозу власному існуванню. :D Валентине, програміст в моєму розумінні, це не той, хто пише програми. Це той, хто постійно шукає щось нове. Це дослідник в першу чергу.

Інжене́р — особа, що професійно займається інженерією, тобто на основі поєднання прикладних наукових знань, математики та винахідництва знаходить нові рішення технічних проблем.

Дослідництво — це процес аналізу даних та пошук нових рішень. Може бути й науковим.

Все це різні частини одного процесу.

Які такі наукові співробітники? Де я таке казав?

Що цікаво, ці два процесса навіть фінансуются по різному. Життедіяльність інженегра- зазвичай зарплата (ну з різним там БДСМ типу обіцянок — єстімейтів, досягнень та пролюблень і пробачень)
А о т у дослідника -то грантова система з цікавинами про звітність за потрачений не тільки тобою грант, ну і взаємовідносинами по типу науковий курятник.

Чому ви вчіпилися в професію/посаду як кліщ у собаку? Дослідництво — це процес аналізу, збору даних, розробки висновків, пропозицій тощо.

Бо чоткое поніманіє у нас есть (опіт панімаешь) — інженегру платятять за те щоб получилось(и какими путями не волнует, хоть аналізіруй хоть @#$%), а досліднику — за сам процесс і графіки у кінці.

Дайте відповідь, інженер моще щось досліджувати чи ні? А дослідник може робити різні цікаві прототипи під час дослідження?

А вы писали за свою жизнь хоть 1 проект, который требовал бы больше чем 3 человеко-месяца на реализацию?

Ой, міряння піпіськами почалося... :D
7 років на одному проекті. SaaS для корпоративних клієнтів. Вас влаштує така цифра?

Я б вас в машину посадив, в якій при повороті руля/натисненні на педаль ви не знаєте, що відбудеться. :)

А ви впевнені, що ви на 100% знаєте, що в цей час відбудеться в машині? Яким буде результат ваших дій? Я — ні. І не намагаюся дізнатися. Головне для мене ефект: машина їде, стоїть, гуркотить тощо.

Імперативщина та намагання все контролювати настільки вросли в ваш мозок, що ви навіть собі не можете уявити, що це не обов’язкова річ, що можна якось по-іншому вирішувати задачі.

Мені дуже сподобався один приклад, тому я постійно задаю запитання. Як правильно нагодувати кота в програмуванні? Можете використовувати абстрактну мову програмування.

Иметь блек бокс за интерфейсом хорошо только когда:
а. этот блек бокс не меняется, и ведет себя одинаково при каждом вызове
б. вам всеравно что этот блек бокс будет отдавать/делать.

Так что это нифига не сильвер булет, а просто вилка которую надо понимать где использовать, а где нет, и если кто-то не использует такой подход, а любит императивный стиль, то возможно это потому что императивных стиль подходит для решений подовляющего большинства повесдневных задач разработки.

а. этот блек бокс не меняется, и ведет себя одинаково при каждом вызове

Він може змінюватися разом із змінами системи. В іншому він працює абсолютно передбачувано.

б. вам всеравно что этот блек бокс будет отдавать/делать.

Ну, безглуздо працювати на /dev/null

то возможно это потому что императивных стиль подходит для решений подовляющего большинства повесдневных задач разработки.

Від нього неможливо повністю позбавитися. Обробники всередені все рівно імперативні.

Він може змінюватися разом із змінами системи. В іншому він працює абсолютно передбачувано.

Изменения блекбокса в такой системе будут не заметны до первой баги, тут или все тестами покрывать, или ждать нежданчика. В лучшем случае и то и то будут делать одни и те же программисты и будут держать все консистентным, в худшем ловить приветы в проде и на альтернативных энвайрментах.
А правда в том, что в реальной жизни, это как правило никому не нужно. Плюсы и минусы ровно те же что и в статической/динамической типизации, соответственно свою долю багов в придачу к динамичности вы отгребете.

Ну, безглуздо працювати на /dev/null

Действительно, прокси писать это вообще идиотизм... *facepalm*

Желание сделать гибкую и расширяемую/сименяему систему это хорошо, но не вижу как вам в этом мешает императивный подход к программированию, тут уже фанатизмом попахивает...

или ждать нежданчика

Очікування «нєжданчіка» — це вже присутність реакції і може бути закладено в архітектуру.

или все тестами покрывать,

Що саме ви хочете покрити тестами? Ситуативний потік виконання коду? У вас переходів зі стану А в стан В може бути сотні через різноманітні ланцюги.

В лучшем случае и то и то будут делать одни и те же программисты и будут держать все консистентным

Знову ж таки повертаємося до тотального контролю. Ви хоч раз бачили систему, яка складається з різних підсистем, та яка була на 100% стабільна в всьому? Консистентність потрібна для імперативного коду, бо без цього ви дійсно не зможете нічого зробити, але не треба переносити цю вимогу автоматично на інші підходи. Це шкодить тільки.

А правда в том, что в реальной жизни, это как правило никому не нужно.

Це найпростіша відмазка. Помітити щось як не потрібне та продовжити жити із базовими, теплими, ламповими налаштуваннями. Реальний світ не настільки простий, як вам здається, та процеси в ньому протікають без тих всіх спрощень, до яких звикли програмісти.

но не вижу как вам в этом мешает императивный подход к программированию

Тому що я ніколи не казав, що він мені заважає. Я ж вище писав, що від імперативного підходу позбавиться не вийде в будь-якому випадку. Але його треба приміняти там, де він доречний, а не крізь.

Вам відомий такий термін як «fault tolerance»? Ви своєю персоною є блискавичним прикладом такої системи ;)

Окей, есть хоть несколько конкретных примеров бизнес задач для разных прикладных областей/задач разработки?

Самое интересное, что те, с кем он спорит — как я, например — имеют как раз реальный опыт разработки таких приложений.
Например, SIP свитч — SIP весь асинхронный из собственного 4-уровневого стека, и в нём ситуации типа «тут с нижнего уровня неожиданно прилетело кирпичом» совершенно стандартны.
Или была разработка мониторинговой системы на Erlang/OTP. Компоненты падали и тут же восстанавливались, набирали данные для работы, динамически регулировали темп потока данных, и так далее. При этом нигде не водилось дедлоков и прочих проблем, типичных для параллельности.
И я ничуть не монстр в этом — есть сильно помонстрее народ :) я, например, не работаю с вебом, где сейчас промис на промисе сидит и асинком погоняет.
Поэтому я к этим рассказам типа «вы нифига не умеете в настоящую динамику» отношусь, мягко говоря, скептически :)

Самое интересное, что те, с кем он спорит — как я, например — имеют как раз реальный опыт разработки таких приложений.

Та знаю, разом працювали надцять років тому. А ще цікаве, ми маємо купу спільних знайомих.

Например, SIP свитч — SIP весь асинхронный

На підхід із ситуативним потоком виконання синхронність чи асинхронність майже не впливає. Процес виконання може бути синхронним, хоча вхід в цей потік може бути асинхронним. А можна й асинхронним зробити повністю, але така система буде складнішою.

где сейчас промис на промисе сидит и асинком погоняет.

Там немає нічого складного. Під капотом все ті ж теплі лампові колбеки. Але це фіксований флоу, імперативщина в іншій обгортці.

Поэтому я к этим рассказам типа «вы нифига не умеете в настоящую динамику» отношусь, мягко говоря, скептически :)

Я такого не казав.

Легко. Процес підписання/розірвання договору. Процес прийняття рішення про видачу кредита. Процес активації послуги. Всі UI-задачі.

А ви впевнені, що ви на 100% знаєте, що в цей час відбудеться в машині?

ні

Яким буде результат ваших дій?

так.
при повороті руля вправо буде поворот саме вправо, при натисненні педалі газу буде прискорення, а при натисненні на гальма — гальмування.
Варіанти, коли при натисненні на кнопку результат невідомий, хороші при генерації випадкових чисел. :)

Як правильно нагодувати кота в програмуванні? Можете використовувати абстрактну мову програмування.

яке запитання, така і відповідь -
на абстрактній мові програмування це так і буде виглядати: «нагодувати кота».
На неабстрактній мові програмування задача не має рішення, доки ви не дасте чітке визначення процесу «нагодувати» (скажу більше — оскільки «нагодувати» має одним з контекстів отримання чіткого фідбеку від того, кого ви годуєте, а думки кота ви читати не вмієте, то визначити, чи ви його «нагодували» неможливо).

при повороті руля вправо буде поворот саме вправо, при натисненні педалі газу буде прискорення, а при натисненні на гальма — гальмування.

Це ваша гіпотеза, що все буде відбуватися саме так. На практиці все дуже залежить від обставин. При занесеннях реакція на руль може бути прямо протилежною, якщо ви не увімкнете передачу, ви нікуди не поїдете, а гальма на льоді не спрацюють. Але ви ж програміст, у вас ідеальна система і ви гадаєте, що саме ви контролюєте ситуацію. :D

Варіанти, коли при натисненні на кнопку результат невідомий,

Ви починаєте сперечатися із своїми ж фантазіями. Тут я вам не опонент. При натисненні на кнопку результат буде залижити від обставин, які існують на даний момент в системі. Відчуваєте різницю?

на абстрактній мові програмування це так і буде виглядати: «нагодувати кота».

Це не буде працювати.

Ви путаєте взаємодію водія з інтерфейсом машини з взаємодією машини з навколишнім середовищем. Коли я натискаю на кнопки склопідйомника (це щоб виключити фантазії про танці на льоду), то скло або підіймається, або опускається, в залежності від того, яку кнопку я нажму. Ця поведінка детермінована і аж ніяк не

Уявіть собі, що ви ніколи не знаєте, що саме буде виконано при натисканні на кнопку. Тому що єдиного обробника не існує.

P.S.

Це не буде працювати.

Ок. :)

Ця поведінка детермінована

Виключно в вашій голові. Спробуйте натискати кнопку склопідйомника в машині, в якій не увімкнено ключа. Ніяких

то скло або підіймається, або опускається, в залежності від того, яку кнопку я нажму.

не буде. Буде повна тиша й відсутність реакції. Ви спростили систему до того вигляду, який вам здається достатнім. Але реальна складність системи набагато вища.

Ок. :)

Кіт — самодостатня система, його не треба годувати, він їсть майже завжди сам. Тому варіант «людина годує кота» — небезпечне спрощення реального світу й призводить до сайд-ефектів у вигляді зайвого ускладнення системи та збільшення рівня абстракцій, якщо в системі з’являться ще один кіт, собака, лемінг, ще пару людей, сусідська миска із їжею.

Буде повна тиша й відсутність реакції.

о, так, а ще буде відсутність реакції, якщо в машині не буде аккумулятора, відсутня електропроводка, несправний електропривід і безліч інших причин.
а якщо клавіатуру від ПК відключити, при натисненні на кнопки також буде відсутність реакції.
і все це не має жодного відношення до теми обробки події від натиснення кнопки.
P.S.
А з «годуванням кота» — ви спочатку визначіться з постановкою задачі, а не займайтеся словоблудством. Тому що в «реальному світі», уявіть собі, слів взагалі не існує — ці «абстракції» і «небезпечні спрощення» придумали люди.

і все це не має жодного відношення до теми обробки події від натиснення кнопки.

Якщо постійно спрощувати все, якщо розглядати сам процес виключно окремо від інших процесів і систем, то відношення дійсно не має. Але такі спрощення ніфіга не спрощують життя. Ми маємо не просто кнопку, скло, двигун, елемент живлення та «реле», а поєднання різних систем в одну. Склом можна керувати з декількох кнопок водночас, в тому числі й дістанційно в одну, або в обидві сторони. Тому спрощення кнопка<=>скло в коді може сильно пожартувати над вами.

А з «годуванням кота» — ви спочатку визначіться з постановкою задачі, а не займайтеся словоблудством.

Я вам можу продовжити розповідати, що таке «годування кота». Це процес обміну сигналами між різними системами.

Якщо ви постійно вручну робите задачі, які нудні та ще й повторюються, вам треба переосмислити свою роботу та підходи.

Я просто лінива людина. Не люблю робити дурну роботу. Саме тому я скоріше напишу конструктор, а потім вже на DSL буду вирішувати задачу, а не довбатися роками із нудними задачами.
А за маєчку дякую, прийму із задоволенням.

Лол. Делфі давно показала, що IDE може деформувати програмістів.

Бгг, байтослесарь против байтофрезеровщиков

Чоловіче добрий, ти мені нагадуєш одного гаврика в ОЦ одного з заводів де я був на практиці. Так вот, було йому оце так як мені зараз −50 і він кожен ранок починав зі слів «Вот ви, с етой вашей пласмасовой балалайкой натовской нікада нє поймьотє радості и труда отладкі программи на пєрфолєнтах». Він пив чай з засмальцьованої чашки, переклав на нас всю свою роботу й весь час читав щось про мандали, реріхів і злобних жидів, мучівших народ русскій. Як кажуть, він починав все як не з глушковим, найкращим способом вводу програмного коду вважав телетайп з перфолєнтою, а ІВМ РС вважав «жи...ской правакацієй протів нашей родіни» . Нас він ненавидів, бо ми «дуже вже легко все отримуємо а папробовалі б ви..» Коротше, пане Жук, ото ви точнісінько такий самий.

А можна це було кудись викласти, на якийсь пейстбін наприклад?

Добре, що ви усвідомили, що не треба такі неформатовані простирадла коду сюди постити. Але головний посил залишився нерозкритим. Що було для вас настільки непридатним в тому коді?
Якщо «бізнес-логіка в onClick обробниках», то для програми такого розміру и такої зовсім не складної функціональності це ніяк не проблема.

Отак і множаться фантазери, які можуть тільки волати про свої суперздібності без IDE і взагалі без компʼютера, напряму крізь астрал.

Кстаті, пане Жук, а я колись був на Дельфі писав — навіть змайстрував не одне ISAPI творєніє які працювали і працювали добре. Чого ви так докопалися до цього інструменту — не розумію.

Ще згадав одне шикарне порівняння. Ви як той шохвьор на зілку стопісятому, він же захар — до водія, що їздить на Сканії — «отето ти как кароль єдіш, а вот попаді ти на сєвєра ілі там на алтай в гори я б на тібя пасматрєл. В мєня нєт всєх етіх тваїм бабскіх ізвращєній зато я магу матор з кабіни пачініть, а ти как поц будєш ждать тєхнічьку». Десь таке.

Ты и в туалет ходишь «во двор» до сих пор, ведь унитаз (IDE) переусложненный механизм для тебя?

Любителі IDE нагадують любителів дореволюційної ортографії, які стверджували, що без ѣ, ѳ та ѹ неможливо писати.

По-перше, це ви кажете про російську орфографію (не варто передавати куті меду й давати грецьке th як т — воно в нас редукується в ф) . То як торкаєтеся таких питань, мусили б знати, що насправді всі аргументи тих дядєй зводилися до одного «она настолько сложна, что владєть правопісанієм можєт только истінно образованний чєловєк, чьто атлічаєт єво от простолюдіна» — що повністю підходить під вас із вашим колегою Шпаком , що мовляв «не розумієте ви сурової правди командної лінійки. вот ми тут такі офігєзні, в умі всьо компілюємо, а ви .барани, тіки в сває дєльхві шось ригаєте».
По-друге. Всі ті загогуліни російської абетки прекрасно розуміли українці, бо десь з 95 відсотків слів з ятєм повністю співвідносні з українськими візаві, дє є «і» (було небагато виключень). Фіта й оу були лише в словах запозичених з церковнослов’янської та грецької. Ну єр на кінці слова- то таке. Так що знов ви плюнули на мене, а обгидили себе, порівнявши себе з пихатим русскім дворяніном, все досягнення якого було те, що він знав всі граматичні правила.
По-третє. В українській мові подібна реформа пройшла у 1919 році,здається (не дивлюся у вікі) — прибрали єри, фіти, омеги, тощо, впорядкували граматику і до нас те що ви кажете — не стосується.

які стверджували, що без ѣ, ѳ та ѹ неможливо писати.

«ѹ» була викинута ще Петрівською реформою 1708р. Ви, мабуть, згадали про іжицю — Ѵ/ѵ. Вона значила або «і» (мѵро), або «в» (єѵангеліє), і походить напряму від давньогрецької Υ.
Ретельніше треба у деталях :)

За суттю — це саме любителі все робити тільки через командний рядок і прості редактори нагадують таких апологетів старої орфографії, а не прихильники IDE. Ваша аналогія строго протилежна реальності.

гіпстери викинули IDE на мороз.

Ага-ага. Щось не бачу тотального переходу хоча б до vim :)

Подібним чином реагують мешканці ЗУ на атеїстів

От не треба ще й релігію до цього домішувать.

Так я тобі скажу, колись і я таки думав шо воно старий п... і нічого він не поніма в ковбасних обрезках, а ото ж таки дожився, столкнувся з разнимі процессами жабогадючих взаємовідносин на стикє С та Жаби і таки я пронікся, таки він дійсно правий. Просто він зрозумінням суті древних збочень так розвив силу, що вона йому допомагала і роботу перекладати на тупий молодняк, і про народ русський узнать, якого тольки хто не угнетал да.
А насчот чашки — сам себя поймал на єтом, бо тольки что послал молодняк в пешей поход за проедложение чашку отміть от чайніх наслоений— бо у кітайцев чайник для заварки не моют, и чем древнее тем лучше

Понімаєте, Афрікан Свиридович, кал — він разний буває © Тут дєло було в том, шо цей товаріщ щітал сібя нєв’єбєзним мамонтом і програмістом і з мов програмування знав тільки якусь хитру зборку Фортрана для старої ЕС — забув вже й марку того гроба+ ще щось хитре . Але той завод отримав 5 286-х машин з 20 Мб вінчестерами ,що для кінця 80-х було шо найновіший макбук для хіпстера. Плюс — ті машинки можна було об’єднати у мережу 10Base2 бо там були мережеві карти й був DOS 3.30 з хитрим софтом, на який предполагалося закинути щось корисне для того заводу . В общім все це лягло на того дядька, а він ну дуже не хотів все те робити, всіляко тягнув з впровадженням. причому — в нього була докумнтація російською мовою на все те , причому фірмова, штатівська — яку він здав у перший відділ заводу, назвавши її особлио важливою і секретною — і нам її давали тільки за його підписом — два рази — на початку практики .А потім, як в нас почала підніматися мережа з тих машин (там був Netware 2.1 на одній з машин !!!!) і ми змогли те все запустити — дядько почав нам тупо шкодити й називати нас «проходімцамі, нє понімающімі вєлікой суті вичтєхнікі с етімі вашімі ігрушкамі » коротше, жаль було звідти йти...да. но нам поставили підпис на листі про практику — і все. А потім нам сказали що той дядя все навернув, але приїхали американськиіспеци, які те все в рамках співробітництва привозили й його погнали з роботи. він спився з горя.Ото таке. Так я до чого ? дядя був банальний лінтяюга. який не розмів.що світ змінюється й змінюється капітально, що вже не буде того що було, що часи великих героїв, в умі пишучих на асемблері — пройшли, що колишні заслуги й досвід треба використовувати для надбання нового а не на могилний памнятничок сєбє любімому. Десь так.

колишні заслуги й досвід треба використовувати для надбання нового а не на могилний памнятничок сєбє любімому

Золотиє слова Соломон Опанасовичу. Підняли настрій перед віклістендапшоу. Спасибі

О, точно такая же фигня и у меня была на практике после третьего курса. Проходила практику в типичной конторке на территории Кибцентра, которая в девяностые пережила превращение из совкового учреждения с непроизносимым аббревиатурным названием в акционерное предприятие. Определили в отдел, где было три человека — начальник лет под 60, его зам такого же возраста и мальчик 25 лет, хз как туда попавший. Надо ли говорить, что начальник со своим друганом только читали новости и трепались, а делал работу, ездил в командировки (понятное дело, что не в Италию, а куда-то в Кременчуг или Луцк) тот самый мальчик.
А первое впечатление помню до сих пор: захожу в первый раз в кабинет, а начальник прям за столом ест селедку и шевелит вымазанными в масле от этой селедки усищами.

О, эти видимо еще сумели как-то проскочить из советских времен.Сочувствую.

Инкиб и сейчас не сильно отличается :(

Та тут не в еде дело.
А в ...собственно говоря во внешнем виде кушающего.Сидит дядя, мало того шо жрет вонючую рыбу, так еще повымазывался. Буээээ...

, это америкен стайл есть за своим рабочим местом или на митинге

есть на митинге сидя на полу в уголка кабинета)

захожу в первый раз в кабинет, а начальник прям за столом ест селедку и шевелит вымазанными в масле от этой селедки усищами.

Вы так художественно описываете

например когда на Java пишешь — куча вещей

Вы про автогенерацию тысяч getXXX/setXXX?

Приєднуюся до запитання. А то всі так смачно розповідають про прискорення роботи...

В основном все же компиляция, где нужно добавить classpath естественно, вручную добавлять в командной строке сотни / тысячи jar-ников ой как утомительно. Сюда же автодополнение Spring-о-вых классов , подсказка сигнатур методов , дебаг же !!! Как в нотепад дебажить ? Ололо !!! Или сотни SQL-Ек писать

Или сотни SQL-Ек писать

o_O

Это в основном чем занимается Java developer на современных проектах , Java там и не пахнет , от силы 5-10% от всего остального.

Или сотни SQL-Ек писать

Я так думал уж в суровом жаве давно придумали ДСЛ какой-нибудь напрямую абстрагирующий а оно вона оно как ))

Придумали, и более одного.

ОРМ мішок та маленький кошик (хоча я особисто вважаю це позаминулим сторіччям). Але програмісти настільки суворі, що продовжують писати п’юр-сікуєль в своїх теплих лампових ідеєшечках...
Як жеж нудно я живу...

Просто потому что ОРМ — defective by design и жизнь имеет только из-за CRUD’ов

Крім ORM існує декілька аналогів LINQ (називаю так, бо останнє більш галасно відоме) і там ORM нема, а руками SQLки не пишуть.

LINQ

Разве это не почти тоже самое, что писать SQL руками (ну да, есть некоторая возможность компайл-тайм проверок, но всё же)

Нет, потому что даже ряд вполне простых типовых запросов очень по-разному транслируется на разные диалекты SQL, а задалбываться этим вручную после каждой мелкой переделки запроса — мягко говоря, марудно.

Просто в результате происходит переход к некоторому наибольшему общему подмножеству всех функций, реализованных в каждому диалекте и продвинутые фичи становятся внезапно недоступными

Вот тут с 15:30, например, insert-with-update — можно посмотреть, как по-разному он реализуется в разных базах.
Ещё совершенно по-разному надо задавать limit+offset.
Но внешний слой, которому это задано на уровне функциональных описаний, знает необходимые слова для каждого движка.

Может и придумали , но суровая индусятина как писала на уровне 2002 года так и пишет, а нам, соответсвенно, тоже с этих рельсов далеко не уйти ((((

Ну не вечно. Что-то в редакторе (уровня vim) даже быстрее. Но нормально можно считать, что IDE ускоряет процессы в 2-10 раз.

Оно актуально и работает. Если кому-то это древность — «ну извините» (© Вовочка)

А как еще файлы по ssh редактировать-то? Через nano/mcedit?

:wq

Які саме процеси прискорює IDE?

Автодоповнення декількох видів (імʼя змінної, функції, аргументи, типи).
Миттєвий фоновий аналіз коду і генерація підказок по використанню, помітка помилок.
Допомога у типових операціях на зразок «поставити імпорт для цього класу».
Підсвітка/помітки на основі семантики — наприклад, чи є метод перекриваючим відповідний базового класу (без такого потрібно було б дати атрибут типу @Override в Java і перевірити компіляцією).
Пошук тексту функції/методу, що визивається, або перехід між декларацією і визначенням. Вкрай зручно для вирішення питання «що це визивається тут?» І навпаки — пошук всіх місць, де щось визивається, і зручний їх перебір.
Генерація «візардами» початкового скелету — від окремої функції аж до повного застосунку.
Візуальне редагування графічного дизайну.
Рефакторінги всіх видів.
Вбудований зневадник з багатою функціональністю.

Це тільки найголовніше, я навмисно не заглядав в жодне IDE, поки писав.

Приймається.
Моя особиста думка з цього переліку. Більшість автоматизацій показують або недоліки дизайну мови програмування, або нетрадиційний спосіб використання IDE (візуальне редагування графічного дизайну).
Єдине, що можна хоч якось записати в плюси, це рефакторінг. Але з ним теж купа проблем. Почнемо з того, що IDE не чистить зайвий код, який вже не використовується, після рефакторінгу.

Більшість автоматизацій показують або недоліки дизайну мови програмування,

Еге ж, вона не вміє читати мої думки.

нетрадиційний спосіб використання IDE (візуальне редагування графічного дизайну)

Цілковито традиційний.

Почнемо з того, що IDE не чистить зайвий код, який вже не використовується, після рефакторінгу.

Приклад в студію, з точними версіями. А так — ніхто не обіцяв, що воно зробить все за тебе.

Шаблонізатори працюють і без IDE

Але незручно.

Це цікаво хіба під desktop.

А також під мобілки і під взагалі усе, де є візуалізація.

Так, це допомагає при роботі з legacy. Але яке legacy на співбесіді?

Таке, яке гарно імітує майбутнє лєгасі (яке буде за будь-яких обставин). І чому тільки лєгасі? В новому коді теж бувають дивні обставини...

Ось і виросло покоління розбробників, які сповідують принципи IDE driven development...

А років 30 тому назад казали «ось і виросло покоління розробників, які сповідують принципи display driven development. Всі ці текстові редактори — для мавп і говнокодерів. Справжні програмісти друкують перфокарти і патчать бінарники побайтно з IMASPZAP.»
Олександре, Ви таке типове верзете...

Хардкорные программисты прямо на лампах программируют, а перфокарты — хипстерский лепет.

Так далеко в прошлое я не планировал забираться :)

коли ти программуеш на перфокарті чи лампі ти програмуєш у двійковому коді

А вы перфокарты в глаза видели? Вообще-то, каждая перфокарта — это одна текстовая строка, 80 символов, не больше не меньше

И таки хватает, что характерно.
Хотя временами выглядит коряво.

80 байт. Не обязательно текстовая. Вот стандарт для представления всех 256 значений (для ЕСок — смотреть таблицы для ДКОИ).

Это использовалось, например, при загрузке диагностического комплекта или для начала генерации ОС. Подаётся вначале 1 перфокарта с 24 байтами (адрес перехода плюс два CCW; CCW описывает длину «бутблока», как сейчас бы это назвали), затем нужное количество 80-байтовых порций «бутблока».

Но 99.9% программистов таки двоичные представления не использовали, а на перфокартах набивали тексты в Fortran, PL/1 и управляющие команды на JCL.

В массе таки использовали перфораторы с клавиатурами.
И основные символы очень легко читались — например, 12+1...12+9 это латинские A..I.

Програма на асемблері — це байтова репрезентація чи текстова?
А якщо вона ще передається крізь транспорт з допоміжним кодуванням, як, наприклад, біти парності в RS232?

Не думаю, що хтось ще масово погодиться з цим.

А до этого вообще программы не писали, а паяли.

Даже вспоминать того ужаса не хочу.

Собственно, основной ужас того времени был не в средствах самих по себе, а в некачественности техники, в экономии на спичках и в тупых режимных запретах.
Диски, которые нельзя было переставить на соседний дисковод (системы 5061), чтобы они читались без проблем.
Тексты студенческих программ в лучшем случае на перфокартах, которые будут рассыпаны и неправильно собраны, а то и просто на бланках, которые набирали 70-рублёвые девочки-операторы со средним темпом опечаток — одна на десять строк.
И так далее.
Где не было таких проблем — нормально работали.

На фортране тех времён (Fortran IV) GOTO был неизбежен. Из структурных операторов привычного нам вида там был только DO — оператор цикла по диапазону целых (как в Паскале for i := 1 to 10).
Структурные развилки и циклы это уже Fortran 77, но к нам эти версии массово добрались уже в конце 80-х.
Разумеется, толковые авторы писали так, что фактически программа соответствовала нормам структурного программирования, но это надо было ещё осознать по результатам чтения кода.

Доступный сейчас код библиотек типа BLAS в основном написан всё в том же стиле, и читать его несколько непривычно. :)

(повторююсь) Схоже, тільки для Вас :)

В художніх — так, рідко.
В підручниках/довідниках/ітд. — норма.

бывают интерактивные книги:
www.e-reading.club/book.php?book=101290
тут после каждой страницы- есть три-четыре ссылки, с какой страницы продолжать читать от вашего выбора.

Не ображайтеся, але ви дуже сильно помиляєтеся. Асемблер — це всього-навсього текстове уявлення низькорівневого коду. Простіше робити для нього компілятор, ото й усе (та й то — відносно).

И даже не так. Лопатой можно копать, но не тогда, когда ты приходишь на следующий день, а траншею кто-то обвалил, и начинаешь всё заново. Там и экскаватор не помогал.

Сейчас эти проблемы ненадёжности решаются всего лишь чуть-чуть бо́льшими затратами, и админмерами типа «не забыть в пятницу забэкапиться».

Олександре, Ви таке типове верзете...

Валентине, якщо моя думка не співпадає з вашою, це не значить, що я щось вержу :) Задайтеся запитанням, чому інструмент прискорює вашу роботу? Що саме в ньому реалізовано та які процеси автоматизовано. А тепер придумайте систему, в якій ця автоматизація безглузда. Чисто задача на «помоделювати». Це не просто розминка для мізків, це один із способів розширення кругозору. Це цікавіше, ніж колупатися в VoIP, мені здається ;)

Энтерпрайзы (и индусы их пищущие) не умеют в модульность )

Да и вообще, рискну предположить, что ты и понятия не имеешь, как выглядят реальные (а не хипстерские) билд-скрипты мало-мальски крупного кода.

Рискну предположить,что vim и командную строку ты видел через плечо чувака которому подносил кофе с булочкой.

оно социальамт, какое там кофе с булочкой ? подайте фрау меркель на жызнь гонимому максику , его злобные погромизды обижайуд.

подайте фрау меркель на жызнь гонимому максику , его злобные погромизды обижайуд.

Все эти рассказки были бы хороши — если бы их писал кто-то иной, а не ленивый прожиратель нищенского украинского госбаблоса.

Зачем у бабки пенсию отъедаешь?

Максег, я работаю, в отличии от тебя,шарящегося по жж и форумам.

я работаю, в отличии от тебя,шарящегося по жж и форумам

Совки тоже считали, что работали. :)
И как, много наработали?

Впрочем, какова «работа» в госбюджетной богодельне — такова там и «оплата». Но всё же, бабку-пенсионерку объедать некрасиво.

Рискну предположить,что vim и командную строку ты видел через плечо чувака которому подносил кофе с булочкой.

Вим это хипстерщина. я пользую старый-добрый ламповый ви.

А вообще, сразу видно ламера, который где-то услышал умное слово — но так и не понял, как этим словом пользоваться.
Посмотрю я на тебя с вимом (который, рискну предположить, ты и в глаза не видел) — если тебе дадут терминал к какому нибудь эйчпуксу или соляре, где ви в стандартной инсталляции, а вима нэт. (И эклипса или в какой хрени ты там «индивидуально-настраиваешь шорткаты» — тоже нэт). :)

так вы и до Кобола скоро докатитесь)

Можно. С такими тёплыми ламповыми диверсиями — работой будем всегда обеспечены.

где ж вы в наших реалиях работу найдет? Я даже не знаю ,есть ли в Украине айбиэмовские фреймы на коболе.

Ну да, эта работа специфична — через океан не аутсорсится.

если тебе дадут терминал к какому нибудь эйчпуксу или соляре,

configure && make && make install либо генту в префикс

Пофигу. Даже если другая клавиатура или схема подсветки кода, человек уже потеряет половину своего автоматизма.

Половину — может быть. Но не весь. На это надо сделать поправку, но оставшейся половины должно быть вполне достаточно, чтобы оценить на уровне такого первого-второго интервью.
При этом вполне нормальна ситуация типа «ой, я три года с Idea проработал, а где в вашем netbeans такая функция?»

Разве что со своим ноутбуком приходить.

Это уже следующий этап. Только что делать тем, у кого рабочий десктоп, как я? ;\
(Хм, я понял, почему гребцы любят лаптопы.)

Половину — может быть. Но не весь. На это надо сделать поправку, но оставшейся половины должно быть вполне достаточно, чтобы оценить на уровне такого первого-второго интервью.

В смысле на это всегда надо делать скидку.
А в целом, конечно, лист бумаги и квадратики-стрелочки — наше все.

Половину — может быть. Но не весь.

В мене була кумедна ситуація. Був присутній на деяких співбесідах на посаду 1C-розробника. Всім давали однакове завдання, дуже просте, на знання базових алгоритмів, навіть шкільного рівня. Умова одна — писати код на папірці. 100 відсотків з кандидатів казали одну й ту саму фразу: «Я точно не пам’ятаю, як воно пишеться, я завжди автокомпліт використовую.» Писали не просто маячню, там була просто феєрична дурня записана.

Наши: Назовите сигнатуру методов класса SpringAPiХуеМое?
«Я точно не пам’ятаю, як воно пишеться, я завжди автокомпліт використовую.»

Пам’ятаю, хтось на ДОУ розповідав, що у нього готовий докер-контейнер з IDE і всіма плюшками. Все, що потрібно — скачати його і розгорнути.

І от приходить він такий з контейнером для Linux, а там тільки Windows 7.

а если преступник посыпал пол толченым стеклом? ©

Есть и такой вариант. Но вероятность попасть на Windows слишком велика, чтобы её игнорировать.
Можно иметь 2-3 таких контейнера :) но свой лаптоп проще.

Вот такую работу — однозначно в /dev/null.

І плем′я індусів забиває дрючками мамонта

Увы, только слона. И то забивать сами не будут, а сделают крайним белого.

Для теста, для которого существенно использование IDE или какой-то специфической тулзы (да хоть /bin/sh), надо требовать установленный и настроенный комп с такой тулзой. Но таких задач не все.

Есть простой и элементарный способ: предупредить, что собеседование (и дальнейшая работа) будет производиться при помощи IDE такой-то, тулзами такими-то. Пусть кандидат и не выучит конкретную IDE полностью, но базовыми инструментами овладеть может элементарно, и не искать на собесе как скомпилить JAR или импортировать класс.

Да, HR очень боятся, что если кандидату заранее рассказать что будут спрашивать — он придёт подготовленным и тогда его некак будет грузить (и вылизывать своё ЧСВ). Но бдлджад, если есть люди которые способны по одной команде на email быстро освоить всё что нужно для работы к дате DD.MM, — нахера брать кого-то ещё? Это же лучшие работники! Явно лучше тех, кому в начале спринта полчаса втираешь ТЗ, а к концу оказывается что мальчег провтыкал что чему розповидалы.

В последний месяц я провёл кучу технических собеседований. Что я спрашиваю:
1. Основы Java
2. Многопоточность
3. Технологии(обычно, спринг/хибернейт)
4. Базы данных

Что спрашивали у меня. Из последнего
1. Расскажите, как смоделировать движение шарика в жидкости(вакансия на разработку eclipse RCP) Ну вот нафига? Ну да, делал я такое, но зачем тратить время собеседования на не относящееся к специальности?
2. Как ВНУТРИ работает сборщик мусора в Java, как бы вы писали свой. Ну да-ну да, для водителя мусоровоза конечно очень важно знать математические основы работы двигателя. Диффуравнение там написать. Важно, чо!
3. Алгоритмы поиска на графе. Для веб разработчика, ага-ага. Ну знаю я их, даже статьюкогда то писал, но вам — то зачем?

Прямо статью хочется написать:"как не надо собеседовать"

2. Многопоточность

Умение ручками синхронизировать потоки, и определение volatile или что-то прикладное?

Опустить мютекс и напрячься...

Ой, всё. Чувак, тут люди хотя бы своими словами рассказали как поток запустить и что такое синхронизация

Счастливый. Мне исходники тестового в ворде присылали. И на вопрос «А как его скомпилировать?» отвечали «А что, его надо компилировать? Я просто написал...»

Умение ручками синхронизировать потоки, и определение volatile

я так понимаю что это то, что у многих синьйоров вызывает проблемы?

какой размер матриц? И ссылку на то как делать умножения матриц (я матан не помню)

1. По 23МБ на матрицу — фигня
2. Посмотрел алгоритм. На вид — должно идеально параллелиться.
3. Одну из матриц я бы транспонировал, чтоб доступ к элементам был последовательным -> больше cache hit’ов
4. Подозреваю, одна из проблем — конфликт между ядрами, когда оба ядра пытаются доступиться к одному и тому же блоку в памяти.
4.а) Либо сделал бы дубликаты матриц для каждого потока (нужно посмотреть чтоб это не занимало больше времени чем сама обработка)
4.б) Если а) не подходит, тогда бы какие-то средства использовал чтоб снизить вероятность конфликтов (например, делать проход по элементам с разным шагом).
5. Дополнительно убедиться, что у потоки не шарят общие кеш-линии для каких-то объектов
6. Код писать лень.

PS Смотрел агоритм «в лоб», описанный здесь ru.wikipedia.org/wiki/Умножение_матриц

Ты вопрос задай ©. Я не получил от тебя чек на $100 чтоб потратить 2 часа на написание кода. Если есть конкретные вопросы как решить определенный затык в многопоточном алоритме — спрашивай.

ты прикольный. Задал тут задачку, с которой большинство никогда не сталкивалось, и «дайте мне алгоритм сходу». Любой тут таких задачек найдет кучу. С этой задачей надо садиться и разбираться. Сходу никто решение не выдаст, конечно же. Если тебе от этого будет лучше на душе — то да, мы все профаны и не шарим в многопоточности.

Витя, я же тебя тут даже примитивами синхронизации не грузил, просто объяснил где затыки будут. В качестве пруфа мог бы написать код, который при наличии честных свободных 8 ядер будет тебе давать 8х, но смысл мне тратить время и тебе что-то доказывать?

Если ты на такой элементарной задачке в свое время завис — не нужно думать, что здесь все такие медленные.

Так она точно так же как вообще программирование — для HP, HA или просто асинхронного выполнения это совершенно разные задачи и подходы.
И знание многонитевости и прочей параллельности для веба никак не даст качественное быстрое умножение матриц, и наоборот.
Поэтому не обязательно «нули», просто другая специфика.

Проблема возникает потом, когда эти мютексы суют куда не попадя. Просто потому что выучили что «так правильно». Эх, как оно потом глючит! Какие там потом дедлоки возникают! А уж падает оно совершенно феерически и всегда в разных местах.

Эх, почитаешь комментарии и задумываешся — нужно было в универе внимательно слушать предметы по программированию компьютерных систем. Там как раз и рассказывали и о различных паралельных системах (заточенные процы), о случаях общей и распределенной памяти, и о специфике компиляторов. А потом — стоп — да мне в работе это и близко не нужно на данный момент.

Спросит кто? У нас сейчас не то что с профильным, редко кто вообще с высшим образованием. Так что не спросят. Спросят про сортировку ну и этих, «обедающих философов» (поняти не имею вообще что это).

особенно улыбает когда спршивают многопоточность там гдее и в промине нет и не предвидится!

Я думал что в приличных вузах разбирают многопоточность анализируя как FFTW сделан. Вот уж что вылизано как яйца мамонта! Причем в реализациях начиная от клястоеров и до чего-то убогово. Это даже фактически стандартный тест для мерянья пиписьками среди производительностики клястеров.

Я про эту библиотеку. www.fftw.org

все наизусть знать не надо, но примитивы, хотя бы какие есть и как это все работает, с точки зрения хотя-бы API, знать необходимо. А то потом сохраняют стейт запроса в статик поле или в код, исполняемый на экзекьюторах, впиливают тред локалы. Или переменные без volatile для обмена данными между потоками используют. Красота

Кстати как там умножать матрицы наизусть не помню

может когда-нить, когда мне вдруг нечем будет заняться, может гляну.

не, это говорит только о том что у меня достаточно большой список тем, которым стоит уделить внимание в ближайшем будущем. И то что мне в 11 вечера неохота гуглить и разбираться с этим тоже.

По шпоре, небось.

угу. а потом что рассказали — записываю и гуглом проверяю. вдруг правда

открою секрет... Не все доу обитатели живут по восточноевропейскому времени
а намекал на что? А то я глупый, не понимаю никак намеков

Или переменные без volatile для обмена данными между потоками используют.

Это провокация такая, или Вы серьёзно? :crash:

Я надеюсь это замечание не в контексте java?
Потому, что незнаю, как в C++, но в java volatile — это не про атомарность.

В C++ точно так же не про атомарность. Volatile это всего лишь запрет иметь кэшированное значение всех(!) переменных до доступа к данной переменной на чтение или после доступа на запись (причём, в отличие от Java, нет требования барьера памяти вокруг доступа). Атомарность доступа не гарантируется, если не гарантируется для этой же переменной без volatile.

В яве не требуется бартер как таковой, а запрещается реординг. Это может быть реалтзовано как через барьер так и нет. Это зависит от архитектуры процессора.

в java таки все-таки в некоторых случаях и про атомарность

На что? Чтение и безусловная запись? Там ни CAS, ни XADD нету, ни более одной переменной синхронизировать. Может, для 1% задач это и даёт какую-то пользу, но для остальных (в отличие от явных Atomic* типов) это не атомарность, а хилый закос под.

причем тут CAS или XADD, если у тебя лонг кривой вдруг прочитается, когда один поток только половину битов записал — а второй читать начал уже?

При том, что запись одиночного long без учёта прежнего содержимого, чтобы его тут же прочитала другая нить безо всякой другой синхронизации — никому(*) в реале нахрен не нужна.

(*) Те 5%, когда нужна — например, раздаются одиночные параметры конфигурации — погоды не делают и всё равно прямее и надёжнее реализуются atomicʼами, а не volatile.

как то, что это редко когда нужно, отменяет мои слова про возможные баги и атомарность?

это редко когда нужно

Т-е нужно только тогда, когда сапортишь код в котором разработчики сначала облажались, а потом использовали volatile для того, чтобы их говнокод работал чуть стабильней, или для переписывания однопоточного говна мамонта с высоким переиспользованием кода?

Ну и насколько я помню, там таки нет атомарности. Там есть побочное явление, которое иногда ведет себя как атомарность.
Там есть
Запись значения в поле типа лонг ХепенсБифор чтение другим потоком значения из этого поля.

Т-е при выполнении следующего кода
a = 12345678
b = 87654321
Если а и b волатильны — все равно возможно выполнение этих команд в следующем порядке (По крайней мере спецификация не запрещает).
1) a = 12345678 ( L )
1) b = 87654321 ( R )
1) a = 12345678 ( R )
1) b = 87654321 ( L )
Т-е не атомарно.

атомарная запись в лонг это гарантия, что все биты установлены за одну операцию. Без volatile такой гарантии нет и биты присваиваются за две операции (сначала одна половина, потом вторая). Ну и при работе с volatile переменной компилятор не меняет порядок выполнения команд (спецификация это прямо запрещает)

Т-е нужно только тогда, когда сапортишь код в котором разработчики сначала облажались, а потом использовали volatile

нет, это нужно для определенного рода задач.

пиндец, как можно сравнивать использование volatile и облажались? Я вообще не понимаю о чем вы тут двое говорите. Может пример тогда бы, чтоб не писать вот это все?

Да. Согласен. Перечитал спеку, пока ехал на работу.

пиндец, как можно сравнивать использование volatile и облажались?
При том, что запись одиночного long без учёта прежнего содержимого, чтобы его тут же прочитала другая нить безо всякой другой синхронизации — никому(*) в реале нахрен не нужна.

JLS говорит что

Writes and reads of volatile long and double values are always atomic.

А то как это реализовано и почему, это уже для разработчика значения не имеет, и не должно иметь.
И не важно как часто это используется, т.к.

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.

Перечитал спеку.
Таки да. Я не прав.
И в контексте записи по частям — «Vasya Pupking» таки прав.
Все реализации java гарантируют атомарную чтение и запись в volatile double и long переменные.
Кроме того, на i64, ARM-ах, и еще многих платформах атомарность чтения и записи гарантируется и для НЕ volatile даблов и лонгов. (Т-е для всего кроме десктопов, и кода, выполняемого на древних ембедедах, вроде телевизоров да POS терминалов)

Знание прикольное, но совершенно бесполезное.
Я надеюсь, что если вдруг я буду искать работу, и меня будет собеседовать «Vasya Pupking» — мне откажут)

Кроме того, на i64, ARM-ах, и еще многих платформах атомарность чтения и записи гарантируется и для НЕ volatile даблов и лонгов.

И на ARM32 для 8-байтных long? А как именно реализовано?

Т-е для всего кроме десктопов,

Десктоп как раз сейчас редко на 32 битах увидишь...

Я надеюсь, что если вдруг я буду искать работу, и меня будет собеседовать «Vasya Pupking» — мне откажут

+1 :)

не, не буду собеседовать, не бойся

Тогда вернемся к вопросу. Как volatile защищает от того, что только половина переменной меняеться?

Да ладно, научиться, когда пол переменной поменяется, а пол нет.

в Java volatile гарантирует атомарное присваивание long и double. Без volatile — не гарантируется

садись, двойка. И про атомарность тоже. Почитай про запись в double/long

Как же я люблю после таких, как вы код сапортить...

Он прав, атомарная запись гарантирована. Нужно только правильно понимать, в какой момент происходит запись, а в какой другие операции

Для подавляющего большинства применений синхронизации — атомарное чтение и безусловная атомарная запись одной переменной это тупо ничто.
Что-то реально полезное начинается с CAS, LL/SC (для стиля Java таки CAS) и обёртки групповой защиты под сериализацией (в виде synchronized). Далее уже можно думать про lock-free (причём осмысленные начинаются там, где поддерживается транзакция из нескольких изменений).
А если кто-то решил, что на одних volatile можно построить что-то надёжное... я таки присоединюсь к предыдущему оратору про «саппортить после таких».

Это никак не отменяет указанный выше факт: для волатильных переменных гарантируется атомарное чтение и запись.

Против этого я ничего и не высказывал. Только «атомарное чтение и запись» это, извините, ещё не атомарность, а 1% от неё, и volatile никак не является основным рецептом синхронизации.

то есть если вероятность бага не очень высока (но больше 0) — то и не будем от него избавляться, всего-то добавив одно ключевое слово к переменной?

«То есть» лечить надо правильно, а не маскировкой косой заплаты.

что ты несешь вообще? То что ты не можешь придумать задачи, где это может пригодиться, не значит что такого не бывает. Пихать атомики туда, где они не нужны — гениальная идея, учитывая что атомики тоже требуют ресурсы. Скажи что сначала тупонул, потом погуглил, понял ошибку и пытаешься выкрутиться, да и все. нет же, куда ж, разве укр. сыроед на такое способен

То что ты не можешь придумать задачи, где это может пригодиться, не значит что такого не бывает.

Могу и «придумал». Но это неважные частные случаи.

Пихать атомики туда, где они не нужны — гениальная идея, учитывая что атомики тоже требуют ресурсы.

При правильном использовании они требуют или столько же ресурсов, или меньше.

Скажи что сначала тупонул, потом погуглил, понял ошибку и пытаешься

Кто «тупонул», ищи в зеркале.

нет же, куда ж, разве укр. сыроед на такое способен

Самокритично.

мда, это клиника, однозначно. Я где-то писал что-то о «чтение+запись»? Или я где-то написал что volatile делает что-то, что оно НЕ ДЕЛАЕТ? Так что не делает, умный ты наш?

нет же, куда ж, разве укр. сыроед на такое способен
Самокритично.

если что, я не укр. сыроед, т.к. не в Украине живу и работаю в одной из топ компаний мира =)

Так что не делает, умный ты наш?

И снова на личности... спасибо, я всё понял.

так а как мне еще вопрос задать, чтоб понять что ж не так я написал? Ладно, еще раз задам, прямо. Делает ли volatile запись в лонг атомарной или нет? Только да или нет, без разлагольствований

так а как мне еще вопрос задать, чтоб понять что ж не так я написал?

Вы написали:

Или переменные без volatile для обмена данными между потоками используют. Красота

99% используют «переменные без volatile» для обмена данными между нитями, потому что используют synchronized и атомики. А у Вас, оказывается, они должны были вместо этого volatile использовать — и плевать, что подавляющее большинство сценариев взаимодействия вообще не защищается volatile в принципе (инвариант на нескольких переменных, сложные структуры типа Map и т.п.)

Теперь понятно?

Делает ли volatile запись в лонг атомарной или нет? Только да или нет, без разлагольствований

Делает. Без разглагольствований. Но от этого описанные выше проблемы не уходят. Без разглагольствований.

ну давай, еще ты расскажи, в чем я не прав, специалист ты наш

во первых в этой ветке разговора речь была совершенно не об этом а о атомарности записи в лонг. То есть ок, что мы наконец-то пришли к тому что я прав?
Дальше.

99% используют «переменные без volatile» для обмена данными между нитями, потому что используют synchronized и атомики.

Есть куса примеров где атомики нафик не нужны а достаточно простых переменных и volatile позволяет не поиметь проблем с кешем (ну и если вдруг записывается лонг или дабл то и с частичной записью).
То что кто-то там тулит атомики везде куда ни попадя — их проблемы. Атомики нужны только когда атомарной должна быть операция чтения И записи. А не по отдельности. По отдельности — оверхед лишний.

во первых в этой ветке разговора речь была совершенно не об этом а о атомарности записи в лонг.

Именно «об этом». Я говорил об этом прямым текстом, а если ты читал что-то иное — уже не мои проблемы.

И ты даже про Java не уточнил. Что я, что Чижденко сразу подумали про C/C++ — в которых и такого нет, а для гарантии атомарности нужны именно атомики и выравнивание. Не задан контекст — имею право предположить любой подходящий.

Есть куса примеров где атомики нафик не нужны а достаточно простых переменных

Жалкая доля от всех применений.

ветка началась вот этим

но в java volatile — это не про атомарность.

на что я сказал

в некоторых случаях и про атомарность

то есть было четко указано что речь о Java, то что кто-то увидел С++ , не моя вина, не так ли?
И было так же четко указано что volatile в опеределенных случаях вносит атомарность (не атомарность чтения И записи, а атомарность записи, но все равно это атомарность). То есть никто не уточнил, что я имею ввиду, а сразу на меня набросились с кучей каких-то примеров не по теме

Никто ней не мешает добавить атомарности для любых объектов программы. Понятно, что тормозить прога будет, но зато достаточно безопасно работать.

Таки она слишком тормозит в этом случае. История со StringBuffer vs. StringBuilder это хорошо показывает. Коллекции тоже не защищают по умолчанию, но тут в принципе невозможно защитить от фокусов типа «выдернули элемент, пока итерировал» — это решается на более высоком уровне.

В С++ вон специально добавили в STL атомики, но не в сам язык.

Ну я бы тут так жёстко не разделял — добавили-то в стандартную библиотеку, а язык обязан обеспечить её надёжную работу.

Да ну? Залочил доступ к коллекции и расслабился.

Спасибо, кэп :) Сейчас практически интересны как раз случаи, когда нельзя лочить коллекцию на время всего итерирования.

Не ставь телегу перед лошадью. Это библиотека должна быть написана в соответствие с требованиями языка.

Не ставлю. Просто «язык» в целом это «чисто язык» плюс библиотека, и они обычно связаны сильно плотнее, чем кажется.
Разработчики языка всегда стараются обойтись без усложнения синтаксиса (в C он уже нетривиален, в C++ вообще ад и сектор Газа), поэтому максимум в библиотеки, но всё равно каждая следующая версия что-то меняет и в «собственно» языке.

Но я сильно не уверен, что она допустима для кусков критичных ко времени выполнения кода. Атомик можно на разных примитивах синхронизации слепить.

Обычно они таки максимально эффективны, насколько им разрешаешь (например, atomic<T>::load по умолчанию с seq_cst, а для relaxed надо указать его явно).
Насколько это «максимально» получается — уже зависит от местности. На x86, например, не очень — в нём введена куча весьма жёстких гарантий на видимость операций записи.

З.Ы. Когда я вбрасывал, я не думал, что всё еще хуже, чем я предполагал до этого.

Ты всегда так пишешь :)

Когда я вбрасывал, я не думал, что всё еще хуже, чем я предполагал до этого.

я когда такое читаю, задаюсь вопросом, что ж ты такой бедный, если такой умный?

Вероятность бага, если неправильно расчитывать только на атомарность чтения записи почти 100%.

где был что-то о атомарности операции чтения И записи? Где я что-то об этом написал?

Если не написал, то хорошо. Это правильно!

я в шоке. написал о атомарности записи, так уже тут развезли хрен знает что. Все только чтоб выкрутиться некоторым товарищам. Готовы нести любую чушь, лишь бы не признать ошибку...

Если «по двум языкам» это со мной, то после первого его ответа дальше стало ясно, что речь про Java, так что проблема не в этом.
А смысл, да, разный — но у слова «атомарность». Ну не могу я называть атомарностью то, что даёт volatile.

На несколько дней развлечения я получил.

Так долго? Я удивлён. Вроде ж у тебя и интернет есть...

No worry, просто ребята потеряли где-то свои капитанские шлюпки, а потом решили что их знания о том что рид+райт в volatile не атомарный являются чем-то необычным и уникальным, и об этом срочно нужно все сообщить.

Применение переменных типа long, double в месте, доступном для нескольких потоков (Даже, если один поток занимаеться только ИЛИ чтением, ИЛИ записью) — признак плохого дизайна кода..
Если же один поток занимается одновременно и чтением и записью в volatile long/double — у тебя не может быть уверенности, что ты прочитаешь правильное, актуальное значение.
Так как для
voletile long longVal;
Следующая операция не являеться атомарной
longVal += otherLongVal;
Хотя возможно тебе нужно какое-то (целостное значение), а не актуальное.
И в таком случае ты используешь побочные особенности одного инструмента для решения проблемы, для которой обычно используется другой инструмент. Это не повышает поддерживаемость кода. Повышпает количество WTF/min от человека, который этот код сапортит.

Ну и использование тред-локалов в екзекьюторах без негативных последствий — возможно. Если их обнулять в начале выполнения ранебла, который крутится в екзекьюторе. (Я ни в коем случае не говорю, что это хорошая идея, я скорее бы сказал, что это ужастная идея. Но так делать можно. И почти без негативных последствий (кроме повышение WTF/min от человека, который этот код сапортит)

Применение переменных типа long, double в месте, доступном для нескольких потоков (Даже, если один поток занимаеться только ИЛИ чтением, ИЛИ записью) — признак плохого дизайна кода

насчет признака плохого дизайна я бы поспорил (если один только читает а второй только пишет), но речь не об этом вообще а о том что volatile значит в Java. Гарантирует ли volatile запись атомарную в лонг или нет? Ответь. Да или нет, без разлагольствований.

Следующая операция не являеться атомарной
longVal += otherLongVal;

спасибо, кеп. где я писал что это атомарная операция?

Ну и использование тред-локалов в екзекьюторах без негативных последствий — возможно. Если их обнулять в начале выполнения ранебла, который крутится в екзекьюторе.

на экзекьюторах работают не только простые ранбл, а и, например, реактивные библиотеки. Попробуй использовать тред локал там — и выстрелишь себе в ногу (и не только)

Меня в этом плане, кстати, порадовал PIIX timer, он же ACPI-fast timer.
Там нет защёлки на чтение, и процессор может прочитать любое значение в процессе его изменения, в момент чтения может идти обновление между любой парой соседних битов.
Поэтому рекомендованный метод чтения — прочитать 3 раза подряд и, если значения оказались строго по неубыванию, вернуть среднее. Если же что-то не так — повторять до успеха.

Взагалі першим питанням мало б бути — який саме алгоритм множення матриць (я так розумію, їх дофіга) потрібно прискорити в 7.999 раз.
Потім глянути на даний алгоритм — чи його взагалі можна теоретично розпаралелити на 8 окремих потоків.
Бо якщо це навіть теоретично зробити не можна (завжди сподіваємось на краще :) ), можна далі вже не напрягатись і піти пити пиво. :)

емм... «алгоритмы быстрого перемножения матриц» ???

Таких нет. Есть разные подходы

Наскільки бачу, що вікіпедія, що статті, на які вона посилається, називають ці «підходи» алгоритмами. ;)
en.wikipedia.org/...​_multiplication_algorithm

Как ВНУТРИ работает сборщик мусора в Java, как бы вы писали свой.

когда высоконагруженный сервис начнет или на stop the world зависать или по аут оф мемори валиться — разберешься как оно внутри работает (не только один а и все 4 разберешь)

Все эти обсуждения собеседований стойко создают у меня ассоциацию девушки в поисках парня:
* Ищет идеального кандидата
* Среди кандидатов выбирает того, кто лучше всех прошел собеседование (по первому впечетлению же, проходят те кто тренируется проходить собеседование)
* увольняет через три месяца
* Кандидат попадает в черные списки ее «колег»

Как стёб пойдет, а если серьезно, поиск парня и поиска сотрудника — разные вещи. Девушка ищет сердцем, а работодатель «кошельком».

Девушка ищет сердцем, а работодатель «кошельком».

Скорее по кошельку ))

А следующему три месяца рассказывает что он хуже чем бывший. Далее он не выдерживает и уходит сам — ну не козёл?

Следующий точно будет козлом, просто потому что он должен совместить в себе всё хорошее предыдущих, плюс все надежды на них, плюс принять месть за тех двоих и за такие же случаи с подругой. И так до тех пор, пока её саму не вышвырнут из компании (тоже разумеется козёл).

О том что работа не имеет ничего общего с козлами отпущения — а зачем знать?

Любые собеседования, проводимые прасисианалами — вред.
Это касается любой деятельности, где требуется образование.
Но почему-то считается, что телятину в кисло-сладком соусе должен готовить шеф-повар с 20-летним стажем, зато с техническим собеседованием — справится 23-летний синьор.

Что он может спросить? Да то, что сам только что вычитал про супер-крутой фреймворк, и забудет через две недели. Но как этого можно не знать кандидату?

А факты таковы, что кандидат работал НА ДРУГОЙ работе, занимался ДРУГИМ делом, возможно всё ещё занимается. И львиная его доля знаний секундной доступности — об этом. А к собеседованиям лучше всего готовы проходильщики собеседований.

Вероятность ошибиться с кандидатом на собеседовании — ВЫШЕ, чем если не проводить его совсем. Именно потому, что чем кандидат ценнее, чем выше его способность фокусироваться на задаче — тем выше гарантия что его текущий фокус не совпадает с общерелигиозным бла-бла-бла вайтишников.

Классический вопрос — чем отличается абстрактный класс от интерфейса. Июнь назовёт 4 отличия по книжке. А те кто знаком с отладкой низкоуровневого кода — скажет что ничем по сути. Вы не можете ни собрать, ни разобрать такие объекты. Иначе говоря, ни тех ни других — не существует, но существуют объекты, отвечающие за приведение к этим типам. Другими словами, когда произошло приведение типа, создаётся КОНКРЕТНЫЙ объект АБСТРАКТНОГО класса — именно то, что якобы «невозможно», а по сути невозможно ничто иное.

И что, разве может вчерашний июнь с лычками принять кого-то сложнее такого же июня?

Но почему-то считается, что телятину в кисло-сладком соусе должен готовить шеф-повар с 20-летним стажем

серьезно? 0_0

Ну добре, шеф-кухар із 25-ти річним стажем. Не могли вже й дати послаблення в 5 років...

Потому как мы в массе своей привыкли есть дерьмо и не понимаем зачем повару такой опыт.

не, удивляюсь другому.
я верил, шо шеф-повар лично готовит исключительно технически сложные блюда с кучей нюансов, к которому тушеная говядина мной не относится.
максимум — контроль за тем, как делают другие.
если шеф-повар лично будет готовить все блюда сложнее супа, то какая будет скорость готовки?

Но почему-то считается, что телятину в кисло-сладком соусе должен готовить шеф-повар с 20-летним стажем

серьезно? 0_0

Телятина в кисло-сладком соусе получится у любого, кто способен выполнить рецепт не добавив отсебятины. А вот с наймом людей такое не выйдет. Нужно знать много людей, чтобы понимать не только насколько они разные, а то насколько огромна степень свободы одного человека, и насколько его результат зависит не от него — но от обстоятельств в которые он попадёт, и от опыта предыдущих обстоятельств.

Простой пример: стрессоустойчивость. У меня за жизнь опыт совместной работы примерно с полсотней стрессоустойчивых людей. И с тысячами не-стрессоустойчивых.
У вас есть рецепт, как отличить одного от другого?

Ладно, вопрос проще: КОМУ нужна стрессоустойчивость, а кому — нет. Назовите хотя бы по 5 обычных профессий, где требуются одни, где другие, и 5 профессий где безразлично.

Негусто. Так нужна стрессоустойчивость оперу или наоборот вредна? Или безразлична? А грабителю?

Вероятность ошибиться с кандидатом на собеседовании — ВЫШЕ, чем если не проводить его совсем.

Совсем спорно. По вашему рандомно подбирать кандидата выгоднее чем с помощью собеседований?

А факты таковы, что кандидат работал НА ДРУГОЙ работе, занимался ДРУГИМ делом, возможно всё ещё занимается.

Все упирается в то, что из доступных кандидатов выбирают тех, кто больше времени провел с нужной технологией. Или можно, прослушав «историю» кандидата, оценить его потенциал.

Хм, мне как программисту это по душе, но чето совсем сомнительно как нанимателю. Хотя бы пару минут пообщаться с кандидатом, чтобы понимать что он за человек.

Настоящая причина бюрократии — наказание за ошибки. Реальный бизнес-процесс — всегда с риском. Риск найма нужно держать на уровне 15%, и не опускать ниже, иначе сливки не взять. Иначе как в работе лучшие себя не покажут.

А вот когда за ошибки наказывают, притом по мере спуска собак по иерархии наказание усиливают в 2-3 раза — оказывается что кого-то уволили за непорядок на рабочем столе [случай реальный].

Бюрократия есть ни что иное, как имитация процесса и подделка результата. Она состоит из 2 слоёв: блестящего верхнего, для руководства, и нижнего слоя говна, в котором топят каждого кто захочет решить проблемы — тем самым пробив верхний блестящий слой, для получения полномочий.

По мере роста нижний слой тоже вынужден быть блестящим... и формирует новую прослойку иерархии. Иначе жестоко накажут. Верхний же слой забирает на себя все полномочия, как бы ни вдруг чего. И хотя формально (и есть процедура) за этими полномочиями можно обратиться — это означает пробить свой блестящий слой.

ТИПИЧНЫЙ ПРИМЕР: Эйчар не может узнать настоящую вакансию, и просто пишет её от балды и копипасты. Конечно есть те, кто знает мат.часть, и плевать хотели на так называемые «блестящие слои» — потому бюрократия развивается стремительно только в терминальной стадии (охота на ведьм). До тех пор это очень вялотекущая проблема, и потому смертельность процесса незаметна.

Особый случай — государственная бюрократия. Она вообще не имеет не-преступного решения. Любое из решений даже небольшой проблемы, требует нарушить устоявшиеся обычаи, привычки, иногда закон. Например, обратиться к чиновнику в неприёмный день — правонарушение, а не принимать в приёмный — нет.

Если есть нечто, что по душе тебе как программисту, то есть программистам как классу — ЭТО САМОЕ НЕЧТО должно быть маст хэв у каждого нанимателя, а у лушчих HRов должна быть степень доктора философии по этому «нечто».

А всех кто в этом «нечто» ни в зуб ногой — отправлять работать в публичный дом, там как раз за красивые глазки [хотел сказать сиськи] платят. И тогда вместо ьобаного.айти у нас было бы честное ьобаное.xxx, сотни курсов как стать шлюхой, со скрамом и покером.

Все упирается в то, что из доступных кандидатов выбирают тех, кто больше времени провел с нужной технологией.

Это не оптимальная стратегия.
Во-первых у людей разная скорость вхождения в работу, вплоть до порядков раз.
Кто-то за месяц поймет больше, чем иной за год, и среднего тут нет.
Во-вторых тому, кто знает пять технологий- выучить шестую понадобится меньше времени. Чем тому, кто всю жизнь занимался одной технологией- выучить еще одну.
А вы даете гарантию, что ваш работник будет все время работать на одном стеке, и ему не придется переучиваться?

По вашему рандомно подбирать кандидата выгоднее чем с помощью собеседований?

По теорверу ещё выгоднее брать того человека из двоих, который набрал чуть меньше баллов на техн. собеседовании

Как идет лесом?) -статья же есть, с которой этот топик начинался. Что только 25% тестирований выбирают правильно кандидата. При такой низкой вероятности правильнее выбрать того, кто не прошел тестирование " послушай женщину и сделай наоборот" ©

По вашему рандомно подбирать кандидата выгоднее чем с помощью собеседований?

К сожалению, показать это на опыте я не смогу. Вы не согласитесь провести этот опыт. Разумеется, не рандомно, но не задавая кандидату тех вопросов, на которые вы не имеете минимум года опыта, и не знаете всех вариаций. Не проводя личного собеседования там, где можно спросить удалённо.

Насчёт нужной технологии — я предлагаю указать именно её в вакансии. А 99 других баззвордов — не указывать. Но так делают только люди с низким ЧСВ, ведь это «глупо» — не выьобываясь проверить человека, согласовать условия и взять на работу.

Не нужно слушать истории. Достаточно просто задать вопросы по знаниям, которые реально применяются. И на пушечный выстрел не допускать к их написанию человека, который только выучил или сейчас учит. За переписывание вопросов с книги, и вообще за применение книги и иной документации при составлении вопросов — отпиzдить ржавой монтировкой.

Почему так? А как вы считаете, если вы сами какими-то данными не пользуетесь в работе [то есть данные бесполезны], за каким мужским половым х′ем это будет знать кандидат? При том что работать он умеет. А тот кто «вызубрил к собеседованию» — не факт.

Невже для когось є новиною, що на інтерв’ю не можна повністю побачити яким працівником буде кандидат на вакансію? Оці так звані «складні інтерв’ю» якраз мабуть завжди враховують, що більшість кандидатів трохи хвилюються на інтерв’ю.

Хоча час, коли я сильно переживав на інтерв’ю, далеко позаду, але мене і зараз трохи більше напрягає, коли кажуть «розкажіть нам про себе», ніж коли задають конкретне технічне питання.

на інтерв’ю не можна повністю побачити яким працівником буде кандидат

Неможливо навіть на 4%. Хіба що він сам того захоче, і так співпаде що інтерв′юер саме це захоче почути. Назвемо цей процес в Україні правильним словом: допит. І ефективність його рівно така сама, як в тьолки дізнатися чи ізміняв їй бой-френд — виносячи йому мозок.

Угадай с одного раза, ограничатся ли этим в Украине. Щщас! Надо же своё ЧСВ проявить, комплекс вахтёра показать, и разумеется доказать кандидату какое он чмо.

С вероятностью близкой к единице все вопросы которые важны — задаст сам кандидат. Или не задаст. А вот HR их не задаёт практически никогда и нигде. И даже правильных ответов не знает на эти вопросы. Потому что для этого надо подорвать жопу и хотя бы краем глаза увидеть саму работу. А не только описание в стиле предвыборной агитации, то есть ни слова правды.

Это не галеры отличаются, это люди. Обычный человеческий фактор — устроить своих тёлок на хорошо оплачиваемую работу.

Лично мне импонирует китайская организация труда: жёстко, массово, продуктивно — и никакой лишней бюрократии в производственном уровне. ИЧСХ, уровень доходов очень одинаков, и зависит от выполняемой работы, а не от лычки. А работа даётся тем, кто может её выполнить, а не тем кто бухал с руководством.

Таким образом чётко разделяется творческая и рискованная работа, от тонн говнокода. И есть разделение труда на тех кто выполняет одну и другую, притом зарабатывают последние нередко больше первых. Просто потому что скоростной работе тоже надо обучаться, а не всем изобретать велосипеды.

Interviewing.co <- битая ссылка (.com ?); в статейке указана interviewing.io

www.wired.com/...​2015/04/hire-like-google — Тут написано результаты для гугла. Вот только Гугл имеет совершенно другую политику найма сотрудников, они ищут не людей на работу, а людей «в гугл», где они же сами себе и делают работу. Считать их статистику подходящей для всех компаний (и для любой компании в частности) — глупость.

blog.interviewing.io/...​arbitrary-heres-the-data
299 интервью с 67 интервьюверами. — мало для статистики.
давали оценку от 1(такое) до 4 (оч. хор.) — это не работает. Сколько времени и денег потрачено, чтобы доказать что это не работает. Ютуб даже лекцию давал.
Что работает: оценки да/нет на ОЧЕНЬ больших объемах людей (от 10000+) и то, с натяжкой. Это дает приблизительное подобие правильности. Оценки по шкалах неправильны потому как оценки «экспертов» не равны и оценивают они субъективно. Кому 3 потому как да хорошо, кому 4, потому как «вау, первый ответил на этот вопрос». Это необъективно. поскольку оба поставят «+» при выборе «+» или «-»

высококлассные специалисты «заваливают» технические собеседования в 22 процентах случаев

Ну, так бывает. Эти «завалившие» не заваливают каждое свое тех собеседование, верно? Сколько они реально заваливают написано? Одно заваленое не показатель, да и разве для всех критерии одинаковы? Если да — разве это техническое собеседование? Каждый знает вещи по разному. На один и тот же вопрос может быть два ответа, оба подходящих, и прочее прочее. Критерия «заваливания» тоже какбы нет.

По сути статейка — спекуляция на графиках, полученных из экселя

Кажись более новый статьи из ее блога используют данные для на много большего количества собеседований.

Энивей, сервис довольно прикольный.

Даёшь одну задачу из «Науки и жизнь» за год, эдак, 87. Если решает или хотя-бы адекватно идёт к решению — можно остаток собеса по квалификации уложить в 10 минут.

Куда катится мир. А ведь когда-то, веришь, не гении решали. Печаль

Мне вероятно в раннем юношестве с бабушкой очень повезло — проводили вечера, пробовали, что-то решили. Даже осталась где-то стопка. Ну ок, чсв того и гляди взлетит у меня.

Да, судя по тому, что в трёхмерном пространстве есть только пять платоновых тел (не моё, ссылюсь на Ф.Вильчека) — задачка сулит быть интересной. Если найдёте описание — сбросьте плиз.

ну ключ к решению — равный диаметр и высота цилинтра, потому что в таких условиях цилиндр можна заменит на удлиненный куб (паралелепипед?) . Делается проекция бока тетраеэдра на плоскость и находится высота удлиненного куба и т.д.

Американцы: Со Spring-ом работал? Что на нем писал? О чем было приложение?
Наши: Назовите сигнатуру методов класса SpringAPiХуеМое?
Я вчера столкнулся со сложной проблемой в Hibernate (и неделю гуглил, так как сам не осилил) — как ее решить ?
Вот кусок говнокода с тройным циклом и однобуквенными переменными и корявыми отступами — как это будет работать ?
Сколько весит в байтах вновь созданный Java объект?
Отбалансируй на листике красно-черное дерево...

Если жестко задрачивать кандидата, то любой сядет в лужу.

черд...

Я вчера столкнулся со сложной проблемой в Hibernate (и неделю гуглил, так как сам не осилил) — как ее решить ?
Вот кусок говнокода с тройным циклом и однобуквенными переменными и корявыми отступами — как это будет работать ?
Сколько весит в байтах вновь созданный Java объект?
Отбалансируй на листике красно-черное дерево...

У меня это все было, и даже приходилось отвечать. До сих пор помню ответ на 3 «сумма объявленных в классе полей + еще чуть-чуть на указатель переменной класса».

Охренеть ответ — чуть-чуть)
— Когда зарплата?
— Подожди чуть-чуть и прийдёт чуть-чуть.

«зависищий от виртуальной машины рандом на сохранение указателя класа» больше подойдет? От машины зависит. Может быть 5 байт, может — разная хрень. К чему ты щас прикопаться хотел?

А на самом деле правильный ответ — да всем похй! Ни один дятел не высчитывает побайтно каждую свою переменную. Их просто клепают пачками под любой чих. И только реально большие объекты либо хранимые данные — адаптируют по структуре данных.

Лучше бы дали базу данных оптимизировать. Я считаю, прекраснейший тест: дать с какого-то боевого проекта реальную базу (ну разве только анонимизировать), позволить кандидату задать любые вопросы, показать процесс — и сказать выполнить оптимизацию. Этого более чем достаточно, чтобы больше к нему с практическими вопросами не приставать и поговорить только о теории.

Почему так: оптимизация базы очень родственна оптимизации памяти. Увидев как он работает с данными, можно сказать что у него в голове — рабочий процесс, или блокчейн с сыром.

Я так и делаю, но в условиях большого распространения галер, можно и без работы остаться. А шутя ставить на место — более верный шаг.

Американцы: Со Spring-ом работал? Что на нем писал? О чем было приложение?

в этом случае есть вероятность, что писал кто-то другой в команде, а кандидат мимо пробегал

Я вчера столкнулся со сложной проблемой в Hibernate (и неделю гуглил, так как сам не осилил) — как ее решить ?

ну «неделю гуглил» это перебор, но я люблю задачи из практики, при этом никто не мешает кандидату погуглить, если он не смог решить задачу самостоятельно. Поверьте, многие даже с гуглом не знают куда копать и в приличные сроки задачи не решают

В штатах тоже задрачивают, я проходил собеседование в одну из дочерних компаний Amazon в NJ — 2 часа собеседования и все вопросы — «Что вы полнит этот код или напиши Pool Thread Executor-ов, который будет вытаскивать фотки с Instagram», в компанию Avira проходил — дали тестовое задание на 3 часа с вопросами типа столкнулся с проблемой Hibernate и несколько вопросов написать код который будет парсить excel. Потом попросили неделю за бесплатно работать — типа испытательный срок.

От US компании Nest requirement после собеседования — придумать и написать свое тестовое залания испрользуя их API и девайсы.
Some examples may include:
— Build an iOS app showing Nest API for Objective-C
— Build a Java based web app using Nest Javascript API
— Build a Java portal dashboard using Nest Scala backend API
— Build an Android app showing Nest API for Android/Java
— Build your own thing showing off your talents using something from Nest

Once you have finished, record a short demo showing off what you have built. Please briefly explain your code and what you integrated from Nest. Upload your video and project to Github.

Расскажите, как легко американским разработчикам войти в IT :D

когда я працовал в УСА (а было это очень давно, может что-то поменялось),
«золотым стандартом» считалось попросить кандидата написать код маркером на доске (при очном собеседованиии). в удаленном варианте собеседования просили написать код в скайпе :-)

Ничего не поменялось, до сих пор такая фишка — как раз именно вот так у меня и было в дочернюю компанию Amazon-а :-) Просто классика

Люди, которые успешно пробираются сквозь перипетии собеседований, зачастую хороши именно в этом — в прохождении интервью. Но далеко не всегда это утверждение правдиво и для рабочей эффективности.

Стикався часто з тим, що нормальний спеціаліст на співбесіді починає хвилюватися і пороти дику фігню, хоча явно знав все і навпаки, коли вдавалося обвести розмову мимо тих моментів, де людина не впевнена. Так що так, співбесіда багато в чому характеризує вміння проходити співбесіду. З іншої сторони залежить від кваліфікації того, хто її проводить. Бо рекрутер, зазвичай, дивиться на ключові слова і все, що в корені невірно. З іншої сторони не можна і питати лише «задачки про кришки від люків», треба мати баланс між теорією, практикою та абстрактними задачами.

Согласен с основным посылом. Мне кажется, самый хороший подход — нормальное тестовое задание на дом по технологиям из проекта на 2-4 часа работы. Можно даже подготовить несколько разных заданий для разных уровней кандидатов. Оно покажет очень многое за пределами умения написания алгоритмов на бумажке и знаний ответов из списка «hack technical interview».
А на очном собеседовании самое важное — понять насколько кандитат «хороший человек», потому что это важнее конкретных технических знаний.

Сьездить на техническое собеседование занимает те же 2-4 часа (это еще если офис в твоем городе). Да, нужно нормально коммуницировать человеку почему вы делаете так, а не иначе. Мне кажется, многие сеньоры еще и спасибо скажут, и больше захотят работать в компании, где преобладает здравый смысл, а не желание интервьюеров «завалить» кандидата.

А нельзя например, подготовить тестовый солюшен, в котором в течении 2-4 часов нужно допилить определенную фичу?

Ну ок. Значит, вам такой метод не подойдет :)

Сьездить на техническое собеседование занимает те же 2-4 часа

А зачем на него ездить, если можно провести по скайпу (или используя другой инструмет аудио-видеосвязи)?

А зачем на него ездить,

Офис посмотреть, пиченьки и кофе оценить, посмотреть на собеседующего, итд.

Сьездить на техническое собеседование занимает те же 2-4 часа

Тоже пошлют лесом) Почему не проводить собеседование по скайпу? Можно включить видео связь на крайний случай (хотя не вижу смысла).
А вот если кандидат подходит по технической части, тогда уже можно пригласить его в офис для более близкого знакомства.

С тестовым мидл и сеньор тебя пошлют лесом с большой вероятностью. Это только для джунов смысл имеет.

Окей, тогда как оценить качество его работы? Просто поговорив. Знавал я одного испанца который любил поговорить, а как дело до кода дошло...

Небольшая поправка: тестовое задание, если нет проектов на гитхабе*

тестовое задание, если нет проектов на гитхабе*

Это такой способ отфильтровать людей, которые не готовы работать бесплатно?)

Ты не поверишь сколько говнокода я видел, я имел ввиду чтобы избежать конкретно говна. На словах каждый Лев Толстой.

А какой код не говно? Только тот, который переписывался и рефакторился раз десять и желательно разными людьми. Нет смысла писать красиво, да еще покрывать тестами, когда нет полной уверенности ни в приоритетах заказчика, ни в предметной области, ни даже в выбранных инструментах.

хз, я пишу сразу нормальный код. Рефакторят его обычно только когда архитектуру меняют. Иногда очепятки исправляют, не без этого. Мне нафиг не сдалось потом искать баги в говнокоде, легче в нормальном их искать.

И то верно. Все же лучше, чем просто «а и так сойдет» и начать писать нечитабельный говнокод, как некоторые тут предлагают

Можно сколько угодно утверджать что «и так сойдет» пока кому-нибудь не выколит глаз. Моя позиция что откровенного говнокода не должно быть остается прежней