6 ms·

Not entirely applicable to this particular quiz (most of the questions were relatively simple until the final few), but the interview questions like the ones th

by ezekg 9y ago

Not entirely applicable to this particular quiz (most of the questions were relatively simple until the final few), but the interview questions like the ones that Hired and Triplebyte focus on honestly make me feel like an imposter. I've been a software developer for over 4 years but I don't have a formal CS education. I've gone through CLRS along with MIT's open-courseware--but I rarely use any of that directly in the workplace and so have forgotten a lot of it. And I think I'm a pretty good software developer, yet in the past when I've tried to get into Hired or Triplebyte, I always leave feeling like I don't belong in this profession because I can't tell you the big-O complexity of DFS off the top of my head, much less write the algorithm on a scratch pad. I've been doing technical interviews for a few weeks now (I was recently laid off) and I'm honestly just a little tired of the brain teasers and non-applicable algo questions--and more often than not, the interviewers flexing their "knowledge" muscles. Case in point: I'm in final stages with multiple companies for a Rails position, yet only one of those had even mentioned Rails in the technical interviews--the others decided to quiz my CS knowledge and one of them even quizzed my FP knowledge (for a Ruby position…). I don't understand it.

ammon 9y ago
Hello Ezekg, I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways is being really good at CS (and to people who want skills in CS, talking about DFS is a reasonable low-bar question). However, another way is writing great, well-structured rails code. We work with people all the time who don't have CS backgrounds (we help them get jobs at companies that don't care about CS). The intent of our process is to measure both CS and practical skills (we actually break it down on more axes, but you get the idea). This does mean that if you go through our process, you will be asked CS questions. But you'll also be asked to code. And not knowing the CS questions is not an obstacle to passing.
- mattmanser 9y ago
  Do you truly believe that being really good at CS will magically make you a skilled programmer? Are they not different skill sets? One is a practical skill, the other an academic one. I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag. I've watched online lectures where Doctors of Computer Science lecture about OO but clearly have no understanding of what works and what doesn't. I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains. I suspect I could add the word small to advantage and subset and that statement would still be true.
  - aerovistae 9y ago
    I mean, you're speaking as if you had the magic cure-all to technical interviewing, and if you did I'm sure you'd be telling us what it is instead of somewhat condescendingly criticizing someone else's methodology.
    - mattmanser 9y ago
      I certainly didn't mean my reply to be condescending. Are you objecting to the word magically? He literally says that one way to be a skilled programmer is to be really good at CS. How is that not magically? What word would you have used? Unfortunately, your reply is clearly condescending. And adds nothing to the discussion.
  - Silhouette 9y ago
    Do you truly believe that being really good at CS will magically make you a skilled programmer? Isn't the problem more often that lacking awareness of theoretical CS issues can limit your potential as a programmer? For example, someone with that awareness would immediately recognise some of the later questions as standard graph theory problems and could then solve them appropriately. Without that context, maybe a good programmer could still figure out a working solution from first principles, but it would surely take them longer. And while I don't suppose many of us will be working on intergalactic transport infrastructure any time soon, similar recognition scenarios do come up in plenty of day-to-day programming jobs.
    - ezekg 9y ago
      There's a difference between expecting candidates to know when to recognize graph theory problems and expecting candidates to know (and implement) Dijkstra's algorithm as the correct solution to some abstract problem. I don't remember what Dijkstra's algorithm is exactly off the top of my head (all I remember is that it's for graph traversal and has a memorable name), but I do know when to recognize graph theory problems so I can start looking for the correct solution. I definitely agree that general CS knowledge is highly beneficial (it's why I put in the time to learn), but knowing implementations for specific algos doesn't seem as important in the day-to-day as interviews make it out to be.
dominotw 9y ago
I don't understand people who don't do prep for interviews ... https://news.ycombinator.com/item?id=13888581 https://news.ycombinator.com/item?id=13888581
- lj3 9y ago
  and I don't understand people who want to waste a month (or more!) of their life every time they change jobs... https://news.ycombinator.com/item?id=13888703 https://news.ycombinator.com/item?id=13888703
  - echevil 9y ago
    Well different people need different amount of time to prepare for interviews, but if preparing for one month gets you a much better job offer, that sounds like a good investment to me.
    - lj3 9y ago
      You've completely missed the point. If you need to do this every time you change jobs, then throughout your career you're spending years! of your life on interview prep. Getting into Google for the first time, sure, it's worth it then. But what about the next job? Or the job after that?
      - sp332 9y ago
        Geez, how many jobs are you planning to have?
        striking 9y ago
        Changing jobs often is not rare in CS and related fields.
        squeaky-clean 9y ago
        Changing jobs gets you a higher pay increase than interviewing well once.
