131–140 of 239 posts
Last I read, Google has something like a thousand applicants for each position, each level of filtering reduces the amount by an order of magnitude for a position they may or may not fill so it becomes statistically harder than being accepted to Harvard.
Likewise, people practice for these interviews harder than they do for college entrance exams and work on saying the exact things the interviewers want to hear. In essence, the filter is on this particular kind of "grinding" work ethic.
Lately I have done a few at home code challenges for companies. They usually take several hours. They are perfectly functional and use minimal code but, the only feedback I receive is: "we're not moving forward". They won't discuss anything with me. The only impression I get is that your company is terrible and I will never respond to your recruiters again.
I've come to believe very firmly that any interviewer who asks me to submit a take-home coding project is not serious about my candidacy. I have no idea what they use them for, but it's not hiring.
So these kinds of posts keep showing up. How are interviews for not-software-engineers conducted? ie. how do you interview for a business analyst role, or a sales and marketing role? I have to assume that those roles suffer from the same sorts of issues a SE job does -- that someone can talk a good game but not be able to perform in the role.
Doctors have to go through a rather grueling licensing process. The job interview is mostly about determining mutual interest. Doctors also need to go through periodic re-credentialing. To put it bluntly, when a doctor has credentials, you at least know that they're competent; and more competent than 2-4 1-hour quizzes.
I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…
I interview quite a lot, and one of the things I try to do in an interview is work through a problem that I almost certainly understand more deeply than any of the candidates (both because it's my niche and because I've worked through the exact problem with hundreds of candidates before). There's a certain minimum bar that I expect any educated and intelligent individual to achieve if they're a good match for the job…
One of the most unrealistic parts about a code interview is just how high-pressure it is, time sensitive in unrealistic ways, way more impact on your career than usual 5 minutes of coding, no peers to ask questions to, unclear if asking to google will be seen as a negative or not, etc. I think trying to reduce some of these unrealistic pressures, by being clear about what you're expecting (and being in this case up front that you _have_ intentionally given them something out of their domain knowledge) can probably give you a better evaluations. Some people do better under that kind of pressure than others, but if that kind of pressure is not actually representative of the actual job, it may not be what you want to be testing for.
Also set expectations for transparency and kindness (instead of bullshitting or preening) by modelling it yourself, right from the start.
I think the crux of the problem is... Everyone knows what to expect in a SAT exam, and still if one complains that they didn't bother preparing for it 'cause they do not have enough time... That excuse is not getting them an admission to top institutions, which admittedly have no short supply of folks willing to prepare and go through the grind. It is sad that interviews in tech have been reduced to a process that re…
I'm not sure why that is bad. The more standardized the interview process is, the more consistently people can prepare for interviews and know what to expect. The interview process doesn't have to represent actual work, as long as preparing for and performing well on the interview requires the same skills used to learn and work with a new software feature / language / problem.
>The premise was that it is simply not possible that most folks with X yrs of experience at a software shop are all secretly terrible that they can't get past your interview process.
That's an obviously false premise.
1) Take home assignment with extremely clear instructions directly related to the job.
2) Discusses the results of the take home assignment over video conference call, and/or in person, and actually asks specific details about it.
That is all I ask. Most of the other interviews either are all conversational in nature, white boarding, or don't actually evaluate the take home when you are done with it. My conclusion is nobody knows how to hire and maybe I should switch to becoming a starving musician full time instead.
So, how do you save yourself before candle burns the rope?
I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…
Earlier quoted context omitted.
Yes. Because if they don't have a deepish understand of the language and framework IME they tend to write crap code. If someone is being hired to write C# /.NET all day every day I don't want to have to spend time teaching them C# or .NET Especially not how to write good C# / .NET.
Wasn't part of the point of C#'s syntax was that it was easy for C++ and Java programmers to learn? Would any real C# advocate really tell me it would take months of manager supervised learning to pickup? I've been writing code for a long time in many languages and I do my best to write "good" code. The principles that make code "good" in one language appear to apply equally to other languages...
The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples.
There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".