Arbeitsplatz Bild DEVJobs.at

Die TechTalk Days

Description

Klemens Schreiber erzählt in seinem devjobs.at TechTalk den Werdegang des Karriereportals und den Hintergrund der TechTalk Days.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In „Die TechTalk Days“ stellt Klemens Schreiber von DEVJobs.at das Event vor und schildert die Entstehung von DEVJobs.at – vom ersten Büro im Kinderzimmer bis zum Prototypen mit SWL‑Komponenten, einer Express‑API und diversen SaaS‑Lösungen – als Reaktion auf intransparente, vage Jobbeschreibungen. Er betont die Mission, mehr Transparenz in die österreichische Entwicklerlandschaft zu bringen und jedem Entwickler den passenden Job zu ermöglichen. Die TechTalk Days geben österreichischen Dev‑Teams eine Bühne; über 30 Speaker teilen ihr Wissen, und alle Talks sind frei auf devjobs.at und techtalks.at verfügbar, sodass Zuschauer gezielt passende Sessions auswählen können.

Vom Kinderzimmer zur Bühne: Was „Die TechTalk Days“ über Transparenz, Lean-Stacks und Community-Building verraten

Kontext: „Die TechTalk Days“ mit Klemens Schreiber (DEVJobs.at)

In der Session „Die TechTalk Days“ setzt Klemens Schreiber, CTO und Co-Founder von DEVJobs.at, den Ton für ein Format, das Wissen aus österreichischen Dev-Teams sichtbarer und frei zugänglich macht. In seinem kurzen, aber pointierten Auftakt steckt mehr Substanz, als es zunächst scheint: Er umreißt die Problemstellung (intransparente Jobbeschreibungen), skizziert die erste technische Umsetzung (Prototyp mit „ein paar SWL-Komponenten“, einer Express-API und diversen SaaS-Lösungen) und benennt die Mission von DEVJobs.at („mehr Transparenz in die Entwicklerlandschaft in Österreich“). Gleichzeitig öffnet er die Bühne: In der ersten Ausgabe sprechen über 30 Vortragende, deren Inhalte im Anschluss kostenfrei auf devjobs.at sowie techtalks.at abrufbar sind.

„Gestartet habe ich damals mit meinem Mitgründer Markus in unserem ersten Büro, das war im Kinderzimmer von meinem Junior.“

„Das [hat] bestanden aus ein paar SWL-Komponenten, aus einer Express-Api und diversen SaaS-Lösungen. Ein großer Teil von dieser Software ist sogar heute noch online.“

„Die große Mission von DevJobs ist es eigentlich, mehr Transparenz in die Entwicklerlandschaft in Österreich zu bringen.“

Im Folgenden ordnen wir die technischen und produktstrategischen Fäden aus „Die TechTalk Days“ ein: Wo liegt das Problem? Welche Architekturprinzipien lassen sich aus den wenigen, aber klaren Hinweisen ableiten? Und welche konkreten Takeaways können Engineering-Teams daraus mitnehmen?

Problemraum: Intransparente Entwickler-Jobs

Klemens beschreibt eine Erfahrung, die viele Entwickler teilen: Stellenanzeigen, die mit Formeln wie „bahnbrechende Projekte in etablierten Unternehmen“ oder „Cutting-Edge-Technologien in agilen Teams“ arbeiten, ohne Substanz zu liefern. Die Folge: hoher Rechercheaufwand, falsche Erwartungen und Friktion im Bewerbungsprozess.

„… ist man relativ schnell zu Projektbeschreibungen gekommen, in denen gestanden ist, bahnbrechende Projekte in etablierten Unternehmen oder Tech-Stack-Beschreibungen, die einfach nur geheißen haben, Cutting-Edge-Technologien in agilen Teams. … mit so einer Information natürlich nicht recht viel angefangen.“

Warum das wichtig ist

  • Opaque Beschreibungen erzeugen Unsicherheit: Tech-Stack, Teamgröße, Entwicklungsprozesse oder Remote-Regelungen bleiben unklar.
  • Developer Experience beginnt nicht erst im Onboarding, sondern bereits bei der Stellensuche: Transparenz*vor* der Bewerbung spart Zeit auf beiden Seiten.
  • Märkte mit geringer Transparenz verstärken „Matching-Fehler“: Kandidaten landen in Rollen, die nicht zu ihren Erwartungen passen; Unternehmen erhalten Bewerbungen ohne Passung.

