Ja zwykle pytam o to mniej więcej:
skąd wiadomo co robić i jak? kto o tym decyduje i w jaki sposób jest podejmowana decyzja? (czyli pytanie o metodykę pracy, scrumy, planowania, waterfalle itp. niestety to pytanie trzeba drążyć, bo np. ktoś może powiedzieć "pracujemy w SCRUM" (a SCRUM jest buzzwordem, pod którym równie dobrze może się kryć waterfall ze spotkaniami na stojąco...) czy "nie mamy jednej metody" .
Albo może sam nie wiem, o co pytam. Po prostu zauważyłem, że już samo tworzenie tasków, i wrzucanie ich do issue trackera ma często o wiele większy wpływ na projekt, niż samo programowanie (programista jest często pionkiem w rękach PMów). Dlatego takie pytanie jest dla mnie ważniejsze od "w jakich technologiach pracujecie?" (to pytanie też zadaję, ale wraz z doświadczeniem zaczyna ono tracić na znaczeniu - bo technologie technologiami, ale w firmach i tak najważniejszy jest management, polityka).
No i oczywiście (zakładając, że rozmawiam z programistami) pytam o stan projektu, jakość kodu, czy są testy, próbuję wybadać podejście ludzi pracujących w danej firmie do programowania (rzucając też pewne swoje poglądy, podejmując jakąś dyskusję). I tu też - technologie, technologiami, ale ważniejsze jest podejście (co z tego, że apka będzie na React, jeśli będzie brzydki kod?). Niestety oczywiście trzeba się liczyć, że wszystko to, co powiedzą ci o kodzie na rozmowach będzie super optymistyczne (nikt raczej nie powie potencjalnemu kandydatowi, że mają w firmie spaghetti kod albo przeinżynierowaną kobyłę).