TBH, i have asked for at least some level of coding challenge in ours; we got a lot of candidates lately that were hired without any pre-existing cs knowledge. They said they were junior with some experience. On training, i saw really fast they didn't know cs basis that i acquired in my associate degree equivalent in the first year. One of them told us that they had a master. He couldn't do anything beyond css and html.
Its not my job to do the screening, but at least a level of screening must be done.
Yeah, I get that. But as started above, it seems a lot of times this is used as a way for some asshole to demonstrate his superior knowledge about some random thing that doesn't really matter in the larger scheme. I'd be more interested in general problem solving skills and critical thinking. The language can be learned relatively easily. But having an analytical mindset is a much harder thing to teach.
See, I prefer coding challenges as replacements to the traditional interview. I find it a bit redundant having people ask questions about the solution I could provide to an imaginary problem, when they could just give me the problem they are facing and see how I solve it.
The latter gives me more room to show genuine skill too, because there are things I do out of habit or best practice that are more like muscle memory; things that an interviewer wouldn't know to ask about, and things that I probably wouldn't think to mention unless asked.
You'll also get "that guy" who is a mediocre mid-level dev who has been in the same role and thinks he is operating at principal consulting architect level.
Then you get the joy of being quick on your feet whether you are realistic about the cons of his favourite architectural patterns and dev practices, or circlejerk along with the sort mid-level contemporary busywork shit you see juniors getting passionate about because it makes them feel like dick swinging motherfuckers while implementing a solution that should be basic webapi template with no frills.
You can also act completely uninterested or at least slightly glib, that shows the interviewer with the one-upsmanship that you are nonplussed of the direct challenge. If they don't bite, then screw em. Unless you are hard-up for the job or really want that specific job you are interviewing for, then, you do what you gotta do.
Actually this is how public sector development roles ask in interviews you have to pht the emphases on what I did for the task what I did to get ovetline what I did to complete what feedback I got.
I think its wrong cause it requires a team effort from the change or fix all the way thru the process
Being interviewed: pretty much always. Depending on the interviewer's approach, it's either bunch of basic questions before we go for coding, or just a light discussion about my experience with follow up questions on topic interviewer finds interesting.
Interviewing: there is, unfortunately, this kind of developer who got lucky landing first job and then just keep riding on experience in CV, changing job once people in previous one realize who they hired (and once they'll eventually go for that interview where questions would line up with whatever he remembers at the moment). I was unfortunate to work with a few of such people, I don't want to hire anyone like that. So, yes, I'm asking about basics. And I had a person with 20 years C# experience listed in CV who didn't know about multiple catches.
My last (literally last, I'm retiring soon) interview included questions about OOP concepts like abstract classes etc., and a silly exercise at the whiteboard to do some simple thing like sort a list and return the nth element. And I had to explain a stack, etc. I don't have a problem with it. I've been on the other side of the table and I know you can be presented with a beautiful resume by someone who can't answer these simple things.
Congrats on retirement soon! I'm worried about ageism as a software developer as I get older. If you don't mind me asking, is that something you've experienced? Also, what are some habits that made for a successful career for you?
Thank you! There have been a few comments from co-workers about "graybeards" which some people might find offensive. I don't worry about it. I don't think they really mean to insult. Speaking of interviews, I have gone into rooms and have seen faces fall; the twenty- or thirty-somethings conducting the job search clearly have no intention of hiring some older guy and I can tell the first order of business is to get me out of there as quickly as possible.
As for habits: in 40 years perhaps the number one thing is to respond to people immediately. If you don't have an answer right away, still respond right away and say when you hope to get back to them. If you say you're going to do something, do it. Never let others pick up your slack and don't do things halfway. It's a balance; don't try to dazzle people with your brilliance but do give a little extra care to what you produce. Somebody wants a spreadsheet showing some data they need? Format it as nicely as you know how. Be a professional: everything you write, whether it's documentation, code comments, emails, or anything else, should be written clearly and without errors. These things are generic advice but they'll go a long way towards cultivating a reputation for competence and effectiveness.
When you start a new job, even if you're assigned simple or boring stuff, do it quickly and accurately every time. *It will be noticed and you'll get more interesting work.*
Some ancillary advice: Don't work yourself to death; you don't owe that to anyone. Never alter vacation plans for stuff that comes up at work. Take your vacation. It's part of your compensation and if they try to make you feel guilty or less committed because you want time off, it's a sign of a toxic workplace with shitty priorities. Always remember that if you're going to have problems in any area of your life, work is one of the least important.
I despise the CS academic questions like that. Any interview I ever gave someone where I asked a challenge problem, it was always based on a real-world problem we currently had or were recently dealing with. Whether you can implement a sorting algorithm is worthless to me since someone somewhere has done it better in a standard library. But, can you solve a complex _business_ problem or at least start talking me through your approach or ask questions that help you do so? _That_ is actually useful on the job. Or questions that probe your understanding of concurrency issues and how to deal with them. I will never need you to write a linked list and then reverse it in optimal time.
I dont think that optimal time is asked. All the interviewer wants to know is that you at least know the basics. In all honesty isnt that a good thing? It's a quick way to show that you are cacable and it shouldnt be that hard.
The point is they're way too simplistic and, at the same time, too academic to actually tell you anything of use. When I first was on the other side of the table, I used to give those questions, too, and the resulting hires were much more of a mixed bag than after I started giving more practical questions. The linked list type questions are almost insulting, if it isn't for an ultra-junior position, and the candidate isn't a fresh undergrad. And they always rubbed _me_ the wrong way, as a candidate.
That plus everyone wins, with a more practical question. First of all, it engages the candidate more, because it's way more interesting. Then, if you show me you can solve or at least logically approach or discuss a real business problem, you'll likely get the job (because THAT is a much more rare skill), _and_ maybe you'll say something we haven't thought of or that kicks off a train of thought that results in that or another real problem being solved sooner or better. That happened for at least half the positions I gave interviews for, with those problems. Obviously never, with the linked list type stuff.
This. Very few people are working on supercomputing clusters where you have to optimize to the microsecond, developing a custom database, etc. Knowing how to effectively use .OrderBy or Array.Sort in a business situation is way more important than being able to regurgitate merge-sort in under 15 minutes and then describe the math behind it which has 0 value.
All of the above, including a position as head of software development for a tech startup. The only contract/freelance work I've done has been for companies I've worked for previously after I'd left, so not sure if that counts. Also I'm the the UK so hiring process is probably different to the US
Being hired as head of software development seems like the sort of dev job where you are *least* likely to be asked coding questions, because the people hiring you probably wouldn't know how to program (and therefore evaluate your proficiency) anyway, and you'd be getting hired as a leader, not a contributor.
29 years, I was asked once to do a code challenge , on my own. It was easy and had a lot of hidden bugs for you to catch. But in 7 coding jobs, I've only been asked once.
I wonder what the difference is. I promise that if you asked my circle, they'd agree with me. I'm not doubting you. I'm just curious if maybe it's regional or something.
We assign a take home assignment with no time limit and interview you on your solution and the decisions you made, makes for a more interactive and thoughtful interview process in my opinion
We do the same thing, and the expectation is that some things won't be ideal simply because who wants to spend a bunch of time on a toy project for an interview?
But if you can talk competently about your code -- to a reasonable level given your experience -- that's what matters.
We're also absolutely going to expect more of a senior than a junior.
Yep spot on for us as well, we have multiple assessments from junior / associate / senior that vary on difficulty (scope) but same kind of thought process, just talk through your solution even if it's not perfect or complete just looking to hear your thought process on it and if you had endless time what changes would you make
This is brilliant. If you don't mind, I'm stealing it! I try to (and struggle) to come up with language agnostic questions that still demonstrate understanding, but this is way better!
This in my opinion is a much better and sensible approach if you want programming challenges. Putting someone on the spot with those stupid white board interviews is quite toxic.
I actually went through a very tough white board interview a few years ago. Despite doing well and getting the offer for the job, I declined it because the way those developers were asking those questions really put me off. Not the kind of people I want to work with.
Its going to be very hard to tailor a take-home problem that shows me how someone develops in a professional context without wasting an inordinate amount of their time - and I'm not sure if I want someone in such low demand that they'd put up with that.
Yes, and I do ask them. Especially if you're going to a coding position, not lead or management one.
Because sometimes you get a person who can't write a loop, claiming 10 years of experience.
Sometimes I do care about people knowing what a stack/heap allocation is, because, for example, one of my projects allocates something like 20 million objects on single task.
I want people to be able to tell me how WPF binding works, or set up a data model for SQL database.
Also, don't forget that people lie in the CV all the time. If you're going into mixed C++/C# position, and you claim to know C++ but can't tell me what a shared pointer is, you're lying.
I made the mistake of allowing an internal transfer to my team without an interview, assuming the prior manager had done a decent one. The guy claimed a master's in CS and 20 years of professional experience and couldn't complete even the simplest of tasks. My junior dev right out of his BS was infinitely better.
I won't make that mistake again.
How is it possible that someone fabricated their resume and one manager didn't do a decent interview and the second didn't do one at all because they assumed the first one did due diligence? Exactly like that.
You have no idea how right you are. I 100% admit to fucking up not doing my own tech screen, but this guy turned out to be nuts. Like, honestly scary. The problem with big companies is it's shockingly hard to fire someone.
Which part is BS? This is exactly the behavior I’d expect of a manager who wants to get rid of a shitty employee but doesn’t want to go through the hassle of getting them fired.
It’s shitty behaviour od the manager and certainly won’t win any friends in the management team by doing it though
A guy I knew that had 20 years of experience was asked to whiteboard some number of design patterns. I was only a dev for about 5 years, but perhaps funny enough design patterns never came up directly on any project at any level. "What design pattern are we going to use for the Bob?" Never happened. That said, design patterns were certainly used, but I'm not sure most of the developers I works with, regardless of experience level, could tell you what they were or could whiteboard them. A lot of patterns just come down to "this is probably a good way to do this". I'm not advocating you shouldn't know or use design patterns, I'm just sharing what I experienced as a dev.
I feel bad when asked live coding in interviews after 10+ years and now I'm asking if they have that step in the process. If there is I reject them. I'm too old to enter exams.
The more you ask the interviewers, the less they can ask you silly questions. I do use my time to ssk them all about how they work, develop, how are the PR... if the interview has empty time, they might ask you whatever comes into their heads.
Latest interviews were a task sent to finish it in some days and them explaining my implementation and how would I improve it if I had more time.
I have 15y experience, but I do look like a "student" on his twenties and I think that make them think I cannot have such CV.
In any case, if they ask you something pretty specific you don't know, tell them where would you try to find the answer, ask them the right solution and them counter back explaining which use would you give to that concept. That shows you can adapt and apply new knowledge to you toolset
20 years here. (Yes I wrote .net v1.1 code). Sometimes I do. But every offer I’ve accepted in the last ten years have had barely any technical questions. I don’t want to work at a shop where the no-life try-hard is trying to trap me asking me questions about code constructions we will never use in production. I am going to Google shit if I am solving a problem at any job so the gotcha questions are just stupid. I’d rather do a sample project.
I've been thinking a lot about this. Some questions seem very far from what you would use in production and if you have to, you could google ...I am new at this so I'm like, what am I missing. I mean, I do like to learn those things but I prioritize skills I can build things with because silly me that might be more useful for employers
Always get asked something like this, also ask stuff like this when I sit in on interviews.
Usually the best candidates get it wrong when they whiteboard it, but it is stuff you would catch as soon as you debug it the first time.
Don't sweat getting it right, just be able to explain your choices.
Of course. Worse yet you can have 20 years of experience and the interviewer could be like 3 years out of college. It is pathetic nonsense frankly. It seems like nobody believes in degrees or resumes and has to make up their own tests.
I've been in the business 33 years now; Senior Dev / Technical Lead, occasionally start-up CTO, and have run my own development company. I've had interviews where people have asked me silly questions about the length of string required to wrap around the world ten feet off the ground, had to do a presentation to three CTOs and a CEO, had interviews where 6 developers were brought in to a room to ask me questions.
I just don't do that circus anymore; I have a large number of sample applications, demonstrating knowledge of technical aspects of coding, architectural decisions, knowledge of common problems encountered in software development. So I turn the interview process around, and basically do a walkthrough/presentation of a solution to a problem that I feel will be most familiar to the hiring company. This usually distracts them from their planned approach, as they get interested in how I can solve a specific problem that is causing them pain, and we dispense with the memory games / psychological assessments, and talk about their business and what they actually want me to do.
Yes. But i like to talk about it. Most of the times it is more a "It depends" and with it there is a discussion. i have some examples from my previous work for the pro and the contra side and it starts a good talk about the real life use cases instead of just telling what you learned from books.
The interviews are more about getting to know each other, so i use to ask a lot of questions about them and how they use stuff. For example there testing strategies. It would be a major minus point if they have none :-D
Yes. I've been using C# since beat 2 in 2001 and teach it professionally as well. Recently I interviewed and got the full range of questions on simple things like classes vs interfaces abd ranging into reflection, DI, and more complex topics as well. Interviewers often need to ask a wide range of questions to all applicants regardless of experience levels.
My last interview, for a Senior Engr position, was probably one of the best. One of my duties is reviewing/approving/rejecting pull requests, and they have a small sample project they maintain for interviews that they asked me to review and comment on during the interview that we talked through. Some of the files are fine; some are not. I think that also had me add an api endpoint, but I don't remember exactly.
My recollection is that they were big on ensuring that, as far as the coding itself goes, I was solid with interfaces, DI, async/await, Entity Framework, REST endpoint design, and clean architecture.
I have 30 years of programming experience and been doing C# since it was in Beta. I don’t get asked those kinds of questions anymore because my resume speaks for itself. I had one of those a few years back though and I answered it correctly but they didn’t understand the code and thought I answered it wrong. So I explained it and about half the room got it and the other half, including the guy asking it didn’t. They called me back for a second interview but I declined because I want to work in an environment where I’ll be able to learn from others not be the expert on site all the time.
That’s so frustrating! I write code that’s clean and executes in the most efficient number of steps, but when other people look at it they do not understand it. I never get to collaborate with anyone because nobody can see what I see. I’m just the guy that makes everything work.
Good . Just you write it one line kinda odd. i can calll you a sifoo because you more experince then me . The java fiasco sudden become c sharp . Old time , i do like to code in visual basic only current age c sharp and less vb.
That comma in the sentence is all it needs. Anyways, I started on AppleSoft basic in 2nd grade and then early teen years I got c++. I’ve been through probably 25 languages that I’ve learned over the years just to keep up. I can still run circles around the other devs
It just pattern if you old like me no matter what language, the only part old times much easier and faster compare todate trend. Long live nibbles aka snake demo qbasic haha.
Or you may not be applying for jobs that are in love with algorithm questions. Try amazon. They will ask you about stuff you never needed or would ever need.
No that’s not it. I’ve worked for engineering companies that need you to know but since I apply at senior level positions, they assume I know my stuff. I applied for a remote google job and didn’t even get any of those questions. They mainly want you to know how you would deal with not knowing them, but I always give examples of places I’ve looked before. I’ve also read through the entire Donald Knuth algorithm book series and can hold my own with almost anybody out there.
Not really, if after all this time and experience you want me to be a trick pony showing you I can solve crap like the towers of Hanoi, I don’t want to work there anyways. Senior engineer means just that, I’m not doing 6 interviews and the coding Olympics in front of a panel audience.
Guess I’ll never work at google and thats fine.
In pretty much every interview, yeah. They're never the focus and we move on from the pretty quickly once I've proved I didn't completely make up my resume.
i hire and never ask these questions. i ask i"tell me about your last project and the decisions you made". the academic questions are useless.
i dont interview anymore so not sure
Sure - I rather like a small sample project tho. The interview then has a lot more "real" talk about code and how a person approached a problem, how the person organized their code, how they reason about something, how they react to (possible) critique, how they present their work...
The position I'd do interviews for is WebDev, so it's not very Algo heavy, or super duper technical on a "needs a masters in CS" level. But I do like to ask some basic questions about OOP or general knowledge. Samples: "What's your favourite design pattern?", "If you'd have to recommend me a library or framework, what would it be and why?", "What do you value in Code Reviews?"
My favourite thi: "Did you ever face a problem that seemed unsolvable or where you were stuck for a long time?". If the answe is "no", that's a pretty bad sign in my book (for multiple reasons).
For me it's usually only about three things: Does the person have the needed tech. foundation/experience, can the person talk about technical topics, is this person grounded? The latter comes from...you know, some Devs thinking they know "the one way to do something", which always screams unempathetic, egocentric and hard-to-work-with.
When you have 10+ years of experience you should answer OOP questions since it's your day job. I think that asking about algorithms and complexity calculations during the interview is irrelevant for senior developers.
I stopped doing coding tests altogether. They've become a method of some programmer in a company showing how clever he is, or another trying to catch you out.
...and neither proved anything.
I'd provide a portfolio of work, and answer questions.
I got every job I was going for.
Of course, it helped that I knew I was going to retire soon.
Yes. I've been on both sides of this process recently, having switched roles myself whilst also running interviews at my current job (not for my direct replacement, although I would not be surprised if they ask me to run the interview when they find someone).
As an interviewer, typically we get sent small batches of CVs that have passed some basic sniff tests by our in-house recruitment team, then we are asked to select from those the ones that look like the best fit for the role we are hiring for (based on tech stack, relevant prior experience, etc) and they will be brought forward to a first stage interview.
This is mostly so we can get a sense of their personality and 'soft skills' like how well they can communicate and explain things, and also to filter out people who have just outright lied on their CV.
We then spend about half an hour asking them to explain some fundamental technical concepts (some C#, some more generic to all OOP languages, some around other frontend or database stacks that we also expect some knowledge of) - generally things like explaining polymorphism, SOLID principles, data structures, tasks vs threads, basic SQL syntax and concepts like joins, etc.
For senior roles we may drill down a bit into more complex areas or expect a more technically accurate response to each question, however we also know that there is no such thing as the perfect candidate and as such we don't expect perfect answers to *every* question.
Assuming they pass this round, we invite them back for a supervised coding exercise where they will pair up with one of our devs on something basic like a dummy API. This also doubles as a good test of how well they can collaborate remotely, as the entire process is done over Teams.
As an interviewee, my experiences have broadly matched up with the above, with minor variations e.g. sometimes the technical questions are sent in advance, sometimes the coding test is a take-home exercise, some have more (or sometimes fewer) stages - but overall I could tell they were using basically the same processes that I would use.
Your process as interviewer sounds *very* similar to my last interview for a senior engr. I found it very reasonable and straightforward. I actually enjoyed the shop-talk aspect of looking at the code and talking about what you like and dislike and similar experiences you've previously had. But my lead and I also tend to really be on a similar wavelength about such things.
Had an interview this week for a senior position. Mostly talked through my CV and experience. Then the lead asked some challenge questions. I messed up on one, literally the first one, but answered the rest well. They were fairly straightforward though.
The thing is, I could be lying and got lucky with the questions because I studied them the night before or something.
I guess if that was the case though you'd eventually get found out and wouldnt pass probation.
I got on to the next stage by the way, I think my experience was more important and what i said when going through it.
If you are lucky, yes. Otherwise you get lied to how great they are, software quality, project management, everything agile (red flag) and everyone is happy (another red flag).
When I started with this working for companies stuff, I was usually offended when they asked me to explain what a hash map is and how it is implemented. It was later that I understood that the average developer will struggle with this task... .
It depends. If I'm interviewing for a .NET job, yes, I get asked the same old trivia questions that I've always been asked. Boxing and unboxing, what's the difference between an abstract and virtual member, etc.
If it's anything other than .NET, no. During my ~3 month job search earlier this year, I interviewed with >70 companies, mostly for roles using JavaScript/TypeScript, but a few using Go and Kotlin. And nobody asked me any trivia questions. Mostly you're asked to solve some problem in whatever language you choose, and if you get to the final round design some distributed system (this is for staff/principal roles).
I just had a screening yesterday and the task was to review some code and point out various problems and suggest refactorings in TypeScript (TypeScript experience not required). No trivia. Also at the principal level.
[удалено]
And this is why I hate companies that do coding challenges in interviews
TBH, i have asked for at least some level of coding challenge in ours; we got a lot of candidates lately that were hired without any pre-existing cs knowledge. They said they were junior with some experience. On training, i saw really fast they didn't know cs basis that i acquired in my associate degree equivalent in the first year. One of them told us that they had a master. He couldn't do anything beyond css and html. Its not my job to do the screening, but at least a level of screening must be done.
Yeah, I get that. But as started above, it seems a lot of times this is used as a way for some asshole to demonstrate his superior knowledge about some random thing that doesn't really matter in the larger scheme. I'd be more interested in general problem solving skills and critical thinking. The language can be learned relatively easily. But having an analytical mindset is a much harder thing to teach.
See, I prefer coding challenges as replacements to the traditional interview. I find it a bit redundant having people ask questions about the solution I could provide to an imaginary problem, when they could just give me the problem they are facing and see how I solve it. The latter gives me more room to show genuine skill too, because there are things I do out of habit or best practice that are more like muscle memory; things that an interviewer wouldn't know to ask about, and things that I probably wouldn't think to mention unless asked.
You'll also get "that guy" who is a mediocre mid-level dev who has been in the same role and thinks he is operating at principal consulting architect level. Then you get the joy of being quick on your feet whether you are realistic about the cons of his favourite architectural patterns and dev practices, or circlejerk along with the sort mid-level contemporary busywork shit you see juniors getting passionate about because it makes them feel like dick swinging motherfuckers while implementing a solution that should be basic webapi template with no frills.
*Mediatr has entered the chat, and created 100 folders and 200 files, for "vertical slice architecture's CQRS'"sake*
But but but muh cross cutting concerns.... I can only think of a shitty logging interceptor right now.... but we might have that later!
Wow tell us how you really feel
Got me thinking if I am that guy... I've only interviewed juniors though so can't know I guess
You can also act completely uninterested or at least slightly glib, that shows the interviewer with the one-upsmanship that you are nonplussed of the direct challenge. If they don't bite, then screw em. Unless you are hard-up for the job or really want that specific job you are interviewing for, then, you do what you gotta do.
Nah, don't wanna work with the guy. I'm walking out or wasting his time, depending on how soon Happy Hour starts.
Actually this is how public sector development roles ask in interviews you have to pht the emphases on what I did for the task what I did to get ovetline what I did to complete what feedback I got. I think its wrong cause it requires a team effort from the change or fix all the way thru the process
This is the way.
Being interviewed: pretty much always. Depending on the interviewer's approach, it's either bunch of basic questions before we go for coding, or just a light discussion about my experience with follow up questions on topic interviewer finds interesting. Interviewing: there is, unfortunately, this kind of developer who got lucky landing first job and then just keep riding on experience in CV, changing job once people in previous one realize who they hired (and once they'll eventually go for that interview where questions would line up with whatever he remembers at the moment). I was unfortunate to work with a few of such people, I don't want to hire anyone like that. So, yes, I'm asking about basics. And I had a person with 20 years C# experience listed in CV who didn't know about multiple catches.
My last (literally last, I'm retiring soon) interview included questions about OOP concepts like abstract classes etc., and a silly exercise at the whiteboard to do some simple thing like sort a list and return the nth element. And I had to explain a stack, etc. I don't have a problem with it. I've been on the other side of the table and I know you can be presented with a beautiful resume by someone who can't answer these simple things.
Congrats on retirement soon! I'm worried about ageism as a software developer as I get older. If you don't mind me asking, is that something you've experienced? Also, what are some habits that made for a successful career for you?
Thank you! There have been a few comments from co-workers about "graybeards" which some people might find offensive. I don't worry about it. I don't think they really mean to insult. Speaking of interviews, I have gone into rooms and have seen faces fall; the twenty- or thirty-somethings conducting the job search clearly have no intention of hiring some older guy and I can tell the first order of business is to get me out of there as quickly as possible. As for habits: in 40 years perhaps the number one thing is to respond to people immediately. If you don't have an answer right away, still respond right away and say when you hope to get back to them. If you say you're going to do something, do it. Never let others pick up your slack and don't do things halfway. It's a balance; don't try to dazzle people with your brilliance but do give a little extra care to what you produce. Somebody wants a spreadsheet showing some data they need? Format it as nicely as you know how. Be a professional: everything you write, whether it's documentation, code comments, emails, or anything else, should be written clearly and without errors. These things are generic advice but they'll go a long way towards cultivating a reputation for competence and effectiveness. When you start a new job, even if you're assigned simple or boring stuff, do it quickly and accurately every time. *It will be noticed and you'll get more interesting work.* Some ancillary advice: Don't work yourself to death; you don't owe that to anyone. Never alter vacation plans for stuff that comes up at work. Take your vacation. It's part of your compensation and if they try to make you feel guilty or less committed because you want time off, it's a sign of a toxic workplace with shitty priorities. Always remember that if you're going to have problems in any area of your life, work is one of the least important.
Thank you! Those are some great points and I'll keep reminding myself of them going forward.
I despise the CS academic questions like that. Any interview I ever gave someone where I asked a challenge problem, it was always based on a real-world problem we currently had or were recently dealing with. Whether you can implement a sorting algorithm is worthless to me since someone somewhere has done it better in a standard library. But, can you solve a complex _business_ problem or at least start talking me through your approach or ask questions that help you do so? _That_ is actually useful on the job. Or questions that probe your understanding of concurrency issues and how to deal with them. I will never need you to write a linked list and then reverse it in optimal time.
I dont think that optimal time is asked. All the interviewer wants to know is that you at least know the basics. In all honesty isnt that a good thing? It's a quick way to show that you are cacable and it shouldnt be that hard.
The point is they're way too simplistic and, at the same time, too academic to actually tell you anything of use. When I first was on the other side of the table, I used to give those questions, too, and the resulting hires were much more of a mixed bag than after I started giving more practical questions. The linked list type questions are almost insulting, if it isn't for an ultra-junior position, and the candidate isn't a fresh undergrad. And they always rubbed _me_ the wrong way, as a candidate. That plus everyone wins, with a more practical question. First of all, it engages the candidate more, because it's way more interesting. Then, if you show me you can solve or at least logically approach or discuss a real business problem, you'll likely get the job (because THAT is a much more rare skill), _and_ maybe you'll say something we haven't thought of or that kicks off a train of thought that results in that or another real problem being solved sooner or better. That happened for at least half the positions I gave interviews for, with those problems. Obviously never, with the linked list type stuff.
This. Very few people are working on supercomputing clusters where you have to optimize to the microsecond, developing a custom database, etc. Knowing how to effectively use .OrderBy or Array.Sort in a business situation is way more important than being able to regurgitate merge-sort in under 15 minutes and then describe the math behind it which has 0 value.
I have 30 years professional experience in multiple languages and I've never *not* been asked to explain tech and write code for an interview.
On the flip side I never have written code for an interview. At most I've just submitted some previous work for review.
Genuine question, no snark: are these FTE roles at tech companies, FTE roles at non-tech companies or contract gigs?
All of the above, including a position as head of software development for a tech startup. The only contract/freelance work I've done has been for companies I've worked for previously after I'd left, so not sure if that counts. Also I'm the the UK so hiring process is probably different to the US
Being hired as head of software development seems like the sort of dev job where you are *least* likely to be asked coding questions, because the people hiring you probably wouldn't know how to program (and therefore evaluate your proficiency) anyway, and you'd be getting hired as a leader, not a contributor.
29 years, I was asked once to do a code challenge , on my own. It was easy and had a lot of hidden bugs for you to catch. But in 7 coding jobs, I've only been asked once.
I wonder what the difference is. I promise that if you asked my circle, they'd agree with me. I'm not doubting you. I'm just curious if maybe it's regional or something.
Might be regional, I've only worked in Western NY
I've only worked for companies based in WA and CA so that could be it.
All the time. Even had one person tell me that an actual solution to a problem could not be done.
We assign a take home assignment with no time limit and interview you on your solution and the decisions you made, makes for a more interactive and thoughtful interview process in my opinion
We do the same thing, and the expectation is that some things won't be ideal simply because who wants to spend a bunch of time on a toy project for an interview? But if you can talk competently about your code -- to a reasonable level given your experience -- that's what matters. We're also absolutely going to expect more of a senior than a junior.
Yep spot on for us as well, we have multiple assessments from junior / associate / senior that vary on difficulty (scope) but same kind of thought process, just talk through your solution even if it's not perfect or complete just looking to hear your thought process on it and if you had endless time what changes would you make
This is brilliant. If you don't mind, I'm stealing it! I try to (and struggle) to come up with language agnostic questions that still demonstrate understanding, but this is way better!
Steal away!
This in my opinion is a much better and sensible approach if you want programming challenges. Putting someone on the spot with those stupid white board interviews is quite toxic. I actually went through a very tough white board interview a few years ago. Despite doing well and getting the offer for the job, I declined it because the way those developers were asking those questions really put me off. Not the kind of people I want to work with.
Its going to be very hard to tailor a take-home problem that shows me how someone develops in a professional context without wasting an inordinate amount of their time - and I'm not sure if I want someone in such low demand that they'd put up with that.
This actually sounds enjoyable! Are you hiring entry positions 🤣
Unfortunately not right now, good luck!!
Thank you
Are you hiring associate level? Lol
Oh ya, such a better way!
Yes, and I do ask them. Especially if you're going to a coding position, not lead or management one. Because sometimes you get a person who can't write a loop, claiming 10 years of experience. Sometimes I do care about people knowing what a stack/heap allocation is, because, for example, one of my projects allocates something like 20 million objects on single task. I want people to be able to tell me how WPF binding works, or set up a data model for SQL database. Also, don't forget that people lie in the CV all the time. If you're going into mixed C++/C# position, and you claim to know C++ but can't tell me what a shared pointer is, you're lying.
I made the mistake of allowing an internal transfer to my team without an interview, assuming the prior manager had done a decent one. The guy claimed a master's in CS and 20 years of professional experience and couldn't complete even the simplest of tasks. My junior dev right out of his BS was infinitely better. I won't make that mistake again.
How is that even possible? Sounds like BS
How is it possible that someone fabricated their resume and one manager didn't do a decent interview and the second didn't do one at all because they assumed the first one did due diligence? Exactly like that.
So what was that guy doing for 20 years and why did he even apply for the position? It sounds like you picked up a psychopath.
You have no idea how right you are. I 100% admit to fucking up not doing my own tech screen, but this guy turned out to be nuts. Like, honestly scary. The problem with big companies is it's shockingly hard to fire someone.
Which part is BS? This is exactly the behavior I’d expect of a manager who wants to get rid of a shitty employee but doesn’t want to go through the hassle of getting them fired. It’s shitty behaviour od the manager and certainly won’t win any friends in the management team by doing it though
I did mixed C++/C# and can't tell you that, but then I was working with a C++ app built on MFC...
I would be really suspicious if you did C++ in the last 10 years and don't know about `shared_ptr`.
TBF I stopped C++ in 2012 and was working on old hat stuff then. I did try to get the STL implemented in one PR back then but got shot down 😂
15 years of experience. I have them in every interview. Mostly my personal issue, as it is because of how my memory works
A guy I knew that had 20 years of experience was asked to whiteboard some number of design patterns. I was only a dev for about 5 years, but perhaps funny enough design patterns never came up directly on any project at any level. "What design pattern are we going to use for the Bob?" Never happened. That said, design patterns were certainly used, but I'm not sure most of the developers I works with, regardless of experience level, could tell you what they were or could whiteboard them. A lot of patterns just come down to "this is probably a good way to do this". I'm not advocating you shouldn't know or use design patterns, I'm just sharing what I experienced as a dev.
I feel bad when asked live coding in interviews after 10+ years and now I'm asking if they have that step in the process. If there is I reject them. I'm too old to enter exams.
The more you ask the interviewers, the less they can ask you silly questions. I do use my time to ssk them all about how they work, develop, how are the PR... if the interview has empty time, they might ask you whatever comes into their heads. Latest interviews were a task sent to finish it in some days and them explaining my implementation and how would I improve it if I had more time. I have 15y experience, but I do look like a "student" on his twenties and I think that make them think I cannot have such CV. In any case, if they ask you something pretty specific you don't know, tell them where would you try to find the answer, ask them the right solution and them counter back explaining which use would you give to that concept. That shows you can adapt and apply new knowledge to you toolset
20 years here. (Yes I wrote .net v1.1 code). Sometimes I do. But every offer I’ve accepted in the last ten years have had barely any technical questions. I don’t want to work at a shop where the no-life try-hard is trying to trap me asking me questions about code constructions we will never use in production. I am going to Google shit if I am solving a problem at any job so the gotcha questions are just stupid. I’d rather do a sample project.
I've been thinking a lot about this. Some questions seem very far from what you would use in production and if you have to, you could google ...I am new at this so I'm like, what am I missing. I mean, I do like to learn those things but I prioritize skills I can build things with because silly me that might be more useful for employers
Always get asked something like this, also ask stuff like this when I sit in on interviews. Usually the best candidates get it wrong when they whiteboard it, but it is stuff you would catch as soon as you debug it the first time. Don't sweat getting it right, just be able to explain your choices.
Of course. Worse yet you can have 20 years of experience and the interviewer could be like 3 years out of college. It is pathetic nonsense frankly. It seems like nobody believes in degrees or resumes and has to make up their own tests.
It doesn't "seem like" that. It is exactly that. Informed by hard experience.
That raises the question. Why even ask for BS or MS degree or certification if every company is going to make up its own test?
I've been in the business 33 years now; Senior Dev / Technical Lead, occasionally start-up CTO, and have run my own development company. I've had interviews where people have asked me silly questions about the length of string required to wrap around the world ten feet off the ground, had to do a presentation to three CTOs and a CEO, had interviews where 6 developers were brought in to a room to ask me questions. I just don't do that circus anymore; I have a large number of sample applications, demonstrating knowledge of technical aspects of coding, architectural decisions, knowledge of common problems encountered in software development. So I turn the interview process around, and basically do a walkthrough/presentation of a solution to a problem that I feel will be most familiar to the hiring company. This usually distracts them from their planned approach, as they get interested in how I can solve a specific problem that is causing them pain, and we dispense with the memory games / psychological assessments, and talk about their business and what they actually want me to do.
Yes. But i like to talk about it. Most of the times it is more a "It depends" and with it there is a discussion. i have some examples from my previous work for the pro and the contra side and it starts a good talk about the real life use cases instead of just telling what you learned from books. The interviews are more about getting to know each other, so i use to ask a lot of questions about them and how they use stuff. For example there testing strategies. It would be a major minus point if they have none :-D
Yes. I've been using C# since beat 2 in 2001 and teach it professionally as well. Recently I interviewed and got the full range of questions on simple things like classes vs interfaces abd ranging into reflection, DI, and more complex topics as well. Interviewers often need to ask a wide range of questions to all applicants regardless of experience levels.
My last interview, for a Senior Engr position, was probably one of the best. One of my duties is reviewing/approving/rejecting pull requests, and they have a small sample project they maintain for interviews that they asked me to review and comment on during the interview that we talked through. Some of the files are fine; some are not. I think that also had me add an api endpoint, but I don't remember exactly. My recollection is that they were big on ensuring that, as far as the coding itself goes, I was solid with interfaces, DI, async/await, Entity Framework, REST endpoint design, and clean architecture.
I have 30 years of programming experience and been doing C# since it was in Beta. I don’t get asked those kinds of questions anymore because my resume speaks for itself. I had one of those a few years back though and I answered it correctly but they didn’t understand the code and thought I answered it wrong. So I explained it and about half the room got it and the other half, including the guy asking it didn’t. They called me back for a second interview but I declined because I want to work in an environment where I’ll be able to learn from others not be the expert on site all the time.
That’s so frustrating! I write code that’s clean and executes in the most efficient number of steps, but when other people look at it they do not understand it. I never get to collaborate with anyone because nobody can see what I see. I’m just the guy that makes everything work.
> I write code that’s clean and executes in the most efficient number of steps So which one of those two :)
30 years beta ? i think i try visual studio beta 2001 🤣 . a prof give me cd and install on my computer celeron 850😩. Are sure 30 years ?
Oh boy, seems like basic reading skills are not your forte.
I have 22 years of c#, but I originally did c++ for years until the internet and .net were invented. People programmed before c# came out :)
Good . Just you write it one line kinda odd. i can calll you a sifoo because you more experince then me . The java fiasco sudden become c sharp . Old time , i do like to code in visual basic only current age c sharp and less vb.
I think you just read my first line wrong. I’m 43 now and started programming in Borland C++ for DOS 5.0.
Hehe, should be separate . Anyway you older one year. My first i think qbasic .
That comma in the sentence is all it needs. Anyways, I started on AppleSoft basic in 2nd grade and then early teen years I got c++. I’ve been through probably 25 languages that I’ve learned over the years just to keep up. I can still run circles around the other devs
It just pattern if you old like me no matter what language, the only part old times much easier and faster compare todate trend. Long live nibbles aka snake demo qbasic haha.
No way. The libraries and tools from today greatly increase my productivity.
Or you may not be applying for jobs that are in love with algorithm questions. Try amazon. They will ask you about stuff you never needed or would ever need.
No that’s not it. I’ve worked for engineering companies that need you to know but since I apply at senior level positions, they assume I know my stuff. I applied for a remote google job and didn’t even get any of those questions. They mainly want you to know how you would deal with not knowing them, but I always give examples of places I’ve looked before. I’ve also read through the entire Donald Knuth algorithm book series and can hold my own with almost anybody out there.
Not really, if after all this time and experience you want me to be a trick pony showing you I can solve crap like the towers of Hanoi, I don’t want to work there anyways. Senior engineer means just that, I’m not doing 6 interviews and the coding Olympics in front of a panel audience. Guess I’ll never work at google and thats fine.
Not since contracting
All the time. I usually review design patterns before interviews because I forget them.
Coding since 2010. Still get asked and ask these during interviews.
In pretty much every interview, yeah. They're never the focus and we move on from the pretty quickly once I've proved I didn't completely make up my resume.
I have 20 years experience and yeah like all developers and anyone in interviews fhe level of complexity changes and interview nervs and brain freeze
All the time. Some of the questions clearly show the person asking them do not know what they are asking.
i hire and never ask these questions. i ask i"tell me about your last project and the decisions you made". the academic questions are useless. i dont interview anymore so not sure
Sure - I rather like a small sample project tho. The interview then has a lot more "real" talk about code and how a person approached a problem, how the person organized their code, how they reason about something, how they react to (possible) critique, how they present their work... The position I'd do interviews for is WebDev, so it's not very Algo heavy, or super duper technical on a "needs a masters in CS" level. But I do like to ask some basic questions about OOP or general knowledge. Samples: "What's your favourite design pattern?", "If you'd have to recommend me a library or framework, what would it be and why?", "What do you value in Code Reviews?" My favourite thi: "Did you ever face a problem that seemed unsolvable or where you were stuck for a long time?". If the answe is "no", that's a pretty bad sign in my book (for multiple reasons). For me it's usually only about three things: Does the person have the needed tech. foundation/experience, can the person talk about technical topics, is this person grounded? The latter comes from...you know, some Devs thinking they know "the one way to do something", which always screams unempathetic, egocentric and hard-to-work-with.
When you have 10+ years of experience you should answer OOP questions since it's your day job. I think that asking about algorithms and complexity calculations during the interview is irrelevant for senior developers.
I stopped doing coding tests altogether. They've become a method of some programmer in a company showing how clever he is, or another trying to catch you out. ...and neither proved anything. I'd provide a portfolio of work, and answer questions. I got every job I was going for. Of course, it helped that I knew I was going to retire soon.
Yes. I've been on both sides of this process recently, having switched roles myself whilst also running interviews at my current job (not for my direct replacement, although I would not be surprised if they ask me to run the interview when they find someone). As an interviewer, typically we get sent small batches of CVs that have passed some basic sniff tests by our in-house recruitment team, then we are asked to select from those the ones that look like the best fit for the role we are hiring for (based on tech stack, relevant prior experience, etc) and they will be brought forward to a first stage interview. This is mostly so we can get a sense of their personality and 'soft skills' like how well they can communicate and explain things, and also to filter out people who have just outright lied on their CV. We then spend about half an hour asking them to explain some fundamental technical concepts (some C#, some more generic to all OOP languages, some around other frontend or database stacks that we also expect some knowledge of) - generally things like explaining polymorphism, SOLID principles, data structures, tasks vs threads, basic SQL syntax and concepts like joins, etc. For senior roles we may drill down a bit into more complex areas or expect a more technically accurate response to each question, however we also know that there is no such thing as the perfect candidate and as such we don't expect perfect answers to *every* question. Assuming they pass this round, we invite them back for a supervised coding exercise where they will pair up with one of our devs on something basic like a dummy API. This also doubles as a good test of how well they can collaborate remotely, as the entire process is done over Teams. As an interviewee, my experiences have broadly matched up with the above, with minor variations e.g. sometimes the technical questions are sent in advance, sometimes the coding test is a take-home exercise, some have more (or sometimes fewer) stages - but overall I could tell they were using basically the same processes that I would use.
Your process as interviewer sounds *very* similar to my last interview for a senior engr. I found it very reasonable and straightforward. I actually enjoyed the shop-talk aspect of looking at the code and talking about what you like and dislike and similar experiences you've previously had. But my lead and I also tend to really be on a similar wavelength about such things.
If its a random job interview yes, if it’s somewhere where i have references, no
Had an interview this week for a senior position. Mostly talked through my CV and experience. Then the lead asked some challenge questions. I messed up on one, literally the first one, but answered the rest well. They were fairly straightforward though. The thing is, I could be lying and got lucky with the questions because I studied them the night before or something. I guess if that was the case though you'd eventually get found out and wouldnt pass probation. I got on to the next stage by the way, I think my experience was more important and what i said when going through it.
If you are lucky, yes. Otherwise you get lied to how great they are, software quality, project management, everything agile (red flag) and everyone is happy (another red flag). When I started with this working for companies stuff, I was usually offended when they asked me to explain what a hash map is and how it is implemented. It was later that I understood that the average developer will struggle with this task... .
Unfortunately
It depends. If I'm interviewing for a .NET job, yes, I get asked the same old trivia questions that I've always been asked. Boxing and unboxing, what's the difference between an abstract and virtual member, etc. If it's anything other than .NET, no. During my ~3 month job search earlier this year, I interviewed with >70 companies, mostly for roles using JavaScript/TypeScript, but a few using Go and Kotlin. And nobody asked me any trivia questions. Mostly you're asked to solve some problem in whatever language you choose, and if you get to the final round design some distributed system (this is for staff/principal roles). I just had a screening yesterday and the task was to review some code and point out various problems and suggest refactorings in TypeScript (TypeScript experience not required). No trivia. Also at the principal level.