7 ms·

> hiring managers, who perhaps often don’t have the time, interest, or even ability to read someone’s portfolio to determine the quality of the code. Then perh

> hiring managers, who perhaps often don’t have the time, interest, or even ability to read someone’s portfolio to determine the quality of the code. 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.

dahart 7y ago
I think you misunderstood my comment about whether a hiring manager has the ability to judge online code, I wasn't suggesting they're incompetent, I'm trying to point out that you can't expect even an amazing programmer with decades of experience to understand what the hell you were trying to do with your code -- in a reasonable amount of time. Styles and goals can be as different as night and day. I believe I'm a very good programmer, but I can't tell from github whether you are. I have to talk to you to figure that out. 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.)
- luord 7y ago
  > you can't expect even an amazing programmer with decades of experience to understand what the hell you were trying to do with your code -- in a reasonable amount of time. ... 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.

dahart 7y ago

I think you misunderstood my comment about whether a hiring manager has the ability to judge online code, I wasn't suggesting they're incompetent, I'm trying to point out that you can't expect even an amazing programmer with decades of experience to understand what the hell you were trying to do with your code -- in a reasonable amount of time. Styles and goals can be as different as night and day. I believe I'm a very good programmer, but I can't tell from github whether you are. I have to talk to you to figure that out. 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.)

luord 7y ago
> you can't expect even an amazing programmer with decades of experience to understand what the hell you were trying to do with your code -- in a reasonable amount of time. ... 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.