Najpopularniejsze pytania rekrutacyjne z Laravela (z odpowiedziami)

Rozmowa o Laravelu rzadko jest egzaminem z całej dokumentacji. Najczęściej to te same kilkanaście tematów, przy których rekruter sprawdza, czy rozumiesz, co dzieje się pod spodem, a nie tylko czy potrafisz uruchomić php artisan make:model. Poniżej znajdziesz pytania, które wracają na rozmowach na stanowisko juniora, razem z tym, jak na nie odpowiadać. Laravel zakłada znajomość samego języka, więc najpierw sprawdź się na pytaniach rekrutacyjnych z PHP, a pytania o bazę danych znajdziesz w artykule o pytaniach rekrutacyjnych z baz danych i SQL.

Przykłady kodu w tym artykule opierają się na dokumentacji Laravela i nie są wynikami uruchomienia, dlatego nie podajemy tu liczb ani wersji. Szczegóły (np. gdzie rejestruje się middleware) różnią się między wersjami frameworka, więc przy konkretnym projekcie zawsze sprawdzaj dokumentację jego wersji.

Jak odpowiadać na pytania rekrutacyjne z Laravela?

Najlepiej w trzech krokach: jedno zdanie definicji, krótki przykład (kilka linijek kodu lub sytuacja z projektu) i informacja, kiedy to ma znaczenie w praktyce. Taka odpowiedź zajmuje 30–60 sekund i pokazuje, że rozumiesz mechanizm, a nie wkułeś formułkę. Przy pytaniu o framework pomaga jeszcze czwarty krok: powiedz, jak to samo wyglądałoby bez Laravela. To pokazuje, że rozumiesz, co framework ci oszczędza. Jeśli czegoś nie wiesz, powiedz, co wiesz, i rozumuj na głos.

Pytania są ułożone od podstaw do tematów, które częściej pojawiają się przy ofertach na mid-poziom.

Podstawy Laravela

Czym jest Laravel i czym różni się od czystego PHP?

Laravel to framework PHP do budowania aplikacji webowych. Dostajesz gotową strukturę projektu, routing, system szablonów, ORM do bazy danych, walidację, uwierzytelnianie, kolejki i narzędzie wiersza poleceń (artisan), dzięki czemu nie piszesz od nowa tego, co powtarza się w każdej aplikacji. W czystym PHP wszystko to trzeba zrobić samemu: własny router, własne sprawdzanie danych, własne zabezpieczenia. Cena to konieczność poznania konwencji frameworka i „magii” (fasady, automatyczne wiązanie), którą rekruterzy chętnie sprawdzają. Dobra odpowiedź pokazuje, że rozumiesz zarówno zysk, jak i koszt.

Co to jest MVC i jak wygląda w Laravelu?

MVC (Model-View-Controller) dzieli aplikację na trzy role: model (dane i reguły, w Laravelu klasa Eloquent), widok (to, co widzi użytkownik, w Laravelu szablon Blade) i kontroler (przyjmuje żądanie, pobiera dane z modelu i przekazuje je widokowi). Żądanie przechodzi przez routing do kontrolera, ten korzysta z modelu i zwraca widok lub odpowiedź JSON. Korzyść: zmiana wyglądu strony nie dotyka logiki, a zmiana reguł biznesowych nie rozwala szablonów. Pytanie uzupełniające brzmi zwykle: „gdzie w MVC trafia logika biznesowa?”. Odpowiedź: nie do widoku i najlepiej nie do rozrośniętego kontrolera, tylko do modelu lub osobnej klasy usługi.

Jak działa routing w Laravelu?

Routing mapuje adres URL i metodę HTTP na kod, który ma go obsłużyć. Definiuje się go w plikach z trasami, np. routes/web.php:

Route::get('/posts/{post}', [PostController::class, 'show']);
Route::post('/posts', [PostController::class, 'store']);
Route::resource('posts', PostController::class);

Route::resource jednym zapisem tworzy komplet tras CRUD (lista, szczegóły, tworzenie, edycja, usuwanie) zgodnych z konwencją REST. Parametr {post} w adresie przy odpowiednim typie w metodzie kontrolera Laravel zamienia sam na obiekt modelu (route model binding), a gdy rekordu nie ma, zwraca odpowiedź 404. Listę wszystkich tras pokaże php artisan route:list.

Jak działa szablon Blade i czym różni się {{ }} od {!! !!}?

