11 ms·

Common problems I see in technical interviews

49 points by leeny 6y ago

Khelavaster 6y ago
Not a good look for the founder of interviewing.io: "I’ve been coding for a pretty long time. Since 1982, actually. There’s no data structure called 'a grouping' in any language I’ve ever used. So what assumptions are you going to make about the problem?" But--there's absolutely a data interface in C#/.Net called "a grouping". It's fundamental to LINQ: https://docs.microsoft.com/en-us/dotnet/api/system.linq.igrouping-2 https://docs.microsoft.com/en-us/dotnet/api/system.linq.igro... Shameful to spread the idea that software developers haven't created an industry-standard interface for groupings of enumerable data in 2020.
- ludamad 6y ago
  Is it that shameful? He chose his words as carefully as anyone should, he said in languages he used. And indeed, a "grouping of numbers" is pretty ambiguous even if you know this exists. It could just mean an array or something more nuanced
- onion2k 6y ago
  Why are you ignoring the "in any language I’ve ever used" part of the quote?
- travisjungroth 6y ago
  The post isn’t by the founder.
lifeisstillgood 6y ago
>>> correct a design when you have 100 lines of Java code written before I really understand Holy Cow. 100 lines in an interview ? I had an interview like that once and never again. Want to see 100 lines of my code - github.com/mikadosoftware. In an interview - no thanks Look we all know interviewing is broken. Hell I have worked with people for months before getting to know them and their coding styles. I think ultimately we are all being a bit too privileged about this : Hiring has three states, acquaintance, friend, spouse. Some people are not skilled enough to be a work collegue - fizzbuzz and 20 minutes chat tell us that - we all know people who after 20 minutes we think we will pay money to avoid the next 20. Fine Friends are harder - we gel in some fashion. This is the mid point for most of us - as long as we pass fizzbuzz / basic design, then we can make things work. Yes it might have friction but we can make it work. Spouse is obviously the perfect level - that ideal together. I fear that far too much effort is put into finding the perfect spouse in an interview - when really we can be fine with a friend. (no benefits!) When hiring set your sights lower ...
- ionwake 6y ago
  fizz buzz In my head I just think - Bro why are you asking me to paste code I can memorise? I use this to figure out which jobs I don't want. It's not the best metric but its worked ok so far.
  - raverbashing 6y ago
    Seconded If you ask me about fizzbuzz I'll complain. Or maybe try to do it in a quirky way You should have addressed if the candidate knows how to write basic code in the phone interview, not wasting my time with a stupid problem on a whiteboard
    - lifeisstillgood 6y ago
      >>> Or maybe try to do it in a quirky way Fantastic - you have just shown an ability to play with code, indicating you are likely to be good at the basic part of the job. Honestly "fizzbuzz" is short hand for "eliminate the set of people who apply for every coding job, but have no ability to code, or can only just take existing code and twist it about" (this last I used to think was laziness, but I think there is an ability to execute code in your head that is necessary - and if you can't do that then making any changes to a code base is scary because you cannot reason about it.) Do I use fizzbuzz anymore? No because it has been years since I have had to go "out to market" - but if I am interviewing you then I will have checked you pass this - reading your code, talking to co workers. I don't go in cold very often any more.
      - ionwake 6y ago
        But you are also eliminating those that "feel" its a question that should not be asked to experienced developers that would otherwise be excellent hires. I seem not to be the only one. (im not saying Im right in this)
        ProZsolt 6y ago
        Till you found somebody with 10+ years of "experience" who can sell himself well. We skip this question because of seniority. Hire him and turns out he struggles with basic for loop. This happened at my previous company.
choeger 6y ago
Quote: Your algorithm will likely be an O(n^2) (n-squared) algorithm because you’ll be iterating over the data in an exponential way End of quote. Ok, so the technical interviewer mixes up exponential and polynomial run-time in a blog post about interviewing. Can you spot what's wrong with interviewing in SE?
- deleted 6y ago
  [deleted]
- dvt 6y ago
  God, this is just painfully embarrassing. It's a real shame we -- as an industry -- haven't pushed back against these kinds of practices (maybe the pay is just too good). At this point, technical interviews are just a meme.
  - ende 6y ago
    Organize. Lobby our legislators. Put that money to use.
    - neonate 6y ago
      Because someone conflated exponential and quadratic?
  - michaelt 6y ago
    I've seen people successfully get interview formats changed - even in companies with a thousand developers. So if you're thinking of advocating for changes, a single enthusiastic person can often get it done! Of course, you can only ever change interview processes you've already passed and you'll never have to pass again - so many people focus their attentions elsewhere.
- mping 6y ago
  That doesn't change the general idea of the post in any kind, although I generally agree that SE interviews are kinda borked. Still, most companies that interview somewhat thrive despite having a far from optimal process.
timdaub 6y ago
Skimmed over the article: Oh, commom problem areas have nothing to do with the skill of coding but only with the skill of being a good interviewe. Kk thx bye
- dang 6y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." Don't be snarky." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - timdaub 6y ago
    Well, if you don't see the deep ciriticism of technical interviews that I'm try to point out, that's ur view.
    - dang 6y ago
      Your deep criticism of technical interviews is welcome! But if you want to share it, you need to do that explicitly, so the rest of us can follow what it is. It's quite common that people post 1% of what is in their mind (often in a snarky way) and assume that they expressed all of it. Then when others respond badly to the snark or totally misinterpret what they meant, it seems weird (or they seem obtuse) because you felt you expressed yourself. Actually that feeling depends on your already knowing the content of your mind and your past experiences—which the rest of us don't. We need it to be laid out explicitly and step-by-step in order to get it and respond meaningfully. That would be interesting. When you do that, though, please do it without snark—we have that rule for a bunch of reasons.
yakshaving_jgt 6y ago
The common theme in this article seems to be about planning approaches to and implementing algorithms. I think there's more to being a successful employed programmer than that. How do you avoid people who are nice as pie in the interview, but play politics and are rude to people under your nose on the job? How do you avoid people who can deploy algorithms on demand, but have very little motivation day to day and fail to get anything substantial done? At a job, you're interacting with people every day. I don't think you're looking for the best-performing algorithm every day. In most cases, best performance doesn't matter.
alanfranz 6y ago
So, a developer should learn what an interviewer wants (actually what this interviewer wants) because it's the "right thing to do". What about sharing expectations and the way the dev will be evaluated with them beforehand?
taywrobel 6y ago
Disclaimer that I work server-side. This is not applicable to all of software engineering by any means, but if you want a more technical answer than those the article provides: concurrency. It's 2020: computers have multiple cores, and it's great to know how to use them, but time and time again I see candidates get tripped up with basic concurrency concepts. Deadlocks in go, event loop blocking in node.js, unsafe memory access in Java or C, they come up all the time in interviews I've done. "Track the median value in a stream of integers"? No problem. Clean code, no errors. "Track the median value of two streams of integers which are coming in concurrently"? Data loss, deadlocks, concurrent modification exceptions... Sad times. I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion. Every language has libraries of data structures already written, but concurrency solutions are often context specific and need handwritten solutions.
- scollet 6y ago
  > concurrency solutions are often context specific and need handwritten solutions. Wanted to second this as it sounds like a great design problem. I personally love reasoning about concurrency models.
- petargyurov 6y ago
  > I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion. You are right, that is hard. Especially in an interview setting. But I 100% agree that it's better than questions about algorithms.
- newswasboring 6y ago
  I recently delivered a big project which was parallelizing a huge computation. I entered the project all gung ho thinking I'm using a high level language (MATLAB) how hard can it be? Turns out very hard, specially if you want to maintain state and operate the parallel computing toolbox even slightly different from the examples. Please recommend the book I wish I had read before jumping in?
- yoyonamite 6y ago
mkl95 6y ago
Interviews reveal much more about a company's culture than interviewers seem to be aware of, and this one is telling me there's a bunch of managers at this company who get away with their lack of organization. If I'm treated like this at an interview I'm going to assume it's the kind of company where seagull managers write tickets with confusing titles and no descriptions, and expect developers to do their job.
vorhemus 6y ago
I increasingly feel that coding interviews are primarily a company's marketing tool ("Look, we have such high barriers to entry, we're exclusive!") rather than real reviews of software engineering skills.
petargyurov 6y ago
The best interview I've had was at my previous job as a backend engineer. After the first two culture-fit interviews I had a technical interview with the lead dev and the CTO. There were no programming tasks. It was a 3-tiered conceptual question on designing a backend system. They asked me how I would do this and that. How would I handle this edge case? What if the user did this? What if the data was shaped like this? I don't think I even did that well in it, but it was the most enjoyable interview process I have had.
Seb-C 6y ago
> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.” > Interviewers want to know what’s going on in your thought process. It’s important that they know how you’re making decisions. How are you qualifying or disqualifying ideas? Why are you choosing to implement something in a particular way? Did you spot a potential problem in your code? What was it? That is a very good way to hire people that are good at interviewing or selling themselves, not so much for very good developers. Speaking loudly about every tiny decision you take for simple algorithms is very hard and inefficient. It is even worse when you have a lot of experience, because you just know which designs will be wrong or not without even thinking twice about it. It is okay to expect communication about the overall design, specifications, input, outputs and behavior, not about the algorithm itself. If spoken human languages were efficient at expressing this kind of thoughts patterns, we wouldn't have invented mathematics notation or programming languages. > “I wonder if … hmm … well, I was thinking about implementing this as a depth-first-search, but given a constraint around ___ I think a better approach might be ___, what do you think?” If you have this kind of expectations, you are again hiring people that are good at interviewing, that is all. I have been a developer for 15 years and I don't know how most of the basic algorithms are called in English, because it is not a useful vocabulary in my everyday work. I make specific algorithms to efficiently solve specific problems. I do not blindly copy patterns from Stack overflow or from a book. I would not know what is a "depth-first-search" unless I start searching and looking for some code in Google either.
- heavenlyblue 6y ago
  You are not hiring me so that I would explain every design decision to you; you are hiring me so that I would deliver solutions about the details of which you do not have the capacity/do not want to think.
ChrisMarshallNY 6y ago
The one thing that struck me, was all the problems were with the interviewee, not the interviewer. I gave up looking for work, when I realized that it was my job to throw the seed into the interviewer’s nest. ”God gives every bird its food, but He does not throw it into the nest." -J.G. Holland I was a hiring manager for 25 years. Hiring people was always a huge commitment. I had to fight like hell for every headcount, and I kept high-end engineers for decades. I wasn’t just interviewing workers; I was interviewing family. I could usually determine basic engineering (not just “coding”) skills after a half hour, and without having to write a single line of code. A big reason for that, was because I worked hard to maintain my own engineering chops throughout my management career, and that helped me to relate well with prospects. Most of the interview was about whether or not the employee would strengthen or weaken the team. Whether they would be conscientious and disciplined in their approach; whether they would be enthusiastic and spend time learning the why of a task, as opposed to just the what. I was interviewing really senior-level engineers. These were people that would need to write high-performance pipeline code, and most of the prospects had no experience in that particular field. I needed to hire people that would learn new algorithms and techniques. Enthusiasm, flexibility, humility, and open-mindedness were the currency; not rote and bluster. I also wanted them to know what they were getting into. I wouldn’t ever lie to prospects, and that probably cost me a few, but I wouldn’t want to establish a relationship on sand. I loved what I did, and wanted people that would also love it. I’m not egotistical, but I am confident in my own engineering (there’s that word again) skill and experience. I don’t demand worship, but I want some simple respect. If you won’t give that to me in an interview, then why should I expect it from you, once you have the free milk? I have had many friends that have left their jobs; uprooted their lives, and headed for greener pastures, only to come back, a few months later, humbled and broken. If you are interested in me, then you are interested in someone that can make an enormous difference in your company. I’m not God’s gift to programming, but I have a unique mix of skills and experience that could really give your effort a big push. I’m also a damn decent person, which becomes obvious after a fairly short conversation. I interview well. But I test badly.
- rimliu 6y ago
  Run away from any company that thinks they are family.
lentil_soup 6y ago
>> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.” I can either think OR talk, I can't do both at the same time. I can happily think and THEN talk but when I've interviewed with companies that have this interview culture (i.e. Google) they don't let you do this. They start telling you they want to hear what you're thinking. Also, most of the time thinking is disjointed and nonsensical and is way faster than what you can express so it's actually disrupting the problem solving. I really don't understand what's wrong with letting people think for a few minutes. Additionally I am perfectly fluent in English and talk code everyday in English but it's not my mother tongue so having me chit-chat my thinking away while I think (potentially in another language) hinders me since I focus more on what I am saying than actually solving the problem. >> "My typical work process in a technical challenge like this is to spend a minute or two thinking quietly about the problem and writing down notes, I’ll share those thoughts with you in a moment to get your input" That's great, but that hasn't been my experience. Interviewers constantly tell you to talk and it's specially bad during a phone interview. I'd be fine if the interview was really setup as a collaboration between two people, but it's not, you're given a problem and a whiteboard.
- legerdemain 6y ago
  I'd talk more in code interviews if more interviewers behaved the way these essays say. I struggle to recall a time when the interviewer acted as a collaborator during the interview. Usually, they'll pose the task, sit back, and stare at you. You ask a clarifying question, but you know you're stalling for time. The task is clear. You just need to remember the LeetCode solution. The interviewer looks at you impatiently. You take a stab at describing the solution. You say, "I think this is a job for prefix trees," and look at the interviewer. The interviewer says, "OK," and gives you a look of alarm and pity. You solve the problem the way you've solved ten very similar problems on LeetCode. The interviewer says, "Are you sure this works the way you think it does?" You panic. What did you do wrong?! The interviewer gives you another look of pity. If you're writing live code, you run it with some test cases. The test cases pass. You think of some edge cases. They pass too. You look at the interviewer. The interviewer says, "OK." A moment elapses. A few days later the recruiter calls you and extends you a verbal offer. Or they send you an email that says that you won't be getting an offer. The interviewer's expression of pity is the same in either case.
lmilcin 6y ago
As an interviewer I wholeheartedly agree with this. I think most egregious problems are: 1) candidates assuming that I am only interested in them producing a solution 2) candidates assuming that I am interested in checking their knowledge of the language or standard library In fact, the process is mostly what I am interested in and I am pretty happy to give hints and especially when it comes to trivia like what is the name of the function that does some specific thing and what kind of parameters it takes. I just would like to see how the candidate approaches and deals with the problem. Does he/she have analytical, planned, ordered approach or is everything chaos? High on my list of things that don't impress me is solving the problem by running the code dozens of times. This shows the person cannot write any stretch of the code without running it because he/she does not actually have a mental model of what is going on and relies on actually running the code as a crutch for their lack of understanding.
- kioleanu 6y ago
  If I understand correctly what the guy says in the article, his candidates lose points if he gives them hints. And about running the code often, what's the problem with getting early feedback? There are people (that I agree with) that run the unit test on the code they're writing every added line or two. Some who also commit every line or two and then squash the commits once the whole "unit" is done. By no means does this mean they don't know what's going on
  - lmilcin 6y ago
    There is no single right way to conduct an interview. Each interviewer has his own style and I think it is fine. I think giving the candidate a hint has a purpose and that is to keep the process of finding a solution progressing. Otherwise the candidate may get stuck and as an interviewer this is bad because we are now wasting time to let me know the candidate. At the very beginning I tell the candidate some of the things that I feel are fine or not fine. For example, I will tell the candidate that I am happy to give out names of functions and lists of parameters as long as the candidate can describe exactly what the function is doing. So I give these for free because in normal work I would expect he/she can find it in couple of seconds on the internet, anyway, and that's also how I do this. What I don't give for free (ie. mentally deduct points for) is give larger hints that would normally be thought as part of the solution. Likewise, when I start technical question section I tell candidates that "I give 5 points for not answering the question". Most people are quick enough to figure out this means I penalize bad answers and would prefer the candidate to say they don't know something rather than keep talking nonsense.
