Kysymys:
Kuinka käsitellä haastattelun teknisiä testejä (esim. Kohtuuttoman suuri tehtävä lyhyellä aikavälillä)?
NibblyPig
2018-07-31 20:30:18 UTC
view on stackexchange narkive permalink

Jos haastattelu sisältää teknisen kokeen, johon sisältyy kohtuuttoman suuri tehtävä ja lyhyt määräaika, onko ehdokkaan järkevää siirtyä töihin, jotka eivät täytä ehdokkaan laatustandardeja, päättyä määräaikaan mennessä? Ja jos ehdokas yrittää tehtävää ja maalintekijä epäonnistuu ehdokkaassa tarjoamatta hyödyllistä rakentavaa kritiikkiä ehdokkaan työstä, miten ehdokas voi reagoida ammattimaisesti?

Kuinka voin päättää, jos Pitäisikö minun tehdä tulevaisuudessa teknisiä testejä, jotka ovat mielestäni järjettömiä (esim. Kohtuuttoman suuri ja lyhyellä aikavälillä tehtävä tehtävä)? (Ei vain tässä tapauksessa.)


I Olen sopimusohjelmistojen kehittäjä, jolla on yli 20 vuoden kokemus, joten usein minulla on hyvin lyhyitä haastatteluja ja usein myös tekninen testi, joka suoritetaan yleensä kotona.

Viime aikoina minut esiteltiin suuryritykselle Olin täydellinen ottelu, minulla oli hyvin lyhyt "haastattelu", joka oli enemmän epävirallinen keskustelu heistä selittäen mitä he halusivat. He sanoivat, että tekninen testi oli tehtävä nopeasti, ja he ymmärtävät, että minun kaltaiset mahdolliset toimittajat eivät halua viettää tunteja todistamassa, joten en ollut liian huolissani; yleensä he ovat kourallinen kysymyksiä tai pyytävät minua rakentamaan nopean konsolisovelluksen muutamien käsitteiden esittelemiseksi.

Tämän yrityksen tekninen testi oli rakentaa ASP.NET MVC -sivusto, jossa on REST-sovellusliittymä. loppu, joka muodostaa yhteyden tietokantaan, ja rakenna MVC-verkkosivustolle järjestelmänvalvojan sivu, jonka avulla voit etsiä käyttäjiä automaattisella täydennystavalla.

Testi oli tarkoitus suorittaa kahdessa tunnissa.

Asiantuntijani mielestäni kukaan ei koskaan sanoisi tämän olevan kahden tunnin työ, jos se tehdään oikein. Laittaisin muutaman päivän alas ainakin saadakseni arkkitehtuurin oikein jne.

Siitä huolimatta räjäytin sen läpi niin hyvin kuin pystyin ja keksin täysin toimivan ratkaisun, jota ei liian suunniteltu huonosti. He pyysivät vastauksia muutamiin kysymyksiin, jotka lähetetään vastauksen kanssa, mukaan lukien "Mitä olisit tehnyt enemmän aikaa?". Laitoin seurantasähköpostin bitit, joista leikkain kulmat, ja miksi kirjoitin sen samalla tavalla kuin tein. Kirjoitin sen myös .NET Core 2: lla, koska he sanoivat, että he käyttivät sitä järjestelmäänsä.

Luulen, että tein melko hyvää työtä, täyttäen kaiken kahden tunnin kehitykseen.

Rekrytointitoimiston välityksellä vastaus oli, että he eivät saaneet sitä toimimaan, joten heillä oli kehittäjä, joka sanoi, että se oli erittäin heikkolaatuinen.

Luulen, että he eivät voineet Saada se ajaa johtuu siitä, että .NET Core 2 on hyvin uusi ja tunnetusti hankala toimiakseen kunnolla - mikä tahansa versioiden ristiriita asentamasi SDK: n ja sen kirjoittamiseen käytetyn välillä voi aiheuttaa ongelmia, kun olen ottanut sen käyttöön oman palvelimen jälkeenpäin nähdäksesi miksi heidän mielestään se ei toiminut, ja minun piti päivittää paikallinen SDK: n vastaamaan palvelinta.

Se, että he sanoivat sen olevan heikkolaatuinen, viittaa kehittäjään, jolle he osoittivat sen ei ottanut huomioon aikarajoituksia. En voinut saada muuta palautetta; rekrytoija ilmoitti minusta melko paljon negatiivisen palautteensa seurauksena, mikä on uskomattoman ärsyttävää.

Olen enemmän ärtynyt heistä sanoen, että työni ei ollut tarpeeksi hyvä, koska minulla on kyseinen persoonallisuustyyppi missä pidän itseäni uskomattoman korkealla tasolla ja se, että se on polttanut minut viraston kanssa, kuin se, että en saanut työtä. Urakoitsijana minut tuodaan yleensä yrityksiin, joissa epäpätevyys hallitsee suurinta osaa (kehitystiimi kävelee ulos, kehitystiimillä ei ole aavistustakaan mitä he tekevät, kauhea johto jne.), Joten voin vain pystyä pitämään sen ajan tasalla .

Joten tämä johtaa minut kysymykseeni:

Kuinka voin tulevaisuudessa päättää, pitäisikö minun vaivautua tällaisten "Kobayashi Maru" -testien tekoon, jossa näytän epäpätevältä, jos suoritan sen heidän aikakehyksessään? Pitäisikö minun sanoa: "Anteeksi, mutta tätä teknistä testiä ei voida suorittaa kahdessa tunnissa?", Vai olisinko voinut tehdä jotain muuta?


Haluaisin haluaisin lisätä, että olen urakoitsija, ei vakituinen työntekijä. Tämä tarkoittaa, että hoidan yritystä täällä; Teen kaikenlaista työtä osaamisalueellani riippumatta siitä, onko asiakas hyvä, huono, kamala, epäpätevä jne., Koska se tulee työn mukana. Se tarkoittaa myös, että työpaikoilla on paljon vähemmän vaihtoehtoja; Vaikka saan pysyvän työpaikan helposti, sama ei koske urakkatyötä.

