A to nie lepiej pytać o to, co ty robiłeś i czy koleś to umie, albo przynajmniej zna podstawy?
Zależy od tego, co konkretnie robił @MarekR22 i jak. Żeby się nie skończyło wałkowaniem pytaniami o rzeczy mocno specyficzne dla danego projektu :) IMO o takie rzeczy jest sens pytać najwyżej żeby sprawdzić, jak kandydat myśli, a nie zmuszać go do zgadywania co ktoś narzezał w swoim CI/CD, którego on na oczy nie widział.
Zgadzam się w dużej mierze z @WhiteLightning
- koszty w chmurze
- pipeline as code
- co by zawarł w takim pipeline CI/CD i dlaczego, w jakim celu
- rzeczy poza samym Jenkinsem (tudzież innym build serwerem)
- integracje z chmurą
- integracje z VCS, zależnie czego używacie np. githooki, status publishery itd.
- zarządzanie artefaktami (obrazy, binarki, RPMy, JARy czy co tam macie), wersjonowanie
- observability - logowanie, metryki, traceability, co powinny zawierać
- inne narzędzia których używacie lub byłyby użyteczne np. Terraform, Ansible, Sumologic, Grafana, Prometheus, Datadog, Artifactory, k8s, konkretne usługi w chmurze... tu już zależy co robicie
- skalowalność, jakie widzi możliwości, z czym by się wiązało np. wprowadzenie shardingu, a z czym replikacji, co by się stało gdyby wepchnąć jeszcze cache po drodze itp itd.
- dostępność usług, co by zrobił żeby zapewnić high availability, na co by patrzył, na jakich poziomach można by zapewnić redundancję itp
- różne przydatne komponenty i wzorce chmurowe np. sidecary, load balancery etc.
- jak by podszedł do tematu multi-tenancy (jeżeli was to dotyka), czy jakoś by to wpłynęło np. na jego odpowiedzi wyżej
- jak by podszedł do deploymentów, jakie by to miało wady / zalety (np. blue/green, canary, shadowing itp.)
- jeśli bawicie się w mikroserwisy (wymieniasz różne technologie i chmurę) to piłuj z tego do bólu, pytaj co by zrobił żeby ten proces CI/CD był bezbolesny, co robić a czego unikać
- bezpieczeństwo infrastruktury
- co by zrobił gdyby - i tu scenariusz gdzie coś się posypało w CI/CD, nie działa, coś jest flaky etc - jak z życia to nawet lepiej.
- jeśli ten DevOps miałby nie tylko opiekować się Waszymi procesami, ale np. też administracją Jenkinsa, to pewnie o te kwestie też trzeba będzie wypytać (np. zarządzanie uprawnieniami, worker nodami etc) - podobnie zresztą np. z zarządzaniem uprawnieniami w chmurze
EDIT: po namyśle, na tyle na ile możesz pilnuj też jakie ma podejście do ludzi którzy się nie znają, czy chętnie dzieli się wiedzą itd. Na dłuższą metę niby macie mieć to odrębne stanowisko devopsa w zespole, ale tak z moich obserwacji developerzy nieraz są jednak zdani na siebie, albo "opsowanie" rozkłada się na cały zespół (zresztą tak ma to chyba nawet wyglądać w metodyce DevOps).