Produktziel: Transparenz als Feature

DEVJobs.at adressiert genau diese Lücke: die „große Mission“ ist es, mehr Transparenz in die Entwicklerlandschaft zu bringen und „so jedem Entwickler seinen passenden DevJob finden zu lassen“. Schlüsselaspekte, die sich daraus ableiten lassen, ohne über den Talk hinauszugehen:

  • Fokus auf verständliche, konkrete Informationen statt Floskeln.
  • Entwicklerzentrierter Zugang: Was braucht ein Dev, um eine fundierte Entscheidung zu treffen?
  • Kuratierte Sichtbarkeit: Inhalte so zugänglich machen, dass sie ohne Barrieren rezipierbar sind.

Technischer Start: Prototyp in der Realität – Komponenten, Express-API, SaaS

Klemens erwähnt drei Bausteine des ersten Prototyps: „ein paar SWL-Komponenten“, eine Express-API und „diverse SaaS-Lösungen“. Bemerkenswert ist seine Feststellung, dass „ein großer Teil von dieser Software … heute noch online“ ist. Das deutet auf eine pragmatische, aber tragfähige Architektur hin: schnell lauffähig, iterativ erweiterbar, mit gezieltem Einsatz von SaaS, um nicht-kernkritische Funktionen auszulagern.

Komponenten + Express-API: Ein leichtgewichtiges Rückgrat

  • Komponenten-Ansatz: Ein modulares Frontend erlaubt, UI-Funktionen unabhängig zu iterieren. Der Talk nennt „SWL-Komponenten“ – unabhängig von der genauen Bedeutung lohnt der generische Blick: Einzelne, wiederverwendbare Bausteine ermöglichen eine schnelle Prototypisierung und klare Verantwortungsschnitte.
  • Express-API: Node.js mit Express ist ein klassischer Weg, rasch eine HTTP-API zu liefern – klein, verständlich, leicht zu deployen. Für ein MVP fokussiert das Team auf Essenz statt Overengineering.

Diverse SaaS-Lösungen: Bauen, wo es zählt; kaufen, wo es beschleunigt

  • SaaS entlastet: Authentifizierung, E-Mail-Versand, Zahlungsabwicklung, Monitoring – die Auslagerung verschiebt Time-to-Value nach vorne.
  • Komplexität bleibt kontrollierbar: Standardaufgaben werden über APIs gebunden, eigene Codebasis konzentriert sich auf differenzierende Funktionen (hier: das Entwickler-Jobmatching und Transparenzfeatures).
  • Dauerhafte Tragfähigkeit: Dass ein wesentlicher Teil „heute noch online“ ist, unterstreicht: Früh getroffene Architekturentscheidungen können langlebig sein, wenn Schnittstellen klar und Abhängigkeiten bewusst gewählt sind.

Architekturprinzipien, die sich aus dem Talk ableiten lassen

Die Aussagen im Talk sind knapp, aber sie verweisen auf solide, bewährte Prinzipien für den Aufbau eines produktionsreifen MVPs.

1) Start small, ship fast

  • Ein einfacher Prototyp aus Komponenten, einer schlanken API und SaaS kann rasch Mehrwert liefern.
  • „Ship early“ erzeugt echte Nutzersignale, die das weitere Backlog präzisieren.

2) Entkoppeln durch klare Schnittstellen

  • Komponenten im Frontend, eine konsistente Express-API und externe SaaS-Dienste kommunizieren über klar definierte Verträge.
  • Diese Entkopplung macht Teile der frühen Architektur dauerhaft tragfähig.

3) Transparenz als Systemanforderung denken

  • Wenn Transparenz Produktziel ist, betrifft sie Datenmodell, Oberfläche und Prozess: Was wird wie abgebildet? Wo fehlt Kontext? Welche Felder sind für Entwickler entscheidungsrelevant?

4) Community-First

  • „Die TechTalk Days“ sind nicht nur Event, sondern Infrastruktur für Wissensaustausch. Die Inhalte sind „online, frei und kostenlos zugänglich“ – ein bewusstes Design für Reichweite und Wirkung.

Beispielmuster: Schlanke Express-API als MVP-Basis

