Все делаю — на работу не берут! (Харьков)

Всем, Hello!

Читал топики по поиску работы и коменты к ним, и т.д.
Мне 25, закончил курсы тестировщиков. Знаю теорию, англ. intermediate. Разослал за 1,5 месяца 80+ резюме и они же висят 5 сайтах по поису работы, был на 10+ собеседованиях. Самообучаюсь: вебинары, книги, википедия, гугл и т.д. Следую многим совет. В голове есть мозг.
Не берут...

LinkedIn:www.linkedin.com/...​esponsive_tab_profile_pic

Резюме:docs.google.com/...​tTGh4bG8/edit?usp=sharing

Немного изменил резюме

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Почитал топик, зашел на линкедин автора поста, а там чувак уже у QA Team Lead в небезызвестной NameCheap. Всего 4 года труда понадобилось. Успехов Вам, Александр!

когда-то будет наоборот:
везде берут — ничего не делаю

На собеседованиях входи в роль что ты в доску командный игрок, обожаешь митинги-хуитинги, срамы и вообще вместо своей личной жизни готов сутками разукрашивать офис/фиксить баги/митинговать (нужное подчеркнуть). Через 3-5 лет что ты будешь делать? Ну конечно же работать на благо этой же XXX-галеры, а не прыгнуть на +500 в ЕПАМ.

Что еще — своим видом и разговором не давай понять что ты представляешь угрозу для начальства и прочих личностей в конторе == «не раскачивать лодку».

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

С сарказмом не переигрывай — идеальная роль эдакий Алеша Попович (а из какого места — не скажу!)

Как правило hr-ки слышат что хотят слышать и охотно верят.

Кто желает учится?Большой выбор Высших Военных Учебник Заведений, в любой точке Украины!!!!Вам нужно только захотеть, всем остальным займёмся мы!!Вопросы по телефону 0674776353

Ну что, как у Вас очередное собеседование прошло?

спс норм заказали запомнился. намного лучше чем первые 5, уже есть опыт так сказать. Спс за советы. Завтра еще одно . но не по QA, по HTML\CSS. а в этом я слабее. Сказали пройдешь сначала тесты, типа www.quizful.net/test/css_basic если пройдешь сразу собес. Так что пошел читать хтмл бук)))

Ну и что сказали? Мой совет — дай ссылку HRу на этот топик. Мы хотим услышать и другую сторону. А заодно увеличишь себе вероятность быть нанятым.

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

Почему-то напомнило старый анекдот периода первоначального накопления капитала:

Встречаются два русских предпринимателя. Один другому говорит:
— Тебе не нужен вагон сахара?
— Конечно, нужен!
И они расходятся: один — искать вагон сахара, другой — искать деньги...

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

Мне всегда в таких случаях вспоминается Жванецкий: «Запах он чем хорош? Не хочешь нюхать — отойди» :)

Отож, и это один из случаев, когда HR-ы не озвучивают причину отказа :) А ведь бывает и такое, что просто не понравился человек внешне (даже если он опрятен) и его не берут на работу?

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

Я бы сказал, что немытая голова, перегар и футболка «darkthrone» это только плюс и таким кандидатам надо отдавать предпочтение.

....или девушка красивее HR-ки

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

глянули с коллегами на твою фотку. 99% ответ один — фотку смени. на этой фотке ты похож на гея ( а может и не только похож).
настоящий тестировщик должен быть похож на задрота :-)

У модераторов доу хорошее чувство юмора :)
Мне пришло уведомление по почте:

Разжигание меж-профессиональной розни
:)
Оказывается гей — это профессия.

Уведомление приходит от того, кто пожаловался на комментарий,
у модераторов вместо «пожаловаться» кнопка «удалить».

настоящий тестировщик должен быть похож на задрота :-)
работа та же — в говне ковыряться
тестировшики негодуют

Они как настоящие мужики должны быть всегда немного неопрятны, или рукав надорван, или спина в говне :)

Скорее всего 9 было бы отсеяно уже по резюме, а то на кторое стоило пойти — 11е-19е, куда его не пригласили.
А ещё — те люди которые его отсеяли с немалой долей вероятности есть на ДОУ. Странно, что не отписываются. Я думаю, если бы перечислил КУДА не взяли, были бы ответы из первых рук.

Хотя культуру не отвечать соискателю прямо — нужно из работников HR выжигать колёным железом.

могу написать названия компаний, думая как оно мне вернется???

а может быть такое: HR посмотрит что на 10+ собесах был и не взяли, так че я буду брать его и изначально забраковать потому что не взяли те 10. типа ваще безнадежный??

типа ваще безнадежный??
Ну почему безнадежный.
Еще можно в киевах позаваливать.

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

Мысли сходятся :)
В реальности же я встречал очень мало безнадёжных людей. Все они поголовно считали себя супер-гениальными, соответственно ничему не учились. Ты не из них.

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

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

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

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

Есть люди которые умеют подавать хорошие новости. Евангелисты. Если бы тебя прокачивал евангелист, ты бы сам меньше чем на 5000$ не пошёл :)

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

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

Для сравнения: если у тебя нет полмизинца — ты либо бандит, либо бездарь за станком, а то и просто идиот и нельзя допускать ни к какому оборудованию. А если нет руки целиком — ты инвалид, к тебе толерантны.

На самом деле людям действительно интереснее СЛЫШАТЬ о плохом. Но ГОВОРИТЬ хорошее. И только журналисты и политики делают наоборот :)

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

Это если абстрагироваться от факта, что вставлять в cv фотку в принципе дичь.

Как раз это до лампочки. Кому фиолетово просто не смотрит фотку. Всё равно ж поищут по соц.сетям и всё увидят. А если нет фотки, может так статься что найдут однофамильца (не факт что положительного).

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

Дять,

CV нечитабельно. На третьей строчке хотелось в корзину отправить. Оно не дает полной картины ни опыта работы ни навыков. У вменяемого CV есть четкая структура. Ее знает HR.
На мой взгляд нужно:
1. Перешерстить сайты по составлению CV американские и канадские. Сделать в их формате.
2. Перегнать CV в PDF.
3. Изменить фото.

Ну и главное: можно по три собеседования в день проходить и не найти работу.
На очередном интервью задай вопрос: «Что не так с моим резюме?» и тд. Так же попроси совета как по опыту так и по CV. Помогает очень на следующем.

Удачи!

Почему половина комментариев касаются резюме, если человека успешно по этому резюме приглашают на собеседования. Очевидно же, что проблема в другом

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

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

Цель у резюме проста:
1) Заинтересовать, чтобы пригласили на нужное собеседование на желаемую должность.
2) Чтобы НЕ приглашали туда, где заведомо не возьмут.
3) Чтобы заранее не подойти спамерам, которым абы кто лишь бы куда сунуть и получить откат.

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

Но к чему это? Человек пишет, что провалил больше десятка собеседований, и не знает почему, просит помощи найти причину. И ему написали пару сотен комментариев, как поменять форматирование в резюме, что в данном случае вобще не в тему.

Что значит — «успешно приглашают»? В смысле человек принимает приглашение что ли?

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

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

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

Чем «успешно приглашают» отличается от «неуспешно» или просто «приглашают»?

Вы же тестировщик
Хосспади упаси. С чего вы взяли, что я тестер?

Последний вопрос к Oksana Zadorozhnyaya. Завтра на собеседовании спросят чем я занимался, где работал и т.д. с 2008. На Ваш взгляд что мне лучше ответь?

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

Подкасты на ДОУ показывают что не все люди строили карьеру «по учебнику». И ничего — попали в лучшие компании.

Я и не говорила о карьере по учебнику. Алексей, боюсь, Вы не прочли все комментарии по поводу правильного\неправильного опыта. Не бывает «неправильного» опыта. Ранее я просто писала о людях, которые каждые 3-4 мес. меняют не просто работу, а сферу деятельности и назвала их потенциально подозрительными. А 2008 год фигурирует в моих вопросах исключительно потому, что у ТС он является годом окончания университета, но ни одно из мест работы, начиная с этого самого 2008-го года, не указано в резюме :-)

Посещал монастырь Дзен, постигал свет истины и занимался кунг-фу. Мечтаешь убить Билла.

Посмотри подкасты на ДОУ, все как один имеют «неправильный» опыт. И добрая половина хрен знает чем занималсь с 2008-го.

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

Знаю людей лично:
23 года — программил микроконтроллеры — крутой англицкий — курсы по тестированию -> походил на собеседования -> выбирал куда пойти работать -> вроде 300$.
27 года — в ИТ не работал, хотя учился на программера — посредственный англицкий — 2-3 недели проштудировал книги, статьи, видеоуроки и т.д. -> походил на собеседования -> вроде 400$, но по трудовой, так что я не знаю, сколько на руки.

300-400$ это зарплата или стипендия? Потому что 400$ в ГлобалЛоджике — стипендия, для толковых ребят.

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

Вот, взгляни: я ничего не исправлял в тексте, лишь накинул форматирование по ширине + шрифт Times, сделал несколько разрывов на удобные кусочки. Разве не лучше стало?
SSMaker.ru/e57d8f58 (масштаб 75%)