Tämä muistuttaa minua veropalvelupaikoista, jotka ilmestyvät kaupunkini ympärillä joka vuosi lähellä ensimmäisen vuosineljänneksen loppua.He palkkaavat ihmisiä seisomaan liikenteen viereen pukeutuneena pukuihin ja aaltomerkkeihin tuodakseen asiakkaita.Tämän työn haastatteluprosessi on seistä muutaman tunnin ajan liikenteessä puvussa, heiluttaa merkkiä ja näyttää innostuneelta.Ihmisille yleensä sanotaan, etteivät he olleet tarpeeksi innostuneita eivätkä saaneet työtä.Mutta heidän ei tarvitse koskaan palkata ketään, kunhan ihmiset "haastattelevat".
Kaksitoista vastused:
TomTom
2018-07-31 20:39:22 UTC
view on stackexchange narkive permalink

Kävelemällä heiltä pois.

GS (Goldman Sachs) halusi kerran minulta pienen koodinäytteen, joka juoksi alas vaihto-tilauskirjan simulaattorille. Ei mitään erityistä, Paitsi että he määrittivät täydellisen testin kattavuuden ja TUOTEKOODIN LAADUN. Jollei kriittisestä asiasta kuluu viikon työ jokaisen reunatapauksen testaamiseen, koska tämän tyyppinen koodi on erittäin kriittinen.

Lähetin rekrytoijalle tarjouksen ja kerroin hänelle, että jos he eivät maksa - ei leikkiä.

Joillakin yrityksillä on typeriä ideoita ja he tekevät naurettavia testejä. Esimerkkisi on samanlainen - ei ole mitään outoa tapaa tehdä se 2 tunnissa sen ulkopuolella, että se olisi jo valmistautunut. Uskallan sanoa, että tämä on rajapetus. Se on todennäköisesti vain merkki koomisesta epäpätevyydestä.

Muista, että tämä on IT - ja IT on myyjämarkkinat. Tonnia työpaikkoja - ei asiantuntijoita. Käy niin. Älä käsittele idiootteja. Kieltäydyn koodaustyöstä ilman ENNEN haastatteluja, koska on toinenkin puoli: Kaikki nuo "mielenkiintoiset, haastavat" projektit ovat aivan yhtä typeriä uudestaan ​​ja uudestaan. Haluan ensin tietää, haluanko tuhlata aikaani, koska rakastan todella tehdä projekteja, joista pidän, ja rekrytoijilla ei ole mitään aavistustakaan, mitä projektit käsittävät nykyään.

Kommentteja ei käytetä laajempaan keskusteluun;tämä keskustelu on siirretty chatiin (https://chat.stackexchange.com/rooms/81086/discussion-on-answer-by-tomtom-how-to-handle-technical-tests-that-are-absurd-e).
* ei ole mitään outoa tapaa tehdä se 2 tunnissa sen ulkopuolella, että se on jo valmistautunut.* - Tai työ oli tarkoitettu jollekin sisäiselle henkilölle, joka tiesi jo testin olevan ...
Ei silti ole väliä.Ainoa tapa tehdä se olisi saada koodi valmiiksi.Ei ole väliä kuinka paljon tiedät, jossakin vaiheessa edes puhdas kirjoittamisnopeus ei riitä.
Ohjeena oli luoda algo, joka tulosti tämän. https://gist.githubusercontent.com/cmikec/9e926a20e5d04b942b03/raw/3df5101440a4c1dfcdd67cb4af5c7edddb227132/spiral.txt Pidetäänkö sitä naurettavana?Heidän tuote on eräänlainen varaussovellus, jossa voit tehdä asioita sinulle.
Old_Lamplighter
2018-07-31 22:24:10 UTC
view on stackexchange narkive permalink

Muista, että kun yritys haastattelee sinua, haastatat myös heitä.

Käytä mielettömiä testejä seulontatyökaluna.

Jos TEST antaa sinulle kohtuuttomia tavoitteita ja aikatauluja, arvaa mitä voit odottaa työssäsi .

Älä ota sitä henkilökohtaisesti, huono testi ei ole hyödyllinen mittari taitojesi mittaamiseen. Jos he sanovat, että työsi ei ollut tarpeeksi hyvä, ja tiedät sen olevan, he eivät ilmeisesti aio arvostaa sinua myöskään työssä.

Jälleen, se ei ole sinä, vaan he. / p>

Sain kerran testin, jossa minua pyydettiin kirjoittamaan kalenterisovellus ja dokumentoimaan sen iso O-suorituskyky.Dokumentoin valitsemani standardikokoelman suorituskyvyn ja totesin, että 1) suorituskykyä voidaan virittää muuttamalla yhtä koodiriviä;2) optimaalinen valinta riippuisi käyttötavoista, eivätkä ne olleet toimittaneet mitään;3) pienten kokoelmien teoreettinen suorituskyky yleensä pienenee kiinteiden kustannusten avulla;ja 4) tuotannossa päätöksesi perustuisi testaukseen, ei teoriaan.Paitsi että he eivät hyväksyneet tätä vastausta, rekrytoija juorutti siitä nykyisille työtovereilleni.
Stephan Branczyk
2018-08-02 00:38:33 UTC
view on stackexchange narkive permalink

Jälkivaikutus on 20/20. Näin sinun pitäisi sanoa seuraavalla kerralla:

"Nyrkkisääntönä en tee mitään kotona tehtäviä kotitöitä, ellet puhu ensin asiakkaan kanssa."

