×

Співбесіда з DevOps. 300+ запитань для Junior, Middle, Senior

Можна сперечатися про популярність DevOps, а можна просто готуватися до співбесіди та отримати омріяні 9K :) Щоб допомогти вам зорієнтуватись у питаннях, які ставлять на інтерв’ю, ми поспілкувались з тими, хто їх проводить, і склали список можливих запитань.

Якщо ви не DevOps, то перегляньте інші добірки питань.

Junior

Загальні

1.Що таке DevOps?
2.Ви набираєте google.com у браузері. Розкажіть якомога детальніше, що відбувається в цей час?
3.Як працює HTTPS?
4.Поясніть концепцію Infrastructure as Code, для чого це потрібно і які проблеми вирішує?

Linux

5.Опишіть загальну архітектуру операційної системи.
6.Опишіть основне призначення операційної системи.
7.Навіщо потрібні файлові системи? Які існують?
8.У чому різниця між віртуалізацією і контейнеризацією?
9.У чому переваги контейнерів?
10.Яка файлова структура у Linux (UNIX) систем, що розташовані в / etc, / dev, / proc, / sys, / lib, / var (кілька директорій на вибір)?
11.Що таке Load Average?
12.У чому різниця між soft та hard symlink?
13.Як працюють file permissions, навіщо директорії права виконання (+x)?
14.Що таке zombie process?
15.За допомогою чого можна зібрати інформацію про поточний стан процесора, пам’яті, диска, мережі?
16.Що таке swappiness?
17.Як подивитися вільне місце на диску?
18.Що таке inode?
19.Розкажіть поетапно процес завантаження Linux від моменту ввімкнення живлення комп’ютера.
20.Що станеться під час виконання команд:

1. cat file1 > file2
2. cat file1 >> file2

21.У чому різниця між Ctrl+C та Ctrl+Z?
22.Як перенаправити одночасно stderr та stdin?
23.Як вбити процес? Які є типи сигналів?
24.Що робить команда grep?
25.Що таке скрипт bash?
26.Які типи змінних використовують у bash?
27.Що виведуть команди:

1. echo ${hostname}; 
2. echo $(hostname);

Networks

28.Що таке модель OSI, TCP/IP?
29.Для чого потрібні network masks?
30.Структура IP-пакета. З чого складається? Що таке фрагментація та чому вона відбувається?
31.Що таке колізія? Чому виникає?
32.Що таке проксі?
33.Що таке firewalls і навіщо вони потрібні?
34.Що таке NAT і навіщо він потрібен?
35.Які типи IP-адрес ви знаєте?
36.За яким портом і протоколом працюють Ping і Traceroute?

Clouds

37.У чому різниця між IaaS, PaaS та SaaS?
38.Що таке VPC і з яких компонентів має складатись?
39.Що таке cloud-init? init/systemd/upstart configs?

Automation

40.Що таке IaaC і навіщо він потрібний?
41.Що таке Terraform?
42.Які інструменти автоматизації ви знаєте?

Information Security

43.У чому різниця між аутентифікацією та авторизацією?
44.Сертифікати. Як працює HTTPS? Що таке certificate ciphers?
45.Як безпечно передати дані своєму колезі?
46.Що таке MFA, TOTP?

Віртуалізація

47.У чому різниця між віртуалізацією та контейнеризацією? У чому плюси та мінуси?
48.Як для при запуску Docker-контейнера «повісити» його з 80-го порту в контейнері на 8081 на хост?
49.Як передати у віртуальну машину USB device?
50.Docker-контейнер споживає багато SWAP. Що робити?

CI/CD

51.Що таке Continuous Integration та Continuous Deployment? У чому різниця між Continuous Deployment і Continuous Delivery?
52.Опишіть основні етапи CI/CD.
53.Опишіть приклад процесу CI (та/або CD), який починається з моменту, коли розробник запушив зміни/PR до Git?
54.Розкажіть про різновиди тестів, які ми можемо використовувати в CI пайплайні.
55.Які інструменти CI ви використовували? Чи є досвід роботи з Jenkinsfile?
56.Які види тестів ви знаєте і навіщо вони потрібні?

Development

57.Git. Як вирішити merge conflict? Що таке rebase, cherry-pick?
58.У чому різниця між git merge та git rebase?
59.Які UI використовували?
60.Яка різниця між GitLab/GitHub/Bitbucket?
61.Яка різниця між Git pull/Git fetch?
62.Що таке Git-flow?
63.Версіонування. Яка різниця між SemVer та CalVer?
64.Тестування. Які існують види? Як писати тести, TDD?
65.У чому різниця між компільованими та інтерпретаційними мовами програмування?

Monitoring/Logging

66.Які метрики треба збирати? Різниця між infrastructure та application monitoring.
67.Яка різниця між pull та push model у системах моніторингу?
68.Яка різниця між Black box та White box monitoring?
69.Розкажіть про підходи до збору application логів.

Практичні завдання

71.Напишіть просту програму мовою на ваш вибір. Програма має отримувати повідомлення з сервісу черг і друкувати його в stdout. Сервіс черг — на ваш розсуд.
72.Розберіть структуру сервісу (на прикладі Docker-compose).
73.Практична сесія роботи з Git (Git command line: fetch, push, pull, rebase, checkout, submodules).

Middle

Linux

1.Опишіть архітектуру ядра Linux.
2.Що таке ядро ​​і яке його призначення?
3.Опишіть загальні частини файлової системи Unix/Linux, архітектуру файлової системи.
4.У чому різниця між RedHat і Debian?
5.У чому різниця між /proc and /sys?
6.Ситуація: показує, що на диску зайнято 50% місця, а створити файл навіть під root користувачем не можемо. У чому проблема?
7.Ми видалили файл, який відкрив застосунок. Як нам його відновити?
8.Як знайти PID процесу, його стартові параметри?
9.Як перевірити, чи відкритий порт на віддаленому хості, локальному хості?
10.Як шукати файл за його вмістом?
11.Що таке SSH, як організувати доступ на сервер без пароля або з певних хостів? Як обмежити доступні для виконання команди?
12.Як перевірити спожиті ресурси під час сеансу SSH?
13.Що означає дозвіл на файл 755?
14.Що таке SELinux і навіщо він потрібен?
15.Як визначити PCI-пристрій у системі, наприклад RAID controller?
16.Як перейменувати пристрій, наприклад мережеву карту чи диск?
17.Що таке LVM? Які знаєте приклади використання?
18.Що таке root reserved space?
19.Що таке exit code та як його дізнатися?
20.Чому вивід df -h показує, що на диску зайнято мало місця, але система не дає записати файл із повідомленням no space left on device?
21.У чому різниця між command1 & command2 та command1 && command2, а також command1 && command2 || command3?
22.З мережі різко зріс вихідний трафік на 25-й порт. Як, маючи доступ на гейтвей, виявити шкідника з внутрішньої мережі?
23.Як затюнити параметри Linux Kernel?
24.Що таке ulimits?
25.У чому різниця між символічними та hard links?
26.Що таке фрагментація ext3 and ext4?
27.Навіщо файлові системи ext* резервують 5% місця?
28.Як збільшити розмір файлової системи?
29.Чи можемо ми зменшити розмір файлової системи?
30.Що таке chroot і навіщо він потрібний?
31.У нас є Linux box з 2 Гб оперативної пам’яті та Java-застосунок, який намагається виділити 4 Гб під час запуску. Чи вдасться це?
32.Є програма, яка читає файл, який користувач намагається видалити. Що трапиться? Чи можна видалити цей файл? Чи можна відновити цей файл?
33.Які механізми створення процесів у Linux ви знаєте?
34.Порівняйте systemd та init system.
35.У вас є папка з великою кількістю файлів, і ви хочете видалити всі файли з іменами, що починаються на A (велика літера). Але команда rm -f A* видає Argument list too long. Як можна видалити ці файли?
36.Ви починаєте видаляти файли першим методом з попереднього питання, але кожен rm запитує підтвердження. Це дуже довго. Як можна прискорити цю операцію?

