Gooose

Man entwickelt sich am besten weiter, wenn man mit anderen zusammenarbeitet. Bei einer "one man show" währst du alleine für deine weitere Entwicklung verantwortlich. Ich würde es nach Möglichkeit vermeiden.

Quelle Keine Abkürzung nehmen Schau dir die grundlegenden SQL Themen an. Aus meiner Sicht sind das geschenkte Punkte, da die Fragen häufig genau definiert sind. Mit "geschenkten Punkten" denke ich nicht nur an die Korrektheit, sondern auch an die Geschwindigkeit. Wenn du vorher übst, kannst du solche Aufgaben (wenn sie vorkommen) als erstes erledigen, und du kommst gut in die Prüfung rein. Die "gewonnene Zeit" kannst du in andere Fragen investieren.

Bei uns war es so, dass man sich bis zum Beginn der drei monatigen Vertiefungsphase entscheiden konnte wie die Reise weitergeht. Das hängt aber davon ab, wie der jeweilige Anbieter sein Angebot strukturiert hat. Ein wenig Spielraum hat er schon.

So lange ein möglicher Abbruch nicht selbst verschuldet ist, ist es kein Problem. Sollte man aber selbst daran Schuld sein, kann es dazu kommen, dass man ein Teil der Kosten tragen muss (man geht z.B. nicht hin, (hats gegeben)). Dies ist aber vertraglich geregelt. Bei möglichen Problemen kannst du dich mit deinem Sachbearbeiter in Verbindung setzten. In der Regel machen die das schon länger, und kennen ihre Pappenheimer. Der, der am meisten "leidet", "schreit" am lautesten. Bewertungen sind maximal Indizien, verlässliche Informationen sind hier nur schwer zu finden. Nutze die Zeit mit den Dozenten so gut wie es geht. Wenn es ein mal mit dem Dozenten nicht klappt, sprecht mit der Akademie/Umschulungsleitung. Kommunikation ist hier das A und O, gerade wenn hier und da Emotionen hochkochen. Organisiert euch untereinander und lernt zusammen. Jeder hat seine Stärken und Schwächen. Dies entschärft ein wenig die Qualitätsproblematik des Umschulungsunternehmens. Aus unserem Kurs hat ("damals") jeder die Prüfung bestanden, der auch angetreten ist.

In Dortmund konnte ich mir aus einer Datenbank das Umschulungsunternehmen raussuchen, was zu dem Bildungsgutschein passte. Die Unternehmen waren quer über das Ruhrgebiet verteilt. Ich habe mich letzten Endes für ein Unternehmen in Essen entschieden, da hier der Praxisanteil am höchsten war. Die Fahrtkosten wurden dann auf Kilometerbasis bezuschusst.

Ich habe immer eine Gehaltsvorstellung abgegeben. Egal ob danach gefragt wurde oder nicht. Dies erspart beiden Seiten Zeit.

Schon mal beim Vorgesetzten gefragt, ob dein Arbeitgeber das Buch anschaffen kann?

Ich gebe fixe Brutto Jahresgehälter an. Du weißt ja nicht, wie das Gehalt üblicherweise zusammensetzt (Urlaubsgeld, Weihnachtsgeld, erfolgsabhängige Anteile, ...).

Wie sieht es mit einer einfachen sms aus?

Hört sich an wie ein EMail Client Spaß bei Seite und OT .... ich habe bei mir weitestgehend alle Notifications ausgeschaltet (vor allem der Sound). Trotzdem habe ich alle wichtigen Nachrichtenquellen immer im Blick. Es bringt keinem etwas, wenn man ständig aus seiner Arbeit rausgerissen wird.

Angebot und Nachfrage. Wenn eine Firma bestimmte Fähigkeiten braucht, und du dies anbieten kannst, muss man sich nur noch über den Preis einig werden. Preisdrücker findest du überall. Denen ist es egal, was du für eine Ausbildung hast. Die werden immer etwas "finden" um den Preis zu drücken. Jenseits der fachlichen Fähigkeiten sind deine sozialen Kompetenzen wichtig. Wenn dein gegenüber denkt, dass du gut ins Team passt, ist das schon fast halbe Miete. Mit der Zeit hat deine Berufserfahrung ein höheres Gewicht, als deine Ausbildung, zumal man mit dem Lernen nach der Ausbildung nicht aufhört, sondern erst dann die Reise richtig los geht.