"Oletko asiakas? Ei, yhdistä minut sitten asiakkaan palkkaamispäälliköön. Ja ei, jos työskentelet HR: n palveluksessa (et ole asiakas, ellet halua minun rakentavan HR-sovellusta) ). "

" Okei, mitä tämä henkilö tekee yrityksellesi? Onko hän henkilö, jolle ilmoitan, jos yrityksesi palkkaa minut? Ok, kyllä. Haluan puhua kyseinen henkilö. "

Kun olet vihdoin puhunut kyseisen henkilön kanssa, sanot jotain:

" Okei, oletko lukenut ansioluetteloni? Luuletko, että voimme ohittaa koko tämän kotiin -projektin? "

Olettaen, että vuokrausjohtaja ei silti halua ohittaa sitä, niin voit sanoa:

"Ongelmana on, että olen palanut aiemmin.

Ensinnäkin, en tiedä, pitäisikö minun vain rakentaa projekti tyhjästä vai käyttääkö vain jotakin koodia I Kerran rakennin projektin alusta muutamassa tunnissa, mutta minua kritisoitiin siitä, ettei minulla ollut tuotantovalmiita sovelluksia likaatio.

Ja toinen kerta, pieni versio ei täsmää, eikä heidän tietotekniikkansa tiennyt kuinka säätää kokoonpanotiedostoa projektini toimimiseksi. "

Mutta mitä tahansa teetkin, älä anna tätä selitystä rekrytoijalle. / hän käyttää kyseisiä tietoja sinua vastaan, koska suunnitellusti portinvartijalla on hyvin harvoin valta tehdä myönnytyksiä, mutta toisaalta heidän roolinsa on pikemminkin syiden etsiminen ehdokkaiden turvatarkastamiseksi.

Oletetaan, että olet puhunut varsinaisen päätöksentekijän, palkkaamispäällikön kanssa, jolle todella ilmoitat, ja olettaen, että saat tältä henkilöltä hyviä tunnelmia, voit sanoa:

"Okei, olen valmis tekemään kotiin -projektin, mutta olisin mieluummin siellä, kun projektini asennetaan ja arvioidaan.

Luuletko, että voisimme asettaa ajan, jolloin Voisiko tulla koodini kanssa ja voisimme asettaa sen yhdessä kehittäjän koneellesi? "

" Entä tämä tuleva keskiviikko? [...] Tuletko sinne? Tulisiko joku kehittäjistä ole myös siellä? "

Mutta jälleen kerran, tee tämä vain, jos saat hyviä tunnelmia tältä henkilöltä. Luota omiin suoliston tunteisiisi. Jos jostain syystä sinusta tuntuu, he käyttävät tätä kotiin -hanketta laiskana tapana seuloa useita kymmeniä hakijoita. Tai jos jostain syystä sinusta tuntuu, että he yrittävät purkaa sinusta ilmaista työtä, jotta he voivat laittaa sen tuotantoon, eivät suostu kotitehtäviin.

Sama pätee, jos ilmestyt, eivätkä he halua asentaa / tarkistaa projektiasi, kun olet siellä. Jos he haluavat sinun tekevän heidän kotitehtävänsä, heidän on myös investoitava jonkin aikaa sinuun. Se osoittaa keskinäistä kunnioitusta.

Ja jostain syystä et saa sitä kunnioitusta. Esimerkiksi, jos he vaihtoivat insinöörin, sinun piti tavata HR-henkilö viime hetkellä. Ole kohtelias, mutta ole luja. Älä anna heille kotiprojektiasi. Kerro heille, että voit mielelläni siirtää haastattelun uudelleen ja lähteä.

CJ Dennis
2018-08-02 06:42:05 UTC
view on stackexchange narkive permalink

En halua viitata muihin vastauksiin vastauksissani, koska heidän pitäisi pystyä ymmärtämään vastaukset itse. Eniten äänestetty vastaus on kuitenkin pohjimmiltaan "yritys on joukko idiootteja. Pakene heiltä." Tämä ei anna OP: lle mitään parannettavaa itsessään eikä mitään muutettavaa tulevaisuudessa. Katson alueita, joita toimenpideohjelma voisi parantaa riippumatta siitä, onko yritys tehnyt mitään väärin vai ei, mitä emme vastaajina todellakaan tiedä, koska olemme kuulleet vain yhden puolen tarinasta.

Kuten sikäli kuin näen, et ole kommunikoinut ennen aloitit tehtävää, jonka uskot vakaasti, ettei sitä voitu tehdä kahdessa tunnissa.

Tässä on tapahtumien järjestys, miten katso se:

  1. Sinua pyydettiin suorittamaan koodaushaaste
  2. Kun sait haasteen, aloitit koodaamisen sen sijaan, että ilmoittaisit huolenaiheistasi.
  3. Nopeit haastetta, leikkaamalla kulmia
  4. Lähetit heikkolaatuisen projektin, joka ei toiminut ilman paljon hämmennystä
  5. Saatuasi palautetta aloitit työsi perustelemisen

Näin luulen yrityksen näkevän sen:

  1. Ehdokas hyväksyi kaikki haasteen ehdot
  2. Ehdokas toimitti projektin ajoissa
  3. Projekti ei toiminut
  4. Pääkehittäjämme sanoi turskan e oli erittäin huonolaatuinen
  5. Ehdokas aloitti tekosyitä työhönsä

Kuvittele olevasi työtilanteessa ja esimiehesi / tiimisi johtaja pyytää sinua suorittamaan tehtävän kohtuuttoman ajan kuluessa. Jos et heti ilmoita, ettet voi tehdä niin paljon työtä tuossa lyhyessä ajassa, kaikki epäonnistumiset ovat sinun syytäsi hyväksyä alkuperäiset ehdot. Olet asiantuntija, et he, ja he luottavat sinuun kommunikoidessaan heidän kanssaan.

