Τεχνική συνέντευξη στην ανάπτυξη εφαρμογών για κινητά: ουσία διεξαγωγής, στάδια και προετοιμασία

Τι είναι η τεχνική συνέντευξη στην Πληροφορική;

Τεχνική συνέντευξη — μια δομημένη διαδικασία αξιολόγησης επαγγελματικών ικανοτήτων προγραμματιστή, που περιλαμβάνει έλεγχο hard skills (τεχνικές γνώσεις) και soft skills (επικοινωνία, ομαδική εργασία). Ο τυπικός κύκλος συνέντευξης προγραμματιστή κινητών διαρκεί 3-5 γύρους με συνολική διάρκεια 4-6 ώρες. Το ποσοστό επιτυχούς διέλευσης από τον αριθμό αρχικών απαντήσεων είναι 2-5% σε μεγάλες εταιρείες τεχνολογίας.

Η διαδικασία πρόσληψης στην ανάπτυξη εφαρμογών κινητών διαφέρει από την ανάπτυξη ιστού: προστίθενται ερωτήσεις σχετικά με τις ιδιαιτερότητες της πλατφόρμας — κύκλος ζωής Activity/Fragment, ARC και διαχείριση μνήμης σε Swift, μοντέλα threading (Main Thread, Dispatch Queue, Coroutines), εργασία με αιτήματα δικτύου και προσωρινή αποθήκευση δεδομένων. Προγραμματιστής Android πρέπει να γνωρίζει Jetpack Compose, Room, WorkManager, Dagger/Hilt. Προγραμματιστής iOS — SwiftUI, Core Data, Combine, URLSession. Η διαφορά στις απαιτήσεις αυξάνεται με την εμπειρία: για θέσεις Senior προστίθεται σχεδιασμός συστήματος και αρχιτεκτονική ολόκληρης της εφαρμογής.

Η δομή της συνέντευξης εξαρτάται από το επίπεδο. Για θέσεις Junior αρκεί βασική γνώση γλώσσας και πλατφόρμας (1-2 γύροι). Προγραμματιστής Middle περνά 2-3 γύρους με μπλοκ αλγορίθμων. Senior συνέντευξη περιλαμβάνει 4-5 γύρους: αλγορίθμους, αρχιτεκτονική εφαρμογής κινητού, σχεδιασμό συστήματος, συμπεριφορική συνέντευξη και τελική συνέντευξη με VPE (Vice President of Engineering) ή CTO.

Στάδια τεχνικής συνέντευξης

HR screening — πρώτο στάδιο διάρκειας 20-30 λεπτών. Ο υπεύθυνος προσλήψεων ελέγχει την αντιστοιχία εμπειρίας με τις απαιτήσεις της θέσης, συζητά συνθήκες εργασίας, μισθολογικές προσδοκίες και κίνητρα υποψηφίου. Σε αυτό το στάδιο είναι σημαντικό να διατυπώσετε καθαρά την εμπειρία σας: έργα, στοίβα τεχνολογιών, επιτεύγματα σε μετρήσεις (μείωση χρόνου φόρτωσης, μείωση ποσοστού crash, επιτάχυνση μεταγλώττισης). Το HR screening δεν ελέγχει τεχνικές γνώσεις, αλλά αποκλείει έως και 40% των υποψηφίων λόγω μη συμμόρφωσης με τυπικές απαιτήσεις.

Μετά το screening ακολουθεί αλγοριθμική συνέντευξη — το κλειδί για τις περισσότερες εταιρείες. Διάρκεια — 45-90 λεπτά. Ο υποψήφιος λαμβάνει 1-2 εργασίες σε αλγορίθμους και δομές δεδομένων. Η λύση γράφεται σε online πίνακα (Codility, HackerRank, CoderPad) ή σε χαρτί. Αξιολογείται όχι μόνο η ορθότητα, αλλά και η ταχύτητα σκέψης, η ικανότητα υποβολής διευκρινιστικών ερωτήσεων και βελτιστοποίησης λύσης. Σύμφωνα με το interviewing.io (2025), το 73% των υποψηφίων αποτυγχάνει ακριβώς στο αλγοριθμικό στάδιο.

