25 pyetje intervistash për frontend / Angular developer: Nga junior te lead (me përgjigje)

Hyrje

Një intervistë për një pozicion Zhvilluesi Frontend ose Angular nuk është kurrë një provë e thjeshtë të sintaksës. Kushdo që bën intervistën dëshiron të kuptojë se si mendoni kur përballeni me një problem, sa ju i njihni thellësisht mjetet që përdorni çdo ditë dhe si ndryshojnë zgjedhjet tuaja kur e bëni këtë Skenari shkon nga "një komponent" në "një aplikacion ndërmarrjeje i përdorur nga qindra mijëra përdorues”.

Ky udhëzues mbledh 25 pyetje reale, të organizuara në katër nivele të vjetërsia — Junior, Niveli i mesëm, I moshuar dhe Ekspert/Udhëheqës — me përgjigje gjithëpërfshirëse që mund t'i përdorni të dyja për t'u përgatitur për një intervistoni të dyja, nëse jeni në anën tjetër të tryezës, për ta drejtuar vetë në një farë mënyre strukturuar.

Pyetjet e nivelit të parë testojnë themelet (HTML, CSS, JavaScript, TypeScript, Basic Angular); ato të niveleve të ndërmjetme hyjnë në RxJS, komponentë, shërbime, rrugëzim dhe menaxhimin e shtetit; të moshuarit prekin zbulimin e ndryshimeve, paraqitjen, performancën e avancuar, modele testimi dhe projektimi; Ekspertët/Udhëheqësit adresojnë arkitekturat e mëdha të aplikacioneve, microfrontend, SSR, siguria dhe kompromiset teknike që një drejtues duhet të jetë në gjendje të argumentojë, jo vetëm duke ditur.

Temat: #Angular #Frontend #IntervistëPunë #TypeScript #JavaScript #RxJS #Zhvillimi në ueb #Këshilla për karrierë #Arkitekturë Softuerësh #Intervistë Teknike

Si është strukturuar ky udhëzues

Çdo pyetje është krijuar për të pasqyruar atë që kërkohet në të vërtetë në intervistat teknike, jo pyetjet e "tekstit" të izoluara nga konteksti. Përgjigjet nuk janë të kufizuara në përkufizim formale: ata shpjegojnë pse përgjigja është se, kur rregulli ka përjashtime, dhe çfarë një intervistues me përvojë pret të dëgjojë për të dalluar një përgjigje teksti nga një përgjigje nga dikush që në fakt e zgjidhi problemin në prodhim.

Niveli i ri (6 pyetje): bazat e HTML, CSS, JavaScript, TypeScript dhe Angular.
Niveli i mesëm (6 pyetje): RxJS, komponentët, shërbimet, rutimi, menaxhimi i shtetit, performanca bazë.
Niveli i lartë (7 pyetje): arkitektura, zbulimi i ndryshimeve, interpretimi, performanca e avancuar, testimi, modeli i projektimit.
Niveli i Ekspertit/Udhëheqësit (6 pyetje): arkitektura të mëdha aplikacionesh, shkallëzueshmëri, mikrofronte, SSR, siguri, kompromise teknike.

Niveli Junior — HTML, CSS, JavaScript, TypeScript dhe Angular Fundamentals

Në këtë nivel, qëllimi i intervistuesit nuk është të gjejë gabimin, por të kuptojë nëse e keni themele të forta për të ndërtuar. Përgjigjet më të mira janë ato që, përveç përkufizimit, ato shpjegojnë ndikimin praktik të njohurive.

1. Cili është ndryshimi midis elementeve HTML të nivelit të bllokut dhe elementëve të brendshëm, dhe pse është e rëndësishme të dihet?

Elementet nivel blloku (si <div>, <section>, <p>) zënë gjithmonë të gjithë gjerësinë në dispozicion të prindit dhe filloni në një linjë të re, duke pranuar width, lartësia dhe margjina/mbushje në të gjitha anët. Elementet inline (si <span>, <a>, <strong>) zënë vetëm hapësirën e nevojshme për përmbajtjen, ato janë të renditura në përputhje me tekstin përreth dhe injoroni gjerësinë/lartësi, si dhe trajtoni kufijtë në një mënyrë të veçantë vertikale.

Njohja e saj është e rëndësishme sepse shpjegon gabimet shumë të zakonshme të paraqitjes: a <span> në të cilën keni vendosur width dhe asgjë nuk ndodh, ose një element që "nuk përputhet" siç e prisni. Me ekranin : flex, grid dhe inline-block ky dallim klasik është i paqartë, por kuptimi i sjelljes së paracaktuar mbetet thelbësor për të parashikuar se si do të sillet një element përpara se të aplikoni CSS.

2. Cilat janë modeli i kutisë CSS dhe ndryshimet midis kutisë së përmbajtjes dhe kutisë kufitare?

Modeli box përshkruan se si shfletuesi llogarit dimensionet përfundimtare të një elementi: përmbajtja (përmbajtja), mbushje (hapësirë e brendshme), kufi (kufiri) dhe margin (hapësira e jashtme), koncentrike me njëra-tjetrën në tjetrin. Vetia box-sizing përcakton se si width dhe lartësia interpretohen:

/* content-box (default del browser): width/height si riferiscono SOLO al contenuto.
   padding e border si sommano, ingrandendo la dimensione finale renderizzata. */
.box-legacy {
  box-sizing: content-box;
  width: 200px;
  padding: 20px;
  border: 5px solid black;
  /* larghezza finale renderizzata: 200 + 20*2 + 5*2 = 250px */
}

/* border-box: width/height includono padding e border.
   La dimensione dichiarata è la dimensione finale renderizzata. */
.box-modern {
  box-sizing: border-box;
  width: 200px;
  padding: 20px;
  border: 5px solid black;
  /* larghezza finale renderizzata: 200px, esattamente come dichiarato */
}

Në praktikë, pothuajse të gjitha projektet moderne janë vendosur *, *::para, *::pas { box-sizing: border-box; } globalisht vetëm sepse i bën llogaritjet e paraqitjes të parashikueshme, duke parandaluar shtimin e mbushjes nga "thyerja" e një rrjeti tashmë të përmasave.