fwefwwfe 9y ago
They probably assume if you know programming, Ruby, and everything else you should be fine with Rails. Quizzing people about minutia that can be easily Googled doesn't really sound like a great way to find apt candidates.
stevenwoo 9y ago
Been programming for a living for 30 something years, my last contract ended recently so started investigating the technical interview process so sympathetic with your point of view. I've never had to do any of the basic algorithms/puzzles from scratch that one typically has to do in these interviews for a shipping product, based on the samples I've seen from hackerrank and leetcode. The questions marked easy on leetcode were ones I was asked in the 90's.

by ezekg 9y ago

ammon 9y ago

Hello Ezekg, I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways is being really good at CS (and to people who want skills in CS, talking about DFS is a reasonable low-bar question). However, another way is writing great, well-structured rails code. We work with people all the time who don't have CS backgrounds (we help them get jobs at companies that don't care about CS). The intent of our process is to measure both CS and practical skills (we actually break it down on more axes, but you get the idea). This does mean that if you go through our process, you will be asked CS questions. But you'll also be asked to code. And not knowing the CS questions is not an obstacle to passing.

mattmanser 9y ago
Do you truly believe that being really good at CS will magically make you a skilled programmer? Are they not different skill sets? One is a practical skill, the other an academic one. I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag. I've watched online lectures where Doctors of Computer Science lecture about OO but clearly have no understanding of what works and what doesn't. I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains. I suspect I could add the word small to advantage and subset and that statement would still be true.
- aerovistae 9y ago
  I mean, you're speaking as if you had the magic cure-all to technical interviewing, and if you did I'm sure you'd be telling us what it is instead of somewhat condescendingly criticizing someone else's methodology.
  - mattmanser 9y ago
    I certainly didn't mean my reply to be condescending. Are you objecting to the word magically? He literally says that one way to be a skilled programmer is to be really good at CS. How is that not magically? What word would you have used? Unfortunately, your reply is clearly condescending. And adds nothing to the discussion.
- Silhouette 9y ago
  Do you truly believe that being really good at CS will magically make you a skilled programmer? Isn't the problem more often that lacking awareness of theoretical CS issues can limit your potential as a programmer? For example, someone with that awareness would immediately recognise some of the later questions as standard graph theory problems and could then solve them appropriately. Without that context, maybe a good programmer could still figure out a working solution from first principles, but it would surely take them longer. And while I don't suppose many of us will be working on intergalactic transport infrastructure any time soon, similar recognition scenarios do come up in plenty of day-to-day programming jobs.
  - ezekg 9y ago
    There's a difference between expecting candidates to know when to recognize graph theory problems and expecting candidates to know (and implement) Dijkstra's algorithm as the correct solution to some abstract problem. I don't remember what Dijkstra's algorithm is exactly off the top of my head (all I remember is that it's for graph traversal and has a memorable name), but I do know when to recognize graph theory problems so I can start looking for the correct solution. I definitely agree that general CS knowledge is highly beneficial (it's why I put in the time to learn), but knowing implementations for specific algos doesn't seem as important in the day-to-day as interviews make it out to be.

dominotw 9y ago

I don't understand people who don't do prep for interviews ... https://news.ycombinator.com/item?id=13888581 https://news.ycombinator.com/item?id=13888581

lj3 9y ago
and I don't understand people who want to waste a month (or more!) of their life every time they change jobs... https://news.ycombinator.com/item?id=13888703 https://news.ycombinator.com/item?id=13888703
- echevil 9y ago
  Well different people need different amount of time to prepare for interviews, but if preparing for one month gets you a much better job offer, that sounds like a good investment to me.
  - lj3 9y ago
    You've completely missed the point. If you need to do this every time you change jobs, then throughout your career you're spending years! of your life on interview prep. Getting into Google for the first time, sure, it's worth it then. But what about the next job? Or the job after that?
    - sp332 9y ago
      Geez, how many jobs are you planning to have?
      - striking 9y ago
        Changing jobs often is not rare in CS and related fields.
      - squeaky-clean 9y ago
        Changing jobs gets you a higher pay increase than interviewing well once.

fwefwwfe 9y ago

They probably assume if you know programming, Ruby, and everything else you should be fine with Rails. Quizzing people about minutia that can be easily Googled doesn't really sound like a great way to find apt candidates.

stevenwoo 9y ago

Been programming for a living for 30 something years, my last contract ended recently so started investigating the technical interview process so sympathetic with your point of view. I've never had to do any of the basic algorithms/puzzles from scratch that one typically has to do in these interviews for a shipping product, based on the samples I've seen from hackerrank and leetcode. The questions marked easy on leetcode were ones I was asked in the 90's.