# Microsoft Interviews

<datetime class="hidden">2004-01-05T00:00</datetime>

<!-- category -- mostlylucidcouk, Imported, Software Development, Testing -->
Lees gewoon. [Deze artikel](http://www.sellsbrothers.com/fun/msiview/#myInterview) over
Een Microsoft-interview.

Ik had ook een interview voor een baan bij Microsoft een paar jaar geleden.
Mijn geval, een PM-werk in één van de servergroepen).

Ik ontmoette hem. [Mark Anders](http://www.4guysfromrolla.com/webtech/MarkAnswers.asp) In
De boekenwinkel op de 1999 ASP-professionele conferentie in IslingtonM SK1 Londen (I' zal missen.
Op die Wrox-conferentieën sprak hij over veiligheidsproblemen.
In de ASP-groep was het toen helemaal embryonaal.
Hij onderzocht nog steeds wat mensen over sommige dingen keken.
lang verhaal kort, Ik werd uitgenodigd naar Redmond.

Dus ik vloog over ,, moest een paar dagen in Seattle doorbrengen.
Uiteindelijk werd hij een dag lang gepest.

Eén van mijn grote problemen is dat je misschien niet begrijpt wat dit is.
Mechanismen voor directe vocale communicatie - maar stel je voor dat jij het zou doen.
Twee keer de snelheid ( hoewel ik een Barry Whitesque bariton heb :-)) - erg dronken en met
Hij had een zak marmeren in zijn mond.

Voeg hieraan toe dat ik erg zenuwachtig was -, had net ontdekt dat Starbucks (6 groot was.
espresso's!) en was nog steeds jet-lagged wellM SK2 Ik zou er een beetje aan lijken te praten.
vreemde verloren taal.

In één dag ontmoette ik verschillende mensen in verschillende gebouwen.
Een paar codeervragen. (eenvoudige dingen zoals het schrijven van een zoek- en vervangalgoritme.
Gewone),, waar ik behoorlijk goed in was. . Er waren wat '-uitvindingen en creatieve vragen.

- Nogmaals heel goed.

Toen kwam de [problemen.](http://www.sellsbrothers.com/fun/msiview/default.aspx?content=question.htm)!
Ik ben wat technisch gezien absoluut verbijsterend is in wiskunde.
wiskundepuzzels onder stress - gekoppeld aan het feit dat ik begon te praten.
Serbo-Coratische bood niet goed.

Er waren vragen over de snelheid van auto's over een brug.
De auto's oversteken in 2 minuten, één over balanceren van ballen ( waar ik het antwoord op kreeg.
Door laterale denken, niet de wiskundige aanpak).

Hoe dan ook, ik werd gevraagd of ik een baan in het testen zou overwegen.
Ik had het met grote ontwikkelingsgroepen.

Dit kleurde mijn kijk op Microsoft -, het hielp me ook een beetje te begrijpen.
Hoe het werkt...

Ze waren op zoek naar wiskunde-geeks - in dit geval tenminste
van de oude school-hacker (in de juiste zin :-)) Ik hou ervan na te denken over de code.
Ik schrijf en vorm een product waarin mensen willen gebruiken dat het niet wiskundig is.
Veel mensen haten deze aanpak, en de meeste mensen die ik ontmoette bij Microsoft.
Ze leek het niet te begrijpen.

Het gebrek aan creatief denken is een groot probleem voor de veiligheid in webgebaseerde systemen.
Gedurende de jaren , testen , schrijven en analyseren van deze systemen
De belangrijkste redenen voor problemen in dergelijke systemen.

Ontwikkelaars moeten creatiever nadenken over hun toepassingen, plaats jezelf
in de context van een persoon die probeert te breken / om de veiligheid van je code te ondermijnen.
Beperkingen voor punten waar alle gebruiker-invoer gevalideerd is - de application firewall.

- Dat is je veiligheidszone.

Het is echt vrij makkelijk om dit te doen, als je beperkingen legt op wat je applicatie aanvaardt.
Als input.

1. Validateer de hele tijd, kliënt en server.
2. Check for bounds in testing (Wat gebeurt er als je te veel karakters invoert
   Een vormveld?).
3. Haal elke fout waar je input accepteert van buiten de toepassing - of het nou is.
   Van de gebruiker of van de database kunnen ze naar beneden gaan.
4. Stel gevoelige foutcodes voor latere code om te controleren dat - veel toepassingen overvallen.
   Alleen omdat ze uit de sequentie - vallen met een of andere essentiële methode die niet terugkwam.
   De correcte waarde. Stel breukpunten in code waar als een voorwaarde een gok is, sommige abortus.
   Sequentie plaatsvindt ( het melden van de fout aan de gebruiker
5. Ver simplifiëren - dit is het allerbelangrijkste ding
   Je code leesbaar, maak je variabele namen duidelijk, voeg aanmerkingen toe die aangeduiken dat het verwacht is.
   pathways en gebeurtenissen in de source. Maak een enkele klasfiles met dezelfde namen.
   Als hun ingebouwde klas. Hou het gewoon simpel!

Hoe dan ook.