josephg 6y ago
A lot of people are badmouthing this article. I think thats unfair. There seem to be some broad misconceptions as to why current technical interviews are designed the way they are. (I speak with the experience of administering over 400 technical interviews.) First, you have to understand that most candidates who apply for a technical position don't really know how to program. The obvious reason for this is that weak candidates spend more time trying to be hired, and thus they apply for far more jobs than qualified candidates. I'd estimate about half the people who apply for an advertised software engineering position can't program something as simple as fizz buzz. Many of these people are lovely humans, have families to support and are depressed from being turned down from job after job. But if you can't program, I can't hire you for a programming role. And for everyone who's competent, I get it. Simple programming problems are a waste of your time. But as an interviewer, I need to quickly differentiate you from someone who spent 3 days watching python videos on youtube then forked some random repositories into their github account. As an interviewer, I'm really trying to answer this question: If I put you in a team of programmers, would you be able to meaningfully contribute? If you want to know how to land your dream job, take a minute to brainstorm which what qualities would make you effective in the role you're applying to. Then demonstrate those qualities in an interview. Your list will look almost identical to mine - be proactive, have good communication skills, know how to program, know the domain (web / ios / ...), etc. If you can't demonstrate a skill in the interview, your interviewer will assume its because you don't have that skill. This is a reasonable assumption and - despite all the grumbling in these threads - usually true. Most people who fail interviews either have poor technical skills or poor communication skills or both. If your interviewer can't tell the difference between you and the mountain of disappointing candidates they're drowning in, its your job to figure out why thats the case and fix it. If you apply for a frontend web position but you can't tell me what a CSS selector is, its not the fault of "the system" when you don't get hired. Lots of folks here are convinced technical interviews are fundamentally broken. I still haven't seen any fairer way to assess programmers that can filter out the flood of weak applicants. If you think technical interviews are broken, I challenge you to suggest a viable alternative. Please - prove me wrong!
bra-ket 6y ago
the best interview would be to pair interviewer and interviewee on a random leetcode problem otherwise it's mostly just a power trip for the interviewer and a lousy signal. oh, and people who like problem #19 on project euler shouldn't be interviewing humans. In fact programmers should not be interviewing other programmers at all, it's not their job.
- MauranKilom 6y ago
  > In fact programmers should not be interviewing other programmers at all, it's not their job. In a scenario where a programmer leads a team of programmers, why shouldn't they get a say in who will be on the team? Who else would be in a better position to judge team fit? Or aptness at the daily tasks?