И ещё момент — исправь или внеси в словарь все подчёркивания грамматики вордом. Потому что что когда получатель открывает, он весь красно-зелёный! Нельзя портить впечатление по мелочам.

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

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

Ну что сказать. На счет резюме и английского я понял вопросов нет. Но из остального я понял что HR исчут изумруды самородки, и пренебрегают золотом! 2 варианта развития событий: Пойду читать книжки, учить английский и т.п. Или возьму веревку и мыло, ну дальше сами знаете что. Так как мне 25 и я не самородок, а еще и в резюме не написал где работал, и вообще пишу с ошибками... то я просто недостоин великой отрасли IT. Всем спс за советы, дельные и не очень. За критику тоже.

Все остальные пойдут как соучастники, либо по статье «оставление человека в опасности».

это недоказуемо в данном случае

А Вы скромно именуете себя золотом?

Оксана, а у вас на собеседовании, ещё никто не угрожал в окно выкинутся? :)

Нет, я на собеседовании добрая, пока не было суицидально-настроенных, а для выбрасывания у нас не окно, а балкон — 26 этаж все-таки.

Владеете даром воскрешения, наверное! И мертвого достанете))) Если Вам не нравится сравните 1 и 2.)

Просто полюбопытствовала, т.к. был использован крайне сильный образ.

Для вдохновления:
habrahabr.ru/post/187770 Девушка изучает веб-программирование: 180 сайтов за 180 дней
Попробуйте тестировать 1 веб-ресурс в день и писать у себя на сайте отзыв, параллельно где-нибудь работая, не в IT, чтобы было за что покушать.
Или возьмите не веб-ресурсы а программы с sf.net или другие известные open-source. В общем, выбирайте то, что вам нравится, но сделайте это качественно. Я не даю гарантий, но люди так делают.

великой отрасли IT
Это миф, есть много хороших профессий. Physical and biomedical electronics, где Вы учились, не хуже чем IT.

Про барышню вдохновило реально крутая баба))

Во-первых, не отчаивайтесь, внимайте советам, которые Вам здесь дают, и продложайте искать работу. Кто ищет, как известно, тот всегда найдет; и не Вы первый, не Вы последний, кто долго ищет. Если Вам отказали после собеседования, то Вы имеете право спросить о причине отказа (хотя HR, в свою очередь, не обязан ее озвучивать, но, как говорится, за спрос в глаз не бьют). Спросите — узнаете, в чем именно нужно еще поработать над собой.

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

И еще. Вот эта фраза, мягко говоря, насторожила: «Programming languages, initial basic knowledge of: SQL, C#, Java, HTML, CSS. »

:) Если Вы не считаете HTML и CSS языками программирования, то, может, есть смысл отдельно указать языки программирования, с которыми Вы знакомы, а потом уж «basic knowledge of: HTML, CSS.» Чтобы это не было, так сказать, камнем преткновения для тех, кто будет рассматривать Ваше резюме...

Удачи!

не считаете HTML и CSS языками программирования
сильно философский вопрос:)

Я что-то пропустил? HTML или CSS стал тьюринг-полным? TeX, PostScript — эти да.

где-то написано про тьюринг-полноту?

Як же за***обують такі теми, мало того шо писати нормально ніхрена не вміє, половину скілів які собі присвоїв чув тільки в неті, дивується чого його не беруть після 10+ співбесід, і ше й мусить всрати пост на доу. Чувак йди в охоронці, там твої скіли якраз пригодяться.
Тут більшість людей провела свою юність за книжками і клавіатурою, поки ти шлявся на районі і по «діскатєках», а аж в 25 років рішив заробляти, і почув шо в ІТ бабло лопатою можна гребти. Халяви нема і не буде.

Вiдповiдаю шановному пану! Который знает мою жизнь лучше чем свою. Если Вы такой умный, и вместо дельного совета оскорбляете людей. То я бы с удовольствием понаблюдал за Вашими действиями по поиску работы в сегодняшних услових. С теми Скилами которые были у Вас после окончания вуза!!! Ненравится тема зачем вообще писать свое мнение.

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

А кто первую работу нашел еще до существования ДОУ — тот уже старпер!

«Шановний пан» найшов роботу на другому курсі університету, з тими скілами які даються на перших 2х курсах.
Взагалі рекомендую зайнятися не тим де «більше платять, всі їдять сири і мають зеркалки», а тим шо подобається, тоді будеш в набагато більшому шоколаді, і роботу любити і гроші заробляти, і горя не знати.

Класс, а я уже думал что один такой со второго курса работаю.

А мир пересобирать на первом?

а у меня на 2м только комп появился(

Дуже радий за пана! Та я не женуся за баблом, розумiю, щоб заробляти треба вкалувати. I так стараюсь i робити.

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

Спавжнiй HR! Це комплiент. До кожоно слова доколупаеться!!

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

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

А у меня вот нету с вами даже 2nd connections и я профайл не вижу. Веский повод не давать ссылку на Линкедин как основную.

Попробуйте набрать в поиске LinkedIn: Alexandr Polunin. Должно получится:)

Попробуйте набрать в поиске LinkedIn: Alexandr Polunin. Должно получится:)
А зачем? Кому это надо?

а че тогда лицо такое довольное на фото?

Два рази намагався відповісти посиланням на картинки, але відповім вам таки словами.
«Глибоко засмучений вашою поразкою.»

Небольшой краш-тест резюме (если Вам действительно важно понять, что не так, а не просто «засветиться» на ДОУ в надежде, что кто-то возьмет к себе):
1. «Простыня» тескта просто нечитабельна. Неужели внимательный человек, которому, возможно, придется тестировать и интерфейсы в т.ч., не замечает этого? Наталкивает на размышления
2. Английский плох. Правда. Много руссизмов, слова употреблены не в их исконном значении. Если Вы заявляете знание английского, будьте добры посидеть со словарем или дать вычитать человеку понимающему. Если Вы этого не делаете, где-то на подсознательном уровне я уже допускаю, что, если Вы для себя, любимого, делаете что-то спустя пукава, как Вы будете работать на кого-то?
3. Много ошибок. Как по мне, для тестировщика это недопустимо.
4. Чем Вы занимались с 2008 года до этого времени? Не знаю, как кому, а мне, как ХР интересно знать об этом
5. Вы готовы платить за то, что будете приходить на тяжелую работу? Или как понимать Вашу фразу «I can compensate for hard work»?
6. И, пожалуйста, не перечисляйте скиллзы через запятую — это же не читабельно. Список будет самое ок (только грамотно используйте пространство страницы)
Но что-то мне подсказывает, что проблема не столько в резюме, сколько в чем-то другом. То количество собеседований, которое у Вас было, позволяет найти работу. Если нет — может, «проблема в консерватории»?

На счет нечитабельности простыни незнаю. Открывал с планшета и мобильного, все ок. Английский согласен. Ошибки возможны. Я могу расписать чем занимался с 2008, сфера продаж и логистика. По мне это не касается тестирования. Не будет иметь отношения к QA. Там же указано limited experience —

«I can compensate for hard work»?
. И вообще каждому HR неугодишь. Для одого резюме идеальное, другой его выбросит его в окно прочитав 2 строки. Пусть мое резюме прочитают 100 HR-ов, и я уверен 90 скажут х*ня.
И вообще каждому HR неугодишь. Для одого резюме идеальное, другой его выбросит его в окно прочитав 2 строки. Пусть мое резюме прочитают 100 HR-ов, и я уверен 90 скажут х*ня.

Если у вас нет интереса в улучшении юзабилити/читаемости своего резюме, откуда возьмётся интерес к тестируемому продукту?

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

И вообще каждому HR неугодишь
Вам ответил ХР, для которого работа с резюме — профессиональная деятельность.Есть определенные стандарты составления резюме. Или Вы тим-лиду тоже станете говорить, что составляете, скажем, тест-кейсы или баг-репорты так, как Вам удобно (на каждого тим-лида ведь не угодишь) и с планшета все ок? Вместо того, чтобы сказать спасибо и задуматься, Вы ведете себя несколько агрессивно.
З.Ы. Русский с ошибками тоже не красит тестировщика. И сейчас я не для того пишу, чтобы помахать пальчиком и сказать: «Ну-ну-ну!», а для того, чтобы Вы посмотрели на себя чуток со стороны. Может, из-за этого Вы дальше ХР собеседования не проходите?

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

Пусть мое резюме прочитают 100 HR-ов, и я уверен 90 скажут х*ня.
А если 90 скажут, что ок, а остальные 10 — Ваш вариант, тогда это победа. Но ныть, чо не берут, — легче, чем переписать резюме и откорректировать поведение.

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

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

4. Чем Вы занимались с 2008 года до этого времени? Не знаю, как кому, а мне, как ХР интересно знать об этом
Люди с 2008 года до этого времени могут заниматься чем угодно: болеть или ухаживать за больными, подрабатывая на несложной работе, быть миротворцем в армии по контракту, жить в лесу с грибными эльфами, работать аниматором при отелях в Египте, да много чего ещё, трагического и самого обычного, с налётом эксапизма. Но то было в прошлом.

