This of course is no excuse - there is a lot of work to be done and we are working on it.
Not even the worst of the descriptions of experience with USDS hiring I've seen could possibly be reasonable viewed as exacerbating the problem (mitigating it less than an ideal process would, sure; but to be exacerbating, it would have to be worse than the average non-USDS public sector hiring process.)
It's certainly not personal. I just think it's bad policy for all but the most safety-critical occupations, and choose to avoid employers who insist on collecting my bodily fluids or health history.
Right, its a bureaucratic policy providing a firm and strongly negative indication of the employing entity's respect for its actual and potential employees.
EDIT: To be fair to USDS, one could argue that the policy with regard to Executive Office of the President staff is an externally imposed (its statutory, not executive order, as I understand) aspect of the kind of government culture that USDS is intended in many ways to be a leading wedge for changing, at least as it applies to the IT space, so it may be worthy of some more generous consideration than would generally be the case, but its still a negative indicator.
I don't see how. It's usually just a sweeping policy for liability or legal reasons and that's it.
The USDS is suppose to be addressing the idiotic "seeping policies" that allow bureaucratic thinking to drive away those interested in working to use technology to improve performance.
That they didn't bother to fix this obviously silly bureaucratic rule that disrespects people is an very valid piece of data that you will find many less blatantly disrespectful bureaucratic rules stymying your attempt to do your work.
It might be they did a decent job fixing the many many problems with how much of government IT has been done but just failed on this one very visible and thus any marketer would tell you very important to address issue. But I doubt it. Most likely if they failed to even deal with this, the situation is pretty bad in many other ways.
USDS has done some nice things, according to stories I have read, but it seems it is just this appendage to the bureaucracy that is given some leeway due to powerful allies in the bureaucracy. This has always been the case in government and lots of good IT stuff has been done by those given power to avoid the normal IT processes by powerful allies.
But the other success isn't about an improved system it is about typical power politics in a bureaucracy. Things like sticking to bad policy that is driven by command and control thinking treating workers like drones such as polygraphs or drug testing for office workers is a sign that even the core thinking around the management system is extremely poor. In that case the management system will constantly be imposing idiotic rules on you that can be ignore only due to a powerful ally preventing enforcement (or just the incompetence of the bureaucracy to enforce the rules it set in place).
It's demeaning, and I simply will not do it.
Don't grasp at straws, anyone with a brain would bring proof of prescription (or put their doctor's number down!) to the test and that gets sent along with the results.
So now it's my urine and substantial pieces of my health history, including a pretty good drug-directed guess of what the actual underlying health condition is. Hope it's not an expensive one to insure. Oh, I'll write the doctor's number down too. I'll just fill out the HIPAA authorization form granting my potential employer access to my medical history. Good thing the practice's name doesn't include "behavioral health" anywhere in it.
Why bother with this nonsense when there are so many better employment options?
If I saw an auth form for any medical records release I would nope the fuck out too. That doesn't sound typical or correct. I have only seen releases for the results of the test which yes, if come back positive and you have proof of legal use will indicate you've been getting treatment based on someone's guess. However, it should stop there. If someone from HR starts asking medical questions about why you are getting treatment, that sounds like it's crossing a serious line and I'd be looking into whether that's legal or not. That sounds like a company that is hiring some shitty people, never mind whether they are good or not because they have a drug testing policy.
>Why bother with this nonsense when there are so many better employment options?
You want to work in a specific industry
I'm certain a lot of this behavior is illegal, but people who don't know or choose to ignore the law are everywhere, and litigation is expensive and time-consuming. I just want to build stuff, so I take these sorts of policies as a warning sign and look elsewhere.
Conflict: an employer demands bodily fluids, revealing medications one is taking.
In most cases, the demand for the private medical history is unnecessary, stupid, and illegal.
I likewise would pass, but would be turned off by the demand. I do not know if I would be sufficiently turned off to turn down an otherwise desirable job - it hasn't come up.
At the very least you now learned about them. I want you to read this: http://mikerowe.com/2015/08/otw-rejection/
And let me relate to you: I get turned down for jobs all the time. It is not because of capricious reasons that I wish were the case, but it's because of me not knowing something. Yes, it's maddening because they throw out good candidates along with the bad to minimize risk to them. The same facts happen to me and you, but try to have the perspective on them be as positive as you can.
That's not to say that failing to know that terminology should automatically result in rejection, but understanding that is not an unreasonable expectation when hiring something other than a narrow-focus language-specific code grinder.
Having said that, I'd be minded to look dimly on a candidate who tried to sidestep that question with 'but I use Python and they're the same there, so it's just a question of semantics' and did not try to clarify the question with me.
It's a principle-agent problem - having a strict filter gives the interviewer a way to deflect blame when they hire a bad candidate. This is at the expense of the company both through additional bad hires and through extra time and money spent interviewing.
Be careful of such assumptions. Google has a lot of languages that they use, and it's not inconceivable that someone that worked at Google might be mainly a Java engineer, without much exposure to Python -- in which case list vs array is a pretty meaningful question from their perspective.
java.util.List is an interface; java.util.ArrayList is the most commonly used implementation.
Of course, the proper response to a dumb interview question like this is "You mean linked list or array, right?" Because a reasonably seasoned programmer should recognize this poor choice of terminology for what it is.
We can follow up with you to let you know where you are in the process, but we'd need some sort of identifying information in order to do that.
Also, your response sounds extremely canned, not gonna lie. Why not just say "Sorry about that, pm me your name and I'll look into it and fix the other dozen folks while I'm at it."? I see emails like yours all the time from middle management who don't quite know how to manage, but have such a large audience that they feel obligated to act "professional". It's a "human" issue, so just write a response like a human :).
Also, we believe it's important to have the team you might work with do the interviewing, not just HR. Which unfortunately means we're often the problem - a fire with a client and suddenly you're down an interviewer, and we're not quite big enough to gracefully rebound and find a new one last minute.
All of which to say: not excuses, but hopefully gives you insight into some of our scaling troubles.
It doesn't sound like it's entirely your tream's fault, then. Not having enough time because of fires and such often screams to me of bad management towards the middle/top. And considering who you work for, that makes sense.
It was a computer science question, not a programming question. If a particular tool doesn't implement one of the fundamental data types that is an interesting point you can talk about.
But the question sounds like the interviewer wanted to make sure you understood the time-complexity difference between the two.
If you've never done that style of interview it is important to realize that the goal is quite different to making sure you understand a language's syntax.
I just turned to the two most relevant books that I had on my shelf. Neither Knuth's The Art of Computer Programming, nor SedgewiCk's Algorithms in C refer to a list without a qualifier. Knuth speaks of Linear Lists, and then goes into a description of Linked lists, doubly linked list and circular linked lists, and Sedgewick refers exclusively to Linked lists.
If I went to an interview for a Java role, and was asked to choose between a list and an array I would assume they meant java.util.List, if it was a Scala role I'd assume scala.collection.immutable.List; I think it's entirely reasonable for a Ruby+Python dev to be confused about what set of terms the interviewer is drawing from.
If you want to ask a generic CS question, then preface it appropriately, and be precise about your terminology.
If anyone asking "why is it so bad" actually genuinely wanted an answer, here is part of one: There's some finite amount of process change that we can absorb per unit time. We have tended not to prioritize process improvements that would reduce the risk of an individual getting a bad experience, in favor of ones that will increase the total yield of qualified hires. We know we are paying a price for this, so we keep an eye on places like HN to see how high it is.
And then of course I didn't get the job (and no feedback on why). The whole thing was maddening, took 3 months total just to get railroaded by an aggressive and imprecise technical interviewer. It sounds like great work though, wish them the best of luck. Wish I could work on their projects.