How not to hire a software engineer | Hacker News Reader

How not to hire a software engineer

tonsky.me

329 pointskiyanwang230 comments

I look to see if I can trust them to not do dumb things. That's really it.

What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all).

Do you see what's not there? Programming language competency. Database knowledge. Things like that.

I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had never seen a mainframe. I was told about 20 years ago to write a program in perl, my boss gave me a perl book with the assignment because I didn't know perl and I did it.

This is not a bad way to go about work. Every codebase is new. Every job has a steep learning curve. Every requirement is a conversation which may only be internal, but has to always happen. Every programmer you work with is someone whose preferences, strengths, styles, and weaknesses you need to have intuition on. People good at those things are what make good programmers.

That's why general competency, ability to learn, not to create a mess and not to waste time on stupid things are the only things I care about. That's really it.

Preexisting technical skills aren't as important as how dynamically you can apply new ones.

I interview quite a lot, and one of the things I try to do in an interview is work through a problem that I almost certainly understand more deeply than any of the candidates (both because it's my niche and because I've worked through the exact problem with hundreds of candidates before). There's a certain minimum bar that I expect any educated and intelligent individual to achieve if they're a good match for the job, but then I take it really far beyond what I actually expect them to know, to the point where a lot of the details are unknown, and the details matter a lot in determining what kinds of solutions will be successful. Do they start BS'ing me? Do they confidently walk into really nasty parts of the problem without recognizing the pitfalls? Or do they tell me they're a little stuck? Do they ask which trade-offs to make? Do they ask if they can do some Googling for prior research on the problem? Do they explain what they would try and what pitfalls they would watch our for, or how they would validate their idea? Do they ask if they can make some simplifying assumptions for practical purposes? There's a lot of right and wrong answers but really I want to see their attitude and communication.

My first couple of hires before I did this were a brilliant computer scientist and a guy with a business degree and some coding background. I was surprised to see the guy with the business degree excel because we weren't doing many CS-hard problems, and an ability to manage time, talk about the problem, and navigate the project life cycle were far more important than classic algorithm knowledge. He needed to know how to code and debug, for sure, but like most software jobs, his soft skills were a force multiplier.

I'm pretty sure this has been done with me - I was given a problem and told to come up with something like an O(n log n) solution, and I honestly couldn't do it. I tried a few different approaches but I could think of really bad pathological cases for all of them. The interviewer gave me a few suggestions which I explored and I kept exploring them and then admitted I didn't see a way forward. I thought I was bombing and then he told me I did really well. I looked up the problem and found out he had done Ph.D. research in that area, and there was no general O(n log n) solution - only solutions that could do that in most practical cases.

I would think that anyone hiring a Ph.D. in Computer Science would be looking for a different kind of output than the knowledge of actually doing software development and the associated project management/time management work. I would imagine that such people, if placed optimally, would be doing largely self-directed work with an expectation of solving a very complicated problem, with work output that looked more like a thesis than a program.

I further surmise that very few companies need these kinds of people. If your needs are people that can be managed to do basic programming tasks (my job as well), then that's what you hire. That's something like 99% of all programming work.

It's like hiring someone that understands the building of nuclear power plants, and being surprised that they don't understand basic home building codes.

The saddest part of it, for me, though, is that someone with a Ph.D. in Computer Science that is searching for a job in the non-research sector is probably having a really bad time. Research is happening, but I don't think it will jump in a very large way until there are a lot more dollars being pumped into research using public money.

Just to be clear, I neither have Ph.D. in CS myself nor am I looking for that in candidates. I agree with everything you say.

I think that would be kinder to the applicants if you told them that there were going to be things you didn't expect them to know required for a good solution and you didn't necessarily expect a good solution but were interested in how they approached it. You'd still be able to tell nearly as much by what questions they asked, and it would be less testing for "How well do they do under unrealistic/unrepresentatives kinds of pressure and in guessing what the boss actually wants when he isn't being honest about it."

One of the most unrealistic parts about a code interview is just how high-pressure it is, time sensitive in unrealistic ways, way more impact on your career than usual 5 minutes of coding, no peers to ask questions to, unclear if asking to google will be seen as a negative or not, etc. I think trying to reduce some of these unrealistic pressures, by being clear about what you're expecting (and being in this case up front that you _have_ intentionally given them something out of their domain knowledge) can probably give you a better evaluations. Some people do better under that kind of pressure than others, but if that kind of pressure is not actually representative of the actual job, it may not be what you want to be testing for.

Also set expectations for transparency and kindness (instead of bullshitting or preening) by modelling it yourself, right from the start.

I generally do tell them it's a complex problem and I'm looking more for how they approach it than any specific solution. I don't tell them everything I'm looking for because then they'll just pretend to be the way I want them to be. But I disagree that it's unrealistic. I've had far too many employees and coworkers who don't understand what is being asked of them or don't know what they're doing, and try to fake it as long as they can. And if I tell them they need to tell me if there's a problem, they almost always haven't until the pattern continues and becomes a worse problem. If the way they deal with pressure in an interview is to bullshit me, I need to know that long before they're under pressure at work.

I like this idea because it allows me to figure out if they have one of the most important skills: being able to say "I don't know" without wasting a lot of time.

IMO anyone else saying you should tell them the solutions might not have answers are dancing around needing to have that skill.

I guess if an applicant has done enough research/prep for technical coding interviews, they probably will come prepared realizing that not all questions may have answers or may be able to be answered without context they aren't expected to have.

I know I will after this discussion!

I know I would also get very thrown by a question without an answer if I wasn't expecting it, in a way I don't think I would be on the job. (On the job I know too well through experience that not all problems have good solutions, but in an interview question I maybe would have assumed there was an answer they expected me to get, before this exchange).

Of course, the end goal of interviewing for an employer is maximizing their chance of filling position with good people, which involves balancing false negatives and false positives -- and in fact a "false positive" (wrong hire) is probably _worse_ than a "false negative" (turning down someone that would have been great). So... filtering out some candidate that might have been good may be a neccessary sacrifice, not a flaw in the process, so long as you're doing even better at successfully filtering out those that wouldn't work out. Whatever works!

If I felt someone was intentionally giving me a "trick question" in an interview, I might conclude they weren't someone I wanted to work for anyway, so everybody wins I guess.

It doesn't even have to be a question for which there is no answer. IMO it works best with progressive questions where you can start with something straightforward that just validates basic knowledge they should have, and progresses to get increasingly difficult.

I used to ask about the layers in the network stack, and how you might troubleshoot it. I start with something as simple as a firewall blocking a port, or the server not listening on the port you expect. If they do that, great. Anyone who's had to troubleshoot distributed systems should have checked that stuff plenty. Then we try a protocol they might not have used. Most developers have a rough idea of UDP vs TCP, but they might be confidently wrong about some details or try to make stuff up and say "I'm pretty sure...". We go down a layer and try some scenarios where routing is messed up. I don't expect most devs to know about that, maybe someone with more sysadmin experience, but by now it's painfully obvious if they don't know what they're talking about. It happens to be pretty handy on my team, but if at this point someone says, "you know I really don't know a lot about networking", great! I'm glad you told me. Let's skip talking about voltage fluctuations in Cat5 cables and get back to software development.

Another good one is designing a data structure where there's a lot of different access patterns you might optimize for. Gives them a chance to demonstrate some simple coding and CS skills before it gets complex, but then there's lots of room to talk about the use cases. Once you're talking about use cases, are they willing to ask about the trade-offs? Priorities of various use-cases? etc.

Then problem is that getting to "I don't know" can take a LONG time for someone who's actually a good fit. A generalist (jack of all trades, willing to become a master in some that are used often in a local time domain) might actually know a lot of that information.

A good way of approaching this might be to provide problem feedback during the mock, stating that there's a given problem reported with the results or some other plausible complication and seeing how things go from there.

Also, the not knowing thing. I've hit that a few times myself, however I'll generally exhaust every reasonable option I have to look-up or reverse engineer the solution on my own first. Google / duckduckgo, stack-overflow, asking some other tech friends if they've encountered similar things before; if I worked somewhere with other technical users that I expect might have seen this they'd be just before the out of company friends on that list.

By the time I get to something I don't know, and can't find out on my own, it's actually a DIFFICULT or VERY domain specific problem. Generally then I go for adding diagnostic prints or using a debugger to trace the problem and find out where things are going wrong so I at least can narrow down causes/solutions. Even then, it's still taking a __LOT__ to get to I don't know.

Getting to an absolute "I don't know" does indeed take too long, but doesn't really do much for me as an interviewer anyway. My goal in these questions is to get to "I don't know, but I think... and I would verify by...", "I don't know, but one could try..." or "I don't know but I would Google for..." are all excellent places to end up. You're not BS'ing me, but you're not stumped either. You know sensible next steps. We all have to look stuff up regularly or test the unknown.

