Ερωτήσεις Συνέντευξης Full Stack Developer

Μπορεί να ανησυχείτε ότι μια διαδικασία full stack σημαίνει προετοιμασία δύο πλήρων συνεντεύξεων, frontend και backend, στον χρόνο που οι περισσότεροι υποψήφιοι αφιερώνουν σε μία. Αυτή η ανησυχία είναι λογική, και αυτή η ενότητα δείχνει γιατί το έργο είναι μικρότερο απ' ό,τι φαίνεται. Οι συνεντευκτές σπάνια επαναλαμβάνουν μια εξειδικευμένη διαδικασία frontend ή backend· εξετάζουν τα σημεία όπου συναντιούνται τα επίπεδα, γιατί εκεί οι full stack engineers κερδίζουν τον τίτλο τους.

Οι περισσότερες διαδικασίες συνδυάζουν τέσσερα είδη γύρων:

• Coding: ένα πρόβλημα δομών δεδομένων ή μια πρακτική εργασία όπως parsing, ομαδοποίηση, ή pagination εγγραφών, συχνά σε JavaScript, TypeScript, Python, ή Java.
• Κατασκευή ενός feature: μια μικρή end-to-end εργασία, όπως μια φόρμα που αποθηκεύει σε ένα API και εμφανίζει σφάλματα επικύρωσης, σε έναν κοινόχρηστο editor ή ένα take-home repository.
• Design σε όλο το stack: σχεδιάστε ένα feature όπως σχόλια ή ειδοποιήσεις, καλύπτοντας το schema, το API, το state του client, και τι συμβαίνει όταν αποτυγχάνει το δίκτυο.
• Συμπεριφορικό: η ιδιοκτησία ενός feature από το ticket μέχρι την παραγωγή, και ένα bug που κυνηγήσατε ανάμεσα στα επίπεδα.

Το επίπεδο-συγκεκριμένο βάθος εξακολουθεί να εμφανίζεται, και τα αφιερωμένα σύνολα, συμπεριλαμβανομένων ξεχωριστών σελίδων για frontend developer και backend developer, βρίσκονται στο hub ερωτήσεων συνέντευξης. Αυτή η σελίδα καλύπτει ό,τι βρίσκεται ανάμεσά τους.

Το API είναι το συμβόλαιο ανάμεσα στα δύο μισά της δουλειάς σας, οπότε οι συνεντευκτές ρωτούν γι' αυτό και από τις δύο πλευρές:

• Πώς θα σχεδιάζατε τα endpoints για ένα feature, και τι επιστρέφει το καθένα σε επιτυχία και σε αποτυχία;
• Πώς αλλάζετε ένα API χωρίς να σπάσετε clients που ήδη τρέχουν σε production; (Versioning, προσθετικές αλλαγές, παράθυρα deprecation.)
• Pagination με offset ή με cursor: ποιο θα χρησιμοποιούσατε για ένα activity feed, και γιατί;
• Πώς κάνετε ένα POST ασφαλές για επανάληψη αν ο client πάθει timeout; (Idempotency keys.)
• REST, GraphQL, ή RPC για έναν συγκεκριμένο client: τι αλλάζει στο caching, στο over-fetching, και στη διαχείριση σφαλμάτων;
• Πού ζει η επικύρωση, στον client, στον server, ή και στους δύο, και ποια είναι η κύρια;
• Πώς αποφεύγετε ένα ερώτημα N+1 όταν ένα endpoint list επιστρέφει ένθετα δεδομένα;

Μια δυνατή απάντηση κατονομάζει το trade-off, όχι μόνο την επιλογή. "Cursor pagination, γιατί γραμμές που εισάγονται καθώς ο χρήστης κάνει scroll θα μετατόπιζαν ένα offset και θα διπλασίαζαν στοιχεία" είναι καλύτερο από το να απαριθμήσετε και τις δύο επιλογές και να σταματήσετε εκεί.