En voi korostaa, kuinka tärkeää on, että molemmilla osapuolilla on yhteinen käsitys tilanteesta. Sinulla oli ylitsepääsemätön kuilu, koska menetit tilaisuutesi puuttua siihen. Seuraavan kerran kun sinulla on ongelma, ilmoita siitä heti, muuten toinen osapuoli ajattelee, että kaikki on hyvin! Tärkeiden tietojen välittämättä jättäminen on laiminlyöntiä, ja mikä tahansa valheiden muoto on epäammattimaista. Se, miten he reagoivat tietoihin, on heidän vastuunsa, ei sinun.

Suosittelen lukemaan Robert C. Martinin (Bob-setä) The Clean Coder: A Code of Conduct for Professional Programmers . , erityisesti:

  • Luku 2: Ei sanominen
  • Luku 3: Kyllä sanominen
  • Luku 10: Arviointi
  • Luku 11: Paine

Jos yritys hylkää hakemuksesi, koska olet pyytänyt palautetta ja selvennystä ennen tehtävän aloittamista, he eivät ole suodattaneet sinua, olet suodattanut heidät yrityksenä, jossa et halua työskennellä.

Vaikka mielestäni OP: lla oli todennäköisesti parempi olla tekemättä siellä, mielestäni on hienoa, että annat käytännöllisiä ehdotuksia, joita hän voi todella käyttää parantamiseen.+1;Teen tämän tyyppistä viestintää * joka päivä, ja se on itse asiassa yksi tärkeimmistä osista työni.Oikea arvio työstä ja * tarkkojen * odotusten asettaminen (joka ei muuten tarkoita "odotusten alentamista"; toisinaan ihmiset arvioivat 4 kuukautta, kun se voidaan tehdä kahdessa päivässä).
Mikä parhaiten arvioitu vastaus tarkalleen?
@VolkerSiegel Tämä on yksi syy, miksi en halua viitata muihin vastauksiin.Se, joka alkaa "Kävelemällä pois heistä".
JohnHC
2018-07-31 20:44:11 UTC
view on stackexchange narkive permalink

Olen kohdannut joitain älykkäitä ja joitain typeriä testejä (SQL / BI) ja kävelin aktiivisesti pois tyhmästä selittäen, että heidän haluamansa oli väärä lähestymistapa.

Olen myös nähnyt testit, jotka olivat tosiasiallisesti yrityksiä ilmaiseen projektiin, ja "näyte", joka oli olennaisesti uusi ratkaisu. Jälleen kerran kieltäydyin suorittamasta näitä.

Se tapahtuu, haastan sen kokemaan ja eteenpäin. Suunnittelen haastattelut aina tuntien jälkeen, joten minulta ei ole todellista menetystä.

Minulla oli toinen haastattelu, jossa olin yhdessä ohjelmoijan työntekijän kanssa ja työskentelimme pariohjelmoinnissa kaksi tuntia hänen nykyisen projektinsa / tehtävänsä parissa.He kertoivat minulle etukäteen, että se oli todellista työtä, ja he maksavat minulle siitä, minkä he tekivät.Mielestäni se oli erinomainen ratkaisu - hanki todellista työtä rehellisesti, näe ehdokas toiminnassa todellisessa työympäristössä, anna ehdokkaan kokea todellinen työympäristö.
Se on todella siistiä.Joillakin täällä olevista suuryrityksistä on uskomattoman intensiivisiä haastatteluohjelmia, joita ei ole maksettu, kuten viisi kierrosta ja jättimäinen tekninen testi, johon sisältyy integrointi niiden sovellusliittymiin.He maksavat hyvin, kun sinulla on työpaikka, mutta on paljon panostettava, jos et usko taitojesi leikkaavan tarpeeksi.
@MartinCarney Palkkaaminen on ratkaiseva osa siellä.Se kuulostaa todella hyvältä haastattelusta, kunhan sinulle maksetaan palkkaa riippumatta siitä, saisitko työn vai et.Jos et maksa, niin he vain pyytävät sinua antamaan heille tavaraa, josta he voivat ansaita ilmaiseksi, ja se todennäköisesti rikkoo muutamia lakeja, vaikka allekirjoittaisit sopimuksen, jossa oli lausekkeita, joiden mukaan luovutit oikeudestasi saada palkkaatyösi ja henkisen omaisuutesi.
@Ryan ehdottomasti.Kun katsot, että yhden työntekijän hankkiminen maksaa tuhansia tai kymmeniä tuhansia, haluttomuus maksaa edistyneille ehdokkaille heidän ponnisteluistaan on hieman järjetöntä.
tarkalleen - OP kuulostaa siltä, että hän olisi kohdannut erikoistyötä, ei haastattelua
DonQuiKong
2018-08-01 22:10:35 UTC
view on stackexchange narkive permalink

No, kerro heille tarkalleen, mitä kerroit pomollesi, jos kohtaat tämän tehtävän.

Joko he eivät tiedä mitä tekevät, sitten opit paljon yrityksestä, tai he haluavat nähdä, ettet tuhlaa aikaa (yrityksen rahaa) tekemällä asioita huonosti sen sijaan, että puhuminen sellaisen henkilön kanssa, jolla ei ole teknistä tietoa arvioimaan tätä.

On olemassa kaksi lopputulosta: sinä läpäisit lentävillä väreillä oikean asian tekemisestä, tai olet väistynyt luotista ja sinun ei tarvitse palata kahden kuukauden kuluessa kertomalla meille, kuinka pomosi vaatii mahdotonta tavaraa; )

Marcin
2018-08-03 00:08:05 UTC
view on stackexchange narkive permalink

