Cele mai cautate limbaje pentru internship

dani.user, on 24 ianuarie 2018 - 19:57, said:

pai in back-end se face si  system programming, ca intr-un os de tipul time-sharing, kernelul nu este in mod sigur in front-end.
La unele corporatii system programming-ul este 70 % din aplicatiile back-end , restul fiind CRUD apps.

Quote

contraexemplu: cod sursa pentru aplicatie tipica back-end, unde lucreaza mii de engineri software:
https://github.com/torvalds/linux

I give up

From 24 ianuarie 2018 - 17:28:

Exact asta se cere ... sa nu intelegi nimic din ce faci, daca se poate sa nu ai deloc intrebari, dar sa faci perfect task-urile. Inca un pas pana la un code monkey! Welcome to Corporation Area!

A invata ceva fara o documentatie, fara a studia acea parte, este munca facuta... sa fie.

Din pacate.

Edited by Rhesus, 24 January 2018 - 20:48.

Rhesus, on 24 ianuarie 2018 - 20:44, said:

Pai in corporatii este multa birocratie, in plus daca ne luam dupa termenul de "code monkey"  ma exact definitia acestuia atunci cei care porteaza aplicatii dintr-un limbaj de programare
in alt limbaj, sunt code-monkey , desi trebuie sa cunosti bine cele doua limbaje, sa cunosti foarte bine semantica celor doua limbaje.

Dupa definitia termenlui de cod monkey cineva care face portare de software ar fi un perfect exemplu de "code monkey".Problema este ca de obicei doar  profesionistii cu ani buni
de experienta sa baga/sunt pusi la portare de aplicatii dintr-un limbaj in altul.

Quote

Pai se invata facand, adica faci si inveti, inveti si faci. Iar apoi sa stii ca multi obisnuiesc sa nu scrie documentatie din mai multe motive
insa principalul motiv(si asta apartine TeamLeaderului) este ca daca nu ai o documentatie trebuie sa-l intrebi pe TeamLeader-ul  despre
impactul unui feature intr-un sistem, chestia asta face sa fie greu de concediat acel TeamLeader.
Apoi de multe ori, nici nu trebuie documentatie din moment ce scrii cod self-explanatory.

Edited by navistar_eagle, 24 January 2018 - 21:06.

Nu am întâlnit backenduri care să fie în mare parte CRUD, CRUD e boilerplate necesar, dar mereu trebuie făcute alte lucruri de business în urma unui insert sau update, sau chiar și delete, și de cele mai multe ori ai 2-10 valori în funcție de care iei decizii.

Depinde de proiect, dar în mare, când a scrie cod pentru crud doare, începi să scrii cod care generează acel cod.

OriginalCopy, on 24 ianuarie 2018 - 21:23, said:

Personal cand am de facut un CRUD dau o cautare pe google limbaj + crud si ii dau bice.

Revenind la intrebarea initiala: JS ESTE completarea fireasca la CSS si HTML.

Dc vrei poti sa continui C cu C# si sa te specializezi pe back end (offtopic tocmai dat de un do-while in C#).

navistar_eagle, on 24 ianuarie 2018 - 18:24, said:

...e si cea mai buna modalitate sa vezi ce poate face omul. Decat sa pierzi luni de zile cu interviuri etc.

HTML și CSS nu sînt limbaje de programare.
Poate ar fi util sa înveți PHP dacă tot vrei să "legi ceva" de HTML, și de asemenea să fie ceva nu prea complicat.

XON-XOFF, on 25 ianuarie 2018 - 11:13, said:

Hmm, PHP mai mult face puntea de back-end.
Tot JS/Angular cred ca leaga mai bine HTML'ul.

exydos, on 24 ianuarie 2018 - 15:16, said:

1. C nu am vazut sa se foloseasca pe piata decat pentru embedded.

