When hiring developers, have the candidate read existing code

I like this approach.<p>Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what you where grilled on you won’t be working on “as that’s to hard” or “we don’t do that” despite being grilled on it and the level of skill not to great they just want senior people. It’s the bait and switch.<p>At least being taken through existing code you know what you are getting yourself in to. Also looking at the current open pull requests and closed pull requests to see the standard and speed of delivery. Bonus points for no PR’s and trunk driven development as that shows a very mature team.<p>My simpler interviews have often been with companies that have held a higher bar than the ones with tougher interviews. Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. My last company had a reputation for new starts disappearing and not great that way, but the team was probably the strongest bunch of people I’ve ever worked with as only do good survived.

This is exactly what I started doing at my company a few years back. You are presented with a complete app written in the stack we use. This app has some bugs we will solve to get it working (nothing that&#x27;s a trick... actual, commonly encountered bugs that have all the error messaging you need to solve them). Once it is working you will walk me through a particular flow of the app, explaining what is going on and why we do it this way. There are optimization opportunities (purely optional, there for you to notice), areas we can dig into if we choose (or if I feel the need to). If you tear through it we can examine a different flow in the app. Perhaps we could discuss the database structure and how it might be improved or changed, maybe we dig into some CSS or into some GraphQL or any other aspect that we need to. I&#x27;ve had people stumped and unable to continue but the vast majority of devs can make a good stab at it, even if they are not familiar with the specific stack. The best devs are barely slowed down by such unfamiliarity and can still reason, logically, about the code.<p>So far I&#x27;ve had really positive feedback from job candidates. A couple even described it as their favorite interview ever! I feel like it has worked well, given the people we have ended up hiring.

That&#x27;s interesting, I&#x27;ve never heard testing code skills by reading instead of writing.<p>An example would have been nice though, as I&#x27;m not sure how to find a piece of code that does something standalone that is too large to grasp in 20 minutes yet make a reasonable prediction at the output. That combination seems kind of weird.<p>I wonder how well it would work to modify OP&#x27;s idea and present a candidate with some code that has a bug in it (you reveal what the bug is to save time, they&#x27;ll need to understand the code anyhow) and you ask them how they&#x27;d fix it. First broadly, like what approach, then actually write part of it.<p>To take my own advice and make the discussion more concrete, I should add an example. Random script from my github: <a href="https:&#x2F;&#x2F;github.com&#x2F;lucb1e&#x2F;randomdirectory&#x2F;blob&#x2F;master&#x2F;randomdir.php#L7-L20" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lucb1e&#x2F;randomdirectory&#x2F;blob&#x2F;master&#x2F;random...</a><p>To prepare for the interview, one could add an argument like -h to show usage (in the same style as -v is currently implemented), then tell the candidate that the bug is that passing -vh executes neither -v nor -h (one would commonly expect it to execute both). Fixing this requires a &#x27;structural&#x27; change to this little bit of code, but it&#x27;s small enough to easily grasp and implement. The candidate might propose to loop over each character after a single hyphen to fix this, or they might propose to throw out this custom reinventing-the-wheel and use a proper arg parsing library. Either is fine, but they should be prepared to write the code (in any language, they can write just the changes in C, Python, JS, or whatever language they&#x27;re comfortable with).<p>Has anyone tried such an interview coding question?

When hiring developers, fetch a stoic subordinate who is A) good at eye contact and B) able to maintain said eye contact without blinking.<p>Have this subordinate and the candidate participate in a staring contest. This will show a couple of things about the candidate: A) How well they maintain eye contact (very important for communication) and B) How long it takes them to back down from a challenge; this taps into their primal instincts.

In my company we go one step further: We encourage the candidates to „bring their own code“. Then we let them explain their code, discuss possible issues, extensions and so on. Usually simply from looking at the code style one can infer a lot about the candidates level of skills. Also the candidates are less nervous and are sometimes really enthusiastic explaining their favorite side project. All in all it leads to a quite good interview experience for the candidate, but also for the interviewer.

I sometimes ask candidates &quot;what kind of interview do you feel would best bring out your strengths?&quot; and try to adapt the interview to their response if I can. It&#x27;s helpful if they want to talk about side projects or war stories, but doesn&#x27;t pressure them to. I still give my coding challenge after. Wonder why no one else does this.