Αρχιτεκτονική συνέντευξη

Αρχιτεκτονικός γύρος ελέγχει την ικανότητα σχεδιασμού εφαρμογών κινητών. Στον υποψήφιο προτείνεται να σχεδιάσει μια εφαρμογή (λίστα TODO, messenger, συγκεντρωτής ειδήσεων, υπηρεσία ροής). Αξιολογείται η επιλογή αρχιτεκτονικού μοτίβου (MVP, MVVM, MVI, VIPER), η οργάνωση επιπέδων (Presentation, Domain, Data), η εργασία με DI (Dagger, Hilt, Swinject) και η πλοήγηση. Για Android — γνώση Jetpack Navigation, για iOS — μοτίβο Coordinator και SwiftUI NavigationStack.

Στη συμπεριφορική συνέντευξη αξιολογούνται τα soft skills: ικανότητα ομαδικής εργασίας, επίλυσης συγκρούσεων, επιχειρηματολογίας αποφάσεων. Χρησιμοποιείται η μέθοδος STAR (Situation, Task, Action, Result) — ο υποψήφιος περιγράφει μια συγκεκριμένη κατάσταση από εμπειρία. Παράδειγμα ερώτησης: «Πείτε μας για το πιο δύσκολο bug που βρήκατε και διορθώσατε». Τελικός γύρος με team lead ή VPE ελέγχει στρατηγική σκέψη και πολιτισμική συμβατότητα με την εταιρεία.

Αλγόριθμοι και δομές δεδομένων στη συνέντευξη

Αλγοριθμικές εργασίες — υποχρεωτικό συστατικό συνεντεύξεων σε μεγάλες εταιρείες τεχνολογίας (Google, Meta, Yandex, Tinkoff, Avito). Ο κύριος στόχος είναι η αξιολόγηση του ability to solve (ικανότητα επίλυσης προβλημάτων), όχι η γνώση γλώσσας. Ο υποψήφιος μπορεί να χρησιμοποιήσει οποιαδήποτε γλώσσα προγραμματισμού — προτίμηση δίνεται σε Kotlin για Android και Swift για iOS. Τυπικά θέματα: πίνακες, κατακερματισμένοι πίνακες, γράφοι, δυναμικός προγραμματισμός, δέντρα (Binary Tree, Trie, Segment Tree).

Σύμφωνα με το LeetCode (2025), για σίγουρη επιτυχία στην αλγοριθμική συνέντευξη απαιτείται επίλυση 250-400 εργασιών. Βασικά θέματα ανά συχνότητα εμφάνισης: Two Pointers (12%), Sliding Window (10%), DFS/BFS σε γράφους (14%), Binary Search (8%), Dynamic Programming (18%), Hash Map / Set (15%). Σημειογραφία Big O — υποχρεωτικό στοιχείο: ο υποψήφιος πρέπει να εξηγήσει τη χρονική και χωρική πολυπλοκότητα της λύσης του και να προτείνει βελτιστοποίηση.

Παράδειγμα εργασίας: Two Sum

