Ну и сам факт что они дают задание говорит, что чуваки просто не умеют поговорить нормально на интервью.
ГВ>Я бы всё же, посоветовал тебе самостоятельно сравнить задачу и реализацию. Глядишь, мнение бы и поменялось.
Я верю вашим комментариям, но... Обрати внимание на "но." Мой посыл был в том, что интервьюеры могли бы установить на интервью подходит им кандидат или нет не напрягая кандидата своим заданием. Далее, он сделал задание, и пусть там будет самый худший код, но они даже не удосужились ответить ему. Что о них еще можно сказать?
ГВ>>>Естественно, не твой. Я привёл это высказывание как пример аналогичного подхода. ОК>>Этот чувак, в отличии от тебя, понимает, что интервью уже давно трансформировалось в экзамен. Ты этого не понимаешь.
ГВ>Да, это отличное новое знание. Только какое отношение оно имеет к вопросу ТСа?
Да самое прямое. В отношении него была совершена несправедливость. Я объяснил причину этой несправедливости.
ГВ>>>Пытаюсь показать тебе, что ты сам и демонстрируешь поведение, за которое упрекаешь других. ОК>>Это что же я демонстрирую? Наоборот, у меня нет эго и я могу поговорить с человеком без всяких заданий.
ГВ>Прикольно. То есть попытка сократить время на оценку кандидата путём выдачи короткого задания — это признак гипертрофированного эго?
Э-э-э... Ты подумать над сказанным не хочешь? Кандидату приходится тратить свое время только потому что они не могут провести интервью! Им там (и тебе тоже) нужно пять минут на просмотр кода, но ведь кандидат-то больше времени потратил на его написание? Так что это получается игра в одни ворота. Типа "умные" чуваки будут решать подходит им кандидат или нет, но однако они лишили кандидата возможности увидеть их код.
ОК>>А вот задающие такие задания (вообще любые а не конкретно это) считают себя более умными хотя более ни на что и не способны.
ГВ>Ты всё ещё утверждаешь, что у тебя "нет эго"? Продолжай в том же духе, мне нравится твой стиль.
Ты заметь, в данной ветке только два человека сказали, что такой экзамен — ненормально. Остальные набросились на ТС, пусть он тысячу раз неправ.
Для этого, к сведению, и нужно интервью, чтобы обоим сторонам понять насколько они подходят друг другу. А тут кандидат пахал а те чуваки решили за пять минут (тебе ведь пять минут понадобилось, чтобы взглянуть на его код?) чтобы отсеять его.
Здравствуйте, Олег К., Вы писали:
ОК>Пулу при инициализации задается число рабочих потоков: ОК>bool CThreadPool::Init(int _numThreads);
ОК>Почему количество потоков не задается в конструкторе?
Стереотипичный ответ: потому что предполагается двухфазная инициализация.
ОК>Что должна вернуть функция?
Внезапно: true, если все в порядке и false, если не удалось создать все запланированные потоки.
ОК>Что делать если нельзя создать нужное количество потоков? Убивать уже созданные или оставить их так как есть? Где описание всего этого?
Ответы простейшие: а) вернуть false, б) убрать созданные.
ОК>Почему от ТС требуются юнит-тесты а составители не желают четко описать чего хотят?
Потому что не нужно быть семи пядей во лбу, чтобы ответить на поставленные вопросы.
ОК>В каком состоянии должны быть потоки? Running или suspended? Где описание?
Это можно спросить у тех, кто дал задание. Но подразумевается, что кандидат сам выберет то, что ему по вкусу.
ОК>Что делает подчеркивание перед параметром? Обычно такая хрень — спереди или сзади — вводится для членов. Какая у них венгерская нотация для самих локальных переменных и членов?
Стиль внешнего оформления задан, внутри пиши как хочешь или уточни у тех, кто дал задание.
ОК>Там еще много чего можно сказать о самом задании.
Угу, заметно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ОК>>>>Я в свою очередь добавил, что некоторые из вещей — мелочи на который нормальный инженер не будет обращать внимания. ГВ>>>Это уже просто праздник какой-то! То есть "нормальный инженер" не обращает внимание на отклонения реализации от письменного задания? ОК>>Если задание может быть непонято, то оно будет непонято! Поэтому во многих случаях явно обращают внимание читающего. Где в задании было написано, что отклоняться от интерфейса нельзя?
ГВ>Праздник плавно перерастает в феерию!
Чувак, ты бы не позорился, что ли? Я видел нормально изложенные задания и видел так, чтобы отвязаться. А есть вообще устные. Это из второй оперы.
На этом форуме мне понравилось как х64 описывал свои пожелания.
ОК>>Где другие детали описывающие какой должна быть реализация? Я привел выше несколько вопросов. А то задача сформулирована всего в пару строчек, так тут еще и юнит тесты от ТС желают!
ГВ>А зачем тебе требования к деталям реализации? Ты же всё равно потом скажешь, что, мол, не написано, что эти требования надо обязательно выполнять.
Не напишу. Это я тебе говорю к тому, что от кандидата хотят многого, а сами четко составить задание не в состоянии. Но до тебя ведь это не доходит?
ОК>>Пулу при инициализации задается число рабочих потоков: ОК>>bool CThreadPool::Init(int _numThreads);
ОК>>Почему количество потоков не задается в конструкторе?
ГВ>Стереотипичный ответ: потому что предполагается двухфазная инициализация.
Ну и нафига? Уж лучше было бы эту функцию назвать что-нибудь вроде CThreadPool::StartThreads() чтобы изменить семантику. Потоки ведь нао будет еще как-то останавливать, уничтожать, ждать их завершения и т.д.
ОК>>Что должна вернуть функция?
ГВ>Внезапно: true, если все в порядке и false, если не удалось создать все запланированные потоки.
Это твои домыслы (с коими я сам также согласен), но дай я поутрирую чуточку. Это ж сколько тебе нужно создать потоков, чтобы функция вернула ложь?
ОК>>Что делать если нельзя создать нужное количество потоков? Убивать уже созданные или оставить их так как есть? Где описание всего этого?
ГВ>Ответы простейшие: а) вернуть false, б) убрать созданные.
Смотри выше. Ну и где описание оного?
ОК>>Почему от ТС требуются юнит-тесты а составители не желают четко описать чего хотят?
ГВ>Потому что не нужно быть семи пядей во лбу, чтобы ответить на поставленные вопросы.
То есть получается, что кто-то желает многого но сам хочет сделать малого (составить нормальное задание)?
ОК>>В каком состоянии должны быть потоки? Running или suspended? Где описание?
ГВ>Это можно спросить у тех, кто дал задание. Но подразумевается, что кандидат сам выберет то, что ему по вкусу.
Почему эта ситуация не была описана в задании? Далее, почему тут можно кандидату выбирать по вкусу а изменить интерфейс как ему нравится нельзя?
ОК>>Что делает подчеркивание перед параметром? Обычно такая хрень — спереди или сзади — вводится для членов. Какая у них венгерская нотация для самих локальных переменных и членов?
ГВ>Стиль внешнего оформления задан, внутри пиши как хочешь или уточни у тех, кто дал задание.
Какой-то хреновый стиль но пусть будет по-твоему. Почему не описан внутренний стиль?
ОК>>Там еще много чего можно сказать о самом задании.
ГВ>Угу, заметно.
S>>Здравствуйте, gandjustas, Вы писали:
G>И это no hire. Неважно что нравится тебе, важно что понравится заказчику. То что ты сделал — не понравилось. Тебе кучу причин уже привели почему оно могло не понравится.
т.е. это no hire не потому, что я плохо пишу код, а потому что я не уточнил у заказчика детали?) Что ж, у меня еще есть надежда)
G>Нет, я тупо копирую готовые рабочие решения, а потом допиливаю детали.
А если готового решения нет?
G>В задании было написано, что потоки не должны простаивать и выполнять задания клиентов. Про минимизацию времени ожидания ничего не сказано. Это ты сам придумал, что вообще говоря плохо.
В моей реализации потоки не простаивают и выполняют задания клиентов. Плюс минимизируется время ожидания. Что в этом плохого?
G>Такая фраза не делает тебя специалистом. Кто мешал сразу уточнить детали и хотя бы API сделать ровно как написано?
Я уже писал об этом. ТЗ было получено через КА и мне совершенно не хотелось играть в испорченный телефон, поэтому я сам придумал вариант. В реальной обстановке, конечно же, я бы долбил заказчика до тех пор, пока ТЗ(техническое задание, не тестовое) не стало бы однозначным, что, собственно, я и делаю постоянно на текущей работе. Мне не понятно почему из этого момента раздувается такая буча.
G>И что? То что ты тут пишешь — ничего не решает. Ты же не предложил внести изменения, ты просто сделал как тебе захотелось.
см выше
G>Собеседование не для того, чтобы оценивать твое творчество. Зачем жаловаться?
Собеседование нужно для оценки кандидата работодателем и работодателя кандидатом. В то числе через их творчество.
G>Читал, поэтому и спрашиваю. Ты хотел показать себя, а не получить работу. Показал, но работодателю оказалось все равно. Зачем жаловаться?
Опять эта ерунда про жалобу. Я сделал ТЗ и не получил фидбека. Это некрасиво со стороны работодателя и я написал об этом, чтобы предостеречь других.
ОК>Почему эта ситуация не была описана в задании? Далее, почему тут можно кандидату выбирать по вкусу а изменить интерфейс как ему нравится нельзя?
Собственно, прямо в точку. В соседней ветке я говорил кому то, что ТЗ было получено через кадровое и мне не хотелось устраивать испорченный телефон по уточнению задания.
Кстати, если бы ТЗ мне дали бы на собеседовании, то я бы, однозначно, задал уточняющие вопросы по нему и скорее всего этого топика бы не было.
Ну и сам факт что они дают задание говорит, что чуваки просто не умеют поговорить нормально на интервью.
ГВ>>Я бы всё же, посоветовал тебе самостоятельно сравнить задачу и реализацию. Глядишь, мнение бы и поменялось. ОК>Я верю вашим комментариям, но... Обрати внимание на "но." Мой посыл был в том, что интервьюеры могли бы установить на интервью подходит им кандидат или нет не напрягая кандидата своим заданием. Далее, он сделал задание, и пусть там будет самый худший код, но они даже не удосужились ответить ему. Что о них еще можно сказать?
, что как минимум невежливо оставлять тесты без комментариев. Однако, я делаю из твоих пассажей такой вывод, что тебе просто хочется поругаться в адрес работодателей.
ГВ>>>>Естественно, не твой. Я привёл это высказывание как пример аналогичного подхода. ОК>>>Этот чувак, в отличии от тебя, понимает, что интервью уже давно трансформировалось в экзамен. Ты этого не понимаешь. ГВ>>Да, это отличное новое знание. Только какое отношение оно имеет к вопросу ТСа? ОК>Да самое прямое. В отношении него была совершена несправедливость. Я объяснил причину этой несправедливости.
Вообще-то, ты ничего не объяснил, а всего лишь предложил возможное объяснение. Да и то, довольно примитивное, где всё сводится к "эго" — таких объяснений тебе накидает любой студент, только-только прочитавший Фрейда.
ГВ>>>>Пытаюсь показать тебе, что ты сам и демонстрируешь поведение, за которое упрекаешь других. ОК>>>Это что же я демонстрирую? Наоборот, у меня нет эго и я могу поговорить с человеком без всяких заданий. ГВ>>Прикольно. То есть попытка сократить время на оценку кандидата путём выдачи короткого задания — это признак гипертрофированного эго? ОК>Э-э-э... Ты подумать над сказанным не хочешь? Кандидату приходится тратить свое время только потому что они не могут провести интервью! Им там (и тебе тоже) нужно пять минут на просмотр кода, но ведь кандидат-то больше времени потратил на его написание? Так что это получается игра в одни ворота. Типа "умные" чуваки будут решать подходит им кандидат или нет, но однако они лишили кандидата возможности увидеть их код.
Ну и? Да, будут. Причём тут эго-то? Люди смотрят, демонстрирует ли кандидат те навыки, которые от него ждут. Что тут такого оскорбительного? Всегда хочется посмотреть на работу мастера перед тем, как заключать с ним договор. Я понимаю, что общая ситуация может оказаться двусмысленной, как сложилась у ТС, но само по себе тестовое задание ничего оскорбительного в себе не несёт. ИМХО, надо иметь какую-то слишком уж ранимую натуру (читай, проблемы как раз с тем самым пресловутым эго), чтобы так остро на него реагировать.
ОК>>>А вот задающие такие задания (вообще любые а не конкретно это) считают себя более умными хотя более ни на что и не способны. ГВ>>Ты всё ещё утверждаешь, что у тебя "нет эго"? Продолжай в том же духе, мне нравится твой стиль. ОК>Ты заметь, в данной ветке только два человека сказали, что такой экзамен — ненормально. Остальные набросились на ТС, пусть он тысячу раз неправ.
Вот это твоя ошибка: набросились не на самого ТС, а на дело рук его. Это уже потом, когда ТС встал в позу, начали огрызаться. Ребята, учитесь отделять себя любимых от того, что вы делаете, это очень полезный навык.
ОК>Для этого, к сведению, и нужно интервью, чтобы обоим сторонам понять насколько они подходят друг другу. А тут кандидат пахал а те чуваки решили за пять минут (тебе ведь пять минут понадобилось, чтобы взглянуть на его код?) чтобы отсеять его.
Так и пяти минут достаточно, чтобы понять, что кандидат читает написанное с пятого на десятое. Я не знаю, кому как, но мне бы в ум не встало связываться с инженером, неспособным буквально последовать заданию. Какой смысл вести дальнейший разговор, если ключевой инженерный навык отсутствует?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Олег К., Вы писали:
ОК>>>Пулу при инициализации задается число рабочих потоков: ОК>>>bool CThreadPool::Init(int _numThreads); ОК>>>Почему количество потоков не задается в конструкторе? ГВ>>Стереотипичный ответ: потому что предполагается двухфазная инициализация. ОК>Ну и нафига? Уж лучше было бы эту функцию назвать что-нибудь вроде CThreadPool::StartThreads() чтобы изменить семантику. Потоки ведь нао будет еще как-то останавливать, уничтожать, ждать их завершения и т.д.
А какая тебе разница? Задание поставлено именно так, и никак иначе. Естественным следствием из наличия Init будет появление и Shutdown.
ОК>>>Что должна вернуть функция? ГВ>>Внезапно: true, если все в порядке и false, если не удалось создать все запланированные потоки. ОК>Это твои домыслы (с коими я сам также согласен), но дай я поутрирую чуточку. Это ж сколько тебе нужно создать потоков, чтобы функция вернула ложь?
Это может быть и второй по счёту поток, если система перегружена. Всё, что тут надо сделать — это отследить ошибку создания потока и прекратить инициализацию, уничтожив уже созданные потоки.
ОК>>>Что делать если нельзя создать нужное количество потоков? Убивать уже созданные или оставить их так как есть? Где описание всего этого? ГВ>>Ответы простейшие: а) вернуть false, б) убрать созданные. ОК>Смотри выше. Ну и где описание оного?
Это стереотип, которого, ИМХО, вполне достаточно для тестового задания.
ОК>>>Почему от ТС требуются юнит-тесты а составители не желают четко описать чего хотят? ГВ>>Потому что не нужно быть семи пядей во лбу, чтобы ответить на поставленные вопросы. ОК>То есть получается, что кто-то желает многого но сам хочет сделать малого (составить нормальное задание)?
Да нормальное оно вполне.
ОК>>>В каком состоянии должны быть потоки? Running или suspended? Где описание? ГВ>>Это можно спросить у тех, кто дал задание. Но подразумевается, что кандидат сам выберет то, что ему по вкусу. ОК>Почему эта ситуация не была описана в задании? Далее, почему тут можно кандидату выбирать по вкусу а изменить интерфейс как ему нравится нельзя?
Потому что интерфейс — это та часть, с которой обычно работают другие и согласуют его отдельно от деталей реализации. Здесь как раз промоделирована ситуация, когда интерфейс предписан извне, а реализация оставлена на усмотрение разработчика.
ОК>>>Что делает подчеркивание перед параметром? Обычно такая хрень — спереди или сзади — вводится для членов. Какая у них венгерская нотация для самих локальных переменных и членов? ГВ>>Стиль внешнего оформления задан, внутри пиши как хочешь или уточни у тех, кто дал задание. ОК>Какой-то хреновый стиль но пусть будет по-твоему. Почему не описан внутренний стиль?
См. выше.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так и пяти минут достаточно, чтобы понять, что кандидат читает написанное с пятого на десятое. Я не знаю, кому как, но мне бы в ум не встало связываться с инженером, неспособным буквально последовать заданию. Какой смысл вести дальнейший разговор, если ключевой инженерный навык отсутствует?
Как же вы легко лепите ярлыки)
Давайте применим эту тактику к вам, как к работодателю или интервьюеру.
1) Вы делаете вывод о целом на основе его небольшой части. Т.е. если кандидат в точности не последовал заданию (тестовому, Карл!!!), то он сразу же "неспособен" и у него "отсутствует".
2) Cпособность кандидата самостоятельно мыслить для вас является минусом. Главное, чтобы было "точно как в ТЗ". Одной из лучших практик написания кода является взаимодействие заказчика-технолога-программиста. В вашем варианте программисту вообще не нужно думать о задаче. Нужно лишь следовать тз. В итоге задача конечно будет решена, но вместо 3х голов будут использованы только 2, причем не самые компетентные.
3) Вы смешиваете тестовое задание и реальную разработку. В большинстве случае ТЗ пишут спустя рукава, поскольку никому не хочется тратить кучу времени и сил на людей, которые оценят ваш труд поверхностным взглядом за 5 мин и в большинстве случаев вынесут решение на основе своего настроения и личных предубеждений. Но Вы об этом не думаете, ставите двойку и кричите — "Следующий!". Знаете в чем проблема? В том, что слишком много голодных кадров и слишком легко их перебирать. Вероятно ситуация в ближайшие годы изменится.
Какой же ярлык можно Вам налепить в этой ситуации?
В голову приходит обидное слово, но я не буду его говорить, поскольку Вы единственный, кто дал полезную инфу по самому коду, за что Вам спасибо еще раз.
S>1) Сложно? Имо, наоборот, это как раз суть ООП — создавать абстракции и раскидывать их по классам. Если взять класс CThreadPoolX и просмотреть его методы, то становится однозначно понятно, что он делает. Я много раз видел, как люди запихивают все в 1 класс и это кошмар для понимания
Это называется ООП головного мозга. ООП это методология которая помогает решать определенные классы задач и наоборот, создает массу проблем на других классах задач. ООП часто связан с overengeneering, это рождение нелепых абстракций типа AbstractFactoryPoolCreator или VirtualTransitionActuator.
Если инженер на простой задаче разводит многоклассовый ООП с мегаклассами, то на сложной задаче его накроет полный ... сложности. Мне нравится KISS — если задача может быть решена 20 строчками, не надо писать 2000
Здравствуйте, Selavi, Вы писали:
S>>>Здравствуйте, gandjustas, Вы писали:
G>>И это no hire. Неважно что нравится тебе, важно что понравится заказчику. То что ты сделал — не понравилось. Тебе кучу причин уже привели почему оно могло не понравится. S>т.е. это no hire не потому, что я плохо пишу код, а потому что я не уточнил у заказчика детали?) Что ж, у меня еще есть надежда)
Я не знаю что они подумали, я лишь отметил слабую сторону.
G>>Нет, я тупо копирую готовые рабочие решения, а потом допиливаю детали. S>А если готового решения нет?
Значит есть близкое.
G>>В задании было написано, что потоки не должны простаивать и выполнять задания клиентов. Про минимизацию времени ожидания ничего не сказано. Это ты сам придумал, что вообще говоря плохо. S>В моей реализации потоки не простаивают и выполняют задания клиентов. Плюс минимизируется время ожидания. Что в этом плохого?
У тебя постоянно курит поток, который раскидывает задачи
G>>Такая фраза не делает тебя специалистом. Кто мешал сразу уточнить детали и хотя бы API сделать ровно как написано? S>Я уже писал об этом. ТЗ было получено через КА и мне совершенно не хотелось играть в испорченный телефон, поэтому я сам придумал вариант. В реальной обстановке, конечно же, я бы долбил заказчика до тех пор, пока ТЗ(техническое задание, не тестовое) не стало бы однозначным, что, собственно, я и делаю постоянно на текущей работе. Мне не понятно почему из этого момента раздувается такая буча.
А чем КА помешало тебе это сделать? Они же только письма форвардят и не более того. А буча раздулась потому что это критичный момент.
G>>Собеседование не для того, чтобы оценивать твое творчество. Зачем жаловаться? S>Собеседование нужно для оценки кандидата работодателем и работодателя кандидатом. В то числе через их творчество.
Это чушь. Платят тебе не за творчество и не оценивают его.
G>>Читал, поэтому и спрашиваю. Ты хотел показать себя, а не получить работу. Показал, но работодателю оказалось все равно. Зачем жаловаться? S>Опять эта ерунда про жалобу. Я сделал ТЗ и не получил фидбека. Это некрасиво со стороны работодателя и я написал об этом, чтобы предостеречь других.
Они тебе ничего не должны.
Здравствуйте, Selavi, Вы писали:
ГВ>>Так и пяти минут достаточно, чтобы понять, что кандидат читает написанное с пятого на десятое. Я не знаю, кому как, но мне бы в ум не встало связываться с инженером, неспособным буквально последовать заданию. Какой смысл вести дальнейший разговор, если ключевой инженерный навык отсутствует?
S>Как же вы легко лепите ярлыки)
Извини, я действительно в задоре заступил за грань допустимого. Кстати, ты один из тех редких собеседников, кто отслеживает такие ошибки.
Не принимай близко к сердцу, прямо к тебе это не относится и на самом деле отклонения от ТЗ не сопровождаются развешиванием таких ярлыков. Меня просто Олег немало рассмешил, вот я и расслабился. Блин, ну надо же такое ляпнуть
: "Где в задании было написано, что отклоняться от интерфейса нельзя?" Гомгардия!
S>Давайте применим эту тактику к вам, как к работодателю или интервьюеру.
Хорошая мысль.
S>1) Вы делаете вывод о целом на основе его небольшой части. Т.е. если кандидат в точности не последовал заданию (тестовому, Карл!!!), то он сразу же "неспособен" и у него "отсутствует".
Выводя я делаю на основании нескольких факторов. Точность следования заданию — один из них. Его вес не абсолютный, он играет свою роль только вместе с другими оценками. Собственно, я тебе это прямо и написал
.
S>2) Cпособность кандидата самостоятельно мыслить для вас является минусом.
С чего это вдруг?
S>Главное, чтобы было "точно как в ТЗ". Одной из лучших практик написания кода является взаимодействие заказчика-технолога-программиста. В вашем варианте программисту вообще не нужно думать о задаче. Нужно лишь следовать тз. В итоге задача конечно будет решена, но вместо 3х голов будут использованы только 2, причем не самые компетентные.
Погоди. Здесь по условиям задачи есть только двое: заказчик (я) и исполнитель (кандидат). Между нами — текст задания. В идеале кандидат сам додумает недостающие аспекты задания и сделает это так, чтобы не нарушать то, что обозначено явно. Если не получается, он вполне может прямо спросить или уточнить. Собственно, примером из твоего задания служит Init и недостающий, парный ему метод Shutdown.
S>3) Вы смешиваете тестовое задание и реальную разработку.
Тест даётся для того, чтобы составить некоторое представление о том, как человек может работать. На 100% его, конечно, переносить нельзя, но некоторое более или менее предметное впечатление о кандидате составить можно.
S>В большинстве случае ТЗ пишут спустя рукава, поскольку никому не хочется тратить кучу времени и сил на людей, которые оценят ваш труд поверхностным взглядом за 5 мин и в большинстве случаев вынесут решение на основе своего настроения и личных предубеждений. Но Вы об этом не думаете, ставите двойку и кричите — "Следующий!". Знаете в чем проблема? В том, что слишком много голодных кадров и слишком легко их перебирать. Вероятно ситуация в ближайшие годы изменится.
Вот сейчас ты сам смешиваешь тестовое задание и реальную разработку, пытаясь прямо переносить не самые удачные "реальные практики" на тест. Не надо этого делать, поскольку тест — это своего рода игра, и игра со вполне определёнными правилами.
S>Какой же ярлык можно Вам налепить в этой ситуации?
S>В голову приходит обидное слово, но я не буду его говорить, поскольку Вы единственный, кто дал полезную инфу по самому коду, за что Вам спасибо еще раз.
Пожалуйста. И извини ещё раз, за то, что я тебя задел.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
S>1) Вы делаете вывод о целом на основе его небольшой части. Т.е. если кандидат в точности не последовал заданию (тестовому, Карл!!!), то он сразу же "неспособен" и у него "отсутствует".
Если не последовал — значит вместо решения задач заказчика человек начнет придумывать свои велосипеды. Делать ТЗ без извращений — это уже похвально и ценно.
S>2) Cпособность кандидата самостоятельно мыслить для вас является минусом. Главное, чтобы было "точно как в ТЗ". Одной из лучших практик написания кода является взаимодействие заказчика-технолога-программиста. В вашем варианте программисту вообще не нужно думать о задаче. Нужно лишь следовать тз. В итоге задача конечно будет решена, но вместо 3х голов будут использованы только 2, причем не самые компетентные.
Мыслить на минимизацию трудозатрат — отлично. Мыслить на изобретение гиперфотонных бульбуляторов идет кандидату в минус
S>3) Вы смешиваете тестовое задание и реальную разработку. В большинстве случае ТЗ пишут спустя рукава, поскольку никому не хочется тратить кучу времени и сил на людей, которые оценят ваш труд поверхностным взглядом за 5 мин и в большинстве случаев вынесут решение на основе своего настроения и личных предубеждений. Но Вы об этом не думаете, ставите двойку и кричите — "Следующий!". Знаете в чем проблема? В том, что слишком много голодных кадров и слишком легко их перебирать. Вероятно ситуация в ближайшие годы изменится.
ТЗ это визитная карточка. Ситуация, вероятно, только усугубится и связано это с деградацией образования и оттоком мозгов в другие страны
Здравствуйте, GreenTea, Вы писали:
GT>Если кто шарит в java, прошу поревьювить. Я сам с ручной многопоточностью редко работал, так что могут быть косяки..
Представь ситуацию, когда в первой половине tasks у нас задачи от первого клиента, а во второй — от второго, и всего один рабочий поток. Он будет выполнять все задания по списку, то есть сначала все от первого клиента, хотя по заданию должен чередовать.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, GreenTea, Вы писали:
GT>>Если кто шарит в java, прошу поревьювить. Я сам с ручной многопоточностью редко работал, так что могут быть косяки..
EP>Представь ситуацию, когда в первой половине tasks у нас задачи от первого клиента, а во второй — от второго, и всего один рабочий поток. Он будет выполнять все задания по списку, то есть сначала все от первого клиента, хотя по заданию должен чередовать.
Согласен.. Поправил.
package net.sf.brunneng;
import java.util.*;
public class ThreadPool {
private class ClientTask {
final int clientId;
final Runnable runnable;
public ClientTask(int clientId, Runnable runnable) {
this.clientId = clientId;
this.runnable = runnable;
}
}
private boolean closed;
private final List<ClientTask> tasks = Collections.synchronizedList(new ArrayList<ClientTask>());
private List<Thread> threads = new ArrayList<Thread>();
private Set<Integer> executingClients = Collections.synchronizedSet(new HashSet<Integer>());
public List<ClientTask> getTasks() {
return tasks;
}
public ThreadPool(int threadsCount) {
for (int i = 0; i < threadsCount; ++i) {
Thread thread = createThread();
threads.add(thread);
thread.start();
}
}
private ClientTask getNextClientTask() {
ClientTask res = null;
synchronized (tasks) {
for (int i = 0; i < tasks.size(); i++) {
ClientTask task = tasks.get(i);
if (!executingClients.contains(task.clientId)) {
res = task;
executingClients.add(task.clientId);
tasks.remove(i);
break;
}
}
}
return res;
}
private Thread createThread() {
return new Thread(new Runnable() {
@Override
public void run() {
boolean finish = false;
while (!finish && !closed) {
try {
ClientTask task = getNextClientTask();
if (task == null) {
synchronized (tasks) {
tasks.wait();
}
continue;
}
task.runnable.run();
executingClients.remove(task.clientId);
} catch (InterruptedException e) {
e.printStackTrace();
finish = true;
}
}
}
});
}
public void addTask(int clientId, Runnable task) {
synchronized (tasks) {
int nextIndex = findBestIndexToInsert(clientId);
tasks.add(nextIndex, new ClientTask(clientId, task));
if (!executingClients.contains(clientId)) {
tasks.notify();
}
}
}
private int findBestIndexToInsert(int clientId) {
int minIndex = 0;
for (int i = 0; i < tasks.size(); ++i) {
ClientTask task = tasks.get(i);
if (task.clientId == clientId) {
minIndex = i + 1;
}
}
return minIndex < tasks.size() ? minIndex + 1 : minIndex;
}
public void close() {
closed = true;
synchronized (tasks) {
tasks.notifyAll();
}
for (Thread thread : threads) {
try {
thread.join();
} catch (InterruptedException ignored) {
}
}
}
}
EP>>Сложность N вызовов addTask квадратичная — O(N*N).
GT>Ну и что? Даже при миллионе тасок этот цикл будет выполняться за миллисекунды. А ситуация что там будет миллион тасок врят-ли реальна.
К слову только что замерил, вот такой цикл
long start = System.currentTimeMillis();
long count = 0;
for (int i = 0; i < 10000000; ++i) {
if (args.length % (i+1) == 0) {
count++;
}
}
long end = System.currentTimeMillis();
System.out.println("Count = " + count + "; execution time: " + (end - start) + "ms");
Выводит у меня:
Count = 10000000; execution time: 30ms
Я не знаю, кому как, но мне бы в ум не встало связываться с инженером, неспособным буквально последовать заданию. Какой смысл вести дальнейший разговор, если ключевой инженерный навык отсутствует?
