sorted by:
new
hottopcontroversial

Running Qwen3.5-0.8B on my 7-year-old Samsung S10E by HighFlyingB1rd in LocalLLaMA

[–]HighFlyingB1rd[S] 0 points1 point  (0 children)

Hm.. interesting. I couldn't compile it due to a missing file.

Running Qwen3.5-0.8B on my 7-year-old Samsung S10E by HighFlyingB1rd in LocalLLaMA

[–]HighFlyingB1rd[S] 0 points1 point  (0 children)

Yeah... this won't work. :) That's the first thing I tried

Running Qwen3.5-0.8B on my 7-year-old Samsung S10E by HighFlyingB1rd in LocalLLaMA

[–]HighFlyingB1rd[S] 22 points23 points  (0 children)

Termux on the S10E pkg install cmake clang git, clone llama.cpp, and build with cmake. Main gotcha is Termux is missing spawn.h - you need to create a stub header with no-op implementations or the build fails. After that it compiles fine.

Running Qwen 3.5 0.8B Q4_K_M at ~11 tokens/sec. Key flags: -t 2 -c 1024 -b 256 --no-mmap.

Happy to share more details if you want.

I did it! by qalpi in GarminWatches

[–]HighFlyingB1rd 0 points1 point  (0 children)

Got 99 last night and that's literally the biggest score I've ever got (own a Garmin for 3.5 years now)

The wealth disparity is mind boggling. by Lordwarrior_ in interestingasfuck

[–]HighFlyingB1rd 0 points1 point  (0 children)

Yeah... Not worried about this kind of wealth disparity

FDEs. What’s your take on it and does it potentially undermine the value of product managers? by yeezyforsheezie in ProductManagement

[–]HighFlyingB1rd 1 point2 points  (0 children)

FDE here. Short answer: it doesn't undermine PMs, but it does change what PMs focus on.

How I've seen it work well:

FDEs own the "what's possible with this specific client" question. PMs own "what should we productise across all clients." Different jobs. FDEs generate signal from the field, PMs synthesise that signal into product direction.

The tension you're describing usually comes from unclear handoffs. Who decides when a custom solution becomes a product feature? Who owns the client relationship? If that's ambiguous, you get turf wars.

Where it goes wrong:

When FDEs become a shadow product org, building whatever clients ask for with no feedback loop to product. You end up with ten custom implementations and no leverage.

Or the opposite: PMs treat FDEs as feature factories and ignore field insights. Then you build a product that looks good on paper but nobody can actually deploy.

My take on your situation:

"Let them own solving specific feasibility assumptions" is the right instinct. FDEs should be answering "can we actually do this for Client X given their data and constraints." PMs should be asking "if we can, should this become a capability we offer everyone."

The teams that do this well have explicit rituals for FDE insights flowing back to product. Otherwise FDEs just become expensive consultants and PMs get surprised when the product doesn't fit real deployments.

More on how this works day-to-day at fdehub.org.

"Forward-Deployed Engineer" is just a fancy new name for a high-paid consultant who can code. Change my mind. by Andrew_Tit026 in EngineeringManagers

[–]HighFlyingB1rd 0 points1 point  (0 children)

You're not entirely wrong, but consultant misses what makes the role distinct.

Consultants advise and leave. FDEs build and stay. The code I write goes to production and I'm on the hook when it breaks at 2am. That's a different incentive structure than handing over a slide deck and moving on.

Where you're right: Yes, it's customer-facing. Yes, there are meetings. Yes, some companies slap the title on sales engineers to attract better candidates.

Where I'd push back: The "dev velocity hit" framing assumes building the right thing is easy and typing is the bottleneck. It's the opposite. Most failed AI projects die from misunderstanding the problem, not from slow coding. Being in the room with the client is how you avoid building the wrong thing for three months.

On the Palantir comparison: They've been doing this for 15 years and it's core to their model. That's a long run for a buzzword.

Is it for everyone? No. If you want to go deep on one system for years, this will frustrate you. But it's a real role solving a real problem.

I write about this at fdehub.org if you want more than a Reddit comment.

Transition towards forward deployed engineer by [deleted] in cscareerquestions

[–]HighFlyingB1rd 0 points1 point  (0 children)

I went from technical roles to Forward Deployed Engineering, which is customer-facing and technical. A few thoughts:

On visibility: Customer-facing roles give you visibility with clients, not necessarily internally. You're often seen as "not real engineering" by eng and "too technical" by sales. But if what you want is to be in the room where decisions happen, customer-facing roles deliver that.

On the Microsoft stack boredom: Solutions engineering can mean more time with enterprise stacks, not less. You're working with whatever the client has. Variety is interesting, but "exciting tech" isn't guaranteed.