Tässä on minun lähestymistapani:

  1. Kommunikoi yrityksen yhteyshenkilön kanssa, jonka et ajattele olevan mahdollista aikanaan, ja mitä aiot todella tehdä.

  2. Jos on aikaa odottaa vastausta, odota; jos ei, tee mitä tarkoitit, ja dokumentoi valintasi yksityiskohtaisesti.

  3. Ideaalista luonnos mihin ottaisit sen.

  4. ol >

    Huomaa, että hyvin harvat haastattelijat todella kalibroivat ja testaavat, että tehtävä kestää 2 tuntia. Jos todella haluat työn, vie se jollekin täydellisyydelle tietyssä ajassa.

    Kuten olet huomannut, laatu yleensä tyydyttää sopivan ajan myötä, ellei heillä ole tiukkoja mekanismeja kaikkien varmistamiseksi ehdokkaat sopivat määräaikaan.

Greg Bacon
2018-08-02 05:50:53 UTC
view on stackexchange narkive permalink

Asiantuntijani mielestäni kukaan ei koskaan sanoisi tämän olevan kahden tunnin työ, jos se tehdään oikein. Laittisin muutaman päivän aikaa ainakin arkkitehtuurin saamiseksi oikein.

Anteeksi anteeksi, mutta sinulta puuttuu asia.

Ajattele sitä ryhmän näkökulmasta. He haluavat jonkun, joka tuntee kaikki ASP.NET, MVC, REST, puhuu tietokannalle ja yhden automaattisen täydennyksen tekstiruudun kohtalaisen edistyneelle ominaisuudelle.

Voisinko voin saada nämä asiat tehty? Kyllä, lopulta. Loppujen lopuksi olen kuullut kaikki nämä asiat, joten voin mennä eteenpäin ja luetella ne ansioluettelossani. Sinä kaltainen asiantuntija voi yhdistää toimivan järjestelmän yhteen määräajan sisällä, koska käsittelet tätä pinoa koko ajan, mutta minun pitäisi viettää tuntikausia kaivamalla käsikirjoja.

Jatka paperi, jossa luettelomerkkien luettelointi on triviaalia. Huono vuokraus on pahempaa kuin ei palkkaa. Oletan, että sinulla ei ollut henkilökohtaista suositusta joltakulta tiimistä, joten vuokrauspäällikkö etsii pätevyyden osoittamista. Todellinen, todellinen tuotantovalmis järjestelmä vie paljon kauemmin, mutta testi ei vaatinut tuotantovalmiita, koska siinä kysyttiin, mitä olisit tehnyt enemmän aikaa. Menestys testissä osoittaa, että osaat sujuvasti kaikkia tasoja ja mikä tärkeintä että osaat priorisoida . Tee se toimimaan ja sitten tee siitä kaunis!

Kahden tunnin testi ei ole aika astronautti arkkitehtuurille.

Lisäksi et melkein varmasti ole ensimmäinen ehdokas näkemään tämän testin. Joukkue on käyttänyt ja mahdollisesti muokannut suodatinta useita kertoja, ja ainakin yksi kehittäjä on päässyt läpi. Nenän kääntäminen ylöspäin - kuten viime vuosina on tullut erittäin muodikasta - vanhurskaassa suuttumuksessa tai heidän "kouluttaminen" miksi se on huono testi, heidän mukaansa asettaa sinut bozo-luokkaan. Phew! he ajattelevat, toinen viivyttelijä tai primadonna, jota meidän ei tarvitse käsitellä.

Kuinka käsitellä sitä? Katsokaa sitä potentiaalisen asiakkaan näkökulmasta. Sen sijaan, että hylätään absurdina, anna epäilystä hyötyä. Kahden tunnin testissä muistele lyhyesti oletuksesi, tee aurinkoisen päivän tapaus yksinkertaiselle esittelytyölle ja jäljellä olevassa ajassa dokumentti siitä, miten tekisit todellisen järjestelmän vankaksi.

En usko, että olet lukenut kysymyksen oikein.OP teki sen, mitä vastauksesi kertoo tekevän, ja silti asiakas jätti huomiotta ratkaisunsa, koska OP uskoo olevan SDK: n ristiriita tai jotain triviaalia.Hän yritti lähestyä tilannetta, kuten ilmoitit, hakkeroivalla mutta toimivalla ratkaisulla, mutta tapasi epäpätevän kehitys- / IT-tiimin.Voitteko muotoilla vastauksenne vastaamaan koko kysymykseen?
@damanptyltd SLC kirjoitti "persoonallisuustyypistä", joka vaatii "uskomattoman korkeatasoista" sekä lopputulosta, joka "ei ollut * liian * huonosti suunniteltu" (painotus alkuperäisessä), mutta arvioitiin "erittäin huonoksi".Yhdistelmä ehdottaa ylisuunniteltua lähestymistapaa testiin, jossa hakijoita pyydetään osoittamaan yksinkertainen toimiva järjestelmä, jossa kaikki pääkomponentit ovat yhteydessä toisiinsa.Helppo tapa on syyttää "järjetöntä testiä" ja epäpätevää kehittäjää, joka ei voinut saada sitä toimimaan - toisin sanoen kaikkia muita mukana olevia.
Mielestäni ei ole oikeudenmukaista tehdä oletuksia OP: n lausunnon ulkopuolella.Jos luulet, että OP: lla on väärä ajatus, sinun on ensin muotoiltava kysymys (joka on täysin hieno) ja vastaettava siihen asianmukaisesti.Tällä hetkellä vastauksesi perustuu oletuksiin, joita et ole perustellut tai todistanut.
Olen samaa mieltä @GregBacon: n kanssa tästä - kyllä, 2 tunnin testi ei ole parasta arkkitehtuuria.Se on tiukka määräaika, mutta .net mvc tekee melkein kaiken tämän raskaan nostamisen - kaikki muu on massiivisesti yliarvioinutlyhyt (ja puuttuu hieman asiasta).Ja valitettavasti kyllä - valitukset jälkikäteen kuulostavat hapan rypäleiltä.
Kuulostaa hyvältä lähestymistavalta.Sitä tein jo Uni-päivinäni.Okei, meillä oli viikko kahden tunnin sijasta, mutta päivän päätteeksi sinulla on vielä järjestelmä, joka ei ehkä ole niin täydellinen kuin haluat, joten _ kirjoitat mahdollisesta tulevasta työstä_.Tämä osoittaa, että osaat kehittää ohjelmistoja ja hallita projektiasi ja ajattelet aina seuraavia parannusvaiheita.Voi yksinkertaisesti olla, että haastattelija etsi sitä, vaikka myönnänkin, että kysymyksessä luetellut erityisvaatimukset vaikuttavat erityisen äärimmäisiltä 2 tunnin aikataulussa.
Tämä on hyvä vastakohta eniten äänestetyille vastauksille.Huomaa, että jos tämä todella oli * tavoite, haastattelijoiden tulisi sanoa: "Tämän testin tarkoituksena on, että voit osoittaa, että sinulla on riittävästi kokemusta näistä tekniikoista, jotta voit perustaa perustyön nopeasti. Sen ei tarvitse olla täydellinen, mutta sen pitäisi toimia *. "
mathreadler
2018-08-07 09:02:16 UTC
view on stackexchange narkive permalink