49 points by leeny 6y ago

Not a good look for the founder of interviewing.io: "I’ve been coding for a pretty long time. Since 1982, actually. There’s no data structure called 'a grouping' in any language I’ve ever used. So what assumptions are you going to make about the problem?" But--there's absolutely a data interface in C#/.Net called "a grouping". It's fundamental to LINQ: https://docs.microsoft.com/en-us/dotnet/api/system.linq.igrouping-2 https://docs.microsoft.com/en-us/dotnet/api/system.linq.igro... Shameful to spread the idea that software developers haven't created an industry-standard interface for groupings of enumerable data in 2020.

ludamad 6y ago
Is it that shameful? He chose his words as carefully as anyone should, he said in languages he used. And indeed, a "grouping of numbers" is pretty ambiguous even if you know this exists. It could just mean an array or something more nuanced
onion2k 6y ago
Why are you ignoring the "in any language I’ve ever used" part of the quote?
travisjungroth 6y ago
The post isn’t by the founder.

lifeisstillgood 6y ago

>>> correct a design when you have 100 lines of Java code written before I really understand Holy Cow. 100 lines in an interview ? I had an interview like that once and never again. Want to see 100 lines of my code - github.com/mikadosoftware. In an interview - no thanks Look we all know interviewing is broken. Hell I have worked with people for months before getting to know them and their coding styles. I think ultimately we are all being a bit too privileged about this : Hiring has three states, acquaintance, friend, spouse. Some people are not skilled enough to be a work collegue - fizzbuzz and 20 minutes chat tell us that - we all know people who after 20 minutes we think we will pay money to avoid the next 20. Fine Friends are harder - we gel in some fashion. This is the mid point for most of us - as long as we pass fizzbuzz / basic design, then we can make things work. Yes it might have friction but we can make it work. Spouse is obviously the perfect level - that ideal together. I fear that far too much effort is put into finding the perfect spouse in an interview - when really we can be fine with a friend. (no benefits!) When hiring set your sights lower ...