Blade to silnik szablonów Laravela: zwykły HTML z dyrektywami (@if, @foreach, @extends). Zapis {{ $name }} wypisuje wartość z zabezpieczeniem: znaki specjalne HTML są zamieniane, więc kod wstrzyknięty przez użytkownika nie wykona się w przeglądarce. Zapis {!! $html !!} wypisuje wartość bez zabezpieczenia, więc użycie go na danych od użytkownika otwiera drogę do ataku XSS. Zasada: domyślnie {{ }}, a {!! !!} tylko dla treści, którą sam wygenerowałeś lub oczyściłeś. O samym ataku piszemy w artykule o XSS w JavaScript.

Do czego służy artisan?

To narzędzie wiersza poleceń, które generuje kod i wykonuje zadania administracyjne. Najczęściej używane polecenia:

Na rozmowie nie trzeba znać wszystkich, ale warto wiedzieć, że tinker pozwala szybko sprawdzić zapytanie bez pisania kontrolera.

Baza danych i Eloquent

Co to jest Eloquent ORM?

Eloquent to ORM (Object-Relational Mapping) w Laravelu: każda tabela ma odpowiadającą jej klasę modelu, a wiersz jest obiektem. Zamiast pisać SELECT * FROM posts WHERE id = 1, piszesz Post::find(1). Konwencje ułatwiają życie: model Post domyślnie odpowiada tabeli posts, a klucz główny to id. Eloquent daje też relacje, zakresy zapytań, mutatory, kolekcje i zdarzenia modelu. Nie zastępuje jednak znajomości SQL: żeby wiedzieć, jakie zapytanie wygeneruje, i wykryć problem N+1, musisz rozumieć, co dzieje się w bazie. O tym piszemy w artykule o pytaniach rekrutacyjnych z SQL.

Jak definiuje się relacje w Eloquent?

Każda relacja to metoda w modelu zwracająca odpowiedni typ:

class User extends Model
{
    public function posts(): HasMany
    {
        return $this->hasMany(Post::class);
    }
}

class Post extends Model
{
    public function author(): BelongsTo
    {
        return $this->belongsTo(User::class, 'user_id');
    }
}

Zasada nazewnictwa: klucz obcy to nazwa modelu w liczbie pojedynczej z _id (tu user_id), więc w prostych przypadkach nie trzeba go podawać. O samych relacjach w bazie piszemy w artykule o relacjach i JOIN w SQL.

Czym jest problem N+1 i jak go rozwiązać w Laravelu?

N+1 to sytuacja, w której jedno zapytanie pobiera listę rekordów, a potem dla każdego z nich leci osobne zapytanie o powiązane dane. Źródłem jest tzw. ładowanie leniwe (lazy loading): relacja pobiera się dopiero przy pierwszym odczycie.

// źle: 1 zapytanie o wpisy + po jednym o autora dla każdego wpisu
$posts = Post::all();
foreach ($posts as $post) {
    echo $post->author->name;
}

// dobrze: 2 zapytania niezależnie od liczby wpisów
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name;
}

Rozwiązaniem jest ładowanie zachłanne (eager loading) przez with(). W dużych projektach warto też włączyć wyłapywanie takich sytuacji (Model::preventLazyLoading() w środowisku deweloperskim), żeby aplikacja zgłaszała błąd zamiast po cichu zalewać bazę zapytaniami. Liczby „1 + N” i „2” wynikają z konstrukcji zapytań opisanej w dokumentacji; w tym artykule nie mierzyliśmy ich na działającej aplikacji.

Co to jest mass assignment i po co są $fillable i $guarded?

Mass assignment to wypełnianie modelu wieloma polami naraz, np. User::create($request->all()). Jeśli nie ograniczysz, które pola wolno ustawiać, użytkownik może dosłać w formularzu dodatkowe pole (np. is_admin=1) i nadać sobie uprawnienia. Dlatego model deklaruje listę dozwolonych pól w $fillable (biała lista) albo zabronionych w $guarded (czarna lista):

class User extends Model
{
    protected $fillable = ['name', 'email', 'password'];
}

User::create($request->validated()); // tylko zwalidowane i dozwolone pola

Dobra praktyka: zamiast $request->all() przekazywać $request->validated() i trzymać białą listę. Domyślnie Laravel po cichu pomija pola spoza $fillable, co bywa mylące przy debugowaniu („dlaczego pole się nie zapisało?”).