Conteaza sa stii C in sensul de: ex. stii sa lucrezi cu intreruperi/thread-uri sau chestii de programare in timp real? Daca nu -> ori inveti, ori mergi pe programare mai high-level.
Pentru internship totusi s-ar putea sa fie ok sa stii doar structuri de date/array-uri/matrici/citire/scriere/string-uri, deci chestii de baza.
Ca oarecum se presupune ca le inveti in internship. Totusi, trebuie sa stii la ce sa te astepti.
Mai e o chestie: ai background tehnic?
Din cate am vazut nu se prea angajeaza decat ingineri pe embedded pentru ca in general lucrezi cu/(aproape de) hardware.

2. HTML si CSS sunt pentru front-end pagini web.

Aici pare ca vine natural sa inveti javascript.
Pe javascript din cate am vazut/auzit de pe la prieteni care lucreaza in js, chiar se cauta. In principiu, in internship te pun sa lucrezi fie cu angular (pe front), fie cu node.
JS-ul a devenit foarte popular si am vazut ca toata lumea a inceput sa mearga pe el (ceea ce nu e neaparat un lucru bun pentru un om nou in js) dar se si cauta.
Habar nu am daca cei care implementeaza partea de front in js fac si chestii de html/css. Aici poate ne lamureste un cunoscator.
Am vazut ca multi aleg sa faca web service-uri in node pentru ca... overall e mai ieftin (desi nu cred ca un proiect serios ar trebui sa se faca in node.. dar ma rog..) . Deci, daca te intereseaza partea de API poti sa incerci sa te familiarizezi cu node.

3. Cel mai popular limbaj la ora actuala e Java

Pe el am ales si eu sa merg. Nu pentru ca se cauta, ci pentru ca... mai mereu alegeam sa-mi fac proiectele de la facultate in java  <chiar daca il foloseam pentru chestii gen: sa comunice cu un microcontroller >.
Daca ai mai avut ceva tangente cu POO poti sa incerci Java. De la sine, el nu face mare branza dar are un.. ecosistem al lui.

4. Mai exista PHP pe partea de back-end. Un limbaj pe care nu-l prea agreez dar pe care o sa-l prinzi destul de repede.

eMag-u spre exemplu am vazut ca e blocat in trecut si angajeaza pe php. Mai sunt... multe alte firme.

Concluzia:

Daca ai terminat vreo facultate de inginerie si ai idee de lucrurile pe care le-am enumerat mai sus => incearca C.

Daca nu, incearca sa inveti basic javascript, apoi uita-te putin peste angular si du-te la internship.
Vezi ca pe site-urile de job-uri gasesti descrieri cu privire la ce vor de la tine pentru a te lua in internship.

Eu unul nu am mai facut internship ci am mers entry-level. Dar spre deosebire de carcotasii de pe aici, consider ca un internship e o experienta buna, care te invata cel putin cam cum e flow-ul intr-o firma mare si cam ce trebuie sa stii de fapt (framework-uri, metodologii etc.).
Desi par lucruri marunte, e imposibil sa le intelegi de la o simpla discutie la o cafea cu un prieten care lucreaza in domeniu.

Edited by MarianG, 26 January 2018 - 15:36.

Dar daca fac o eventuala facultate , de ex info la UBB , am voie de ex sa fac tot ce mi se cere in python ? Sau numaidecat trebuie sa fac in c++ ?

La facultate studiezi diverse si aplici asemenea, nu-i dupa cum vrei tu. Si e bine asa, trebuie sa cunosti cat mai multe.

navistar_eagle, on 24 ianuarie 2018 - 20:57, said:

Nu. Pentru mine, un code monkey este o persoana care habar nu are ce reprezinta codul ala, dar care este pus sa lucreze la el, ca "asa trebuie". Si hai sa recunoastem, 99.999% dintre "corporatii" asa procedeaza: Au un proiect de zeci de mii de linii de cod (vorbim de 8000-10000 in sus), si "na, hai da-i bataie! Pana saptamana viitoare vrem primul release".

Nu am pretentia ca oricine sa fie full stack-developer (desi mi se pare aiurea sa livrez o interfata grafica fara sa am habar de interactiunea cu back-end-ul) - dar e alta poveste.