Im Talk fallen keine konkreten Codebeispiele. Aus der Nennung einer „Express-Api“ lässt sich jedoch ein generisches Muster ableiten, wie Teams den Kern eines MVP strukturieren können:

// server.js
import express from 'express';
import morgan from 'morgan';
import helmet from 'helmet';

const app = express();
app.use(helmet());
app.use(express.json());
app.use(morgan('tiny'));

// Healthcheck
app.get('/healthz', (req, res) => res.status(200).json({ ok: true }));

// Beispiel: Jobs-Endpoint (Platzhalterstruktur)
app.get('/api/jobs', async (req, res) => {
  // In einem MVP könnte hier eine SaaS-Quelle oder eine DB abgefragt werden
  res.json({ items: [], total: 0 });
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`API listening on :${port}`));

Das Muster illustriert: Sicherheit (Helmet), Logging (Morgan), JSON-Parsing und ein früh erreichbarer Healthcheck. In der Realität binden Teams an dieser Stelle SaaS-Dienste über REST/Webhooks an – ohne das eigentliche Produktziel zu verlieren.

Transparenz als Produktarbeit: Von der Mission zur Umsetzung

„Die große Mission … mehr Transparenz in die Entwicklerlandschaft in Österreich zu bringen und so jedem Entwickler seinen passenden DevJob finden zu lassen.“

Wie überführt man diese Mission in konkrete Produktarbeit, ohne den Talk zu überschreiten? Indem man Transparenz als Querschnittsthema versteht:

Datenmodell

  • Felder definieren, die Entwicklern helfen, eine Entscheidung zu treffen (z. B. Technologieangaben, Onsite/Remote, Gehaltsband, Teamgröße, Deployment-Frequenz – als generische Beispiele für Transparenzfelder).
  • Pflichtfelder vs. optionale Felder: Wo ist Vollständigkeit entscheidend?

Darstellung

  • Prägnante, strukturierte Anzeige statt Marketingfloskeln.
  • Vergleichbarkeit erhöhen: konsistente Labels, klare Gliederung.

Prozesse

  • Redaktions- oder Review-Schritte, um unpräzise Angaben früh zu erkennen.
  • Feedback-Loops von Nutzern, um Lücken im Informationsangebot aufzudecken.

Ohne Annahmen über die konkrete Umsetzung bei DEVJobs.at zu treffen, zeigt der Talk: Transparenz ist für diese Plattform kein „Nice-to-have“, sondern Kern ihrer Daseinsberechtigung.

„Die TechTalk Days“ als Plattform-Strategie

Klemens macht zwei Dinge deutlich: Die Bühne gehört Entwicklerinnen und Entwicklern aus verschiedenen Teams in Österreich; und die Inhalte bleiben als frei zugängliche Wissensquelle bestehen.

„… Entwicklern aus verschiedenen Dev-Teams in Österreich eine Bühne geben, um ihr Wissen zu teilen … online, frei und kostenlos zugänglich …“

„Ich bin sehr stolz darauf, dass wir … bereits mehr als 30 Speaker begeistern konnten … Die Talks stehen nachher auf DevJobs.at sowie auf der Eventseite techtalks.at kostenlos zur Verfügung.“

Wirkung auf das Ökosystem

  • Niedrige Zugangshürden fördern aktiven Wissenstransfer.
  • Sichtbarkeit stärkt die Community und unterstützt das ursprüngliche Ziel: bessere Matches zwischen Entwicklerinnen/Entwicklern und Teams.
  • Langfristig entsteht eine referenzierbare Wissensbasis – die Talks sind über die Eventtage hinaus nutzbar.

Lektionen für Engineering-Teams

Aus dem Talk lassen sich praxisnahe Leitplanken ableiten, die unabhängig vom spezifischen Stack funktionieren.

1) MVP: Scharf stellen, was wirklich zählt

  • Reduzieren Sie den initialen Scope auf das differenzierende Problem (hier: Transparenz für Dev-Jobs).
  • Nutzen Sie SaaS, um Commodity-Funktionen auszulagern.
  • Setzen Sie auf eine kleine, wartbare API (Express ist ein typischer Kandidat für schnelle Ergebnisse).

