121–130 of 203 posts
I interviewed at Twilio. My resume and phone chats made it abundantly clear that my professional experience was 95% backend in languages like Java and Go. I looked at their Glassdoor where people wrote they were heavily biased to the algorithm type questions, for better or worse. In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, wit…
Maybe 2 hours should have been enough? I don't know - with the stress of writing under time pressure ( I had a new sympathy for contestants in cooking shows ) and complete unfamiliarity with the module, I was pretty impressed that I submitted something that passed the unit tests.
Then I got rejected with the implication that I wasn't using good OOP principles. OK, my decision to store JSON data as a byte array was unorthodox - but it worked without a lot of coding overhead. I thought it was pretty clever frankly.
> Are they able to read a manual? Uh, I can read a manual (in fact, I enjoy reading software documentation), but it's going to take me longer than an hour...
Let me amend that. Are you able to look up information in a manual - either using the index or hitting CTRL+F?
Does the manual having working code examples? Then is it probably a good manual. If it does not have working examples that you can copy & paste (and they actually work), then it probably is terrible.
Earlier quoted context omitted.
I've done a similar test. I didn't finish it in the time allotted, but a few other candidates did and they hired one of them. The fact companies can do these kinds of demanding frontend tests and still hire people is what makes me think there's a glut of web developers and not a shortage like people keep saying.
There's a glut of resumes that have something web dev on them, and a scarcity of reliable ways to filter for the candidates who legitimately have the skillset(s) needed for the job. I've done a lot of these tests and interview projects, passed plenty, didn't pass a few, didn't bother finishing a few, but - weirdly - every place I've been hired didn't use them in the first place. I've started to view them as a sign of…
Similar here. Strangely, the places that don't do them pay about the same as the ones who do (in the same market—not talking FAANG versus Bob's Printer Service & PC Repair in Madison, WI).
After my latest search my new policy for future searches (at least until the downturn or it otherwise stops being super easy to find jobs) is at least not to do any kind of project or evaluation before a real interview, that is, without a real person from the company taking the same time I am, at the same time. The kind where they send you to some "coding challenge" website or give you some "take-home" project before even talking to you. If they're asking me to burn a bunch of my time to save some of theirs, it means I'm too far down the slush pile and/or they're too bad at interviewing for it to be worth my time.
Earlier quoted context omitted.
>it sounds like you're not a very good person to be interviewing candidates We agree on that one, but the alternatives are worse. Would you like to take my place interviewing? It's a time consuming task I'd love to delegate to someone more experienced.
I would honestly love to take a job that was 100% focused on interviewing and hiring technical people. I have been through so many bad interviews (on both sides of the desk) that I think it really should be a dedicated position staffed by people who actually understand the major defects in the industry.
I'm not sure what position I would be hiring for, but this is the interview I would like to conduct.
Other possible ideas would be a background check that is either insanely deep (so you're 3rd grade teacher was unavailable for a recommendation) or raises issues that they have no part of, "we see you've spent time in North Korea."
I hear a lot (and believe myself I suppose) that I would rather hire someone that knows how to learn than someone who currently knows thing x but can't pick up and learn things on their own. But I feel like it's VERY hard to figure this out about someone. It's pretty easy to test how well someone knows a particular technology or tool (given some variance for operating in a high-pressure scenario etc.) but it seems pr…
If nothing else, it will give you a general idea of how often they learn new things.
Earlier quoted context omitted.
I don't think I've ever had to learn something very complex under the same short time constraints and high do-or-die pressure as an interview. Tiny things (think: new-to-me unixy commands), yeah, but nothing very complex. With as many unknowns as that introduces, should it ever come up in a real job situation with a very short time window available, my expert (I'm quite serious using that term here) advice would be t…
I end up doing a lot of technology selection and so I have to have these skills and the ability to ask hard questions. I don't for a second believe this should be the skillset of every member of a team. A team where everyone is adding new tools all the time is chaos. Learning new tools isn't really a goal. Getting better at your job is the goal, and learning new tools is either a means to that end or just moving the…
I've always wanted to run one where we bring them to a room to interview. Maybe take a break. Move their stuff to a slightly different room. Pick back up right where we left off. Maybe change out the furniture and people outside during the interview. Introduce them to numerous employees, who will respond to names swapped amongst each other. Another break - switch interviewers. Pick up right where the first one left o…