DashDash

Sehe das genauso. Worauf du dich fokussieren solltest ist, Erfahrung zu sammeln, denn Erfahrung ist trumpf in unserem Beruf. Möglicherweise gibt es ja auch die Möglichkeit eines bezahlten Praktikums mit der Aussicht auf Übernahme?

Und du möchtest/kannst das ERP System nicht anpassen? Dann brauchst du das Query nur für regelmäßige/ad hoc reports?

Ich finde wichtig zu verstehen, dass Komplexität in einem Monolithen nicht automatisch verschwindet mit Microservices. Die Komplexität geht nur vom Code in die Integration über. Auch wissen viele nicht, dass man nicht mit ultra kleinen Microservices anfangen sollte, wenn man nicht gerade sehr direkte Skalierungsprobleme hat... Microservices sollten so klein sein, wie man sie braucht - nicht unnötig ne Domäne aufbrechen z.B.

Die ganzen neuen Fintech Unternehmen machen auch kein COBOL, da steht buzzword bingo ganz oben auf der Liste: Big Data, Microservices, Cloud, etc :-)

Hört sich gut an. Größen sind tricky, weil die nicht unbedingt standardisiert sind.. jedes Land hat ihre eigenen größen und man kann in der Regel nicht von dem Größenraster eines Artikels auf einen anderen Artikel übertragen. Ich würde das ganze warscheinlich etwas komplizierter angehen. Anfangen würde ich mit der Definition einer Größenraster Tabelle, die hätte eine Referenz auf verschiedene Größen und einen sortkey. Eine Größe wäre erstmal nur als Name definiert (wo man später noch mehr Felder hinzufügen kann). Die Artikel würden dann eine Größe referenzieren. Wenn du sortieren möchtest, müsstest du über die Größe zum Größenraster hinjoinen und könntest dann sortieren anhand des sort keys. Der Vorteil ist, das du dann auch andere Größen für allerlei Artikel ordentlich sortieren kannst - weil es eben nur innerhalb eines Artikel Größenrasters sortierst. Wenn du alle Artikel sortierst, müsstest du doppelt sortieren nämlich einfach z.B. auf dem Artikel name und dann auf dem sortkey innerhalb des Größenrasters. Das ganze hier stützt sich auf die Annahme, dass ihr nicht ausschließlich Schrauben nutzt wo dasselbe Größenraster genommen wird. Das ganze soll natürlich nur als Denkanstoß für dich dienen :-)

Klar ist das möglich. Die Frage ist ob das ein Problem ist, das man mit SQL angehen sollte. Ich sehe spontan mehrere Möglichkeiten, zu aller erst musst du die Werte die dir wichtig sind alleine kriegen (damit du darauf sortieren kannst). Das kannst du, wie z.B. Enno schon beschrieben hat machen. Du könntest diese Daten z.B. auch in eine temporäre Tabelle oder in einen View packen - das bedeutet zwar am Anfang mehr Arbeit.. wird dir aber letztendlich das abfragende Query sehr erleichtern. Die Alternative ist, dass man sich innerhalb der Applikation alle Daten holt und die split und sortier Logik dann dort implementiert, was wesentlich einfacher sein sollte. Die eigentliche Lösung ist aber, nicht mit diesen Daten rum zu hantieren sondern dir die Zeit zu nehmen diese Daten ordentlich zu normalisieren. Alleine dass du dir die Frage stellst, is eigentlich ein "smell" dafür, dass die Daten nicht ordentlich normalisiert sind :-)

Das halte ich aber für ein Gerücht, dass sich Software Entwickler nicht mit Netzwerken auskennen müssen. Wie würde ich sonst debuggen, warum meine Applikation langsam ist? :-)

Muss bei vielen Meetings immer hier dran denken.. :-)

Sehe das wie Goulasz. Es besteht gar kein Bedarf, dass du dich als Full Stack Entwickler profilieren musst. Ich würde mich z.B. auch als Backend Entwickler der Notfalls auch Full Stack kann bezeichnen. Meine Frontend Fähigkeiten beschränken das ganze dann aber, ich hab z.B. kein Bock auf Angular oder NodeJS.. ausserdem macht mir das einfach nich soviel Spaß, wie hoch skalierbare Systeme zu bauen :-) Ich würde dir vorschlagen, konzentriere dich auf etwas. Generell musst du natürlich nicht auf jeden Hype aufspringen.. da würden die besten Entwickler nicht mtikommen ;-) Konzentriere dich auf ein Kerngebiet, werde darin gut. Wenn das Kerngebiet dann noch langfristig Zukunft hat, is das doppelt gut. Überleg mal, selbst wer vor 20 Jahren COBOL gelernt hat - kann damit heute immernoch in Banken oder sonstigen Unternehmen alte Mainframe Software maintainen. Ich persönlich mache das so, dass ich mir gewisse Technologien aussuche und wenn ich die kann, dann dazu komplementäre Technologien z.B. Java und Python. Darüber hinaus habe ich mir nen Fokus gesetzt auf System Design und sauberen Code zu schreiben und mentore mitlerweile als Senior viele meiner Entwicklerkollegen. Setz dirn realistisches Ziel und arbeite darauf hin. Dabei kommt es nich drauf an bei jeder Frontend Technologie sofort aufzuspringen. Spezialisiere dich ruhig... die Spezialisten verdienen auch mehr und sind wertvoller für ne Firma :-) Achso und belese dich mal ein wenig über das so genannte Imposter Syndrome.. die Awareness da kann dir vielleicht auch helfen dich selbst besser ein zuschätzen

