r/golang Mar 05 '21

Remote Role Interviews

Why do companies insist on using algorithmic code tests when hiring? When this is not what they do on a day to day basis.

2/3 interviews I have had so far do this.

I build applications and api’s. Asking questions about a random topic or asking me to code algorithm on things I would just google in real life isn’t a measure of my skill as a developer or am I wrong?

122 Upvotes

99 comments sorted by

2

u/Asdayasman Mar 08 '21

You're correct. Find another company.

Or, if you need the money, bend the knee.

2

u/[deleted] Mar 06 '21

At the senior level or higher, it's insulting to me to get those kind of interviews. I tell the recruiters when they reach out that I don't tolerate those kinds of things, and if they want me to do something technical then just ask me to implement a simplified version of some kind of feature.

1

u/[deleted] Mar 06 '21

Because a lot of candidates don't know how to code in practice and it's a quick and easy filter.

Ideally they'd at least ask questions that can lead to probing on computer architecture, etc.

3

u/Sancer Mar 06 '21 edited Mar 06 '21

Guy who does a lot of hiring for his remote SW engie team here.

Totally agree. I don’t waste any time with toy problems, they almost always find me the wrong candidates.

My interview process looks like this:

  • Background Screen
  • Light discussion of experience with engineers
  • Take home modeling actual work we do day to day ( 2-5 hours completion time )
  • 1 Hr interview to review / refactoring pair session
  • Final interview with C suite.

The notion that somehow every company is trying to hire the “best” is dumb. Hire engineers you can work with and that will show growth.

2

u/alexsergivan Mar 06 '21

Agree absolutely! Algorithmic interviews can't help to hire professionals who cold solve day-to-day challenges. In our interview process we are giving to solve a real-world problem. I.e. build a simple API, that should be aligned with specific quality attributes.

3

u/muchbravado Mar 06 '21

In big companies, even "APIs and applications" require writing performant code. If you're building for scale, tiny details like "authenticate users" or "store data" become whole subjects unto themselves with tons of complexity and lots of highly technical challenges. Including algorithmic challenges.

1

u/lgj91 Mar 06 '21 edited Mar 06 '21

Yes indeed they do, but when you face those challenges in real life it is entirely setting. You can google similar problems and see if it has been solved before, ask colleagues etc. The challenges I have been given so far restrict googling and strictly timeboxed.

2

u/mattconndev Mar 06 '21

I’ve taken the position that while this is terrible, it’s not going away, and so I want to get good at algorithms for the sake of landing a job.

0

u/brucepnla Mar 06 '21
  1. If you can solve algorithms & data structure tasks it is a good indicator that you would produce a reasonable code and won’t struggle when faced with something reasonably complicated
  2. A lot of companies do want you to be overqualified for a job. Especially in a remote environment there’s no way to invest in up and coming talent.

1

u/Bstochastic Mar 06 '21

This question and variations of it have been beaten to death over at r/cscareerquestions

1

u/kokizzu2 Mar 06 '21

usually mix of both '__') first just to filter candidates (either making APIs or competitive programming questions or both) then goes the interview..

4

u/H1Supreme Mar 06 '21

100% agree. Also, I've been leet-coding my ass off for the last 6 months because lots of companies are using these tests, and I don't see another way around it.

Tbh, I'm not (too) mad about it. As a self-taught programmer, I never learned about more traditional CS concepts. Now, I'm much more comfortable with how and when to use recursion. I'm using hash maps much more now (for reasons I didn't previously). And, holy shit, dynamic programming is such an awesome technique.

For instance, 0/1 Knapsack problem has the potential to solve a ton of business problems, in a very succinct way.

I still don't think reversing a linked list on the spot means shit. But, I don't have a better solution for large companies who need to sift through 100's of candidates.

4

u/eikenberry Mar 06 '21

Those are red flags you are seeing. IE. You don't want a job at one of those companies. They don't know how to hire good people and it will show.

4

u/Bobgar_the_Warbarian Mar 06 '21

It really depends on the role. I ask algorithms questions to candidates when I am attempting to hire someone at a similar level of competency as me since I have used them in my work. Certainly the average day of work does not involve knowing them -- I only implement novel algorithms a few times a year to solve complex problems -- but on those days I do need senior engineers to know how to reasonably come up with solutions and analyze the run time.

One of the questions I often ask has an optimal solution of O(n) time, but the brute force solution takes O(n^n) time. When building a critical piece of our platform this is the difference between being able to handle 10 users and 10,000,000,000.