ionwake 6y ago
fizz buzz In my head I just think - Bro why are you asking me to paste code I can memorise? I use this to figure out which jobs I don't want. It's not the best metric but its worked ok so far.
- raverbashing 6y ago
  Seconded If you ask me about fizzbuzz I'll complain. Or maybe try to do it in a quirky way You should have addressed if the candidate knows how to write basic code in the phone interview, not wasting my time with a stupid problem on a whiteboard
  - lifeisstillgood 6y ago
    >>> Or maybe try to do it in a quirky way Fantastic - you have just shown an ability to play with code, indicating you are likely to be good at the basic part of the job. Honestly "fizzbuzz" is short hand for "eliminate the set of people who apply for every coding job, but have no ability to code, or can only just take existing code and twist it about" (this last I used to think was laziness, but I think there is an ability to execute code in your head that is necessary - and if you can't do that then making any changes to a code base is scary because you cannot reason about it.) Do I use fizzbuzz anymore? No because it has been years since I have had to go "out to market" - but if I am interviewing you then I will have checked you pass this - reading your code, talking to co workers. I don't go in cold very often any more.
    - ionwake 6y ago
      But you are also eliminating those that "feel" its a question that should not be asked to experienced developers that would otherwise be excellent hires. I seem not to be the only one. (im not saying Im right in this)
      - ProZsolt 6y ago
        Till you found somebody with 10+ years of "experience" who can sell himself well. We skip this question because of seniority. Hire him and turns out he struggles with basic for loop. This happened at my previous company.

choeger 6y ago

Quote: Your algorithm will likely be an O(n^2) (n-squared) algorithm because you’ll be iterating over the data in an exponential way End of quote. Ok, so the technical interviewer mixes up exponential and polynomial run-time in a blog post about interviewing. Can you spot what's wrong with interviewing in SE?

deleted 6y ago
[deleted]
dvt 6y ago
God, this is just painfully embarrassing. It's a real shame we -- as an industry -- haven't pushed back against these kinds of practices (maybe the pay is just too good). At this point, technical interviews are just a meme.
- ende 6y ago
  Organize. Lobby our legislators. Put that money to use.
  - neonate 6y ago
    Because someone conflated exponential and quadratic?
- michaelt 6y ago
  I've seen people successfully get interview formats changed - even in companies with a thousand developers. So if you're thinking of advocating for changes, a single enthusiastic person can often get it done! Of course, you can only ever change interview processes you've already passed and you'll never have to pass again - so many people focus their attentions elsewhere.
mping 6y ago
That doesn't change the general idea of the post in any kind, although I generally agree that SE interviews are kinda borked. Still, most companies that interview somewhat thrive despite having a far from optimal process.

timdaub 6y ago

Skimmed over the article: Oh, commom problem areas have nothing to do with the skill of coding but only with the skill of being a good interviewe. Kk thx bye

dang 6y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." Don't be snarky." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- timdaub 6y ago
  Well, if you don't see the deep ciriticism of technical interviews that I'm try to point out, that's ur view.
  - dang 6y ago
    Your deep criticism of technical interviews is welcome! But if you want to share it, you need to do that explicitly, so the rest of us can follow what it is. It's quite common that people post 1% of what is in their mind (often in a snarky way) and assume that they expressed all of it. Then when others respond badly to the snark or totally misinterpret what they meant, it seems weird (or they seem obtuse) because you felt you expressed yourself. Actually that feeling depends on your already knowing the content of your mind and your past experiences—which the rest of us don't. We need it to be laid out explicitly and step-by-step in order to get it and respond meaningfully. That would be interesting. When you do that, though, please do it without snark—we have that rule for a bunch of reasons.

yakshaving_jgt 6y ago

The common theme in this article seems to be about planning approaches to and implementing algorithms. I think there's more to being a successful employed programmer than that. How do you avoid people who are nice as pie in the interview, but play politics and are rude to people under your nose on the job? How do you avoid people who can deploy algorithms on demand, but have very little motivation day to day and fail to get anything substantial done? At a job, you're interacting with people every day. I don't think you're looking for the best-performing algorithm every day. In most cases, best performance doesn't matter.

alanfranz 6y ago

So, a developer should learn what an interviewer wants (actually what this interviewer wants) because it's the "right thing to do". What about sharing expectations and the way the dev will be evaluated with them beforehand?

taywrobel 6y ago

Disclaimer that I work server-side. This is not applicable to all of software engineering by any means, but if you want a more technical answer than those the article provides: concurrency. It's 2020: computers have multiple cores, and it's great to know how to use them, but time and time again I see candidates get tripped up with basic concurrency concepts. Deadlocks in go, event loop blocking in node.js, unsafe memory access in Java or C, they come up all the time in interviews I've done. "Track the median value in a stream of integers"? No problem. Clean code, no errors. "Track the median value of two streams of integers which are coming in concurrently"? Data loss, deadlocks, concurrent modification exceptions... Sad times. I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion. Every language has libraries of data structures already written, but concurrency solutions are often context specific and need handwritten solutions.

scollet 6y ago
> concurrency solutions are often context specific and need handwritten solutions. Wanted to second this as it sounds like a great design problem. I personally love reasoning about concurrency models.
petargyurov 6y ago
> I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion. You are right, that is hard. Especially in an interview setting. But I 100% agree that it's better than questions about algorithms.
newswasboring 6y ago
I recently delivered a big project which was parallelizing a huge computation. I entered the project all gung ho thinking I'm using a high level language (MATLAB) how hard can it be? Turns out very hard, specially if you want to maintain state and operate the parallel computing toolbox even slightly different from the examples. Please recommend the book I wish I had read before jumping in?
yoyonamite 6y ago

mkl95 6y ago

Interviews reveal much more about a company's culture than interviewers seem to be aware of, and this one is telling me there's a bunch of managers at this company who get away with their lack of organization. If I'm treated like this at an interview I'm going to assume it's the kind of company where seagull managers write tickets with confusing titles and no descriptions, and expect developers to do their job.

vorhemus 6y ago

I increasingly feel that coding interviews are primarily a company's marketing tool ("Look, we have such high barriers to entry, we're exclusive!") rather than real reviews of software engineering skills.

petargyurov 6y ago

The best interview I've had was at my previous job as a backend engineer. After the first two culture-fit interviews I had a technical interview with the lead dev and the CTO. There were no programming tasks. It was a 3-tiered conceptual question on designing a backend system. They asked me how I would do this and that. How would I handle this edge case? What if the user did this? What if the data was shaped like this? I don't think I even did that well in it, but it was the most enjoyable interview process I have had.

Seb-C 6y ago

> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.” > Interviewers want to know what’s going on in your thought process. It’s important that they know how you’re making decisions. How are you qualifying or disqualifying ideas? Why are you choosing to implement something in a particular way? Did you spot a potential problem in your code? What was it? That is a very good way to hire people that are good at interviewing or selling themselves, not so much for very good developers. Speaking loudly about every tiny decision you take for simple algorithms is very hard and inefficient. It is even worse when you have a lot of experience, because you just know which designs will be wrong or not without even thinking twice about it. It is okay to expect communication about the overall design, specifications, input, outputs and behavior, not about the algorithm itself. If spoken human languages were efficient at expressing this kind of thoughts patterns, we wouldn't have invented mathematics notation or programming languages. > “I wonder if … hmm … well, I was thinking about implementing this as a depth-first-search, but given a constraint around ___ I think a better approach might be ___, what do you think?” If you have this kind of expectations, you are again hiring people that are good at interviewing, that is all. I have been a developer for 15 years and I don't know how most of the basic algorithms are called in English, because it is not a useful vocabulary in my everyday work. I make specific algorithms to efficiently solve specific problems. I do not blindly copy patterns from Stack overflow or from a book. I would not know what is a "depth-first-search" unless I start searching and looking for some code in Google either.

heavenlyblue 6y ago
You are not hiring me so that I would explain every design decision to you; you are hiring me so that I would deliver solutions about the details of which you do not have the capacity/do not want to think.

ChrisMarshallNY 6y ago

The one thing that struck me, was all the problems were with the interviewee, not the interviewer. I gave up looking for work, when I realized that it was my job to throw the seed into the interviewer’s nest. ”God gives every bird its food, but He does not throw it into the nest." -J.G. Holland I was a hiring manager for 25 years. Hiring people was always a huge commitment. I had to fight like hell for every headcount, and I kept high-end engineers for decades. I wasn’t just interviewing workers; I was interviewing family. I could usually determine basic engineering (not just “coding”) skills after a half hour, and without having to write a single line of code. A big reason for that, was because I worked hard to maintain my own engineering chops throughout my management career, and that helped me to relate well with prospects. Most of the interview was about whether or not the employee would strengthen or weaken the team. Whether they would be conscientious and disciplined in their approach; whether they would be enthusiastic and spend time learning the why of a task, as opposed to just the what. I was interviewing really senior-level engineers. These were people that would need to write high-performance pipeline code, and most of the prospects had no experience in that particular field. I needed to hire people that would learn new algorithms and techniques. Enthusiasm, flexibility, humility, and open-mindedness were the currency; not rote and bluster. I also wanted them to know what they were getting into. I wouldn’t ever lie to prospects, and that probably cost me a few, but I wouldn’t want to establish a relationship on sand. I loved what I did, and wanted people that would also love it. I’m not egotistical, but I am confident in my own engineering (there’s that word again) skill and experience. I don’t demand worship, but I want some simple respect. If you won’t give that to me in an interview, then why should I expect it from you, once you have the free milk? I have had many friends that have left their jobs; uprooted their lives, and headed for greener pastures, only to come back, a few months later, humbled and broken. If you are interested in me, then you are interested in someone that can make an enormous difference in your company. I’m not God’s gift to programming, but I have a unique mix of skills and experience that could really give your effort a big push. I’m also a damn decent person, which becomes obvious after a fairly short conversation. I interview well. But I test badly.

rimliu 6y ago
Run away from any company that thinks they are family.

lentil_soup 6y ago

>> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.” I can either think OR talk, I can't do both at the same time. I can happily think and THEN talk but when I've interviewed with companies that have this interview culture (i.e. Google) they don't let you do this. They start telling you they want to hear what you're thinking. Also, most of the time thinking is disjointed and nonsensical and is way faster than what you can express so it's actually disrupting the problem solving. I really don't understand what's wrong with letting people think for a few minutes. Additionally I am perfectly fluent in English and talk code everyday in English but it's not my mother tongue so having me chit-chat my thinking away while I think (potentially in another language) hinders me since I focus more on what I am saying than actually solving the problem. >> "My typical work process in a technical challenge like this is to spend a minute or two thinking quietly about the problem and writing down notes, I’ll share those thoughts with you in a moment to get your input" That's great, but that hasn't been my experience. Interviewers constantly tell you to talk and it's specially bad during a phone interview. I'd be fine if the interview was really setup as a collaboration between two people, but it's not, you're given a problem and a whiteboard.

legerdemain 6y ago
I'd talk more in code interviews if more interviewers behaved the way these essays say. I struggle to recall a time when the interviewer acted as a collaborator during the interview. Usually, they'll pose the task, sit back, and stare at you. You ask a clarifying question, but you know you're stalling for time. The task is clear. You just need to remember the LeetCode solution. The interviewer looks at you impatiently. You take a stab at describing the solution. You say, "I think this is a job for prefix trees," and look at the interviewer. The interviewer says, "OK," and gives you a look of alarm and pity. You solve the problem the way you've solved ten very similar problems on LeetCode. The interviewer says, "Are you sure this works the way you think it does?" You panic. What did you do wrong?! The interviewer gives you another look of pity. If you're writing live code, you run it with some test cases. The test cases pass. You think of some edge cases. They pass too. You look at the interviewer. The interviewer says, "OK." A moment elapses. A few days later the recruiter calls you and extends you a verbal offer. Or they send you an email that says that you won't be getting an offer. The interviewer's expression of pity is the same in either case.

lmilcin 6y ago

As an interviewer I wholeheartedly agree with this. I think most egregious problems are: 1) candidates assuming that I am only interested in them producing a solution 2) candidates assuming that I am interested in checking their knowledge of the language or standard library In fact, the process is mostly what I am interested in and I am pretty happy to give hints and especially when it comes to trivia like what is the name of the function that does some specific thing and what kind of parameters it takes. I just would like to see how the candidate approaches and deals with the problem. Does he/she have analytical, planned, ordered approach or is everything chaos? High on my list of things that don't impress me is solving the problem by running the code dozens of times. This shows the person cannot write any stretch of the code without running it because he/she does not actually have a mental model of what is going on and relies on actually running the code as a crutch for their lack of understanding.