Ich würde sagen es kommt sehr dadrauf an wie das Team gemanaged wird bzw sich selbst managed. Da kommt es auf verschiedene Faktoren an, vor allem wenn es um agile Softwareentwicklung geht. Ich habe schon viele verschiedene Teams gesehen, manche meeten sich fast tot - andere reduzieren die Meetings radikal und stellen feste Agendas und Zeitvorgaben für die Meetings, die absolut notwendig sind. Aus Erfahrung kann ich sagen, dass es definitiv auch ohne viele Meetings geht - aber dazu muss man nen guten Prozess haben, denn die Produktseite möchte immer gerne auf dem Laufenden sein.. vielleicht noch andere Stakeholder, etc. Da muss man ggf. auch härter durchgreifen als Entwicklungsteam :-)

Bisschen spät, aber vielleicht hilft es ja doch noch :-) Ich denke, dass dein Arbeitgeber einfach mal versucht - ob er damit durch kommt. Das solltest du natürlich nicht zu lassen und ruhig und vor allem selbstbewusst mehr fordern. Gehalt verhandeln tut niemand gerne aber es ist schon wichtig, dass du dich entschieden positionierst. Komm ruhig auch gut vorbereitet in das Gespräch, liste auf was du geschafft hast in der Ausbildung und was für positive Effekte das im Unternehmen hatte. Dass du deine Ausbildung gemacht in dem Unternehmen und dich gut in ihm auskennst ist übrigens auch nen plus Punkt dafür, dich zu behalten. Das kostet nämlich viel Zeit, Leute in das Unternehmen "ein zu arbeiten", so dass diese dann auch produktiv sind..

Ich persönlich würde auch mit 32k gehen, wenn sie andere Vorstellungen haben - können sie dich ja immernoch versuchen runter zu handeln. Ich hab damals meine Ausbildung in einem Unternehmen gemacht, das sich hauptsächlich auf PHP Webseitenprogrammierung fokussiert hat und mit 36k angefangen (in Berlin) - allerdings war das auch keine Umschulung d.h. das Unternehmen kannte mich schon und konnte mich einschätzen. Dein Gehalt ist zwar wichtig um deinen Lebensunterhalt zu bestreiten aber ich finde die Erfahrung viel wichtiger, nehm soviel wie möglich an Erfahrung und Wissen mit in deinem Job. Nach 1 - 2 Jahren kannst du dann immernoch in einen deutlich besser bezahlteren Job wechseln. Hauptsache ist erstmal nen Job zu kriegen in dem du Erfahrung sammeln kannst und dann ordentlich ran zu klotzen :-) Mach dir vielleicht auch nen Plan was du alles gerne lernen willst und wie du das erreichst... Notfalls auch ausserhalb deiner Arbeitszeit, wenn dich das Thema fasziniert.

Sorry.. aber wenn du Bewerber ausfilterst basierend auf "Quatschfragen".. dann machst du oder dein Unternehmen etwas grundlegend falsch. "Natürlich bist zu zuverlässig, natürlich arbeitest du ordentlich und bist pünktlich. Aber das sagt jeder von sich." <- ich frage auch niemanden ob er zuverlässig oder pünktlich ist, das sind einfach die falsche Art von Fragen um etwas über den gegenüber kennen zu lernen. Du fragst nach Erfahrung und Reaktionen.. dann bleibt dem gegenüber immernoch die Möglichkeit zu lügen - aber das is wesentlich schwieriger, weil du eben erstmal erahnen musst, was du eigentlich als Antwort erwartest. Bei den Fragen die du hier postest, reicht mir auch nen Fragebogen - dafür brauch ich kein Gespräch. "Bist du pünktlich [ X ] Ja [ ] Nein". Das alles is doch kein Maß heraus zu finden ob jemand nen wertvoller Zusatz für die Firma is.. da kann ich nur den Kopf schütteln :-)

Eben genau das is mein Kritikpunkt, Westentaschenpsychologie. Einen Zusammenhang darüber zu ziehen wie sich ein Mensch in einem Bewerbungsgespräch (unbekannte Situation, starke Aufregung, fremde Menschen) und wie sich der Mensch denn dann wenn er sich eingearbeitet hat und in nem gutem Team ist verhält - das is Blödsinn und Wunschdenken. Ich persönlich bevorzuge nach Dingen zu Fragen die ich bewerten kann, technisches know how, Führungserfahrung, Situationen von früher und wie gehandelt wurde, etc. Aber zu glauben, dass man nen guten Einblick in den Charakter eines Menschen in ner Stunde Interview bekommt.. ist sowieso nen Irrglaube :-)

Was kann denn das über einen Bewerber aussagen? Selbe Frage dafür Fragen zu stellen, die rein gesetzlich gar nicht gestellt werden dürfen? Meiner Meinung nach sagt das überhaupt nichts darüber aus, ob der Bewerber zum Unternehmen passt und die nötigen Skills hat. Andersherum würde ich sagen, das sagt viel mehr über das Unternehmen aus - die ihre Personaler solche Fragen beantworten lassen. Wenn ich als Interviewer merke, dass ein Bewerber sehr aufgeregt ist - dann versuche ich ihm sicherlich anders die Angst zu nehmen als ihn scherzhaft nach seiner Religion zu fragen oder wieviele Elefanten bei Vollmond theoretisch auf einer Wippe Platz haben könnten