Networks

37.Розкажіть про модель OSI. Опишіть функції та призначення кожного рівня.
38.Які мережеві топології ви знаєте? Опишіть різницю між ними.
39.Навіщо потрібна IP-адреса, якщо MAC-адреса унікальна? Хіба ми не можемо спілкуватися тільки за MAC-адресою?
40.У чому різниця між концентратором і комутатором L2 у мережах Ethernet?
41.Що таке Vlan і навіщо існує поділ на віртуальні локальні мережі?
42.Який номер порту використовують для PING-комунікації?
43.Що таке сеанс зв’язку? Який алгоритм використовує TCP для доставки?
44.У чому основна відмінність між TCP і UDP?
45.Навіщо нам маршрутизатор за замовчуванням?
46.Як хост вирішує DNS за замовчуванням?
47.Комп’ютер почав отримувати IP-адресу з іншої мережі (є підозра, що в мережі працює інший DHCP-сервер): як його знайти і від’єднати? Які є методи захисту від такої проблеми?
48.Ми будемо мігрувати сайт на нову IP-адресу. Як зробити, щоб користувачі цього практично не помітили?
49.Що таке socket?
50.Як дізнатися, які віддалені хости під’єднуються до хосту через порт 8888? (за допомогою команд і не використовуючи /proc чи /sys).
51.Ми маємо кілька мережевих карт. Як збільшити пропускну спроможність сервера?
52.Як перевірити відкриті порти на віддаленому сервері без команди Netcat чи Nmap Linux?

Container orchestration

53.У чому переваги Kubernetes як платформи?
54.Що таке control plane та з яких компонентів складається?
55.Які CNI ви використовували та чим вони відрізняються?
56.Чим відрізняється managed Kubernetes від self-deployed?
57.Яким чином можна контролювати розміщення подів у кластері? (taints/tolerations, affinities, topologies etc)
58.Скейлінг кластеру. Cluster autoscaler vs HPA vs VPA? Як зробити zero-downtime node decommission/cluster upgrade? PDB? Lifecycle hooks?
59.Які існують способи для зовнішнього доступу до кластеру? ingress, node port, port-forward тощо.
60.З яким PID запускається процес у контейнері?
61.Що краще використовувати для ізоляції оточення — Vagrant чи Docker?
62.Який інструмент оркестрування контейнерів використовували? (Swarm, Kubernetes, Openshift, Rancher тощо.)
63.Що відбувається в Kubernetes після запуску kubectl (API, ReplicaSet Controller, storage back-end, scheduler, kubelet, worker node, pod)?
64.Яка різниця між pod та контейнером у K8s?
65.Як ми можемо зробити будь-який мікросервіс, який працює на K8s, доступним із зовнішнього середовища?

Віртуалізація і контейнеризація

66.Які типи віртуалізації ви знаєте?
67.Як працює Docker на macOS/Windows?
68.Що таке Docker-image і Docker-контейнер? Як вони між собою пов’язані?
69.Які основні відмінності між контейнерами докерів і віртуальними машинами?
70.Що таке image layer? Яка максимальна кількість layers можлива? Чому треба намагатися мати малу кількість layers? Яка оптимальна кількість?
71.Як у віртуальній машині змінити розмір диска після створення? Що треба зробити з гостьовою ОС?
72.Як у Docker реалізовано обмеження ресурсів?
73.Існує віртуальна машина, до якої втрачено доступ. Як, маючи доступ до її диска, відновити root пароль/SSH-ключ?
74.Оптимізувати Dockerfile, пояснити, що і чому так:

FROM golang
RUN apt install -y pkg1 pkg2 pkgN # Dependencies for app
COPY. .
RUN go build -o app main.go
CMD ./app

75.Що таке IPVS та який функціонал у нього є?
76.Яка структура API у Kubernetes?
77.Що таке operators і для чого вони потрібні?

CI/CD

78.Які стадії мають бути в будь-якому пайплайні (lint, test, build, deploy etc)?
79.Як і де зберігати build artifacts?
80.Що таке артефакт?
81.Є два бренчі: dev і stage. Ми закинули Dockerfile у dev, а потім збілдили у dev і stage. Це буде одним артефактом чи різними?
82.Що ви використовували для автоматизації налаштування Jenkins and GitLab CI?
83.Порівняйте CI інструментів: Jenkins, GitLab CI, AWS Code Pipeline, GCP cloudbuild, GitHub actions, Circle CI.
84.Deployment strategies. Які існують і чим відрізняються (recreate, blue-green, canary etc)?
85.Яким чином реалізувати СI/CD для програми, яка залежить від кількох інших програм?
86.GitOps. В чому його переваги та недоліки?

Clouds and Automation

87.Яка роль і переваги хмарних сервісів для DevOps?
88.Що таке immutable infrastructure? Як досягти? У чому переваги та недоліки? Packer, AMI тощо.
89.Структура Terraform. Як організувати multi-environment project? Terraform workspaces?
90.Найкращі практики з використання багатьох Terraform states.
91.Як організувати доступ розробницькій команді до AWS/GCP/Azure? Role-based access, assume role, SSO.
92.Що таке Terraform provider, module?
93.Як версіонувати Terraform modules?
94.Коли потрібно використовувати local-exec та remote-exec?
95.Що таке golden image та як його створити?

Monitoring/Logging

96.Як моніторинг допомагає підтримувати всю архітектуру системи?
97.Які інструменти моніторингу ви використовували?
98.Що таке медіана та процентиль?
99.Що таке SLI, SLO, SLA? Навіщо це потрібно?
100.Архітектура системи для збору логів, ELK, EFK etc. Як зберегти логи у разі відмови сховища? Чи потрібно використовувати для цього брокер повідомлень? Чи потрібно робити throttling/rate limits?
101.Prometheus long-term storage. Які варіанти?
102.Як працює Prometheus?
103.У чому принципова відмінність між Grafana і Kibana?
104.В чому головна відмінність між Ansible and Terraform?
105.Що таке SAAS monitoring та які види знаєте?
106.Якщо ви використовуєте Datadog/NewRelic, то як нам відстежувати падіння інструментів моніторингу?
107.Що таке distributed tracing та error tracking systems? Як ви думаєте, коли варто їх використовувати?

Information Security

108.У чому різниця між RBAC та ABAC?
109.У чому полягає XSS атака? SQL injection? Що таке CSP?
110.Які базові заходи можна вжити для захисту SSH-з’єднання?
111.Root-пароль невідомий чи загублений. Яка процедура відновлення?
112.Як керувати правами на файловій системі в Linux?
113.Що таке Firewall?
114.Чим відрізняється stateless від stateful фаєрволів?
115.Скільки таблиць у iptables?
116.Чи можна налаштувати трансляцію NAT за допомогою iptables? Яку таблицю варто використати?
117.Яку таблицю використовують для зміни заголовків пакетів?
118.Якщо вам ламають Linux-сервер, то як більш ефективно блокувати трафік з IP-адрес?
119.Принцип роботи GCP Firewall: чи можемо ми профільтрувати трафік на Load Balancer?
120.Що таке SELinux?
121.Чи можна повністю від’єднати SELinux на льоту?
122.З якими secrets management systems ви працювали?
123.У нас є сервер NAT, і ми хочемо забезпечити доступ за ІР до сервера зовні. Як нам це реалізувати?
123.Щоб потрапити на сервер клієнта, треба залогінитись на 4+ jump хоста. Як це автоматизувати? Де ми зберігатимемо наш SSH-ключ?