Czym jest migracja i dlaczego nie edytujemy bazy ręcznie?

Migracja to plik PHP opisujący zmianę struktury bazy (utworzenie tabeli, dodanie kolumny) razem z jej cofnięciem. Dzięki migracjom zespół i serwery mają tę samą strukturę, a zmiany są w repozytorium jak zwykły kod.

Schema::create('posts', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->foreignId('user_id')->constrained();
    $table->timestamps();
});

Dwie zasady, o które dopytują rekruterzy: nie edytuje się migracji, która była już uruchomiona na innych środowiskach (dodaje się nową), oraz do zmiany struktury tabeli, która ma już dane, pisze się osobną migrację. Cofnięcie ostatniej partii to php artisan migrate:rollback. Dane testowe tworzą fabryki (factories) i seedery. Podobną ideę w Pythonie opisujemy w artykule o migracjach z Alembic.

Czym różni się Eloquent od Query Buildera i kiedy użyć każdego?

Query Builder (DB::table('posts')->where(...)->get()) buduje zapytania SQL i zwraca zwykłe obiekty, a Eloquent zwraca modele z relacjami, mutatorami i zdarzeniami. Eloquent wygodniej się czyta przy typowych operacjach na rekordach, Query Builder bywa lżejszy i prostszy do dużych raportów. Obydwa używają tej samej ochrony przed SQL injection: wartości trafiają do zapytania jako parametry. Zasada ostrożności dotyczy surowych fragmentów SQL (whereRaw, DB::raw): tam parametry trzeba przekazywać osobno, a nie sklejać w tekst. Szerzej o ataku piszemy w artykule o SQL injection.

Czym są soft delete i accessors?

Soft delete (use SoftDeletes; w modelu) zamiast usuwać wiersz ustawia datę w kolumnie deleted_at, a zapytania domyślnie pomijają takie rekordy. Pozwala to przywrócić dane i zachować historię. Accessory i mutatory zmieniają sposób odczytu i zapisu pola, np. zawsze zapisują e-mail małymi literami lub składają imię i nazwisko w jedno pole. Pytanie uzupełniające: czym grozi soft delete? Odpowiedź: rekordy wciąż zajmują miejsce i trzeba pamiętać o nich przy unikalności pól i zapytaniach na surowym SQL.

Żądania, walidacja i bezpieczeństwo

Co to jest middleware i do czego służy?

Middleware to warstwa, przez którą przechodzi żądanie, zanim trafi do kontrolera (i przez którą wraca odpowiedź). Służy do zadań wspólnych dla wielu tras: sprawdzenia, czy użytkownik jest zalogowany, ochrony przed CSRF, ograniczania liczby żądań, logowania. Najprościej wyobrazić je jako cebulę: żądanie przechodzi przez kolejne warstwy do środka, a odpowiedź wraca na zewnątrz.

class EnsureUserIsAdmin
{
    public function handle(Request $request, Closure $next)
    {
        if (! $request->user()?->is_admin) {
            abort(403);
        }

        return $next($request);
    }
}

Wywołanie $next($request) przekazuje żądanie dalej, a brak tego wywołania je zatrzymuje. Middleware przypisuje się do trasy lub grupy tras (np. ->middleware('auth')). Nazwa pliku i miejsce rejestracji zależą od wersji Laravela.

Jak działa walidacja i czym jest Form Request?

Najprostsza walidacja to $request->validate([...]) w kontrolerze. Gdy reguł jest dużo, wydziela się je do osobnej klasy Form Request (php artisan make:request StorePostRequest), która sprawdza dane, zanim kod kontrolera w ogóle się wykona.

public function store(Request $request)
{
    $validated = $request->validate([
        'title' => 'required|string|max:255',
        'email' => 'required|email|unique:users,email',
    ]);

    // $validated zawiera tylko sprawdzone pola
}

Przy błędzie Laravel sam przekierowuje z powrotem do formularza z komunikatami (dla żądań JSON zwraca odpowiedź 422 z listą błędów). Walidację po stronie serwera trzeba robić zawsze, bo walidacja w przeglądarce jest tylko wygodą dla użytkownika. Jak wygląda to samo bez frameworka, pokazujemy w poradniku o walidacji formularza w PHP.

Jak Laravel chroni przed CSRF?

