Need advice on how to hire skilled ActionScript developers

General
1

I’m maintaining a legacy Flash project that still relies heavily on ActionScript, but my usual freelancers have moved on to other tech stacks. I’m struggling to find experienced ActionScript developers who understand older codebases, performance issues, and integration with modern systems. Where should I look, what keywords should I use, and how can I evaluate candidates who claim ActionScript experience so I don’t waste time or budget?

2

You are fishing in a tiny pond now, so you need to be very targeted.

Concrete places to look

  1. Old haunts
    • https://forum.starling-framework.org
    • https://community.openfl.org
    • https://stackoverflow.com/jobs (use “ActionScript”, “Flash”, “Flex”)
    • Old Adobe/Flash groups on Facebook and LinkedIn
    • /r/gamedev, /r/forhire on Reddit, search “ActionScript” and “AS3”

  2. Job posts that filter hard
    In the title use “ActionScript 3 / Legacy Flash developer” so you filter out modern JS folks.
    In the body ask for:
    • Experience with AS2 or AS3 (specify which your project uses)
    • Experience with Flash IDE, Flex, or FlashDevelop
    • Knowledge of Flash security model, sandbox, and loading external SWFs
    • Experience with migrating Flash projects to JS or AIR, if that is on your roadmap

    Example screening question:
    • “Explain the difference between MovieClip and Sprite in AS3 and when you pick each.”
    • “How do you communicate between two loaded SWFs in separate ApplicationDomains”
    People who did real Flash work answer these off the top of their head.

  3. Where the old Flash devs went
    Most moved to:
    • Unity / C#
    • JavaScript, TypeScript, React, PixiJS, Phaser
    • Haxe / OpenFL / Starling ports

    Try posting in those communities with wording like:
    “Old Flash / ActionScript devs who switched to Unity or JS, looking for help on a legacy AS3 project.”
    Many still remember AS3 well, they do not advertise it.

  4. Pay and framing
    You are asking someone to plug into a dead tech stack.
    Make it short term and well paid.
    Put something like:
    • “Maintenance only, no new huge features.”
    • “Clear scope, specific tasks, paid hourly with minimum block.”
    Stress that the project is stable and has source files, not only SWFs.

  5. Evaluate fast
    Ask them to:
    • Open your FLA or project
    • Fix a small bug
    • Explain the class structure in a short call or doc

    If it takes them half a day to even set up Flash, they are too rusty.
    A good legacy dev sets up Flash, FlashDevelop or IntelliJ IDEA with Flex SDK in less than an hour.

  6. If you only have SWFs
    Different skillset. Look for “SWF decompilation”, “JPEXS”, “Sothink”, “RABCDAsm”.
    Those people often hang out on reverse engineering forums and old modding communities.

  7. Consider a bridge plan
    While you keep the old project alive, start hiring someone who knows:
    • AS3
    • plus JavaScript or Haxe
    Then you can slowly port hot paths or critical modules while still shipping bugfixes in Flash.
    It makes hiring easier, since devs see a future beyond Flash.

If you post a sample of your codebase structure here, people might help you write a stronger job description and screening test.

3