Знаете...

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

Объясните этот момент.

Продуктовые компании хотят и взращивают, потому и спрашиваю. Но вот взращивать хочется не всякого, а человека, который хочет взращиваться, который готов учится (и, как минимум, поднять пятую точку, заглянуть в словарь, исправить ошибки). Но мне всегда интересен предыдущий опыт, так как никогда не знаешь, чем он может оказаться полезен. Возможно, у меня 100500 проектов и часть из них пересекается с предыдущей деятельностью кандидата. И всегда интересно, что сподвигло человека поменять вид деятельности — настоящий интерес или «я буду тыкать в кнопочки с 9 до 6 потому что тут много платят». Если второй вариант, то мне, скорее, такой человек неинтересен, т.к. в компании уже сложилась определенная корпоративная культура, в которую претендент не впишется. Экономя и свое, и чужое время (т.к. время, потраченное на подбор == деньги компании) я сразу спрашиваю о предыдущем опыте (например, если у человека 4 мес. ОР продавцом, потом 5- промоутером, потом 3 — водителем, потом 4- бухгалетром и т.д., я, подверженная стереотипам, восприму как возможность того, что через 4-5 мес. он от нас уйдет в капитаны дальнего плавания или еще куда искать себя дальше)

А то, что у человека была каша в голове, но он привёл себя в порядок — не рассматривается?

Или коль не начал программировать с 13 лет — так сразу и ставим на человеке крест?

Рассматривается, но при прочих равных я лучше возьму человека,у которого не было каши в голове, просто чтобы не рисковать. Грубо — но честно. И никто не ищет программистов, начавших программировать с 13. Вы передергиваете. Перечитайте внимательнее — я о другом писала.

Думаете, что может наступить рецидив?

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

Особенно, когда интересуются как-то в стиле: «Почему вы в хзсофт-консалтинг проработали 3-6-9 месяцев, вы что, попрыгун?», а потом сами не знают, куда пристроить человека после внезапно приостановленного через 2-5-8 месяцев проекта, а на вопрос «WTF?» отвечают «Ой!.. :-(»

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


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

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

Я вас понял.

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

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

Это у вас не страшно, а в других местах за это накажут.

Ну так я же не в другие места набираю, а к нам. в других местах рекрутеры, видимо, по другим критерям отбирают и другие вопросы задают

приходили 25-летние и не могли ответить ни о хобби, ни об интересах, вообще ни о чем
а я, например, и не собираюсь распинаться перед каким-то эйчаром о своих интересах и хобби.

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

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

А какие такие специалисты идут работать на проетк, не выяснив деталей? Мне такие не встречались еще :-)

Лапшу на уши вешают очень часто и убедительно.

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

Которые не знают, что спрашивать.
Которые выяснили одно, а на самом деле там всё иначе.

Я выяснял о деталях проекта на некоторых собеседованиях, а там от ответа по-риэлторски уклонялись или говорили, что рано ещё такие вопросы задавать, на данном этапе.

__а на каком тогда этапе их задавать?
__сначала интервью в 1-2-3 подхода
__потом оффер или отказ
__потом испытальный срок или сразу без него, где начинаются интересности, сразу или чуть погодя.

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

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

Вы сейчас Оксану на чем-то подловить пытаетесь?

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

Не он пытается, а я. И не подловить, а понять.

Для человека, которому нужна работа у вас довольно странная манера общения, если честно.
мне показалось или подобная манера проскакивает у 90% тех, кто создает топики «не могу найти работу»? Это сейчас новая инфекция у джунов такая?

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

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

Вон, некто С. Скунин писал почти то же самое

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

писал, будучи 1Сником.

1с по Вашему не люди? И не заслуживают норм работы и уважения? ПОсмотрел бы я на вас батенька. После того как вас жизнь поламала бы, и вы стали 1с ником

По-моему, вы просто не в состоянии прочитать написанное. Кругом враги, да?

Держал в страхе весь родной двор
Но мент пришел, и краток разговор
По почкам получил от пепеэснка,
Жизнь поломала — стал 1Сником.

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

У меня вот с 7-го класса мечта работать программистом. А то что я не сразу после школы в программисты, все не возьмете. Конец мечте???((((((

так чего тогда в QA, а не в программисты?)

Не паясничайте, пожалуйста. Это никого не красит. У меня есть программисты с далеко не программистским образованием и разным ОР до ИТ. Но ни один из них не вел себя таким образом.

я вам хамил, или оскорбил Вас. Или сделал замечание именно Вам? Или у Вас просто завышенная самооценка?

Я нигде не написала, что Вы хамите, я написала, что вы паясничаете.

А то что я не сразу после школы в программисты, все не возьмете. Конец мечте???((((((
Именно тут и пасничали:-)
А диагнозы по юзерпику ставить — последнее дело :-)
У меня вот с 7-го класса мечта работать программистом
И шо вы таки сделали с вашей мечтой? Как поняли, что хотите быть программистом, и что для этого делали?
У меня вот с 7-го класса мечта работать программистом.
Мой одноклассник серьёзно занимался лёхкой отлетекой, как для 16 лет показывал многообещающие результаты, мечтал через четыре года попасть в сборную и выступить на Олимпиаде.
А после школы поступил в военное училище, женился на дочке командира училища и сейчас заведует нефтебазой в Забайкалье.

Молодец хорошо устроился. Он изменил мечте, ну бывает. А у меня есть огромное желание мечту осуществить. Если даже завтра сорву джек пот, все равно мечта останется!!!

Твой опыт не релевантен, тем более программировать — не батальон вести в бой.

Знаете, я возьму того, кто знает, зачем он идет в ту или иную сферу. И студенты и 4, и 5 курса у меня вполне хорошо работают, не забивая. Возраст еще не показатель отсутствия «ветра в голове». И я уже писала, что не отбрасываю людей с опытом в разных сферах, Вам стоит научится читать повнимательнее — в работе тестировщиком это весьма пригодится. Просто я отношусь к людям, не задерживающимся нигде дольше 4-5 месяцев с определенным подозрением, т.к. они или бросили дело на полпути, или не знают чего хотят от жизни. У нас, хоть и продуктовая компания, но не профориентационный центр. Это бизнес — мы платим деньги за работу, а не за попытку.

Просто я отношусь к людям, не задерживающимся нигде дольше 4-5 месяцев с определенным подозрением, т.к. они или бросили дело на полпути, или не знают чего хотят от жизни
Помню устраивался я работать в бодишоп и на стандартный вопрос «Кем вы себя видите через год» — ответил что техдиром. Посмеялись вместе. Через полгода я уволился, чтоб перейти на должность техдира в стартап.

Это я к чему? Если человек часто меняет работу — это не значит, что он не знает, чего хочет от жизни. Возможно наоборот — он весьма трезво идет к цели.

Да, но в процентном соотношении таких сильно меньше, чем тех, которые просто не знают, чего хотят. И, если в данный момент времени я не могу себе позволить рисковать, то и рисковать не буду. Тем более, что выше я писала о людях, которые меняют каждые 4-5 месяцев не просто место работы,но и сферу деятельности.
З.Ы. Про кем Вы себя видите никогда не спрашиваю. Считаю вопрос недостаточно показательным.

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

Ситуацию с родственником гипотетическим мы уже тоже рассматривали сегодня. Но таким образом бросит он одну работу. Если же бросает работу каждые 3-4 месяца, то в уходе ли за кем-то дело?

Справа в тому, що в більшості людей тут ситуація інша, ні в Україні і у Вас. Не вони шукають роботу, а робота шукає їх. Так шукає, що їх (чи нас) мало не в дупу готові цілувати аби тільки в офіс ходили. Ібо такий ринок.
І тому ситий голодному не товарищ, Вас не зрозуміють.
Ваш наступний крок:
1. В резюме вказати, що працюєте за досвід, а не за гроші.
2. На співбесіді попросити детальний фідбек що в Вас не так, і звернути на це увагу.
3. Я впевнений, що Вас візьмуть.
4. Коли візьмуть, з Вас пузирь :-)

За 2 роки Ви будете таки же «крутим» як місцеві, і будете роздавати поради.

Першi два кроки i так роблю. У треть’ому майже не сумнi ваюсь. Пузирь не гарантую, а ось добрi вiдгуки це можу)))

единственный позитивный комментарий из всех что прочитал

Я обязательно спрошу, почему такой скачок. Еще лучше — если человек, понимая, что это вызовет вопросы, сам напишет в кавер-леттер, например. Это может быть как норм (объективные причины, например, не было возможности обучаться/работать в другом месте, скажем, кто-то из родственников нуждался в уходе, а в провинции нет другой работы), так и не норм (работал 4 года охранником, а потом узнал про сыр, учиться не хочу, а сыра хочу)

Конечно, бывают различные комбинации.Яя говорила о крайних вариантах.

Мне приятнее, когда вкратце, не расписывая, пишут о предыдущей работе. А то странно смотрится (где-то на уровне подсознания) тридцатилетний джуниор, который нигде не работал (может и работал где-то, но мое подсознание кричит мне:"Не работал!")

вам уже ответили что многие не советуют писать опыт не в IT

Писать или не писать — личное дело каждого. Я описала свои ощущения от «пустого» резюме.

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

Я не говорю о «делать больше, чем платят». Я говорю о формальном подходе к работе и отсиждывании рабочих часов вместо собственно работы.

Есть задача X которую нужно решить за время Y с уровнем качества Q. Я так понимаю что интерес вам нужен для того чтобы была мотивация сделать задачу за (Y minus T) время c тем же качеством — выиграш только в том что такой человек посидит меньше времени на DOU и больше за работой. ;-)
Но отсидеться в любом случае не получится.

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

Это больше относится к проблемам вашего дырявого процесса разработки, если такое возможно проделать. ;-)

Расскажите, как вы проверяете качество работы тестера-мануальщика (так, что у вас ошибки исключены)

Мануальщики проверяют сценарии и делают скриншоты чекпоинтов. Но постепенно движемся к своей мечте — полностью перейти к автотестам. ;-)

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

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

Я не знаю какой у вас там уровень Code Coverage, ну и конечно если покрыты тестами функции типа long get_id() const { return id; }; то это ничего не решает. ;-)
Это сложно, но думаю что в принципе это возможно.

Подумайте ещё раз. У каждой функции довольно много комбинаций входных данных — по каждому экстремуму каждого параметра. Другими словами, для функции с тремя параметрами нужно проверить 27 условий.

И да, автотесты(если вы подразумеваете все же функциональные тесты, а не модульные) покрывают функционал, а не код.

Оптимизация: Если параметр enum тогда нужно проверять каждое его значение, а если типа long то достаточно перебрать [min, random(avg), max] так как маловероятно что функция завалится на каком то min <= x != random(avg) <= max — иначе это будет какой то хардкод внутри функции для этого параметра, а хардкорные параметры лучше хранить в enum.

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

min <= x != random(avg) <= max
Верно (точнее — это минимальный набор). + неверный тип данных. Отсюда и min 27 вариантов для 3х параметров.

Мы покрываем тестами по основным тесткейсам, но все равно бывают неучтенные мелочи. И уж точно я не готов утверждать, что мы ВСЕ проверили. Опыт фейсбука/гугла с их практиками оплаты за баги — подтверждает мои слова.

А что мешает теперь покрывать мелочи?

1. Оптимизация по времени — нет смысла реализовывать кейсы для редких ситуаций (например — у кого то имя из 256 символов).

2. Банальная невозможность проверить всего (а что будет, если я начну регистрироваться в Лондоне, а закончу в Киеве?).

Нет, вы правда думаете, что возможно проверить все-все? :)

