Technical Interview Prep: Πώς να Διαβάσεις Σωστά

Περιεχόμενα

Η Φιλοσοφία της Τεχνικής Συνέντευξης: Γιατί δεν είναι απλή εξέταση

Πολλοί υποψήφιοι προσεγγίζουν την τεχνική συνέντευξη σαν ένα διαγώνισμα στο πανεπιστήμιο, όπου η μόνη σημασία έχει η σωστή απάντηση. Στην πραγματικότητα, η διαδικασία αυτή είναι μια προσομοίωση της καθημερινής εργασίας. Οι recruiters και οι senior developers δεν ψάχνουν για μια "κινητή εγκυκλοπαίδεια", αλλά για έναν συνεργάτη που μπορεί να διαχειριστεί την αβεβαιότητα.

Όταν σου δίνεται ένα πρόβλημα, ο interviewer θέλει να δει:

• Πώς αντιδράς όταν δεν γνωρίζεις τη λύση αμέσως: Κολλάς ή ζητάς βοήθεια;
• Πώς αναλύεις τις απαιτήσεις: Ρωτάς διευκρινιστικές ερωτήσεις ή υποθέτεις;
• Πώς σπας ένα σύνθετο ζήτημα: Σε μικρότερα, διαχειρίσιμα κομμάτια;
• Αν δέχεσαι feedback: Μπορείς να αλλάξεις κατεύθυνση αν σου δοθεί hint;

Η αποτυχία πολλών υποψηφίων δεν οφείλεται στην έλλειψη γνώσεων, αλλά στο γεγονός ότι "παγώνουν" ή προσπαθούν να λύσουν το πρόβλημα σιωπηλά, στερώντας από την εταιρεία τη δυνατότητα να κατανοήσει τον τρόπο σκέψης τους.

Τι Αξιολογούν Πραγματικά οι Εταιρείες σε Junior και Mid Developers

Οι απαιτήσεις διαφοροποιούνται σημαντικά ανάλογα με το επίπεδο της θέσης.

Για Junior Developers:

Η έμφαση δίνεται στα θεμέλια. Η εταιρεία θέλει να βεβαιωθεί ότι:

• Κατέχεις τις βασικές δομές δεδομένων (arrays, strings, hashmaps)
• Γράφεις κώδικα που είναι ευανάγνωστος και σωστά δομημένος
• Έχεις τη διάθεση να μάθεις και να δεχτείς feedback
• Μπορείς να λύσεις απλά προβλήματα με λογική

Δεν περιμένουν να ξέρεις πώς να στήσεις μια ολόκληρη υποδομή στο cloud, αλλά περιμένουν να ξέρεις πώς λειτουργεί ένα array, ένα loop ή μια βασική SQL query.

Για Mid-level Developers:

Η αξιολόγηση μετατοπίζεται στο impact και στα trade-offs. Εδώ δεν αρκεί να δώσεις μια λύση που "δουλεύει". Πρέπει να είσαι σε θέση να εξηγήσεις:

• Γιατί επέλεξες τη συγκεκριμένη προσέγγιση έναντι μιας άλλης
• Ποια είναι τα trade-offs (π.χ. memory vs speed)
• Πώς θα κλιμακώνονταν η λύση σε μεγαλύτερα δεδομένα
• Πώς θα συντηρούσες τον κώδικα μακροπρόθεσμα

Η ικανότητα να συζητάς για την απόδοση (performance) και τη συντηρησιμότητα (maintainability) του κώδικα είναι αυτό που ξεχωρίζει έναν έμπειρο προγραμματιστή.

Η Στρατηγική των Τριών Φάσεων: Από τη Θεωρία στην Πράξη

Για να αποφύγεις το burnout, το διάβασμά σου πρέπει να είναι δομημένο σε τρεις διακριτές φάσεις:

Φάση A - Foundations (20% του χρόνου)

Εδώ φρεσκάρεις τις βασικές έννοιες. Δεν χρειάζεται να είσαι expert, αλλά πρέπει να νιώθεις άνετα:

• Σύνταξη της γλώσσας προγραμματισμού που χρησιμοποιείς
• Βασικές δομές δεδομένων (arrays, linked lists, stacks, queues)
• Έννοιες όπως loops, recursion, conditionals
• Big-O notation (όχι μαθηματικά, αλλά πρακτικά)

