Интервью: Интересные вопросы

[valchkou]

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

Я догадываюсь откуда ноги растут, как правило на позиции куёв, и не важно ручных или ножных, есть требование bachelor in CS or similar.
В наши дни подразумевается что с этим дегри кандидат умеет хоть что то решать с литкода.

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

[nyekimov]

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

Я догадываюсь откуда ноги растут, как правило на позиции куёв, и не важно ручных или ножных, есть требование bachelor in CS or similar.
В наши дни подразумевается что с этим дегри кандидат умеет хоть что то решать с литкода.

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

Если такое надо, то наверное да. У тебя ж фирма реально продвинутая. Но если вернуться к твоему изначальному комменту, то что мешает человеку с cs degree идти дальше в разработчики или админ бд или ещё чего. Нормальный qa как по мне должен тестировать фронт и находить баги вперед пользователя. И не обязательно забивать голову тех деталями, хотя конечно не помешает. Все остальное, это уже хотелки частного места. Хотят скинуть с разработчика рутинные обязанности, экономят на sre.
Ну и в вакансиях как правило зоопарк - нужно уметь все, а человек придёт, 2/3 там и не нужно.

[valchkou]

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

Я догадываюсь откуда ноги растут, как правило на позиции куёв, и не важно ручных или ножных, есть требование bachelor in CS or similar.
В наши дни подразумевается что с этим дегри кандидат умеет хоть что то решать с литкода.

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

Если такое надо, то наверное да. У тебя ж фирма реально продвинутая. Но если вернуться к твоему изначальному комменту, то что мешает человеку с cs degree идти дальше в разработчики или админ бд или ещё чего. Нормальный qa как по мне должен тестировать фронт и находить баги вперед пользователя. И не обязательно забивать голову тех деталями, хотя конечно не помешает. Все остальное, это уже хотелки частного места. Хотят скинуть с разработчика рутинные обязанности, экономят на sre.

возможно издержки платформы. У нас просто тестеры отделены и как бы сами по себе и сами отвечают за свои энвайронменты

[Сабина]

Это не про архитектуру процессора но и не про замер времени выполнения fork-a

По тому как описано, это именно замер скорости fork'а. Есть низкоуровневые способы, но вряд ли они имелись в виду постановщиками задачи.

Вот в авторском варианте

"Write a C program which measures the the speed of a context switch on a Linux system."


Во время fork-a конечно происходит context switch, но тут мне кажется другое

https://stackoverflow.com/questions/236 ... n-linux-os ?

[kostik78]

Это не про архитектуру процессора но и не про замер времени выполнения fork-a

По тому как описано, это именно замер скорости fork'а. Есть низкоуровневые способы, но вряд ли они имелись в виду постановщиками задачи.

Вот в авторском варианте

"Write a C program which measures the the speed of a context switch on a Linux system."


Во время fork-a конечно происходит context switch, но тут мне кажется другое

https://stackoverflow.com/questions/236 ... n-linux-os ?

Ответ там не верный. И даже не вчитываясь что человек написан, достаточно увидеть С++ с шаблонами из std. Это как бы об многом говорит

[alex_127]

https://stackoverflow.com/questions/236 ... n-linux-os ?

Ответ там не верный. И даже не вчитываясь что человек написан, достаточно увидеть С++ с шаблонами из std. Это как бы об многом говорит

там вариация длины квантума+много другого а не собственно свитч. но он и писал что измерял "интерактивность" - как скоро он сможет получить квантум при нагрузке

[idle0]

Это не про архитектуру процессора но и не про замер времени выполнения fork-a

По тому как описано, это именно замер скорости fork'а. Есть низкоуровневые способы, но вряд ли они имелись в виду постановщиками задачи.

Вот в авторском варианте

"Write a C program which measures the the speed of a context switch on a Linux system."


Во время fork-a конечно происходит context switch, но тут мне кажется другое

https://stackoverflow.com/questions/236 ... n-linux-os ?

Вот отсюда выкопался правильный ответ! Спасибо Сабина!!!

https://pages.cs.wisc.edu/~remzi/OSTEP/ ... anisms.pdf