Вы упираетесь в метод полного перебора всех состояний и их комбинаций что практически невозможно за конечное время, то есть вы хотите решить проблему не аналитически, а итерационным путем.
Я же не преследую цель перепроверить всевозможные комбинации, а больше доверять что если функция работает для N, то она будет работать и для N+1 и это не нужно проверять в Runtime, а будет достаточно убедится в этом через CodeReview.

Я же не преследую цель перепроверить всевозможные комбинации, а больше доверять что если функция работает для N, то она будет работать и для N+1 и это не нужно проверять в Runtime, а будет достаточно убедится в этом через CodeReview.
qaненужны?

Ок, реализуете «тестирование через codeReview» — обязательно напишите об этом.

Полностью отказаться от QA не думаю что реально (кто то должен хотябы поверхностно пройтись по билду перед релизом) но значительно сократить количество QA также хороший результат ;-) А какие то мелкие недочеты зарепортят уже реальные пользователи.

кто то должен хотябы поверхностно пройтись по билду перед релизом
Расскажите, что толку от поверхностного прохода? Если есть мажорные баги (звездец, регистрация отвалилась!) — значит есть и дофига более мелких, которые вы пропустили.

Если после «поверхностного» прохода — багов нет — это ещё ничо не значит :)

Это в случае когда будет все покрыто тестами и они будут успешно пройдены после билда (ситуация с отвалившейся регистрацией будет не возможна после автотестов) только тогда будет достаточно поверхностного тестирования перед релизом.
P.S. Тестирование армией QA тоже ничего не гарантирует, так почему вы боитесь автоматического тестирования? Если что и будет пропущено то зарепортят реальные пользователи и этот кейс добавится потом в автотест.

Это в случае когда будет все покрыто тестами и они будут успешно пройдены после билда (ситуация с отвалившейся регистрацией будет не возможна после автотестов) только тогда будет достаточно поверхностного тестирования перед релизом.
Ещё раз, какие цели преследует «поверхностное» тестирование?
P.S. Тестирование армией QA тоже ничего не гарантирует, так почему вы боитесь автоматического тестирования?
Внимательно читайте мои комментарии, иначе наша переписка теряет смысл. У нас нет мануальщиков — только автотесты. Да, это упрощает жизнь и значительно ускоряет тестирование. Но это не дает 100% гарантий. Как и ничто не даст вам такую гарантию.

Для того чтобы крепче спалось после релиза ;-) Полностью доверится автоматике не позволяет психология человека. (зачем нужны пилоты в самолете когда автопилот вполне может и сам справится)
Конечно не даст 100% потому что есть кучи конфигураций окружений операционных систем, но это не значит что мы не можем стремится к 100% сами или с помощью репортов от пользователей.

Для того чтобы крепче спалось после релиза
Значит вы не верите в свою идею. :) Ничо, внедрите автотесты, если все сделаете правильно — начнете доверять

Идея здесь ни причем это просто формальность (традиция) бегло пролистать релиз перед публикацией. ;-)

Отличная традиция для СЕО (без иронии), но паршиво, если команда делает что либо, исключительно традиции ради.

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

Мануальщики проверяют сценарии и делают скриншоты чекпоинтов.
Тогда я крайне не советую доверять и этому.

P.S. А вообще наш разговор скатился в унылое гавно. Так вы скоро будете отстаивать иконки на системнике, дескать с ними лучше работает.

А где здесь вопрос доверия? Здесь просто отчет о проделанной работе, если этот кейс завалится на проде тогда уже будет разбор полетов и это гарантирует то что не будет тупой отмазки мануальщика: я тестил (по скринам будет видно каким образом тестил) все работало, а теперь оно почему то не работает не только на проде но и на бете ;-)

хех, поиск виноватого, вместо гарантии качества? И что делаете с провинившимся тестером?

P.S. Вы не поверите, но «сделал кейс + скриншот» — это как раз то, что великолепно делают автотесты. лучше мануальщиков, чесно-чесно.

А что здесь такого? Если мануальщик реально ничего не сделал, а сказал что протестил и все ОК то что ему теперь орден доблести выдавать?
Распознавать корректность полученного результата на скриншотах в общем случае под разными визуальными темами и разрешениями экранов та еще задачка.

Так что с мануальщиком делаете? *колись сволочь, куда трупы спрятал!*

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

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

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

А за счет чего он должен быть более мотивирован? $400 очень мотивирует ;-)
А трамваи внутри компании должны ездить, не как нибудь, а по определенным требованиям (читай рельсам). Так вот процесс разработки это и есть эти самые рельсы.

Да ладно, вам. Мне было офигенно интересно работать с оптимизацией highload. Когда ты реально видишь результаты своей работы на графике нагрузки на сервера. Простым прогером, кстати.

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

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

Но бывает что вступаешь в компанию, а потом выясняется что лучше бы ты в говно вступил.

Ну и нафига терпеть? Серьезно, вы ни работодателю много пользы не принесёте, ни себе

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

Одна ейчарша утверждает не совсем это, а то, что 4-5 мес. в совершенно разных отраслях на протяжении нескольких лет — это звоночек. Более того, Вы всегда можете не указывать то место работы, где поработали месяц-два или, если оно такое одно в Вашем резюме, Вас и так поймут :-)

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

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

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

Кажется, мы о разных вещах. Выше, когда я приводила этот пример, речь шла не о подработке,а о полноценных нескольких годах после института (скажем, четыре года таких метаний). Шансы есть у всех :-)

Выражайтесь яснее, у нас мышление прямолинейное, можем и не понять.

Я выше об этом прямо писала, но, боюсь, что в таком кол-ве комментов Вы могли просто не заметить :-)

Спроси об этом водителей трамваев, какой интерес ездить 20 раз по кольцу изо дня в день годами ;-)

Я забыл написать про свободу выбора? Ан нет, написал.
И да, судя по кол-ву статей «Хочу быть QA, кто возьмет» рано или поздно появится подобная статья от водителя трамвая.

Человек конечно. Так что и у него есть выбор :)

Самим то не смешно? С каких это пор выбор гарантирует результат? ;-)

Должно быть зажрались.

Чувак, почему б тебе не освоить программирование?
Сейчас народ ломится в тестировщики потому что:
1) Низкий порог вхождения
2) Платят с нуля больше,чем инженеру на заводе.

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

