In my experience, dynamic programming is overrepresented in interview questions (vs. like other algorithm techniques). Everyone loves to ask dynamic programming questions, make sure you've done a lot of them and you'll look really impressive.
Tech Interview Handbook
91–100 of 344 posts
Re: Tech Interview Handbook
#92> Get a proper email account with ideally your first name and last name, eg. "john.doe@gmail.com" instead of "angrybirds88@gmail.com"... Avoid emails like "me@christi.na" or "admin@[mycooldomain].com" -- because it is very prone to typo errors. I don't think I've ever seen anyone explicitly recommend against using a custom domain for email.
[deleted]
Re: Tech Interview Handbook
#93Earlier quoted context omitted.
They could in theory, but nobody wants to. I used to see probationary periods, but I haven't seen a company use that for salaried staff for a long time. HR and Legal have put an end to that kind of thing. So Jim is right, in practice the only way HR is going to let you have a probationary period is to use contractors, and that limits your hiring pool significantly.
Every decent sized contracting firm I've ever worked with offered benefits. It's more expensive, but you just price that into your rate. So I don't understand what the concern is. Is it the risk that after 3 months you won't be brought on full time?
Upheaval is the issue. First, most contracting firms have pretty crappy medical plans. Secondly, there's generally a wait period before full benefits kick in. Thirdly, you wind up switching your medical plan multiple times in a short period.
That's fine if you're single, but if you've got kids that might mean switching doctors multiple times, which is a gigantic huge deal. Also, you have multiple periods of time where you don't really know your benefits which is terrifying. And if the company does drop you after three months for whatever reason, now you're doing it again.
And keep in mind it's definitely a seller's market if you're a good dev. It's incredibly unlikely that the 3-month contract is the only offer on the table. So all things being equal, who would take it?
Re: Tech Interview Handbook
#94I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…
I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. It'd be nice to think I…
Thank you for your refreshing point of view. I'm a mid-level software developer and I was on the other side of the table as a junior web developer and encountered this same style of questioning and embraced it. This is my go-to style when interviewing because if you are confident in the lingo and zeitgeist of development, there is no way they can bullshit there way and lie through their teeth on their own experiences. It is very easy to tell. Whiteboarding doesn't give that detection since it is too broad of a spectrum to start as a indicator of experience.
Re: Tech Interview Handbook
#95I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…
I prefer take-home assignments. I know that they often get a bad rep and have the potential for abuse; for this reason I'd argue for implementing some or other solution in the field.
I recently had one requiring me to develop a native mobile application, which I enjoyed. It was interesting, the code is useful down the line, and if I don't land the job, it beefs up my portfolio.
Initial screening by recruiters is tough as my background's missing a degree and industry experience.
Context: self-taught, started out with game dev, tried going solo - not a runaway success. Looking to move away from the field.
Re: Tech Interview Handbook
#96Two outcomes for the technical industry: 1.) Everyone is studying these problems all of the time and they finally disappear. 2.) Other outcome is a dystopian field fueled by a race to the bottom where everyone is practicing algorithms problems all of the time. If you read the blind forums, some people are completing 500-1000 leetcode problems before heading into interviews. I'm putting my money on number 2, which is…
Can only imagine what this is doing to code quality... I don't get why no one seems to consider the possibility that these sorts of interviews actually do get high quality engineers in the door. I get downvoted for raising the question every time. But isn't it possible this interview style actually works, even though it doesn't resemble real coding and even though many of us hate it? I have yet to see any compelling…
I guess the reason is that if it would work we would already know about it and there would be a bullet-proof way to prove it
Re: Tech Interview Handbook
#97I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…
I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. It'd be nice to think I…
It’s also very subjective and hard to train for or to audit externally. When a company gets too big, you can’t properly vet hiring personally anymore, so you have to scale it.
You don’t want ‘bozo cliques’ to form, so you make a semi-objective process like ‘solve this algorithmic question’ as part of the interview loop. I think execs and the founders doing a final review before hiring all engineers comes from that fear.
Then other companies cargo cult interview processes from larger companies and the trend propagates.
If you want to ‘hack hiring’ as a smaller company, you should use hard to scale processes like the one described in the parent post.
Re: Tech Interview Handbook
#98I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…
I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. It'd be nice to think I…
These are the kinds of interviews I love, and I appreciate that they're still given at some places. I agree, it's nearly impossible to bullshit your way through this kind of a conversational interview but people still think they need to ask trivia questions.
Re: Tech Interview Handbook
#99Earlier quoted context omitted.
Can only imagine what this is doing to code quality... I don't get why no one seems to consider the possibility that these sorts of interviews actually do get high quality engineers in the door. I get downvoted for raising the question every time. But isn't it possible this interview style actually works, even though it doesn't resemble real coding and even though many of us hate it? I have yet to see any compelling…
I guess the reason is that if it would work we would already know about it and there would be a bullet-proof way to prove it
Can you help me follow, because that seems like a leap of logic. Why would that imply there's a bullet-proof way to prove it?
Re: Tech Interview Handbook
#100Earlier quoted context omitted.
I really hope this fails, something I have never wished for any other startup. At least personally in my hirings I'll never use or trust anything like this. There are so many things wrong with this approach that I'm kinda speachless as to where to start.
Please do start? I'm kind of curious what you'll say because it's not at all obvious to me that it would be a bad idea.
I'll try - a few thoughts:
Software engineering is part knowledge and part application of knowledge (problem solving) and part ability to acquire and apply new knowledge. We remain current in our jobs and roles by making sure we're constantly learning. Interviews should be part testing of knowledge, but a lot more discussions to evaluate problem solving and ability to acquire & apply knowledge.
Also, knowledge in many cases becomes stale if not used. If I learn a new language/framework but don't use it in a project immediately, I'll forget almost all of it. I may learn react via books/tutorials, get a great score in the test, never use it and/or forget it by the time I get a job based on the score. Am I a good hire?
Given that it's not clear as to what problem such a test will solve and moreover it's unclear as to the long term impact of such a test. Is this just for initial filtering, or will become an actual hiring criteria?
If graduates from colleges are expected to take such a test to prove something, then what is the value of the work these grads did in their colleges? How is a score in these taking in regards to the work students do in colleges?
Some people are better test takers than others. An a good interviewer is able to probe and work with the person. So such tests may end up discriminating, not on purpose of course, against bad test takers if they become the sole filtering mechanism. People may have to take tests again and again till they get a good score. An effort, which in no way helps in their job per se but is simple an additional burden.
The only potential place where I can see some value for such a test if to evaluate the coding camp folks, since different coding camps have different quality. However, even there, it's unclear how this will pan out.