It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.
I can try and come up with reasons why that might be the case, why a simple OO modeling problem + a couple of trivial algorithmic problems (like, take an ascii string, return me a dict mapping characters to character counts) would trip someone up...but that isn't sufficient justification for me to want to continue to an onsite.
And that's the people who get past the verbal screen. Plenty drop out at that point. "I see you spent two years as a Senior DBA. Can you tell me what the acryonym ACID stands for?" "No, I'm not familiar with that" "Okay. Well, the 'C' stands for consistency. Can you tell me what one means when we talk about data being consistent in the database?" "It means when you write something it stays written (or some other made up twaddle)" "I see."
That said, I agree that coding tests that are completely unrelated to the job, and are geared toward college grads rather than long term developers (i.e., "Implement a (data structure)" or "Remember/discover an algorithm that was a PhD thesis 30 years ago to solve a contrived problem in a theoretically optimal way" rather than "Solve a real problem of a kind similar to what we'd expect you to do here") are dumb.
There were people who were bad at (possibly some because they were under pressure), it but nobody who couldn't do it at all.
I wasn't giving out a trivial question either.
I'd suggest a widely-accepted professional certification could help a lot, like doctors and lawyers have with the medical board exam or the bar exam. Easier said than done, but what we have today, where the candidate pool is overflowing with impostors with great resumes is not working.
(I've had that happen several places)
"i passed the bar exam!" and nothing else doesn't get you a legal job you want.
and your medical boards, if i recall correctly, just mean you're qualified to go be a slave, er, uh, resident, some place for a few years.
Find me good certifications that are actually meaningful and relevant to my career, and I’ll do the study work and get them.
I have yet to find any.
Go long enough interviewing hundreds, you'll see a few no matter what. Have a crappy enough filter in front and you'll see them right away.
Asking the right questions at interviews are crucial for finding the right people. If a candidate for a programming job knows binary trees but doesn't listen to other peoples views I would say he's less worth to us than a listener that easily learns new concepts but is currently not familiar with binary trees.
BTW, leaving a candidate in tears is not professional recruiting. Please let someone with more people skills accompany you to your interviews, you might leave people with scars that takes years to heal.
I'm sure it's used under the hood in a lot of code I write and have written but so is XOR, manual memory management and a bunch of other lower level implementations that I don't need to spend time on when developing on a higher abstraction level.
Not sure why you would expect all programmers to know about binary trees specifically.
I'll bet, even with this feedback, you'll continue to ask that question, just because.
For some reason that company insisted on only doing interviews at 7:00 AM, and my brain doesn't come fully online until after 9:00 anyway. I felt annoyed later when the answer came to me that afternoon, too late: put the list in a hashtable, add all pairs of numbers for O(N^2) complexity, and check if each answer occurs in the hashtable.
Much later after that, I realized that all the other red flags I'd picked up on while interviewing there added up to an impression that their corporate culture was seriously f'ed up, and that I probably dodged a bullet by getting passed over quickly in the process.
The skill takes a long time to practice, and quickly evaporates once you stop doing it. Yet none of our work is anything like that. a more real world situation is reading documentation or SO for the function concat_ws that will turn an array column to a concatenated string.
however, the system that is, and one that you seem to think is ok, is one that discriminates people on many levels. Its a skill you do not get good at by working, so you must practice this in your free time. Now you just discriminated against men and women with families, people from less fortunate backgrounds, and others who otherwise do not have the time in the day to dedicate to a skill that is only useful to coding interviews.
as far as a comment above, I was a DBA for 10 years and can do pretty complicated queries off the top of my head, know how to optimize my indexes, worked with both structured and unstructured data in the multi tb size, ect ect, but I have no recollection on what ACID stands for. I dont really care. Sure, you may hire someone who memorizes useless crap, but then they have no idea why the IO has gone through the roof when inserting IDs out of order on a clustered index.
I just look up joins when I need them, and it's straight forward, but ask me in an interview and I sound like an idiot.
I wasn't rejected but I've been asked to retake a phone interview. Apparently, the interviewer had very good feelings about me, but found that I was "out of practice" as far as coding goes.
I wonder if my age is an issue (40+) or if they have a really high level of expectation. Are most other candidates super fast at solving these kinds of problems. I'm a bit disappointed because I'm not sure that I've got much room for improvement at that stage.
They want 23 year olds who just did their finals. You know, real stallions.
You know, real pegacorns.
It sounds to me like you did pretty well so don't give up.
From my perspective that is only about 3% of what I expect from a software engineer. Writing readable, easy to maintain code that is well tested, collaborating with product and other developers for how a feature should work, influencing technical designs, giving good feedback are things I value much higher than how quickly someone can write a snippet of code that works.
How did you arrive at that conclusion? Is it based on data or does it "feel" right based on an easily-measured metric?
This is _a_ metric but I wouldn't bet too much on it. I know lots of people that come to optimal solutions to "algorithm type" _much_ faster than I do. I'm pretty slow at that type of stuff. But... its just such a small part of what makes someone a good programmer. Building out a medium to large application requires balancing a lot of trade offs and figuring out how to keep things simple. I know seasoned, quality algorithm solvers who honestly just repeatedly churn out garbage applications. And they can tank the productivity of an entire team of developers in their wake. I don't know how you test for that, but I can promise phone screening for problem solution time isn't it.
Translated: "the one that did it much faster is a more recent graduate and exploitable for 100-hour weeks at below-par pay, hire that one".
Congratulations, now you know how to hire at a tech company!
The answer to that is almost always yes.
Maybe the interviewer was biased and led to think I was "out of practice" because he knew I was on the older side. But I'll give them the benefice of the doubt. I believe it's a competitive position and I simply wasn't in the right percentile to qualify.
Now, would my former self 20 years ago be more competitive for this kind of interviews? slightly faster perhaps, but I don't feel I'm at a disadvantage compared to younger candidates.
For many tech companies where they get a lot more candidate applications than they have positions for, the goal of the interview process isn't to avoid losing good candidates, it's to not hire bad candidates.
So much more goes into software engineering than "Can solve tiny example problems in an examination system"
True that software engineering is more than that, but those other things largely depend on in-house company processes, tools and policies so you would learn them afterwards.
It annoys me that the good answer if you actually encounter the problem during the job is never accepted during an interview.
They aren't looking for people who don't know to start by doing some research, they're looking for people who won't be completely stuck when that research doesn't turn up the answer.
So then I try and give them a O(n^3) solution (or something).
Of course this isn't accepted as there's a better O(n^2) solution, which can always be found by googling, and I fail the interview.
The "turtle and the hare" problem of finding a loop in a single linked list in O(n) time and O(1) memory is the perfect example. It's easy if you know the answer (or can google) but basically impossible if you don't.
What did the interviewer do when I said I couldn't do better than a hashmap? He laughed and said "not many can".
The gist of it is: walk the list and after each step, multiply the previous node’s pointer by negative one.
If the current node’s pointer is negative you’ve found a loop (because you colored it by inverting the pointer in a previous step).
Clean up by starting at the beginning and multiplying all pointers by negative one until you reach the last one you inverted. Then return your answer (true).
If you reach a null pointer there is no loop because you’ve gotten to the end of the list. Clean up by going through again and multiplying all the nodes by negative one. Then return your answer (false).
Your worst case running time is 2n (if there is no loop) which reduces to O(n) and you use O(1) memory because you’re coloring the list by using the already existing pointers in the list.
Which means what they're really saying is not "we want problem solvers". What they're really saying is "the bare minimum for entry level work here is being able to, in 30 minutes and on the spot, out-perform top-tier theoretical CS researchers".
Which in turn really boils down to "be a recent CS graduate who memorized this algorithm in advance so as to 'derive' it later on command".
They were probably looking for the answer of, "Lets talk through it and figure out a better answer". Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc.
So from their perspective, they asked you to try harder on a problem, and you just said, "No." And they dropped you for it.
FWIW, I had similar questions in some interviews where we hashed through similar problems, and together collaborated down to a "No" answer... but we spent 15 minutes exploring the problem and seeing how well a couple coders can work through it before saying no. And I got the offer despite an otherwise rusty performance.
I was asked to sketch the proof for the irrationality of sqrt(2) in a quant programming interview. I kind of froze, and explained that though I had learned it, I could not recall.
He prompted me with "Well, what does it mean to be irrational?", and with that little hint I did the rest. Though ultimately I did not end up working there, it was very satisfying to have answered it.
Well, in one case (me), all the information the interviewer had was "this guy happens to know how to implement a quick sort by heart. K.".
In the other case (my friend), he got "this guy is able to understand and implement an algo he never saw before in a reasonable time", which is much more impressive
Assume sqrt(2) is rational and has the reduced form (x/y). Thus we are assuming that x and y are integers and that gcd(x,y) is 1. You square it and get x^2/y^2 which are somehow simultaneously coprime integers and also reducible to 2/1...
> We now show that the equation (1) p^2=2 is not satisfied by any rational p. If there were such a p, we could write p=m/n where m and n are integers that are not both even. Let us assume this is done. Then (1) implies (2) m^2=2n^2. This shows m^2 is even. Hence m is even (if m were odd, m^2 would be odd), and so m^2 is divisible by 4. It follows that the right side of (2) is divisible by 4, so that n^2 is even, which implies that n is even. > The assumption that (1) holds leads to the conclusion that both m and n are even, contrary to our choice of m and n. Hence (1) is impossible for rational p.
This isn't always true. Some interviews are really about solving the problems as fast as possible. And lots of interviewers are looking for exactly the answer they have on hand, and will think you're doing it wrong if you come up with a different, but equally valid (or better!) solution.
Huge asterisk that as long as you arrive to the correct solution with minimal help. I've had plenty of algo/ds interviews and it seems like needing help to see the trick in the question pretty much means you're out.
At my last company, we would sit a candidate down at a pairing station. We'd offer them about 5 problems to choose from, and together we'd pair program on the problem for 2 hours. Using the internet, the IDE, anything they want was totally fair game. No system is perfect, but this was by far the best one I've ever experienced.
In many of the places that do claim this, even if you solve the problem "correctly" you still get more brownie points than someone who got a less efficient answer or didn't get an answer. Meaning that they /do/ actually care. I do get that some places are smarter with regards to this than others but it's depressingly common in my experience. "You didn't get the O(n) solution that has weird edge cases and was published as a paper in the 70s? Too bad, because some other person did, because they remember the solution from some programming interview book!"
The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well)
The answer to that item would be: (with scala)
> datasource.window(3,1).filter((a,b,c)=> a+b == c)
I mean if you knock it out of the park and know the internals of window.. then asking the bar raiser question is appropriate as a curiousity.
There are other problems as well: Those are the ones where they have an expected answer, response, and reiterate. I've seen that with tree problems. That's where they would low-key ask for the recursive version and then get you to say stackoverflow exception.
My immediate solution: Sort the two strings and then compare them:
(defn anagrams? [x y] (= (sort x) (sort y)))
"Ok, what's the efficiency of that solution?"
"Well, assuming the library sort functions I'm using are sane, I'll take a guess and say O(n log n)"
"Can you come up with a more efficient solution."
Off the top of my head, on the spot, I couldn't. Later, during the plane ride home, the obvious occurred to me: Don't sort the strings, just scan through each string once and build a hash table, keeping track of the number of occurrences of each letter in each string. Then compare the occurrences for each string. Not as elegant to express in code, but faster.
As it turns out, they later declined to hire me, giving me an excuse that made it clear they weren't really serious about hiring anyone for the position (as is the case at least half the time, it seems).
And thus ended my latest round of failed interviews. I cancelled the last one I had scheduled (probably another fake) and decided to take a break for a while (I mean, I do have a job right now, so it isn't urgent).
You’re right.
ac = 1 + 3 = 4 bb = 2 + 2 = 4
So I think something silly like: character_code = len(string)*len(alphabet)^character_index should work.
Still, consider the word ‘abe’ with a = 2, b = 3, c = 5, d = 7 and e = 11.
abe would then be 2^1 * 3^1 * 5^0 * 7^0 * 11^1. ‘abba’ would be 2^2 * 3^2. Each anagram would have a distinct value.
See also Gödel numbering and FRACTRAN.
Reminds me of my final round at Amazon, which they always do in Seattle. I woke before 4 AM west coast time having flown out the night before from the East, and 12 hours later was still coding on a white board. After writing (to my surprise) a correct merge sort, they asked my to write a program to do basic math with, IIRC, binary numbers. I was like, um. I'm out.
And if you throw in distributed databases, there is yet another understanding of "consistency" (vis-a-vis the CAP theorem), which really means "linearizability".
Sorry, didn't mean to be super-pedantic but consistency as a concept may seem simple to the uninitiated but is easy to get tripped up on, especially for folks who are aware there is a deeper layer of understanding associated with the concept, but can't articulate it right off the bat.
All this is to say filtering people truly is a hard thing. The extremes are easy to tell apart, but people who hover around the average are much less differentiated.
[1] https://en.wikipedia.org/wiki/Consistency_(database_systems)...
And I have similar anecdotes related to candidates who claimed years of distributed systems architecture experience, and were yet unfamiliar with CAP (and when explained, could not tell me even at a high level whether, in the event of a partition, their system was CP or AP, let alone the specifics of how that actually exhibited itself).
Once you start working on a particular database, and are working on all of the specific details of that db, how often does ACID come into things, really? It just doesn't.
I don’t think it’s essential to know this, but I’d be surprised if a web dev interviewed with us and didn’t know at least the basic version I’ve given above.
Just my experience, perhaps I live in another world.
I think this is partially what I'm referring to. I use these terms in conversation with others when designing systems because they are useful in describing very specific properties of databases.
If you legitimately did the work without picking up -any- of the terminology, -and- respond confidently to questions you should know you don't know the answer to (rather than admitting ignorance and asking for follow-up questions, or declaring assumptions, i.e., "Well, I would assume it has to do with the behavior that if a constraint is violated or something similar in a transaction, the transaction will be rolled back instead of committing"), I don't want you. Because it means you both did not have formal training in, AND didn't seek out information or knowledge in the domain you were expected to be -senior level- in.
And while atomicity and durability are just characteristics of a relational DB (and so adminning one doesn't really require you to understand them), isolation and consistency both have definite relevance, because the isolation level is configurable, and that affects the consistency guarantees of the system. I expect someone saying they were a -senior level DBA- to be able to talk intelligently about those behaviors, and yes, to understand the words, because just reading the docs would have introduced the words.
Otherwise, I think we simply disagree in some respect, although I think it's over emphasized due to the topic. I think both perspectives have a level of truth to them, and have their flaws. It really depends on the candidate, and what they really know. Perhaps my particular circumstances are sufficiently odd enough that they aren't useful in a broader context. Who knows.
One of my mentors said that about an interview he conducted a while back. I found a lot of truth in that line. I run my tech interviews by starting very green and let the candidate dictate how fast I ramp it up. I've gotten pushback from managers before that you can't start with basic questions, but I've equally gotten positive feedback from candidates (even one's who've been failed the interview). In the end, programmers want to see an algorithm that allows them to judge an interviewee. I don't believe one exists.
I mean, look at this thread; would it be better to start with "Here are some example tables, please write the SQL that will return me (etc)" and turn it into a coding exercise? Because I honestly don't care that much about that from anyone espousing a senior level of knowledge.
The worst part is that usually these toy problems are justified with "but you can post this to your Github for others to see!"
Likewise, if someone wants me to walk them through a project I have with explanations of what choices I made and why, I'm happy to do that. But please don't waste my time asking me to implement DFS, or write another twitter API client.
Now: If you care about being able to collaborate on a tough problem with somebody, work on a problem neither of you has seen before together :)
Perhaps because, like many developers on modern teams which eschew the older role distinction, the incumbent in the position being hired for will need to act in the role of a classic system analyst in defining specific requirements give a fuzzy business problem as well as the role of a grunt coder.
Also, the presence, functionality, and quality of code on GH does not establish it's provenance.
Sure but that's a different skill from solving DS/algos, so don't conflate the two. Some people know their DS/algos super well but need to solve them solo, some people need to google around a bit for inspiration or take a walk if they get stuck.
Instead, separate it out. Give a specific "system analyst"-style question that's distinct from coding. A question you don't already know the answer to or that could be taken in a thousand different directions that you've definitely never thought of before.
If you need proof they can "actually code" and use DS/algos etc, use their GH if it exists. And if you want to see that they can work on a team to define and deliver a messy problem with other people, do that with them on a messy problem you've never solved before. (It could eventually be a DS/algo problem; my point is it's a group effort and neither of you knows the solution; you're looking explicitly for how the interaction goes, not if "the candidate" got the "right" answer.)
If you don't take a candidate's prior art into consideration, you're wasting everyone's time. You're also eliminating candidates who may excel in ways that aren't solving riddle-problems out-loud in front of new people when their livelihood is on the line.
Start with the GH and if you have doubts fall back to portions of old model.
> So I'm supposed to spend my time researching your GH instead of just letting you spend 5 minutes proving it?
I've never seen a worthwhile programming q take only 5 mins to answer. And the candidate is supposed to waste an hour of her time proving to you what you could see in 5 minutes on GH?
> There isn't enough time in a day to research every candidate's code they wrote on their own time
Yet there is enough time to spend with whiteboarding problems that prove the same things the candidate has already proved on their GH?
> (and personally I'd rather not be judged by mine).
Sure - only use the candidate's GH if they prominently put it on their profile and/or own an "intended to be used/seen" public repo.
> And, if people lie on their resumes already, what makes me trust their GH?
Not a replacement for conversation! It's a way of indicating they can code without solving an arbitrary riddle in a high-pressure situation. If you're not convinced they wrote or understand the code you're looking at, ask them about it or ask them how they might change it slightly.
As an aside, the reason not to work on novel-to-you problems with job-seekers is that it's very hard to fairly compare candidates after. I strongly prefer pairing on the same problem with all the candidates in a batch. Otherwise it's hard to tell if a bad result is due to a bad problem or an unacceptable candidate.
Sure - but you're not likely to really see the "real" thought process you're hiring for by asking a stranger a riddle you already know the ansewr to in a high-pressure situation.
Real problem-solving and thinking is done in a huge number of ways that sometimes isn't conducive to strangers, pressure, or whiteboarding.
> I'm interested in when candidates pick not-optimal choices for good reasons
Right - which is why starting with something they've written on GH (which is something they've thought about and are probably passionate about) is a great jumping-off point for such a convo.
> As an aside, the reason not to work on novel-to-you problems with job-seekers is that it's very hard to fairly compare candidates after.
I see your good-intention here, but it's nearly impossible to compare two candidates without all kinds of biases (implicit and explicit) coming into play.
> I strongly prefer pairing on the same problem with all the candidates in a batch. Otherwise it's hard to tell if a bad result is due to a bad problem or an unacceptable candidate.
I think this may be another way of trying to compare candidates to eachother (which is perilous).
Good candidates can do well with bad questions, and bad candidates can rarely do better than okay with good questions. There are lots of good/proven questions you haven't solved - ask your colleagues.
Unfortunately, the current common argument from the hiring side is that GitHub profiles are not sufficient proof of skill since code can be copied (not fair) and GitHub projects bias toward people with extra free time (reasonable, but not enough to discount GitHubs completely IMO)
Yes, some of the code may not be original, but unless the repo is a fork you can pretty easily see if the code is organized in a coherent way that shows the committer knew how to decompose a problem well. If they solved /every/ piece of the problem themselves, it may be a sign of a different problem (and also copy/pasting without citing source is also telling!)
On the other hand, fakers have caught on to the "GitHub is my resume" thing. I have had applicants who have basically fraudulent Github projects, or who have taken group projects on which they did basically nothing and claimed them as their own. So a Github page now requires an expert to evaluate it.
If its is their own code it shouldn't be a problem.
If it isn't their code and they can still talk you through it, even better - they have managed to understand code that someone else wrote which is probably an even more valuable skill.
And no, having somebody who's an energetic fraud on the team is poisonous. Having somebody who's so good at it that they're hard to catch is worse, not better.
I didn't write the monstrosity that I am working on just now, but I could explain how it works and I know where to look to fix bugs. I don't know why some crappy design decisions were made. Does that make me a worse programmer than if I had written it myself? Is harder to understand someone else's code than stuff you have written yourself. There are far more jobs working on existing code bases than on new new projects.
(My guess is that you have never worked with anyone who has claimed ownership of someone else's code, have you?)
None of the techniques discussed in this article are even attempting to judge productivity, they are attempts to judge coding ability. It's good that you bring up productivity though; that's what we are really after, isn't it?
>from a short conversation
I'd argue 30 minutes to an hour is not a short conversation. Do you think an imposter could fool you about tech (assuming you are an active programmer) for 30 minutes to an hour?
>it's probably better to see the proof
You're not proving anything except the fact that the candidate has memorized a merge sort algorithm (or whatever trivia you are testing for). What you really want to know is, can they ship?
I think you should at least consider the idea that not only are these tests and homework assignments (past fizz buzz) a poor indicator of ability, they active repel any candidate good enough to be in even reasonable demand. I mean you have a lot of people on not only this thread, but many other threads saying the same thing.
Time for a little reflection, what does your company offer that even a mediocre developer can't get in 20 other places in your city? I mean if I could get "market rates," and a "fine cubicle," and "standard PTO" in 20 places, tell me again why I would bother with this rigamarole?
I have no idea where the idea that having someone come on site for 6+ hours wasting a dozen peoples time became the norm as opposed to talking to someone for 1 or 2 hours and truly speaking with them to understand what they know.
You're completely right, if you can't talk shop and not know when someone is bullshitting you shouldn't be the one interviewing.
How would this even fly in other industries? Are you telling me that someone can bluff their way discussing the intricacies of surgery to other surgeons without looking like a moron? Or discussing particle physics with a researcher and stand on equal footing? I honestly want to hear a conversation where a liar with no programming skills is able to convince a Senior level Software Engineer that they are on equal skill sets.
The best interview experience I had, where I eventually worked for the company, was having an hour conversation with the Engineering Manager who I would be working under then being ask basic programming Qs based on our conversation we had. Everyone in the company was interviewed the same way. IMO the resulting team was very professional and skilled on various levels from various backgrounds. I actually felt like a human at that job and not a person hired because of x thing.
I'll never forget I had an interview where they asked me a question about finding anagrams. At that moment in my life, I've never heard of an anagram or knew what it was. The Interviewer then explaining what it was to me made me feel very humiliated. I completely bombed every question because I had the audacity to not know about this thing where the interviewers knew about thing therefore I should know thing as well. I immediately understood how cultural biases can effect candidates getting jobs. I can only imagine how worst it is for people not from traditional backgrounds in this industry.
I had a candidate for a 3d graphics job, who showed me incredibly impressive things he'd programmed like very realistic water simulations, etc. He talked us through them, was incredibly articulate and clearly knew his stuff.
He completely bombed the coding exercise. It was something like: given 2 hours alone at a computer, with a threejs scene already setup, make it display a few cubes at different heights, colors, etc. Full access to internet, google, etc.
He couldn't get one cube to show up. That's maybe a two line piece of code when given the entire environment already set up, and you can find it by googling Threejs tutorial and copying like the first example.
Ya.
As far as graphics, the only time I was ever fooled was by a front end guy in 2005. He brought really nice looking color printouts of his front ends; beautiful stuff. I was really wowed by it; so much I didn't ask him basic programming problems or follow up questions about his prior work, and that was my fault. I allowed myself to be fooled.
His biggest issue was he was lazy. He had grown accustomed to government contracts where you do a lot of prototyping, but nothing ever went live (at least the contracts he had). We had a very aggressive 3 year schedule to build a sophisticated product and he just couldn't or wouldn't keep up. I had to double my workload and he ended up only doing about 5% when he should have done a third and he required a lot of prodding and hand holding. We still managed to ship on time though, but it was really hard on the other 2 people on the team for 3 years.
I'll never make that mistake again.
Perhaps he really was a very talented developer but your coding exercise was too stressful for him. Shame you missed out on hiring him.
This is not a story to show why we should do coding exercises. It is a story to show why they sometimes don't test the right thing.
1. He knows how to do extremely specialized things in an existing environment, but can't do things outside of that environment.
2. He was presenting work that he had only a partial hand in creating.
3. He is amazing at e.g. C++, but cannot learn even rudimentary new things in Javascript.
...
Some of these stories make him a terrible programmer. Some of them make him an OK programmer for other positions, but weren't relevant for us. None of the stories make him a particularly great programmer.
"Perhaps he really was a very talented developer but your coding exercise was too stressful for him"
Yes, it's possible. A lot of things are possible. But I'm sorry - if someone can't copy-paste a 3 line program from the internet and get it to work, in their own field, for 2 hours, then... I don't know how I could ever design a test on which they won't fail. Including the actual job.
Honestly, that's way too trivial to call "can code". I usually ask something less trivial, yet still extremely easy like "a function to check if a string is a palindrome" (I explain what a palindrome is) or "check if a substring exists in a given string".
You wouldn't believe how many people "with 10 years experience" just lose all motor function in their hands and mouth, even without any time pressure.
Coding in the large is project management and could be tested by a take home, but I'd rather tease it out by asking in person questions about organization, prioritization, and technology choice.
Throughout my career, I've been in professional situations where I was under a lot of pressure: Having to explain failures to executives, near-impossibly tight deadlines, production outages. At least I haven't had to testify in front of Congress yet. Absolutely NOTHING I've encountered in my professional day-to-day has the extreme level of pressure of a typical silicon valley job interview.
Because if I hire that person, they'll be in charge of critical production systems and will face much harder problems in much more stressful situations and if they can't handle the palindrome question, I have very little confidence they can handle the actual job.
Not claiming to be that hero, but I have personally had those moments where I came out of the interview, and as the disorienting fog of pressure lifted during my drive home I said to myself, "WTF happened to my brain in there? I know that stuff cold!"
EDIT: I think I read this one from a commenter here, but it's so true: We're interviewing people to be music composers, but judging them by their ability to be performance artists.
(i.e. bring out groovy, using bash, etc)
Is it reasonable to ask things like that? Maybe, maybe not.
But as stressful as an interview is, it's still a basic problem (I can English describe it to you in 30 seconds...coding (in C/C++) would take me another 5-8 minutes (and, probably, be pretty damn inefficient ... but it's still a simple problem)
Checking substring in a string is a 1 liner in languages like python.
I was at a final interview with FAANG. One question asked was to load a csv. I used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a
with open() as f: do_some_shit
and kept pushing me to write this on the board. I looked at him and said "Why? Why write your own method in a vanilla language? Give me a good reason."
That's like answering "how often do you need math?" to the question "what is 2+3?". It is an utterly, completely, stunningly trivial question that even a CS101 student on their first semester should be able to answer.
> used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a with open() as f: do_some_shit
I would be perfectly fine with the pandas answer, but my point is "csv parsing" wouldn't be my first question, I'd start with something much easier and if you managed that, I'd gladly accept pandas as a valid and then asked you to elaborate further (what does this pandas function do, how would you implement it yourself etc).
What are the downsides to using pandas? Is that worth brining in that large of a library for a matter like that.
They can't ask you a complicated problem, because they don't have the time (nor do you) to solve a real problem that requires coding.
You are totally missing the point of what they are trying to ask you if you insist on using pandas for parsing CSV. Understanding the point of what you are being asked to do is critical to being a professional software developer.
I’ll take someone who gives an idiomatic answer over someone who reinvents the wheel anyday. Who is likely to be more productive on the job?
They can definitely ask a complicated problem. On-sites are 4 hours long these days.
The ability to understand the underlying need behind a request is important to being a good employee. If a candidate fails completely to understand the purpose of a question during an interview, and in fact continues to argue against you as you explain it, they aren't a good candidate at all.
I agree with everything you've said, but that still makes it a bad and equally obtuse question. If they don't actually need a CSV parser, they don't need to know that you can parse CSVs, either (if you can - which is the other point - you might be a pretty good programmer if you can quickly parse a CSV, but there are tons of excellent programmers who can't).
And that was when I found out parsing something that should be as stupid simple as CSV file can actually be pretty complicated.
I understood the "purpose" of the question and I self-selected myself out of a role I would've been bored, micromanaged at, and probably not challenged at.
Overgeneralized at best, LOLworthy at worst. Does this include palindrome questions for Ruby that require the use of linked lists? Because I had that from a CTO of a couple-hundred person company not two months ago.
I think to some degree, a suspension of disbelief is reasonable for an interview, and it's not worthwhile to get tunnel vision on a particular problem asked. It's ok to point out that something is trivial with a particular widely used library or whatever, but if it is asked to implement something via first principles or whatever, it is a perfectly reasonable expectation to just do it for interview purposes as a simple mental exercise.
There's a few things going on here. First, there's a frustration from the interviewer who is obviously looking for the cookie-cutter answer to move things along. Second, there's a culture misalignment because they are looking for cookie cutters to do the job while I am not that. Third, they, along with OP, are obviously not a palindrome company nor a load-everything-to-lists company yet this is what they're testing. So again, culture misalignment.
At the end of the day, you are right, I self-selected myself out because I would not be happy at a place like such who are looking for cookie-cutter employees.
That you couldn't yield on such a trivial, manufactured matter would make me wonder how you respond in a team environment on real matters in the face of adversity.
One of my go-to questions is "sort this array", and if the candidate types `Arrays.sort(input)` they get bonus points, because it shows they have useful knowledge of the language they'll be writing in.
> I took my sunglasses off, looked him dead in the eye,
> and said "Why? Why write your own method in
> a vanilla language? Give me a good reason."
It's a synthetic interview question. Why does it suddenly need to be a production-ready CSV parser?
We don't have enough information to say whether these are bad interview questions, and it's really not the point.
Maybe the interviewer just wanted to see if you'd use good fd hygiene (`with open('file.txt') as f:`) and that you can stub out some toy parser code and speak of it intelligently. And that you wouldn't throw a fit when asked to write some code that a library like `npm install fizzbuzz` can already solve.
Creating a dependency to a library is not benign. Even if the library is easily available and mature doesn't mean that everyone has it, or that it will never change. Remember how "leftpad" broke npm?
Having that smug attitude towards the recruiter, assuming he is an experienced developers himself, should rise a red flag. Yes, sometimes projects have constraints (like "no pandas") that may seem stupid, and sometimes they are. But it is first important to understand the context.
So instead of asking "give me a good reason?" to the recruiter, give the reasons yourself. Invent a scenario where you actually need to rewrite that csv parser, bonus points if it is related to the company's business, and finally, write the damn code the recruiter wants you to write.
In my case about a decade ago, I became obstinate when given one of those silly math-trivia-puzzle problems like how many ping pong balls will fill an elevator or how long is a string. This was for a relatively senior track FAANG interview, where my background at the time was in HPC, distributed systems, and provisioning systems that were precursors to today's IaaS bread and butter. In my case, the interviewer was adamant that I derive some figures that depended on basic geometry and knowing the diameter of the earth and ratios of landmass to ocean surface. But, he wanted me to first SWAG these figures, after I told him I wasn't a geospatial geek and didn't memorize such facts.
I decided to be difficult. If I were somehow faced with such a task, I would first consult reference materials and even see if I could find the actual answer he wanted, since it sounded only one step removed from what you could find in the CIA World Fact Book or similar. Only if that failed, would I dig up source facts and try to derive an answer. I would focus on getting the answer, not on entertaining myself with a Martin Gardner puzzle at my employer's expense and risk. I would never have to make seat of the pants estimates and act on them rather than doing due diligence. I'd either have done homework, or if there was really no time (like some system availability crisis, if we pretend I was an ops person), I'd choose a pre-planned contingency action to make time.
They didn't go forward with an offer, and I felt a bit of relief at that.
I asked "Do you want me to do the simple thing, and use a library, or write code to do this?"
They preferred the latter. So I did.
As happy as it might make you to be snarky for the often silly questions you are asked, people are, if they are smart about it, looking to see your thought processes.
I recently got a question that I didn't know how to answer, so I started thinking through it aloud. I think they liked it, because they engaged with me during the process. Redirected my thought processes.
Again, good companies will do that. Look for every question, no matter how silly, as a way to show how you deal with situations, even ones you may not like. These are the moments for you to shine.
And after you get home, tell your SO/friends/etc. how wacky they are.
Can your pandas library handle that?
Your response is to flip the table and leave? If so, then good riddance.
const isPalindrome(str) { return str === str.split('').reverse().join(''); }
And the post interview notes said bad performance on the isPalindrome() question since I didn't write out my own functions (interviewer did not mention to).
The interviewer probably should have probed you about performance though if their intention was to judge you on that (they're both O(n) time complexity, but split, reverse, and join are generally more intensive).
Id say that close to 0 out off 10 engineers at work including me would get a working program without debugger or print statements.
Just tried in c and got me 2 compiles to get it right. Without the output I would just present a nonworking program.
"Write a function that counts the number of vowels in a string"
Candidates are allowed to run it multiple times and just have to produce a correct result within 10 minutes. It's not a trick question -- the test case in place makes sure you pay attention to case.
Success rate for mid to senior devs? Only 60%.
Took me less than 10 seconds to come up with an approach that would work oh just though of a more efficient one but that would use a regex :-)
"Write a function that reverses the words in a (string) sentence"
i.e. (x) => x.split(' ').reverse().join(' ');
The fastest way to reverse a string is in JS is:
function reverse(s) {
var o = [];
for (var i = 0, len = s.length; i <= len; i++)
o.push(s.charAt(len - i));
return o.join('');
} return inputString.Count( "eaoiuAIEOU".Contains );
static Regex VowelMatcher = new Regex( "[aeiou]",
RegexOptions.Compiled | RegexOptions.IgnoreCase );
...
return VowelMatcher.Matches( inputString ).Count;
return 2; // number of vowels in "a string" def vc(s):
return len([c for c in s if c in ['a','e','i','o','u']])I've run into this issue in different specific ways earlier in my career and no matter what I'd say about skill level / lack of knowing required technologies / being willing to take lower pay in order to justify aiming for another role it didn't matter in the face of the possibility that the recruiter could obtain a larger % for themselves off of that senior / higher-than-in-my-range job's salary.
Maybe this isn't as applicable for senior dev role applicants as it is for some lower level dev roles but at the point an applicant is actually physically there in front of the interviewers I'm sure one of the last things they are going to want to admit is that they wished they were interviewing for a lower paying / easier job even if it's 110% in the favor of both parties.
I've tried working with them before, have gone on job interviews through them, and then generally found that the jobs that hire through recruiters pay peanuts, and I end up finding a permanent job paying much more and taking that instead. I think if a company only works through 3rd-party recruiters, that means the company has no idea how to hire people, and doesn't want to pay much either (because they're paying the recruiter a huge commission).
Not to mention most of the one's I worked with early in their career not only had no idea about any of the technologies they were checking to see if I was fluent in but they also acted like they DID know everything about programming and beyond that they tried to flaunt this fact and treat me like I was trying to overstate my skills to sneak my way into a job out of my pay range.
Such a frustrating ecosystem in order to find a career job.
In ten years I can count on 1 hand how many times I've gotten a reply from a non-recruiter job I applied for (applied on my own without a staffing agency submitting / representing me).
It's really crazy how that works.
Another thing I dealt with was people who hired me saying (TO MY FACE):
In this situation I'm making $35.00/hr as a Regular Developer (non-junior / non-senior dev, just a middle of the road contract developer):
CEO of company in front of everyone: "scoggs we are paying way more for you than we are for our senior developers so we are expecting top notch work from you."
Me (used to it by now, unfazed but I hate this situation): "Sir with all respect I'm only getting less than 1/2 of what you pay my staffing agency for my contract/"
CEO: "well they don't really do anything / didn't really do anything but introduce us and get you a phone and in person interview with us."
Me: "But you guys didn't have to pull programmers, HR, and design / copy writing people off of their normal work to create interview materal, submit interview material, review resumes, vet candidates, plan phone interviews and schedule them, set aside time for phone interviews, review phone interview candidates among 'hiring team', review candidates references, plan in person interviews and schedule them, execute in person interviews and have meetings with 'hiring team' to pick who to hire', make offers to people you want to hire, or hire them. All you had to do was tell the staffing agency what skills your were looking for and what kind of company you were. I'm not an employee of your company. I don't have insurance, I don't get paid for sick days, I don't get paid for holidays, and I have no job security."
Of course I didn't say all of this, I said something along the lines of "They take care of the majority of the process" but in my head I feel like I'm always having to live up to the expectations of the people paying the total bill. The same way they think the staffing agency doesn't do any real work and isn't worth the cost / price of doing business -- most of these people feel the same way about developers. They don't understand what we do, they just expect us to solve anything and everything to do with computers / programming / technology and this is ALWAYS the way it is regardless if the final product / project outcome is directly tied to the company suddenly turning a profit based on the success of this project / programming endeavor.
These companies want to underpay contract developers, pile stress on their shoulders, guilt them for the situation they have little to no control over, and then stick them with the majority of the blame if things don't go 200% well (because they are expecting work that's 2x as good as the amount of money I'm being paid).
I've found it impossible to truly and personally (mentally) live up to the majority of expectations laid upon my shoulders by non-technical CEO's / Presidents / Bosses of companies I've worked for.
This is the majority of what I deal with right outside of NYC in Northern New Jersey. There is the rare company that truly respects the programmers they hire (usually companies where programmers have become CEOs / Presidents / people in powerful positions within the company who wield influence).
I love the money I make in this market but I truly hate the way everything makes me feel even when the situation is like this yet I am able to deliver above and beyond expectations. I hate working for people and in situations where it feels like I'm being told I'm robbing the company when meanwhile the recruiter is robbing us both yet they have us pitted against one another -- and beyond that the staffing agency has a 2 year lock on me being able to accept a job from that company without them "buying out" my contract.
The cost of buying out a contract? A university wanted to do that once early in my career (I wish I was still working there frankly, 10 years later), but the staffing agency wanted 2x the amount the university was paying the staffing agency! I was making $60,000/yr at that point so on top of the University paying me somewhere in the realm of $60,000/yr they would have also had to pay the staffing agency ~$240,000 just for the right to hire me. That means they would have had to shell out $300,000 total including my salary and the buyout.
Nothing about that seems right and / or legal. Under no circumstances would I ever be worth that much to the staffing agency and honestly with the amount of work they actually do I feel like it's damn near criminal.
No State University that pays employees with citizen's tax money is ever going to be able to justify spending that type of money on 1 employee. It's just a fantasy of epic proportions.
Anyway, you make it sound like you can't get a job there without a recruiter. There's still plenty of companies hiring directly, I even interviewed at a few when I was there such as Alcatel at Bell Labs and some wifi company in Manhattan. My current gig is with a large company (in the DC area) that hired me directly. Stop wasting time with recruiters and just look for companies that do their own recruiting; there's no shortage out there that I've seen. I've had 8 jobs now that were not contracts and not through recruiters: 3 large corporations, 3 small companies, 1 mid-size, and one a state university research division. Am I apparently special that I'm able to find these jobs?
Personally, my first-line screen is a short answer (3-5 sentences) to a programming-related question. [1] For me, about 90% of applicants who pass that can also code. I like that better than a resume screen, as plenty of people who haven't officially been programmers are decent coders.
[1] Examples here under the "Join Us" section. https://web.archive.org/web/20151005181908/http://www.codefo...
Our standard fizzbuzz question was something like: print the multiplication table. This is a loop inside a loop. I think every programmer should be able to do this given 10-20 minutes. Around 30%-40% couldn't. Like literally, didn't know how to do this in languages they supposedly work in. I'm sorry, I make lots of allowances for stress, I calm candidates, I tell them syntax doesn't matter, do it in pseoudo-code for all I care. But if after 10 minutes you can't print a multiplication table on the screen, I'm going to pass.
I'm not saying that All Coding Tests Are Good, but they do provide a modicum of certainty in a very uncertain environment.
Then misconstruing poor performance as coding ability.
if (~false == true) std::cout << "true"; else std::cout << "false";
In C++, what does this print? And if they answered correctly, I'd ask them to explain how/why. This question wasn't a deal breaker, but did immediately given an insight into their depth of knowledge of the language.
What does it all mean? It means exactly what it meant in a high school/college group assignments - one or two people carried the group project but everyone took credit.
I have seen hundreds of resumes where people claimed that they have done XYZ where through some side channels I know they just happened to be on that team but their contribution was limited to tweaking spelling.
I see coding tests as one of the two ways to evaluate that someone can code[1]. I trust it.
[1] The other way is that I know this person and I'm already aware what they can do.
Unless you meant “lead software engineering role” in which case yes, you are right.