kioleanu 6y ago
If I understand correctly what the guy says in the article, his candidates lose points if he gives them hints. And about running the code often, what's the problem with getting early feedback? There are people (that I agree with) that run the unit test on the code they're writing every added line or two. Some who also commit every line or two and then squash the commits once the whole "unit" is done. By no means does this mean they don't know what's going on
- lmilcin 6y ago
  There is no single right way to conduct an interview. Each interviewer has his own style and I think it is fine. I think giving the candidate a hint has a purpose and that is to keep the process of finding a solution progressing. Otherwise the candidate may get stuck and as an interviewer this is bad because we are now wasting time to let me know the candidate. At the very beginning I tell the candidate some of the things that I feel are fine or not fine. For example, I will tell the candidate that I am happy to give out names of functions and lists of parameters as long as the candidate can describe exactly what the function is doing. So I give these for free because in normal work I would expect he/she can find it in couple of seconds on the internet, anyway, and that's also how I do this. What I don't give for free (ie. mentally deduct points for) is give larger hints that would normally be thought as part of the solution. Likewise, when I start technical question section I tell candidates that "I give 5 points for not answering the question". Most people are quick enough to figure out this means I penalize bad answers and would prefer the candidate to say they don't know something rather than keep talking nonsense.

josephg 6y ago