Ideea e ca intr-o corporatie, daca te misti rapid, oricat de prost ai face ceea ce faci, e bine. Daca ii iei la intrebari, sau ceri o perioada de timp pentru documentare: eject, "n-avem timp". So ... prost si mult, decat putin si eficient(corect/sau cum vreti voi).

PS: @navistar . De ce oare 80% din cod este retrimis de testeri catre dezvoltatori ? Oare nu pentru ca e facut PROST?
Atata timp cat nu se mai pune pret absolut deloc pe calitate, ci pe cantitate, cercul vicios: dezvoltator - tester - dezvoltator va exista.

O companie care se respecta (sau nu numai: inclusiv un programator "simplu"), ar trebui sa aiba (o mentalitate) un standard minim de performanta. Este absolut ridicol ca mai mult de 50% din munca angajatilor sa ajunga din nou la re-re-re-recoding, ba ca a aparut un bug, ba ca ninge, ba ca ploua.

Eu de exemplu, pot scrie intr-o zi hai sa zicem maxim 600-700 de linii de cod. Tot ce e mai mult, ori e pe langa, ori intervine oboseala, etc. Dar cand aud monstruozitati de genul: "Frate, am scris ieri 6000 de linii de cod", deja e SF. Cand ai gandit codul? (daca l-ai gandit, sau l-ai scris ca un papagal).
Ii rog sa-si spuna parerea si colegii mai avansati decat mine (de pe forum). Cred ca inclusiv la un nivel avansat, target-ul e undeva la 1500-2000 de linii/zi. Ce e mai mult, deja e pe langa.

Edited by Rhesus, 26 January 2018 - 22:37.

Înainte de toate, LOC nu e o măsură bună a complexității, iar complexitatea nu e mereu o măsură bună a plus valorii.

Cel mai de valoare cod pe care l-am scris într-o zi nu a fost nici măcar o linie de cod, ci modificarea uneia existente. Dacă nu mă înșel, am schimbat un singur caracter. Era o linie într-un sistem de vreo 5k LOC prin care treceau zilnic multe milioane de euro. Și nu s-a plâns nimeni că aș fi făcut prea puțin în ziua aia, din contră, am primit și o mărire de salariu mai târziu.

O măsură mai bunicică ar fi complexitatea ciclomatică.

Acestea fiind spuse, nu cred că am trecut vreodată de 1k LOC pe zi, decât dacă am generat acel cod boilerplate.

Ce fel de cod ar trebui să fie acela pe care îl scrii într-o zi și e un roman? Ce spune cantitatea de cod despre complexitatea sa ciclomatică?

Deci din contră, cred că cu cât ești mai avansat, cu atât scrii mai puțin cod. Codul care e mult fie îl generezi, fie îl abstractizezi.

Sau îl delegi unui novice din echipă.

De multe ori stergi cod in loc sa scrii
Oricum sa numeri liniile de cod cred ca e cea mai mare prostie, nu reprezinta nimic

Rhesus, on 26 ianuarie 2018 - 22:21, said:

Pai asta  nu e code monkey , aceea persoana  nu intelege ceea ce citeste.Asta este analfabetism functional

Quote

Nu, la majortiatea corporatiilor 99% procesul de recrutare are 6 interviuri si dureaza 50 de zile . Dupa ce tipul este angajat , atunci sa stii ca acel tip stie sa inteleaga
din codul ce i se da  cum lucreaza.De asemeni nush de unde ai venit cu numeratoarea liniilor de cod, pt ca este o tampenie.Nimeni nu tine cont de asta.
Apoi tu nu stii cum se face un release intr-o corporatie. Chiar daca codul este gata sa zicem , si testat ,acel cod va intra in productie peste 2 luni, pt ca in acest timp
cei de la QA luand versiune compilata a aplicatiei o vor pune pe un test-bed care replica mediul de lucru, unde efectiv metaforic "vor da de toti peretii cu aceea aplicatie" ca sa vada unde crapa.Si daca sunt buguri se reintra in ciclu de dezvoltare si se amana release-ul.