3. Cili është ndryshimi midis var, let dhe const në JavaScript, dhe cilat probleme mund të zgjidhin?

var ka shtrirje funksioni (ose shtrirje globale nëse deklarohet jashtë funksionet) dhe vuan nga ngritja me inicializimin në të papërcaktuar, e cila ju lejon të "përdorni atë përpara se ta deklaroni" pa gabime - një sjellje e gabuar i heshtur. let dhe const në vend të kësaj kanë shtrirje bllokimi (të dukshme vetëm brenda kllapave kaçurrelë në të cilat janë deklaruar) dhe jetojnë në një zona e vdekur e përkohshme: qasja në të përpara se deklarata të lëshojë një Error Reference eksplicite në vend që të ktheheni në heshtje i papërcaktuar.

// Il classico bug da var dentro un loop asincrono
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log('var:', i), 10);
}
// Stampa: var: 3, var: 3, var: 3
// perché var è condivisa da tutte le iterazioni (una sola variabile, function-scoped)

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log('let:', i), 10);
}
// Stampa: let: 0, let: 1, let: 2
// perché let crea un nuovo binding per ogni iterazione del loop

const parandalon ricaktimin e lidhjes (nuk e bën objektin të pandryshueshëm: një grup ose objekt i deklaruar me const ende mund të ndryshohet në të e brendshme). Rregulli i përgjithshëm që ndjekin pothuajse të gjitha skuadrat: const si parazgjedhje, let vetëm kur nevojitet ricaktim, var kurrë në kod të ri.

4. Çfarë janë mbylljet në JavaScript dhe për çfarë janë ato në praktikë?

Një mbyllje krijohet kur një funksion "kujton" variablat e fushës në i cili ishte përcaktuar, edhe pasi ai fushëveprimi të ketë përfunduar ekzekutimin. Në praktikë, funksioni i brendshëm ruan një referencë të drejtpërdrejtë për variablat e funksionit të jashtëm.

function createCounter() {
  let count = 0; // variabile "chiusa" nella closure

  return {
    increment: () => ++count,
    decrement: () => --count,
    getValue: () => count,
  };
}

const counter = createCounter();
counter.increment();
counter.increment();
console.log(counter.getValue()); // 2

// count non è accessibile dall'esterno: è uno stato privato reso possibile dalla closure
console.log(counter.count); // undefined

Mbylljet janë kudo në kodin real Angular: sa herë që kaloni një funksion të kthimit të thirrjes në një subscribe(), në një setTimeout, ose përcaktoni një llogaritur()/efekt() të një sinjali, ai funksion "mbyllet" në variablat përbërëse. Kuptimi i mbylljeve shpjegon gjithashtu një gabim të shpeshtë: kapja nga referojuni një variabli që ndryshon (p.sh. indeksi i një cikli) në vend të vlerës së pritur në koha e thirrjes.

5. Çfarë janë gjenerikët në TypeScript dhe pse janë të dobishëm?

gjenerikët ju lejojnë të shkruani funksione, klasa dhe ndërfaqe që ata punojnë me lloje të ndryshme pa humbur sigurinë e tipit, duke zëvendësuar alternativën më e keqja — përdorni any, i cili në mënyrë efektive çaktivizon kontrollin e tipit.

// Senza generics: perdiamo informazione di tipo, il chiamante deve fare un cast manuale
function wrapInArrayUnsafe(value: any): any[] {
  return [value];
}
const result = wrapInArrayUnsafe('hello'); // result è any, nessun autocompletamento

// Con generics: il tipo si propaga automaticamente dall'input all'output
function wrapInArray(value: T): T[] {
  return [value];
}
const strings = wrapInArray('hello'); // TypeScript inferisce string[]
const numbers = wrapInArray(42);      // TypeScript inferisce number[]

// Un caso reale: un servizio HTTP generico
class ApiService {
  constructor(private endpoint: string) {}

  getAll(): Observable {
    return this.http.get(this.endpoint);
  }
}

const productsApi = new ApiService('/api/products');
// productsApi.getAll() restituisce Observable, tipizzato correttamente

Në Angular, gjenerikët janë kudo: E vëzhgueshme, sinjal, Komponent në prova, i Repository Ana e NestJS. Të dish t'i përdorësh ato në dorë të parë (dhe jo vetëm kaq njohin ato) është ajo që i dallon ata që shkruajnë kod të shtypur të fortë nga ata që thjesht kopjoni modelet ekzistuese.

6. Çfarë është një komponent këndor dhe cilët janë elementët kryesorë të tij?

Një komponent Angular është një klasë TypeScript e zbukuruar me @Component që kontrollon një pjesë të ndërfaqes së përdoruesit. Elementet kryesore të tij janë:

Decorator @Component: metadata që përshkruajnë përzgjedhësin, shabllonin dhe stilin e komponentit.
Model: HTML (në linjë ose në skedar të veçantë) me lidhje, direktiva dhe interpolim.
Klasa: përmban gjendje (veti, sinjale) dhe sjellje (metoda, grepa të ciklit jetësor).
Stilet: CSS me shtrirje të kapsuluar në komponentin e paracaktuar (Shiko Enkapsulimin).

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-greeting',
  standalone: true, // non richiede più NgModule dal 2023 in poi
  template: `
    Ciao, {{ name() }}!
    Cambia nome
  `,
  styles: [`h2 { color: var(--color-primary); }`],
})
export class GreetingComponent {
  name = signal('Mondo');

  changeName(): void {
    this.name.set('Angular');
  }
}

Nga viti 2023 (Angular 14+ për komponentë të pavarur, më pas i paracaktuar nga Angular 17) një komponent nuk ka më nevojë të deklarohet në një NgModule: ai deklaron drejtpërdrejt varësitë e veta nëpërmjet importeve në dekorues. Është modeli që prisni mund të përdoret në çdo projekt të ri sot.