// LeetCode 1: Two Sum — κλασικό πρόβλημα HashMap
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Αποθήκευσε complement = target - nums[i] και τον δείκτη του
    val map = mutableMapOf<Int, Int>()

    for (i in nums.indices) {
        val complement = target - nums[i]

        // Αν βρεθεί complement — βρέθηκε ζεύγος
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Χρόνος: O(n), Χώρος: O(n)

Η εργασία Two Sum — η πιο δημοφιλής εργασία σε συνεντεύξεις (σύμφωνα με LeetCode, πάνω από 20 εκατομμύρια υποβολές). Η λύση σε O(n) χρησιμοποιεί HashMap: για κάθε στοιχείο ελέγχουμε αν η διαφορά target - nums[i] έχει ήδη εμφανιστεί. Αν ναι — επιστρέφουμε δείκτες. Αν όχι — αποθηκεύουμε το τρέχον στοιχείο στο HashMap. Η απλοϊκή λύση σε O(n²) με δύο ένθετους βρόχους θεωρείται μη αποδεκτή για θέσεις Senior.

Ερωτήσεις ανάπτυξης εφαρμογών κινητών

Ερωτήσεις πλατφόρμας στη συνέντευξη προγραμματιστή κινητών χωρίζονται σε τρία μπλοκ: βασικές γνώσεις πλατφόρμας, εργασία με UI και πολυνηματικότητα, αιτήματα δικτύου και αποθήκευση δεδομένων. Για Android υποχρεωτικά: κύκλος ζωής Activity και Fragment, διαφορές Fragment v1 vs Fragment v2, ActivityResult API (αντικατάσταση onActivityResult), ViewModel + StateFlow, Compose lifecycle. Για iOS: κύκλος ζωής UIViewController, ARC (Automatic Reference Counting), DispatchQueue και OperationQueue, SwiftUI lifecycle (View — @State — @Binding — @ObservedObject).

Παράδειγμα ερώτησης: κύκλος ζωής

Τυπική ερώτηση: «Ποια callbacks κύκλου ζωής Activity καλούνται κατά την περιστροφή οθόνης;». Σωστή απάντηση: onPause → onStop → onDestroy → onCreate → onStart → onResume. Πρόσθετη ερώτηση: «Πώς να διατηρήσετε κατάσταση κατά την περιστροφή;» — μέσω SavedStateHandle στο ViewModel, onSaveInstanceState Bundle ή rememberSaveable στο Jetpack Compose. Για iOS: «Τι συμβαίνει με το UIViewController κατά τη μετάβαση στο παρασκήνιο;» — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

Σχεδιασμός συστήματος εφαρμογής κινητού

System Design Interview για προγραμματιστή κινητών ελέγχει την ικανότητα σχεδιασμού αρχιτεκτονικής εφαρμογής πελάτη και αλληλεπίδρασής της με διακομιστή. Τυπικές εργασίες: σχεδιασμός ροής ειδήσεων (όπως Instagram/TikTok), συνομιλίας (όπως Telegram), αναπαραγωγής βίντεο (όπως YouTube), προσωρινής μνήμης πρώτου επιπέδου (L1 — in-memory, L2 — δίσκος). Διάρκεια — 60 λεπτά. Αξιολογείται η δομημένη σκέψη, όχι ο αριθμός λεπτομερειών.

Πρότυπο απάντησης για System Design: 1) Clarify requirements — διευκρίνιση λειτουργικών (ροή, likes, σχόλια, μεταφόρτωση φωτογραφιών) και μη λειτουργικών απαιτήσεων (offline, ταχύτητα φόρτωσης, κατανάλωση μπαταρίας). 2) High-level design — σχεδίαση σχήματος επιπέδων: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — λεπτομερής ανάλυση βασικών στοιχείων, π.χ. μηχανισμός σελιδοποίησης (Paging 3 για Android, Offset-based vs Cursor-based για iOS). 4) Trade-offs — συζήτηση συμβιβασμών: cache vs φρεσκάδα δεδομένων, offline-first vs online-only.

Βασικά θέματα System Design για κινητά: προσωρινή αποθήκευση (LRU Cache, Disk Cache με όριο), εργασία με εικόνες (Coil, Glide, SDWebImage — φόρτωση, cache, placeholder, πρόοδος), βελτιστοποίηση κίνησης (protobuf αντί JSON, συμπίεση, Differ/GraphQL), offline εργασία (Room + Sync Adapter, Core Data + iCloud, WorkManager για συγχρονισμό παρασκηνίου). Offline-first — ένα από τα πιο συνηθισμένα θέματα για θέσεις Senior.

Για iOS προστίθενται ερωτήσεις σχετικά με App Thinning, Slicing, On-Demand Resources και βελτιστοποίηση build. Για Android — σχετικά με R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery και Minification. Η αρχιτεκτονική ερώτηση «Πώς να υλοποιήσετε προσωρινή μνήμη εικόνων με περιορισμό μνήμης;» ελέγχει κατανόηση LRU Cache (LinkedHashMap με access order), Disk LRU Cache (DiskLruCache του Jake Wharton) και επιπέδου προσωρινής μνήμης Coil/Glide.

