Acing the technical interview
aphyr.com
aphyr.com
> The William Gibson version would begin thusly:
> It was hot, the night I burned the Seeker. Moths batted themselves to death against the humming neon signs just outside the single window in the cramped room. There were ancient electronics piled to the ceiling in here, hot new chipsets from Taiwan still unwrapped distributed unevenly amongst them.
> The Seeker put his hands on his hips, brushing aside the corners of his Sukajan jacket bomber jacket replica. "I heard you and Bobby were hotshots, once. Real.. artístes", he said, the last word paired with a smug grin. "Heard you could do things."
> "Things like what?" It's been 20 seconds and you've already wasted too many cycles with this guy.
> "Things like making lists, just, fold up inside themselves. Come out the other way around. Crazy things."
> You grit your teeth. The dex has left your system and you're starting to feel a massive drug deficiency coming on. "Crazy things cost money", you manage. The lists already unfurling in your head, you start typing as quickly as you can to hide the microtremors.
I just wish someday I could write like this. Beautiful.
I am curious what you meant by this. Would you mind elaborating?
I myself have been working through cracking the coding interview in an attempt to migrate from upstate new york to the bay area. Maybe I wouldn't bother with positions that demanded white boarding if I already had a position over there and could be selective but maybe not. It kind of feels like it's all part of the game at this point.
It's a bit of a slog but it's not that hard if you're motivated to get a new job. My girlfriend has gone back to school for nursing and she works a shit load harder than me all the time, while I just do a month or so of ~ten hours a week of prep for every round of interviews I do.
I've done hundreds of tech interviews over my career, and especially in recent years (now that companies are trying new things), it's completely random.
Some will do "Cracking the coding interview" type shit, some will do code reviews, some will give you a take home thing you have to present, some will do pair coding. Some do algorithms only, some do design discussions only, and so on and so forth.
So any prep I do will be a shot in the dark and 99% of the time I'll have to do something I did not prep for. So I don't bother trying.
Notable exception is my current job, which is a big tech co with a semi well known interview process (not as infamous as google or facebook, but still), and they gave me a fair amount of info up front. I also -really really really- wanted to work there because the team I wanted to work for did things no one else does. So i bit the bullet and studied/practice.
That was literally the first time (and probably last) time I did.
I totally agree that it's a shot in the dark, though.
To be sure, some people take it too far. The "four months" figure does not come from me.
Curious if you have any examples. I have really hard time motivating myself to study same old ds and algorithms too .
Solving those problems gave me a reason to touch lots of parts of the language and was also intellectually interesting. See, for example: https://github.com/brianquinlan/learn-rust/tree/master/i18n
> Some will do "Cracking the coding interview" type shit, some will do code reviews, some will give you a take home thing you have to present, some will do pair coding. Some do algorithms only, some do design discussions only, and so on and so forth.
"Cracking the Coding Interview" and algorithms are the only things you mention that you don't spend all day doing at your day job. Spending time studying algorithm questions will be hugely beneficial for some interviews. For others, they'll quiz you on stuff you (should) already know.
I think that if you are working on some moderately challenging and varied personal projects, that's probably also a great way to prepare.
The way I see it, no experienced candidate should have to do "interview prep" because the work that he/she does on the job should be more relevant to his/her ability to do the job than any form of interview prep.
To make an extreme example, John Carmack's work time is probably better allocated actually doing work than brushing up on "Cracking the Coding Interview" problems. In an ideal world a software engineer's candidacy for a job would be based strictly on his ability to do the job, not academic trivia questions.
Most interviewers aren't really interested in figuring out "is it worthwhile that you built this thing / did you do it right / why do you think this was something worth learning?" when it's so much easier to evaluate your whiteboard code on a narrow problem against some ideal standard solution.
You can tell them about how you were able to learn enough about a particular database in a couple weeks to be able to cut 90% of the runtime out of a hot query in your first few months at a job, since that was an area that wasn't scaling well and it was something your boss asked if you could take a look at, and they'll be like "ok that's nice, now implement a trie." What's the point of even having experience building and running real systems if that's the process?
If you'd rather be building than practicing whiteboard questions, your best path to success is probably going to be a less predictable one where you need to come across one of the right companies willing to work harder at interviewing because they have to find the best candidates who fall through the cracks at the places with the name recognition.
If you are a good developer who sucks at whiteboard interviews, write open source code that everybody can see.
Otherwise there is no reason an interviewer can or should trust whatever story you tell of past successes.
I'm saying that you can't complain that an interview doesn't show you are good coder if there is no other way for somebody to look at a project you've done.
Saying you did X/Y/Z at your last company but can't share the code since it belongs to them isn't a valid excuse for why you have no code out in the world to show off.
Also, some people have enough flexibility to learn new languages, technologies, frameworks, and such within the context of their day jobs.
Can't exactly contribute to open source if my contract says my employer owns everything that I do, and even if you think that can get tossed out, you'd better have a good legal fund.
Problem is, the skills you need to be a good interviewer don't necessarily overlap so well with the skill set of a good software engineer. It's much easier to get people to ask about what they know, irrespective of whether or not that will be an accurate indicator of technical skill.
It's been done, still doesn't get you a job.
So there is a conflicting case.
No company is going to be perfect at hiring just the same way as no person is going to perfectly crush every interview. But there is no world where having contributed quality code to an open source project will hurt your chances.
Instead it's usually "Huh, you seem like you just might not be a complete dullard. Would you mind proving it to us by taking this 3-hour HackerRank test? 'Coz we know you've got nothing but time. And you'll go through just about any number of hoops to get us to pay attention to you."
† Even the ones who ask for it.
†† Even when we patiently and politely point out the gaps and ambiguities, sometimes quite glaring, in their cute little "challenge" problems. Which, again, many to occur in at least around half of these exercises.
Would be interesting to see which companies actually look at your github profile like they claim they do.
It doesn't sound like you fully disagree, because writing OSS isn't that curated path, but sadly none of the devs I know who focus heavily on algorithmic whiteboard question performance look at open source projects. And they could justify this with the same one you give: people lie, people copy/paste code...
I've pushed my team quite a bit away from where they were when they hired me in terms of whiteboarding focus, and we're better able to hire senior candidates now than they were back then. The BS detection is a big part of this: ok, you were on a team that did [really cool sounding thing]. What part of it did you do? What specifically did you learn from it? Even in aggressively paced interviewer loops you probably have at least 45 minutes to get them to answer those questions, if they're ducking and dodging, or answer back with wrong information, or with stuff that makes it clear they used the wrong tool for the job and didn't know how to find the right one, then there you go.
It's easy to present code, but it's also easy to copy or memorize code. Some of the most impressive candidates I've seen are the ones where the "let me ask you this stuff about your past experience" discussion expands to fill the whole time slot and we never actually look at any code, because we're too busy talking about how you took a service from a single database to a multi-master geo-distributed easy-failover alerted and monitored system, or how your random side project to look for Hidden Markov Models in baseball player's batting results went (how'd you store the data? what libraries did you use? did you implement your own versions of algorithms? what made it hard to draw conclusions? etc).
Exactly this.
The memorable example for me was someone that worked on a military helicopter training simulator, and specifically, they worked on connecting the physical radios (used for internal communications between the crew) to the simulator. Sounds cool, involved network experience that was entirely applicable to what we were hiring for, and personally, I have a fascination with and have done a lot of interfacing of physical human-interface hardware to software.
However, the candidate was unable to explain details. What type of I/O hardware was used? Did you have to poll or did it push/stream changes? Did you run into anything weird with bad signals or missed state changes or restarts that posed a big challenge? No answers to this, because apparently they "just worked on the protocol".. but then couldn't remember anything about the details of the protocol (HTTP or something custom? Text-based or binary? TCP or UDP?). It was frustrating, because I remember otherwise liking this person.
They had similar responses for their most recent job (that they were at literally a few weeks prior).
I have a terrible memory, but even I can remember some of the biggest challenge highlights of my career. If I start talking about them, especially when asked probing questions, I will remember all the little details and could go on for hours.
I don't get it. Were they just coasting in the background, not really contributing anything meaningful, doing just enough to not be fired? Did the interview make them so anxious that they literally couldn't remember any details (it didn't seem that way)? Were they outright lying about what they did?
(S)he spends so much time playing translator that there's no time to sweat the details. That falls to the team.
Except that its pretty easy to see if someone is telling the truth about their area of expertise with a few open ended questions.
Not good enough for me. My engineers need to be able to collaborate with customers, management, and each other. They need to come up with ideas and explain them, advocate for their ideas. They need to be able to think, code, and collaborate.
Writing code is the easiest part of software engineering. In the environment I work, our engineers can't sit in isolation and submit pull requests. So while open source contributions are nice, being able to interview successfully is still required.
The hardest project I've worked on so far was a CubeSat project where I had to collaborate with Electrical/Computer and Mechanical engineers with specialized knowledge (orbital mechanics, the design of the custom boards, etc.) to develop the software. I had to communicate why certain hardware elements are absolutely needed in their design, why certain elements of the Attitude Determination and Control System need to be optimized, and so on. As well as why we needed many of software engineerings best practices, which when you step back and look at them from the outside some do seem fairly odd.
But on the other hand, it is not always needed. Also, I'm confident I could prove my capability without a whiteboard because I could probably talk about the problems and collaboration to resolve them on that project for well over 30 minutes.
If you're a Google or HFT firm working on massive scale or optimizing super low latency systems, sure it very well may be critical knowledge. If you're some random company with a CRUD app, this kind of hiring process isn't going to optimize for the most qualified candidates for the job.
[More] prone to biases and opinions? Let's assume this is true (I'm not convinced that it's such a slam dunk - someone who wants to say no to a candidate can find a way, especially if they aren't being shadowed or recorded (which would feel pretty draconian for the interviewee too)). Isn't it still just a way of making a lazy complaint, "but that's harder!" You as hiring manager are responsible for knowing yourself, knowing your interviewers, knowing their strengths and weaknesses, and knowing your own.
That makes it hard to assembly-line interview fresh graduates, but maybe you should have a separate process there anyway because they won't have much in the way of useful experience yet anyway.
This. You elegantly captured my thoughts.
Finance cares that you have past proven experiences in finance and they'll hire you for it.
Breaking into finance is the hardest thing to do, once you're in, you're good and you can have a great career.
Tech companies don't care what you've done and they rarely, if ever, ask about it.
Breaking into tech companies is only about rehearsing Cracking the code interviews, and once you're in, you have no guarantee to make any sort of career. You'll probably be out soon because things move too fast and the turnover is insane. Your next job is gonna be difficult to find because the next tech company won't care about experience and will try to pay you with free food.
10 minutes out of 4 hours, that's like less than 5% devoted to real world experience.
That said, having gone through loops from the other side, I know this isn't always the case and that your mileage may vary.
As someone who's worked as a software engineer in the bay area in tech companies this is 100% not my experience at all. Though tech interview definitely matters, experience also matters and the turnover is not insane. All of my coworkers who I have made friends with are still in this business and I've worked at a few different places. I just don't think you have any idea of what you're talking about.
> you have no guarantee to make any sort of career.
I have quite a good career. Others do too.
Actually, all of the jobs I've had have cared very much about past experience and have asked about it in the interview. If I weren't actively contributing in certain open source projects, and hadn't worked with certain technologies, I wouldn't be where I am.
1. Simple iterators vs Syntactic sugar both pass the same unit tests
2. The 'Java 1.4' style closely matches idiomatic golang code, which has high adoption and maintainability
3. People who want better iterators, also want better everything, leading them to use more progressive JVM languages like Clojure and Scala rather than just waiting for the Java spec to move forward
Sure, she might be forced to use 1.4 in her job but surely, any developer who's a bit passionate about what they do would be aware of the more modern version of their tool of choice?
If we use 1.8 where I work, I can't really evaluate whether she'll be able to adjust since she didn't make any time to adjust these past ten years.
For interviewing, the 1.4 style is totally valid, works in more environments and achieves the same result. I don't red flag folks who answer questions based purely on small preferences, in the same way I wouldn't red flag you for writing these loops instead of using map / reduce concepts instead.
A candidate who writes list.stream().filter(...).map(...).collect(...) gets big bonus points in my book. I'll ask them about efficiency, to see if they know when to drop to for-loops. If they write a 1.4 for-loop, I'll ask them to evolve or parallelize it to see if, at some point, they stop adding complexity to their loop and instead switch to a cleaner functional style. Starting from a for-loop and asking to implement some simple transformations like filters, reverse, group by, map, etc., does wonders to separate the wheat from the chaff here.
But I do carve out a special exemption for myself when[+] I interview someone. I kindly request the candidates that they don't use Scala or Prolog.
+: I interview a lot of people.
How the hell am I supposed to evaluate a candidate's performance if I have no clue what they are doing when attacking a problem?
Trying to follow what a Scala program does under the hood makes my head hurt. Following the edge cases through a forest of syntactical candy-floss is just too much. The plain Java parts are not bad, but the moment you pull out and nest all the special lispy shortcuts... from that point onwards I need to expend a big fraction of my brain cycles trying to figure out just what the hell the piece of code is actually doing. Or trying to do - because I can't properly trace the subtler logical parts.
And the end result is that, with Scala I do not feel qualified to assess your problem solving approach. Code should be written for computers to run, but for humans to understand.
it's also pretty reasonable to just say to hell with prolog, and go do other fun things with your life. But if you do care at some point, it's not magical. it's just a fancy search.
[1] https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-29.htm...
[2] http://www.scheme.com/tspl4/examples.html#./examples:h10
He's got an interview coming up, where he can work in the programming language of his choice. I tried to talk him into doing his coding problems in hand assembled X86_64, but he apparently wants to get the job and doesn't want to come off like an arrogant jerk, so it's going to be Python.
What if I offered to teach you basic Prolog for an hour ;)? One of my favorite side projects was playing around with it and seeing how clean and concise it could make the rules for T9-style (this was like ten years ago) predictive text matching, going from digit -> letter.
Lisps, MLs, stack languages, and SQL.
They use Scala and Clojure on a regular basis.
God I hope they offer me that job.
And I did get an offer.
And I'll try and answer all the progamming questions by using an excel spreadsheet`.
` Or whatever equivalent tooling is available.
We're hiring: https://nubank.workable.com/jobs/440029
Lots of Clojure and a few hours from beautiful beaches ;)
Companies are NOT out there to bring you in, waste several collective hours of their employees time who could be working otherwise, just to reject you. They WANT You to pass the interview.
If you don't pass the interview because they think you are not qualified, then that's something that can be fixed. You just need to study more and get more experience.
But if you don't pass because you're not a "culture fit", it means you probably came off as a difficult person to work with. And this article shows why.
Obviously. In Silicon Valley, Company knows best. /s
There are a lot of reasons you can fail the culture fit. Doesn't mean you aren't the problem, but as someone frequently interviewing candidates I can tell you blame also rests on the other side of the table.
I don't think that's necessarily the case. A lot of companies have very strong cultures tailored to certain personality types. Company A may encourage bluntness and risk taking where Company B may encourage more tactful feedback and careful planning of any task. It depends on the market the company operates in and the ingrained culture.
Or they're the kind of company that will ask you about your hobbies and then reject you if you don't have the same hobbies as the rest of the team. If you're a mild-mannered, introverted enterprisey person, and the company is a hip young startup staffed with extraverted brogrammers, you're going to be rejected for "culture fit". It's toxic.
>> In most cases when a company rejects you because of "culture fit", chances are there's something wrong with yourself.
I completely disagree. Interviewing teams reject candidates for all sorts of reasons that have nothing to do the candidate.
Reasons (valid or not) a applicant gets reject include:
- thinking candidate would get bored in a menial job
- discrimination
- unstated hiring freeze
- position is closed during hiring process
- position requirements are revised
- candidate wants to pair program, company does not, and vice versa
- interpersonal communication challenges, mostly around language barriers
- candidate seems too expensive
- candidate seems way too cheap, which seems too good to be true
- company believes candidate will not tolerate commute for extended period of time
- candidate bugged recruiter one too many times about status of interview process
- candidate overdressed for interview
- candidate underdressed for interview
- candidate reminds an interview too much of themself ("I'm the vision person, and we need some who likes to build the plan I come up with")
- the job is a demanding grind, and everyone who previously had kids has quit
- company doesn't like candidates education
- company worked for a stigmatized employer
- a backdoor reference check doesn't go well
This list could go one forever, and none of these things are something wrong with the candidate.
Source: was recruiter, saw people rejected for all sorts of reasons
A job interview is a social game. An interviewee coming in to an interview thinking this is purely about their ability to whiteboard a solution or solve a puzzle may end up a "poor cultural fit". The main deciding factor is whether you can get along with the people interviewing you for the duration of the interview. The secondary factor is that you meet some minimum bar of smart/skills/knowledge.
Companies are NOT out there to do anything. They don't want you to pass or fail. The person interviewing you, who may have had a good day, a bad day, may have a certain background or certain preference, may know the hiring decision has already been made, may have another candidate they already prefer, may have their own little special FizzBuzz, or whatever. This person and you have to sit down for an hour and you have to convince them they should hire YOU. Even if they had a bad day. Even if you think vi is better than emacs and they prefer emacs. Even if they like object oriented programming and you're a functional programming guy. Even if they think you're too old to know how to code. You CAN do it. Then it's up to you to decide whether you want to work for a person who prefers emacs ;)
Are you aware that you sound like an apparatchik?
(Sorry if your post was sarcasm, I wasn't sure.)
And I'd probably be more likely to want to hire them, too! Asking their interviewer a technical question would show me that the candidate cares about the quality of his or her future co-workers.
Well done?
c: {[h;t]{(h;t)x}} / cons
h: {x 0} / head
t: {x 1} / tail
n: {h y t/x} / nth
p: h'-1_(~^:)t\ / print
r: {{$[^y;x;c[h y;x]o t y]}[0N;x]} / reverseThis post included, it's currently at #11 but is clearly more popular than the 10 above it.
What's up with that? Why is this obviously popular subject on hiring practices (which I would think is prime HN material) being effectively censored?
Moderately sure that comment threads on a submission are strictly ordered by score.
Was the naming thing a reference to William Gibson, or Rumpelstilskin? Is there really a language named after Le Guin? What other references did I miss?
This is a common thing among many fantasy fiction works, so it's hard to tell what inspired it; might not be Eartsea.
Much older. The idea that knowing a being's True Name gives you power over it is common to many human cultures.
There is not actually a language named after Le Guin (at least, not that I know of). However, she did write a fantasy series (Earthsea), in which wizards gain their power from the use of names.
His wife plays the possessed violin from Lovecraft's "The Music of Erich Zahn".
Beautiful.
I think the first time I learned the value of knowing the true names of things was here:
https://www.youtube.com/watch?v=dlbMuv-jix8#t=12m54s
before I studied it in depth reading Rothfuss.
If I could se a new one of these every week and play along in the terminal I'd have a a lot of fun (all in the name of learning to!).
- Almost all the interviews followed the same pattern maligned a lot in HN.
- Almost in every one of those loops, I felt like my current experience building storage systems and replication wasn't examined very well.
- I had many other informationals where the company felt completely borgish (no one knew what the other parts were doing), where the recruiters were clueless, where they were trying to undercut me by 50% or so(We have the smartest!), under level me (We always under level outside hires!), where they had no real reason to hire me (We are always looking for smart people!), where they were just trying to prove that they are smarter and so on. All this when I had 5 odd offers in hand and actually told them that to see if they would have a productive conversation rather than wasting everyone's time.
But I do have different takeaways from these though:
- For every guy like me, there are a lot of other folk who can probably spend the whole hour with you and make you leave ambivalent. You will never know whether you hired him because you liked him or because of his skills.
- An actual (even a flawed one) datapoint is better than nothing.
- If the guys interviewing me are anything like me, They probably spend 5-10 hours a week on interviews already. This means custom tuning a process for each candidate is exorbitantly hard. I mean we do look at resumes and try to calibrate what we expect from a given candidate and we do assign certain folk to get information about their current positions - but a completely personalized loop is still in the zone of people who have been the top 1% of any company. If you aren't there, you gotta expect the rote process.
- I don't have a week to fully dedicate to each company. I currently have a hard job - and I prefer to prepare for a generic process rather than custom one.
- It isn't really hard to prepare for this anyway: In fact the rote process makes it so much easier. There are set concepts and websites. I built my own list, filled them in with actual notes, practiced a 100 problems to get into the mode and was in.
- At the end of the day, all these companies have great people in great teams solving great problems. It is very very hard to distinguish one from the other, There is a very high chance you will end up doing very similar work for one or other. So now the distinguishing factors become something else.
- The recruiters in general are just trying to meet a quota.
The Python list should have printed out [0, 1, 2] ... so (print "[") and (print ", ") ... Maybe that's why we didn't get invited to the next interview :)
For a moment there I thought some Python in Lisp thing was going to get pulled out of the hat.
/me heads back to read the rest.
That's not trying hard enough. That's litterally the definition of a cons cell. (The array is simply raw memory and the index is a pointer)
Then I read it a couple more times, while googling for what I didn't understand. After, I agreed with the praise.
I learned something.
It really takes a lot of effort to be a competent interviewer. One needs engineering skills, but also soft skills, empathy, teaching skills. Doing interviews doesn't count in one's performance evaluation, especially given that it's almost impossible to figure out whether an interview was performed in a good or just average way, so for the typical engineer it's a PITA with no upsides. Candidates will be treated respectfully, but the process is what it is. There are no incentives to improve it, especially for companies that are in demand.
Just so you get an idea how hard it is to manage hiring, when we came up with our interview process we more or less had to do the following:
1. Selected a group of competent developers with interviewing experience. They were then responsible for the whole technical side of interviewing.
2. Convinced management to offer support for the initiative.
3. Evaluated multiple options on how to structure the interview and chose one (e.g. phone + several face to face).
4. Prepared guidelines on how to behave, overcome typical biases, evaluate candidates.
5. Prepared a pool of exercises.
6. Added verification steps to make sure that nothing went wrong in the phone interviews.
7. Ensured that there was always a mix of experienced vs. unexperienced interviewers in face to face interviews.
8. Set out some rules for offering feedback to interviewers after face to face interviews. I have to confess that this never really worked properly. Offering negative feedback is particularly difficult.
9. Checked all of the above with management and implemented.
Then we had to adjust based on practice:
* added guidelines on special situations such as timezone differences, interviewer mistakes, insufficient information gathered during the interview, replacements, interview preparation, offering feedback, offensive remarks, etc.
* scheduled weekly review rounds for all phone interviews and made sure that people took part and took things seriously
* tinkered a lot with the candidate funnel to ensure that interviewers aren't swamped by inadequate candidates but also that we don't miss competent candidates with unusual applications
* balanced between growth goals visible as management pressure to hire and ensuring that the process stayed true to its goal to demand certain technical standards from the candidates
* experimented with various ideas such as homework, different interview structures, laptop vs whiteboard vs paper, access vs no access to docs, etc
* made sure that office management personnel understood the above and was able to work with the process.
When you think about it, this was "just" a typical phone + face to face interview, not rocket science. And the description covered only the technical part, there was also HR, sponsoring conferences and job postings, managing invitations and organizing the appointments, expenses reimbursement, preparing reports for management, etc.
Such an interview method is not typically designed to find what's unique about each candidate and allow them to best express their individuality. It's a machine designed to answer to answer the question of whether someone is (probably) able to work productively in the organization.
The process starts decaying the moment it's not supervised. People come up with brilliant ideas about what could be improved (let's ask candidates to solve problems from programming competitions!), don't stick to the reviews, reuse leaked exercises, become too lenient or too harsh, don't prepare, etc.
At this point, I suspect I'm never going to choose to learn Lisp.
I'm a firm believer in the value of learning a functional language, and I totally understand that from a historical perspective Lisp is important, but does it really have much to recommend it over modern functional langauges?
yup, I was doing this too.
notice also he did give a nod/mention in the post
So if you learn Lisp, you learn a language that transcends programming style. It's much more universal than Haskell.
Also if you happen to like what you see in macros, try also checking out parsing words from forth or factor.
Going by that metric, we should all switch to C and C++ as they are obviously the way to get software done.
Famous are schedulers or AI apps, such Orbitz and DART. http://www.paulgraham.com/carl.html
https://stackoverflow.com/questions/543579/what-is-the-most-... and http://franz.com/success/ have lists.
It's this precise attitude that turns me off Lisp. First, it's not actually that hard to understand. Sure, it's harder than most other languages, but if you've done programming in half a dozen languages (some functional, etc.) Lisp holds no real mysteries.
More importantly, being hard to understand is a bad thing. A large part of what makes a good programmer is the ability to write clear, robust, easy to understand code. Yet Lisp advocates seem to love to talk up how hard the language is to learn and how subtle and mysterious it is. I'm sure that appeals to teenage boys, but it is objectively a bad thing! Like, literally - hard to understand code has all sorts of obvious disadvantages, and no compensating advantages over easy to understand code. It's a bad thing!
When the language is easy to work, you delve into harder problems.
Any recommendations for getting starting?
Yeah, because you come off as completely nuts. Oh, and an asshole since you chose a language the interviewer didn't know then refused to answer basic questions.