Niveli i mesëm — RxJS, Komponentët, Shërbimet, Drejtimi dhe Menaxhimi i Shtetit

Në këtë nivel, intervistuesi kontrollon nëse dini të lidhni konceptet: nuk mjafton duke ditur se çfarë është një Observable, ju duhet të dini se cilin operator RxJS të përdorni në cilin skenar, dhe sepse një zgjedhje e gabuar shkakton gabime të vërteta (kushtet e garës, rrjedhjet e kujtesës, kërkesat dublikatë).

7. Cili është ndryshimi midis switchMap, mergeMap, concatMap dhe exhaustMap në RxJS dhe kur të përdoret secili?

Të katër janë operatorë "rrafshues" që menaxhojnë një Observable of Observable, por me strategji konkurruese të kundërta:

Operator	Sjellja	Rasë tipike përdorimi
`switchMap`	Anulon kërkesën e mëparshme të papërfunduar kur mbërrin një e re	Fushë kërkimi me plotësim automatik (vlen vetëm hyrja e fundit)
`mergeMap`	Ekzekuton të gjitha kërkesat paralelisht, pa anuluar asgjë	Ngarkime të shumta skedarësh të pavarur nga njëri-tjetri
`concatMap`	Rreshton kërkesat, ekzekuton tjetrën vetëm pasi të përfundojë e mëparshmja	Operacione që duhet të ndodhin në rend të rreptë (p.sh. shkrim sekuencial në një regjistër)
`exhaustMap`	Injoron ngjarjet e reja derisa të përfundojë ajo aktuale	Buton dërgimi — shmang dërgime të dyfishta nga klikime të shumëfishta

// L'errore più comune: usare mergeMap per una ricerca con autocomplete
searchInput.valueChanges.pipe(
  debounceTime(300),
  mergeMap(query => this.api.search(query)), // ❌ le risposte possono arrivare fuori ordine!
).subscribe(results => this.results.set(results));

// Se l'utente digita velocemente "an" poi "angular", e la richiesta per "an"
// impiega più tempo a rispondere di quella per "angular", l'utente vede
// i risultati sbagliati (quelli di "an") sovrascrivere quelli corretti.

// La scelta corretta: switchMap cancella la richiesta obsoleta
searchInput.valueChanges.pipe(
  debounceTime(300),
  switchMap(query => this.api.search(query)), // ✅ solo l'ultima richiesta conta
).subscribe(results => this.results.set(results));

Një përgjigje solide e nivelit të mesëm përmend në mënyrë eksplicite këtë gabim të klasifikimit: është arsyeja real kështu që switchMap është pothuajse gjithmonë zgjedhja e duhur për kërkimin, jo një rregull arbitrar që duhet mësuar përmendësh.

8. Si funksionon Dependency Injection në Angular dhe cili është ndryshimi midis ofruesve provideIn: 'root' dhe nivelit të komponentit?

Angular mban një hierarki prej injector: një nivel rrënjë aplikim, dhe një për çdo komponent (dhe fëmijët e tij, nëse nuk anashkalohet). Kur a komponenti kërkon një varësi në konstruktor (ose me inject()), Angular kërkon për një ofrues lart në hierarki nga injektori i komponentit në rrënjë.

// providedIn: 'root' — un'unica istanza condivisa in tutta l'applicazione (singleton)
@Injectable({ providedIn: 'root' })
export class AuthService {
  private currentUser = signal(null);
}

// providers a livello di componente — una nuova istanza per ogni istanza del componente
@Component({
  selector: 'app-product-form',
  providers: [FormStateService], // ogni  ottiene la SUA istanza
  standalone: true,
})
export class ProductFormComponent {
  private formState = inject(FormStateService);
}

Zgjedhja ka pasoja reale: nëse vendosni një gjendje që duhet të ndahet (p.sh. vërtetimi) në ofruesit të një komponenti në vend të në providedIn: 'root', çdo shembull i komponentit do të ketë një gjendje të izoluar - një gabim klasik "pse shërbimi im nuk i sheh të dhënat e përditësuara?" e cila pothuajse gjithmonë lind nga kjo konfuzion midis fushës së injektorit.

9. Çfarë janë Route Guards dhe cilat lloje ekzistojnë në Angular moderne?

guard janë funksione (në Angular moderne, funksione të pastra, jo më klasa me ndërfaqet) që vendosin nëse një navigim mund të vazhdojë, duhet të ridrejtohen ose bllokuar. Ato kryesore janë:

CanActivateFn: vendos nëse një itinerar mund të aktivizohet (p.sh. kontrolli i vërtetimit).
CanActivateChildFn: si më sipër, por zbatohet për rrugët e fëmijëve.
CanDeactivateFn: vendos nëse një itinerar mund të lihet (p.sh. paralajmërimi "ndryshime të paruajtura").
CanMatchFn: vendos nëse një rrugë mund të përputhet fare, e dobishme për fshehjen e seksioneve të ngarkuara me dembel nga përdoruesit pa leje.
ResolveFn: teknikisht nuk është roje, por ngarkon paraprakisht të dhënat përpara se itinerari të aktivizohet.

export const authGuard: CanActivateFn = (route, state) => {
  const auth = inject(AuthService);
  const router = inject(Router);

  if (auth.isAuthenticated()) return true;

  router.navigate(['/login'], { queryParams: { returnUrl: state.url } });
  return false;
};

// registrazione nelle route
export const routes: Routes = [
  { path: 'dashboard', component: DashboardComponent, canActivate: [authGuard] },
];

10. Si do ta trajtonit gjendjen e përbashkët midis komponentëve të palidhur në një aplikacion Angular me madhësi mesatare?

Për komponentët e palidhur (të cilët nuk kanë marrëdhënie të drejtpërdrejtë prind-fëmijë), zgjidhja standardi është një shërbim i përbashkët me shtrirje i ofruarIn: 'root' i cili ekspozon gjendjen nëpërmjet sinjalit (ose, në bazat e kodeve më të vjetra, nëpërmjet Subjekti i sjelljes).

@Injectable({ providedIn: 'root' })
export class CartStateService {
  private readonly _items = signal([]);