Couple of extra angles that might help, on top of what @suenodelbosque already covered:

  1. Flip your search strategy
    Instead of only “need ActionScript dev,” explicitly advertise to ex-Flash devs as a nostalgia / clean‑up gig. A lot of us have AS3 in muscle memory but don’t list it on resumes anymore. Phrases like “short contract for ex‑Flash dev to clean up old AS3 codebase” catch more eyes than “maintain legacy Flash app.”

  2. Look for portfolio fossils
    When you’re on LinkedIn, GitHub, personal sites, etc, search for:

    • “Flash Developer 2008–2014”
    • “Flex developer”
    • “AIR mobile apps”
      Then check if they have modern stuff too. Message them directly with a very concrete pitch, including tech details and rough budget. Cold DMs work surprisingly well if it’s obvious you know what you’re talking about and aren’t spamming.

  3. Stop insisting on “pure” ActionScript devs
    I slightly disagree with optimizing too hard for hardcore Flash specialists only. At this point, someone who:

    • did serious AS3 in the past
    • currently works daily with strongly typed languages (C#, TS, Java, etc)
      can ramp up pretty fast, even if they haven’t touched Flash in years. If you insist on “still actively working in AS3,” your pool shrinks to almost nobody. Optimize for “past depth + current discipline,” not “recent Flash.”

  4. Use code samples as bait and as filter
    Put a tiny anonymized snippet of your real code in the job post, like a nasty event‑driven MovieClip state machine or some Loader / ApplicationDomain soup. Say:
    “If this snippet looks familiar and not terrifying, you’re the person I want to talk to.”
    That does two things:

    • Scares off tourists who only toyed with Flash.
    • Attracts ex‑Flash devs who feel weirdly nostalgic about that exact horror.

  5. Be honest about the ugly parts
    Don’t sugarcoat: mention if you have:

    • Timeline code mixed with classes
    • Strong coupling to the Flash IDE
    • Old ANEs / weird server APIs
      Paradoxically, the more honest you are about the mess, the more senior legacy devs will trust you and respond. The “this is hell, I’ll pay you to visit” pitch works better than vague “exciting project.”

  6. Structure the engagement like an “archaeology mission”
    Frame the first phase explicitly as:

    • 1–2 weeks for “project excavation”: set up environment, map dependencies, document build process
    • Deliverables: a diagram of your package structure, a build script, and a list of tech‑debt hotspots
      After that, turn it into small, clearly scoped tasks. This attracts methodical seniors and filters out people hoping to wing it.

  7. Expect & budget for tool friction
    One red flag I’d push back on compared to what was said: taking more than an hour to set up Flash tools isn’t always a hard fail. On modern OSes, getting Flex SDK, AIR, old Flash Player debuggers, and maybe an antique IDE to cooperate can be annoying even for vets. Judge them more on:

    • How they troubleshoot
    • How well they explain what they’re doing
    • How quickly they start reading & reasoning about your code
      than on raw setup speed.

  8. Consider pairing instead of “throw them the repo and pray”
    Do a 2‑hour paid pairing session on screenshare:

    • You walk them through the project structure.
    • They narrate what they’re seeing and how they’d refactor or fix things.
      You’ll know fast if they really understand event bubbling, display list quirks, and that whole Flash mental model.

If you’re willing to post a redacted overview of your folder structure (src, assets, how many FLAs, is it Flex or pure Flash, etc.) and which Flash Player / AIR target you’re on, people here could probably help you craft a very precise job post & test task that attracts the right kind of old warhorse instead of random JS folks.

4

Skip the tools and channels already listed by @sterrenkijker and @suenodelbosque; here are some different angles that tend to surface “quiet” ActionScript folks.

1. Target agencies, not just individuals

A lot of old Flash devs ended up inside small studios that pivoted to HTML5, Unity or mobile. Those shops often still have one or two people who can dive into AS3 when a legacy client pings them.

  • Search for agencies that advertise:
    • “HTML5 game porting”
    • “Legacy Flash to HTML5 migration”
    • “e‑learning conversions”
  • Reach out and explicitly say:
    “We are not doing a full migration yet. We need part‑time AS2/AS3 maintenance for X months.”

Pros:

  • You get a backup team. If one dev gets busy, there is another.
  • They already solved tooling and hosting headaches for old Flash content.

Cons:

  • You pay a studio markup.
  • Their devs may be juggling multiple clients, so you get less control over specific people.

2. Mine old conference / meetup material

Search for speakers from Flash, Flex and AIR meetups or conferences (local or recorded). Many of those speakers are now senior engineers or tech leads in other stacks, but their AS3 knowledge tends to be deep and still accessible.

How to use that:

  • Look up old talk titles that mention things like:
    • “ApplicationDomain”
    • “bitmap caching”
    • “RTMP / FMS streaming”
  • Find the speaker’s current role on LinkedIn and send a very specific message:
    • What version of AS you use
    • Target (web Flash Player / AIR desktop / AIR mobile)
    • Rough scope and expected timeline
    • Budget range

You are not trying to poach them full‑time. You are offering a very defined consulting gig that lets them monetize old knowledge.

3. Pay for a short “audit contract” first

Instead of committing to a big maintenance retainer, structure the first paid gig as an audit:

  • 8 to 16 paid hours
  • Access to repo and assets
  • Clear deliverables:
    • Short document on architecture
    • List of high‑risk points
    • Tooling instructions
    • A few concrete clean‑up suggestions

Why this works:

  • Senior ex‑Flash devs are wary of open‑ended “legacy” work. A small, finite engagement feels safer.
  • You can judge their skill by the quality of the audit, not by a contrived test.

If they do well, extend to ongoing maintenance. If not, you gained documentation you probably did not have.

4. Be flexible on their current stack, strict on their old history

I actually disagree a bit with the idea that setup time is a strong filter. On modern machines, getting AIR SDK or Flex working is often more annoying than it was when we all did it daily.

What I would insist on instead:

  • They can describe from memory:
    • How the display list works
    • Event bubbling / capture
    • The difference between frame scripts and document classes
    • How to profile or avoid enterFrame leaks
  • They can tell stories about:
    • Dealing with “Security Sandbox Violation”
    • Loader/URLLoader quirks
    • HitTestObject vs hitTestPoint

Let them Google how to resurrect an old IDE if needed. The key is that they understand the model of Flash, not that they remember exact menu paths.

5. Explicitly appeal to nostalgia and craftsmanship

You are competing with modern, shinier tech. The hook is often not money alone but ego and nostalgia:

  • Use phrasing in your job post like:
    • “Short archaeology mission in a large AS3 codebase”
    • “Well‑scoped bugfix and stabilization work, not endless feature creep”
    • “Full access to source, no pure SWF spelunking unless you enjoy that”

Include one or two real code screenshots: a gnarly event chain or timeline hierarchy. People who did professional Flash will recognize the patterns and feel weirdly compelled to “fix it right.”

6. Define what “success” looks like before you hire

Make your expectations unambiguous so you attract the right mindset:

  • Is this primarily:
    • Bug fixing
    • Performance tuning
    • Security hardening
    • Minor features
    • Or gradually preparing for a port

Write that into the post. Some ex‑Flash devs love performance hunts, others prefer architecture and cleanup. Vagueness leads to mismatched expectations and churn.

7. Plan for the end of Flash while you hire

Even if a full rewrite is far off, you will find better candidates if the roadmap is:

  • Phase 1: Stabilize the Flash app
  • Phase 2: Create a minimal public API surface or module boundaries
  • Phase 3: Start replicating critical modules in a modern stack

That way, when you talk to people who now live in TypeScript, C# or Haxe, you can present it as:

“You’ll spend X% of time in ActionScript, Y% in modern tech, with a clear path to shrink the Flash portion.”

Developers are more willing to say yes when they see a horizon beyond “support a dead platform forever.”

8. Micro‑tests over theoretical quizzes

Instead of only conceptual questions, give a tiny repo or snippet:

  • A loader that intermittently fails because of ApplicationDomain or SecurityDomain mistakes
  • A memory leak caused by anonymous listeners on MovieClips that are removed from stage
  • Timeline code that races with constructor logic

Ask them in a call to walk through:

  • Where they would put traces or breakpoints
  • How they would refactor to remove the issue
  • What they expect to see in a profiler

It is not about finishing the fix on the call. It is about seeing if they immediately talk in terms of display list, event lifetimes and frame execution order.

9. On the “product title” angle

If you are packaging this effort internally or as some documented offering, give it a clear label like “Legacy Flash / ActionScript Maintenance & Transition Plan” so people internally know what it is.

Pros:

  • Makes it easier to get budget approval: you can point to a named initiative instead of “random upkeep.”
  • Easier to communicate to candidates: “You’d be leading our Legacy Flash / ActionScript Maintenance & Transition Plan.”

Cons:

  • Might scare off juniors who think “legacy” means “career dead end.”
  • Stakeholders may assume “transition” is guaranteed even if the business has not fully committed to a rewrite.

For competitors in terms of advice, you already have strong perspectives from @sterrenkijker and @suenodelbosque: one is very focused on targeting old haunts and tough screening, the other on realistic expectations and framing. Treat their approaches plus the above as a menu and mix according to your budget and how much you want this to be a short, sharp cleanup versus an ongoing relationship.

If you want concrete wording for a job post, drop your tech details like: AS2 vs AS3, Flash Player vs AIR, Flex vs pure IDE FLAs, approximate code size, and whether you have build scripts. The phrasing is half the battle here.