Tämä vääriä testejä kartoittaa persoonallisuuttasi, etenkin kuinka käsittelet järjettömiä ja stressaavia tapahtumia. Oletko sellainen, joka

  1. ärsyttää ja lähtee vai
  2. yritätkö hiljaa ratkaista sen vai teetkö sinä
  3. yrität itse asiassa väittää ja selitä johdolla, mitkä asiat ovat kohtuuttomia tai
  4. stressaantuvatko niin, ettet tiedä mitä tehdä, tai
  5. oletko se, joka teeskentelee yrittävänsä selvittää sen, mutta antaa yhtä järjetön palautettu tulos, koska juuri kuka tahansa tällaisen tehtävän ansaitsi ansaitsisi?
+1 Mittaaminen siitä, miten ehdokas reagoi paineen alla, on yleinen haastattelutaktiikka.
@Eric En ole koskaan nähnyt sen tapahtuvan, mutta arvaan sen olevan syy jos se tapahtuisi.Ehkä yleisempi muualla kuin missä olen ollut.
AnoE
2018-08-02 16:03:41 UTC
view on stackexchange narkive permalink

Tämä vastaus ei anna lausuntoa siitä, ovatko tällaiset testit hyviä vai eivät (vai suostuinko niihin), mutta keskitytään tiettyyn kysymykseen.

Kuinka voin päättää, pitäisikö minun tehdä tulevaisuudessa teknisiä testejä, jotka ovat mielestäni järjettömiä (esim. kohtuuttoman suuri tehtävä lyhyellä aikavälillä)?

Kuten tekisitkin reaalimaailma:

  • Kerro kuinka kauan tehtävä kestää kohtuullisesti.
  • Suunnittele suunnitelmasi mitä tehdä annetussa ajassa (eli tee vähemmän tai tee se huonompi, tai molemmat).
  • Tee niin paljon kuin voit, mahdollisimman vähäiseen laatutasoon, jonka voit mahata. Keskity toimivan ratkaisun hankkimiseen ennen täydellistä ratkaisua.
  • Dokumentoi selvästi, mihin leikkaat kulmat, mitkä ovat seuraukset ja mitkä ovat TODOt.

Kaikki tämä auta minua suuresti työnantajana tai asiakkaana arvioimaan, haluanko työskennellä kanssasi.

Työnantajan / asiakkaan hallintorakenteesta riippuen sinua työllistävä kaveri (ts. suora pomo / asiakas) voi hyvinkin olla tilanteessa, jossa hän ei voi vaikuttaa millaiseen työhön saat. Matriisien hallinta on olemassa ... tässä tapauksessa haluaisin mieluummin jonkun, joka pystyy käsittelemään tällaisia ​​tilanteita armon yli sankariin, joka toimittaa kaikkien aikojen suurimman koodin, mutta ei pysty kommunikoimaan aika- / laaturajoista.

Tarkka mitta siitä, haluatko saada enemmän laatua vai enemmän sisältöä, riippuu. Esimerkiksi sinun tapauksessasi olet todennäköisesti eniten kiinnostunut heistä siitä, että pystyt tarjoamaan laadukasta työtä. Joten saatat leikata muutamia ominaisuuksia (käyttämällä joitain paikkamerkkejä jne.), Mutta pitää koodisi laatu korkeana. Vastaavasti, jos työ liittyisi esimerkiksi turvallisuuteen, tekisit saman. Mutta jos se on täysin kriittinen todiste jostakin käsitteestä, niin voi kääntyä enemmän toiseen suuntaan. Dokumentoi kaikki tämä (ytimekkäästi), ja olet hyvin matkalla.

PS: Haluan välttää "hulluja tai huonoja" tuomioita. Toisin sanoen, sinun ei pitäisi välittää siitä, onko asiakas vain hullu vai tuleeko sinuun (eli oletko tehnyt työtä ilmaiseksi) pelkästään tehtävän koon perusteella. Sinulle tärkeä todellinen määrä on sinun aikasi, ja se korjattiin. Niin kauan kuin olet hyvin sijoittanut kaksi tuntia potentiaaliseen uuteen asiakkaaseen, sillä ei ole merkitystä, onko tehtävä helposti suoritettavissa vai korkeapainetehtävässä vai vain kahden tunnin pienellä puheella toimistossa.