Одной темы
«Начинающий Java программист в Киеве — не могу найти первую работу :( » недостаточно?
Пусть уже в тестирование пробивается, тем более, на собеседования активно приглашают.

Начинающий Java программист в Киеве — не могу найти первую работу :( " недостаточно?
Не достаточно. Большинство народа Java — джуниоров берут.

Я когда такие топики вижу, сразу вспоминаю «робити я не вмію, а красти я боюся, поїду я на Київ в міліцію наймуся». Тока в ментовку срочную службу надо оттрубить вроде бы, а в тестировщики и этого не надо.

Лот № 1. Trainee, Junir QA Engineer. Стартовая цена: Три сотни Американских рублей.

Стартовая цена:
Нет, это аукцион на повышение.

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

Не забудьте опубликовать вакансию на ДОУ, возможно будете удивлены,
например эта вакансия
jobs.dou.ua/...vacancies/8098
получила 59 откликов.
эта — www.peeep.us/3400ca7b — 94 отклика.
эта — www.peeep.us/83830c6b — 79 откликов.

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

В августе доля откликов «с текстом» увеличилась в несколько раз:
public.tableausoftware.com/...isplay_count=no

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

Зачем кому-то писать? На открытую вакансию, в среднем, у нас приходит до 100 резюме. Всегда есть из кого выбрать. К тому же всегда приятнее работать с «проактивными» людьми, они точно знают чего хотят.

Если на открытую вакансию, в среднем, у нас приходит до 100 резюме, то да.

На открытую вакансию, в среднем, у нас приходит до 100 резюме.
ого! ажиотаж таки спадает?

Не знаю, видимо срабатывают рыночные механизмы, много в отрасль людей идёт в возрасте 25+, много бывших админов переучиваются в программистов, студенты стараются пораньше начать работать, лидеры штампуют на курсах кучу народа. Но в принципе, ажиотажа я последние полгода не наблюдаю.
Исключения составляют люди с очень высокими скилами, но их нужно 1-2 на очень крупный проект, но такое положение вещей, мне кажется, в любой отрасли.
Но я думаю тут лучше мнение профессионального рекрутера. Я то со своей колокольни это вижу. Возможно дела обстоят совсем наоборот.

зарплаты пора снижать потихоньку ?

кандидаты не удосуживаются даже ссылку на резюме дать

и это на фоне развернувшейся junior-истерии... дааааа....

видел пожелания по з/п от 200 у.е.

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

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

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

Вам нада трохи попрацювати текстом
www.linkedin.com/...tab_profile_pic
(і над баченням, так як текст це лише його відображення)

I finished courses
Звучить якось не кошерно...
Initial level of mobile platforms Android and IOS
початковий рівень в чому? використанні? програмуванні?
Basic knowledge of SQL, C#, Java, HTML, CSS
Тоже звучить не того... Ви або можете, або ні...
Understanding of OOP principles
Це все що ви можете сказати після 5 років в National Technical University — «Kharkov Polytechnic Institute»? Так школяр може казати про себе. З ж*пи іскри мають сипатись з OOP...
Limited experience, I can compensate for hard work.
А це що таке? По-перше граматично не правильно. По-друге виникає питання, що буде, коли ви наберетесь досвіду — will not work hard?

Дякую за яскраву критику мого резюме. Якби ви уважно читали, то могли помiтити що я навчався не 5 рокiв а 3,(2005-2008). Отже кiлькiсть iскор з ж*пи значно менша)))) Але буду пахать у три змiни.))

Вибачаюсь забув додати — заочно.

Basic knowledge of smth — приобретается за 1-3 недели знакомства. Бывают, конечно, и случаи посложнее.

Или раньше, я свою сестру-экономиста за пару часов научил на SQL делать CRUD (select, join, update, delete, create, drop), это считается на базовом уровне?

Да как же тебя возьмут, товарищ, если ты себе цену не указал!

Текст не мой, но в жизни правда все так и есть(:

почему вы не можете найти хорошую работу
2k.livejournal.com/654334.html

Особенно люблю вот этот пункт:

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

работа хочет, чтобы вы с ней по любви.
за это она даст вам денег и соцпакет.
Как можно любить работу в украинском оутсорсинге: ковыряние второстепенных задач за четверть зарплаты нормального специалиста, скажем в США?
Без обид, но мне кажется в оутсорсинг ходят исключительно за деньгами, что впрочем не исключает стремления делать работу хорошо.

Поддерживаю. В США я могу поехать по H1b с з.п. в лучшем случае 70 тысяч долларов. Работать там придётся скорее всего овертайм, потому как не для того работодатель чурок с Украины вывозит, чтоб они ему за гигиену трудовой деятельности боролись. Друзей, родственников, знакомых у меня в США нету. Привычные мне развлечения стоят в среднем дороже.
Только как это отменяет факт отсутствия душевного трепета перед заурядной работой(правда, хорошо по украинским меркам оплачиваемой?) просто делаешь её за деньги — всё.

Спасибо за ссылку, она прекрасна.

Точно и красочно, как автор выразился «по делу, без х*йни»
Дарья, спасибо, внес в избранное.

Резюме хотел сделать типа баг репорта или тест кейса(IDEA, Summury, Discription. etc,.), что бы выделится немного. Но вижу это многим не понравилось. Резюме вроде в открытом доступе. Исправлю скину новую ссылку. Тем кому надоела заезженая тема — можете не отвечать) Остальным Спасибо за критику, вижу с чем еще нужно работать)

Так и не смог ознакомиться с твоими скилами по средствам планшета

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

.Все делаю — на работу не берут!(Харьков)
А искать на ДОУ подобные темы пробовали?
В голове есть мозг.
Это прямо звучит как серьезный аргумент!
Следую многим совет.
Точно есть мозг?

ЗЫ:
Не берут? — ничего страшного, — идите кассиром! Там берут всех кто закончил «курсы» (читай — школу) и умеет рассылать 80 резюме за 1.5 месяца.

ЗЫЫ:
Извините за сарказм, но уже начинает подташнивать от таких тем как ваша... без шуток.

А) Резюме странное, пока особо комментировать нечего.
Рекомендуется переписать, по шаблону:
— контактная информация
— Objective
— Skills
— Expirience (за неимением такого, пет проджекты)
— Education

Всё!

Б) 10 приглашений на собеседование это показатель, и очень приличный, 10 отказов после собеседования, показатель еще более... гм, показательный.
Любой ценой вытянуть «чистосердечное» из собеседовавших, всё равно туда пока не берут.
Делаемые самостоятельно выводы о причинах явно не те, которые нужны для прекращения провалов.

В) Без передышки качать англицкий, может быть провалы на тесте «вживую» касательно знания языка.
Initial basic — масло масляное.
Luck of bad habits — удачлив в плохих привычках? Даже если бы было «lack of bad habits» — звучало как сожаление, что оных нет.
I can compensate for hard work — кто на ком стоял?
Actively studied English language , QA, Java — даже если проигнорировать русизм, неужели всё, уже означенное изучено и можно ставить жирную точку? Тем более, не совсем ясно, как можно «изучить» Quality Assurance.

Не берут...
Объясняю:
LinkedIn:www.linkedin.com/...tab_profile_pic
Могли бы и публичную ссылку оставить, а не скопировать адресную строку браузера
Резюме:docs.google.com/...dit?usp=sharing
__Idea__: Getting a job Junior QA Engineer, with the opportunity of
professional and career growth.
Зачем писать свои «идеи» в резюме (это к вопросу про уровень ангельского)
Testing methodologies: TDD, Agile.
Рылли?
А теперь добавим сюда переизбыток джунов КуА, и очень сильно удивимся что пригласили аж на 10+ собеседований.
Поскольку я вас не знаю (и даже не видел ни разу), то не могу сказать почему не берут __именно__ вас.
Для самоанализа попробуйте ответить на вопрос: Чем я лучше студня из профильного ВУЗа?
Попробуйте проанализировать каждое неудачное собеседование (что могло бы вам не понравится будь вы «с другой стороны»)
Ну и рынок сейчас такой, что продолжайте спамить, куда-то да возьмут ... наверно. :)