Development

125.Що таке cookies? Для чого потрібні? JWT?
126.Що таке feature toggles та навіщо вони?
127.Що таке TDD (Test Driven Development) та BDD (Behaviour Driven Development)?

Databases

128.Що таке індекс і що таке ключ?
129.Які переваги та недоліки індексів?
130.Уявіть, що ви розробляєте систему білінгу, яка має обробляти тисячі рахунків. Яку стратегію оновлення даних ви б обрали?
131.Які методи найчастіше використовують для масштабування реляційних баз даних?
132.Опишіть механізм транзакцій БД.
133.Як ми можемо видалити таблицю чи базу даних?
134.Як знайти повільні запити у MySQL/PostgreSQL?
135.Які SQL-оператори маніпулювання даними ви знаєте?
136.Чи можна вивести список баз даних/таблиць через CLI? Як ми можемо перемикатися між базами даних MySQL/PostgreSQL?
137.Які storage engines в MySQL ви знаєте? Які відмінності?
138.Як реалізовано реплікацію MySQL master-master? Скільки серверів MySQL може бути залучено в такій взаємодії?
139.Як працює реплікація MySQL/PostgreSQL? Які параметри мають бути налаштовані для реплікації?
140.Порівняйте SQL і NoSQL.
141.Sharding vs replication?
142.Які є види індексів? Коли і для чого використовувати?
143.Вимоги до схеми БД. Character sets, collations, default, not null тощо.
144.Ми мігруємо MySQL/PostgreSQL з on-prem у хмару. Як нам зробити це з мінімальним даунтаймом?
145.Навіщо та як тестувати перформанс баз даних?

Практичні завдання

146.Напишіть Terraform module для інфраструктури тестового сервісу у AWS.
147.Напишіть hello-world програму мовою на ваш вибір і сформуйте для неї helm chart/kustomize.
148.Як організувати деплой без downtime?
149.Опишіть способи troubleshooting для Docker-контейнера.
150.Розібрати і пояснити структуру CI/CD pipeline (на прикладі gitlab.yml).
151.Продемонструйте навички роботи з GitOps, опишіть деплоймент простенької програми.
152.Як організувати деплой вебзастосунку, запущений на кількох серверах без (або з мінімальним) downtime?
153.Як за допомогою Ansible дізнатися default gateway для пулу серверів, і якщо він відрізняється від бажаного, записати рядок «hostname: gateway» у файл на локальній машині?

Senior

Linux

1.Що може створювати високе навантаження на CPU (процеси застосунків споживають дуже мало ресурсів CPU)?
2.У нас немає команд ifconfig, ip, і поставити ми їх не можемо. Як нам дізнатися ip address, mask, network, routes?
3.Що таке suid, sgid та sticky?
4.Що тюнилося з системою для навантаження трафіку 1GB, 10G, 40G+?
5.Що тюнилося з системою для високого навантаження на диск?
6.Що таке Linux namespaces?
7.Що таке Ceph, як працює?
8.Що потрібно тюнити для Ceph?
9.Що станеться, якщо /dev/sda1 перенесемо в /root?
10.Ми видалили /dev/sda1. Як нам його відновити? Що таке pseudo-devices?
11.Нам хакнули сервер, і в директорії /var/www створили два мільйони файлів невеликого розміру. Якщо використовувати команду cd /var/www і потім rm -rf*, то у нас зависне термінал. Як видалити файли?
12.На якому рівні працює iptables?
13.Що таке eBPF та навіщо потрібен?
14.У вас є файл, який містить IP-адреси серверів (по одному в рядку). Є SSH-доступ до цих машин, і вам потрібно виконати завдання (наприклад, встановити список пакетів на всі вузли). Поясніть, як це можна зробити.

Networking

15.У чому відмінності між IPv4 та IPv6? Навіщо ми мігруємо на IPv6?
16.Співіснування IPv4 та IPv6: що це означає?
17.Чи справді працюють міжмережеві екрани з підтримкою IPv6?
18.Як працює DHCPv6? Чим він відрізняється від DHCPv4?
19.Як фрагментуються пакети IPv6 і чим це відрізняється від IPv4?
20Чи з IPv6 треба більше використовувати NAT?
21.Що таке DPDK?
22.Що таке SR-IOV? У чому різниця між DPDK та SR-IOV?
23.Що таке NetFlow та навіщо потрібен?
24.Що таке OpenFlow?
25.Що таке SDN і які контролери ви знаєте? Порівняйте контролери.

Різне

26.Що таке SDLC?
27.Розкажіть про останній досвід реалізації архітектури для сервісу.
28.Який найважчий скрипт писали?
29.Що таке configuration drift? Чому це відбувається і як це ускладнює життя інженерам\SRE\Ops?
30.Розкажіть про архітектуру, за яку ви наразі відповідаєте, і вкажіть, як вона масштабована та відмовостійка.
31.Назвіть три важливі KPI для DevOps-фахівця.
32.Як працює Kafka (clusters(brokers, controllers), topics, partitions)?
33.GitOps: Rancher Fleet vs Flux vs Argo?
34.Як використовувати GitOps для оновлення документації DevOps-застосунків?
35.Розкажіть про особливості проєктування Kubernetes on-premise.
36.Як організувати On-call процес для команди DevOps?
37.Опишіть основні кроки завантаження операційної системи Linux.

Container orchestration

38.Service mesh. Що це таке та для чого потрібно?
39.Cluster federation. Що це таке та для чого потрібно?
40.Pod fine-grained access. Як реалізувати? IRSA vs kube2iam vs kiam?
41.Як реалізовані послуги в кубернетах?
42.Як дебажити трафік контейнера?
43.Що таке unikernel і навіщо він потрібний?
44.Чому ком’юніті переїжджає з Docker containerd?

Clouds and Automation

45.Які переваги і недоліки cloud-провайдерів?
46.Cost optimization. Які є інструменти? Spot/preemptible instances, reservations?
47.Як організувати multi-account, multi-region cloud setup?
48.У чому полягає різниця між приватними та публічними мережами в AWS?
49.AWS Lambda: чи мали досвід роботи?
50.Коли варто переходити на AWS Lambda? Коли не варто? Аналогічні рішення в GCP чи Kubernetes?
51.Коли краще використовувати CloudFormation, а коли Terraform?

CI/CD

52.Що таке state в контексті використання Terraform?
53.Які існують branching strategy? На що опиратись при виборі?
54.Яким чином реалізувати feature/dynamic environments?
55.Як зробити емуляцію ресурсів cloud-провайдера для локального тестування та прискорення розробки?
56.Що таке MultiCloud?
57.Що таке Cloud-Agnostic і коли він буде потрібний?
58.Що таке Hybrid-Cloud та з якими рішеннями ви працювали?

Information Security

59.Як мають зберігатися паролі в базах даних (Salt&Pepper, Rainbow Tables, Adaptive Hashing)?
60.Як передавати секрети в application (Secrets management)?
61.Порівняйте CI/CD SAST та DAST?
62.Які ви знаєте Kubernetes security practices? RBAC? OPA? Які недоліки RBAC та які кейси знаєте?
63.Розкажіть про захист від DDOS атак, WAF.
64.Що таке Rootless containers і навіщо він потрібний?
65.Що таке AppArmor та Seccomp і навіщо вони потрібні?
66.Чи доводилося працювати з Falco? Якщо так, то що реалізовували?
67.HashiCorp Vault і як правильно передати нам секрети в контейнер і CI pipeline?
68.Що таке Admission Controllers та які ви використовували?
69.Як зберігаються секрети etcd? Як переглянути ресурси в etcd?
70.Чим перевіряєте на вразливості ваш Kubernetes cluster?
71.Що таке Secure SDLC?
72.Що ви знаєте про Cloud Infrastructure Attack via a Pull Request і як цього уникнути?

