- 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 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.
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.)
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.
[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.
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.
>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.
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. :-)
As for government being slow and only change once a decade, you might be underestimating engineers in the government.
Here's the disability claim processing project I worked on when I was on SSA Digital Service. https://federalnewsradio.com/ask-the-cio/2017/01/ssa-turns-c...
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.
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 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. :)
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.
Not true. GS15 caps at 161k at DC area. It is a very respectable salary. http://www.fedweek.com/pay-tables/2017-gs-pay-table-washingt...
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.
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.