  readonly items = this._items.asReadonly(); // esposto in sola lettura
  readonly total = computed(() =>
    this._items().reduce((sum, i) => sum + i.price * i.quantity, 0)
  );

  addItem(item: CartItem): void {
    this._items.update(items => [...items, item]);
  }
}

Për aplikime të mesme ky model është i mjaftueshëm: është i thjeshtë, i sigurt për tipin, i përgjegjshëm dhe nuk kërkon varësi të jashtme. Një bibliotekë si NgRx bëhet vetëm e justifikuar kur shfaqen nevoja konkrete - korrigjimi i udhëtimit në kohë, veprime të gjurmueshme me DevTools, Logjika komplekse e gjendjes ndahet në dhjetëra veçori - jo "sepse është standardi ndërmarrje". Futja e tij para kohe shton pllakën e bojlerit pa përfitime proporcionale.

11. Cilat janë sinjalet në Angular dhe si ndryshojnë ato nga një RxJS Observable?

Një Signal është një kontejner reaktiv i një vlere që njofton automatikisht kushdo që e lexon kur ndryshon, pa nevojën për t'u abonuar/çabonuar. Krahasuar me një RxJS Observable, ndryshimi kryesor është se një sinjal gjithmonë ka një vlera aktuale sinkrone dhe menjëherë e disponueshme (lexo duke e thirrur si funksion: count()), ndërsa një Observable përfaqëson një transmetim ngjarjesh me kalimin e kohës që mund të mos ketë emetuar ende asgjë.

import { signal, computed, effect } from '@angular/core';

const count = signal(0);
const doubled = computed(() => count() * 2); // si ricalcola automaticamente

effect(() => {
  console.log('Il valore doppio è ora:', doubled()); // si riesegue ad ogni cambiamento
});

count.set(5); // stampa: Il valore doppio è ora: 10
count.update(v => v + 1); // stampa: Il valore doppio è ora: 12

Në praktikë: Sinjalet janë ideale për gjendjen lokale sinkrone të një komponenti (numëruesit, format gjendje, të dhëna të përftuara), ndërsa RxJS mbetet mjeti i duhur për flukset asinkrone komplekse (debounce në një hyrje, provoni përsëri në një telefonatë HTTP, duke kombinuar transmetime të shumta). Këndore moderne i bën ato të ndërveprojnë me toSignal() dhe toObservable(), kështu që pyetja nuk është “cila” por “cila për këtë rast konkret”.

12. Cili është ndryshimi midis @Input()/@Output() tradicionale dhe hyrjes()/output() të bazuar në sinjale të reja?

Dekoratorët tradicionalë @Input()/@Output() deklarojnë pronat normalet (ose EventEmitter) që Angular i popullon/vëzhgon nëpërmjet mekanizmit të tij e brendshme; funksionet e reja input()/output() (Angular 17.1+) ata kthejnë përkatësisht një sinjal vetëm për lexim dhe një emetues të shtypur, duke u integruar në mënyrë natyrale me kompjuter() dhe efekt().

// Stile tradizionale
@Component({ selector: 'app-counter', standalone: true })
export class CounterComponentLegacy {
  @Input() initialValue = 0;
  @Output() valueChange = new EventEmitter();
}

// Stile moderno basato su Signals
@Component({ selector: 'app-counter', standalone: true })
export class CounterComponent {
  initialValue = input(0);                 // Signal, in sola lettura
  initialValueRequired = input.required(); // obbliga il chiamante a passarlo
  valueChange = output();           // tipizzato, senza dover importare EventEmitter

  // Con input() come Signal, puoi derivare stato reattivo direttamente:
  doubledInitial = computed(() => this.initialValue() * 2);
}

Avantazhi praktik i hyrjes së re input()/output() nuk është vetëm sintaksor: duke qenë Signal, ato integrohen automatikisht në grafikun e reaktivitetit këndor (veçanërisht i dobishëm në aplikacionet pa zona), dhe input.required() lëviz një gabim i cili më parë ishte zbuluar në kohën e ekzekutimit në një kontroll të verifikueshëm në kohën e kompilimit me lo kontroll i rreptë i shabllonit.

Niveli i lartë — Arkitekturë, Zbulim i Ndryshimit, Renderim, Performancë dhe Testim

Në nivelin e lartë, intervistuesi nuk po kërkon përkufizimin e duhur: ai po kërkon arsyetim. Pyetjet shpesh nuk kanë një përgjigje të vetme të saktë, por ato vlerësojnë nëse mund të argumentoni shkëmbim i informuar.

13. Si funksionon mekanizmi i zbulimit të ndryshimit të Angular dhe cili është ndryshimi midis strategjisë Default dhe OnPush?

Me strategjinë Default, çdo herë që Angular ekzekuton një lak ndryshimi zbulimi (i shkaktuar nga ngjarjet DOM, kohëmatësit, telefonatat e përfunduara HTTP, nëpërmjet Zone.js), çdo komponenti i pemës kontrollohet për të parë nëse lidhjet e shabllonit janë ndryshuar, pavarësisht se ku ka ndodhur ngjarja.

Me OnPush, Angular kontrollon një komponent vetëm kur: (1) a @Input()/ndryshimet e hyrjes së sinjalit me referencë (jo nga mutacioni i brendshëm i objektit), (2) një ngjarje DOM ndodh brenda tij, (3) një Observable për të cilën është lidhur nëpërmjet | async nxjerr një vlerë të re, ose (4) është shënuar në mënyrë eksplicite me markForCheck()/përditësimi i një sinjali që lexon.

@Component({
  selector: 'app-product-card',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  template: `{{ product().name }} — {{ product().price | currency }}`,
})
export class ProductCardComponent {
  product = input.required();
}

// ❌ Questo NON scatena il change detection su ProductCardComponent con OnPush,
// perché muta l'oggetto esistente invece di sostituirlo (stesso riferimento):
someProduct.price = 99;

// ✅ Questo sì, perché crea un nuovo riferimento:
this.products.update(list =>
  list.map(p => p.id === someProduct.id ? { ...p, price: 99 } : p)
);