Du kannst es im ersten Schritt iterativ mit einer Schleife lösen. Ein rekursiver Ansatz ist auch möglich. Zudem kannst du dich mit diesem Beispiel in die Welt der Pointer Arithmetik einarbeiten. Je weniger komplex die Beispiele, desto mehr kannst du dich auf das eigentliche Problem konzentrieren.

Es ist zum Lernen gedacht. Ein String in c ist ein char Array. Du gehst über das char Array und zählst die Durchläufe, bis du das Zeichen \0 (Terminator) gefunden hast.

Vielleicht ist dies erst mal ein Schritt zu viel. Für die Prüfung brauchst du "nur" ein gesundes Grundverständnis. Nimm erst mal eine überschaubare Struktur (z.B. Person, Adresse, Kontaktdaten, ...) und erstelle die Datenbankstruktur. Mit einer Umgebung/Programmiersprache deiner Wahl (idealerweise eine, die du schon für deine Ausbildung verwendest), greifst du auf diese Datenbank zu. Erstelle einen Client, mit dem du Create/Read/Update/Delete Operationen ausführen kannst. Dies kann eine Konsolenanwendung sein, oder auch eine einfache Web Gui. Nimm möglichst viel Komplexität raus, und konzentriere dich auf die Datenbank Themen. Wenn du damit gut klarkommst, kannst du dich immer noch mit herstellerspezifischen Themen auseinandersetzen. Bis dahin konzentriere dich erst mal auf deine Ausbildung. Nach deiner Ausbildung hast du immer noch Zeit tiefer in das Thema einzutauchen.

Wie genau sieht die Arbeit aus? Wenn es ums Programmieren geht, könnt ihr das Liveshare Feature in Visual Studio (Code) ausprobieren. Einer startet die Session, und weitere schalten sich in diese Session ein. Wir nutzen es derzeit für unsere Team Katas. Ich kann dir aber nicht sagen, wie sicher dies ist. Für sensibele Daten würde ich es erst mal nicht verwenden.

Neben Prime nutze ich viel die öffentlich rechtlichen Mediatheken. Tagsüber läuft häufig WDR5. Abends schaue ich mal in die ARD/ZDF Mediatheken rein. In letzter Zeit haben sie häufig norwegische Kurzserien im Programm. Lineares Fernsehen kommt eigentlich kaum noch vor. Am Donnerstag gibt es (je nach Thema) noch die heiseshow.

@programmuser666 nehme doch mal die Ablehnungsgründe des Prüfers, und nehme die Punkte die du aus deiner Sicht verändern kannst und stelle deinen Antrag noch mal hier rein.

Das ist gut, und ich freue mich wenn du dein Projekt erfolgreich abschließen kannst. Idealerweise haben alle Beteiligten das selbe Verständnis / das selbe Bild vor Augen. Aber auch hier muss man mal in die Zukunft blicken. Beispiel: Während man ein Ticket / Problem bearbeitet stößt man auf einen Codeblock, den man sich nicht richtig erklären kann. Über den Commit gelangt man zu dem Ticket, unter dem dieser Block das letzte mal bearbeitet wurde. Idealerweise findet man dort ein wenig Prosa, eine Problembeschreibung, oder ein verlinktes Wiki Dokument oder Ähnliches, was einem weiterhilft. Es kommt durch aus mal vor, das viele Beteiligte von "damals" nicht mehr im Unternehmen sind, und diese Informationsbrocken das einzige sind, womit man arbeiten kann. Wenn man sich angewöhnt in knappen, und präzisen Worten komplexe / komplizierte Vorgänge zu beschreiben hat man langfristig ein einfacheres Leben. Man wird viel weniger angerufen oder angeschrieben, und die Arbeit im Allgemeinen verläuft flüssiger. Dieser Projektantrag ist ein gutes Beispiel dafür. Der Prüfer hat den Antrag nicht verstanden, und hat nachfragen gestellt. Völlig legitim. Effektiv zu kommunizieren erlernt man mit der Zeit und man wird mit der Zeit besser darin. Der Projektantrag ist die erste "Hürde" die man nehmen muss, um diesen Weg zu beschreiten.