That being said I typically don't care if an engineer gets the problem right, especially not on the first try. I care if they are able to analyze their run time, take feedback and work toward a better solution. I'm also happy to provide pretty generous hints to push people in the right direction -- when you run into a problem like this one of the smartest things to do is find another smart engineer and discuss it after all.

I test on other things too. Having a great attitude, communication, enthusiasm and work ethic are all incredibly important. Knowing how to write code and structure a project are obviously a requirement. Having a baseline competency in Computer Science, for the jobs I hire for, are also important so I ask questions that require the necessary competency.

4

u/tak1za Mar 06 '21

Agree with everything except for "ask algorithm questions". I'm pretty sure you've implemented them at work to solve some complex problem and finding the most optimal solution is key, but I'm pretty sure you'd have Googled some or the other thing while writing that piece of code. Discussing with your peers is important to know if it would be right or not, whether it was the right approach or not, but limiting interviewees the ability to Google things and simply coding it from scratch in an IDE like leetcode's or hackerrank's, how is that gonna help? That's not how they are gonna work if they are employed! The IDEs don't even have autocomplete in most cases. A much better approach would be to give them a PROPER use case, and then see if they are able to figure out the right way to do it, and then discuss the steps with them. It'd be much better if you are able to see how they are thinking, and not how they end up with the code. If you really wanna see how they code, give them a project, and ask them to put it up on GitHub or somewhere, walkthrough the code with them, see their commit history, their commit messages. That I believe is much more important.

This isn't a rant on your approach. I agree with all your points except asking algorithmic questions which can simply be Googled in most cases.

2

u/Bobgar_the_Warbarian Mar 06 '21

That makes sense and I agree on your point. The only somewhat difficult algorithms questions I ask are on take-home tests so they are not timed and they are allow to use google (though they are non-standard enough that they are hard to google). I ask candidates to site sources, but that is for context on where they're getting their information and what kind of information they seek out.

5

u/NotBIBOStable Mar 06 '21

What really fucking blows is that its almost always in some shitty web based "IDE". Im already rusty on certain languages since i havent touched them in a while, and using a buggy unresponsive interface with horrible autocomplete, no hotkeys, and poor formatting controls makes its a crapshoot on whether you spend the first half of your allotted 10 minutes for this problem actually reading and solving the problem, or fighting with the fucking IDE. Ask me how i know. Seriously blew an awesome job i wanted on a fucking code test, that under normal circumstances (i.e. using goland or vscode), I would have aced. Holy shit, talk about a frustrating experience. Whole thing once you speed it up enough starts to feel like SAT test taking strats with a hell of a lot more on the line.

Also, did a C test for something else and they had a leave a comment button on this question. It was talking about Unions and memory size. For some reason my immediate reaction was they were asking about struct packing and memory allocation concerns associated with it and I realized that based upon the architecture or compiler the size of the memory allocated wasnt definitive based on their info (turn up the optimization on your C compiler and check out some of the weird assembly it generates). Anyways, I assumed it would flag the question to answer later so I clicked the comment button to help them improve an otherwise ambiguous question... Nope, fucking thing navigated me to a different page and didnt allow me to answer the question, but it still kept the time to ticking... FML.

3

u/ntrrg Mar 06 '21

Interesting, so there are Go VSCode Developers, Go Goland Developers, Go Vim Developers.

4

u/aksdb Mar 06 '21

If it's about being fast, it absolutely matters what you are used to. Which is another reason these kind of tests suck. Unless you care how fast someone is without IDE. Which is elitist at best and still nets you nothing in regards to a real work environment in a real project.

-2

u/ntrrg Mar 06 '21

Agreed. But it is not "I can solve this faster with my IDE", it is "I can't solve this without my IDE"

2

u/aksdb Mar 06 '21

Agreed. But it is not "I can solve this faster with my IDE", it is "I can't solve this without my IDE"

Disaggreed. OP specifically said:

you spend the first half of your allotted 10 minutes for this problem actually reading and solving the problem, or fighting with the fucking IDE

It was absolutely about time.

2

u/ntrrg Mar 06 '21

If you are given to solve a problem in 10 minutes, I am pretty sure it would be tied to how fast you think, not how fast you type. Even a simple textarea would be enough.

Don't take me wrong, I am a big interviews failer haha but at least I take responsibility for my failures.

1

u/burros_killer Mar 06 '21

Yeah, but it another professions, like video editing for example, "I can't edit without my NLE" is normal for at least medium level specialist. And nobody asks you to "edit our storyboard that we have here on whiteboard, so we can see how you think")) Because it could be fun, of course, but kinda useless exercise. People just look at other people portfolios.

1

u/ntrrg Mar 06 '21