2) Schnittstellenverträge ernst nehmen

  • Interne Modularität (Komponenten) und externe Integrationen (SaaS) stehen und fallen mit klaren Verträgen.
  • Stabilität im Produktiveinsatz wächst aus wohldefinierten Endpunkten, Fehlermodellen und Auth-Strategien.

3) „Transparenz by Design“ verankern

  • Definieren Sie früh, welche Informationen für Kandidaten entscheidungsrelevant sind.
  • Integrieren Sie Validierungen und Review-Schritte, um Floskeln durch Substanz zu ersetzen.

4) Community als Multiplikator denken

  • Wissen aufzeichnen, zugänglich machen und auffindbar halten.
  • Formate schaffen, in denen Teams Einblicke teilen – so wie bei den „Die TechTalk Days“.

5) Langlebigkeit trotz MVP

  • Saubere Modul- und Integrationsgrenzen erhöhen die Chance, frühe Entscheidungen im Bestand zu halten – ganz im Sinne von „Ein großer Teil … ist heute noch online“.

Beispiel: SaaS-Integration als Beschleuniger

Ein wiederkehrendes Muster in MVP-Setups ist die Integration von SaaS-Diensten für wiederkehrende Aufgaben. Generisch gedacht:

// Beispiel: Webhook-Handler für ein SaaS-Event
app.post('/webhooks/saas', async (req, res) => {
  const signature = req.headers['x-saas-signature'];
  const payload = req.body;

  // 1) Signatur prüfen (Dienst-spezifisch)
  if (!isValidSignature(signature, payload)) {
    return res.status(400).json({ error: 'invalid signature' });
  }

  // 2) Ereignis auswerten und intern verarbeiten
  switch (payload.type) {
    case 'record.updated':
      await upsertRecord(payload.data);
      break;
    default:
      // optional: loggen
      break;
  }

  res.status(200).json({ received: true });
});

Dieses Muster trennt den SaaS-Eventfluss vom Domänenmodell und hält die API-Logik übersichtlich – genau die Art von Architekturdisziplin, die MVPs auch langfristig stabilisiert.

Zitate, die hängen bleiben

  • „Gestartet … im Kinderzimmer von meinem Junior.“ – Ein Reminder: Große Plattformen beginnen oft erstaunlich klein.
  • „… ein paar SWL-Komponenten, … eine Express-Api und diverse SaaS-Lösungen.“ – Lean-Stack mit klarer Fokussierung.
  • „Ein großer Teil … ist sogar heute noch online.“ – Früh getroffen, gut geschnitten.
  • „Die große Mission … mehr Transparenz …“ – Produktkompass, kein Marketing-Spruch.
  • „… online, frei und kostenlos zugänglich.“ – Community-Wert vor Paywall.

Was Ingenieurinnen und Ingenieure jetzt tun können

Auf Basis der Impulse aus „Die TechTalk Days“ lassen sich unmittelbar anwendbare Schritte ableiten:

  • Identifizieren Sie in Ihrem Produkt das eine Kernversprechen (hier: Transparenz) und messen Sie dessen Erfüllung statt Vanity-Metriken.
  • Prüfen Sie, welche Funktionen Sie konsequent an SaaS auslagern können, um das Team auf die differenzierende Domäne zu fokussieren.
  • Schneiden Sie Ihre API und Komponenten so, dass Änderungen lokal bleiben und Schnittstellen stabil sind.
  • Dokumentieren und teilen Sie Wissen – intern und extern. Talks, Demos und frei zugängliche Inhalte steigern die Wirksamkeit Ihrer Arbeit.

Ausblick

„Die TechTalk Days“ stellen Wissen in den Mittelpunkt und verbinden es mit einer klaren Produktmission: Transparenz für Entwicklerinnen und Entwickler in Österreich. Der technische Start von DEVJobs.at – leichtgewichtig und bewusst zusammengesetzt – zeigt, wie ein MVP mit Komponenten, einer Express-API und SaaS-Integrationen schnell Wirkung entfalten und zugleich langlebig sein kann. Die Kombination aus transparenzgetriebener Produktarbeit und frei verfügbarer Wissensplattform ist ein starkes Signal an die Community – und ein praktikabler Kompass für Teams, die heute bauen, was morgen trägt.

Zum Abschluss bleibt die Einladung von Klemens: „Ich freue mich auf spannende Talks und have fun!“

Weitere Tech Talks

Weitere Dev Stories