Perché la domanda "Dare cinque cose che odi di C #" è così difficile rispondere durante un'intervista? [chiuso]

Se dovessi indovinare:

1. Alcuni programmatori non hanno una diversa esposizione linguistica. È difficile vedere le cose che non vanno nel linguaggio quando non sai che esistono cose migliori.

2. Alcuni programmatori sono mere scimmie di codice. Analizzano a malapena i problemi di fronte a loro, per non parlare di come il loro linguaggio di programmazione potrebbe essere migliore.

3. Poche persone sono particolarmente critiche. Vedono vantaggi e caratteristiche, non mancanze. È difficile per loro spostarsi in quel modo di pensare se l'intervista non sta andando in quel modo.

4. Almeno da queste parti, essere eccessivamente critici è considerato un fatale difetto di personalità. Invece di essere "lo sviluppatore perspicace che è sempre alla ricerca di modi migliori di fare le cose" (come alcune aree che ho vissuto), sono "quel coglione che odia tutto". Persino le persone che riescono a pensare a cose che odiano nella lingua potrebbero differire in un'intervista impostando un aspetto meno acerbo.

Immagino che la domanda sia così difficile da rispondere durante un'intervista perché è:

1. Davvero inatteso,

2. Richiede molto pensiero e un pensiero in un modo molto diverso da quello utilizzato durante un'intervista,

3. È difficile rispondere in generale in un breve lasso di tempo (a meno che non sia stato preparato prima dell'intervista).

1. È inatteso

Le domande inaspettate sono davvero difficili, specialmente in un contesto stressante. Immagina la seguente finestra di dialogo durante un'intervista:

‒ What's the difference between HashSet<T> and List<T>?
‒ The hashset is optimized in a way that the search for an element is very fast. For example if you're using set.Contains() within a loop lots of times, moving the set from list to hashset may make things faster.
‒ How do you create a read only property?
‒ I use a field marked as readonly as a backing field for a property which has only a getter.
‒ What is the usage of sealed?
‒ You use it for classes which must not be inherited.
‒ What's the last time you've seen a dentist?
‒ What?!

2. Richiede molti diversi pensieri

Quando ti vengono poste domande tipo intervista generale, stai usando la memoria per ricordare ciò che hai imparato dai libri o dalla tua pratica sulla lingua e il quadro. Potresti pensare un po 'per trovare una risposta, ma non troppo.

D'altra parte, la domanda sulle cinque cose che odi richiede un pensiero più profondo. Non puoi semplicemente ricordare qualcosa che hai imparato dai libri, e non puoi trovare nulla per analogia. Invece di essere passivi, devi essere critico e trovare ciò che potrebbe essere sgradevole nella lingua che usi.

3. Richiede tempo

Francamente, ho la mia lista di cinque (in realtà più) cose che odio di C #, ma ci ho pensato per un lungo periodo di tempo. Alcune cose provengono dall'era di .NET Framework 2; la maggior parte dei problemi che ho elencato per .NET Framework 2 non sono più validi perché sono stati rimossi, alcuni con LINQ e tutta questa roba di programmazione funzionale, altri con programmazione dinamica. Non sono sicuro che, senza preparare questa domanda, sarei in grado di trovare tutti i cinque elementi durante un'intervista.

Penso che sia difficile a causa della parola cinque . E in misura minore, a causa della parola odio .

Cinque ? E se ti venisse in mente solo quattro? Hai omesso di rispondere alla domanda? Cosa succede se hai più di cinque? Ora, sul posto, devi capire quali di questi sono i migliori cinque da usare.

L'odio è una parola molto negativa. È il tipo di negatività che alle persone viene detto di evitare nelle interviste. Inoltre, penso che sarebbe strano per molte persone avere molte cose che "odiano" di una lingua in cui passeranno tutta la giornata a programmare. Alcune persone potrebbero anche pensare che sia una domanda trabocchetto: se effettivamente fai ottieni cinque cose, saranno squalificate per odiare C # troppo da programmare bene. Sfortunatamente, questo genere di domande perverse non è mai sentito nelle interviste.

Invece, potresti chiedere a Cosa miglioreresti su C # se dipendesse da te? Ciò consente all'intervistato di rispondere con un numero qualsiasi di cose. Questo fraseggio scambia anche la negatività della parola "odio" per il "miglioramento" relativamente positivo.

• La maggior parte dei candidati non è così profondamente coinvolta in più di un linguaggio o paradigma per contrastare . Non ho lavorato con un altro linguaggio orientato agli oggetti per oltre 5 anni, e quello in cui avevo lavorato (PowerBuilder), ho avuto un lotto di peeves con. La maggior parte dei ragazzi appena usciti dal college sono (o pensano di essere) roba calda in uno, forse in due lingue e hanno ricevuto "esposizione" a tre o quattro (significa che hanno completato almeno un compito a casa che lo richiede ma meno di un intero semestre corso studiandolo). Non è abbastanza conoscenza o esperienza per sapere veramente cosa c'è che non va nella lingua. Ottieni un lavoro nel mondo reale, e quella concentrazione si restringe considerevolmente; impari molto di più sulla lingua che ti dà lo stipendio di ogni altro e, nel processo, arrivi ad accettare ciò che la lingua non farà o fa in modo strano, al punto da non ricordare facendo diversamente.

• La maggior parte dei candidati al C # che la confrontano con Java / C / C ++ ne sono molto contenti . C # è stato progettato da zero per fare un sacco di cose meglio di Java (eventi, callback, la libreria grafica, il lavoro di database). Java a sua volta è stato progettato per essere più facile da usare e quindi più focalizzato sul codice corretto, rispetto a C ++. Devo ancora incontrare un programmatore C # che voglia tornare al C ++ in qualsiasi ambiente in cui le prestazioni a livello di vesciche e il controllo a livello di quasi-circuito non sono requisiti indispensabili.

In altre parole, i See-Sharpers lo hanno abbastanza bene, tutto considerato.

Ecco la mia lista:

• istruzioni Lambda non guardabili / valutabili . Le chiamate ai metodi denominati possono essere inserite in QuickWatch di VS. Quindi le espressioni possono. Ma lambda? No (almeno non in VS2010). Rende il debug delle catene di Linq un vero lavoro di routine.

• I valori dei parametri opzionali per tipi di riferimento diversi dalla stringa possono essere nulli . se stavo creando un sovraccarico, potrei voler usare altri valori di default. Potrei essere in grado di default un valore basato su una proprietà o un'espressione semplice basata su un altro parametro. Ma non posso. Quindi il valore di non dover creare uno stack di sovraccarico (che è minore con un assistente di refactoring come ReSharper per gestire il boilerplate) è diminuito quando le opzioni per i parametri facoltativi sono così drasticamente limitate.

• C # sta diventando abbastanza vecchio da avere seri problemi con i codici legacy . Il codice originariamente scritto per 1.1 avrebbe causato orrore a chiunque fosse abituato a 4.0. Anche il codice 2.0 manca molto. Allo stesso tempo sono arrivate le librerie di terze parti che fanno sembrare ADO.NET tristemente primitivo (e gran parte del "modello connesso" di ADO.NET è ora un grande anti-modello). Eppure, per la retrocompatibilità, .NET supporta tutto il vecchio codice cattivo, non osando mai dire qualcosa come "ArrayList era un modo scadente di farlo, ci dispiace che lo abbiamo inserito e stiamo prendendo fuori, usa List invece e se hai assolutamente bisogno di un elenco di tipi diversi, dichiaralo come List<Object> .

• Regole per le dichiarazioni degli switch seriamente limitate . Probabilmente una delle cose migliori che potrei dire su PowerBuilder è che l'istruzione Choose Case (equivalente a switch) consentiva espressioni booleane basate sulla variabile. Permetteva anche di far cadere le istruzioni di commutazione anche se avevano il codice. Capisco le ragioni per cui quella seconda non è consentita (è più probabile che venga eseguita involontariamente che apposta) ma sarebbe comunque carino di tanto in tanto scrivere una dichiarazione del tipo:

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }
  