I&#x27;ve interviewed maybe 500 engineers in my career. I&#x27;m an early engineer of Instacart, 3rd engineer of Eventbrite, founding engineer of Reforge. Started 3 companies myself.<p>My interview is always the same:<p>1. Bring code you&#x27;ve written 2. Share your screen 3. Explain what it does and I will casually ask questions about it<p>You get so much information from this:<p>- How they think about code - If they think it could be better - Who they blame if the code isn&#x27;t the best - Personality - Product dev glimpses - Comms - Sentiment

This makes a great deal of sense, to me.<p>But I am also the type of developer that would do well at this (experienced and older). Young folks, right out of school, or with just a couple of years of experience, would not do as well.<p>I’m pretty convinced that one of the goals of LeetCode tests is as a “young-pass filter.” It controls for people close to college age, where those types of problems are common, as well as people that are willing to work very hard, learning exercises that appear pointless.<p>Not sure that many companies, these days, are actually interested in older, more experienced, developers.

This is my standard practice - I give a real world data fix script that has been simplified to understand and comment on in 20 minutes. The interviewee is the code reviewer before it gets run in production. It covers things like performance, security, typical syntax mistakes, and working with sensitive data. The best part is actually not the script, but the stories it triggers about past challenges.

My thesis is that the true measure of reading code is still the ability to fix and extend it. So my current ideal interview problem is still a tiny toy codebase, where the interviewee is tasked with adding some (relatively trivial) feature to it. Like ten lines of code, but where those lines require you to have grokked the other couple hundred or so. Any downsides?

<i>Reading probes the most fundamental skills. Reading code is probably 95% of what a developer does as part of their job.</i><p>This is true. Most of the time I&#x27;m only reading my own code, and over the years I&#x27;ve been motivated to code better by having to go through crap I wrote early on.

To be honest as a developer I might have thought twice about certain roles had I seen their code base ahead of time!<p>Nothing cured my imposter syndrome (self taught, no degree) like walking into a startup and seeing PhDs fail to follow just about everything I&#x27;d ever learned was best practice and was doing without thinking in my own projects.

Except most commercial code bases are tangled rats nests and it would take a substantial effort to understand anything beyond the most basic details. My view of interviewing is it should require no special effort on the part of the engineer to demonstrate their skills. One simple way to do this is to have the engineer explain an open source project they&#x27;ve already built. Obviously this doesn&#x27;t work for people who have never created open source projects they would be comfortable sharing. But I think we need to be doing more to actually value people&#x27;s time.<p>My experience with many companies is they treat people as a &#x27;resource&#x27; that needs to be managed rather than a human BEAN. Companies, in the process of funneling around these resources, forget that there is an individual cost to these resources. And if your first introduction to a company is being dehumanized and treated like your time doesn&#x27;t matter: what are the chances that this company is a good place to work at? And that mans name. Albert Einstein.

I’m personally against this approach. I’m an appsec person. I absolutely do not know how to write most of the code I review. In my past two jobs I’ve been required to read code and explain it during interviews. I’ve never had trouble explaining what’s going on because on a very basic level, most languages use the same conventions.<p>If this were a heuristic of a good developer, it would let me (not a dev) in and who knows what the effects of that could be :).

I do almost the same but a bit differently. Like a lot of people have suggested here that they can&#x27;t share their company&#x27;s proprietary code (neither can I). So I have cooked up some sample questions asking people to code for a app involving REST and CRUD (because that&#x27;s resturant what we do at office). It&#x27;s not much work and can be done in 2-3 hours. Then I get down to discuss their answers and the &#x27;why&#x27; questions around their approach. Always gives me a pretty good insight on their work style and doesn&#x27;t give the candidates any opportunity to cheat (in these remote times) because eventually they would get caught whole explaining their code.<p>This approach has given me excellent candidates every single time and also led to a lot of time saved otherwise wasted.

Would really like to see one day a post about &#x27;when hiring developers, read their CV and have a technical discussion about their past work in relation to the role required&#x27; becoming a thing.

I&#x27;ve been doing this for a long time now. I present the candidate with a function (on paper) that compiles and runs. It does the job but it does everything poorly: an embedded connection string, leaves the connection open, no error handling, bad variable names, no comments, etc... EVERY candidate can find something wrong with this code and the things they pick up is informative. Juniors can find the easy stuff, more senior-level folks find the deeper flaws about the basic structure of the code like figuring that a lot of this is boilerplate that could be implemented elsewhere.