Një përgjigje e lartë duhet të përmendë në mënyrë eksplicite konceptin e barazisë për referenca: ky është shkaku numër një i defektit "Unë përditësova të dhënat por ndërfaqja e përdoruesit nuk funksionon" përditësim" kur kaloni në OnPush pa adoptuar vazhdimisht modele të pandryshueshme aplikimin.

14. Çfarë është Angular pa zona dhe si ndryshon modeli i zbulimit të ndryshimeve?

Historikisht Angular përdor Zone.js për "monkey-patch" API-të asinkrone shfletues (ngjarje, kohëmatës, premtim, marrje) dhe e di automatikisht kur mund të jetë është i nevojshëm një cikël i zbulimit të ndryshimeve. Modeli pazone (i qëndrueshëm që nga Angular 18+) e heq plotësisht këtë varësi: Angular mbështetet ekskluzivisht në sinjal të dini saktësisht çfarë ka ndryshuar, pa pasur nevojë të kontrolloni të gjithë pemën "për çdo rast" sa herë që ndodh diçka asinkrone në sfond.

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';

bootstrapApplication(AppComponent, {
  providers: [provideZonelessChangeDetection()],
});

Përparësitë praktike: paketa më e vogël (Zone.js peshon rreth 30 KB), zbulimi i ndryshimit dukshëm më i synuar (janë vetëm komponentët që varen nga një sinjal i ndryshuar përditësuar), dhe korrigjime më të parashikueshme sepse çdo përditësim i ndërfaqes është i gjurmueshëm në a Ndryshimi i qartë i sinjalit, jo në një ngjarje të përgjithshme asinkrone të kapur "a ombrellë". Ana negative: bibliotekat e palëve të treta të datës që presin Zone.js (disa versionet e komponentëve të materialit, bibliotekat grafike) mund të kërkojnë a Manuali NgZone.run() për të vazhduar punën si duhet në pa zona.

15. Si do ta diagnostikonit dhe zgjidhni një problem të performancës për shkak të zbulimit të tepërt të ndryshimeve në prodhim?

Hapi i parë nuk është me hamendje: po matet me Angular DevTools, skedë Profiler. Duke regjistruar një ndërveprim problematik (p.sh. duke shtypur në një fushë kërkimi), Profiler shfaq një grafik me shirita ku çdo shirit është një komponent i kontrolluar në atë cikël — nëse një komponent që nuk ka lidhje me ndërveprimin shfaqet vazhdimisht, ai është sinjali që mungon OnPush ose që ka një model reaktiv të projektuar keq.

Rruga tipike e zgjidhjes, sipas rendit të ndikimit:

Aplikoni ChangeDetectionStrategy.OnPush për komponentët më të shtrenjtë "fletë" për t'u renderizuar, duke u siguruar që të dhënat rrjedhin në mënyrë të pandryshueshme.
Zëvendësoni mutacionet direkte të array-ve/objekteve me modele të pandryshueshme (spread, map/filter) ose kaloni te Signal, që e bëjnë barazinë me referencë automatike dhe korrekte.
Shtoni track të saktë (id-në unike, jo indeksin) në blloqet @for për të shmangur që Angular të shkatërrojë dhe rikrijojë nyje DOM pa nevojë kur një listë riorganizohet.
Vlerësoni miratimin e zoneless për të eliminuar ciklet e change detection të shkaktuara nga ngjarje asinkrone që nuk lidhen me ndërfaqen e dukshme.

Një përgjigje efektive Senior përmend gjithmonë Angular DevTools Profiler fillimisht hapi: Optimizimi sipas ndjenjës pa të dhëna reale të profilizimit është një gabim i zakonshëm edhe në nivel të lartë, dhe kushdo që kryen intervistën e vëren këtë menjëherë.

16. Cilat modele dizajni aplikoni më shpesh në një arkitekturë të ndërmarrjes Angular?

Model	Aplikim në Angular
Facade	Një shërbim që fsheh kompleksitetin e disa shërbimeve/store-ve themelore pas një API-je të thjeshtë për komponentët (p.sh. `CartFacade` që koordinon `CartService`, `PricingService`, `InventoryService`).
Repository	Një shërbim i dedikuar për qasjen në të dhëna (HTTP, cache lokale) që izolon komponentët nga detajet e zbatimit të burimit të të dhënave.
Strategy	Injektim i zbatimeve të këmbyeshme përmes `InjectionToken`, e dobishme për sjellje që ndryshojnë sipas mjedisit ose konfigurimit (p.sh. strategji të ndryshme pagese).
Smart/Dumb Component	Ndarja ndërmjet komponentëve "container" (menaxhojnë gjendjen dhe efektet anësore) dhe komponentëve "presentational" (marrin të dhëna përmes input, emetojnë ngjarje përmes output, pa varësi direkte nga shërbimet).
Adapter	Izolon formën e të dhënave të jashtme (API të palëve të treta) pas një mapimi drejt modeleve të brendshme të aplikacionit, kështu që një ndryshim i API-së së jashtme prek vetëm një pikë të kodit.

Një përgjigje e lartë dallon qartë kur çdo model shton vlerë dhe kur në vend të kësaj është mbiinxhinierim: prezantoni një Fasadë për një shërbim të vetëm të thjeshtë, për shembull për shembull, shton indirekt pa përfitime reale.

17. Si e strukturoni testimin e një aplikacioni kompleks Angular dhe çfarë kompensimesh mendoni?

Unë ndjek piramidën e testit : shumë teste të shpejta dhe të izoluara të njësisë (shërbim, tub, logjika e pastër e nxjerrë nga komponentët), një numër i moderuar i testeve të integrimit (komponentët me TestBed, duke verifikuar ndërveprimin real me shërbimet), dhe disa teste E2E synuar në flukset që janë vërtet kritike për biznesin (hyrja, arka), jo në secilën prej tyre faqe.

// Unit test: logica pura, veloce, nessuna dipendenza da Angular
describe('calculateDiscount', () => {
  it('applica correttamente uno sconto percentuale', () => {
    expect(calculateDiscount(100, 20)).toBe(80);
  });
});

