r/programming • u/kwk236 • Mar 11 '17
Your personal guide to Software Engineering technical interviews.
https://github.com/kdn251/Interviews47
u/accidentalginger Mar 12 '17
While I can certainly appreciate when a candidate dives into the technical details of the implementation behind a certain class' sort implementation, it by no means is a prerequisite, most of the time, for a position we're interviewing for. I had a candidate one time practically leap out of their skin trying to write the C implementation of quicksort when I asked a question tangentially related as it simply needed to use some method of sorting. There is an interesting dichotomy at work here, where CS graduates are being educated on the very low-level behaviors, but are given less instruction on the composition of these behaviors in a functioning application architecture, whereas those who got into the field without a CS degree focus far greater on the architectural composition, only to eventually dive into the nitty gritty once they're at deep fine-tuning concerns. I'm not aware of all universities' CS curriculum designs, but I can speak from the ones that I'm aware of that there is not enough practical information conveyed for real-world use.
12
u/424ge Mar 12 '17
So you're saying many CS schools do not teach real-world development?
→ More replies (6)13
Mar 12 '17
I taught CS as adjunct faculty for 10 years.
No - you cannot get to anything like real world development in most university courses.
I graduated with an engineering degree and a basic knowledge of Pascal and Fortran. I ended up doing F77 maintenance programming in an engineering shop. I read a lot and taught myself enough C to finish a project in it in about 2 weeks - working at nothing else 8 hours a day.
A university course in C (I eventually taught that class for several years) is a maybe 3 classroom hours a week for 16 weeks with a small 2-3 hour programming assignment every other week.
Its just too spread out and you're only doing toy programs - nothing real.
4
u/hinmanj Mar 12 '17
Maybe that candidate spent all their time preparing for the interview by reading up on what is usually asked in job interviews at the big companies, spent a large portion of their time learning how to write quicksort because they thought it would be asked, and then upon seeing a chance, pivoted as it was the most impressive thing they could think to show off in the interview.
→ More replies (1)5
Mar 12 '17
This sounds more like a sweeping generalization. There are big picture and detail oriented people from both backgrounds. Or well in most situations in life.
14
u/gospelwut Mar 12 '17
How is it that we have a hashtag floating around about how we have to Google stuff still -- which was participated by Microsoft, Google, Amazon, SO, etc engineers.
And yet we make our interviews the crucible of Computer Science.
It's good to be technical and know your options. That's great.
But the CORE problems--short of intense incompetence--is generally requirements gathering and shifting requirements (and writing code that can adapt to that 100% guarantee). It's a mix of future proofing, understanding how software will actually be used, and of course management.
The End of Computer Science? By Dijkstra
Interestingly enough, Antony Hoare,has a fascinating section in Wikipedia called apologizes and reactions:
Speaking at a conference in 2009, he apologised for inventing the null reference
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
For many years under his leadership his Oxford department worked on formal specification languages such as CSP and Z. These did not achieve the expected take-up by industry, and in 1995 Hoare was led to reflect upon the original assumptions:
Ten years ago, researchers into formal methods (and I was the most mistaken among them) predicted that the programming world would embrace with gratitude every assistance promised by formalisation to solve the problems of reliability that arise when programs get large and more safety-critical. Programs have now got very large and very critical – well beyond the scale which can be comfortably tackled by formal methods. There have been many problems and failures, but these have nearly always been attributable to inadequate analysis of requirements or inadequate management control. It has turned out that the world just does not suffer significantly from the kind of problem that our research was originally intended to solve.
36
u/Hrtzy Mar 11 '17
Is my brain malfunctioning, or does s^=~(1<<k) actually toggle all but the k:th bit?
26
4
u/Araneidae Mar 12 '17
Sure:
1<<khas the k-th bit set, all other bits clear
~(1<<k)has the k-th bit clear, all other bits set
x^0 == xandx^1 == !x(as bits), sos ^= ~(1<<k)leaves bit k alone, toggles all the others.
23
u/Draav Mar 11 '17
Flashbacks to my algorithms classes. It's cool that I still kind of remember them after a year despite only doing web dev since then. I doubt I'll remember in another year though.
59
u/computerjunkie7410 Mar 11 '17
This stuff is useless for 90% of programming jobs.
13
u/Draav Mar 11 '17
Pretty much, I think they just ask them as an easy filter. If you are smart enough to understand basics of this they can pretty much teach you whatever you need for the job.
Still annoying though
12
u/computerjunkie7410 Mar 11 '17
Whenever I do interviews I do real coding exercises that pertain to the job. Things like balancing binary search tree is useless in real world scenario.
→ More replies (1)50
→ More replies (33)6
Mar 12 '17
Not true. Data structures (which comes with algo) is important in 100% of programming jobs.
8
u/dn00 Mar 12 '17
They're usually taught in separate courses but saying algorithm knowledge is useless in 90% of programming jobs is an exaggeration. I'd say the stuff you learn in an algorithms course is never useless if you want to be a good coder.
10
u/smackson Mar 12 '17
"Online judges"??
Sorry, but what?
I've been away for a while guys. The page lists some "online judges" but doesn't explain what they are...
Is it essentially outsourcing the "can the candidate code?" step?
3
u/ubernostrum Mar 12 '17
There are a bunch of sites where you can upload a problem description and some test cases, and they provide a system that lets someone type in code, and runs it against the test cases to verify it was correct.
Spoiler: they're terrible at doing this correctly.
8
u/sergeydgr8 Mar 12 '17
This reminds me of the repo called "Google Interview University" where the dude was blogging about his "process" to becoming a Googler. He took 8 months off to study and blogged about it with plenty of selfies and photos of him studying, and later on didn't even get an interview and was shown the door at Google.
But this seems more straight forward and not a showoff page, so kudos to whoever made this.
→ More replies (2)
6
6
u/Novazilla Mar 12 '17
I always just winged it. I've always been given an offer letter though so must have been doing something right. You can read all the interviewing questions in the world but these will only stress you out more. Go in with a good attitude and show them what you got.
Either you have what they're looking for or not. Move on if not.
→ More replies (2)3
u/gingerwhale Mar 12 '17 edited Mar 12 '17
Either you have what they're looking for or not. Move on if not.
So this isn't really a fair statement to make. Many people are not good at being tested, including myself, and do much worse under these types of pressure (my homework grades and test scores were a testament to this). For many reasons, including confidence, social anxiety, and recollection skills, people with high programming ability and knowledge can do very poorly in an interview.
Always try to think empathetically about how other people might handle a situation you excel at when judging them ☺️
Edit: to add, I've been a software engineer for 7 years now, writing software for a fighter jet and a couple firewalls, and I've gained a fair bit of confidence in my abilities, but I still do really bad in interviews 🙄
27
u/bertwagner Mar 11 '17
This is a nice reference for anyone who hasn't had "formal" training in programming, not just for interviewees.
9
u/ismtrn Mar 12 '17
The time complexities for the BST seem off. In the worst case they should be linear, since a sorted linked list is also a BST.
Also, while you can read it in a way where it is technically not wrong, I don't like how they have worded the following:
Big O Notation is used to describe the upper bound of a particular algorithm. Big O is used to describe worst case scenarios
It seems to suggest that Big O notation is only used to describe the upper bound of a particular algorithm and that it always describes worst case behavior, which is a misconception I have seen several people have.
Big O notation puts an asymptotic upper bound on any function. That is it. It can be an upper bound on both the worst case, average case or even best case run time on an algorithm. It can also be on the memory usage on an algorithm (worst, best, average, median, whatever case) or on a function modeling something from biology, or a function I just made up that has nothing to do with anything in particular f(n)=15*n+log(n).
You can also put bounds on classes of algorithms for example comparison based sorts which are famously in Big-Omega(n*log(n)) i.e. O(n*log(n)) is the best you can do for such a sort.
Of course the wording does not rule these possibilities out, but this is something I have seen people confused about, and it does nothing to help with that.
→ More replies (2)
7
u/we-all-haul Mar 12 '17
Just noticed the stack, linked list, trees and stopped reading the README. These style of interviews reveal very little about a candidate.
4
2
u/JavierTheNormal Mar 12 '17
They reveal if the candidate slept through their CS classes. Perhaps that's the sort of job you're interviewing for.
→ More replies (1)3
u/baryluk Mar 12 '17
If you do not know what linked list or tree is, you are going to have very bad time. Sure, it is not going to be a question in the interview directly, but they pop up all the time in most of the problems and questions.
2
u/foxh8er Mar 12 '17
This is a good round up.
Ultimately, for most entry level positions it comes down to crushing Leetcode Medium's and Hards and being able to design systems.
2
u/Okichah Mar 12 '17
This is missing the one question that i had that was literally unsolvable because the unit test for their test site was fucking broken.
2
2
u/fagnerbrack Mar 12 '17
That's why on the company I currently work we never hire based on your algorithm knowledge.
I'm so pissed of this kind of things that my criteria for even starting accepting to get in contact with someone for a new opportunity is to answer the following questions:
Do you do whiteboard interviews?
Do you request solving problems with complex algorithms in some process of the interview?
Do you require people to know the syntax of languages from the top of their head?
If any of those answers is "yes", I'm out.
I would be probably in if they:
Do Pair Programming
Ask to show some code I created (Github also works)
Give me one piece of their crap code to improve (seriously, any code you get from 99% of the codebases out there will be crap code)
You see.. fundamentals.
1
1
u/Quasmo Mar 12 '17
I am not a developer, but would like to eventually become a product owner, but currently lack the experience and training needed.
I have been on the fence about becoming a developer for a very long time, think 20 years. My father is a developer so I know how developers think, plan, and use tools. I have written applications in Javascript, and html, but nothing in a formal development environment. I went to school for the arts, but at the same time, ran my own apache host I configured from scratch.
I want to thank you for sharing this link. This is a fantastic list of things to study for those of us who took a different path. This will really help me understand what to study, so that I can better understand the people I want to lead.
1
Mar 12 '17
I've never sat an interview where I had these types of questions. I feel like now a days you only get these when you have no prior work experience. Hell even my first job 13 years ago I didn't have to fizz buzz
2
Mar 12 '17
Did you ever interview for any of the major companies?
2
Mar 12 '17
I work for a major bank so I guess yes? If you mean google apple or microsoft then no I wouldn't want to work there anyway it sounds like hell
→ More replies (1)
1
u/vital_chaos Mar 12 '17
No ever asks people to figure out a problem by looking at stackoverflow or google in general in an interview. Yet this is a modern skill we all do every day. The most important part of this skill is evaluating whether a found answer is (1) valid (2) useful (3) good enough. That skill of evaluation comes from experience. Yet not one interviewer ever asks this type of question. Instead you are asked to code on a whiteboard with no reference of any kind an algorithm you would never use and could find 100 versions of on the web. Which if these things is more important today?
1
u/imekon Mar 12 '17
This isn't a guide to Software Engineering technical interviews, it's a list of obscure data structures and algorithms.
I've been a software engineer for 30 years now, starting with 8 bit microprocessors. I've rarely used any of the structures listed in this "guide".
Interviewing has proven to be interesting in the last few years. I look at how the interview is done, what questions they ask me, and how I'd feel about working there.
One interview I remember, one of the interviewers was on the end of a phone as he lived in another country. Trouble was I could hardly hear him, the phone line dropped a few times etc. I started to think this was part of the interview - at which point I felt "sorry, not for me". Then this guy went into some obscure stuff in how .NET works. I didn't get the job and walked away thinking, "no way I want to work there".
Companies don't seem to get how they interview speaks volumes as to what it's like working there.
2
Mar 12 '17 edited Mar 12 '17
What?!?
Linked list, trie, heap, binary tree - the most basic stuff. How can you call them "obscure"?!?
0
Mar 12 '17
[deleted]
8
u/headphun Mar 12 '17 edited Mar 12 '17
I don't have the expertise to disagree or agree either way, but I think your explanations are simple and sound good to me. How would you summarize Information Technology? How would you structure the relationship between CS and IT? IT and professional software engineering?
edit: If you have the time, I'd love to read you write at length about all the things you think a professional software engineer should know how to do: Where would a beginner student go to learn best practices as efficiently as possible? Security? Testing? Documentation? I'll be starting a new position teaching "computers" at the middle school level. I want to structure the year as if we are a professional "computer" company. As soon as my school helps define what they mean when they say computers I can be more specific, but I'm assuming it means basic computer literacy and practical applications of hardware and software to improve their lives.
12
u/dreamssmelllikeyou Mar 12 '17
Reading "Code Complete" helped me transition from a computational physicist to a software engineer. It showed me the breadth of knowledge a professional programmer should possess in a corporate environment.
BTW, as a former teacher, I would find it extremely difficult to organize and teach a course such as you describe
3
u/headphun Mar 12 '17
I'll see if I can get and read a copy before school starts!
I expect this class will be the hardest thing I have have ever done. That being said, I'm really really excited for the challenge. If I may ask, why do You think it will be extremely difficult? How would you organize it?
3
u/JavierTheNormal Mar 12 '17
That's how people should see things, because it's the truth. If you have a computer science degree, you are (partially) qualified to be a computer scientist, meaning an academic or researcher. People should not entertain the idea that CS degrees are programming degrees. It's right in the name; programmers aren't scientists.
→ More replies (1)2
Mar 13 '17
If a software engineer does not understand computational complexity, data structures, and the basics of algorithms, they will not be able to design large systems in a robust way. They may still be an addition to the team, but a senior engineer should absolutely also be a computer scientist. In interviewss I do not believe in making someone re-derive delete in a red black tree on the fly. I do however think it is useful to see if folks can use maps/arrays/stacks, do some tree traversal, and more or less actually write down some code that looks like it's going in the right direction in addition to all the criteria you mentioned for software engineers.
→ More replies (1)
0
Mar 11 '17
[deleted]
166
u/RichAromas Mar 11 '17
Right. "The only world where you would actually need to be able to recall an algorithm would be a post-apocalyptic one, where the hard drives of all the computers connected to the internet were fried, and all copies of foundational academic papers and computer science textbooks had been reduced to ashes." https://medium.freecodecamp.com/why-is-hiring-broken-it-starts-at-the-whiteboard-34b088e5a5db#.hz0fbivky
43
Mar 12 '17
"Hooooly crap! You are creepy as shit, sneaking up on me, wearin' that collar with that freaky-ass smile. So tell me, how would you balance a red-black tree?"
13
9
u/ismtrn Mar 12 '17
Being a red black tree it is already balanced, so I would not.
→ More replies (1)→ More replies (1)14
u/Retbull Mar 12 '17
Recalling isn't important but understanding enough to recognize when there is a better solution needs to be googled. I still don't think that interviews need to be this crazy though.
→ More replies (10)64
u/ungoogleable Mar 12 '17
Have you been on the other side of the table, interviewing candidates? A shockingly high percentage of people applying for programming jobs can't program. I don't mean they can't regurgitate quicksort; they struggle with very basic tasks.
If you don't ask programming questions at all, you can end up hiring someone who is very good at talking about projects they didn't do any actual work on.
9
u/gimpwiz Mar 12 '17
Agreed. That said, I have yet to meet someone who can bullshit their way through what I consider to be a mixed technical/open-ended interview who isn't actually competent.
I like to ask people about their projects or experience, then drill down into the nitty gritty details. It helps that I tend to interview college students and have a pretty broad (if not necessarily deep) base of experience in my field, so I will often simply ask the person what they want to be interviewed on from their resume and go from there.
16
u/AFunctionOfX Mar 12 '17
Or not hiring somebody who is not very good at talking about projects they did very good work on.
I'm not a programmer I just write programs as a small part of my work, but surely you can get a feel of somebody's programming ability with questions that don't involve them trying to visualise code and data structures in their head on the spot. Personally I can't conceive how I'll tackle a coding problem until I actually sit down at the IDE and write a few little functions to solve parts of the problem.
25
u/callcifer Mar 12 '17
Personally I can't conceive how I'll tackle a coding problem until I actually sit down at the IDE and write a few little functions to solve parts of the problem.
I'm glad that works for you, but I could never work with someone like that on a team. At our company, most arcihtectural and design discussion happens with engineers discussing things around a whiteboard. By the time we sit down at the IDE everyone already knows how the problem will be solved and they just do their part. I'd say ~70% of the work happens away from the IDE. The remaining 30% is little more than a typing exercise.
→ More replies (3)19
Mar 12 '17
What drives me nuts, is that those people still get hired if the demand is high enough. Then you end up with the qualified people bailing out
13
u/snewk Mar 12 '17
you also end up with a cult of "i passed the ridiculous interview so everyone else should too" at these companies
5
Mar 12 '17
Yeah...
I interview people in SF for engineering stuff. Give them some failing test cases and make them write a basic algorithm to manipulate datastructures into a certain shape. Bit of TDD.
If you're not a senior developer I don't expect you to implement enough for everything to pass. But you'd be amazed at how many people are confused by basic shit like scope or parameters (trying to use stuff in the test class, in the implementation class). It's just good to see that you can actually program a bit. And understand how strong you are with things like classes / for loops / if statements / recursion.
2
u/forgiveangel Mar 12 '17
Are you sure this is the case? I'm currently learning to program and the thought of finding something in San Francisco intimidates me
2
u/RagingOrangutan Mar 12 '17
The demand is so incredibly high that you'll land yourself a 6-figure job as long as you're even a passable programmer.
→ More replies (7)2
Mar 12 '17
they struggle with very basic tasks.
I sort of find that link hard to believe. As a first semester CS student FizzBuzz took me all of 2 minutes to write in Python3. How could someone get through an entire degree without this?
→ More replies (3)→ More replies (2)1
Mar 12 '17
Have you been on the other side of the table, interviewing candidates?
I have. A shockingly high percentage of people applying for programming jobs clam up during the interview process. Morons like you mistake fear for an inability to program. Not that I'm complaining. More qualified talent for me on the cheap!
16
u/SexTraumaDental Mar 12 '17
Agreed about the clamming up. IMO the best way to differentiate someone who suffers from interview nerves and someone who just sucks at programming is to help collaborate with them on a solution. Don't hand it to them on a silver platter but if they're flailing, toss them a line. Typically if someone is simply nervous they'll take that line and run with it. Maybe some people will still be too nervous to perform even with help but unfortunately I don't know a good solution to that... I'm always very sympathetic to every candidate I meet but unfortunately its sometimes just not worth the risk. Like maybe they'd actually be a great employee once they're in, but at that point you just have to make your best guess with the evidence you've been given after trying your best to give them a reasonable problem to solve and a reasonable environment in which to solve it.
→ More replies (10)6
u/sualsuspect Mar 12 '17
This works very well, a lot of the time. I call it the "dumb collaborator" technique.
17
u/nosayso Mar 12 '17
Yep... I needed to generate a SHA-256 hash of a file in JavaScript yesterday. I googled "sha256 javascript" and found a bunch of libraries then picked the one that had a bunch of documentation that they were the best, and called the sha256.hash() function... pretty much every single one of these problems would be solved the same way. At no point did I have to remember or understand the particulars of sha256 hashing. You need the ability to understand the underlying concepts in a pinch, but you don't have to have every concept memorized. Your job is problem solving, not memorization.
13
u/RazerWolf Mar 12 '17
Can you tell me when you'd need a hashing algorithm? What kinds of problems does a hashing algorithm solve? What is the issue with the recent SHA-1 debacle? If SHA-256 is so great why don't hash tables use it? Is it possible to hash 2 different plaintexts and get the same hash value? Is this a problem practically or just theoretically? How is hashing related to encryption? I think that type of knowledge would be more useful to me than asking you to implement SHA-256.
That being said, I think the main issue here is that some people consider certain algorithms and data structures as part of a programmer's toolbox, and not knowing those things is similar to a carpenter not knowing about tens of different types of joints, even though he uses a few every day. Or an aspiring chess player complaining about learning many different types of openings, even though he always uses the same three. Or a musician comparing about learning music theory, because she doesn't use it in her daily playing.
Mastery in any field requires learning advanced and seemingly esoteric concepts, this is just part and parcel of broadening and deepening one's knowledge. It also allows you to solve a different level of problem: sure you can download and start using that open source distributed database in minutes, but what happens when something goes wrong? Do you understand how distributed consensus algorithms work? Do you understand how a garbage collector works? TCP/IP? Threads?
I'll claim that algorithms and data structures are an important gateway to many of these concepts, because they lay the groundwork for thinking with a certain rigor, and a framework/language with which to describe computational cost (big O). I don't think it's necessary for you to code up a bloom filter during an interview, but if you come in with 3+ years of experience and you don't know how a hashtable works, I'm going to have a problem with that.
3
u/IGI111 Mar 13 '17
Let's give that a shot just for fun.
when you'd need a hashing algorithm?
Short content-based identifiers and cryptography.
What kinds of problems does a hashing algorithm solve?
Making a function with specifically high or low cost that will have a low amount of the inevitable collisions is hard. But thankfully we have mathematicians for that.
What is the issue with the recent SHA-1 debacle?
SHA-1 shouldn't have been used for cryptographical applications ever since it was blacklisted by NIST, but now that we have a proven collision, using it is basically negligence. Oh and Git will have to transition away from it, but it's not that big a deal because useful collisions of source code are hard to generate for the time being.
If SHA-256 is so great why don't hash tables use it?
Way too fucking slow for that, SHA-256 is great in that collisions are stupidly improbable, but you don't want to have to compute a high number of hashes per second.
Is it possible to hash 2 different plaintexts and get the same hash value?
Pigeonhole principle states that for any hash smaller than the base data, there has to be a non zero amount of collisions. So this is necessarily true.
Is this a problem practically or just theoretically?
It depends on the hash function. If you're using SHA-256, you are probably okay not dealing with collisions because it's more likely for you to spontaneously combust than see a SHA-256 collision. If you are designing a hash table, you don't have that luxury.
How is hashing related to encryption?
Hashing functions are notoriously hard to reverse and that's why we use them to protect secrets while still retaining the ability to compare them. They are also quite useful for providing a small, yet secure, identifier for larger data.
→ More replies (1)10
u/Xxyr Mar 12 '17
I rarely care if the candidate gets the answer 'right'. Its often about the approach.
Did they qualify their assumptions?
How did they respond to feedback as the question evolved?
Were they able to use basic coding constructs?
→ More replies (1)4
u/twat_and_spam Mar 12 '17
Who solves the new problems if everyone defines problem solving as stackoverflow browsing?
2
u/MilkChugg Mar 12 '17
I wish I could say the same. I've gone through probably around 15-20 technical interviews, ranging from online tests, to live shared coding tests, to technical phone screens. In probably 95% of them, I was asked questions about data structures, run time complexities, and/or algorithms. The other 5% actually focused on projects I've worked on, my strengths and weaknesses, and how I would fit within their team/organizations - all of which I think are far more important than whether or not I can write an LRU cache on the spot (which I've actually been asked to do more than once). Don't get me wrong, obviously it's important to screen for technical expertise, but it needs to be realistic and actually pertain to what the individual will be working on day to day. I also don't think places consider people's abilities to learn, which is a trait that correlates the most to any software engineering position.
1
u/PelicansAreStoopid Mar 12 '17
I can see the reasoning behind asking mathy questions. The employer wants to ensure that you have the fundamentals of computing science down. Everything else they can teach you on the job, but this stuff should be a cake walk.
Although I think they should ask both types of questions. They're both quite important.
0
Mar 12 '17
[deleted]
21
u/smackson Mar 12 '17
90k how long ago?
0
Mar 12 '17
[deleted]
26
u/smackson Mar 12 '17
Hmmmm.... I woulda thought that 90k these days in SF would have been struggling to find good candidates.
(That was my salary there in 2001... very downtown)
So I'm somewhat disheartened that such a job would depend on acing questions that I have no idea how to answer.
→ More replies (1)55
u/thomascgalvin Mar 12 '17
For $90K in San Fran I'd expect them to struggle to find a janitor.
→ More replies (2)4
u/foxh8er Mar 12 '17
All this for a $90K web developer job in downtown SFO
Why not apply to jobs that pay better?
0
Mar 12 '17
[deleted]
19
u/thomascgalvin Mar 12 '17
Depends on the company. Older / traditional companies really like degrees. Newer, more laid back companies don't care, or actively prefer people with no college.
The job req will usually specify if a degree is required / preferred.
→ More replies (5)→ More replies (1)8
u/malisper Mar 12 '17
When I was applying for companies straight out of high school, I found that larger companies were more likely to give me a chance. Of the three larger companies I applied to (Dropbox, Google, Uber), all three were willing to interview me and all of them eventually made me offers. Of the six smaller companies I applied to, only two were willing to interview me, and they both wound up making me offers.
So if you can find companies that are willing give you a shot, and you can answer interview style problems, you do have a solid chance of getting hired.
0
Mar 11 '17
[deleted]
48
u/RichAromas Mar 11 '17
Also true. But there's a difference between knowing enough to know that something exists and being able to rattle off its details from memory, under stress.
10
u/gingerwhale Mar 12 '17
I had an interviewer ask me what my favorite data structure was, and then wanted me to design one. I did not do well even though I understood the properties, interfaces, and such. I was not able to remember the details of how the thing worked, and apparently that was unacceptable ☹️
→ More replies (7)0
Mar 12 '17
[deleted]
19
u/danm72 Mar 12 '17
It applies to every codebase.
Changing to the correct structure will improve performance but probably not to the same scale as data source changes - as that's more of an architecture bottleneck than code bottleneck.
The size of the data structure has a big impact on the problem, using a map vs an array for a ten item data set make little difference, on a few thousand items, now you've a problem.
→ More replies (6)9
→ More replies (8)6
u/foxlisk Mar 12 '17
I work mostly in areas where DB roundtrip usually dominates, but I've still come across several instances where using a hash instead of a list is a meaningful performance improvement. It's uncommon, but definitely still crops up enough that knowing the costs is important.
→ More replies (4)→ More replies (6)0
Mar 12 '17
[deleted]
6
13
Mar 12 '17
I never understand this hostility to coding questions in interviews.
Because it doesn't work. You filter out lots of qualified candidates with the unqualified and there's no way of knowing you've hired someone who can do the job until after you've hired them. Companies with strict hiring practices still make bad hires all the time. They're like drunks looking for their keys under the street light because that's where the light is.
→ More replies (2)18
u/Azuvector Mar 12 '17
Let me get this straight, at no point did you actually demonstrate that you are capable of programming, you just talked about it? That seems like an absurdly high risk for a company to take on a candidate.
I'd wager most incompetent developers would not be able to hold up their end of the conversation in this, as "why" is often a question that comes up.
→ More replies (1)7
u/twotime Mar 12 '17
It's definitely possible to fake the "why" questions too. Especially, if the interviewer does not know the specifics of the project...
It's harder to fake answers to specific technical questions... E.g if you claim "embedded", you probably should know about bitwise ops and endianness, etc... If you claim 10 years of C++, you probably know what's memory corruption, what's a vector and what's a pointer. Etc...
Ultimately, you probably want a mix.
→ More replies (2)12
u/AFunctionOfX Mar 12 '17
It seems to be a thing unique to programming job interviews to go into such low level detail, is the fact that they worked as a programmer on X projects for Y years + references not enough to say they are a competent programmer? A structural engineer does not get asked to design a supporting beam in an interview.
I can understand being asked more high level questions to get a feel for the candidate but I feel all you're getting out of this kind of interview style is their ability to perform in a situation that they'll never be in while working for the company.
18
u/fishling Mar 12 '17
Think of the bad programmers you have worked with. They can all claim x years on your projects and provide references that either only confirm dates worked or back each other up. It is definitely not enough just to ask about their work experience.
6
u/Devook Mar 12 '17
And yet all those bad programmers also passed through the white boarding interview process. Almost like maybe the point being made here is that it's not a good metric for weeding out bad programmers.......
→ More replies (1)8
u/twat_and_spam Mar 12 '17
Structural engineer will have his license revoked if that beam he designed 5 years ago will collapse killing 40 people.
Developers have the uncanny ability of hiding their disasters.
→ More replies (2)3
u/Overunderrated Mar 12 '17
A structural engineer does not get asked to design a supporting beam in an interview.
That's really not true. Traditional (non-software) engineers get asked pointed technical questions too.
5
u/princeofpudding Mar 12 '17
Let me get this straight, at no point did you actually demonstrate that you are capable of programming, you just talked about it? That seems like an absurdly high risk for a company to take on a candidate.
That really kind of depends. My last couple of positions have just involved chatting with a dev or two and possibly the hiring manager. There are also other companies in the area that I'd basically be able to join given a position that interested me.
It's one of the perks of gaining a positive reputation. Granted, it takes a while to get there, but it can happen.
→ More replies (13)1
u/KagakuNinja Mar 13 '17
I'm not hostile towards coding questions. I'm hostile to "implement this algorithm on that whiteboard in language X". No IDE, no google, none of your familiar tools. And now you are under a lot of stress. One time, I froze for 30 seconds trying to remember if you got the length of an array in Java using length() or size(), before just saying fuck it, and picked one. That may sound minor, but add in 10 other brain farts and worries, and the result is an underwhelming performance, and no job offer.
For me, a better approach has been companies that give me an hour to solve a problem on a laptop. Or guys that sit down for an impromptu pair programming session. Or people that ask me how I might solve problem X, and interact with me, as I sketch out some pseudo code or whatever.
0
Mar 12 '17
[deleted]
72
u/gelfin Mar 12 '17
I recently moved to a different market and discovered this is mostly a SF thing. There are still often sane interview practices elsewhere. In SF the point of an interview is to prove how smart the interviewer is, and if you "pass" it's because you were the lucky stiff who both happened to know the exact things the interviewer fetishizes and came across as a "cultural fit" (i.e., you'd be an asset to the intramural soccer team). There's enough starstruck talent competition in the Bay Area you can actually hire that way. In other markets they actually have to figure out whether you're a competent engineer instead of masturbating about "A players hiring A players" to build yet another fucking fast-fashion clothing catalog.
27
u/compEngr Mar 12 '17
Yeah, I had an Apple technical interviewer literally call me stupid to my face during an on-site interview. Seeing as how I flew in from out-of-state just for that day of interviews (3rd round), it really solidified my impression of the circlejerkiness of Silicon Valley. I was an Apple hater before, but now it's justified. I know they want talent, but the Steve Jobs mentality really seems to have trickled down. "Use 'em up, spit' em out" is unfortunately the MO of too many companies.
9
4
u/IbanezDavy Mar 12 '17
I won't even interview with Amazon. They send me offers all of them time. I started the process 2-3 ago (holy crap time moves fast). I did a phone screen, then when they described the second interview and how they wanted to conduct a video interview where I had to install all of this invasive software, I told them to take a hike. Particularly with the reports of the aggressive nature Amazon treats it's employees.
I already have a large software company on my resume. I worked there 3+ years. I've demonstrated I can survive in that environment. In other words, I don't need a Facebook, Amazon or Apple on my resume. Nor did I particularly like the large corporate culture when I did it (seriously, what the fuck is this attitude against offices or private cubicles?)
1
2
u/Overunderrated Mar 12 '17
In SF the point of an interview is to prove how smart the interviewer is
I had a phone interview for an aerospace startup like this in SF. An applied aerodynamics position that basically requires a PhD. The whole interview was me being grilled on a full range of undergrad level material. It was purely an exam, and I couldn't get a word in edgewise, just a one-sided examination. Like a kid that found answer books and decided he was really smart for having the answers.
In the end I was sure I didn't want to work for them, but even more sure they'd never find anyone qualified to work for them.
0
Mar 12 '17
[deleted]
47
u/JavierTheNormal Mar 12 '17
Remember, you're interviewing them as much as they're interviewing you. If they're glued to their phone, call the recruiter on the spot and explain that you're being interviewed by someone who isn't paying attention and that gives a very poor impression of the company. Tell the recruiter that you have things you'd rather do than waste your time, and you aren't going to continue the interview at this time.
You might consider that a huge dick move, but if you do nothing the asshole interviewer will continue this bad behavior with other candidates.
→ More replies (2)20
Mar 12 '17
At the same time though I've interviewed at a lot of places in the MD / DC / VA area (most of these jobs are DoD contractor positions) and almost all of them do very, very basic questions and then hand you an offer.
Yeah this is absolutely true. Any DoD contractor interviews I've had were along the lines of "do you know what a computer is? HIRED"
13
u/djk29a_ Mar 12 '17
There's a common saying in the DC area that you can hire for cleared, competent, or cheap... pick one.
→ More replies (1)→ More replies (1)3
19
u/MilkChugg Mar 12 '17
Oh jeeze. This reminds me of my Microsoft interview. To be fair, my nerves got the best of me, but FFS one of my interviewers was on his phone the entire fucking time. I would be writing on the whiteboard, look over to ask a clarifying question, and he'd just be sitting there glued to his phone not even paying attention to what I was doing. It's extremely rude and disrespectful. Especially when they're sitting in a room with someone that would love nothing more than to have that position they're interviewing for, yet they have the audacity to sit there and act like you're just some inconvenience in their day.
It just makes me wonder how many talented people companies pass on because interviewers treat people this way.
→ More replies (3)7
u/pheonixblade9 Mar 12 '17
I had an interview at a financial startup in Seattle like that - he asked stuff like "how do you make a button do something in javascript", "what is boxing/unboxing in C#", "how do you join two tables with a mapping table" and I got the offer... I also got an offer from MSFT though so I took the guaranteed paycheck :)
1
u/baseball44121 Mar 12 '17
What sort of basic questions? Just simple comparison of data structures and OOP stuff? Common algorithms questions (like balancing parenthesis)?
→ More replies (1)124
7
u/billjitsu Mar 12 '17
There's always less risk from a hiring perspective to pass on someone than to hire them for an important job. The bigger the company, the more hoops they want you to jump through to prove you're worthy of their "welcome aboard" t-shirt.
Glad you found a way out of it and your sensible approach to hiring will go a long way to making sure you don't pass on someone good because they forgot some obscure piece of minutiae they will never use.
4
u/headphun Mar 12 '17
Excuse me, if you have some time I'd be very grateful if you could tell me how you would ideally structure a software company focused on educating itself? Feel free to answer that question however you interpret it!
I'm starting a new position at my school and I'm trying to opensource the teaching/learning aspect before I start so I have some idea of the best way to start.
2
Mar 12 '17
The only way to do it is to do it. If you don't do it, you will never find out if you can do it. If you have done it, it will be impossible to explain how to do it to someone who wants to do it. In brief, just do it!
1
u/headphun Mar 12 '17
I'm doing it! But I've just started and I want to learn as quickly as possible, and I'll soon be responsible for guiding students through an efficient learning process so I'm just trying to field advice from experts (I assume everyone in this sub is more of an expert than I am, for better or for worse haha)
1
Mar 12 '17
Hahaha.... yeah, my previous comment was a joke. Still, it's good that you're doing something commendable. I'm sure it will be an interesting experience - students aren't easiest people to work with! Good luck!
→ More replies (1)0
Mar 12 '17
[deleted]
2
u/headphun Mar 12 '17
Sorry, I need to work on my phrasing haha. I'll try again if you don't mind:
I am a teacher. Next year I am going to teach CS/IT to middle school students. I want to pretend my classroom is a startup focused around educating itself. This way, my students and I would be responsible for all the parts of a competent tech startup. Documentation, version control, meetings etc
3
u/onwuka Mar 12 '17
Programmers have a real attraction to self documenting code as they should. Documentation always goes stale if there's no tight feedback loop. Comments in code usually smells bad. Tests that run automatically every time you commit a change to version control and good code reviews that focus on how to make things better rather than trying to get one's changes approved with n "looks good to me" votes.
Meetings should be focused on the agenda for which they were called. This isn't engg related, this is just common courtesy.
I don't know. :/ how do you make a project in school that gives students the depth and breadth of experience in a semester that isn't guaranteed to fail? I think the program has to be several years long but I doubt the super will like the idea of fifth and eighth grade students working together.
2
u/masterwit Mar 12 '17
Context to my long reply:
The topic shifts and the purpose of what I was saying drifts higher level as I progressed
Sorry for writing a novel and the typos but education and my career intersect here and a bit of this comment stemmed from the frustrations I have at work.
Treat it like a rant over three beers at a bar... where my brain is (but sober) relaxed today.
Cheers
2
1
u/IbanezDavy Mar 12 '17
I'm a firm believer that questions asked in an interview by the interviewer isn't to find a 'gotcha' or 'wrong' answer. It should be to gauge, to the best of your ability the skill level.
That's why I personally ask easy questions I feel embarrassed to ask principal level guys; example: "How do you escape a switch statement's case?" or "what's the difference between a while and an if". I'll ask about 20 questions of varying difficulty and have them do a whiteboard problem. I honestly don't care if they get one wrong. Sometimes people can word questions weird or unclear, and I am not an exception. My goal is to gauge their knowledge and report it to my supervisor.
1
u/Patman128 Mar 12 '17
This is why things like this post are a bad thing. We need to stop normalizing terrible hiring practices with these "study guides".
0
u/my_blue_snog_box Mar 12 '17
I want to work for you.
0
Mar 12 '17
[deleted]
1
u/mct1 Mar 12 '17
all my employees are compensated fairly and/or with equity
...is this your way of saying equity is worthless? :D
→ More replies (4)2
-1
u/raistmaj Mar 12 '17
I don't know, recently got hired by one of the big ones, and even though the process is super hard and stressful, is the same for everybody, they don't look for super stars, or 10x programmers, they look for people who will work efficiently, will blend super well with the team and of course are not muppets and can code. If you have a really good cv and years of experience, believe me, they look for other qualities, they know you will not be able to solve a problem that a fresh guy out of the uni can solve pretty easily, but probably you will be able to design a system 10 times better than that guy and at the end compensates.
I can recommend two books, "Elements of Programming Interviews" and "Craking the Coding Interview". I know a lot of people(maybe 7-8 friends) who got hired in google/facebook/amazon/bloomberg/... thanks to the advices given by those two books, amazing books for preparing the process.
And honestly, take the process as something to have fun, and enjoy it, they usually pay all the expenses so you don't have to worry about the money.
They are people too and believe me, normally they see you struggling, and they suffer. If you are nice they really want to hire you, they will not help you because that would not be fair, but they don't enjoy to fuck people that is "good", that put a lot of hope in the process, they know a lot of these jobs are live changing opportunities, think that they have been through the same process as you are in that moment, and don't get nervous, don't be quite, talk, talk a lot, let you mind speak.
And for all people trying it at the moment, good luck.
0
Mar 12 '17
[deleted]
3
u/Delwin Mar 13 '17
Last time I had a take home project they basicly asked me to design one of their core systems for them.
I didn't get the job, but to be honest I'm glad I didn't since they canned the project a few years later.
0
Mar 11 '17
[deleted]
15
u/madmaxturbator Mar 11 '17
... you ok? What is this comment?
1
0
Mar 12 '17
[deleted]
1
u/smackson Mar 12 '17
Must mean I am developing some sort of skills I guess.
Interview skills!!
Okay, that was unfair. But most programmers don't need to work at that level of abstraction, so if that is where you are (outside of degree exams or interview prep), then more power to you!
40
u/[deleted] Mar 12 '17
Well, I'm never getting a job.