I&#x27;m struggling to think of code examples that would be concise enough to be usable in an interview setting, but that are complex enough to still discern their skillset to code.<p>If you introduce subtle issues in your code, you&#x27;re most likely just testing their familiarity with a framework or language nuance.<p>Big issues could work.<p>Perhaps just providing a take home codebase that&#x27;s 80% of the way there, and asking them to take it to where they think the remaining 20% should be is a good middle ground.

I always preferred this style of technical interview because it has two critical advantages over tests based on coding from scratch in an interview situation.<p>Firstly, you can work with realistic code. It can use your real tech stack and there can be enough code with a realistic structure to see how a candidate finds their way around.<p>Secondly, you can make it open-ended. For junior candidates it might be best to stick to simple questions like what does this short function print and see if they can reason through some basic logic. But for more experienced candidates it can be a general code review.<p>Your example code can include anything from superficial mistakes like typos and unnecessary duplication to strategic problems like inflexible designs or inconsistent models. You can include obvious or subtle logic errors and performance problems appropriate to the level of the role.<p>Ask each candidate to talk you through what they&#x27;re thinking about as they read the code and see what level they work on and how much they find in the time available. Are they methodical? Do they flag the trivial stuff but not get hung up on it? Do they spot the O(n^2) algorithm? Do they spot that algorithm but then start talking about worst case vs amortized performance and using a profiler to decide whether changing to a theoretically better but much more complicated algorithm would be justified?<p>In this kind of environment you can quickly tell if you have an awful or outstanding candidate. For the majority who fall in between you have an objective basis for comparing their performance. And all without any trick questions or LeetCode junk at all.

&gt;Nobody sketches code on a white board or notepad as part of their daily work.<p>Sometimes when I&#x27;m trying to plan something which requires a lot of thinking I take a piece of paper, write bits of code, draw schematics of the flow, schematics of data structures. If I am planning the architecture of an application which isn&#x27;t trivial, I like to go to the whiteboard and draw. Even if I have it in my mind, visualizing it helps me find improvements.

That&#x27;s a good approach if only because it shows how and how fast someone can build up a mental model of what a piece of code really does.<p>The problem is that the &#x27;existing code&#x27; may well be of poor quality and that in order to understand it you first have to get into what it was supposed to be doing in the first place, and this isn&#x27;t always obvious. So the writer had better take good care to make the code self explanatory or provide additional documentation to give sufficient context. In a way the underlying assumption is that the code is &#x27;good&#x27;.<p>And that&#x27;s where the real problem lies: lots of code isn&#x27;t all that good and plenty of it is probably best described as &#x27;single use&#x27;, in other words: write only. Trying to read it or trying to make sense of it is more effort than writing it ever was. And given the fact that code is typically read many more times than that it is written it pays off to write it well, but hardly anybody really does. The pressure to deliver the next commercial feature is just too high.<p>And woe to the interviewee that points out the deficiencies in the code if the author of the code happens to be the interviewer, because people will be people, so this could easily turn into a minefield.<p>Questions to ask of the interviewer before &#x27;reading&#x27; the code:<p>- who wrote it?<p>- is it functional?<p>- are you supposed to debug it or explain it?<p>- was it written for the express purpose of the interview or is it code from the company codebase that is representative of how they work there? (this alone might be reason to terminate the interview depending on how it looks :) ).

How do you avoid language familiarity bias? I&#x27;ve had one interview like this and am sure I did much worse just because the language was Javascript, which I have limited experience with.<p>Intuitively I&#x27;d expect that not to make much difference since most mainstream languages are pretty similar, and the interview wasn&#x27;t syntax oriented. But that&#x27;s not what I experienced. Signal to noise ratio was there and definitely affected speed of processing the code.<p>(To answer my own question, for coding interview style algorithmic questions, it should be easy for the company to translate the questions to the applicant&#x27;s preferred language before the interview. (if not then it&#x27;s probably not a good interview question). Hopefully this company does that.)<p>Obviously if the company explicitly wants the candidate to be familiar with deep aspects of whatever language you use, then this doesn&#x27;t matter. I can imagine hypothetical cases where this would hold, but I&#x27;d think it relatively rare.

I would probably think twice before accepting an offer if I had a peek in the codebase of some companies I worked on. From weird practices to complete useless tests and straight copies of other projects without any planing.<p>But for first step a Psychotechnical test on the candidate, and to be fair, the team and manager.