Yeah, that is absolutely true and I agree, but the video editing software for a video editor is not like an IDE for a developer, it is the whole computer. Asking for editing a video in an interview would be like asking for building a microservice.

1

u/burros_killer Mar 06 '21

Video editing software, once you're familiar with one or two, are kinda the same as IDE, because they all do the same things (professional one at least). So it all just boils down how fast can you push your shortcuts. Editing in this aspect is very similar to programming - it happens in your head. As for asking to edit a video on the interview - depends on video of course, but yeah, it could take couple of hours for a short one, but so does some programming tests. It's just doesn't considered a good practice and most editors will see something like this as a major red flag.

11

u/YourMomsMoistCunt Mar 05 '21

I think the goal is to see how recently you took a class on algorithms, so that they can filter out anyone over twenty three. The theory being that someone twenty three will work longer hours for less money.

4

u/fat_bjpenn Mar 05 '21

Algorithm questions aren't used measure the height of your skill as a developer but rather baseline knowledge. IMO its important to know DS & Algorithms well enough to solve performance problems at scale. That is why FAANG companies use it as a standard.

1

u/Asdayasman Mar 08 '21

It's not important to know algorithms to solve "problems at scale". You are not writing hardcore bits and bytes "should I unroll this loop" algorithms if you're solving problems. You're using a library whose authors have done that for you.

2

u/constructivCritic Mar 06 '21

Unless you're going to be working on the performance team, I don't see any reason why you'd test anybody in performance.

If you join the performance team, you're expertise will eventually be in performance related things. If you join the frontend team, your area of expertise will end up being frontend. That's just how things end up working out.

Plus, when you test somebody on what they're going to be doing, you're already testing baseline knowledge.

0

u/fat_bjpenn Mar 06 '21

I think you're misunderstanding performance in this context, think performant.

For example, if you and I are both candidates for the same position and are given identical tasks. Upon review of the code quality, I would assume that the candidate with the more performant code will be the best hire. This is due to baseline knowledge of algorithms.

Leetcode questions are minimal demonstration of that.

2

u/constructivCritic Mar 06 '21

The link you provided is basically what I was thinking performant meant in this context.

Nobody cares in 95% of the tasks being done anywhere. There's way bigger things to worry about getting screwed up than whether the code will run in O(n), in pretty much all cases.

Heck, just having a best practices doc (which could come from a team focused on actual performance), will make it so that everybody avoids the pitfalls that can reduce performance for a particular language.

So unless you're highering someone who's going to guide your team towards better performance, it makes zero sense to be asking them about some algo they'll never need to worry about or use.

Would be better to focus on what they'll actually be doing, and in that context, assess their knowledge. You can tell when someone is going to be writing bad code in a plethora of ways without resorting to some formulaic questions.

4

u/burros_killer Mar 06 '21

For frontend engineer position it would be rather "candidate with the most readable code" at least in my city. As for performance - nobody expect you optimize frontend from the start (sometimes ever).

0

u/aniketsinha101 Mar 05 '21

I say lets make a project to change the hiring system. What I propose is

1) Integrating Github contribution to ensure Candidate has not started coding 1 month before coding Interview.

2) This point I got idea from freecodecamp where they give you certain task and you have to implement or code the feature.

3) MCQ is other way we can judge.

4) Debugg the code, We spend more time reading the code then writing hence we will be provided with a code and would be asked to debug it.

If you have more suggestion let me know.

3

u/bforbokofios Mar 05 '21 edited Mar 06 '21

I also don't understand the GitHub part. I've been asked numerous times to provide my GitHub account for them to see my projects.

The thing is, between a full time job, freelancing and personal life, there isn't much time or will left to put into side projects.

Reviewing somebody's projects on GitHub is a great way to find out more about their skills, don't get me wrong. BUT, don't make me feel ashamed that I have to work 16 hour days and I can't support a personal project.

18

u/CoDgER223 Mar 05 '21

Algo based interview is truly annoying. I mean it works if your pool is too big and you need to narrow down your pool as fast as possible. I attended a few interviews where 3/4 people made it to the technical interview and we were given algorithmic questions from leetcode. Only one company took real life programing test like building basic CLI tools along with basic programing.

PS: i am not a competitive programing guy and truly bad at algorithmic interviews

-4

u/gororuns Mar 05 '21

Here's a tip - don't try to solve algorithms in Go, it's too verbose and not being able to run code with unused variables is a big time waster. Python is great for algo interviews.

4

u/nikoren1980 Mar 06 '21

This is why we need those interview questions. When you frequently practice solving problems, you don't write code with unused variables. And this is why Python is such a bad option because it lets you do anything and give you the wrong impression that you are writing a good solution.

