I am constantly interviewing candidates for roles at my company. It seems like CVs are a complete gamble. Either some are lies, or wildy understated, and everything in between -- at all levels of experience! "[J]ust to prove..." and yet so many can not do the 2022 version of FizzBuzz. I am stunned how many senior (well, so they say!) hands-on technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works. For get about explaining the finer points of sorting algorithms (honestly, very low value in my line of work).
There is no reasonable alternative to testing of some kind for hands-on techincal roles -- I am flexible about method: (1) white board coding (ugh in 2022), (2) IDE/text editor on shared PC / video chat (meh / eh in 2022), or (3) take home (the best in 2022, even if there are drawbacks for people with families).
Joel Spolsky said it best about hiring: The goal is to avoid bad hires. Average and above are fine.
I've been in software development for 15 years and being able to explain either of these things has never come up and I probably wouldn't be able to give a decent answer without reviewing the topics specifically.
I would expect most people I hire to be able to explain how a hash map works.
I'd care more about an applicant understanding the concept of a hash; or hashing in general. If an applicant shows that he understands that a hash is a magical and fascinating mathematical concept; and it can have uses in Information/Computers, that would be more interesting (to me) than someone who memorized a hash map definition.
He can always learn about a particular application of hashing (hash map, for example). But the latter shows aptitude and capacity to learn these later on the job.
Because a hash map is:
1) a pretty basic concept in data structures
2) Variations on hash maps are used all the time in the real world. If you use objects in javascript, dictionaries in python, or maps in C++, then you are using things that essentially implement hash maps.
Point number 1 is like if I went to an orthopedic surgeon and they couldn't tell me what the liver does. You can say "well the liver has nothing to do with my finger that got smashed in a car crash, so what do I care." Or you can say, "that seems like a red flag. Maybe I'd be safer choosing a different doctor."
* Note: I have no idea how often the liver comes up in orthopedic finger surgery and for all I know it's a lot. But I think you get the point.
Yes, you use them. You don't build them. To torture your analogy it's like asking the surgeon to explain how their bone saw works. Why should they know? All they care is that it cuts bone.
Analogies aside, hashmaps (in one implementation or another), arrays, vectors/lists, strings and arguably sets are very very common data structures in most modern languages. I don’t expect someone to be able to build a hashmap from scratch but I do expect an experienced engineer to have some basic idea of the pieces that go into building it as well as it’s properties (not necessarily ordered, O(1)ish sets/gets, collisions, etc). Knowing this kind of thing helps you understand when to use an object in JavaScript vs a map. Or how dictionaries differ between python 2 and 3. If you understand the underlying data structure, then you know what questions to ask.
* in python 2, a dictionary’s keys are not guaranteed to have consistent order. In more recent versions of python 3, they ARE guaranteed to have consistent ordering. This has ramifications for the code you write, and it’s especially confusing if you don’t understand hashmaps because 99% of the time, the order will be maintained in python 2 even though it isn’t guaranteed. But relying on things that are true most of the time is a very bad way to write production code :)
Yeah, I'd say this is all in knowing how to use a hash. How to build one would go into the underlying data structure.
Although I would probably ask them to specify the level of detail they want before trying to comply, and then not get the job because I ask a lot of unnecessary questions or something.
an in-depth definition would be that, followed by how you implement a hash map (thus if your language of choice already has a hash map, don't use that but show us how you would implement this classic data structure), how do you avoid collisions, maybe discuss some various ways that you could implement it and what the tradeoffs are. This would be you 'understand!!' what a hashmap is, like deeply. (I hope my tone makes clear I do not advocate for this)
on edit: I think it seems you might actually be advocating for this deep definition? If so, probably you are working at relatively low level?
on edit 2: for example if you were using Python you might say a hash map is a dict, and talk about how to use dict, the in-depth definition would not allow this. Which I think is what the other posters were worried about, being asked not to use your language's implementation of the concept but go lower and show you can make the whole thing.
I work as an ML engineer, so very high level.
If you ask for the in-depth understanding for positions that would never need it, it follows that you will be disadvantaging many applicants who might be great for the position and advantaging applicants who know at least one non-relevant thing.
Oh I wasn't trying to say that this knowledge was valuable or not. I was just pointing out that you seem surprised that experienced people wouldn't be able to provide a good answer to that question. And the answer is that in many jobs, its not useful knowledge.
What has burned me, however, cannot be tested adequately in an interview. Bad attitude and laziness. Anyone can behave well in interviews, so we've hired a few people who turned out to have a passive aggressive streak or condescending attitude that interferes with the rest of the team. We've also hired people who are really great developers ... when they work. But they're really lazy and getting them interested enough to do the work is the hard part.
Hiring is hard. I doubt I need to tell you that. There is a reason we gravitate towards hiring people we've worked with in the past, or come recommended by someone we trust.
If you can point me to extensive open-source experience on projects that roughly approximate professional coding, then fine, I'd be happy to walk through your code with you instead of doing an algorithmic problem. The issue is that that's a minority of developers... most people don't have the time or desire to do extensive open-source work outside of work hours and I don't blame them for it [2]! But given that resumes are unreliable, I need to test you somehow.
[1] No, I don't ever have to reverse strings at work. But I do have to write efficient code. And if you can't conceptualize how to reverse a string then you probably won't stand a chance at more difficult algorithmic issues I often come across.
[2] I don't recall who it was, but I once heard a very well-regarded chef say that he's tired after work and so he doesn't like to cook much at home. I have zero problem with a developer doing the same with coding! Go home and work on a hobby, spend time with your family, or smoke pot and watch netflix... I care about what you are capable of at work, not what you do with your free time.
In my experience people know these things, they just don't realize that what they're doing can be described generically.
An example: If you're in an iOS interview and ask the person to describe a graph, they will get very angry and complain that this is useless knowledge and they don't need it to get the job. But if you ask the same person to describe an UIView hierarchy, they often have no problem doing so. So they _know_ what a graph is, they just didn't know it had that name.
With that in mind, my tests shows that generic algorithm questions suck and questions themed around actual features of the product are the best. If you word the question in a way that feels relevant and is familiar to developers, they will be more likely to know the answer even if deep down the solution is exactly the same as the generic ones.
The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.
I interview many candidates at FAANG, I can easily tell the ones that have prep by just doing leetcode and the ones that knows the shit.
I couldn't care less if you can solve all kinds of complex dynamic programming challenges.
I ask coding questions that you won't find in leetcode and requires problem solving skill and good craft.
And this is because I do like working with smart people and not with people good at memorizing patterns.
I think it is easier to know the shit to do LC interviews than somehow memorizing the question bank. I haven't seen many people succeed who were unskilled but managed to just memorize the questions.
I think LC style interview have ruined the interview process in the tech industry.
Note: I do ask candidates to code during the interview, but I ask things that are related to real problem, some of which, I had to solve in my day-to-day.
In addition, I put a lot of emphasis on how well they articulate their thought process, and the quality of their craft.
Also, I would not discount `past experience talk` that easily. Actually I use that to drill down in their resume to better understand their real contribution. More often than not, people just lie. They are very easy to spot. At that point is game over. I don't care if you nailed the coding. If you lie and oversell yourself you are done.
Another thing that I find very annoying is that very often interview are conducted by junior engineer, and they don't have imo the maturity and experience to properly assess candidate skills and potential. You either do well according to what their expected solution is, or you are out.
Interviewing is not just a binary process coding well yes/not. It is a little more involved.
I passed candidates that did not do well on coding, but I was convinced they had potential. Whereas I did not pass candidate that did very well on coding, but did not show any interest or passion at all.
You put the bar wherever you want. A company can decide to set it lower than what you would expect or like, but it could still make business sense, e.g. if 99%+ of hires still perform well with this bar and the company would like to hire faster.
This is related to:
> and barely get anything done. Plus the quality of their work (generally speaking) is very low
That's a problem of the performance review process. If everybody considers that someone is not delivering, that could be for multiple reasons, and even with a very high hiring bar that could still happen, so you can't rely solely on interviews.
If you don't have a good performance review process, you'll end up with worse hiring because you can't measure the impact of your changes.
> I passed candidates that did not do well on coding, but I was convinced they had potential. Whereas I did not pass candidate that did very well on coding, but did not show any interest or passion at all.
Can you do that objectively? It's very easy to introduce bias if you try to evaluate whether candidates show passion.
It’s good you like that I suppose, but it sounds absolutely bonkers to me.
The mold being answering questions about their supposed area of expertise.
I think people really like to claim that they are misunderstood geniuses who just don't fit the mold of being able to answer questions about the things they know. I have no doubt that such people exist, but I would not want to scrap an evaluation system simply because it doesn't catch every possible person, more important to me is keeping bad people out.
you seem very confident about that. In my experience LC/FAANG style interview don't keep bad people out.
But I have never encountered a company that doesn't have a on-the-spot technical interview (involving coding or math) that has had more success keeping bad engineers out than FAANG.
I am arguing that LC/FAANG interview does not do a better job at filtering them out.
The solution: accept that you will do bad hiring, but that you will let them go as well.
Instead, everyone want to be politically correct and the play safe. So people are hardly let go.
Also working at FAANG implying you are a stellar swe is a big time BS.
it's fascinating how these playbooks can recycle themselves in any number of scenarios. yes, conditioning on being an engineer at FAANG you are much more likely to get a better engineer, I'm not going to apologize for saying the truth.
e: not going to keep replying, I seem to recall getting in previous fruitless arguments with you when you suggested banning renting was the way out of California's housing crisis.
You're talking of gigantic tech companies that actually have a business interest in getting that right and you just assume that haven't done any studies about that. If you want to argue they're wrong, fine, but the money is against you on this, so more proof and arguments would be welcome.
I think we all agree that no interview process is perfect, but you're basically claiming that they're all equally bad.
It depends on the job. I have had interviews that broke the mold here and were panel discussions or more job-talk experience, and I found the interviews uniquely exhausting because they required their own set of skills to study for that were different from the “leet code” style. At the extreme end were the take home projects, which I simply didn’t have time to do for every company and were extremely unattractive to me for that reason. I actually find doing leetcode style interviews for me required the least amount of prep and was the most straightforward, especially when they were structured to leave me with time to ask and talk to real engineers at the company.