Look, this is the same as taking tests in school. Tests suck, but there's a reason we have to take tests and not just only turn in homework. The reason is that you need to demonstrate that you can do it on your own in a time-bound environment. Github doesn't demonstrate that even when you're amazing. Talking to someone who can ask questions about your abilities, and demonstrating your abilities on the spot is the way to do that, just like taking a test. I'm sorry it's less comfortable than posting online, but it's reality.
Leetcode doesn't have more weight than projects in my book, and I didn't mention it, neither did the top comment, so I'm not clear why you're saying that. Are you referring to the article?
> the discussion here is regarding whiteboard algorithms vs actual experience
The discussion in this sub-thread was about interviews & online portfolios. I wasn't talking about whiteboarding.
> Companies are willing to waste the candidates time [...] asking algorithm questions makes the interviewer feel smart.
I can't speak to all companies, you are probably right about many of them.
However, young grads today seem to feel entitled to easy interviews and job offers from all of them. What I hear in your post is some angst and frustration. I can understand that. I think it's a buyer's market. Getting a good job means figuring out how to stand out from the rest of the crowd, and it's really, really hard to do that with code alone.
It's true that companies are optimizing for their own needs, just as you are optimizing for your own needs. You can choose to see that negatively, as them wasting your time, or you can take more control of your interviews, and work to protect your own time.
The deal on offer is, if you pass the interviews, then you get paid well to code. Or, you can go start your own company and make your own money.
If you paid attention in school and understand algorithms, them you should think of algorithm questions as the easy part of the interview, something you can pass without problems. The questions are there to see if you care about algorithms and understand the basics. Don't take them personally, and understand that the questions are for all candidates, and they need to filter people out who don't know algorithms. So stop complaining about the easy questions, and start spending your time figuring out what the hard questions are and how to ace them. (Also, just FYI people who complain about certain kinds of interview questions is a small red flag in my book. If you love programming, algos might not be the exact thing you want to do, but it's part of the job pre-requisites and basic knowledge, so enjoy them instead of fighting them.)
If I have to become the culture in order to participate in it, then I will just take my toys and play in my own sandbox. I won't compromise my personal ethos, just because everyone else is.
As a manager, I took my Responsibilities very seriously. I worked for an extremely frugal and conservative corporation, and had to fight like a badger to get headcount. Making sure that the person that filled that headcount was top-notch was critically important, and I spent a great deal of time evaluating résumés and interviewing candidates. I would have killed for information like what you can get from a well-stocked SO story. Each candidate was a potential "family member." I kept them for decades. Japan wouldn't even recognize their existence until they'd been there for over a year.
Have you ever seen a designer get ready for an interview? I was trained as an artist (way back when), and know the drill.
They bring a large (usually black) case with them. It contains samples of their work; often including things like sketches and layout exercises. They go over the contents of this case with the interviewer; often telling stories about how they addressed some kind of issue, or the creative process that went into the work. I guess they may bring a laptop with them, these days.
No design manager in their right mind would ever think of ignoring the portfolio, and, instead, throw a matchbook on the table, and ask the designer to "Draw Spunky."
I'm not saying ignore people's portfolio. I'm only saying I don't spend a lot of time doing it before I talk to them. You also understand as well as I do that code portfolios and art portfolios are very different things, we can't compare those two types of interviews directly. It's easy to get a sense of quality from an art portfolio very, very quickly. At the same time, it can take days to understand whether a code portfolio has high quality.
You, as someone who'd done a lot of hiring, I think understands that a hiring manager doesn't have 4 hours to research each and every candidate at the resume phase before interviewing them on the phone, while also trying to write code and manage other coders at the same time. We take the best candidates we get, rank the resumes, look over the portfolios, reject any candidates that aren't prepared for the job, then call the top candidates and chat on the phone for a few hours, after that bring in the top from that set for interviews, which can be multiple days.
I also take hiring extremely seriously, and I've never had to fire someone, because we spend a lot of time talking with the candidate and making certain they'll fit in well on the team. That time spent talking is spent talking about their portfolio, having the candidate explain in their own words why they made the design decisions they made, why they chose to work on certain projects.
I would be willing to bet that in a face to face conversation, we would be agreeing damn near 100% on hiring philosophy and process. The problem here is it's hard to get across my motivation online in text. :P
My writing tends to be a lot more casual, and even a bit humorous. I like humans, and believe that the human relationships we make are the most important artifacts of our lives.
... That's a software engineer's everyday job, specially when just starting a new gig. In fact, the "reasonable time" part is often a pipe dream.
Someone unwilling (or unable) to read and try to understand someone else's codebase has no place doing technical interviews. That's literally the first thing that a new hire has to do.
You might have half point if you were saying that you discuss someone's portfolio during the interview (which would be analogous with the new hire discussing the code with the rest of the team to better gauge the decisions made), but you've said that you dismiss it and instead defend tests.
Speaking of that defense of tests: surgeons also had to do tests in medical school, yet they're not asked to perform routine surgery as part of their interviews (that I know of). This is to say that you were using a false equivalency.
> I'm sorry it's less comfortable than posting online, but it's reality.
Evidently, it isn't. What makes it easy for you (which is ultimately the real reason for those pointless tests) is not the optimal process. It's, in fact, the entire problem discussed in the FA and the comments here.
> Leetcode doesn't have more weight than projects in my book, and I didn't mention it, neither did the top comment
From the top comment:
>> At least, that was the reason they gave for ignoring the links I sent, and instead, giving a binary tree "Draw Spunky" test (I don't do well on them; never have, never will. I spend exactly 0.0 hours on HackerRank [emphasis mine], practicing).
What exactly were you going for?
> The discussion in this sub-thread was about interviews & online portfolios
One of the main points of the top comment was the explicit and deliberate dismissal of the commenter's portfolio in favor of leetcode type tests. I refer to the paragraph I just quoted.
> and it's really, really hard to [stand out as a programmer] with code alone.
Interesting, most of the programmers I know of, I know of them because their code is great; I'm here mostly thinking of authors of widely used open source software.
To reference a famous anecdote: I'd hire the creator of homebrew on the spot. You wouldn't even give him an interview.
> you can take more control of your interviews, and work to protect your own time.
In other words: Potential candidates should make your job easier by continuing the drill this whole discussion is about instead of complaining about how ineffective it is. How much of a problem this whole charade is.
That's just borderline insulting, and it's pretty clear that it is deliberate. I'm surprised it flew here, specially considering the featured article(s) and most of the other comments.
> If you paid attention in school and understand algorithms, them [sic] you should think of algorithm questions as the easy part of the interview, something you can pass without problems.
You called yourself a great programmer, I'll make no comment on that, but you've given me a good idea for how to screen which engineers should participate in interviews for when I have my own company: I'll ask them what they think of algorithm questions and I'll ask them whether they think that what is taught in college should be enough to pass those questions.
If they respond on the affirmative, I'll ask them the most obscure thing I can think of from any of my physics or calculus classes. Hey, after all, they "studied that in college", they ought to remember it even though it would be a gigantic coincidence if they ever actually had to use that knowledge in their job, and the question should be an easy point, correct?
Hopefully that will be a teachable moment, on how responding on the affirmative was wrong, maybe even unethical (because I sure wouldn't have asked that during their own interviews, with one caveat).
And this is, of course, ignoring the whole point of the featured article and the original one this is a follow up to: algorithm questions have devolved into being far more difficult than anything anyone had to do in college and they're something that 99% of candidates would never have done, or needed, in any previous job.
> The questions are there to see if you care about algorithms and understand the basics.
They aren't, GP comment was on the money by saying that they're just there for the interviewer to feel smart.
> Don't take them personally, and understand that the questions are for all candidates, and they need to filter people out who don't know algorithms.
Filtering out people who don't remember (as opposed to not knowing; for remembrance only a short refresher is needed, but that's something that a coding test doesn't give the time for) algorithms is a terrible practice unless the company doing the hiring is explicitly researching for algorithm design and creating knowledge as opposed to applying existing knowledge.
Or, in short, most people won't ever need to dive deeply into algorithm design in this field (most, if not all, of the algorithms needed are already baked into the commonly used libraries), meaning that filtering out the ones that don't remember is pointless at best, self-defeating at worst.
For the very rare cases (outside of the aforementioned companies that need to create new stuff for their products) where reimplementing an algorithm is needed (and there better have been enough research to know that it's not an example of NIH), a couple of hours of getting reacquainted with them is often enough.
> So stop complaining about the easy questions
You've given no reason to. In fact, by rationalizing it, you helped me see with even more clarity how much of a problem this is.
> Also, just FYI people who complain about certain kinds of interview questions is a small red flag in my book.
That's good, every person you rejected for that reason (along with the ones rejected over tests, specially if they had portfolios) clearly wasn't a culture fit and they are better off in a different company.
I just wish they could have dodged the whole hiring process you employ. Then again, I wish that for everyone, myself included.
> If you love programming, algos might not be the exact thing you want to do, but it's part of the job pre-requisites and basic knowledge
They aren't prerequisite for 99% of the jobs and I would say that, if you love programming, you would, well, program and let everyone know you do, like by contributing to open source software and building a portfolio. And yet you would barely spend a second of your time looking at someone's portfolio.
So whose criteria for "someone who loves programming" is the right one?
Finally, a disclaimer: I often do well in those stupid tests and have never spent more than a few weeks in between jobs, while my online portfolio is pathetically barren. Just to put in perspective that one can hate everything about the problem and rightfully complain about it while still having to play, and mostly knowing how to play, that awful game.
I can see that you’re frustrated by interviews. Why don’t you tell me more about your experience and what about interviews isn’t working for you? You said you’ve never gone long in between jobs, so why are interviews bothering you so much? If you’re just commenting on the awful game, why are you taking it personally and insulting me?
You took much offense to my explanation of algorithm questions without acknowledging that I agreed with the GP comment that many companies might be doing it for the wrong reasons. Still, that doesn’t make it a good idea to just speculate on the reasons companies use algorithms questions. Just because you feel like they’re pointless and interviewers are trying to feel smart doesn’t mean it’s true. Jumping to a negative conclusion isn’t the best idea, even if you’re right.
The person who’s criteria matters for loving programming is you.
You're the one defending rote tests (that literally only test for technical knowledge), not me nor anyone who replied to you (as far as I read).
From my previous comment:
>> You might have half point if you were saying that you discuss someone's portfolio during the interview (which would be analogous with the new hire discussing the code with the rest of the team to better gauge the decisions made), but you've said that you dismiss it and instead defend tests.
I value discussion, that's ultimately one of the things that matters most for a developer. And, mind you, thanks to git platforms (GitLab, GitHub, etc.) this is also becoming more transparent in portfolios, like by looking at how the candidate handles merge/pull requests and issues.
> your many personal insults directed at me.
Could you quote which sentences in my previous comment were personal insults? I'd like to know where I phrased myself poorly and apologize and/or explain my intent.
> If someone who was interviewing you read your comment, do you think they’d want to hire you more?
If someone who was interviewing me disagreed with any of my points, I guess not. Then again, I wouldn't want to work in such a company either; making it a win win situation.
I fail to see how this sentence is apropos anyway, HN isn't a job board.
> You said you’ve never gone long in between jobs, so why are interviews bothering you so much?
That's all but spelled out in the article and most of the comments, but I'll share my experience explicitly: I am yet to have a job, that used those leetcode type tests or generic coding challenges as part of the hiring process, where I needed to use the knowledge required for the tests or the challenges in the actual job.
It's a gigantic waste of time, testing for all the wrong things.
> Just because you feel like they’re pointless and interviewers are trying to feel smart doesn’t mean it’s true.
I'm yet to find a counterexample in any job I've had. You seem to be mistaking your own experience (assuming you actually do those tests for the "right" reasons) as the norm. Though I guess all of us are a little bit at fault of that.
> Jumping to a negative conclusion isn’t the best idea, even if you’re right.
You are the one who told someone else to stop complaining and even made another not-apropos comment about how complaining is a red flag. There's no way to interpret that other than negatively. If there is, I would love to read what you meant by that.
> The person who’s criteria matters for loving programming is you.
Alas, evidently it doesn't, because even hiring managers/interviewers/recruiters who comment in HN posts about the awful state in hiring for software engineers think that rote algorithm tests are of utmost importance, and I don't particularly agree.
Then perhaps this person should not be interviewing in the first place? Why should an unqualified hiring manager somehow asses the candidates technical abilities ? This seems really bizarre to me. Imagine putting someone who is clueless about the medical field in charge of hiring surgeons based on some test score they took online, whilst completely ignoring their years of experience.
> I can’t tell from your online portfolio whether you’re the sole author and/or how much you’ve contributed to a project. I can’t easily tell if you get a lot of your code from StackOverflow, or write it yourself.
The OP has hundreds of citations in his portfolio. It's interesting that leetcode which can be gamed by a grad has more weight than multiple, well established projects. If you place this much trust in applicants, you will most likely be micromanaging them as well. This isn't the way to attract top talent.
> I can’t tell what motivates you, whether you love programming or you are hoping for a high salary. This is what the in person interview is for.
> While high technical ability is a requirement for someone I hire, it’s not actually the primary requirement. What I need to know is how adaptable people are, how well they’ll work in a team, how quick they are on their feet
All these are valid points, but the discussion here is regarding whiteboard algorithms vs actual experience.
I honestly think it boils down to a few things: - Companies are willing to waste the candidates time. - Copying FAANG style interviews serves as a marketing tactic for startups (we have the same hiring standards as Google)
And finally an unpopular opinion: - Asking Algorithm questions makes the interviewer feel smart, Especially if they are interviewing someone which is more experienced.