Αυτή η φάση χτίζει την αυτοπεποίθησή σου ώστε να μην κολλάς στη σύνταξη κατά τη διάρκεια της συνέντευξης.

Φάση B - Practice (70% του χρόνου)

Αυτή είναι η πιο κρίσιμη φάση. Η θεωρία μετατρέπεται σε πράξη. Αντί να διαβάζεις λύσεις άλλων, πρέπει να λερώσεις τα χέρια σου γράφοντας κώδικα. Η εστίαση πρέπει να είναι στην επίλυση προβλημάτων με συγκεκριμένα patterns:

• Two pointers
• Sliding window
• Hashing
• Tree/Graph traversal
• Dynamic programming (βασικά)

Στόχευσε 40-60 καλές λύσεις, όχι 300 επιφανειακές.

*Αν νιώθεις ότι η "Φάση B - Practice" σε δυσκολεύει ή δεν ξέρεις από πού να ξεκινήσεις, στην έχουμε σχεδιάσει το Web Development Bootcamp ακριβώς πάνω σε αυτή τη λογική. Εκπαιδεύεσαι στο να γράφεις clean code και να σκέφτεσαι σαν επαγγελματίας developer από την πρώτη μέρα.

Φάση C - Polish (10% του χρόνου)

Εδώ επικεντρώνεσαι στην ταχύτητα, την καθαρότητα του κώδικα και την επικοινωνία. Είναι η φάση της "τελικής πρόβας" πριν βγεις στην αγορά εργασίας.

Κατακτώντας τα Data Structures & Algorithms χωρίς Παπαγαλία

Η παπαγαλία αλγορίθμων είναι η σίγουρη συνταγή για αποτυχία. Αν ο interviewer αλλάξει μια μικρή λεπτομέρεια στο πρόβλημα, ο υποψήφιος που έχει απομνημονεύσει τη λύση θα καταρρεύσει. Η σωστή προσέγγιση είναι η κατανόηση της χρησιμότητας κάθε δομής.

Τι πρέπει να γνωρίζεις:

• Arrays & Strings - Πώς να τα διατρέχεις, πώς να τα τροποποιείς, πώς να βρίσκεις patterns
• HashMaps/Sets - Πότε ένα HashMap μειώνει τον χρόνο εκτέλεσης από O(n2) σε O(n)
• Stacks & Queues - Πώς να διαχειρίζεσαι nested δεδομένα ή FIFO/LIFO λογική
• Trees - DFS/BFS, recursion, binary search trees
• Graphs - Βασικές έννοιες connectivity και traversal
• Sorting & Binary Search - Πότε χρησιμοποιούνται και γιατί

Μάθε να υπολογίζεις το Big-O complexity όχι ως μαθηματικό τύπο, αλλά ως εργαλείο λήψης αποφάσεων. Όταν γράφεις μια λύση, αναρωτήσου: "Μπορώ να το κάνω πιο γρήγορα; Τι θα γινόταν αν τα δεδομένα μου ήταν εκατομμύρια εγγραφές;".

Η Τέχνη του Problem Solving: Patterns που Επαναλαμβάνονται

Τα περισσότερα προβλήματα κώδικα στις συνεντεύξεις βασίζονται σε συγκεκριμένα μοτίβα (patterns). Αν μάθεις να αναγνωρίζεις αυτά τα μοτίβα, θα μπορείς να λύσεις προβλήματα που δεν έχεις ξαναδεί.

Τα κύρια patterns που πέφτουν συχνά:

1. Two Pointers: Χρησιμοποιείται σε ταξινομημένα arrays (π.χ. "βρες δύο αριθμούς που αθροίζονται σε target")
2. Sliding Window: Για προβλήματα με subarrays ή substrings (π.χ. "βρες το μεγαλύτερο substring χωρίς επαναλαμβανόμενους χαρακτήρες")
3. Hashing / Frequency Maps: Για προβλήματα που αφορούν duplicates ή frequency (π.χ. "βρες τον πιο συχνό χαρακτήρα")
4. Stack for Monotonic: Για προβλήματα με nested δεδομένα (π.χ. "έγκυρες παρενθέσεις")
5. Binary Search: Όχι μόνο σε ταξινομημένα arrays, αλλά και σε "answer space" (π.χ. "βρες το ελάχιστο χρόνο για να ολοκληρωθεί μια εργασία")
6. Tree/Graph Traversal: DFS και BFS για διάφορα προβλήματα
7. Dynamic Programming (Basics): Για προβλήματα με overlapping subproblems (π.χ. climbing stairs, coin change)

