>>> correct a design when you have 100 lines of Java code written before I really understand
Holy Cow. 100 lines in an interview ? I had an interview like that once and never again. Want to see 100 lines of my code - github.com/mikadosoftware. In an interview - no thanks
Look we all know interviewing is broken. Hell I have worked with people for months before getting to know them and their coding styles. I think ultimately we are all being a bit too privileged about this : Hiring has three states, acquaintance, friend, spouse.
Some people are not skilled enough to be a work collegue - fizzbuzz and 20 minutes chat tell us that - we all know people who after 20 minutes we think we will pay money to avoid the next 20. Fine
Friends are harder - we gel in some fashion. This is the mid point for most of us - as long as we pass fizzbuzz / basic design, then we can make things work. Yes it might have friction but we can make it work.
Spouse is obviously the perfect level - that ideal together.
I fear that far too much effort is put into finding the perfect spouse in an interview - when really we can be fine with a friend. (no benefits!)
Had an interview (one of my last formal interviews I ever did) back in 2002 where the developer gave me a computer, no internet access and Notepad (not Notepad++, or an IDE or anything decent) and said I had to write an entire generic double-linked list class in C++. Without access to documentation or a compiler. In a room. On a folding chair. Without a break. I had two hours to do it in. I cranked out around 1,100 lines of code.
The interviewing developer was all smugness when looking through the code because he didn't like my bracketing style, or my variable style, and so on, and pissed and moaned because I had a couple of syntax errors in the entire class.
I was offered the job. And I turned them down. I did it to prove I could do it. Then I walked away. That was pretty much my last ever formal interview.
I had a second interview about the same - was given a Linux PC in the corner of the office and asked to write a simple client server system in C++ that registered clients based on their MAC address.
They left me alone for two or three hours and didn't speak to me and at the end I had a chat with the CTO about the code and he was happy enough and all was OK.
The main bit to me was they left me alone - if someone had asked me anything, or even worse, watched me coding I would never have been able to do it.
Likewise. In one interview, I was given a short task to write some simple multithreaded C++ application before the interview. IIRC it was just a bunch of timers running in parallel to trigger events. During the onsite, they said here's the code you gave us, now here's a laptop, make it a client/server system in the next couple of hours.
The time pressure didn't hurt. Had to remind myself about the order of all the necessary system calls on the client and server side to set up the sockets, listen and connect, define a suitable message format, and whatnot. But I had a working client and server talking to each other doing their thing.
What I like about this style of interview is that it demonstrates your ability to be given a high-level problem and then go through requirements, design, implementation, testing then when given new requirements, iterate over the process to meet them. It's much more representative of day to day job requirements than a whiteboard. And being thrown that challenge shortly after coming onsite demonstrates that you can handle the pressure of being given new requirements and new tasks out of the blue and roll with it.
Amusingly enough I wasn't being interviewed for a developers job - it was a jack of all trades Director of Engineering job. I didn't write a line of code when I worked there....
I also think the industry as a whole would benefit from more fluid movement - easier to get hired means it's also easier to leave. Honestly, lots of hires (including myself for some places, I'm sure!) seemed great early on but then didn't quite work. Does usually take 3-4 months to feel that part out. And then eh, this isn't quite working, and I'll see you later. Or, as often, eh, wasn't sure how things would go but actually we work great together.
Bro why are you asking me to paste code I can memorise?
Because fizzbuzz isn't about the code. It's a starting point for a candidate to show an ability to code something, and an understanding of the requirements, and an ability to talk about their code and why it does things in the particular way they wrote it, and to discuss what the next steps would be (streaming, optimizations, etc).
If the coding test is literally just 'write fizzbuzz' then it's a terrible test, but if it's more like 'write fizzbuzz and then we'll talk about it' then it can be a great test.
Coding interviews (and just coding as an art really) should never be about solving a problem in a limited amount of time. The problems we face as developers usually need a few rounds of thinking, experimentation, more thinking, implementation, optimization, and so on. You can't do that process properly in an interview. Using things like fizzbuzz is an attempt at a shortcut.
Also, as someone who interviewed lots of people and used fizzbuzz as a test in the past, I can assure you that simply being capable of implementing it takes you out of the bottom 30% or so. Being able to talk about it and suggest ways to do more with it, or to extend it, would put you in the top 30%. There are a lot of developers out there who are not great.
EDIT > just to be clear, I am completely aware of the different reasons you ask for fizzbuzz, but I know that the question can be completely rehearsed and revised with a few minutes of work. If you are using it as a metric I feel you are a poor judge.
In my experience, I have been unable to comply with the fizzbuzz questions in interviews - which has generally ended with me or the interviewer slowly closing the interview.
At the same time I was one of 2 people who built a major airlines checkin system within a couple of months.
The interview for this role? A phone call, after looking through my CV.
The roles which asked me fizz buzz? generic roles in companies that since went nowhere, I even got a callback telling me the technical hiring manager had since been fired ( or left ) and if I would re consider interviewing, which I then had to turn down.
I am not saying you are wrong, I am probably wrong to judge a person if they are assessing my years of experience with a test aimed at an 18 year old.
But be aware of how fizzbuzz makes some developers react.
I don't want to screen out good candidates, and I'm genuinely curious about your experience.
If you have no problem building a major airline checkin system, you must have some practical skills. Can you explain why you couldn't implement fizzbuzz in an interview? What went wrong?
If you designed an interview question which would show off your skills instead of undermine them, what kind of technical questions would you like to be asked instead?
If my friend said to me in a bar "tell me why computers are good" , I would have a deep conversation with him that would cover different domains from philosophy to the sciences.
If an interviewer for a job, requiring a specialist in 4 frameworks, 2 languages, a nosql db, cognito authentication, a complex portfolio which matches the job spec and real world examples of viable commercial products, sat me down in a room, and asked me to answer the same question, as an opener, and it was timed to a minute - I would flounder.
The experienced dev vs the fresh graduate
Sure I could have done some research into the several domains, written down a good short concise answer, which covered a general aspect of each domain and recited it. However I did not.
I would have no reason to prep for such a question due to the amount of time Ive spent in the commercial sector developing solutions rather than rehearsing interviews like a fresh graduate who has never programmed before would do.
Can I solve the problem? Ofcourse, but not as quickly as someone who has revised for it, even if I take a couple of minutes longer, it would be taken badly - regardless of whether it was rote or freshly devised.
You arent selecting for a good developer - you are selecting for someone who has had the time to prepare for interview questions ( a massive red flag in my book )
The answer? Atleast for me.
Is he experienced? Does the conversation flow naturally? Do you feel he is a loyal, dependable person who can clearly communicate? Well I would say that covers 90% of the issue. Hire the guy, see how he performs.
This makes sense. But I'm still confused about your struggle to implement fizzbuzz in an interview. Fizzbuzz doesn't need you to understand 4 web frameworks and a nosql database. Its like, 5 lines of code. What happened?
> Is he experienced? Does the conversation flow naturally? Do you feel he is a loyal, dependable person who can clearly communicate? Well I would say that covers 90% of the issue. Hire the guy, see how he performs.
Interesting idea but unfortunately this isn't a viable strategy. There's a mountain of people who are perfectly charming but can't program, and we need to screen them out. And there's plenty of great programmers with awkward social skills who we would love to hire.
A few years ago I interviewed an Indian developer with broken english, who'd spent the last 10 years working on Oracle internals. She wasn't charming or a good conversationalist and her resume had obvious typos. I had very low expectations - but when I interviewed her I realised her technical knowledge was top notch. It took both me and my boss to bat for her for the client to give her a chance. But she ended up outlasting everyone else on her team. The company we placed her at absolutely adore her now. If I didn't go deep on technical content, I wouldn't have known that and we would have passed her up.
I have no knowledge of the specific, but I think most people have experienced a freeze up in an interview - I certainly have. (I tried to reimplement basic math functions on a coding test - I still have no idea what happened)
That's why there is no silver bullet - fizzbuzz is an indicator. But we rely on expertise to spot itself - or spot potential. Which is why we need to be careful of just cloning ourselves and our cultural biases.
For example, you could put your Indian dev in front of me and I would not have the Oracle depth to recognise her as skilled enough to go to bat for. But Python internals? Yeah maybe. PostgreSQL once upon a time.
Im going to move off fizzbuzz because I feel that I have explained my position well enough.
Regarding the developer with the broken english, how long a developer stays in a team is not necessarily a good sign, the others could have left because she was hard to work with.
However you said the new company liked her, so thats good, maybe she was great.
When you made your last point about "going deep on technical content being good" I don't think you've understood my point of view very well.
I'm not saying not to ask technical questions, Im saying ask complex ones, where possibly relating to the developers experience.
I had one experience in an interview where I couldn't context switch fast enough to answer a simple technical question. It was for a CTO job and I was asked to prepare and present a presentation on "how to launch a product" - I think I had 30 minutes to prepare and 30 minutes to give the presentation to their management team. This went really well.
Then the CEO wanted a quick chat and asked me a simple technical question - and I could not do it. My brain simply froze and he clearly thought I was an idiot or some marketeer pretending to be technical. The reverse being far closer to the truth!
Edit: I've interviewed a lot of people over the years and would never had believed this could happen until it happened to me.
Same happened to me. I remember thinking " these 2 interiewers are thinking Im thinking about the solution, but Im not, my mind is blank because of the stress of having to answer a seemingly simple question, but I know if I say the slightest thing in the wrong way Ill be judged harshly for it"
I realise this is a problem with me and stress during long interviews, but it was still a little funny at the time.
When I interviewed regularly I felt like that was probably the biggest difference between a great interviewer and a terrible one. Any decent programmer can ask technical questions, but great interviewers will do everything in their power to help you stay relaxed and calm while you answer them.
When you get too stressed, your creativity then your memory stop working properly. So its simply impossible to fairly assess the technical skills of a candidate while they're on their way to a panic attack. Knowing how to keep people calm is rarely on the job description, but its an essential skill of any good interviewer.
The big problem with implementations in interviews (or coding challenges in general) is that they don't test what the interviewer is thinking they are testing, and it is usually a clear indicator that the business looking to hire has some major shortcomings in their developers.
For what it's worth I've been on both sides of the table. I don't bother with code when I interview because it's a waste of time. I may show a (non-critical, not-worth-NDAing) section of code to a prospective employee and have a discussion about it, but in general I can suss out whether someone knows what they are doing in less than 30 minutes just by having a conversation with them. Why make the applicant or me wade through 2-3 hours of code and not get a sense of what they are truly capable of when I can talk to them for 30 minutes and assess their technical ability, communications patterns, and fit for work culture simultaneously?
The smartest people I've ever worked or interviewed with don't bother with code as interview.
> one of 2 people who built a major airlines checkin system within a couple of months
That doesn't tell me whether you can code; it's entirely possible the other person did all the coding and you did architecture, requirements, user stories, testing, integration, office politics, SnapChat.
You might still be a great asset to the company; my job as a technical interviewer though is to assess whether you can code.
Makes sense, and I'd be ok with that, but I would suggest that the first version of fizzbuzz is given to me, bit that I have to write it. Then we can already start taking about it and do alterations etc.
As an aside this reminded me of "benefit of clergy", where one could get a reduction in sentence if you could prove you were literate in court - by reading out a Psalm in Latin. Now, as it was always the same psalm, illiterate people could memorise the psalm and recite it as if reading.
(of course this was a legal fiction to allow courts to avoid handing out death sentences to all comers).
The thing is fizzbuzz is like Miserere Mei - it's a quick proxy for a form of literacy. Yes, anyone already literate could easily swot up that psalm. But anyone not literate could only learn the words off by heart - and any simple test such as read the next psalm, would unmask them.
So the easiness of fizzbuzz is kind of the point - we are not trying to work out if you are Phd or undergrad level. Just literate.
> this reminded me of "benefit of clergy", where one could get a reduction in sentence if you could prove you were literate in court - by reading out a Psalm in Latin. Now, as it was always the same psalm, illiterate people could memorise the psalm and recite it as if reading.
IIRC, until the literacy test was abolished and the benefit made generally applicable to first-time offenders, the judge had the option of demanding a different work.be read if he suspected the privilege was being abused.
> (of course this was a legal fiction to allow courts to avoid handing out death sentences to all comers).
Well, it evolved into such a fiction (and eventually even the literacy test was removed). But it didn't originate as one, and didn't originally involve a sentence reduction but transfer to ecclesiastical court from secular court.
Fizz buzz is great in a nihilistic way. The interviewer is basically saying “It’s impossible to judge coding skill in a short interview. So I’ll just make sure you’re not a total fraud”
If you ask me about fizzbuzz I'll complain. Or maybe try to do it in a quirky way
You should have addressed if the candidate knows how to write basic code in the phone interview, not wasting my time with a stupid problem on a whiteboard
Fantastic - you have just shown an ability to play with code, indicating you are likely to be good at the basic part of the job. Honestly "fizzbuzz" is short hand for "eliminate the set of people who apply for every coding job, but have no ability to code, or can only just take existing code and twist it about"
(this last I used to think was laziness, but I think there is an ability to execute code in your head that is necessary - and if you can't do that then making any changes to a code base is scary because you cannot reason about it.)
Do I use fizzbuzz anymore? No because it has been years since I have had to go "out to market" - but if I am interviewing you then I will have checked you pass this - reading your code, talking to co workers. I don't go in cold very often any more.
But you are also eliminating those that "feel" its a question that should not be asked to experienced developers that would otherwise be excellent hires. I seem not to be the only one.
Till you found somebody with 10+ years of "experience" who can sell himself well. We skip this question because of seniority. Hire him and turns out he struggles with basic for loop. This happened at my previous company.
I suppose it would eliminate those that would walk out of an interview if asked to do fizzbuzz. I guess if someone genuinely objects to the "easy" question we can jump into some harder technical areas but I would definitely see it as a red flag.
Will they refuse to manually fix up the test data because it is "beneath" them? Will they think that getting the HTML to float right on that screen is for juniors only?
Disclaimer that I work server-side. This is not applicable to all of software engineering by any means, but if you want a more technical answer than those the article provides: concurrency.
It's 2020: computers have multiple cores, and it's great to know how to use them, but time and time again I see candidates get tripped up with basic concurrency concepts. Deadlocks in go, event loop blocking in node.js, unsafe memory access in Java or C, they come up all the time in interviews I've done.
"Track the median value in a stream of integers"? No problem. Clean code, no errors.
"Track the median value of two streams of integers which are coming in concurrently"? Data loss, deadlocks, concurrent modification exceptions... Sad times.
I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion. Every language has libraries of data structures already written, but concurrency solutions are often context specific and need handwritten solutions.
As an interviewer, I would not expect most candidates, including qualified ones, to be able to whiteboard the concurrent case without issues, but I would expect them to be able to talk about those issues when pointed out. I'm curious if that matches your expectations as well?
Yeah, of course, I'm not looking for perfect code. Concurrency is hard, and as I mentioned, it's probably the most common problem spot I see in interviews, so if I were a hard-ass about it I'd never hire anyone.
My expectations are that a candidate can identify that there is a concurrency consideration to be made in the first place, and have some knowledge around how to handle concurrency issues in their language of choice, since different languages take very different approaches.
For JS/node that could mean identifying that the main execution is single threaded, so you need to use async/await or callbacks for asynchronous tasks to prevent blocking all other execution. In go that could mean understanding that passing messages is generally safer than sharing memory. In java that could be an awareness of the concurrency primitives that the language has like atomics and concurrent data structures (I could never expect a candidate to fully grasp the concurrency nightmare that is java).
I also usually give candidates a laptop and free use of the internet. I try to ask questions that are more grounded in the actual work we do and not just toy algorithms, which means letting people look up documentation, data structures, and whatever else they want. If we're being honest with ourselves, the ability to effectively search the internet is just as important to software engineering as the coding itself, if not more so.
I recently delivered a big project which was parallelizing a huge computation. I entered the project all gung ho thinking I'm using a high level language (MATLAB) how hard can it be? Turns out very hard, specially if you want to maintain state and operate the parallel computing toolbox even slightly different from the examples.
Please recommend the book I wish I had read before jumping in?
> I know it's a bit more complex than basic algorithms and data structures, but it also is much more important in the "real world", at least in my opinion.
You are right, that is hard. Especially in an interview setting. But I 100% agree that it's better than questions about algorithms.
The best interview I've had was at my previous job as a backend engineer. After the first two culture-fit interviews I had a technical interview with the lead dev and the CTO.
There were no programming tasks. It was a 3-tiered conceptual question on designing a backend system. They asked me how I would do this and that. How would I handle this edge case? What if the user did this? What if the data was shaped like this?
I don't think I even did that well in it, but it was the most enjoyable interview process I have had.
As an interviewer I wholeheartedly agree with this.
I think most egregious problems are:
1) candidates assuming that I am only interested in them producing a solution
2) candidates assuming that I am interested in checking their knowledge of the language or standard library
In fact, the process is mostly what I am interested in and I am pretty happy to give hints and especially when it comes to trivia like what is the name of the function that does some specific thing and what kind of parameters it takes.
I just would like to see how the candidate approaches and deals with the problem. Does he/she have analytical, planned, ordered approach or is everything chaos?
High on my list of things that don't impress me is solving the problem by running the code dozens of times. This shows the person cannot write any stretch of the code without running it because he/she does not actually have a mental model of what is going on and relies on actually running the code as a crutch for their lack of understanding.
If I understand correctly what the guy says in the article, his candidates lose points if he gives them hints.
And about running the code often, what's the problem with getting early feedback? There are people (that I agree with) that run the unit test on the code they're writing every added line or two. Some who also commit every line or two and then squash the commits once the whole "unit" is done. By no means does this mean they don't know what's going on
There is no single right way to conduct an interview. Each interviewer has his own style and I think it is fine.
I think giving the candidate a hint has a purpose and that is to keep the process of finding a solution progressing. Otherwise the candidate may get stuck and as an interviewer this is bad because we are now wasting time to let me know the candidate.
At the very beginning I tell the candidate some of the things that I feel are fine or not fine. For example, I will tell the candidate that I am happy to give out names of functions and lists of parameters as long as the candidate can describe exactly what the function is doing. So I give these for free because in normal work I would expect he/she can find it in couple of seconds on the internet, anyway, and that's also how I do this. What I don't give for free (ie. mentally deduct points for) is give larger hints that would normally be thought as part of the solution.
Likewise, when I start technical question section I tell candidates that "I give 5 points for not answering the question". Most people are quick enough to figure out this means I penalize bad answers and would prefer the candidate to say they don't know something rather than keep talking nonsense.
The post is about candidates' failings, presumably to help them.
The failings of interviewers are whole other, not less interesting, story.
As to your point, it is completely misplaced in that list which is list of problems with my candidates.
When I interview candidates I am expected to do my job which is to treat the candidate humanely and give back quality, actionable feedback.
Why wouldn't I be able to evaluate candidate's approach? Can he solve the problem? If his approach is so good I can't understand it why then he wasn't able to solve the problem?
Why would that happen on a problem I chose? When I put up a problem for my candidate I have already solved it in every imaginable way so I know ins and outs of every possible solution. I do that so that I can stop focusing on the approach and focus on the candidate because that is ultimately my task. I can imagine the candidate providing another solution but why wouldn't I be able to even evaluate the solution if I have spent so much effort on relatively simple problem already?
It is also important to understand, that the job of the interviewer is not to approve every good candidate. The job is to prevent bad candidates from getting hired. It is expected that some good candidates will be lost in the process and it is acceptable, because hiring a bad candidate is much, much worse than loosing a good one. If you loose a good candidate you have a queue of other candidates so the worst that will happen is you will spend a little bit more on acquisition and maybe make a little suboptimal decision. If you hire bad candidate you are tied to him/her for a long time and usually have to expend huge amount of resources before the candidate is finally let go or maybe while he/she stays indefinitely, blocking your ability to find better candidate.
The common theme in this article seems to be about planning approaches to and implementing algorithms.
I think there's more to being a successful employed programmer than that. How do you avoid people who are nice as pie in the interview, but play politics and are rude to people under your nose on the job? How do you avoid people who can deploy algorithms on demand, but have very little motivation day to day and fail to get anything substantial done?
At a job, you're interacting with people every day. I don't think you're looking for the best-performing algorithm every day. In most cases, best performance doesn't matter.
Interviews reveal much more about a company's culture than interviewers seem to be aware of, and this one is telling me there's a bunch of managers at this company who get away with their lack of organization.
If I'm treated like this at an interview I'm going to assume it's the kind of company where seagull managers write tickets with confusing titles and no descriptions, and expect developers to do their job.
>> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.”
I can either think OR talk, I can't do both at the same time. I can happily think and THEN talk but when I've interviewed with companies that have this interview culture (i.e. Google) they don't let you do this. They start telling you they want to hear what you're thinking. Also, most of the time thinking is disjointed and nonsensical and is way faster than what you can express so it's actually disrupting the problem solving. I really don't understand what's wrong with letting people think for a few minutes.
Additionally I am perfectly fluent in English and talk code everyday in English but it's not my mother tongue so having me chit-chat my thinking away while I think (potentially in another language) hinders me since I focus more on what I am saying than actually solving the problem.
>> "My typical work process in a technical challenge like this is to spend a minute or two thinking quietly about the problem and writing down notes, I’ll share those thoughts with you in a moment to get your input"
That's great, but that hasn't been my experience. Interviewers constantly tell you to talk and it's specially bad during a phone interview. I'd be fine if the interview was really setup as a collaboration between two people, but it's not, you're given a problem and a whiteboard.
I'd talk more in code interviews if more interviewers behaved the way these essays say. I struggle to recall a time when the interviewer acted as a collaborator during the interview.
Usually, they'll pose the task, sit back, and stare at you. You ask a clarifying question, but you know you're stalling for time. The task is clear. You just need to remember the LeetCode solution. The interviewer looks at you impatiently.
You take a stab at describing the solution. You say, "I think this is a job for prefix trees," and look at the interviewer.
The interviewer says, "OK," and gives you a look of alarm and pity.
You solve the problem the way you've solved ten very similar problems on LeetCode. The interviewer says, "Are you sure this works the way you think it does?"
You panic. What did you do wrong?! The interviewer gives you another look of pity.
If you're writing live code, you run it with some test cases. The test cases pass. You think of some edge cases. They pass too. You look at the interviewer. The interviewer says, "OK." A moment elapses.
A few days later the recruiter calls you and extends you a verbal offer. Or they send you an email that says that you won't be getting an offer. The interviewer's expression of pity is the same in either case.
Yup. I've had that blank stare interview. I've decided that the next time it happens, I'm going to attempt to patiently explain to the interviewer why that isn't going to get them the information they want. Last time it happened I was hired anyway because this was only one interview of many. It turns out the bad interviewer was a nice chap and very clever, but with no understanding of how humans work. I've found that such people are often interested to know why their interactions are failing. They want to learn new rules that they can add to the personality simulator they run in their head :-)
Absolutely, that's what I meant with my last comment. It's framed as a collaboration to see how you think but that's not what really happens. It's all about jumping through hoops and doing the right dance.
My experience is in the games industry and interviews there are usually more about what you've done which eventually leads to implementation details from where you can easily gather if the person knows what they're talking about.
I increasingly feel that coding interviews are primarily a company's marketing tool ("Look, we have such high barriers to entry, we're exclusive!") rather than real reviews of software engineering skills.
> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.”
> Interviewers want to know what’s going on in your thought process. It’s important that they know how you’re making decisions. How are you qualifying or disqualifying ideas? Why are you choosing to implement something in a particular way? Did you spot a potential problem in your code? What was it?
That is a very good way to hire people that are good at interviewing or selling themselves, not so much for very good developers.
Speaking loudly about every tiny decision you take for simple algorithms is very hard and inefficient. It is even worse when you have a lot of experience, because you just know which designs will be wrong or not without even thinking twice about it.
It is okay to expect communication about the overall design, specifications, input, outputs and behavior, not about the algorithm itself. If spoken human languages were efficient at expressing this kind of thoughts patterns, we wouldn't have invented mathematics notation or programming languages.
> “I wonder if … hmm … well, I was thinking about implementing this as a depth-first-search, but given a constraint around ___ I think a better approach might be ___, what do you think?”
If you have this kind of expectations, you are again hiring people that are good at interviewing, that is all. I have been a developer for 15 years and I don't know how most of the basic algorithms are called in English, because it is not a useful vocabulary in my everyday work.
I make specific algorithms to efficiently solve specific problems. I do not blindly copy patterns from Stack overflow or from a book. I would not know what is a "depth-first-search" unless I start searching and looking for some code in Google either.
You are not hiring me so that I would explain every design decision to you; you are hiring me so that I would deliver solutions about the details of which you do not have the capacity/do not want to think.
A lot of people are badmouthing this article. I think thats unfair. There seem to be some broad misconceptions as to why current technical interviews are designed the way they are. (I speak with the experience of administering over 400 technical interviews.)
First, you have to understand that most candidates who apply for a technical position don't really know how to program. The obvious reason for this is that weak candidates spend more time trying to be hired, and thus they apply for far more jobs than qualified candidates. I'd estimate about half the people who apply for an advertised software engineering position can't program something as simple as fizz buzz. Many of these people are lovely humans, have families to support and are depressed from being turned down from job after job. But if you can't program, I can't hire you for a programming role. And for everyone who's competent, I get it. Simple programming problems are a waste of your time. But as an interviewer, I need to quickly differentiate you from someone who spent 3 days watching python videos on youtube then forked some random repositories into their github account.
As an interviewer, I'm really trying to answer this question: If I put you in a team of programmers, would you be able to meaningfully contribute? If you want to know how to land your dream job, take a minute to brainstorm which what qualities would make you effective in the role you're applying to. Then demonstrate those qualities in an interview. Your list will look almost identical to mine - be proactive, have good communication skills, know how to program, know the domain (web / ios / ...), etc.
If you can't demonstrate a skill in the interview, your interviewer will assume its because you don't have that skill. This is a reasonable assumption and - despite all the grumbling in these threads - usually true. Most people who fail interviews either have poor technical skills or poor communication skills or both. If your interviewer can't tell the difference between you and the mountain of disappointing candidates they're drowning in, its your job to figure out why thats the case and fix it. If you apply for a frontend web position but you can't tell me what a CSS selector is, its not the fault of "the system" when you don't get hired.
Lots of folks here are convinced technical interviews are fundamentally broken. I still haven't seen any fairer way to assess programmers that can filter out the flood of weak applicants. If you think technical interviews are broken, I challenge you to suggest a viable alternative. Please - prove me wrong!
The one thing that struck me, was all the problems were with the interviewee, not the interviewer.
I gave up looking for work, when I realized that it was my job to throw the seed into the interviewer’s nest.
”God gives every bird its food, but He does not throw it into the nest."
-J.G. Holland
I was a hiring manager for 25 years. Hiring people was always a huge commitment. I had to fight like hell for every headcount, and I kept high-end engineers for decades.
I wasn’t just interviewing workers; I was interviewing family.
I could usually determine basic engineering (not just “coding”) skills after a half hour, and without having to write a single line of code. A big reason for that, was because I worked hard to maintain my own engineering chops throughout my management career, and that helped me to relate well with prospects.
Most of the interview was about whether or not the employee would strengthen or weaken the team. Whether they would be conscientious and disciplined in their approach; whether they would be enthusiastic and spend time learning the why of a task, as opposed to just the what.
I was interviewing really senior-level engineers. These were people that would need to write high-performance pipeline code, and most of the prospects had no experience in that particular field. I needed to hire people that would learn new algorithms and techniques. Enthusiasm, flexibility, humility, and open-mindedness were the currency; not rote and bluster.
I also wanted them to know what they were getting into. I wouldn’t ever lie to prospects, and that probably cost me a few, but I wouldn’t want to establish a relationship on sand. I loved what I did, and wanted people that would also love it.
I’m not egotistical, but I am confident in my own engineering (there’s that word again) skill and experience. I don’t demand worship, but I want some simple respect. If you won’t give that to me in an interview, then why should I expect it from you, once you have the free milk? I have had many friends that have left their jobs; uprooted their lives, and headed for greener pastures, only to come back, a few months later, humbled and broken.
If you are interested in me, then you are interested in someone that can make an enormous difference in your company. I’m not God’s gift to programming, but I have a unique mix of skills and experience that could really give your effort a big push.
I’m also a damn decent person, which becomes obvious after a fairly short conversation. I interview well.
> Enthusiasm, flexibility, humility, and open-mindedness were the currency; not rote and bluster.
This is key. And I understand that not every industry, company or team can hire with the goal of keeping people around for decades, but I can't think of a better place to work or hire people for.
I am so sad that you are so cynical. I guess that reflects today's workforce, and, most likely, management.
It was never the company. It was me. The company was a corporation, and they were way too stuffy to do that whole "family" thing.
I kept senior-level C++ engineers for decades (I am not exaggerating). It was a small, high-functioning team that wrote image processing pipeleines for a very well-known company.
I am aware that today's entire management style is based on engineers staying at a company for an average of eighteen months. That's crazy. I worked for a Japanese company, and the Japanese would barely even acknowledge my staff, until they had been there at least a year. It was really important for me to keep engineers for as long as possible.
NEVER underestimate the impact of decent first-level managers. It is often said that armies run on their sergeants. First-level managers are the sergeants of the workforce. I was never interested in becoming a commissioned officer. I liked staying close to the ground. I'm entirely capable of doing extremely good strategy; I just didn't like it. I had to be dragged kicking and screaming into management, and being a sergeant was as high as I could tolerate.
I'm a really good manager, but I also never liked it. That's why I have returned to my engineering roots.
I understand that by family you mean to have a good and strong relationship between teammates, which I approve. But my experience with family-like teams is that you end up with managers that act like they were you father/mother and you an immature child whose every request is a whim.
Pretending that everyone is a friend is not necessarily good either because straightening a friend is much more harder than a colleague, so you end up not taking the right decisions by fear of frustrating and losing your friend.
I agree with rimliu for those reasons. Coworker relationships have to be different than family or friends, but that does not mean being inhuman or disrespectful, and it is not incompatible with a good and fun ambiance.
BTW: I enjoyed looking at your code. It shows a clean, disciplined, quality approach.
I'm big on having an open portfolio. I think that it is a really important component in interviews.
I think an almost perfect interview, is for the prospect to supply some projects, and the interviewer then asks them about their submissions.
Like for me, since I do device control and communication software, a good discussion might be around the patterns that I use to synchronize local model with the server state (spoiler: I use what I call my "staged model" pattern, which I'm considering farming out into another one of my general-purpose SDKs).
Well, I apologize for using the word "family." I guess it's loaded.
You are correct. It is a different type of relationship.
In my experience, I had two primary goals:
1) The corporate strategy and tactical direction.
2) The productivity, cost-efficiency, well-being, and cohesiveness of the team.
My stuff came after that.
In any case, you're determined to find fault with my experience and outlook. I get that. I am quite aware that my approach is orthogonal to "industry standard," and that makes people uncomfortable. No problem. We'll probably never work together, which may actually be sad. I'm a pretty decent person to work with. I wouldn't be surprised if you were, as well.
the best interview would be to pair interviewer and interviewee on a random leetcode problem
otherwise it's mostly just a power trip for the interviewer and a lousy signal.
oh, and people who like problem #19 on project euler shouldn't be interviewing humans.
In fact programmers should not be interviewing other programmers at all, it's not their job.
> In fact programmers should not be interviewing other programmers at all, it's not their job.
In a scenario where a programmer leads a team of programmers, why shouldn't they get a say in who will be on the team? Who else would be in a better position to judge team fit? Or aptness at the daily tasks?
Your algorithm will likely be an O(n^2) (n-squared) algorithm because you’ll be iterating over the data in an exponential way
End of quote.
Ok, so the technical interviewer mixes up exponential and polynomial run-time in a blog post about interviewing. Can you spot what's wrong with interviewing in SE?
That doesn't change the general idea of the post in any kind, although I generally agree that SE interviews are kinda borked.
Still, most companies that interview somewhat thrive despite having a far from optimal process.
I've no problem with it. I understand he means superlinear, and I have both a formal and intuitive understanding of what he's getting at. Getting hung up on such minutiae is unimportant, it's like someone who will correct your "who" to "whom" - it misses the point.
The bigger problem is those who don't recognise the implications at all, or know but don't care. I've worked with both.
Actually I did exactly this when being interviewed, talked about exponential. The interviewer obviously got annoyed and moved on but didn't do the right thing which was to ask me to be precise. Had he, I could have said I meant quadratic. He didn't so we both lost an opportunity.
An interviewee making that kind of mistake is unfortunate an interviewer doubly so.
But putting this kind of thing into an article that has presumably been reviewed by multiple people does, in my view, a fair bit to undermine their credibility.
God, this is just painfully embarrassing. It's a real shame we -- as an industry -- haven't pushed back against these kinds of practices (maybe the pay is just too good). At this point, technical interviews are just a meme.
I've seen people successfully get interview formats changed - even in companies with a thousand developers.
So if you're thinking of advocating for changes, a single enthusiastic person can often get it done!
Of course, you can only ever change interview processes you've already passed and you'll never have to pass again - so many people focus their attentions elsewhere.
Skimmed over the article: Oh, commom problem areas have nothing to do with the skill of coding but only with the skill of being a good interviewe. Kk thx bye
Your deep criticism of technical interviews is welcome! But if you want to share it, you need to do that explicitly, so the rest of us can follow what it is. It's quite common that people post 1% of what is in their mind (often in a snarky way) and assume that they expressed all of it. Then when others respond badly to the snark or totally misinterpret what they meant, it seems weird (or they seem obtuse) because you felt you expressed yourself. Actually that feeling depends on your already knowing the content of your mind and your past experiences—which the rest of us don't. We need it to be laid out explicitly and step-by-step in order to get it and respond meaningfully. That would be interesting. When you do that, though, please do it without snark—we have that rule for a bunch of reasons.
Not a good look for the founder of interviewing.io: "I’ve been coding for a pretty long time. Since 1982, actually. There’s no data structure called 'a grouping' in any language I’ve ever used. So what assumptions are you going to make about the problem?"
Is it that shameful? He chose his words as carefully as anyone should, he said in languages he used. And indeed, a "grouping of numbers" is pretty ambiguous even if you know this exists. It could just mean an array or something more nuanced
Holy Cow. 100 lines in an interview ? I had an interview like that once and never again. Want to see 100 lines of my code - github.com/mikadosoftware. In an interview - no thanks
Look we all know interviewing is broken. Hell I have worked with people for months before getting to know them and their coding styles. I think ultimately we are all being a bit too privileged about this : Hiring has three states, acquaintance, friend, spouse.
Some people are not skilled enough to be a work collegue - fizzbuzz and 20 minutes chat tell us that - we all know people who after 20 minutes we think we will pay money to avoid the next 20. Fine
Friends are harder - we gel in some fashion. This is the mid point for most of us - as long as we pass fizzbuzz / basic design, then we can make things work. Yes it might have friction but we can make it work.
Spouse is obviously the perfect level - that ideal together.
I fear that far too much effort is put into finding the perfect spouse in an interview - when really we can be fine with a friend. (no benefits!)
When hiring set your sights lower ...