Alex Velea - tu ce anume te temi, ca o sa reusesti sa inveti totul in liceu/facultate?   
Cum zice Cosmin - fa ceva real, vezi cum e. Sa inveti algoritmi si sa castigi concursuri e un inceput bun, dar e un INCEPUT.
Poti sa te angajezi, sigur; poti sa mergi in practica la o firma peste vara, nu strica. Da' mai ales, in domeniul asta (si la varsta asta), poti fi propriul tau sef: fa ceva ce te pasioneaza, ceva ce simti ca este nevoie si alti oameni ar folosi. Ai o oportunitate extraordinara acum cu epoca smartphone-urilor: fa o aplicatia Android sau iOS, cine stie, poate vei deveni bogat pana cand termini facultatea
Sau, alatura-te unui proiect "open source", fa lumea mai buna. Sunt atatea de unde poti alege.....

Cosmin, presupunerea mea e ca nu te pregatesti "saptamani" pentru un interviu... asta deja e "invatare pe cont propriu". Sigur ca se poate invata partea de algoritmica, doar ca nu mi se pare ca se poate "pentru interviu". Eu presupun ca pentru interviu un om are cam o zi (sau mai putin) inainte de "phone screening" si  2-3 zile inainte de interviul "face-to-face".

Probleme de estimare Fermi - cool, nu stiam ca au nume . Da, rareori au sens cand angajezi un "fresh grad", da' pentru un "senior" s-ar putea sa conteze. Cel putin in ADBE, unul din lucrurile care-mi plac e ca "senior management"-ul se asteapta ca programatorii seniori sa inteleaga business-ul; nu iti zice sefu' ce sa implementezi, ci sefu' se asteapta sa vii cu propuneri "cum sa facem viata clientilor mai usoara". In contextul asta, de ex. daca ai o idee care vrei sa o bagi in produs, s-ar putea sa fie util sa faci o estimare de "cati clienti ar folosi acest feature"/ "cat timp/bani economiseste clientul cu feature-ul asta" etc. Care estimare, trebuie sa plece de la niste ipoteze "rezonabile" si sa para "logica", sa fie ceva ce altii ar putea accepta... ca daca scoti o cifra din 'thin air', nu esti luat in seama.

Design: si eu fac la fel, incerc sa prind "modul de gandire" si nu un "pattern". Mai mult, nu ma astept de la un "fresh grad" sa fie mare maestru la capitolul asta, se poate nici sa nu-l intreb nimic. Da' realitatea e ca foarte multi (din alte firme, nu neaprat ADBE; si imi imaginez ca e la fel si in US) sau intreba explicit despre un anumit pattern, dau iti cer sa faci o aplicare directa/triviala a unui pattern . Si eu mai dau uneori o "problema" care e basically o aplicare directa de MVC + un pic de sincronizare, si e surprinzator cat de multi programatori "senior" se incurca la asa ceva! (desi daca rostesti cuvantul "MVC" ti l-ar recita fara probleme). Secretul e ca ascund un pic "problema de design" intr-una de sincronizare, si atunci majoritatea se focalizeaza pe sincronizare si uita sa faca un "design"; sau invers, fac design da' ignora complet faptul ca pot aparea probleme de sincronizare
Insa pattern-urile chiar au o logica in spatele lor. Merita sa citesti un pic cateva, da' nu doar "ce este/cum scriem niste clase pe patternul asta", ci mai ales motivatia aparitiei lui, in ce situatii e util/ce probleme rezolva, in ce situatii e contraindicat/ce dezavantaje are, etc. Asta e ceva ce IMO poti face inainte de interviu, si sunt sanse bune sa-ti fie util

Eu am o dilema... cu ce caut pe net "Google Interview Questions"?
Pot cauta cu Google, dar mi-e frica sa nu fiu directionat catre niste false intrebari de interviu.
As putea incerca cu Bing, da' cum ei copiaza rezultatele de la Google, nu rezolv nimic.
Singura speranta ramane Baidu....

Acu' mai serios vorbind, sfaturile mele sunt asa:
1. Nu puteti invata algoritmica inainte de interviu. Forget about it. A... puteti sa va mai "dezmortiti", daca nu ati facut probleme de genul asta de ceva vreme... sa zicem. Da' de invatat algoritmi, tre' sa invatati fiindca va intereseaza si vreti sa stiti, nu ca sa luati interviul - ca nu-l veti lua.

2. Dupa parerea mea, "trick questions" (gen "cate bile incap in autobuz") pot sa apara/au rost, da' depinde de post si de ce urmareste cel care da interviul. In functie de candidat si de post eu mai intreb de exemplu chestii de genul "cati oameni sunt acum in mall" (biroul Adobe e langa un mall), dar nu urmaresc sa aflu un raspuns, ci sa vad cum reactioneaza la o intrebare 'tampita', sa vad daca/cum aplica logica pt. a afla raspunsul, cum face el o estimare de genul "wild guess", ce ipoteze de plecare isi alege (si cum si le justifica) etc. (bonus points daca face estimarea in 2 feluri diferite si isi estimeaza si precizia raspunsului; da' ca sa fiu sincer, asta nu mi s-a intamplat pana acum ).