Observability

73.Що таке observability та чим відрізняється від звичайного моніторингу? Які особливості необхідно враховувати у мікросервісній архітектурі (tracing)?
74.Що таке SLI, SLO, SLA та для чого вони потрібні? Навіщо використовують error budget?

Databases

75.Що таке теорема CAP? Навіщо це треба?
76.Як працювати з міграціями? Що робити у випадку rollback? Як перевірити, що міграція backward-compatible?
77.Опишіть, як би ви оптимізовували роботу бази данних? (БД за вибором кандидата) Slow queries, buffers, thread pools?
78.Навіщо потрібно тестувати перформанс бази даних та якими інструментами?

Практичні завдання

79.Уявіть, що ви CTO Booking чи Airbnb. Які б ви ухвалювали рішення щодо:

  • Мови програмування.
  • Infrastructure as a Code.
  • Архітектури інфраструктури.
  • Налаштування CI/CD.

80.У вас є файл, який містить патчі в директорії. Наприклад:

/var/tmp/temp/file1.c
/var/tmp/file.ext
/var/tmp/temp/

etc... один шлях у рядку. Якщо шлях закінчується на ’/’ , це шлях до каталогу. Вам потрібно відновити це дерево каталогів із порожніми файлами в іншій файловій системі. Напишіть bash-скрипт.

81.Уявіть, що вам треба переконати Spotify, що використовує AWS, перейти на GCP. Як ви мотивуєте Spotify мігрувати на GCP?
82.Є сервісна компанія, яка надає сервіс трекінгу перевезень. Є клієнти, які не хочуть, щоб їхні дані процесувалися в AWS. Як нам реалізувати multi-cloud solution?

Дякуємо за матеріал Владу Волошину, Павлу Петриченку, Віталію Гарбулинському (BrightLocal), Євгену Думі, Сергію Яремчуку, Вадиму Шкілю, Олександру Білюку, Олександру Нежинському, Владиславу Граму, Станіславу Коленкіну, Олегу Миколайченку, Антону Гаврилову.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось27
До обраногоВ обраному37
LinkedIn

Схожі статті

  • Співбесіда з Java. 250+ запитань для Junior, Middle, SeniorСпівбесіда з Java. 250+ запитань для Junior, Middle, Senior

    Редакція DOU

    Редакція DOU запитала СТО та досвідчених фахівців, що проводять інтерв’ю з Java, про те, які теоретичні запитання ставлять і які задачі та завдання пропонують розв’язати кандидатам. Адже перед технічною співбесідою важливо мати чіткий план підготовки. 47

  • Співбесіда з .NET. 150+ запитань для Junior, Middle, SeniorСпівбесіда з .NET. 150+ запитань для Junior, Middle, Senior

    Редакція DOU

    Редакція DOU поспілкувалась з розробниками, що проводять технічні співбесіди для різних рівнів .NET-спеціалістів, і зібрала приблизний список запитань для кандидатів. У матеріалі є і теоретичні питання, і практичні задачі. 95

  • Співбесіда з Python. 100+ запитань для Junior, Middle, SeniorСпівбесіда з Python. 100+ запитань для Junior, Middle, Senior

    Редакція DOU

    Редакція DOU поспілкувалась з розробниками, що проводять технічні співбесіди для різних рівнів Python-спеціалістів, і зібрала приблизний список запитань для кандидатів. У матеріалі є і теоретичні питання, і практичні задачі. 50




Найкращі коментарі пропустити

— Так! Архитектура ядра, быстро, без подгладяваний! Системы ветвления Git, какие знаешь! BPF, расскажи как и что дебажил. Писал скрипты на 200 строк?
— ЭЭЭ... а зачем это все?
— тыждевопс, позажирались тут, 7,5К... Ладно, какие у тебя вопросы?
— Как и в чем вы документируете инфраструктуру? Как устроен бэкап кубера? Как бэкапите базы данных? Технического долга много? Какова структура работы с credentials?
— Мы вам перезвоним...

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

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

Для соискателя такие материалы вредны, потому что это один из вариантов гейткипинга. Человек посмотрит на подобный список и развернётся со словами: «Та ну нафиг». И да, аргументы из разряда «ну не нужно же отвечать на все вопросы!», «даже если вы знаете Х% — всё равно стоит подаваться» и (моё любимое) «это же покажет людям, на что обратить внимание» — не работают. Первые два аргумента просто отсеивают всех, кроме самых наглых, последний — чистой воды подмена понятий. Если хотите помочь подтянуть знания в той или иной дисциплине, и статьи нужно писать соответствующие. Например, «Kubernetes 101» или «Сети для самых маленьких» (поищите эту статью на Хабре); но уж точно не публиковать список на сотню случайных вопросов без ответов.

Для работодателя подобные статьи — тоже плохо! Во-первых, из-за того самого гейткипинга чата кадров не попадает в индустрию и народ потом ноет, что специалистов не найти ни на какой вообще уровень. Кроме того, после прочтения подобного материала неопытный интервьюер может подумать: «А действительно! Чего ж это я не спрашиваю про ARP, коммутаторы, „это жы база!“.» И не важно, что в компании инфраструктура в облаке и к реальным задачам это никакого отношения не имеет.

Собеседование — это двухсторонний матч. Как в Тиндере, если вам угодно.

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

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

Для тех же, кто думал о том, чтобы вкатиться в инфраструктурную или системную инженерию, но увидел этот список вопросов и подумал: «Ну нафиг!», — не спешите! Здесь интересно и весело, не давайте случайным людям из Интернета сбить вас с пути!

Всем добра! Читайте хорошие статьи. Tschüssi!

Конечно хорошо, когда современный девопс знает «Опишіть архітектуру ядра Linux», но скажите честно, например на амазоне, когда там все автоматизированно и инстансы просто как строительные блоки, котрые удаляются, стартуют, заменяются и т.д и т.п., когда пригодилось знание архитектуры ядра?

«У чому переваги Kubernetes як платформи?» — стоило бы уже и о недостатках тоже поговорить.

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

Забавный список. Попробую его прокомментировать глазами нанимателя.

С одной стороны — это сборная солянка для всех «околоинфраструктурных» позиций, что отражает общий бардак на нашем рынке — где в одной лавке девопсы «настраивают кубер», в другой отвечают за continuous delivery и operations, а в третьей — за выдачу аккаунтов в suite. Смешались вопросы по традиционному администрированию, devops-ингу, SRE, и чуть ли не solution architecture. Не отражает ни одну из зон в достаточной мере, но действительно трогает все. Отдельное спасибо за не-безбожно-мимо вопросы по security — действительно, от инфраструктурного инженера, который не занимался ИБ серьезно, но работал в приличном месте и делал что-то около безопасности, ответа хотя бы на некоторые из этих вопросов я был бы рад услышать.

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

