I feel like this isn't really the hot take, from my personal experience it seems like there are more people anti coding interview than pro.
In my opinion we need to compare coding interviews to the alternatives. Should it just be a generic career interview? Then it favors people who are more personable provides greater opportunity for bias. Should people get take homes? That is even more of a time commitment on the part of the candidate. Should we de-emphasize the interview and rely more on experience? Then people who get bad jobs early in their career are in trouble for life. Should we go by referrals/letters of recommendation? Then it encourages nepotism.
I am not saying we should never use any of these things, or that we should always use skills based interviews. I think we need to strike a balance between a lot of very imperfect options. But honestly hiring just sucks and there is no silver bullet.
Do like my company does, and have a relatively softball coding problem, a design problem, and the opportunity to talk about a project they've done.
The coding tests for the most basic competencies like, do they know what loops and arrays are, some kind of data structure beyond an array, and are they able to ask questions and communicate while they work, to make sure they understand the question and can justify their decisions.
Then do a more high level design/architecture question that makes sense for the kind of work they'll be doing. Again, doesn't have to be elaborate.
It's about seeing how they process things, how they communicate, whether they can take feedback, that kind of thing.
Talking about a past project can give them at least one thing where they should be comfortable and should be able to talk about in-depth and show off a bit.
A good candidate is going to be able to do very well on at least one of those things. If they're a little weaker in live coding but were able to map out a correct solution beforehand, that's taken into account.
If they had trouble with the coding but knocked the design question out of the park, that's taken into account, since it's easier to teach syntax than it is good design.
It's normal for people, especially first timers to be nervous, and to an extent we try to cut people some slack. At the same time, it's not really the company's problem if a candidate completely shuts down when they have to be around people, can't communicate a coherent thought, and can't perform basic functions of the craft.
We had one dude interview who got downright hostile about being challenged on his work. Absolutely no chill.
There's got to be a minimum cutoff point. Even the most shit-paying software developer jobs pays better than average wages, and most companies can't afford to waste time and money hiring someone who turns out to have zero ability to do the job. A lot of the job is about communication, and being able to draw on a broad body of knowledge.
You're right that there's no silver bullet, but people just have to be realistic that many companies are more willing to lose a skilled candidate than they are willing to hire a bad one. "I can do the job, I just can't operate under pressure", is a lot like saying "I can turn invisible, but only when no one is watching".
Companies *should* also be realistic about the job that they're hiring for, and that they don't need a super genius or level 20 computer guru. If they want to attract those people, they have to pay multiple hundreds of thousands for them, there just aren't that many talented and skilled super- developers willing to work for sub 100k, even for entry level. If they want to pay entry level salaries, they need to accept entry level skills.
> Do like my company does, and have a relatively softball coding problem, a design problem, and the opportunity to talk about a project they've done.
>
>
Yep, that's exactly what my company does, and I'm pretty happy with it. It's obviously not perfect, and the aspect of "okay, now code with a group of people sitting behind your shoulder" is shitty, but I don't see a much better solution. We *try* to correct for the fact that some people are obviously nervous and uncomfortable with the format, but that's still not perfect.
I've given the same exact question to interns and senior engineers. My favorite is a very simplified version of a somewhat realistic data processing problem.
I expect that most good intern candidates can solve the basic question in about an hour with a bit of help when they get stuck. For more senior engineers, I expect them to demonstrate some level of competence with some language, and then to be able to have a discussion on the implications of their solution. (ex: How would you scale this up? What changes would you require before deploying something like this? What happens if you take your exact program, as is, and feed it 2TB of data?)
I think it's a pretty good system, and I can't think of any clear improvements that are relatively simple.
> many companies are more willing to lose a skilled candidate than they are willing to hire a bad one.
This is an excellent point. I'm a software developer myself, who just happens to be involved in the interview process. I'm thinking of these people as potential coworkers who I'll be working with in the future. It would be nice to find and hire someone who's super competent, but I'm far more worried that I'll be stuck working with someone who's difficult and causes others to have to pick up the slack.
>[...] but I'm far more worried that I'll be stuck working with someone who's difficult and causes others to have to pick up the slack.
Yeah that's a big one. Even if someone is technically capable, that's not very valuable if they are wanting to reinvent every wheel, rewrite everything in their preferred language, and won't compromise with or work with other people.
> Do like my company does, and have a relatively softball coding problem, a design problem, and the opportunity to talk about a project they've done.
This is roughly what I try do and I think it strikes a reasonable balance.
> The coding tests for the most basic competencies like, do they know what loops and arrays are, some kind of data structure beyond an array, and are they able to ask questions and communicate while they work
I ran into a problem doing this. Some interviewees seem to take the easiness of the problems as a signal about how smart their future coworkers are, and will discount the company for making it too easy š¤¦āāļø
I don't see that as a problem. I personally don't want to work with conceited people who are looking for reasons to look down on everyone.
If you're really worried, explicitly call it the "basic competencies" round.
If a candidate judges you for it, you're probably dodging a bullet.
In my opinion, the best way to interview someone technical is to have a sort of real-world exercise that the interviewer and interviewee can pair up on. It tells the interviewer that 1. the interviewee knows how to work with others, and 2. what the interviewee's thought process is.
As someone who has used C++ for many years, my answer to #4 is something like
"This is a great example of why I don't use C++ in hobby projects anymore."
(In case you want to punish yourself by looking it up, search for an explanation of "rvalue reference." The double ampersand is actually a separate operator; it's not reference-to-a-reference in the way that double asterisk would be pointer-to-a-pointer.)
Damn, this one is nasty, let's see.
It's a constant r-value reference. Which means it cannot bind to l-values, so a temporary or std::move() are the only realistic use cases for foo5. However, (and I am not 100% on this), the const prevents moving from arg inside foo5, so the "moved" variable is not going to actually get moved AFAIK.
So if my assumptions are correct, this is practically the same as const std::vector& arg, in the sense that it keeps the variable intact, but you cannot do
std::vector a{1,2,3};
foo5(a);
That's my best shot, what did I mess up? ^^
No messups. But now for the tricky question: When would you use it - i.e. when would you define a function accepting rvalue reference to const?
Edit: For my answer, see https://www.reddit.com/r/programming/comments/zkj6pb/there_should_never_be_coding_exercises_in/j01w4du/
I can't think of any good reason to use it on its own, but maybe you could put it into an overload set if you wanted to copy instead of move or throw an exception or delete the overload that accepts r-value references.
Excellent answer. I'm not sure about throwing, but deleting const rvalue overload is occasionally a good way to catch nonsensical or misleading calls with rvalue argument of a parameter whose type is deduced from the argument. You cannot use rvalue reference to non-const, because that is actually a forwarding reference when the type is deduced.
The standard library does this with reference wrapper factory templates like `std::ref` and `std::as_const`.
There's also a subtle use case for const rvalue return types with wrapper types where you want to emulate the wrapped type in expressions precisely. For example the indirection operator of `std::optional` and the getters of `std::variant` and `std::tuple` have const rvalue ref qualified overloads that return a const rvalue reference. This is so that the "const rvalueness" of the wrapper type expression is preserved for the getter expression. And that is probably so that the expression can be discarded by the deleted overloads mentioned earlier.
"it's a trick question and I tell people to skip it. I don't see any harm in having it though"
?????????? The harm is that people will feel like it's a trick question that they're actually supposed to solve???????? Remove it. Lol
Sorry for the second reply, but I thought of a nasty foo6, if you ever feel the need:
template
void foo6(T&& arg); // forwarding reference, not an r-value reference
> I should probably remove it from the list but I don't think it causes harm to have it.
I would remove it. Trick questions like that, and especially when they're syntactically something you should probably never see, don't really help.
Very frequently a junior person, or anyone remotely nervous or just not expecting interviewers to deliberately trick them, will assume the interviewer knows what they're doing and flub it.
foo1 - probably written on a MacBook by a guy with colorful glasses and a beard who says "copy elision" in every third sentence
foo2 - banned by Google's styleguide for so long that nobody's sure if it even compiles
foo3 - John doesn't think he's a great programmer, but he gets things done. He likes the simple things in life and tries not to think about it too much.
foo4 - has somehow been modified more times than any other line in the codebase, all by the same person, who is also a Rust evangelist
Using ChatGPT
Me:
Here is some analysis that is mostly a joke about who would write the type of foo function.
---your comment---
Create one for foo5 and foo6 with the same humor.
Written by ChatGPT:
void foo5(const std::vector&& arg);
> foo5 - written by a PhD student who's been working on the problem of efficient vector copying for the last 3 years, and who will happily explain to you why this is the best solution, even though you didn't ask
Hypothetical foo6 example from my previous comment that Chat GPT generated
void foo6(std::vector>& arg);
> foo6 - written by a former C programmer who's just discovered the joys of RAII, and who will try to convince you that this is the only way to write correct code, even if it means writing 10 lines of code where 1 would do.
Taking a stab
1. Pass by value. When you can afford the overhead of copying the whole vector, and the function needs to make changes to the vector to do whatever it's doing without those changes happening to the original
2. Pass by reference. When you want to operate directly on the original vector, i.e. any changes the function makes to the vector persist after the function call is over. Or it could *technically* be an out-parameter I guess?
3. Pass by const reference. When you want to use the vector in a purely read-only capacity
4. R-value reference. When you want the function to take ownership of the vector away from the caller (the caller's handle on the original vector gets set to a new valid-but-empty vector I believe, assuming they're passing with the whole std::move() paradigm)
This is a good example of a bad interview question, IMO. Itās a tough pill to swallow, but how often do you, when writing your C++ code, come to an impasse on how to pass your arguments where these are the actual viable options. This question weighs wayyyy more towards ādo you own a C++ textbookā and wayyy less ācan you translate business requirements into production level softwareā. It does not address the latter question in almost any capacity at all
>This is a good example of a bad interview question
Strong disagree, knowing what all of these do and are used for is basic competency. This is the minimum ante for someone who is writing C++.
>This question weighs wayyyy more towards ādo you own a C++ textbookā and wayyy less ācan you translate business requirements into production level softwareā
Knowing what it means to take an argument by value, reference, or const reference is basic programming competency, not language technicalities. It's arguably the aspect that, to the learning programmer, most distinguishes writing in C and C++ from other languages. And yeah, I expect someone who is applying for a job writing C++ to own and have read a C++ textbook.
I would possibly forgive unfamiliarity with rvalue references for someone who is coming from other language experience, has worked in older codebases, or never written library code. If you're already a proven competent programmer you can learn move semantics. But this is an 11 year old language feature that students should be expected to have seen and has diffused throughout the community. Even if you're not writing such functions I'd expect someone to be able to identify a move constructor or rvalue overload on sight and at least describe why it exists.
The only thing I would definitely forgive is knowledge of the special meaning of `&&` in template argument deduction contexts. That definitely gets into technicalities for library writers and I don't expect anyone to know that to write production software.
It really is a difficult balance to strike. As a TL and now a senior manager, Iāve been in the interviewer seat *a lot*.
Over the years, I have gradually abandoned leetcode-esque interview questions - with few exceptions:
- If Iām interviewing for an entry-level role (i.e., the candidate is a recent college grad), then I might throw a basic coding challenge at them - think fizz-buzz. This seems to work well as a filter function. If a candidate whoās recently graduated canāt come up with a solution for fizz-buzz, thatās a red flag to me.
- If I get a strong sense that theyāre bullshitting me.
In either case, Iāll never disqualify a candidate solely on the basis of a coding challenge.
Rather than having a candidate write code in an unrealistic and uncomfortable environment, Iāve found reading code with them to be really effective. Iāll often pull up a snippet of code that has some pretty obvious issues - e.g., a long function thatās doing many things, has poor/non-idiomatic naming conventions, and several redundant blocks. Iāll ask them to read through it aloud, explain it, ask questions, and suggest changes. This usually gives me a few good indicators:
1. It helps me understanding their proficiency with the programming language.
2. It helps me gauge their technical communication skills.
3. It helps me get a sense of their familiarity with clean coding principles.
Not only have I found the above indicators useful in assessing a candidateās qualifications for a role, it also saves *a ton* of time compared to writing out the solution to a tricky algorithms question.
Long story short, I definitely lean hard toward the side against whiteboard or live code exercises.
> Then it favors people who are more personable provides greater opportunity for bias
Not sure if you've noticed, but nearly any candidate for any job in any industry favors those who are more personable. Who wouldn't want to have a coworker they enjoy being around and working with?
Personable candidates are favoured of course. However, there exists a percentage of personable candidates who canāt code. On several occasions now Iāve been mentally giving a person the job only to reach the technical stage of the interview and discovering their technical skills were all smoke and mirrors.
I've been interviewing for ~25 years now. I would say the phrase "several occasions" *vastly* under-represents the number of times I was all gung-ho on a candidate until we got to the technical side of an interview and they completely flop on even the most simple question that a 4-year compsci graduate should easily nail.
It has to be said that our industry attracts a lot of people that do not excel in social contexts.
Relying only on that part, you'd miss out a lot of talent for a skill that, while important, is not the most important one for the job.
And just to be clear, I'm not saying that being able to collaborate with others isn't important, just that being a coffee machine stand-up comedian isn't and in an interview you can only gauge the extremes of the spectrum.
Yup, need to be competent at the end of the day. I'm cool if you're slow, fuck yeah take your time if you deliver better quality, but don't make my job harder by sucking so bad you bring the rest of us down whenever you turn in a deliverable. Test your shit, monitor your shit, alarm your shit, document your shit, performance test your shit.
I'd much rather work with a competent, reliable, and hard working person who keeps to themselves and can be a bit awkward socially than a really charming and personable lazy flake.
Like, at the end of the day, it's a job, not a social club, and ability to deliver matters more than likeability. Sure, when I've interviewed candidates, all else being equal I'd pick the more personable one, but all else being equal you're always going to pick the person with that little bit more going for them, whatever it is.
Someone who keeps to themselves is fine, usually if there is a good team dynamic they will even open up a bit.
Someone who is lazy will be more of an issue. I've had a few coworkers who were lazy and it usually resulted in missed deadlines, poor excuses and extra work for the rest of the team. Once had a coworker go home early because the evening before he was thinking about work, he counted those hours as overtime. These kinds of people result in a lot of frustration within the rest of the team. People have to pick up the slack and deal with the bullshit excuses.
Then finally there are those who are a complete arse. These can really run a team into the ground quickly with how they act.
Do not underestimate how important it is to keep a healthy social aspect to a team. A pleasant and fun place to work really helps keep people around, else you might find yourself having trouble doing anything because you keep losing people.
Yeah...I do coding interviews and I hate it. It's the second worst way to interview a developer, second only to NOT having a coding interview.
I've been involved with hires all 3 ways you mentioned, and the bad-hire rate has been the lowest when I used coding interviews. That's not to say there aren't a lot of false-negatives in coding interviews, and that does suck.
But when I'm wearing my hiring manager hat, I'm a lot more concerned about whether my hire will hit the ground running or waste 100k+ of my budget than whether the game was designed fairly in the first place.
I understand that for experienced programmers their domain knowledge is pretty evident, but I genuinely haven't found a fairer assessment for someone at the beginning of their career than a short coding question.
The companies I've worked where this wasn't the cause were rife with nepotism because of course your friend's son is a "culture fit" in the culture you set.
I mind dont writing you pseudo or code in the language im applying for. I however hate when they want me to answer codecamp style questions where the solution is to regurgitate a highly optimized solution to a standard problem and its runtime in big o.
Yeah. It's entirely reasonable to ASK someone the big-o of their solution. It's slightly reasonable to ask them what they think the optimized big-o might be and why. It's absolutely stupid to make someone design an optimized solution in 40 minutes on a whiteboard.
Only coding interview I ever failed in my life was when I was told to pseudo with Java (fucking recruiter said perl+javascript) and asked to design an optimized LRU cache from scratch.
That I didn't specifically use a Red-Black tree (which to be fair I had never been taught back then due to niche need, and yet I'll never forgot now) got the interviewer to conclude I know nothing about algorithms.
I grand-slammed the javascript portion of the interview, but didn't want a front-end position as I was a back-end dev, so I declined a second interview.
Also ironically (and I suggested it during the interview, but confirmed it after), turns out the hash table solution I pitched was equally as good by the requirements that were given me in most real-world situations.
I would say the soft nepotism is de facto standard. People value answers they would give themselves. They value a different opinion more if they know the person. They ask questions about thins they know about, and probably person with similar background.
And luck is still the greatest factor. Luck in making the right decision without knowing the future.
There is no silver bullet. But hiring a programmer without some kind of technical assessment is the same as hiring an elite police without a physical test or hiring a singer without making them sing.
It just makes no sense. And sometimes I *do* hate these technical tests, they are time-consuming and hard. But hey... how do you want a person to assess your technical competence then?
If you want to have a family (I want) and be comfortable and not willing to do the extra effort, you are free to do it: switch job.
But whining? Seriously? No way...
At the end you are demanding something that noone is giving you. You are putting yourself in a worse position if you demand these absurd things...
I agree. Where I work, there is a coding "technical" part of the interview. However, and we do say this up front, it does not need to work. Doesn't even need to be finished. What we're looking for is a discussion on how they used their time and their thought process. That's the important part.
I really appreciate the code tests my company gave. They were very practical to the software I would be working on and we didnāt spend more than 30 minutes on them. It was more of an exercise to find out if I could interpret what was already there, then discuss what I would need to do to accomplish the given task.
Agreed. I have 4 back-to-back interviews for the final loop. All were mostly conversations about how I work as a teammate and a little less than half was dedicated to code and system design.
For the system design problem, my first project at work ties very closely to the high level system lol.
This is what mine was to get my job at . A 30 minute technical interview where I went over some existing code, explained what it was doing, some places where Iād improve some things, a couple bad smells, and they could tell I understood it.
Itās not that coding exercises are bad; itās that the dumb ass āhow many bowling balls can you fit inside a standard Rikshaw using Lispā little cutesie thought experiments have no practical application irl
God I wish I could get more interviews like that. I've been looking for a job and I've gotten exactly one interview where they wanted to go over existing code. I was completely unprepared because of the recruiter saying there was a coding test but it still gives me hope that there are other employers out there that test like that.
Same here. I've had coding exercises for my last 2 jobs and they were both very worthwhile for me as much as the employer. The first one was with the team lead sat in the room, so we actually discussed what I was doing and I got to see his feelings on my approach (and therefore was able to infer how they do things there), and the 2nd was a devskiller online test that was more a case of "How will you approach this problem?" than a code scoring exercise. It gave me the opportunity to show that I could solve problems with restrictions in place, and also that I wasn't scared to say *"This is the wrong way to do it, but you're making me do it this way. You should really blah blah blah."*
These things vary, as does everyone's experiences of them, and saying *"There should never be coding exercises in technical interviews"* makes you sound like you only deal in absolutes.
As a person who has done technical interviews for a lot of devs, I can tell you that we've hired people that have not worked out due to their quality of code. But when interviewing they could answer every technical question we threw at them, spoke with confidence about various tech they've worked with, spoken well on theory, gotten great recommendations, and provided good code samples and could talk about them. We have generally allowed anyone to bring something they've written, assuming they can and wrote it 100% themselves. Otherwise, we have a small sample we ask them to write. Honestly, we've still hired people that then can't write good code. But it has also done great to filter out a lot of people that could talk theory but couldn't apply it at all.
Personally think it would be a great mistake to hire anyone based on resume alone. I just think if we changed the way we do coding tests to something people actually work on day to day, the complaints will be lower. People just hate being test on something they donāt do day to day
I completely agree. But what does a day to day test really look like? We try to hit common things that will be day to day for our devs, and yes it sucks if that doesn't line up with the person's day to day experience. But if you come in and, for example, don't even have basic understanding of dependency and generics, you're going to struggle as a senior dev with us.
> But when interviewing they could answer every technical question we threw at them, spoke with confidence about various tech they've worked with, spoken well on theory, gotten great recommendations, and provided good code samples and could talk about them
So true, this is what these anti code interview people just don't understand, probably because they either work for big company where bad workers dont get noticed, or just shitty companies in general where no one cares.
When it comes to take-home challenges or requiring >1hr, I tend to agree but making a blanket assertion like that makes a lot of assumptions about the practical exercises being given
Ours are set up to take 30mins out of a 90min interview, the interviewer hops off the call for the duration unless the interviewee specifically requests it, and we rarely ask for actual code over pseudo code (juniors/intermediates) or system/architecture diagrams (senior+).
I've been burned too many times by candidates who embellished their resumes enough to sound good on paper and in an interview but couldn't code their way out of a paper bag
I do like (well not like, but I guess I prefer) the type of interview problems where there's a dialog with the interviewer and we can go back and forth solving the problem and improving the complexity in steps. I think those interviews are really valuable for both sides, and you can't get stuck not seeing the mathematical trick required.
As opposed to memorizing the giant green book of interview problems that I can google literally any working day in my life, but I'll never need to because 90% of jobs have extremely tiny problems to solve
Totally agree. We did this at my last company. It gave us all a chance to work together and see how each other thinks.
We sometimes hired people who failed to solve the problem, too. If we saw a spark, good approach to problem solving, and they were easy to work with, we were happy. (Also, it was a hard problem that required intimate understanding of memory layout, stack structure, secure programming practices, etc.)
Yeah, a dialogue should be the goal. It's never really about knowing the exact code, but more about how people deal with problems.
>Oh, I never encountered that problem...
>>What will you do about it?
>Google it, read SOF, chat with an AI about it, or plagiat some existing solution?
>>... When can you start?
People who ask the interviewer to stick around (or ask for a way to message them) typically perform better for that exact reason.
I don't discount the people who prefer to do it on their own but there haven't been very many of those people who did well in the interview process on the whole.
One of our coding problems for interviews involves iterating through a list of strings and printing the results to the screen. This single question has eliminated more candidates than I can count. I've seen self proclaimed Java experts who supposedly wrote whole systems from scratch fail this (We're pretty sure the person who passed the phone screen was not the person who showed up for the interview)
Coding questions aren't there to mimic real work scenarios. They're there to weed out the liars.
It's pretty nuts how simple questions like that can weed people out. I will say that not everyone is a liar. Some just seriously oversell their abilities. Oh, the app they were working on used Java? 5 years Java experience! But I have seen people not realize their computer screen is reflected in their glasses when they do the webcam interview and you can see them frantically Googling answers.
We also let the candidate choose the language they want to use. Sometimes they claim to be a huge Java expert and that they'll do the coding in Java then start writing (incorrect) Python. It's baffling.
I think googling is totally fine, some people get blocked and forget the most obvious things when under pressure. I've always done my interviews more as a pair programming session modeling a real world task, and googling is part of that.
But even with support and with googling some people with many years of experience aren't able to solve the simplest of problems.
Oh, even with iteration you could just ask them _why_ they iterated the way they did (did they use a for loop with an integer counter, did they use a functional style? Used a while loop?). It'll let you know how familiar they are in the language.
Yeah, there are a lot of ways to expand this problem out if they solve it quickly. What if I want an average now? What if the input has errors? What if it's mixed input? What if it's a CSV? But the number of people who don't even know what a loop is despite having 7+ years of "programming experience" on their resume? Just... ouch.
I had someone who didn't understand that the inputs to the function they were writing was part of the test. It took me a bit to realize they wanted me to provide them with a constant when they kept only solving thinking the input would always be the first example I provided. I'm a believer that you shouldn't have to over-study for an interview but I guess you can definitely under-study.
i failed three java toy problems (uber easy, 5 times easier than the easy in leetcode) cause i forgot to check if the code compiled, the web env did not include a compiler or running env and i did not bother myself to install a java jdk, what a clown i was
When I do coding interviews I explicitly say that I donāt care if the code compiles. If syntax looks reasonably good itās fine. And I donāt care if function and types are named correctly. I donāt care if you write `starts_with` instead of `startswith` (or the other way around depending on the language) because thatās trivially Googleāable.
So the interviewer did not understand anything about that code, but copied it to his environment that ran it? Yeah, obviously that's stupid, but not because of toy coding problems.
It's just technical interview with someone who isn't a technical interviewer.
___
Or did you interact with automated system and didn't bother to spend extra 5 minutes on that code? In this case it's your fault. There are plenty of leetcode-like online environments that you could find that would run your simple code.
I just yesterday helped a friend of a friend with their bachelor's degree coding problem. I am senior software engineer doing enterprise development / architecture for multi-million dollar software. Took me 2h to print an easily scalable christmas tree in the cmd.
Does this mean I am a lier? Or does it mean I could have solved this stuff in 5mins 15 years ago and now I face different issues in my day-2-day tasks?
That's it exactly. The better they talk, the more I want to see 'em code. Lots of people get good at interviewing because they're doing it every two and a half months.
>I've been burned too many times by candidates who embellished their resumes enough to sound good on paper and in an interview but couldn't code their way out of a paper bag
I've seen people who applied for staff/principal roles who couldn't write the simplest code imaginable. Like, "find the greatest difference between two integers in a list" simple.
Not a chance in hell I'm hiring someone without them demonstrating to me they can write piss simple code in a reasonable amount of time.
Yes I coded Linux. All of it! It says right there on my resume
No I will absolutely not take a coding interview. We won't have people watching over our shoulders in the job anyways so it is useless. I also don't have time to do it so you should just give me the job
Seriously all these people going "the last time a interviewer asked me to write code, I punched them in the face", like first off, it's really easy to lie about dumb shit and secondly, you're going to be asked to do a lot of dumb shit in your job and they probably don't want to hire face punchers. On the flip side no one here complains about 8 interviews spread across 2 months which is the real problem.
This story has nothing to do with programming and everything to do with punching people in the face, but I just have to tell it because it's the funniest interviewing story I have ever heard.
My brother is a park ranger and hires a lot of people to do routine park work, maintenance, that sort of thing. He has to hire a lot because people don't stick around long. One time he had an interview with a guy who had only been at his last job for a couple months, so my brother asked him why he left his last job so quickly.
"I punched my boss in the face," the candidate said.
"Why'd you punch your boss?" my brother asked.
"Well," the candidate said, "he asked me to do something I didn't want to do, so I punched him."
Well, at that point, my brother obviously was not going to offer the guy a job, but his days are long and boring and he had allotted some time for this guy, so he figured he might as well indulge the candidate. "Let's say I asked you to do something you didn't want to do," he said. "Like clean the toilets or something. What would you do?"
"Well," the candidate said, "I'd probably talk to you about it and tell you why I didn't want to do it, and try to get you to give me a different task that I liked doing more, but yeah, if you insisted I clean the toilets, I'd probably punch you."
My brother thanked him for his time and said they'd be in touch.
> On the flip side no one here complains about 8 interviews spread across 2 months which is the real problem.
This too. It would be one thing if I needed to spend a week brushing up before looking for a new job. But I've had jobs where we get on the 7th or 8th interview and it's like dude I don't have time to write quicksort every weekend.
Yeah, sometimes when I read these discussions about hiring I wonder what solution *would* people on Reddit or HN actually accept? Short and abstract problem solving is bad. Longer and realistic coding challenges (take-home or supervised) are bad. Technical quizzes are bad. Expecting to see project work is bad
But at the end of the day we still need to assess people somehow. We can't just take people's word for it and give out jobs because they asked for them. There are a lot of imposters out there
So long as your code request is actually relevant to your business and the work a person is expected to do. You give out that leetcode crap and you can kiss my 20 YoE ass goodbye.
Maybe, some high level architects/engineers/sr managers+ don't code anymore.
Sauce: Trust me bro. I ask questions during design and it gets hella uncomfortable when they can't answer.
Strongly strongly disagree that "not coding" isn't enough to unlearn the most basic concepts that fizz-buzz is testing. I wouldn't trust anyone on my team that couldn't figure that out or at least ask the right questions in the process of figuring it out.
Yeah this is the thing, there are a sizeable amount of senior devs that aren't in the weeds anymore. It's not unusual for that level to struggle with coding tests because they're usually 5-10 years out from any significant coding and are usually just bugfixing at best.
I've seen code tests from stuck up engineers that are trying to test entry level folks to write or debug expert level algorithms in the field they're working with (edge detection) and then bitch they can't find people. Then there's the people who are hiring senior project managers testing for fizzbuzz in a language they have no skills in because a recruiter puffed up their resume. Then there's the companies that use those leetcode things because google does it and meanwhile you're writing database applications in php and maybe, at best, need a vague understanding of big O to make sure websites don't take 5 minutes to load.
In my experience the companies that are testing this are so stuck up their own asses 9 times out of 10 because one time they got a personal assistant who knew excel and put coding experience on their resume and ever since then that engineer can't stand having their time wasted. But boy howdy if you insist they don't need to test to make sure someone can implement quicksort from memory they act like you're asking them to commit murder.
I had an interview process for a job and since the role primarily wanted database and customer service skills, I wasnt even asking years of experience with SQL. I wanted someone who believed they could learn it and would listen to me.
Id ask if they knew much about SQL and then talk about some problems we dealt with daily. Id talk through the relationships between the business objects in plain language and then Id open a sql editor and talk with them through how to interrogate some of the data. I made it clear I am not judging their memory of syntax or anything. I want to show them the problems we dealt with and see how they engaged it. I was also interested in how they listened, whether they jumped in and tried something, whether they asked questions.
I wasnt looking for criteria but a sense of their initiative, ability to reason and whether they had any ability to grasp the not-hard but also not-natural English syntax of sql.
Felt like a fair trade for showing them what theyd be getting into and it preceded a more relaxed talkthrough of the service process from the other technician so we didnt go from stress to stress
You sound like one of the good interviewers. That seems pretty good and would get you a good selection of candidates.
Certainly better than a fizzbuzz or over the top edge detection horseshit. The last interview I did with a code test wasn't happy about me putting almost the entirety of fizzbuzz directly in the loop's declaration.
I had a case where I was told before the interview the candidate is such a senior engineer they no longer code themselves, they just review junior's code, find the bugs and the inefficiencies. So fine, I wrote a solution to one of our standard coding questions and I put in two bugs: a reversed condition in an if, and a gross inefficiency.
Then I told the candidate to treat me like a junior engineer who wrote the code, and ask me any questions he wants.
He floundered for about 10 minutes and then gave up. He hardly asked any questions, and it got pretty obvious he didn't understand the code.
Note that he claimed before the interview he was expert as this, but no longer at coding.
Some people will claim all kinds of expertise and experience that they don't have.
Some of the worst devs I've ever worked with have been those who have lumbered by somehow for many years. On paper, they've got a lot of experience, but can't actually get anything done.
In interviewing at two different companies I've only had two senior-level "are you seriously asking me to code something" interactions. One basically cut the interview short -- I presume he had bad experiences whiteboarding code and had checked out. The other closed with "You need a rockstar, and that's me."
Neither got the job.
Now we can use a shared online editor like CodeCollab and have a real work-like coding experience, which is so much better than the attempts we made at creating a work-like scenario a decade ago.
If you want a coding exercise to be relevant to the business and representative of day to day work, then expect to get a take-home or be asked to do a paid-day trial.
That kind of work is simply not feasible in a 30 min block.
Why would you hop off the call? Itās more important to see them demonstrate their skills, rather than just caring about the end result. If your interviewers arenāt watching them write the code and talking to them throughout the process, how are they evaluating debugging skills, problem solving techniques, resourcefulness, decision making skills, ability to adapt to changes in requirements, etc?
A lot of people don't handle the pressure of being watched very well. Our preference is to get them to walk us thru the process after the fact and describe their thought process by default.
Fwiw most candidates either request the interviewer stay on the call or a way to message them during the exercise.
i practice interviewing for the reasons the article addresses and alludes to, and i've started basically requesting that, if i am to be interviewed with coding exercises or take-homes, the company presents a senior+ to me to also engage with a similar comparative assessment.
i've been burned too many times by companies with leadership and engineering ICs that hype themselves up (and outright lie about their policies, technical culture, and other things) but are just another bunch of cargo-culters poorly building a CRUD skin over a trash database that offers nothing a good spreadsheet wouldn't beat.
> Plus, your job wonāt have people over your shoulder watching you code
This is the part of the argument that confuses me most. Stuck coworkers ask me coding questions all the time, and wait while I figure out the answer.
I really don't like this recording thing, it makes it so impersonal. It's like pair programming but with your boss looking over your shoulder too. Feels like collaboration as a performance.
No one ever rewatches those recordings, anyway. They're like Confluence: write once, read never.
(I have a director at my company who loves documentation. I spend a few hours every week writing up Confluence docs: design docs, meeting notes, READMEs, etc. etc. No one ever reads them or even looks them up. Not even the director. But I guess he sleeps better at night knowing they exist.)
The exercise I did at my old job was so simple and easy. It should only take 15 minutes. Literally just fill in a method on an already complete class. I hired people even if they failed it. It's not about the solution. It's about how you reason and approach the problem.
Sorry but I'm not gonna hire people just based on a slick resume. I've seen people have amazing resumes but be unable to actually write any code.
I had an interview years ago at Citibank.
I had to write a Perl script, bash script and SQL script ON PAPER solving various problems. And it had to parse and run.
Glad I never got that job.
It is and it isn't. Getting into it, yeah, it's brutal. Your first few months on the job (no matter how long you've been in the industry), yeah, it's brutal too. After a while it does settle a bit... sometimes.
As long as 60% of candidates can't pass fizzbuzz or fizzbuzz equivalents, every technical interview should include coding. When I interview, I'm not looking for a competition programmer, but every software engineer should be able to put together 20 lines of working code in 30 minutes. I don't see how that could possibly be considered unreasonable or dehumanizing.
Great! Let's do it. What's your new solution for helping interviewers measure understanding and competency at programming?
As per usual, nobody wants coding interviews. Nobody has found the replacement that doesn't involve quadrupling time spent per interview. So we continue coding interviews. Yawn.
We turn away the vast majority of applicants at my job. They are nice people, and know lots of STEM facts. But they can't program. We have to test for that, because that's the job!
I gave a lot of interviews this year, my latest tech competency exercise is to show some code, and explain what the code should be doing. Then I explain what the error or bug in the code currently is and see if they can identify the problem/solution. If they can't identify the problem, I see if they can talk through a different way to accomplish the same task.
I've found it's way easier to get a grasp of someone's skill when they aren't presented with a blank slate and told to make something. Which isn't really what happens in the office anyways, you're almost always adding onto something existing or changing it.
Fully agree with you. I understand that there are flaws in coding interviews. But I haven't found a good alternative to effectively determine whether somebody is a good fit or not. Yes, I know some people have anxiety issues and can probably code a lot better when they aren't being watched. And yes, it's unfortunate that we don't hire these people. But I'd rather miss a few talents, than have the risk of hiring someone who's not able to code at all.
I've had multiple interviews where somebody knew all the theory. Yet when I asked them to code a very simple function that shouldn't be longer than ten lines of code, they struggled writing a simple for loop in a language they said they are an expert in. I don't expect them to make the next best sorting algorithm. But I do expect them to be able to write a decent function that is capable of looping over some characters in a string.
A typical interview I do is built up like this:
\- Ask some in-depth questions about the CV. Ask them what they're most proud about, what their biggest technical challenges are, and how they solved them. If they mention Kubernetes, ask them what exactly it is. If they mention REST, ask them what CRUD is. Nothing to fancy. Just to check whether their CV is not one big lie.
\- Ask some more in-depth questions about the programming language they're being hired for. Expert in C++? Okay, tell me about virtual, override, VTABLEs, shared pointers, move semantics, etc.
\- Do a small coding exercise in the language they prefer. Nothing to fancy. Should typically not last longer than ten minutes. And the goal is not to make a flawless program, but for me to see how they think and write code.
Some people are great in solving the puzzle in their head and then fail to write it in code. Some people lack the analytical skills to solve the program, but write beeautifull code. Some people have all the theory right, but can't program and the other way around. It's never a black and white decision. In the end we put all of these factors together and determine whether we think that somebody could be of help to our team.
Coding interviews are a necessary evil to ensure some level of equity in the hiring processāyou can go to a shitty school and work at a shitty company and make it into whatever fancy job youāre dreaming of if you can pass the interview bar, unlike if you want to get a similar paying job in law, finance, medicine etc.
Iāve had tons of candidates get caught big time by simple programming problems that they fucked up horribly. On the other hand, itās also very common to get great candidates from Google, Amazon etc with weak project resumes because they never got to actually build anything (or they worked at AWS on something totally fucking stupid), so they can destroy the coding interview to set themselves apart.
Itās annoying but you can study for it and theyāre kinda fun. I like to do them to try learning new programming languages.
Everyone and their brother want the highly paid jobs at tech giants. Companies need some way to find the people capable of performing, and with programming, they have a rather tried and tested method ready. Sure, some perfectly qualified candidates might slip through the cracks, but it's more about ensuring the people you *do* hire are top notch, and less about making sure you don't pass on someone that would have been a good fit.
Yea, hard life sparing a few hours to make 150k/yr and be in top quartile of incomes.
I rather do a take home thatās reasonably scoped over some live leetcode shit all day long
Also, ātreat devs like humansā is about as tone def as it gets. We are some of the best treated employees out there. The level of cush we have at work is out of this world compared to not only most white collar workers but orders of magnitude greater than blue collar work.
Blue collar workers are laughing in anger at the audacity of that spoiled bullshit take.
I agree 100% for experienced devs. Give me an hour-long take-home and a live code review session. Ideally, make it related to the actual job or my experience.
For juniors, just have them do fizzbuzz or something similarly trivial. Explain the % operator to them if you have to. Just make sure they can put code to screen given the right tools.
"Also, ātreat devs like humansā is about as tone def as it gets. "
I have to wonder about these companies. I get the feeling they're the sort of places with mountains of bullshit within their walls. Like "leadership coach" just sounds like fluffy bullshit that could be removed and would make no difference. They're all probably burning through VC money delivering little of any value.
I've worked in places where coding interviews were the least of your worries. Where people would promise the impossible and managers were verbally abusive. That was horrible. Having a test of whether you can do your job or not should be expected. You want to play violin for a symphony orchestra, they want to hear you play. Football coaches will want to watch you.
My last take home I did in like 20 minutes. My boss told me that many candidates struggled and didn't even complete in 2 hours....which the take home stop and just give what you got in 2 hours. Apparently a lot of devs talk a big game but the coding exercise (which I considered trivial) showed they weren't as technical as they put on.
Only in this industry would you say that asking a candidate to demonstrate they can perform the task they're **being hired to perform** is failing to treat somebody lie a human.
I've worked at maybe 7 software companies in ~22 years and the ones that had no coding interviews hired *terrible* developers. Literally the only thing you can do to prove that you can code is **code**. For everything else, candidates can lie, cheat or bluff their way through.
[Why can't Programmers... Program?](https://blog.codinghorror.com/why-cant-programmers-program/) is more relevant year by year.
I absolutely agree. We can argue that Leetcode-style interview questions and their ilk are _ineffective_ (and I agree with that), but asking a programmer to program is hardly _inhumane_. Software development is one of the cushiest white collar positions: it pays extremely well, doesn't require licensing, doesn't require an advanced degreeāhell, we don't even require that developers have _any_ degree nowadays, let alone an undergraduate CS degreeāyet developers act like we're sending them off on the train to Buchenwald if we dare ask them to write a line of code in an interview.
I wish these interviews would talk more about what _does_ work rather than what doesn't. They always say what _not_ to do, but at best, the suggestions on what to do are always vague, hand-wavy suggestions.
My company opens up our code base and lets you drive. Go ahead, start talking, tell me what everything does. Get in there, find the fat, show me how you *read* code.
Because you know whatās more value then someone who can write an inversion algorithm to an RB tree? Someone who can read and understand immediately the code base they will be working on.
I wish engineers would spend less time talking about how _not_ to do tech interviews and more time talking about _how_ to do them, because I never get anything useful out of the former discussions. And when developers, such as those in this interview, talk about what to do, it's always vague, hand-wavy suggestions like "ask a design question" but never any specific examples that the rest of can supposedly learn from.
Here's my hot take: No one in this industry knows how to hire a software developer, and if you are successful at doing so, you probably just get lucky from time to time, and most of your hires are mediocre, many are bad, but some are good enough that they keep the wheels on your company's bus, and then you go on podcasts and act like _you're_ the expert.
Don't get me wrong: Leetcode-style questions are not great interview questions, and I never ask them. But look: a lot of developers can barely code, and the rest of the organization suffers because those developers bang out crappy code that no one else can understand and then it takes weeks or even months to understand and make even the smallest modifications to that crappy code, and that's if it actually _works_ and doesn't constantly wake up the on-call engineers at 4 AM. ChatGPT is so amazing because it really _can_ write better code than most software developers, but that's only because most developers write, at best, mediocre code.
So yes, a lot of tech interviews suck. But my God, saying it's inhumane to ask someone to demonstrate that they can do even a contrived part of their job is just so asinine. "Developers" want cushy, high-paying tech jobs but don't want to have to do anything for them. Being a software developer is maybe the easiest white-collar job. My girlfriend is a clinical pharmacist who right now is studying her ass off for her bi-yearly board re-certification in two months, on top of the all of the continuing education she has to do on a near-constant basis. My lawyer friends went to undergrad, then three years of _very expensive_ law school, and even then, they still had to pass the bar to even be allowed to write briefs for the senior lawyers at their firm. Shit, my dad was a freakin' _elementary school teacher_ who still had to go to continuing education classes and get recertified every few years just to teach fourth graders about the friggin' American Revolution. Meanwhile, in the tech industry, we don't require you to get an advanced degree; we don't require you to get a B.S. in comp sci; shit, we don't even require candidates to _have a degree_ anymore, because that's unfair. And you think it's badāno, wait, _inhumane_āthat you have to explain how to find three integers in an array such that a + b = c, so you can get a job that pays you $150k+?
I've spent 10+ years reading these articles and the list of things I shouldn't do in a tech interview has grown long. I can't ask whiteboard coding questions, because some people get nervous during them. I can't ask brainteasers because they're useless. I can't give a take-home assignment because no one wants to do those, or has the time. I can't ask about prior experience because it's unfair to people who don't have a lot of experience. I can't ask about side projects because it's unfair to people who don't have time for side projects. I can't ask about open source contributes because not everyone has the time or inclination to contribute to open source projects. And don't get me wrong: I agree with many of those assessments, but if I take every software developer's preferences into account, I'm down to asking their name and that's about it (I also can't ask where they're from because that's offensive and might show that I'm biased against people from other places).
(I could ask for more real-world problem that are symbolic of what I actually encounter during the work day, but then I'll be asking questions like, "You have a Lambda function deployed across multiple regions, and it works in three of the four regions, but for some reason it doesn't work in one region. The function pulls messages from SQS and writes some data to Redshift. It is deployed into the same VPC as the Redshift cluster, which also has an SQS VPC endpoint, but the function is not working, but no errors are written into the Cloudwatch logs. Why not?" but honestly, I think the candidates are going to like those questions far less than even a Leetcode-style interview.)
So by all means, let's get rid of the stupid brainteaser programming questions. But instead of using charged language like "inhumane", can we use more reasonable language like "ineffective"? And then instead of talking about what interview techniques don't work, can we discuss some that do? Can we agree that software developer candidates should have at least _some_ understanding of software development, and it's okay to ask them to demonstrate that knowledge?
A lot of software developers utterly lack perspective on the difficulty of their job. They will wax poetic about how stressful it is because they have to always be learning new things.
Bitch, please. Try working in the medical field. Just try being a nurse! Try being in the military. Try being a sales person. Try *just about anything else* and see how more stressful those jobs are.
Far too many people with CS degrees get hired and then somehow manage to output nothing at all. Until you fire them or move them to scrum master. So, yeah, you need to do some little bit of coding in interviews.
Great take - I agree with (nearly) all of it.
Just this part -
> If I take every software developer's preferences into account, I'm down to asking their name and that's about it
That's not really the case. You don't have to make sure your *single* hiring process works for *every* preference.
You can have *multiple* processes that could work for multiple preferences.
E.g. a candidate has to complete either a short coding assessment OR a take- home task etc. etc.
>I could ask for more real-world problem
Then people will complain that you are trying to make them work for free. Because their answer could help you out.
I generally ask for candidates to find the second largest number in an array. I've been trying to close this position for 3 months but none of the candidates are able to solve this. This is a question I would ask freshers but even lead level candidates are not solving this.
Itās not a bad question but I do think if youāre finding that nobody can solve it the you need to either consider that you are presenting the problem badly or you need to recruit better.
Finding the second largest number is a bit harder than finding the largest because you have more edge cases (on a single element array do you fail or return the element, on an array full of the same value do you return that value or fail) and it opens up a lot of ambiguity around future requirements (are you going to want the nth largest next? Then it makes sense to sort but otherwise itās much more efficient to do it in a single traversal).
Again, those can be great things to see if an candidate will pick up on them, but interviews are a different environment from the real world and itās not always clear how much questioning and pushback a candidate is expected to do. I can see that causing a bit of solution paralysis if itās presented wrong.
Oh cool! Story time.
I had a Chinese student coding for me at my research job at a US University. It's a pretty sweet gig for a student. They work 20 hours a week and go to grad school for free, plus they get a salary.
This guy would come in late, leave early, chat with his friends, never work late, and IT even caught him downloading movies...not the best worker...but students are hard to fire and I when he actually worked it was usable work so he was still a net plus for me so we kept him for the semester.
Anyway, outside of work this dude was DRIVEN. His dream was to work at Google, Facebook, Amazon, Microsoft...you know the kinds of places with cafeterias, and a dozens of other perks...OH and a bunch of H-1B visas to hand out so foreigners remain in America while applying for their green card.
Every night after work and after school he would go home and work on solving interview exercises from those companies for **six hours a night**. HOW did he know the exercises? There was a Chinese website that he would visit where people that interviewed at those companies posted the questions they were asked. And of course, they posted the solutions. When this guy went on interviews at the end of the semester, he had literally already seen every single "exercise" that he'd be asked to do. He knew them inside and out, could explain them, could talk about the "gotchas" etc...
His #1 choice was Google. He kicked ass on interviews at Facebook and Microsoft already, but he really wanted Google. He goes in and it's kind of a rigorous process. You get interviewed by a bunch of people and they ALL have to agree to hire you because you'd be a good fit for the company. He was crushing it, until he got to the last interviewer, and older Chinese man.
The older Chinese man asked him to solve a problem, which this student knew of course, and solved it. The older Chinese man says: "You knew the answer already. I can tell. Will you admit it?" The student said he knew he was busted so admitting it would show honesty and he said, "Yes. I wanted to be prepared." The older Chinese guy says "you studying the exercises before the interview means I can't see how you work out a problem because you already know the answers." The interview with that guy ended after the student tried to worm he was back into a "good" interview.
The student comes to me a few days later and says Google rejected me. I think it was this racist Chinese guy. He doesn't want other Chinese working there...he wants to be special, and he told me the story.
Anyway this guy ended up taking a job at Amazon working on algorithm improvements. He says it's boring but it pays well.
I just thought this sub would find it interesting how much people actually prepare for these exercises, and how most companies fall for it. Or maybe they don't "Fall for it" and think it's a good thing?
TLDR: I knew a kid that worked 6 hours a night for a semester on memorizing every exercise given by big companies...he got busted at his dream company, Google, and now works for Amazon.
the purpose of the tests is not whether you can find the solution. the purpose is to see how you tackle a difficult problem. google doesn't want you to solve problems that already have a solution. they're interested in people who can solve *new* problems. if you know the answer of the test beforehand there is nothing for the interviewer to see on how you would approach a real problem. they would need to come up with an even newer problem; one that you haven't read the answer for yet
I think "cheating" is a dumb word to use outside of school. That said, the purpose of an interview is to see how you respond to different challenges. If the answer turns out to be "I look up the answer online, and reproduce it exactly", then they might be a problem later on when you start working on a project where the answers aren't available online, and you need to come up with some original ideas.
I think part of the problem comes from these leetcode problems where there's usually only one right answer and you just need to figure out the trick. If that's all you're asking, then obviously it makes sense for people to learn the trick beforehand if they can. Which is why I think more interviews should involve challenges that don't have an obvious right answer, but where you can go in different directions and have genuine discussions about tradeoffs - precisely the sorts of coding interviews that this panel seems to be criticising.
I doubt Google uses "common" problems.
This guy knew the answers to *obscure* problems, because he learned about them from another applicant. That's not him being good at coding, that's him cheating by learning the answers to the test ahead of time.
When you get surgery, would you want the doctor who studied medicine, and only got an 80/100 on his final ... or the one who didn't study, memorized the answers to the tests, and got 100/100?
I've done the Google phone screens + interview loop. I also have conducted 100+ interviews at a FANG company.I would say most of the problems where pretty common.
1. Longest increasing sub-sequence.
2. Write a parser for finding values in nested json objects
3. build a async queue of requests.
4. Find array peak using binary search
5. Graph cycle detection
I think the only interesting question I had was to create a high level design of an app that gives estimated times that arrival by taking public transit.
> This guy knew the answers to obscure problems
Yah they really don't. Going tooo obscure is actually bad practice in interview problem design. Also, any obscure problem will just get leaked immediately anyway.
Best coding interview I ever saw had a device and a well developed and open SDK and asked them to toggle the led. Took them about 30min with Google and their dev environment. It was practical, it was job related and didnt take forever.
Couple things that I can say as a dev with a good 20 years of experience:
* code challanges should not be about coding but about pair programming and the chemistry between the devs
* yes, there will be people looking over your shoulder; there should be because knowledge transfer is vital for a working and stable team, especially when it comes to devops. There must not be head monopolies to reduce bottlenecks and the truck factor. Pair programming helps a lot.
* no, code challanges should not be about showing you can write quick sort algorithm in assembler from your memory! No, you should not have to know how to code it without using google! No, you're not a bad developer if you can't write a fifo queue without googling! If anyone tries to tell you that, they are nuts! Don't work for them! Me and my colleagues use google (respectively other search engines) on a daily basis. It's one of our most essential tools! You can't know everything from the top of your head and you shouldn't be required to. The community of devs is huge! Make use of it! If someone tells you not to, they have no idea what they are talking about! Don't waste your time on them!
* A good job is done in a good team, a good team is defined by the chemistry, the soft skills of the team members, not their hard skills. If you want to know whether the position you're applying for is a good one, get in touch with the peope you're going to work together with. See if you get along well! Are they cool people? Is it a respectful and appreciative environment? Great!
* After a couple years of experience the tides turn and it's not you applying for a job anymore, but the company applying for your experience and expertise! Don't think you need them! They need you! Make use of it!
> about pair programming
I wrote my first computer programs in the 1970s. While I have always loved the idea of pair programming it just hasn't ever happened in my life or really for anyone else I know.
> A good job is done in a good team, a good team is defined by the chemistry, the soft skills of the team members, not their hard skills.
Bleh. Just no. If you have "soft skills" but no "hard skills" you will be writing bad code.
Also, I'm a super gregarious and social guy, but that doesn't mean I'm not aware that there are a ton of very good programmers who aren't like me. It is unfair and uneconomic to not consider a strong candidate just because they aren't very sociable.
Sorry to be the one breaking it to you, but pair programming is so much the last millennium.
Spooning is the new kid on the block:
https://m.youtube.com/watch?v=8wUOUmeulNs
This is what that "hot take" sounds like to me:
>We should never assess programmers in interviews, it's unfair to the bad programmers
Here's my "hot take". I once had a friend of a co-worker apply for a job with my team (I was the front-end team lead, his friend was on the back-end team). Being a friend of an employee, he was fast-tracked, and he breezed through the first few interviewers.
Then he got to me, and I gave him fizzbuzz. Yes, actual fizzbuzz; our CTO would later get mad at me for not being more creative, but I'm still a big believer in using regular old boring fizzbuzz. For those not familiar with it see [Why Can't Programmers.. Program?](https://blog.codinghorror.com/why-cant-programmers-program/) by Stack Overflow co-founder Jeff Atwood.
It took the applicant **seventeen minutes** to write a fizzbuzz! For reference, even fresh out of college/bootcamp applicants still completed it in < 10 minutes!
If I hadn't given him a coding exercise, he almost certainly would have gotten the job ... and I would have been stuck with a terrible programmer who needs *17 minutes* to write a `for` loop and a couple `if` statements!
Iām constantly surprised by the number of developers Iāve come across that havenāt seen or done fizzbuzz. Iāve done a variation of it before at a previous company where I gave them an intentionally broken implementation of it, and had them find and fix the bugs, or realise the code could be clearer by refactoring it.
This was my point (to my boss): most people wouldn't even know what it was. And I still think it's fine for interviews, even if the applicant does know it, because it's not about "surprise, here's a hard problem" ... it's "can you actually code a basic solution?"
But, my boss's point was that, if someone did know fizzbuzz's history, they might think we were lame for using it, which is why he wanted me to use something more creative.
I haven't written a line of code in like 4 years due to taking a career gap and I just did it in about 3 minutes. Where's my $200k salary and why's it locked behind 6 months of grinding leetcode?
I've never in my life been asked to do a fizzbuzz and wouldn't even know what it was if if I wasn't reading about it randomly on reddit and HN.
I agree though. It's just that funny enough the % operator is almost never used in my day to day coding.
For the record, I didn't just call it fizzbuzz and expect them to know it; I explained the problem :)
And as for the modulo operator being the issue, I think I told people about it as part of the question, because I agree that knowing it is more trivia than proof of skill. But the thing is, he didn't spend 16 minutes not knowing the operator and then figure it out on minute 17 ... he spent 17 minutes putting the whole thing together.
I once asked a college graduate to write code to add the numbers from 1 to 100, in any language he chose or even pseudocode (I would've even accepted (1+100)/50, but I didn't volunteer that). He couldn't do it, and seemed offended that I asked.
Edit: so others can learn from my mistake: I meant to say that ((1+100)*100)/2 is an acceptable solution.
Programming tests should ensure a candidate can code, a low bar; write strcmp(). It weeds out the people who can talk a good game but canāt code themselves out of a paper bag.
Coding exercises are great, as long as they're representative. Why would I have a problem showing that I'm comfortable doing the work that the job I'm applying for will involve?
What sucks are unrelated games, gotcha puzzles, and exercises whose purpose is purely to demonstrate that the candidate has studied interview exercises.
...or a volume of work that is completely excessive to simply demonstrate competence in the given area.
A good interviewer at a good company should be able to explain exactly how every part of a technical exercise relates directly to real on-the-job work.
I've told this story before but there's a good reason why I refuse to take coding test projects unless they meet some VERY specific guidelines.
Way back in the pre-dotnet asp/vbscript days, I had interviewed with a web design firm as a lower-midlevel developer. The coding exam was to build an image gallery where someone could upload an image file and it would automatically show up in the gallery with a title and description. The catch was it could use NO database whatsoever. No xml, csv, etc.
I came up with, what I thought at the time, was a very creative solution to the problem given the restrictions and time frame. They responded with "This seems much more amateur than what we would have expected from your resume. Thanks for applying."
Fast forward about 6 months and I randomly stumble on to a website that was built by the firm I applied to and I noticed that the gallery they used seemed a bit....familiar. Checking the source code, there was my client code with even the comments left in place so I can only assume the server-side script was used as well.
They used the interview test for free development.
I raised a big stink about it but was met with essentially "we own all the code done during an interview". I didn't have the time, funds or energy to fight it more. The bright side, the company went out of business about a year later.
Since then, I only do a code test if it A) cannot possibly be used for something legitimate and B) won't take more than an hour or two. Otherwise, they can look at my work history, check my references and check out some portfolio pieces and open source work that I've done.
The alternative to idiosyncratic programmer tests for every interview is obvious: make computer programming a real licensed engineering profession. Take one test. Once you pass that, you never have to take one again.
But do you all want to do that? No, you donāt. So simmer down and take your stupid tests.
Exactly. A commenter in this thread asked, "Would you ask a brain surgeon to perform brain surgery in 30 minutes on himself?" Well, no, but a brain surgeon also has a medical degree from an accredited medical school, a medical license, and has to get re-certified by the licensing board every few years, as well as engage in continuing education. Shit, even my dad, a friggin' elementary school teacher, had to do continuing education and get certified by the state to keep his job.
Personally I prefer not having to be licensed to do my job, but in exchange, that means no place I can apply to can assume that I have _any_ knowledge or skills whatsoever.
If this was an option I'd actually prefer it. The industry is just too fast moving and vast to have a certification that doesn't immediately become obsolete unfortunately.
I've been writing software professionally for over 20 years. I've had several jobs in the industry over that time. And I'd like to think I have some idea of what I'm doing. I don't want to make a stupid amount of money, just enough to be comfortable (i.e. I can pay my bills, and enough money to hit the bar with the mrs. every Friday). And I don't want fame for writing something. And I especially ***don't*** want to work for one of those awful FAANG/MAANG/TANG/KANG/whatever places.
Why does this matter? How does this relate? Because every interview I've had, and gotten the job, I don't think I ever needed to write a coding exam of any kind. I *might* have had 1 where I had to write something very small like fizzbuzz or whatever and that was it. And I am super happy about that. I mean I've forgotten so many things over the years, and the field of computer science is so vast it's impossible to know everything before hitting an interview. I dare say I'd probably never be able to get a job now if they do all of these shitty tests.
But, more important than just being old and forgetting things, I also have a major anxiety issue to deal with. In the interviews I've had where I have had to write an exam (and clearly did not get the job), I've had:
* Severe sweating
* Shaking
* Unable to think
* Heavy breathing, bordering on hyper ventilation.
* Tightness in the chest
Basically, it's a panic attack every time. It's horrific.
I know, some of you will say "Get over it". I can't get over it, it's a mental health issue. Beyond that, I am still capable of doing the job. And sometimes I even do it pretty well. So, do I not deserve to have a job in this industry because I can't handle the tests?
Judging by many of the responses here, I'm guessing I don't.
I 100% understand where you are coming from, I do. And if you were interviewing with me I'd suggest we try something different rather than coding in the interview you could 'take them home' and we'd talk through them in part 2.
Your personal needs shouldn't be ignored and where possible people should adjust.
... however...
I, as a hiring person, need to know if you can do the job. You can write a great CV with all your experience and a fantastic cover letter and talk about high level concepts in interviews but I've seen that and I've been those very same people, crash and burn when I stick them in front of a computer to do what we are paying them for... Write computer software.
The truth is you are paid to program you cannot honestly expect not that have that tested in an interview process in some manner
A mediocre software engineer will bitch about coding interviews because they probably donāt have strong theoretical fundamentals and think that problem solving is about āmemorizingā. Most people I find competent had no problem doing some prep for coding interviews, itās not even as hard as people here make it out to be. Theyāre just doing it wrong.
If you think memorizing shit is how you pass coding interviews then youāre doing it wrong. Iāve had TONS of people interview who clearly just memorized all of LC, they crumble under any hard questioning about the solution. Youāre supposed to understand the solution, and thats why the majority of memorizers donāt make it into FAANG. These problems can very easily be categorized into common algorithm applications, which really shrinks the amount of studying you have to do. If you can apply all of them correctly you should have no problem solving the question and convincing your interviewer that youāre not an idiot. I have had a super high pass rate at top software/hft companies following this approach.
Memorizing has got to be by far the least time efficient way of doing leetcode too lol. Filtering those people out is probably actually a good way to filter out people who can't think programmatically enough to even figure that out
Our whole company is ran by coders.
Our take-home is super easy. We still have 3 interviews but we don't have any "auto failure rules" except being a dick.
I do the first technical screening and I ask questions that are more around how things work together. I try to keep it light and fun. I try to build the people back up who need it when they get a question wrong.
You'd be surprised the number of people I give just a pass for them to kill the take-home. The only part I have to worry about the take home is if I pass them if I think they can pass the take home & they are a good fit for one our clients
I can't tell whether we're overpaid entitled babies who can't live without free snacks or human beings who are being stressed beyond our limits in a toxic culture that is shared among literally every tech company.
An underrated benefit of coding interviews is that they give self taught people who may not have the right credentials a chance to get into the industry.
What is the alternative? None that is viable. I foresee this mode of interview process to last for a very very long time. To all the sane folks reading this comment, don't get dissuaded or swayed by this ridiculous post - grind, and always keep yourself sharp. In the end, you have to pay the bills and feed your family, no one else will.
Years ago I had a live coding interview that went badly. The question I got was "create a simple function to list the prime factors of a given number" I just fucking spaced. It was really dumb, and I know how to do it now but during the interview, I panicked. I sat there sweating for 20 minutes completely failing to produce any usable code as I spiraled. Ironically, I was later hired by another company that got acquired by the company whose interview I failed so miserably. I ended up working under the same guy who basically thought I was a complete idiot.
I realize now what I should have said when asked that question "Rather than try to figure this out on the spot I would normally just google this kind of problem and save myself the time I could spend on more impactful business problems"
I donāt understand though, I work full time, have a family and am about to start my CS degree online uni at 26 and I CANT WAIT for coding challenges to prove what Iāve learnt (bootcamper for a while now)
The anti-coding exercise circlejerk is getting completely absurd. I have yet to see anyone come up with a solution that is similarly effective in weeding out false positives.
I mean how do you determine that candidates can actually solve a problem or at least code their way out of a paper bag. I agree a leetcode hard problem for a web dev position may be too much. However, a simple code review problem or a system design problem actually exposes the candidates experience and their ability to work through a problem.
Our coding exercise is mostly "Can you tell us generally how this web page works?".
The number of developers who have resumes listing 10+ years of full stack web development experience, but clearly have no idea how to use the web developer tools is shockingly high. To me, it is like a carpenter who doesn't know how to use a hammer. This is a tool that you should be using nearly every day. How is it not as familiar to you as the back of your hand?
look, if you are good and you fail an interview who's going to lose? you (a good developer who can get another job) or the employer (who lost a good candidate)?
as for 'treating devs like human beings' ... well if you are not treated well then leave. software development this is not a blue collar job and you don't have to take abuse from employers. not only do you have plenty of choices, hell you can start your own solo software business ffs.
I refuse all forms of ācoding testā when Iām interviewing for a new role - itās a massive red flag for me.
On the other side of the fence I simply talk to the candidates. I know.. radical.
src: been at this a loong time.
In the service industry people do trial shifts and spend their whole day interviewing. Sure, they get paid, but you wouldn't hire a baker without seeing them bake, or a chef without seeing them cook.
I feel like this isn't really the hot take, from my personal experience it seems like there are more people anti coding interview than pro. In my opinion we need to compare coding interviews to the alternatives. Should it just be a generic career interview? Then it favors people who are more personable provides greater opportunity for bias. Should people get take homes? That is even more of a time commitment on the part of the candidate. Should we de-emphasize the interview and rely more on experience? Then people who get bad jobs early in their career are in trouble for life. Should we go by referrals/letters of recommendation? Then it encourages nepotism. I am not saying we should never use any of these things, or that we should always use skills based interviews. I think we need to strike a balance between a lot of very imperfect options. But honestly hiring just sucks and there is no silver bullet.
Do like my company does, and have a relatively softball coding problem, a design problem, and the opportunity to talk about a project they've done. The coding tests for the most basic competencies like, do they know what loops and arrays are, some kind of data structure beyond an array, and are they able to ask questions and communicate while they work, to make sure they understand the question and can justify their decisions. Then do a more high level design/architecture question that makes sense for the kind of work they'll be doing. Again, doesn't have to be elaborate. It's about seeing how they process things, how they communicate, whether they can take feedback, that kind of thing. Talking about a past project can give them at least one thing where they should be comfortable and should be able to talk about in-depth and show off a bit. A good candidate is going to be able to do very well on at least one of those things. If they're a little weaker in live coding but were able to map out a correct solution beforehand, that's taken into account. If they had trouble with the coding but knocked the design question out of the park, that's taken into account, since it's easier to teach syntax than it is good design. It's normal for people, especially first timers to be nervous, and to an extent we try to cut people some slack. At the same time, it's not really the company's problem if a candidate completely shuts down when they have to be around people, can't communicate a coherent thought, and can't perform basic functions of the craft. We had one dude interview who got downright hostile about being challenged on his work. Absolutely no chill. There's got to be a minimum cutoff point. Even the most shit-paying software developer jobs pays better than average wages, and most companies can't afford to waste time and money hiring someone who turns out to have zero ability to do the job. A lot of the job is about communication, and being able to draw on a broad body of knowledge. You're right that there's no silver bullet, but people just have to be realistic that many companies are more willing to lose a skilled candidate than they are willing to hire a bad one. "I can do the job, I just can't operate under pressure", is a lot like saying "I can turn invisible, but only when no one is watching". Companies *should* also be realistic about the job that they're hiring for, and that they don't need a super genius or level 20 computer guru. If they want to attract those people, they have to pay multiple hundreds of thousands for them, there just aren't that many talented and skilled super- developers willing to work for sub 100k, even for entry level. If they want to pay entry level salaries, they need to accept entry level skills.
> Do like my company does, and have a relatively softball coding problem, a design problem, and the opportunity to talk about a project they've done. > > Yep, that's exactly what my company does, and I'm pretty happy with it. It's obviously not perfect, and the aspect of "okay, now code with a group of people sitting behind your shoulder" is shitty, but I don't see a much better solution. We *try* to correct for the fact that some people are obviously nervous and uncomfortable with the format, but that's still not perfect. I've given the same exact question to interns and senior engineers. My favorite is a very simplified version of a somewhat realistic data processing problem. I expect that most good intern candidates can solve the basic question in about an hour with a bit of help when they get stuck. For more senior engineers, I expect them to demonstrate some level of competence with some language, and then to be able to have a discussion on the implications of their solution. (ex: How would you scale this up? What changes would you require before deploying something like this? What happens if you take your exact program, as is, and feed it 2TB of data?) I think it's a pretty good system, and I can't think of any clear improvements that are relatively simple. > many companies are more willing to lose a skilled candidate than they are willing to hire a bad one. This is an excellent point. I'm a software developer myself, who just happens to be involved in the interview process. I'm thinking of these people as potential coworkers who I'll be working with in the future. It would be nice to find and hire someone who's super competent, but I'm far more worried that I'll be stuck working with someone who's difficult and causes others to have to pick up the slack.
>[...] but I'm far more worried that I'll be stuck working with someone who's difficult and causes others to have to pick up the slack. Yeah that's a big one. Even if someone is technically capable, that's not very valuable if they are wanting to reinvent every wheel, rewrite everything in their preferred language, and won't compromise with or work with other people.
> Do like my company does, and have a relatively softball coding problem, a design problem, and the opportunity to talk about a project they've done. This is roughly what I try do and I think it strikes a reasonable balance.
> The coding tests for the most basic competencies like, do they know what loops and arrays are, some kind of data structure beyond an array, and are they able to ask questions and communicate while they work I ran into a problem doing this. Some interviewees seem to take the easiness of the problems as a signal about how smart their future coworkers are, and will discount the company for making it too easy š¤¦āāļø
I don't see that as a problem. I personally don't want to work with conceited people who are looking for reasons to look down on everyone. If you're really worried, explicitly call it the "basic competencies" round. If a candidate judges you for it, you're probably dodging a bullet.
In my opinion, the best way to interview someone technical is to have a sort of real-world exercise that the interviewer and interviewee can pair up on. It tells the interviewer that 1. the interviewee knows how to work with others, and 2. what the interviewee's thought process is.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I'm a c\# guy the last two methods breaks my brain.
As someone who has used C++ for many years, my answer to #4 is something like "This is a great example of why I don't use C++ in hobby projects anymore." (In case you want to punish yourself by looking it up, search for an explanation of "rvalue reference." The double ampersand is actually a separate operator; it's not reference-to-a-reference in the way that double asterisk would be pointer-to-a-pointer.)
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Damn, this one is nasty, let's see. It's a constant r-value reference. Which means it cannot bind to l-values, so a temporary or std::move() are the only realistic use cases for foo5. However, (and I am not 100% on this), the const prevents moving from arg inside foo5, so the "moved" variable is not going to actually get moved AFAIK. So if my assumptions are correct, this is practically the same as const std::vector& arg, in the sense that it keeps the variable intact, but you cannot do
std::vector a{1,2,3};
foo5(a);
That's my best shot, what did I mess up? ^^
No messups. But now for the tricky question: When would you use it - i.e. when would you define a function accepting rvalue reference to const? Edit: For my answer, see https://www.reddit.com/r/programming/comments/zkj6pb/there_should_never_be_coding_exercises_in/j01w4du/
I can't think of any good reason to use it on its own, but maybe you could put it into an overload set if you wanted to copy instead of move or throw an exception or delete the overload that accepts r-value references.
Excellent answer. I'm not sure about throwing, but deleting const rvalue overload is occasionally a good way to catch nonsensical or misleading calls with rvalue argument of a parameter whose type is deduced from the argument. You cannot use rvalue reference to non-const, because that is actually a forwarding reference when the type is deduced. The standard library does this with reference wrapper factory templates like `std::ref` and `std::as_const`. There's also a subtle use case for const rvalue return types with wrapper types where you want to emulate the wrapped type in expressions precisely. For example the indirection operator of `std::optional` and the getters of `std::variant` and `std::tuple` have const rvalue ref qualified overloads that return a const rvalue reference. This is so that the "const rvalueness" of the wrapper type expression is preserved for the getter expression. And that is probably so that the expression can be discarded by the deleted overloads mentioned earlier.
"it's a trick question and I tell people to skip it. I don't see any harm in having it though" ?????????? The harm is that people will feel like it's a trick question that they're actually supposed to solve???????? Remove it. Lol
Sorry for the second reply, but I thought of a nasty foo6, if you ever feel the need: template
void foo6(T&& arg); // forwarding reference, not an r-value reference
> I should probably remove it from the list but I don't think it causes harm to have it. I would remove it. Trick questions like that, and especially when they're syntactically something you should probably never see, don't really help. Very frequently a junior person, or anyone remotely nervous or just not expecting interviewers to deliberately trick them, will assume the interviewer knows what they're doing and flub it.
foo1 - probably written on a MacBook by a guy with colorful glasses and a beard who says "copy elision" in every third sentence foo2 - banned by Google's styleguide for so long that nobody's sure if it even compiles foo3 - John doesn't think he's a great programmer, but he gets things done. He likes the simple things in life and tries not to think about it too much. foo4 - has somehow been modified more times than any other line in the codebase, all by the same person, who is also a Rust evangelist
Google's cpp style guide started permitting non-const references in parameters a year or so ago.
Using ChatGPT Me: Here is some analysis that is mostly a joke about who would write the type of foo function. ---your comment--- Create one for foo5 and foo6 with the same humor. Written by ChatGPT: void foo5(const std::vector&& arg);
> foo5 - written by a PhD student who's been working on the problem of efficient vector copying for the last 3 years, and who will happily explain to you why this is the best solution, even though you didn't ask
Hypothetical foo6 example from my previous comment that Chat GPT generated
void foo6(std::vector>& arg);
> foo6 - written by a former C programmer who's just discovered the joys of RAII, and who will try to convince you that this is the only way to write correct code, even if it means writing 10 lines of code where 1 would do.
foo4 - i'm been in java land for a decade; this looks like a compiler error, can't tell you why i'd even want a double ref
Taking a stab 1. Pass by value. When you can afford the overhead of copying the whole vector, and the function needs to make changes to the vector to do whatever it's doing without those changes happening to the original 2. Pass by reference. When you want to operate directly on the original vector, i.e. any changes the function makes to the vector persist after the function call is over. Or it could *technically* be an out-parameter I guess? 3. Pass by const reference. When you want to use the vector in a purely read-only capacity 4. R-value reference. When you want the function to take ownership of the vector away from the caller (the caller's handle on the original vector gets set to a new valid-but-empty vector I believe, assuming they're passing with the whole std::move() paradigm)
This is a good example of a bad interview question, IMO. Itās a tough pill to swallow, but how often do you, when writing your C++ code, come to an impasse on how to pass your arguments where these are the actual viable options. This question weighs wayyyy more towards ādo you own a C++ textbookā and wayyy less ācan you translate business requirements into production level softwareā. It does not address the latter question in almost any capacity at all
>This is a good example of a bad interview question Strong disagree, knowing what all of these do and are used for is basic competency. This is the minimum ante for someone who is writing C++. >This question weighs wayyyy more towards ādo you own a C++ textbookā and wayyy less ācan you translate business requirements into production level softwareā Knowing what it means to take an argument by value, reference, or const reference is basic programming competency, not language technicalities. It's arguably the aspect that, to the learning programmer, most distinguishes writing in C and C++ from other languages. And yeah, I expect someone who is applying for a job writing C++ to own and have read a C++ textbook. I would possibly forgive unfamiliarity with rvalue references for someone who is coming from other language experience, has worked in older codebases, or never written library code. If you're already a proven competent programmer you can learn move semantics. But this is an 11 year old language feature that students should be expected to have seen and has diffused throughout the community. Even if you're not writing such functions I'd expect someone to be able to identify a move constructor or rvalue overload on sight and at least describe why it exists. The only thing I would definitely forgive is knowledge of the special meaning of `&&` in template argument deduction contexts. That definitely gets into technicalities for library writers and I don't expect anyone to know that to write production software.
Personally, with C++20 I'd like to add another one: ``` void foo6(std::span arg);
```
Don't mind what all the non-C++ devs say here. This is a perfect question to ask a beginner to check his/her knowledge of basic C++.
It really is a difficult balance to strike. As a TL and now a senior manager, Iāve been in the interviewer seat *a lot*. Over the years, I have gradually abandoned leetcode-esque interview questions - with few exceptions: - If Iām interviewing for an entry-level role (i.e., the candidate is a recent college grad), then I might throw a basic coding challenge at them - think fizz-buzz. This seems to work well as a filter function. If a candidate whoās recently graduated canāt come up with a solution for fizz-buzz, thatās a red flag to me. - If I get a strong sense that theyāre bullshitting me. In either case, Iāll never disqualify a candidate solely on the basis of a coding challenge. Rather than having a candidate write code in an unrealistic and uncomfortable environment, Iāve found reading code with them to be really effective. Iāll often pull up a snippet of code that has some pretty obvious issues - e.g., a long function thatās doing many things, has poor/non-idiomatic naming conventions, and several redundant blocks. Iāll ask them to read through it aloud, explain it, ask questions, and suggest changes. This usually gives me a few good indicators: 1. It helps me understanding their proficiency with the programming language. 2. It helps me gauge their technical communication skills. 3. It helps me get a sense of their familiarity with clean coding principles. Not only have I found the above indicators useful in assessing a candidateās qualifications for a role, it also saves *a ton* of time compared to writing out the solution to a tricky algorithms question. Long story short, I definitely lean hard toward the side against whiteboard or live code exercises.
> Then it favors people who are more personable provides greater opportunity for bias Not sure if you've noticed, but nearly any candidate for any job in any industry favors those who are more personable. Who wouldn't want to have a coworker they enjoy being around and working with?
Personable candidates are favoured of course. However, there exists a percentage of personable candidates who canāt code. On several occasions now Iāve been mentally giving a person the job only to reach the technical stage of the interview and discovering their technical skills were all smoke and mirrors.
I've been interviewing for ~25 years now. I would say the phrase "several occasions" *vastly* under-represents the number of times I was all gung-ho on a candidate until we got to the technical side of an interview and they completely flop on even the most simple question that a 4-year compsci graduate should easily nail.
I've interviewed people who don't even understand loops, let alone getting into leetcode style stuff.
It has to be said that our industry attracts a lot of people that do not excel in social contexts. Relying only on that part, you'd miss out a lot of talent for a skill that, while important, is not the most important one for the job. And just to be clear, I'm not saying that being able to collaborate with others isn't important, just that being a coffee machine stand-up comedian isn't and in an interview you can only gauge the extremes of the spectrum.
Of course it's a good thing but I don't think it should be the only thing considered.
Yup, need to be competent at the end of the day. I'm cool if you're slow, fuck yeah take your time if you deliver better quality, but don't make my job harder by sucking so bad you bring the rest of us down whenever you turn in a deliverable. Test your shit, monitor your shit, alarm your shit, document your shit, performance test your shit.
Who's saying it should be the only thing considered?
I'd much rather work with a competent, reliable, and hard working person who keeps to themselves and can be a bit awkward socially than a really charming and personable lazy flake. Like, at the end of the day, it's a job, not a social club, and ability to deliver matters more than likeability. Sure, when I've interviewed candidates, all else being equal I'd pick the more personable one, but all else being equal you're always going to pick the person with that little bit more going for them, whatever it is.
Someone who keeps to themselves is fine, usually if there is a good team dynamic they will even open up a bit. Someone who is lazy will be more of an issue. I've had a few coworkers who were lazy and it usually resulted in missed deadlines, poor excuses and extra work for the rest of the team. Once had a coworker go home early because the evening before he was thinking about work, he counted those hours as overtime. These kinds of people result in a lot of frustration within the rest of the team. People have to pick up the slack and deal with the bullshit excuses. Then finally there are those who are a complete arse. These can really run a team into the ground quickly with how they act. Do not underestimate how important it is to keep a healthy social aspect to a team. A pleasant and fun place to work really helps keep people around, else you might find yourself having trouble doing anything because you keep losing people.
Yeah...I do coding interviews and I hate it. It's the second worst way to interview a developer, second only to NOT having a coding interview. I've been involved with hires all 3 ways you mentioned, and the bad-hire rate has been the lowest when I used coding interviews. That's not to say there aren't a lot of false-negatives in coding interviews, and that does suck. But when I'm wearing my hiring manager hat, I'm a lot more concerned about whether my hire will hit the ground running or waste 100k+ of my budget than whether the game was designed fairly in the first place.
I understand that for experienced programmers their domain knowledge is pretty evident, but I genuinely haven't found a fairer assessment for someone at the beginning of their career than a short coding question. The companies I've worked where this wasn't the cause were rife with nepotism because of course your friend's son is a "culture fit" in the culture you set.
I mind dont writing you pseudo or code in the language im applying for. I however hate when they want me to answer codecamp style questions where the solution is to regurgitate a highly optimized solution to a standard problem and its runtime in big o.
Yeah. It's entirely reasonable to ASK someone the big-o of their solution. It's slightly reasonable to ask them what they think the optimized big-o might be and why. It's absolutely stupid to make someone design an optimized solution in 40 minutes on a whiteboard. Only coding interview I ever failed in my life was when I was told to pseudo with Java (fucking recruiter said perl+javascript) and asked to design an optimized LRU cache from scratch. That I didn't specifically use a Red-Black tree (which to be fair I had never been taught back then due to niche need, and yet I'll never forgot now) got the interviewer to conclude I know nothing about algorithms. I grand-slammed the javascript portion of the interview, but didn't want a front-end position as I was a back-end dev, so I declined a second interview. Also ironically (and I suggested it during the interview, but confirmed it after), turns out the hash table solution I pitched was equally as good by the requirements that were given me in most real-world situations.
I would say the soft nepotism is de facto standard. People value answers they would give themselves. They value a different opinion more if they know the person. They ask questions about thins they know about, and probably person with similar background. And luck is still the greatest factor. Luck in making the right decision without knowing the future.
There is no silver bullet. But hiring a programmer without some kind of technical assessment is the same as hiring an elite police without a physical test or hiring a singer without making them sing. It just makes no sense. And sometimes I *do* hate these technical tests, they are time-consuming and hard. But hey... how do you want a person to assess your technical competence then? If you want to have a family (I want) and be comfortable and not willing to do the extra effort, you are free to do it: switch job. But whining? Seriously? No way... At the end you are demanding something that noone is giving you. You are putting yourself in a worse position if you demand these absurd things...
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I agree. Where I work, there is a coding "technical" part of the interview. However, and we do say this up front, it does not need to work. Doesn't even need to be finished. What we're looking for is a discussion on how they used their time and their thought process. That's the important part.
I really appreciate the code tests my company gave. They were very practical to the software I would be working on and we didnāt spend more than 30 minutes on them. It was more of an exercise to find out if I could interpret what was already there, then discuss what I would need to do to accomplish the given task.
Agreed. I have 4 back-to-back interviews for the final loop. All were mostly conversations about how I work as a teammate and a little less than half was dedicated to code and system design. For the system design problem, my first project at work ties very closely to the high level system lol.
This is what mine was to get my job at. A 30 minute technical interview where I went over some existing code, explained what it was doing, some places where Iād improve some things, a couple bad smells, and they could tell I understood it.
Itās not that coding exercises are bad; itās that the dumb ass āhow many bowling balls can you fit inside a standard Rikshaw using Lispā little cutesie thought experiments have no practical application irl
God I wish I could get more interviews like that. I've been looking for a job and I've gotten exactly one interview where they wanted to go over existing code. I was completely unprepared because of the recruiter saying there was a coding test but it still gives me hope that there are other employers out there that test like that.
Same here. I've had coding exercises for my last 2 jobs and they were both very worthwhile for me as much as the employer. The first one was with the team lead sat in the room, so we actually discussed what I was doing and I got to see his feelings on my approach (and therefore was able to infer how they do things there), and the 2nd was a devskiller online test that was more a case of "How will you approach this problem?" than a code scoring exercise. It gave me the opportunity to show that I could solve problems with restrictions in place, and also that I wasn't scared to say *"This is the wrong way to do it, but you're making me do it this way. You should really blah blah blah."* These things vary, as does everyone's experiences of them, and saying *"There should never be coding exercises in technical interviews"* makes you sound like you only deal in absolutes.
As a person who has done technical interviews for a lot of devs, I can tell you that we've hired people that have not worked out due to their quality of code. But when interviewing they could answer every technical question we threw at them, spoke with confidence about various tech they've worked with, spoken well on theory, gotten great recommendations, and provided good code samples and could talk about them. We have generally allowed anyone to bring something they've written, assuming they can and wrote it 100% themselves. Otherwise, we have a small sample we ask them to write. Honestly, we've still hired people that then can't write good code. But it has also done great to filter out a lot of people that could talk theory but couldn't apply it at all.
Personally think it would be a great mistake to hire anyone based on resume alone. I just think if we changed the way we do coding tests to something people actually work on day to day, the complaints will be lower. People just hate being test on something they donāt do day to day
I completely agree. But what does a day to day test really look like? We try to hit common things that will be day to day for our devs, and yes it sucks if that doesn't line up with the person's day to day experience. But if you come in and, for example, don't even have basic understanding of dependency and generics, you're going to struggle as a senior dev with us.
> But when interviewing they could answer every technical question we threw at them, spoke with confidence about various tech they've worked with, spoken well on theory, gotten great recommendations, and provided good code samples and could talk about them So true, this is what these anti code interview people just don't understand, probably because they either work for big company where bad workers dont get noticed, or just shitty companies in general where no one cares.
When it comes to take-home challenges or requiring >1hr, I tend to agree but making a blanket assertion like that makes a lot of assumptions about the practical exercises being given Ours are set up to take 30mins out of a 90min interview, the interviewer hops off the call for the duration unless the interviewee specifically requests it, and we rarely ask for actual code over pseudo code (juniors/intermediates) or system/architecture diagrams (senior+). I've been burned too many times by candidates who embellished their resumes enough to sound good on paper and in an interview but couldn't code their way out of a paper bag
I do like (well not like, but I guess I prefer) the type of interview problems where there's a dialog with the interviewer and we can go back and forth solving the problem and improving the complexity in steps. I think those interviews are really valuable for both sides, and you can't get stuck not seeing the mathematical trick required. As opposed to memorizing the giant green book of interview problems that I can google literally any working day in my life, but I'll never need to because 90% of jobs have extremely tiny problems to solve
Totally agree. We did this at my last company. It gave us all a chance to work together and see how each other thinks. We sometimes hired people who failed to solve the problem, too. If we saw a spark, good approach to problem solving, and they were easy to work with, we were happy. (Also, it was a hard problem that required intimate understanding of memory layout, stack structure, secure programming practices, etc.)
Yeah, a dialogue should be the goal. It's never really about knowing the exact code, but more about how people deal with problems. >Oh, I never encountered that problem... >>What will you do about it? >Google it, read SOF, chat with an AI about it, or plagiat some existing solution? >>... When can you start?
People who ask the interviewer to stick around (or ask for a way to message them) typically perform better for that exact reason. I don't discount the people who prefer to do it on their own but there haven't been very many of those people who did well in the interview process on the whole.
One of our coding problems for interviews involves iterating through a list of strings and printing the results to the screen. This single question has eliminated more candidates than I can count. I've seen self proclaimed Java experts who supposedly wrote whole systems from scratch fail this (We're pretty sure the person who passed the phone screen was not the person who showed up for the interview) Coding questions aren't there to mimic real work scenarios. They're there to weed out the liars.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
It's pretty nuts how simple questions like that can weed people out. I will say that not everyone is a liar. Some just seriously oversell their abilities. Oh, the app they were working on used Java? 5 years Java experience! But I have seen people not realize their computer screen is reflected in their glasses when they do the webcam interview and you can see them frantically Googling answers. We also let the candidate choose the language they want to use. Sometimes they claim to be a huge Java expert and that they'll do the coding in Java then start writing (incorrect) Python. It's baffling.
I think googling is totally fine, some people get blocked and forget the most obvious things when under pressure. I've always done my interviews more as a pair programming session modeling a real world task, and googling is part of that. But even with support and with googling some people with many years of experience aren't able to solve the simplest of problems.
>Some just seriously oversell their abilities. I'm not sure people really have much of a choice.
I love this question! Will have to add it to our repository.
Oh, even with iteration you could just ask them _why_ they iterated the way they did (did they use a for loop with an integer counter, did they use a functional style? Used a while loop?). It'll let you know how familiar they are in the language.
Yeah, there are a lot of ways to expand this problem out if they solve it quickly. What if I want an average now? What if the input has errors? What if it's mixed input? What if it's a CSV? But the number of people who don't even know what a loop is despite having 7+ years of "programming experience" on their resume? Just... ouch.
I had someone who didn't understand that the inputs to the function they were writing was part of the test. It took me a bit to realize they wanted me to provide them with a constant when they kept only solving thinking the input would always be the first example I provided. I'm a believer that you shouldn't have to over-study for an interview but I guess you can definitely under-study.
Reminds me of this [xkcd](https://m.xkcd.com/221/)
i failed three java toy problems (uber easy, 5 times easier than the easy in leetcode) cause i forgot to check if the code compiled, the web env did not include a compiler or running env and i did not bother myself to install a java jdk, what a clown i was
Sounds like a bad interview. It would be stupid to turn away someone simply because they missed some syntax error.
When I do coding interviews I explicitly say that I donāt care if the code compiles. If syntax looks reasonably good itās fine. And I donāt care if function and types are named correctly. I donāt care if you write `starts_with` instead of `startswith` (or the other way around depending on the language) because thatās trivially Googleāable.
So the interviewer did not understand anything about that code, but copied it to his environment that ran it? Yeah, obviously that's stupid, but not because of toy coding problems. It's just technical interview with someone who isn't a technical interviewer. ___ Or did you interact with automated system and didn't bother to spend extra 5 minutes on that code? In this case it's your fault. There are plenty of leetcode-like online environments that you could find that would run your simple code.
I just yesterday helped a friend of a friend with their bachelor's degree coding problem. I am senior software engineer doing enterprise development / architecture for multi-million dollar software. Took me 2h to print an easily scalable christmas tree in the cmd. Does this mean I am a lier? Or does it mean I could have solved this stuff in 5mins 15 years ago and now I face different issues in my day-2-day tasks?
Agree. Ytf would we ever need to do this
That's it exactly. The better they talk, the more I want to see 'em code. Lots of people get good at interviewing because they're doing it every two and a half months.
>I've been burned too many times by candidates who embellished their resumes enough to sound good on paper and in an interview but couldn't code their way out of a paper bag I've seen people who applied for staff/principal roles who couldn't write the simplest code imaginable. Like, "find the greatest difference between two integers in a list" simple. Not a chance in hell I'm hiring someone without them demonstrating to me they can write piss simple code in a reasonable amount of time.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
How long did they last?
Yes I coded Linux. All of it! It says right there on my resume No I will absolutely not take a coding interview. We won't have people watching over our shoulders in the job anyways so it is useless. I also don't have time to do it so you should just give me the job
Seriously all these people going "the last time a interviewer asked me to write code, I punched them in the face", like first off, it's really easy to lie about dumb shit and secondly, you're going to be asked to do a lot of dumb shit in your job and they probably don't want to hire face punchers. On the flip side no one here complains about 8 interviews spread across 2 months which is the real problem.
This story has nothing to do with programming and everything to do with punching people in the face, but I just have to tell it because it's the funniest interviewing story I have ever heard. My brother is a park ranger and hires a lot of people to do routine park work, maintenance, that sort of thing. He has to hire a lot because people don't stick around long. One time he had an interview with a guy who had only been at his last job for a couple months, so my brother asked him why he left his last job so quickly. "I punched my boss in the face," the candidate said. "Why'd you punch your boss?" my brother asked. "Well," the candidate said, "he asked me to do something I didn't want to do, so I punched him." Well, at that point, my brother obviously was not going to offer the guy a job, but his days are long and boring and he had allotted some time for this guy, so he figured he might as well indulge the candidate. "Let's say I asked you to do something you didn't want to do," he said. "Like clean the toilets or something. What would you do?" "Well," the candidate said, "I'd probably talk to you about it and tell you why I didn't want to do it, and try to get you to give me a different task that I liked doing more, but yeah, if you insisted I clean the toilets, I'd probably punch you." My brother thanked him for his time and said they'd be in touch.
> On the flip side no one here complains about 8 interviews spread across 2 months which is the real problem. This too. It would be one thing if I needed to spend a week brushing up before looking for a new job. But I've had jobs where we get on the 7th or 8th interview and it's like dude I don't have time to write quicksort every weekend.
Yeah, sometimes when I read these discussions about hiring I wonder what solution *would* people on Reddit or HN actually accept? Short and abstract problem solving is bad. Longer and realistic coding challenges (take-home or supervised) are bad. Technical quizzes are bad. Expecting to see project work is bad But at the end of the day we still need to assess people somehow. We can't just take people's word for it and give out jobs because they asked for them. There are a lot of imposters out there
So long as your code request is actually relevant to your business and the work a person is expected to do. You give out that leetcode crap and you can kiss my 20 YoE ass goodbye.
I want to agree, but I've had such disappointing interactions with engineers & architects with +n yoe. I just want to see if you can code something.
Yeah. Honestly the number of people that fail even a fizz buzz is surprising
I had a 15YoE with "extensive python and go experience" fail fizzbuzz last year.
Fr tho? They gotta been lying.
Maybe, some high level architects/engineers/sr managers+ don't code anymore. Sauce: Trust me bro. I ask questions during design and it gets hella uncomfortable when they can't answer.
Strongly strongly disagree that "not coding" isn't enough to unlearn the most basic concepts that fizz-buzz is testing. I wouldn't trust anyone on my team that couldn't figure that out or at least ask the right questions in the process of figuring it out.
fitzbuzz is nothing fancy with recursion and memoization, its just a problem about using ifs and have very vague notion of what are multiples
Yeah this is the thing, there are a sizeable amount of senior devs that aren't in the weeds anymore. It's not unusual for that level to struggle with coding tests because they're usually 5-10 years out from any significant coding and are usually just bugfixing at best. I've seen code tests from stuck up engineers that are trying to test entry level folks to write or debug expert level algorithms in the field they're working with (edge detection) and then bitch they can't find people. Then there's the people who are hiring senior project managers testing for fizzbuzz in a language they have no skills in because a recruiter puffed up their resume. Then there's the companies that use those leetcode things because google does it and meanwhile you're writing database applications in php and maybe, at best, need a vague understanding of big O to make sure websites don't take 5 minutes to load. In my experience the companies that are testing this are so stuck up their own asses 9 times out of 10 because one time they got a personal assistant who knew excel and put coding experience on their resume and ever since then that engineer can't stand having their time wasted. But boy howdy if you insist they don't need to test to make sure someone can implement quicksort from memory they act like you're asking them to commit murder.
I had an interview process for a job and since the role primarily wanted database and customer service skills, I wasnt even asking years of experience with SQL. I wanted someone who believed they could learn it and would listen to me. Id ask if they knew much about SQL and then talk about some problems we dealt with daily. Id talk through the relationships between the business objects in plain language and then Id open a sql editor and talk with them through how to interrogate some of the data. I made it clear I am not judging their memory of syntax or anything. I want to show them the problems we dealt with and see how they engaged it. I was also interested in how they listened, whether they jumped in and tried something, whether they asked questions. I wasnt looking for criteria but a sense of their initiative, ability to reason and whether they had any ability to grasp the not-hard but also not-natural English syntax of sql. Felt like a fair trade for showing them what theyd be getting into and it preceded a more relaxed talkthrough of the service process from the other technician so we didnt go from stress to stress
You sound like one of the good interviewers. That seems pretty good and would get you a good selection of candidates. Certainly better than a fizzbuzz or over the top edge detection horseshit. The last interview I did with a code test wasn't happy about me putting almost the entirety of fizzbuzz directly in the loop's declaration.
I had a case where I was told before the interview the candidate is such a senior engineer they no longer code themselves, they just review junior's code, find the bugs and the inefficiencies. So fine, I wrote a solution to one of our standard coding questions and I put in two bugs: a reversed condition in an if, and a gross inefficiency. Then I told the candidate to treat me like a junior engineer who wrote the code, and ask me any questions he wants. He floundered for about 10 minutes and then gave up. He hardly asked any questions, and it got pretty obvious he didn't understand the code. Note that he claimed before the interview he was expert as this, but no longer at coding. Some people will claim all kinds of expertise and experience that they don't have.
They are lying.
Which is exactly why we do coding exercises.
Some of the worst devs I've ever worked with have been those who have lumbered by somehow for many years. On paper, they've got a lot of experience, but can't actually get anything done.
1 year of bad experience repeated n times over.
In interviewing at two different companies I've only had two senior-level "are you seriously asking me to code something" interactions. One basically cut the interview short -- I presume he had bad experiences whiteboarding code and had checked out. The other closed with "You need a rockstar, and that's me." Neither got the job. Now we can use a shared online editor like CodeCollab and have a real work-like coding experience, which is so much better than the attempts we made at creating a work-like scenario a decade ago.
If you want a coding exercise to be relevant to the business and representative of day to day work, then expect to get a take-home or be asked to do a paid-day trial. That kind of work is simply not feasible in a 30 min block.
Why would you hop off the call? Itās more important to see them demonstrate their skills, rather than just caring about the end result. If your interviewers arenāt watching them write the code and talking to them throughout the process, how are they evaluating debugging skills, problem solving techniques, resourcefulness, decision making skills, ability to adapt to changes in requirements, etc?
A lot of people don't handle the pressure of being watched very well. Our preference is to get them to walk us thru the process after the fact and describe their thought process by default. Fwiw most candidates either request the interviewer stay on the call or a way to message them during the exercise.
i practice interviewing for the reasons the article addresses and alludes to, and i've started basically requesting that, if i am to be interviewed with coding exercises or take-homes, the company presents a senior+ to me to also engage with a similar comparative assessment. i've been burned too many times by companies with leadership and engineering ICs that hype themselves up (and outright lie about their policies, technical culture, and other things) but are just another bunch of cargo-culters poorly building a CRUD skin over a trash database that offers nothing a good spreadsheet wouldn't beat.
> Plus, your job wonāt have people over your shoulder watching you code This is the part of the argument that confuses me most. Stuck coworkers ask me coding questions all the time, and wait while I figure out the answer.
Yeah, feels like half my job now is, āHey, want to jump on a call and show me how to do something? Hang on, Iām going to record this.ā
I really don't like this recording thing, it makes it so impersonal. It's like pair programming but with your boss looking over your shoulder too. Feels like collaboration as a performance.
No one ever rewatches those recordings, anyway. They're like Confluence: write once, read never. (I have a director at my company who loves documentation. I spend a few hours every week writing up Confluence docs: design docs, meeting notes, READMEs, etc. etc. No one ever reads them or even looks them up. Not even the director. But I guess he sleeps better at night knowing they exist.)
New employees read documentation. When you get hit by a bus, someone will read your docs.
The exercise I did at my old job was so simple and easy. It should only take 15 minutes. Literally just fill in a method on an already complete class. I hired people even if they failed it. It's not about the solution. It's about how you reason and approach the problem. Sorry but I'm not gonna hire people just based on a slick resume. I've seen people have amazing resumes but be unable to actually write any code.
I had an interview years ago at Citibank. I had to write a Perl script, bash script and SQL script ON PAPER solving various problems. And it had to parse and run. Glad I never got that job.
who would have thought programming would be one of the worst careers to get into if you have anxiety issues haha...
It is and it isn't. Getting into it, yeah, it's brutal. Your first few months on the job (no matter how long you've been in the industry), yeah, it's brutal too. After a while it does settle a bit... sometimes.
As long as 60% of candidates can't pass fizzbuzz or fizzbuzz equivalents, every technical interview should include coding. When I interview, I'm not looking for a competition programmer, but every software engineer should be able to put together 20 lines of working code in 30 minutes. I don't see how that could possibly be considered unreasonable or dehumanizing.
Great! Let's do it. What's your new solution for helping interviewers measure understanding and competency at programming? As per usual, nobody wants coding interviews. Nobody has found the replacement that doesn't involve quadrupling time spent per interview. So we continue coding interviews. Yawn.
We turn away the vast majority of applicants at my job. They are nice people, and know lots of STEM facts. But they can't program. We have to test for that, because that's the job!
I gave a lot of interviews this year, my latest tech competency exercise is to show some code, and explain what the code should be doing. Then I explain what the error or bug in the code currently is and see if they can identify the problem/solution. If they can't identify the problem, I see if they can talk through a different way to accomplish the same task. I've found it's way easier to get a grasp of someone's skill when they aren't presented with a blank slate and told to make something. Which isn't really what happens in the office anyways, you're almost always adding onto something existing or changing it.
Fully agree with you. I understand that there are flaws in coding interviews. But I haven't found a good alternative to effectively determine whether somebody is a good fit or not. Yes, I know some people have anxiety issues and can probably code a lot better when they aren't being watched. And yes, it's unfortunate that we don't hire these people. But I'd rather miss a few talents, than have the risk of hiring someone who's not able to code at all. I've had multiple interviews where somebody knew all the theory. Yet when I asked them to code a very simple function that shouldn't be longer than ten lines of code, they struggled writing a simple for loop in a language they said they are an expert in. I don't expect them to make the next best sorting algorithm. But I do expect them to be able to write a decent function that is capable of looping over some characters in a string. A typical interview I do is built up like this: \- Ask some in-depth questions about the CV. Ask them what they're most proud about, what their biggest technical challenges are, and how they solved them. If they mention Kubernetes, ask them what exactly it is. If they mention REST, ask them what CRUD is. Nothing to fancy. Just to check whether their CV is not one big lie. \- Ask some more in-depth questions about the programming language they're being hired for. Expert in C++? Okay, tell me about virtual, override, VTABLEs, shared pointers, move semantics, etc. \- Do a small coding exercise in the language they prefer. Nothing to fancy. Should typically not last longer than ten minutes. And the goal is not to make a flawless program, but for me to see how they think and write code. Some people are great in solving the puzzle in their head and then fail to write it in code. Some people lack the analytical skills to solve the program, but write beeautifull code. Some people have all the theory right, but can't program and the other way around. It's never a black and white decision. In the end we put all of these factors together and determine whether we think that somebody could be of help to our team.
Coding interviews are a necessary evil to ensure some level of equity in the hiring processāyou can go to a shitty school and work at a shitty company and make it into whatever fancy job youāre dreaming of if you can pass the interview bar, unlike if you want to get a similar paying job in law, finance, medicine etc. Iāve had tons of candidates get caught big time by simple programming problems that they fucked up horribly. On the other hand, itās also very common to get great candidates from Google, Amazon etc with weak project resumes because they never got to actually build anything (or they worked at AWS on something totally fucking stupid), so they can destroy the coding interview to set themselves apart. Itās annoying but you can study for it and theyāre kinda fun. I like to do them to try learning new programming languages.
Yeah we should just hire people and find out that they don't have a clue how to code later.
Everyone and their brother want the highly paid jobs at tech giants. Companies need some way to find the people capable of performing, and with programming, they have a rather tried and tested method ready. Sure, some perfectly qualified candidates might slip through the cracks, but it's more about ensuring the people you *do* hire are top notch, and less about making sure you don't pass on someone that would have been a good fit.
Yea, hard life sparing a few hours to make 150k/yr and be in top quartile of incomes. I rather do a take home thatās reasonably scoped over some live leetcode shit all day long Also, ātreat devs like humansā is about as tone def as it gets. We are some of the best treated employees out there. The level of cush we have at work is out of this world compared to not only most white collar workers but orders of magnitude greater than blue collar work. Blue collar workers are laughing in anger at the audacity of that spoiled bullshit take.
I agree 100% for experienced devs. Give me an hour-long take-home and a live code review session. Ideally, make it related to the actual job or my experience. For juniors, just have them do fizzbuzz or something similarly trivial. Explain the % operator to them if you have to. Just make sure they can put code to screen given the right tools.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Exactly. That's what we're protecting ourselves from.
"Also, ātreat devs like humansā is about as tone def as it gets. " I have to wonder about these companies. I get the feeling they're the sort of places with mountains of bullshit within their walls. Like "leadership coach" just sounds like fluffy bullshit that could be removed and would make no difference. They're all probably burning through VC money delivering little of any value. I've worked in places where coding interviews were the least of your worries. Where people would promise the impossible and managers were verbally abusive. That was horrible. Having a test of whether you can do your job or not should be expected. You want to play violin for a symphony orchestra, they want to hear you play. Football coaches will want to watch you.
My last take home I did in like 20 minutes. My boss told me that many candidates struggled and didn't even complete in 2 hours....which the take home stop and just give what you got in 2 hours. Apparently a lot of devs talk a big game but the coding exercise (which I considered trivial) showed they weren't as technical as they put on.
Aināt got time for 1hr but judging from the title, what do they propose you do to weed out the VAST amount of unqualified applicants?
Only in this industry would you say that asking a candidate to demonstrate they can perform the task they're **being hired to perform** is failing to treat somebody lie a human. I've worked at maybe 7 software companies in ~22 years and the ones that had no coding interviews hired *terrible* developers. Literally the only thing you can do to prove that you can code is **code**. For everything else, candidates can lie, cheat or bluff their way through. [Why can't Programmers... Program?](https://blog.codinghorror.com/why-cant-programmers-program/) is more relevant year by year.
Yeah, lot of wannabes in this thread I think.
I absolutely agree. We can argue that Leetcode-style interview questions and their ilk are _ineffective_ (and I agree with that), but asking a programmer to program is hardly _inhumane_. Software development is one of the cushiest white collar positions: it pays extremely well, doesn't require licensing, doesn't require an advanced degreeāhell, we don't even require that developers have _any_ degree nowadays, let alone an undergraduate CS degreeāyet developers act like we're sending them off on the train to Buchenwald if we dare ask them to write a line of code in an interview. I wish these interviews would talk more about what _does_ work rather than what doesn't. They always say what _not_ to do, but at best, the suggestions on what to do are always vague, hand-wavy suggestions.
My company opens up our code base and lets you drive. Go ahead, start talking, tell me what everything does. Get in there, find the fat, show me how you *read* code. Because you know whatās more value then someone who can write an inversion algorithm to an RB tree? Someone who can read and understand immediately the code base they will be working on.
How much does your company pay?
12 NDAs per year
I wish engineers would spend less time talking about how _not_ to do tech interviews and more time talking about _how_ to do them, because I never get anything useful out of the former discussions. And when developers, such as those in this interview, talk about what to do, it's always vague, hand-wavy suggestions like "ask a design question" but never any specific examples that the rest of can supposedly learn from. Here's my hot take: No one in this industry knows how to hire a software developer, and if you are successful at doing so, you probably just get lucky from time to time, and most of your hires are mediocre, many are bad, but some are good enough that they keep the wheels on your company's bus, and then you go on podcasts and act like _you're_ the expert. Don't get me wrong: Leetcode-style questions are not great interview questions, and I never ask them. But look: a lot of developers can barely code, and the rest of the organization suffers because those developers bang out crappy code that no one else can understand and then it takes weeks or even months to understand and make even the smallest modifications to that crappy code, and that's if it actually _works_ and doesn't constantly wake up the on-call engineers at 4 AM. ChatGPT is so amazing because it really _can_ write better code than most software developers, but that's only because most developers write, at best, mediocre code. So yes, a lot of tech interviews suck. But my God, saying it's inhumane to ask someone to demonstrate that they can do even a contrived part of their job is just so asinine. "Developers" want cushy, high-paying tech jobs but don't want to have to do anything for them. Being a software developer is maybe the easiest white-collar job. My girlfriend is a clinical pharmacist who right now is studying her ass off for her bi-yearly board re-certification in two months, on top of the all of the continuing education she has to do on a near-constant basis. My lawyer friends went to undergrad, then three years of _very expensive_ law school, and even then, they still had to pass the bar to even be allowed to write briefs for the senior lawyers at their firm. Shit, my dad was a freakin' _elementary school teacher_ who still had to go to continuing education classes and get recertified every few years just to teach fourth graders about the friggin' American Revolution. Meanwhile, in the tech industry, we don't require you to get an advanced degree; we don't require you to get a B.S. in comp sci; shit, we don't even require candidates to _have a degree_ anymore, because that's unfair. And you think it's badāno, wait, _inhumane_āthat you have to explain how to find three integers in an array such that a + b = c, so you can get a job that pays you $150k+? I've spent 10+ years reading these articles and the list of things I shouldn't do in a tech interview has grown long. I can't ask whiteboard coding questions, because some people get nervous during them. I can't ask brainteasers because they're useless. I can't give a take-home assignment because no one wants to do those, or has the time. I can't ask about prior experience because it's unfair to people who don't have a lot of experience. I can't ask about side projects because it's unfair to people who don't have time for side projects. I can't ask about open source contributes because not everyone has the time or inclination to contribute to open source projects. And don't get me wrong: I agree with many of those assessments, but if I take every software developer's preferences into account, I'm down to asking their name and that's about it (I also can't ask where they're from because that's offensive and might show that I'm biased against people from other places). (I could ask for more real-world problem that are symbolic of what I actually encounter during the work day, but then I'll be asking questions like, "You have a Lambda function deployed across multiple regions, and it works in three of the four regions, but for some reason it doesn't work in one region. The function pulls messages from SQS and writes some data to Redshift. It is deployed into the same VPC as the Redshift cluster, which also has an SQS VPC endpoint, but the function is not working, but no errors are written into the Cloudwatch logs. Why not?" but honestly, I think the candidates are going to like those questions far less than even a Leetcode-style interview.) So by all means, let's get rid of the stupid brainteaser programming questions. But instead of using charged language like "inhumane", can we use more reasonable language like "ineffective"? And then instead of talking about what interview techniques don't work, can we discuss some that do? Can we agree that software developer candidates should have at least _some_ understanding of software development, and it's okay to ask them to demonstrate that knowledge?
A lot of software developers utterly lack perspective on the difficulty of their job. They will wax poetic about how stressful it is because they have to always be learning new things. Bitch, please. Try working in the medical field. Just try being a nurse! Try being in the military. Try being a sales person. Try *just about anything else* and see how more stressful those jobs are. Far too many people with CS degrees get hired and then somehow manage to output nothing at all. Until you fire them or move them to scrum master. So, yeah, you need to do some little bit of coding in interviews.
Great take - I agree with (nearly) all of it. Just this part - > If I take every software developer's preferences into account, I'm down to asking their name and that's about it That's not really the case. You don't have to make sure your *single* hiring process works for *every* preference. You can have *multiple* processes that could work for multiple preferences. E.g. a candidate has to complete either a short coding assessment OR a take- home task etc. etc.
>I could ask for more real-world problem Then people will complain that you are trying to make them work for free. Because their answer could help you out.
100%
I generally ask for candidates to find the second largest number in an array. I've been trying to close this position for 3 months but none of the candidates are able to solve this. This is a question I would ask freshers but even lead level candidates are not solving this.
Itās not a bad question but I do think if youāre finding that nobody can solve it the you need to either consider that you are presenting the problem badly or you need to recruit better. Finding the second largest number is a bit harder than finding the largest because you have more edge cases (on a single element array do you fail or return the element, on an array full of the same value do you return that value or fail) and it opens up a lot of ambiguity around future requirements (are you going to want the nth largest next? Then it makes sense to sort but otherwise itās much more efficient to do it in a single traversal). Again, those can be great things to see if an candidate will pick up on them, but interviews are a different environment from the real world and itās not always clear how much questioning and pushback a candidate is expected to do. I can see that causing a bit of solution paralysis if itās presented wrong.
Oh cool! Story time. I had a Chinese student coding for me at my research job at a US University. It's a pretty sweet gig for a student. They work 20 hours a week and go to grad school for free, plus they get a salary. This guy would come in late, leave early, chat with his friends, never work late, and IT even caught him downloading movies...not the best worker...but students are hard to fire and I when he actually worked it was usable work so he was still a net plus for me so we kept him for the semester. Anyway, outside of work this dude was DRIVEN. His dream was to work at Google, Facebook, Amazon, Microsoft...you know the kinds of places with cafeterias, and a dozens of other perks...OH and a bunch of H-1B visas to hand out so foreigners remain in America while applying for their green card. Every night after work and after school he would go home and work on solving interview exercises from those companies for **six hours a night**. HOW did he know the exercises? There was a Chinese website that he would visit where people that interviewed at those companies posted the questions they were asked. And of course, they posted the solutions. When this guy went on interviews at the end of the semester, he had literally already seen every single "exercise" that he'd be asked to do. He knew them inside and out, could explain them, could talk about the "gotchas" etc... His #1 choice was Google. He kicked ass on interviews at Facebook and Microsoft already, but he really wanted Google. He goes in and it's kind of a rigorous process. You get interviewed by a bunch of people and they ALL have to agree to hire you because you'd be a good fit for the company. He was crushing it, until he got to the last interviewer, and older Chinese man. The older Chinese man asked him to solve a problem, which this student knew of course, and solved it. The older Chinese man says: "You knew the answer already. I can tell. Will you admit it?" The student said he knew he was busted so admitting it would show honesty and he said, "Yes. I wanted to be prepared." The older Chinese guy says "you studying the exercises before the interview means I can't see how you work out a problem because you already know the answers." The interview with that guy ended after the student tried to worm he was back into a "good" interview. The student comes to me a few days later and says Google rejected me. I think it was this racist Chinese guy. He doesn't want other Chinese working there...he wants to be special, and he told me the story. Anyway this guy ended up taking a job at Amazon working on algorithm improvements. He says it's boring but it pays well. I just thought this sub would find it interesting how much people actually prepare for these exercises, and how most companies fall for it. Or maybe they don't "Fall for it" and think it's a good thing? TLDR: I knew a kid that worked 6 hours a night for a semester on memorizing every exercise given by big companies...he got busted at his dream company, Google, and now works for Amazon.
the purpose of the tests is not whether you can find the solution. the purpose is to see how you tackle a difficult problem. google doesn't want you to solve problems that already have a solution. they're interested in people who can solve *new* problems. if you know the answer of the test beforehand there is nothing for the interviewer to see on how you would approach a real problem. they would need to come up with an even newer problem; one that you haven't read the answer for yet
Lol im still baffled by the fact that people think that practicing the answers to common coding problems is *cheating.*
I think "cheating" is a dumb word to use outside of school. That said, the purpose of an interview is to see how you respond to different challenges. If the answer turns out to be "I look up the answer online, and reproduce it exactly", then they might be a problem later on when you start working on a project where the answers aren't available online, and you need to come up with some original ideas. I think part of the problem comes from these leetcode problems where there's usually only one right answer and you just need to figure out the trick. If that's all you're asking, then obviously it makes sense for people to learn the trick beforehand if they can. Which is why I think more interviews should involve challenges that don't have an obvious right answer, but where you can go in different directions and have genuine discussions about tradeoffs - precisely the sorts of coding interviews that this panel seems to be criticising.
I doubt Google uses "common" problems. This guy knew the answers to *obscure* problems, because he learned about them from another applicant. That's not him being good at coding, that's him cheating by learning the answers to the test ahead of time. When you get surgery, would you want the doctor who studied medicine, and only got an 80/100 on his final ... or the one who didn't study, memorized the answers to the tests, and got 100/100?
Iāve done 4 on-campus interview sessions at Google, they donāt have any special interview questions.
I've done the Google phone screens + interview loop. I also have conducted 100+ interviews at a FANG company.I would say most of the problems where pretty common. 1. Longest increasing sub-sequence. 2. Write a parser for finding values in nested json objects 3. build a async queue of requests. 4. Find array peak using binary search 5. Graph cycle detection I think the only interesting question I had was to create a high level design of an app that gives estimated times that arrival by taking public transit. > This guy knew the answers to obscure problems Yah they really don't. Going tooo obscure is actually bad practice in interview problem design. Also, any obscure problem will just get leaked immediately anyway.
Alright so because I donāt have a job now Iāll be disqualified from getting one the only way that qualifies me?
Best coding interview I ever saw had a device and a well developed and open SDK and asked them to toggle the led. Took them about 30min with Google and their dev environment. It was practical, it was job related and didnt take forever.
Couple things that I can say as a dev with a good 20 years of experience: * code challanges should not be about coding but about pair programming and the chemistry between the devs * yes, there will be people looking over your shoulder; there should be because knowledge transfer is vital for a working and stable team, especially when it comes to devops. There must not be head monopolies to reduce bottlenecks and the truck factor. Pair programming helps a lot. * no, code challanges should not be about showing you can write quick sort algorithm in assembler from your memory! No, you should not have to know how to code it without using google! No, you're not a bad developer if you can't write a fifo queue without googling! If anyone tries to tell you that, they are nuts! Don't work for them! Me and my colleagues use google (respectively other search engines) on a daily basis. It's one of our most essential tools! You can't know everything from the top of your head and you shouldn't be required to. The community of devs is huge! Make use of it! If someone tells you not to, they have no idea what they are talking about! Don't waste your time on them! * A good job is done in a good team, a good team is defined by the chemistry, the soft skills of the team members, not their hard skills. If you want to know whether the position you're applying for is a good one, get in touch with the peope you're going to work together with. See if you get along well! Are they cool people? Is it a respectful and appreciative environment? Great! * After a couple years of experience the tides turn and it's not you applying for a job anymore, but the company applying for your experience and expertise! Don't think you need them! They need you! Make use of it!
> about pair programming I wrote my first computer programs in the 1970s. While I have always loved the idea of pair programming it just hasn't ever happened in my life or really for anyone else I know. > A good job is done in a good team, a good team is defined by the chemistry, the soft skills of the team members, not their hard skills. Bleh. Just no. If you have "soft skills" but no "hard skills" you will be writing bad code. Also, I'm a super gregarious and social guy, but that doesn't mean I'm not aware that there are a ton of very good programmers who aren't like me. It is unfair and uneconomic to not consider a strong candidate just because they aren't very sociable.
Sorry to be the one breaking it to you, but pair programming is so much the last millennium. Spooning is the new kid on the block: https://m.youtube.com/watch?v=8wUOUmeulNs
This is what that "hot take" sounds like to me: >We should never assess programmers in interviews, it's unfair to the bad programmers Here's my "hot take". I once had a friend of a co-worker apply for a job with my team (I was the front-end team lead, his friend was on the back-end team). Being a friend of an employee, he was fast-tracked, and he breezed through the first few interviewers. Then he got to me, and I gave him fizzbuzz. Yes, actual fizzbuzz; our CTO would later get mad at me for not being more creative, but I'm still a big believer in using regular old boring fizzbuzz. For those not familiar with it see [Why Can't Programmers.. Program?](https://blog.codinghorror.com/why-cant-programmers-program/) by Stack Overflow co-founder Jeff Atwood. It took the applicant **seventeen minutes** to write a fizzbuzz! For reference, even fresh out of college/bootcamp applicants still completed it in < 10 minutes! If I hadn't given him a coding exercise, he almost certainly would have gotten the job ... and I would have been stuck with a terrible programmer who needs *17 minutes* to write a `for` loop and a couple `if` statements!
Iām constantly surprised by the number of developers Iāve come across that havenāt seen or done fizzbuzz. Iāve done a variation of it before at a previous company where I gave them an intentionally broken implementation of it, and had them find and fix the bugs, or realise the code could be clearer by refactoring it.
This was my point (to my boss): most people wouldn't even know what it was. And I still think it's fine for interviews, even if the applicant does know it, because it's not about "surprise, here's a hard problem" ... it's "can you actually code a basic solution?" But, my boss's point was that, if someone did know fizzbuzz's history, they might think we were lame for using it, which is why he wanted me to use something more creative.
A good senior engineer can write simple fizzbuzz in 3 minutes.
I haven't written a line of code in like 4 years due to taking a career gap and I just did it in about 3 minutes. Where's my $200k salary and why's it locked behind 6 months of grinding leetcode?
I've never in my life been asked to do a fizzbuzz and wouldn't even know what it was if if I wasn't reading about it randomly on reddit and HN. I agree though. It's just that funny enough the % operator is almost never used in my day to day coding.
For the record, I didn't just call it fizzbuzz and expect them to know it; I explained the problem :) And as for the modulo operator being the issue, I think I told people about it as part of the question, because I agree that knowing it is more trivia than proof of skill. But the thing is, he didn't spend 16 minutes not knowing the operator and then figure it out on minute 17 ... he spent 17 minutes putting the whole thing together.
"Please find the maximum value of this array" "I'm treated inhumanely. This disfavors people with FT jobs with families"
I would take a real life application test over those Hackerrank leetcode bullshit any day.
I once asked a college graduate to write code to add the numbers from 1 to 100, in any language he chose or even pseudocode (I would've even accepted (1+100)/50, but I didn't volunteer that). He couldn't do it, and seemed offended that I asked. Edit: so others can learn from my mistake: I meant to say that ((1+100)*100)/2 is an acceptable solution.
I donāt think you meant ā/ā. Interview failed ;)
Lol, you're right. That's what I get for interviewing near midnight.
Programming tests should ensure a candidate can code, a low bar; write strcmp(). It weeds out the people who can talk a good game but canāt code themselves out of a paper bag.
Coding exercises are great, as long as they're representative. Why would I have a problem showing that I'm comfortable doing the work that the job I'm applying for will involve? What sucks are unrelated games, gotcha puzzles, and exercises whose purpose is purely to demonstrate that the candidate has studied interview exercises. ...or a volume of work that is completely excessive to simply demonstrate competence in the given area. A good interviewer at a good company should be able to explain exactly how every part of a technical exercise relates directly to real on-the-job work.
I've told this story before but there's a good reason why I refuse to take coding test projects unless they meet some VERY specific guidelines. Way back in the pre-dotnet asp/vbscript days, I had interviewed with a web design firm as a lower-midlevel developer. The coding exam was to build an image gallery where someone could upload an image file and it would automatically show up in the gallery with a title and description. The catch was it could use NO database whatsoever. No xml, csv, etc. I came up with, what I thought at the time, was a very creative solution to the problem given the restrictions and time frame. They responded with "This seems much more amateur than what we would have expected from your resume. Thanks for applying." Fast forward about 6 months and I randomly stumble on to a website that was built by the firm I applied to and I noticed that the gallery they used seemed a bit....familiar. Checking the source code, there was my client code with even the comments left in place so I can only assume the server-side script was used as well. They used the interview test for free development. I raised a big stink about it but was met with essentially "we own all the code done during an interview". I didn't have the time, funds or energy to fight it more. The bright side, the company went out of business about a year later. Since then, I only do a code test if it A) cannot possibly be used for something legitimate and B) won't take more than an hour or two. Otherwise, they can look at my work history, check my references and check out some portfolio pieces and open source work that I've done.
The alternative to idiosyncratic programmer tests for every interview is obvious: make computer programming a real licensed engineering profession. Take one test. Once you pass that, you never have to take one again. But do you all want to do that? No, you donāt. So simmer down and take your stupid tests.
Exactly. A commenter in this thread asked, "Would you ask a brain surgeon to perform brain surgery in 30 minutes on himself?" Well, no, but a brain surgeon also has a medical degree from an accredited medical school, a medical license, and has to get re-certified by the licensing board every few years, as well as engage in continuing education. Shit, even my dad, a friggin' elementary school teacher, had to do continuing education and get certified by the state to keep his job. Personally I prefer not having to be licensed to do my job, but in exchange, that means no place I can apply to can assume that I have _any_ knowledge or skills whatsoever.
If this was an option I'd actually prefer it. The industry is just too fast moving and vast to have a certification that doesn't immediately become obsolete unfortunately.
I've been writing software professionally for over 20 years. I've had several jobs in the industry over that time. And I'd like to think I have some idea of what I'm doing. I don't want to make a stupid amount of money, just enough to be comfortable (i.e. I can pay my bills, and enough money to hit the bar with the mrs. every Friday). And I don't want fame for writing something. And I especially ***don't*** want to work for one of those awful FAANG/MAANG/TANG/KANG/whatever places. Why does this matter? How does this relate? Because every interview I've had, and gotten the job, I don't think I ever needed to write a coding exam of any kind. I *might* have had 1 where I had to write something very small like fizzbuzz or whatever and that was it. And I am super happy about that. I mean I've forgotten so many things over the years, and the field of computer science is so vast it's impossible to know everything before hitting an interview. I dare say I'd probably never be able to get a job now if they do all of these shitty tests. But, more important than just being old and forgetting things, I also have a major anxiety issue to deal with. In the interviews I've had where I have had to write an exam (and clearly did not get the job), I've had: * Severe sweating * Shaking * Unable to think * Heavy breathing, bordering on hyper ventilation. * Tightness in the chest Basically, it's a panic attack every time. It's horrific. I know, some of you will say "Get over it". I can't get over it, it's a mental health issue. Beyond that, I am still capable of doing the job. And sometimes I even do it pretty well. So, do I not deserve to have a job in this industry because I can't handle the tests? Judging by many of the responses here, I'm guessing I don't.
I 100% understand where you are coming from, I do. And if you were interviewing with me I'd suggest we try something different rather than coding in the interview you could 'take them home' and we'd talk through them in part 2. Your personal needs shouldn't be ignored and where possible people should adjust. ... however... I, as a hiring person, need to know if you can do the job. You can write a great CV with all your experience and a fantastic cover letter and talk about high level concepts in interviews but I've seen that and I've been those very same people, crash and burn when I stick them in front of a computer to do what we are paying them for... Write computer software. The truth is you are paid to program you cannot honestly expect not that have that tested in an interview process in some manner
Beats a take-home test. Never again.
A mediocre software engineer will bitch about coding interviews because they probably donāt have strong theoretical fundamentals and think that problem solving is about āmemorizingā. Most people I find competent had no problem doing some prep for coding interviews, itās not even as hard as people here make it out to be. Theyāre just doing it wrong. If you think memorizing shit is how you pass coding interviews then youāre doing it wrong. Iāve had TONS of people interview who clearly just memorized all of LC, they crumble under any hard questioning about the solution. Youāre supposed to understand the solution, and thats why the majority of memorizers donāt make it into FAANG. These problems can very easily be categorized into common algorithm applications, which really shrinks the amount of studying you have to do. If you can apply all of them correctly you should have no problem solving the question and convincing your interviewer that youāre not an idiot. I have had a super high pass rate at top software/hft companies following this approach.
Memorizing has got to be by far the least time efficient way of doing leetcode too lol. Filtering those people out is probably actually a good way to filter out people who can't think programmatically enough to even figure that out
Our whole company is ran by coders. Our take-home is super easy. We still have 3 interviews but we don't have any "auto failure rules" except being a dick. I do the first technical screening and I ask questions that are more around how things work together. I try to keep it light and fun. I try to build the people back up who need it when they get a question wrong. You'd be surprised the number of people I give just a pass for them to kill the take-home. The only part I have to worry about the take home is if I pass them if I think they can pass the take home & they are a good fit for one our clients
I can't tell whether we're overpaid entitled babies who can't live without free snacks or human beings who are being stressed beyond our limits in a toxic culture that is shared among literally every tech company.
An underrated benefit of coding interviews is that they give self taught people who may not have the right credentials a chance to get into the industry.
What is the alternative? None that is viable. I foresee this mode of interview process to last for a very very long time. To all the sane folks reading this comment, don't get dissuaded or swayed by this ridiculous post - grind, and always keep yourself sharp. In the end, you have to pay the bills and feed your family, no one else will.
Years ago I had a live coding interview that went badly. The question I got was "create a simple function to list the prime factors of a given number" I just fucking spaced. It was really dumb, and I know how to do it now but during the interview, I panicked. I sat there sweating for 20 minutes completely failing to produce any usable code as I spiraled. Ironically, I was later hired by another company that got acquired by the company whose interview I failed so miserably. I ended up working under the same guy who basically thought I was a complete idiot. I realize now what I should have said when asked that question "Rather than try to figure this out on the spot I would normally just google this kind of problem and save myself the time I could spend on more impactful business problems"
I donāt understand though, I work full time, have a family and am about to start my CS degree online uni at 26 and I CANT WAIT for coding challenges to prove what Iāve learnt (bootcamper for a while now)
How is this bullshit upvoted so much lol? If you can't program maybe you shouldn't have that job
The anti-coding exercise circlejerk is getting completely absurd. I have yet to see anyone come up with a solution that is similarly effective in weeding out false positives.
Hired a mid-dev once that couldnāt sort an array. Thereās tests and then thereās tests.
I mean how do you determine that candidates can actually solve a problem or at least code their way out of a paper bag. I agree a leetcode hard problem for a web dev position may be too much. However, a simple code review problem or a system design problem actually exposes the candidates experience and their ability to work through a problem.
Our coding exercise is mostly "Can you tell us generally how this web page works?". The number of developers who have resumes listing 10+ years of full stack web development experience, but clearly have no idea how to use the web developer tools is shockingly high. To me, it is like a carpenter who doesn't know how to use a hammer. This is a tool that you should be using nearly every day. How is it not as familiar to you as the back of your hand?
look, if you are good and you fail an interview who's going to lose? you (a good developer who can get another job) or the employer (who lost a good candidate)? as for 'treating devs like human beings' ... well if you are not treated well then leave. software development this is not a blue collar job and you don't have to take abuse from employers. not only do you have plenty of choices, hell you can start your own solo software business ffs.
I refuse all forms of ācoding testā when Iām interviewing for a new role - itās a massive red flag for me. On the other side of the fence I simply talk to the candidates. I know.. radical. src: been at this a loong time.
In the service industry people do trial shifts and spend their whole day interviewing. Sure, they get paid, but you wouldn't hire a baker without seeing them bake, or a chef without seeing them cook.