Podczas wywiadu zadaję podstawowe pytania dotyczące projektowania baz danych. Normalizacja (kiedy-dlaczego) jest jednym z moich problemów, jeśli chodzi o projektowanie baz danych. Niektóre scenariusze I strona, która obejmuje zsynchronizowane serwery i co / dlaczego / jak biorą pod uwagę powiązane problemy; problemy bezpieczeństwa i tak dalej.
- Czy zapytałbyś ich w kontekście konkretnego systemu baz danych (np. Oracle), który wolą?
- Jakie pytania techniczne byś im zadał?
- Jakie scenariusze umieściłbyś na stronie i czego szukałbyś jako odpowiedzi na te scenariusze?
- Jak dowiesz się, czy mają wiedzę na temat rozwiązywania problemów związanych z bezpieczeństwem?
- Inne powiązane pytania. (np. DB Restore / Backup)
Dziękuję Ci.
database
database-administration
Zrodzony ze smoka
źródło
źródło
W moim zespole ds. Oprogramowania w ramach wywiadu testujemy zrozumienie baz danych.
Prezentujemy - bardzo kiepski projekt (pomyśl aplikację typu CRM) i prosimy o ulepszenie projektu, po około 30 minutach namysłu.
Następnie zadajemy im więcej pytań w oparciu o to, o czym mówią.
Próbujemy zrozumieć
Jako zespół zastanawialiśmy się wtedy nad odpowiedziami na tego typu pytania, które uznalibyśmy za Junior / Senior / Architect.
So for - Performance v Normisalation -
zobaczy przede wszystkim ten problem i będzie mógł omówić, dlaczego (Junior)
poleciłby 4/5 NF, ale zrozumiałby problem z wydajnością, czy zdenormalizowałby i zrozumiałby, jak wyrazić problem (Senior)
czy zaleciliby inny rodzaj projektu, np. schemat gwiazd i omawiali implikacje na wielu poziomach (Architekt)
Widziałby, że integralność referencyjna jest potrzebna do egzekwowania relacji danych i byłaby w stanie to omówić, ale nie dostrzegłaby problemu z Key Choice and Design (Junior)
Omówiłby kwestie związane z wolumenami danych i typami danych v szukającymi naturalnych kluczy w danych i byłby w stanie przedyskutować, dlaczego na nie patrzą - oraz problemy, które wynikają z integralnością referencyjną (Senior)
Może argumentować różne punkty widzenia związane z kluczami i integralnością i być w stanie wymyślić różne rzeczywiste modele do szybkiego projektowania (Architekt)
Dostajesz obraz.
Jeśli chcesz, żebym dodał więcej, dodaj komentarz i opisz szczegółowo, co myślimy o reszcie, ale po prostu uwzględniłem pierwsze dwa, aby dać ci wyobrażenie o tym, co myśleliśmy.
Chodzi o to, aby pomyśleć o 1. pytaniach 2. My, jako zespół , zastanawialiśmy się wtedy, co uważamy za odpowiedzi typu Junior / Senior / Architect na tego typu pytania.
Podkreślam, że zespół jako kandydat i zespół muszą być pewni umiejętności osoby wchodzącej, a jeśli wymyślą to, co postrzegają jako odpowiedzi na różne poziomy, osoba wchodząca będzie, mam nadzieję, lepiej pasować do zespołu. Daje także zespołowi możliwość wpływania na wybór kandydata. Wyznaczają również osobę, która będzie zasiadać w panelu pytań. Bardzo pomaga przy wpisowym do zespołu.
źródło
Możesz stworzyć fikcyjną bazę danych, w której było kilka problemów z normalizacją, potencjalne usterki bezpieczeństwa, ale ogólnie rzecz biorąc wygląda to dość typowo, jak baza danych pracowników. Następnie możesz zacząć od zadawania rozmówcy prostych pytań, takich jak uzyskanie pewnych danych w bazie danych za pomocą połączeń, pracując nad trudniejszymi pytaniami dotyczącymi normalizacji i bezpieczeństwa.
źródło
Zobacz Smart and Gets Things Done
... i zapytaj ich, jakie książki ostatnio czytają, jakie blogi czytają i jakich podcastów słuchają. I zapytaj, czy uczestniczą w stackoverflow.com i serverfault.com ;-)
źródło
To niekoniecznie jest związane z bazą danych, ale rzeczy, które lubię dodawać do wywiadu, to praktyczne rozwiązywanie problemów i scenariusz projektowy.
W przypadku problemu praktycznego należy mieć system lub systemy, do których dana osoba może uzyskać dostęp, i poprosić ich o rozwiązanie problemu otwartego. Moimi osobistymi ulubionymi tutaj są problemy z wydajnością, ponieważ niekoniecznie jest to coś, co można odtworzyć na żądanie w celu przeprowadzenia wywiadu i rzadko jest jedna poprawna odpowiedź. Zamiast tego możesz obserwować, jak kandydat przechodzi przez proces rozwiązywania problemów, a także będzie musiał otworzyć z tobą dyskusję, aby uzyskać dodatkowe informacje na temat środowiska. Kluczem do sukcesu jest, aby osoba przeprowadzająca wywiad była szczera w kwestii problemu, a nie zamieniała scenariusz w polowanie na jajka wielkanocne dla jednego źle skonfigurowanego ustawienia lub coś w tym rodzaju.
W scenariuszu projektowym przedstawiam kandydatowi ogólny zarys nowego projektu (tj. Brak zależności od starszych wersji) i proszę o wymyślenie ogólnego projektu w ich konkretnym obszarze (DBA, systemów lub sieci), który spełnia cele projektu. Kluczem jest utrzymanie projektu na tyle małym, aby ktoś mógł zachować cały scenariusz w głowie, a wyjaśnienie nie zajmuje więcej niż kilka minut.
Przykładem, którego używam tutaj dla moich systemów i pracowników sieci, jest opisanie ich projektu dla małego oddziału, który jest tworzony, biorąc pod uwagę pewne ograniczenia naszej działalności. Po stronie DBA, może użyj małej / oczywistej aplikacji CRUD. W obu przypadkach nie szukasz szczegółowego projektu, ale bardziej ogólny przegląd i sprawdź, czy kandydat szuka typowych problemów, które się pojawiają.
Ważnym punktem dla obu tych scenariuszy jest otwarcie dyskusji na ten temat i umożliwienie kandydatowi poprowadzenia dyskusji własnymi pytaniami. Powinno być jasne, że nie pytasz o dokładną odpowiedź na którekolwiek z nich.
Jak możesz sobie zobrazować, bardzo nie lubię ciekawostek podczas wywiadów i myślę, że to pozwala mi na głębsze zrozumienie umiejętności kandydatów.
źródło
pozwól jej mówić. zapytaj o wcześniejsze doświadczenia, zapytaj, jakie problemy napotkał i jak sobie poradzili. jaka była motywacja do wyboru tego lub innego rozwiązania typowych problemów [backup? monitorowanie? skalowanie, skalowanie, bezpieczeństwo].
myślę, że możesz wiele powiedzieć o tej osobie, po prostu słuchając.
niestety, jeśli szukasz specjalistycznej wiedzy w danej dziedzinie, zadaj szczegółowe pytania - sugestia Stefana Thyberga jest bardzo dobra.
źródło