Если азов (способности отвечать на вопросы из списка выше) нету на уровне «не может внятно рассказать Junior-уровень» (а это 50% кандидатов с словом senior в шапке резюме, увы, судя по 15-летней статистике), то любые прикладные навыки осваиваются неглубоко, системное мышление и опыт не множатся с годами, а растягиваются тонким слоем по монгольской степи. Nothing wrong with that, мы таких не нанимаем (потому что уважаем нервы уже работающих в компании), но это не значит, что кандидат «профнепригоден по факту отсутствия шашечек» — он действительно в некоторых командах хорошо сможет ехать в узком прикладном поле, где он научился что-то делать, и может компенсировать недостаток глубины знаний трудолюбием, усидчивостью, социальными навыками, авантюризмом и карьеризмом и чем угодно еще — есть много способов скомпенсировать свои слабые стороны, хороших и плохих.

Що таке DevOps?

Шикарне питання!
Якщо людина відповіла правильно (про культуру і тд), то добиваєте питанням «Так як же тоді може існувати позицію на яку ви претендуєте?»

115 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Не смотря на то, что я могу ответить на все эти вопросы — это бред собачий. 90% — вопросы под конкретный проект. Эти вопросы не покажут понимания человеком принципов работы.

Команди, з якими я працював 2019-2020 говорили, що шукали спеціалістів з DevOps і не знайшли відповідних спеціалістів. Навряд чи за 2 роки в Україні виникло кілька тисяч спеціалістів з навичками devops і досвідом 3-5 років. Таких забрали глобальні ІТ корпорації на $8-12К в місяць. Лідери ринку змогли підготувати за 2 роки 1000 спеціалістів, ще пару тисяч навчились самостійно. Але зростання виделки з $2-5К до $4-12К вказує на те що дефіцит існує. Пропозиція не встигає за попитом.

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

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

Для соискателя такие материалы вредны, потому что это один из вариантов гейткипинга. Человек посмотрит на подобный список и развернётся со словами: «Та ну нафиг». И да, аргументы из разряда «ну не нужно же отвечать на все вопросы!», «даже если вы знаете Х% — всё равно стоит подаваться» и (моё любимое) «это же покажет людям, на что обратить внимание» — не работают. Первые два аргумента просто отсеивают всех, кроме самых наглых, последний — чистой воды подмена понятий. Если хотите помочь подтянуть знания в той или иной дисциплине, и статьи нужно писать соответствующие. Например, «Kubernetes 101» или «Сети для самых маленьких» (поищите эту статью на Хабре); но уж точно не публиковать список на сотню случайных вопросов без ответов.

Для работодателя подобные статьи — тоже плохо! Во-первых, из-за того самого гейткипинга чата кадров не попадает в индустрию и народ потом ноет, что специалистов не найти ни на какой вообще уровень. Кроме того, после прочтения подобного материала неопытный интервьюер может подумать: «А действительно! Чего ж это я не спрашиваю про ARP, коммутаторы, „это жы база!“.» И не важно, что в компании инфраструктура в облаке и к реальным задачам это никакого отношения не имеет.

Собеседование — это двухсторонний матч. Как в Тиндере, если вам угодно.

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

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

Для тех же, кто думал о том, чтобы вкатиться в инфраструктурную или системную инженерию, но увидел этот список вопросов и подумал: «Ну нафиг!», — не спешите! Здесь интересно и весело, не давайте случайным людям из Интернета сбить вас с пути!

Всем добра! Читайте хорошие статьи. Tschüssi!

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

Вони закривають важливу нішу: співбесіда джунів (трейні/інтренів, тих у кого досвіду 0). Такий «екзамен» — це найефективніший в плані результат/витрачені ресурси підхід.

Найм джуниоров, трейни и интернов — это коммитмент в их развитие.

Если вы априори знаете, что перед вами человек с малым опытом, «экзамен» никакой новой информации вам не предоставит. Он только:

а) Демотивирует соискателя
б) Создаст компании репутацию, куда лучше не собеседоваться. Все эти истории о самоутверждающихся за чужой счёт интервьюерах образовались не на пустом месте.

Гораздо продуктивней спросить соискателя примеры задач (пусть не продакшн), которые тот решал. В этот момент, если очень хочется, можно и поспрашивать пару-тройку технических вопросов.

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

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

Найм джуниоров, трейни и интернов — это коммитмент в их развитие.

Ні. Це спроба __компанії__ «заробити» на тому, що людина буде рости швидше ніж їх ЗП. Комерційні організації існують, щоб заробляти гроші.

Если вы априори знаете, что перед вами человек с малым опытом, «экзамен» никакой новой информации вам не предоставит.

Ля-ля. Це я все знаю :)
Але воно актуально, якщо задача саме «виховати» крутого члена команди.
Коли є бізнесова задача, то треба, якось міряти її і оптимізувати ціну.

Гораздо продуктивней спросить соискателя примеры задач (пусть не продакшн), которые тот решал.

Відповідь — не вирішував ніяких задач. Що далі?
В цьому проблема з джунами. Ну в універі може про докер розповідали, може щось про мережу. З клаудами, тераформами, кубом та гіопсом людина не працювала на рівні коли навички показують розуміння.

Каждый раз в подобных дискуссиях я натыкаюсь на communication breakdown с аутсорсом.

Це спроба __компанії__ «заробити» на тому, що людина буде рости швидше ніж їх ЗП.

Компании зарабатывают на предоставлении услуг или сервисов. Вот эта идея о перепродаже голов даже звучит как-то противно.

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

Хорошего вам дня!

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

Хорошего вам дня!

Ліл. Якщо люди не хочуть продовжувати розмову, вони її просто не продовжують, а от коли в них немає аргументів, то пишуть те що ви написали :)

на communication breakdown с аутсорсом.

В продуктових конторах та ж історія:
— не завжди стоїть задача знайти того самого,
— не завжди інженери і навіть лінійні менеджери розуміють як «комітмент на розвиток» мапиться на бізнес цілі (див попередній пункт)

Человек посмотрит на подобный список и развернётся со словами: «Та ну нафиг».

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

И такие вот списки помогали понять, что в принципе спрашивают, можно и нужно знать, про что можно почитать. процентов 30-40 из этих вопросов по всем направлениям мы все это знали и считали, что ничего не знаем и еще кучу практических навыков надо получить. при том, что большинство шли по пути разработчиков, а не опсов\админов. потому что это давали в универе + сами для себя осваивали и считали это базовыми знаниями. Это не rocket-science какой-то.
Остальные процентов 40-50%, это уже чет прикладное, что используется на практике, в каких-то направлениях. Чего в универе не дают и не должны. Ибо зависеть будет от компании, сферы ее бизнеса и т.п. Кому то клауда, кому то все свое. У кого то своя сеть и маршрутизация, кто-то сервисами пользуется. И остальные 10-20% может быть редко используемое, что будет знать уже реально умный и любопытный, на кого стоит обратить внимание.

Но сейчас, когда полно свитчеров, кто закончил 3 месячные курсы и думает, что он стал junior software engineer, кажется что это никому не надо, rocket science, чего вы вообще меня собеседуете, тут я пришел спрашивать почему я к вам должен идти. Может все таки пусть посчитает «ну его нафиг» ?

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

А если собес на галеру, где нужно делать 20 проектов в месяц на фреймворке Х, то там и не будет этих вопросов. Ибо не всегда выйдет вытащить на интервью людей, кто сможет задать и оценить ответы на все эти вопросы.

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

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

У меня где-то 20 лет опыта в этой области, университетское образование, я тоже впитываю все, до чего дотягиваюсь и я не стесняюсь вот прямо сейчас заявить, что минимум 40% этого бреда я не отвечу.
тоесть либо они ищут супер-гуру с эйдетической памятью(моя вроде тоже очень неплоха), либо просто ищут чувака умеющего отвечать на стандартные вопросы, а не работать.

Ну к примеру

Що станеться, якщо /dev/sda1 перенесемо в /root?

