Наверно это моя проблема, но когда через месяц открываешь старый код, постоянно хочется что-то улучшить, сделать лучше, применить другой подход или оптимизировать.
Очень много постов на тему собеседований, поиска работы, зарплат и людей.
Сам хожу на собеседония и сам провожу технические собеседования, потому выделил для себя 2 основных правила собеседования человека:
1. Человек не должен быть **даком
2. Человек должен любить программирование
<habracut />
Не выполняется первое правило — вся комманда может начать работать плохо, так как человек новый человек может нарушить сложившиеся в команде связи, начнет отнимать время других участников команды.
Со вторым пунктом — несколько сложнее, в нем заключены следующие утверждения:
— желание идти вперед, учиться, развиваться в профессиональном плане.
— ощущение себя творцом, человек любит то что он делает.
— желание сделать лучше.
Если человек подходит по этим двум пунктам, то можно брать на испытательный срок, который и покажет насколько человек подходит команде и команда человеку. Это тоже важно, поскольку грамотный и толковый человек при работе в команде, которая ему не подходит, будет постоянно пребывать в дискомфорте. Неизвестно, что получится в итоге: человек тихонько найдет другую работу; попытаться переделать под себя других людей(как правило неудачно). Испытательный срок хорош тем, что можно так же посмтотреть на уровень развития спопбности Думай Головой. Эта способность нужна не только в сфере IT, но и в любой другой. Понятно, что если человек пишет код быстрее чем думает, то такой человек может не подойти команде(а может и подойти, если надо именно писать код быстро). И последнее(по порядку, но не по важности) на что я обращаю внимание — оценки, которые делает человек. Будь-то время прихода на работу, срок выполнения задачи или новый смартфон от company_name, аргуметированность суждений для меня очень важна.
Что де касается самих собеседований, каждый их нас может задать такой вопрос на собеседовании, на который сходу не ответит даже профессионал, как пример:
— Как заменить все названия TestSuite в отчетах JUnit на русские названия, которые берутся из собственной аннотаций к классу? Версия Junit 4.10.
(Вопрос для программистов Java)
Сидим думаем. Без поиска по гуглу. Есть только тест, аннотация и IDE.
Не смогли придумать? Вы нам не подходите… Очень жаль..
Это НЕ подход, но он очень часто встречается на собеседованиях. Получается что-то типа такого: «Мы нашли нестандартной решение для нашей нестандартной задачи, после чего решили, что все должны об этом знать и спрашиваем об этом у каждого собеседуемого человека.»
— Напишите код программы, которая… на этом листочке
Очень, здорово, а компьютера у вас нет? А можно своим ноутбуком воспользоваться? А у вас все программисты на листочках пишут?
Тоже, по моему мнению, не подход.
Собеседование — процесс на котором можно задать самые разные вопросы, но почему-то мы забываем об этом.
Вопрос типа: «Каким кодом вы гордитесь?», не слышу уже давно.
(Для меня лично правильный ответ — никаким, код старше месяца хочется переписать).
«Придумайте алгоритм для ....что-то интересное», так же давно не задают.
«Вот вам задачка на логику, порассуждайте над ее решением вслух» — единицы, а ведь этот вопрос реально покажет вам то как человек думает. Даже если задача решена неправильно, человека можно оценить по его рассуждениям.
И напоследок — очень важное для меня замечание — поддерживайте связь с человеком! Позвоните ему после собеседования, особенно если он не прошел его, объясните почему, ведь возможно, что через полгода-год, к вам придет тот же человек, но теперь он подойдет вам!
Может я и извращенец, но я начал использовать YouTrack на рабочем ноутбуке, для задач по собственным проектам, этакий Evernote с дэдлайнами и привычным планированием. Поэтому прошу статью об API YouTrack. Потому что сам не очень хорошо разобрался.
И вот еще вопрос:, планируется ли интеграция YouTrack c Eclipse?
Товарищи, а подскажите компактный способ записи. А то столкнулся внезапно. Можно услышать мнение людей которые более сведующие в данном вопросе. Граф надо хранить в реляционной БД.
Что-то странное, похоже что памяти не хватало оперативной, у нас stage сервер постоянно посылается, что-то около 500 запросов в секунду и нормально работает час или больше. Второй вариант, что-то не так с тестами.
Мне кажется что тестировщику нужно знание sql. По нескольким причинам, которые были указаны и не были:
— Написание автоматических тестов(а уж если тетсировщик занимается еще и интеграционными тестами, тогда сам бог велел).
— Понимание как это работает и от чего ломается. Выше указан пример с поиском — тестировщик должен не только найти, но и грамотно описать поведение определить условия возникновения ошибки, а для этого ему скорее всего необходимо знание механизмов работы.
— Наполнение тестовой БД — спорный вопрос, кто и как должен это делать. Но вот шаг тестирования когда в БД хранятся какие-либо недопустимые данные игнорировать не стоит и тестировщику нужно добавлять эти данные самому.
— Есть приложения большая часть логики которых строится в бд(например на хранимых процедурах) и тут без знание SQL — никуда.
Это моё мнение относительно «среднестатистического» тестировщика. Конечно тому кто тестирует игры, приложения для мобильных или какиое-то специализированное ПО знание sql-может вообще в жизни никогда не пригодиться. Но в целом, я считаю, знать sql очень полезно. В каком объеме — каждый решает для себя сам.
У меня тоже вопрос появился. Во время тестов вы используете реальную СУБД или что-то, которое крутиться, так скажем, in-memory?
Мы просто используем следующую методику на девелоперской машине используем легкую реализацию в памяти(например hsqldb), которая быстро поднимается в памяти, таким образом время на интеграционный тест уменьшается, так как создается один instance на каждую TestSuite.
На тестовом сервер при прогонке тестов уже соединяемся с базой подобной по настройкам с продакшеном, для того чтобы посмотреть на наличие ошибок в боевых условиях(бывали случаи что код работает прекрасно на in-memory и валятся на тестовом).
Сейчас меня закидают помидорами наверное, но оно пожирает ресурсов больше чем флеш.
Для сравнения:
сайт трона — 50% времени процессора, на браузерах Chrome, FF 4, Opera. IE 8
любая флеш игра на armorgames — не более 20%
Оборудование — Core i3, видео Radeon 5470 HD, win7(x64).
Сам хожу на собеседония и сам провожу технические собеседования, потому выделил для себя 2 основных правила собеседования человека:
1. Человек не должен быть **даком
2. Человек должен любить программирование
<habracut />
Не выполняется первое правило — вся комманда может начать работать плохо, так как человек новый человек может нарушить сложившиеся в команде связи, начнет отнимать время других участников команды.
Со вторым пунктом — несколько сложнее, в нем заключены следующие утверждения:
— желание идти вперед, учиться, развиваться в профессиональном плане.
— ощущение себя творцом, человек любит то что он делает.
— желание сделать лучше.
Если человек подходит по этим двум пунктам, то можно брать на испытательный срок, который и покажет насколько человек подходит команде и команда человеку. Это тоже важно, поскольку грамотный и толковый человек при работе в команде, которая ему не подходит, будет постоянно пребывать в дискомфорте. Неизвестно, что получится в итоге: человек тихонько найдет другую работу; попытаться переделать под себя других людей(как правило неудачно). Испытательный срок хорош тем, что можно так же посмтотреть на уровень развития спопбности Думай Головой. Эта способность нужна не только в сфере IT, но и в любой другой. Понятно, что если человек пишет код быстрее чем думает, то такой человек может не подойти команде(а может и подойти, если надо именно писать код быстро). И последнее(по порядку, но не по важности) на что я обращаю внимание — оценки, которые делает человек. Будь-то время прихода на работу, срок выполнения задачи или новый смартфон от company_name, аргуметированность суждений для меня очень важна.
Что де касается самих собеседований, каждый их нас может задать такой вопрос на собеседовании, на который сходу не ответит даже профессионал, как пример:
— Как заменить все названия TestSuite в отчетах JUnit на русские названия, которые берутся из собственной аннотаций к классу? Версия Junit 4.10.
(Вопрос для программистов Java)
Сидим думаем. Без поиска по гуглу. Есть только тест, аннотация и IDE.
Не смогли придумать? Вы нам не подходите… Очень жаль..
Это НЕ подход, но он очень часто встречается на собеседованиях. Получается что-то типа такого: «Мы нашли нестандартной решение для нашей нестандартной задачи, после чего решили, что все должны об этом знать и спрашиваем об этом у каждого собеседуемого человека.»
— Напишите код программы, которая… на этом листочке
Очень, здорово, а компьютера у вас нет? А можно своим ноутбуком воспользоваться? А у вас все программисты на листочках пишут?
Тоже, по моему мнению, не подход.
Собеседование — процесс на котором можно задать самые разные вопросы, но почему-то мы забываем об этом.
Вопрос типа: «Каким кодом вы гордитесь?», не слышу уже давно.
(Для меня лично правильный ответ — никаким, код старше месяца хочется переписать).
«Придумайте алгоритм для ....что-то интересное», так же давно не задают.
«Вот вам задачка на логику, порассуждайте над ее решением вслух» — единицы, а ведь этот вопрос реально покажет вам то как человек думает. Даже если задача решена неправильно, человека можно оценить по его рассуждениям.
И напоследок — очень важное для меня замечание — поддерживайте связь с человеком! Позвоните ему после собеседования, особенно если он не прошел его, объясните почему, ведь возможно, что через полгода-год, к вам придет тот же человек, но теперь он подойдет вам!
Всем удачного дня!
И вот еще вопрос:, планируется ли интеграция YouTrack c Eclipse?
— Написание автоматических тестов(а уж если тетсировщик занимается еще и интеграционными тестами, тогда сам бог велел).
— Понимание как это работает и от чего ломается. Выше указан пример с поиском — тестировщик должен не только найти, но и грамотно описать поведение определить условия возникновения ошибки, а для этого ему скорее всего необходимо знание механизмов работы.
— Наполнение тестовой БД — спорный вопрос, кто и как должен это делать. Но вот шаг тестирования когда в БД хранятся какие-либо недопустимые данные игнорировать не стоит и тестировщику нужно добавлять эти данные самому.
— Есть приложения большая часть логики которых строится в бд(например на хранимых процедурах) и тут без знание SQL — никуда.
Это моё мнение относительно «среднестатистического» тестировщика. Конечно тому кто тестирует игры, приложения для мобильных или какиое-то специализированное ПО знание sql-может вообще в жизни никогда не пригодиться. Но в целом, я считаю, знать sql очень полезно. В каком объеме — каждый решает для себя сам.
Мы просто используем следующую методику на девелоперской машине используем легкую реализацию в памяти(например hsqldb), которая быстро поднимается в памяти, таким образом время на интеграционный тест уменьшается, так как создается один instance на каждую TestSuite.
На тестовом сервер при прогонке тестов уже соединяемся с базой подобной по настройкам с продакшеном, для того чтобы посмотреть на наличие ошибок в боевых условиях(бывали случаи что код работает прекрасно на in-memory и валятся на тестовом).
Для сравнения:
сайт трона — 50% времени процессора, на браузерах Chrome, FF 4, Opera. IE 8
любая флеш игра на armorgames — не более 20%
Оборудование — Core i3, видео Radeon 5470 HD, win7(x64).