Assume people are smart, tell them about the actual job & and it’s responsibilities, tell them about the challenges of the job, ask them if it actually sounds like an interesting position, and then test them a bit on relevant things to see if they sounds reasonably competent.
Absolutely preposterous. Are you suggesting we interview folks for the job at hand?
Sarcasm aside, I’ve started interviewing people with “mock work day” style materials and it’s been pretty effective at determine who has been doing this for a decade, who can do this with a couple months to ramp up, and who is entirely faking it.
I’ll have folks combing through mock stacktraces, creating a new endpoint, connecting to a local database, and even doing a little bit of multithreaded design. I’ll assess completion against quality of the solution and factor in how long it takes someone to complete it.
That’s a difficult determination to make, but usually that’s the difference between someone who can walk me through the solution and stumble on the implementation, and someone who can’t explain to me what’s going on.
Lots of this stuff is language agnostic, so I keep that in mind too. For example, a stacktrace is a stacktrace in any language. However, we usually don’t extend offers to folks doing things for the first time, as we need a quick ramp up.
We generally don’t find it too big an ask for engineers to be familiar with the basics of Spring, or can SSH into and debug remote boxes. If someone doesn’t know this, they’re generally a college grad. Otherwise, unfortunately, it’s not the talent we’re looking for.
Evaluate people on past projects. If you have a project, show the code and walk through the code in a screen sharing session. Only show code that is non-confidential.
If you do not have code, then first create a small project. That can be done in a week or two. This requires less time than grinding leetcode.
Some people will say: but you need to be able to solve a problem in under a few minutes. That is utter bullshit. We all know that development doesn't work that way in reality.
>Evaluate people on past projects. If you have a project, show the code and walk through the code in a screen sharing session. Only show code that is non-confidential.
Lots of bullshitters out there will find some code they don't own, study it and become well-versed in how it works, and fake their way through.
>If you do not have code, then first create a small project. That can be done in a week or two. This requires less time than grinding leetcode.
Do you mean one of those "interview projects"? Lots of people, especially on HN, would balk at this as "blah blah don't do free work". Those same people will then go back to your first point and say "just evaluate people on their experience.
"The best" may spend their "spare" time raising children, doing volunteer work, or simply unwinding - just because you didn't sell that time to an employer doesn't mean there aren't demands on it, or that you're obligated to spend every waking moment engaging in some form of labor. Having personal time to devote to programming isn't a function of job performance, it's a function of your particular life circumstances.
And if you created a huge incentive to fabricate personal projects, a cottage industry of people who will create something cool on your GitHub in a way that looks authentic would spring up, and you'd be prioritizing people with the wealth and inclination to cheat over other candidates.
grinding leetcode to prep for interviews takes a lot more time. how can you have a CS degree and a career and have no personal projects? i graduated in CS with 4 programming projects done.
all the arguments you give are the same for leetcode prep. the difference is that if it is your own code that you walk through you need to prep a lot less. and that is good because in your situation you would not be able to grind hundreds of irrelevant problems in your spare time for each interview.
as far as your cottage industry argument… you can tell if someone did not write his own code and the system is being gamed right now anyway by people taking interviews for others and so on. and this thread shows people are medicating which is the worst.
> how can you have a CS degree and a career and have no personal projects?
Other people's lives differ from yours in ways that are difficult to imagine. Plenty of people have a career in programming without ever going to college. Just because one can't imagine it doesn't make it invalid, or even that it is one's business. If it isn't about their job performance, don't measure it.
> all the arguments you give are the same for leetcode prep.
An interesting point, but of course I wasn't defending leetcode interviews, I was responding to your assertion that people who have the requisite skills necessarily have free time, and the subtext that any time not spent working was available for more working.
The technical interview for my current job was phenomenal.
It was a leetcode style interview (maybe it was through hackerrank? I dont remember), but it was just writing code to hit a JSON-based HTTP API and collect the results into a list. I was encouraged to google things, and explain what I was thinking about in relation to the task.
The task was trivial if you've done it before, but probably not easy if you didn't know how to write code. While doing that task, I was able to expand on my knowledge by talking about what my code was doing.
It was in python, and I was doing it recursively (because that's what I like), so I was talking about how performance optimizations would be to make it iterative instead, if needed. I got into explaining this was because python doesn't have TCO recursion, so it just blows up the call stack if it's too large.
The interviewers were chatty, and were happy to banter and in general be cordial during the interview as well, which I really liked.
At the end of it, I felt really good about the interview and was confident that I had "passed".
Don't treat programming as performance art. Some are great performers, but many are not. Don't force them to do something that's unnatural like code on a whiteboard. A whiteboard is not an interactive medium. A computer is. It's OK to riff on a computer the way you do on guitar. I know few that get it right the first time. Everybody thinks its all orchestration but Joe Beda points out the improvisation going back at least five years. He wasn't the first and likely won't be the last.
You may see Donald Knuth once in a career. It's rare. Don't expect it from everyone.
As an interviewee I use badly copied FAANG style as a red flag. Most will cargo cult interview styles copying what they've seen without thinking much about it. I've seen people memorize and pass interviews because Gayle Laakman McDowell's book was so overused. Do we really believe memorizing the book is better than not testing everyone exactly the same? I don't.
As a person who's sat on both sides of the table, I'm a huge believer in technical conversations, but I believe that's very different than code. To me, programming is not a performance art.
I recommend a few things:
1. Ask for sample code, preferably with git history showing that the author did most of the work or it was pairs or something like that. Ask lots of code review questions: why, how, alternatives, etc. Public github repos are fine. Private git repos are fine too. It's the history that tells the story both in terms of code frequency, velocity, revisions, tests, style, etc.
2. Use a pull request style in which the interviewee is the reviewer: what's wrong with this code? How should it improve? Is it good enough for MVP? What about production? Good opportunity to test whether they can speak truth to power when you show them rubbish that is patently wrong. I always hated reviewing bosses code when I had to march into their office and tell them they needed to fix their broken class inheritance or whatever. Interview is a good time to test for assertiveness.
3. Use pairs style where the interviewer is the keyboard/mouse driver and the interviewee is the navigator/commenter keeping the driver on track.
4. Ask them to bring their own hw/sw stack. Examine the choices and reach your own conclusions asking questions about why/how they arrive at their stack when no one is guiding the choices but them or their influencers. They don't really need to do much, more than a show/tell, explaining choices and why/how. To me, this is really interesting philosophically, particularly if it gets into stuff like *nix that are not the typical ubuntu, fedora, etc. and go off into arch derivatives or left field in a telling, R&D way such as shell, package managers, tmux, language, lint, tests, and so on.
