4 ms·

I do not think they are going away. They are a filter some like to use. I personally use a dead simple 'leetcode' style program because I want to see they hav

I do not think they are going away. They are a filter some like to use. I personally use a dead simple 'leetcode' style program because I want to see they have the basics and can communicate them. I have had to filter more than a few people just because of that. If you can not handle some simple if's and for loops you are in for some real trouble later on. Sometimes they will come in and bust on through it quickly. Which actually helps me decide. Because I can then say 'oh you got through that semi quickly which site/book did you learn from?' That opens up what they know and gives me a good handle on how they are technically. I can then move quickly on to 'let them brag about previous work'. That shows if they were passionate for or was it just a job to grind out. Some cases it matters others not so much. If they come in and really give it a good try but struggle a bit and can say why I may recommend making them a bit more junior and pairing them with someone. I also do not see it going away. I recently proctored some classes in my org. By the time the 'class' was done most had not bothered to even do 1 or 2 chapters. It was mostly just watching a 20-30 min video with whatever level of homework you wanted. I watched many of them for a few months after. The ones who bashed it all out were ones who tended to be tech leads and suggesting better things to happen.

phist_mcgee 5y ago
Dude come on... 1. You seem to think that your interview version of basic concept of 'simple ifs and for loops' is the base tier of programming. It's not man, everyone has their blindspots and you are selecting for candidates who are most similar to you. 2. You display hubris in your skills test by assuming that people who can brag the most are somehow more qualified than those who are more humble. Protip, people who code outside of work are not better developers. They are just enterained by their work skills in their personal time. 3. You display immense superiority claiming that your 'class' could not achieve what you wanted them to achieve. You attach meaning to this result. Not many people really want to study at work.
- sumtechguy 5y ago
  1. it is the base. If you can not do that you have more learning to do. I have seen many fail it. I am nice about it but they just need more training. Most of they type of code they will be writing is little more than enterprise glue code. It is not that complex but it takes a bit of logic skill and base coding skills to do. It can help me help them with what sort of training they need. 2. The interview is not about the code. I want to see them in action and see how personable they are (a grump/huckster will ruin a team). I usually have very little time with them so the test has to be simple (something someone who is semi competent can do in 10 mins). That they are studying outside shows they are at least willing to do the work (and a bonus and helps shortcut many things). Learning to do things is usually part of the job. I do not expect them to do it outside of work. But it shows passion if they do (which is not a bad thing but is sometimes needed to grind out more glue code). I am usually more interested in what they used to work on and can they describe what they did. I do not even really care what the thing is. I want them to explain it to me. Explaining what is going on is part of the job many times. As in 'hey so and so wants a powerpoint presentation of what you have been working on for the past 3 months'. Some are good at it many are terrible at it. I am not looking for slick presenters but people who understand what is going on and show that they can do it. Interviews are about time management too. So you have usually 40-70 mins to decide if someone is worth it. You have to divvy up that time into chunks. That is on the interviewer. I usually spend the first few mins just trying to calm the person down. Then the next few with a semi simple test and explanation. The rest of the time is them showing off and hopefully asking questions about the job (not all do). Them not interviewing me shows something too. 3. The whole class was voluntary. I could have snapped the whip and made them do it. But that was not the point of the class. It was to be a group thing where we learned from each other. It was up front that you can do this on the clock or off. It was up to them. It was very free form. I do not think it was too much to ask them to watch some training videos for a framework they were going to soon be using? My 'meaning' that I attached was many do not want to put in the work but still reap the reward. Honestly it kind of shocked me the numbers. It was not like a couple of people dropped out. It was 95% of them. All of the other people helping with these similar classes had the similar results. My 'bar' for them was to watch 1 video per week over 12 weeks (for 9 videos) and some (optional) simple code test. Is that hubris? I was not expecting much at all. 'Not many people really want to study at work' Well then that will be a problem for many. If both 'do not want to study outside of work' and 'do not want to study at work' are both true you will find your skills rusty and long term unable to do the job. I have watched it happen over and over. At some point the tech stack will change. You will need to learn it. I can honestly say I have not gone many days in my career learning something. Reading docs, reading tutorials, watching vids, classes, prototypes, whatever.

phist_mcgee 5y ago

Dude come on... 1. You seem to think that your interview version of basic concept of 'simple ifs and for loops' is the base tier of programming. It's not man, everyone has their blindspots and you are selecting for candidates who are most similar to you. 2. You display hubris in your skills test by assuming that people who can brag the most are somehow more qualified than those who are more humble. Protip, people who code outside of work are not better developers. They are just enterained by their work skills in their personal time. 3. You display immense superiority claiming that your 'class' could not achieve what you wanted them to achieve. You attach meaning to this result. Not many people really want to study at work.

sumtechguy 5y ago
1. it is the base. If you can not do that you have more learning to do. I have seen many fail it. I am nice about it but they just need more training. Most of they type of code they will be writing is little more than enterprise glue code. It is not that complex but it takes a bit of logic skill and base coding skills to do. It can help me help them with what sort of training they need. 2. The interview is not about the code. I want to see them in action and see how personable they are (a grump/huckster will ruin a team). I usually have very little time with them so the test has to be simple (something someone who is semi competent can do in 10 mins). That they are studying outside shows they are at least willing to do the work (and a bonus and helps shortcut many things). Learning to do things is usually part of the job. I do not expect them to do it outside of work. But it shows passion if they do (which is not a bad thing but is sometimes needed to grind out more glue code). I am usually more interested in what they used to work on and can they describe what they did. I do not even really care what the thing is. I want them to explain it to me. Explaining what is going on is part of the job many times. As in 'hey so and so wants a powerpoint presentation of what you have been working on for the past 3 months'. Some are good at it many are terrible at it. I am not looking for slick presenters but people who understand what is going on and show that they can do it. Interviews are about time management too. So you have usually 40-70 mins to decide if someone is worth it. You have to divvy up that time into chunks. That is on the interviewer. I usually spend the first few mins just trying to calm the person down. Then the next few with a semi simple test and explanation. The rest of the time is them showing off and hopefully asking questions about the job (not all do). Them not interviewing me shows something too. 3. The whole class was voluntary. I could have snapped the whip and made them do it. But that was not the point of the class. It was to be a group thing where we learned from each other. It was up front that you can do this on the clock or off. It was up to them. It was very free form. I do not think it was too much to ask them to watch some training videos for a framework they were going to soon be using? My 'meaning' that I attached was many do not want to put in the work but still reap the reward. Honestly it kind of shocked me the numbers. It was not like a couple of people dropped out. It was 95% of them. All of the other people helping with these similar classes had the similar results. My 'bar' for them was to watch 1 video per week over 12 weeks (for 9 videos) and some (optional) simple code test. Is that hubris? I was not expecting much at all. 'Not many people really want to study at work' Well then that will be a problem for many. If both 'do not want to study outside of work' and 'do not want to study at work' are both true you will find your skills rusty and long term unable to do the job. I have watched it happen over and over. At some point the tech stack will change. You will need to learn it. I can honestly say I have not gone many days in my career learning something. Reading docs, reading tutorials, watching vids, classes, prototypes, whatever.