• Nessuna interfaccia inumerica . Se è un numero, puoi fare matematica con esso. In molti casi il metodo attuale non deve preoccuparsi esattamente di quali tipi sono collegati; la precisione è la responsabilità del chiamante. Tuttavia non è possibile creare un metodo o una classe generici che possano accettare solo tipi di numeri come GTP.

Suggerirei che parte del problema è la paura di dare una cattiva risposta - tu dici di odiare X, l'intervistatore ama X o pensa che la tua ragione per odiare X sia idiota, dicendo che pensi che va bene potrebbe sembrare il meno opzione controverso.

Probabilmente è anche qualcosa a cui la maggior parte della gente non ha pensato molto; hanno problemi attuali e problemi passati, i problemi passati causati dalla langauge sono finiti e quindi la gente pensa principalmente alla soluzione e non al problema in quanto è più significativo, e pochi avranno un problema attuale causato dalla lingua.

Per un'intervista chiederei solo l'1 o il 2, ma sono d'accordo, se non puoi nominare alcun limite dello strumento che usi, probabilmente non lo sai molto bene. Facciamo questa domanda esatta su SSIS e aiuta davvero a separare il grano dalla pula; tutti quelli che abbiamo assunto che hanno risposto a questa domanda si sono trasformati in un grande impiegato. Abbiamo bisogno di persone che abbiano una conoscenza avanzata actaul non qualcuno che l'abbia guardato un paio di volte. E scommetto che è quello che vuoi anche tu.

