TLDR: Why can’t interviewees just be given computers and write real code in a real (or example) codebase? This is my idea for how an interview could work and I want to get people’s opinions on why this isn’t done: - The interviewee is given a computer with a reasonably sized section of the team’s code base (in a language the interviewee knows, discussed beforehand), be it real or some mock, opened up in some editor that is recording just that window (the interviewee is told this). They are given this to look through on their own for 10 minutes or so. *The monitoring is to see what the interviewee looks at, gaining information on how they think, and to record the work in later steps.* - The first interviewer comes in (senior engineer) and tells them about the function of this section of the code base and asks the interviewee about it: do they understand it, at first glance what do they like or not like, etc. Then they ask about how the interviewee thinks they could make it better or how they could extend it. They work together on a deliverable for the interviewee to have done by the end of this interview loop, and the interviewee gets started. *We learn what the interviewee thinks about when it comes to programming, what they focus on and what they think is important. We learn their ability to voice their opinions, comminicate about and work together on making plams, and their ability to gauge how long it takes them to do something.* - After another 15 minutes or so, the second interviewer comes in (entry level engineer) and asks the interviewee to explain what it is that they are working on and then the two peer program for 15 minutes, with the interviewer offering any help they can. *You learn more about their ability to communicate in regards to the work they do. You learn their willingness to ask for help. You overall see how they interact with others.* - Another 10 minutes of just working then a third interviewer (mid-level engineer) comes in and tells them that the plans for what is needed have changed. Instead of extending it in X way, they decided we actually want it to be Y. They discuss this change, why it was made, and if the interviewee understands. *You learn how the interviewee responds to change. Have they written code that can be changed easily? Do they freak out with an impending deadline? Do they ask enough questions to truly understand the change? Are they willing to talk about their opinions on the change, seeing as how they worked to agree on the first iteration? Are they stubborn?* - Another 15ish minutes of coding and the first interviewer to let them know that time is up, then the two discuss how the process went for the interviewee, what they think/learned/would do differently. *You see their ability to be retrospective when it comes to their programming and their general attitude if they believe they have ‘succeeded’ or ‘failed’ because of the amount of work they’ve done.* Is there something about this process that im oversimplifying? To me this seems like a much more legitimate way to see how good of an engineer someone is and how well they’ll work on your team. Throughout the process they could search for things on the web (like we ALL do) keeping the focus on ‘how’ they work and the quality of the work they produce instead of how good they are at remembering leetcode problems and cs facts. After multiple interviews you have literal side by side code and recordings of processes you can use to compare interviewees. (In fact you could have another ‘interviewer’ who never sees, gets talked to about, or interacts with the interviewee at all. They just look at the final code changes or video and make a decision. This removes almost all biases except those surrounding coding style.) The only real extra difficulty is the creation of an example code base in a few languages, but you could use existing code or share some ‘example repos’ between your teams/org. #interviews #tech #future #leetcode
Lol trust me, there will be tons of people passing this and you'll need another way to weed out more people
It’s not a ‘pass/fail’ thing now though. I doubt the quality of code written and interaction will be equal, and if it is then make the codebase and the expected extension of it more complex.
I've done an interview similar in concept at BoA. They put you in an office for 4 hrs. They give you github, jira, and visual studio. The interview is to do a jira. The have a screen mirrorer and watch how you work... After you complete working the jira for two hours (I was only 60% done) they have a lot of discussions about why's and then finish up with a system design collaboration session. This style of interview shows a dev team how you work and communicate. It's really time consuming though...
fuck no there are so many things that can go wrong when doing things this way. ever had issues with an ide or corrupted build artifacts at work well too bad you fail if anything goes annoyingly wrong during the interview. what’s wrong with system design interviews? it’s not like you can game them.
Yes, I have had them happen at work, it’s real situation people will be faced with. If they sit there for an hour and do nothing because it broke that’s a bad sign. If they tell an interviewer, fine, either give them another computer or ask a system design question at that point.
It won’t scale. You cannot use real codebase because it’s the company’s IP and the interviewee is not yet an employee. Thus, to simulate the team’s real code, who is in charge of coming up with enough variety of “real code” to prevent blatant cheating? Some FANGs don’t set-up loops for any specific teams, so which team’s codebase are you going to simulate to be as close to the real code as possible? Next, the biggest assumption OP has made is that every single interviewer has great interpersonal skills, are both effective and engaging at collaborating with other engineers through peer-programming, and have enough emotional intelligence to ask the right set of probing behavioral questions to mine for technical competencies and team fit. I dare say that most of us don’t even have these levels of interactions with every single member of our own team. And if OP does find that dream team of interviewers, will this Fantastic-Four be relegated to be the only ones interviewing candidates? This approach could work for smaller companies or research institutions that hire sporadically. For FANG that have to interview too many candidates to fill their open positions, OP’s approach is a time sink and won’t scale.
This is fair. I agree this is the place it falls apart the most. If I was to propose a solution, it would be for every major organization in a FANG company to have a dedicated set of example repos and a dedicated set of reviewers that go through regular trainings, but I agree that isn’t really feasible at a large scale.
The code doesn't have to be company code, they can be created by interviewees... The first couple could be add features, then you can start doing debugging and adding features. It could be a clone of an open source code too. Your concern about interpersonal skills, how does white boarding solve that?
A simple leak and your interview question is gone
There is no ‘question’ there is simply an example repo which may be leaked, but the work / extension would be agreed upon at interview time.
The timing mentioned is not realistic (3 people cycle through in an hour?) but this is not so different from Stripe's interview process
Cars
Yesterday
1456
Why are Americans obsessed with SUV?
Software Engineering Career
Yesterday
3926
28 terrorist worshipping idiots just got themselves fired and I've never been prouder to work at Google.
2024 Tax
5h
867
Biden’s new tax proposal is wild
Layoffs
Yesterday
32747
Google CFO confirms "large-scale" layoffs today (Apr 17)
Health & Wellness
6h
3185
Why are women naked in gym?
Because it doesnt weed out enough people
Why not? I feel like there are Many mistakes people could make in this process. All of which are more valid than they forgot the name of some function or the exact implementation of merge sort.