I still think Triplebyte gave me the best interview I&#x27;ve experienced, and I&#x27;ve done ~100 over the years at all kinds of companies. I&#x27;ve also interviewed people ~1000 times myself.<p>It was even more impressive because the person doing the interview wasn&#x27;t super competent and yet they still managed to do a fairly comprehensive technical evaluation in ~2 hours.<p>One section was a debugging session where you had to get tests to pass. The code and tests were quite decent, which made it quite easy to show off. Every company should do this.<p>Too bad the Triplebyte promise (not having to do phone screens) was a joke and their business model wasn&#x27;t good, but that part of Triplebyte had major promise.

This is a clever idea. First, every team has tons of code that a new-hire would see on day one. Might as well see how they perform! Second, this truly is an important skill. I&#x27;ve read hundreds of libraries, if not thousands, and being able to accept not just a coding style, but a thought style, and internalize it is <i>essential</i>. Yeah, the more I think about this, the more I wish I had thought of it when I was hiring!<p>I&#x27;m kinda jealous, I&#x27;d love to do code interviews again, but I haven&#x27;t been a junior dev in ... &#x2F;* checks notes <i>&#x2F; ... over three decades?!? </i>cries in yaml*

There&#x27;s only 1 real answer to hiring.<p>Make sure the candidate&#x27;s personality is a good fit for the team, have them do a fair coding question, and then hire them quickly. Give them 3 months to become productive and if not, fire them quickly and give a 3 month severance package.<p>You can probably analyze the data and figure out which of the employees are good at spotting good candidates and lean on them to make the decisions, but overall fast-hire-fast-fire is the best for everyone, except for fake candidates.<p>This also gives you the opportunity to take chances on borderline candidates or candidates with less experience.

I am a solo non-technical founder who hired and fired around 10 developers on a freelancer platform before finding the gem of a developer who single handedly completed the platform. Unfortunately, after a year he has left and now I&#x27;m struggling to find a replacement. The web app is still running fine, but further development is stalled. I&#x27;m wary of giving access to the entire codebase to the would be new hire. And I being a non technical person, have no idea how to give only partial access to my developer. Just rambling after reading the title. Sorry!

This would be great because if the code stinks to high heaven then I won&#x27;t work there. When they think I&#x27;m not a fit for not understanding their code, the feeling would be mutual.

Of course, if a developer comes with experience and personal references from acquaintances, you don&#x27;t need to test their abilities at all during the interview process.<p>For example, I hired a backend developer last month. She already had the job because she came highly recommended from a trusted friend of mine, but she didn&#x27;t know that. Here&#x27;s how the interview went down:<p>Me: I see on your resume that you&#x27;ve achieved Grand Master level in Microsoft Solitaire Collection.<p>Her: Yes.<p>Me: Well, we won&#x27;t waste any more time then. Welcome to the team.

These kinds of articles always seem to get a lot of comments, and so many hiring processes seem to miss the mark.<p>If the criteria that you use for engineering hires has nearly 0 overlap with the criteria that you use for engineering promotions, then I&#x27;d assert that your company is suffering from some serious cognitive dissonance.<p>This article describes a hiring process that is probably a lot more useful than what I&#x27;ve typically witnessed at the FAANG&#x27;s, provided the results can be quantified.

This is my preferred option also but I love reading the comments when these sorts of posts appear as it seems that interviewing is still something that causes loads of debate and no matter whether the op is whiteboard, tricky algorithm or &lt;other&gt; focussed, there’s still a hot debate. Interviewing just seems broken<p>It must surely boil down to the profession aspect. Doctors and lawyers do a period of internship after and during the degree that perhaps mitigates the uncertainty around hiring. I doubt that doctors are asked to bring in a cadaver to operate on during an interview for a new position, or lawyers are asked to jump into court unprepared and defend someone as part of the hiring practice.<p>It sometimes seems that programming jobs need to be a calling. Ie: you spend 50 hours a week at job doing the thing but then are also asked to have a portfolio on the side that you presumably do in your spare time.<p>It could just be an American thing, though. Perhaps hiring is seen as very risky because sv salaries are so out of proportion to the standard across the rest of the working environment, in addition to there being very little quality control regarding professionalism in the industry that makes technical hiring such a minefield.

Makes sense to me in general. We all spend much more time reading our own code and others&#x27;, much more than writing code. In fact, first period a new hire is going to experience is spending a disproportionate amount of time, just getting to know the system(s) they&#x27;re expected to contribute to.<p>I&#x27;m currently looking for someone to join our own team, I&#x27;ll be taking this adjusted priority in mind.