спс за советы. из каждого собеседования извлекаю опыт: что нужно говорить, что не стоит, как вести себя и т.д. Поражает одно отосла резюме, прислали тестовое задание, сделал отправил, ответ: вакансия закрыта — ок, через 2 недели вакансия вновь открыта- звоню, вспомнили меня пригласили, после 10 мин разговора с HR сказали Спасибо и все, даже без собеседования с Тех лидом и другим специалистом. После такого просто опускаются руки.((

Резюме:docs.google.com/...dit?usp=sharing
имхо: странный формат резюме в виде простыни текста, странно ужатая до пугающего вида фотка, после «Testing methodologies: TDD, Agile.» то, что идет дальше, воспринимается как копипаст оглавления какой-то книги. так что советовал бы допилить до более стандартного вида.

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

Какие-то ошибки конечно допускал, где-то путал определения, ну такое считаю стажеру можно простиь..

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

А зачем тестеру знать что такое test driven development?

Зачем вообще тестировщику что-либо знать? (а «тестер», к слову, знать ничего не может в принципе, — ибо это прибор!) — они же не нужны как и менеджеры!

Зачем вообще тестировщику что-либо знать?
они же не нужны как и менеджеры!
Ну есть еще организации из прошлого века которые не осознали этого.
а «тестер», к слову, знать ничего не может в принципе, — ибо это прибор!)
деливери юнит менеджер тоже непойми что: www.indeed.com/...nit Manager"&l= но это же тебя не смущает?

Ок, а с чего ты взяла что он не загуглил?

Ну вот некто майкрософт тоже это относит к методологиям тестирования: msdn.microsoft.com/...y/ff649520.aspx
Ну и меня интересут еще такой вопрос: и у тебя и у Оксаны Чуйко в профайлах куча страшных слов, вы претендуете на абсолютное их понимание?
Мораль сего отступа такова: очень легко предираться сидя в норке, выложи свое резюме, код и т.д., я с удовольствием обосру посмотрю.

То есть, в МС джуниор мануальщики пишут юнит тесты?
Какая разница, твой наезд ведь не в этом был а в том что он назвал тдд методологией тестирования? С чего ты взяла что ТДД это только юнит тесты? Силениум УИ тесты полностью исключаются?
Ruby от Rails отличаем так точно.
У тебя там только РоР написан?
А кто придирается? Чувак спросил, что не так с резюме — ему ответили.
Это не ответили, ответили это например если бы ты написала: «ТДД не принято называть методологией тестирования а принято ...», а то что ты сделала с посыланием в гугл это понты на ровном месте, из которых было совершенно непонятно что именно ты имела в виду.

И веди себя так и впредь, мир станет лучше.

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

А насчет ссылки — походу таки ТС увидел заголовок и спарсил то что было ниже. Отсюда и TDD в методологиях, и Agile.

Ты б ещё реализацию синглтона кинул :)

Нее, хош выпендриться — ссылку на пет проджект в гитхабе.

P.S. не знаешь к чему придраться? Всегда есть фигурные скобки и пробелы vs табы!

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

90% американцев не знают ответа на этот вопрос — ты с рекламы чтоли берёшь лозунги?

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

Проект — это показатель твоего кода, задачка — показатель вы#бона.

Ну вот гугл, фб, мс, эпл почему то практикует такие задачи на интервью, наверное они чего то не знают?

Ты путаешь задачи на кодирование алгоритмов с головоломками. Вторые забанили, первые вполне продолжают спрашивать, вот пример месячной давности: www.glassdoor.com/...-RVW2897431.htm там же найдешь еще тыщу таких же.
Ок, в отличие от тебя я не стесняюсь писать код, т.к. это шлифует мои скилы прохождения интервью с умными и не очень интервьюерами. Слушаю твои задачи, что тебе написать (за разумное время конечно), мои специализации — джава backend, алгоритмы, informational retrieval, machine learning, nosql много данных и т.д.

Тебе код только для интервью нужен?

Понимаешь в чем дело — то как ты напишешь код на 10-20 строк не отражает твою «хорошесть» как программиста. Даже если это будет идеальный код.

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

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

P.S. Кстати, сейчас думаю о решение указанной тобой задачи в общем виде. Т.е. у тебя есть ведра литражем a и b (взаимопростые) и надо набрать ровно X литров. Это забавнее, чем сделать библиотеку вариантов, но не уверен о размере кода на выходе и времени на решение (так что скорее всего и сам доведу решение только до алгоритма на бумаге)

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

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

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

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

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

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

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

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

Работал в отделе «оптимизации» — фиксили и разгоняли код за остальными. Очень прикольный опыт, но и там была рутина.

Ну это же наверное не совсем — держать правильного человека на алгоритмы.

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

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

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

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

А вообще, для обсуждения ключевых алгоритмов мы «лидским» составом у доски собирались — это совсем плохо, да? :)

Плохой алгоритм и плохой код — разные вещи.
Плохой алгоритм порождает плохой код.
Плохой код должен отлавливаться на ревью. ИМХО, конечно.
Да, это требует больше усилий, легче отфутболить человека на собеседовании чем держать специальных алгоритмистов вдохновляющих на код ревью.
А вообще, для обсуждения ключевых алгоритмов мы «лидским» составом у доски собирались — это совсем плохо, да? :)
Зависит от алгоритмов, я от тебя конкретики еще не слышал.
Плохой алгоритм порождает плохой код.
С чего вдруг? Уж не путаешь ли ты дизайн(архитектуру) приложения и алгоритм?
Зависит от алгоритмов, я от тебя конкретики еще не слышал.
Любой ключевой алгоритм. Из реальных примеров — построение сортировочных меню «на лету»
С чего вдруг? Уж не путаешь ли ты дизайн(архитектуру) приложения и алгоритм?
Нет не путаю, гавнокод может быть не только в структуре классов но и в их наполнении, зачастую второй вариант преобладает.
Любой ключевой алгоритм. Из реальных примеров — построение сортировочных меню «на лету»
И что нарешали?
Нет не путаю, гавнокод может быть не только в структуре классов но и в их наполнении, зачастую второй вариант преобладает.
Ну вот от алгоритмов гавнокод не зависит. Можно и самый дурной алгоритм воплотить в виде простых понятных методов. Которые потом можно будет легко переписать.

А можно и хороший алгоритм гавнокодом написать.

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

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

Конечно. Поэтому — просто попробуй.

Попробовать что? Писать кривые алгоритмы и разбивать их на мелкие методы? Как нибудь обойдусь. Простой пример: dou.ua/...ic/7210/#354529 , там тебе маленькие методы, и т.д., но бренчей логики тупо в 5 раз больше чем нужно и поддерживать такое особенно если такого кода пару десятков мегабайт врагу не позавидуешь.

Я эрланг в первый раз вижу (а посему он для меня вырвиглазен). Кроме вложенного case проблем в оформлении особо не вижу. Хотя вывод и логика в одном листинге — напрягает.

Давай с-подобный пример, потрындим.

Если понимаешь метод в течении 5 секунд (а это, на мой взгляд, основная задача декомпозиции кода), то пофиг какой там алгоритм — поддержка будет простой. Ну и перепилить будет не сложно.

run() - слишком «сложный». И комментарий сбивает с толку :). И ещё пара придирок по мелочам

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

Или у тебя возникли бы проблемы с поиском бага?

А какой именно баг ты там нашел?

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

Или этот код тяжело рефакторить? Профилировать? Покрыть тестами? Моками?

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

Правильно. Но стоит переработать метод run() и назвать его по человечески — и все будет ок

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

function checkMailForRegistration(mailString) {

return checkUserName(mailString) &&
checkAt(mailString) &&
checkDomain(mailString);
}

попахивает гавнокодом, однако вполне понятно и поддерживаемо.

Но стоит переработать метод run() и назвать его по человечески — и все будет ок
Весь остальной гавнокод магически исчезнет?
Кстати, ты ведь понимаешь, что редко когда тебе нужно досконально понять как некий модуль работает. Обычно достаточно поверхностного понимания.
Когда система большая и живет лет 5-10 уже, то что бы ее расширять нужно постоянно читать и править чужой код, и просто написаный код делает эту задачу намного проще.
и просто написаный код делает эту задачу намного проще.
И я о том же. Просто написанный код — важнее чем хитрый алгоритм.

Если метод run переработать, переназвать (и удалить ненужный комментарий) — то код станет простым. И да, если для того, чтоб понять код метода, нужно залазить внутрь каждого вызываемого метода — то у нас уже большие проблемы.

И я о том же. Просто написанный код — важнее чем хитрый алгоритм.
Чел не осилил именно найти простой алгоритм, я бы этот код написал в одном методe в 5-10 строчках, код был бы чище и читабельнее.

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

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

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

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

как то так — pastebin.com/TYV8UhnH (алгоритм намерянно не менял, только косметика)

Фу, алгоритм конечно то ещё гуано.

Ну если ты считаешь этот код кишащий багами простым, то Ок.

Баги — ловятся тестировщиками и тестами. Если пытаться словить все ошибки на ревью — потратишь дофига времени.

Но код, имхо — да, довольно простой.

100% полагаться на тестировщиков и тесты тот еще лол.

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

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

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

возникает только вопрос времени поиска нужного спеца и стоимости онного.

В большинстве случаев приходится заниматься рутиной. Т.е. в большинстве случаев ты — overqualified.

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

Ок, ты хочешь сказать что весь день выдумываешь алгоритмы?

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

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

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

да, забыл уточнить — я имел ввиду реально интересные алгоритмы, а не рутинные.
НУ это сильно зависит от уровня хотелок, я например сейчас работаю над search engine у которого компрессированная база — 60ТБ, но наверное каким то перцам из гугла может показаться это скучным.
У меня? Выяснение/согласование требований, приоритизация фич, встречи и переговоры.
На вкус и цвет, для меня это рутина т которой я всячески стремлюсь убежать спрятавшись за bugtrackers, имейл переписками и design docs.
НУ это сильно зависит от уровня хотелок, я например сейчас работаю над search engine у которого компрессированная база — 60ТБ, но наверное каким то перцам из гугла может показаться это скучным.
Тогда — нема вопросов, у меня тоже мечты в таком покопаться, если дорастем.
Если ты самый дурной алгоритм уберёшь в маленькие методы с адекватными именованиями — то код будет отлично поддерживаться.
лол просто лол.
А вы уверены что сможете разбить «дурной алгоритм» в «меленькие методы с понятными именами»? :)

