71–80 of 101 posts
Earlier quoted context omitted.
But most people are not doing that in their careers. It's mostly CRUD applications that they are building
I am working on CRUD just now. Its amazing how complex some people manage to make simple things. Keeps me in a somewhat unsatisfying job though.
On Fridays I typically spend the afternoon deleting as much code as I can
Earlier quoted context omitted.
But most people are not doing that in their careers. It's mostly CRUD applications that they are building
I am working on CRUD just now. Its amazing how complex some people manage to make simple things. Keeps me in a somewhat unsatisfying job though.
Just because you don't have to write some novel algorithm doesn't mean you're not solving hard problems.
Earlier quoted context omitted.
These would be perfect questions, if candidates didn't lie. They do. All the time. More often than you'd think about something as trivial as "can you actually write code". And so, you'll need to demonstrate your skills. Find a better way with an extremely low false positive rate, and you can make a fortune consulting and implementing that. It's not like anybody likes doing these interviews.
You don't need to ask "really hard Algorithm puzzles" to figure out whether they can actually write code. You can ask normally hard or even simple algorithm and have them implement it. If your company does object oriented, you can also ask them basic patterns. If you do functional, have them do little bit of that. It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part. That…
Really? That's not how I read it. And when I asked OP, that's not how he responded. The examples of questions that he said he would ask had been stripped of any algorithm-related questions, or any questions that involve coding.
Earlier quoted context omitted.
Are you guessing, or have you actually asked?
I have been a janitor (or pretty much that) during my MD studies, then I have been a nurse, then a doctor, then a programmer. I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own). In the IT field it's different though. Every junior is absolutely sure they are better than their team lead (been there, done that, also been the team lead). Every QA thin…
> I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own).
More than once I've heard staff (not janitors though) talking depreciatively about doctors (e.g. "he thinks he knows everything", "he said X but my uncle says Y").
I think if you read what I wrote a bit more charitably you'll see that my point wasn't really about janitors. I used them figuratively to comment on OP's attitude that seemed like the terrible combination that is confidence and ignorance.
Isn't organizational skills a fancy way of saying refactoring & (depending on your language) Object-Oriented-Design? Just look at Sandi Metz's or Avdi Grimm's or Martin Fowler's writings and there's lots of good ideas on how to organize your code.
I totally agree, so how can we interview for this?
My favorite is to have someone explain to me what happens when a browser makes a HTTP request to a web URL, which has . Network guys will tell you all about the request and response, web developers will focus on the front end, devOps will tell you how all the pieces communicate, etc. My expectation is for someone to at least be able to give a high level of all those things, while also having detailed knowledge of some specific areas... and seeing how they choose to answer such an open-ended question tells you quite a bit about where their focus and attention lies.
Earlier quoted context omitted.
You don't need to ask "really hard Algorithm puzzles" to figure out whether they can actually write code. You can ask normally hard or even simple algorithm and have them implement it. If your company does object oriented, you can also ask them basic patterns. If you do functional, have them do little bit of that. It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part. That…
> It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part. Really? That's not how I read it. And when I asked OP, that's not how he responded. The examples of questions that he said he would ask had been stripped of any algorithm-related questions, or any questions that involve coding.
This reminds me of the PHD in the office, who was hired because of some mathematical related skill they specialize in, is never getting their hands dirty. They are off somewhere looking smart and protecting their allure, while us grunts are keeping the lights on. Broad stereotype here, but it is what I have experienced. To be very honest, being on Google searching constantly has been the most important skill. In this…
"In this face paced IT environment, if you stay too long becoming an expert on something, it's replacement is coming right around the corner..." Depends what the value adding function is. I work in a field (essentially CAD) where getting anything done takes years at best and if a technology does not have an estimated lifespan of at least a decade we don't invest in it. Web stuff is of course starting to spill in.
Earlier quoted context omitted.
Please no! Tech interviews are already steaming hours of worthless horse shit as they are.
I think they meant improving interviews by testing for this instead of algorithmic brain teasers on a whiteboard.
This reminds me of the PHD in the office, who was hired because of some mathematical related skill they specialize in, is never getting their hands dirty. They are off somewhere looking smart and protecting their allure, while us grunts are keeping the lights on. Broad stereotype here, but it is what I have experienced. To be very honest, being on Google searching constantly has been the most important skill. In this…
You know the adage "Work smart not hard"? That's what you get a PhD for.