0

u/iCanHazCodes Mar 05 '21

I thought this at one point my career, but not anymore. These are decent tests of a candidate’s problem solving skills and these types of problems let you see how they think about and step through code.

Also I do occasionally need to do these things in my day job.

1

u/nycmfanon Mar 05 '21

One question that I've come up with on my own to ask, is "Build a package that implements an LRU cache". You can google and use any libraries you want (e.g. linked list), besides a library that straight up offers an LRU cache. To me, it's something that a decent engineer should be able to build in about half an hour, and then be able to describe its performance characteristics, maybe potential features to add (e.g. cache eviction, concurrency), etc.

What are people's thoughts on that?

2

u/dontcomeback82 Mar 05 '21

any example like that is good, small enough to understand and do quickly but mildly complex enough to have interesting talking points. I recommend pairing with the person on it so you can get a sense of how easy they are to collaborate with

-10

u/NativeCoder Mar 05 '21

It shows how smart you are

1

u/gandu_chele Mar 05 '21

To add to this, for me it seems so hard to land any APAC region golang interviews

7

u/sixstringjones Mar 05 '21

I've asked why this is done a million times. I can't tell you how many people have responded with "what's the alternative?". I think if you're in a position to do interviews that force people to think very hard about difficult things, but you haven't spent more than 15 minutes thinking about what "better" might look like, you're not qualified to interview. Conveniently, interview skills aren't generally interviewed for ;-P

-1

u/ajanata Mar 06 '21

I think if you're in a position to do interviews that force people to think very hard about difficult things, but you haven't spent more than 15 minutes thinking about what "better" might look like, you're not qualified to interview.

I don't disagree with this statement but when there's only 5 people on the team we all gotta be involved in the interviews... I am absolutely terrible at anything that requires creativity, so I go to things I know well. Which happens to be algorithm-y things.

5

u/nycmfanon Mar 05 '21

Then what's your answer to "what's the alternative?"

-6

u/sixstringjones Mar 05 '21

my answer is 'think about it for 15 minutes and if you don't come up with at least 2 ideas you should ask someone else to run the interview process'.

1

u/Asdayasman Mar 08 '21

To the sheep downvoting this comment, consider that he's never said he's qualified to be, nor should be, an interviewer.

You can taste bad cooking without being a chef.

10

u/nycmfanon Mar 05 '21

That's not really helpful—I'm asking what you would ask instead, if you were the interviewer?

I don't think that all remote coding problems are bad. The ones that rely on you getting lucky and figuring the trick behind it (I've heard them called "Aha" interviews) are obviously dumb—hilarious description by Eric Lippert: https://ericlippert.com/2011/02/14/what-would-feynman-do/.

But how about something like: "Given a list of numbers, what's the largest gap between them?" E.g. for [1, 5, 6] you'd give 5-1=4. This isn't anything especially tricky, but it shows how you can think through a relatively simple challenge.

FWIW I've spent a lot of time thinking about this as a hiring manager, and have tried a couple other things:

  • The company puts up a PR on github, and asks you to review it. No trick questions, just looking for you to spot potential edge cases, lack of test coverage, divide by zero errors, etc.
  • Build a package that implements an LRU cache. Follow up: how about expiry? concurrency?

1

u/sixstringjones Mar 05 '21

I think your ideas are great examples of things that are definitely an improvement over the standard fare these days. When you start talking with a lot of folks about this and force them to think and talk about it more, what I've found is that there are personality-driven or stylistic differences that can be interesting sometimes. For example, I prefer a more conversational style to a more Q&A style, and so I tend to start a conversation by asking them about projects they've worked on, what role they played on the project, the technologies used, challenges in using those technologies, what they learned, what they'd do differently, etc.