Każdy formularz, który zmienia dane, zawiera ukryty token wstawiany przez dyrektywę @csrf w Blade. Laravel porównuje go z tokenem w sesji i odrzuca żądanie, jeśli się nie zgadza (błąd 419). To chroni przed sytuacją, w której obca strona wysyła w imieniu zalogowanego użytkownika żądanie do twojej aplikacji. Częsty problem z praktyki: żądania AJAX bez tokenu kończą się błędem 419 (jedno z najpopularniejszych pytań o Laravela na Stack Overflow). Rozwiązanie to dołączenie tokenu do nagłówka, a nie wyłączanie ochrony. Mechanizm działania CSRF wyjaśniamy w artykule o CSRF i ciasteczkach SameSite.

Jak działa uwierzytelnianie i autoryzacja?

Uwierzytelnianie (authentication) odpowiada na pytanie „kim jesteś?”, autoryzacja (authorization) na „co ci wolno?”. W Laravelu logowanie dla aplikacji z widokami najłatwiej dodać gotowym pakietem startowym (np. Laravel Breeze), a dla API i aplikacji SPA służy Sanctum (tokeny API i sesje). Autoryzację opisują polityki (policies, reguły dla modelu, np. czy użytkownik może edytować wpis) i bramki (gates). W kontrolerze wystarczy $this->authorize('update', $post);. Zasada, którą rekruter chce usłyszeć: sprawdzaj uprawnienia do konkretnego rekordu, a nie tylko to, czy użytkownik jest zalogowany. To klasyczny błąd, w którym użytkownik widzi cudze dane po zmianie id w adresie.

Architektura i narzędzia

Czym jest kontener usług i wstrzykiwanie zależności?

Kontener usług (service container) to mechanizm, który tworzy obiekty i dostarcza im potrzebne zależności. Wystarczy w konstruktorze lub metodzie kontrolera podać typ klasy, a Laravel sam ją utworzy i przekaże (dependency injection):

class OrderController extends Controller
{
    public function __construct(private PaymentGateway $payments) {}

    public function store(Request $request)
    {
        $this->payments->charge($request->amount);
    }
}

Korzyść: klasa nie tworzy zależności sama (new PaymentGateway), więc w testach można podstawić atrapę, a w aplikacji zmienić implementację w jednym miejscu (w dostawcy usług, service provider). Częsty błąd: Laravel nie potrafi zbudować klasy, której konstruktor wymaga zwykłej wartości (np. tekstu), i zgłasza Unresolvable dependency.

Czym są fasady i czy warto ich używać?

Fasada (facade) to statyczny zapis (Cache::get('klucz'), Auth::user()), który pod spodem wywołuje obiekt z kontenera. Jest krótki i czytelny, ale ukrywa zależności klasy i bywa nadużywany. Wstrzykiwanie przez konstruktor jest jawniejsze, a fasady dobrze się testuje (Laravel potrafi je podmieniać). Dobra odpowiedź nie wybiera „zawsze jedno”, tylko mówi, że w kodzie, w którym zależności mają być widoczne, wolisz wstrzykiwanie, a fasady zostawiasz dla prostych, powtarzalnych zastosowań.

Co robi plik .env i czym różni się env() od config()?

Plik .env przechowuje ustawienia zależne od środowiska (dane dostępowe do bazy, klucze API) i nie trafia do repozytorium. Pliki w katalogu config/ czytają wartości z .env przez env(), a reszta aplikacji pobiera je przez config('app.name'). Powód: po zbuforowaniu konfiguracji (php artisan config:cache) funkcja env() poza plikami konfiguracyjnymi przestaje zwracać wartości z .env, więc kod używający jej bezpośrednio działa lokalnie, a przestaje na produkcji. To klasyczne pytanie sprawdzające, czy ktoś wdrażał aplikację.

Co to są kolejki, zdarzenia i zadania?

Kolejka (queue) pozwala przenieść wolną operację (wysłanie e-maila, generowanie raportu) poza żądanie użytkownika, żeby strona odpowiadała od razu. Zadanie (job) opisuje taką operację, a worker w tle pobiera je z kolejki i wykonuje. Zdarzenia (events) i nasłuchiwacze (listeners) pozwalają rozdzielić „co się stało” od „co z tym zrobić”: np. po rejestracji wysyłasz mail powitalny i zakładasz konto rozliczeniowe bez wpychania wszystkiego do kontrolera. Dobra odpowiedź podaje przykład, który wymaga kolejki (e-mail masowy), a nie samą definicję.