Στρατηγική προετοιμασίας για συνέντευξη

Προετοιμασία για συνέντευξη απαιτεί συστηματική προσέγγιση 4-8 εβδομάδες πριν από την προγραμματισμένη συνέντευξη. Βασική στρατηγική: 2 εβδομάδες για επανάληψη θεωρίας (γλώσσα, πλατφόρμα, αλγόριθμοι), 2-4 εβδομάδες για επίλυση αλγοριθμικών εργασιών (100-300 εργασίες στο LeetCode), 1-2 εβδομάδες για δοκιμαστικές συνεντεύξεις (Pramp, interview.io, με φίλους). Για θέσεις Senior προστίθεται προετοιμασία System Design (2-3 εβδομάδες). Το σχέδιο παρέχει 70-80% επιτυχή διέλευση στο επίπεδο-στόχο.

Για προγραμματιστές κινητών η ειδική προετοιμασία περιλαμβάνει: ανάγνωση Android Developers Guide / iOS Developer Library, ανάλυση πηγαίου κώδικα δημοφιλών βιβλιοθηκών (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), συγγραφή προσωπικού έργου με Clean Architecture και CI/CD (GitHub Actions, Fastlane). Γράψτε μια εφαρμογή παραδείγματος στο GitHub με αρθρωτή αρχιτεκτονική, DI, δοκιμές (Unit + UI + Snapshot) — αυτό θα δείξει βαθιά κατανόηση και θα αποτελέσει επιχείρημα στη συνέντευξη.

Τυπικά λάθη υποψηφίων

Λάθος 1: σιωπηλή λύση. Ο υποψήφιος γράφει κώδικα σιωπηλά, χωρίς να σχολιάζει τη ροή σκέψης. Ο συνεντευκτής δεν μπορεί να αξιολογήσει τη διαδικασία λύσης. Σωστά: να λέτε κάθε βήμα δυνατά — «Βλέπω ότι η εργασία ανάγεται σε αναζήτηση γράφου. Προτείνω να χρησιμοποιήσουμε BFS επειδή πρέπει να βρούμε τη συντομότερη διαδρομή». Αυτή η επικοινωνία δίνει στον συνεντευκτή τη δυνατότητα να κατευθύνει τον υποψήφιο σε περίπτωση λάθους, κάτι που αξιολογείται θετικά.

Λάθος 2: άμεση γραφή κώδικα. Η έναρξη κωδικοποίησης χωρίς διευκρίνιση απαιτήσεων και συζήτηση προσεγγίσεων — ένας από τους κύριους λόγους αποτυχίας. Πριν γράψετε κώδικα, πρέπει: να διευκρινίσετε δεδομένα εισόδου/εξόδου, να συζητήσετε ακραίες περιπτώσεις, να συγκρίνετε 2-3 προσεγγίσεις με αξιολόγηση Big O και μόνο μετά από συμφωνία με τον συνεντευκτή να γράψετε τη βέλτιστη λύση. Σωστό μοτίβο: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Λάθος 3: άγνοια πλατφόρμας. Ο υποψήφιος λύνει εξαιρετικά αλγορίθμους αλλά δεν μπορεί να εξηγήσει τη διαφορά μεταξύ Activity και Fragment ή μεταξύ weak/unowned σε Swift. Για θέσεις κινητών, οι γνώσεις πλατφόρμας αξιολογούνται ισότιμα με τους αλγορίθμους. Μελετήστε: διαφορές εκδόσεων SDK (compileSdk vs minSdk vs targetSdk), κανόνες ProGuard/R8 για δημοφιλείς βιβλιοθήκες, Swift Concurrency (async/await, actors) και MainActor. Κάθε τρίτος υποψήφιος για θέση iOS αποτυγχάνει σε ερωτήσεις σχετικά με ARC.