I think this style of interview dialog has helped me gain some clarity around the maturity of the developer in terms of how they make decisions, how they worked on a team, things that bug them (or don't!), how they prioritize choices on a project, and all kinds of other stuff. Often they're also using a technology I'm familiar with, so I can sometimes dive deep to see how deep they've gotten with the technology, and how inquisitive they are, etc.

To be honest, as a hiring manager, I have only ever let one person go because of incompetence (and I didn't hire them). Most people I've ever had to let go was ultimately because of maturity and/or attitude-related things, so I do find that aspect of the interview to be really critical.

1

u/[deleted] Mar 06 '21

Fantastic insight here. Thank you

3

u/nycmfanon Mar 05 '21

Thank you for the thoughtful reply, I seriously appreciate it.

We do a lot of that too—we have a behavioral portion of our interview that's purely Q&A.

But I have to admit, we have certainly had candidates that had impressive resumés, yet were shockingly unable to code. Like would say they had 2 years of Go experience, and then didn't know how to parse an integer (I don't mean how to write a parse function, but didn't know what strconv.Atoi was). Or would try and define a slice as `int[]`. Or not know how to write a for ... range loop.

That's why I like simple questions that anyone decent should be able to solve. It eliminates people that are clearly lying on their resumé, and you can get a signal on how quickly they solve the simple problem, how they communicate during it, how they name their variables, how they think of edge cases.

Maybe we're agreeing, and what I'm describing isn't what OP means by "algorithmic code tests."

-2

u/dfgrddfgrd Mar 05 '21

But what's the alternative?

You have a system design section to test global thinking and overall concept-building abilities.

And have algorithms to test hard skills.

It's the best combo.

3

u/nycmfanon Mar 05 '21

I agree. I feel like we've got this collective arrogance as a community of being too good to interview.

If OP is referring to the type of questions that require you to spend a month practicing coding challenges, then I agree, those are stupid. Maybe, just maybe, a company like Google needs something like that given how in demand their roles are.

But if the problems are relatively straightforward, and don't require esoteric knowledge of a specific algorithm or data structure, I've found them quite useful.

73

u/vividboarder Mar 05 '21

Agreed. We stopped doing those types of tests in our interviews. Now they are all “implement this simplified version of a feature in our app”. It’s a lot more practical and actually gives us a much better signal on the candidate.

3

u/zerocoldx911 Mar 05 '21

Leet Coding, all companies do that and it's annoying!

-2

u/[deleted] Mar 05 '21 edited Mar 05 '21

[deleted]

2

u/nikoren1980 Mar 06 '21

I tend to agree with you.
I had the same attitude. I was afraid of solving algorithmic questions and couldn't understand why companies do that. But after failing a few interviews and spending a few months practicing Leetcode questions, I think I became a much better engineer. If you give someone a simple (easy-level question), you can see how they think, handle errors, write basic logic. Now when I review code, I find so many problems, tons of if/else statements, lack of error handling, ignoring basic edge cases, lack of abstractions, non-standard names, inefficient data structures, redundant operations...but it still works :)

4

u/dontcomeback82 Mar 05 '21

IMO You are basically hazing people

-1

u/[deleted] Mar 05 '21

[deleted]

4

u/dontcomeback82 Mar 05 '21

It's hazing because you know it's probably not indicative of the candidates ability to the job, but just because it's difficult. You probably have ppl who have gone through it already there and continue this needless practice because of survivorship bias.

But, I don't really care if you haze or not, I just wanted to see if you could answer a difficult, irrelevant question. Would you like a job? :)

9

u/PaluMacil Mar 05 '21

I was feeling like writing something only opposed to your comments, but I laughed at the Ebay API example because last I looked, it had some awful broken bits. That said, I think the point of refusals isn't about people being unwilling to do that sort of thing on a job. Overall, I think these challenges bias your hiring towards people with less experience. Someone will do more poorly with more time since college yet be more likely to be able to talk to the EBay API (or more reasonable APIs like Azure AD, haha). If they experienced dev doesn't think they will do well with your test, it makes sense for them to skip out because they might have half a dozen other interviews lined up anyway.

In a real job, if you get assigned something uncommon, you might grab a mug of tea and watch a couple YouTubes, read a spec, and take notes before you sit down and write the code. While writing the code, you might be Googling a number of things. However,
online tests are testing your memory of things you won't often use and can't sit down and research because they grade you on time. Further, online tests put you in an environment that might reduce your score for stupid things like number of times you compile (a totally legit way to write code--some people refactor by leveraging the compiler, whereas type errors in an online challenge might be counting up those errors against you), performance (when it makes perfect sense to just implement something that works and then determine if it needs tuning), or things the challenge isn't coded to understand despite language support.

Code challenges during an in-person interview are often even worse because you aren't using an environment where you know your tools. I had a peer once who would have people code on paper and then say they did a bad job if they missed a symbol somewhere. It doesn't measure how they'd do on a job--even a challenging one.

1

u/lgj91 Mar 05 '21

Your approach differs from the companies I have applied for. They want the perfect algo, they want the solution with all the tests passing. They want perfect answers to all the questions. They don’t use it to determine aptitude,problem solving and determination.

1

u/lgj91 Mar 05 '21

Maybe this is a result of the wider talent pool with the job being remote.

3

u/boomzeg Mar 05 '21

Is "I would use existing implementations from packages X or Y and call it a day" considered a good or a bad answer in your interview process?

15

u/andrew_v23 Mar 05 '21

It's a really bad way to test developers.

There are so many ways to tell a good developer from a bad one just by asking some well thought questions but obviously that would require the recruiter to put in some efforts to come up with those questions (which rarely happens)

-7

u/TrolliestTroll Mar 05 '21

I’m so happy I found you! Please tell us what the magical set of questions we can ask someone that will determine the effectiveness on our team and in our domain are! I think you’ve finally cracked the difficulty of hiring candidates the match the unique mix of aptitude’s and dispositions that I need for my organization! Teach us!

On a more serious note, hiring is really really hard. Like we always talk about how shit the experience is for the candidate, but it’s also dogshit for the employer. They have a couple hours to figure out if it’s justified to make a multi year, multi hundreds-of-thousands of dollars investment in you. The cost of a wrong candidate, especially for a really small company/startup, can be the death of your organization. Yes, many of the practices that have become common place in the industry are pretty terrible, and yes companies far too often reject candidates (or don’t even allow them to start the process) for the wrong reasons. But the reality is that’s because it’s really fucking hard and there are no silver bullets. So we end up using proxies like take home tests and logic puzzles (how many tennis balls fit inside a school bus?) to try and make an educated guess on what might turn out to be an enormous and costly investment. It’s far from perfect, but it’s also not as if companies aren’t also motivated to streamline the process such that it has the best possible success rate.

3

u/Yeti_Detective Mar 06 '21

This response is extremely interesting to me. Disclosure: I'm a software developer, I happen to be great at algorithm puzzles because algorithms are an easy kind of thing for me to memorize, I still think they're a bad metric for hiring devs since you can google an algorithm, AND ALSO I know devs who are great at algorithms but build shitty software because they don't care about the quality of their work. It seems like the incentive to figuring out what qualities make someone a good software dev are extremely high, and the disincentives to getting wrong are just as high, if not higher. Do you have an opinion as to why nobody has figured it out? Do you think there is a company that's figured it out, but the industry doesn't follow their model due to some bias?

1

u/TrolliestTroll Mar 06 '21

I completely agree with you, the systems we have today largely suck. That’s entirely my point. I think they suck because it’s a fundamentally hard problem to discern someone’s fit for a role in a few short hours. I’ve had people under me that I thought weren’t going to make it, but with appropriate coaching became top performers. And I’ve had rockstar ninjas that shit rainbows completely blow out and become net negative contributors (ie not only low performers, but so bad they dragged the rest of the teams performance down too). The reality is, and this is what I was satirizing in my original post, is there does not seem to be a golden set of questions or problems or puzzles that you can give to someone and divine all you need to know about them within 4 hours. So what we are left with is, essentially, people just feeling around in the dark and going by gut instinct which is notoriously flawed. Employers don’t want to make a bad hire at least as much if not more than you want to be hired. I’m not shilling for corporate meritocratic bullshit here, but I am saying there are genuine incentives working in both directions that lead to the system we have today. Until we can quantitatively determine a persons fitness for a given role without human bias, there is always going to be substantial error in the system.

I don’t have the solution. If I did I would be making millions selling it to companies by fixing their broken hiring pipelines. I don’t know of any company that does this particularly well, but I know of many that do it extremely poorly. That’s not to say there aren’t companies out there with wonderful hiring and onboarding processes for software engineering type folks, but I’ve personally never seen or heard of them.

My frustration with the OP of this comment chain (and indeed many commenters in this thread) is that they want to believe that there is a simple solution to this problem. That the deck is stacked against them with all these hard algorithm problems for CSS designer jobs because corporations are evil run by people with their heads up their asses. And that might be true in some cases. But at least as likely is their process is so fucked up because everyones process is so fucked up and there are no clear solutions on how to fix it. Corporations do a lot of evil shit, but it might also be true that the problem is simply harder than “think about it for 15 minutes :forehead:”.

1

u/andrew_v23 Mar 06 '21

Maybe I misworded that. I’m not saying that there is an easy way that will work for all companies. What I’m saying is that most companies don’t even try to find a solution to improve their process. They just do the same shit over and over again and expect different results. And its not only the technical interview at fault, I’ve seen people who were alcoholics, drug addicts and some who have the emotional intelligence of a child passing the hr interview.

-6

u/apt-apparatchik Mar 05 '21

In short: because there is nothing better.

7

u/lgj91 Mar 05 '21

I had one where I paired with the CTO over zoom on a simple problem. I was graded on approach, performance and readability. A real world test of what it’s like to work with me.

Another was a take home test to build an api client for one of their api endpoints. A real world test of my skills that I would use in the job.

6

u/LetsNotBeTooQuick Mar 05 '21

I think there is. In my first remote job, before Covid, I had a two-round interview with just talking about IT and past experiences in general, then I was given a real task, as a provisional member of the team. In a few days it was apparent I was fit for the job, and hence I was hired. Granted, it may not work for every company, but I think what the OP described is more of a legacy, overly theoretical approach.

1

u/AsyncOverflow Mar 05 '21

The problem is we have 13 candidates for this 1 role and we can't objectively judge the best one when they each so 13 completely different real tasks.

It's a good way to unintentionally creep in personal bias.

My favorite way to interview was to complete a small project in 1 hour. It was a telnet chat server and I could google. But really it was just as hard as algorithmic interviews and had many of the same problems.

2

u/LetsNotBeTooQuick Mar 05 '21

I get that. But just picking a way (algorithmic code, as the OP mentioned) to test them in order to choose one, when the job itself is completely different... That’s just no ideal. I understand that it’s easier, though. However, when you are paying 100-200k a year to someone, you might want to make sure you don’t reject an otherwise perfect candidate just because they were wrong in picking the absolutely most effective way to search for a substring in a string (just a silly example, it’s Friday night), staying behind the most effective solution by .5 ms. You get the idea.

0

u/apt-apparatchik Mar 05 '21

Tell me more, was this for a software job or an it job?

2

u/LetsNotBeTooQuick Mar 05 '21

Software. I may not have been concrete enough, sorry; the questions were about software engineering.

1

u/apt-apparatchik Mar 05 '21

Interesting, so you came into work for a few days and worked full days as a team member, as a try-out?

2

u/LetsNotBeTooQuick Mar 05 '21

Yes. It was quite nice, because both they and I knew what to expect.

2

u/apt-apparatchik Mar 05 '21

It does seem better, and also impractical for some of the places I've worked. Were you compensated for those days?

3

u/PaluMacil Mar 05 '21

I wasn't compensated, but the one time I had an all day interview it included pair coding with different employees one hour each apiece, the code was a certain feature actually implemented sometime in the past (now that I work there, I'm guessing the interview had been used for a couple years). It meant they could point you in the right directions, and by them always writing unit tests that I had to satisfy, I wasn't totally lost about what APIs or libraries to use. The VM we used was something they could just roll back for the next interview, and the realness was fantastic.

This was a cybersecurity product, they certainly care about confidentiality and I signed an NDA, but I loved the interview, and it gave everyone involved a very accurate impression of what to expect from me or me from the company.

3

u/LetsNotBeTooQuick Mar 05 '21

Well, I realize it may not work for every company. But provided that you have a track record of some sorts (like open source, or just nice a SO profile), I think it’s better. About compensation: they told me I would be fully compensated, even if I was not to be hired, provided I produce something meaningful.

1

u/apt-apparatchik Mar 05 '21

Thanks for sharing!

2

u/LetsNotBeTooQuick Mar 05 '21

Couldn’t agree more.

31

u/[deleted] Mar 05 '21 edited Mar 05 '21

[deleted]

0

u/Asdayasman Mar 08 '21

But all the hand wavy ‘let’s chat about tech’ interviews tend to bias hard toward people the interviewer likes personally

And we should definitely bias against people who like each other and won't cause trouble with grating personalities in the workplace, because it's impossible to train someone to have new skills, and really easy to train people to like each other.

1

u/tak1za Mar 06 '21

Hand them an actual project to work on. Ask them to put it up on GitHub. Look at their code, their commit history, their commit messages. That is gonna help fellow developers who they might end up working with.

13

u/[deleted] Mar 05 '21

But all the hand wavy ‘let’s chat about tech’ interviews tend to bias hard toward people the interviewer likes personally.

I have to say that in my 20+ years those are the only interviews I've ever really had. Sometimes over coffee, beer, or food. You start talking about "hard problems you've solved", or get quizzed on Jenkins v.s. Gitlab pipelines vs. Github actions, and get progressively more and more in-depth.

I've never had a brutal "Explain how your computer loads a website" question, but I'd be able to answer it - DNS, TCP handshakes, MTU, etc, etc.

I've had a few people say "Find the bugs in this project", or "Look at this problem and explain how you'd solve it, roughly". But I've never any complicated memorization for that.

I appreciate that I've been hired because i have a similar background to my interviewers - grew up coding BASIC, and assembly language on my ZX Spectrum - and "likeability". But I'd probably walk out of the kind of stereotypical l33tc0de interviews anyway ..

9

u/nycmfanon Mar 05 '21

I've never had a brutal "Explain how your computer loads a website" question, but I'd be able to answer it - DNS, TCP handshakes, MTU, etc, etc.

Just curious, why is that a brutal question? I think as long as you grade it very open-endedly, it's a fair question to ask someone who's going to be building APIs. And I think that the level of detail and the things they focus on can tell you a bit about their profile.

I could see someone who's done a lot of devops focusing on DNS, load balancers, reverse proxies, etc. Someone who's done a lot of backend API work talking about TCP, HTTP protocol, headers, cookies, etc. Someone who's done a lot of frontend talking about fetching the html, then assets, optimization, API / XHR requests.

Seems as long as you grade this leniently it can give a decent signal?

1

u/[deleted] Mar 06 '21

I'd expect most people, developers at least, to be able to give a "decent" answer to that question. But when I was thinking about it I was thinking of the ongoing discussion and "So how does TCP work?", "What happens if buffers are full?", "Explain the nagle algorithm".

Basically I can answer that question pretty well I think, but it's designed to get more and more specific and I think while I'd get further than most (e.g. I implemented BGP in software) I'd still hit my limit eventually! And no doubt I'd forget a thing or two.

Anyway, details aside, I think that's almost like a whiteboard/algorithm course. It's about demonstrating what you know, can remember and articulate, rather than what you've actually done.

One of my favourite interviews had 30 minutes dedicated having to explain how some code I wrote worked. I was told "Pick a project of yours, or something open-source you understand, and explain it". We started off with an overview of the program, and a high-level overview of how I'd implemented it. Then we looked at the code, the test-cases, and even the documentation I'd made.

To me that was a great question because a) it covered code I'd actually written, b) showed my design-choices, c) demonstrated how I made different tradeoffs, and d) kinda did the teamwork/pair-programming/communication thing. Also I got to say "See? Documentation is fun!"