Αντί να προσπαθείς να λύσεις 500 τυχαία προβλήματα, διάλεξε 50-60 προβλήματα που καλύπτουν όλα τα βασικά patterns. Μελέτησε πώς εφαρμόζεται το καθένα και προσπάθησε να εντοπίσεις τις ομοιότητες μεταξύ διαφορετικών ασκήσεων. Αυτή η "μετα-γνώση" είναι που θα σε κάνει να νιώθεις άνετα σε οποιαδήποτε τεχνική πρόκληση σου τεθεί.

System Design: Πώς να Σχεδιάζεις Συστήματα που Αντέχουν

Το System Design συχνά τρομάζει τους υποψηφίους, αλλά για επίπεδα Junior/Mid, οι απαιτήσεις είναι λογικές. Δεν περιμένει κανείς να σχεδιάσεις το επόμενο Netflix σε 40 λεπτά. Αυτό που αναζητούν είναι η ικανότητα να σκέφτεσαι σε επίπεδο αρχιτεκτονικής.

Τυπικές ερωτήσεις System Design:

• "Πώς θα σχεδίαζες ένα URL shortener;"
• "Πώς θα έστηνες ένα REST API για bookings;"
• "Πώς θα αποθήκευες και θα παρουσίαζες images;"
• "Πώς θα χειριζόσουν το σύστημα 1 εκατομμύριο ταυτόχρονες συνδέσεις;"

Το framework απάντησης (απλό και αποτελεσματικό):

1. Requirements -> Ρώτα για functional (τι κάνει) και non-functional (πόσο γρήγορα, πόσο αξιόπιστα)
2. Data Model -> Σχεδίασε τις entities και τις σχέσεις τους
3. API Endpoints -> Γράψε τα κύρια endpoints (GET, POST, PUT, DELETE)
4. High-level Architecture -> Σχεδίασε τα κύρια components (Load Balancers, API Servers, Databases, Cache)
5. Scaling Considerations -> Πώς θα χειρίζονταν το σύστημα περισσότερα δεδομένα (caching, pagination, rate limits)
6. Failure Modes -> Τι συμβαίνει αν κάτι σπάσει (timeouts, retries, monitoring)

Δεν χρειάζεται να πας σε "Kubernetes λεπτομέρειες", εκτός αν είναι DevOps role. Η συζήτηση γύρω από το System Design είναι μια ευκαιρία να δείξεις ότι κατανοείς έννοιες όπως το latency, το throughput και το availability, ακόμα και αν δεν έχεις δουλέψει με τεράστια συστήματα στην πράξη.

Εξειδικευμένες Γνώσεις: Τι πρέπει να ξέρεις για Frontend και Backend

Πέρα από τους αλγορίθμους, θα ερωτηθείς για το συγκεκριμένο stack σου.

Αν είσαι Frontend Developer:

Πρέπει να γνωρίζεις σε βάθος:

• Πώς λειτουργεί ο browser (rendering, reflow, repaint)
• DOM manipulation και event handling
• CSS specificity και layout (flexbox, grid)
• State management και component lifecycle
• Performance optimization (memoization, lazy loading, code splitting)
• Accessibility basics (ARIA, semantic HTML)
• HTTP requests, caching, CORS

Θέματα όπως το state management, το component lifecycle και το performance optimization είναι σχεδόν βέβαιο ότι θα συζητηθούν.

Αν είσαι Backend Developer:

Η έμφαση δίνεται στην ασφάλεια, τη διαχείριση δεδομένων και την επικοινωνία μεταξύ υπηρεσιών:

• Authentication (JWT, OAuth, sessions)
• Authorization και permissions
• RESTful API design conventions
• Database optimization (indexes, query optimization)
• SQL joins, transactions, normalization
• Caching strategies (Redis, memcached)
• Testing (unit, integration, end-to-end)
• Logging και monitoring

