3 ms·

We have ~4 hours to judge a candidate. Like it or not, we are going to have to choose :) The complex questions, if I can get answers are awesome. They are also

by SubuSS 7y ago

We have ~4 hours to judge a candidate. Like it or not, we are going to have to choose :) The complex questions, if I can get answers are awesome. They are also the ones that are hard to objectively describe. Based on the number of blogs read, candidate charisma, my own work pressures - there is a big chance a senior enough person can wave their hands through those. Hence the tilt towards the surety of coding. Also TBF, in my 1000s of interviews, we have always had a couple of rounds (Bar raisers / System Design / Architecture ... whatever) which try to get the fuzzy input. We get a sense, but that's not in depth as you might imagine. OTOH we have a clear cut answer in the problem solving world that gets us a bit more closer to the hire/nohire decision.

scarface74 7y ago
I’m on the opposite end of the spectrum. I work for small companies mostly and I’ve conducted interviews for small companies. We have a limited budget for a limited number of positions. One developer can be working on a project that can individually move the needle. We need to hire “engineers” in the truest sense of the word not “coders”. For instance, currently my title is “senior software engineer”. But I am the “Directly Responsible Individual” for a project that one of our clients is paying for. It will be added to our core product. This means that I’m expected to interact with the client and BA to come up with the SOW, work with the product manager/UX person to design the interface, do some of the web work, write the backend using one of our approved languages (C#, Javascript, Python) , design the database schema, do all of the CI/CD setup and to know the AWS fiddly bits and know which services are appropriate for the asynchronous processing requirements. I’m no special snowflake, this is life in small companies since my first job 20 years ago. I don’t interview candidates for algorithms. I interview them to know whether they can hit the ground running on as much of our (industry standard) technology stack as possible, will they make good architectural decisions, can they ship a feature across the finish line, how fast they pick up new frameworks and will they embarrass us with customers and senior management. LeetCode ability does us no good. I want to know whether you can translate real world business requirements into a working system - including knowing which questions to ask when customers/product managers come to you with “XY Problems”.
- SubuSS 7y ago
  I don't know your scale for small, but my current org is tiny compared to AWS (my previous). So yes - we have to do all those things. I am directly responsible for ALL of data analytics infrastructure in snapchat. Pretty much most senior engineers have a similar scope. We might be talking over one another though: I am not saying any of that is useless: I am saying they're hard to measure. We still do it though. We also do the coding round as something that gives a more definitive datapoint.
  - scarface74 7y ago
    My definition of small is less than 50 people in total including salespeople, managers, implementations managers, and a few QA people. It’s really not that hard to ask a few technical questions based on what they purport to know, the soft skill behavioral questions, some design questions, and ask them about previous projects. The hands on part is the part where they fix the code to make the unit tests pass. I wasn’t asked a single technical coding question for my current job. I was given real world questions about issues they are having with process and how I would go about (re)architecting some processes. Now that I think about, my job before that when I was interviewing for the dev lead position I was only asked about process, system design, and a lot of high level theory - both jobs were hands on coding positions. Both of the managers were highly technical with current programming experience. But, I’m not completely disagreeing with you, if you are solving hard problems(tm) at scale you need people who understand algorithms and you may not be able to use off the shelf solutions - I would say Snapchat qualifies for “at scale”. But, for you typical yet another software as a service CRUD app or your typical dark matter corporate developer - and those positions are a lot more numerous than HN seems to realize - the complications aren’t in the complexity of the code, it’s in translating the business needs to code and shipping software that the company needs. As strange as it sounds, the “coding” side of software engineering has gotten a lot simpler 20 years into my career than it was when I started (C, C++, and a little x86 assembly). The “engineering” side has gotten a lot more complex and requires me to know a lot more technology. I don’t think it’s because I am better “coder” now either. When I got my first job, I had already been a hobbyist for a decade doing assembly.
- 7y ago

by SubuSS 7y ago

scarface74 7y ago

I’m on the opposite end of the spectrum. I work for small companies mostly and I’ve conducted interviews for small companies. We have a limited budget for a limited number of positions. One developer can be working on a project that can individually move the needle. We need to hire “engineers” in the truest sense of the word not “coders”. For instance, currently my title is “senior software engineer”. But I am the “Directly Responsible Individual” for a project that one of our clients is paying for. It will be added to our core product. This means that I’m expected to interact with the client and BA to come up with the SOW, work with the product manager/UX person to design the interface, do some of the web work, write the backend using one of our approved languages (C#, Javascript, Python) , design the database schema, do all of the CI/CD setup and to know the AWS fiddly bits and know which services are appropriate for the asynchronous processing requirements. I’m no special snowflake, this is life in small companies since my first job 20 years ago. I don’t interview candidates for algorithms. I interview them to know whether they can hit the ground running on as much of our (industry standard) technology stack as possible, will they make good architectural decisions, can they ship a feature across the finish line, how fast they pick up new frameworks and will they embarrass us with customers and senior management. LeetCode ability does us no good. I want to know whether you can translate real world business requirements into a working system - including knowing which questions to ask when customers/product managers come to you with “XY Problems”.

SubuSS 7y ago
I don't know your scale for small, but my current org is tiny compared to AWS (my previous). So yes - we have to do all those things. I am directly responsible for ALL of data analytics infrastructure in snapchat. Pretty much most senior engineers have a similar scope. We might be talking over one another though: I am not saying any of that is useless: I am saying they're hard to measure. We still do it though. We also do the coding round as something that gives a more definitive datapoint.
- scarface74 7y ago
  My definition of small is less than 50 people in total including salespeople, managers, implementations managers, and a few QA people. It’s really not that hard to ask a few technical questions based on what they purport to know, the soft skill behavioral questions, some design questions, and ask them about previous projects. The hands on part is the part where they fix the code to make the unit tests pass. I wasn’t asked a single technical coding question for my current job. I was given real world questions about issues they are having with process and how I would go about (re)architecting some processes. Now that I think about, my job before that when I was interviewing for the dev lead position I was only asked about process, system design, and a lot of high level theory - both jobs were hands on coding positions. Both of the managers were highly technical with current programming experience. But, I’m not completely disagreeing with you, if you are solving hard problems(tm) at scale you need people who understand algorithms and you may not be able to use off the shelf solutions - I would say Snapchat qualifies for “at scale”. But, for you typical yet another software as a service CRUD app or your typical dark matter corporate developer - and those positions are a lot more numerous than HN seems to realize - the complications aren’t in the complexity of the code, it’s in translating the business needs to code and shipping software that the company needs. As strange as it sounds, the “coding” side of software engineering has gotten a lot simpler 20 years into my career than it was when I started (C, C++, and a little x86 assembly). The “engineering” side has gotten a lot more complex and requires me to know a lot more technology. I don’t think it’s because I am better “coder” now either. When I got my first job, I had already been a hobbyist for a decade doing assembly.
7y ago