I've been conducting coding interviews for some time and I will like to help you answer questions you might have about it.
I am not a recruiter, I do the so-called "technical interview" so lets share and hopefully help someone to hit a home run on their next interview.
Some topics I think you might be curious are:
preparation, approach, tools, common pitfalls, etc...
So go on and shoot 😄
Side note
I am thinking about sparing some time to do mock interviews with some newcomers to the software industry, so if you are interested please let me know and we can check a way to sort it out.
Top comments (17)
How important is top-of-mind CS knowledge?
From my last two interviews, I feel like I need a part-time job just to drill CS puzzles, as I'm not flexing those muscles at all in my current fullstack dev role.
Sadly, this is all too common, at least in Silicon Valley. Apparently, the tech giants have decided that puzzles and algorithm questions are the way to find the best engineers. I'd like to know whether they have metrics which prove that because over 10+ years of interviewing, I've found the opposite to be true.
So much of what we do now revolves around effective use of tooling and understanding how to simplify code and workflows. Particularly with front-end, there is virtually no need to devise clever algorithms. I've seen that people who look for clever solutions tend to overthink simple problems and write more (complex) code.
I want to know how you can quickly solve practical, real-world problems, so I started giving candidates a mini-app to build, and I've found that that process reveals more about them than giving them a series of algorithm/puzzle questions.
It depends on the role and the career level you're looking for, although some companies still do the algorithms questions, but it also depends on the interviewer, I like the case study approach because we can put you on a situation that is close to what will be your day to day job and also see how you implement it, so far it has had very good results and we are very happy with that.
Probably for other positions or companies the algorithmic challenges work best, I don't claim to have the secret sauce and we are always learning and improving our process and for us it works to find out if someone has what it takes through a conversation than while drilling them with complex and most of the times hypothetical problems.
Unless the job you're applying for is heavily focussed on developing algorithms to solve hard problems, technical interviews which focus on those type of problems should be considered red flags. In fact, any coding interview which cannot realistically tell the employer something useful about your ability to perform the tasks in the job description with the tools/languages required is a definite red flag, IMHO.
I am 100% agree with Kevin, any decent company should offer you a lot of transparency on the role and the responsibilities related to it.
Is "the software interview" evolving over time? How have things changed in the last five our so years in terms of how developers are typically interviewed?
Hi Ben, such an honor to have you here 😄
I will say is evolving, probably not at the speed we will like it to be but as everything in the software industry is moving forward, nowadays there are some platforms that support a lot of processes related to interviewing, and just the fact that we can interview people all around the world broadens the market both for employers and for job hunters.
Challenges can come from any direction, specially when having such a wide ecosystem where everything requires a very special set of skills and qualifications.
You need to have a well defined profile and make a list of specific skills (soft and hard) you're looking for. I've seen some job ads that are asking for frontend engineers with a taste for backend and experience with devops which makes me wonder what are they really looking for.
In terms of the interview itself I will say the changes are quite visible, now most of the software companies are going for power of proof instead of a university degree, people coming from all sort of backgrounds is applying to software engineering roles which gives you a lot of different perspectives and solutions for the same case study and also the white-boarding is getting obsolete, while platforms like Github are providing a lot of developers with hands on experience while they are also contributing to a product or project.
For the last part of your comment, the typical interview process involves a case study, a technical interview, a company culture and motivation interview and finally a probation time.
It is a slow process but it is always evolving as we learn a lot from the interaction with our interviewees.
For me the accessibility to educational platforms and content about software is amazing and has had a lot of impact in plenty of my colleagues and myself.
You also have the other side of things, where people feels like just because they followed two or three tutorials they are software engineers and I've seen tons of this applicants, this is not that good (personal opinion) but I also understand that there are a lot of misconceptions when Youtube is flooded of people claiming that anyone can be a software engineer or videos saying how I got a job at x just by following this course or something else which I feel is not fair for the end user as they are just being part of a clickbait.
That is why I will like to share as much as I can to hopefully clear our a lot of this misconceptions.
How important is it to meet all the requirements for a job posting?
I have seen plenty of job postings that have a long list of all the languages or platforms they want the applicant to know. C, C++, C# Python, SQL, Assembly, Node.js, Ruby, R, and so on... Does it really matter?
And if so, what kind of expertise do the interviewers/company realistically expect the applicant to have in each of the many languages they want?
It is important mostly for you than for the company, because the company runs a business and unless you are joining a new startup, you will be working with code that is already in place so it might make you unhappy in the long run or just impact your output as an employee.
But also taking your example, let's say you are super good with C, well then use C and make clear that even when you don't meet all the criteria for the position you are willing to learn and push yourself to catch up.
When I was looking for a job I did a list of the programming languages I was OK with, then I found companies working with that.
It is unrealistic to think you're going to use all of those at the same time, probably they know that at some point you will have to go and fix a bug in an old project written in R even when all the new stuff is in python, companies are quite reluctant to rewrite what they have because time is money and development time is quite expensive, the business side of things is something that you also need to understand because companies value that a lot.
I'm struggling to land interviews, despite completing a nanodegree program, the few interviews I've had (to varying degrees of success, Facebook and WalMart Labs mostly) highlighted my CS deficiencies. How do you think a nascent bootcamp developer could land more interviews? Should I focus on building software, learning new technologies, or like Kait mentioned (and where I am mostly invested now) CS puzzles/exercises? Thanks So much!
It depends on your expectations, but for the tech giants this is the way to go, though for google I think things are changing for some positions.
What is really sad is that most of the companies think they should do the same as Google or Facebook when the scope and the product they have is not even close to that.
As I said before define what you want, list the things you're good at, make some wishes about your future employer and then target companies matching your criteria, if you wanna work at Facebook or Google you will definitely need to be among other things a algorithms ninja
I am thinking of giving a session on prepping for software engineering interviews for juniors in my university. Based on my own experiences of giving multiple interviews, I've fair amount of knowledge about the whole process (which topics to study, how to communicate effectively when asked a complex question, engaging with HRs and recruiters via networking, salary negotiation etc).
*Still there's a strong chance that you know things which I don't. So I would like to know your perspective on the process in depth. *
Hope I'm not abusing the AMA offer by treating it as an AME.
Which cut (ordinally speaking, perhaps) are you responsible for? Since you say you're a technical interviewer rather than a recruiter can I assume yours is not the first cut? How many cuts have candidates survived prior to meeting with your scrutiny? How many cuts are downstream of yours? What is the cut rate for your step in the process (or, what is the distribution of your cut rates?)
Well I am happy to tell you that some of your assumptions are wrong, we are the first and the second filter as we don't have recruiters nor we accept referrals from recruiters or agencies, we have a mechanism called proactive application in which we expose the case study for each position, in order to apply you need to complete the case study that then goes straight to the team in which you will work and is this very same team the one interviewing you, we have a final interview that check company values and culture fit and that one is also conducted by people from the team.
I can say from the case studies we get around 10% get to the technical interview and from there like 1/10 will pass to the final one.
This varies from one person to other, for me I always start with a bit of dummy talks to make them feel comfortable because I've also been on the other side of the table and then we transition to the presentation, I will say just be nice and when you have the chance to talk be authentic, if you don't know something don't try to come up with an answer right away, you can say that you need time to understand the question and I also like a lot when they make questions to clarify assumptions because then they can make a fully informed solution/answer.
What's a common misconception with the technical interview that you would like to set straight?
That you need to be a master in algorithms, I mean for most of the entry level and junior positions.
That your resume needs to be outstanding and so on, we care more about the code and the way you think that if you went to a top notch college or had a lot of certifications (unless this is a requirement for the role).