30 years ago software engineering was probably a few bunch of technical skills. Now it's a very big spectrum, no individual knows everything.
Someone applying to search quality team at Google that works on search algorithm really wants someone who knows algorithms..
but that may not be the case for a web of app developer.
but the same app developer needs to know have algorithmic sense to do some performance tuning.
The current interviews ignore all these nuances and simply ask a weird, sometimes boring, competitive coding question. That's fine too.. most engineers enjoy a puzzle once in a while.
But what really irritates me is sensitivity of assessment in these coding interviews.
Someone the other day was saying Cracking the Coding Interview book is no longer relevant. The problems are apparently simpler to what people ask in real interviews.
We don't just have to provide pseudocode. Write working, beautiful code, solve the edge cases and speak to the interviewer while doing all of this. I don't know since when engineers actually talk and code at the same time during working hours.
The phone interviews are a joke. In a 45mins meeting, where 10mins spent on introduction from both people has zero weight. In those days it was supposed to weed out non-serious candidates with fizz-buzz question. Well' agreed fizz buzz isn't really a good question, but neither a LeetCode Hard DP question to be solved in 30mins.
I agree and also don't get it: I barely write real code in my day job as the only coder on a project I own. I mostly go in, make notes on what looks bad, then fix it later, but the majority of the work isn't writing code and sometimes even I have to look up the proper `case` statement syntax or something. I can imagine being nervous, going in to do FizzBuzz, and bombing it, even as someone who has coded since I was 14 (I am now much older). We need to stop worrying about coding expertise and start thinking about how a programmer visualizes and thinks about data and code flow, that's the important part. Syntax can be forgotten, the semantics of programming are the important thing.
I was a teacher for a laughably short time, and I think what you are talking about would be called an "authentic performance task". Also, I think what interviewers are attempting is called "assessment", and I can say these tests are the absolute laziest version of it.
Genuine assessment is very hard. I worked at a leading bootcamp you would know the name of and was asked by $BIGCO to create a one dimensional assessment for all (guessing) 10000 of their programmers, so they would know who to fire. I refused. It isn't that simple.
I think a company like hackerank likely got that contract.
I am not expert enough to weigh in heavily on what's the best way to do that, but I feel like "software engineer" is just a title to make us feel great while we assemble our components much like the workers on an auto manufacturing line, but with a tiny bit more education and day-to-day work differences. However, with all the low-code and other tools which make it easier to write software and deploy it (crappy software, but "it works") soon we'll see "software engineers" turn into "software assemblers" or something like that. Sure, there will be a handful of programmers who will need to code those tools, or specialize in algorithms or writing code on constrained environments (embedded), but those will be the surgeons who make all the money, and the rest of us are the closers (whatever they call the surgeons who just sew things shut and finish up the procedure).
Lol. I took the teaching job because I was bored with "software assembly" (nice name). It was fun to get drop shipped into a random location in the world and go toe-to-toe with their best and brightest.
I've since moved on to embedded development, and it is as you say. I've recently got to work on tensorflow light, pytorch, rust, object detection, compute shaders... it's amazing.
The big company stuff can be a bit boring, but I can also say there's some pride even in the "glue". The team I was most proud of implemented Heroku-flow in their proprietary cloud using some kick-ass devops skills, figured out some innovative ways to solidly test their creation, and also got to write a genuinely comp-sci database diff tool to migrate data nightly from the original thing into their re-write.
If you can build the trust, there's most often a good route to turn a terrible, untrusting, corporate monstrosity into something decent. But that being said, it takes a ton of passion and also sometimes it will just be dull and a hobby project is probably a necessary relief valve.
I love your comment, thanks, it gave me a bit of hope, which is more valuable than most other things in the world (my son gave me the hope needed to get out of depression, maybe you will give me the spark to make my company better?).
Yes, it's not 1:1, but the comparison is apt, IMO. I worked in a factory that had a semi-technical assembly line, in other words we had to train the workers to some level of technical competence (medical devices) and I see parallels in how I was onboarded at my current company. They don't care about your technical designs or how good your algos are, they just want you to pump out ticket completions as fast as possible, ensuring you follow the procedures to the letter, no matter what. As someone who thinks highly of my own abilities (why wouldn't one think highly of themselves?) I feel like my growth is stunted and my full abilities aren't being used because of the strict environment and procedures. I understand why they are there, I know they are important for quality (I was a QA manager at that factory) but I think there are better ways than treating coders like assembly line workers.
Don't take the comparison too literally, the actual work of putting a machine together is different than coding, and I'm not talking about "sticker applicators" type assembly lines, I'm talking about high-tech assembly lines like what I experienced (medical devices, in this case). I did base my comment on more experience than a few "How It's Made" episodes, though.
Agreed. There's one in my family. She's literally putting the same kind of sticker on the same kind of car 8 hours a day for months or years (they rotate positions in factory so that people don't go crazy - but retraining for the new position is a matter of a couple of hours). She's basically a biological machine augmenting the factory pipeline and the company has her only because for now she's cheaper than a robot arm. I see zero parallels between that job and software development.
Someone applying to search quality team at Google that works on search algorithm really wants someone who knows algorithms..
but that may not be the case for a web of app developer.
but the same app developer needs to know have algorithmic sense to do some performance tuning.
The current interviews ignore all these nuances and simply ask a weird, sometimes boring, competitive coding question. That's fine too.. most engineers enjoy a puzzle once in a while.
But what really irritates me is sensitivity of assessment in these coding interviews.
Someone the other day was saying Cracking the Coding Interview book is no longer relevant. The problems are apparently simpler to what people ask in real interviews.
We don't just have to provide pseudocode. Write working, beautiful code, solve the edge cases and speak to the interviewer while doing all of this. I don't know since when engineers actually talk and code at the same time during working hours.
The phone interviews are a joke. In a 45mins meeting, where 10mins spent on introduction from both people has zero weight. In those days it was supposed to weed out non-serious candidates with fizz-buzz question. Well' agreed fizz buzz isn't really a good question, but neither a LeetCode Hard DP question to be solved in 30mins.