5

u/mr4kino Mar 05 '21

This question is both easy and "hard" depending on how deep you go.

I agree with you though, normally most candidates should be able to give an OK answer. In real life though, I haven't met lots of developers that answer this question in more than 30 seconds (forget about DNS, TCP, and whatever).

2

u/i-can-sleep-for-days Mar 06 '21

I did get asked this question and it is very ambiguous. Are they talking about the packet level (DNS, TCP, routing, etc)? Or a system level (gateway, load balancers, services, databases, etc)? You could give the right answer but it isn't the answer the interviewer was looking for and fail it.

1

u/mr4kino Mar 07 '21

Ask the interviewer the question. It's always good to ask those questions. First, it shows you have some knowledge, secondly that you don't jump head first and thirdly if the interviewer is one of the guys you described, it prevents a failure.

2

u/TreeOk2846 Mar 06 '21

I notice the question didn't say whether it's a server or client that's loading the website. There's a difference. A server loading software has to instantiate a server socket, handle connections (probably with TLS), hand off the connection to a handler, etc. A client has to connect to a listener (probably with TLS), make a request and listen for an answer. I know: oversimplified. But still, the question should have stated which side it's about.

3

u/mr4kino Mar 06 '21

I understand your point. Usually I make it clear for candidates: "You are on your computer, you decide to open your favourite browser and go to www.google.com. what's happening in the background. Details as much as you want".