// Integration test: componente reale con TestBed, verifica il comportamento visibile
describe('ProductCardComponent', () => {
  it('emette addToCart quando si clicca il pulsante', () => {
    const fixture = TestBed.createComponent(ProductCardComponent);
    fixture.componentRef.setInput('product', mockProduct);
    fixture.detectChanges();

    let emitted: Product | undefined;
    fixture.componentInstance.addToCart.subscribe(p => (emitted = p));
    fixture.debugElement.query(By.css('[data-testid="add-btn"]')).nativeElement.click();

    expect(emitted).toEqual(mockProduct);
  });
});

Kompensimi kryesor që diskutoj gjithmonë në biseda: E2E-të japin besimin maksimal real (ata e testojnë aplikacionin ashtu siç do ta përdorte një përdorues) por janë të ngadalshëm dhe më të brishtë; testet e njësisë ata janë shumë të shpejtë, por nuk kapin probleme integrimi. Marrëdhënia e duhur nuk rregullohet, varet nga kritika e domenit - një rrjedhë pagese meriton më shumë mbulim E2E se një faqe informacioni statik.

18. Çfarë është tundja e pemëve dhe si ndikojnë në të zgjedhjet arkitekturore?

tundja e pemëve është procesi me të cilin bundler (esbuild në Angular 17+/20+) eliminon kodin që është eksportuar, por kurrë nuk është importuar nga paketa përfundimtare ose përdorur, duke zvogëluar madhësinë e JavaScript-it të shkarkuar nga shfletuesi.

Zgjedhjet arkitekturore ndikojnë në atë në një mënyrë konkrete: të pavarura komponentët me importe të qarta i bëjnë varësitë statike dhe i analizueshëm, duke përmirësuar dridhjen e pemëve në krahasim me NgModule i vjetër me deklarata Deklarata “ombrellë” që shpesh kishin më shumë rëndësi se ç’duhej. Edhe atë skedari fuçi (index.ts i cili rieksporton një modul të tërë) mund të përkeqësoni lëkundjen e pemëve nëse grupi nuk mund të përcaktojë në mënyrë statike se cilat eksporte janë përdorur në të vërtetë, duke çuar në përfshirjen e kodit të vdekur në paketën përfundimtare.

// ❌ Import "largo": può impedire il tree-shaking se lodash non è in formato ESM puro
import _ from 'lodash';
const chunks = _.chunk(array, 3);

// ✅ Import mirato: il bundler include SOLO la funzione realmente usata
import chunk from 'lodash/chunk';
const chunks = chunk(array, 3);

19. Si do të zbatonit caching nga ana e klientit për të reduktuar thirrjet e tepërta HTTP në një mënyrë të shkallëzuar?

Zgjidhja më elegante në Angular moderne është një HttpInterceptor i cili përgjon kërkesat GET dhe kthen një përgjigje të memorizuar kur është e disponueshme dhe jo skaduar, veçanërisht duke e pavlefshme cache-në kur ndryshojnë të dhënat themelore.

@Injectable()
export class CacheInterceptor implements HttpInterceptor {
  private cache = new Map; expiry: number }>();

  intercept(req: HttpRequest, next: HttpHandler): Observable> {
    if (req.method !== 'GET') return next.handle(req);

    const cached = this.cache.get(req.urlWithParams);
    if (cached && cached.expiry > Date.now()) {
      return of(cached.response.clone());
    }

    return next.handle(req).pipe(
      tap(event => {
        if (event instanceof HttpResponse) {
          this.cache.set(req.urlWithParams, {
            response: event,
            expiry: Date.now() + 60_000, // 60 secondi
          });
        }
      }),
    );
  }
}

Pika që dallon një përgjigje të lartë: të dish çfarë të bësh mut dhe çfarë jo . Të dhënat e katalogut rrallë ndryshojnë dhe janë të përshtatshme për ruajtjen e memories; të dhëna specifike e përdoruesit të vërtetuar kërkojnë një çelës memorie që përfshin identitetin e përdoruesit (ose duhet të përjashtohet fare), përndryshe rrezikoni t'i tregoni të dhënat e një përdoruesi tjetrit - një gabim sigurie, jo vetëm një gabim i performancës.

Niveli i Ekspertit / Udhëheqësit — Arkitekturat e Ndërmarrjeve, Shkallueshmëria, Microfrontend, SSR dhe Siguria

Pyetjet e ekspertëve/udhëheqësve rrallë kanë një përgjigje unike "të drejtë". Ata vlerësojnë aftësinë për të argumentoni një kompromis, mbroni një vendim me të dhëna të forta dhe kuptoni se kur Zgjidhja "më e sofistikuar" është në fakt ajo e gabuar për kontekstin.

20. Kur ka kuptim të adoptohet një arkitekturë mikrofrontale kundrejt një monoliti këndor modular dhe cilat janë kompensimet reale?

Mikrofrontet kanë kuptim kur ekziston një problem i vërtetë organizativ, jo vetëm teknike: ekipe të shumta që duhet të vendosen në mënyrë të pavarur, rafte ose lëshime Këndore të ndryshme midis pjesëve të aplikacionit, ose nevoja për të izoluar plotësisht cikli i lëshimit të një seksioni kritik nga pjesa tjetër.

Pamja	Modular Monolit	Microfrontend
Kompleksiteti operacional	I ulët — një ndërtim, një vendosje	I lartë — orkestrim, versionim, kontrata ekipore
Dislokime të pavarura	Jo	Po, për ekip/seksion
Dublikim i varësive të kohës së ekzekutimit	Asnjë	Rreziku konkret (kopje të shumta të Angular/RxJS) nëse nuk menaxhohet me module federation
Konsistencë UX midis seksioneve	Natyrale	Kërkon qeverisje eksplicite (sistem i përbashkët dizajni)
Inboarding i zhvilluesve të rinj	Më e thjeshtë, një repo/arkitekturë e vetme	Më komplekse, duhet të kuptosh kufijtë midis aplikacioneve