When I did interviews @ Google (I only do hiring committee work now, thank god :-) I usually asked questions around bugs I added to an existing codebase, to see if the candidate can avoid the pitfalls I ran into by making bad assumptions.<p>As I&#x27;m a pure C coder, my starter question was usually something like:<p>a). What does malloc(0) return ? b). Why does it do that ?

I have found a lot of value from putting up real code from our code base (maybe simplified with some parts removed) and asking the candidate to explain what a function does. It’s very fair, low stress, and you can ask open-ended questions about “why this way?” or “what are some other ways to do this?”

Good article, terrible advice at the end. I agree 100%, seems like a way better interview approach, but the last sentence is just not applicable to everybody. I enjoy doing side projects, but should not be a requirement and you can be a great developer without even having a public project on GitHub.

I liked the article and kudos to reaching top of hacker news.Your article however does not consider real world problems like - What if this technique becomes popular and now there is LeetCode db for your question? In that case its really easy to just know the answer and get far. - Same for reading the code part. Most interviewers have a set of questions they go with to be fair or what not however once you know the code snippet in question you can talk about it.<p>The real issue is that one approach does not work for all and there need to be uniqueness to every team so an avg candidate cannot just hack the interview process. This is the problem with the current system as well since everyone uses it and its become its own nemesis.

We had a mix of code written by brilliant people who knew how to maximize cache coherence in template metaprogramming hacks... and interns who generated more compiler warnings than anything else.<p>Over the years, I found some truly awful code, in our cash cow application.<p>So I turned those into the smallest representations of what was bad, and showed those to candidates.<p>I was trying to assess, &quot;How much will I need to mentor this person, and how hard will that be?&quot;<p>I may have given bad reviews to people who deserved better, but I honestly think I never once gave a good review to someone who deserved a bad one. A few times, the company went against my suggestions, and each time, the candidate wrote some terrible, buggy code that I later had to untangle and fix.

&gt;So instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works.<p>While reading and understanding code written by others is an important skill, I am not sure it would be totally fair in an interview. The candidate might not be familiar with the particular coding style. The code can be very easy to read or very cryptic. I can write easy to read code, cryptic code or anywhere in between.<p>So since reading code doesn&#x27;t solely depend on the candidate &#x27;s skills, basing hiring decisions solely on it, might not be the best idea.<p>I would see no harm, though, if part of the interview consists in testing the comprehension of well written code.

Yeah I had an interview like this recently. First part of the interview proceeded well as they asked me to read different bits of code and how different language features worked.<p>Then I was asked a brain teaser that I bombed. And that was the end of the interview.

This article would be much more interesting if they shared the code. They imply they use a new set of question every cycle so it should be safe and easy to share the examples used in a past cycle.

I saw that back in the nineties: my employee had an interviewing task where you had to look at a c++ listing with obvious errors, the task was to find the errors, like memory leaks, buffer overruns, use of stack allocated memory, etc. Actually few candidates would pass this test...<p>I don&#x27;t think they will do this: the interviewing process at most places seems to emulate that of the industry leader, nowadays that&#x27;s google, correct me if I am wrong.

It&#x27;s kind of funny hearing both potential employers and employees coming up with &quot;concise&quot; or good enough code example. I think this exactly the beauty of this approach. If you don&#x27;t talk about some simple sorting Algo code is always full of tradeoffs. Talking about these tradeoffs how your potential hire thinks about them if they even see them. This is the real value of this approach I think.

Those are similar to my own thoughts. I like also having them talk about their favorite recent achievements.<p>&gt; I can quickly train a person to have knowledge in some domain,<p>This part I have a little bit of trouble with. If you have a trivial domain, sure. In my experience domain knowledge takes a while to truly get your head wrapped around. But I expect that&#x27;s why there&#x27;s always other things that people do in an interview.

I like this idea. My first job out of university, this was actually what they did.<p>Though many companies don’t care if you’re familiar with the specific language they use, because they assume a decent developer can pick up a new language, and if someone weren’t familiar with that specific language it maybe could put them at a disadvantage. Or maybe that would actually be a good test of their skills??

We ask candidates to review and criticise 2 pages of really buggy, badly written C++ code. It is a great way to find out how experienced a C++ developer is and how good they will be solving hard problems. Writing new code is easy. Fixing problem in code written by other developers is much more of a challenge.