Это вообще к чему? А что у нас на нем? а есть ли вообще в системе сата диски? А зачем это в облаке, учитывая вопросы по облачной инфраструктуре? Да и вообще, что значит «перенесем» в данном контексте? Примонтируем? Скопируем файлы? rsync?

1.Що може створювати високе навантаження на CPU (процеси застосунків споживають дуже мало ресурсів CPU)?

ем? все что угодно? учитывая что про систему мы ничего не знаем. Может там мышка глючит. Или msdos и происходит чтение с диска 5 дюймов.

А уж «уявить шо вы СТО» на позицию девопса.. к чему это?

23.Як затюнити параметри Linux Kernel?

а какая, собственно, цель? ибо с такой постановкой единственный правильный ответ — нефига не трогать.

Это вообще к чему? А что у нас на нем? а есть ли вообще в системе сата диски? А зачем это в облаке, учитывая вопросы по облачной инфраструктуре? Да и вообще, что значит «перенесем» в данном контексте? Примонтируем? Скопируем файлы? rsync?

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

ем? все что угодно? учитывая что про систему мы ничего не знаем. Может там мышка глючит. Или msdos и происходит чтение с диска 5 дюймов.

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

а какая, собственно, цель? ибо с такой постановкой единственный правильный ответ — нефига не трогать.

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

Та все можно, можно просто отвечать на почти все вопросы из списка «недостаточно контекста».
Просто не вижу смысла.
Лично я когда мне клиент задает такие вопросы говорю «наверно вам нужен другой исполнитель, если у вас с ним тоже не получится, возвращайтесь».

Та все можно, можно просто отвечать на почти все вопросы из списка «недостаточно контекста».
Просто не вижу смысла.

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

И такие вот списки помогали понять, что в принципе спрашивают, можно и нужно знать, про что можно почитать.

Лёгким движением руки меняем заголовок на «На что стоит обратить внимание при изучении работы Linux / сетей / баз данных / обеспечения безопасности» (тут просто обо всём есть вопросы). И там далее по тексту: «... при изучении стоит так же обратить внимание на общую архитектуру ОС, типы файловых систем, их преимущества и недостатки, работу блочных устройств...» ну и так далее.

И вуаля! Из тупого гейткиперского списка практически такой же текст превратился в какое-никакое пособие для домашней работы.

интересно как вы прикидываете динамику роста.

Когда я только начинал свой карьерный путь, меня часто спрашивали, какие книги я прочитал за последние N времени. Можно прикинуть опорные временные точки. Например, испытательный в компании 3 месяца, можно спросить, что человек выучил за последние 3 месяца. Спросить, учил ли сам или группой и так далее.

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

Нет ничего плохого в том, чтобы спросить про таблицы IPTABLES, если речь зашла о сетевых фильтрах или маршрутизации трафика на Linux машинах. Точно так же вопросами можно контекст переключать, например, если вы долго общались про БД, а теперь хотелось бы и про Web что-то, можно перевести разговор пресловутым «что будет, когда написать google.com в браузер». Хотя я лично стараюсь таких вопросов избегать и переключать контекст во время интервью явно: «Хорошо, вот мы поговорили про БД, давайте ещё поговорим о Web...».

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

P.S. И это не говоря уже, что в этой конкретно статье часть вопросов вне контекста, мягко сказать, странная и куча вопросов вообще повторяются.

Буде нецікаво, якщо кандидат знає всі анекдоти. Про що тоді розмовляти на співбесіді?

Якщо корпорація накаже, то вперед з піснею :)

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

Не существует такого списка.

«Что должен знать девопс» звучит приблизительно так же, как «что должен знать разработчик». Java-разработчик должен знать Java, а JavaScript-разработчик, стало быть, JavaScript.

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

Точно так же и соискатель, если имеет опыт с определённым стеком, будет в это стек целиться. Исключение, разве что, сознательный переход от одного стека в другой. Например, человек, который всю жизнь работал с AWS, хочет перейти в GCP. Но даже тут такой список не поможет.

Нету такого. В компании могут вообще не использовать облака к примеру.
или не использовать модные контейнеры, потому что все в облаке, тогда вам надо знать базворды amazon, как тому 13летнему solution architect associate.
В любом случае по факту вы будете гуглить и делать тестовые сервера, чтоб случайно не навернуть продакшн с простоем как ваша зарплата за год.
Единственный точно полезный навык — понимание последствий своих действий.

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

Ну если у вас в организации весь деплоймент .Net под виндой и в облаке тоже винда, то да — вам вообще нет смысла уметь работать с линуксом.

дотнет под виндой это скорее исключение для легаси, где есть завязки на операционную систему, все что стартовало с года 16-17 в 99% случаев не имеет этих завязок

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

«Jack of all trades, master of none» ©

Список вопросов для рекрутинга сферичекого DevOps-а в вакууме.
Но, благодаря этому списку/паттерну вопросов теперь за километр будет видно, что те кто собеседуют тебя, нихрена «не отстреливают» зачем им DevOps на проекте.

Але буде видно, хто читав статтю :)

It is time to know who are using AWS on US-East-1 only :)

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

Може вже час замінити питання про MySQL/PostgreSQL на Cassandra/MariaDB?

Скільки employers готові платити за знаходження 3-5 DevOps спеціалістів і скільки на цьому процесі бажають заробити рекрутери? Коли варто використовувати власних recruiters and sourcers, а коли залучити freelance, hr agencies?
Спробував знайти відповіді.
dou.ua/forums/topic/35540

ви ще спитайте чи VPC реалізовано під капотом на VRF і куди дівся в ньому ARP протокол

в AWS broadcastи не ходять і ARP spoofing/Cache Poisoning не працює — воно там земульовано proprietary mapping service

All AWS VPC traffic is unicast, да.

Docker-контейнер споживає багато SWAP. Що робити?

— это кому-то еще интересно?

Що таке SELinux і навіщо він потрібен?

— а это?

HashiCorp Vault і як правильно передати нам секрети

 — это на правах рекламы?

Уявіть, що вам треба переконати Spotify, що використовує AWS, перейти на GCP. Як ви мотивуєте Spotify мігрувати на GCP?

— наверно владельца Spotify придется вывезти в лес

Як і часто буває, багато питаннь biased на те з чим працюють ті, хто питають. На самій співбесіді це є норм, адже людину під це і шукають, а ось в такому списку не дуже.

Ansible, як на мене, несправедливо обділили увагою )

Ну і з голови написати consumer для черги — таке собі ... якщо протягом останнього місяця це не робив, то перший запит в гуглі буде на доку по клієнту для потрібної черги.

А в цілому, цікаво ... є що погуглити )

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

Забавный список. Попробую его прокомментировать глазами нанимателя.

С одной стороны — это сборная солянка для всех «околоинфраструктурных» позиций, что отражает общий бардак на нашем рынке — где в одной лавке девопсы «настраивают кубер», в другой отвечают за continuous delivery и operations, а в третьей — за выдачу аккаунтов в suite. Смешались вопросы по традиционному администрированию, devops-ингу, SRE, и чуть ли не solution architecture. Не отражает ни одну из зон в достаточной мере, но действительно трогает все. Отдельное спасибо за не-безбожно-мимо вопросы по security — действительно, от инфраструктурного инженера, который не занимался ИБ серьезно, но работал в приличном месте и делал что-то около безопасности, ответа хотя бы на некоторые из этих вопросов я был бы рад услышать.

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