Penso che sia una domanda valida e il fatto che così tanti non possano rispondere è solo un esempio di quanto siano davvero poveri molti dei candidati al lavoro. Se qualcuno non è abbastanza analitico da essere in grado di capire alcune limtitazioni dello strumento, come sarà mai abbastanza analitico da risolvere problemi di programmazione difficili?

È come se tu avessi detto che non hai esperienza approfondita con C # e / o mancanza di esposizione ad altre lingue. Ho intervistato un certo numero di sviluppatori che si consideravano senior che non potevano rispondere ad alcune domande che anche un leggero graffio sulla superficie di C # avrebbe dovuto rivelare a loro.

Senza scavare abbastanza, non raggiungerai i limiti della lingua e vorresti che non ci fossero. I miei primi cinque nel caso qualcuno si stia chiedendo

1. Gli oggetti immutabili richiedono un sacco di cerimonie per creare (al contrario di un linguaggio funzionale in cui gli oggetti sono immutabili per impostazione predefinita).
2. La metaprogrammazione è difficile da fare. Confronta i tipi emit con le macro Lisp. (I servizi di compilazione aiuteranno molto in futuro).
3. I metodi di estensione sono grandi ... le proprietà di estensione e gli operatori di estensione (in particolare gli operatori impliciti ed espliciti) sarebbero migliori.
4. I cast espliciti vengono risolti in fase di compilazione anziché in fase di esecuzione.
5. Nessuna corrispondenza alla sequenza è molto più pulita dell'overloading della funzione.

Penso che nel suo giro sul modo in cui sta dicendo; se pensi che sia rotto probabilmente non capisci perché è così com'è. Potrebbe esserci un buco nella tua conoscenza.

Ironia della sorte, gli intervistatori che pensano che stiano citando "il grande Joel" usando quella domanda come intervista sono probabilmente piuttosto privi del punto.

Potrebbero essere riluttanti a rispondere perché potrebbero avere l'impressione che se possono elencare 5 cose che odiano di una lingua che l'intervistatore potrebbe voltare e dire "Oh, stiamo cercando C # 'ninja' e sembra che non ti piaccia la lingua 'o' Perché hai fatto domanda per il posto di lavoro se non ti piace la lingua? '.

Gli intervistati sono sottoposti a molte pressioni per rimanere positivi durante le interviste.

Perché le lingue danno forma al nostro modo di pensare . Usando C # tutti i giorni, hai preso l'abitudine di pensare e progettare il tuo codice in un modo che naturalmente aggira i problemi della lingua.

Ora lo fai senza pensare, senza nemmeno sapere che lo fai. Questo è il motivo per cui è così difficile indicare quali sono le cose brutte. Non c'è dubbio che il giorno in cui hai iniziato ad imparare C #, hai trovato un sacco di problemi, ma ora non li vedi più. Le abitudini sono cose potenti. Abitudini di pensiero, ancora più .

Il lato positivo di questo è, se trovi difficile elencare i difetti in C #, deve essere perché sei un buon programmatore C #, ti piace la lingua e usala più di altre lingue.

Ma se vuoi diventare più capace di vedere i difetti in C #, devi cambiare il tuo modo di pensare. Ulteriori informazioni sui linguaggi di programmazione e sii abituato a loro. Mira alle più diverse lingue possibili. Sei abituato a digitare in modo statico? Prova Python o Ruby. Sei abituato a orientato agli oggetti e imperativo? Haskell è un altro mondo interamente.

E quando torni a C #, sarai come, "Perché ho bisogno di cento linee di C # per fare questa cosa semplice che è solo una riga in Haskell?". Odierà molte cose su C #.

• C # non ha tipi di riferimento non annullabili.
• Nessun tipo di dati algebrici.
• Nessuna interpolazione delle stringhe.
• La sintassi è eccessivamente prolissa ovunque.
• Nessun sistema macro.
• L'inferenza del tipo è limitata.
• Nessuna espressione regolare.
• Nessuna tipizzazione strutturale.
• Supporto scarso per l'immutabilità
• Le strutture C # sono soggette a errori
• La raccolta di raccolte standard è molto limitata.
• Impossibile definire i vincoli sui parametri dei costruttori.
• Impossibile programmare genericamente con vincoli sugli operatori matematici.
• No 'newtype'.
• Nessun allineamento di array, nessun intervallo letterale.
• Le funzioni non elencano gli effetti collaterali che possono fare come parte del loro tipo. :)

(Naturalmente nessuna lingua può avere tutto, la progettazione della lingua è estremamente difficile e l'aggiunta di tutte le funzionalità nella stessa lingua non può funzionare. Diversi strumenti per scopi diversi.)

Sì, la domanda è difficile da rispondere bene, specialmente durante un'intervista. Ma le persone che possono rispondere provano che ci hanno pensato, che hanno una certa prospettiva.