Δύο τύποι ερωτήσεων ξεχωρίζουν τους υποψήφιους full stack από τους ειδικούς. Ο πρώτος είναι η αυθεντικοποίηση από άκρη σε άκρη: περιγράψτε τι συμβαίνει από τη στιγμή που ένας χρήστης υποβάλλει μια φόρμα login μέχρι τη στιγμή που μια authenticated κλήση API πετυχαίνει. Οι συνεντευκτές προσέχουν πού ζει το credential (ένα cookie ή client storage), πώς το ελέγχει ο server, γιατί ένα HttpOnly cookie αντιστέκεται στην πρόσβαση από script, τι προστασία CSRF χρειάζεται μια session βασισμένη σε cookie, πώς επηρεάζει το CORS ένα front end σε διαφορετικό origin, και πώς αντιμετωπίζονται το logout και η λήξη του token.

Ο δεύτερος είναι η ιχνηλάτηση: "Ένας χρήστης κάνει κλικ στο Save και δεν συμβαίνει τίποτα. Περιγράψτε μου πώς θα το κάνατε debug." Μια καλή απάντηση κινείται επίπεδο προς επίπεδο, από την κονσόλα του browser και την καρτέλα network, στο request και response, στα logs του server, στην εγγραφή στη βάση δεδομένων, αντί να μαντεύει.

Μια full stack developer που δίνει συνέντευξη σε μια μεσαίου μεγέθους εταιρεία SaaS είναι μια τυπική περίπτωση. Όταν ρωτήθηκε πώς θα λειτουργούσε ένα feature σχολίων, ξεκίνησε από τον πίνακα (σχόλια με ένα post ID, ένα author ID, και timestamps, indexed ανά post), όρισε το endpoint list με cursor pagination, περιέγραψε optimistic rendering στον client με ένα rollback αν το POST απέτυχε, και έκλεισε με το πώς θα εμπόδιζε ένα διπλό κλικ να κάνει post δύο φορές. Κράτησε κάθε επίπεδο σύντομο, και οι follow-up ερωτήσεις του συνεντευκτή πήγαν κατευθείαν στα σημεία επαφής που είχε κατονομάσει.

Εξασκηθείτε στην ιχνηλάτηση φωναχτά. Επιλέξτε ένα feature από μια εφαρμογή που χρησιμοποιείτε καθημερινά και εξηγήστε το από το schema μέχρι την οθόνη, μετά κάντε το ξανά προσθέτοντας μια αστοχία: το API είναι αργό, η εγγραφή πετυχαίνει μερικώς, ο χρήστης αποσυνδέεται στη μέση του request. Ηχογραφηθείτε, ή τρέξτε τις ερωτήσεις σε ένα AI mock interview, που κάνει follow-up ερωτήσεις με βάση τις προφορικές απαντήσεις σας.

Σε live γύρους, η εφαρμογή desktop του SubcueAI για macOS και Windows μπορεί να μεταγράφει τον συνεντευκτή και να προτείνει μια δομή για απαντήσεις design και συμπεριφοράς όπου οι κανόνες της συνέντευξης επιτρέπουν βοήθεια· η επέκταση Chrome/Edge καλύπτει κλήσεις σε καρτέλα browser, και η εφαρμογή iPhone ακούει μια κλήση που παίζει σε άλλη συσκευή. Το τίμιο όριο μετράει περισσότερο στις διαδικασίες full stack: οι γύροι κατασκευής feature και coding γίνονται συχνά σε ένα shared screen, και οτιδήποτε βρίσκεται σε ένα shared screen είναι ορατό, οπότε η βοήθεια είναι εκτός εμβέλειας εκεί. Τα proctored online τεστ και οι συσκευές που διαχειρίζεται η εταιρεία είναι επίσης εκτός εμβέλειας. Η ρύθμιση βρίσκεται στο tutorial.