En ole samaa mieltä viimeisen mielipiteesi kanssa.Se todennäköisesti antaa sinulle enemmän ongelmia tulevaisuudessa, jos saat maineen, että sinut voidaan ajaa ympäri minne tahansa.Ehkä * sinä * ei yksinkertaisesti välitä, mutta * muut ihmiset * välittävät ja he saattavat virheellisesti ajatella, että tällainen kohtelu saa sinut tuntemaan olosi pahaksi ja mikä saa heidät sääliäsi sinusta riippumatta kuinka vähän sinä * todella * välitätkin heidän typerästä painostuksestaanpelejä.
@mathreadler, Ymmärrän mitä tarkoitat yleensä, mutta en näe suhdetta viimeiseen asiani.Viimeinen kappaleeni on puhtaasti "sisäinen" eikä sisällä neuvoja siitä, miten toimia näkyvästi.Vai muotoilinko sen väärin antaakseni tuon vaikutelman?
Andrew
2018-08-08 03:11:40 UTC
view on stackexchange narkive permalink

Kuten muut vastaukset ovat ainakin vihjanneet, testin motivaatio voi olla kohtuullinen, varsinkin jos testi:

  1. on hyvin räätälöity todelliset työn vaatimukset;
  2. minimoi vähemmän tärkeät elementit;
  3. ei selvästikään ole yritys saada "ilmaista työtä"; ja mahdollisesti
  4. Mukana ainakin joitain vihjeitä siitä, mitä arvostelijat "etsivät".

Aikaisemmassa työpaikassa suunnittelin ja hallinnoin väitetysti "absurdia" "ohjelmointitesti. Työ oli aina ylemmän tason täyden pinon ASP.NET/SQL Server -kehittäjätyö, ja tehtävänä oli luoda hyvin yksinkertainen verkkosovellus, johon sisältyi yksi sivu ja kaksi tai kolme yksinkertaista tallennettua menettelyä. Ehdokas suoritti testin paikan päällä vakiotyökaluilla:

  1. Visual Studio (ehdokkaan valinnan versio kahden tai kolmen viimeisen version aikana);
  2. SQL Server Management Studio; ja
  3. verkkoselain paitsi testausta varten, myös asiakirjojen, resurssien jne. etsimiseen, minkä kerroin ehdokkaille nimenomaisesti.

Annoin ehdokkaalle "shell" -perusratkaisun (jokaisessa sallitussa Visual Studio -versiossa), ja loin tietokannan ja taulukot etukäteen.

Annoin ehdokkaalle yhden sivun kuvauksen ja kerroin ehdokkaalle, että palaan takaisin kymmenen minuutin kuluttua vastaamaan kaikkiin sitä koskeviin kysymyksiin, minkä jälkeen hänellä on yksi tunti tehtävän suorittamiseen.

Kun palasin kymmenen minuutin kuluttua vastaamisen jälkeen kaikkiin kysymyksiin, kertoi ehdokkaalle, että jos hän ei ole varma, että hän pystyy suorittamaan tehtävän kaikki osat tunnin sisällä, hän voi harkita keskittymistä osaan tehtävää, jonka hän voi suorittaa ja päästä ajamaan määrätyssä ajassa. Mainitsin myös, että jos hänellä olisi lisäkysymyksiä tunnin aikana, hän voisi löytää minut kahden kaapin päästä ja kysyä.

Koska kirjoitin testin, pystyin suorittamaan sen alusta loppuun noin 45 minuutissa. En ehdottomasti odottanut ehdokkaiden suorittavan koko kokeen tunnissa. "Absurdinen" aikaraja oli voimassa kolmesta syystä:

  1. Halusimme nähdä, onko hakijalla edes puoliksi kohtuullinen käsitys työn vaatimuksista. Muista, että tämä oli ylemmän tason tehtävä. (Reilusti yli puolet ajasta vastaus oli ei.)
  2. Ehdokkaan tulee pystyä analysoimaan perusvaatimukset ja jakaa ne hallittaviin, erillisiin tehtäviin.
  3. Testin jatkaminen yhden tunnin kuluminen vie enemmän ehdokkaan aikaa antamatta meille paljon mahdollisia lisätietoja.

Tunnin lopussa pyysin ehdokasta näyttämään minulle, mitä hänellä oli, onko hänellä ollut mitään osaa käynnissä olevasta ratkaisusta demonstroitavaksi jne. Meillä olisi yleensä noin viisi minuuttia aikaa käydä läpi työ tässä vaiheessa, sitten ehdokkaalla olisi henkilökohtainen haastattelu johtajan kanssa. Tuossa haastattelussa kehitystiimi tarkasteli kaikki ehdokkaan toimittamia tietoja. Odotimme todella tätä velvollisuutta, koska se ei ollut koskaan tylsää.

Jos ehdokkaalla oli toimiva ratkaisu, joka hoiti sen tarkoitetun osan kokonaistehtävästä, ehdokas melkein varmasti läpäisi tämän haastattelun vaihe. Vaikka ratkaisu ei vielä toimisi, jos voimme nähdä huomattavaa edistystä ja todisteita ehdokkaan pätevyydestä, harkitsemme tyypillisesti silti ehdokasta. Tarkistimme aina ehdokkaan selainhistorian nähdäksemme, mitä resursseja hän käytti.

Mukana olivat syyt todellisiin ehdokkaisiin:

  1. Kirjaimellisesti ei tuoteta mitään koko tunnin jälkeen. On valitettavaa sanoa, että tilanne tapahtui useita kertoja.
  2. Koodin plagiointi ehdokkaan nykyisestä työstä ja yrittäminen (ja epäonnistuminen) muokata sitä vastaamaan testin vaatimuksia. Kun epäilimme tätä, selainhistoria antaisi sen pois.
  3. Kyvyttömyys muodostaa yhteysmerkkijonoa sovelluksen yhdistämiseksi tietokantaan. Tämä saattaa tuntua hieman epäoikeudenmukaiselta, mutta muista, että etsimme vanhemman tason ehdokkaita, mukaan lukien vanhemman tason SQL Server -kehityskokemus. Emme todellakaan odottaneet, että ehdokas muistaa yhteyden muodostamisen, mutta odotimme , että ehdokas pystyy etsimään sen nopeasti. ConnectionStringBuilder olisi myös ollut aivan hieno, mutta kukaan ei koskaan käyttänyt sitä. Ensimmäinen esimerkki osoitteesta https://www.connectionstrings.com/sql-server/ olisi toiminut hienosti.