Pozicioni im në një intervistë: një monolit modular i strukturuar mirë me kufijtë e veçorive qartë (i ngarkuar me dembel, me ndërfaqe të qarta midis moduleve) zgjidh shumicën e problemet që ekipet mendojnë se duhet t'i zgjidhin me mikrofronte, me një fraksion të kompleksiteti operacional. Microfrontends janë një mjet organizativ për çështjet e shkallës e ekipeve, jo një "arkitekturë më e mirë" në mënyrë abstrakte - dhe duhet të miratohet vetëm kur kostoja i koordinimit ndërmjet ekipeve tashmë tejkalon koston e kompleksitetit teknik shtesë.

21. Si do ta hartonit strategjinë SSR/hidratimi për një aplikacion Angular të ndërmarrjes me kërkesa të rrepta SEO?

Unë do të filloja nga Angular Universal me sigurojClientHydration() për hidratimi i plotë, duke vlerësuar hidratimin në rritje (withIncrementalHydration()) për seksione të panevojshme të ngarkuara me faqe në paraqitjen e parë (grafika, redaktues të tekstit të pasur, harta), të kombinuara me @defer për shtyni ngarkimin e tyre derisa të hyjnë në portin e shikimit.

// app.config.server.ts
import { provideServerRendering } from '@angular/platform-server';
import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';

export const serverConfig = [
  provideServerRendering(),
  provideClientHydration(withIncrementalHydration()),
];

<!-- Il componente si idrata solo quando entra in viewport, non al bootstrap iniziale -->
@defer (on viewport) {
  <app-heavy-dashboard-chart [data]="chartData()" />
} @placeholder {
  <div class="chart-skeleton"></div>
}

Për kërkesat e rrepta të SEO, pjesa kritike arkitekturore nuk është vetëm paraqitja: ju duhet një SeoService i centralizuar që përditëson në mënyrë dinamike titullin, meta përshkrimi, kanonik dhe JSON-LD gjatë paraqitje nga ana e serverit (jo pas, kur është shumë vonë për zvarritësit që nuk ekzekutojnë JavaScript), plus një strategji të qartë për menaxho kodin që akseson API-të vetëm për shfletuesin (dritare, dokument) pas një kontrolli isPlatformBrowser(), për të shmangur përplasjet gjatë paraqitjes anën e serverit.

22. Cilat masa sigurie janë thelbësore në një aplikacion të ndërmarrjes Angular?

XSS (Cross-Site Scripting): Angular sanitizon automatikisht bindings [innerHTML]/interpolimin, por bypassSecurityTrustHtml() duhet përdorur vetëm mbi përmbajtje vërtet të besuar — kurrë mbi hyrje të papavlerësuar nga përdoruesi.
CSRF (Falsifikim i Kërkesës Ndër-Site): HttpClientXsrfModule trajton automatikisht modelin double-submit-cookie, por vetëm nëse backend-i vendos në mënyrë korrekte cookie-n XSRF-TOKEN.
Politika e sigurisë së përmbajtjes (CSP): Titulli i konfiguruar nga ana e serverit që kufizon burimet nga të cilat mund të ngarkohen skriptet/stilet, duke zbutur ndikimin edhe të XSS të suksesshëm.
Menaxhimi i tokenit JWT: tokeni i aksesit jetëshkurtër, rifreskimi i tokenit i menaxhuar në anën e serverit (asnjëherë i lexueshëm nga JavaScript nëse është e mundur, nëpërmjet httpOnly cookie) dhe pavlefshmëri reale në dalje.
Vlerësimi nga ana e klientit si UX, jo siguria: çdo vërtetim nga ana e klientit duhet të përsëritet gjithmonë në anën e serverit — një klient mund të manipulohet me mjete zhvillimi.

Një përgjigje eksperti/udhëheqësi duhet të theksojë në mënyrë eksplicite se siguria nga ana e klientit është një mbrojtje në thellësi, jo e vetmja linjë mbrojtjeje: kush mendon se vërteton/ mjafton të mbrosh vetëm anën këndore ka një hendek serioz konceptual për këtë niveli.

23. Si do ta menaxhonit versionimin dhe migrimin në rritje të një baze kodi të trashëguar Angular në të pavarur/sinjale në një ekip prej 20+ zhvilluesish?

Jo me një "rishkrim të madh" - shumë i rrezikshëm për një ekip me atë madhësi. Strategjia që unë miratoj është migrimi inkremental sipas kufijve të veçorive: Angular mbështet bashkëjetesën e NgModule dhe komponentëve të pavarur në të njëjtën aplikacion, kështu që ju mund të migroni një modul në të njëjtën kohë, duke verifikuar që çdo hap është të vendosshme në mënyrë të pavarur në prodhim.

Automatizoni hapin e parë me gjeneratorin zyrtar ng generate @angular/core:standalone, i cili konverton automatikisht komponentët/direktivat/pipe-t.
Vendosni një kufi të qartë: veçoritë e reja shkruhen vetëm në standalone menjëherë, për të parandaluar vazhdimin e rritjes së borxhit teknik gjatë migrimit.
Migroni modulet e vjetra në rendin e rritjes së "rrezes së ndikimit" — veçori të izoluara me trafik të ulët në fillim, pastaj në mënyrë progresive thelbin e aplikacionit.
Futni sinjalet paralelisht, por veçmas nga migrimi në të pavarur: ato janë dy boshte ortogonale, nuk ka nevojë t'i bëni së bashku dhe përzierja e tyre rrit rrezikun për çdo ndryshim të vetëm.

Pika që kërkon një intervistues kryesor: aftësia për të renditur rrezikun, jo vetëm për të mësoni rreth mjeteve të migrimit. Komunikoni qartë ekipit pse po migroni gradualisht (dhe jo të gjitha menjëherë) është po aq pjesë e punës sa shkrimi i kodit.

24. Çfarë kriteresh përdorni për të vendosur midis NgRx, një dyqani të thjeshtë sinjalesh me porosi ose asnjë bibliotekë të menaxhimit shtetëror?