Measuring the cost of a context switch is a little trickier. The lmbench benchmark does so by running two processes on a single CPU, and set- ting up two UNIX pipes between them; a pipe is just one of many ways processes in a UNIX system can communicate with one another. The first process then issues a write to the first pipe, and waits for a read on the second; upon seeing the first process waiting for something to read from the second pipe, the OS puts the first process in the blocked state, and switches to the other process, which reads from the first pipe and then writes to the second. When the second process tries to read from the first pipe again, it blocks, and thus the back-and-forth cycle of communication continues. By measuring the cost of communicating like this repeatedly, lmbench can make a good estimate of the cost of a context switch. You can try to re-create something similar here, using pipes, or perhaps some other communication mechanism such as UNIX sockets.

Это можно даже на Питоне сделать

[idle0]

Это не про архитектуру процессора но и не про замер времени выполнения fork-a

По тому как описано, это именно замер скорости fork'а. Есть низкоуровневые способы, но вряд ли они имелись в виду постановщиками задачи.

Вот в авторском варианте

"Write a C program which measures the the speed of a context switch on a Linux system."


Во время fork-a конечно происходит context switch, но тут мне кажется другое

https://stackoverflow.com/questions/236 ... n-linux-os ?

Ответ там не верный. И даже не вчитываясь что человек написан, достаточно увидеть С++ с шаблонами из std. Это как бы об многом говорит

Ответ неверный, но есть ниже ссылка на правильный ответ. См. мой пост выше

[Komissar]

https://stackoverflow.com/questions/236 ... n-linux-os ?


Вот отсюда выкопался правильный ответ! Спасибо Сабина!!!

Сабина - молоток! На 3х форумах раздел "Работа" на себе тянет

[Мальчик-Одуванчик]

Ответ неверный, но есть ниже ссылка на правильный ответ. См. мой пост выше

Осталось только уточнить что измеряем: переключение контекста процесса или потока.
Если потока - то уточняем какого.

[idle0]

Ответ неверный, но есть ниже ссылка на правильный ответ. См. мой пост выше

Осталось только уточнить что измеряем: переключение контекста процесса или потока.
Если потока - то уточняем какого.

Это trick question.

[kostik78]

По тому как описано, это именно замер скорости fork'а. Есть низкоуровневые способы, но вряд ли они имелись в виду постановщиками задачи.

Вот в авторском варианте

"Write a C program which measures the the speed of a context switch on a Linux system."


Во время fork-a конечно происходит context switch, но тут мне кажется другое

https://stackoverflow.com/questions/236 ... n-linux-os ?

Ответ там не верный. И даже не вчитываясь что человек написан, достаточно увидеть С++ с шаблонами из std. Это как бы об многом говорит

Ответ неверный, но есть ниже ссылка на правильный ответ. См. мой пост выше

В статье что я Вам послал описан этот способ с pipes а также указано почему он не полный как и впрочем второй способ.

[idle0]

Вот в авторском варианте

"Write a C program which measures the the speed of a context switch on a Linux system."


Во время fork-a конечно происходит context switch, но тут мне кажется другое

https://stackoverflow.com/questions/236 ... n-linux-os ?

Ответ там не верный. И даже не вчитываясь что человек написан, достаточно увидеть С++ с шаблонами из std. Это как бы об многом говорит

Ответ неверный, но есть ниже ссылка на правильный ответ. См. мой пост выше

В статье что я Вам послал описан этот способ с pipes а также указано почему он не полный как и впрочем второй способ.

Есть более оптимальный вариант чем с pipes?

[Boriskin]

Нормальный qa как по мне должен тестировать фронт и находить баги вперед пользователя. И не обязательно забивать голову тех деталями, хотя конечно не помешает. Все остальное, это уже хотелки частного места. Хотят скинуть с разработчика рутинные обязанности, экономят на sre.

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

[kostik78]

https://stackoverflow.com/questions/236 ... n-linux-os ?

Ответ там не верный. И даже не вчитываясь что человек написан, достаточно увидеть С++ с шаблонами из std. Это как бы об многом говорит

Ответ неверный, но есть ниже ссылка на правильный ответ. См. мой пост выше

В статье что я Вам послал описан этот способ с pipes а также указано почему он не полный как и впрочем второй способ.

Есть более оптимальный вариант чем с pipes?

Оптимального нет ибо он не возможен в user space по этому и я сказал что context switching можно только примерно высчитать если знать исходные данные процессора и тип scheduler. Все остальные методы включая pipes имеют большие погрешности ибо не учитывается много факторов.