201–210 of 348 posts
Please don't. I can take one day off work for a full-day interview; I'm not going to burn through four fucking vacation days for you to vacillate over whether or not I'm a "culture fit" or whatever.
Earlier quoted context omitted.
Since you're attacking me, do you have any experience screening resumes? Phone screens? In-person interviews? Have you had the experience of a candidate that has apparently "done it all" on their resume, and confirmed their skill level when asked in-person, only to see them struggle with the simplest question in an area they deem themself an "expert" in? I've interviewed well over 300 people, for positions from junio…
Yup... and I don't know, for someone who has "300 people" worth of interview experience, you sure don't seem to be demonstrating in this thread the sort of level headed temperance and soft skills I would expect. I'm joking. (sorta) I'm glad to hear that you tailor to the resume, that's actually better than most and my favorite approach. But if I had a dollar for every time someone walked out of an interview with a br…
Just because a candidate fails or falls short in one area doesn't mean they are cut, but it's a pretty large red flag if a candidate purports to know something, both on their resume and in person, yet can't answer some seemingly basic questions. If you state on your resume that you architected and implemented a system end to end, yet can't whiteboard the result and explain bottlenecks or failure conditions, I absolutely will assume you stretched the truth a bit. And if the candidate feels the need to do that to get the job, what will it be like to work with them? Could you trust their estimates? Would you be able to back them if something they delivered fails and you trusted them as a senior to deliver?
I ask follow-ups. I give hints. Honestly I'm dismayed at the skillset of purported "seniors" and "architects", and that's interviewing for small companies up to one of the FAANGs.
Earlier quoted context omitted.
I mean, people shouldn't be reversing strings by hand, but being unable to do so is also very worrying. Not because manual string reversal is an everyday problem, but because you need to do similarly complicated things all the time . In fact, you need to do them even if you're not a dev, it's just that devs share a common language that makes string reversal a sensible problem to ask in an interview.
>you need to do similarly complicated things all the time My policy is to ask about those things instead. The ones you'll actually do rather than the ones that are, at best, tangentially related.
Earlier quoted context omitted.
I've interviewed and been interviewing for over a decade. I have had the displeasure of interviewing many people who have very impressive resumes yet when asked how they would judge their skillset in an area, and being told from them that they would say "expert", being shown exactly the opposite when it came time to answer some questions in that area. One data point... Senior engineer that founded the local java user…
Why do you assume that the person is lying? Why do you start your relationship with your new co-worker on distrust? There is a way to weed out the liars - you hire them and then when it does not work out you fire them. You would be astonished how little people lie on their CV. They may exaggerate claims - yes, that is why you gave them a call in the first place. But then again you exaggerated your claims in the job p…
In my experience, firing someone takes multiple months. Months in which they are mutating the codebase (with review, but it's a time sink that shouldn't exist for a decent senior), influencing other engineers, etc.
Passing on a good candidate is cheaper in the long run than hiring a bad candidate. Or said another way, false negatives are preferred over false positives.
> You would be astonished how little people lie on their CV.
This has not been my experience. From something as white-lieish as "I designed and implemented" vs. "I was a peer on the team that did it" to flat out fabrications. You learn alot by simply asking "what was your role on the project" and asking follow-ups to dig into their contributions.
The process that my CTO and I have found works best is as follows;
A 20min phone interview (to screen for BS’ers).
A technical test that’s based on the sort of problems they will be solving in their job. How would you do X in language Y, no boiler plate code, and it doesn’t have to be perfect. (So no fizz buzz, conways game of life etc.) We also stipulate to spend no more than 2 hours on it, and if their successful they get that time back. We even offer a discount (on the thing we sell) to unsuccessful people who don’t make it. The test serves as not only a good high level demonstration of ones skils but, more importantly, gives us all something to talk around. It also shows us how they approach key things like testing, deployment, maintainability etc etc.
Then there is a 2 hours face to face interview. Ahead of this the test is peer reviewed by the engineering team (or part of it) The interview is made up of one one hour technical section with the CTO/Senior, and one with a designer/product manager. A joint decision is made.
Then, if they are successful, we have a probation period where we (the candidate and us) work out if it’s all going as we’d hoped. If not, we part ways. You most likely wouldn’t marry someone before a first date. A job is the same. You both need time to see if you like each other and your profile pics match real life.
It’s not perfect, but no system is. Sure we’ve hired a few people we’ve had to let go, but for the most part it’s a great system. We’ve managed to hire not just great engineers but also build a team and culture that fits and works.
Hiring is time consuming, hard and at times emotional. There is no shortcut.
I’ve interviewed and worked at big tech companies and they all think there is some secret sauce, a magic code to hiring. That is, if you ask super hard questions only the “best” make it through - utter tosh. Some of the most amazing engineers I’ve worked with would fail these type of stupid questions (for a while load of reasons) but quietly write amazing code.
Also, and more importantly imo, to be an amazing engineer you need to be great (equally) at teamwork and communication, not just be super book smart.
I read a while back (or imagined it?) that MSFT only hired people with Msc’s/PHd’s and that it created a probelem where there wasn’t any intellectual diversity. These tests cause this too. You get cookie cutter people who are smart but often can’t work in teams and can’t communicate well.
Great, now can Netflix, Google and Facebook do this, too? Not because I want to work in these places, but because they influence everyone else and as a senior engineer in the systems space I feel I shouldn't need to study days or weeks for fizzbuzz sorting algorithms questions that are designed to test comp sci recent grads. I have a proven career, and was never suddenly stumped in a project due to not being able to.…
I had a junior/intermediate level engineer start asking me minutiae about HTTP and HTTPS... After about 5 minutes of this I literally said: "Dude, have you seem my resume? I literally built a petabyte scale full text search engine and wrote 1.5M lines of code to do so and a HTTP framework that parses fetches more than 2PB of HTML per month. If there's some edge case that I might miss I can Google it in 30 seconds". I…
It sucks, but this is what happens when the job you’re interviewing for has no license or certification requirements (but pays six figures).
Earlier quoted context omitted.
The question was: Write a method that can take in a regex and a string and return whether the string matches it, with the regex limited to the characters . * ? (And backtracking is definitely where I started coming unstuck)
Ah, that's definitely different than I understood your first post. You're writing a regex to match a given type of string. The regex parser is in the language itself, consuming what you've written and evaluating it.