Если азов (способности отвечать на вопросы из списка выше) нету на уровне «не может внятно рассказать Junior-уровень» (а это 50% кандидатов с словом senior в шапке резюме, увы, судя по 15-летней статистике), то любые прикладные навыки осваиваются неглубоко, системное мышление и опыт не множатся с годами, а растягиваются тонким слоем по монгольской степи. Nothing wrong with that, мы таких не нанимаем (потому что уважаем нервы уже работающих в компании), но это не значит, что кандидат «профнепригоден по факту отсутствия шашечек» — он действительно в некоторых командах хорошо сможет ехать в узком прикладном поле, где он научился что-то делать, и может компенсировать недостаток глубины знаний трудолюбием, усидчивостью, социальными навыками, авантюризмом и карьеризмом и чем угодно еще — есть много способов скомпенсировать свои слабые стороны, хороших и плохих.

jobs.dou.ua/...​ck-labs/vacancies/151541

TL;DR — способность хорошо отвечать на вопросы соответствующего уровня квалификации из этого топика на DOU: dou.ua/...​rticles/interview-devops

Вот уж пригорело :D

Люблю внимательных людей, готовых сделать пару кликов из любопытства, спасибо вам!

Половину, якщо не більше, питань мені задавали на звичайних девелоперських співбесідах, хіба про кубер і тераформ ще ніразу не питали.
Границя між професіями стирається.

Загалом питання ок, взяв на озброєння, дякую!

С другой стороны где вопросы про blue/green, canary deploy. С какими балансировщиками работал. Системы виртуализации. Кластеры баз данных. Service discovery. Про сертификаты.

Вам «шашечки» или ехать?

Я щось не зрозумів.. а де відповіді?)

Я щось не зрозумів.. а де відповіді?)

Я — девопс,
Я не хочу нічого вирішувати,
Я хочу 9К

Там ще є декілька питань, які принципово некоректно сформульовані. І це гарно — таких має бути щонайменше пара відсотків — щоб розуміти рівень розуміння і у відповідях отримувати розʼяснення, як має бути насправді.
Так що все ok :)

Що таке DevOps?

Шикарне питання!
Якщо людина відповіла правильно (про культуру і тд), то добиваєте питанням «Так як же тоді може існувати позицію на яку ви претендуєте?»

Співбесіда з Python. 100+ запитань для Junior, Middle, Senior
Співбесіда з .NET. 150+ запитань для Junior, Middle, Senior
Співбесіда з JavaScript. 300+ запитань для Junior, Middle, Senior
Співбесіда з Java. 250+ запитань для Junior, Middle, Senior
Співбесіда з PHP. 250+ запитань для Junior, Middle та Senior

Что забавно во все предыдущих нет подобного вопроса)
Що таке Python, PHP, .NET, JS, Java не спрашивают.
Щож таке DevOps?

Похоже, питон в 3 раза проще девопса.

У чому різниця між концентратором і комутатором L2 у мережах Ethernet?

если у них сеть до сих пор на HUB-ах, я б туда поостерегся идти

Ну в принципе и в облаке можно покопаться найти реализацию, которая пересылает всё всем.

— Так! Архитектура ядра, быстро, без подгладяваний! Системы ветвления Git, какие знаешь! BPF, расскажи как и что дебажил. Писал скрипты на 200 строк?
— ЭЭЭ... а зачем это все?
— тыждевопс, позажирались тут, 7,5К... Ладно, какие у тебя вопросы?
— Как и в чем вы документируете инфраструктуру? Как устроен бэкап кубера? Как бэкапите базы данных? Технического долга много? Какова структура работы с credentials?
— Мы вам перезвоним...

В целом плюс комменту, но

Системы ветвления Git, какие знаешь!

Здесь снова залезу на броневичок).
1) Как без этого настраивать CI/CD?
2) Как без этого в том же гите хранить IaC вообще?
Ибо они напрямую связаны с ветвлением.

Стратегии ветвления то тут причем ? Как настраивать CI/CD — правильный ответ как попросят и чтобы удобно было менеджменту понимать что зарелижено и когда, что бы все можно было откатить назад из продакшена если нужно, восстановить из бакапа в случае сбоя и т.д. Dev Ops — и Solution Architect это не одно и тоже самое, то что дев-опс может вырости в архитекта — конечно может.

Стратегии ветвления то тут причем ?

Наверное, при том, что CI/CD прибит гвоздями к веткам в репозитории?) Например, если следовать ортодоксальному GitFlow 100% «по книжке», то нельзя реализовать «build once — use everywhere» подход без модификаций этого самого Flow.

Dev Ops — и Solution Architect это не одно и тоже самое

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

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

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

Без проблем. Как тимлид сказал комитить, так и комитят. Даже название проекта и ветки лучше спросить у тех, кто дольше в компании ибо СоС.

Вопрос, который был задан, не относится к мантре, в которой Вы пытаетесь натянуть сову на глобус (контекст разработки аппликейшена на контекст IaC). Я говорю про новые проекты, и что всем пофиг, как хранится инфраструктура, но «тимлид сказал» и «спросить», ага. Тимлиду в 99% случаев пофиг на то, как будет храниться инфраструктура, а если речь о тимлиде девопсов — это тоже девопс (ваш Кэп).

ибо СоС

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

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

Ну это был стёб )) Более демонический вопрос-ответ (на слух):
— какой у вас Git Flow?
— GitFlow
— зачем вы дразнитесь!?!?!?
А если серьезно, то с моей точки зрения, система ветвления это очень важно. Особенно когда в Gitlab, у которого в архитектуре своя система, начинают пихать gitflow.

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

Senior
48.У чому полягає різниця між приватними та публічними мережами в AWS?

Слишком толсто

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

Коментар порушує правила спільноти і видалений модераторами.

И снова здравствуйте, открытый вопрос про infrastructure as code на senior который задают junior-у. Или опишите архитектуру linux — если даже взять третье издание Тандербаума где поверху прошлись — то будет целый раздел книги. И наоборот senior-а спрашивают что может давать нагрузку на CPU. В общем все как и в других сборниках — видимо ещё отраслью не умеем собеседовать. ИМХО часть вопросов вообще к developer — а не к dev ops, например branching strategy и SLDC.

Тебе уже ответили выше — как скажет команда и менеджер, так и настроишь CI

Так это ж и есть формошлёпство со стороны DevOps). По-нормальному DevOps это должен предлагать. Экспертиза же в смысле применения, а не в знании тулинга как такового — тулинг можно выучить, а опыт приходит только с практикой. Тем более, пример я уже привёл — придут к тебе с ортодоксальным GitFlow, попросят build once, и всё, лапки — потратится время, пока эмпирически не наткнутся на «ой, а так не получается».

Ты теперь знаешь, что я тебе в команду не подойду. Это сэкономит всем время :)

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

Для чего ещё это знать — одному тебе ведомо.

А как стратегию выбирать для IaC будем, и CI/CD для неё же? Побежим к менеджменту и девелоперам за помощью, что ли? А менеджмент и девелоперы озабочены своими application сервисами — до инфры им дела нет, раз есть DevOps’ы на проекте — это их работа). Снова лапки?..

Так это ж и есть формошлёпство со стороны DevOps). По-нормальному DevOps это должен предлагать.

Это вопрос таки на стыке областей ответственности. Часть вопросов решается только со стороны PO, который собирает и переваривает пожелания клиентов — например, сколько должен держаться LTS релиз? Сколько трейнов должно быть и какие (сколько, например, супернадёжных, хоть и отстающих по фичам)? Тут девоп никак не может повлиять, только советом. А вот, например, напускать полный цикл CI тестов по крону, после одобрения всего pull request или можно и до — это уже компетенция как раз девопов, сколько у них выдержит вся система с CI во главе; а это уже может влиять на стратегию бранчинга.

Остальное примерно так же.

