18 ms·
I run coding interviews. I would never give an esoteric algorithms question, or even really an algorithms question. I have prompts that test very basic concept
by geraldwhen 2y ago
I run coding interviews. I would never give an esoteric algorithms question, or even really an algorithms question.
I have prompts that test very basic concepts and nearly everyone fails. Resume fraud is rampant.
- wasteduniverse 2y ago[dead]
- HeyLaughingBoy 2y agoWe found that doing both worked very well. Overall interview is "write code to solve this puzzle." But first, do this very basic thing that is needed to solve the puzzle. 80% of candidates get hung up on the basic part of the interview and never even get to the point of looking at the rest of the problem. But of those that did, we got some great people.
- teaearlgraycold 2y agoI usually ask candidates to do example questions related to everyday stuff like log parsing. They won’t need anything fancier than a hash map. Many people are stuck after writing 4 lines of boilerplate. Some don’t even know the syntax of the language of their choice.
- a20eac1d 2y agoCould you give me a concrete example of what that looks like?
- teaearlgraycold 2y agoSure. Here's a log file of page accesses on our server. It's a CSV. The first column is the user, the second column is the page, and the third column is the load time for that page in milliseconds. We want to know what is the most common three page path access pattern on our site. By that I mean, if the user goes to pages A -> B -> C -> A -> B -> C the most common three page path for that user is "A -> B -> C". user, page, load time A, B, 500 A, C, 100 A, D, 50 B, C, 100 A, E, 200 B, A, 450 etc. So for this first question you should give an answer in the form of "A -> B -> C with a count of N". We would have two files, one simple one that is possible to read through and calculate by hand, and one too long for that. The longer file has a "gotchya" where there's actually two paths that are tied for the highest frequency. I'd point out that they'd given an incomplete answer if they don't give all paths with the highest frequency. The second part would be to calculate the slowest three page path using the load times. In my opinion it's a pretty good way to filter out people that can't code at all. It's more or less a fancy fizzbuzz.
- mulmen 2y agoAre these records assumed to be in order?
- teaearlgraycold 2y agoYes. That would of course be included in the problem statement
- mulmen 2y agoThat’s not obvious. If you are including “gotchas” this may be another one.
- tekla 2y agoIts only a gotcha to anyone who has never looked through a log file.
- mulmen 2y agoI have seen a lot of log files, never one in CSV format or without timestamps.
- lucb1e 2y agoSince there is no timestamps, it being in order is a requirement because otherwise it's unanswerable. Since chronologicalness is indeed virtually universal for any sort of log file, it's also a fairly safe assumption, but sure, if you want to double check assumptions then it's a valid question to ask. I do think it was obvious enough, though, and the question that came to my mind was rather about scale, like: can I assume the number of users and unique paths will both fit in RAM? Btw, if you want CSV log files, look no further, and not all my data logs have timestamps either! :D The particular timestampless case I'm thinking of, I wanted to log pageload times for a particular service so it logs the URI (anonymized) and the loading time, though I think that's not csv but just space separated, one entry per line
- dakiol 2y ago> Some don’t even know the syntax of the language of their choice. I still struggle with this. I don’t find it a blocker, though. The bottleneck is usually to understand and parse business requirements. If you know about good code practices as well, then the least of your problems is to know whether you can use ‘in’ or ‘[]’, ‘var’ or ‘let’, ‘foreach’ or ‘for’, ‘def’ or ‘fun’, etc.
- fullstackchris 2y ago"everyday stuff like log parsing" Unless youre talking about using tail / grepping some linux logs I've never done this once let alone on a daily basis... But if needed frankly I would look up any needed regex / pattern for this on the job and on the fly. The topic of "log parsing" is massive anyway. What types of logs? Is this something like request logs from NGINX? Custom stderr / stdout from some cron job? Some sort of horrible XML based system dump? I could go on and on... When you know the solution already of course its obvious.
- ApolloFortyNine 2y ago>I have prompts that test very basic concepts and nearly everyone fails. Resume fraud is rampant. It is crazy how many people will fail a question that boils down to 'write a for loop' despite going to college for 4 years in CS.
- deleted 2y ago[deleted]
- mulmen 2y agoWhat’s the question?
- woobar 2y agoFizzBuzz?
- zelphirkalt 2y agoSpeaking about Germany: This is because many CS degrees do not include sufficient practical projects. If you get some degree concluding practical project, you can already be happy. The real practice most CS students get, they get "off the job", in side projects. Or on the first job they somehow manage to get.
- lucb1e 2y agoNetherlands also, although it depends a bit on which master's they did. If you want people able to do stuff off the bat, hire those who did MBO or HBO (in DE, HBO=Fachhochschule, but DE doesn't have an MBO equivalent I think: that would be Ausbildung level afaict, except MBO doesn't require you to have a job at the same time). In English, my HBO translated their name to "University of Applied Sciences"; my MBO did not give a English translation of the degree
- emseetech 2y agoThere should be a 4 year Computer Science degree and a 2 year programming trade school, both equally difficult but in different directions, and companies should be aware enough to know which graduate they need. Of course the best hires would be those willing to do both, if they're capable of a 6 year commitment. Apprenticeships and on-the-job training is also an option, but nobody seems to be willing to do that anymore.
- whstl 2y agoI have prompts but I give the solution away. It's basic shit like factorial or fibonacci. People still fail. Resume fraud is rampant. EDIT: Another thing: about 80% of the candidates I interview wouldn't be able to pass our Product Manager SQL interview. It's basic shit, but not as basic as the stuff I ask. All the PMs in my current job have better skill than 90% of the backend engineers I interviewed in the last two years. Resume fraud is rampant.
- lucb1e 2y agoFYI I wouldn't know how to do fibonacci sequence because I don't know its definition. I could make a guess because it came up as a toy problem before, but because I never actually needed it for anything I'm not super familiar. Compound interview stress and I'd potentially get factorial wrong as well because that's also not something I'd normally implement. I might recommend, when asking this question, to give the definition with a few example inputs and outputs. That should avoid these types of issues where people are perfectly capable of coding the requested algorithm but aren't mathematicians / toy problem experts
- valicord 2y ago> I wouldn't know how to do fibonacci sequence because I don't know its definition You know you can ask the interviewer about this, right?
- lucb1e 2y agoYes, and I would because if I don't know then that's my only option (short of sitting there and going "no can do"). However, given their phrasing "basic shit like factorial or fibonacci" I got the vibe this is supposed to be known by the candidate and they'd judge the candidate negatively (before having written a single line) for needing to ask
- valicord 2y agoI'd assume that the purpose of a simple question like that is to test basic programming skills (can you write a loop?). Testing knowledge of a specific math concept is doesn't really fit into this goal, so you're unlikely to be penalized for it.
- a20eac1d 2y agoCan you give me a couple of examples? I'd like to see where I stand with my knowledge.
- pphysch 2y agoOne of the first questions I ask is "create a dictionary with three elements in Python and assign it to a variable" The amount of insane answers I've seen to that one alone... Then if they pass, I test proficiency by having them loop over the dict and update each value in-place.
- dakiol 2y agoI’m divided. I can do what you ask, but not without googling it. I can produce performant and robust code, but not without double checking on google. I’m unable to deliver code that compiles in any language without checking the documentation. Pseudocode, yeah sure. So, I wouldn’t pass these kind of interviews. In over a decade I’m never being asked these kind of questions though (I have done take home assignments and leetcode, but always with google opened)
- bondarchuk 2y agoReality check: if you say on your resume that you know python, then you should be able to make a dictionary with three items and assign it to a variable without googling anything.
- dakiol 2y agoFair point. I don’t like resumes in which people state that they know X or Y. I prefer the ones focused on what problems were resolved using what technologies. I have used Python to solve average business problems, yet I cannot produce non trivial code without looking at the documentation. Same for the other dozen programming languages I have used in the past.
- 2y ago
- gloryjulio 2y agoExactly. Most of the medium difficulty interview questions are just typical cs algorithms that you are supposed to know. If you are a competent software engineer, it doesn't take long to just brush up and get enough practices for all of them.
- dver 2y agoIf you're "supposed to know", I would assume enough use to not need to brush up. Brushing up implies not used enough to keep in the mental model.
- gloryjulio 2y agoKnowing != passing the interview. They are in different layers. Any cs student would know about things like the hashmap, stack, queues, linked list. You encounter those data structures everyday especially when you are doing debugging the source code. That's still different compare to interview though because you need to explain, code, solve a question under 20-30 minutes. It's not hard if given enough time. But most people would need to practice some questions before going into those questions so that they can solve those under the time limit.
- golergka 2y agoAlgorithm questions are overrated, but asking a real life question where a naive solution is n^2 but basic knowledge of standard tools brings it down to log n is always a good idea.
- throwaway2037 2y agoNice idea. Do you have a good example?
- ufmace 2y agoYup, I've developed a workflow that starts with writing a brain-dead easy fizzbuzz and gradually adds features and complexity. The way I've done it, it gives you a way to judge levels as well as basic competency. If you can't, or can just barely, complete fizzbuzz in the allowed interview time with a lot of coaching in your language of choice, then you definitely aren't ready to work as a SWE. If you breeze through all my extra sections in half the time, then you're great. Partway through, and you're probably a decent junior to senior engineer.
- lucb1e 2y ago> fizzbuzz in the allowed interview time Which would be how long? I haven't practiced it specifically so it would be a good test I guess
- ufmace 2y agoWe have a hour total per interviewer. The basic FizzBuzz is intentionally incredibly simple, no reason anyone qualified to be a full time software engineer should take more than 10 minutes to build it in a pre-set-up environment in their language of choice.
- lucb1e 2y agoI haven't done it in a while and never practiced it specifically, 10 minutes sounded quite short for writing working code. Looking up the description again and timing myself now (starting the timer after reading the description, since I didn't know how long it'd take to find a good description whereas that's a given at the interview): yeah okay, that took 63 seconds for printing the results for the range 0-100. Good interview question, quick and easy enough (though I don't use n%x==0 a lot in real coding, it has come up and it's a basic enough task). Thanks for the answer!
- selcuka 2y ago> I don't use n%x==0 a lot in real coding I use it all the time, especially when logging the progress of a long running process at every x records.
- dakiol 2y agoWould you consider inverting a binary tree a basic question? Some may, but many developers have never inverted a binary tree in decades (because it’s something that doesn’t pop up in a normal job). Just because it’s such a classic topic in CS, that doesn’t mean I need to remember it after decades of seeing it in uni.
- bondarchuk 2y agoCan't you expect a halfway decent coder to derive how to invert a binary tree from first principles? It's literally just swapping the left and the right field in each node...
- dakiol 2y agoThe thing is when I’m the interviewer I’m not looking for coders. I’m looking for people who can understand the business, find a solution that is business oriented and produce (if needed) good enough code (we are not Google). So, if you cannot invert a binary tree from scratch but are good at the other skills I’ve mentioned above, I want to work with you. What good is someone who can code the best algorithm but cannot understand the business? Unless you are working in the top 1% of the companies out there (where you may have the luxury to invent new ways of doing things), for the rest of us our main skill is: to solve business problems with zero or minimal good enough code. We (99% of the tech companies) don’t need a Messi, just an average Joe.
- valicord 2y agoThen don't ask this question if it's not relevant for your position? Presumably those who would ask it don't want to hire engineers that have never heard of recursion. It's a basic level CS concept, not rocket science.
- geraldwhen 2y agoOut of 100 people I interview, maybe 1 would know what recursion even is.
- charlescurt123 2y agoSo I feel I strongly fall in a poor performer interview category any time any code problems come up. How would I convince you I do not have a fraudulent resume? I study hours every day for many years now. I know many complex systems however studying algorithms bore me to tears. I've built HPC clusters, k8s clusters, Custom DL method, custom high performance file system, low level complex image analysis algorithms, firmware, UIs, custom OS work. I've done a lot of stuff because I can't help wanting to learn it. But I fail even basic leetcode questions. Am I a bad engineer? There seems to be no way for me to show my abilities to companies other than passing a leetcode but at the same time stopping learning DL methods to learn leetcode feels painful. I only want to learn the systems that create the most value for a company. I imagine if you interviewed me you would think I wrote a fraudulent resume. Not sure how I am supposed to convince someone otherwise though. Perhaps I've been dumb in not working on code that can be seen outside of a company.
- itsdrewmiller 2y agoWhy are you doing all those things and what jobs are you applying for? Can you solve fizz buzz in an interview setting?
- darby_nine 2y agoFizz buzz is certainly not a replacement for expertise, which is what the above commenter seems to be emphasizing. Naturally it's a "low bar" but it's an awfully low bar for a job that isn't entry level.
- joenot443 2y agoThat's why it's so concerning when you have people who confidently say they're great engineers who are experts in firmware, UIs, operating systems, and networking, yet when you ask them to write a 3sum or remove from a binary tree they freeze up and blame it on an unfair interview structure. I'm a bit reminded of a chef who claims he can cook pasta, sushi, and pastries, yet when asked to fry an egg says that it's not fair to expect him to do so on the spot. A chef who can't cook when needed is about as useful as an engineer who can't code when needed.
- jroseattle 2y ago> Resume fraud is rampant. So is interview fraud. The remote-interviewee-answers-questions-while-her-face-reflects-windows-popping-up-on-her-screen is tiring at this point. So, I decided to find a way to inform me if someone was being fed answers in a tech interview. Behold, the low-tech whiteboard. Also known as a piece of paper and a pencil. With the candidates I've run into that do not pass the "smell" test -- where I think they are being fed answers -- I ask them to draw some things, on paper. It's not a true validation, but it gives me something of a clue. I ask for a simple diagram. Different services in a network, for example. Or a mini-architecture. For their level, I'll ask for something that should be drop-dead easy. I ask them to show me their drawing. The responses I've received run the gamut of "I don't know" (after 5 seconds of deliberation) to "I don't understand the purpose" (after 5 minutes of silence) to "I need to shut off my screen for a while" (while refusing to explain why) to "it depends if your cloud is AWS" (not in any way remotely related to the question.) I did have a candidate follow-up with a series of questions about the drawing, which were feasibly legitimate. This hand-written diagram is not an absolute filter (I've only used it maybe four times), but rather it can confirm some suspicions. I think I can generally gauge honesty from questions/tasks like this. And that's really what I'm after -- are you being honest with me? It's imperfect, but it has been helpful.
- hipadev23 2y agoGlad to hear it. Whiteboards remain the ultimate interview tool, even remotely.
- lucb1e 2y agoMaybe easier is to just ask that they show their hands while you ask a short question until they gave the answer. Could even be up front about it and say you suspect they're looking up the answers, since it's not like you care much if they get upset at a false suspicion, or just say "to avoid looking up answers, our standard procedure involves this". The drawing approach also sounds like a good idea, though it's not like software is not going to evolve to be able to draw answers graphically which the candidate could copy down. By having them not able to input something into the machine, the only remaining option is someone listening in and feeding the answer on screen. Plausible, but that's a level of being prepared to cheat that the helper could also prepare to draw stuff out. Or they type with their feet but that's also a scenario where I'd be happy to have them come in for a final interview and demonstrate this amazing ability!
- lawgimenez 2y agoCodebase fraud is rampant too. The company has very excellent coding and test interviews but the codebase is just shit.
- selcuka 2y ago> The company has very excellent coding and test interviews but the codebase is just shit. It is also possible that this is because of all the fraud developers they've hired. A "company" is not a person. It doesn't produce shit code itself. While management can also be a source of bad codebase, it is usually the developers.
- lawgimenez 2y agoOh? Do you not blame the front office of a sports time for failing to win a championship or assembling a shitty team?
- selcuka 2y agoNo, because resume fraud is very rare in sports. What is expected from an athlete is very clear. If they can't run x metres in y seconds then they are out. This is not so clear cut in software development, so yes, I don't blame management when they accidentally hire an incompetent, fraud developer. Obviously it is a different story when management hires good developers but can't maintain a good workplace culture, apply unnecessary time pressure, don't pay them enough etc.
- gedy 2y ago> While management can also be a source of bad codebase, it is usually the developers. Plot twist: the devs who are good at leet code quizzes are frequently crap product developers on teams.
- darby_nine 2y agoYou see this sort of interview incompetence at every large company. There's simply no way to force software engineers to be fungible, but that's what the processes of many large companies expect.
- stogot 2y agoI agree that Resume fraud is rampant. Simple questions that should be easy for “20 years of experience doing that thing” get bad answers >50% of the time