3 ms·
I'm honestly tired of programmers complaining about interviews. I don't think the whiteboard blitz is a good gauge of an employee, either, but I don't know of
by jknoepfler 8y ago
I'm honestly tired of programmers complaining about interviews. I don't think the whiteboard blitz is a good gauge of an employee, either, but I don't know of any good "test" of a potential coworker other than working with them.
One thing I think people wildly underestimate is how aware the interviewer is of the inadequacies of parts of the process. I will ask basic programming questions for the same reason I write unit tests. Weed out obviously broken candidates with really easy questions. But beyond that, I need people with common sense and a strong sense of professional ownership. I need engineers with spines. I need people who tell me what they think needs to be done, not people who are going to sit in their cubical complaining about how crappy the interview process is. I need people who learn quickly, not people who will be paralyzed by code smell or new tech. I need people who can jump into management roles to fill in gaps because they get how things work and want the team to get shit done.
If you don't like the process, fix it yourself on your team. Do better. Teach others. Believe it or not, lots of people have gone down the same rabbit hole, and your "crappy interviewer" is likely one of them.
- scarface74 8y agoI'm honestly tired of programmers complaining about interviews. I don't think the whiteboard blitz is a good gauge of an employee, either, but I don't know of any good "test" of a potential coworker other than working with them That's the answer - "you work with them". I create a simple version of a real world class that we have worked on. Each method has comments on what the code is suppose to do and a bunch of failing unit tests and we pair program. The first set of unit tests are relatively easy. I then add a second set of requirements with a second set of unit tests. They have to modify the code to pass the 2nd set of unit tests without breaking the first. But as far as "going down the rabbit hole", I've never gone down that rabbit hole of algorithm type tests. I was drilled on C in an interview in 1999 because they were doing a lot of hard core C work (I stayed on that job until 2008). But since then, most of my interviews have either consisted of the sitting down at a computer and solving problems type or just drawing on the board and explaining architecture. Even though I'm very much hands on, at this point most companies hire me more to help them with architectural issues than just as another coder. My salary requirements filter the just another developer type roles out. No, I'm not bragging about how much I make. I'm still only making the median for a senior software Engineer/architect for my market - if the salary surveys and my anecdotal experience is accurate.