> 99% of my candidates can code, as in iterate over collections, write case statements, and call functions.
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.
Problem is: It's hard to judge the difference between someone who doesn't know what they are doing and someone who does but loses it under the extreme pressure of an interview wherein their entire future with the company is being determined by their performance on a 30 minute exercise.
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.
I understand and truly symphatize with stress the candidate is in, but someone who claims to be a "senior developer with 10 years experience" should be able to write that palindrome function in 30 whole minutes in any kind of stress scenario.
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.
People are strange. I can totally picture someone who is an experienced senior, a hero under the pressure of a critical production outage, yet whose brain goes into a crash loop when sitting across from someone who has the power to deny them their dream 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.
Fair enough. I certainly don't claim to know the best interview method ever; simply that, in my experience, starting with trivial coding questions has a higher benefit/risk ratio then other approaches.
I don't agree. They should be able to write that as a solution to resolve an issue. It should be very well understood why they're writing it. Additionally, if you want to keep going under that justification: you should also accept quick alternatives that aren't the naive approach.
While I agree in the abstract ...honestly, it's not that hard to write at least pseudocode for problems like that regardless of the "stress" of an interview
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)
It's way more expensive to hire a bad fit than to pass on a good fit. Also, I think I'd prefer the person who doesn't crack under pressure. Flopping an interview is more likely an indicator of lack of preparation than nerves, although nerves are such an easy scapegoat.
Not sure with the amount of sloppy code I have been maintaining for the last couple of jobs.The people appear to be able to do "clever" stuff, but have an inability to keep things simple or follow best practices.
How often do you need to write palindrome functions for your job?
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."
So what is the interviewer supposed to do to find out if you can code? They want to give you a simple, straightforward task to see how you code. Of course, every simple, straightforward task is going to have an existing tool to do the job, but they aren't looking for a solution to parsing CSV, they are looking to see you code.
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 think that is the point. If your business relies on importing csvs that cannot be imported with pandas then explain that, explain the edge cases where pandas has failed, and I will understand. If your business relies on having the best fucking palindrome product then that becomes super relevant.
They can definitely ask a complicated problem. On-sites are 4 hours long these days.
You sound like somebody who would derail all of the technical discussions and pat himself on the back for it because he was "technically correct" while still missing the point altogether.
I hear the opposite. They are stressing a technical opinion here, but for the sake of rationality and efficiency. These are usually not the same people that are overly concerned with "correctness" when communicating with others.
But it is only 'rational and efficient' if you are being obtuse... they aren't asking you to code a CSV parser because they actually need a CSV parser, they are asking because they want to see you code. The 'rational' thing to do is satisfy THAT requirement, which is the real one, not try to bypass the purpose by insisting on using a CSV library.
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.
> 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).
I recently couldn't use a built-in CSV parser and had to roll my own because one of our clients couldn't be arsed to send us consistently formatted CSV files so we had to include a bunch of edge cases in there to still correctly format the damn things. (sometimes pipe-delimited, other times comma delimited, sometimes fields surrounded by quotes, other times no quotes except one column (that has a LASTNAME, FIRSTNAME" in it), yet still other times has quotes in the data itself, fields usually have no commas, but sometimes this one field will have it in the middle of it, typos in header names, not including the end of file checksum that others include, etc). The built-in CSV reader you had to specify if the fields had surrounding quotes or not for the entire document, it didn't detect it on its own, for example.
And that was when I found out parsing something that should be as stupid simple as CSV file can actually be pretty complicated.
I'll argue that a one-liner IS code. That's what I put into production systems.
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.
The question on the interview isn't about the business, it is about showing your ability to design an algorithm. I is an exercise, not a purpose driven task.
Let's be honest: most commercial programming jobs don't. And the person with a thorough working knowledge of the standard libraries is in a better position to do it anyway.
They want to give you a simple, straightforward task to see how you code.
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.
> How often do you need to write palindrome functions for your job?
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).
I don't consider palindromes equivalent to math. Unless you mean how to index lists? That would be a valid question since there's different ways in python.
Your refusal exposed you as someone with a hubris that's hard to work with. Who doubles down and refuses to budge.
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.
CSV is really fucking hard to parse. There's tons of edge cases. "I'd just use a well-known, well-tested library" is a very valid answer.
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.
Here's how their scenario would actually play out:
> 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."
Interviewer: "To see how you might approach it."
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.
That's a bit unfair. I agree that Array.sort is the best answer, but array sorting is such a classic interview puzzle that most candidates will expect that that's what you want. So instead of the bonus answer, they'll slog away trying to remember the algorithms that they learnt at uni years ago (or codecademy last month).
When I see someone doing something wrong or poorly I speak up and I speak out. Loading csv using vanilla python is in that boat. Present a good reason why it should be done in vanilla. Otherwise, I won't maintain your code as-is and will refactor it.
At least you were given a programming problem. I would have played along a little bit and at least discussed how the layers work. Instead of pandas, use the csv module so he could see a loop iterating over header and data rows as tuples. If he pushed further, outline how you might code the csv reader yourself if it didn't exist. Move the discussion into the difficulties of correctly handling a file format like csv and real-world issues like malformed inputs, validation, and error-handling.
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 got this CSV question at some nameless large company in the bay area.
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.
That seems like a fairly arrogant response on your part - it's obvious that an interview is meant to gauge your technical capabilities/knowledge. Even if something is trivialized, the ability to solve certain types of problems can translate to other problem domains where you have to use the same core skills to solve other problems - parsing a file does not seem like an other worldly type of skill (it could even be an unstructured/loosely structured text file for example).
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.
I respect your view but disagree. I use pandas everyday for my job. I use spark. I use keras. I use scikit. I use all these APIs everyday for my job. I can't think of the last time I loaded a file using vanilla python. If it's a requirement for the job (which it wasn't, they showed me pandas code later) then I completely understand and would not be qualified nor would I want the job.
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.
Why write your own method? Because it is sometimes better to write 10 lines of your own code rather than pull an entire library for some trivial task.
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.
I don't agree with this reasoning. Perhaps the details are important. The task required loading, filtering, and aggregating a csv. Sure, if all do is "load" a csv perhaps you don't need to import a huge library. But if you want to do anything with that data I'm sure the library becomes very useful :)
Ah. Did I not mention that these CSV files I wanted you to parse... they're generated by an old mainframe system we can't modify the sourcecode to. It does have a few idiosyncracies - for fields like addresses which can contain commas, it uses a special escape sequence where the field just consists of three asterisks, then the value for that field is the content of the next line. Oh, and it uses just CR characters for linebreaks. In EBCDIC.
So presumably the mainframe has code that can parse these non standard files? Just take that code and build "on the mainframe" a tool that converts their non standard csv to something more usable.
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).
Personally, if you gave me this answer I would accept it and then asked you how those functions work and how you would implement them. Still trivial, but it would tell me whether you are familiar with the basics or you just memorized some stdlib functions.
To be fair, if you wanted to do a performant implementation, this is probably a more expensive implementation. The expected response is generally for you to iterate over the string and construct a count map of how many times a character appears in a string, and then iterate over the keys of that object and have at most one odd number in the values of the count map.
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).
Err I always thought that the expected performant response is to have two indexes 0 and length-1 and bring them to the middle checking that the values are equal :)
I'm very confused by this answer. Have I missed a joke? Wouldn't the expected response be to iterate over half the string comparing the characters to the other half (in reverse order)? The criteria you provide seems to suggest aabbc is a palindrome.
The function to check palindrome will be composed of those building blocks, that's my meaning. Use those basic skills and composing them to solve a problem, such as palindrome, that's coding in the small to me.
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.
Maybe it's just me, but needing an entire IDE or a debugger to write a function that checks if a string is the same backwards seems entirely too much to me. It's a pen&paper question really.
It's not just you. I use Visual Studio when I'm occasionally looking at C#, IntelliJ on the odd occasion that I'm doing Java, and otherwise it's emacs and I can't remember the last time I used a debugger for Go, Elixir, C, C++, JS, Python, Ruby, etc. Basically, unless the language's standard library is massive and over-abstracted, no IDE is necessary. There's no way I'll ever remember org.apache.some.deep.package.HttpClientBuilderFactory and its 6 constructor arguments, but "import requests; requests.get(...)" is pretty easy to write without an IDE.
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.