Hmm.... I apply every 6 months or so and get the thumbs down. Not sure what they're looking for. I've got 30 years of every kind of experience (dev, DBA, network, security, product mgmt, analytics/data science, business mgmt, and more) with good credentials and they never bite. I wish I knew more what the ideal profile was; I'd love to help out!
I can provide a little general insight on this. Here are some things that might lead one to get rejected from USDS Engineering without an interview:
- You're too junior (not your case, I understand.)
- It is not clear that you've actually written software recently as a professional. (While we're looking for senior people and do have management needs, over time we've struggled with hiring managers -vs- growing them because government is such a radically different environment that success managing in the private sector is a poor indicator. So engineering managers are evaluated primarily as engineers first, managers after they pass)
- Your skills seem too specialized in areas we do not have needs. (Much of government technology is super old and much of what is wrong with it is technical debt and decay, not cutting edge technical challenges. For that reason we prefer generalists. Again this doesn't sound like your case)
- Not enough web development work (There is an on-going debate about this, but realistically citizen facing services tend to mean websites and the infrastructure that supports them. In the past we have hired engineers who were unable to adjust to web development and we couldn't find them enough work to play to their strengths. So while we're open to software engineers from other disciplines, there's still a lot of inconsistency in how the engineers judging your resume weigh this issue. Our attempts to correct this are ongoing.)
- You've applied as an engineer and emphasized non-engineering accomplishments (Since we're a civic tech organization sometimes people curate their resumes to play up their social good activities instead of their engineering. This is without a doubt the wrong move. If our engineers don't think you can write code they will not clear you for a technical interview.)
- You've applied for the wrong role or it's not clear what role you would fit into (This seems like it might your case. USDS has three types of roles [well five, but two are not really relevant here]: Engineering, Design (which includes visual, UX research, and content strategy), and Strategy/Operations (which includes both our front office administration and people who are coming in with significant government/policy/legal/product management experience. While we definitely have people who straddle lines [PMs with engineering backgrounds, designers who can program, etc] all those people still applied and were evaluated for one specific community.)
I wonder if the environment of experience is significant? USDS positions itself like a startup (even their page has a section on "dress code" which mentions being like "any other startup"). Someone whose experience is primarily enterprise or BigCo might be less appealing. It would be interesting to see a roster of current USDS FTEs and their backgrounds (I didn't see a "Who's Who" on their page, but didn't look extensively).
I think that startup mentality might bite them in the arse.
I saw "React on Ruby" and winced.
There is nothing wrong with that platform as a "We are in a market where things will change radically in two years" but for the VA? Where things might change once a decade, that's a recipe for pain.
Look at where the Web was 5 years ago (hell React didn't exist) never mind 10.
Angular is 7 years old, KnockoutJS is 7, jQuery is the grandaddy at 11, React is 4.
Not a criticism (they are clearly doing important impactful work) more a concern.
If someone said to me "You will have to support this for at least 10 years" the choices I made would be extremely conservative.
To me, this looks like the bigger potential problem:
>U.S. Digital Service members join us for what we call a tour of duty. We are seeking candidates interested in joining the U.S. Digital Service fulltime, ideally for at least 12 months. In some cases, we can accommodate candidates who can only commit to a shorter amount of time. Three months is the minimum time commitment we can accommodate. All members of the U.S. Digital Service hold "term-limited" positions, which means that at the end of a prescribed term, the candidate's employment with that agency must end.
You have to move to DC -- without relocation assistance -- knowing that you're only going to work for USDS with an expiration date? Seems like that'd really shrink the net of candidates to me. I know it kind of kills my interest, personally.
Yeah, this is hard. I worked from home for five years before joining USDS, and I wish we could support remote work, but we're grafted onto agency projects that are so often based in D.C. that it's just not possible.
The "term-limited" positions are actually quite nice. Generally, you can serve for up to four years. USDS is almost 3 years old, and anecdotally it feels like people tend to leave by the end of their first two-year term because, well, it's hard and it can be exhausting. You lose effectiveness over time, and returning to the private sector is important to re-strengthen your skills and knowledge.
As it happens, the excellent career civil servants we work with also appreciate knowing we're there to help them, not take their jobs. :-)
What also concerns me about that is maintenance. You're constantly bringing in new people to build new things who have no knowledge of what people in previous "tours" built. The overheard of all the handoffs and knowledge transfers that needs to happen seems unfortunately high.
While the USDS does build things, the model is to have them partner with career civil servants and contractors and get them to implement industry best practices. So there is still overhead when handing off between tours, but the bigger problem is finding capable contractors and vested partners at the agency's who can champion the new way of doing things.
Our team is very careful at choosing technology that is stable and well proven. In fact, it took a lot of debate for us to move from Rails static pages to React SPA.
As for government being slow and only change once a decade, you might be underestimating engineers in the government.
The team I worked with managed to pull off React/Node.js/Redis/Zookeeper microservice framework over AWS using Jenkins as CI/CD pipeline. And most of the team came from an older enterprise stack using Java and IBM WebSphere. They were able to adapt to the new framework.
Be conservative, yes. But being overly conservative is part of the reasons why government is so far behind today.
Interesting, when I said once a decade I didn't particulary mean changing anything I meant that the system as a whole has to last a decade.
I've stuff in production I wrote in 2007, it's the same system but lots of the parts have been replaced (bit of a Theseus/Triggers Broom philosophical point) over time.
I agree on the overly conservative point, what I find helps there is to consider the migration away from anything new you are considering, I usually ask myself the following question - "If the entire dev team for foobar disappeared tomorrow, how much would it hurt" if the answer is "not much because I can maintain it myself while migrating away" then thats very different to "a lot because I don't understand it that well and/or it's massively complex".
Enterprise is a different world (even for a medium sized one like I work for) because (frankly) a lot of the programmers are doing it purely for the money and/or simply aren't that competent.
Not all of them by any means but I run into a lot of code that is just plain horrible, not "not the way I'd have done it" so much as "how does this thing even work?" and "Who possibly thought this was the right approach?".
I'm weird, I like LoB software development - I find that done well the feedback loop is very gratifying, you get to have an immediate affect on the companies bottom line and you have happier employees also the problems have a lot of hidden complexity which is intellectually stimulating.
I think that much of the reason for the existence of USDS is that government agencies like the VA should not be stuck with 10-year-old [1] technology. The idea is that U.S. citizens should be able to expect the same level of technology from their government that they get from Facebook, Twitter, Apple, or Google. They're explicitly trying to change the culture where you do things once for hundreds of millions of dollars and then it's never revisited because the first time was such a clusterfuck.
[1] Actually more like 50 year old technology, if my friends at the USDS are to be believed. In some cases, they're replacing systems where SOP is to manually type in data, print it out, fax it over to another department, and then type it in again to a different system.
Those kinds of inefficiencies are /everywhere/ in government. They tend to mirror the limited ways departments communicate (see: Conway's Law). Having structured data available isn't a given, nor is the ability to send it across networks that often predate the internet.
I remember an incident where a critical feature went down for days because a backhoe severed the only available link between two agencies. It's hard to overstate how unusual it is by government standards to operate the way modern startups do-- e.g., put everything in the cloud and let Amazon handle your availability problems.
There's nothing that would prohibit maintaining a Backbone or Knockout app (or just one written with a bunch of non-spaghetti-code jQuery) today, and it's hard to say that any other choice for writing a piece of software with a GUI would have fared better. Why do you think that using React will have a worse result than that?
I think that of the kinds of tools people are using to make web applications in 2017, React and Rails are probably in the more conservative, most likely to be maintainable in 10 years category. (I wouldn't believe this about Rails except it's been so popular for the past 10 years.)
> There's nothing that would prohibit maintaining a Backbone or Knockout app (or just one written with a bunch of non-spaghetti-code jQuery) today
Well that kind of depends, I still have stuff in production with knockout and for some stuff I still use it but it's not just a matter of the framework/library it's the ancillary tooling.
We went through grunt, gulp, browserify and webpack fairly quickly, we could have stayed with any of them but no-one else did, if you stand still you end up been left miles behind when you eventually do want to move on.
The dozens of different bits approach has a lot of advantages but it has some severe downsides as well.
Modern JS is a bit of a red queen problem, you have to constantly adapt your codebases just to stay even on a 5-10 basis.
It's a problem in my world (enterprise LoB stuff in the browser), you want to be somewhat conservative while still be able to have some assurance of long term viability and some of the nice toys.
My approach has been to trade off dependencies as much as possible, I moved to TypeScript for a lot of stuff since it emits good JS so if it ever did go away I could just output the most recent JS and base from that (and I doubt TypeScript is going away in the next few years, MS has invested heavily in it as a platform for internal stuff).
Meanwhile over on the other side of things I recently ran something that was written in 'pure' Java 1.2 on the modern VM with not as many issues as you'd think (that platform is 20 years old).
I recently inherited a large enterprise system that is classic jQuery/no framework, it 'works' on a modern browser but it's an unholy unstructured mess and getting any kind of iteration velocity on it is a complete pain and that was written in over a few years finishing two years ago.
The developers just hadn't adapted to the modern landscape well at all and their momentum was terrible and getting worse.
Hey, I'm the current director of engineering, so I'll toss in my 2 cents because I want to make sure this is really, really clear.
I could not care less about what which company/non-profit/agency/whatever you worked for. I just care about what you have stepped up and done in that environment. We will gladly consider a BigCo person, as long as they can demonstrate how they managed to get awesome stuff done at BigCo (e.g. ported a legacy system to a modern stack) because that is relevant to what we do. We have also passed on folks from FancyStartup.com because they show signs that they would struggle in an environment this complex.
Fundamentally, who we look for are people who can go into just about any situation and figure out a reasonable way to deal with it so that we can get services working for the people who need them. And we look for this in our designers, engineers, talent team, procurement specialists, and product and strat ops folks. See mbellotti's comment for great info on some engineering-specific tips.
The Federal government is a giant bureaucracy. I would actually love to see more BigCo applicants with experience succeeding in tough environments because that's what we do here. We need a good balance of people who know how to deal with things the way they are and people who know how to build things the way they should be. The best candidates are folks who can do both. We make the best decisions we can based on resumes and interviews, and it sucks when we may miss out on a super swell person. But it's bound to happen sometimes.
To be clear: I don't care how old you are, what company you worked for, what part of the country you're from, what school you went to (or if you didn't go to school at all), or any other artificial criteria. In fact, I'm really not interested in hiring the same profile over and over again. That's ineffective and honestly, boring. All I care about is finding people who demonstrate that they can creatively and scrappily solve the types of problems we tend to see in the types of environments/situations in which we tend to land. Period.
So if any of this sounds like you, consider applying. This country and it's citizens could really use your help. And make sure your resume shows us that this sounds like you. :)
They're probably looking for much kids/fewer years experience (they keep bloviating about being startup like after all). Based on GS pay they cap out at a salary that is not very high for an industry veteran (they talk about steps being skipped only in "exceptional" circumstances). I guess they assume that if you've got all those years and are still applying you must not be very good. A GS15 is only 128k in the costly DC area. I work for a nonprofit in a much much lower cost of living area and make about that and I'm nowhere near the top of any payscale!
Oh and no relo assistance either lol. To work in the capital of corruption. Sorry but I would have to be braindead to surround myself by that environment knowing I was just a blue collar lackey. And if equivocating "public" service and being Trump's bitch works for you, I am happy for you.
For engineering, USDS predominately hires senior engineers with years of experience. The reason is because we help troubleshoot some of the biggest crises in the government.
Sure, but isn't 161k the max, and there's no room to grow beyond that? For many people who work in the SF bay area (for example) and have 10+ years of experience, even 161k may represent a pay cut. DC is certainly cheaper cost-of-living-wise, but not by a lot. And if 161k is the max, where do you go from there, especially if you won't have a job after a few years due to how their "tour of duty" thing? Spend even more of your own money to move back to the bay area, and try to reestablish your old salary from before you left?
If your counting the money it will never be worth it. It makes no financial sense to go work for the USDS, you will get paid less, you will work in a much worse environment, with more frustration then you can imagine. However you will directly impact the lives of millions of Americans. People who would have died, might live. Educations can be obtained for those who might never have had one. Doctors will get paid more efficiently and will take on more medicare and medicaid patients.
You might not have as much disposable income, but you can live a good life in a nice area for 161k. Thats more them most people in the DC area make.