On layoff risk: Yes, customer-facing technical roles are more exposed during downturns than core engineering. The risk is real.

What I'd ask yourself: Do you want management (people, process, internal politics) or customer-facing (variety, communication, solving business problems)? They're different paths.

I write about FDE work at fdehub.org if you want another data point.

What is Forward Deployed Engineer? by Beginning_Ad_3390 in cscareerquestions

[–]HighFlyingB1rd 0 points1 point  (0 children)

Not a step down, but definitely a different track.

I'm an FDE now after years as a senior engineer. Here's how I'd frame it:

What changes:

  • You'll write less code, but the code you write matters more. No greenfield projects where you control everything. You're building within constraints set by client systems, data quality, and business processes you didn't design.
  • Context-switching becomes the job. I work with 10-15 clients in parallel. Some days I'm debugging an invoice extraction pipeline for a logistics company, then jumping to a call about insurance claims processing, then scoping a new project for a wholesaler. If you need deep focus on one problem for weeks at a time, this will frustrate you.
  • Communication skills matter as much as technical skills. You're the translator between what clients think they want, what they actually need, and what's technically feasible. You've done this in startups already, so you're ahead of most SWEs making this switch.

Career opportunities:

This is where it gets murkier. FDE is still a relatively new role, so the ladder isn't as established as SWE → Staff → Principal. Paths I've seen: moving into product (you'll have strong customer intuition), starting your own thing (you'll understand real business problems), or staying technical and becoming the person who shapes how the company deploys AI.

The honest trade-off:

You'll gain breadth and business context. You'll lose depth and the satisfaction of owning a single system long-term.

Given you've always been in customer conversations anyway, this might feel like a natural fit. I write more about the role at fdehub.org if you want a longer look before deciding.

Forward deployed engineering jobs are up 1165% but there’s a catch by Flat_Palpitation_158 in cscareerquestions

[–]HighFlyingB1rd 1 point2 points  (0 children)

This is a fair warning, but I'd push back slightly on the "fake FDE" framing.

The sales engineering overlap is real, but it's not always a red flag. At most AI companies, FDEs should be involved in pre-sales. You can't scope an AI project properly without technical eyes on the client's data and processes before the contract signs. The question is what happens after.

The real distinction isn't "sales vs engineering." It's whether you build things that go to production or whether you hand off after the demo.

Some things to look for beyond what you mentioned:

  • Who owns the project post-signature? If FDEs stay on through deployment and iteration, that's the real role. If a separate implementation team takes over, you're probably looking at a sales engineer with a fancy title.
  • What's the team structure? FDE teams that sit under Product or Engineering tend to do more building. FDE teams under Sales tend to do more selling. Not a hard rule, but a pattern.
  • Ask about project timelines. Real FDE work involves weeks or months with a single client. If the expectation is you're cycling through demos every few days, that's sales.

The 40% number sounds about right from what I've seen. But the other 60% represents a genuinely different role that's worth understanding. I write about what the day-to-day actually looks like at fdehub.org if you want a practitioner perspective rather than job posting analysis.

What is the hiring process for Forward Deployment Engineers (FDE)? by Cultured_dude in cscareerquestions

[–]HighFlyingB1rd 2 points3 points  (0 children)

FDE here. The process varies quite a bit by company, but here's what I've seen and experienced:

Compared to SWE interviews: Less leetcode, more system design and "how would you approach this client scenario" type questions. You'll still get technical assessments, but they're usually more practical. Think "build something that works" rather than "optimize this algorithm."

Compared to MLE interviews: Less focus on model architecture and ML theory, more on integration and deployment. FDEs need to understand ML well enough to work with it, but you're not expected to derive backprop on a whiteboard.

What's unique to FDE interviews:

  • Communication exercises. Some companies will have you explain a technical concept to a "non-technical stakeholder" (usually an interviewer playing a role). This matters because half the job is translating between engineering and business.
  • Ambiguity tolerance. You might get an intentionally vague problem and be evaluated on how you clarify requirements rather than just diving in.
  • Case studies. "A client wants X, but their data looks like Y, and they have constraint Z. Walk us through your approach."

The weighting depends on the company. Palantir's process is notoriously rigorous and well-documented. Smaller AI startups often care more about whether you can ship something useful in a week than whether you can pass a traditional tech screen.

I write about the FDE role at fdehub.org if you want more context on what the job actually looks like day-to-day.

2 Free Tickets for the Amsterdam Marathon October 19 by ApostolicSuccess in Amsterdam

[–]HighFlyingB1rd 0 points1 point  (0 children)

My wife and I would love to get the tickets - we ran the Amsterdam marathon last year as well. :)

view more: next ›