Не буду утверждать наперёд, но не вижу примера, доказывающего обратное

Не буду утверждать наперёд, но не вижу примера, доказывающего обратное
Ну это хороший знак для ТСа. Если человек с вашим опытом — СТО, то ему так же все двери открыты. :)

Богдан, жду примера от человека «с вашим опытом». Чтонибудь кроме как кидаться какашками — умеете?

Ну вот некто майкрософт тоже это относит к методологиям тестирования: msdn.microsoft.com/...y/ff649520.aspx
Лол. Сударь вот от вас я такого не ожидал. Где там (в статье) написанно что МС относит ТДД к методологиям тестирования? (Статья, кстати, аутдейтед)
А для человека, который не особо в теме, статья с таким __заголовком__ — это аргумент. Тоньше надо быть, сударь.

Прямым текстом не написано, но смысл именно таков, статья рассматривает методологии тестирования и в частности ТДД, написано в objectives.

Прямым текстом не написано, но смысл именно таков, статья рассматривает методологии тестирования и в частности ТДД
Я прочитал совсем другое :)

Не, Богдан прав — там рассматриваются методологии тестирования в разрезе методологий разработки.

Там написано что TDD это некоторая практика в рамках extreme programming , т.е. TDD это методология тестирования в составе extreme programming.

т.е. TDD это методология тестирования в составе extreme programming.
не, это уже ты сам добавил.

TDD рассмотрен, потому что он «переварачивает традиционный процесс разработки».

Мы можем выделить «методологию написания тестов при применении TDD», но не правильно называть TDD методологией тестирования.

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

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

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

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

Ок: отвечает ли TDD на вопрос «как тестировать» — хотя бы отчасти — да (пропускаем интеграционные тесты итп). То есть методологию тестирования оно в себя включает и описывает. Хотя в контексте скила для QA: TDD выглядит... странно. Ну то есть можно представить себе картинку: сидит QA клепает мелкий автоматический тест кейс, рядом сидит девелопер — быстренько его реализует. Такое себе «попарное тестопрограммирование». Выглядит не очень реально. Другой вариант: речь идет о том что товарищ просто раньше занимался разработкой и как разработчик знаком с TDD.

Это уже третий вопрос, хотя я уже писал что селениум УИ тесты вполне могут делаться QA и применятся в TDD.

в ATDD, и только как часть внешнего цикла.

А почему именно селениум для ТДД не годится как часть «внутреннего цикла»?

внутренний цикл — белый ящик, а селениум — для тестирования системы енд-ту-енд (т.е черный ящик). Тесты на селениуме не будут «драйвить» девелопмент. В них не будет никаких «запахов» плохого дизайна. Они не будут поддерживать дизайн когда.

селениум — просто инструмент. Теоритически в TDD для UI юзать можно

есть различия между TDD и test first

«Левый человек пишет» — вот что несоответствует идеологии TDD

А почему КУА — левый человек?

Левый = не-тот-кто-будет-писать-код

А разве ТДД говорит что тесты должен писать именно тот который будет логику имплементировать? Я в живую не сталкивался, но вроде например в МС СДЕТ пишут тесты, а потом СДЕ их имплементируют, разве такой подход противоречит ТДД?

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

Итого, приходит продукт, говорит — «пацаны, надо перепилить сортировку, пусть сортирует по имени, а не по дате». Что ты делаешь? Зовешь QA и обьясняешь как перепилить тесты и идешь пить чай? (По ТДД мы начинаем кодить, только если есть «красный» тест).

Т.е. в твоем подходе три минуса:
1) временной лаг
2) в одну проблему вьезжать 2м спецам
3) Нарушение автономности (QA создает ветку, пушит туда новый тест и идет искать разраба для фикса)

Ну в МС вроде всех разбивают на групки: 2 СДЕТ, 2 дева, 1 програм менеджер, т.е. как бы все уже в курсе всего, вьезжать в проблему не нужно.

Это test first, а не tdd. Тут тесты имеют очень мало влияния на дизайн

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

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

Сложный тест может показывать нарушение SRP. И.т.д

Это вырожденный пример, в мире dependency injection такого не бывает.

DI этому никак не мешает. Например A инжектится в B, а B спрашивает у A С и вызывает один из методов С. А тесты позволяют четко увидеть такие нарушения.

Ну и собственно тесты (TDD) и толкают к использованию DI, вместо прямого инстанцирования или использования локатара

а B спрашивает у A С
Так это уже не DI со всеми вытекающими

Почему не DI? зависимость внедрена C->A->B. Возвращение С описано в интерфейсе A. Все по правилам. Только дизайн плохой

Не по правилам, C должен инициализироваться DI фреймворком а не через factory method у А

А это и не фактори метод. C заинжекшен фреймворком в А и А его вернул при вызове метода

Но это на самом деле частный случай. Общий — тест становится сложным/нечитабильным — значит с дизайном что-то не так.

А это и не фактори метод.
То что ты его называешь по другому сути не меняет.
C заинжекшен фреймворком в А и А его вернул при вызове метода
Ну вот это и есть кривость, если C уже в DI контексте что тебе мешает его инжектить прямо в B?
То что ты его называешь по другому сути не меняет.
ну он ничего не создает.
Ну вот это и есть кривость, если C уже в DI контексте что тебе мешает его инжектить прямо в B?
В том то и дело, что DI никак не влияет на то, как используется заинжекшеный объект. Так что с точки зрения DI все ок.
И, возможно, инъекция С не самый лучший выбор. Возможно лучше изменить A. C A,B,C все выглядит очевидно. В реальности явная зависимость B от С может быть еще хуже и надо пересматривать все взаимодействие объектов.
И тут в игру вступает TDD, который подсказывает как сделать лучше.

Я вот написал кучу кода с использованием DI фреймворков, и везде как то все очевидно.

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

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

Заменим B на комнату, А на дверную ручку, С на дверь. Цель — потянуть ручку, чтобы открыть дверь. Ты считаешь очевидным добавление зависимости комнаты от дверной ручки. А мне тесты подскажут лучшее решение — добавить метод открыть к двери.

А кто в твоем примере инициирует открытие? Комната? Не совсем ясна сигнатура классов и кто кого вызывает.

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

В контексте DI здесь возможно два подхода:
1. Комната ничего не знает о ручке и общается только с дверью и тогда у тебя в тесте мок не возвращает мок
2. В комату инжектится ручка

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

Я имел в виду все инжектить в контекст, а в сам класс инжектить то что нужно. Т.е. нужна ручка — инжектим, не нужна не инжектим, разница в одной строчке кода и никаких моков возвращающих моки, и сложных обьектов возвращаемых методами.

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

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

Ну так в изначальном варианте есть нарушение закона Деметры, о чем мне скажут тесты (мок, возвращающий мок) и я уйду от него. Попробую внедрить ручку, получу тест вида
Ручка = создать мок ручки с ожиданиями вызовов
Комната = new Комната(Ручка)
....
Попробую прочитать тест и сразу пойму неправильность действий, поменяю интерфейс двери и перепишу тест, сделав его читабельным, основной код менее связным и с более естественными зависимостями.

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

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

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

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

А я где то писал что ДИ мешает ТДД или наоборот?

А я где-то писал что не использую di? Это ты так решил. Ну Ок. А я решил, что ты не знаешь, что такое тдд.

А я где-то писал что не использую di?
Да, ты привел наглядные примеру с АБЦ , ручками и дверями где ты описал что ты не инжектишь обьект и поэтому ТДД позволяет тебе писать «качественный и гибкий код».
Ну Ок. А я решил, что ты не знаешь, что такое тдд.
Наздоровье, это ты слабо представляешь что такое ТДД, доволен?

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

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

Я это и не буду пытаться предвидеть. У меня просто будет меньше зависимостей либо они будут более органично вписываться в модель. Соответственно меньше вероятность устаревания итд

Сам подумай — «комната зависит от ручки» даже звучит плохо. А тесты покажут это

Я это и не буду пытаться предвидеть. У меня просто будет меньше зависимостей либо они будут более органично вписываться в модель. Соответственно меньше вероятность устаревания итд
У тебя зависимостей будет столько же, т.к. у тебя еще есть зависимость у двери на ручку в отличие от моего варианта.
Сам подумай — «комната зависит от ручки» даже звучит плохо.
Для меня «комната открывает дверь ручкой» звучит еще хуже, но мы же говорим о абстракциях?

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

В конце у меня не будет зависимости от ручки, тесты приведут к изменению интерфейса двери
Не будет зависимости когда, через год или в момент 0? Зависимости откуда, из двери или из комнаты?
Ну в абстракции должна быть логика. Т.е. Комната зависящяя от двери все же лучше, чем от ручки.
Ну вот «комната открывающая двери» менее совместима с логикой чем «комната имеющая зависимость на ручку». Абстракцию ты херовую придумал с самого начала.
Не будет зависимости когда, через год или в момент 0?
по окончании текущих действий над тестами/кодом. Очевидно из комнаты.