1

u/InfiniteDaremo Mar 05 '21 edited Mar 05 '21

You still want a job OP? PM me. I don’t even do a practical test

4

u/mrprofessor007 Mar 05 '21

It's a bad way to be honest, but easier if you are on the recruiting side.

64

u/bforbokofios Mar 05 '21

Because double-bubble-merge-quick-insert-random-word-here sort is beautiful and you are wrong.

In a more serious manner, most of the companies that have sent me this kind of code tests use automatic test generation services.

16

u/lgj91 Mar 05 '21

Maybe it’s just something I need to get good at.

Hack rank here I come.

1

u/charkadog Mar 05 '21

Hacky Spank has a repetitive formula for their questions. You'll see this if you do some prep up front. But it usually involves a map of maps or a map of slices. I did some heavy prep in 2019, by the time I got to the actual competency test... copy and pasta all the way. This is not always the case, but it will get you quite far. Also remember you'll be judged on how you solve the problem. There's always 10 different levels of doing something. Use up the full time to refractor and improve.

2

u/Icelain Mar 05 '21

I think its to test a person's problem solving skills.

10

u/lgj91 Mar 05 '21

I am not sure it does.

If I need to find combinations of string I’ll google it and see an example backtracking algorithm and use that problem solved. Being able to code one from scratch doesn’t represent what you would do day to day?

10

u/Icelain Mar 05 '21

It's a bad model yeah