This is good.
But the question is how to get smart enough to solve medium-hard level problems without hours and hours of practice?
Tech Interview Handbook
331–340 of 344 posts
Re: Tech Interview Handbook
#332I'm going a different route with interviews and wonder if anyone has input... I'm a senior backend dev with 10+ years of experience. Breadth of projects, masters in CS, open source work, team lead, top contributor, great references, etc. But I cant pass a coding interview, because I kinda freeze up during algorithm whiteboarding questions. I get requests for interviews daily and have been considering starting with a…
Put “I don’t do pop quiz interviews” on top of your documents and see what happens. I do this but haven’t been so blatant about it. Networking is the only other avenue.
Re: Tech Interview Handbook
#333For all the negativity for these type of tech interviews, they are, from what i've seen, one of the most merit based systems out there. It is either this or we need to create some sort of national developer exam. The other alternate is to get jobs at good companies, they will only look at what school you went, whether you graduated with a CS degree, what companies you worked etc... All things which do not guarantee m…
Merit at high pressure performance, not being a good developer.
Re: Tech Interview Handbook
#334What if people not being able to answer simple programming questions is a problem with the interviewers, and not the interviewees?
This is one of those ideas that sounds really sophisticated, but is just wrong. The fact is that there a tons of people out there representing themselves as programmers who actually can’t perform basic tasks. The HN population massively selects for competence, so people here have a hard time imagining what things are like from the interviewer side.
Notwithstanding, interviewers could also be asking misguided questions. Which I find often.
Re: Tech Interview Handbook
#335Earlier quoted context omitted.
One company sent me (before the interview) a small technical assignment. After I had submitted the code, an interview was scheduled. The entire interview was an extended code review -- talking about trade-offs, about other potential solutions, etc. I felt this was much better in that it was less stressful, yet allowed me to demonstrate both knowledge and design skills. Another company did something similar but more t…
I've been thinking for a while that companies should create their hiring tests from bugs and/or feature requests that came from their actual software in the past. Then they can gauge the quality of the employee for their purposes by comparing the candidate's solution(s) to those the actual employees wrote.
Bugs I have seen in actual code are divided into two types: those that are due to the way code inter-operates with other code (sort of integration bugs) and tricky bugs (usually edge cases) in some highly dense code.
The first type requires the candidate to learn a lot about the existing code base. The second requires more mental work but is atypical of real work.
Implementing features sounds like a good idea. Perhaps create a small well defined system which is a simplification of the real world system and let the candidate implement some additional features.
Re: Tech Interview Handbook
#336Earlier quoted context omitted.
Personally I can't see an issue with very simple FizzBuzz style programming interview questions. I used to ask a simple "count duplicate substrings" question [1]. Maybe some people consider this too hard? I never used to require exact syntax, and would have been happy with pseudo-code. Using libraries is fine etc.. I also found very few people could solve this (similar non-SF large city location). Occasionally, peopl…
Your problem actually is a good illustration of the whiteboard test problems. I just tried it, and it was trivial to do in a minute or two on my laptop. However, I did took note of two syntax mistakes that I made in the python REPL that were immediately obvious there and took seconds to fix, but which I most likely would not have noticed on a whiteboard. So there's quite a bunch of problems where if the acceptable "f…
I also was able to solve it in a couple/few min after seeing the comment. I did have a couple issues, index was off by one, and didn't catch an issue if I had already seen the substring using a brute force nested loop, but otherwise it works (Python). Edit: I also did it without a nested loop using a dictionary. Why I didn't think of this initially I don't know.
I've also had a couple FAANG onsites and get nervous as can be, but that's just a practice more and be more confident with my abilities problem I feel. No offers though yet. Still trying and practicing.
Re: Tech Interview Handbook
#337I 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…
Been doing it the same for over 20 as well, only had one bad hire and it had to do with drugs and attitude more than skill set. He was a good developer and was sober when I hired him but fell off the wagon and started missing work, no showing etc. I fully concur that if you can't spot a competent developer from a conversation, you probably should not be in the position of evaluating potential developers.
I don't disagree that there are a lot of fake it till you make it developers who did a vo-tech class and are applying for jobs out of their league, but I just don't know how people don't spot them. It takes me about 5 phone calls to find a competent individual, and then I bring them in for a in person. As a hiring manager, I don't find it cumbersome to weed thru 5-10 people to find a good hire.
Re: Tech Interview Handbook
#338Earlier quoted context omitted.
As a very fresh junior developer, crafting a CV is extremely exhausting, because it is very hard to gauge what you can put in. Take git as an example: I used it for a couple of personal programs, read part of the documentation, had some errors and managed to get rid of them. I know the theory of how to use it on large projects. I even know enough to know that I'm pretty much just scratching the surface, but so are pr…
You should be able to talk fluently for at least 1 minute about everything you list as a skill. You should have enough material to be able to talk about your CV as a whole for 45 minutes. Not a cast iron rule but this will see you through most interviews. Good luck!
Thank you, that is an interesting way to look at it, and makes a whole lot of sense! I guess it should be amended by "meaningfully talk about", but I get that from context.
To be honest, the process of writing a CV is mostly painful for me because I have to evaluate myself and feel quite inadequate. At the same time, I have multiple companies wanting me despite not being very good, so my actual chances are really good. Software development in Germany is going crazy at the moment.
Re: Tech Interview Handbook
#339Earlier quoted context omitted.
Maybe they can , but why would they? Algorithms interviews are the only thing with an actual bearing on their future earnings.
> Maybe they can, but why would they? Professional pride? Wanting to get better? > Algorithms interviews are the only thing with an actual bearing on their future earnings. Do they not want promotions or pay increases at their current jobs before leaving? Usually you have to do good quality work to get promoted. Please read my original comment: https://news.ycombinator.com/item?id=20727948 . People who lack these ski…
"Do they not want promotions or pay increases at their current jobs before leaving? Usually you have to do good quality work to get promoted."
In my experience, algs interviews are far, far more fair than promos. You don't need to do good work to get promoted, just be friends with the boss or lie about how much "impact" you had, at least that's what I've seen in big tech and it's been extremely frustrating. Learning to code well definitely doesn't matter much, the measurements for promotion are gamed by the dishonest and/or subjective enough to let the bosses promote their best friends.
While doing well on interviews isn't the only way to be recognized, it's the only consistent way the market continues to pay you properly if the company decides not to promote you. Suddenly my code was considered amazing once I brought another offer.
Re: Tech Interview Handbook
#340Earlier quoted context omitted.
The cost of hiring the wrong person can be huge. This just isn’t true. Every company has a “probation period” usually 3 months where either party can terminate the agreement. That’s more than sufficient to cover this risk. You don’t pay the recruiter until probation is passed - everyone knows this. This meme comes from Spolsky who somehow also convinced the world that the hottest programming talent was beating down h…
> This just isn't true. Sure it is. People on our team need to take time to onboard the new hire. That's good and expected. The new hire will work slower and that's ok; they will need extra help, time to learn the codebases, etc. After a couple of months, a particular new hire did not work out. Time had to be taken to document reasons, meet with HR, meeting to talk about expectations, etc. In the end, the new hire is…
This is all true to my experience but not just exclusive to hiring low performers (which I assume is wrong qualifier means here) but also to unsuitable fit, poorly management, failure to motivate a new hire (specially when hiring senior developers), etc.