3. Cel putin in Adobe, cand se angajeaza cineva se pleaca in general de la presupunerea ca "nu stim maine la ce proiecte vom lucra, ca lumea se schimba; daca se anuleaza proiectul asta, nu vrem sa dam omul afara". Asa ca se urmareste de multe ori ca un candidat (a) sa fie destept (b) sa fie pasionat de ce face (se vede! inclusiv din activitatea lui... una e daca in facultate "ai luat nota de trecere", si alta e daca poti arata ca ai facut o chestie cool. Just because, nu ca sa castigi, nu ca sa iei 10, ci fiindca ai vrut sa vezi cum se face), iar (c) sa aiba notiuni de baza (algoritmi, sisteme de operare, structura unui calculator, layoutul datelor in memorie, paradigme de programare etc.). Da, sigur ca daca avem nevoie de un om care stie JS o sa fie si intrebari de genul "cum se propaga evenimentele"... da' rareori astea sunt "make it or break it", cel mult pot face diferenta intre 2 candidati pe acelasi post.

Pe scurt, daca interviul e bine/"corect" facut, nu va puteti pregati pentru el, inaintea interviului, astfel incat sa para ca stiti mai multe decat stiti. Ce puteti face insa (si e bine sa faceti) este:

 1. sa va interesati despre companie: ce e ea, ce face/care e bunsiness-ul pe care v-ati angaja? Cine sunt clientii? (nu la modul "IBM e client" ci la modul "face soft pt. lanturi de magazine" vs. "face soft pt. automobile" vs. "face soft pt. end-user, e.g. soft de tel. mobile" etc.). Ce puteti afla (informatii publice) despre postul pe care ati aplicat? Ce NU puteti afla dar v-ar interesa (si e bine sa intrebati pe interviewer)? Faceti-va o parere despre "care ar fi rolul meu in firma", si nu va sfiiti sa o ziceti: "uite, eu din cate am inteles daca ma angajez aici, voi face <asta> si <astalalta>. Am inteles bine? A propos, <asta> ma pricep binisor, am facut, da' nu ma dau in vant; <astalalta> nu stiu prea bine dar sunt foarte interesat sa invat".  Relatia trebuie sa fie benefica si pentru angajat si pentru angajator - nu incercati sa va ascundeti, e mult mai bine pentru toata lumea sa fie un dialog deschis.
Rolul punctului (1) este dual: va ajuta pe voi sa va clarificati daca va chiar intereseaza slujba, si (2) arata ca sunteti interesati de post si stiti ce vreti ( nimeni nu-si doreste sa angajeze pe cineva care "a vrut la firma X" doar ca sa constate ca nu-i place ce are de facut la firma X, sau ca isi doreste altceva de fapt)

2. Cititi un pic si voi despre "best coding practices", ca sa fiu onest asta ajuta la multe interviuri. Eu nu intreb niciodata direct despre "programming patterns" ("ce e aia un Singleton?"), dar sunt multe firme care o fac. Oricum, si eu mai dau "probleme de design", si cineva care e familiarizat cu pattern-urile are o sansa ceva mai buna sa raspunda "corect" (am pus in ghilimele "corect" fiindca eu nu urmaresc un raspuns anume de obicei, ci incerc sa observ cum ajunge omul la raspuns, cum si-l justifica, cum si-l "apara" etc. Daca mi se pare ca "stie raspunsul" de obicei consider intrebarea gresita si caut alta).

3. Cititi despre limbaj, atat feature-urile vechi cat si cele noi. Nu e "make it or break it", da' daca aplicati la un proiect C#, e bine sa stiti "cam ce aduce nou C#4.0", in special daca va dati de "expert C#". Daca aplicati la un post care cere cunostinte de C++, e util sa nu aflati la interviu ca exista mostenire virtuala; si nu strica sa stiti ca in C++11 a aparut initializer-list-constructor. Din nou, nu sunt elemente "make it or break it", da' sunt detalii care dau bine, arata ca va intereseaza cum mai evolueaza tehnologia/limbajele in care lucrati. Nu suplineste in nici un caz necunoasterea layoutului datelor din memorie in urma mostenirii multiple;sau necunoasterea mecanismului de apel al metodelor virtuale; dar este un 'nice touch', si e ceva care cu siguranta puteti "invata" (citi) inainte de interviu, si in plus nu va strica, indiferent de rezultatul interviului...

4. Nu in ultimul rand, daca ati lucrat cu o tehnologie da' nu prea mult, si banuiti ca la postul respectiv e ceruta, faceti niste exercitii/reimprospatati-va memoria. Un exemplu comun e SQL-ul - daca nu ati lucrat de ceva vreme cu baze de date da' noul job ar implica asa ceva, e util sa va uitati din nou cum se fac niste query-uri, sa va readuceti aminte ce e un inner join/outer join, cum functioneaza tranzactiile, etc.