1,181 karma · joined February 6, 2013
I can't find the snippet but it's somewhere in the "DDD is not for perfectionists" vein
Transpiling is common in js only because there isn't/wasn't a standard like webasm.
The Golden Rule: When in doubt, use a hashmap. Almost all code challenges are about finding an algorithm or datastructure to fit the problem/solution. Many of them are solvable efficiently via a hashmap.
Preparation
- Practice on a whiteboard
- Do mock interviews with the most skilled people you can find and get feedback! This is critical to glean any information about how you're actually doing! I could volunteer to do that for you remotely if you like. Send me your contact info. I'm a distributed systems guy but could walk you through some problems and tell you how you're doing with whatever you're using for tech very likely still. Drop a note on how to connect if you're comfortable.
- Take an algorithms course before you interview. (The princeton sedgewick one is great and easy to grokk. see coursera: https://www.coursera.org/learn/algorithms-part1)
During:
- Write tests for your code during the interview to demonstrate production quality code.
Especially if interviewing for eg Google. They don't give super tricky problems in every interviews (eg during phone screen) - focus on writing good code that is tested and will compile and run after the interview, not writing mediocre code fast.
- It's okay to incrementally improve your solution. Talk through your thinking. Start at the naive solution and then work toward optimal. Eg give two lists, find any number from list a sums to any number from list b. To start, you could write a couple quick tests on the board to make sure you understand the problem. Then you could reason about solutions - say you could use nested for loops. That's O(n squared) which isn't suitable as a solution. So you ask if the data is sorted. If they say no, you can sort lists, iterate through one and binary search on the larger list to get to an asymptotically linearithmic solution. That's suitable so you write that fairly swiftly. To improve you discover you only need to sort one list so you change the solution to only sort the larger one and iterate through the smaller. If there is extra time you might start to reason about how you can move toward a linear solution. Remember I said the golden rule is use a hashmap? Why don't you make a hashmap out of one of the lists and iterate through the other one to find values in the map? Don't just sit there and take it away to the corner and try to solve it.
God Mode: - WAYYYY before you take the interview: Stop using an IDE at work if you're working in a statically typed language. Use emacs, or vscode or whatever you fancy. Moving to emacs made my brain learn the qualities of the language at an intimate level faster than anything else. You check the docs if you forget the api until you stop forgetting the API. It slows you down a bit at first so it's an investment but whatever - tack 25% on your estimates for a few weeks. You can revert to the IDE for larger refactoring work.
Lots of new research kicking around. That's a science-backed approach.
I personally prefer working with statically typed languages but I've been working with elixir for the last 8 months or so and do not feel very compelled by the use of dialyze (type checker) in the dynamically typed language - you get used to the idioms and try to keep the code type-y but it seems unidiomatic to take type safety too far in a dynamically typed language when you don't get the performance benefits. You cover the things you're likely to get wrong but embrace it for the sake of development speed otherwise. For a new project the right question to ask is "why would we use this instead of a statically typed language." I suppose for an existing project the question this is trying to solve is "how can we reduce bugs now that we've made it to market."
We use a blend of Elixir/OTP, Scala/Akka, Ruby/Rails (API, migrations), and Ember, alongside Kafka, Postgres, and Redis to build a Manufacturing Execution System which listens to signals from machines used in manufacturing, and writes back to them to track parts and control manufacturing processes. There are many interesting features to tackle, and a good start on the v2 architecture with many small elixir apps interacting through kafka (via command and event topics). Scala is used for individual part tracking on a model of the physical process route.
The domain is physical, and is a great fit for event driven systems and domain driven design. We talk about things in terms of aggregates, commands and events more or less daily. The code is well covered. It is a small company so we have a few opportunities in terms of process maturity but generally the technical approaches are reasonable.
The company is young but bootstrapped and profitable and growing with substantial equity available for really strong hires. We have some very smart people kicking around as is common in my experience in startups that end up turning out pretty well. I was working at Google for a bit - I'm trying to bring examples from my experiences there into the culture here as we grow.
I worked here on contract and flipped to full time on seeing the equity package, problem space, and rate of growth. It's a good opportunity with smart people in an interesting technical space.
I'm currently hoping to fill a spot for one of those ember/ruby/elixir people (any 2 would be good). I come from a more functional background with scala but I think with the current technology having 2 of 3 of ember/ruby/elixir would be good.
Strong Scala or FP candidates would also be welcome to come if they're alright trying on dynamic typing in elixir as there is a lot of work to be done squarely in elixir and scala right now. You'd be able to pick up rails easily enough for what it's used for.
contact: ...jason...at...funnelcloud...dot...io...
People can think what they want I guess. It just has more of an effect on the world than I thought it used to so I feel a little saddened watching this new dark age come about.
This is for 1h of compute in the calculation so would you not actually need to run for a very long time, and also be spending in each and every one of those blocks?
Again sorry for my ignorance - hoping for some insight.
It was incredibly painful to start using it full time but I built good habits from the start as I re-learned touch typing. It's a very valuable experience watching the brain learn a new keyboard layout as an adult.
From there it took me maybe a month or two to be very confident. I then was unable to type in qwerty without looking at the keys for a couple years. Now my brain is pretty happy switching back and forth. It's odd but I find Ive learned things like typing one handed with colemak on keyboards that are qwerty (eg my macbook) and odd things like that so the brain keeps learning to work in a pinch in the edge cases years later.
Colemak is _incremental_ to qwerty so is significantly easier to learn and get started with full time than dvorak for a software engineer.