Saturs[Paslēpt][Rādīt]
- 1. Ko tu saproti ar REST?
- 2. Ko jūs domājat ar REST API?
- 3. Kas īsti ir URI?
- 4. Kādas ir RESTful Web Services īpašības?
- 5. Kādi ir ATPŪTAS pamatprincipi?
- 6. Norādiet HTTP metodes, kuras atbalsta REST.
- 7. Aprakstiet ierobežojumus, ko nosaka konsekventa saskarne.
- 8. Kas īsti ir REST resurss?
- 9. Ko jums nozīmē JAX-RS?
- 10. Kas atšķir AJAX un REST vienu no otra?
- 11. Vai varat uzskaitīt dažus RESTful tīmekļa pakalpojumu trūkumus?
- 12. Ar ko PUT un POST tehnikas atšķiras viena no otras?
- 13. Kā jūs testējat RESTful tīmekļa pakalpojumus?
- 14. Aprakstiet REST API reālajā pasaulē.
- 15. Kā darbojas mikropakalpojumu arhitektūra?
- 16. Kas īsti ir kešatmiņa?
- 17. Aprakstiet lietderīgo slodzi.
- 18. Atšķirt SOAP no REST?
- 19. Vai transporta slāņa drošības protokolu (TLS) var izmantot kopā ar REST?
- 20. Idempotentās metodes: kas tās ir? Kā tas attiecas uz RESTful tīmekļa pakalpojumu pasauli?
- 21. Kāda ir HTTP pamata autentifikācijas funkcionalitāte?
- 22. Vai, jūsuprāt, GraphQL ir labākā izvēle mikropakalpojumu arhitektūras izveidei?
- 23. Kādas ir galvenās atšķirības starp drošo un idempotento HTTP metodēm?
- 24. Ko JAX-RS API nozīmē RESTful Root Resource Classes?
- 25. Kas īsti ir Pastnieks, un kāpēc tas tiek izmantots?
- 26. Kā REST API tiek uzturētas drošībā?
- Secinājumi
REST evolūcija ir padarījusi API neticami pieejamas, vienlaikus atklājot visu to spēku un potenciālu. REST API ir viegli izveidot un saglabāt kešatmiņā to uz resursiem orientētās arhitektūras dēļ.
Turklāt visu laiku RESTful API bija priekšteči citiem nozīmīgiem notikumiem, piemēram, mākoņdatošanas un mikropakalpojumu dizainam.
Tāpēc nevajadzētu būt pārsteigumam, ka REST API izstrādātāji mūsdienās ir pieprasīti, ņemot vērā to, kā viņi nodrošina konkurētspēju uzņēmumiem, kas izmanto RESTful pakalpojumus. REST API ir populāra dizaina tendence.
Daudzi IT uzņēmumi vēlas zināšanas par REST API programmatūras izstrādātāji un jautājiet par to tehniskajās intervijās.
Šeit ir daži no tipiskākajiem REST API interviju jautājumiem, kas palīdzēs jums būt gatavam intervijām dažādās firmās, ja vēlaties strādāt REST API izstrādes jomā.
1. Ko tu saproti ar REST?
REST ir arhitektūras paradigma tīmekļa lietojumprogrammu izstrādei, kuru pamatā ir hiperteksta pārsūtīšanas protokols (HTTP).
REST nosaka noteiktus standartus, kuriem tīmekļa pakalpojumiem jāatbilst, lai tos uzskatītu par RESTful. Šie ieteikumi garantē, ka pieprasījumi un resursi tiek ātri un efektīvi pārsūtīti starp klientu un serveri, izmantojot standartizētus HTTP protokolus.
2. Ko jūs domājat ar REST API?
Programmatūras un programmatūras saite, kas pazīstama kā lietojumprogrammu saskarne, nodrošina saziņu un datu koplietošanu starp citādi neatkarīgām programmām. Piemēram, ziņu vietne var izmantot Twitter API, lai automātiski atklātu atbilstošus tvītus un integrētu tos ziņu stāstos.
API, kas atbilst REST principiem, ir pazīstama kā REST API, dažkārt pazīstama arī kā RESTful API. REST API katrs datu fragments tiek apstrādāts kā resurss, un tam tiek piešķirta atsevišķa standarta resursa identitāte (URI).
Piemēram, Twitter API padara katru tvītu par izgūstamu resursu, kas ir pieejams klientiem. Twitter API lietotāji var izmantot, lai publicētu tvītus un veiktu citus vietnes uzdevumus.
3. Kas īsti ir URI?
A datortīkls uz resursu var atsaukties, izmantojot URI vai vienotu resursa identifikatoru. Tas kalpo kā līdzeklis, lai atdalītu vienu resursu no cita. Avoti var būt vai nebūt tiešsaistē.
Pateicoties to standarta struktūrai, URI ir viegli izveidot savienojumu ar pat dažāda veida resursiem. Resursa atrašanās vieta vai nosaukums ir iekļauts URI kopā ar rakstzīmju virkni.
URI veido ceļš, shēma, vaicājums un citi elementi, bet tas neietver protokolu.
Izmantojot protokolu, vietrāži URL (vienotie resursu meklētāji) tiek izmantoti, lai atrastu resursus internetā vai caur to tiem piekļūt.
4. Kādas ir RESTful Web Services īpašības?
- Klienta-servera paradigma ir pakalpojuma pamats.
- Pakalpojums var piekļūt resursiem, izmantojot URI.
- Pakalpojums izmanto HTTP protokolu, lai iegūtu datus/resursus, izpildītu vaicājumus un veiktu citus uzdevumus.
- Ziņapmaiņa ir tās metodes nosaukums, ko izmanto, lai sazinātos starp klientu un serveri.
- Šie pakalpojumi var arī ieviest REST arhitektūras modeli, izmantojot SOAP pakalpojumus.
- Lai samazinātu servera zvanus pēc tāda paša veida atkārtotiem pieprasījumiem, šie pakalpojumi izmanto arī kešatmiņas ideju.
5. Kādi ir ATPŪTAS pamatprincipi?
REST API ir jāatbilst pieciem kritērijiem:
Klienta un servera atsaiste: saziņai starp klientu un serveri var izmantot tikai virkni pieprasījumu un atbilžu. Tikai klienti un serveri var nosūtīt attiecīgi pieprasījumus un atbildes. Šī vienkāršā ideja ļauj abām pusēm darboties neatkarīgi viena no otras.
Vienots interfeiss: visiem klienta un servera savienojumiem ir jābūt vienotam protokolam. Šis REST protokols ir HTTP. Tā kā katra lietojumprogramma pieprasa un sūta datus, izmantojot vienu un to pašu valodu, konsekvents interfeiss padara integrāciju vienkāršāku.
Bezvalstnieks: serveris nesaglabā nekādus iepriekšējo pieprasījumu vai atbilžu ierakstus bezvalsts saziņā. Katrs pieprasījums un atbilde sniedz visu nepieciešamo informāciju, lai pabeigtu apmaiņu. Bezvalsts saziņa palielina ātrumu, ietaupa atmiņu un samazina servera slodzi. Turklāt tas novērš iespēju, ka pieprasījums neizdosies nepilnīgu datu dēļ.
Slāņu sistēma: serveri, kas atrodas starp klientu un API serveri, tiek saukti par slāņiem. Šie papildu serveri nodrošina dažādus pakalpojumus, piemēram, surogātpasta noteikšanu un ātruma optimizēšanu. REST slāņi ir modulāri, kas nozīmē, ka tos var pievienot un dzēst, neietekmējot saziņu starp klientu un API serveri.
Saglabājams kešatmiņā: klienti var saglabāt kešatmiņā jebkurus resursus, lai palielinātu ātrumu, ja servera atbildes norāda, vai resurss ir vai nav kešatmiņā.
Kodēšana pēc pieprasījuma: atbildot uz API, klientiem var nosūtīt izpildāmu datora kodu. Pēc tam klienta lietojumprogramma var palaist kodu savā aizmugurē.
6. Norādiet HTTP metodes, kuras atbalsta REST.
REST atbalstītās HTTP metodes ir:
- GET: šī metode pieprasa resursu norādītajā URL. Pieprasījuma pamattekstu nevajadzētu iekļaut, jo tas tiks ignorēts. To varētu būt iespējams saglabāt kešatmiņā lokāli vai serverī.
- POST: šī metode nosūta datus pakalpojumam apstrādei, un pakalpojumam parasti ir jāatgriež jauns vai mainīts resurss.
- PUT: resurss tiek atjaunināts pieprasījuma URL.
- DZĒST: resurss tiek izdzēsts pieprasījuma URL.
- Opcijas: tas identificē atbalstītās metodes.
- HEAD: tiek atgriezti pieprasījuma URL metadati.
7. Aprakstiet ierobežojumus, ko nosaka konsekventa saskarne.
Lai atdalītu klientu no servera, ir nepieciešama konsekventa saskarne.
Lai panāktu konsekventu saskarni, ir nepieciešami šādi četri ierobežojumi:
- Resursu identifikācija: klientu pieprasījumos ir jāizmanto standarta resursu ID, lai identificētu resursus (URI).
- Resursu manipulācijas, izmantojot šos attēlojumus: klientiem ir visa nepieciešamā informācija, lai varētu mainīt resursa stāvokli, kad viņi saņem resursu attēlojumu no servera.
- Pašaprakstoši ziņojumi: ziņojumos ir visi metadati un cita informācija, kas nepieciešama, lai saņēmējs tos saprastu.
- Hipervide kā lietojumprogrammas stāvokļa dzinējs: klienta un servera saziņas kanāls ir hipervide, piemēram, HTML, un klientiem nav nepieciešama API specifiska dokumentācija, lai saprastu servera atbildes.
8. Kas īsti ir REST resurss?
Resursi ir galvenās RESTful tīmekļa pakalpojuma sastāvdaļas REST arhitektūrā. Tajos ir iekļauta visa būtiskā informācija, kurai API klientam ir jāpiekļūst.
Jebkura veida resursiem, piemēram, HTML lapai, attēlam, video vai jebkam citam, kas nepieciešams API darbībai, var piekļūt, izmantojot serveri klienta-servera sistēmā.
Resursi tiek identificēti ar vienotu resursu identifikatoru. Teksts, JSON vai XML ir pieņemami resursu attēlojumi. Ņemot to vērā, attēlojuma formātam nav ierobežojumu.
9. Ko jums nozīmē JAX-RS?
Ir vienkāršāk izveidot RESTful tīmekļa pakalpojumus Java, pateicoties Java API RESTful tīmekļa pakalpojumiem, ko bieži sauc par JAX-RS. Izstrādātāji var aprakstīt resursus un ar tiem veicamās darbības, izmantojot piedāvātās anotācijas.
10. Kas atšķir AJAX un REST vienu no otra?
Ajax:
- Ajax ir tehnoloģiju grupa, kas ļauj dinamiski atjaunināt lietotāja interfeiss elementus, nepārlādējot lapu.
- Ajax noņem asinhrono saziņu starp klientu un serveri.
ATPŪTAS:
- REST pieprasa saziņu starp serveri un klientu.
- Resursu izmantošana ir svarīga URL struktūrai un pieprasījuma/atbildes modelim, ko izmanto REST.
11. Vai varat uzskaitīt dažus RESTful tīmekļa pakalpojumu trūkumus?
Sesijas nevar turpināt, jo dienesti ievēro bezvalstniecības jēdzienu. (Klients ir atbildīgs par sesijas ID nodošanu sesijas simulācijas laikā.)
Drošības ierobežojumi nav REST pamatelementi. Protokoli, kas to izmanto, manto drošības pasākumus. Tāpēc ir svarīgi ievērot piesardzību, ieviešot drošības pasākumus, piemēram, integrējot uz SSL/TLS balstītas autentifikācijas.
12. Ar ko PUT un POST tehnikas atšķiras viena no otras?
PUT:
- PUT atbildēm nav kešatmiņas.
- Idempotents (ti, vairāki pieprasījumi dos vienu un to pašu rezultātu)
- pieprasījuma lietderīgā slodze atjaunina vai aizstāj mērķa resursu.
POST:
- idempotents nav (ti, vairāki pieprasījumi dos viena un tā paša resursa daudzkārtējus)
- Tīmekļa serveris apstrādā pieprasījuma lietderīgo slodzi, pamatojoties uz paredzēto resursu.
- Ja ir iekļauta atbilstošā kešatmiņas kontroles galvene, POST atbildes var saglabāt kešatmiņā.
13. Kā jūs testējat RESTful tīmekļa pakalpojumus?
RESTful tīmekļa pakalpojumu testēšanai var palīdzēt vairāki rīki, tostarp Swagger un Postman. Pieprasījuma parametru, piemēram, vaicājuma parametru, galvenes un atbilžu galvenes, pārbaude ir iespējama, pateicoties pēdējo funkciju pārpilnībai.
Pastnieku var izmantot, lai veiktu pieprasījumus galapunktiem un parādītu rezultātus. Un no šīm atbildēm var izveidot XML un JSON.
Gan Postman, gan Swagger nodrošina ļoti salīdzināmas funkcijas. No otras puses, Swagger piedāvā arī tādas iespējas kā galapunkta dokumentācija.
14. Aprakstiet REST API reālajā pasaulē.
- Ceļojumu un biļešu pārdošanas vietnes var izmantot lidojumu laikus un cenas, ko aviosabiedrības dara pieejamus, izmantojot API.
- Lai kartēšanas un navigācijas lietotnes (piemēram, Google Maps) tās varētu izmantot, sabiedriskā transporta aģentūras savus datus bieži dara publiski pieejamus reāllaikā, izmantojot API.
- Laikapstākļu lietojumprogrammas izmanto atvērtas API, kas apmainās ar laikapstākļu datiem, lai parādītu laikapstākļu informāciju.
- Izstrādātāji var piekļūt Google Maps kartēšanas datiem, izmantojot vairākas tās mitinātās API. Šīs API izmanto izstrādātāji, lai savās lietotnēs un vietnēs iegultu dinamiskas kartes.
15. Kā darbojas mikropakalpojumu arhitektūra?
- Pieprasījumus sūta dažādi klienti, izmantojot dažādas ierīces.
- Pēc klientu identitātes apstiprināšanas identitātes nodrošinātāji nodrošina drošības marķierus.
- Klientu pieprasījumus pārvalda API vārteja.
- Viss sistēmas materiāls tiek saglabāts kā statisks saturs.
- Pārvaldības rīks pārbauda pakalpojumu līdzsvaru mezglos un visus defektus.
- Atklāt saziņas ceļu starp mikropakalpojumiem palīdz pakalpojumu atklāšana.
- Datu centri un starpniekserveri veido izkliedētas tīkla sistēmas, ko sauc par satura piegādes tīkliem.
- Attālinātie pakalpojumi nodrošina piekļuvi informācijai no attāluma.
16. Kas īsti ir kešatmiņa?
Prakse īslaicīgi kaut kur saglabāt servera atbildes kopiju (piemēram, datora atmiņā), lai vēlāk tai ātrāk piekļūtu, tiek dēvēta par kešatmiņu.
Kešatmiņa uzlabo servera ātrumu, izmantojot REST API, samazinot darba apjomu, kas serverim jāveic, lai izpildītu pieprasījumu. Lietojumprogrammas, kas izmanto API, darbojas ātrāk, pateicoties kešatmiņai, jo tām nav jāiesniedz jauns pieprasījums katru reizi, kad ir nepieciešams resurss.
HTTP atbildes galvenes laukā Cache-Control ir informācija par to, cik ilgi klients var saglabāt resursu kešatmiņā, pirms tam atkal ir jāpiekļūst.
17. Aprakstiet lietderīgo slodzi.
Lietderīgā slodze REST attiecas uz HTTP atbildes pamattekstā ietverto informāciju. Klients izmantoja GET paņēmienu, lai pieprasītu attiecīgos datus.
Dokuments, kurā ir ietverts tvīta teksts un visi nepieciešamie faili tvīta ievietošanai vietnē, tiks iekļauts lietderīgajā slodzē, piemēram, ja Twitter API prasīsiet konkrētu tvītu. Turklāt lietderīgo slodzi var iekļaut HTTP pieprasījumā, izmantojot POST metodi.
18. Diferencēt SOAP Vs REST?
- Atšķirībā no SOAP, kas var apstrādāt tikai XML, REST nodrošina plašāku resursu formātu klāstu, tostarp XML, tekstu, HTML, attēlus, video un citus.
- Ja tiešsaistes lietojumprogrammām drošība ir ļoti svarīga, noder SOAP. REST nevar izmantot, ja darījumi ir jāpabeidz droši, jo tas nav īpaši drošs.
- Tā kā SOAP ir tikai protokols, REST to var izmantot savos tīmekļa pakalpojumos, bet ne otrādi.
- Lai gan REST ir tikai arhitektūras modelis, ko izmanto, lai izstrādātu tīmekļa pakalpojumus, un tas atbilst noteiktiem ierobežojumiem, piemēram, klienta un servera iestatīšanai, bezpavalstniecībai, kešatmiņā ievietojamai atbildei, slāņveida sistēmām un konsekventai saskarnei, SOAP ir protokols, kas darbojas saskaņā ar noteiktiem standartiem, kas ir stingri jāievēro. uz.
- Kamēr REST izmanto universālos resursu identifikatorus (URI), SOAP izmanto pakalpojumu saskarnes, lai nodrošinātu savas iespējas klientu lietojumprogrammām. REST ir mazāks joslas platums nekā SOAP, jo SOAP ziņojumi ir vairāk informācijas.
19. Vai transporta slāņa drošības protokolu (TLS) var izmantot kopā ar REST?
Patiesībā mēs varam. REST klienta un servera sakari tiek šifrēti, izmantojot TLS, un protokols klientiem sniedz arī iespēju autentificēt serverus.
Tā kā tas ir drošligzdu slāņa aizstājējs, tas tiek izmantots drošai saziņai (SSL). RESTful tīmekļa pakalpojumu ieviešana ir veiksmīga ar HTTPS, jo tā efektīvi sadarbojas gan ar TLS, gan SSL.
REST pārmanto tā ieviestā protokola īpašības, kas šeit ir jāņem vērā. Tā rezultātā drošības aizsardzība ir atkarīga no REST izmantotā protokola.
20. Idempotentās metodes: kas tās ir? Kā tas attiecas uz RESTful tīmekļa pakalpojumu pasauli?
Ja URI ir vienāds, dažām HTTP metodēm pieprasījumā ir tāda pati ietekme uz serveri neatkarīgi no tā, vai tās tiek piegādātas vienu vai vairākas reizes. Idempotenti paņēmieni ir pazīstami kā tie.
Piemēram, neatkarīgi no tā, cik reižu tiek palaists URI, izmantojot GET metodi, serverim vienmēr būs tāds pats rezultāts. Idempotentās metodes ietver GET, PUT un PATCH, lai nosauktu dažus.
Idempotentās HTTP metodes ir dažas no tām, kuras izmanto RESTful tīmekļa lietojumprogrammas. Tie ir nepieciešami, lai nodrošinātu RESTful tīmekļa pakalpojumu darbību konsekvenci.
Klienti, kas izmanto REST API, var pieļaut koda kļūdas, kas liek REST API veikt nejauši atkārtotus pieprasījumus. Šie zvani var ļaunprātīgi izmantot resursus.
21. Kāda ir HTTP pamata autentifikācijas funkcionalitāte?
Izmantojot pamata autentifikāciju kā daļu no API, lietotājam ir jāiesniedz lietotājvārds un parole, ko pārlūkprogramma saista formā “lietotājvārds: parole” un kodē base64.
Katrā HTTP pieprasījumā no pārlūkprogrammas kodētā vērtība tiek piegādāta kā galvenes “Autorizācija” vērtība. Tā kā akreditācijas dati ir tikai kodēti, ieteicams izmantot šo veidlapu, sūtot HTTPS pieprasījumus, jo tie nav droši un tos var pārtvert ikviens, ja netiek izmantoti drošības protokoli.
22. Vai, jūsuprāt, GraphQL ir labākā izvēle mikropakalpojumu arhitektūras izveidei?
Mikropakalpojumi un GraphQL lieliski sader, jo GraphQL jūsu mikropakalpojumu arhitektūru slēpj noslēpumā no jūsu klientiem.
Sākot no priekšpuses, jūs vēlaties, lai visi jūsu dati tiktu iegūti no viena API, savukārt aizmugurējā daļā vēlaties tos sadalīt mikropakalpojumos. Labākais paņēmiens, ko es zinu, lai sasniegtu abus, ir GraphQL izmantošana.
Tas ļauj sadalīt aizmugursistēmu mikropakalpojumos, vienlaikus nodrošinot katrai lietojumprogrammai vienu API un iespējot dažādu pakalpojumu datu savienošanu.
23. Kādas ir galvenās atšķirības starp drošo un idempotento HTTP metodēm?
Idempotentās metodes rada tādu pašu rezultātu, ja tās tiek izsauktas vienu vai vairākas reizes, izmantojot vienu un to pašu pieprasījumu. PUT metode ir idempotenta.
Visi drošie veidi ir idempotenti, bet ne visas idempotentās metodes ir drošas, jo drošas metodes nemaina resursus. Piemēram, GET ir drošs, jo tas tikai izgūst datus un nemaina resursu.
Turklāt tas ir idempotents, kas nozīmē, ka tas vienmēr atgriezīs to pašu atbildi, kad tas tiks izsaukts.
24. Ko JAX-RS API nozīmē RESTful Root Resource Classes?
Java Enterprise Edition nodrošina klases un saskarnes, kas atbilst JAX-RS API prasībām. Ar JAX-RS palīdzību ir vieglāk izveidot Java tīmekļa pakalpojumus REST arhitektūras stilā.
JAX-RS API saknes resursu klases ir tikai “vienkārši veci Java objekti” jeb POJO. Lai ieviestu nepieciešamos tīmekļa resursus, tiek izmantotas JAX-RS anotācijas.
Viņiem ir @path anotācijas, vai arī vismaz vienai no metodēm ir @path anotācijas. Tos var apkopot kā Java klases ar metodēm API galapunktiem.
25. Kas īsti ir Pastnieks, un kāpēc tas tiek izmantots?
API izstrādes rīks Postman tiek izmantots, lai izveidotu, pārbaudītu un modificētu API. Šo rīku izstrādātāji var izmantot jebkurai funkcijai, kas nepieciešama API. Tas vienkāršo un atvieglo izstrādātāju darbu.
Postman ļauj viegli veikt dažādus HTTP vaicājumus, tostarp GET, POST, PUT un PATCH, saglabāt vidi vēlākai lietošanai un pārveidot API kodos vairākās dažādās valodās.
Katrs API cikla posms ir vienkāršots ar Postman, un sadarbība ir pilnveidota ātrākai API izstrādei.
Turklāt tas ļauj izstrādātājiem pārvaldīt dokumentāciju, specifikācijas, testa gadījumus, procesus un API katalogus.
26. Kā REST API tiek uzturētas drošībā?
Tā kā REST API neizmanto tik stingrus drošības pasākumus kā SOAP API, sensitīvus datus nevajadzētu nosūtīt vai izgūt, izmantojot tos.
Tomēr uzticamās REST API turpina integrēt drošības kontroles drošai un uzticamai datu pārraidei.
- Autentifikācija un autorizācija: katram API pieprasījumam ir jāiztur šīs divas pārbaudes. Klienta identitātes pārbaude, izmantojot autentifikāciju, un apstiprināšana, ka viņam ir tiesības piekļūt pieprasītajiem resursiem, izmantojot autorizāciju, ir divi dažādi procesi.
- Validācija: pirms API piešķir piekļuvi saviem resursiem, pēc autentifikācijas un autorizācijas joprojām ir jāpārbauda, vai pieprasījumos nav iespējami kaitīga koda. Tādējādi serveris būtu atvērts injekcijas uzbrukumam.
- Validācija: pirms API piešķir piekļuvi saviem resursiem, pēc autentifikācijas un autorizācijas joprojām ir jāpārbauda, vai pieprasījumos nav iespējami kaitīga koda. Tādējādi serveris būtu atvērts injekcijas uzbrukumam.
- Šifrēšana: TLS/SSL šifrēšana aizsargā savienojumu starp klientu un serveri un neļauj hakeriem pārtvert pieprasījumus un atbildes.
- Likmes ierobežošanas paņēmieni, piemēram, ierobežojumi un droseles, aizsargā serverus no brutāla spēka uzbrukumiem, piemēram, DDoS, kuru mērķis ir tos pasliktināt vai avarēt.
- URI nav sensitīvas informācijas: resursu URI nedrīkst ietvert nekādus aizsargātus datus (piemēram, lietotājvārdu, paroli vai autentifikācijas pilnvaru).
Secinājumi
Apsveicam! Vairāki pamata vai sarežģīti REST API intervijas jautājumi un to attiecīgie risinājumi tagad ir pa rokai.
Tagad, kad jums ir labs priekšstats par to, kā atbildēt uz dažiem tipiskiem REST API intervijas jautājumiem, varat turpināt atbildēt uz intervijām. Nākamais solis ir atkarīgs no jūsu mērķiem.
Apmeklējums Interviju sērija ar Hašdorku, lai sagatavotos intervijām.
Atstāj atbildi