«комната имеющая зависимость от ручки» хуже «комната имеющая зависимость от двери»

по окончании текущих действий над тестами/кодом. Очевидно из комнаты.
«комната имеющая зависимость от ручки» хуже «комната имеющая зависимость от двери»
Та нет, не очевидно, это абстракции в вакууме и ими можно крутить как хочешь подгоняя хуже/лучше под желанный ответ. Я например могу сказать что человек в комнате который хочет из нее выйти воздействует на ручку а не на дверь, и ему удобно иметь зависимость на ручку а не на дверь, и в этом сценарии будет в 100500 раз больше логики чем в твоем где комната открывает дверь.

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

И из-за неправильно привязки к ручке, получаешь проблему в будущем.

в моем примере комната принимает команду проветриться, и открывает для этого дверь:) реальный автор в такой модели не так важен. Можешь считать его роботом, который часть комнаты и открывает дверь, если тебе так проще.
И из-за неправильно привязки к ручке, получаешь проблему в будущем.
Ок, ты заменил моего человека на своего робота. Как именно твой робот способен открыть дверь не зная о ручке? С ноги?

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

используя интерфейс двери «открыть»:) детали уже будут скрыты. Может и с ноги, может и ручкой, может ментальным сигналом.
А почему этот интерфейс встроен именно в дверь? Почему нету абстрактного «opener» который имеет конретную реализацию в DI контексте которая может быть и роботом вышибающим с ноги, и автоматической дверью, и заменятся одной строчкой в DI фреймворке? Зачем комнате вообще знать о каком то роботе?

комната и не знает. Робот только для тебя, чтобы не смущала комната, открывающая дверь, как пример. Но если бы актор имел значение в моделе, то да, был бы какой-то опенер.

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

нет конечно. Это аналогично матрешке — естественнее связь между матрешками соседних размеров, чем через 1.

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

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

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

Например, при вышибании двери дверь все еще нужна, а ручка уже нет:)
А при автоматически открываемой двери уже не факт.

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

BTW эклипс разве не моветон сейчас в джава разработке?

но и эванса, фаулера, мартина и других.
Эти люди где то советуют использовать DI только в частных случаях?
выпилить легко. пока код не засорен ненужными зависимостями и вообще не сгнил:)
Ну так я ж говорю, одна из задач DI облегчить разгребание таких зависимостей.
BTW эклипс разве не моветон сейчас в джава разработке?
У айдиа вырвиглазные шрифты на линуксе который я использую, поэтому она отправилась в пешее эротическое, с другой стороны эклипс меня всем устраивает.
Эти люди где то советуют использовать DI только в частных случаях?
то что я писал это не использование DI в частных случаях, это ограничение внедрения ненужных зависимостей в конкретный объект.
Ты же не агитируешь за иньъекцию всех возможных сервисов во все объекты, в которые возможно?

Это ты уже додумал о каких-то «народных» способах и приписал это мне.

я юзаю айдею в линукс (правда кде) вроде все ок со шрифтами. Может привык

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

в коде просто не должно быть никогда
тут дело не только в дисциплине написания кода.

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

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

Дублирования в коде тоже не должно быть никогда. Но вся индустрия борется с этим и не очень-то успешно (если даже взять довольно качественный open-source код)

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

Агрегат — объект состоящий из других объектов и контролирующий изменения своих внутренностей.

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

Мокать нужно не те объекты, которые трудно создать, а те с которыми нужно протестировать взаимодействие (с очевидным исключением в вид value-objects и структур данных)

Domain объекты это не только объекты-структуры или value-объекты, это могут быть объекты с достаточно сложными методами, которые нужно тестировать самостоятельно, и соответственно мокать в других тестах (чтобы не допустить хрупкости тестов).
Т.е. если следовать стратегии разделять все классы на легковесные value обьекты и классы сервисы (к чему стремятся всякие фанаты REST и функциональщики) все проблемы исчезают?

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

легковесные value обьекты и классы сервисы
Это на самом деле тема другого холивара

Ок, а что мешает агрегаты инжектить?

Тут вопрос в другом — инжектить ли внутреннюю часть агрегата.
Если да — агрегат перестает контролировать часть.
Поэтому правильный путь — менять интерфейс агрегата.

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

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

выпилите дверь- избавит от зависимостей

Хм, исторический момент! ПХП-шник рассказывает джависту (хацкер, тыж джавист?) о прелестях ТДД! Только на ДОУ! ШОК, Скриншоты!

в мире dependency injection такого не бывает.
просто оставлю здесь, что бывает в мире dependency injection:)
github.com/...rTransport.java

Во первых это ведь value objects у тебя к ним претензий не было?
Во вторых это как раз частичный подход dependency injection, правильно обьявлять поле:

@Inject @HttpPort private int httpPort;
и ДИ фреймворк сам засунет туда значение.

в этом классе целый букет проблем:) во-первых он не value object.
Есть возврат заинжекшеной переменной
public Settings settings() { return this.settings; }
есть создание сервиса внутри класса, есть нарушение закона Деметры. Не особо разбирался, что он делает, но уверен что есть нарушение SRP.

Теперь представь как будет выглядеть тест этого класса.
И мог ли подобный класс возникнуть в ходе TDD?

вы точно пхп-девелопер? по-моему вы нас обманываете

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

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

во-первых он не value object.
Он не value object, но возвращает value objects.
Есть возврат заинжекшеной переменной
Ну так это ж твой подход, получать сложные обьекты через методы а не DI context, у меня бы ничего такого не возвращалось, а он бы получался исключительно из DI context.
возвращает value objects.
который тем не менее находится в контексте DI.
Ну так это ж твой подход
в моем подходе (tdd) такой класс в принципе не может возникнуть

Я тебе показал как может быть в DI мире — DI сам по себе ничего не гарантирует.

А теперь вопрос: ты все еще считаешь что тесты не влияют на дизайн при тдд?

который тем не менее находится в контексте DI.
С чего ты взял?
в моем подходе (tdd) такой класс в принципе не может возникнуть
Я тебе показал как может быть в DI мире — DI сам по себе ничего не гарантирует.
Если кодер не изпользует DI то да, DI ничего не гарантирует.
А теперь вопрос: ты все еще считаешь что тесты не влияют на дизайн при тдд?
Если использовать ДИ то нет, потому что дизайн и так хорошо тестируемый. Если следовать твоим рецептам то да, возникают грабли при написании тестов и они героически фиксятся
С чего ты взял?
@Inject public NettyHttpServerTransport(Settings settings, NetworkService networkService) {
Откуда берется settings?
дизайн и так хорошо тестируемый
Так надо просто тебе начать писать безошибочный код и никакие тесты не нужны
Откуда берется settings?
Сеттингс да инжектится, values в нем нет, а возвращаются как значения из геттеров, что вроде как не противоречит твоим принципам дизайна.
Так надо просто тебе начать писать безошибочный код и никакие тесты не нужны
Это очень простой принцип, как не использовать goto например, откуда ошибки?
Это очень простой принцип, как не использовать goto например
зачем-то же использовали? при живом-то di
откуда ошибки?
я же и говорю — просто пиши без ошибок
зачем-то же использовали? при живом-то di
Наверное люди исповедуют сходные твоим принципы дизайна, другого рационального обьяснения пока что не видно.
я же и говорю — просто пиши без ошибок
Типа как вставлять гото в лунатических припадках?

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

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

Ну это же твоя логика (простое правило -> отсутствие проблем)

>>инжектить все что инжектится и можно чувствовать себя сухо и комфортно.
Это конечно мои слова

Будет ли схема «пачка тестов -> пачка кода» TDD в чистом виде — философский вопрос :) Хотя, если допустить что товарищ так умеет — он очень скромничает в резюме.

Потому что цель TDD не тестирование, а разработка. Поэтому это методология(практика) разработки.

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

Потому что цель TDD не тестирование, а разработка.
Если цель не тестирование то зачем в ней тесты нужны?

1 .Для минимизации кода. (делаем только то, что делает тест зелёненьким)
2. Для уверенности «неповрежденности» кода.
3. Вроде как ведёт к простому дизайну коду.

вы претендуете на абсолютное их понимание
Это означает, что есть определенный опыт с этой кучей страшных слов. Что как минимум я в курсе что это за технология и при необходимости могу решить задачу с ее применением без посторонней помощи. А где указано какой % технологии надо изучить\иметь опыт прежде, чем писать ее в резюме? Была бы очень благодарна за разъяснение, а то вдруг я совершенно неоправданно указала список навыков.

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

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

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

кто сказал — год опыта?

у него в резюме это написано

Когда работодатель принимает решение брать человека или нет, то вы не поверите, но зачастую 200, 300 или даже (о Боже!) 400 баксов роли не играют.

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

Только вот почему то так все время получается что за время потраченного старшего спеца + ЗП джуна = не хватает чтобы нанять не джуна ;-)

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

Подписаться на комментарии