But wait, how is this fair to the millions of software engineers that can only pass interviews by memorizing the question? Isn&#x27;t that the whole point? To gatekeep people with other learning styles and fast track people who arguably cheated on tests throughout school?

I would like this. I&#x27;m a lowly front-ender with some engineering chops working towards a full-stack&#x2F;backend role, and this would help me convey my knowledge better than getting brain freeze when trying to remember syntax in a language I might not be great in.

Shoot, just ask them bout their own FOSS changes.<p>&quot;Why&#x27;d you design it that way?&quot;<p>&quot;Why&#x27;d you implement it that way?&quot;<p>&quot;What alternatives did you consider?&quot;<p>Interviewers be so lazy in 2022 though. &#x27;uh um do a fizzbuzz in ten seconds no your solution not match my first mental solution bye&#x27;

At first reading, I thought this would be horrible<p>but then I realised it would tell me as an interviewee how good&#x2F;bad the code is before I join.<p>If there are no comments, loads of &quot;clever&quot; optimisations lots of &quot;syntactic sugar&quot; it would be a good time to GTFO.

Sounds legit. Also gives me a look at the real day-to-day that I can expect. No contrived code, just real production code at the company, please. That way I can avoid the great waste of life that is: thousand line functions without tests.

Sounds great for testing the candidate but at the same time it sounds like the best way to get the candidate to look for another job.<p>I still haven&#x27;t found a company larger than a few employees with a codebase that didn&#x27;t make me want to leave.

I do a variant of this in my interviews. <i>I</i> write code from scratch and talk about the statement and ask questions based on the code before asking them to make modifications to it and talk me through their thinking.

This does not just work for companies: The University of Cambridge (England) asks for candidate-written code as part of the application package for its Master&#x27;s program in advanced computing (MPhil).

This is brilliant. Thank you for sharing that. I have always thought that writing code in front of somebody else was not indicative of skills. This is showing a very good and simple alternative.

Related to this, is solving programming-trivia on white-board with a clock ticking and someone watching over your shoulder still a thing?<p>I think that&#x27;s leaning to interrogation, and less of interviewing.

