Some people might not have realized USDS is still around since it was best known for the Healthcare.gov rescue under Obama. But it's still here, and still hiring people to work on problems like this www.usds.gov/join
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.
I am glad to see it's still around. I was worried that it would be cut with the change in administrations since it reports into the White House. The USDS is a shining example of civil service and the best of government.
Hey there, I'm the USDS Administrator. Most of our projects are the same, like making sure that veterans can get their health benefits. We've found partners in the White House who really want to make government work better for the American people. An example is Chris Liddell, who was CFO for Microsoft. Every administration is going to be different and have different interests, but we've been able to find common ground on projects, and those projects are helping people who need it.
Our mission has remained very consistent: use design and technology best practices to improve government services. The new administration has different policy priorities, but it has been remarkable to see the bipartisan support for our mission. Our work has remained largely the same. The major difference is fewer technologists are raising their hands for public service now, which constrains our ability to improve things.
I'm not the photographer, I put the site together. Our photo journalist, Amos, met one of the tuskers on another reporting trip (which I also produced), called On Siberia's Ice Highway.
This is awesome work that is going to make it easier for a number of our digital service teams across government to deploy services.
[shameless plug to join public service for a year or two]
If you're interested in joining 18F or the U.S. Digital Service (which has an HQ office in the White House but also has teams across government), this application works for both teams: https://www.whitehouse.gov/usds/apply
If you'd like to build things like this Dashboard, and help fix the services Americans depend on, we are hiring. We have an amazing core already, and are growing fast. Read more about the U.S. Digital Service and apply at: https://www.whitehouse.gov/usds
Our pitch is pretty simple: Fix Stuff That Matters.
While you might be hiring, it was remarkably hard to find any details on job listings. (edit: I don't think I actually found any.) The closest I could find was by following many links and eventually getting a web form where I could give my contact info for joining the Digital Service.
Is there a chance you could put a more convenient link directly to your listing of jobs (or a friendly page that links directly to USAJOBS, or explains about that painful tar baby) at the bottom of the main 18F page?
This 18F blog post talks about the different types of roles people play on our team: https://18f.gsa.gov/2015/02/25/We-Are-Hiring/ . The application form for the Presidential Innovation Fellowship program also calls out specific skills and domain expertise they're looking for: https://pif.gsa.gov/ . Cheers!
There are several ways you can plug in to the big problems we’re solving. You'll drive vision for a better government, working alongside policymakers, agency leaders, and program teams to build world-class digital services.
Product Managers -- We are looking for product managers who can balance user needs with business requirements and apply technical knowledge to bring world-class digital services to the American people. You'll need to manage complex projects to hit tight deadlines without sacrificing quality. If you feel comfortable reviewing engineering design documents, project plans, and contracts, and you can communicate technical concepts to various audiences up and down the command chain, we're looking for you.
Engineers -- Our engineering leads will drive technical teams to build large-scale, innovative products that serve the American people. You need to be an expert strategizer, fixer, and builder with the engineering chops to roll up your sleeves and push your own code. You'll provide leadership on major technology projects, manage project teams with focus and vision, contribute to product strategy, and support strong teams of engineers.
Designers -- We are looking for designers from an array of disciplines — experts in research, UX, service design, product strategy, visual/UI design, and content strategy. Whatever your flavor, you embrace complexity and revel in drawing simplicity and clarity out of thorny challenges. You are a relentless advocate for the needs of users. You will help lead teams and prototype, test, and iterate on services and products. You will help build the Federal Government’s capacity to deliver services to the American people.
Many positions are DC-based (at least some part of every month), but several of our digital service teams (including the largest and most mature Digital Service team at GSA called 18F https://18f.gsa.gov) have remote offices and allow remote work. You can indicate your geographic limitations on the application.
And also open-sourced the adapter we use to get the data out of Google Analytics and into a nice clean JSON API for our client-side static app to consume:
There was a bit of a kerfuffle around Healthcare.gov sending data to analytics services (despite that being industry standard practice), so I'm curious if there's any push to ditch Google Analytics, etc., for .gov, and move analytics services in-house.
Can you be more specific about what you mean by "kerfuffle"? This is the same healthcare.gov that was/is sending PHI data to 3rd parties analytics and ad services (doubleclick, etc)?
Man I love the fact that you guys continuously contribute to this community. I hope whatever you are doing spread to other parts of the government. I really enjoy seeing the government engage the community in this way.
It's pretty damning of the HealthKit product team that a post like this is required. Why would Apple publish the app at all?
It seems like they should have released iOS8 with some kind of simple pedometer/stair counting app that looked good and was easy to use, like a reference application to show what HealthKit could be used for, and then buried the HealthKit app as it currently stands in some settings menu that most people will never need to look at.
The only thing I can imagine is that they intended to roll out a bunch of HealthKit-compatible apps from third parties like Nike and FitBit along with iOS8, but the bug messed up their release plan.
The best I can tell is that the Health app is more of a hub to see aggregated (raw-ish) data, and set/update permissions on what apps have access to what data.
I don't think their intent is to compete with any of the apps out there that use the data though.
I believe your correct. The iPhone 5s, 6, and 6+ all record the number of steps you take thanks to the M7 motion processor, but that seems to be more of a 'because it's there' thing.
Because the intention was to have third-party apsp and device integration at launch. But something went wrong, and all the partner apps were pulled if already published, or postponed if not.
It's called HealthKit because it's basically a software development kit. The GUI is clearly more of an afterthought and a way to keep the settings from getting buried in the already packed settings app.
The best thing about teaching kids some basic programming is that it shows them that they have the power to shape the world, rather than just experience it.
Whether or not they go on to do anything code-related in their "real life", I think getting that experience at an early age is extremely empowering.
"it shows them that they have the power to shape the world, rather than just experience it"
That is precisely why I love programming so much, it's that statement right there. You have the tools to shape the world right in front of you, all you need is the drive and vision to do it.
Some of my Innovation Fellow colleagues at GSA are trying to do just that: making it easier for modern, small web development shops to apply for government IT contracts.
I'm getting a ton of errors trying to register for RFPEZ. Everything from timeouts to 500 server errors. Feels like the Healthcare.gov issue all over again.
Also, why would one need to "provide a link to an image of your best work"? That seems very contrary to the point of procurement - especially given that so little of the opportunities are for actual design work. Furthermore, how does one link to work performed on an intranet, etc. (as most government work is)?
Seems like it needs to be thought out a little better. Is the "best work" link part of the selection criteria? How does this work with FAR requirements or simplify the RFP/RFQ process?
i just signed up for RFP-EZ, looks great, except all of the existing projects seem to be links to massive FBO RFPs. hopefully more projects are submitted soon!