Can be a problem trying to out-generalist a generalist, but if you pick something in your niche (I ask them lots of other questions relating to their background, so this question doesn't have to cover the exact job requirements) and practice the problem with dozens of interviewers, it'll be pretty hard to have someone who can genuinely out-think you in the depth of that problem. And missing out on the "I don't know" is a small price to pay to find a candidate that does that well on the problem!

If I smell any bs then I immediately change tactics and make sure I put them deep over their head. For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?"

There's 3 ways to answer these kinds of questions and it exposes you as either a genius (or in this case a linguist), a non-genius (real geniuses are as common as 7.5 ft tall people) or a bullshitter trying to look like a genius.*

I've never met an actual genius in an interview so let me address the other two. That third group is a nonstarter. I've known the person for 10 minutes and they're already trying to deceive me. How the hell am I going to build a product with them?

Kim Scott, some SV big wig wrote an entire book on this called Radical Candor. Essentially it's "don't bullshit people (and know where your taking the relationship when you use that rule)"

I strongly believe companies work best with the smallest bullshit quotient possible. They may sell more or be more profitable with certain flavors of bullshit, but things are easier and more stuff gets done without it.

At the end I would have rather actually made something than duped people with sham products sold on dreams

---

* I actually can't answer that question but I could probably identify the neighborhood of a real answer (...something something limitations of the von nuemann model restricting the constructions of parsing systems something something...). The point isn't to answer it, although that would be quite impressive; it's to see how far someone digs into their own BS.

For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?"

What's the point of grandstanding like this? To make yourself feel smarter than they are?

My way of dealing with bullshitters (who in general are surprisingly eager to reveal themselves as such -- there's no need to lay special traps for them) is simply to say "Hmm - okay" and politely end the interview at the nearest reasonable opportunity.

It's a 1-on-1 interview (not in front of others). Ultimately the point is to help the person.

When interviewing and I didn't get a job I always desperately wanted to know how to improve things next time and nobody would tell me. Instead there was this little canned BS email from HR "after much consideration blah blah blah" stop that ... tell why!

This goes one step beyond telling. Show people why. Show them what they are doing, when they are doing it, how you can see it, why it's bad, why it hurts them and help them not do it in the future.

Give them an offer to correct it after you've made it clear (this is like throwing an exception in programming versus silent failure). Reset the clock and try again if you want. Maybe they're actually great and you read them wrong (they might be a "good program" with your bad input). The interviewer isn't some flawless executioner.

Most interviewers don't act like characters out of an Ayn Rand book. At the end of the day they care about others and know they have bills to pay. Doing this shows "this is why this job can't happen". Try to be their best interview for a job they didn't get.

The candidate doesn't walk out the door with ambiguity or false pretense or the illusion of doing well. Nor do the decisions come across as arbitrary and indiscriminate. They know exactly what action they need to take for their next opportunity.

If they don't get the job on offer, the best you can do for them is help make sure they can get the next one.

Fair enough - thanks for clarifying.

I'm curious about the question here if anyone wants to chime in (this is just an area in CS that I'm interested in but don't have exhaustive knowledge of or anything).

> what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?

Are there alternative classification schemes for grammars? I haven't come across any personally—not for formal languages anyway.

Or was something else meant by the question?

For Chomsky, I would hazard finite state automata, BNF systems, and Turing machines. I might then mumble about number of tapes and time to recognize, and then stop.

Type 0, Type 1, Type 2 and Type 3 (aka: Type K grammars).

Type 0 is an unrestricted grammar.

Type 1 is a context sensitive grammar.

Type 2 is a context free grammar.

Type 3 is a regular grammar.

For our (CS) purposes we typically use Type 2 and 3.

" I looked up the problem and found out he had done Ph.D. research in that area, and there was no general O(n log n) solution - only solutions that could do that in most practical cases."

The Kobayashi Maru of programming interview questions!

Sadly I’m yet to meet an employer who thinks like this. Especially in Australia. I’m a C# developer not because I was born with C# DNA but because to use any other language in suddenly looking at junior wages. Even though I could do a great job in any programmming language. It’s insane.

I've worked at 4 software companies in Australia so far and none have been concerned about which programming languages I know (admittedly not for super high wages, but still...)

So how did they do the code test? Did they say you can do it in any language?

I interviewed for atlassian a few years ago. They gave me a tricky Java test, the kind that you’d only pass if you’ve been battling Java for years and know the gotchas. So that was a fail. I could have studied Java harder, but I’ve only got so much time and so many opportunities.

1 don't remember, 1 any (but need SQL), 1 Java (Atlassian, actually, but only the easy screen - may have been the particular division here), 1 no test because they knew me.

out of curiosity how high / low relatively are the aussie wages compared to us ones ?

They are lower, but better than continental Europe.

I here that SF people are getting $130k out of uni. That would be a rare high salary here (180k Aud).

Probably a manager of 100 people or a good cider working in trading, or a smart employer who doesn’t want to play the market rates game.

Salary is total comp here pretty much.

I wish everyone thought that way but they don't. In today's rapid paced world if you don't know Rails (not even Ruby) but Rails, for example, and we're using it - then you ain't in... and here write this 8 hour code test so we can subjectively judge it because grading code tests to see if you don't put logic in your controllers make our egos hum.

Maybe nitpicking certain micro-design choices isn't always helpful, and maybe it doesn't need to be a task requiring 8 hours, but I believe a "work sample" of actual code is the only technique that has any research backing it as a good way to evaluate potential hires.

If you're recruiting with a specific company and specific team that you love, sure. But I can't imagine committing multiple hours of my time to each random company's take-homes. As a rule I don't really do any take-homes - the couple I've done haven't been very useful in terms of my own time investment into the problems themselves, and the companies have not been worth it to go above and beyond.

This is my exact issue with take-home tasks: I can get to an onsite or a rejection with most other companies after a 15 minute recruiter call and a 45-60 minute technical phone screen. So, why do I want to do a 2+ hour homework assignment? Most of the time, there simply is no compelling reason to do so.

I greatly prefer take-homes, because I feel they show off the quality of what I can do under actual coding conditions (rather than the stress of live coding or the BS of whiteboard coding) but it does get a bit tiresome. Especially because it is rarely a 2 hour assignment, they can be 8-16 easy.

Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30 hours of work + interview steps. I'm sorry, but a full week's of unpaid work that I have to fit around my actual day job is just not practical, I know you want to make a good decision, but really...????

The best I've seen recently is a company that paid an hourly wage for 2 days worth of take-homes. Not consulting wages, but a good wage. It gives them incentives not to invite everyone in the world to do their test, and gives the interviewee something for their time.

> Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30 hours of work + interview steps.

This lines up exactly with my experience. 3-4 interviews, each requiring ~30 hours of technical tests, and interviewing. Absolutely ridiculous.

I wish there was like one long interview process I could go through - I do a bunch of technical work, I answer some standard questions on video, a bunch of companies review it all, and the ones that are interested schedule a 1-2 hour personal conversation to make sure we are a good fit.

I suppose that is what triple-byte is trying to do.

But really, we're all at-will employment, let's just work together for 3 months or so, see if you like my skills and I like your culture and if not just part ways - I'd even be happy to work at a wage cut for the first 3 months. But having a full-time job interviewing while working a full-time job is exhausting, esp when after 30+ (!!!) hours of interviews and conversations, you can be cut at the final stage without a single word about what went wrong.

Regardless of what Triplebyte is trying to do, they don’t actually work the way you suggest. You take a short, multiple choice quiz, then do a coding challenge and an interview. I believe the time investment is around 4 hours.

What you get is actual, real feedback on your performance, and you skip straight to onsites with companies they match you with. The feedback is valuable, but I don’t know how their matching process works at all.

What it _doesn’t_ do is “turn an O(n) process into an O(1) process,” as their FAQ suggests. All it saves you is 1 phone screen per company they match you with. If a typical phone screen is 45-60 minutes, and the time you spend on their process is 4 hours, you need to interview with 4-6 of their clients to make it worthwhile in terms of time savings.

IMO, don’t try Triplebyte to save yourself time. Do it for the interview feedback, because that’s the best place I know where you can get real feedback for free.

Ture, but for some companies the "technical phone screen" is multiple interviews + a take home. Etc.

If I get to skip 10+ hours of interviews and coding work, that's a significant time savings

This has become more worrisome of late since the number of workable toolchains seems to be increasing. The fraction of jobs in this town I could be eligible for (without a lot of tapdancing) is much smaller than it used to be, despite the fact that we aren't really doing all that much that's different than ten years ago.

well then fuck those companies. The people you work with will be the people who made it through that kind of filter.

Their other processes are probably equally terrible and their codebase is likely a nightmare. Make your money somewhere else. Really.

8 hour code test - you are an optimist! :D Recent trend in Silicon Valley is 1 week to 1 month (MVP) coding test in a hot area (e.g. Deep Learning), preferably coming with unique world-class solutions during that time :DDD And you get a phone interview only when you went to a Top 10 school.

In this market? I'd laugh in the interviewer's face. Like hell I'm doing a month of unpaid work for your "prestigious" opportunity.

Yes, if you are competing for high-end salaries/share %.

It's another way for them to age discriminate.

I guess, I just call it demanding I work for free, and that ain't gonna happen.

Couldn't agree more. An ability to learn quickly, to self-teach, to solve problems is vastly more important than any degree of exposure to a specific piece of technology. These characteristics are as much about your skill level as they are about your attitude and approach to software engineering, as well.

> Do you see what's not there? Programming language competency. Database knowledge. Things like that.

I hear this a lot, but I'm not sure I agree 100%.

I want to work with people who can write idiomatic code and are able to use a database efficiently (or who are at least willing to learn these things).

Some small counterpoints on idiomatic code:

1. I've worked with people with years of experience in a language who can't (well, really, "won't") write idiomatic code in that language. This has—in my experience—typically come down to overconfidence/arrogance built on top of their experience whereby they've spent enough time with the language to develop their own "better" style.

2. Learning quickly on-the-job typically involved picking up idiomatic style first, before you really gain a deep understanding of the underlying workings. Ideally a good engineer should gain both, but at least initially, I haven't found the former to be a problem for "good" engineers starting out on something new.

3. For some language ecosystems, what's idiomatic changes over time. Flexibility and adaptibility is key to being a good engineer, but if someone has a lot of experience but isn't so adaptible (and/or hasn't brushed up on modern techniques in their ecosystem), this can also lead to non-idiomatic style.

I get that some of the things above should be red flags "in an of themselves" when hiring, but I'm just pointing out that a focus on past familiarity with tech can cloud things somewhat, and shouldn't be implicitly prioritised.

I prefer working with idiomatic code. On the other hand, we hired a guy who didn't write idiomatic code but who was a brilliant engineer in general and he was overall a great hire even if I had to bring him up to speed on a couple style points. Overall, I found his general engineering chops dramatically outweighed the minor annoyance of tidying up style foibles.

Sometimes idiomatic code results in code which is hard to understand, as exemplified by the C idiom `while (s++ = t++);' for copying a string from t to s. It's always good to be able to read idiomatic code, however.

It sounds a bit like you are primarily selecting for high IQ, with a side of good attitude. I tend to agree with that.

My experience has been that interviewers like you are rare. I may have reflected on my observations incorrectly, but it seems to me that depending on a newcomer to quickly learn a language and adapt is seen as a high-risk investment. I consider myself an adaptable person, and while I was able to make this impression upon prospective employers in my early days, they would always weigh this against the cost of training me for "longer" than the average employee.

In a sense, they were right. I have noticed myself increasingly comfortable with new codebases whenever I change jobs, so experience definitely counts for something.

Yeah, too often I've had interviewers who were far too eager to go and go all the way down to the minor corner cases of a problem (even if I try to beg off of them) and in the end I have no time to ask interesting questions. Questions that might reveal more about my skills than the last two corner cases.

In your opinion are there any common signs you see that indicate someone is good at dynamically applying new skills? or even better is there any signs that clearly idcated they aren;t good?

you talked about paying attention to their attitude but I mean more specific things like, if they said they use Emacs and write bash scripts would you take that as arrogance or that they are competent?

That's what happened at my first job - told to get the book on Fortran from company library and learn it.

To be fair, I found Fortran 77 to have the easiest learning curve of any language I've had to pick up. It only required about 2-3 hours of reading, plus a little more Googling to understand the challenges of having it interact with C++ code.

> ability to learn, not to create a mess and not to waste time on stupid things

People do stupid things and create a mess, while they learn.

They are learning at a new job anyway: the code base, tech stack, and social constructs that contributed to these. Learning the syntax and idioms of a new language is the smallest thing in most cases. Unless the language is particularly esoteric I submit that worrying about the "mess" made by learning it is hardly worth considering compared to those other things.

How do you check for those things in an interview? I'm not suggesting you can't, I'm genuinely asking.

You talk with them. You've probably worked with enough people that you can sniff out the fakes

All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used. "Can you show you know sufficient SQL? Did you write applications before using Rails/Django what have you? Distributed this, Web that - OK, jobs is yours." After all that the productivity of the programmer is solely based on the work environment and how motivated you can keep a developer who is becoming depressingly convinced that his calling in life is to write web handlers and optimize queries to a bloated database schema and watch the guy whose been on the job too long walk around like he's some fusion of John Carmack and Elon Musk.

Why these interview processes act as if candidates are going to be designing graphics engines from scratch for graphics hardware extracted fr om a downed alien spacecraftis beyond me. We just really be testing their ability to sort through a bunch of legacy OOP designed by people who are so board with the project domain that made of bunch of bad abstractions and used every new OOD technique in the books when a handful few procedural functions would have sufficed.

> All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used.

this is exactly the company/boss i would not want to work for. It is exactly the opposite. You should not care if the person if familiar with the tech you use. Who cares if you do php or c#? Does it REALLY make any difference when it comes to taking the business logic and adapting it into MVC/API?

Yes.

Because if they don't have a deepish understand of the language and framework IME they tend to write crap code.

If someone is being hired to write C# /.NET all day every day I don't want to have to spend time teaching them C# or .NET

Especially not how to write good C# / .NET.

Wasn't part of the point of C#'s syntax was that it was easy for C++ and Java programmers to learn? Would any real C# advocate really tell me it would take months of manager supervised learning to pickup?

I've been writing code for a long time in many languages and I do my best to write "good" code. The principles that make code "good" in one language appear to apply equally to other languages...

I would argue that what makes code "good" is completely subjective which is why I don't spend too much time thinking about it.

The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples.

There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".

"The only criteria I have for good code these days is "Does it work", "Can I understand it"."

Which of course, are not trivial to achieve by any means.

Maybe also add "Can my coworkers understand it?" Which might be a very different metric.

"I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later."

If you want to get very far with any of those, you will need to write "good code", as you have defined it. So maybe a better way to understand good code would be to read the code of large projects implementing the things you want to learn about?

I don't know. Procedural code in Golang is pretty trivial - you basic constructs are regular in the selection, iteration, and sequence sense with a sprinkle of interfaces and some CSP constructs for concurrent design. That covers like 99% of what you need to write good code. I'd say pattern matching is pretty helpful Ala ML, Haskell, Rust. Beyond that all the GOF and Solid and all that jazz seems to do way more harm than good IMHO.

> If you want to get very far with any of those, you will need to write "good code"

If you have ever looked at the code of the most successful programs the code is anything but "good". Have you glanced at the Linux Kernel code lately? But again, "good" is very subjective. The Linux Kernel works well enough to server the purpose of millions of users and enough people understand it. Its good code!

There _are_ differences in good code between language. For exmaple, I've recently worked with a very good Java dev who wrote some code for a React frontend. While his code was very good, it definitely had that "java" feel to it, and I actually fixed a few bugs by removing some of it, mostly around state vs props synchronization.

While it might not always be a huge leap between languages, I think it would be a bit more work to explain something like this to a PHP user: "We used reflection to modify the expression tree Entity Framework generated from this SQLFunctions.DateDiff call to allow dynamic ranges to be used. This has saved us thousands of lines of boilerplate code, but it should only be used in non-critical locations, like reports, as it depends on the internal implementation of the expression tree using a list, which is not guaranteed under any circumstances, but very unlikely to change."

I'm sure there are similar situations going from .NET to PHP. I think they would understand the implications, but I'm not sure they would be able to quickly fix it if the expression tree implementation changed and they had to determine which implementation was being used with reflection.

That said, I would hire the PHP/Ruby programmer who didn't run screaming at the use of reflection and monkey patching over a .NET/Java developer with no interest in all the neat things their language of choice can do to eliminate massive amounts of boilerplate code.

Man, you are singing on my frequency. I’ve worked with too many John Musks. And I’ve seen too many full table scans and null reference exceptions :-(

> We just really be testing their ability to sort through a bunch of legacy OOP designed by people who are so board with the project domain that made of bunch of bad abstractions

My preferred coding interview approach is indeed to let the candidate interact with a correct but poorly-written piece of code and refactor it into something more maintainable. I find that reading and working with other people's code is a hugely important part of the job on a modern dev team, but rarely is that part of the evaluation.

No, they are not. The things programmers do are not mundane.

The word you are missing from your description is "effects". The parts of program or system interacts with each other not only by passing and returning values, but also by effects. It is good if your effects are isolated in SQL with ACID, but oftentimes they are not. The interaction is often subtle when resource in conflicting usage is shared indirectly (systems programming, come here!). And in the end of the day you are more Sherlok than you could imagine you ever would.

I am here not to say that interview questions are perfect. I am here to say that things that programmers do are not mundane (or they would be automated out quite quickly).

"I am here to say that things that programmers do are not mundane (or they would be automated out quite quickly)."

And they have been automated out, and so we are all working to solve other things now, which will then be automated, leaving us to solve other things...until the Singularity.

I don't ask brain-teasers during an interview, but time and time again the value of a simple coding assignment has proven its worth. It is simply amazing to me how many candidates seem to lack the basic ability to code a couple of nested for loops, and weeding those candidates out early streamlines the whole interview process.

I will typically do this on a phone screen, having informed the candidate beforehand that they need to be near a computer with an internet connection during the call. Typically this will be after business hours, so they're at home where they're comfortable, and on their own machine, whatever it is.

I use a site called rextester to administer the test. I've been using it for years, and it's fantastic.

https://rextester.com/runcode

As the tester, you go to the site, choose the language, and click 'live cooperation' at the bottom. Then you email or tell the candiate the link to follow, and both of you click on it to go to the shared coding editor. You can now see the candidate type and talk about how they're solving the problem, editing yourself to give hints/clarity if need be. To save time, you can have some code handy to paste in and pre-seed the problem if you choose (like a list of data to sort, etc.)

This tool has proven immensely useful in my interview process, and beats the hell out of whiteboard coding in person, IMHO.

[edit - spelling]

I think you're testing for someone who can think on the spot with a person watching every keystroke which would be rare in an actual work environment. For a lot of programmers, they spend most of their time in their own head thinking through a problem, trying things, removing things, etc. To accomplish what I think you are trying to select for would be a take-home assignment. The interviewee can work through problems in a more natural way without someone watching intently on every keystroke.

I think that asking really simple fizz buzz style questions in this context is probably fine. The whole point I think is to screen out candidates who can't do these sorts of assignments in ~5-20 minutes or whatever. With a take home assignment you'll get people who spend two hours or on your 15 minute problem which is the kind of person who I think OP is trying to filter out.

I think even if you're not the kind of person who can think on the spot with someone watching you well, you should be able to knock out fizz buzz style question in that setting quickly.

"I think you're testing for someone who can think on the spot with a person watching every keystroke which would be rare in an actual work environment."

Except maybe for pair programming shops?

Is it amazing that they can't do them at all, or they can't do them in the spotlight in a totally unfamiliar? I have a strong feeling that most of the people you think fall in the former are actually in the latter.

Yes, the solution might be a couple nested for loops. But if it's a new question to the interviewee, then they don't know the solution yet.

If you can't find the solution, and you can't work in a slightly unfamiliar situation which is undoubtedly supposed to be your core competency, then I don't see why that's a job you should get.

If you're bad at taking tests, being able to make a vague excuse for why you failed one is not an acceptable substitution for passing it.

If you're bad at taking tests, being able to make a vague excuse for why you failed one is not an acceptable substitution for passing it.

Nor is the above argument an acceptable substitution for a sound argument that these kinds of tests have some kind of validity.

If you ask questions that are relative to the job and something you might run into or someone asking you for help, then that is different.

But, I've personally never been asked these kinds of questions in a live coding/whiteboarding session. It's always brain teasers or some sort of algorithmic problem. Usually they are things that aren't necessarily hard, but are about as far from everyday work as you can get.

Lately I have done a few at home code challenges for companies. They usually take several hours. They are perfectly functional and use minimal code but, the only feedback I receive is: "we're not moving forward". They won't discuss anything with me. The only impression I get is that your company is terrible and I will never respond to your recruiters again.

Never take a code test until you speak on the phone with an engineer at the company. That way, they need to at least trade something valuable of theirs (expensive engineer time) for something valuable of yours (your time). When you adopt this policy, all kinds of B.S. magically vanishes from your life.

After all, you would never continue to try to win the affection of a guy/girl who wouldn't at least give you a first date? Why do the same for a company that can't bother to give you some of their time?

I despise the "legal risk/threat" aspects of this process, which is most likely the reason nobody can actually tell you something useful. In many large companies you can't even provide critical feedback to your own employees, and if you end up letting them go as a result, you are unable to tell them what really went wrong.

I understand an aversion to legal risk, but IMHO this is going to an extreme that hurts all of us.

That has always got me about interviews; I've tried emailing back the company, calling them, etc - trying to get some kind of feedback.

I consider it lucky if I even get an email or voicemail saying they've decided to pass. Honestly, most of the time, I don't even get that.

If you're a recruiter, or interviewing someone for a position, it's my opinion that you should be able to give the candidate feedback on what they did right, and what they did wrong, so that they can improve themselves for their next interview.

So often, as a candidate, I've been left to guess at what I did wrong, or why things didn't turn out well. Sometimes, you can figure it out. Other times, it's not very clear what it is you did or answered wrong. Maybe you have a nervous tic or other habit that you are totally unconscious of that nobody has pointed out - and that put them off? Or maybe you need to work on your delivery, or who knows what?

I can understand why companies don't do it; I can see it from their side. I'm sure they (well, their recruiters) can see it from the candidate's side as well. I wish there were a way around this impasse.

I tend to wonder if it has become this way, in part, due to candidates getting honest feedback, and then they in turn went off the rails against the employer or employees? Pure speculation, but it wouldn't surprise me to find out this was the case for some of this.

For me, honest and accurate feedback is the one thing that is missing.

When I get rejected, the response is usually "You are not a good match to our company culture". What I would appreciate would be "Your lack of experience in managing remote teams is a gap for us."

I feel that quality to the pool of candidates will increase once this feedback loop problem is fixed.

I'm not sure this is true but I've heard people who work in 'hiring' say so: from the company's point of view there is almost no upside to providing insightful and useful feedback, and there's always a chance that feedback will be used to sue for discrimination, or ridicule the company online, etc. Best to be generic and forgotten about by the candidate as soon as possible

Mostly this. I was a hiring manager at a big company where HR made it very clear we cannot give specific feedback to applicants. We also could not give references for the same reason; fear of being sued. But after a while you learn to speak in code for those cases where you really feel you need to provide meaningful information.

The last time I was asked for a reference I was contacted by a hiring manager who said they were about to make an offer and just needed a couple references. It was a previous employee who had been a particularly low performer. My response was "Company policy prevents me from providing any references. However, (pregnant pause) you should always be very careful and selective in your hiring process." The hiring manager asking for the reference was baffled. She must have been new and had not yet learned the code. Later I bumped into her at some industry event and she thanked me profusely because my non-reference prompted her to do more digging and she learned just how bad that candidate was.

Moral of the story: learn the code (strikes me as kinda funny on HN where the usual advice is learn to code)

If you can't for legal and ethical reasons say bob sucks don't hire him then you can't communicate the same thing in a way that is as subtle as a brick.

Next time before you do something like that I suggest you communicate with your companies lawyer and ask his opinion on the matter before you get your company sued and yourself fired. Especially if you are going to discuss the matter on the public internet.

Odds are incredibly good that its trivial to discern your actual identity and that you have done the same thing repeatedly. Its entirely possible that someone could be working out right now why they weren't hired and whom they should sue.

wtf. what you are describing is something that i would say is suable. and should be.

you basically said dont hire that person to someone. because of your bad experience with that ex-colleague ?. you are denying that person a chance. how come ?

what are you going to do next time someone calls for reference ? the same ?

immature, questionable, discriminating practices...

It is almost like the impressions you leave with former colleagues and managers matters. Who would have thought that is what a reference call is attempting to uncover.

> you basically said dont hire that person to someone. because of your bad experience with that ex-colleague ?. you are denying that person a chance. how come ?

I disagree. If you had a bad experience with an employee and you're asked to validate the quality of that candidate why should you lie or omit that info?

When you're looking for a job do you also feel that it's wrong to ask current and former employees for references?

Furthermore, it seems you're oblivious to how many candidates outright lie about their CV and working experience.

You need info to make good informed decisions. Otherwise you have no alternative other than to fell for con jobs.

I wonder how that is actionable. I did not say anything about the candidate. Just the opposite, I was clear that I cannot say anything about him. What I said was very generic and sound advice for any hiring manager. Any negative information concerning the candidate came from somewhere else after the hiring manager did more digging. So any legal action would have to target my intent, not what I said. And my intent was for the hiring manager do a complete assessment before making a decision, which is of course sound advice, and the same advice I would give for any candidate. Good luck suing me. If the candidate wanted to sue someone they would go after whoever provided negative information, which was not me.

When asked for an assessment of a co-worker, providing said assessment is immature and somehow discriminatory? What do you even think is the point of references?

Not everyone's great to work with, I'm sure you have had a few co-workers you would rather not work with again, right?

yes, doing what the previous poster did - giving vague "bad signals" even against company's policies - is what i consider immature and discriminatory.

references in form of background check - worked years a, b, c, on projects x, y,z - yes, sure.

references about performance, likability, etc - why ? how are you going to judge that ? are the references legit ? are you going to get references on the reference giving people ? are you gonna research the excompanies culture to judge tbe referential credibility ?

you're just fooling yourself giving any meaning to this, you could be as well tossing a coin.

Reference = "A letter from a previous employer testifying to someone's ability or reliability, used when applying for a new job." [0]

What even is your rant about? Managers especially can easily tell your performance, how you get along with everyone, etc. That's the whole fucking POINT of a reference.

https://en.oxforddictionaries.com/definition/reference

in most cases, people are only getting called up for a reference because the applicant specifically chose to list them. if the only person they could think of to use as a reference has nothing good to say (or gives subtle negative signals) that's a pretty strong sign there's something wrong with the fellow.

Strange. Where I live it's common practice to ask former employers about a persons performance. I you have no prior work experience they would want to call your math theacher or army drill instructor.

In the US it's illegal? It's discrimation yes but isn't that the whole point of a recruitment process?

Not at all illegal, and is quite the norm to ask for references.

You can get sued for anything - it need not be illegal to be sued for it.

It's illegal in the US for the company or anyone representing the company to say anything more than that they worked for the company, and what they worked on.

They can't tell the person that the employee was fired, or anything like that.

But as noted - there are ways used to get around such things (that is, the laws of our country). Those laws exist because people were wrongly discriminated against by using such "references".

But if you have a reference to someone you worked with, and they are no longer employed by that company - then I'm pretty sure they can answer anything they wanted too (unless there's some kind of NDA they are still under after leaving the company). Because they don't represent the employer any longer, and are a personal reference - things become more casual.

That's not illegal. HR/legal just usually prohibits it because negative feedback could potentially be used in a discrimination lawsuit.

Then what is the point of a reference?

When I do interviews I try to give good feedback. My goal is that in 2 or 3 years if the candidate is interested in working with us again that they will certainly pass the interview. However, "You are not a good match for our company culture" is feedback I've definitely given and it's a bit hard to give details.

There are a couple of main things. Usually when I have this issue it's because the candidate seems really keen to do things or have things that we just don't offer. For example, "Every piece of code must be a micro service". Some of our code works that way but lots doesn't and we aren't going to change it. Another example might be a very junior person saying, "I want to be the scrum master". Well, we don't do scrum master in our team and even if we did, we would be unlikely to pick that person.

Basically, "You aren't a good match to our company culture" is saying "I really think you would be very unhappy here based on your responses". Again, I try to explain if I can but I also don't want to get into an argument. If I'm getting "no go" feelings and they aren't reciprocated, this seems doubly like a problem.

My advice, if you are getting this response a lot, is to consider how you are responding to questions. You may be projecting an inflexible attitude. Don't wait until the end of the interview to ask questions about how things work. Try to make sure to fit it in at every place you can. How are they doing their development? What are the people like? How do they resolve disputes? How do they decide on their tech stack? etc, etc.

However, also think critically about the place you are applying into. If you think, "Oh this is an awesome place" and they think "This guy isn't a good fit", That's a pretty bit mismatch. Did you listen well enough to their explanations? Are you sure that it works the way you think it does? However, if you are thinking, "Oh well, this place is OK. There are problems, but I can fix them", maybe there is a mismatch between what you think is a problem and what they think is a problem.

And while you might be thinking that "not a good match" is corporate speak for "you can't balance a B-tree", my experience is that it really means exactly what it says. As much as my ego takes a hit when I experience it myself, in retrospect every time I've gotten that response it's because it was true. I would have hated that job.

Sorry for the rambling nature of this reply. I should be working, but I hope it was helpful.

Your comments are helpful and it is aligned with my observations as well.

I have been on both sides of the hiring table, and while the engineer in me wants to give constructive feedback so that the rejected candidate can better themselves for their next interview, the corporate management in me is telling to do something else.

It has been a conflicting point of view in my head ever since I got involve in hiring.

a) dont take these rejections personally. dont hold a grudge. it might be someone incompetent is reviewing your code. it might be the company does not have urgent need to hire but is only on tge lookout if they spot someone matching their (awkard) criteria.

b) if its a repeating thing consider asking someone (a friend, a forum, a senior dev) for review of one of these "exercises". this could show you what youre not seeing. or could show you your code is just fine or perfect and it's about the company not knowing what they want. so either you will learn something or you will boost your self confidence.

a series of "rejections" can put one's self-confidence to a test, remember good times will come again.

I hate these take-home code projects, to a point where I won't do them for similar reasons that you mentioned ("we're not moving forward, we will keep your resume on file!").

It's sort of a selfish way of interviewing; to write good code for these projects, it can take me upwards of 8 hours. An engineer where I live (NYC) can fairly easily make $50/hour (usually more), so they effectively expect me to give $350-450 of time for this company where there's a fairly high likelihood that they'll tell me to buzz off. I typically write in a very functional lispy style (even when I did JavaScript), and while the overall understanding of FP has improved in the last couple years, a lot of the interviewers would simply not understand what I was writing, and ask me to write it "more object oriented".

Big corporations like Google can get away with that, but for a small startup I really don't think it's worth it to do them (not to mention that I had a friend who did one of these assignments, and they ended up using his code in production without paying him).

> to write good code for these projects, it can take me upwards of 8 hours.

The good data science take-home assignments I've done suggest a 2-3 hour limit and they were correctly scoped for that limit, although technically there's no incentive for the candidate to stick to that limit.

The worst take home I did suspiciously did not have an expected time limit (but was due in 48 hours after issuing). It was extremely broadly scoped, and as a result it took 16 hours; even after a couple years as a data scientist now and familiar with time-saving tricks, it would still take 8 hours minimum if you weren't already familiar with the company's data.

Even 2-3 hours is pretty high, expecting me to spend $100-150 of labor for it.

16 hours is kind of insane and you have my sympathies. My record is around 10 hours.

"I typically write in a very functional lispy style (even when I did JavaScript), and while the overall understanding of FP has improved in the last couple years, a lot of the interviewers would simply not understand what I was writing, and ask me to write it "more object oriented"."

Which is a good way for you to weed out companies where the developers are low to average intelligence.

Not understanding basic functional programming concepts, in 2019? Seriously?

In fairness, the times this happened was 2015, so about four years ago. Still, even by then it was getting to the "it's not ok to not know this" territory.

Honestly, this is why I'm skeptical of take-home coding. They require a high investment of my time, and a lower investment of the hiring company's time.

It's fine when I'm in a "my job is to get a job" situation, but I haven't been in that situation very much.

As a result, I only start these kinds of projects when I have a clear understanding of the company; and when my personal ramp-up will be very small. Otherwise, I just walk away. My free time is limited.

Another fun aspect is that, surprisingly often, these "tests" are poorly (and in some cases, plainly wrongly) articulated and/or simply not do-able as articulated.

Or do-able, but they end up requiring 2-4x the "just a couple of hours" they asked for to be done reasonably well.

After which at some point one starts asking one's self: "Do I need this industry actually?"

I've got you beat regarding feedback. I applied to a backend position looking for 3-5 years of backend experience, and was told I "didn't have enough API experience." I had 5 years of backend experience at the time. Literally all I do is write, modify, and interact with APIs.

Try not to judge the individuals too harshly in this circumstance - their lawyers have probably forbid them from saying much if anything at all.

I'll judge them all the same because it's not illegal to give someone feedback. Unless you have discriminatory hiring practices in which case the judgement holds true, or your legal team is so far up their own and everybody else's ass, the judgement still holds true.

Partly the problem is "the system" people created for themselves. At some point people started suing employers because of some really contrived reasons so employers became very, very careful.

If there is a big company that hires a lot of people and this is managed by many HR stuff, it is much cheaper and safer not to give any response than go through every rejection response to double check if something seemingly innocent cannot be interpreted as "discriminatory practice", rightly or not.

Yes, it basically is illegal to let a non-lawyer give someone feedback. Not literally, but negligent of a company to allow.

The requirements to open yourself up to a discrimination lawsuit are fairly high.

Legal doesn't have 'interview experience - net promoter score' or any other interview quality metrics as one of their KPIs, so they're happy to mandate the nuclear option because it gets work off their plate.

Can you elaborate? What do these laws actually say?

It's less about what the laws say and more about what the consequences of not following industry standard would be.

If you explicitly flout standard and as a result get sued for violating one of the related hiring/discrimination laws, your investors may have a good case to sue you personally because you didn't act in the best interest of the company by opening your company up to that extra risk for no tangible benefit.

That's not a reason to let them off the hook, because they control the rest of the experience. If they can't give feedback, then they shouldn't have a hiring process that asks for such effort from the candidate.

That is pretty bad behavior. Our position is that if you took the time out of your schedule to complete our coding task, we will take the time to do a technical interview with you.

I always use those as a way to test a new language/paradigm/something. I'm naturally lazy and this is a wonderful way to get new knowledge.

>Sorry I want to write an extension to emacs so I'm solving your problem in elisp.

We used to give standard questions for college candidates, language unrestricted.

I saw several candidates solve the problem in scheme and every one of them was beautiful.

A perspective from the interviewer's side. Since I run a small startup, when hiring, my first thing to determine was that whether I would be able to work with the candidate. Hence, I would come up with a puzzle, a maths problem, or even a guesstimate, just to see the thought process and that whether there is any "gelling". Things to evaluate are, original thinking, how well the candidate puts his perspective forward, how well he takes suggestions, how quickly he reaches the crux of the problem etc. If there is a face to face interview, the general assumption is that the candidate is talented, more important is that whether he can work with others in the company. If I am hiring someone who will work alone, without anyone's inputs, I might change the process (something like an integration or SSIS workflow) but have not needed to encounter that as of yet.

I usually go through the resume, and have interviewed enough coders to understand that they would know about what is written on the resume. Hence, knowing the background is good enough for evaluation, but feels repetitive during the interview. (Also, if you have had 4-5 years of experience, and 2-3 jobs, you can only stay for long if you had good skillset)

I usually give my disclaimer: "These aren't real world problems. Some questions involve code that we wouldn't write in the real world. We only have 45 minutes. The goal is to have a conversation about code."

And then I point out that "it's not practical to spend 2-3 days on-boarding you for a job interview. Thus, these questions are contrived. The best way to succeed is to have a conversation about code, and sometimes you need to play a little bit of the 'tell me what I want to hear' game".

And then, for one question, I need to point out that, "I once had a candidate say, 'I like JSON better then XML. XML's outdated.' This question is to discuss concepts that are easy to discuss with C#'s XML APIs, because chances are, you've used them." (And if the candidate tells me that they don't have a lot of XML experience, it's okay.

Interestingly in the last 6 months I’ve been on both sides of this: being hired and hiring others. It was really cool because it allowed me to understand what is actually good and useful in the hiring process from both ends.

While hiring (only 2 people, one junior and one senior, both fully remote) I just had a ~45-60min chat about technical and non-technical things (e.g. what do you think about functional programming/rails/deployment/ops/whatever, what does <something> mean to you, how do you feel about <some workplace practice>) and then gave them a small paid project to work on our actual codebase - something like implementing a small, self contained feature or writing some tests for a particular piece of code. I found this to be a really good way to find out if I’ll like working with someone and if they are a good fit on a technical level.

I second this. I freelance as a part time CTO and this has been my favorite appproach to hiring devs. A paid project goes a long way to establishing a good work relationship and gives both sides most of what they need to decide if it’s a good fit longer term. I also always offer my clients to start with a small contained project to see if we’re a fit. This ends up saving a lot of time: the risk is low for the employer, and the developer gets paid their market rate and has a chance to show that they are worth it. It’s then really easy to decide if we should continue working together or not.

>freelance as parttime CTO

job title inflation bingo !!! ;)

I agree; when I interview I tend to talk to them for a bit to get a feel for how they view the world and how they code. I ask about personal projects, how they learn new things, sources of information for keeping current, what they've worked with, personal interests. I ask what they've worked with and why and why they would choose a particular solution. You can get some really interesting answers (programmers tend to be polymath-y types). I think the best hires we've made were people who had personal side projects, naturally curious with learning hobbies (not just programming), and were open and honest about questions, willing to have a good discussion, and weren't just trying to give the expected answers. There are two sides to that coin, since the interviewer also has to value that, and maybe it just depends on who you are and what you are looking for, but it has worked well for us.

I love the idea about doing the paid project on the real project; I'd love to implement that too.

On the plus side: I wholeheartedly agree with all those points.

On the contra side: Nothing of this really felt like it helped me. I found interviewing people absolutely horrible and almost never had a good feeling. People who seemed like they may have been a good fit didn't get offers for one reason or another, some people seemed awesome in the interview and then weren't. Overall I've been happy with the decisions I personally made (not all that the team/higher-ups then made) but even with the best of intentions.. it's hard. But it was a small company so maybe it was already a problem of not looking very interesting to some.

It still amazes me that some people seem to be utterly disinterested in what your company does or how they will work in a team, asking basically zero questions besides "how much money?" and "which language?".

At my last employer, I sat in on an interview for a co-op with my boss. After asking the interviewee some questions the conversation went basically like this:

Boss: Do you have any questions for me?

Co-op: No

Boss: Would you like to know about the company? What we do?

Co-op: No

I couldn't help myself from laughing. I know he's just a student, but he's still a 20 something adult. No interest at all, just looking to check another box on his list of credentials. At least fake it!

One of my last tech interviews was for a startup. The tech team were all kids and seemed embarrassed to be interviewing me because I had much more experience than them. That all went well.

I asked to have a brief meeting with senior leadership to talk about their business model/plan -- how did they intend to make money?

CEO, COO, CFO, CTO, or the like, would do (it was a small co.). So I got an appointment for 30 minutes with the CTO or CFO (can't remember). Day of the meeting I show up and checkin with reception. 20 minutes later, I reminded them I was still here and someone came out and told me the guy I was supposed meet was out of the office on travel.

I just don't really get this attitude. What exactly you want me to ask assuming I know salary and position? General information about company is usually right there on the website. I am really not sure what exactly the hiring manager is supposed to be asked at that moment, especially by someone young who does not have enough experience to distinguish between lying hiring manager and the one that tells the truth.

I could see meaningful questions about vacation policy and overtimes and such, but that comes with experience and a.) youngsters wants pretend how they don't care bout weekends in work b.) companies lie about that sort of thing.

I know that this attitude exist so I will ask something, it is not about that. But, the exercise is mostly empty for someone who is inexperienced and does not fully know yet what are situations where he fit vs where he does not fit.

- Tell me about your software development methodology.

- How are requirements communicated to developers?

- How is work by developers tracked?

- What VCS do you use?

- What bug tracker, etc?

- Do you practice devops?

- What's your build process look like? Automated? Continuous deployment?

- How big is the team?

- Do you do sprints? how long typically? How do you decide what to work on in a sprint?

- How do you determine when something is "done"? Who decides?

- Describe your infrastructure.

That's usually enough to get started. You can drill down as far as you want on pretty much any of those.

I would call those good questions from someone experienced or savvy. The guy I'm talking about didn't even care to know what we make.

It's not like we were Facebook or something where he'd already know.

Right, I was responding to watwut's question of "what exactly do you want me to ask?"

"What exactly you want me to ask assuming I know salary and position?"

"Who are your most important customers?"

"What is your monthly recurring revenue?"

"What is your best selling product?"

"What's one thing you like about working here?"

"What's one thing you don't like about working here?"

This isn't very difficult. Just requires a slight interest in the industry you plan to work in.

None of them is useful for anything. They are just questions that you ask to fulfill the "must ask question" requirement. Generally, product is on company main page. Asking that one likely shows you did not seen it.

Moreover, they are unlikely to tell you monthly recurring revenue. That is just odd question. Our company would not definitely.

Hiring manager will not tell you what he does not like about working there - for the same reason why you are not truthful about why you left previous place. Seriously. I would not ask the like dislike question for similar reason - it strikes me as odd and possibly would mark me as someone with low social skills. But the risk there is not too high.

If you read the company's web site, and are a curious and interested person, then you should pretty quickly stumble upon things you would like to know which aren't written there. So if you come up empty, either you are not interested in that company at all, or your curiosity is so easily satisfied that a plain web site can answer all your questions. Both is not a great sign for a prospective employee.

Even suppose you apply to a straightforward company with an extremely detailed web site, so that all your questions have been answered already, then this is still a test if you can meet social expectations. You are indeed expected to have questions, and if you don't even follow this simple convention because you think you know everything already, then your social skills are probably underdeveloped.

Finally, even you already know much about the company (e.g., about the most important product), asking about things you know already and comparing this with what you are told in the application talk will give you additional valuable information. Are they excited about their product? Are they exaggerating? Are they bored when answering? Do they know the basic information on their own web site? If you don't use the opportunity to extract as much information as you can, it's simply not smart.

It just sounds like complete rationalization. That is not how humans work nor how companies work. That is not how interest in things work especially not in work or position.

Yes, it is test of whether you know that social thing. So, if the company is treating it as the test of that, then it is fine. Instead, the parent was almost offended over that "No interest at all, just looking to check another box on his list of credentials. At least fake it!".

> Are they excited about their product? Are they exaggerating? Are they bored when answering? Do they know the basic information on their own web site?

Christ, you are talking with hiring manager at that point. I would not mind him not knowing company web site. Most employees don't actually go there all that often. That person might not even work on that product. Unless we are talking about very small company, people do their small parts of the larger whole.

You are hiring tech person and while cooperation, ability to express oneself clearly and without pointless insults, ability to listen and such are important, ability to guess excitement from someone they don't know much less so. It is not sales position.

I generally agree with your view, an experienced candidate will be able to figure out a lot of the work environment during the interviews before meeting with the hiring manager. Although I generally have a few softball questions that I ask as either filler or to see how much thought they have given to how their development teams work.

They don't ask anything because the answer changes nothing. If they get an offer, they'll 99% take it. If they get two competing offers (I'd say this is uncommon unless you're interviewing in a very large job market like SV) they'd most likely know which one they prefer based on their individual criteria (unlikely this would come down to a question asked in an interview).

Second, most people aren't lucky enough to interview for their dream job, they usually have to settle for something else. Consequently, they really have no significant interest in their future industry. Do you blame them?

You want them to fake interest? Sure, they can do that, but does it really help anyone? They applied because they might want to work there, for whatever reason. Why not let them be concerned with how interested they are?

He didn't even want to know what we make. He had no idea. And no interest. Hopefully he was just showing up for practice or something and not actually expecting a good outcome.

Being inexperienced can excuse a lot, but not a total lack of basic curiosity. And I'd say it's useful to know what a company is producing so you can know if you have any interest in helping produce it.

|I just don't really get this attitude.

Hopefully you just weren't understanding just how bad this was. If not, then try harder I guess?

I call this "developer swagger." As in, "I'm such a hot commodity, I don't need to care about your company specifically."

Agree with everything the OP said but I'd add: when hiring for senior engineers, this process is even more absurd because the real skill of senior engineers is not how much horizontal knowledge they've acquired (knowing web frameworks, Linux guts, databases, distributed systems, etc) or vertical knowledge (being a domain expert in X) but their soft skills -- how good are they at convincing other people of something in a meeting?

A real example: a product person once asked a team I was on for a feature that'd be difficult and time-consuming to program, probably taking the better part of a year. My teammates said no. Not, "We want to ship this software soon and we don't think that's an acceptable tradeoff," they just said no. Product became furious (not knowing how hard it'd be, since the engineers hadn't explained it) and it hurt those developers.

Knowing how to invert a b-tree doesn't help you solve situations like those, which are far more common than 99% of fake problems presented in programming interviews.

When I interview a candidate I ask them to tell me about projects they worked on and poke and prod about real-world stuff they actually did, not converting a singly linked list into a circular linked list.

Ideally people would be offered the choice of an in-person or take-home to satisfy both those who feel like they shouldn't have to spend their free time on homework and those who don't like being forced to instantly come up with solutions to fake problems.

I blame Google for introducing this scourge, hopefully it lifts before the next time I do a job search.

My favorite example of this is Google turning down Max Howell for a job: https://twitter.com/mxcl/status/608682016205344768

I like giving coding “tests” but I prefer to let the candidate pick an issue from an open source project ahead of time. I want to be on as close to the same footing as the interviewee.

I like to see them work in as comfortable and nerve free environment as possible.

And in the event that the person doesn’t get hired, they have a commit on their GitHub and maybe added some value to a project.

> they have a commit on their GitHub

Maybe I'm applying to the wrong places but virtually no one cares about my Github. It's really sad to see so many potential employers ignore one of the best pieces of information for a candidate. For reference, my github is filled with maintained projects and OSS with people using them, submitting issues, prs, etc. It's like the employer's process is set in stone and since a lot of people don't have active githubs, it cannot be used as a comparison.

I think the places that do look at github profiles are great, but then I fear they end up looking for massive OSS projects for it to bear any weight.

I really like this. It gives the candidate the chance to walk out of the room with something

I really liked what my last interviewer did. He did not think of an abstract quiz to test some abstract skills. He took a Problem they where fighting with for some time and we just had a conversation about it.

When can you start?.. Tomorrow.. See you then.

Find someone you can work with on the actual problems you face: work with them during the interview. Just struck me as genius.

I was nervous about my CV not looking too good, he didn't even bother to look at it.

It does sound like a good way to interview a candidate.

But I can see from the company's side it being a bit of a potential legal challenge issue. Depending on what the problem is and how deep it goes into the codebase or whatever, you might get into proprietary process information that someone outside the company shouldn't have access to, possible IP access violations, etc.

If it can be done in such a way to avoid those pitfalls, then it might be ok. But I bet it's a tricky challenge, and may be why it isn't done often?

I suppose I'll be the first to say that yellow as a background color is a horrible design choice. And it's not even using the background color CSS option alone, it's got some weird tiled single pixel yellow image on top of it! What??

Firefox > Reader View

Save your eyes.

Yeah, that felt like a solid punch to the eyes.

Couldn't stand 5 minutes looking at it, sadly.

I think the crux of the problem is... Everyone knows what to expect in a SAT exam, and still if one complains that they didn't bother preparing for it 'cause they do not have enough time... That excuse is not getting them an admission to top institutions, which admittedly have no short supply of folks willing to prepare and go through the grind.

It is sad that interviews in tech have been reduced to a process that resembles SAT-esque entrance exams. And now, there's an entire industry around prepping candidates for the interviews.

That said, I like the approach tptacek wrote about: Give the candidate a book or two, and when they are ready, interview them on it instead of interviewing on algorithms and data structures regardless of the position/industry [0].

I'm not so sure about Stripe's process as well [1], because one might have been effective because of the team and setup they are comfortable with in a given setting that isn't replicatable in an interview setting. No amount of 'bring your own laptop' to the interviews is going to make it work for the interviewee. You need to test the interviewee on the basis of their strengths. Not arbitrary measure of strength. Gosh, this is a hard problem.

There was an article on techcrunch about interviewing in tech and how it breeds ageism [2]. The premise was that it is simply not possible that most folks with X yrs of experience at a software shop are all secretly terrible that they can't get past your interview process.

Either you are part of an exclusive network to get on a rocket ship of a startup [3], or slog it out like everyone else: I remember how tough it was to get a job at Facebook in 2009 or Google in 2005 with ACM ICPC finalists and TopCoders as your interviewers.

[0] https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

[1] https://www.quora.com/Stripe-company/What-is-the-engineering...

[2] https://news.ycombinator.com/item?id=9166501 (on secretly terrible engineers).

[3] https://a16z.com/about/

>It is sad that interviews in tech have been reduced to a process that resembles SAT-esque entrance exams. And now, there's an entire industry around prepping candidates for the interviews.

I'm not sure why that is bad. The more standardized the interview process is, the more consistently people can prepare for interviews and know what to expect. The interview process doesn't have to represent actual work, as long as preparing for and performing well on the interview requires the same skills used to learn and work with a new software feature / language / problem.

>The premise was that it is simply not possible that most folks with X yrs of experience at a software shop are all secretly terrible that they can't get past your interview process.

That's an obviously false premise.

> I'm not sure why that is bad. The more standardized the interview process is, the more consistently people can prepare for interviews and know what to expect.

Yep, agree. You tend to then hire folks who are good at interviewing and not at getting the job done. I think there is no right answer but multiple right answers. Provide three or four different interview loops and let the candidate choose which one they want to opt for: for instance, one loop is the standard algorithms/data-structure, the other loop is a take-home problem, the third could be tptacek-style, the fourth could be stripe-style, and so on...

> That's an obviously false premise.

Sorry, I didn't get. The article argues that obviously that many folks with that much amt of work experience can't all be secretly terrible that we continue to find it hard to hire and so the current interview process needs an overhaul.

#1 thing for me - don't ask me to be a salesperson. In relation to this post - https://news.ycombinator.com/item?id=19534772 I was recently at an interview and the interviewer was a technical guy who had recently been promoted and he had a checklist of 10-15 things he wanted to achieve in the next half year, all really good reasonable things and then he said 'Now I just want you to tell me why you are the best person to do this'.

I finally had to give up and say hey lots of people can do what you want, I can do it and I can give you a list of people who can do it, I don't understand this "best" thing you want from me?

I actively say things similar to what you said. For example, if I’m ever asked why I want the job or why I’d be a good match at the company, I will always say I don’t know. I’ll always say I’m not trying to be facetious or dodge the question, but with limited information from a job listing, maybe a few phone calls, and a day of small 1-hour interviews (that are mostly made up of coding questions with no time for me to ask questions), then it’s just not possible to give a sincere answer that has any more depth than a rehearsed answer based on LinkedIn advice listicles or something.

It is very difficult for me not to say I want the job because I sell my skills for money, if you are willing to pay the price I want then I am willing to provide the product you need.

"because money can be exchanged for goods and or services."

Interviewer didn't like that answer too much, heh.

Best way to hire programmers is to hire them without getting them to code.

Before anyone burns me at the stake...It's not really the "best" but it can work. I was a coding interview advocate for a long time. I changed it from solving puzzles, to solving real problems taken from the domain they were interviewing for. In the early years I was a bit surprised by who struggled with coding, but I noticed a trend after a while, I could mostly tell how well someone was going to do from the preliminary discussions about software / design / experience / tradeoffs / etc. So I actually learn a lot more about the developer from that discussion and have tried to get better at that to explore more things. I like to focus on the nitty gritty of real problems, hand ow to approach architecting a piece of software from all angles. I do still use coding where I think it might help, with grads, I mostly do coding as its a good icebreaker into general conversation, and intermediates where their experience is still limited, I like to set problems that test peoples ability to keep their code tidy and modular, to see if they have developed any coding discipline, but sometimes from the initial conversation I will already know. But most often I already have a good idea.

While a lot of what you say is true, that hiring pattern leaves you exposed to the bullshit artists.

I always want to see some kind of code from someone for whom coding ability matters at all. Doesn’t need to be extensive, tricky, or even written live in front of us, but when the job is more than talking, I want to see more than just talking to evaluate.

I've seen the bullshit artists. When I was early on in interviewing people ( I've been coding just less than 40 years and hiring people ~20 years ), they did surprise me when it came to coding, though I never came close to hiring one. But it turns out, I just wasn't asking the right kinds of questions to pickup on bullshit, or I would let things slide without question where they seem to have glossed over things. But like I say, code isn't out of the question, if I end up with doubts, usually because I can't get super concrete details out of someone, then code is a good way to go.

I've been responsible for hiring 10 or so engineers in my career and everyone of them turned out to be a good hire from the company's perspective. I was always able to smell the BS pretty quickly during interviews and it's always surprised me that this seems to be such a difficult thing for some interviewers to recognize. The BS is exposed when asking for more and more detail about prior work and projects. What was the last project you worked on? What was your role specifically? Were you responsible for selecting any portions of the tech stack? If so, how did you make those decisions? What were the determining factors? And on and on. As an interviewer, if I could not get a good read on one's abilities in this way I'd question my qualifications to be conducting the interview.

The BS artists might be 1 in 250 to 1 in 1000 candidates, so give it time and you'll run into a skilled one sooner or later.

I have made several bad hires over 25 years and probably 100 direct hires and 500 total hires where I was on the panel. It happens. Most would have been difficult to ferret out in an interview, because an interview is an inherently spotty/lossy process.

The worst hire I ever made had, in retrospect, been given the (business case) question ahead of time and had pre-written notes in his notepad. He theatrically took careful notes while I was stating the business case problem, asked if it was OK if he did some computations and composed his thoughts in his notebook before presenting the case at the whiteboard. He did just that and stood to deliver literally the most polished presentation on the case that I have ever experienced. 5/5 definitely hire.

Shows up to the job and couldn't get water out of a boot if told the instructions were printed on the bottom. Flames out in a few months and moves on to his next gig. It was only after playing things back that I realized the only way he could have pulled that off was to have pre-seeded his notebook with the solution to the business case.

If I had to interview someone for a programming job, I think I'd try using LeetCode problems, but NOT as coding challenges. I'd pick a few problems that the candidate and I both find somewhat interesting, and then for each do three things.

First, we'd both read the problem, and talk about our understanding of what it is asking for.

Second, we'd talk about algorithms to solve it, probably at a whiteboard. No need for actual code, or even pseudocode. Anything that gets the ideas across would be fine. Somewhere in here we'd also talk about what cases are tricky and what we would need to do to make sure any test input we were to write would cover them. I'd try to let the candidate drive this, but would provide sufficient hints and nudges to get to a solution and not count needing that against them--this is really just setup for the third part, which is the most important part.

Finally, and most importantly, we'd go to the LeetCode discussion area for that problem and look at solutions people have posted and review them together. Many of the solutions will have mistakes, ranging from minor to major, and trying to spot those together and talking about how to fix them would, I think, give good insights into both the candidate's technical abilities and how they work with others.

I have seen my fair share of candidates who can talk just like you suggested, but literally cannot put even simple solutions into code. Like, can't write a for loop or an if-condition but could walk through a problem like you describe and can even talk about tech trends.

Personally I get intense panic seeing a person's face looking at me while I try to avoid off by one errors.

It's all in the experience but that might be the other side to the situation you are describing.

I am practicing a lot to be more comfortable but I still feel bad for those people who interviewed me and ended up disappointed.

I'm currently working on revamping the way we do the first interview, which is nothing more than a filter.

We currently ask mainly, let's face it, poor theoretical questions.

I want to ask more experience based questions.

so instead of:

Explain what a database index is

Ask:

Can you give us an example of a time you used a database index? What were you trying to achieve? Could there have been a different solution to reach the same outcome?

If the candidate doesn't have experience with databases that's fine we just ignore this question, at least that's what I would like to do, whether I can sell this is another story.

To be sure if the candidate has no database experience, no cloud experience and no backend development experience then it's probably not going to work out but we can try to be flexible about candidate's experience.

It's easy enough to learn what SOLID means but a lot harder to know when it's a bad idea to use it or when it might be a good idea to compromise.

I’ve been asked these kind of questions before....for a compiler job. I mean, you can clearly see on my CV that I don’t do backend, cloud, or database, the hiring manager is not interested in me for those things, yet their interview process is so inflexible that these are the only questions that can be asked during the interview (....and not one compiler question either).

I was on a Senior Frontend Interview, it came up that I had a startup at one point where bootstrapped just about everything, the interviewer started going into that and how I maintained database versioning, and the batch processes I had running on Linode and why I chose Linode, and why I had ElasticSearch running on Searchly and not on AWS, and how did I do performance optimization and build times and why didn't I do this type of QA process and when I took stuff from ElasticSearch and put it into Redis for quicker response times etc. etc. and devops and whatnot, which most of the responses were well that was because I was the only one who could and some of these things you wanted me to have done are just too expensive for a startup in that position.

So anyway the interviewer told the recruiter who'd contacted me that I was not a good cultural fit for their Senior Frontend Developer position.

The key is flexibility. As you say, there is little point in asking somebody who is going to be working with compilers the best way of doing something with React or Angular.

A guy I used to work with would walk through the technical skills section on candidate's CV asking for knowledge level out of 10 and then ask questions accordingly but that is trickier to do on an online platform (at least as far as I'm aware)

I recently had a job interview where I was asked about skills on my resume. Except on every question the scale would change.

For example. On a scale on 1 to 7 how do you rate your self on Linux Then, On a scale of 1 to 9 how do you rate your self on AWS.

It was maddening and I could couldn't give an honest answer as I kept getting confused. That is one of the many reasons I declined a second interview with that company.

Why change the scale? that would've confused me too

I guess the interviewer thought the scale change would make you think harder about your skill level ...

Many interview processes avoids trivia for pure problem practice. Either some real life problem setup designed to fit into 45 minutes, or...Leetcode problems. Only the latter are immune to the specialization problem, but have little bearing on the job actually to be done.

be more open-ended?

> Can you give us an example of a time you used a database index

Hey this query is slow, what could we try doing to speed it up?

Everyone is forgetting why big companies do interviewing the way they do. It's the same reason the entrance criteria to elite universities are they way they are.

Last I read, Google has something like a thousand applicants for each position, each level of filtering reduces the amount by an order of magnitude for a position they may or may not fill so it becomes statistically harder than being accepted to Harvard.

Likewise, people practice for these interviews harder than they do for college entrance exams and work on saying the exact things the interviewers want to hear. In essence, the filter is on this particular kind of "grinding" work ethic.

As somebody hiring more regularly now, I can sympathize. I'm usually operating on the notion that interviews are demonstrably not a very good way to select people. They are pretty random. I tend to embrace this and focus on the big picture: which is do I want to hire them.

So I have only two big topics in my head.

1) Verify that this person is competent by getting to talk about anything remotely relevant. The job here is listening; not asking. If buzzwords come up, ask follow up questions. If someone is a bull-shitter, it will show in minutes. I have some generic questions that I can put in to keep the conversation going but usually, I just focus on stuff on their CV that interests me. Tell me more. Anything. What do you want in a job? Why?

2) Establishing whether I like the person enough for further collaboration. Yes, this is super subjective. But the way this business works is that anyone passing #1 you basically should hire unless you have a good reason not to. Not liking them would be a red flag.

Most of the rest of the interview is selling them on the job and figuring out whether that even remotely aligns with their expectations. This is a sales pitch. As an interviewer, your job is getting the candidate enthusiastic about working with you. If they are good, they'll have other offers lined up. In other words, it is you the interviewer that needs to be nervous about whether they will say yes; not the other way around.

This is the most important step in the interview and this is where you either get somebody enthusiastic about working for you or disengaged. If that's the case, don't hire but if they show eagerness, interest, etc. you basically try to hire them.

It's not like we have a long list of candidates typically. So, decide quickly and act with a sense of urgency.

When I'm interviewed, I think of it as a privilege for the wannabe employer. You successfully got introduced to me by somebody I trust. We talked and I liked you somehow. Now we are talking shop. Your job is to make me want to work for you. Sell it to me. Make an effort. Don't waste my time with bullshit. I'll talk to your HR after you convince me I'm not wasting my time; not before.

So these kinds of posts keep showing up.

How are interviews for not-software-engineers conducted? ie. how do you interview for a business analyst role, or a sales and marketing role? I have to assume that those roles suffer from the same sorts of issues a SE job does -- that someone can talk a good game but not be able to perform in the role.

Research shows that the two best ways to screen candidates are a general knowledge/IQ test (which is mostly illegal in the US) and a work sample test.

The fact that a work sample test predicts work success makes a lot of sense - have them do the thing you want to pay them to do and evaluate how well they do it. Duh!

You should screen folks using the work that they are going to be doing for you. Are you hiring someone to code on a whiteboard? No? Then why are they doing that in the interview?

Doctors have to go through a rather grueling licensing process. The job interview is mostly about determining mutual interest.

Doctors also need to go through periodic re-credentialing.

To put it bluntly, when a doctor has credentials, you at least know that they're competent; and more competent than 2-4 1-hour quizzes.

Speaking as a licensed attorney, passing the bar does not mean that you're competent.

But if you were applying for a position at another firm, what would they likely look at to determine competency?

I'm not a lawyer - but my guess would be how many cases they've handled in the past, whether those were with another firm or by themselves (not sure what this is called - if anything - "self-employed lawyer"?), and how the case turned out and such (though this latter thing may not tell you much - after all, they could be a great lawyer and candidate, but lose every single case not based on anything they did or didn't do).

As you can probably tell - I really don't know what I am talking about in this area...

Then how would you go about identifying a competent attorney?

References and talking to them.

The bar exam is different than what doctors go through

Years ago, I was interviewing, and they asked me a fairly typical "Design Twitter" question.

I always hate these kinds of questions because it took Twitter 10 years to get to where it is, and I'm certain they didn't design all of it in 15 minutes on a whiteboard.

Anyway, I'm drawing little boxes and arrows, and when the subject of a DB comes up, I ask "do you want availability or consistency", because I figured that CAP theorem was part of the "gotchas" on this. The interviewer said "I want both", to which I replied, kind of sheepishly, that you cannot have both. We go back and forth, and eventually I pull up the CAP theorem wiki page on my phone and he had to concede the point.

This is rare; usually when I know more than the interviewer, they double down on their wrong ideas. I have several stories like that.

Did that interviewer hire you after admitting that you were right in pointing out his mistake?

The company made me an offer, which I didn't accept, though for different reasons, mostly with me having skepticism on the sustainability of the company.

Joke's on me, I think; looks like the company is doing better than before, the stock package they had might have made me about $400k.

I think the point is that big corporations don't believe in the value and depth of talent. They're not trying to find the world's top software engineers; they just want to find enough good engineers to fill their quota. What that means is that they don't care about depth. They don't care if the candidate is a genius in their domain; they just want to hire people who can reliably solve coding problems; that's it.

It's quantitative, not qualitative; it's not about how well the candidate can solve problems - The 'if' is much more important to them than the 'how'. Unfortunately, not many people have the ability to objectively measure the quality of a technical solution, that's why they don't bother at all with the 'how'.

Honestly these days I'm thinking that the best interview is going to be about people's attitudes and opinions. e.g. I usually ask things like what's your favourite source control system, branch technique etc? Why?

There's no right answer here, other than to show thought and understanding of the engineering problems this is seeking to address.

Obviously there should be some domain/framework/language specific things in here too. But the object is to gauge competence and experience level, and thoughtfulness vs doctrine.

The 'practical' should take place on the job, give them a week and if they aren't up to the task(s) at hand, say goodbye and move on.

I've helped hire 3 software engineers to both work with me and mentor me and they were all failures.

First two hires quit after only a few weeks.

Third hire was temporarily successful. He eventually revealed himself to be both a jerk and not very technically skilled, so I spoke to higher-ups to get him removed.

My hiring strategy was designed to be simple and respectful. A simple, 20 minute assignment completed between phone screening and on-site. And 2 on-site interviews. Despite the 3 failures, I still feel like it's a good strategy. But evidence says otherwise!

You didn't even mention what those 3 interview questions are like which is the whole point of this discussion. You made the conclusion with 3 data points. I could just as easily make a conclusion about the common denominator of all this which would t be fair to you.

I'm unsure why you think my anecdotes of failures hiring software engineers is not relevant to a discussion on how to not hire software engineers. I think you misread my comment, because drawing a conclusion on my hiring process from 3 data points is exactly what I'm not doing.

Get them to ask a question on stackoverflow without it being closed or put on hold or marked as a duplicate.

While that is probably useful in its own way I doubt it would show whether someone can write decent code or not.

If they can pass this test they can solve any problem

Closed as being argumentative or objective question. Be specific.

> How to check if a linked list has a loop? Does one N-dimensional box fit into another N-dimensional box? Can you swap two variables without a third one? How to find the shortest distance between two moving ships? Find all permutations of N elements doing only N-1 swaps?

> Those puzzles are fun to talk about and solutions to them can be very insightful. I used to enjoy lots of them reading Mathematical Recreations and Essays as a kid. Don’t take me wrong, they are fun.

> However, no matter how fun they are, they are merely anecdotes. The property of a puzzle is that you either know the answer to it or you don’t.

I disagree with how the author lumps these questions together. Questions like "Find all permutations of N elements doing only N-1 swaps" are actual brain-teasers and typically require a flash of insight and creativity beyond what most people can do within a 45 minute interview. Questions like "Does one N-dimensional box fit into another N-dimensional box" are algorithmically challenging and can be approached from first principles and solved within an interview. One question does not carry signal, the other does not, and by categorizing them together the author suggests that neither are useful.

Now I really want to know how I save myself before the candle burns through the rope.

Spit on the candle. Grab the rope in your teeth and just hang on until rescue comes. Lure another animal over with mating calls to distract / feed the lion. Swing back and forth by wiggling your feet and neck at the appropriate rate to swing yourself up onto the branch.

*note that it sorta doesn't matter because cats are notoriously good at climbing trees and likely wouldn't wait for you to fall.

> The property of a puzzle is that you either know the answer to it or you don’t. It doesn’t tell you anything else. It has nothing to do with future performance, being smart, capable or anything else whatsoever. Knowing a particular answer does not mean you have an apparatus to solve real problems in a generic and predictable way. The only thing it tells you is that the person has been in a situation when someone shared a solution with him. Nothing more, nothing less. Just stop already.

Oh come on. It's true that people seeing the problem before is a major confounding factor, but it sounds like the author is saying that nobody ever solves the puzzle in the interview and it's a pure coin flip. That is obviously not true.

The puzzle type questions probably aren't a great fit for startups, but they're not meant to be. Big tech can afford the vast numbers of false negatives that they produce. In return, they're able to effectively conduct IQ tests of candidates without running afoul of the law.

As a recent candidate I've set my LinkedIn profile to actively searching and have a highly in demand skill set in the SRE space with a decent amount of experience in a booming city, so not technically full blown software engineer but similar enough. Having gone through maybe 5 or 6 interviews in last couple weeks of those interviews, one company, just one has had what I would consider a reasonable interview process:

1) Take home assignment with extremely clear instructions directly related to the job.

2) Discusses the results of the take home assignment over video conference call, and/or in person, and actually asks specific details about it.

That is all I ask. Most of the other interviews either are all conversational in nature, white boarding, or don't actually evaluate the take home when you are done with it. My conclusion is nobody knows how to hire and maybe I should switch to becoming a starving musician full time instead.

Honestly, this article sounds like a rant.

Hiring is hard. A lot of interviewers aren't good at it. Every technique that gets promoted has flaws.

We could be like doctors and have a grueling licensing process, and then interviews that are mostly about finding mutual interest. But, I don't think most of us like the idea of a licensing process.

What i've noticed recently with interviewing candidates is some lack the ability to work outside the way they work normally, especially in practical tests.

Things like, "I usually work from home, so its too difficult to concentrate in this meeting room", "I use Windows, so writing code on a Mac is really hard" and the most common for some reason for why the technical exercise isn't working "Intellij usually saves the file for me"

Practical interviews are difficult to get right on both sides, but from the side of the candidate, I feel there has to be some ability to handle those situations, under pressure, with confidence.

Unless the IDE you use everyday is the whiteboard, these are all fine and valid criticisms of your hiring tests. If you want to see real-world results, give candidates real-world conditions (including their preferred OS/IDE/workspace environment).

> under pressure

is this a common occurrence in your company? people expected to code well under direct supervision and a strict short time limit?

Hackerrank interviews done with video chat literally have a person's face watching their screen which updates as you type. I had an hour to write a few functions and the person interviewing had the ability to run the tests

I hate hackerrank. The experience writing the code is terrible. You have to scroll up and down the page to remember what they want you to do. It's barely a text editor and slows down how fast you can actually write the code they want under the timelimit.

If you're a complete novice with Windows, using a Mac for the first time will be similar.

If you have years of muscle memory and shortcuts and knowledge about Windows OS, switching to Mac OS will be painful. Not least the different Cmd/Ctrl keyboard placements and shortcuts.

Also, those universal text editing/navigation shortcuts on MacOS?: they're emacs shortcuts which don't exist on Windows OS.

Well to be honest, I once had an interview (and got the job) where I had to use a Mac for the programming test.

It was a rather annoying experience when you are not used to it and some of your time does get lost fighting with the system.

In this case, I do think it was a good thing because everyone in the company had to work on a mac. I do believe it's not a reason to complain, just work with the tools you get, but it might impact their performance a bit

We ask a programming question that's harder than fizz buzz but not terribly difficult. There's an opportunity to get the gist, but miss some edge cases which leads to good conversations. When I go in to discuss the solution, I ask how it went and we end up with three scenarios:

1) candidate is modest (it was pretty tricky but I think I got it) and they did a good job

2) candidate is modest (it was tough I think I screwed X up..) and they made some major mistakes

3) candidate says it was easy and totally blew it.

I've yet to have a candidate who said it was a breeze actually ace it.

Thank you for writing this. I really hope common sense prevails soon. I have no idea how we got to the point where the "test" for a job has nothing to do with the job. I think senior engineers and tech leads need to actively work to kill this culture. I personally will never interview someone for my team by using some random questions from the internet that have nothing to do with what the candidate will work on. Again, great post

So, how do you save yourself before candle burns the rope?

sing Happy Birthday to the lion

You're hired!

Saving youself before the rope burns is easy. After the rope burns is more challenging.

Trick question, candle aint gonna burn the rope there.

You pray for rain

Here's an idea for how to actually do a technical test (if you do want to do one).

1. You bring the candidate in to your office. You have their future desk already available with computer and development environment already functional. Pick a somewhat standard environment configuration.

2. Have an exercise already prepared. Best option is not a "build this from scratch" but have something that already works and needs some additional feature. Something small that could be done in, at most, an hour. Another option is two or three smaller tasks that together would take as long.

3. You give the candidate incomplete information. You describe the task clearly and in a mostly complete way, but leave out a number of details.

4. Very clearly explain these things. One: You won't be on them; this is not pair programming and they should feel at ease and free to do however they want. But you will be sitting in the next desk and you will be doing something unimportant so they can -and should- ask you anything and all they want. They can also use S.O. or whatever search service they want but you'd prefer that they asked you first. Two: You won't be looking at their code unless they want to show you. Three: they have around one hour, but time doesn't matter that much. If giving out more than a single task, indicate that they won't be judged by how many they manage to finish.

5. During that time, you focus on the questions they ask you. What they ask, how they ask them, which problems they face, what things they do or don't understand. This is the key. This is what will tell you about how they think, what things they know and which ones they don't. Keep an eye on them, if they seem too quiet you can interrupt them with simple "how's it going?" or "something wrong?", but don't push it too much so that you don't stress them. You may even suggest a 5 minute break for a coffee/water half-way through if you feel they might need it.

6. The whole idea is to get them to do some task but more importantly to get them to talk about it. When they are done, or when enough time has gone by, don't go over their code. Instead, ask them how it went, what they managed to do, if they got stuck. If they got it running, they can run it. If they want, they can show you the code or part of it. but you don't need to focus on that. Focus on their talk.

7. Finally, do offer them the option of showing the code. But then, get them to show it and explain it. Don't just go over it yourself.

8. The task(s) should be adequate and reasonable for the role, of course. But try to lean on the easier side more than on the harder one. And remember: do leave some information out. The task should be clearly understood but not finely detailed so that they will need to ask and maybe even make some decisions. (You can make them have to decide something by giving them more than one option as answer to some question.)

Thanks! This is a nice approach which I will try with our next front-end-candidate.

Currently our process consists of three exercises: A small website-layout where the candidate has to fix two styling-bugs and equalize some container-heights (CSS-Part); a Palindrome-Function (JS-Part); and a discussion where we look at a webpage-layout, and go through how they would structure it HTML/Component-wise and talk about general topics that come up. But I like the colleague-like approach of your way and guess that it'll work better in our case.

Can you name an example of an app which the candidate has to extend?

> Can you name an example of an app which the candidate has to extend?

Oh, it can be almost anything, but it depends a lot on the role. For the kind of work you mention you could, say, give them an already built layout and ask them to add some additional component or section, or to rearrange some parts. Maybe add a form similar to some other one in a different page. Or something like "add an option for this block to be hidden/shown depending on a configuration". Really anything can do.

I've sometimes had success picking up some minor tasks that we had already done in the previous months. Using things you actually work on is nice. It gives them some sense of what you do and gives you good knowledge about the task and possible difficulties. There's the risk of becoming biased towards the particular solution you implemented. To combat this I sometimes pick tasks I didn't work on myself or that I wasn't completely satisfied with the solution we achieved.

In all my years of interviewing (~25), I've only had this happen once - I got sat in front of an internet connected laptop, given a perfectly sensible task, and left alone for half an hour.

Most of the time it's "solve this already thoroughly solved problem in your own time but with {one hand in a blender, whilst you're on fire, without using any variables}" or some such bullshit.

About the same - I had one 'interview' where I had to write a client and server in C++ that would allow clients to register network MAC addresses with the server along with some associated data and then retrieve it at a later time.

Took me a couple of hours, interviewer said my code wasn't particularly "object oriented" but I got the job.

The irony of this was it was for a Director of Engineering job where I didn't do any coding! :-)

In my similar amount of experience... I have seen an approach similar to this maybe twice. Sad, yeah.

I have used it, though, when I had to hire. And it went fairly well. I don't have any hiring responsibilities now so I haven't had the chance to use it more often.

I agree and disagree with a lot of points.

Most importantly, writing programs on whiteboards. I hate this, but it's an insightful way to measure the individuals thinking processing, decision-making skills, and communications skills.

Expect them to fail and see how they handle the situation and themselves.

To me, a good software engineer is the one who could figure out the issues. In most of case, it's not about the solution. It's about identifying the issue is the hardest part of the job.

Maybe of topic, but: I find it interesting that the author lists user experience in his "what I would like to talk about" list yet uses super bright yellow as background.

Read it on mobile, found it surprisingly nice. On a large monitor I can see it being a bit annoying.

I found it surprisingly comfortable to read :)

At my company we don't bother with specific problems. When we ask a candidate: "If you were asked to build x program how would you go about it", the answer we are looking for is along these lines: "I would go online and find someone who has already done the problem and replicate/alter it to fit my needs". The majority of the questions we ask are like: "Where do you see yourself in 5 years.", "What does our company do?", "Present us with a time when you had to overcome a challenge and failed.". If your going to work with someone then its best you know that they are capable of learning. After all, a degree isn't about proving you know something, it's about proving you have the ability to learn and fight for that knowledge when necessary. It proves you have drive and direction in your life; important qualities in a candidate.

I just started using an ToDo app called "Remember The Milk", and it works for me so far. The next time I get an interview question that asks me to make a ToDo app, I'll be tempted to respond with "I already have one that I like. Why don't you try it, and if you don't like it, tell me why." I doubt that would go over well, but maybe it would. Who knows!

It depends on how the question is phrased. If they hand you a white board and say: "Show us the code" then you are going to have to build something. However, if they ask you something like: "If we asked you to build a ToDo app that solves x problem, how would you do it?" Then it's reasonable to assume they are open to more solutions than you jumping up and grabbing a marker. Being able to distinguish those differences is also important.

Reply on news.ycombinator.com