Hands-on Meets Big Picture: Inside SQUER’s Engineering Culture and Hiring – Insights from “David Leitner, Co-Founder von SQUER”

Context: SQUER in one line – pragmatic, curious, and relentlessly problem-oriented

In the session “David Leitner, Co-Founder von SQUER” with Speaker David Leitner (SQUER), we at DevJobs.at heard a crisp account of a company that started in Vienna four years ago, now counting around 50 people, and has kept a strikingly consistent core: SQUER combines deep hands-on engineering with strong conceptual thinking. That pairing sits at the center of their mission and explains why the team can frame a legacy replacement to a CEO and then sit down with developers to build the solution.

Leitner’s point of view is clear: software isn’t an end in itself; it’s a means to an end. Technical excellence is loved and pursued, but always in service of solving a concrete problem. This ethos runs through everything—how SQUER hires, how they approach projects, and how they prepare for new technology waves, including generative AI.

The defining profile: the “Elevator Architect” and a true problem-solver mindset

Leitner invokes what he calls “a bit of what George Hope refers to as an ‘Elevator-Architekt’”: the ability to make a crisp, C-level case for decisions (e.g., replacing a legacy system) and then go hands-on to implement it alongside the engineering team.

That dual capability isn’t a nice-to-have at SQUER—it’s their market differentiator. The expectation is explicit: understand context, keep the big picture, translate decisions into code, and co-own the outcome. It’s engineering leadership in the best sense, regardless of title or hierarchy.

Software as a means to an end—without compromising excellence

Leitner puts it plainly: “Software is not an end in itself, but a means to an end.” That’s not an argument against technical sophistication—quite the opposite. SQUER “loves to engage with new technologies.” The line is clear, though: no solution excels without understanding the problem. This guards against tool fetishism and architecture decisions detached from domain reality.

Hands-on excellence plus conceptual strength

The role SQUER expects from its engineers is hybrid: articulate the “why” at executive level, then turn it into a robust solution delivered with the team. In complex, historically grown environments, that’s the competence that earns trust—because it keeps the conversation anchored in outcomes rather than technology for its own sake.

Community-first: How SQUER meets talent—and why their recruiting feels different

SQUER’s recruiting starts long before any formal interview. Many candidates discover the company through its community work: meetups, conferences, and open knowledge sharing. That has two effects: first, talent gets an early feel for how SQUER thinks; second, interest forms around substance, not slogans.

This openness is a promise: if you join, you join a learning and sharing culture. It attracts people who value arguments over hype and who take “means to an end” seriously.

A three-step tryout: interviews as a two-way street

SQUER deliberately designs hiring to be mutual rather than adversarial. Leitner outlines three steps:

1) A 15-minute initial get-to-know-you conversation to set expectations and build rapport.

2) About one hour with two engineers from the team for a deeper technical and cultural exchange.

3) A half-day on site to meet the team in action—without artificial stress and without a “classic” coding-test vibe.

This approach underscores that fit is mutual. It must work for SQUER—and equally for the candidate. The goal is for people to feel: “This is a team I’d enjoy spending my time with day to day.”

What SQUER looks for in candidates

SQUER operates in consulting and professional services—variety in topics, people, and technologies is the norm. They look for people who treat technology as a toolbox, not an identity. As Leitner puts it:

This polyglot mindset is critical because SQUER builds solutions where the problems actually are—inside existing stacks and within real constraints.

Consulting DNA: Solve where the problem lives—no “rewrite by default”

SQUER has a go-to stack, but dogma isn’t the point. In client environments, pragmatism wins. Leitner makes it precise:

That line captures a consulting doctrine with four pillars:

• Respect for the existing system: not every pain is an argument for migration. Often, the right diagnosis beats a tool switch.
• Context before code: better architecture decisions come from domain understanding—saving time, budget, and trust.
• Polyglot delivery: engineers are comfortable in multiple languages and frameworks and switch when the task requires it.
• Ownership for outcomes: solving means delivering—within the client’s stack and constraints.

Product vs. consulting: where the appeal lies

Leitner sketches two career paths: the product path (making the same product better, day by day) and the consulting path (many topics, many technologies). SQUER covers the latter—with the “beautiful advantage” of seeing a lot and learning fast. The challenge is obvious: not everyone enjoys frequent change; SQUER explicitly looks for those who do.

For talent that values variety, context switching, and continuous learning, that’s a compelling environment. It trains the “Elevator Architect” capability and deepens craftsmanship at the same time—a rare combination.

Engineering culture: big picture first, then go deep

The delivery philosophy that emerges from Leitner’s remarks is straightforward:

• Sharpen the problem statement: “If we don’t understand the problem, we won’t solve it well.”
• Hold the big picture: break concepts down, identify the relevant levers, align with stakeholders (up to C-level).
• Stay hands-on: build the solution with the dev team—don’t just advise; co-own delivery.
• Use technologies as means: be excited about new tools—but in proportion to client value.

This builds trust, avoids tech churn, and prevents “solution in search of a problem” dynamics—turning consulting into shared delivery.

Learning as a system: community, variety, and real-world constraints