Versetze dich mal in die Lage desjenigen, der sich diesen Antrag anschaut. Die Prüfer bekommen Tonen von Anträgen, die sie bearbeiten müssen, und viele machen das schon seit Jahren. Die sind dankbar für jedes klare Wort, was geschrieben ist. Mal angenommen, ein "kompliziert" geschriebener Antrag geht durch, und nach der Projektdurchführung wird klar, dass zu wenig passiert ist. Dann bekommt der Prüfling für sein Projekt eine schlechte Note. Damit ist keinem geholfen. Zudem ist es hilfreich, während der Projektdurchführung immer mal einen Blick auf seinen Antrag zu werfen um zu sehen, was man bisher geschafft hat, und was man noch machen muss. Es währe doch doof, wenn man jedes mal auch für sich selbst seinen eigenen Antrag noch mal "entschlüsseln" muss. Wenn man später im Arbeitsleben mit Ticketsystemen arbeitet und ein Ticket bekommt, was unnötig kompliziert geschrieben ist, würde es auch zu unnötigen Kommunikationsaufwänden führen. (Idealer Weise werden solche Tickets im Grooming vor der Planung noch mals aufbereitet, sodass man auch effektiv damit arbeiten kann). Im schlimmsten Falle bearbeitet man solch ein Ticket nach besten Wissen und Gewissen und weicht stark vom dem ab, was sich der Autor vorgestellt hat. Insbesondere im Zeiten von Corona, sollte die Kommunikation (asynchron via Ticket, Email oder Chat) möglichst einfach und schnörkellos sein, um allen Beteiligten die Arbeit zu erleichtern. Diese Art und Weise zu Arbeiten spiegelt sich auch in dem Projektantrag wider, und zeigt Problemverständnis und Kommunikationsfähigkeiten.

Damit man noch weniger versteht, was eigentlich gemacht werden soll? Der Projektantrag ist ein Kommunikationswerkzeug. Deswegen sollte man es als solches auch Nutzen.

Wenn du keinen Einfluss auf die Anwendung hast, kannst du Skripte wie wait-for-it nutzen, um auf die Datenbank zu warten. Dies löst aber nur das Problem beim Start der Anwendung. Es kann immer mal sein, das die Datenbank nicht zur Verfügung steht (Netzwerkprobleme oder Ähnliches). Dieses Scenario muss die Anwendung selbst abfangen.

https://docs.docker.com/compose/startup-order/ Docker-Compose hatte eine Funktionalität um beispielsweise auf eine DB zu warten, die aber wieder entfernt wurde. Ich denke auch, dass eine Anwendung mit Datenbankausfällen klarkommen muss. Dies würde ich auch außerhalb vom Dockeruniversum unterschreiben.

Wie willst du in der verbleibenden Zeit eine Diashow für Produktiv Systeme machen. Du musst ja dafür alles nachbauen. (wenn dafür überhaupt Hardware zur Verfügung steht)

Wenn man bei einer "normalen" Bewerbung zu viel verlangt, kann man schon schnell aus dem Rennen fliegen. Der Headhunter wiederum ist an einem Abschluss interessiert, und verweist auf das obere Limit. Sollte es für einen immer noch im Rahmen sein, willigt man ein und der zukünftige Arbeitgeber erfährt nichts von dem ursprünglich zu hohen Wert.

Man kann davon ausgehen, das die den Ramen genau kennen, da sie ja einen Vertrag mit ihrem Auftraggeber abschließen. Der Auftraggeber, muss ja auch wissen, welche Kosten auf sie zukommen.