Most common mistakes during interviews
aitorvs.github.io
aitorvs.github.io
Most normal developers. Spending you time on leetcode means you want to get in a faang. Most people are going for other roles.
I was honestly taken a back. These companies aren’t known for “high” standards and make up for the lack of interesting work with WLB (or at least it comes across like that.
Just like how everyone copied google Qs a decade ago (how many toothpicks can a tree yield...). I’m fully expecting everyone to copy FAANG like interviews because someone in HR thinks it might signal better hires, and why wouldn’t you want better hires right?
Companies that wouldn't have leetcoded you 5, 10, years ago are now doing so. The difficulty of leetcode questions is going up too.
Also, takehome problems are becoming more common - not instead of leetcode interviews, but in addition to.
Examples: run length encoding problem or a bit extracting/setting question. I want to see if the candidate can formulate a simple state machine and they understand bit manipulation. I target the bit manipulation questions for firmware/embedded software roles, which very much involves reading and setting bits from hardware registers all day long.
If the interview is the same, you are better off working at some one who pays better. As a side effect eventually there could across the board better pay.
Has complexity or efficiency ever come up in a team discussion? Nope. Do we have use for high efficiency solutions at scale? Not particularly. But we judge candidates on it.
Not only that - I often see atrocious code. Stuff like comparing boolean expressions against true/false. Stuff that makes me question basic competence of the person writing it.
I do this sometimes if it makes the code clearer. Sometimes it's not 100% clear if you're just coming in that a function returns a boolean. Sometimes you just want to remind yourself and it sneaks past a code review. I've been coding for 20 years across a dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript). Sometimes null is false, sometimes it's not, sometimes an empty string is false, sometimes it's not.
Any compiler, JIT, optimizer etc. will completely ignore the comparison anyways so there's 0 runtime issue with it.
I'd argue the function isn't named appropriately, then.
> Sometimes you just want to remind yourself and it sneaks past a code review
Remind yourself what, exactly?
> dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript)
I'd argue that it's on the developer to know and work with the language's semantics (and I say this as someone who's not a fan of JS). Trying to write code that is nearly language agnostic in semantics will leave out a whole lot of language-specific value.
Maybe yes, maybe no. The point is that adding "== true" makes it more clear and should therefore be done.
As do I, the above poster is just super judgemental and probably not a lot of fun to work with.
An observation I've had over the years is that often times developers will come to conclusions that they ought not to. The idea that typing out "== false" indicates you don't understand bools is a non-sequitur.
if not (x > 5)
if (x > 5) == false { .. ]
Why would it matter if a function returned a boolean? It's either compared for truthiness, or the comparison for truthiness or compared for truthiness, even in the most dynamic languages.
Functions are not always consistent about returning a Boolean either. Bad design/naming, but you work with what you have got.
I think some classes were not mandatory in school, or people hated that class.
I will sometimes compare against true/false, it doesn't mean I don't understand boolean logic, it means I feel like it's more clear.
It could also be that I'm in a language with truthy values and I specifically only want to compare to real boolean values.
You really need to stop and ask yourself why you're so judgemental about code. Because that's a you problem, not a them problem.
If I ever had a co-worker try and tell me I don't understand boolean logic because I felt like typing it out was more clear I'd laugh in their face.
It’s visual noise. This isn’t an issue with truthiness either. I’m talking normal java code. Where if I see an if-statement, clearly the thing inside doesn’t need comparison against true or false unless you want to add another comparison just for fun and mental gymnastics.
Are you young or early in your career? I think the extra verbosity is something you come to appreciate the “the hard way” over the years.
There's cases where this might make sense (when things like truthiness are unclear). But in any of the cases I've seen, it's where things are pretty obvious and even when things are explicitly boolean types.
Write the boolean expression and if it doesn't fit or has lots of parts, define them separately above the conditional with clear names.
People seem upset by this, but idk it seems like common sense.
I'm not sure I understand how `if (someCondition == true) {...}` is preferable to `if (someCondition) {...}`
Idk this is just my experience with disorganized code and unclear.
No one is upset, they simply disagree with you...
Maybe avoid trying to dismiss people and look at what they're actually saying? There are things you put in code that others are unfairly judging you for.
something something glass houses.
Response 1: I thought it would be clearer with the explicit comparison. (fine, then you can bring in your own opinion and maybe have a nice discussion)
Response 2: You don't need == true? I never knew. (bad)
Another common scenario that is complained about: using `this` with instance variables when it's technically unnecessary.
if ((conditional == true) == true)
A lot of it is just them not really interviewing much so they Google how to interview developers and think about questions they were asked.
Start with your observation.
While I'm currently not working (for money, anyway) I'm fortunate to be in a position to not have to look for work. That could change, of course (for example, if the SCOTUS strikes down the ACA I'll need to find a job with insurance). Just thinking about interviewing in this current environment makes my stomach tie up in knots. But for now, I'll be over here working on my own interesting problems.
1) is something that I abhor because it allows the interviewer to assume very little of the responsibility for communication, which is an exercise for both people to come to a consensus of what the task is at hand. Instead of saying "did I communicate this effectively", it's saying "it's the listener's fault for not understanding me."
2) is very similar to 1) in that it also absolves the interviewer of any responsibility for communicate. It's also an absurd proposition because it's saying it is the interviewee's job to keep me, the interviewer, entertained. This is absurd because the purpose of interviews is to vet a candidate, if that's not the purpose, then the interviewer should make it more clear that an hour's worth of a jester's time is being requested.
3) is specifying a criteria that might make sense for recent college graduates or if the candidate knows what to prepare for. In my experience, no such guidance is typically given, the most I've seen is "prepare for questions that might be relevant to the role/job posting." The interviewer fails to consider does he/she have a full time job? Did the interviewer actually provide materials for he/she to study? If the questions the OP cited were not actually provided, how do they know to prepare for those types of questions.
I think you're taking an overly unfair view of what the author meant.
We know what's wrong with that statement in this climate.
That's a non-sequitur.
The problem is that customers, PMs, and managers often don't communicate clearly either. Being able to ask the right clarifying questions is part of being a software professional. It's completely fair for new grads to lack that skill but experienced people should have developed it.
I completely agree on 2 and 3 though. Guess some people have become so used to the status quo that leetcode no longer seems like an aberration.
Exactly. One of my favorite interview challenges is to write an input validation that checks for a valid SSN. The actual code should be pretty trivial for a competent programmer; but the real test is if they ask for what "valid SSN" means (123-45-6789, 123456789, 123 45 6789, all of the above?) If they jump right to the code based on an assumption, without even thinking or asking about it, that signals that they're likely to make such assumptions in the field.
Developers have this really bad habit of coming to conclusions that don't actually follow from the premise.
The fact that they made the assumption that an SSN would be input exactly the way it's always input everywhere is not indicative that they would make dangerous assumptions elsewhere.
If someone were to bring that up to me I'd probably laugh at them and tell them to write an extra function to normalize the input first and pass that off to the validation function because they're separate concerns.
Because that's exactly what I would do, assume it's in the typical format. And if it came to light that the SSN had to be normalized, I'd normalize it at the edge of the system rather than making my validation function more complicated by giving it concerns that are unrelated to validation.
Which means you wouldn't hire me, despite my 24+ years of experience building software.
2) you're conflating "engaged" and "entertained". If you're engaging the interviewer then they can help guide you when you're going astray. If you're not the chances of them realizing you're headed down the wrong path decreases.
3) how is the candidate's current employment status relevant to their preparedness? The things listed in the article are the kinds of things you can expect to encounter at most technical interviews. You can expect to be asked about a project you've worked on, you can expect to be asked about data structures and algorithms, you can expect to be asked about software development best practices. If you were interviewing to be a barista would you need to be told to expect to answer questions about coffee?
If you'd hire people based of how much they could lift, you'd see how the smart, driven, competent people coming in suddenly have much bigger muscles.
The system is never broken. You are broken for failing to adapt to it. If you fail to adapt to it, there are hundreds willing to take your place.
Interviews are two-sided auditions.
If there was a genuine talent shortage as we keep hearing about, the asymmetry would be the other direction; while it would still be two-sided, the bigger burden would be on the interviewer as the representative of the prospective employer to impress the prospective employee.
If that is the case, then it's possible that a broken system could end up coming into existence in a company that:
- has a revolving door of expensive attrition
- loses all the good talent so that ones that remain aren't good at their jobs
- slowly ossifies into place
- can't seem to get things done
- eventually loses its customers
- loses market position, growth and relevance
- becomes a bankrupted carcass eventually stripped for parts by a distressed asset firm
Sounds familiar? I agree that if you fail to adapt to the system, there are hundreds willing to take your place. But where we may disagree is whether I'd envy any of them. I'll tell you one thing, though -- I've never had to sacrifice my career trajectory to just put up with this kind of nonsense. In fact, the places I've had to put up with it the most are the places where I've grown the least and leaving opened up a much better opportunity afterwards.
At the end of the day, all tech companies compete with each other to hire people who exhibit a growth mindset and show strong signs of perseverance. That's why they give you challenges to overcome on the spot. Past experience will help you start higher-up on the ladder, if you get an offer, but it won't mean crap if you can't demonstrate your willingness to push through the challenges.
You're only holding yourself back if you dismiss advice instead of welcoming any and all tips and tricks to improving your chances.
[0] https://80000hours.org/podcast/episodes/will-macaskill-moral...
I have a hard time following this conclusion - how do you know this?
This comment represents everything that is wrong with your technical interview process. Big yikes.
The lack of self-awareness displayed by that comment is kind of impressive. Especially the bit about being so keen on identifying "bad" candidates, not realizing that the entire point is that interviewers are actively bad at determining good vs bad candidates.
That's the entire point, you don't, you only think you do.
I think a lot of companies have deluded themselves into thinking they've designed some sort of unique interviewing system that can guarantee good job performance (instead of reducing the incidence of catastrophically bad performance), but honestly, job performance itself is very hard to measure in any objective way once you disregard the extremes.
Just because a misused tool is bad at doing the thing you're misusing it for doesn't mean that it doesn't have utility when used for its actual purpose.
Algorithm quizzes aren't the only way to reduce false positives. Can we say definitively that they are the best?
There's probably a place for practical programming tests, too, but whiteboarding algorithms and such seems to be more of a fraternity hazing/secret handshake ritual than anything else. Good if the skill you need to hire for is "Read and memorized 'Cracking the Coding Interview'", not really indicative of anything else.
I would appreciate it if companies finally acknowledged that interviewing is a two-way street.
I have cancelled way more interviews due to red flags happily waved by companies than companies have rejected me because I failed one of the 8 algorithms questions.
https://aitorvs.github.io/post/most_common_interviewer_mista...
Let me cherry-pick an example: You mention that you don't read a candidate's CV before your one interaction with them (the technical interview). As you say, this is a debatable choice (I find it somewhat acceptable).
At that point, has anyone else at your company read the candidate's CV and cover letter? Sounds stupid, but you would not believe how many people ask about specific topics ("So have you worked with a relational database before?") not in order to ask deeper questions about knowledge or experience, but just in order to tick off checkboxes on their HR form. (This is not made up, this has actually happened to me.)
This bigger issue of a company never asking themselves "How do we as a company show that we actually give a shit about each candidate, and are not just looking for a butt in an office chair" is where in my experience, lots of companies are still completely failing at self-reflection.
My understanding is that this situation happens as a test to see that you were the one that wrote your resume.
Thanks for the insight!
In that context, I think it's a great question:
> given a list of numbers, return two numbers such that one times the other results in 220
It's highly plausible that at some point in the candidate's career, a nontechnical coworker or manager will use nontechnical language to ask them to do something technical, and they'll need to ask for better specification.
A candidate who smart-assedly ignores the input list and returns the numbers 10 and 22 is demonstrating that they assume the asker is an idiot not even worth the time to ask clarifying questions. The candidate has messed up priors: what is the chance that the only piece of information provided in the question is utterly irrelevant? The candidate is also prone to unilaterally making assumptions that reduce their workload, possibly while smugly patting themselves on the back for Kobayashi-Maruing their way past the idiotic interview question. That's bad.
A candidate who has a modicum of social intelligence would reasonably assume that the asker expects them to limit their consideration to the given list (otherwise what's the goddamn point?). Even then, there are ambiguities, which the article rightfully points out you should ask about.
If I was given that question it would be a red flag.
1) it’s a stupid algorithm question similar to what I saw in high school, 2) it’s poorly worded and nonsensical.
Depending on what I know about the company I may or may not give them the benefit of the doubt. In most cases it’s safer to assume the interviewer (and by extension the team) is just not competent.
It stands to reason that if you rejected this question in an interview with the complaint that it was "poorly worded and nonsensical" (I put it to you that it's a perfectly meaningful question), instead of taking the constructive route by asking clarifying questions, this would probably count as a red flag to the employer about you. So again, the question would effectively inform both parties in this case that they are not mutually compatible.
you wanting the company to acknowledge that its a two-way street is evidence that it's not. It's very rare.
> I have cancelled way more interviews due to red flags happily waved by companies than companies have rejected me
You can boycott a business too if you don't like it, but that doesn't make it a two-way street. You have very little leverage over the business.
Yes I can? I can walk away from the interviewing process. They have invested in recruiting just as much if not more than I have in interview prep.
Their employees are paid just the same for technical interviews than their normal work.
The exception being candidates skilled at a rare niche, then it's stacked in your favor.
Your mileage might greatly vary.
I've only encountered companies that struggle to hire good people (so they end up not hiring many people at all, not enough to keep up with growth) and companies that struggle to hire good people (so they end up hiring everyone that passes Fizzbuzz and can't keep up their quality).
But then this is an insular market (Switzerland) where there are tens of thousands of unfilled positions.
To me parent’s point is that any company acting as if you’d unconditionally accept their offer if they made one is a recipe for failure.
I think I confused "two-way street" to mean an equal-sided transaction.
If you are interviewing to have an alternative to another offer, you might effectively dictate the process (time spent, deadlines etc.) if they want to interview you bad enough. And I’ve been on the receiving end as the recruiting company’s interviewer, pitching the job to get a favorable answer.
Same if you don’t have any pressure to leave your current job.
Sure big companies sometimes won’t have any leeway to deal with these candidates, that’s also why they get avoided by people who have the choice, and everyone’s happy.
Yes, "think out loud" is better than being completely silent, but given that many hiring decisions are based on how the interaction feels, including the quality of the communication _in order to assess thinking skills_, candidates can see huge returns by learning specific communication techniques.
I make videos on this topic (technical and non-technical interview and negotiation skills), and happened to have just made a video on what to say while writing code:
It did leave one gap though - it assumes my handwriting is legible! Many companies (at least pre-COVID) still expect people to hand write code on a whiteboard, under immense time pressure Most people aren't used to writing on a whiteboard, and many interview rooms inexplicably have a combination of large markers and a small whiteboard, which often leads to my output being of marginal readability. Narrating what I'm writing can help move past that.
I think there was a combination of things that straight away disposed me negatively towards it - the negative title (stop X!), the negative introduction (stop x, again) and also the camera being so close to your face. It had the effect of feeling like I was being simultaneously negged and mansplained to by some overly aggressive dude (no doubt more an artifact of my own life experiences more than the video. Stop telling me what to do, Dad.). It felt very you-tube, but like, the uglier parts. I stopped watching pretty quickly.
Glancing at your profile, it seems like you have a number of videos titled "Stop X". I'm noting here that you describe this video as "a video on what to say while writing code." There's a clear value prop there: What to say when writing code! But it doesn't exactly come through in the first exposure to the video. I'd watch a video on "what to say while writing code" because I have my own opinions on it, and am interested in comparing my mental model with someone else who's spent time thinking about good communication in a coding context. Feeling scolded by said video made it a solid pass.
I think I read something purporting to be research about how closeup pictures on faces tend to elicit stronger emotional reactions.
I did like that you were modeling perspective taking - "your interviewer is a programmer who can read your code." Building a capable theory of mind is long term work, and it's work that people who are drawn to computers often don't do.
Anyways, thanks for sharing it, and taking the time to make those videos. It seems like a worthy project.
I tend to avoid it except things that are "obvious" but I tend to forget, like you know - there's SOLID and everybody understands it differently and applies it differently, I never remember the theory behind it.
I believe going without preparation means that you're "pure" - you're talking only about stuff you know or understand, not just seen 10h ago on some blog.
When it comes to questions I really love open questions like design something or try find security issue
This is valuable for yourself as well, because you can avoid places where the role they have in mind for you doesn't fit your expectations
When you prepare for the behavioural questions, give answers of real situations that you are very familiar with, and avoid "keyword soups". I've seen quite a few candidates failing interviews because they gave almost canned answers that seem to hit all the right points, but once you dig deeper they aren't able to elaborate more.
I've already been employed for several years at different places, doing a whole range of things, and it's weird that I have to practice some arbitrary exercises in order to demonstrate to a company that I can work. This has led to me landing at companies that don't require the bizarre jumping-through-hoops that filters for the desperate and "committed".
And so far, I've not only yet to see interview-style programming on the job, I've seen utterly atrocious practices.
If I could it my way, I'd start with a 30-minute briefing session on the coding test that's to follow. 1-1.5 hour coding project - implement an API or something. 45 minutes where you review some code (maybe intentional bad code). 1 hour writing a design document. 1 hour presenting the design doc to a couple of team members. Couple of behavioral sessions with team members/manager.
There are fieldS with more complicated knowledge than tech/CS that don’t put their candidates through this type of interview process. Not doctors, nor lawyers, nor scientists and engineers (electrical/mechanical/civil).
The technical interview process is absurd on its very premise, and should be outlawed.
I don't make use of any of the algorithmic skills I was interviewed on, but I do have to push through stressful situations regularly and make progress in a timely fashion. I do think that if I weren't able to do that during an interview situation, I wouldn't have been able to do that on the job.
Maybe I wouldn't have any stress in my current position if I were 10x smarter or 10x more experienced/knowledgable, but that would also indicate that I were underleveled.
I'm certain there are many smart and skilled individuals that wouldn't be able to consistently make it past a tech interview loop unless they put in lots of "unnecessary" extra work.
You mean like everyone else in (almost) every single job ever? Do you think developers at inferior companies just sit around blissfully typing away with half of their brains shut off?
Those interview processes say practically nothing about candidate’s fit/performance for the job. This has been shown to be true many times. The awkward hoops put in place just result in the interviewer having ample convenient opportunities to turn down a candidate for any reason. Like maybe in the back of their mind, deep deep down inside, they actually don’t want to hire that black person who just wasted weeks or months of their life grinding useless leetcode questions.
> Like maybe in the back of their mind, deep deep down inside, they actually don’t want to hire that black person who just wasted weeks or months of their life grinding useless leetcode questions.
That's a reason to push for standardized interviews with objective questions, so you decrease the effect of interviewer bias and focus on candidate performance.
There's definitely something to be said here though about increasing the knowledge of how to get into top tech companies for disadvantaged groups, because I don't think it's common knowledge.
This is a giant red flag :
I do have to push through stressful situations regularly and make progress in a timely fashion
Also based on the same argument, its kind of obvious your hiring process at all levels isn't working.
1) not screening the company during the interview 2) not preparing by doing "warm-up" interviews for roles you won't be too sad about if you don't get 3) not doing enough interviews to get multiple offers for negotiating leverage
For my first point, you'll learn a lot about the company and how they work from the interview process. If the company has dysfunctional elements to its corporate culture, depending on the size, it's quite likely they'll be surfaced here. Not only is this one of the first impressions of you for them, but it's one of the first impressions of them for you. Pay attention to what your gut and intuition tell you here. Every time I've broken this rule, it's bitten me.
For my second point, I think that people often forget that the only way to get better at interviewing is to just do it over and over again. It's a little hard to do that in a synthetic environment because it's hard to trick your brain into behaving as if it is real unless it actually is. But wait, you may say, treating an interview like practice is unethical! But I'd disagree. After all, if you really do well on the interview but you're not chomping at the bit to join, they might be more willing to negotiate and make you an offer that would make you reconsider. But, you likely know (and can force-rank) the roles you'd be most willing and least willing to take if you had the opportunity, so make sure to go through the sequence from least desirable to most desirable so that you have more leverage.
My third point is probably the most crucial. You need the BATNA (best alternative to negotatiated agreement) of accepting something else or staying where you are to be able to negotiate. Otherwise, you have much less leverage. This is part of why timing and interviewing for less desirable roles is preferable, because you are more likely to negotiate with an offer for your more desirable role by the time you get there.
Can you offer any advice or resources on what to ask or watch out for in this area?
Beyond company fit, there needs to be team fit (and proximally manager fit) and role fit. A lot of this depends on size, too. Company fit is going to be really important if you're anywhere early. But beyond a size, it matters a whole lot less than manager+team.
For the latter, you have to work with the team and manager on something to get a sense of what their style is and whether you'll clash. Try and find some way to talk about a problem as if it's a real world scenario, and see how easy it is to intellectually collaborate towards a solution. Does it feel natural or no? Would you trust this person enough to work with them for 8H+ a day? Keep this in mind as you compare offers.
But it's hard. You can only discern so much, and this stuff is really easy to fake in an interview. You see different shades of people once you really have to rely on them in the dint of production. This is part of what makes warm intros so powerful -- if you've worked with someone you trust and respect before, and they've worked with someone they trust and respect before, it's more likely that you and that other person will transitively be compatible. Move too far outside that transitivity and you're taking existential risks. This is why it's not always a bad thing to move around a bit more in your earlier career -- it can open up your second degree circles a bit more once you hit mid career.
A common example is to fill the CV with buzzwords and when asked about them, the knowledge varies from shallow to non existent.
Reality: shift-entered my way through an interactive tutorial in Google Colab's free tier like I was button-mashing a videogame combo
Ugh. I'm going through the interview process right now and this peeves me so much
The presumption that I, the supplicant, need to be interesting and keep the interviewer, who has deigned to give me 30 minutes of their time (often 23 minutes because, "sorry I'm late but I also have a hard stop at the top of the hour") "engaged" makes the interview so lopsided, awkward, and just nonproductive
That being said: > Not preparing for the interview
Is completely legit. I have walked out of a couple of interviews wishing I had prepped a little bit more so that I could make the conversation a productive one
In real-world problems I almost always think of corner-cases. So I think that the interview process is flawed - at least in my case - by assuming that not asking about specifics generalizes.
In general, if the interview process is designed in a way that reading a random article like this on HN helps you pass it, I'm kind of skeptical how well it's measuring future job performance.
[1] https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
It's a bit like saying the NBA shouldn't discriminate against short people. At the end of the day, the best performers tend to not be short, that's just reality.
In the same way that anxious people tend to struggle in an interview. Obviously you shouldn't be going out of your way to discriminate, but the reality is what it is.
NBA scouts evaluate how players perform in real games. Most tech interviews are nothing like the job.
Many countries require employers to reasonably accommodate people with disabilities. Not going out of your way to discriminate isn't enough.
This is a great clarifying question. Ambiguous from the prompt.
> what shall I return if there are multiple numbers meeting the criteria
This is a decent clarifying question. I think it is better expressed as a clarifying point instead of question--mention to the interviewer your thinking out loud; something like "if there are multiple options, I'll return an arbitrary pair". Ask if they are okay with that.
> is the list sorted
If I were the interviewer, this question would almost make me dock points off of the interviewee. Maybe not that strong as I do try and ensure people are as comfortable and open as possible in asking clarifying questions, but this barely qualifies as a clarifying question in my opinion. It is almost irrelevant to the prompt; if the lists were sorted and the interviewer failed to mention / there was some "trick" that they expected you to clarify, that would be an awful interview question.
That being said, overall agree with the sentiment and yes you should try and always ask clarifying questions and ensure you understand the problem statement.
One of my first internships was punching in 10 meter reams of dot matrix printed numbers.
After several days, during lunch, I casually mentioned how much easier it would have been if the list was electronic.
They said that it was electronic, they just printed it out "for my convenience" so I wouldn't have to constantly keep switching between two apps.
They gave it to me on a floppy, and with the help of an Excel macro I finished two weeks worth of work by the end of the day.
While these whiteboard questions obviously aren't designed to have wider context, I now always appreciate when candidates question the question itself.
(EDIT: after thinking about this more than two seconds, the quadratic algorithm for unsorted input can become n log n by sorting the list, though that takes linear space. This would certainly be a clarifying question.)
The other questions would be less obvious to me, though I'd encounter them while thinking more than 2 seconds about the problem, I suppose.
Or maybe this just outs me as an ex-amateur competitive programmer :)
Just because you can ask a question whose answer makes a drastic difference between the best algorithm involved, doesn't mean it is a good question.
(and note I said "_almost_ make me dock points...". And if the answer to the question was "yes, the list is sorted", I would _certainly_ dock points off of the interviewer/company if I were the interviewee for not giving that context).
Not for a total of 220!
I like the follow up question of "what if they are floats?" to see if the interviewee knows not to use `==` with floats.
> > is the list sorted?
> this barely qualifies as a clarifying question in my opinion.
Maybe I'm being too charitable but whether or not the list is sorted is very relevant to the first solution that came to my mind as I read the problem.
for i from 1 to n:
for j from i+1 to n:
prod = a[i] * a[j]
if prod == 220:
# found it
if prod > 220:
break
# don't waste time, assumes sortedAnother "clarifying question" in this vein would be "if there is a valid answer, will they be in index 0 and 1 of the list?"
I'm obviously being somewhat facetious here but there's a difference between clearing up an ambiguous part of the question versus asking something that the interviewer gave no indication would be part of the problem.
If I were the interviewer, this question would almost make me dock points off of the interviewee
Why? Knowing that can be a useful filter to reduce the search time and space, assuming whole numbers only.
If the answer is yes the input is sorted, then that context should have been given in the original prompt as it is a completely different question.
Not saying “I don’t know” when you clearly don’t know the answer to a question.
Try to ask: how many exercises do you have to solve, and how many parts does the current exercise have.
I've always wondered why they don't somehow all me to demonstrate this before it gets to an interview. Let the candidates winnow themselves out. It could be so easy, it should work, but they don't. IDK, perhaps it works only in theory.