I really wanted to work for the digital service and my experience applying was horrendous. The recruiter scheduled an appointment to call me and didn't at the scheduled time. She followed up weeks later and I finally got my phone screen. Phone interview went well, she said we would schedule another interview. The followup from her didn't happen until another month later. Then I had a technical interview where the interviewer talked over me and asked whether I would use a list or an array for a particular data structure, to which I replied I use Ruby & Python so I don't know what you're asking because it would be a question of semantics, to which he finally clarified he meant a linked list and chided me for not "knowing the difference between the properties of a linked list and an array." How can you expect me to know the difference between two data structures if you're using unclear shorthand to refer to one of them? And the interviewer was an ex-Google engineer so I imagine he had some familiarity with Python (where a "List" is what many languages refer to as an array) since it's an official Google language.
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.
Hi Andrew. I'm really sorry that you went through that. We know and acknowledge that our hiring process isn't perfect - I can't count the number of conversations where we at USDS share stories about how we personally were in some limbo before interviews or what we had to do to get drug tested or how we were super confused.
This of course is no excuse - there is a lot of work to be done and we are working on it.
I appreciate the apology but the really disappointing thing is talking to your recruiters who say it's hard to get good technologists into government and then looking at your process that seems to exacerbate the problem.
> I appreciate the apology but the really disappointing thing is talking to your recruiters who say it's hard to get good technologists into government and then looking at your process that seems to exacerbate the problem.
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.)
Every public-facing process a business has is part of the marketing process. If people are left with a story of how dealing with the business was a bad experience, that will affect the business's reputation. When stories like yours are common the pool of potential talent is reduced as people are put off applying in the first place. The recruiting process at the USDS is exacerbating the problem because it means that fewer candidates will apply for jobs there.
Seriously. Good software developers have other employment options that don't involve being treated like a criminal and having someone watch you urinate.
It definitely would. "Okay, that's the fourth and final interview; you're hired, salary is within our range, now give us your urine so we can see if you're a heroin addict" is typically not how I like to start major employee/employer trust relationships.
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.
> Piss test would turn you off of a job? Seriously? You know that is bureaucratic policy 95% of the time and not personal?
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.
Most of the best coders I know would fail a drug test. It's just plain stupid. Even though I would pass one, I would never work for a company that does 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).
I think this is one of those east coast vs west coast business mindsets. West coast businesses for the most part don't even think about drug testing while east coast ones can't imagine why you wouldn't drug test.
I have never been drug tested. I've worked since 1990 on the East Coast. It's never even been mentioned to me, except the one time that I looked into the FBI and discovered that they can't afford me.
The stupid part is that drug tests would reject a large percentage of really good programmers, and they are neither abundant nor cheap. That's a big cost for such a vague benefit.
Even better: at some of these employers, being treated therapeutically by a doctor with a DEA scheduled medicine forces you to take the urine test, fail it, and then inevitably listen to someone from HR ask you questions about your health history in order to ascertain if you really need to be taking the medicine. It's intrusive, infantilizing, and just not worth it when there are so many better employers out there.
>Even better: at some of these employers, being treated therapeutically by a doctor with a DEA scheduled medicine forces you to take the urine test, fail it, and then inevitably listen to someone from HR ask you questions about your health history in order to ascertain if you really need to be taking the medicine.
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.
I doubt people without a brain would get much out of drugs.
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?
>I'll just fill out the HIPAA authorization form granting my potential employer access to my medical history
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?
The issue is that virtually all practices will refuse to disclose any medical information to third parties without explicit written authorization.
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.
I am generally against drug tests but I'd deal with one for USDS because I believe in the mission. Also let's say you're a recreational marijuana user, all you'd have to do is stop smoking for a month or so to pass a single test.
Premise: it is good, to the point of being legally enforced, to keep an individual's medical history private, except when necessary for medical treatment.
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.
My father always refused any position that demanded a drug test, even at points in his life where I am virtually certain he would have passed.
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.
Why should anyone not operating heavy machinery have to be subject to such a test? I'm with the other poster in that I will never take a job that requires such a test purely on principle. If a job requires such a poor heuristic for gaining employment, how is it going to be actually working for them? My guess would be a steaming pile of incompetence raining from above. I have much better prospects as a technologist elsewhere.
I don't believe you do for 18F, but you do for the US Digital Service, as its a part (or operates under the authority) of the executive office of the President.
Not to be a jerk but I'm going to sound like a jerk, but know it is from a position of love: linked lists and arrays are both fundamental data structures.
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.
Well, the appropriate response is to politely ask for clarification. Sometimes asking a dumb question is a useful way to see how someone treats someone less experienced. I find treating interviewers with deep respect no matter how dumb they sound generally puts me in the drivers seat going forward.
If someone mentions array and list as alternatives in a generic CS context (not language specific), one generally familiar with the field should be aware of the concepts being referenced (one might reasonably ask to verify that the latter was a referenced to a singly-linked list, since while that's by far the most likely meaning in a generic context where it would be paired with an array, there are some other possibilities.)
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.
I agree that the question needs improvement, it admits too much confusion unless there's a context. List is an ADT in Java and OCaml and some of the literature, an implementation in Python, C++ etc. Linked-list would have avoided that, although possibly suggests an answer.
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.
The most maddening part of seeing companies throwing good candidates out along with the bad is that it's actively harmful for getting good candidates. You're doing more interviews, which means more opportunities for a bad candidate to somehow slip through your filter.
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.
I'm really sorry about your experience. In many ways we're still a fledgling startup. We don't trust the regular federal government's hiring process, which means we have to build our own from scratch, so we have our own recruiters, coordinators, and when we aren't fighting fires or developing software, we're the ones actually doing the interviews. The process was maddeningly slow for a while but it's improving.
> And the interviewer was an ex-Google engineer so I imagine he had some familiarity with Python since it's an official Google language.
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.LinkedList also implements that interface. ArrayList has the same semantics under the hood as an array (fast insertion at arbitrary places, fast random access, slow extension), and any Java programmer who's remotely familiar with data structures should know the difference between the two. Especially when LinkedLists are so commonly used under the hood in e.g. the java.util.Queue family.
Yes, of course. But if someone - especially a java programmer - asked me "list or array?", I would regard them amateur. In most of today's popular programming languages, list != linkedlist.
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.
at least you got a call back, ive been waiting for weeks to hear back to my initial contact. this kind of makes me want to not answer the phone if they do in fact ever call.
Hi, really sorry that you feel this way. Delays on the order of a few weeks aren't unexpected at this point, but we shouldn't have people that have been waiting for a response of some kind for much longer than that. We're still growing the team (including those doing the recruiting and hiring) and we appreciate everyone's patience.
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.
If you don't mind me asking - why is the process so bad for you guys right now that many folks are complaining?
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 :).
18Fer here: Our team talent is tiny - I think three or four people. The amount of people in the pipeline is massive. They're inventing, and reinventing, processes left and right to improve. Also, at some point we have to hand off to GSA's hiring group for final paperwork, and we have less control over that process.
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.
I wouldn't even say it's bad management. Emergencies do happen sometimes, and when that happens it sometimes has a bigger impact than "people can't buy pants on the internet right now."
Yes I would say it's typical. But they also say their challenge is getting good technologists into government. So if they believe they have difficulty hiring (which is their public stance) why not adopt a more candidate friendly process? And I'm not saying I necessarily would have gotten the job otherwise, who knows, but I do feel like they wasted a lot of time, strung things out over months and then didn't give me a good opportunity to show them my abilities.
Agree with you. Government work has not been very popular with programmers. Working for "the man" is not something that is generally sought after. Ideals are strong in this young industry. Dunno if they should try and work as a startup. They are a not a business, nor can they operate like one.
asked whether I would use a list or an array for a particular data structure...the interviewer was an ex-Google engineer
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.
Except, if you want to ask a question about CS Data Types, you really do need to be clear in your terminology.
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.
(Member of USDS) - I'm sorry we gave you a bad experience. It is not something I want to have happen to anyone.
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.