SQUER’s learning culture stands on three legs:

• Public knowledge work: meetups, conferences, and sharing internal knowledge externally. It trains argumentation and invites peer feedback.
• Project variety: different domains, teams, and stacks accelerate learning—without contrived exercises.
• Constraints as a catalyst: instead of “greenfield at all costs,” people learn to make good decisions under real constraints.

This last point is formative: engineers who can produce sound architecture within constraints become leadership-ready faster, because decision-making under uncertainty is a core competence.

Generative AI: baseline literacy, tool fluency, and use-case clarity

Leitner positions generative AI as disruptive—and as a tool engineers must be able to use. No need to train neural nets in-house; what matters is using the tools well and spotting use cases inside companies where they make sense.

For SQUER, that translates into a practical learning mandate: baseline literacy in AI, focus on applicability, and a keen eye for the problem/solution fit. That aligns with their means-to-an-end ethos and their consulting DNA of solving problems where they live.

The future of the craft: the developer as indispensable problem solver

Leitner repeatedly emphasizes the developer’s role as a problem solver. AI will provide powerful tools, but the competence to understand a problem, decompose it conceptually, and produce a viable solution remains central. The act of writing code may change—“maybe not Java code in the future but some higher-level domain language”—yet the core remains human.

He adds a grounding observation: “There will always be a low-level approach, because programming code is the lowest or most specific form of specification.” No matter how abstractions evolve, there will be a bridge between intent and precise execution—and ample room for engineering excellence.

Why SQUER is appealing to tech talent

From the session, a clear value proposition emerges for engineers—particularly those who prioritize impact over tool dogma:

• Hands-on plus big picture: responsibility from executive-level argument through to implementation.
• Community orientation: active meetups and conferences; sharing knowledge as a habit.
• Human-centered hiring: a three-step, two-way process without artificial stress; attitude and team fit matter.
• Polyglot pragmatism: work across stacks; solve problems where they are (no “rewrite by default”).
• Consulting variety: many topics, many technologies, many teams—learning at speed.
• Problem focus: software as a means to an end; no over-engineering.
• Future readiness: generative-AI tool fluency and use-case sensibility over hype.
• Career durability: developers remain indispensable as problem solvers—even at higher levels of abstraction.

For talent not wedded to a single language (“Java, .NET, JavaScript, Go—bring it on”), interested in learning (“from Angular to React—why not?”), and driven by real impact, this is an environment that supports both breadth and depth of growth.

How SQUER builds trust in delivery

Whether parachuting into troubled projects or starting new initiatives, the practices outlined create reliable momentum:

• Expectation management: “Elevator Architect” communication to CEO/CTO aligns priorities around value.
• Collaborative build: engineers work “with the developers” on the ground—no hard wall between consulting and delivery.
• Context integrity: decisions follow the problem, not the favorite stack.
• Openness: the same impulse to share knowledge publicly applies internally—people learn with and from client teams.

These are not flashy moves—and that’s exactly why they work. They make progress legible, reduce friction, and increase the odds that technical decisions hold over time.

Growth with principles: four years, ~50 people—and clear edges

SQUER’s growth to about 50 people in four years fits the narrative: clear principles, consistently practiced, attract the right talent. The recruiting process reinforces this—through genuine encounters rather than pressure tests. And the consulting orientation ensures that people with a hunger to learn aren’t slowed down but instead develop faster through exposure to varied contexts.

Growth for growth’s sake does not feature in this session. The question that does: “What problem are we solving, and how do we know the solution works?” That question threads through hiring, delivery, tech decisions, and readiness for new waves like generative AI.

What we learned from “David Leitner, Co-Founder von SQUER”

• SQUER defines engineering as the combination of conceptual clarity and hands-on execution.
• Recruiting is community-driven and dialog-focused—with mutual fit and learning attitude at its core.
• Technology choices follow the problem. Rewrites are not a default move.
• Generative AI matters when used as a tool with clear use cases.
• Developers remain indispensable—as people who understand problems, decompose them, and build robust solutions.

SQUER shows how consulting, engineering culture, and employer value proposition can form a coherent whole: people who stay curious, take ownership, and love to learn will find a place where they can hold the big picture while going deep—exactly where it counts.

• 

  

  Architecting for Scale

  David Leitner von SQUER spricht in seinem TechTalk über die auftretenden Challenges – technologisch und organisatorisch – wenn ein System skaliert und wie damit umgegangen werden kann.

  Watch now
• 

  

  Domain Driven Kitchen Madness

  Maurizio Rinder von SQUER überlegt in seinem devjobs.at TechTalk wie man ein hervorragendes italienisches Mahl organisiert und warum die selben Überlegungen auch gut für die Software Entwicklung sind.

  Watch now

• 

  

  Julia Toifl, Senior Full Stack Engineer bei SQUER

  Julia Toifl von SQUER spricht in ihrem Interview über ihren unerwarteten Einstieg in die IT als Physikerin, was die aktuelle Arbeit im Full Stack Engineering umfasst und gibt Tipps für Neueinsteiger.

  Watch now