101–110 of 127 posts
Earlier quoted context omitted.
Some people have 10 years of experience. Others have 1 year of experience 10 times.
What a great quote. I wonder where it came from.
This is someone's (very arbitrary) opinion in a grid. I hope you don't actually interview people. Figuring out someone's skill level is a soft science; it takes months after a hire to really know where someone is. Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here? Experience…
I'd just like to see a list of some things that should be minimum / recommended concepts that every programmer should know to be good at their craft. I'm ~40 and going back for a CS degree isn't very appealing / practical. But if I knew what things to study... I could start on my own. I'm advanced in my career, but its been mostly advanced level support and system administration work. I want to get into programming.…
You can also always program on the side if you want to maintain the stability of an established career.
This is someone's (very arbitrary) opinion in a grid. I hope you don't actually interview people. Figuring out someone's skill level is a soft science; it takes months after a hire to really know where someone is. Some people I know are great at fixing bugs but have narrow language experience. They're damn valuable. Others integrate well into teams and provide great product feedback. Where's that on here? Experience…
Many are biased (objects > functions), several are not useful and a few are plain wrong. Meh.
Agreed. I'm not sure how 'Source Code Version Control' and 'Build Automation' is anywhere near the words 'Software Engineering'. And 'Automated Testing' isn't a given at a lot of shops. Professionally, I've never set up version control. It's there when I start the job, it'll be there when I leave. I've branched and merged but a lot of times this is handled by a build manager. Build automation I have never expressly d…
It's not hard to start a Git repo you know, it's something you can pick up in under a day.
I'm not sure if "has used git" should be log(n)-- I'm only barely a programmer, and I've never used CVS/SVN, but I use git to version control markdown files.
Earlier quoted context omitted.
Agreed. I'm not sure how 'Source Code Version Control' and 'Build Automation' is anywhere near the words 'Software Engineering'. And 'Automated Testing' isn't a given at a lot of shops. Professionally, I've never set up version control. It's there when I start the job, it'll be there when I leave. I've branched and merged but a lot of times this is handled by a build manager. Build automation I have never expressly d…
> I'm not sure how 'Source Code Version Control' and 'Build Automation' is anywhere near the words 'Software Engineering'. I'm not sure how they couldn't be. True, they are not a part of computer science, but both are very helpful to be able to build software efficiently (i.e. software engineering). The places I've worked tend to not have build managers (and the one time there was one, the person wasn't technical and…
- can the candidate do the job? (github projects, portfolio, hands-on test)
- when they talk, do you understand?
- when you talk do they understand?
- do they sit all day and read HN / Stackoverflow?
- on the other hand, they never heard of the above
- do they get the job done or try to make it perfect?
- do they fit the culture of the company
- can they learn a new skill quickly
give 1 point for each of the above and you got a much better matrix (if you want to hire people you won't need to fire)