Jak testuje się aplikację w Laravelu?

Laravel ma wbudowane wsparcie dla testów (PHPUnit lub Pest). Testy funkcjonalne wywołują trasy jak przeglądarka i sprawdzają odpowiedź, a cecha RefreshDatabase przywraca bazę do czystego stanu przed testami. Fabryki tworzą dane testowe, a atrapy (Mail::fake(), Queue::fake()) pozwalają sprawdzić, że mail został wysłany, bez realnego wysyłania. Uruchamia się je poleceniem php artisan test. Rekruter oczekuje odpowiedzi, co testujesz i dlaczego: ścieżkę rejestracji, walidację i uprawnienia, a nie wywołania biblioteki.

Jak wdrożyć aplikację Laravel na serwer?

W skrócie: kod trafia na serwer z repozytorium, instalujesz zależności przez Composer (composer install --no-dev), tworzysz plik .env produkcyjny, generujesz klucz aplikacji, uruchamiasz migracje (php artisan migrate --force) i buforujesz konfigurację oraz trasy, a serwer WWW kieruje ruch na katalog public/. Wdrożenie można zautomatyzować, np. przez Laravel Forge, który konfiguruje serwer i uruchamia skrypt wdrożenia. Dobra odpowiedź wspomina o rzeczach, które łatwo pominąć: katalog storage/ musi być zapisywalny, .env nie może być publicznie dostępny, a tryb debugowania (APP_DEBUG) na produkcji musi być wyłączony.

Jakie zadania z kodem pojawiają się na rozmowach z Laravela?

Najczęściej: prosty CRUD (wpisy, zadania) z walidacją, relacja jeden do wielu z listą i poprawką N+1, własny middleware (np. dostęp tylko dla administratora), Form Request z regułami, zapytanie do bazy z filtrowaniem i paginacją oraz test funkcjonalny jednej trasy. Rekruter patrzy, czy używasz konwencji frameworka, czy zabezpieczasz dane ($fillable, walidacja, autoryzacja) i czy rozumiesz zapytania, które wygeneruje Eloquent. Umiejętności wymagane od juniora backendowego omawia poradnik o tym, jak przygotować się do rekrutacji na juniora developera.

Co zrobi Laravel? Mini-test na rozgrzewkę

Rekruterzy lubią pytanie „co się stanie?”. Spróbuj odpowiedzieć na trzy poniższe, zanim zajrzysz do odpowiedzi. Odpowiedzi wynikają z dokumentacji Laravela, bez uruchamiania.

Zadanie 1. Ile zapytań do bazy wykona ten kod dla 100 wpisów?

$posts = Post::all();

foreach ($posts as $post) {
    echo $post->author->name;
}

Odpowiedź: 101 (jedno o wpisy i po jednym o autora dla każdego z nich). Z Post::with('author')->get() będą dwa zapytania.

Zadanie 2. Co się stanie, gdy użytkownik dośle w formularzu pole is_admin=1, a model ma $fillable = ['name', 'email']?

User::create($request->all());

Odpowiedź: pole is_admin zostanie po cichu pominięte, bo nie ma go w $fillable. Gdyby model miał $guarded = [] (nic nie jest zabronione), użytkownik mógłby nadać sobie uprawnienia. Dlatego do create przekazuje się $request->validated().

Zadanie 3. Kod używa env('APP_NAME') w kontrolerze. Po wdrożeniu na produkcję i php artisan config:cache zwraca null. Dlaczego?

Odpowiedź: po zbuforowaniu konfiguracji .env nie jest już wczytywany przy każdym żądaniu, więc env() poza plikami w config/ nie ma skąd wziąć wartości. Poprawnie: config('app.name').

Jak przygotować się do rozmowy z Laravela?

Samo czytanie odpowiedzi nie wystarczy, bo pytania uzupełniające szybko pokazują, czy rozumiesz temat. Skuteczniej działa zbudowanie małej aplikacji (blog z logowaniem, komentarzami i ocenami) bez kopiowania gotowca oraz głośne tłumaczenie decyzji komuś innemu, na przykład mentorowi. Dla porządku:

Na czym juniorzy najczęściej tracą punkty?

