This was my take on interviewing with Amazon at one point a long while ago.
The initial interview itself was pretty straight forward, but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts. We talked about hashing, and when he asked if I knew what hashing was I said sure, its a one-way function to create a unique identifier. He asked me to elaborate, so I sorta... talked more? I remember feeling confused because I'm not sure what else he wanted me to say. Eventually he ended the question, said he was looking for me to say hashing is for "fingerprinting"
We moved on, he asked me for an example of a hash function. I said md5 or sha. He pressed further, asked about collisions and eventually cut off the line of questioning telling me he was looking for an example like the modulus function. Questioning lead further to reaching into linked-lists and the like.
Having never sat through this kind of interview I was left with a really salty taste for the process. If any they were looking for was me to rattle off some pre-determined key words then what good is the interview for? I incorrectly assumed he was gauging my familiarity with the subject rather than repeating my 2nd year university coarse which introduced shit like data structures and algorithms.
His smugness in the way he concluded each topic was just a giant turn off of ever seeking further work with companies like Amazon (giant & highly competitive software conglomerates). I feel like everyone is trying to one up or appear to be king shit in some way, it left a bad taste. (For the record, I did a couple interviews of this style before totally writing the experience off. Others were better, but this experience always stuck with me)
One time an interviewer asked me "how would you go about counting the ridges of a US quarter?"
I rattled off some ideas about counting the ridges in an arc and then multiplying to get total ridges but the interviewer kept prodding and eventually ended the question and said he was looking for me to say "google it" (I didn't realize it was a known, fixed number).
I just rolled my eyes and laughed and said "Huh, good one, but how would you go about counting the ridges of a foreign coin assuming it's freshly minted and the number of ridges is unknown?" The interviewer shifted uncomfortably and just said "yeah, I'd probably do something like what you said - count the ridges in an arc and multiply..."
(i.e. "if you are going to give me bogus lateral thinking puzzles to test my competence I'm going to fire them back to see how you handle them")
I had a similar experience with Amazon many years ago but my takeaway was "don't work at Amazon" not "don't do technical interviews". I've had great technical interviews (Google, Square) and terrible ones (Amazon, Stripe). Companies you want to work for are cognizant of this and spend time developing their process and training their interviewers to make sure their experience is one of the good ones.
Sounds like my Google interview. By the end I had absolutely no interest in working there. Such a toxic environment. The guy they had take me to lunch also seemed completely miserable.
Dunno if that was representative of Google or big companies in general but it turned me off forever.
> but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts.
This is also one indication that the person is an inexperienced interviewer and their whole line of questioning is focused on tripping up the candidate into making mistakes. A good interviewer thinks along with you, helps you and is fairly satisfied if you articulate a concept "well enough".
> His smugness in the way he concluded each topic was just a giant turn off of ever seeking further work with companies like Amazon (giant & highly competitive software conglomerates). I feel like everyone is trying to one up or appear to be king shit in some way, it left a bad taste. (For the record, I did a couple interviews of this style before totally writing the experience off. Others were better, but this experience always stuck with me)
Well this is the typical behavior towards those who cannot interview properly and has to introduce pedantic point scoring to bring people down. It would take an experience of resentment, denial or some sort of impactful rejection from the interviewer to be at the point to certainly enjoy this ego trip as an interviewer at somewhere like Amazon.
Now it seems everyone and the whole tech industry thinks they're Amazon, Microsoft or Google by asking about implementing efficient algorithms, libraries or the like yet they continue to use the slowest languages, spinning up multiple VMs or clusters at higher runtime costs and choosing Electron for software development. Unless they are also contributing to writing a production grade compiler or systems software, companies who ask these data structures and algorithms questions are doing it simply 'because of reasons'.
> The initial interview itself was pretty straight forward, but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts.
One thing that shocked me in discussions is that apparently interviewing incoming candidates at FAANGs has now become a mandatory performance review objective.
This is going to produce a lot of interviewers who really don't know what they are doing and don't care.
I don't know what idiot came up with this brain-damaged scheme to totally sabotage interviewing and what moron actually propagated it between companies, but I hope they die a horrible, slow, painful death.
Had the exact same experience interviewing for Amazon way back in 2005. I was still in college, and the answer he was looking for involved some obscure Linux/Unix command. I really felt defeated and thought “well I guess I’m just not enough of a hard core coder.” I still remember his smug attitude as well. Looking back it seems ridiculous, deciding a college student was not fit for a software engineer position because he didn’t know an obscure Linux command off-hand? Bizarre. But I guess back in 2005 there was much less demand for software engineers so they could afford to be absurdly selective.
> We talked about hashing, and when he asked if I knew what hashing was I said sure, its a one-way function to create a unique identifier. He asked me to elaborate, so I sorta... talked more?
I had a similar experience at Apple where my experience lined up well with the position. I felt like the interviewers were hostile - repeatedly asking weirdly pointed questions about hashing too!
It's because they don't know the answer, the first round is a recruiter asking you trivia to separate you from people who know nothing, in the hope of not wasting their engineers' time.
To be honest, I don't think money is a good reason enough to tolerate that kind environment, I'd rather work in a smaller company paying less and build a small business on the side to increase your passive revenue streams.
Maybe things will change with faang going remote because of COVID (given one perk of small companies was their flexibility) but it looks like your salary at big companies will also scale according to your location, so I'm not too hopeful.
Same. Worse is when they ask open-ended design questions. Like "How would you design 1-hour shipping?" which I was asked. I've done many, many new product designs and the process is deliberately meant to take weeks. I have, in real life, been asked to design a system on a 45-minute call and my professional answer was "no". I have no idea if they're looking for brainstorm, process, architecture or my ability to question. But honestly it's not enough time for even one of those.
OK even ignoring the (in my opinion very strong) possibility this interviewer was completely ignorant of the subject matter, how do you manage to miss the connection between the word "fingerprint" in the desired answer, and the word "unique" in the actual answer?
Sorry about that bad experience. It sounds like the interviewer wasn't good at communicating.
To be fair, it also sounds like you were conflating popular hash functions like md5 with the general concept of a hashing data structure and underlying function. Knowing that modulus operation is one approach and knowing common approaches for dealing with collisions are part of that. See: https://www.geeksforgeeks.org/hashing-data-structure/
Man. I interviewed somewhere last week for a Scala position, advertising myself as a functional programmer.
In the interview, they asked me, "What's the difference between fold left and fold right?" I said "Um, one of them starts on the left side of the data structure, one of them starts on the right. I never remember which is which." They said essentially: "okay. The answer I was looking for was that fold right is not stack safe." I protested weakly, and they dug in, so I graciously let it go.
But it's patently not true. A naive implementation of fold right in Scala isn't stack safe, but the actual implementation is stack safe. It's been stack safe since like 2010. So rather than interrogating my knowledge of functional programming, they're just asking me bullshit language trivia, and dinging me when I don't come up with their arbitrary wrong answer.
I wanted to work there before that, but the interview made me a little ambivalent, and then they just ghosted me. So I guess I dodged a bullet. But man, that was frustrating.
you can often give a company a pass for a shitty interview, but you should name & out them for ghosting you as that is a far more systemic problem indicator. When I'm interviewing I want the poeple we don't hire to go away and have good things to say about us because they will tell many people about their experience. Companies that are disrespectful and inconsiderate to the point of just cutting off contact should pay the price.
Assuming the data structure is a singly linked list than yes it's not stack safe.
At a high level foldLeft and foldRight represent abstraction leakage. The Domain and Codomain for both functions are exactly the same. If there is no performance difference or side effects to consider then there is almost no point in having two fold functions as a plain fold has the exact same inputs and outputs as foldLeft or foldRight.
Typically for side effects you don't want to put it in a fold as you're integrating way too much IO with your functional computations. Rather functional languages tend to have something along the lines of "foreach" for using side effects on the content in a functor. That being said it's strange that scala has a foldLeft and a foldRight with identical performance characteristics. Maybe it's a legacy thing. I dunno, not a scala guy.
Just bringing that up. I still agree with you that the interview question sucked and that the interviewer was wrong. Personally I wouldn't have ever figured out that was what the interviewer was looking for even when I do possess the requisite knowledge.
What's happening here is more subtle. The interviewers question didn't carry enough information to get the answer they wanted.
They created a puzzle where you needed to ask for more information. Intentionally or not, they were discovering if they could communicate with you. That the communication failed doesn't mean your somehow less then them. It means you just have a different background.
Now to the problem, the problem people don't set good goals. It probably doesn't make sense to hire a carbon copy of yourself.
Huh. Other than taking the opportunity to talk about tail call elimination, I'm not sure what you could have done to salvage that interview. Bullet dodged, indeed.
I agree. We recently got rid of our more traditional "tech screen" and replaced it with a 90 minute realistic programming interview.
We have 3 tests we give depending on the role (game dev, backend, or SRE). The tests replicate typical work the engineer would be doing, such as adding functionality to a 2D game, developing out a web service for a given API, or debugging and optimizing a linux server. We provide a development environment remotely, or the engineer can use their own. They code/work on their own, without needing to share their screen, though we're on the line if they have questions or just want to chat. The interview itself takes about an hour and we schedule in buffer time before/after to setup and to debrief.
We've designed the problems to be (a) relative, (b) scalable and (c) fun. By scalable, I mean that the problem should have a simple, naive solution that most engineers who work in that space should be able to solve quickly and easily, while also having enough space for more advanced engineers to extend the problem and show off a bit.
So far we've gotten good feedback from this approach, even for candidates who haven't passed. I know 90 minutes is a long time, we but feel that with this test, we get a good, realistic work sample, and we can forgo a lot of the other less effective interviews.
"scalable" (not sure about that name) questions or scenarios are the best to gauge competency. I do them although it's pretty hard to come up with good ones.
A fallback for shorter question is to ask for a something with many possible answers, as typically somebody more experienced will have many answers besides the most popular ones. (server A can't ping server B, what can be the reasons?)
I had the strangest technical interview recently. I didn't get an offer, but in every case where that's happened before it's been obvious to me where my deficiencies lie (which I then use to improve in that area). This time I learnt nothing.
It was six individual one-to-one interviews, back to back. The first five were an ego trip for me. I was able to do everything perfectly it seems: read code, write code, talk about code. Then the sixth was this synthetic problem involving nested boxes. I figured out it was a tree problem and started writing code to build the tree. I had an approach in mind and asked the interviewer if he thought that was a good approach (given that there was only enough time for one attempt). He said no, he didn't think it would work. That completely threw me off. Later I realised me approach would have worked anyway.
I didn't get an offer, but what in the ever-loving fuck was the point of putting me through 5 technical interviews only to fail the sixth? It really felt like they were looking for that ego boost but didn't get it from me. It's hard not to sound arrogant in this situation, but I've been humbled in the past. This time I was just confused.
I'd say this happens semi consistently to me when I get rejected. I did a tech screen (of which this is the first I've ever failed). I chose to do it in Rust as that's my main language these days. I probably should've reconsidered that decision as Rust is notoriously difficult when it comes to dealing with trees and I spend most of my time managing pointers. I described a solution to the tree problem quickly, implemented it, and then dealt with the compiler for about 15 minutes. As a result I never fully finished the task, but it was pretty darn clear I knew what I was doing.
Same thing, they came back and said no and I really have a hard time imagining why other than the interviewer not being familiar with Rust - but - hey, don't tell me it's fine to use then!
That to say, rejection feedback is almost always useless.
Candidates pass the technical screens all the time but don't get offers for various reasons. Maybe there was someone else who impressed more, but there's also culture fit and personality to consider. I've rejected very very smart candidates for being arrogant or being poor listeners. A strong team needs more than technical expertise, it needs people who feel comfortable collaborating and have the safety to be wrong and learn
If the whole thing was coordinated, that’s messed up; I wonder if it was a coincidence and #6 was testing your mettle, or even just genuinely disagreed.
Of course it is, it's a way to gauge whether "someone is dedicated to the job by cramming the algorithms section they haven't touched in years"
I've done dozens of interviews and after all of it, I realized there are only four qualities we quantify as useful: caring, ability to listen, ability to learn.
> “Often, I will give them a scenario where the processes are failing the team to find what they would do to tackle inefficiencies and if they would be willing to speak up.“
While the intention here is good you are unlikely to get an accurate answer from the candidate using this method because the candidate “should” tell you what you want to hear rather than what they would do in reality. You basically want to find out how the developer delivers criticism. Do they bruise egos or are they tactful or do they simply stay silent.
A better approach is allowing a candidate to demonstrate how they offer criticism. Give them a codebase to read and make sense of and ask them to explain it to you. Ask them to to point out parts that could be better designed. You can gather a lot of information this way.
1. Can the candidate read a foreign codebase and make sense of it.
2. Can the candidate pick up business logic from the code.
3. Does the candidate offer criticism that is likely to make another developer defensive or are they more guarded with their communication and offer higher level design alternatives.
Articles like this always underestimate how many bullshit artists there are out there. The technical interview is not perfect but it is still far more meritocratic than many fields.
I'm coming to the realization that there's almost no point in spending time on a lot of the things that I love about being a developer: learning new languages, studying best practices for your tech stack, reading software engineering books, becoming involved in tech communities, keeping up with the latest trends. Interviewers don't value any of that beyond lip service. The only thing worth spending time on is leetcode grinding, it can be worth 10s of thousands of dollars.
The attitude of the algorithm geniuses is that software engineering is easy and anyone can learn it, which might be true, but my point is that I already did learn it and I spent five years becoming an expert in it. That should be valuable to your business whether you look down upon it or not.
This is super true. I was interviewing with a Startup once, and we had an initial screening, and they had a lot of work to be done with AWS, some APIs and data pipelines. My area of work. When we had a "technical" interview, it was completely algorithms focused. And the interviewer dropped a few anchors, which restricted my thinking, and caught me cycling. It was super obvious the call wasn't going great. Odd enough, they acknowledged, that I was one of their best candidates, and were surprised. I didn't get the offer. It was a job I knew I could've aced, but the questions they asked didn't match up to what they actually needed done :/
> My golden rule for technical interviews is that, "Every step, conversation and question must be pertinent to the day-to-day of the role." While this may be obvious, I am sure that many hiring managers are still expecting candidates to arrive at technical interviews with Computer Science books memorized. This form of technical interviews should be made obsolete.
Here's the core of the article right here. The "regurgitate LeetCode-style problems" interview fails to be relevant to the day to day of pretty much any SWE job (unless, maybe, you're applying to work for LeetCode, and one of the duties is to create solutions to problems in under 40 minutes, without outside resources).
Take the author's golden rule and layer on a structured interview process, and now you've got an interview process that will be more predictive of whether a candidate is a good hire than any "throw a random engineer in a room with the candidate and have them answer random algorithm problems" type interview. Even better, since you have an actual process, you can tweak it to be even more predictive of a good hire.
I really like the interview process the author lays out here. As someone who has been working for about 20 years in the industry, this feels like a better, more direct gauge of how well someone will fit in the role than of seeing if they know how to invert a binary tree. I do think it's still worth doing some sort of coding question, but it doesn't have to be some intricate algorithmic puzzle. It can be as simple as, "How would you design X?" for design and some data structure algorithm question, but something that does not take up the bulk of the interview. (Perhaps one interview in the loop could be devoted to hands-on coding.)
One of the best interviews I had, and I'm biased here since i hit out of the park, was one where the interviewer literally gave me a laptop and told me to code a simple iOS app. I was applying as a senior iOS developer with many years experience, so it was totally fair to ask it. Having written several apps on the side, I got straight to work and knew exactly how to set up data structures, algorithms, and trade-offs. Even with my experience, I was not able to finish the complete app in the time allotted, but I was able to breeze through all the elements of of what go into designing an app from scratch.
I had a few more interviews and later they offered me a job, but I ended up working elsewhere. Interestingly, the place I did take a job at had more traditional tech interviews, which I actually found too easy compared to larger tech companies, however there was more long-term growth available there and the pay was much better.
Ego Trip is the right phrase. A lot of the traditional algorithms puzzler interviews amount to the material being covered in an adversarial, closed-book fashion for the interviewee, after the interviewer has themselves gotten to master the material in a "at your leisure" fashion with an open book.
I wouldn't mind getting asked nasty questions about red-black trees or Krushkal vs Prim or something if I knew the person sitting across from me had taken a "pass this test under these same conditions or you're fired" type scenario. It wouldn't make these interviews a good idea, but it's the reek of hypocrisy about them that puts it over the top for me.
I still contend these interviews - in any form - are a hazing exercise designed to convince you that your own expertise doesn't really matter. You may think of yourself as a accomplished professional developer but to BigCo you are a Smart Person (?) Grade N to be slotted into an arbitrary role. What better way to convey this message than put you through an interview that you would have been best equipped to pass straight out of university or grad school? I suspect my peak "pass the tech interview" would have been straight out of the core courses mid-PhD and my ability to do this has since gone down every year.
> I wouldn't mind getting asked nasty questions about red-black trees or Krushkal vs Prim or something if I knew the person sitting across from me had taken a "pass this test under these same conditions or you're fired" type scenario. It wouldn't make these interviews a good idea, but it's the reek of hypocrisy about them that puts it over the top for me.
The only equivalent I know of this is a PhD oral comprehensive exam. I get your point regarding the hypocrisy of it all, but I don't think I would be into it, even if my interviewer had a PhD and had done something similar.
I'm doing a lot of interview as an interviewer these days mostly with junior candidate.
The guy in charge of those before me was the kind that use aha question with no relevance whatsoever. Pure ego trip. If that guy had interviewe me I would have said "I don't know" a few times and eventually get up and leave.
For my candidates, I tried a few things. Now I've got it down to explain to me your last project. I ask questions until I've understood every little detail of the project. Then we code a few simple "exercises" with increasing "difficulty". The candidate is allowed google, documentation, questions, anything. Then we read code. A piece of code with a "bug" or a feature to add.
The key is to make them talk about concept from impérative, fonctionnal and object paradigm and interact like a junior and senior dev would in a dev team.
I found that junior candidates react pretty well to these. Some of them thank me for having had the opportunity to learn about new things like functionnal programming. It's pretty cool and I feel that make them want to join us most of the time.
One issue is very few people get interview training. I have interviewed maybe 100 people but had to figure it out for myself what works. I wish I could apologize to the first few dozen.
Look, you have to do technical interviews. You don't have to be a bully, but you have to find a way to probe the candidate's ability to solve technical problems and code.
Pick a question that tests the skills you're looking for, but not too closely related to the problems you encounter every day, as that will introduce really strong bias. Pick a question that can be answered in 10 or 20 minutes on a white board. The question should seem really easy, so prepare a follow up question (or two) that adds difficulty for the candidate that needs the challenge.
But here's the most important part: use the same question in at least 10 interviews. Test your questions by using them on many candidates. Don't introduce uncertainty by playing a different role in every interview. You'll get much better results.
"Every step, conversation and question must be pertinent to the day-to-day of the role"
While I agree with the author's 'golden rule', I believe the complex data structure questions are just a way to filter interviewing candidates in a highly competitive job market. It's akin to the highly competitive Indian Joint Entrance Examination (JEE) where hundreds of thousands of students solve complex problems in Math, Physics, and Chemistry to get into premiere institutions with few thousand seats, most of whom do not pursue a career in sciences.
I think that biggest issue for me is when some small startup acts like "premier institution". If you need to sling out cookie cutter code to deliver stuff to your customers don't pretend you are going to change the world.
I just rejected one company because they had 4 pages of NDA and were small company.
Problem solving skill is a must.
Not saying to cram the algorithms. But using those in your approach shows the ability of the candidate's efficiency and quickness in solving them.
There's so much hate for "whiteboard interviews" and "interviewers focusing on themselves rather than the candidate" and all that on HN, but what if...this is actually what works for some companies?
Some people want to work on super challenging problems with technically brilliant coworkers. Some people treat a poor performance not as a humiliation, but as an opportunity to understand how much they do not yet know.
What if you want to attract candidates like that? Ask them tough questions, don't tailor the questions to their strengths, and have the interviewers show off how smart they are (even if they're not, it's easy to appear smart when you have all the answers). Pay good money and have high prestige so that you get plenty of quality applicants for every role, because you're going to miss out on many of the good ones, but you will attract some of the brightest and most driven people.
[+] [-] TheCapn|5 years ago|reply
The initial interview itself was pretty straight forward, but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts. We talked about hashing, and when he asked if I knew what hashing was I said sure, its a one-way function to create a unique identifier. He asked me to elaborate, so I sorta... talked more? I remember feeling confused because I'm not sure what else he wanted me to say. Eventually he ended the question, said he was looking for me to say hashing is for "fingerprinting"
We moved on, he asked me for an example of a hash function. I said md5 or sha. He pressed further, asked about collisions and eventually cut off the line of questioning telling me he was looking for an example like the modulus function. Questioning lead further to reaching into linked-lists and the like.
Having never sat through this kind of interview I was left with a really salty taste for the process. If any they were looking for was me to rattle off some pre-determined key words then what good is the interview for? I incorrectly assumed he was gauging my familiarity with the subject rather than repeating my 2nd year university coarse which introduced shit like data structures and algorithms.
His smugness in the way he concluded each topic was just a giant turn off of ever seeking further work with companies like Amazon (giant & highly competitive software conglomerates). I feel like everyone is trying to one up or appear to be king shit in some way, it left a bad taste. (For the record, I did a couple interviews of this style before totally writing the experience off. Others were better, but this experience always stuck with me)
[+] [-] umvi|5 years ago|reply
One time an interviewer asked me "how would you go about counting the ridges of a US quarter?"
I rattled off some ideas about counting the ridges in an arc and then multiplying to get total ridges but the interviewer kept prodding and eventually ended the question and said he was looking for me to say "google it" (I didn't realize it was a known, fixed number).
I just rolled my eyes and laughed and said "Huh, good one, but how would you go about counting the ridges of a foreign coin assuming it's freshly minted and the number of ridges is unknown?" The interviewer shifted uncomfortably and just said "yeah, I'd probably do something like what you said - count the ridges in an arc and multiply..."
(i.e. "if you are going to give me bogus lateral thinking puzzles to test my competence I'm going to fire them back to see how you handle them")
[+] [-] ng12|5 years ago|reply
[+] [-] emerged|5 years ago|reply
Dunno if that was representative of Google or big companies in general but it turned me off forever.
[+] [-] ra7|5 years ago|reply
This is also one indication that the person is an inexperienced interviewer and their whole line of questioning is focused on tripping up the candidate into making mistakes. A good interviewer thinks along with you, helps you and is fairly satisfied if you articulate a concept "well enough".
[+] [-] rvz|5 years ago|reply
Well this is the typical behavior towards those who cannot interview properly and has to introduce pedantic point scoring to bring people down. It would take an experience of resentment, denial or some sort of impactful rejection from the interviewer to be at the point to certainly enjoy this ego trip as an interviewer at somewhere like Amazon.
Now it seems everyone and the whole tech industry thinks they're Amazon, Microsoft or Google by asking about implementing efficient algorithms, libraries or the like yet they continue to use the slowest languages, spinning up multiple VMs or clusters at higher runtime costs and choosing Electron for software development. Unless they are also contributing to writing a production grade compiler or systems software, companies who ask these data structures and algorithms questions are doing it simply 'because of reasons'.
[+] [-] bsder|5 years ago|reply
One thing that shocked me in discussions is that apparently interviewing incoming candidates at FAANGs has now become a mandatory performance review objective.
This is going to produce a lot of interviewers who really don't know what they are doing and don't care.
I don't know what idiot came up with this brain-damaged scheme to totally sabotage interviewing and what moron actually propagated it between companies, but I hope they die a horrible, slow, painful death.
[+] [-] maxlamb|5 years ago|reply
[+] [-] kowsheek|5 years ago|reply
That data structures and algorithm book and course is the root of so much distasteful smugness in the tech world, it's really bizarre.
[Edit]: It's almost like it was the first course we found very difficult so we should that imprint of challenge on everyone else.
[+] [-] gnusty_gnurc|5 years ago|reply
I had a similar experience at Apple where my experience lined up well with the position. I felt like the interviewers were hostile - repeatedly asking weirdly pointed questions about hashing too!
[+] [-] jokethrowaway|5 years ago|reply
To be honest, I don't think money is a good reason enough to tolerate that kind environment, I'd rather work in a smaller company paying less and build a small business on the side to increase your passive revenue streams.
Maybe things will change with faang going remote because of COVID (given one perk of small companies was their flexibility) but it looks like your salary at big companies will also scale according to your location, so I'm not too hopeful.
[+] [-] tootie|5 years ago|reply
[+] [-] rdiddly|5 years ago|reply
Edit: https://news.ycombinator.com/item?id=12701625
[+] [-] fizixer|5 years ago|reply
If you're not throwing the keyword you're a 12-year-old fanboy of in the question, you can go eat a carrot for all I care.
[+] [-] seanmcdirmid|5 years ago|reply
Google and Facebook seem to be a bit more of a consistent experience, but interviews are done generically and not by the team that would hire you.
[+] [-] blackflame7000|5 years ago|reply
[+] [-] callmeed|5 years ago|reply
To be fair, it also sounds like you were conflating popular hash functions like md5 with the general concept of a hashing data structure and underlying function. Knowing that modulus operation is one approach and knowing common approaches for dealing with collisions are part of that. See: https://www.geeksforgeeks.org/hashing-data-structure/
[+] [-] roflc0ptic|5 years ago|reply
In the interview, they asked me, "What's the difference between fold left and fold right?" I said "Um, one of them starts on the left side of the data structure, one of them starts on the right. I never remember which is which." They said essentially: "okay. The answer I was looking for was that fold right is not stack safe." I protested weakly, and they dug in, so I graciously let it go.
But it's patently not true. A naive implementation of fold right in Scala isn't stack safe, but the actual implementation is stack safe. It's been stack safe since like 2010. So rather than interrogating my knowledge of functional programming, they're just asking me bullshit language trivia, and dinging me when I don't come up with their arbitrary wrong answer.
I wanted to work there before that, but the interview made me a little ambivalent, and then they just ghosted me. So I guess I dodged a bullet. But man, that was frustrating.
[+] [-] nogabebop23|5 years ago|reply
[+] [-] x87678r|5 years ago|reply
[+] [-] leafboi|5 years ago|reply
At a high level foldLeft and foldRight represent abstraction leakage. The Domain and Codomain for both functions are exactly the same. If there is no performance difference or side effects to consider then there is almost no point in having two fold functions as a plain fold has the exact same inputs and outputs as foldLeft or foldRight.
Typically for side effects you don't want to put it in a fold as you're integrating way too much IO with your functional computations. Rather functional languages tend to have something along the lines of "foreach" for using side effects on the content in a functor. That being said it's strange that scala has a foldLeft and a foldRight with identical performance characteristics. Maybe it's a legacy thing. I dunno, not a scala guy.
Just bringing that up. I still agree with you that the interview question sucked and that the interviewer was wrong. Personally I wouldn't have ever figured out that was what the interviewer was looking for even when I do possess the requisite knowledge.
[+] [-] blain_the_train|5 years ago|reply
They created a puzzle where you needed to ask for more information. Intentionally or not, they were discovering if they could communicate with you. That the communication failed doesn't mean your somehow less then them. It means you just have a different background.
Now to the problem, the problem people don't set good goals. It probably doesn't make sense to hire a carbon copy of yourself.
[+] [-] pmiller2|5 years ago|reply
[+] [-] jaaron|5 years ago|reply
We have 3 tests we give depending on the role (game dev, backend, or SRE). The tests replicate typical work the engineer would be doing, such as adding functionality to a 2D game, developing out a web service for a given API, or debugging and optimizing a linux server. We provide a development environment remotely, or the engineer can use their own. They code/work on their own, without needing to share their screen, though we're on the line if they have questions or just want to chat. The interview itself takes about an hour and we schedule in buffer time before/after to setup and to debrief.
We've designed the problems to be (a) relative, (b) scalable and (c) fun. By scalable, I mean that the problem should have a simple, naive solution that most engineers who work in that space should be able to solve quickly and easily, while also having enough space for more advanced engineers to extend the problem and show off a bit.
So far we've gotten good feedback from this approach, even for candidates who haven't passed. I know 90 minutes is a long time, we but feel that with this test, we get a good, realistic work sample, and we can forgo a lot of the other less effective interviews.
(plug: we're still hiring [1])
[1] https://www.singularity6.com/careers
[+] [-] lazyant|5 years ago|reply
A fallback for shorter question is to ask for a something with many possible answers, as typically somebody more experienced will have many answers besides the most popular ones. (server A can't ping server B, what can be the reasons?)
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] scollet|5 years ago|reply
[+] [-] throwaway815190|5 years ago|reply
[deleted]
[+] [-] globular-toast|5 years ago|reply
It was six individual one-to-one interviews, back to back. The first five were an ego trip for me. I was able to do everything perfectly it seems: read code, write code, talk about code. Then the sixth was this synthetic problem involving nested boxes. I figured out it was a tree problem and started writing code to build the tree. I had an approach in mind and asked the interviewer if he thought that was a good approach (given that there was only enough time for one attempt). He said no, he didn't think it would work. That completely threw me off. Later I realised me approach would have worked anyway.
I didn't get an offer, but what in the ever-loving fuck was the point of putting me through 5 technical interviews only to fail the sixth? It really felt like they were looking for that ego boost but didn't get it from me. It's hard not to sound arrogant in this situation, but I've been humbled in the past. This time I was just confused.
[+] [-] sushisource|5 years ago|reply
Same thing, they came back and said no and I really have a hard time imagining why other than the interviewer not being familiar with Rust - but - hey, don't tell me it's fine to use then!
That to say, rejection feedback is almost always useless.
[+] [-] efficax|5 years ago|reply
[+] [-] phnofive|5 years ago|reply
What did you do when he said no?
[+] [-] WrtCdEvrydy|5 years ago|reply
I've done dozens of interviews and after all of it, I realized there are only four qualities we quantify as useful: caring, ability to listen, ability to learn.
[+] [-] davidhyde|5 years ago|reply
While the intention here is good you are unlikely to get an accurate answer from the candidate using this method because the candidate “should” tell you what you want to hear rather than what they would do in reality. You basically want to find out how the developer delivers criticism. Do they bruise egos or are they tactful or do they simply stay silent.
A better approach is allowing a candidate to demonstrate how they offer criticism. Give them a codebase to read and make sense of and ask them to explain it to you. Ask them to to point out parts that could be better designed. You can gather a lot of information this way. 1. Can the candidate read a foreign codebase and make sense of it. 2. Can the candidate pick up business logic from the code. 3. Does the candidate offer criticism that is likely to make another developer defensive or are they more guarded with their communication and offer higher level design alternatives.
[+] [-] ng12|5 years ago|reply
[+] [-] bosswipe|5 years ago|reply
The attitude of the algorithm geniuses is that software engineering is easy and anyone can learn it, which might be true, but my point is that I already did learn it and I spent five years becoming an expert in it. That should be valuable to your business whether you look down upon it or not.
[+] [-] catchmeifyoucan|5 years ago|reply
[+] [-] pmiller2|5 years ago|reply
Here's the core of the article right here. The "regurgitate LeetCode-style problems" interview fails to be relevant to the day to day of pretty much any SWE job (unless, maybe, you're applying to work for LeetCode, and one of the duties is to create solutions to problems in under 40 minutes, without outside resources).
Take the author's golden rule and layer on a structured interview process, and now you've got an interview process that will be more predictive of whether a candidate is a good hire than any "throw a random engineer in a room with the candidate and have them answer random algorithm problems" type interview. Even better, since you have an actual process, you can tweak it to be even more predictive of a good hire.
Why don't companies understand this?
[+] [-] darth_avocado|5 years ago|reply
[+] [-] paxys|5 years ago|reply
[+] [-] allenu|5 years ago|reply
One of the best interviews I had, and I'm biased here since i hit out of the park, was one where the interviewer literally gave me a laptop and told me to code a simple iOS app. I was applying as a senior iOS developer with many years experience, so it was totally fair to ask it. Having written several apps on the side, I got straight to work and knew exactly how to set up data structures, algorithms, and trade-offs. Even with my experience, I was not able to finish the complete app in the time allotted, but I was able to breeze through all the elements of of what go into designing an app from scratch.
I had a few more interviews and later they offered me a job, but I ended up working elsewhere. Interestingly, the place I did take a job at had more traditional tech interviews, which I actually found too easy compared to larger tech companies, however there was more long-term growth available there and the pay was much better.
[+] [-] glangdale|5 years ago|reply
I wouldn't mind getting asked nasty questions about red-black trees or Krushkal vs Prim or something if I knew the person sitting across from me had taken a "pass this test under these same conditions or you're fired" type scenario. It wouldn't make these interviews a good idea, but it's the reek of hypocrisy about them that puts it over the top for me.
I still contend these interviews - in any form - are a hazing exercise designed to convince you that your own expertise doesn't really matter. You may think of yourself as a accomplished professional developer but to BigCo you are a Smart Person (?) Grade N to be slotted into an arbitrary role. What better way to convey this message than put you through an interview that you would have been best equipped to pass straight out of university or grad school? I suspect my peak "pass the tech interview" would have been straight out of the core courses mid-PhD and my ability to do this has since gone down every year.
[+] [-] pmiller2|5 years ago|reply
The only equivalent I know of this is a PhD oral comprehensive exam. I get your point regarding the hypocrisy of it all, but I don't think I would be into it, even if my interviewer had a PhD and had done something similar.
[+] [-] uxenthusiast|5 years ago|reply
The guy in charge of those before me was the kind that use aha question with no relevance whatsoever. Pure ego trip. If that guy had interviewe me I would have said "I don't know" a few times and eventually get up and leave.
For my candidates, I tried a few things. Now I've got it down to explain to me your last project. I ask questions until I've understood every little detail of the project. Then we code a few simple "exercises" with increasing "difficulty". The candidate is allowed google, documentation, questions, anything. Then we read code. A piece of code with a "bug" or a feature to add.
The key is to make them talk about concept from impérative, fonctionnal and object paradigm and interact like a junior and senior dev would in a dev team.
I found that junior candidates react pretty well to these. Some of them thank me for having had the opportunity to learn about new things like functionnal programming. It's pretty cool and I feel that make them want to join us most of the time.
[+] [-] x87678r|5 years ago|reply
[+] [-] wwarner|5 years ago|reply
Pick a question that tests the skills you're looking for, but not too closely related to the problems you encounter every day, as that will introduce really strong bias. Pick a question that can be answered in 10 or 20 minutes on a white board. The question should seem really easy, so prepare a follow up question (or two) that adds difficulty for the candidate that needs the challenge.
But here's the most important part: use the same question in at least 10 interviews. Test your questions by using them on many candidates. Don't introduce uncertainty by playing a different role in every interview. You'll get much better results.
[+] [-] vasu_man|5 years ago|reply
While I agree with the author's 'golden rule', I believe the complex data structure questions are just a way to filter interviewing candidates in a highly competitive job market. It's akin to the highly competitive Indian Joint Entrance Examination (JEE) where hundreds of thousands of students solve complex problems in Math, Physics, and Chemistry to get into premiere institutions with few thousand seats, most of whom do not pursue a career in sciences.
[+] [-] ozim|5 years ago|reply
I just rejected one company because they had 4 pages of NDA and were small company.
[+] [-] rehman|5 years ago|reply
[+] [-] dmurray|5 years ago|reply
Some people want to work on super challenging problems with technically brilliant coworkers. Some people treat a poor performance not as a humiliation, but as an opportunity to understand how much they do not yet know.
What if you want to attract candidates like that? Ask them tough questions, don't tailor the questions to their strengths, and have the interviewers show off how smart they are (even if they're not, it's easy to appear smart when you have all the answers). Pay good money and have high prestige so that you get plenty of quality applicants for every role, because you're going to miss out on many of the good ones, but you will attract some of the brightest and most driven people.