A lot of people are badmouthing this article. I think thats unfair. There seem to be some broad misconceptions as to why current technical interviews are designed the way they are. (I speak with the experience of administering over 400 technical interviews.) First, you have to understand that most candidates who apply for a technical position don't really know how to program. The obvious reason for this is that weak candidates spend more time trying to be hired, and thus they apply for far more jobs than qualified candidates. I'd estimate about half the people who apply for an advertised software engineering position can't program something as simple as fizz buzz. Many of these people are lovely humans, have families to support and are depressed from being turned down from job after job. But if you can't program, I can't hire you for a programming role. And for everyone who's competent, I get it. Simple programming problems are a waste of your time. But as an interviewer, I need to quickly differentiate you from someone who spent 3 days watching python videos on youtube then forked some random repositories into their github account. As an interviewer, I'm really trying to answer this question: If I put you in a team of programmers, would you be able to meaningfully contribute? If you want to know how to land your dream job, take a minute to brainstorm which what qualities would make you effective in the role you're applying to. Then demonstrate those qualities in an interview. Your list will look almost identical to mine - be proactive, have good communication skills, know how to program, know the domain (web / ios / ...), etc. If you can't demonstrate a skill in the interview, your interviewer will assume its because you don't have that skill. This is a reasonable assumption and - despite all the grumbling in these threads - usually true. Most people who fail interviews either have poor technical skills or poor communication skills or both. If your interviewer can't tell the difference between you and the mountain of disappointing candidates they're drowning in, its your job to figure out why thats the case and fix it. If you apply for a frontend web position but you can't tell me what a CSS selector is, its not the fault of "the system" when you don't get hired. Lots of folks here are convinced technical interviews are fundamentally broken. I still haven't seen any fairer way to assess programmers that can filter out the flood of weak applicants. If you think technical interviews are broken, I challenge you to suggest a viable alternative. Please - prove me wrong!

bra-ket 6y ago

the best interview would be to pair interviewer and interviewee on a random leetcode problem otherwise it's mostly just a power trip for the interviewer and a lousy signal. oh, and people who like problem #19 on project euler shouldn't be interviewing humans. In fact programmers should not be interviewing other programmers at all, it's not their job.

MauranKilom 6y ago
> In fact programmers should not be interviewing other programmers at all, it's not their job. In a scenario where a programmer leads a team of programmers, why shouldn't they get a say in who will be on the team? Who else would be in a better position to judge team fit? Or aptness at the daily tasks?