Kriter	Pa bibliotekë (Sinjal/shërbime)	Sinjal i personalizuar i lehtë Dyqani	NgRx
Kompleksiteti i domenit	I ulët/mesatar	Mesatar	I lartë, me shumë veprime të ndërlidhura
Nevoja për korrigjimin e gabimeve në udhëtim në kohë	Jo	Jo	Po
Ekipi i mësuar me modelet Redux	Nuk kërkohet	Nuk kërkohet	Avantazh nëse tashmë prezent
Pllakë bojleri e pranueshme	Minimal	Moderuar	I rëndësishëm, i zbutur nga schematics zyrtare
Testueshmëria e gjendjes së izoluar	Mirë	Shkëlqyeshëm	Shkëlqyeshëm, me modele të konsoliduara

Kriteri im i vendimmarrjes në një intervistë: Unë gjithmonë nis nga opsioni më i thjeshtë (Sign in një shërbim providedIn: 'root') dhe unë e evoluoj atë vetëm kur shfaqen simptoma konkrete — kopjoni logjikën e gjendjes midis veçorive, nevojës reale për korrigjim të avancuar ose një ekipi që tashmë funksionon mirë me modelet Redux në projekte të tjera. Prezantoni NgRx "si parazgjedhje" në secilën projekti i ri është një zgjedhje që tenton të ngadalësojë zhvillimin fillestar pa përfitime proporcionale derisa kompleksiteti aktual ta justifikojë atë.

25. Si do ta balanconit shpejtësinë e zhvillimit, performancën dhe mirëmbajtjen në një vendim arkitektonik me afate të rrepta?

Një shembull konkret i një shkëmbimi real: një ekip duhet të ofrojë një panel me grafikë interaktive në dy javë. Biblioteka e grafikëve me performancë më të mirë kërkon tre ditë integrim dhe konfigurim i avancuar; një bibliotekë më e thjeshtë, më pak e optimizuar por me dokumentacion i shkëlqyer, merr gjysmë dite.

Vendimi që do të argumentoja: përdorni bibliotekën e thjeshtë tani, por izolojeni atë pas një ndërfaqe/përshtatës i brendshëm i qartë (mos e thirrni drejtpërdrejt nga secili komponent), si kjo se nëse në të ardhmen metrikat reale (jo hipotetike) të performancës tregojnë se bibliotekë më e sofistikuar, zëvendësimi prek vetëm një pikë të kodit në vend që të jetë një rishkrim i përhapur.

Parimi i përgjithshëm që unë komunikoj gjithmonë në biseda: shpejtësia e dorëzimit dhe cilësia arkitekturore nuk është gjithmonë në konflikt — shpesh konflikti i vërtetë është ndërmjet shpejtësia e dorëzimit dhe zgjedhjet e parakohshme të pakthyeshme. Investoni kohë për të ruajtur një vendim i kthyeshëm (nëpërmjet një shtrese abstraksioni minimal, jo të tepruar) lejon për të përmbushur afatin pa kompromentuar mirëmbajtjen në të ardhmen. Vërtet vendime shtrenjtë për t'u ndryshuar më vonë (skema e bazës së të dhënave, kontrata publike API, zgjedhja e kornizë) meritojnë më shumë kohë analize; vendime lehtësisht të kthyeshme (cila bibliotekë të stilistëve grafikë) nuk e meritojnë atë, dhe këmbëngulja për ta "marrë menjëherë" është shpesh humbje kohe krahasuar me afatin.

Si të përgatitemi më mirë për një intervistë këndore

Mos mësoni përmendësh vetëm përkufizimet: Për secilin koncept, pyesni veten "çfarë problemi të vërtetë parandalon njohja e kësaj?" — është pikërisht lloji i përgjigjes që dallon një kandidat solid.
Praktikoni me kod real, jo vetëm teori: ndërtoni një projekt të vogël që përdor sinjalin, OnPush, ngarkimin dembel dhe të paktën një test — njohuritë praktike shfaqen gjithmonë në pyetjet vijuese.
Përgatitni shembuj konkretë nga puna juaj: për pyetjet e të moshuarve/ekspertëve, të kesh një shembull real (madje edhe një të thjeshtuar) të një kompromis me të cilin ke përballur vlen më shumë se një përgjigje teorike e patëmetë.
Studioni gabimet e zakonshme, jo vetëm praktikat më të mira: duke ditur çfarë shkon keq kur aplikohet gabim një model (p.sh. OnPush me mutacione të drejtpërdrejta) demonstron kuptim më të thellë sesa citimi i thjeshtë i rregullit.
Qëndroni të përditësuar me versionet e fundit: Signal, komponentët standalone, zoneless dhe control flow-u i ri (@if/@for) tashmë janë standardi i pritshëm në një intervistë Angular në 2026, jo njohuri opsionale.

Përfundim

Këto 25 pyetje mbulojnë rrugën e rritjes natyrore të një zhvilluesi Frontend/Angular: nga themelet e HTML/CSS/JavaScript/TypeScript, përmes RxJS dhe menaxhimit të shtetit, deri në vendimet arkitekturore që një Udhëheqës duhet të jetë në gjendje të motivojë përpara një ekipi ose individi palët e interesuara. Pavarësisht nëse jeni duke u përgatitur për një intervistë apo për të kryer një, tema e përbashkët është gjithmonë e njëjta gjë: të kuptuarit pse një zgjedhje teknike është e duhura në një kontekst specifike, mos përsërit një rregull nga kujtesa.

Nëse jeni duke u përgatitur për një intervistë të lartë ose eksperte, këshilla më konkrete është kjo: zgjidhni tre ose katër vendime të vërteta arkitekturore që keni marrë (madje edhe ato të papërsosura, edhe në një projekt personale) dhe përgatituni t'u tregoni atyre në detaje - çfarë keni zgjedhur, çfarë alternativa keni të hedhura dhe pse, çfarë do të bënit ndryshe sot. Është një lloj përgjigje që asnjë përkufizimi i tekstit shkollor mund të zëvendësojë.