Haastattelussa oli toinenkin osa johtajan ja kehitystiimin kanssa yhdessä, ja kysyisimme ehdokkaan ratkaisusta, siitä, miten hän olisi lähestynyt loppuosaa. jne. "absurdi" -testi ennen sen hylkäämistä käsin.

PhD
2018-08-02 07:00:29 UTC
view on stackexchange narkive permalink

Kahden tunnin mielettömässä teknisessä testissä ei ole ehdottomasti mitään vikaa. Kaikkien muiden ehdokkaiden olisi tehtävä sama testi, joten todennäköisyyssi saada työtä ei eroa helposta aloittelijan ohjelmointiharjoituksesta. Ei ollut puolueellisuutta; sinua pyydettiin tekemään se yksinkertaisesti siksi, että olit hakenut tehtävää.

Olet myyjä työmarkkinoilla, ja sinun vastuullasi on majoittaa ostajat mahdollisimman paljon. Sinulla on vähän neuvotteluvoimaa kuin mennä toiseen asemaan. Ohjelmointitesti, joka kaikkien ehdokkaiden on tehtävä, ei tietenkään ole kohtuutonta riippumatta siitä, voitko tosiasiassa kilpailla vai ei. Jos sinulla on korkea pätevyys työhön, mutta et pysty suorittamaan testiä, muut ehdokkaat eivät myöskään pysty suorittamaan sitä. Joten mikä ongelma on?

Yrität parhaasi mukaan. Oletko vihainen siitä, ettei sinua tarjota tehtävään? Yrityksen on palkattava joku, joten joku muu on saattanut tehdä parempaa työtä. Mahdotonta ohjelmointitestiä varten on löytää parhaiten menestyvä ehdokas. Sillä, onko paras ehdokas suorittanut harjoituksen, ei ole merkitystä.

kuinka voin päättää, pitäisikö minun suorittaa absurdiksi katsomia teknisiä testejä

Sinun pitäisi tuntea olosi mukavaksi mihin tahansa tekniseen kokeeseen, jos luulet, että sinulla on taitoja työhön ja kaikkien muiden ehdokkaiden olisi tehtävä se. Älä koskaan tee hullua testiä, jos uskot, että se on yritys ilmaisiin ohjelmointityöihin tai / tai annettu sinulle puolueellisuuden (esim. Rasismin) takia.

PS: En koskaan maininnut, että OP ei ole " tarpeeksi hyvä ". @TessellatingHeckler

"* Varmasti ohjelmointitesti, joka kaikkien ehdokkaiden on tehtävä, ei ole kohtuutonta *" - se ei seuraa lainkaan.
@TessellatingHeckler ??Jos ehdokas A tekee sen, B tekee sen, C tekee sen ... Yritys valitsee parhaiten suoriutuneen ehdokkaan, mikä on ongelma?Kilpaileeko paras ehdokas todella, ei ole merkitystä.
@TessellatingHeckler OP ei voinut kilpailla testissä, niin olivat myös muut ehdokkaat.Tarjoa paras ratkaisu 2 tunnin määräajassa.Mikä siinä on ongelma?
@TessellatingHeckler Kysymys muistutti pikemminkin häviötä toiselle paremmin menestyvälle ehdokkaalle.
"* miten voin päättää, pitäisikö minun tehdä teknisiä testejä, joita pidän järjettöminä?OP: lla?
@TessellatingHeckler Se ei ollut huijaus.En sanonut, että OP ei ollut tarpeeksi hyvä.
@TessellatingHeckler päivitin!
Olen tehnyt "vaikean" ohjelmointitestin 3 tunnissa."A, B, C" -tehtävistä onnistuin suorittamaan vain tehtävän A, mutta niiden tärkein ero tässä oli se, että tekninen johtaja ja kehittäjä tarkastelivat ratkaisuani heti sen suorittamisen jälkeen.Tämä varmistaa, että ratkaisu toimii, on "tuore", ja meillä on mahdollisuus käydä läpi koodi yhdessä ja keskustella siitä.Pystyin parhaiten kaikista ehdokkaista (kukaan muu ei suorittanut tehtävää A) ja sain työpaikan.Joten ehkä joskus sinun täytyy vain tehdä parhaansa näennäisesti mahdottomasta tilanteesta sen sijaan, että hämmentäisit / luovuttaisit ??
Mitä muita ehdokkaita?Tämä on ylemmän tason tehtävä, ** muita ehdokkaita ei ole **.
@Davor?Vain junioriasemilla on ehdokkaita?Vain vanhempi taso OP voi hakea, eikä kukaan muu?Jos OP ei saa työtä, kukaan ei ???Mistä puhut?Mistä tiedät, ettei tehtävään ollut ehdokkaita?
@Davor Tarkoitatko, että OP on ainoa vanhempi ohjelmoija tällä planeetalla?Vain hän voi hakea johtotehtäviin?Testi, jonka häneltä kysyttiin, tehtiin vain hänelle?
Sijainnista riippuen vanhemmat ohjelmoijat voivat todellakin olla uskomattoman harvinaisia.Täytetty avoin työpaikka oli ollut avoinna __2 vuotta__ ennen kuin he onnistuivat saamaan minut.Asuinpaikkassani on yleensä varma, että ylemmässä asemassa ei ole muita ehdokkaita.Mutta se todennäköisesti vaihtelee paikasta toiseen.


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 4.0-lisenssistä, jolla sitä jaetaan.
Loading...