Πρέπει να μπορείς να εξηγήσεις πώς λειτουργεί το authentication, πώς σχεδιάζεις ένα σωστό RESTful API και πώς βελτιστοποιείς queries σε μια βάση δεδομένων χρησιμοποιώντας indexes. Η γνώση γύρω από το testing θεωρείται πλέον αυτονόητη και απαραίτητη.

Η Σημασία της Επικοινωνίας: Γιατί ο Κώδικας δεν Φτάνει από Μόνος του

Μπορεί να δώσεις την πιο βέλτιστη λύση, αλλά αν την έδωσες χωρίς να πεις λέξη, μπορεί να μην πάρεις τη δουλειά. Η τεχνική συνέντευξη είναι μια "δυνατή σκέψη" (think aloud). Ο interviewer θέλει να ακούει τις υποθέσεις σου, τους δισταγμούς σου και τις διορθώσεις που κάνεις στην πορεία. Αυτό δείχνει ότι είσαι συνεργάσιμος και ότι μπορείς να εξηγήσεις τεχνικά θέματα σε άλλους.

Πώς να επικοινωνείς αποτελεσματικά:

• Ξεκίνα με clarifying questions - "Υπάρχουν αρνητικοί αριθμοί;", "Είναι το array ταξινομημένο;", "Τι επιστρέφουμε αν το input είναι κενό;"
• Περίγραψε τη λύση σε υψηλό επίπεδο πριν γράψεις κώδικα - "Σκέφτομαι να χρησιμοποιήσω ένα HashMap για να αποθηκεύσω τις τιμές και να τις αναζητώ σε O(1) χρόνο. Τι λέτε για αυτή την προσέγγιση;"
• Εξήγησε τις επιλογές σου - "Επέλεξα αυτή τη δομή δεδομένων επειδή..."
• Αποδέξου το feedback - Αν ο interviewer σου δώσει ένα hint, δεν είναι αποτυχία. Είναι ευκαιρία να δείξεις ότι μπορείς να προσαρμοστείς.
• Σκέψου δυνατά - "Τώρα θα κάνω ένα test με αυτό το παράδειγμα για να δω αν δουλεύει..."

Τα Συνηθέστερα Λάθη και πώς να τα Μετατρέψεις σε Πλεονεκτήματα

Λάθος 1: Βιασύνη να ξεκινήσεις κώδικα

Πολλοί υποψήφιοι ξεκινούν να γράφουν κώδικα πριν καταλάβουν πλήρως το πρόβλημα. Με αποτέλεσμα να ανακαλύπτουν edge cases στη μέση της διαδικασίας και να πρέπει να σβήσουν τα πάντα.

Λύση: Πάντα να ρωτάς διευκρινιστικές ερωτήσεις στην αρχή. Αφιέρωσε 5 λεπτά για να κατανοήσεις το πρόβλημα πριν ξεκινήσεις.

Λάθος 2: Παράλειψη των tests

Δεν περιμένεις από τον interviewer να σου πει αν ο κώδικάς σου είναι σωστός. Πάρε ένα μικρό παράδειγμα και "τρέξε" το με το χέρι μέσα από τις γραμμές του κώδικά σου.

Λύση: Κάνε 2-3 manual tests πριν πεις "done". Αυτό δείχνει επαγγελματισμό και προσοχή στη λεπτομέρεια.

Λάθος 3: Σιωπή και απομόνωση

Ο interviewer δεν μπορεί να δει τι σκέφτεσαι αν δεν μιλάς. Σιωπή = red flag.

Λύση: Μίλα συνεχώς. "Θα ξεκινήσω με brute force για να επιβεβαιώσω...", "Αυτό είναι O(n²), μπορούμε να το κάνουμε O(n) με hashmap..."

Λάθος 4: Παπαγαλία λύσεων

Αν έχεις απομνημονεύσει τη λύση και ο interviewer αλλάξει λίγο το πρόβλημα, θα κολλήσεις.

Λύση: Μάθε patterns, όχι λύσεις. Κατανόησε γιατί δουλεύει κάθε προσέγγιση.

Λάθος 5: Κώδικας χωρίς δομή

Ο κώδικας που γράφεις πρέπει να είναι καθαρός και ευανάγνωστος.

Λύση: Χρησιμοποίησε σαφή ονόματα μεταβλητών, σχόλια όπου χρειάζεται, και σωστή indentation.

