3 ms·

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

by 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.

by SubuSS 7y ago

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.