С одной стороны лид девопсов тоже никто не отменял. Тоесть нужно знать как менеджить релизы, артефакты и т.д. Обычно к девопсу полностью другие вопросы, по созданию настройке и сопровождению всей инфраструктуры. Собственно если посмотреть все другие сборники вопросов на собеседования по всем другим специализациям — получаем тоже самое. Перемешаны слоны с котлетами и преправлено мухами. Вот с какого перепугу спрашивается junior-а спрашивать как устроено ядро linux ? Я понимаю ещё что то вроде — «что нужно чтобы подключится по ssh к серверу», «что делают команды top, du, df» и тому подобные простые вопросы на определение минимально необходимой квалификации. А тут что хотят узнать?Особенности монолитного ядра в сравнении с микро и экзо ядрами, организации системных вызовов и механизмов распределения памяти ? Может ещё и научную работу тогда зачитать где сравниваются: FreeBSD, L4, March и Darwin/Mac OS X ?

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

Таненбаум проходился по архитектуре Линукса в книге? Точно? Или есть какой-то другой Тандербаум, зыбкий двойник-typo-однофамилец, который написал какое-то здоровенное сочинение про Linux?

Upd, я понял! Речь о четвертом издании архива comp.os.minix за 1992-й год (единственное место, где Энди Таненбаум действительно разбирал устройство ОС Linux, насколько я знаю)?

Прочитай третье издание, там его аспирантка и аспирант добавили внушительные части книг с обзорами по linux и windows nt. Секции называются «Рассмотрение отдельных случаев». В предисловии к книге Таненбаум и написал об этом в разделе — что нового в третьем издании и что он привлекал к этому труду своих аспирантов. Естественно это по существу поверхностный обзор, потому что по архитектуре ядра linux есть отдельные книги.

Truly so, good find.

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

<

Уявіть, що вам треба переконати Spotify, що використовує AWS, перейти на GCP. Як ви мотивуєте Spotify мігрувати на GCP?

Spotify вже на GCP :)

Так час на співбесіді тянути треба, слот не просто так ж дали) Взагалі якщо порівняти співбесіди на забугорні кантори і наші це небо і земля. Був на забугорних, давали практичні задачі і тд, побудувати архітектуру, програмінг тощо. Наші ж питають тупо теорію яку ітак потім в доці можна підглянути і яка практично ніяк не використовується)

31.Що таке колізія? Чому виникає?

Тут треба уточнити, колізія чого? Колізія в хеш таблиці, чи колізія IP адрес, чи правова колізія?)

исходя из раздела

Networks

думаю, речь про ethernet collisions и CSMA/CD
вероятно, по мнению экзаменаторов, задающих подобные вопросы в категории DevOps, это самое сакральное знание, для использования public cloud, построенных на полудуплексных 100BASE-TX и WiFi[сарказм]
при чем наверняка сами экзаменаторы в ethernet-протоколах не разбираются, откуда ограничение в 100м для того же 100BASE-TX — не представляют и соответственно, природу late collisions — не понимают

чи колізія IP адрес

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

Я думаю, речь таки про MAC или IP address collision.
Во всяком случае, я бы про это как раз начал отвечать. А если что-то другое — пусть правильно ставит вопросы...

Може бути колізія двух автомобілів.

т.зв. колізія інтерв’юера і кандидата :D

На это нужен отдельный раздел. Виды таких коллизий, методы разрешения. Применяемые технологические средства (чай, кофе, водка, кулаки, биты, стулья, столы, клавиатуры).
Эффективность применения конкретных средств (эх, не сохранился ролик, где два админа дрались — с одной стороны Cisco 2511, с другой 2503).
Стратегия win-win и сколько отката кандидат даёт интервьеру после успешного найма.
Ну и так далее...

Конечно хорошо, когда современный девопс знает «Опишіть архітектуру ядра Linux», но скажите честно, например на амазоне, когда там все автоматизированно и инстансы просто как строительные блоки, котрые удаляются, стартуют, заменяются и т.д и т.п., когда пригодилось знание архитектуры ядра?

«У чому переваги Kubernetes як платформи?» — стоило бы уже и о недостатках тоже поговорить.

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

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

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

Хз, зависит от рода деятельности специалиста и его основных задач. Если эта инфа не используется — она перезатирается или удаляется и это самое обычное поведене мозга.

В универе мне преподавали физику, много, Ландау и Лифшиц наверное были в восторге от этого, но уже прошло 8 лет после окончания универа и чет не особо я жалею и помню эту инфу.

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

отдел спецов по networking, отдел спецов по линуксу, отдел спецов по sdlc. а связующим звеном кто будет?) все равно кто то должен быть, кто все это будет знать поверхам либо их экспертиза должна пересекаться

а по поводу:

Конечно хорошо, когда современный девопс знает «Опишіть архітектуру ядра Linux», но скажите честно, например на амазоне, когда там все автоматизированно и инстансы просто как строительные блоки, котрые удаляются, стартуют, заменяются и т.д и т.п., когда пригодилось знание архитектуры ядра?

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

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

Не так, это вопрос уровня «Расскажите химический состав кирпича»

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

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

Ну и когда вам прошлый раз пригодилося знание именно архитектуры ядра? Или когда вы прошлый раз видели вживую колизию в век full duplex и full speed switching?

Ну и когда вам прошлый раз пригодилося знание именно архитектуры ядра?

В «архитектуру ядра» входит, например, то, что iptables включаются между протоколонезависимым драйвером сетевухи и реализацией IP стека (или не IP, в особых случаях).
И поэтому, если вы в выводе tcpdump не видите пакетика, то ждать его на сокете и искать фильтрующее правило бессмысленно, и наоборот.
Или, что если идёт прожорство процессора в bottom half, то искать, какой процесс это вызвал, напрямую чем-то вроде top уже не получится.
И таких мелочей, которые возникают от понимания, «кто на ком стоял», будет 100500.

Да не, у вас вопрос вменяемый. Это вроде как «раскажите особенности кирпича».

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

Знание всех подробностей архитектуры ядра для девопса не особо актуальны. Достаточно понимания базовых принципов. Для девопса важно видеть архитектуру проекта (сервера, взаимодействие, очереди, кеши, базы данных, IAC и т.п.), и понимать их взаимодействие и связи, понимать основы сетевого протокола на уровне найти почему пакеты не ходят или почему затык, знать и понимать работу сетей.

Для инфраструктурного инженера есть смысл знать архитектуру ядра.

Девелоперам, смотря что пишут.

найти почему пакеты не ходят или почему затык,

ну как бы для этого и нужно понимание) видеть архитектуру и связи и картограф сможет) а понимать почему так, из-за чего могут быть проблемы, на каком уровне. почему после обновления на свежу версию ОС внезапно сломался dns resolving между сервисами, а на stackoverflow еще не набежали хомячки с вопросами о поломке и им еще не успели помочь... что делать тут без понимания и как решать задачу?

Давайте уточним. Мне кажется мы отвлекись от знания архитектуры ядра :)
Вот настолько подробно, как на картинке, девопсам нет смысла знать ядро.
losst.ru/...​delayet-yadro-linux-1.png

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

Наверное в сторону взять кусок инфрастуктуры, например, базы, понять как это работает. Потом, кусок, например, автоскейлинг группы, NFS/EFS понять где хранятся файлы и т.п. смыл понять что это такое, как оно взаимодействует, что влияет на число инстансов, как это мониторится, почему в кластере БД столько серверов... И вот когда прейдёт понимание в целом, тогда уже изучать детали. Т.е. идти от сверху в низ. Пример, конечно, натянут, но надеюсь суть смог объяснить.

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