У нас с девом ушло дня 3 с учетом синхронизации результатов. Это много или мало? А сколько вы потратите времени на написание и саппорт таких кейсов в случае изменения:
локейшенов;
алгоритма поиска / сортировки;
CV пользователя;
наложенных фильтров?
В случае с автоматизацией - минимум, и только в случае изменения алгоритма. В случае с ручным тестированием - каждое изменение повлечет за собой дополнительный перерасчет. Плюс ко всему, если вдруг сломается алгоритм, вы можете и не узнать этого наверняка, если результаты будут на поверхности одинаковые, но стоит вам изменить критерий поиска (добавить фильтр, изменить одну точку и т.п.), - все сломается. Т.е. проводя регрессию, вы каждый раз будете надеяться на то, что ваши старые расчеты при строго определенных обстоятельствах, дают правильный результат. А ведь на более низком уровне вы бы сразу смогли выявить проблему.
В общем, вопрос достаточно тонкий. И далеко не всегда оно того стоит. Я лишь привел пример, когда это действительно окупилось в плане временных затрат. Но это совсем не значит, что ваш подход - не применим. Во многих ситуациях он будет даже более действенным. Но вы ведь сами попросили привести пример.
ну, вроде тестирование должно это учитывать, не? то есть, для такого сложной фильтрации явно надо будет набор тестов, по которым можно определить, какая часть сломалась, в случае чего?
Пример действительно очень интересный
И сколько времени в итоге уйдет на анализ / создание / саппорт такого сьюта? Да и где гарантии, что этого набора будет достаточно? Разница в том, что в случае с описанным подходом каждый новый тест не потребует никаких доп. вычислений, т.к. алгоритмы уже реализованы. А так все придется считать ручками, еще и периодически освежать наши тесты.
Понятно, что людей из других городов тяжело собеседовать, но если людей всегда не хватает, то приходиться искать и по телефону в том числе.
Девы и к ним тоже должны относиться, как разработчикам, тогда и код будет соответствующий. Вот я как бы автоматизатор, но пишу библиотеки на python сейчас и к ним пишу юнит тесты. Вроде бы юнит тесты и не нужны, но для того, чтобы библиотеки не ломались по каждому чиху, надо правильно программировать.
Написать декоратор, который перед вызовом декорируемой функции выведет строку.
Декорировать любую функцию с любыми параметрами.
На листочке.
2. JavaScript
Дано
function Music(url) {
this.url = url
}
Music.prototype.play = function() {
//...
}
var music = [new Music("111"), new Music("222"), new Music("333")]
написать последовательный проигрышь (вызов play), с интервалом 10 секунд.
Код пишется онлайн, соответственно должен быть рабочим.
3. “Люди в комнате - остаться должен только один”
Реализовать задачку
Дано n людей в комнате. Есть судья (арбитр).
Судья начиная с первого человека чередует “остаешься” и “иди вон”.
Пройдя круг повторяет с оставшимися в том же порядке, до тех пор пока в комнате не останется один человек.
Каким по порядку был этот человек при первом цикле?
На примере объясняется так:
n = 4
+ + + + (сначала все)
+ x + x (арбитр 2му и 4му сказал идти вон)
+ x x x
=> остался 1й
n = 3
+ + +
+ x + (только 2й ушел, 3му остаться)
x x + (т.к. перед этим 3й остался, то сейчас 1му "вон")
=> остался 3й
Код пишется онлайн, соответственно должен быть рабочим.
Насчет фибоначи на javascript-e, как было сказано выше. Обычная реализация рекурсией покажет что у вас есть знания что такое рекурсия, это да, но она очень неоптимальная, если знать как и что работает в жс-е. Основные возможности ускорения расчетов с примерами можно посмотреть вот тут http://jsperf.com/fibonacci-y-combinator/5 . Там все понятно и просто, но если есть жедание, могу расписать каждый пример отдельно, почему он выполняется быстрее и тд и тп.
Дело не в последующей пригодности на проекте, а в том, что на мат. задачках легко проверить понимание основ языка и умение выбрать правильный подход в реализации. К примеру, даже дав вам определение чисел Фибоначи, можно оценить вашу способность придумать алгоритм решения. А потом еще попросить объяснить, что валидней использовать: циклы или рекурсию, к примеру. Как все это дело может отразиться на времени выполнения и т.п. Т.е. задача не в том, чтобы проверить знание каких-то формул, а в том, чтобы оценить ваше мышление.
Python:
Using API documentation below verify that all endpoints (methods) on server**
work as expected (accessible and return correct response codes for all cases).
Output should be:
Code that verifies that data is added to server.
Code that verifies correctness of returned response codes.
Small tips.
● POST request accepts name and position in body;
● Body is expected to be in JSON format;
● All requests with body should contain correct “Content-Type” header;
● Not all methods might work as expected;
● In this section you do not need to parse response, only to verify that
“some” data was uploaded to server.
**Please note that your are not the only person using this server, thus you might notice that
there will be some data which you did not create, as well as your data might be occasionally
deleted by other users.
Datamining:
Use existing access log (any language) to receive next information:
Count # of successful requests per hour.
Results should be stored in file.
Small tips:
● Log contains data only for 1 day;
● Successful request should have response code 200;
● Easiest way to achieve that - *unix command line.
OUT OF THE BOX:
Python & Redis:
For “OUT OF THE BOX” level make several enhancements to Python tasks from
the “OK LEVEL” and “NICE TO HAVE”. Create a DB using Redis in which candidate
names and positions will be stored. In order to accomplish this task:
Redis should be installed on local machine.
All requests to server that require passing names and positions within your
test should take that data from Redis.
All comparisons that touch verification of the names and positions you have
in test should be done using data from Redis.
Datamining:
Use existing access log (any language) to receive next information:
Count % of successful requests per hour.
Results should be stored in file.
Small tips:
● Log contains data only per 1 day;
● Successful request should have response code 200;
● Easiest way to achieve that - *unix command line.
хотелось бы выслушать мнение экспертов проходил вот собеседование на selenium и дали вот такую задачку позиция junior qa
Необходимо описать задачу с применением принципов ООП.
Условие тестовой задачи:
Дано объекты-фигуры следующих видов: квадрат, треугольник, круг, трапеция. Каждую фигуру можно нарисовать, получить ее площадь и цвет. Также фигуры имеют уникальные методы, например: вернуть радиус, длину гипотенузы, длину стороны и т. д.
Нам необходимо сгенерировать случайный набор фигур, количество объектов в наборе также заранее неизвестно.
После генерации массива нужно вывести весь список объектов, которые у нас имеются, например:
Фигура: квадрат, площадь: 25 кв. ед., цвет: синий
Фигура: треугольник, площадь: 12,5 кв.ед., цвет: желтый
////////////////////////////////////
вот решение там джарник и код хотелось бы услышать ваше мнение, так как вродебы работает прога может код конечно не мега но все же и позиция такаяже https://drive.google.com/folderview?id=0B1cu5dnmSDIgfmlVWWpxX0IzQnpLSHJ1b1R3Q2FKeE5qYkI1SkQ3dFFEQUFkTjJhRFVqamM&usp=sharing
“с применением принципов ООП” - это не то, что написано у Вас.
Должны быть: фигура (базовый абстрактный класс/интерфейс, в котором реализуются необходимые методы), квадрат, треугольник, круг, трапеция (классы наследованные от базового). Соответственно необходимо переопределение метода toString (если мои познания Джавы верны)
Почему-то мне кажется, что от вас требовалось не полное решение, а лишь создание прототипа. А вы восприняли все буквально и начали создавать визуальные компоненты, методы отрисовки и т.п. Зачем?!
Все, что от вас нужно - это понимание основ ООП. Причем, задачка с геометрическими фигурами во многих источниках приводится в качестве примера полиморфизма.
Решение (как намекнули выше): 1 интерфейс с 3 методами: draw, getArea, getColor. 4 класса, имлементирующих этот интерфейс. В каждом из классов будут свои доп. методы, на которые я бы вообще не стал обращать внимания, исходя из условия - просто создайте заглушки. Ну и дефолтные конструкторы с какими-нибудь рэндом значениями. Далее можно написать параметризованный enum, возвращающий наши фигуры. Помимо этого, сюда же можно вшить геттер, получающий на вход длину массива, и возвращающий random List<InterfaceType>. Хотя, тут можно сильно и не заморачиваться. Вариантов решения с рандомизацией - масса. Про toString() тоже уже сказали. Впрочем и все. Вызываем 1 метод с произвольным параметром длины, и в цикле проходимся по результирующему массиву, печатая результат.
Если честно, я бы даже не стал обращать внимания на формулы в решении (устроили бы и заглушки), т.к. цель тут - проверка знаний ООП, а не школьной математики.
Во спасибо вам огромное, хоть указали на ошибку сидел бы так и не понимал что к чему, а так даже посмеялся да так даже лучше через интерфейс, не надо заморачиваться … спасибо
Почитал и апнул тему своим мнением.
Какие-то длинные вам задачи дают. Больше одной строчки. Я что не получаю, выглядит всё проще, в одну строчку:
Написать сканнер wifi сетей и их параметров на питоне используя DBus. Результаты хранить в sqlite
Написать стиллер картинок с веб сайтов с проверками на возможные атаки DoS.
testomat.io управление авто тестами
да так даже лучше через интерфейс, не надо заморачиваться … спасибо