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")
It's funny that his expected answer was "Google it". In most cases when people answer with that (it could be the answer for any tech interview question...) you get encouraged to actually do the problem, so it's a time waster. For the interviewer it gives them no signal outside of you having the ability and awareness of the existence of search engines, although there could be some vague behavioral signal that shows you have a stronger urge to find existing solutions rather than waste time creating your own. This is a really toxic interview because you're basically expected to read the interviewer's mind. I've had a couple of these with peak Silicon Valley companies. At pre-IPO Zynga I was asked by a GM "what the most important number in game design is", at River Studios (Mike Rothenberg's company...) the entire interview was basically this style of question.
Years ago Zynga asked me how would I design a vending machine for blind people which was annoying because I asked it immediately back and clearly they hadn't even thought about it themselves. But then I brought up Ian Bogost and it was a hard stop basically, lol.
edit: Is it health? Like health tracking / indication? Not all games require it but maybe in the right context this would be the most important. This is snarky but I think you could run with it (health being the most important "number").
The answer was 3 I think, referring to rock paper scissors balance relationships in RTS games, and fighting games, but it was Zynga in 2011 so they were mostly thinking about casual strategy. I think I said 1 at first because the question was kind of silly and I trend toward reductive answers with silly questions.
response to your edit: Your interpretation of the question makes a little more sense. He was talking about a specific number, not a concept\variable that is common in games. For Zynga I'd probably say energy or money or something, although any tracked resource that determines loss, victory or progression would work for your version.
Sounds like your interviewer smoked too much pot before the interview. What the hell kind of question is that and what information could it possibly give you to help make a candidate selection
People assume interviews are to prove technical competence. Answering with “Google it” is more of a test of someone’s humour. While in practice it might be true that you’d Google it, most people have been conditioned by the education system to answer with something more substantive and demonstrative of their technical thinking ability.
I'm not responsible for your conditioning. I want you to tell me the truth. If you're playing a game in your mind that causes you to give me a more complex answer than you need because you think that's what I want to hear, you're going to have similar pathology as an employee and IMO this is a great screen for exactly that!
Edit: doing any "technical" work prior to doing research is a display of technical INcompetence.
That article doesn't seem to contain a point relevant to this particular issue.
If I ask you "How can you attempt to get the answer to this in under a minute" or "what's the first thing you would do" and you don't say "search for existing solution" (it doesn't have to be Google), you fail. You don't have to read my mind; I want to know where YOUR mind goes first. And if it goes to anything more complicated than "I'll try to look it up" you just simply fail; I can't afford to have you wasting any more of my business' time.
I don't think googling is even a valid answer. If he asked "how would you find out how many ridges are on a quarter" then yes (and I think Google it would be everyone's first answer). But counting, as a verb implies the act of measurement, not just obtaining the final number. Assuming that he used that word, it sounds like a trick question.
I was once asked how many golfballs could fit in a school bus. I blathered on about measurements of the bus, volume of a ball, the average due to gaps between balls, are the seats still there, etc... bottom line we could spend a lot of time getting an ever more precise estimate. The guy seemed satisfied. Later at home I realised that my test engineer friend may have suggested doing an actual experiment - rent a bus and a few tons of balls. The later would be easy since there is a local company here that recovers lost balls from golf courses (even from the water), repaints the and sells to driving ranges. You can buy them in bulk.
Which answer is better? Which were they looking for? Who knows.
If we live in a world where reality is on deck, and not the seemingly arbitrary and capricious one that folks sometimes weave, I think you can determine what answer is "better" with more context.
Renting a bus and filling it with golf balls is significantly more effort intensive than calculating, but it might give interesting, real world insights if the values differ.
For the purpose of running a business, the choice, to my mind, hinges on how much your revenue / customer satisfaction / product depends on the real world intelligence such an endeavour might bring. The situation illustrated is contrived, so it's hard to contrive an answer to that question.
There's hybridized approaches. Here's a 3D/AV interactive developer's contribution to your approach list:
I've used lidars and depth cameras as a hammer quite a bit over the last year, so I'd do thus - Realsense D435 capture the inside of a bus. Use meshlab to align and stitch all your pointsets. Perform reconstruction on it so you get a 3d mesh. Use your tool of choice to perform a physics simulation on golf balls (I'd probably use Unity3d, because customers love simulations they can play with.)
Run your simulation a ton of times with epsilon changes to initial conditions. Maybe even do it with an evolutionary algorithm that tries to maximize the count!
Either way, report back with a distribution. Also capture frames every once in a while so you can give them a timelapse. God customers love timelapses.
The tradeoff with this approach, if you fail to build a good rapport with the interviewer, you'll get labeled as not a good culture fit. Calling them out for a dumb question or critiquing the expectation of an 'expected answer' is not going to get you the job.
That doesn't sound like a tradeoff per se to me. Chances are that if the interviewer gets offended by a candidate turning a question back at them, that candidate may not actually be a cultural fit. It's much lower cost for both the company and the candidate to find this out earlier rather than later, so I'd actually call it a win-win.
I was interviewing during the time covid started and everyone started working from home. I was interviewing with a company. I had a call with recruiter then with a hiring manager. I also got a project to work on over weekend.
Then got response something like, we really like you, but currently our hiring is suspended, we will let you know when it is back up.
Like, why did you wasted my time if you knew that I can't proceed to the on-site interview and you won't do it remotely?
I've witnessed this a few times. Usually because you actually passed the current hurdle, but the company got cold feet because the next step requires more effort from them and they can't make up their mind...eitherway as irritating as it is you probably dodged a bullet
Its sort of like companies doing subconscious window shopping...absolutely infuriating stuff
I see nothing wrong with this, why would I write algorithm X from memory or taking my best guess at it on the spot, isn't the whole point of learning them recognising when are they applicable and how to find them quickly ?
Knowing the multiplication table is such steaming nonsense. I know 7x10 is 70 so half of that, 7x5 is 35. I can add seven to 35 fast enough that I don't have to memorize 7x6 is 42.
I am thinking that a google search about an interview question about the number of ridges on a US quarter or "Quarter" (whatever the 25 cent coin is) would unlikely point to this thread, or to your statement, which is (paraphrased): the US quarter has 11 ridges.
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.
Certainly. I had a really good interview recently that was entirely technical, but none of this. It was a "this service is down, walk me through your process of isolating and debugging". If I said "I'd check these logs or services" then I'd get answers. And I'd get architecture described. Was more a technical problem solving and thought process exercise than "prove you know the same technical trivia I do".
I cannot relate to, after two miserable phone interviews with Google I told them on their third request, that if my CV looks so great (by their own words why they were reaching out to me) and yet I had to deal with such interview processes better not bother me ever again.
It’s a stochastic process. Some percentage of Google interviews are bad. As a job-seeker you are drawing a few samples from each company and you make a judgement.
The bigger the company the more variability in experiences.
So you make a decision with imperfect information. But it doesn’t really matter because even if you have perfect information through the interview that’s still an imperfect measure of how the job will be.
It’s all stochastic so the only way to get a good outcome is to iterate—guess, evaluate, try again until you find something you like.
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.
At the ~500 person tech company I work for, the first goal of the recruitment and interview process is to decide if the candidate would be a good fit for the role, and the second goal is to convince the candidate that they should accept the job if offered.
I recently interviewed at both Apple and Amazon. None of the interviewers or recruiters at either company tried to sell me on the job and I left both interviews not wanting to work there. My theory is that Apple and Amazon don't spend time trying to sell the company because they already have more than enough willing applicants for each position. Is the same true for other large tech companies?
My impression was they expect you to desperately want to work there and be willing to submissively beg to be accepted. That's not how my mind works so it just seemed repulsive.
Google had a guy take me to lunch as well. I suppose this is part of their process. I was surprised it was a random developer (a quiet, uninterested, also slightly miserable young guy), rather than someone who was otherwise involved in my (potential) recruitment. It seemed like a lost opportunity for them to get to know something about me other than whether I could do simple coding exercises quickly and accurately under pressure without recourse to external resources. (I can, but apparently not quite quickly or accurately enough for them). I was amazed that they were prepared to fly me to another country (NZ to Australia), but at no stage showed the slightest interest in me personally or anything I had ever done. I am 59 years old, I've been working with code since I was 21 and worked out how to program a significant embedded application on an Intel 8085 CPU using nothing but the manufacturer's data sheets and a simple hex keyboard and display breadboard target. I've learned a few useful skills along the way.
> "It seemed like a lost opportunity for them to get to know something about me"
Don't know the policy at Google but lunch is usually intentionally supposed to be a break from the interview process. Having somebody grilling the candidate while they are trying to eat defeats that purpose.
> "I am 59 years old, I've been working with code since I was 21 and worked out how to program a significant embedded application on an Intel 8085 CPU using nothing but the manufacturer's data sheets and a simple hex keyboard and display breadboard target."
At a FAANG, nearly everybody has similar stories, so that's not particularly distinguishing.
I don't doubt that the Google people were very accomplished, but it still seems logical for them to find out something about where my skills and strengths lie. I didn't want to be grilled at lunch. Normal practice in my experience is to make lunch a pleasant experience for all involved at the same time providing an opportunity for both sides to check for cultural fit etc. etc. A win win basically.
I did about 20+ technical interviews at Google/Facebook over the last 2 years.
Overall, the interviewers were competent. Sometimes you could tell that they didn't really enjoy interviewing people but it was ok. I only had one interviewer I'd consider bad (gave confused advice to lead me to his solution), but maybe it was just a personality mismatch.
I had better experience with more senior interviewers too, and I found Facebook better than Google (although similar), on every respects (choice of questions, team matching process, more interesting projects...).
My main complaint is that I've found the whole process random. Right now I'm in the team matching phase at Google, but not sure it'll go through (and it's not the best time).
I applied two times at Facebook, and two times at Google (they contacted me each time at one year interval). Each time was 0 to 2 screening interviews, then 5 to 7 on-site interviews. Yes, I'm counting each interviewer as a separate interview (not counting discussions with the recruiter, but counting "culture fit" interviews).
I think it says a lot more about the individual interviewer than anything about the company.
I've had great interviews with a company, and then I've had one where the person was looking for me to say 'base64" (which I wasn't actually aware of at the time!) even though I was explaining the same exact concept from the same company. The whole process is capricious.
IMO, "capricious" is a word that could be used to describe any interview process that isn't a structured, formalized process. You don't get a good signal out of ad hoc interviews, you can't calibrate across interviewers, and you can't compare accurately across candidates, so why bother?
> 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.
when i interviewed at google a few years ago the guy told me they were starting to require everyone who’d taken the relevant training to interview candidates.
unsurprisingly, he didn’t seem enthusiastic, couldn’t manage to say “yes” when i asked if he liked google, and didn’t know python.
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/
>Knowing that modulus operation is one approach and knowing common approaches for dealing with collisions are part of that
Yes, expecting them to know that is reasonable. Expecting them to regurgitate that factoid unprompted is bullshit.
Don't inquire on a topic and expect a canidate speaking in generalities and off the cuff to overlap with your toy facts.
I'm fighting the urge to rant in the comments here on how to competently conduct a useful technical interview; but I'm more and more convinced it's a competitive advantage.
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.
Yeah, I'm ambivalent about that. From a purely theoretical standpoint, sure, bad actors should be punished. There's also slim but non-zero chance that they'll reciprocate and attempt to harm my reputation, and we'd end up in some dumb internecine conflict. It's good for bad actors to be punished, but usually irrational to be the one doing the punishing.
I appreciate whenever I see people in your position get angry about ghosting, but in my experience, for positions that I’ve interviewed for and didn’t get, I think only one ever let me know.
I’ve come to rationalize this as a risk-avoidance tactic, and I think the negative effects of reputations damage to the company are mostly unaccounted for.
I’ve never experienced it before now - how common is this? Is it a west coast thing? This was my first interview with a west coast shop. I don’t need an essay on why they thought it wasn’t a good fit, but radio silence seems eminently unprofessional.
Not sure how common but this has happened to me as well. Coding challenge complete, follow-up interview scheduled... then cancelled. Rescheduled... then ghosted.
It was a cheap way of figuring out I shouldn’t even consider working there.
> It was a cheap way of figuring out I shouldn’t even consider working there.
I mean - all you're experiencing is the HR/recruitment side of the pipeline at that point. You can't really say that an entire company is shit just because some subset of its HR/recruiters do shitty things. How many CTO's actually give a shit about IC interviewing experience and dig into the entire methodology that recruiters use when interacting with candidates? (And actually keep track of what their recruiters do) I'm gonna give a wild guess and put 0 out there.
In my case, it was a small shop and entirely through direct communication with the manager making the hiring decision. He seemed like a genuine, nice guy, so I'm leaning toward it being evidence that the dude does destructive, avoidant behavior, which is an unsettling tendency in a manager.
Regardless of how many CTOs do care, 100% of them should care. The reason they don't is there's no real incentive for them to care. Outing companies who do things like ghost candidates or have shitty, arbitrary interview processes probably isn't going to be enough to get most of them to care. But, some might, which is why I think it should be a regular practice.
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.
> The Domain and Codomain for both functions are exactly the same.
This is not true.
> def List[A].foldLeft[B](z: B)(op: (B, A) => B): B
> def List[A].foldRight[B](z: B)(op: (A, B) => B): B
Notice the signature of the fold op: the arguments types are swapped. This is because fold left and right on a list [a, b], say, is the difference between:
(z op a) op b
and
a op (b op z)
(If this isn't compelling enough, consider [a, b, c].) Not all functions are associative. For example, consider a cryptographic hash function.
Elements in sets are not ordinal. In principle they are the same as the set (B, A) is the same set as (A, B).
If you're saying that foldRight in scala exists aesthetic reasons... well can't argue with that. I figured it was more for legacy reasons as the original poster said that there use to be a performance difference.
As for the associative thing I mentioned side effects. Function composition is always associative. Unless you have side effects. See: https://www.wikiwand.com/en/Function_composition (search for associative)
I don't know much about crypto but I'm assuming you're referring to things that aren't side effect free. In general though a hash function should be associative under function composition as it is just a surjective mapping from domain to codomain.
Also can't exactly read that syntax nor the stuff below it. Not a scala dude. Maybe a more traditional map implementation in like python or JS pseudo code would make more sense to me, but that may be too much to ask.
edit:
I think you actually may be right. We're both a little wrong with our reasoning though. Function composition is not commutative. And FoldRight and FoldLeft reverses the order of composition which has an effect on operations that are not commutative.
I don't think I understand the point you're making. I just tested it, and empirically your assertion is incorrect:
// this makes a linked list ten million and one elements long, from zero to ten million
val longList = (0 to 10000000).toList
// this adds the elements
longList.foldRight(0)({ case (l, r) => l + r})
This does not stack overflow.
You write:
>> a plain fold has the exact same inputs and outputs as foldLeft or foldRight
but if you use fold over a collection of type T with the fold function in Scala, the result must be of type T. Fold left and fold right don't have this constraint. Further, this fold is only coherent if the operation is commutative, because it doesn't happen in any particular order. You can add integers in any order to make the same sum, but you can't add pages of a PDF in any order to make a PDF.
Framed via recursion schemes, I'm pretty sure foldLeft can be viewed as a catamorphism where foldRight is an anamorphism. You're consuming the tree from different directions. They may have the same domain and codomain (I'm a little hazy on that) but they're not apparently the same function. y = 2x and y = 3x both have the same domain and codomain, right? But the difference between them isn't aesthetic.
Parent wasn't slightly wrong, you just tunneled in on the signature of the operator function, when the reason why parent comment brought it up was to illustrate that the operator function is not necessarily associative, and that the function signature was meant to suggest the difference in associativity.
You're wrong about the operations possibly not being commutative; as you pointed out, whether the parameter list is (A, B) or (B, A) doesn't really matter, so it doesn't pose a problem.
An example is the subtraction operator: with just two elements, I can change `(a, b) => b - a` to `(b, a) => b - a` with with no difference in result. But there is no way I can write a subtraction function for foldLeft that gives the same results as a foldRight on subtraction in general. That is, I can write op such that a op b = b - a, but not that (a op b) op c = (c - b) - a. Nevertheless, I can still write op such that a op (b op c) = (c - b) - a due to some dual notion of commutativity.
Function composition is associative but not commutative.
So in essence given three functions z,g,f and composition operator <.>
f . g . z != z . g . f (commutativity)
which is sort of what fold left or right is doing (but with z g and f being the same function).
but:
f . g . z == z . (g . f) (associativity)
My edit is right about the operations not being commutative. Parent is wrong about associativity as it has nothing to do with this, but he is right that the codomains of left and right are not equal.
Function composition isn't completely accurate to what's going on, it's a more higher order form of composition going on with fold but the rules remain the same.
> which is sort of what fold left or right is doing (but with z g and f being the same function).
> it's a more higher order form of composition
More precisely, a fold performs function composition on the provided operator curried with the respective elements, so that z g and f above are different functions (hence not commutative in general, but associative in general, wrt folding).
You're still confused. There is no function composition here.
op in the example above is just some other function, like +. The associativity of + and function composition are true for totally unrelated reasons. Associativity of plus is an inductive argument that follows from the Peano axioms.
Function composition says:
(f o g) o h = f o (g o h)
as functions. It is true because unary function application "serializes" function applications. Formally, I mean:
((f o g) o h)(x)
= f(g(h(x)))
= (f o (g o h))(x)
Function composition has one value flowing through several functions. Fold has several values flowing through one function.
It's a higher order composition of functors. Lack of Commutativity still applies and is the factor for why the codomains aren't equal not associativity. It's all pedantry though. Overall you're right.
Intuitively the composition is similar enough to function composition that is has the same basic ruleset and is how I'm working out the logic in my head. Think of the functor as a tuple of the accumulator and the value: (acc, x), and the function is just an op that takes in this tuple as a parameter and spits out a new tuple (acc, z) with the next value in the list.
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?)
Yes, scalable problems are the best, but can be difficult to devise.
A lot of folks tend to go the "optimization" route, by having a problem with multiple ways of extracting more performance, typically by better algorithms or data structures. These are ok, but not great. Most candidates will reasonably start with a simple naive solution that works and then try to optimize, but time may not allow for that and the optimization may require significant rewriting of the solution. So unless you either start out with the optimized solution or you have a lot of time, you're unlikely to ever see those solutions.
I tend to prefer scaling via scope.
For example, for our game engineering test, we start with a half-finished 2D "game" (think something like pacman). We then have a list of functionality that can be added with increasing difficulty. This allows us to measure "seniority" by both (a) how far down the list they get and (b) the quality of the individual solutions.
Another example is starting with a single threaded solution and then extending into a multi-threaded or multi-process solution.
At this stage of the studio, we are orienting to a more "senior" team, but that basically means senior+. We're not particular about titles as it's still a small, flat team. As the team grows, we'll gain the mentoring capacity for more junior talent, but for now, we're focused on an experienced team.
I just started game dev this year, so I'm slowly gauging the complexity the same way I might gauge complexity in my eng domain: fullstack web development.
If you have the time, what are your clear indicators on who is a competent mid-level game systems engineer?
I'd love to apply your advice to my portfolio before I feel ready to assume that role.
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.
This is why Python is my dedicated coding interview language. You could do something far more impressive in C++ or Rust, but if you don't quite finish the full implementation it's an automatic fail with some interviewers even if you had to take into account many nuances that a Python solution wouldn't.
That's also because in addition to testing if you can solve the problem, they're also testing your _judgement_.
It's an interview. Just like any other engineering problem: use the right tool.
If you go off tangent and don't solve the problem, then that raises the question: "Ok, the engineer seems to be able to code, but they didn't finish. Will they finish other work? Will they regularly get caught up in irrelevancies?"
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.
To be completely honest, it was a mistake... I forgot to add 'curiosity' after 'caring' but... I will now use this to figure out who is curious about the fourth one :D
> “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.
It is utterly shocking how many bullshitters show up for interviews. I'm sure it varies by company and industry, but a fair chunk of interviewing is weeding out bullshitters.
I can't believe how many people claim to have years of experience but are completely unfamiliar with terms like "binary", "library", "compiler", and "filesystem".
If it sounds crazy, it is because you're not a BS artist yourself, so it is hard to put yourself in that mindset. I have friends who fall into this category, and they would be the first to admit they bullshited their way into FANG
Not only that, but the only concrete example the author gives is that they asked him about red-black trees. Probing knowledge of data structures is very relevant to day-to-day software development work: even if you don't actually implement them (or haven't since college), having a good knowledge of how they work is the only way to make intelligent decisions about tradeoffs involving them.
NOT knowing the internal implementation details of everthing is what has gotten us this far in the first place. You just don't evaluate candidate data structures that often in the vast majority of programming work.
If you want to test somebody's ability to think a problem and not just bullshit 100%, why not ask them questions like "Given two integer variables x and y, write a function to swap their values without using a third variable"?
It's a pretty small problem, but it's still one that needs some thought to get. Also doesn't weed out people who don't know technical details of a red-black binary tree (for example) without necessarily getting rid of people who could quickly pick up what a red-black binary tree is.
The vast majority of interviews ask coding questions somewhere in between the difficultly level of swapping two integers and red-black trees. I have interviewed at pretty much every mid-large tech company over the years, and have never once been asked anything involving more than array manipulation, linked lists, binary trees, hash tables and BFS/DFS traversal. And this includes senior+ roles at Google, Facebook etc.
Careful there with that "legit" solution! With extreme values, it can cause overflows and other weird behavior.
For example, in Javascript with:
x = 2
y = 9007199254740991
then:
x = x + y // 9007199254740992
y = x - y // 1 (!!!)
x = x - y // 9007199254740991
Or in a somewhat more sane language like C, it'll usually work but may technically invoke undefined behavior:
% cat test.c
#include <stdio.h>
int main() {
int x = 2;
int y = 2147483647;
x = x + y;
y = x - y;
x = x - y;
printf( "%d %d\n", x, y );
}
% gcc -fsanitize=undefined -O0 -g -o test test.c && ./test
test.c:5:7: runtime error: signed integer overflow: 2 + 2147483647 cannot be represented in type 'int'
test.c:6:7: runtime error: signed integer overflow: -2147483647 - 2147483647 cannot be represented in type 'int'
test.c:7:7: runtime error: signed integer overflow: -2147483647 - 2 cannot be represented in type 'int'
And even in Python you can end up with it silently turning your ints into longs.
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 :/
Reminds me of an interview a friend got me at a Spring Boot shop. Make sure you know SB, he said. I normally do Python, so I brushed up on Java and Spring for a month beforehand and was impressed with my progress.
Well, final technical interview wasn't done by him and was instead 100% SQL and database theory instead. I did decently, I got about 85% of the questions right off the top of my head. Pretty decent result for zero preparation. Well, guess what another SQL-head did better. Was a total disaster because I was unemployed at the time and staring down financial ruin.
> 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.
Following the other comments, I gave GPT-3 the prompt:
A post titled "The Technical Interview Is an Ego Trip" was submitted to tech forum Hacker News.
Here are the comments on that submission:
Here are the unedited/uncurated results:
---
"The interview process is really more of an ego trip for the interviewer, and the interviewee is just the means of satisfying that need."
"The most common reason I see people getting technical interviews is to satisfy the ego of the interviewer."
"I have been on both sides of the table and I can honestly say that the interview process is mostly about the ego of the interviewer. And that is a shame."
"I have done many interviews, and can say that, with a few exceptions, the vast majority of them are ego trips."
"The technical interview is a big ego trip for the interviewer."
"I am not sure how many times I have heard a manager say that he likes the technical interview process because it gives him a chance to meet technical people."
"While the 'ego trip' comment might be a bit of an overstatement, interviewing is a skill and a process that, like any other, should be improved over time."
"I have never really gotten the feeling that a technical interview is done for the benefit of the candidate."
"Once you realize that you're not actually interviewing for a job, you'll find the process a lot less stressful."
"I don't think the 'ego trip' term is a fair description. First of all, I am not interviewing for my ego."
A blog post titled "The Technical Interview Is an Ego Trip" was submitted to tech forum Hacker News.
Here are the top-rated comments on that submission:
Here are some more unedited, longer outputs:
---
"This is a very accurate and useful description of the process of interviewing at most companies. I have seen this for over a decade. The interview is almost always a complete failure from the point of view of the interviewer. They start out with a very simple question, which they then follow up with a more complex version of the same question, but slightly different. The candidate is supposed to realize that this is a follow-up, and answer it correctly. The interviewer may take notes. The interviewer is supposed to realize that the candidate is able to recognize the pattern, and answer correctly. So the candidate is asked a number of questions, and at the end of them, the interviewer feels that they have learned whether the candidate is smart enough to be hired. This is obviously a very flawed process, because it's very easy to fool the interviewer. If you study the candidate's manner, you can tell if they are intimidated and trying to please you, or if they are confident and trying to impress you. Or if they are just bored, and hoping you will end the interview. It's very easy to fake the answers to questions, too. Most people don't know the answers to the questions they are asked in interviews. They could look up the answers on Wikipedia, but they don't. They just make something up and go with it. It's not like the interview is going to check. It's not like the interview is going to test the candidate's knowledge on the spot."
"All of these comments are eerily familiar because they echo my own experience. I've interviewed hundreds of candidates over the past ten years. I've sat on hiring committees for some of the most in-demand tech jobs. I've hired some amazing people and I've hired some terrible people.
As a general rule, both the good and the bad candidates have the same attitude.
What I'm talking about is the attitude that a candidate comes into an interview with. You can't see it, but I can. It's the attitude that a candidate projects over email, phone, and Slack. It's the attitude that I can tell when a candidate's voice is shaking because they're nervous but they're trying to hide it. That attitude is the one that says "I'm awesome and you should hire me, and if you don't you're a fool."
It's not a coincidence that the candidates that I've come to like or even love the most have been the ones who come in with a humble attitude. These are the candidates that don't care if they get the job because they're happy to have an opportunity to interview. They don't need to prove themselves. They don't need to be the smartest person in the room. They don't need to fight for the job."
"From a former interviewer:
As an interviewer, I'm totally biased towards the candidate. I want to like them and I want to give them the benefit of the doubt when they don't know something. I want to believe that they're a good person. I want to think that if they're not a good culture fit, it's because they're just having a bad day. I want to give them the benefit of the doubt. I don't want them to be bad. I want to think that if they're bad, it's because they're just young and inexperienced and they'll get better.
And as a candidate, you have no idea whether you're being interviewed by one of those people. You never know whether you're talking to the one who's going to be completely honest, or whether you're talking to the one who's going to try to tell you what they think you want to hear."
I want a GPT-3 trained on HN - if it can look at your title and generate basically your content/comment, don’t post it. Similarly, if it can look at the comment you’re replying to and generate essentially your reply (let’s say in top-5 most probable), don’t post it.
Edit, love the irony that both responses are about GPT. Point proven?
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.
Well, here's the thing about that, though... somebody does eventually pass these interviews. It may be a tough blow to your own ego to realize that you actually weren't the best candidate out there, or that somebody more qualified than you would be willing to accept a position that you yourself are just qualified enough for, but probing the competence of the candidate is entirely the point of a job interview. This is doubly important for a technical position where a false positive is orders of magnitude more damaging than a false negative.
I like how you are assuming that I'm writing this out of sour grapes. I've never failed a technical interview. As always, there are an ample supply of folks (of, ahem, rather varying achievement levels) on Hacker News who always seem to fondly imagine themselves on peering dubiously over their glasses at my while I supplicate for a job. :-)
Maybe you could try to apply the supposed Hacker News rule of not assuming the person you are responding to is a complete idiot? I'm startled to think that you assume that I wouldn't understand that interviews are typically competitive processes where some people get hired in the end and (at sufficiently desirable jobs) most people don't.
Instead, you could maybe think through whether "competence" == "ability to pass typical BigCo coding interviews" and my actual point? Really, basically any of my points? I have met, and worked with, people in all 4 quadrants of that particular pair of qualities.
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.
Another thing to consider is even if you interviewed that many people there's really know way to evaluate your interview accuracy and performance unless you work with all 100 people.
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.
45 minutes - write a simple API matching the spec in one of the 3 languages on your/our laptop. Use Google if you have to. Someone will be in the room to help answer questions. API should be functional. Returning fake data is fine (or provide data in a sqlite db)
45 minutes - do code review of this extremely buggy code like you'd review a coworker's code
45 minutes - presentation on a technical topic to one or more members
45 minutes - behavioral. Let's talk about failures, conflicts in your career. Who are your role models? What do they do well? Leadership abilities, career progression
45 minutes - troubleshooting. Here's a docker container. Make this thing work.
Rate all these on a scale of 1 to 10. Sum up the scores. Keep calibrating across all your candidates.
"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.
As an interviewer and decision maker around hiring engineers, there is zero legitimate reason to make the candidate feel like an idiot for not knowing something. It's easy enough to clarify what they're saying, and if there's a miss to just say "ok cool" and to ask the next question.
Ha! Zoox (the self driving car company) out of the 5 hours, 2 hours were math problems. Couldn’t google. Couldn’t use a calculator. No notepad. Had to use a zoom virtual whiteboard.
What’s the area of an equilateral triangle ? Volume of a sphere? Sorry. Haven’t needed to use that in eons. I usually just google it.
Unpopular opinion: I like technical interviews. They at least enforce some form of a standard hiring bar.
I feel this way because I've seen hiring for non-technical roles, e.g., project management, etc. They basically end up being friends hiring friends, with minimal domain expertise.
Most technical interviews aren't technical. You are expected to know irrelevant trivia like which port does ICMP use? There's literally no job on earth where that matters.
So when I did technical interviews; I had a demo domain controller vm. I printed out 5 steps they need to do. dcpromo, slave domain.local to the dc, install wsus. pretty boring stuff that much candidates know how to do. My trick, there's lots of tiny details like did you get the server's name instead of SERVER-1897237534
Oh and I'll be talking about video games, tv and movies distracting you as much as possible during the testing. I just sit there asking them question after question about hobbies. Really really distracting.
Sadly there is another side to this - by not doing any kind of technical assessment you expose yourself to fraud. I would have never expected that in the past, but after nearing a hundred interviews I saw a few cases of a candidate's skills as judged by code samples looking completely different once they were writing code on the spot. The exercises were all related to real tasks. I don't think we'd have caught on through product or problem-solving questions.
There's a real performance downgrade when performing in front of people. To add more accuracy to your assessment I would give these people the opportunity to perform in a room without someone watching.
So I've always wondered about these leetcode interviews, having never suffered one myself, if you're given one you've seen before, are you still supposed to pretend you're working it out from first principles?
Others may disagree, but I think if you haven't seen the problem before (or a close variant), chances are that you won't be able to finish it during the interview (unless it's an easy problem). FAANG interview a lot of people and the bar is high. You're competing with people who completed tons of leetcode problems.
When I started practicing leetcode, I underestimate the amount of work to be ready (they say that you should solve 100 problems, I think it's much higher, but obviously some guys are smarter than others...).
That being said, I'm 50-75% of myself during an interview. I managed to fail at questions that I did several times before.
The experience is also different from one interviewer to the next. You can have a guy who asks an easy question, provides help, and still give very positive feedback because he was happy with the way you communicate and explain your algorithm. Then you can have an interviewer (usually more junior ones) who asks a "trick" question that there's no way of solving if you havent' seen it before.
I don't know what the interviewers expect, but, generally, your "reward" for admitting you've seen the problem before is a harder question to answer. It seems more in the candidate's interest to pretend to work out the solution than to be honest.
Yeah, I've been asked a lot of leetcode questions and always pause for a couple minutes before the answer hits me in a "brilliant" stroke of insight. This con works really well.
You need to get advanced level tactics like one of my past coworkers. He told me he would purposefully go down the wrong path with a problem - to only later have "divine inspiration" just before the interviewer would interrupt him and try to give him a hint... He would raise his hand and exclaim, "But, maybe!" And then promptly explain and solve the problem.
It was at this point that I realized I have no chance of getting into FAANG when I'm playing low-level tactics like just trying to just solve two medium problems in <40 minutes with the most optimal answer. :( (Or 1 hard problem in 30-35 minutes)
Long time ago I go the "Why is a manhole cover round?" at an interview. I prefaced that I heard this question before and followed up with 3-4 possible answers. The interviewer was still impressed.
It's clichéd question, but in my opinion it's a very good one and would still be useful if it wasn't so overused. The reason why is because there's one big reason why manhole covers are round and maybe 3-4 subsidiary and less important reasons why. A person who can 1/ identify that there's more than one reason, name them all and 2/ sort and rank the reasons correctly in order of importance reveals a person's clarity of thought and reasoning process.
The standard practice is for the interviewer to explicitly ask the candidate whether or not they have seen the question before.
More frequently than one would expect, the candidate will deny having seen the question before, zip through the solution, and then completely stall-out when they are asked to revise their solution to accommodate a very small alteration is made to the problem parameters.
I want to work with engineers that know their basic algorithms. Sorry, but complicated projects require smart solutions. If you don’t know the basics, you won’t be able to solve difficult problems efficiently.
YC2025 - "home.ly" - we aim to disrupt the remote technical interview process by replacing capricious human interviewers with the latest conversational AI leet-bots...
If we aren't complaining about interviews where we got the offer and turned it down, there's a serious risk we're experiencing "sour grapes". Every interview I failed was an opportunity to get better. If it feels arbitrary and you don't get the job... you may just be below the bar. No shame in that... buy there's definitely shame in this sadly common framing attack on the concept of the tech screen.
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)