Ένα Ρεαλιστικό Πλάνο Προετοιμασίας 14 και 30 Ημερών

Πλάνο 14 Ημερών (2 ώρες/ημέρα):

Αν έχεις λίγο χρόνο, πρέπει να είσαι πολύ επιλεκτικός:

• Ημέρες 1-3: Foundations: Arrays, Strings, HashMaps (6-8 προβλήματα)
• Ημέρες 4-6: Sliding Window & Two Pointers: (6-8 προβλήματα)
• Ημέρες 7-9: Stack/Queue & BFS/DFS Basics: (6-8 προβλήματα)
• Ημέρες 10-11: Trees Basics: (4-6 προβλήματα)
• Ημέρα 12: Timed Session: Λύσε 2 προβλήματα με χρονόμετρο
• Ημέρα 13: Review & Cheat Sheet: Κράτα σημειώσεις για τα patterns
• Ημέρα 14: Final Polish: Ξεκουράσου και προετοιμάσου ψυχολογικά

Μην προσπαθήσεις να μάθεις νέα, δύσκολα θέματα την τελευταία στιγμή.

Πλάνο 30 Ημερών (1.5-2.5 ώρες/ημέρα):

Με περισσότερο χρόνο, μπορείς να ακολουθήσεις μια πιο ολοκληρωμένη διαδρομή:

• Εβδομάδα 1: Foundations - Βασικές δομές δεδομένων, Big-O, σύνταξη
• Εβδομάδα 2: Easy/Medium Problems - Arrays, Strings, HashMaps (15-20 προβλήματα)
• Εβδομάδα 3: Patterns - Stacks, Queues, Trees, Graphs (15-20 προβλήματα)
• Εβδομάδα 4: Advanced & System Design - Binary Search, DP basics, System Design scenarios

Γενικές συμβουλές:

• Η συνέπεια (π.χ. 2 ώρες κάθε μέρα) είναι πολύ πιο αποτελεσματική από το να διαβάζεις 10 ώρες μόνο τα Σαββατοκύριακα.
• 1 μέρα/εβδομάδα "active rest" (review notes, όχι νέα problems).
• Κράτα ένα "error log" - λίστα επαναλαμβανόμενων λαθών που κάνεις.

Τελικό Checklist και Συμπεράσματα

Πριν τη Συνέντευξη:

• Έχω σταθερό internet + ήσυχο χώρο
• Έχω έτοιμο editor / IDE / environment
• Έχω νερό και χαρτί για σκίτσα
• Έχω κάνει 2-3 timed sessions τις τελευταίες ημέρες
• Έχω ξεκουραστεί καλά τη νύχτα πριν
• Γνωρίζω λίγα πράγματα για την εταιρεία

Κατά τη Διάρκεια της Συνέντευξης:

• Ρωτάω clarifying questions
• Περιγράφω τη λύση πριν γράψω κώδικα
• Λέω τη σκέψη μου δυνατά
• Κάνω tests πριν πω "done"
• Αν κολλήσω >2-3 λεπτά, ζητάω hint
• Δεν πανικοβάλλομαι αν δεν ξέρω κάτι

Μετά τη Συνέντευξη:

• Σημειώνω τι με δυσκόλεψε
• Ζητάω feedback αν είναι δυνατόν
• Δεν κάνω "post-mortem" που με κατακρεουργεί

Συμπέρασμα

Η επιτυχία σε μια τεχνική συνέντευξη είναι ένας συνδυασμός τεχνικής κατάρτισης, ψυχολογικής προετοιμασίας και επικοινωνιακών δεξιοτήτων. Δεν είναι τύχη. Είναι αποτέλεσμα σωστής προετοιμασίας.

Οργάνωσε το διάβασμά σου σε τρεις φάσεις, εστίασε στα patterns και μην ξεχνάς να εξασκείς τη "φωνητική" επίλυση προβλημάτων. Με τη σωστή προετοιμασία, η τεχνική συνέντευξη παύει να είναι ένα εμπόδιο και γίνεται η ευκαιρία σου να δείξεις την αξία σου ως επαγγελματίας.

Ξεκίνησε σήμερα. Δεν χρειάζεται τέλεια προετοιμασία, χρειάζεται συνεπή προετοιμασία.