|
|
|
|
|
|
by rescbr
1900 days ago
|
|
|
It really depends on the interviewer not wasting both our times and making it worth for everybody. I had candidates that weren't good sellers of their past experience, but I made sure to engage with them and they were in fact excellent professionals. When interviewing you can ask the candidate for details on their MySQL + cron job and investigate how do they think, architect and build a solution and how much bullshit they're talking. Were you given a very detailed task to perform and you just did it? Or did you reach the conclusion that a MySQL DB plus a cron job would achieve the results? Why? What if the cron job failed? Draw a rough flowchart of your script, etc. On the other hand, you can smell the bullshit of interesting fictions from a long distance when you ask those probing questions. Now, an interview on basic CS algorithms? The only thing I would know is that you have a good memory and can recall the Cracking the Code Interview book. |
|
|
It might come down to who is doing the interview: if you're a founder, or a team leader, and have done a lot of project management, you're likely to ask better questions about constraints, considerations, teamwork, etc, and get a better read on a candidate from questions about past experience. OTOH, a programmer giving an interview may not really care that much about those aspects or have a realistic idea of what a reasonable answer sounds like, and will thus tend to just jump through the interview hoops--and be more susceptible to, well, nonsense. On the other hand, they may actually be interested and invested in low-level technical questions.
I've had really good tech interviews that were challenging and even fun, and I don't think I could've faked my way through. I've never had a good experiential interview. But then, I've only ever interviewed for front-line programming jobs at large companies.