То есть если человек перед интервью вызубрил кучу алгоритмов/особенностей языка/порешал типовых задачек, которые могут быть заданы, он внезапно стал походить на должность, а без этого — не годился, так получается?
Я видел две крайности: собеседущий «подготовился» вызубрив «хитрые» книжки, API, алгоритмы. Пофиг что в проекте не используется вообще ничего из этого. Он же не хочет выглядеть в глазах Работодателя «неучем» и начинает тебя «пресовать» на собеседовании.
или
решал какую-то проблему в проекте последние месяцы, заглянув так глубоко, как только можно в недра кода и API и потом этой проблемой пытается тебя «пресовать».
Самое грустное в этих случах, когда на таких собеседованиях обнаруживается что знаешь тему лучше «собеседника» и пытаешься с ним общаться как с «равным»… Сразу в глазах у них читается «ну нахрена я спросил...» и попытки резко сменить тему :)
Ни одно из этого не помогает ни найму ни собеседованию.
А на собеседованиях моментально можно выявить того кто «заучил» или того кто понимает и применял на практике.
Он, умеющий ответить на простые вопросы, доступные студентам 2-3 курса.
Думаю, постоянную Планка, число e, число Авогадо и т.д. Вам тоже преподавали на каком-то курсе. Возможно даже в школе. Сможете назвать «с ходу»?
Это особенность работы памяти/мозга — «отбрасывать» то, что не используется постоянно. Мозг извлекает память «по тригерам» — запахи, слова, жесты. Дайте мне их использовать!
Очень часто было, когда «собеседующий» не могли ответить на мои вопросы. Тоже «элементарные», только в моих проектах это были работы последних месяцев, а у них возможно и никогда.
Если вы хотите прособеседовать адекватно — пришли плиз программу собеседования.
Есть просто «молоток». Отработанный веками инструмент. простой, функциональный. И тут вдруг кто-то придумывает молоток с двумя ручками, с лазерным наведением, кто-то приделывает венчик для взбития сливок, кто-то ручку из силикона или надувного шарика. И вот на собесдование, у тебя спрашивают состав газа для такой ручки или правильную форму венчика… Тоже, вроде бы развитие, но вот нахрена ?!
Проблемы, то может и решают. Но может лучше их предотвращать? или просто не провоцировать эти проблемы?
Есть такая проблема — и жук и жаба изобретают свои велосипеды.
С быстрых и удобных коммуникаций усилия пошли не в координацию а-ля «глобальный product/scrum backlog», а на раскрутку сотен вентиляторови вкидывания в них куч ...«всего». По итогу только дочитал ман одной СуперТулзы, как обнаружил что появилось еще пару новых СуперПупер 1.2 и на них уже код какой-то наваяли…
Неужели столько много этих «плохих групп» и сколько много людей в них состоят как «поводыри-куклоды»? Какие цели они преследуют?
Неужели правоохранительные органы не могут вместе с администрацией сервисов в рамках уголовного дела использовать СОРМ и свои полномочия?
Если «эксперты» будут помогать, может быть еще хуже. Вроде «добровольные эксперты» не проводят нейро-/кардио-/… операции без специального обучения лет 10...15. Или это будет делаться под соусом «не оставление в беспомощном состоянии»?
Благими намереньями…
Как-то юридически такие действия должны сопровождаться.
Никогда не «задавал вопросы» на собеседованиях :)
Всегда старался помочь кандидату раскрыть свои знания, оценить ход его мысли, широту и гибкость взлядов и оценивал как могу их использовать в проекте. Как «дорого» будет «доточить» кандидата под проект.
А знания «API по памяти»- в большистве своем бессмысленны. На это мануалы есть и отладчик :)
Наверное удивитесь, но программист пришел со своего проекта и у него в голове свой код, свои объекты архитектура, шаблоны мышления решения именно «проектных» типовых задач. Нужно некоторое время на «переключени контекста», а собеседование и так дополнительный стресс для мозга (подсознательная и сознательная оценка собеседника(ов)). И тут тебе в лоб «задача-тест» не удивительно, что не все разу могут подобрать решение. Это не значит что программист «тупой» или «не грамотный» и т.д., просто «фоновые потоки» заняли все ресурсы. Вполне возможно что через минут 30 спокойной обстановки он выдаст решение, даже процитировав на память API
Вроде главная функция школы и прочих образовательных учереждение — учить.
Учить как находить знания, как анализировать и трактовать знания об окружающем мире.
Где грань между терроризмом, изготовленим взрывчатки и экзотермической химической реакцией вместе с третим законом ньютона? Чем определить что «царя взрывали бомбисты» правильно. Это же чистой воды пропаганда терроризма :)
Если мы против насилия и самоубийства — отлично! Давайте запретим информацию о самопожертовании вместе с распятием, запретим историю отравлений Медичи и Наполеона.
Если знания закрыть, чему будет учить школа? Выдуманными фактами вроде бы оперирует религия :)
. поэтому, если обработчик будет работать в одном потоке с логикой генератора, это как раз и поставит разработчика в рамки.
Это как раз вас поставит в рамки :) Ваш генератор станет «колом», поскольу ничего не сгенерит, пока обработчик не вернет управление.
Если вы разрабатываете библиотеку «для того парня», вы обязаны продумать API взаимодействия. В частности Вашей задачей будет предоставить и делегаты под обработку и декларацию событий и модель асинхронной работы (Event Based, Task Based и т.д).
В общем случае не ваша забота, как будут обрабатываться ваши события и по какой модели. Даже если вы сделаете «просто один поток» то обработчики сами себе придумают как быстро вернуть управление генератору.
Вопрос только в том — генератору нужен результат «обработчика или нет».
Я бы рекомендовал ознакомиться вот с этим материалом. MCTS Self-Paced Training Kit (Exam 70-536)
Если мне не изменяет память там было достаточное описание, для основ. (Chapter 7
Threading, Lesson 3: The Asynchronous Programming Model )
После без проблем «поверх ляжет» await & async
Поймите простую штуку: дьявол в деталях.
События не могут «выполняться», события можно вызвать.
А выполняется «Обработчик события».
Это два разных элемента. Когда вы сможете их рассмотреть отдельно, все станет на свои места. Пока Вы будете их рассматривать «связно» вы не получите правильного ответа.
Сам вопрос поставлен не очень корректно: как правильно молотком закручивать шуруп? :)
Правильный ответ: возьмите отвертку.
Executes the specified delegate asynchronously with the specified arguments, at the specified priority, on the thread that the Dispatcher was created on.
Namespace: System.Windows.Threading
Assembly: WindowsBase (in WindowsBase.dll)
Нас вот в универе не учили работе с потоками.
Это все есть в документации. Согласен что муторно, то иногда надо :)
Вроде как за последние лет 20 выработаны достаточно походов к решение многопоточного взаимодействия?
Что-то из уже сделанного не подходит?
Обычно на этапе дизайна уже ищутся ответы на вопросы:
Как должен себя вести родительский поток, если упадет созданный поток ?
Стратегия обработки ошибок ?
Стратегия работы с общими ресурсами ?
Исходя из этого уже и выбирают все events / messages / и т.д.
Полагаю, что проблема тут:
То есть генератору событий теперь до лампочки, кто, как и как долго будет обрабатывать его события.
Нафига приложение без «TimeOut»? Выжрать все ресурсы в одно рыло один генератор? Так вроде бы вычислительные ресуры то общие (см п3 выше)
Уже не первый раз все сводится к двум вопросам:
1. А что вы хотите?
2. А правильно ли выбрали инструмент и поняли вы к нему инструкцию?
Оказывается оба ответа отрицательные.
Да, неудобно отверткой закручивать гвоздь, так же как и молотком закручивать шурупы.
Но и смысла дальше повышать КПД изнчально не верных действий нет.
Я имею ввиду, что ребята вместо быстрой «телеги с лошадью», предложили «автомобиль». Кленты были и готовы :) Телеги с лошадьми и сейчас остались.
Так же и тут
Прослеживается устойчивая мысль: вы получаете то, за что платите. Хотите хороший продукт? Тогда сделайте так, чтобы тот, кто его делает был в этом заинтересован. Хотите больше UserStory и «галочек»? Получите свои UserStory и галочки. Только хорошего продукта уже не будет.
Что и требовалось выяснить- не корректное применение инструментария безграмотными менеджерами.
Вины инструментария Scum / Agilre- нет. :)
Я видел две крайности: собеседущий «подготовился» вызубрив «хитрые» книжки, API, алгоритмы. Пофиг что в проекте не используется вообще ничего из этого. Он же не хочет выглядеть в глазах Работодателя «неучем» и начинает тебя «пресовать» на собеседовании.
или
решал какую-то проблему в проекте последние месяцы, заглянув так глубоко, как только можно в недра кода и API и потом этой проблемой пытается тебя «пресовать».
Самое грустное в этих случах, когда на таких собеседованиях обнаруживается что знаешь тему лучше «собеседника» и пытаешься с ним общаться как с «равным»… Сразу в глазах у них читается «ну нахрена я спросил...» и попытки резко сменить тему :)
Ни одно из этого не помогает ни найму ни собеседованию.
А на собеседованиях моментально можно выявить того кто «заучил» или того кто понимает и применял на практике.
Думаю, постоянную Планка, число e, число Авогадо и т.д. Вам тоже преподавали на каком-то курсе. Возможно даже в школе. Сможете назвать «с ходу»?
Это особенность работы памяти/мозга — «отбрасывать» то, что не используется постоянно. Мозг извлекает память «по тригерам» — запахи, слова, жесты. Дайте мне их использовать!
Очень часто было, когда «собеседующий» не могли ответить на мои вопросы. Тоже «элементарные», только в моих проектах это были работы последних месяцев, а у них возможно и никогда.
Если вы хотите прособеседовать адекватно — пришли плиз программу собеседования.
Проблемы, то может и решают. Но может лучше их предотвращать? или просто не провоцировать эти проблемы?
С быстрых и удобных коммуникаций усилия пошли не в координацию а-ля «глобальный product/scrum backlog», а на раскрутку сотен вентиляторови вкидывания в них куч ...«всего». По итогу только дочитал ман одной СуперТулзы, как обнаружил что появилось еще пару новых СуперПупер 1.2 и на них уже код какой-то наваяли…
Неужели правоохранительные органы не могут вместе с администрацией сервисов в рамках уголовного дела использовать СОРМ и свои полномочия?
Если «эксперты» будут помогать, может быть еще хуже. Вроде «добровольные эксперты» не проводят нейро-/кардио-/… операции без специального обучения лет 10...15. Или это будет делаться под соусом «не оставление в беспомощном состоянии»?
Благими намереньями…
Как-то юридически такие действия должны сопровождаться.
Всегда старался помочь кандидату раскрыть свои знания, оценить ход его мысли, широту и гибкость взлядов и оценивал как могу их использовать в проекте. Как «дорого» будет «доточить» кандидата под проект.
А знания «API по памяти»- в большистве своем бессмысленны. На это мануалы есть и отладчик :)
Учить как находить знания, как анализировать и трактовать знания об окружающем мире.
Где грань между терроризмом, изготовленим взрывчатки и экзотермической химической реакцией вместе с третим законом ньютона? Чем определить что «царя взрывали бомбисты» правильно. Это же чистой воды пропаганда терроризма :)
Если мы против насилия и самоубийства — отлично! Давайте запретим информацию о самопожертовании вместе с распятием, запретим историю отравлений Медичи и Наполеона.
Если знания закрыть, чему будет учить школа? Выдуманными фактами вроде бы оперирует религия :)
Это как раз вас поставит в рамки :) Ваш генератор станет «колом», поскольу ничего не сгенерит, пока обработчик не вернет управление.
Если вы разрабатываете библиотеку «для того парня», вы обязаны продумать API взаимодействия. В частности Вашей задачей будет предоставить и делегаты под обработку и декларацию событий и модель асинхронной работы (Event Based, Task Based и т.д).
В общем случае не ваша забота, как будут обрабатываться ваши события и по какой модели. Даже если вы сделаете «просто один поток» то обработчики сами себе придумают как быстро вернуть управление генератору.
Вопрос только в том — генератору нужен результат «обработчика или нет».
MCTS Self-Paced Training Kit (Exam 70-536)
Если мне не изменяет память там было достаточное описание, для основ. (Chapter 7
Threading, Lesson 3: The Asynchronous Programming Model )
После без проблем «поверх ляжет» await & async
Поймите простую штуку: дьявол в деталях.
События не могут «выполняться», события можно вызвать.
А выполняется «Обработчик события».
Это два разных элемента. Когда вы сможете их рассмотреть отдельно, все станет на свои места. Пока Вы будете их рассматривать «связно» вы не получите правильного ответа.
Сам вопрос поставлен не очень корректно: как правильно молотком закручивать шуруп? :)
Правильный ответ: возьмите отвертку.
Полагаю, что нюанс в этом: Dispatcher Class
Dispatcher.BeginInvoke Method (Delegate, DispatcherPriority, Object[])
.NET Framework (current version)
Executes the specified delegate asynchronously with the specified arguments, at the specified priority, on the thread that the Dispatcher was created on.
Namespace: System.Windows.Threading
Assembly: WindowsBase (in WindowsBase.dll)
Это все есть в документации. Согласен что муторно, то иногда надо :)
Что-то из уже сделанного не подходит?
Обычно на этапе дизайна уже ищутся ответы на вопросы:
Исходя из этого уже и выбирают все events / messages / и т.д.
Полагаю, что проблема тут:
Нафига приложение без «TimeOut»? Выжрать все ресурсы в
одно рылоодин генератор? Так вроде бы вычислительные ресуры то общие (см п3 выше)А какую проблему то это все должно решить?
1. А что вы хотите?
2. А правильно ли выбрали инструмент и поняли вы к нему инструкцию?
Оказывается оба ответа отрицательные.
Да, неудобно отверткой закручивать гвоздь, так же как и молотком закручивать шурупы.
Но и смысла дальше повышать КПД изнчально не верных действий нет.
Так же и тут
Производи что покупают.
В данном случае ребята вышли на рынок к ожидающим клиентам :)
Сдать на Scrum мастера, PM- сертифиакцию и т.д.- это же недостижимо для обычных людей…
Что и требовалось выяснить- не корректное применение инструментария безграмотными менеджерами.
Вины инструментария Scum / Agilre- нет. :)