Nie na trudnych tematach, tylko na trzech drobiazgach, które wychodzą dopiero przy pytaniach uzupełniających:

1. Pętla z odwołaniem do relacji bez with(). Kod działa na kilku rekordach, a na produkcji zalewa bazę zapytaniami. Nie wystarczy powiedzieć „znam N+1”. Pokaż, jak go rozpoznać (liczba zapytań) i jak naprawić.
2. $request->all() przekazane do create. Brak zrozumienia mass assignment to jedna z najczęstszych luk. Wyjaśnij, po co jest $fillable i dlaczego dane przechodzą najpierw walidację.
3. Logika biznesowa w kontrolerze lub widoku. Kontroler, który ma 200 linii i sam liczy rabaty, nie da się przetestować ani użyć ponownie. Wspomnij o wydzieleniu logiki do modelu, klasy usługi lub zdarzenia.

Na co zwraca uwagę mentor, gdy sprawdza kod w Laravelu?

Przy code review kodu w Laravelu mentor zwykle zaczyna od trzech rzeczy, które pasują też do rozmowy rekrutacyjnej.

Pierwsze: „Ile zapytań do bazy wykonuje ta strona?” Kod z pętlą po rekordach i odwołaniem do relacji działa na kilku danych testowych i dopiero na produkcji okazuje się wolny. Dlatego przy cudzym kodzie warto najpierw policzyć zapytania (np. w narzędziu do debugowania zapytań albo przez DB::listen), a dopiero potem czytać logikę. Kto zadaje to pytanie sam sobie przed oddaniem kodu, wyłapuje N+1 bez pomocy mentora.

Drugie: „Zanim napiszesz własny mechanizm, sprawdź, czy Laravel go nie ma.” Własna walidacja w kontrolerze, ręczne sprawdzanie uprawnień czy wysyłka maila w trakcie żądania to klasyczne przykłady kodu, który framework już rozwiązuje: Form Request, polityki i kolejki. Ręczne rozwiązanie bywa dłuższe, trudniejsze w testach i pomija przypadki brzegowe, o których autor nie pomyślał.

Trzecie: zbuduj małą aplikację w czystym PHP, zanim sięgniesz po Laravela. Księga gości z logowaniem, formularzem i bazą przez PDO pokazuje, ile pracy framework robi za ciebie: routing, walidację, ochronę CSRF, migracje. Kto raz napisał to ręcznie, rozumie, po co jest MVC i Eloquent, i potrafi wyjaśnić to na rozmowie, zamiast powtarzać nazwy z dokumentacji.

Jak brzmi dobra odpowiedź, a jak słaba?

Weźmy pytanie o middleware:

Ten sam schemat działa przy każdym pytaniu z tego artykułu: definicja, mechanizm, przykład użycia.

Co zrobić, gdy nie znasz odpowiedzi?

Nie zgaduj i nie milcz. Powiedz, co wiesz na pewno, a potem rozumuj na głos, np.: „Nie pamiętam dokładnej nazwy tej metody, ale wiem, że szukam sposobu na wczytanie relacji razem z listą, więc sprawdziłbym with w dokumentacji Eloquent.” Taka odpowiedź pokazuje, że potrafisz sobie poradzić w pracy, a umiejętność znalezienia odpowiedzi jest w codziennej pracy ważniejsza niż pamięć do szczegółów.

Dobrze też wiedzieć, jak wygląda sama rekrutacja. W podcaście Mateusz Choma opowiada o procesie rekrutacji i przygotowaniu do rozmów.

Znajomość odpowiedzi to połowa sukcesu, drugą jest znalezienie rozmów, na które warto się umówić. Jeśli szukasz ofert, sięgnij po darmowy poradnik o tym, jak szukać pracy w 2026 roku, w którym zebraliśmy 3 sposoby poszukiwania pracy, które u naszych podopiecznych dają najlepsze efekty. Całość procesu, od CV po rozmowę, opisuje artykuł o tym, jak przejść cały proces rekrutacyjny na juniora.

Jeśli braki wyjdą przy Eloquent albo middleware, to sygnał, że warto uporządkować wiedzę z mentorem. W kursie PHP z Laravelem są osobne moduły o Laravelu, relacjach w Eloquent (z eager loadingiem i problemem N+1), projektowaniu bazy MySQL i wdrożeniu przez Laravel Forge. Zadania i projekty z tej tematyki sprawdza mentor w code review.