Quote

Ti se pare aiurea pentru ca  in proiectele pe care le-ai facut sau ai lucrat nu ati avut si un sofware arhitect ca sa gandeasca proiectul conform principiilor de proiectare
enterprise, care implica si extinderea principiului DIP( dependency INVERSION principle) la nivel de arhitectura.
Adica cu alte cuvinte acest principiul spune ca  nu trebuie sa stii si nici nu este necesar sa stii si munca ta nu trebuie sa depinda de rezultatul sau forma altui modul din acelasi proiect. In JAVA acest principiu se realizeaza prin intermediul interfetelor/claselor abstracte.

Cu alte cuvinte modulul tau pe care il dezvolti nu trebuie sa depinde  de functionareA  altui modul.Modulul tau se leaga de alt modul prin intermediul unei interfete.Tu  iti dezvolti modulul doar pentru acea intefata.Pentru tine, mai sus sau mai jos de aceea interfata nu te intereseaza pentru ca este un BLACK-BOX pentru tine.
Tu iti dezvolti modulul doar pentru acea interfata specificata. Alt coleg  de al tau face acelasi lucru insa pentru alta interfata.

Apoi vine arhitectul software si conecteaza prin linii de cod interfetele respective, et voila ,munca ta este cuplata cu munca altuia  fara ca nici unul  sa nu trebuiasca a stii ce face modulul celuilalt.

Apoi software arhitectul vine si da altui Gigel sa faca un modul care comunica cu back-endul si acel modul este legat tot de interfata.Gigel face modulul de I/O cu backendul pentru interfata specificata de ahitect.Pe Gigel nu-l intereseaza ce faci tu si cum lucreaza modulul tau pentru ca   Gigel  lucreaza doar pentru interfata care i s-a dat

Apoi software ahitectul leaga interfetele intre ele prin linii de cod , si trimite rezultatul catre o alta interfata. Alt software arhitect la randul sau leaga interfetele sale cu interfetele primului arhitect si trimte catre alt software ahitect si tot asa.
Si uita asa vei avea un lant de interfete care se pot cupla intre ele si decupla , realizand astfel diferite functionalitati  fata de care cei care au implementat modulele
habar n-au si nici nu trebuie sa aiba

Ca sa intelegi mai bine ce am zis eu iti trebuie sa cunosti design patterns si arhitectural enterprise design patterns.

Quote

Ba se pune, de aceea iti trebuie cam 6 interviuri in 50 de zile ,ca o corporatie sa-si faca  o idee

Quote

Asta probabil sunt in firmele bananire nu in corpoatiile care se respecta.Dar oricum noua ne vin proiecte si de la  astfel de corporatii bananiere(vine clientul cu codul in brate la noi sa-l rezolvam) si de obicei il costa cam 5X mai mult.

Quote

Eu niciodata nu mi-am numarat liniile de cod =)), haha ) asta ar fi tare.

La noi "code-monkey" insemana sa scrii software fara a te implica in partea de design a acestuia.
Ceea ce la tine inseamna "code-monkey" la noi inseamna analfabet functional si pica de la primul interviu (din seria celor de 6)

Edited by navistar_eagle, 27 January 2018 - 14:18.

Doar pentru ca unii fac lucrurile diferit nu inseamna ca nu stie.
Apoi daca este "gata si testat' ce mai cauta QA cu alte teste.
Daca ai bunavointa sa ma lamuresti.

Edited by MarianG, 27 January 2018 - 17:03.

Dar nu-i vorba de asa ceva.
Este vorba de a te uita pe o secventa de cod si da a-l citi si de a intelege ce face efectiv acel cod.
Este exact problema de la bac:

spuneti ce face urmatoarea secventa de cod : inainte ai black-box, vine secventa de cod , urmeaza black-box iarasi. Ce face secventa aia de cod ?
Cam la asta se rezuma problema in fond.