&gt; When hiring developers, have the candidate read existing code<p>Are they intentionally trying to scare devs away?! (Some of the code bases that I&#x27;ve seen have been pretty bad)

Problem is, reading is at least an order of magnitude easier than writing.<p>In terms of natural languages, if you can read and mostly understand a text in another language, let&#x27;s say you score 8&#x2F;10. At the same time it is completely reasonable to expect that you would not be able to write the same text, and if you had to, it would be at 5&#x2F;10. Then if you had to do it in a speech, you would score a measly 3&#x2F;10.<p>I&#x27;m not saying that focusing on reading and analyzing code is a bad idea, just be careful, and expect these differences in skill levels. Definitely a hundred times better than leetcode though.

I hope it&#x27;s actually to an ide. They do so much to make code easier to read, like showing the code highlighting, function docs, and links to the source

This is a great idea! I would love to see some real examples, what can people think of that would work for this?

Why don&#x27;t companies just have prospective candidates work for 2-4 weeks on the actual job unpaid and then select 1-2 candidates from that pool based on performance?<p>Most job seekers are working for free when applying for jobs anyway and it seems like this would have the nice benefit of providing a free rotating labor force for the hiring companies. It might even allow them to do without a couple of paid positions long-term.

Very glad to see takes like this becoming more popular. This is how it was done when I started out.

There is no baseline to measure against candidates as opposed to competitive programming problems

in my ignorance i wondered.. perhaps it is possible to have some automation compare methods used in the employers software with ones used by the dev in their public repos?<p>Imagine how interesting a job offer would be if they can prove you will get to do things you know well.

In the past, I&#x27;ve taken existing code that needed a good refactor, checked the unit tests gave a good working&#x2F;not working signal (i.e., deterministic pass&#x2F;fail), set up the candidate&#x27;s preferred IDE&#x2F;editor, and asked them to refactor it to be better, according to their definition of better.<p>Then we talked about the things they did and why that was better.<p>Probably the best &quot;coding exercise&quot; I&#x27;ve ever done in terms of getting to understand how someone approaches a typical code base.<p>But sometimes candidates were very unsure about how to approach it, they found it hard to proceed without knowing exactly what &quot;better&quot; was.<p>I stopped using this, as I realised that my approach was unconsciously selecting for a certain type of person, one who resembled myself and it excluded people who could be amazing devs within clear parameters.<p>TL;DR interviewing is hard to get right, this reading idea is a good one.

Even better: read the code, understand it and then change it.

I really like this.

Nah lets give them leetcode instead!

You could ask them to show you their favorite personal projects. Have a conversation about that. Seems most natural and revealing.

This - this is important!

No. Only leet.

My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what&#x27;s said, but also follow up on what is not said.<p>Here’s a real-life example. I asked a recent applicant (for a fullstack software job, where we were hoping to hire a novice-to-mid-level engineer):<p>Me: How would you improve a situation where a page is loading slowly and you suspect the problem is related to the database?<p>Applicant: Well, I’d start by checking the HTML, is it correctly done, and then the CSS, is there any redundancy? And then the Javascript, is it correctly written, is it minified? Can we speed that up at all? Check the timeline, the API calls, see what is slow.<p>Me: Okay, great, that’s a good start, but what else? If the problem is not on the frontend, then what?<p>Applicant: Uh, well, then, I guess I need to look at the backend database model code. Is my database model code concise? Am I fetching the data needed, without any excess?<p>Me: Okay, great, that’s a good start, but what else?<p>Applicant: Uh, what else? Well, uh, we really need to look at that database code. Is the model bloated? Can we slim it down?<p>Me: Yes, okay, you basically said that already, anything else?<p>Applicant: Uh, well … uh, you need to check the HTML and the CSS and the Javascript and then, uh … API calls … uh ... the model code, make sure that is cleaned up. That needs to be lean.<p>Me: Yes, okay, but you said all of that already, anything else?<p>Applicant: Uh … well … the model code … and uh …<p>Me: Have you ever worked directly with a database?<p>Applicant: Uh … not much?<p>Me: If you get unexpected results from your model code, do you know how to debug the query?<p>Applicant: Uh … I guess I could … not really.<p>Me: Have you ever looked at the “slow query” log?<p>Applicant: Uh … no?<p>Me: Do you know how to run EXPLAIN or ANALYSIS?<p>Applicant: Well … uh …. no.<p>Me: Have you ever written SQL by hand?<p>Applicant: Uh … no.<p>Me: Are you aware of any differences in dialect between the SQL of MySQL and the SQL of PostGres?<p>Applicant: Uh … no.<p>Basically, they were somewhere between a novice level and a mid-level engineer, so they knew the frontend reasonably well, but they didn’t know a thing about databases. Which was okay, because that was what we were looking for. We still hired them and they turned out to be great in some areas, and they were eager to learn about the things they didn&#x27;t already know. But obviously, if I&#x27;d been hiring a senior-level engineer, and it turned out they knew nothing about databases, that would have been a problem. The crucial thing is that I kept asking the question, over and over again, until I had the full answer. In this case it was easy, but sometimes it can feel aggressive, asking the same question over and over, which can leave either you or them feeling uncomfortable. But you will never be any good at interviewing people until you learn how to tolerate uncomfortable moments. The goal is to find out if you want to hire someone, without wasting their time or yours. And asking questions like this, directly, and digging deep, is a much faster method than handing out homework assignments and then waiting a few days for them to complete it, then reviewing it yourself, then discussing it with them. And such direct, factual questions, as above, are at least as objective and as any “objective” test that you might invent.

Please comment your code, when it is is necessary.<p>I don&#x27;t need &quot;we need to loop here from 1 to 50&quot;, I need &quot;we have to rate-limit this function to under 60 transactions per second due to hardware requirements&quot;, etc.<p>If you are putting &quot;magic numbers&quot; anywhere, COMMENT it as to what that number is, why you chose it, etc.<p>I&#x27;m 30 years into this game and I still come across code that takes <i>way too long</i> to reason about.

Really like how this makes the interview simulate day-to-day work

I think we should just jump to the end game and make interviewees do ultra man triathlons while solving differential equations. Then at the finish line, they knife fight each other to find the one we let go to the next stage in the interview. That way we can be sure who has stamina and the best competitive programming problem solving skills.<p>Something like squid game will truely find the A players. I mean, we wouldn’t want a bad hire after all, and everyone lies on their CV.<p>(Obviously &#x2F;s)

&gt; because reading is easily an order of magnitude faster than writing.<p>Hmmmm, really?